BPEL Cookbook: Best Practices for SOA-based integration and composite applications development

By Arun Poduval , Doug Todd , Harish Gaur and 12 more
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Extending Enterprise Application Integration

About this book

Service Oriented Architecture is generating a buzz across the whole IT industry. Propelled by standards-based technologies like XML, Web Services, and SOAP, SOA is quickly moving from pilot projects to mainstream applications critical to business operations. One of the key standards accelerating the adoption of SOA is Business Process Execution Language for Web Services (BPEL).

BPEL was created to enable effective composition of web services in a service-oriented environment. In the past two years, BPEL has become the most significant standard to elevate the visibility of SOA from IT to business level. BPEL is not only commoditizing the integration market, but it is also offering organizations a whole new level of agility - ability to rapidly change applications in response to the changing business landscape. BPEL enables organizations to automate their business processes by orchestrating services within and across the firewall. It forces organizations to think in terms of services. Existing functionality is exposed as services. New applications are composed using services. Communication with external vendors and partners is through services. Services are reused across different applications. Services are, or should be, everywhere!

Publication date:
July 2006
Publisher
Packt
Pages
188
ISBN
9781904811336

 

Chapter 1. Extending Enterprise Application Integration

by Praveen Chandran and Arun Poduval

Leverage the orchestration capability of Oracle BPEL Process Manager to enable standards‑based business process integration that complements traditional EAI middleware.

Most organizations have a highly disparate application infrastructure comprising a variety of applications from multiple vendors, running on different platforms, and created with completely different technologies. Traditional Enterprise Application Integration (EAI) products—from companies such as TIBCO, webMethods, Vitria, and SeeBeyond—have emerged in the last decade to tackle these integration challenges. Over the last few years, many organizations have made significant investments in these EAI solutions. As a result, business integrations in the EAI space tend to be locked into a single vendor, and the integration components are tightly coupled.

The cost of maintaining these proprietary integration links is a significant burden. Specialized skills are required, exacerbating the cost and stability concerns. Furthermore, ripping and replacing existing EAI solutions is not a plausible alternative for an organization protecting massive investments in EAI.

BPEL addresses all these problems by delivering a standards-based, platform-neutral solution. The loosely coupled BPEL process eliminates vendor lock-in, reduces integration costs, and provides interoperability; it also adds a sophisticated layer of security, exception management, and logging. Most important, companies can leverage their existing infrastructure, service-enable it, and orchestrate it using BPEL.

In this installment of The BPEL Cookbook, we will present an architectural blueprint for leveraging Oracle BPEL Process Manager to develop new integration solutions as well as interface with existing ones. It includes a case study in which orchestrated web services must be integrated with existing heterogeneous EAI solutions based on TIBCO BusinessWorks and webMethods.

Furthermore, because any business process implementation is incomplete without a carefully designed error management, security, and logging framework, we'll explain how BPEL scopes and compensation handlers can make this process more robust and fault-tolerant, as well as how to secure the BPEL process and participating services.

Case Study Background

EAI is an excellent driver for service-enabling existing applications; existing middleware processes can be exposed as web services, which are then orchestrated via BPEL.

The following diagram illustrates a generic approach in which Oracle BPEL Process Manager is used to orchestrate existing EAI interfaces as well as to integrate new applications. This approach assumes that the middleware can expose the business processes as web services and that the application servers themselves have web service interfaces.

An analysis of a specific case study involving two traditional EAI middleware products demonstrates how BPEL can play an important role in integrating the two products.

In many organizations, changes made in one customer "system of record" are not propagated to the other systems in which customer data is maintained. Consider a scenario in which an enterprise, for various business reasons, ends up using two middleware products from different vendors, such as Siebel CRM integrated with TIBCO BusinessWorks and SAP R/3 integrated with webMethods.

