Web services have evolved from plain application-integration enablers to value-added stand-alone functionality providers such as getting a quote to a comprehensive business function like processing orders. Enterprises are exploiting this new revenue model by offering such business functions as services on usage basis. Information sharing instances such as Amazon's e-commerce services have helped in the creation of new powerful solutions using business functions as services.

Why Do We Need Adaptation in Web Services?
In the vision of e-business, it becomes important to address the dynamic nature of business environments. As third parties access more and more business functions, the richness of Web services offered should be adequately addressed. With Web services having to participate and cooperate in a networked system, they may need to frequently join or leave a process, or at times may need to change their preferences by tailoring or adding functionalities. Such unanticipated changes as demanded by businesses and the associated complexity necessitate an adaptable nature to web services where specific features can be introduced or deactivated in a planned manner.

The adaptation of Web services with regards to constant change in the business has to deal with the behavior of the service. Some of the existing approaches of adaptation primarily concentrate on transformation of the content and much less effort has been made towards behavioral adaptation. Much as object-oriented programming introduced encapsulation and inheritance, the behavioral adaptation should also introduce features in a modular way. However in contrast to the object-oriented way, certain significant issues need to be addressed:

• Context-aware provisioning, which is necessary because Web services will be involved in widely distributed and heterogeneous solutions
• Diversified personalization, for improving quality of service and delivering user-centric functionality
• Nondisruptive feature insertion/release, to facilitate the high availability requirement

Aren't Business Rules Sufficient?
Even though business rules also define or constrain the behavior of services, they are primarily intended to enforce certain explicit motivations based on contextual data. On the other hand, Web services in e-business scenarios would have to deal with proactive and reactive adaptations. Such adaptations have to be non-enforcing and yet facilitate the requestor's ability to choose the behavior. To understand this better consider a simple personal loan offering service. The bank may decide to run a promotion for a specific season by virtue of which a business rule could be added to the service so that loan requests with credit scores in the range of 60 to 75 on a 100-point scale would reduce the interest rate by 0.25 percent. However converting the offered personal loan to a line of credit having variable interest rates would involve changes in the service logic itself. This wouldn't be a feasible option because it has to be made available only for a specific time period. Moreover, because requestors have different preferences some might not opt for this conversion while others might. Using business rules, such adaptations would get even more complex if the preferences are negotiated before the request is made to the service.

Adaptations May Not Be Just for Functional Features
The behavior of Web services as in the case of any computational system would be made up of certain functional and nonfunctional features. The sole purpose of the nonfunctional features would be to enable services to function for various execution conditions through changes in the behavior of the service without altering the core service logic. A distinguishing factor of such adaptations is that often the service itself might be unaware of the existence of nonfunctional features. To put it another way: the nonfunctional features are not configured at design time but are categorized under operational constraints.

The operational constraints would essentially relate to the communication characteristics between the interacting services. There are various WS-* standards that are trying to address the nonfunctional requirements of Web services. There are also some competing standards for similar functionality. For example, to tackle reliable, guaranteed message delivery, a group consisting of Sun, Fujistu, Oracle, etc. came out with WS-Reliability and a second group consisting of IBM, BEA Systems, Microsoft, and TIBCO came up with the WS-ReliableMessaging specification. Though both provide mechanisms to ensure basic delivery assurance, the difference between them is in how they incorporate other standards such as WS-Security, WS-Addressing, and WS-Policy. On the contrary, there are some specific widely accepted and employed standards for a given problem area that have overlapping features. For instance, in the case of security, there are standards such as Security Assertion Markup Language (SAML) as well as WS-Security that are both widely used to provide security cover to Web services. Because this is the case with the ever-growing stack of WS-* standards, participants within a composition have many options to choose from. Even with such disarray within the stack, some of the reasons that participants differ in their choices could be the pace of adoption of the standard, or the preference for a specific platform/tool choice made during the service development, etc.

Essential Considerations for Adaptation
The behavioral adaptation is to be considered in the context of interaction between the service provider and the requestor. To appropriately customize Web services, the contextual information has to be processed so that the intended interaction is achieved. In order to do so the following considerations are essential for leading to behavioral adaptations within Web services.

Variation Points or Hotspots
The unanticipated introduction of new features has to coexist with the base functionality offered by the Web service. It is also possible that the adaptations would have to intervene between the basic flows. Web services planning for such adaptations will have to identify the variation points or hotspots where new features can be induced. The identification of such hotspots is very crucial and decides the degree of flexibility that a Web service can offer. Another important aspect of hotspots is their role in the weaving of the adaptations. This facilitates the ability of the Web service to truly cater to and take part in a wide variety of solutions.

Proactive and Reactive Nature
Proactivity in the adaptation could be accomplished by deciding on the service behavior even before the change or before the invocation of the service. On the other hand, reactivity is the consequence of the change after the service invocation. For example, the credit reporting service could exhibit a proactive behavior in providing a simple report that contains the credit score and summary or a complete report that details public records, past dues, payment, collections, open accounts, inquires, etc. Reactive behavior may be accomplished by providing the credit score on different scales like 400-900 or 100 points.

Late Binding
The undetermined quality of adaptations necessitates late binding. Without having late binding, the service needs to be as abstract as possible and has to extend itself to add the features indented for adaptation. This may not be feasible and may lead to chaos in managing requirements, which leads to the cluttering of features.

Negotiations
Negotiations provide the property of compatibility and replaceability to the interactions between the requestor and the provider. The constantly changing preferences could be accommodated through negotiations so that both requestor and provider can agree on the best possible terms for information exchange. For example, the way in which security credentials are passed can be negotiated. To ensure his confidentiality, the service requestor can opt for a lengthier encryption key and similarly the service provider can specify various options for the encryption key length from which the requestor can choose.