BPEL in SCA assembly model
(For basics about SCA visit:
http://khanderaotech.blogspot.com/2007/02/basics-of-service-component.html)
SCA and BPEL are complementary technologies. Though both have a mechanism to capture relationship between services, both do it differently. Moreover, BPEL is an execution language while SCA captures only the dependencies.
BPEL process can be an implementation type of service(s) within SCA. One may define service using BPEL and deploy the composite.
BPEL capture relationship between a process and an interactive web service as a partnerlink with different roles tied to port types. SCA maps the partnerlink with a single role (port type) to a reference. Thus, mapping between SCA and BPEL is straightforward.
Let us assemble a composite containing a BPEL process. I am using a stripped down version of a PurchaseOrderProcess given in proposed WS-BPEL 2.0 specifications. This process invokes two other services one to compute price and another to ship the product. These relationships are captured in three partnerlinks.
In case of WS-BPEL, a partnerLink defines two roles, one for the WS-BPEL process and one for the partner. In SCA, Depending upon a message flow direction, one of them becomes a reference and another becomes a service.
In our example, the BPEL process’s interface is exposed as a service entry point of the composite while other partner links are mapped as references.
Invoice (computePrice) service and Shipping service can be local or external to the composite. I am making both of them as external webservices. Thus, our composite looks like:
You may notice, wires between component and references. The BPEL process does not know what kind of implementation those references and what kind of binding it has. This loose coupling and flexibility is a power of SCA architecture.
Finally, here is the SCA composite representation for this assembly.
Disclaimer: The specs are still being evolved and may change. The representation is simplified for explanation hence it is not complete.
References:
1. WS-BPEL 2.0 : http://docs.oasis-open.org/wsbpel/
2. SCA whitepaper: http://www.osoa.org/display/Main/SCA+BPEL+White+Paper
3. SCA - BPEL specs: http://www.osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforBPEL_v0.95.pdf?version=2
posted by Khanderao at
11:11 PM
3 Comments:
Hi i wanted to understand one thing here.
now in BPEL when defining the partner link we specify the endpoint WSDL for the service (say webservice) now in SCA though we are creating composites and the WS_BPEL implementation inside it say, how do we connect the partner link with the reference points are the references defined somewhere to the endpoint service. my understanding is that the references are directly coupled with the service or composite components callouts and when defining the partnerlink inside the SCA composite the end points get defined for the partnerlink automatically when we reference itwith the reference address. if my assumption is right then why are we doing this is to have dynamic referencing at runtime. correct me if i am wrong.
By
Unknown, at 10:38 AM
Anirudh,
When BPEL process uses the partnerlinks within a sca composite, it would be using the reference/service as defined in SCA composite. In the composite, the reference wired to another component or an external service.
SCA does not dictate runtime behavior. During a deployment, one may rewire the partnerlinks reference durectly to the concrete ones(bypassing a wire), but doing this, we would loose a benefit of redirection.
Hence, alternatively, assume that BPEL would invoke a SCA runtime which would be a light weight router based on wiring defined in the composite.
By
Khanderao, at 6:26 PM
Thanks for the article Khanderao.
One little question - would it be right to say that what can be done through composites can also be done in BPEL? From your post, I do understand that BPEL and SCA approach the problem in different ways.
However, it appears that while composites can only specify the wiring structure, BPEL is more of a superset which can do both wiring + business logic. Is that true?
(A similar question I asked on an SOA forum received the following reply "SCA is more relevant due to details, standards and specifications"; however, it wasn't quite clear why composites are required when the same job can be done through BPEL)
By
AJ, at 12:23 PM
Post a Comment
<< Home