Noninvasive Adaptations in Web Services
As mentioned earlier, one of the important issues to be solved during adaptation is the insertion/removal of features nondisruptively or noninvasively. In other words, the base service logic should not be aware of any changes. This is also a key issue for maintaining high availability, which is an important quality of a service attribute. Earlier works in this direction have advocated the use of an aspect-oriented paradigm that was essentially used to support many of the cross-cutting concerns. Furthermore, with our experience in working with aspect orientation, we also conciliated with the application of aspect-oriented software development (AOSD) to handle the dynamic changes for Web services.

AOSD addresses the first two of the concerns discussed in the "Essential Considerations for Adaptation" section. It introduces units of modularity called "aspects" that contain code fragments called "advice" and hotspots of information called "pointcuts." Various advices can be introduced based on the kind of adaptation needed. Specifically with the "join-points" (a collection of join-points forms pointcuts) advices can be plugged in at the well-defined hotspots. Due to having various advices to be weaved, most of the aspect-oriented programming (AOP) models such as AspectJ have introduced relative precedence based on their ordering within the aspect body. The property-based pointcut designators facilitate the proactive insertions of advices and control flow-based pointcuts aid in the reactive insertions of advices.

The Role of Policies
We envisioned adaptation in services as the accommodation of new features on an as-needed basis. AOSD addressed the basic need of feature introduction, but to accommodate preferences of both the service requestor and the provider (e.g., late binding and negotiation) we use policy-driven techniques. Policy in Web services refers to a set of rules, facts, capabilities, and preferences that could regulate the behavior of the service. Policy assertions are used to convey the conditions between the interacting services. The service providers would advertise their policies for which the requestors might choose to opt. This would result in a specific behavior that reflects the accepted condition. The policy assertions could hence be used for providing the necessary preferences in adapted behavior of Web services over and above the functionality they embody.

As shown in the Figure 2, policy plays a central role in providing self-adaptation and autonomy to Web services, realizing specific instances of abstract compositions and accommodating preferences between interacting services. In order to facilitate coordination among adaptations we used weaving of aspects. In addition to this we apply policies to reconcile and decide which aspects needed to be woven on the fly. A hierarchy of policies can also be used to provide a rich set of behaviors.

How Do We Achieve Noninvasive Adaptations Using Aspects?
The core idea is that of binding aspects and policies to enrich Web services. In the aforementioned scenario, adaptations were induced in the various participating services by considering dynamic situations such as seasonal (Christmas and New Year) offers like converting EMI-based loans to personal line of credit, variation in scoring in credit reports, and security variations such as choosing the algorithms for encryption of relevant information in messages. The following are details of the participating services:

• Loan Agent Service: A composition service invoked by the customers that orchestrates the various other services listed below. BPEL4WS, an industry-accepted standard was used to compose the orchestration. Oracle's BPEL process engine was used to host this service.
• Credit Rating Service: A simple Web service that gives the credit score, given the unique identity of the customer. This service is only accessible to the loan agents who are registered prior to the requisition. The authorized loan agents are identified through a simple username/password-based authentication. This service provides various means of specifying the credentials. Also the credit scores are provided on varying scales such as 400-900 or 100-point scale.
• Loan Offering Services: Two simple Web services that offer loans based on the individual's credit score, the amount requested, and the repayment period. These services provide various offers such as discounts on interest rates and conversion of type of loan at regular intervals based on the market conditions.

Because AOSD provided a paradigm to address adaptability, policy-driven aspect selection was adopted to enrich the aforementioned Web services and their variations. A mediation layer was plugged into the framework in between the BPEL process and the external Web services as shown in Figure 3 . This layer is responsible for the enforcement of the required policies and the enabling of the relevant aspects. This layer weaves necessary aspects to achieve adaptability within the loan agent service. The aspects would be the enforcement plugs for the policies chosen (policy enforcement point - PEP). A policy store acting as decision point (policy decision point - PDP) stores and fetches various policies based on the contextual information provided to the mediation layer. The policies are expressed using the simple and flexible grammar provided by Sun's Extensible Access Control Markup Language (XACML). XACML provides a model where policies are expressed using XML notations and also has the provision to evaluate policies to label as accept, deny, not applicable, or indeterminate state. To negotiate the policies between the loan agent service and external services, a policy negotiator is used. Once the policies are accepted the negotiator enables the aspects that are woven into the PEP.

