Técnicas e instrumentos de recolección de datos

Some activities may require support for more than one non-functional concern. For example, an invoke activity that requires confidentiality and exactly-once semantics could also participate in an atomic transaction. In such a case, a combined usage of the three middleware Web Services is necessary.

When transaction and security are combined, the security Web Service can be called either before (e.g., to send an encrypted message with a plain coordi- nation context header) or after the transaction Web Service (e.g., to encrypt a message that was previously enhanced with a coordination context).

The other two combinations of reliable messaging with transaction or secu- rity are not supported in the current implementation because of problems that arise when Sandesha is used together with WSS4J or Kandula.

In fact, Sandesha and WSS4J cannot work together unless all messages of the WS-RM protocol have security headers, because the message handler of WSS4J discards all messages that do not have a security header. To solve this problem, sequence creation messages and acknowledgment messages should have security headers and not only the application messages. However, the protocol specific messages of WS-RM are not accessible to the process container, which can only intercept application messages.

Moreover, Sandesha and Kandula use WS-Addressing [25] handlers. Kan- dula requires these handlers not only at the Web Service side but also at the client side. When these handlers are added at the client side, Sandesha can no longer send the messages of the WS-RM protocol because this causes an error in the addressing handler. This problem is currently being addressed by the developers of Kandula and Sandesha.

Another limitation of the AO4BPEL container is that aspects can be only applied to application messages, i.e., it is not possible to use a container aspect to send messages of the transaction protocols in a reliable way for example. That is, the combination of transaction protocols with reliable messaging is not supported. The transaction Web Service cannot use the reliable messaging aspects because there is no possibility to define aspects on the middleware Web Services.

7.7

Related Work

This Section first presents some research works that use aspects to modularize middleware services and to implement light-weight containers. Then, it reports on other works that address non-functional concerns in the context of Web Service compositions.

7.7.1

Works on light-weight containers

The process container is inspired by the Spring framework [114], which uses Aspect-Oriented Programming to provide J2EE services such as transaction management to plain old Java objects (so-called POJOs). Spring AOP uses method interception to insert custom behaviour before or after method invo- cations. Together with Java 1.5 annotations, Spring can be used to provide transaction support declaratively as the AO4BPEL process container frame- work does for BPEL processes.

In [73], an approach to the design of component middleware frameworks is presented. This approach, which is called Alice, combines Aspect-Oriented Programming and annotations. In Alice, business logic is implemented in POJO classes and the crosscutting middleware services are implemented using aspects. The Java Aspect Components framework (JAC) [149] also uses aspects to modularize the implementation of middleware services such as persistence and transactions. The programmer works with POJOs and the middleware services of EJB are replaced by loosely coupled dynamically pluggable aspect compo- nents. JBoss AOP [27] is another aspect-based container framework, which provides an aspect library for supporting non-functional concerns such as secu- rity and transaction.

In [154], the container model is generalized to mobile computing environ- ments, where applications join or leave the network spontaneously. Using dy- namic AOP, a spontaneous container allows the nodes of a network to dynami- cally acquire support for non-functional concerns such as transactions, orthog- onal persistence, logging, and access control.

The process container framework is different from the works mentioned above in several regards. First, the process container framework targets BPEL work- flow processes whilst the works mentioned above target Java objects. Second, AO4BPEL container aspects intercept join points across the process layer and the SOAP messaging layer, rather than points in the execution of object-oriented Java programs. Third, the process container framework is tailored to the spe- cific requirements of BPEL workflows and to the Web Service middleware, which operates on SOAP messages according to the WS-* specifications. Fourth, the whole AO4BPEL process container is a set of aspects and there is no kernel as in Alice or JAC. The BPEL engine itself can be seen as the kernel.

7.7.2

Works on non-functional concerns in BPEL

Colombo [58] is a light-weight platform for service-oriented applications, which supports transactional, reliable, and secure Web Service interactions. The messaging-level requirements are expressed indirectly by attaching policies to local copies of the WSDL files of partner Web Services. At deployment time,

the policy component parses the policies that are attached to the different WS- DLs and configures a handler chain for each incoming or outgoing message.

As already said, Colombo supports the messaging-level requirements of BPEL activities. In a joint work with the group of the Colombo project, the author of this thesis extended the Colombo platform with support for process-level re- quirements by attaching external policies to BPEL processes [32]. To enforce such requirements, the BPEL engine of Colombo was modified to notify the policy component about various events in the process execution.

In [174], an approach to transactions in the context of BPEL compositions is presented. This approach uses WS-Policy [113] and WS-PolicyAttachment [45] to specify the transactional requirements of scopes and partner links.

To enforce the transactional requirements of the coordinated scopes and partner links, the BPEL process, which is annotated with transaction policies, is compiled to Java using a special compiler. The complied Java code uses an implementation of WS-AtomicTransaction and WS-BusinessActivity to enforce the transaction requirements of the BPEL scope. Both atomic transactions and business activities are supported.

Whilst the purpose of the process container and the transaction Web Service is also to support transactions in BPEL processes, there are several differences between the AO4BPEL process container framework and the approach proposed in [174] with respect to requirement specification and requirement enforcement. With respect to requirement specification, WS-Policy is too declarative and does not provide means to specify the necessary parameters for enforcing non- functional requirements such as security keys and certificates (what and not how ), unlike the deployment descriptor of the AO4BPEL process container framework.

Moreover, when using the internal policy attachment mechanism of WS- PolicyAttachment as done in [174], one has to annotate each transactional ac- tivity in the BPEL process with an appropriate transactional policy using the WSDL extensibility attribute wsp:PolicyRefs. In contrast, the deployment descriptor uses XPath-based activity selectors, which eliminates the need to at- tach policies to BPEL activities in a point-wise fashion. Another advantage of the deployment descriptor over the internal policy attachment mechanism is the separation between the specification of the non-functional properties and the specification of the functional composition (i.e., the BPEL process).

