Business Process Execution Language provides an “Orchestration Engine” for describing exchanges of information internally or externally. BPEL deals with functional aspects of business process: Control flow (branch, loop), asynchronous conversations and correlation, long running nested units of work (Transactions). BPEL Supports long running business transactions and activities, coordinating asynchronous communication between services, manipulating data between partner interactions.
Web Services Business Process Execution Language (WS-BPEL) is an XML based programming language to describe high level business processes. A 'business process' is a term used to describe the interaction between two businesses or two elements in some business. An example of this might be company A purchasing something from company B. BPEL allows this interaction to be described easily and thoroughly such that company B can provide a Web Service and company A can use it with a minimum of compatibility issues.
The BPEL language enables you to define how to:
1. Send XML messages to, and asynchronously receive XML messages from, remote services
2. Manipulate XML data structures
3. Manage events and exceptions
4. Design parallel flows of process execution
5. Undo portions of processes when exceptions occur
Advantages:
1. Provide industry standard language for expressing business process.
2. Abstracts business logic and responsibility.
3. It is a state-full connection.
What is choreography? How does it differ from orchestration?
Orchestration == Executable Process
Web Service Orchestration relates to the execution of specific business processes. WS-BPEL is a language for defining processes that can be executed on an orchestration engine.
Choreography == Multi-party Collaboration
Orchestration
In this case we have a central controller process which controls and co-ordinates all the Web Services involved in the application. How the participating Web Services will be called, what will be the control flow, what all transformation will take place ... these all things are known only to the central controller process.
Choreography
Here we don't have any central controller process and hence all the participating Web Services know when to call, whom to interact, when to execute operations, etc.
Orchestration has a central controller process and all other participating Web Services don't know about the actual business process. They are called only by the controller process and they don't know anything about other Web Services involved in the application.
Whereas Choreography doesn't have any controller process/service and all the participating Web Services know the actual business process and they are well aware of which all Web Services they need to interact with, when to execute the operations, etc.
Fault handling is easier in Orchestration as the execution is controlled which is not the case with Choreography. Web Services can be easily and transparently replaced in case of Orchestration as the involved Web Services don't know the actual business process whereas it'll be difficult in case of Choreography.
Thus, we see that Orchestration is having quite a few advantages over Choreography and hence Orchestration is normally preferred for business process implementations, but Choreography may certainly have its own usage in some selected scenarios.
What are the different message exchange patterns in BPEL?
The port type name attribute provides a unique name among all port types defined within in the enclosing WSDL document. WSDL has four transmission primitives that an endpoint can support:
One-way
|
The operation can receive a message but will not return a response
|
Request-response
|
The operation can receive a request and will return a response
|
Solicit-response
|
The operation can send a request and will wait for a response
|
Notification
|
The operation can send a message but will not wait for a response
|
The most important message exchange patterns are one-way, request/response, and request/callback (asynchronous request/response).
What is the difference between Sync and Async activity on wsdl level and BPEL Process as well?
The synchronous process defines one two way operation port to receive the request and send the response.
On the BPEL process side, the Synchronous BPEL process gets instantiated on receiving the client request and sends back the reply using the reply activity on the same port on which the Client is waiting.
Synchronous process using only one port for request and reply operation.
Asynchronous BPEL process is having two Port Types and each of them supports single operation. That means the asynchronous BPEL process receives the request on one of the ports and sends back the reply from another port (callback port). To send the response the asynchronous BPEL process invokes the client on the callback port using the callback activity.
No comments:
Post a Comment