To understand the weaving of aspects that bring about necessary adaptations, let's consider a section of the interaction between the loan agent service and the credit rating service (CRS) as shown in Figure 4. When the request is made the orchestration facilitates the extraction of the customer's unique identification from the customer request and constructs the message requesting the credit score to be sent to the CRS. Rather than being sent directly to the CRS, this request gets intercepted by the mediation layer. The PEP in the mediation layer receives the message and based on the message definition the endpoint is selected from the configuration. The PDP then decides on all of the policy actions that are to be associated with the CRS such as the usage of the PBEWithMD5AndDES algorithm for sending credentials. These actions are then forwarded to the policy negotiator that creates policy statements as shown in Listing 1. The policy statements are then exchanged with the CRS, which either accepts or denies them. The policy actions accepted have associated aspect advices that are enabled. So when the PEP forwards the request to the CRS, it passes through the aspect that adds the credentials using WS-Security standards through the use of the accepted algorithm.

Listing 2 gives a snapshot of the PEP and an associated simple aspect that uses the hotspots for adaptations. Because the PEP is a service itself, it has a process operation that receives the messages. It also provides another operation called induceVariations that is used to mark hotspots within the PEP. This operation takes in the message and returns the modified message. As shown, the hotspots are marked before sending the request message and then after receiving the response message. The hotspots and the aspect's advices are triggered, thereby implementing necessary changes as required either during the assignment or before or after invocation. In the interaction between the loan agent and the CRS when the induceVariations operation is called before calling the CRS, the pointcut would add the credentials to the request message. Then returning from the induceVariations operation the modified request message is assigned to the context of the Web service call, thus facilitating transparent (with regard to the PEP or loan agent service) adaptation.

Adaptations in Orchestrated and Choreographed Services
Composition of various independent activities within the view of business functionality is achieved through choreography or orchestration of Web services. The difference between choreography and orchestration is that in case of the latter, one of the services has control over defining the role within the composition. It is thus evident that orchestration languages such as BPEL4WS by nature provide some flexibility. For example in the scenario discussed above, the flexibility in the loan agent process is seen through dynamic partner binding, i.e., addition or deletion of loan offer service. However in case of practical scenarios, orchestrated services too have to support unplanned, on-the-fly changes. The changes however may not necessarily mean changes to the static view of the process (as with different partners), but rather over every instance of the process. Efforts in this regard such as AO4BPEL are adding extensions to the existing BPEL4WS specification, thus allowing specific adaptation for orchestrated services in a modular fashion.

In case of choreography, not one service truly owns the conversation. Because they are collaborative in nature, each party involved describes its part in the interaction and is completely dependent on the observable behavior of every service. The adaptation hence in this case is very essential for managing the logical dependencies between unknown interactions. Specifically adaptation that involves aspect binding plays a prominent role in planning such interactions. Moreover, using the policies will also allow dynamic interaction patterns that would closely follow the changes in business.

Conclusion
Flexibility is an important aspect of e-business that may be achieved by using Web services. The dynamic environment of e-business necessitates constant changes. Web service providers have to evolve so that unplanned changes can be adapted to the contextualized information. Initiatives such as AdaptiveBPEL and AO4BPEL, which have explored ways of transparently allowing customizations. The use of aspect-oriented approaches and policies seems promising for on-the-fly adaptations. A middleware made up of a mediation layer based on policy-driven selection of aspects would especially result in realizing faster time to market for truly adaptive Web services.

The source code for the article accompanies the online version of the article.

References

• Amazon Web services: www.amazon.com/webservices.
• Gisolfi, D. "An Introduction to Dynamic e-Business": www-128.ibm.com/developerworks/library/ws-arc1/
• Web Services Architecture, W3C working group note, February, 11 2004: www.w3.org/TR/ws-arch/
• Erradi, A., Maheshwari, P., Padmanabhuni, S. "Towards a Policy-Driven Framework for Adaptive Web Services Composition," NWeSP 2005, Seoul, Korea.
• Cibrán, M.A., Verheecke, B. "Dynamic Business Rules for Web Service Composition," Second Dynamic Aspects Workshop 2005.
• Ortiz, G., Hernández, J., Clemente, P. J. "Reusable Web Service Choreography and Orchestration Process," Workshop on Engineering Service Composition 2005.
• Charfi, A., Mezini, M. "Using Aspects for Security Engineering of Web Service Compositions," International Conference on Web Services 2005.
• AspectJ project: http://eclipse.org/aspectj