In this model, inconsistent customer data across the SAP and Siebel systems can adversely affect customer service levels and can drive down department and organization revenues. Rather, consistency can be maintained through a common Customer Details Management Module that has multiple interfacing points with the TIBCO and webMethods integrations. For example, when Siebel receives customer data, it checks whether the customer is a new or existing one, and then either adds new data to SAP or updates existing customer data in both apps.

You could use the existing middleware tools (TIBCO and webMethods) to achieve this integration, but doing so would simply increase the footprint of proprietary integration and vendor lock-in. This situation represents an excellent opportunity to service-enable the applications, thereby achieving a standards-based, vendor-agnostic solution.

The first step toward achieving a standards-based interface in EAI is to expose the process as a web service. Most middleware platforms can talk to each other through web services, but the scenario becomes complex when a set of interfacing services must be glued together with appropriate business logic.

You could use another middleware process or even complex Java code to orchestrate web services. However, the process would have to provide following capabilities:

  • Parallel web service invocations

  • Asynchronous web service invocations

  • Loose coupling between services and portability

  • Exposing the whole orchestration with standards-based interfaces

  • Orchestration monitoring

As shown in the following figure, a prefabricated standards-based orchestration solution based on BPEL can address these issues:

Introducing BPEL into this scenario has the following potential advantages:

  • BPEL supports loosely coupled web service orchestration.

  • Business logic (even parallel flows!) can be represented in simple XML tags.

  • Data can be easily routed among services with simple assign (copy rules) and invoke statements.

  • The Customer Details Management Module can be invoked as an independent web service component from another orchestration, middleware tool, or web application.

  • Processes can be managed via a simple GUI, such as with Oracle BPEL Process Manager.

Most middleware tools can expose their business processes as web services, making it easier to bridge existing integrations with BPEL orchestrations. In fact, you can use a common message format for all the middleware service interfaces involved.

Now let's consider how Oracle BPEL Process Manager can be used to achieve this synchronization of customer data across SAP and Siebel.

 

Case Study Background


EAI is an excellent driver for service-enabling existing applications; existing middleware processes can be exposed as web services, which are then orchestrated via BPEL.

The following diagram illustrates a generic approach in which Oracle BPEL Process Manager is used to orchestrate existing EAI interfaces as well as to integrate new applications. This approach assumes that the middleware can expose the business processes as web services and that the application servers themselves have web service interfaces.

An analysis of a specific case study involving two traditional EAI middleware products demonstrates how BPEL can play an important role in integrating the two products.

In many organizations, changes made in one customer "system of record" are not propagated to the other systems in which customer data is maintained. Consider a scenario in which an enterprise, for various business reasons, ends up using two middleware products from different vendors, such as Siebel CRM integrated with TIBCO BusinessWorks and SAP R/3 integrated with webMethods.

In this model, inconsistent customer data across the SAP and Siebel systems can adversely affect customer service levels and can drive down department and organization revenues. Rather, consistency can be maintained through a common Customer Details Management Module that has multiple interfacing points with the TIBCO and webMethods integrations. For example, when Siebel receives customer data, it checks whether the customer is a new or existing one, and then either adds new data to SAP or updates existing customer data in both apps.

You could use the existing middleware tools (TIBCO and webMethods) to achieve this integration, but doing so would simply increase the footprint of proprietary integration and vendor lock-in. This situation represents an excellent opportunity to service-enable the applications, thereby achieving a standards-based, vendor-agnostic solution.

The first step toward achieving a standards-based interface in EAI is to expose the process as a web service. Most middleware platforms can talk to each other through web services, but the scenario becomes complex when a set of interfacing services must be glued together with appropriate business logic.

You could use another middleware process or even complex Java code to orchestrate web services. However, the process would have to provide following capabilities:

  • Parallel web service invocations

  • Asynchronous web service invocations

  • Loose coupling between services and portability

  • Exposing the whole orchestration with standards-based interfaces

  • Orchestration monitoring

