Article Preview
TopIntroduction
Web services are platform independent modular pieces of software offering functionality over the web to anyone who uses a protocol stack consisting of UDDI, WSDL, and SOAP. Web services aid a business organization by forming a temporal collaboration with other web services to execute a complex business task. Nowadays such collaborations, due to the success of cloud computing, can even perform compute-intensive scientific tasks as well. The collaboration of web services is often termed as web service composition. It is a domain where multiple services are bound are runtime to cater to the need of a client. In web service composition, services are selected on the basis of both functional and non-functional properties. Using service compositions one can achieve flexible, yet efficient business process execution with reduced development and transactional costs. But, the composition of web services at runtime is difficult task. The rationale is backed by (Confora, Penta et al. 2005) where it is specified “Finding optimal solutions for QoS-aware Web service composition with conflicting objectives and restrictions on quality matrices is an NP-hard problem”. The situation is further exasperated by the fact that for single piece of functionality there are multiple service providers. Moreover, owing to reliability and availability problems of distributed computing, a composition has to deal with adaptability and inconsistency issues as well. To demonstrate the situation we present a real world example of a national railway ticket booking system. The example shown below demonstrates how individual services are composed together to accomplish a complex ticket-booking functionality for a user.
To book a ticket a customer has to specify his/her destination and the boarding station. After filling up all the necessary details one has to buy the ticket. The payment could be done via a Bank specific Debit/Credit Card portal or a payment gateway. Further, suppose the payment service providers (e.g. Citi, ICICI, HDFC, Axis Bank, American Express) are divided into Silver-Bronze and Gold-Silver classes respectively. The Silver category has Success rate 70-80%, the bronze category has the success rate of < 70% and the gold category has a success rate of >80%. The gateways in the gold class demand additional charges to offer their services. A normal customer, who wants to minimize the amount he/she has to pay, selects a gateway in Bronze class. If the number of such customers increases drastically then the gateway is bound to become congested. Moreover, there is a huge possibility the stability of the system will be compromised. In such situations the best choice is the recommendation of a gateway by the system so that the quality of experience of a user is not jeopardized (Since, user experience is a valuable asset in the service industry).
In the example, it can be seen that multiple services are working together, but the order in which they are invoked is defined one after the other. A similar architecture of this kind is proposed in (Srivastava and7 Sorenson 2010). Here, the architecture is called a service domain. In a service domain an application can be thought of as a hierarchy of services, where services are invoked in a top down manner. A sample service domain can be represented as Figure 1. Here each level consists of a certain number of service nodes. All the service nodes present at a particular level are functionally equivalent and offer unit functionality. An application is said to be composed when the requests for a composite application exits the lowermost level. It should be noted here that only one service from a level must be selected to accomplish a part of the complex application. In other terms, a service domain is representation of a workflow instance based on service choreography, where a service at a level executes a work-item. A sample service domain for the trip-planning application is shown in Figure 2. This figure is taken from (Srivastava and Sorenson 2010).