To design a composite service, integration developers use a web service composition language BPEL to specify the invocation sequence through Oracle BPEL Process Manager (PM). This composite service has its own WSDL definition and endpoint through the creation of a Partner Link which allows a business event, for example, to be published to the Oracle BPEL Process Manager or to interact with a partner service.
To efficiently utilize a BPEL process in orchestrating a meaningful business flow, the basic concept of creating a BPEL process is discussed in this section.
A BPEL process specifies the exact order in which participating web services should be invoked either sequentially or in parallel. In a typical scenario, a BPEL process receives a request. To fulfill it, the process invokes the involved web services and then responds to the original requestor. Because the BPEL process communicates with other Web services, it heavily relies on the WSDL description of the web services invoked by the composite services.
For example, a BPEL process consists of steps that are placed in the exact order that will be invoked. And these steps are called 'activities'. Each activity represents basic construct and is used for a common task, such as use <invoke>
activity to invoke a web service; use <reply>
to generate a response for synchronous operations.
Key Activities and Message Patterns
In supporting web services and message exchanges over the web, there are many communication patterns to model the processes. For example, a basic request - response pattern can be used in a synchronous or asynchronous way. A synchronous request - response pattern is one that waits for a response before continuing on; while an asynchronous request - response pattern does not wait for a response before continuing on which allows operations to occur in parallel until the response is ready. Another pattern can be request only operation that does not require response at all.
Based on the message patterns, appropriate activities representing various actions can be orchestrated in a meaningful way and enable the services.
To have better explanation about the message patterns and some key activities that are frequently used in a BPEL process, the following two message patterns are used to further describe how to build a simple BPEL process:
For synchronous request-response service type, a consumer or client sends a request to a service, and receives an immediate reply.
Synchronous Request - Response Message Pattern
Many online banking tasks are programmed in request-response mode. For example, a request for an account balance is executed as follows:
A customer (the client) sends a request for an account balance to the Account Record Storage System (the server).
The Account Record Storage System (the server) sends a reply to the customer (the client), specifying the dollar amount in the designated account.
The synchronous request-response interaction pattern interpreted in a BPEL process can be illustrated in the following diagram:
Synchronous Request-Response Interaction Pattern in BPEL
In the above diagram, there are two BPEL processes involved to complete the synchronous request-response service:
BPEL Process as Client (Request)
When the BPEL process is on the client side of a synchronous transaction, it needs an Invoke activity to send the request and receive the reply and a PartnerLink to carry information between the inquiry BPEL process and a Web service.
BPEL Process as Service (Response)
When the BPEL process is on the service side of a synchronous transaction, it needs a Receive activity to accept the incoming request, and a Reply activity to return either the requested information or an error message (a fault). Additionally, it requires a PartnerLink to carry information between the web service and the inquiry BPEL process.
Note: Sometime, an Assign activity is placed before a Reply activity to take received data as an input variable and assign it the Reply activity as an output variable in respond to the request.
Partner Link
A partner link defines the location and the role of the web services that the BPEL process connects to in order to perform tasks, as well as the variables used to carry information between the web service and the BPEL process. A partner link is required for each web service that the BPEL process calls.
Invoke Activity
An Invoke activity opens a port in the BPEL process to send and receive data. It uses this port to submit the required data and receive the response.
In the account balance inquiry example, the Invoke activity submits the account number entered by the customer to the server and receives dollar amount in return as the account balance. For synchronous callbacks, the Java rule function supports the feature through Business Event System. Thus, only one port is needed for both the send and receive functions.
Receive Activity
A Receive activity waits for an incoming request data as an input variable. For example, the Receive activity accepts the account balance inquiry by taking the account number as an input variable to the server.
Reply Activity
A Reply activity enables the business process to send a response message in reply to a message that was received through a Receive activity. For example, the Reply activity takes the account balance from the server as an output variable and sends it back to the requestor.
The combination of a receive and a reply forms a request-response operation.
The composite BPEL process design flow should be orchestrated with necessary BPEL components or activities so as to successfully invoke a synchronous web service.
Use the account balance inquiry as an example. The service invocation sequence can be orchestrated in Oracle JDeveloper BPEL Designer as shown in the following diagram:
An Example of a BPEL Process Diagram
A client sends the request by entering account number for the balance inquiry.
The Receive activity receives it as an input variable.
The Assign activity takes the account number and passes it to the Invoke activity.
The Invoke activity submits the account number entered by the client to a ActBalanceService
Partner Link and receives dollar amount in return as the account balance.
The Assign activity then takes the dollar amount as an input variable and passes it to the Reply activity.
The Reply activity takes the account balance and replies to the requestor.
The above composite service - BPEL process requires the following tasks at the design time:
Adding a Partner Link
Adding an Invoke Activity
Adding a Receive Activity
Adding a Reply Activity
Adding an Assign Activity
Once a Partner Link is successfully added to a synchronous BPEL project, a WSDL description URL that corresponds to the ActBalanceService business event service with appropriate event payload will be automatically generated. This ActBalanceService Partner Link serves as a bridge to communicate information between the service and the synchronous BPEL project.
Note: The generated WSDL URL of a BPEL process can also be used in defining an event subscription if the BPEL process is used for service invocation through the Business Event System.
For One-way or request only service type, there is only one input element which is a client's request for a service and no response is expected.
Request Only Message Pattern
For example, a stock symbol sends updated price to the stock quote service when the price change using the request only operation. The server updates the stock price but no response is sent back.
This type of interaction pattern interpreted in a BPEL process can be illustrated in the following diagram:
One-Way (Request Only) Interaction Pattern in BPEL
The following two BPEL processes are involved in this type of service:
BPEL Process as Client (Request)
As the client, the BPEL process needs a valid PartnerLink and an Invoke activity with the target service and the message. As with all partner activities, the WSDL file defines the interaction.
BPEL Process as Service
To accept a message from the client's request, the BPEL process needs a Receive activity only.
In the stock quote update example, the Invoke activity submits a stock symbol along with a market price to the StockQuote service in a server. The Receive activity takes the new price as an input and update the StockQuote service.
The following diagram illustrates the service invocation sequence for the stock update example in Oracle JDeveloper BPEL Designer:
A client sends the stock symbol and updated price.
The Receive activity receives it as an input variable.
The Assign activity takes the new price and passes it to the Invoke activity.
The Invoke activity submits a stock symbol along with an updated price to the StockQuoteService
Partner Link in a server.
This composite service - BPEL process requires the following tasks at the design time:
Adding a Partner Link
Adding an Invoke Activity
Adding a Receive Activity
Adding an Assign Activity
Like synchronous request - response operation, once a Partner Link is successfully added to a BPEL project, a WSDL description URL that corresponds to the service with appropriate event payload will be automatically generated.