As shown in the following figure, a prefabricated standards-based orchestration solution based on BPEL can address these issues:

Introducing BPEL into this scenario has the following potential advantages:

  • BPEL supports loosely coupled web service orchestration.

  • Business logic (even parallel flows!) can be represented in simple XML tags.

  • Data can be easily routed among services with simple assign (copy rules) and invoke statements.

  • The Customer Details Management Module can be invoked as an independent web service component from another orchestration, middleware tool, or web application.

  • Processes can be managed via a simple GUI, such as with Oracle BPEL Process Manager.

Most middleware tools can expose their business processes as web services, making it easier to bridge existing integrations with BPEL orchestrations. In fact, you can use a common message format for all the middleware service interfaces involved.

Now let's consider how Oracle BPEL Process Manager can be used to achieve this synchronization of customer data across SAP and Siebel.

 

Implementing the Customer Details Management Module


BPEL plays an instrumental role in automating the customer data synchronization process between SAP and Siebel. The steps involved in implementing this BPEL process are:

  1. 1. Expose TIBCO and webMethods processes as web services.

  2. 2. Orchestrate web services using a BPEL process.

  3. 3. Add exception-management capability to the BPEL process.

  4. 4. Secure communication between Oracle BPEL Process Manager, application adapters, and the EAI tool.

  5. 5. Centralize the logging and notification process.

Step 1: Expose TIBCO and webMethods Processes as Web Services

Customer information is represented in a canonical format and contains fields needed for both SAP and Siebel. If you're passing this generic format across TIBCO and webMethods, these platforms will convert the canonical format into Siebel and SAP customer records, respectively.

Here are the steps you would take to expose the BusinessWorks process as a web service:

  1. 1. Analyze the functionality offered by your BusinessWorks process, to determine whether it can be an independent component in the integration scenario.

  2. 2. Determine the input and output of the process.

  3. 3. If input and output are complex, use W3C XML schemas (XSDs) to define them. You can use XSDs to define your custom fault schema as well.

  4. 4. Create the WSDL, using the WSDL palette, and define input and output message formats (associate them with predefined XSDs, if required). You can import existing WSDL as well.

  5. 5. Configure an HTTP Connection resource.

  6. 6. Use a SOAP Event Source as the first activity, followed by business logic, and then use a SOAP Send Reply to expose the process as a service.

  7. 7. Associate the HTTP Connection resource with the Event Source.

  8. 8. Associate WSDL and Send Reply with the Event Source.

  9. 9. Handle possible exceptions, and use SOAP Send Fault for sending exceptions to the service client.

  10. 10. If your machine name is mymachine, the port used for the HTTP Connection resource is 8000, and the process name is SOAPService, your service can be accessed using the URL http://mymachine:8000/SOAPService.

  11. 11. Get the final WSDL of the service from the WSDL tab of the Event Source activity.

Here's how you would do the same with webMethods:

  1. 1. Check whether your webMethods Flow Service can be an independent component in the integration scenario.

  2. 2. Specify Execute ACL to Anonymous under the Permissions tab if you want to invoke this web service from outside the webMethods environment without any authentication.

  3. 3. Select the Flow Service in webMethods Developer, and click on Generate WSDL from the Tools menu.

  4. 4. While generating the WSDL document, specify the protocol (SOAP‑RPC/SOAP‑MSG/HTTP-GET/HTTP-POST) and transport mechanism (HTTP/HTTPS).

  5. 5. Define the target namespace for the WSDL document.

  6. 6. Enter the IP address or name of the machine where webMethods Integration Server is hosted in the Host field.

  7. 7. In the Port field, enter the port number to be used for connecting to the current Integration Server.

  8. 8. Save the WSDL document to the local file system. You can find the service endpoint in the generated WSDL document.

    Note

    webMethods Integration Server sends predefined SOAP faults for certain error conditions. If you have to send custom SOAP faults, you should use a custom SOAP processor. You should also use a wrapper service or a custom SOAP processor to expose the service as a document/literal web service.

