http://www.osoa.org/display/Main/Relationship+between+SCA+and+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.

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:

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