BPEL

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.

Synchronous BPEL process has one reply activity instead of callback. Synchronous BPEL process WSDL is having single partnerLinkType instead of two.

WSDL

·         WSDL stands for Web Services Description Language

·         WSDL is an XML based protocol for information exchange in decentralized and distributed environments.

·         WSDL is the standard format for describing a web service.

·         WSDL definition describes how to access a web service and what operations it will perform.

·         WSDL is a language for describing how to interface with XML-based services.

·         WSDL is a language for describing how to interface with XML-based services.

Sample WSDL:

<?xml version="1.0" encoding="UTF-8"?>

<description xmlns="http://www.w3.org/ns/wsdl"

             xmlns:tns="http://www.tmsws.com/wsdl20sample"

             xmlns:whttp="http://schemas.xmlsoap.org/wsdl/http/"

             xmlns:wsoap="http://schemas.xmlsoap.org/wsdl/soap/"

             targetNamespace="http://www.tmsws.com/wsdl20sample">

<!-- Abstract type -->

   <types>

      <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

                xmlns="http://www.tmsws.com/wsdl20sample"

                targetNamespace="http://www.example.com/wsdl20sample">

         <xs:import namespace=http://www.example.org schemaLocation=”abc.xsd”/>

      </xs:schema>

   </types>

<!-- Abstract interfaces -->

   <interface name="Interface1">

      <fault name="Error1" element="tns:response"/>

      <operation name="Opp1" pattern="http://www.w3.org/ns/wsdl/in-out">

         <input messageLabel="In" element="tns:request"/>

         <output messageLabel="Out" element="tns:response"/>

      </operation>

   </interface>

<!-- Concrete Binding Over HTTP -->

   <binding name="HttpBinding" interface="tns:Interface1"

            type="http://www.w3.org/ns/wsdl/http">

      <operation ref="tns:Get" whttp:method="GET"/>

   </binding>

<!-- Concrete Binding with SOAP-->

   <binding name="SoapBinding" interface="tns:Interface1"

            type="http://www.w3.org/ns/wsdl/soap"

            wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"

            wsoap:mepDefault="http://www.w3.org/2003/05/soap/mep/request-response">

      <operation ref="tns:Ge99t" />

   </binding>

<!-- Web Service offering endpoints for both bindings-->

   <service name="Service1" interface="tns:Interface1">

      <endpoint name="HttpEndpoint"

                binding="tns:HttpBinding"

                address="http://www.example.com/rest/"/>

      <endpoint name="SoapEndpoint"

                binding="tns:SoapBinding"

                address="http://www.example.com/soap/"/>

   </service>

</description>

WSDL Types Element

A Web service needs to define its inputs and outputs and how they are mapped into and out of services. WSDL <types> elements take care of defining the data types that are used by the web service. Types are XML documents, or document parts.

  <types>

    <schema targetNamespace="http://example.com/stockquote.xsd"

            xmlns="http://www.w3.org/2000/10/XMLSchema">

      <element name="TradePriceRequest">

        <complexType>

          <all>

            <element name="tickerSymbol" type="string"/>

          </all>

        </complexType>

      </element>

      <element name="TradePrice">

         <complexType>

           <all>

             <element name="price" type="float"/>

           </all>

         </complexType>

      </element>

    </schema>

  </types>

WSDL Message Element

·         The <message> element describes the data being exchanged between the Web service providers and consumers.

·         Each Web Service has two messages: input and output.

·         The input describes the parameters for the Web Service and the output describes the return data from the Web Service.

·         Each message contains zero or more <part> parameters, one for each parameter of the Web Service's function.

·         Each <part> parameter associates with a concrete type defined in the <types>container element.

   <message name="SayHelloRequest">

      <part name="firstName" type="xsd:string"/>

   </message>

   <message name="SayHelloResponse">

      <part name="greeting" type="xsd:string"/>

   </message>

WSDL portType Element

The <portType> element combines multiple message elements to form a complete oneway or round-trip operation.