Now, suppose you have the following three TIBCO web services (implemented with TIBCO BusinessWorks processes and TIBCO Adapter for Siebel):

  • Siebel Add

  • Siebel Update

  • Siebel Query

Similarly, you have the following webMethods web services deployed (using webMethods Integration Server and webMethods SAP R/3 Adapter):

  • SAP Add

  • SAP Update

The solution architecture can be summarized as follows:

As seen in the figure, the BPEL process brokers the conversation between the front-office call center and back-end SAP and Siebel CRM applications via EAI tools.

Here are some best practices for exposing middleware processes as web services:

  • Adhere to WS-I standards whenever possible.

  • Try to expose services in "document" style with literal encoding. If that option is not available, use "RPC" style with literal encoding. Although either is recommended by WS-I, you will find document style easier, at least when you create copy rules for a BPEL assign activity—with RPC style, all the schema elements come as separate message parts, whereas with document style, the entire message is delivered in one part. You can use a single copy rule to copy the entire schema, thereby easing the development effort, and verify the style and encoding in the final WSDL document.

  • Avoid the use of SOAP encoding; the SOAP Action attribute of WSDL is an empty string.

  • Confirm that the middleware uses WSDL 1.1 to describe the interface of the web service.

  • Use HTTP binding of SOAP.

  • Make sure that all XSDs used for describing the schema conform to the XML schema specification proposed by the W3C. For example, global element declarations should not use references to other global elements; that is, use the type attribute instead of the ref attribute.

Step 2: Orchestrate Web Services

Having exposed middleware processes as web services, you can then orchestrate them using Oracle BPEL Process Manager, which has a powerful, GUI-based BPEL-authoring interface.

Previously, we mentioned that an important aspect of the Customer Details Management Module is that it synchronizes customer data between SAP and Siebel. This process is visually created in BPEL Designer as shown in the following figure:

The BPEL Processes Images in this chapter have been edited for clarity purposes. Actual BPEL process will look slightly different in BPEL Designer (Partners Links are not shown in this BPEL process).

Here's a summary of this process flow:

  1. 1. A receive activity accepts the customer details (enterprise schema).

  2. 2. Details are passed to Siebel through assign and invoke (Siebel Query service) activities.

  3. 3. Via a pick activity, the Siebel Query result is used to determine whether the customer is existing or new.

  4. 4. If the customer is new, parallel execution is invoked, with flow activity adding the customer in both Siebel and SAP; otherwise, another parallel flow updates customer details in both applications.

  5. 5. If the customer details are not present in SAP, those fields are fetched from Siebel by Siebel Query. This and the other SAP fields to be updated are passed to SAP Update, possibly via a set of assign copy rules.

  6. 6. The final status of Customer Update/Addition is returned by use of an explicit reply activity.

As you can see, on either side of the business process are web services for adding and updating Siebel and SAP data. These web services, which we designed in Step 1, internally invoke EAI processes.

This BPEL process addresses the business requirements of customer management, but it still can't handle exceptions. For example, what would happen if a customer was added successfully in Siebel but addition failed in SAP? To address that issue, you need to enable exception management in your business process.

Step 3: Add Exception Management Capability

Exception management allows a BPEL process to handle error messages or other exceptions returned by outside web services and to generate error messages in response to business or run‑time faults.

The following table contains exceptions that need to be handled to make the customer management BPEL process more robust.

No.

Case

Resolution

Case 1

Siebel Query fails

Terminate the process; retry

Case 2

Siebel Add fails; SAP Add succeeds

Compensate to remove SAP record; retry

Case 3

Siebel Add succeeds; SAP Add fails

Normal flow; retry

Case 4

Siebel Add fails; SAP Add fails

Normal flow; retry

Case 5

Siebel Update succeeds; SAP Update fails

