by May 4, 2006 0 comments



Business processes are understood by developers as Web
services. To enable us to take advantage of pre-coded Web services, we have the
WSDL (Web Service Definition Language) documents that provide engines such as
BPEL with information about the where and how of using the exposed Web services.
Having understood the concepts of BPEL in our technology story last month (refer
to Interoperable Biz Processes with BPEL, page 46, April 2006, PCQuest) let us
move forward and implement an application where we integrate two Web services
using BPEL. This way, we shall get a better understanding of how BPEL works.

Direct
Hit!
Applies to:
Developers
USP:
Understand how BPEL works by creating a simple loan approval Web service 
Links:
www.oasis-open.org 
Google keywords:
Interoperable Web services

Sample Web services
Our sample Web services are meant to handle loan approval. The loan approval
process includes three tasks: computing the

associated risk level with the loan amount, processing the loan request if
approved and sending the accept/reject reply to the customer. The loan process
starts off with receiving a loan request. The next step includes risk assessment
based on the loan amount. The final step is to send an accept/reject message. As
you can see, each of theses tasks are handled by Web services and our BPEL
process will integrate them into a single business process. One of ou WSDL files
is as follows.

     
targetNamespace=”http://loans.org/wsdl/loan-approval
      xmlns=”http://schemas.xmlsoap.org/wsdl/
      xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap/
      xmlns:xsd=”http://www.w3.org/2001/XMLSchema”    
      mlns:plnk=”http://schemas.xmlsoap.org/ws/2003/05/partner-link/”      
            …





     


Major
constructs

Following are the other
major constructs in a BPEL process definition.

Correlation:
Construct for keeping track of a group of messages that belong together in
one particular business-partner interaction. Correlation matches messages
and interactions with the business process instances they are intended
for. It is represented using ‘‘ tag

Compensation:
Process of reversing or providing an alternative for a successfully
completed activity, especially when a fault occurs. Compensation restores
data to what it was before the activity was done. It is represented using
‘ tag. It can only be used inside fault handlers

Activity: A unit
of work in the entire business process. Activity can be amongst
,  ,
, , , , ,
, , , ,

Until>, , , , , , ,
, Activity>




  
     
     
                  
message=”lns:errorMessage”/>
  





  


     
     
        message=”lns:errorMessage”/>
  









    Loan Approver
Service

         


      location=”http://localhost:8080/active-bpel/services/ApproverWebService”/>


   





BPEL process
Defining the BPEL process starts with defining the ‘partnerLinks’. The
partnerLinks define the role a business partner (or more appropriately a
service) will play in the process. In our case we have three partnerLinks for
the three services that are defined as follows.





partnerLinkType=”lns:loanPartnerLinkType”/>

 



      partnerLinkType=”lns:loanApprovalLinkType “partnerRole=”approver”/>

Here ‘lns’ is the name we have chosen for our
loan-service namespace. Defining the variables for the process follows
partner-link definitions. These variables are messages that are passed between
the ‘partners’ of a business process. Variables allow processes to maintain
state data and process history based on messages exchanged. The variables of our
business process will be:


name=”request”/>








  


The message-type information is taken from the WSDL files
where each of these is defined in the ‘‘ tag. The other major
section of a BPEL process definition is the ‘Fault handlers’ that define the
proceedings in the ‘not-going-right’ case. That is, fault handlers define
activities that must be performed in response to faults that may occur either
during initialization or from the initialization of services. BPEL identifies
faults, both internal and ones resulting from invocation of service by a
qualified name. This is in contrast to WSDL 1.1 where all faults within a common
namespace may not have unique name-a serious limitation as it makes all faults
within a common namespace indistinguishable. However, it is overcome in BPEL due
to unique names. Thus, our sample process will also contain fault handlers as
follows.



     operation=”request” partnerLink=”customer” 
portType=”lns:loanServicePT” variable=”error”/>


The diagram represents our sample loan application process, integrating the activities of request receipt, assessment and approval/rejection

Rest of the process defines normal behavior of the loan

request. This section ideally includes both compensation and correlation
descriptions. However our sample process does not require any such description.
We’ll now define the process flow between activities. This definition contains
a description of all the links between activities, followed by description of
each of the activities executing to complete the business process. The sample
process will, therefore, have the following description.




                                                                 

     



        
             

     
        

        

     


     



        



        


        


     



     



        



        



        


     



     


        



        


        



           



           



        


  
   


 


The link tag describes the links between activities, which

is followed by describing the activities themselves and their

operations. Once all this is done, you have a complete BPEL process definition
that can be deployed onto a BPEL engine. A more comprehensive process would also
have sections for describing event handlers apart from correlations and
compensations. We have omitted that for the sake of simplicity. BPEL gives a
complete definition for a process integrating Web services. You can also define
expressions for evaluating conditions and provide conditional and iterative
constructs. It also overcomes some of the serious limitations in other XML based
specifications as we have seen in the case of fault handlers in our sample
process. Not surprising that it has seen wide acceptance as a standard and is
here to stay.

Anadi Misra

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.

Your data will be safe!Your e-mail address will not be published. Also other data will not be shared with third person.