With respect to requirement enforcement, a special compiler is used in [174] to generate a Java stub that contains the necessary calls to the transaction middleware. As a result, it is not possible to exchange the transaction middle- ware by another one or to integrate further middleware services such as security and reliable messaging without changing the implementation of the compiler. Such extensions are supported easily in the AO4BPEL container framework by writing appropriate aspects.

Moreover, with WS-Policy based approaches such as [174], the logic for en- forcing the transaction requirements is hidden, e.g., a coordination context is implicitly created when a transactional scope starts. Thus, people who want to extend the container cannot do that because they do not understand the inter- action of the BPEL interpreter with the middleware services. They also cannot understand the interactions and dependencies between the different middleware services, e.g., which service is called before another. In the AO4BPEL-based

process container the logic for enforcing the non-functional requirements is avail- able explicitly in container aspects.

In the context of security of BPEL processes, the work described in [29] presents a brokered architecture for security conscious Web Service composition. In that proposal, each Web Service describes its security constraints (using the WSDL extensibility mechanism) and capabilities (using the Security Markup Assertion Language (SAML)). Moreover, a security broker assigns specific Web Services to the activities of a BPEL process by matching the requirements and capabilities of the process with those of the partner Web Services. That work is concerned only with the specification of the security requirements of the process activities, but it is not concerned with the enforcement of those requirements, unlike the AO4BPEL process container framework. Moreover, process-level se- curity requirements such as secure conversations and federations are not ad- dressed in that work.

In [21], Berbner et. al. address other non-functional properties in Web Ser- vice composition such as cost, availability, and throughput. That work assumes that there is a set of alternative Web Services with similar functionality for each activity in the workflow process and that these Web Services have different QoS properties. It presents a heuristic-based approach to solve the QoS-aware Web Service composition problem, i.e., how to select Web Services so that the overall QoS requirements of the workflow process are satisfied.

7.8

Conclusion

This chapter presented a modular and extensible implementation of the process container using AO4BPEL aspects. In that implementation, container aspects are generated automatically from the deployment descriptor using XSLT.

Moreover, three middleware services for BPEL were presented. These ser- vices were implemented as Web Services to allow the AO4BPEL container as- pects to call them. For each middleware Web Service, this chapter presented the interface, the mode of interaction with the process container, and some imple- mentation details. For implementing the middleware Web Services, open-source implementations of WS-* specifications were reused and extended to support the process-level requirements.

Chapter 5 has shown that AO4BPEL aspects improve the modularity of BPEL processes and increase their flexibility. The current chapter has shown that AO4BPEL aspects support the process-level non-functional requirements of BPEL processes, which is an unsolved problem in all current BPEL imple- mentations. The process container framework allows for secure, reliable, and transactional BPEL processes. Thus, this framework enables Web Service based production workflows.

The ultimate message of this chapter to BPEL implementors is: engines that support AO4BPEL aspects provide not only modularity and flexibility but also support for security, reliable messaging, and transactions.

CHAPTER

8

Implementing Business Rules with AO4BPEL

8.1

Introduction

This chapter1 presents a second application of AO4BPEL in the context of business rules in BPEL processes.

Several business domains are inherently policy- and decision-intensive such as the finance and insurance sectors. In these domains, an important part of the business knowledge is available in the form of policies, recommendations, and preferences. Business rules are declarative statements capturing that kind of business knowledge.

When software applications are developed using object-oriented program- ming languages or process-oriented workflow languages such as BPEL, the busi- ness rules are embedded in the application code and they no longer exist ex- plicitly as separate first-class entities. This poses several problems with respect to modularity and flexibility. First, the business rules are intertwined with the process business logic, which leads to complex processes that are hard to un- derstand and to maintain. Second, the business rules cannot be reused across different processes. Reusability is, however, crucial especially for organization- wide business rules. Third, business rules cannot be changed independently of the business process although they are the more volatile part of the composition logic. Consequently, changing business rules involves expert programmers and cannot be done by business analysts.

To solve these problems, this chapter proposes a hybrid composition ap- proach that separates the business rules from the business processes. In this approach, the core business logic is defined in the BPEL process, whereas deci- sions and policies are defined in well-modularized and separated business rules. To implement this hybrid approach, one needs a business rule implementa- tion technology, a workflow engine for executing the processes, and a technology for integrating the business rule implementation technology and the workflow

1_{This chapter is based on the paper Hybrid Web Service Composition: Business Processes} Meet Business Rules, ICSOC 2004 [35].

engine. In this chapter, AO4BPEL aspects are used for implementing the busi- ness rules and the AO4BPEL engine is used as an integration technology for the business rules implementation (i.e., the AO4BPEL aspects) and the business process implementation (i.e, the BPEL process).

To the best of the author’s knowledge, the work presented in this chapter is the first to address the problem of business rules in BPEL processes. One year after presenting this work [35], research proposals such as the work pre- sented in [159] and industrial products such as Oracle BPEL Process Manager [143] adopted similar approaches. The Oracle BPEL Process Manager was in- tegrated with the ILOG rule engine [109] and the process modeling tool ARIS was recently integrated with Corticon’s business rules [107].

The remainder of this chapter is organized as follows. Section 8.2 defines business rules and introduces the Business Rules Approach. Section 8.3 high- lights the problems that arise when business rules are embedded in BPEL pro- cesses. Section 8.4 presents a novel hybrid approach to Web Service composition and its implementation with AO4BPEL. Section 8.5 reports on related work and Section 8.6 concludes this chapter.