OSOA Home

This paper discusses the relationship of Service Component Architecture (SCA) and the Business Process Execution Language (BPEL).

SCA and BPEL - Rivals or Friends?

Sometimes, when talking about composite service-based applications, people get confused about the roles of SCA and of BPEL and consider that these two technologies are in conflict or that they are trying to perform the same roles.  This isn't the case - far from being rivals, SCA and BPEL are firm friends and are complementary parts of a business solution, each with its own role to play.

However, the similarities between SCA and BPEL show why there is the possibility for confusion.  First, both BPEL and SCA are described in terms of a formal language that is based on XML.  Secondly, both languages may be used to describe a business service that is implemented by composing together other business services and both can describe inbound and outbound service interactions types by WSDL port types.  There the similarities end.  The important difference between SCA and BPEL is that SCA is all about describing the structure of the application while BPEL describes business logic involving the sequencing of operations in a business process.

Putting this in another way, SCA is concerned with what components exist in the business application, what services those components offer, what service references those components depend on, how the components are connected together, what endpoint addresses and communication methods are used for the connections, what policies are applied to components and to the connections between them. BPEL is concerned with business logic and the sequences of operations which are performed to execute an individual business process. BPEL processes provide and consume other services through partnerLinks, but these are abstract interfaces that must be connected to actual endpoints and communication methods through configuration.

So, SCA describes the structure of a business solution in terms of business components and their connections, but the sequence in which particular services are invoked is determined by the business logic of the implementation used for each component. It is a good combination when the components are implemented as BPEL processes within an overall SCA assembly, since then it is possible to get a combined view of structure and sequence.  Of course, SCA does not force this as a requirement and components may be implemented in any supported programming language, such as Java or C++.  In this case, sequence decisions are made in the implementation language of the component and it may be harder to work out the sequences involved.

So, BPEL and SCA are the firmest of friends and work well together when building business solutions as sets of services. The following sections provide some details and some examples as to how this works in practice.

BPEL and Business Processes

BPEL can be used to build executable descriptions of business processes.  It does this in an XML language that describes the external interactions of a process in terms of one or more partnerLinks, where each describes interfaces that the process has with other entities.  One partnerLink typically represents the service that the process offers to its clients.  Other partnerLinks usually represent other services which the process depends on to get its tasks done.  Some partnerLinks can represent both a service offered by the process and a service required by the process - both directions of a conversation with another entity.

The following is a highly simplified BPEL process for orderProcessing - the service that many a company might offer to its customers to place orders with the business and get them dispatched.

<process name="purchaseOrderProcess"
   targetNamespace="http://example.com/bpel/OrderProcessing"
   xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
   xmlns:lns="http://example.com/wsdl/purchase">

   <documentation xml:lang="EN">
      Example of a WS-BPEL process for handling a purchase order.
   </documentation>

   <partnerLinks>
      <partnerLink name="orderProcessing"
         partnerLinkType="lns:orderProcessingLT" myRole="orderProcessingService" />
      <partnerLink name="payment" partnerLinkType="lns:paymentLT"
         myRole="paymentRequester" partnerRole="paymentService" />
      <partnerLink name="warehouse" partnerLinkType="lns:warehouseLT"
         myRole="warehouseRequester" partnerRole="warehouseService" />
      <partnerLink name="eventLog" partnerLinkType="lns:eventLogLT"
         partnerRole="eventLogService" />
   </partnerLinks>

   <variables>
      <variable name="PO" messageType="lns:POMessage" />
      <variable name="Invoice" messageType="lns:InvMessage" />
      <variable name="shippingInfo" messageType="lns:shippingInfoMessage" />
      <variable name="availability" messageType="lns:availabilityInfo" />
   </variables>

   <sequence>
      <receive partnerLink="orderProcessing" portType="lns:orderProcessingPT"
         operation="placeOrder" variable="PO" createInstance="yes">
         <documentation>Receive Purchase Order</documentation>
      </receive>

      <flow>
         <documentation>
            A flow to handle order processing including accounts, shipping
         </documentation>
         <links>
            <link name="ship-to-invoice" />
         </links>
         <sequence>
            <assign>
               <copy>
                  <from>$PO.customerInfo</from>
                  <to>$shippingRequest.customerInfo</to>
               </copy>
            </assign>
            <invoke partnerLink="warehouse" portType="lns:warehousePT"
               operation="checkInventory"
               inputVariable="PO" outputVariable="availability">
               <documentation>Check inventory</documentation>
               <sources>
                  <source linkName="ship-to-invoice" />
               </sources>
            </invoke>
         </sequence>
         <sequence>
            <invoke partnerLink="payment" portType="lns:paymentPT"
               operation="orderPayment" inputVariable="PO">
               <documentation>Complete payment</documentation>
               <targets>
                  <target linkName="ship-to-invoice" />
               </targets>
            </invoke>
            <invoke partnerLink="warehouse" portType="lns:warehousePT"
               operation="shipOrder"
               inputVariable="PO" outputVariable="shippingInfo">
               <documentation>Dispatch Order</documentation>
            </invoke>
            <receive partnerLink="payment" portType="lns:paymentCallbackPT"
               operation="sendInvoice" variable="Invoice" />
         </sequence>
      </flow>
      <reply partnerLink="orderProcessing" portType="lns:orderProcessingPT"
         operation="placeOrder" variable="Invoice">
         <documentation>Invoice Processing</documentation>
      </reply>
   </sequence>

</process>