For example, a <portType> can combine one request and one response message into a single request/response operation. This is most commonly used in SOAP services. A portType can define multiple operations.

Sync WSDL

<portType name="Hello_PortType">

      <operation name="sayHello">

         <input message="tns:SayHelloRequest"/>

         <output message="tns:SayHelloResponse"/>

      </operation>

   </portType>

Async WSDL

<portType name="Hello_PortType">

      <operation name="sayHello">

         <input message="tns:SayHelloRequest"/>

      </operation>

</portType>

<portType name="Hello_PortType">

      <operation name="sayHello">

         <input message="tns:SayHelloRequest"/>

      </operation>

   </portType>

WSDL Binding Element

·         The <binding> element provides specific details on how a portType operation will actually be transmitted over the wire.

·         The bindings can be made available via multiple transports, including HTTP GET, HTTP POST, or SOAP.

·         The bindings provide concrete information on what protocol is being used to transferportType operations.

·         The bindings provide information where the service is located.

·         For SOAP protocol, the binding is <soap:binding>, and the transport is SOAP messages on top of HTTP protocol.

·         You can specify multiple bindings for a single portType.

·         The binding element has two attributes - the name attribute and the type attribute.

  <wsdl:binding name="PrepaidAccountSOAP" type="tns:PrepaidAccount">

    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>  

 <wsdl:operation name="viewRechBarInfo">

      <soap:operation soapAction="http://www.telenor.mm/PrepaidAccount/viewRechBarInfo"/>

      <wsdl:input>

        <soap:body use="literal"/>

      </wsdl:input>

      <wsdl:output>

        <soap:body use="literal"/>

      </wsdl:output>

    </wsdl:operation>

    <wsdl:operation name="QueryAvailableOffers">

      <soap:operation soapAction="http://www.telenor.mm/PrepaidAccount/QueryAvailableOffers"/>

      <wsdl:input>

        <soap:body use="literal"/>

      </wsdl:input>

      <wsdl:output>

        <soap:body use="literal"/>

      </wsdl:output>

    </wsdl:operation>

  </wsdl:binding>

WSDL Ports Element

A <port> element defines an individual endpoint by specifying a single address for a binding.

·         The port element has two attributes - the name attribute and the binding attribute.

·         The name attribute provides a unique name among all ports defined within in the enclosing WSDL document.

·         The binding attribute refers to the binding using the linking rules defined by WSDL.

·         Binding extensibility elements (1) are used to specify the address information for the port.

·         A port MUST NOT specify more than one address.

·         A port MUST NOT specify any binding information other than address information.

<service name="Hello_Service">

      <documentation>WSDL File for HelloService</documentation>

      <port binding="tns:Hello_Binding" name="Hello_Port">

         <soap:address

            location="http://www.examples.com/SayHello/">

      </port>

   </service>

WSDL Service Element

·         The <service> element defines the ports supported by the Web service. For each of the supported protocols, there is one port element. The service element is a collection of ports.

·         Web service clients can learn from the service element where to access the service, through which port to access the Web service, and how the communication messages are defined.

·         The service element includes a documentation element to provide human-readable documentation.

Different Types of WSDL

1.       Abstract WSDL: Contain Types, Messages, PortTypes

2.       Concrete WSDL: Contain Types, Messages, PortTypes and Bindings, Services

Different Styles of WSDL

1.       Document

2.       RPC

Document vs RPC

1.       In document style, the SOAP (Simple Object Access Protocol) message is sent as a Single Document whereas in the RPC Style, the SOAP body may contain several elements.

2.       The document style is loosely coupled whereas the RPC is tightly coupled.

3.       In the document style, the client sends the service parameters in simple XML format, whereas in the RPC style, the parameters are sent as discrete of values.

4.       The document style losses the operation name in the SOAP message whereas the RPC style keeps the operation name in the SOAP message.

5.       In the document style, messages can always be validated using any XML validator, whereas in the RPC style, the transformed data is difficult to validate by the SOAP message.