Configuration of Web Services as Parametric Design

Abstract

Abstract. The configuration of Web services is particularly hard given the heterogeneous, unreliable and open nature of the Web. Furthermore, such composite Web services are likely to be complex services, that will require adaptation for each specific use. Current approaches to Web service configuration are often based on pre/post-condition-style reasoning, resulting in a planning-style approach to service configuration, configuring a composite web service "from scratch" every time.In this paper, we propose instead a knowledge-intensive brokering approach to the creation of composite Web services. In our approach, we describe a complex Web service as a fixed template, which must be configured for each specific use. Web service configuration can then be regarded as parametric design, in which the parameters of the fixed template have to be instantiated with appropriate component services. During the configuration process, we exploit detailed knowledge about the template and the components, to obtain the required composite web service. We illustrate our proposal by applying it to a specific family of Web services, namely "heuristic classification services". We have implemented a prototype of our knowledge-intensive broker and describe its execution in a concrete scenario.

Customizable Web Services Description, Discovery and Composition : An Attribute Based Formalism

“…However, unlike the approaches [4], [3], and [7], where the services specifications are generic and where planning is the main metaphor behind the Web services composition (i.e., general reasoning based only on the components specifications), our approach, like the one in [6], is based on Web services descriptions in a specific knowledge domain, and the metaphor behind the Web services composition is called mediation (i.e., reasoning with the knowledge specialized in a restricted domain). Indeed, a planner is supposed to be domain independent, it is supposed to work for any set of components, given their descriptions.…”

“…A mediator exploits specific knowledge about the objects (services) it manipulates, it is domain directed, therefore it is more specialized. Our approach provides more genericity than the one proposed in [6] where answers to the requests consist in a set of predefined composite Web services customizable by user requests. In our approach, the response to a given request can be supplied by a simple (basic) service or by any combination of simple services available in the domain.…”

“…The idea of WSC appears also in many other works, with various instances : it is presented in the form of "generic procedures customizable by users' requests" in [4], instantiation of BPEL preset process models in [3], coordination patterns in [7] and as the parametrization of predefined composite Web services in [6]. However, unlike the approaches [4], [3], and [7], where the services specifications are generic and where planning is the main metaphor behind the Web services composition (i.e., general reasoning based only on the components specifications), our approach, like the one in [6], is based on Web services descriptions in a specific knowledge domain, and the metaphor behind the Web services composition is called mediation (i.e., reasoning with the knowledge specialized in a restricted domain).…”

VCU: The Three Dimensions of Reuse

“…Finally, there have also been efforts to provide CI for services through parameterization and personalization [1] and using templates [23]. [2] proposes an approach that allows customized use of web services in XML documents.…”

The OpenKnowledge System: An Interaction-Centered Approach to Knowledge Sharing

“…Semantic web-service work aims at automatic on-line composition of simple services into complex services, by means of intelligent algorithms (e.g. based on configuration [20] or planning [21]), whereas, OpenKnowledge restricts itself to executing predefined "work-flows" of services (the "interaction models" to be discussed later in this paper). The only decision that OpenKnowledge makes at run-time is which instance of a service is executed; that is, which agent providing the service will be used (i.e.…”