Friday, May 14, 2010

Difference between Sync and Async BPEL process

As the name suggests a Synchronous and Asynchronous BPEL(Business Process Execution Language) process can be defined based on their operational behavior.

If Triggering point of a BPEL process waits until a response returns from the same, then it can be recognized as Synchronous in behavior and if it continues with next set of operation then the process is asynchronous.

Now we can trill down bit for its architectural differences. Each and every BPEL process irrespective of Sync or Async can be exposed as an external Web Service which can be defined by Web Service Description Language (WSDL).

Two Port Type:

Asynchronous BPEL process is having two Port Types and each of them supports single operation. According to the figure SampleAsyncBpel process WSDL is having onePortType named "SampleAsyncBpel" which supports operation "process". Operation Process is having one input message named "SampleAsyncBpelRequestMessage".
Another PortType is "SampleAsyncBpelCallback" supports operation processResponse which is having input message named "SampleAsyncBpelResponseMessage".

Two Partner Link Role:

SampleAsyncBpel partnerLinkType binds the provider and requester roles into an asynchronous conversation. Each role corresponds to a single port type.
Provider role uses "SampleAsyncBpel" port type where as Requester role uses "SampleAsyncBpelCallback" port type.

Now how these matter in BPEL Process:

Partner Link in BPEL process accepts both provider and requester role.The name is given in BPEL itself but the type is referring from WSDL file. Provider role from WSDL is mapped to myRole attribute and requester role from WSDL is mapped to partnerRole attribute.

<partnerLivk name="sampleasyncbpel_client" partnerLinkType="client:SampleAsyncBpel" myRole="SampleAsyncBpelProvider" partnerRole="SampleAsyncBpelRequester"/>

Receive activity is gateway for every BPEL process and uses portType corresponds to provider role.

<receive name=receive_input partnerLink="sampleAsyncBpel_client" portType="client:sampleAsyncBpel" [uses provider role in wsdl] operation="process" variable="inoutVariable" createInstance="yes"/>

callback activity only occurs in asynchronous BPEL process

<invoke name="callbackClient"
partnerLink="sampleasyncbpel_client"
portType="client:SampleAsyncBpelCallback"
operation="processResponse"

inputVariable="outputVariable"/>

How it differs from a Synchronous BPEL process

Single PortType and partnerLinkType instead of two.In asynchronous BPEL process two portTypes are defined and each portType corresponds to a single operation but in synchronous BPEL process we can see Single portType is defined with single operation.

According to above picture SampleSyncBpel supports single operation named "Process" and it is having one request message and one response message.

<wsdl:portType
name="SampleSyncBpel">

<wsdl:operation name="process">
<wsdl:input message="client:SampleSyncBpelRequestMessage" />
<wsdl:output message="client:SampleSyncBpelResponseMessage"/>
</wsdl:operation>
</wsdl:portType>

Synchronous BPEL process WSDL is having single partnerLinkType instead of two. And it supports only Provider role [no requester role as Asynchronous] which uses portType defined above.

<partnerLink
name="samplesyncbpel_client"
partnerLinkType="client:SampleSyncBpel"
myRole="SampleSyncBpelProvider"/>


synchronous BPEL process has one reply activity instead of callback.

<reply name="replyOutput"
partnerLink="samplesyncbpel_client"
portType="client:SampleSyncBpel"
operation="process"
variable="outputVariable"/>

Thursday, May 13, 2010

AIA Implementation Steps

Abbreviation:
AIA - Application Integration Architecture
EBO - Enterprise Business Objects
EBM - Enterprise Business Messages
ABM - Application Business Messages
EBS - Enterprise business Service
ABCS - Application Business Contract Service
EBF - Enterprise Business Flow
WSDL - Web Service Definition Language
BPEL - Business Process Execution Language

An actual implementation of Oracle Application Integration Architecture requires
• Defining integration scenarios
• creation of functional design document,
• creation of technical design documents
• Developing AIA integration Scenario
• Testing AIA integration scenario


1. Defining Integration Scenario:


  • This includes identification of various collaboration artifacts between several applications. This artifacts includes.
    Enterprise Business Objects (EBO): canonical cross functional application independent business entity . Mainly XML schema definitions (XSD)
    Enterprise Business Services (EBS): Centerpiece of AIA,light weight business service which implements operations that an EBO should have.
    Application Business Connector Service (ABCS): connecting service for participating applications which is called by or calls EBS
    Enterprisie Business Messages (EBM): Input and output messages for EBS
    Enterprise Business Flows (EBF): Orchestration of multiple EBS in case Integration scenario is not bound to ABCS-EBS-ABCS paradigm.


2. creation of functional design document:


  • Functional design document produces Exact EBO's needs to be used from foundation pack and Enterprise Business Messages (EBM) from Foundation Pack and if required we need to create or extend them.
    Apart from these FDD should capture detail about participating Application and their business trigerring events and functional flows.This is generic for all FDD.


3. creation of technical design document


  • Technical design document produces actual flow logic, error handling framework, Domain value Map creation, Mappings between ABM to EBM and vice versa.TDD captures detailed analysis of ABMs and their mappings to EBMs as well as Identified EBS,ABCS and EBF from AIA foundation framework.
    Technical design document also produce Security model and Deployment strategy


4. Developing AIA Integration Scenario

  • Developing EBS is first thing to be taken care of.EBS are selected as per TDD and Developer should define contract first for selected EBS which includes identification of all operations supported by that and Identification of each and every operation in EBS which use specific EBM as input and output.From a developers point of view it is important to understand which type of business service is going to fit in. There are two types of EBS . One is Entity based service and other is process based service. Entity based service is used to implement operations that an EBO can do where as Process based Service uses a customize WSDL which is used to capture all operation that an EBF is supposed to do.
  • Developing ABCS(Application Business Contract Service):
    ABCS contract is nothing but the WSDL that is used by that ABCS and defining that contract is to understand participating systems and their Integration touch pints as well as their integration capabilities.

  • Developing EBF:
    To define the contract for an EBF we need to Identify whether EBF is required or not.An EBF is needed when an enterprise business service (EBS) operation needs to be implemented with a set of tasks and involves invoking of multiple services. To create the contract for an enterprise business flow we need to Identify the EBM and Construct the WSDL for the EBF.
    An EBF can invoke only another EBS. In no situation should an EBF invoke an application business connector (ABC) service directly. and design pattern for the EBF and
    One interesting fact is that from development point of view ther is no difference between an ABCS and an EBF because both of them are BPEL process and requires a complex WSDL to be constructed as their contract but ABCS deals with ABM while EBF deals with EBM.