Normal flow; retry

Case 6

Siebel Update fails; SAP Update succeeds

Compensate to roll back SAP record; retry

Case 7

Siebel Update fails; SAP Update fails

Normal flow; retry

Cases other than 1, 2, and 6 (discussed later) needn't be handled explicitly to keep the data consistent.

It is necessary to track the status of the web service to catch exceptions and take appropriate actions. Before a discussion of how cases 1, 2, and 6 are handled, let's see how the status of a specific web service is tracked.

The entire BPEL process has these reply schema attributes:

  • Siebel_Add_Status

  • Siebel_Update_Status

  • SAP_Add_Status

  • SAP_Update_Status

All these attributes can have the values Failed, Success, or NA, which can be set by the BPEL process at various points. To set the Failed status, the process can catch the SOAP faults thrown by target web services (use a catch handler with each invoke activity). The client invoking the Customer Details Management Module can resend the details in case of any failures.

Now, let's see how exceptions are managed:

Case 1

If the Siebel query itself fails, the process should be terminated, and the invoking client can retry.

Case 2

When customer-details insertion fails in Siebel and succeeds in SAP (they occur in parallel), data consistency will be lost. Moreover, in the case of a retry, the following problems may occur:

  • If you try to invoke the BPEL process to insert customer details into Siebel, customer details may be duplicated in SAP.

  • If you try to invoke the BPEL process to update customer details, update in Siebel will fail, because there is no corresponding record.

To handle the situation, you have to delete the SAP customer record before a retry takes place, using another webMethods web service with a BPEL compensation handler and scopes.

The scope and compensate activities are key BPEL development tools. A scope is a container and context for other activities; a scope activity is analogous to a {} block in a programming language. A scope simplifies the BPEL flow by grouping functional structures, and provides handlers for faults, events, and compensation as well as data variables and correlation sets.

Oracle BPEL Process Manager provides two constructs for handling compensation:

  • Compensation handler: This handler is the business logic for achieving rollbacks. Handlers can be defined for processes and scopes.

  • Compensate activity: This activity invokes the compensation handler on an inner scope activity that has already successfully completed, and it can be invoked only from within a fault handler or another compensation handler.

Exceptions are caught at the scope level via catch handlers. Catch handlers, in turn, use the compensate activity to invoke the compensation handler for the inner scope. The compensation handler will perform the required rollbacks.

Returning to our example, let's assume that our BPEL process has two scopes: an inner one and an outer one. Invoke activities for SAP Add and Siebel Add services come under outer scope, but only SAP Add comes under the inner scope. A compensation handler can be associated with the inner scope, and the compensation handler will contain an invoke activity for the SAP Delete service.

You have to associate a catch block with the outer scope so that a SiebelAddfault sent by the BusinessWorks web service can be caught. Whenever a SiebelAddfault occurs, a compensate activity compensates the inner scope, and the SAP customer record is deleted. Note that compensate will be successful only if all the activities in the inner scope have been successful.

A modified BPEL process with scopes and compensation handlers is shown in the figure below:

Case 6

The transaction also fails if the Siebel update fails and the SAP update succeeds. This leads to data inconsistency; thus, you have to use compensation logic to roll back the transaction that occurred in SAP. The compensation handler is associated with the SAP Update service and will invoke the SAP Rollback service. Modification of the BPEL process will adhere to the guidelines identified earlier.

The ability to explicitly invoke the compensate activity is the underpinning of the error-handling framework of BPEL. Unlike traditional EAI compensation mechanisms, BPEL offers a standardized method of dealing with rollbacks.

Having created a BPEL process to orchestrate TIBCO and webMethods web services, let's see how we can make the communication between BPEL, adapters, and EAI tools more secure.

Step 4: Secure Business Communication

Security can be enabled at two levels: outbound (invoking secure TIBCO and webMethods services) and inbound (securing the BPEL process).