The BPEL script starts with a description of the partnerLinks for the process - with the first being the service offered by the process to clients.  There are some variable declarations and then a <sequence.../> holding a particular sequence of operations for a particular process - in this case, it is for the operation "placeOrder" on the orderProcessing partnerLink.  Operations are described in terms of invocations of operations on various partnerLinks (principally the payment and warehouse partnerLinks in this example), including responses received from those links.  The sequence here ends with a <reply.../> which sends a message back to the client, in this case with an invoice for he order.

Not shown in this example for reasons of space are the partnerLinkType definitions for the partnerLinks, typically done as WSDL file(s) defining portTypes with additional BPEL elements added defining partnerLink roles.

One thing that is not present here is any definition of how and where each of the services exists or how they are invoked - this concrete information must be supplied outside the BPEL script, as part of its deployment. 

SCA and the Structure of Composite Applications

SCA is useful for describing the structure of composite service applications.  To get a better sense of what this means, an example application is shown in the following diagram:

Figure 1: Example Order Processing composite application

In this example, the Order Processing service is offered for use by customers, most likely as a Web service available over a general protocol such as SOAP over HTTP.  This may have a set of operations such as "createOrder", "checkAvailability", "getOrderStatus" and so on.

The Order Processing service is implemented by the OrderProcessing Component.  In turn, the OrderProcessing component makes use of services provided by other components, represented by the EventLog component, the AccountsComposite and the WarehouseComposite.  The names of those components already indicate how they are implemented - EventLog is a simple implementation, for example a Java class, while AccountsComposite and WarehouseComposite are each a composite set of components which work together to provide the services used by the OrderProcessing component.

The OrderProcessing component does not need to know the structure of the AccountsComposite or the WarehouseComposite - but the assemblers and developers responsible for those parts of the solution certainly do!

So, SCA shows what components make up a particular business solution and it shows how they are connected together. SCA provides more information than this, if it is needed.  For example, SCA knows what binding is used for each connection.  The OrderProcessing component may, for example, connect to the PaymentService using an EJB binding, if the AccountsComposite is implemented as a Java EE application using EJBs.  Meanwhile the OrderProcessing component might connect to the WarehouseService using a JMS binding using an underlying messaging infrastructure.  SCA may also apply particular policies to these connections.  For example, accounts information may be regarded as sensitive and so require that all operations on the PaymentService are encrypted.  The same operations may also require authentication to ensure that only trusted users are invoking the operations.  Meanwhile some of the operations on the WarehouseService, such as those involved in dispatching orders to the customer, must be performed transactionally and reliably, so that the OrderProcessing component can be assured that the order is dispatched once and once only.

What SCA does not do is in any way show the sequences of operations associated with the OrderProcessing service. So, the checking of the customer's account status, the checking of the inventory status of the order items, the calculation of the price of the order items, the billing of the customer, the request to dispatch the goods to the customer - all these operations (and more!) may be required to complete a "createOrder" operation, but their sequence is entirely determined by the code used as the implementation of the OrderProcessing component.

Using SCA and BPEL together in an Application

SCA shows the structure of a composite services application.  BPEL processes determine the flow sequences for individual operations.  It is clear from this that SCA and BPEL are complementary and can fit together very well in business solutions.

BPEL can be used in two different ways in SCA; the composite level and component level.  A composite contains one or more components. 

At the composite level, BPEL can be used to provide the sequence and logical interaction between components in a composite like the one shown in Figure 1.  BPEL is well suited to this job, but it is not the only possibility. Orchestration of components within composites can be done with other languages such as BPMN, or with programming languages such as Java.  At the component level, BPEL can be used to define the inner workings of an implementation for a component that resides inside of a composite.  This is also similar to the way that programming languages such as Java and C++ are used. 

BPEL is incorporated into SCA as the implementation of a component, similar to components written in Java or C++.  A BPEL process is included into an SCA composite using the syntax implementation.bpel. 

To return to the OrderProcessing service described in the previous section, it is clear that a BPEL process implementation of the OrderProcessing component is likely to work very well, using a BPEL script shown previously (or rather and expanded version of that example). The OrderProcessing component is implementing operations by the controlled execution of sequences of operations provided by other components in the overall solution.  BPEL is great at doing this.  Meanwhile, SCA shows the relationships of the elements making up the solution - and it provides the endpoint definitions and communication protocols as configuration information for each of the partnerLinks that the BPEL process uses.

The following snippet of SCA XML shows what the BPEL process would look like if used to implement the OrderProcessing component of the composite application shown in the diagram above:

<?xml version="1.0" encoding="UTF-8"?>
<!-- CompositeComponent example -->
<composite  xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://www.osoa.org/xmlns/sca/1.0"
    targetNamespace="http://example.com/"
    xmlns:exm="http://example.com/bpel/OrderProcessing"
    name="CustomerOrdersComposite">

	...
    <component name="OrderProcessing">
        <implementation.bpel process="exm:purchaseOrderProcess">
		<service name="OrderProcessing"/>
		     <interface.wsdl interface="http://example.com/customer#
			    wsdl.interface(OrderProcessing)"/>
		</service>
        <reference name="Payment" target="AccountsComponent"/>
	<reference name="Warehouse" target="WarehouseComponent"/>
        <reference name="EventLog" target="EventLogComponent"/>
    </component>
    ...

</composite>

In this case, the OrderProcessing component has an implementation which is a BPEL process with the name purchaseOrderProcess.

A happy friendship, with clearly defined roles.

References 

Service Component Architecture specification

SCA BPEL Client and Implementation specification

BPEL OASIS committee specification Version 2.0