Positioning paper of the BPT work group.

Requirements on Ontologies for Web Services for Automated Service Composition.

Dominik Kuropka, Harald Meyer, Mathias Weske

Business Process Technology Group
Hasso Plattner Institute for IT-Systems Engineering
University of Potsdam

1. Business Process Technology research group

The Business Process Technology research group is part of the privately funded Hasso Plattner Institute for IT-Systems Engineering at the University of Potsdam, Germany. Its core competencies are process technology in general and the application of processes in the context of service oriented architectures in particular. This includes concepts and methodologies for process modeling, analysis and flexible enactment. Further research topics are architectures for process-enabled software systems and process-aware software product lines. In the context of services the main expertise is in the areas of semantic-enabled automated service composition, late service bindung and case-based recomposition of services.

Hasso Plattner Institute is one of the 21 members of the EU funded Adaptive Services Grid project. The main scope of this project is research on the design and the prototypical implementation of an open development and deployment platform for semantically described services. The key challenges of the project are automated composition of semantically specified services, generation of software based on semantically specified services and platform-independent models, negotiation and enactment of service compositions by an adaptive process engine and dynamic resource and implementation binding by a grid services infrastructure.

2. Automated Service Composition

A key feature of service-oriented architectures is the possibility to register, discover and invoke services dynamically at any time. Additionally services may also be composed out of existing ones. These service compositions are processes that can be enacted by a process enactment engine to benefit from features like abstract, flexible modeling and monitoring which are provided by those engines. This is an important feature for real world scenarios as it allows to offer new services based on compositions of existing ones.

While this approach allows more flexbility than hard coding service compositions, it still can not leverage the full potential of service-oriented architectures, especially the inherent openness of those architectures. Service compositions can barely incorporate changes in the landscape of available services. While late service-binding allows the substitution of concrete services, it can not handle new services with new functionality or ensure functioning of service compositions if services are de-registered. Requests for services may vary a lot in implemented service-oriented architectures like for example a market place. Several different service requestors with various interests participate in the marketplace requesting different services. Service compositions must therefore be generic to satisfy these requests. Hence the available services and service compositions will be most probably not optimal for all service requests, a more flexible approach is required.

One approach that allows the above described flexibility and also handles the openness of service-oriented architectures is automated service composition. Instead of manually modelling service compositions during build-time, service compositions are automatically composed on-demand during run-time. As the service composition is composed for a specific service request, it is precisely tailored to this particular request. This ensures a better adaption to the peculiarities of each service request. Since service composition takes place directly before enactment, only services available at this point in time are actually used. While it is still possible to use services inside the service composition that are de-registered before enactment, the probability for this is reduced as the time frame between service composition and enactment is shortened. Automated service composition may be combined with late service-binding to further reduce probability of failure and increase the flexibility.

Current Web Service standards are not sufficient to perform automated service composition. WSDL [W3C01] for example defines the operations of services just with input and output parameters (messages). Neither the semantics of the operation's functionality nor the semantics of its non-functional properties are given.

3. Outline of Requirements on Semantic Descriptions for Web Services

For a semantic description of Web Services an adequate framework including a description language and a service ontology [OWLS03, WSMO04] is needed. To support automated service composition the framework has to provide concepts and language constructs which allow a sufficient semantic description of service properties (functional and non-functional). In [ScWe04, Meye05] a model on requirements and concepts needed for automated service composition is provided. It identifies several aspects like concepts and requirements regarding the elements of composition, control and data flow, and quality of services. In this outline we will focus on the elements of composition. They are the building blocks from which the composition is build up. To support automated service composition, it must be defined for each operation what (effect) the operation does under which circumstances (precondition). An operation may have different effects under different circumstances.

Preconditions and effects can be logical expressions. But we opt for introducing numerical expressions as well. Both can be used to define the functionality of a service operation. The use case for numerical expressions is representation of non-functional properties (e.g., cost, time). The advantage of this approach compared to defining non-functional properties seperately from preconditions and effects is for example: It is not only possible to define what the invocation of the service operation does (effect), but also expectations regarding non-functional properties, e.g., cost. The seperation between functional and non-functional properties is actually fuzzy. Not only may properties be non-functional in one scenario and functional in another one (e.g.: time is often regarded as non-functional, but in real-time systems it is functional), but the nature of a property may differ between services and service requests in the same scenario. While time can be crucial for some requestors ("service must be executed in less then 10s") it may be less important to others ("service should be executed as fast as possible"). This is only possible if functional and non-functional properties are unified. Functional and non-functional properties are mapped to logical and numerical expressions. This approach is similar to the one used in the Planning Domain Definition Language (PDDL) [FoLo03] in the AI planning community and allows the automated composition of services based on their functional and non-functional properties [Hoff03].

Regarding logical expressions it is important to support function-free first-order logic. In order to allow easy modeling of objects, frames should be supported. It should also be possible to create objects during the process. If this is not possible all the objects used in a service composition must be specified in the service request in advance. This is inadequate as it restricts the flexibility of service composition and increases modeling efforts: if service operation s1 creates an object that service operation s2 needs as an input, this object should not necessarily be specified in the service request. Only objects which are needed for the semantic specification of the request should be declared in the request. To allow modeling of real world services it is necessary to support negations and disjunctions in preconditions and effects. Negation is for example necessary to specify the absence of information. Disjunctions can be used to express uncertainty over the effects of a service operation. This is a common case in service operations especially for information gathering operations (e.g.: an operation to check the validity of a credit card number may return either true or false).

For numerical expressions it is important to support basic arithmetic operations like addition, multiplication, substraction or division. Means to express equations and inequations are necessary, too. It also makes sense to support ranges to express that the exact value of a property is unknown. With ranges it is possible to state that the invocation of a service operation will cost between, for example, 10¤ and 20¤. Depending on the actual architecture the exact cost are either negotiated with the service provider or determined after the invocation.

4. Summary

Automated service composition and its requirements are a major research area of our group. To support automated service composition, service operations must be semantically specified with preconditions and effects. Results of our current research efforts in this area pointed out that preconditions and effects should be specified using logical and numerical expression. Futher, logical expressions should support function-free first-order logic with a Frame logic like syntax. Preconditions and effects should allow negations and disjunctions. Numerical expressions should be based on basic arithmetic operations and support equations and inequations. Ranges of numerical values should be supported, too.

5. References