Outbound Security

TIBCO and webMethods services need to be secured to prevent unauthorized access. Oracle BPEL Process Manager supports HTTP basic and WS-Security authentication for calling external services. This example focuses on how to secure the TIBCO and webMethods services and mechanisms to call them from the BPEL process, using HTTP authentication.

Web services deployed in TIBCO BusinessWorks and webMethods Integration Server support HTTP basic authentication. While designing the TIBCO web service, check the Use Basic Authentication checkbox on the Transport Details tab of the SOAP event source activity. While deploying the web service by using TIBCO Administrator, you can set service access levels for different users/roles. When designing the web service with webMethods Developer, you can set the ACL (Access Control List) for different operations.

If you use basic authentication while deploying the TIBCO and webMethods services, the services, on each invocation, will expect credentials, and these should be passed by the BPEL process. This task can be achieved by setting two "partner link" properties: httpUsername and httpPassword. The value of these properties can be set statically as follows:

To pass the credentials dynamically, use a copy rule.

<copy>
<from variable="varUsername"/>
<to partnerLink="p1" bpelx:property="httpUsername"/>
</copy>

In addition, you can secure TIBCO and webMethods services by using WS-Security. BPEL processes can pass WS-Security authentication headers to WS-Security-secured web services. You need to define the WS-Security headers that the service supports in the WSDL document for the service. These header fields can then be manipulated as variables in the BPEL process, just like message-body data elements. You can find more details about WS-Security authentication in the HotelShopFlow example, downloadable from the OTN at http://www.oracle.com/technology/ products/ias/bpel/files/hotelshopdemostandalone.zip.

Inbound Security

BPEL processes can be secured from invocation by unauthorized users using HTTP authentication; it is also possible to set different credentials for different BPEL processes.

To enable this security, HTTP basic authentication has to be enabled at the application-server level. Credentials can then be extracted in the BPEL process and passed to TIBCO and webMethods web services as "partner link" properties.

For more details about BPEL security, listen to the "Securing BPEL Processes & Services" Webinar on OTN.

Step 5: Centralize Logging and Error Handling

Your business processes are now secure and robust, but it is equally important to build logging and notification capability into them. Building a centralized logging and error-handling framework will make the application even more robust, increase reusability, and reduce development costs. You can build such a framework by using a web service from the BPEL process as well as from middleware. Via Oracle BPEL Process Manager, you can add logging to this service with the file adapter and require that an email notification be sent in case of error.

The following sample schema can be used for the framework:

Schema Element

Description

ROLE

Roles such as ERROR, DEBUG, WARNING, and INFO

CODE

Error code

DESCRIPTION

Error description

SOURCE

Source of error

EMAIL

Email ID to which notification has to be sent

This BPEL process can be exposed as an asynchronous one-way web service, which makes the clients of this service continue operations without any delay. The centralized logging and notification process LogNotify is shown in the following figure (Partners Links are not shown in this BPEL process for clarity purpose):

As shown in the figure above, the LogNotify process does the following:

  1. 1. Receives information to be logged from an external process.

  2. 2. Invokes Log Service to write this data into a log file. Log Service leverages the file adapter for this purpose.

  3. 3. If logging is successful, the process completes. In addition, if the ROLE field contains ERROR, the service will notify the relevant person via email. Email information is retrieved from the original message received (see the sample schema).

  4. 4. If notification fails, the process ends after the notification error has been logged in a file.

Each invoke activity in our main BPEL process can have a separate try-catch block. SOAP faults sent by the middleware process (which may even include exceptions thrown by the end application) are handled in the catch block and routed to the common logging and error-handling framework.

The figure below shows how the LogNotify process is invoked when Siebel Add fails:

 

Conclusion


The integration market is flooded with powerful EAI products, with which lots of integration has already been done. BPEL represents a unique choice for service-enabling these existing EAI solutions. By exposing existing middleware processes as web services and orchestrating them with Oracle BPEL Process Manager, organizations can embark on the route of SOA.

