Project Description

Recent advances in networks, information and computation grids, and WWW have resulted in the proliferation of a multitude of physically distributed and autonomously developed software components or services. The W3C Web Services Architecture defines ‘‘Web service as a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL) and other systems can interact with it in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards’’. It is envisioned that the construction and deployment of complex workflows of composite Web services by leveraging independently developed software components will lead to substantial gains in productivity in several application domains including e-Enterprise, e-Business, e-Government, and e-Science. Typically, service composition resorts to suitably integrating ‘‘parts-of’’ the available Web services to develop an integrated service, which otherwise cannot be realized for a particular client requirement. However, developing composite services require overcoming several challenges:

• For specifying the functional requirements of a composite service, the user is responsible for understanding and using service specification languages like OWL-S or BPEL which requires more detailed understanding about the behavior of the desired service. This makes the process of service composition, even for knowledgeable users, tedious and error-prone. As a result, there is a need for developing approaches which allow specifying composition requirements using high-level languages that are intuitive and easy to understand.
• The existing approaches provide one-step request-response paradigm for Web service composition. In other words, a user submits a goal specification to a ‘‘composition analyzer’’ (generically speaking), which tries to find an appropriate strategy for realizing the composite service. In the event, such a composition is incomputable, the whole process fails. As opposed to this, we claim that, there should be provision for iteratively refining the goal in an intuitive, yet efficient way, to build composite services.
• Individual Web services needed for realizing a desired functionality are often developed by autonomous groups or organizations. Consequently, semantic gaps, arising from different choices of vocabulary for specifying the functionality of the services, are inevitable. Frameworks for assembling complex Web services from independently developed component services should provide support for bridging such semantic gaps.
• Available Web services as well as requirements of users change rapidly in the real world. Thus, environments for service composition need to support rapid re-design and re-deployment of services, through re-use of parts of previously assembled services whenever possible and incorporation new components whenever needed.

Motivated by these concerns, this project investigates a new framework Modeling Web Service Composition and Execution (MoSCoE) for (semi)-automatically realizing new services from pre-existing ones. Composition in MoSCoE is based on the three-steps of abstraction, composition & refinement. The user provides a high-level specification of desired service (abstraction) while the service providers advertise existing services in terms of standard service description language. The composition engine identifies a suitable composition, if any such exists; otherwise it guides the user to refine the abstract specification by providing intuitive hints. Refinement can be iterated till a composition strategy is realized or the user decides to abort. In the event such a strategy is realized, it is translated into a concrete BPEL code for execution. During the execution, additional non-functional requirements (such as Quality of Service) of the client are monitored, and appropriate actions are taken in case of violation of these requirements. Furthermore, while execution various data and control flow transformations are carried out by referring to the pre-defined ontologies (describing the services) and the set of inter-ontology mappings. Figure 1 shows the architecture of MoSCoE.

Figure 1: Architectural Diagram of MoSCoE