This paper focuses on middleware concerns in BPEL workflows. When looking at those workflows from the implementation perspective, we observe that they have several BPEL-specific middleware requirements, which are not supported by current WS-* specifications and by most BPEL engines available to date. This demo paper will show the AO4BPEL Engine, which implements a container framework that allows the specification and enforcement of middleware requirements in BPEL processes. A deployment descriptor is used to specify the quality of service requirements of BPEL activities. A light-weight and aspectbased process container is used to enforce those requirements by calling dedicated middleware Web Services. We implemented those middleware Web Services by extending open source implementations of WS-* specifications for security, reliable messaging, and transactions.
In BPEL [11], a composite Web Service is implemented by means of a workflow process, which consists of a set of interactions between the composition and the partner Web Services along with the flow of control and data around those interactions. Whilst the functional side of the composition is specified by the BPEL process, it is unclear how to handle non-functional middleware concerns such as security, reliable messaging, and transactions.
The BPEL specification does not address middleware issues and leaves that
for good reasons to BPEL implementations, which should support these
“deployment issues” somehow. We observe however, that current BPEL engines do
no provide appropriate middleware support for BPEL processes. In addition, it
is widely assumed that WS-* specifications such as WS-Security [18] and
WSReliableMessaging [
In [
We distinguish simple requirements, which correspond to BPEL messaging activities and could be supported somehow by using existing WS-* specifications and complex requirements, which are specific to BPEL. We will elaborate on reliable messaging, security, and transactions. 2.1
A simple requirement of BPEL messaging activities is the reliable delivery of
their respective SOAP messages with guaranteed delivery assurances (e.g.,
without message loss and/or duplication). Consider for instance two messaging
activities such as reply or one-way invoke that target different partners and are
nested in a sequence. The corresponding messages should be delivered in the
order, in which the activities appear in the sequence, i.e, the SOAP message of
the first activity should be received by the respective partner before the SOAP
message of the second activity. Current reliable messaging specifications [
Messaging activities have simple requirements such as integrity, confidentiality, and authentication, which are supported by WS-Security [18]. Complex requirements arise when we consider issues such as secure conversations, trust, and federation in the context of BPEL processes. For example, we assume that we have a sequence, which contains many messaging activities targeting the same partner. From a performance point of view, it is inefficient to secure each messaging activity individually as in WS-Security. Instead, using a security context (according to WS-SecureConversation [14]) for all interactions with that partner would improve the performance significantly. 2.3
Composite BPEL activities might require transaction semantics e.g., in a sequence with two invoke activities it might be necessary that either both invocations succeed or both must be undone. It is also essential that the process and the partners decide together the outcome of the transaction, which is called external coordination [19]. This feature is not supported in BPEL. Moreover, a way is needed to flexibly configure the transactional requirements of activities according to the application semantics e.g., a sequence might need to be executed as an atomic transaction or as a compensation-based transaction. WS-* transaction specifications [12, 13] can support the transactional requirements of BPEL activities if the BPEL engine is integrated properly with the Web Service transaction middleware. 2.4
The problem of middleware requirements in BPEL is two-fold. On the one hand, appropriate means are needed to specify the requirements of BPEL activities. On the other hand, appropriate infrastructure is necessary to enforce those requirements during process execution. Even for simple requirements, most current BPEL engine do not provide a way to say “this invoke or that reply must be secure”. Moreover, the integration of BPEL engines with existing WS-* middleware is still problematic. 3
Our framework has three main components: a deployment descriptor, a process
container, and a set of middleware Web Services [
Fig. 1. Deployment Descriptor GUI Tool 3.1
An XML-based deployment descriptor specifies declaratively the middleware requirements of the BPEL activities and the parameters that are needed to accomplish those requirements. Listing 1. shows an excerpt of a deployment descriptor for a bank transfer process, which calls the operations credit and debit on two partner Web Services.
The deployment descriptor defines one or more activity selectors, which are XPath expressions to identify the activities that will be associated with some requirement. The attribute selectorid attribute of the requirement element is used for this association. The service elements group requirements that belong to a specific middleware service.
The deployment descriptor is the only component of the framework that the BPEL programmer needs to know about. He/she could write it manually or use the GUI tool shown in Fig. 1 to generate it.
One major advantage of the deployment descriptor against policies [16] is that the deployment descriptor allows the specification of the necessary parameters to enforce a given requirement. With policies, which are too declarative, this is not possible. For instance, in a policy is not possible to specify the user name and password that should be used to support authentication.
At process deployment time, the deployment descriptor file has to be specified in addition to the BPEL file as shown in Figure 2. 3.2
The process container is an implementation concept that BPEL programmers do not need to know about. It intercepts the execution of BPEL activities at well-defined points and calls dedicated middleware Web Services that provide the necessary functionality to enforce the middleware requirements.
We implemented a light-weight and aspect-based process container using a set
of AO4BPEL aspects [
AO4BPEL [
After deploying the BPEL process (cf. Fig. 1), container aspects are automatically generated and deployed. We can see these aspects by switching to the process-list view of the AO4BPEL engine shown in Fig. 3.
Listing 2 shows the second aspect in the aspects list of Fig. 3. This aspect declares the reliable messaging service (RM) as partner and two variables for the input and output parameters of the call to sendWithExactlyOnceSemantics.
The pointcut of this aspect intercepts the invoke activity that calls the operation credit at the point where the SOAP request message has been created (this is the semantics of the advice type around soapmessageout ). The advice contains an assign activity, which sets the input parameters of the call to the operation sendWithExactlyOnceSemantics of the RM Service. The SOAP message corresponding to the current join point (i.e., the invoke activity that calls the operation credit ) is accessed by means of the special AO4BPEL context collection variable soapmessage. The second assign activity is used to pass the response message for the current join point activity from the RM Service to the BPEL process by using the special AO4BPEL context collection variable newsoapmessage. This is necessary because the request message for calling the operation credit was sent by the RM service on behalf of the BPEL process. The middleware Web Services are not part of the AO4BPEL engine. They are based on open source implementations of WS-* specifications.
The reliable messaging service [10] provides operations that are called by the
container to enforce a delivery assurance for messaging activities (e.g.,
exactlyonce) and to support the in-order delivery of messages even between more than
two endpoints. Our implementation of this service is based on Apache Sandesha
[
The security service [8] provides two port types: one for secure messaging
according to WS-Security and one for secure conversations according to
WSSecureConversation with operations such as createContext, encryptWithContext,
etc. The implementation of this service is based on Apache WSS4J [
The transaction service provides operations that are called by the container to
enforce atomic transactions [12] such as begin(transid), participate(transid, soap),
and commit(transid). The implementation of this service is based on Apache
Kandula [
In this demo, we will use a travel agency scenario with several BPEL processes that compose the Web Services of airline companies and hotel chains. We will deploy these processes on the AO4BPEL engine and specify a deployment descriptor file that defines the middleware requirements of the process activities.
Once the process is deployed, the audience will see how AO4BPEL container aspects will be generated automatically and activated. Then, we will start some instances of the deployed processes and use a tool to monitor the SOAP messages that are exchanged between the processes and their partners. Thus, we verify that the middleware Web Services are called correctly by the process container and the requirements of the different activities are fulfilled. 5
In this paper, we presented a user-friendly implementation of a container framework for the specification and enforcement of the middleware requirements of BPEL processes. The framework was inspired from enterprise component models and it can be reused with other BPEL engines. The engine has to provide a process container that is able to intercept the execution of BPEL activities and call the middleware Web Services. The deployment descriptor and the middleware Web Services could be reused without any changes.
The AO4BPEL engine presented here provides support for many BPELspecific middleware requirements and paves the way toward a new breed of BPEL engines that we devise application servers for BPEL. 8. Anis Charfi and Mira Mezini. Using Aspects for Security Engineering of Web Service Compositions. In Proceedings of the IEEE International Conference on Web Services (ICWS), Volume I, pages 59–66. IEEE Computer Society, July 2005. 9. Anis Charfi and Mira Mezini. AO4BPEL: An Aspect-Oriented Extension to BPEL.
World Wide Web Journal: Recent Advances on Web Services (special issue), to appear, 2006. 10. Anis Charfi, Benjamin Schmeling, and Mira Mezini. Reliable messaging in bpel processes. In Proceedings of the 3rd IEEE International Conference on Web Services (ICWS), to appear, September 2006. 11. F. Curbera, Y. Goland, J. Klein, et al. Business Process Execution Language for
Web Services (BPEL4WS) Version 1.1, May 2003. 12. D. Langworthy (Eds.). Web Services Atomic Transaction (WS
AtomicTransaction), November 2004. 13. D. Langworthy (Eds.). Web Services Business Activity (WS-BusinessActivity),
November 2004. 14. M. Gudgin and A. Nadalin (Eds.). Web Service Secure Conversation Language (WS-SecureConversation) Version 1.0, February 2005. 15. IBM. The BPEL4WS Java Run Time, August 2002. 16. J. Schlimmer (Eds.). Web Services Policy Framework (WS-Policy)., September 2004. 17. OASIS. Web Services Reliable Messaging TC WS-Reliability 1.1, 15 November 2004. 18. OASIS. Web Services Security: SOAP Message Security Version 1.0, March 2004. 19. Stefan Tai, Rania Khalaf, and Thomas Mikalsen. Composition of coordinated web services. In Proceeding of ACM/IFIP/USENIX International Middleware Conference (Middleware), volume 3231 of LNCS, pages 294–310. Springer, October 2004.