About the Authors

  • Arun Poduval

    Arun Poduval works as a Technical consultant at Midwave Corporation specialized in SOA/Middleware.

    Browse publications by this author
  • Doug Todd

    Doug Todd is CTO of Enterra Solutions in Yardley, PA. He has more than 20 years of experience in systems architecture, applications architecture, systems integration, and applications integration with major corporations. Todd is responsible for Enterra's overall IT strategy and tactical implementation, enterprise information architecture, and technology product offerings. Doug Todd worked on Chapter 5.


    Contact Doug Todd

    Browse publications by this author
  • Harish Gaur

    Harish Gaur has more than 13 years of experience in the enterprise software industry including 7+ years at Oracle. He is currently the Director of Product Management for Fusion Middleware at Oracle. In his current role, he works closely with strategic customers implementing SOA & BPM using Oracle Fusion Middleware. He is co-author of BPEL Cookbook (2007) and Fusion Middleware Patterns (Sept 2010)

    Before Oracle, he worked as a Solution Specialist with Vitria Technology educating customers about the benefits of Business Process Management. Prior to that, he helped Fortune 500 companies architect scalable integration solutions using EAI tools like webMethods and CrossWorlds (now IBM).

    Harish holds an engineering degree in Computer Science and is an MBA from Haas School of Business, UC Berkeley.

    Contact Harish Gaur

    Browse publications by this author
  • Jeremy Bolie

    Jeremy Bolie is a Senior IT Manager at QCT, managing the custom applications and Documentum development team. Jeremy has over 10 years of experience with Java and Oracle technologies, and has been involved with web services and Service-Oriented Architectures since the late 1990s. Jeremy Bolie and Michael Cardella worked together on Chapter 9.


    Contact Jeremy Bolie

    Browse publications by this author
  • Jerry Thomas

    Jerry Thomas is Chief Architect at CenterStone Software, which helps many of the world's largest organizations automate and manage their real estate, facilities, personnel, assets, leases, and workplace operations more efficiently. Thomas focuses on CenterStone's enterprise workplace management product and web services, BPEL, and system infrastructure. Prior to CenterStone, Thomas worked as a consultant and held principal development positions at Riverton, ONTOS, and Hewlett-Packard. Jerry Thomas wrote Chapter 6 for this cookbook.


    Contact Jerry Thomas

    Browse publications by this author
  • Kevin Geminiuc

    Kevin Geminiuc currently works as a senior software architect in Denver. Over the last 15 years, Kevin has worked as a systems architect, technical manager, developer, and hardware engineer. Kevin's technical interests include SOA, RFID, AVL, and genetic software. Kevin contributed Chapter 4 for this book.


    Contact Kevin Geminiuc

    Browse publications by this author
  • Lawrence Pravin

    Lawrence Pravin is the Product Manager, Process Integration Packs, Sierra Atlantic Inc. Process Integration Packs deliver end-to-end business process integration solutions between enterprise applications. He has over 10 years of rich experience in packaged applications, and has deep integration expertise with Oracle, PeopleSoft, Siebel, and SAP applications. Lawrence Pravin worked on Chapter 2 for this book.


    Contact Lawrence Pravin

    Browse publications by this author
  • Markus Zirn

    Markus Zirn is a Senior Director of Product Management for Oracle Fusion Middleware. In this role he heads the Strategic Customer Program, where he works with Oracle's leading and most innovative middleware customers. He has been part of the Enterprise Software industry for more than 10 years, including roles as Vice President of Product Marketing and part of the founding team of QUIQ and as a Management Consultant of Booz Allen & Hamilton's Silicon Valley High Tech Practice. Markus' passion for Service-Oriented Architecture (SOA) and BPEL stems both from practical experience designing and optimizing business processes as part of process reengineering projects and from being part of the advent of "software as a service" before web services became mainstream. He holds a Masters of Electrical Engineering from the University of Karlsruhe and is an alumnus of the Tripartite program, a joint European degree from the University of Karlsruhe, Germany, the University of Southampton, UK, and ESIEE, France.


    Contact Markus Zirn

    Browse publications by this author
  • Matjaz B. Juric

    Matjaz B. Juric holds a PhD in computer and information science. He is a full-time professor at the University of Ljubljana and heads the Cloud Computing and SOA Competence Centre (http://www.soa.si). Matjaz is an Oracle ACE Director and has been designated Java Champion and IBM Champion. He has more than 20 years of work experience.

    He has authored and coauthored Do More with SOA Integration: Best of Packt, WS-BPEL 2.0 for SOA Composite Applications with IBM WebSphere 7, Oracle Fusion Middleware Patterns, Business Process Driven SOA using BPMN and BPEL, Business Process Execution Language for Web Services (both English and French editions), BPEL Cookbook (which was awarded the best SOA book in 2007 by SOA World Journal), SOA Approach to Integration, Professional J2EE EAI, Professional EJB, J2EE Design Patterns Applied, and Visual Basic .NET Serialization Handbook.

    He has published chapters in More Java Gems, Cambridge University Press, and in Technology Supporting Business Solutions, Nova Science Publishers, Inc. His work has also been published in several journals and magazines and presented at conferences.

    Browse publications by this author
  • Michael Cardella

    Michael Cardella is a Staff Engineer at Qualcomm CDMA Technologies (QCT). Michael works in the custom applications development team, primarily on web-service- and business-process-related applications. Previously he served as Principal Architect for a leading web services security and management product.


    Contact Michael Cardella

    Browse publications by this author
  • Praveen Ramachandran

    Praveen Ramachandran works as a Technical Consultant for Midwave Corporation focusing on BPEL and other EAI technologies.

    Midwave is a rapidly growing firm that specializes in building highly available and highly secure information technology systems for medium to large companies and government agencies in seven midwestern states. Midwave is an Oracle Partner.

    Contact Praveen Ramachandran

    Browse publications by this author
  • Sean Carey

    Sean Carey is a Software Architect at SPS Commerce, a leader in hosted EDI. Sean has over seven years of experience in mission-critical e-commerce implementations, and 15 years of industry experience in software design. Sean Carey gave us Chapter 7.

    Contact Sean Carey

    Browse publications by this author
  • Stany Blanvalet

    Stany Blanvalet is a BPEL and J2EE consultant. Previously, working as a Java EE architect, Stany introduced and administered Belgacom's BPEL-based DSL provisioning application, a mission-critical BPEL production system. He is a contributor to the Jaisy-ORABPEL Interface project , an open-source JMX monitoring tool for Oracle BPEL Process Manager. Stany Blanvalet contributed Chapter 10.

    Contact Stany Blanvalet

    Browse publications by this author
  • The Hoa Nguyen

    The Hoa Nguyen currently works for the SDC subsidiary of SpaceBel SA in Brussels as senior software engineer. His main interests are J2EE, web services, and workflow development with BPEL. Since 2001, he has been one of the lead engineers of the SSE project team at SpaceBel and is also in charge of SSE software releases and on-site SSE software installations at ESA. The Hoa Nguyen and Yves Coene contributed Chapter 3.

    Contact The Hoa Nguyen

    Browse publications by this author
  • Yves Coene

    Yves Coene currently works for SpaceBel SA in Brussels as Project Manager. He has 15 years of experience in aerospace software projects such as Ariane 5, the International Space Station, F16 MLU, and various other projects for the European Space Agency. Since 2001, he and his team have been responsible for the SSE project for ESA in Frascati, Italy.

    Contact Yves Coene

    Browse publications by this author
Book Title
Unlock this book and the full library for FREE
Start free trial