As web services become more prevalent, tools will be needed to help users find, filter and integrate these services. Composing existing services to obtain new functionality will prove to be essential for both business-to-business and business-to-consumer applications. We have developed a prototype to guide users in the dynamic composition of web services. Our semi-automatic process includes presenting matching services to the user at each step of composition, filtering the possibilities by using semantic descriptions and directly executing the services through WSDL.
Semantic Web, OWL, DAML-S, Web Services, Web Service Composition
Web services are designed to provide interoperability between diverse applications. Composing services dynamically to create new functionality is necessary when the required task cannot be realized directly by the existing services. It is an ongoing research activity to automate this process but accomplishing this goal with a human controller as the decision mechanism can be achieved. The main problem is the gap between the concepts people use and the data computers interpret. We can overcome this barrier using Semantic Web technologies.
The Semantic Web [1] is an extension of the current web in which information is given well-defined meaning, better enabling computers and people to work in cooperation. This is realized by marking up Web content, its properties, and its relations, in a reasonably expressive markup language with a well-defined semantics. The Web Ontology Language (OWL) [3] is a forthcoming W3C specification for such a language which will supersede the earlier DARPA Agent Markup Language (DAML+OIL). The DAML-services (DAML-S) [2] is a set of ontologies marked up in this language to establish a framework within which the web services may be described in this semantic web context.
DAML-S partitions a semantic description of a web service into three components: the service profile, process model and grounding. The ServiceProfile describes what the service does by specifying the input and output types, preconditions and effects. The Process Model describes how the service works; each service is either an AtomicProcess that is executed directly or a CompositeProcess that is a combination of other subprocesses. The Grounding contains the details of how an agent can access a service by usually specifying a binding to a WSDL operation.
Our work focuses on the composition of web services that have been previously annotated with semantics and discovered by a system. As an example of composition, suppose there are two web services, an on-line language translator and a dictionary service, where the first one translates text between several language pairs and the second one returns the meanings of English words. If a user needs a FrenchDictionary service, neither of these can satisfy the requirement. However, together they can -- the input can be translated from French to English, fed through the English Dictionary, and then translated back to French. To provide the semantic concepts like language or French, we can use the ontologies provided on the Semantic Web.
Service composition can also be used in linking Web (and Semantic Web) concepts to services provided in other network-based environments. One example is a sensor network environment which includes two types of services; basic sensor services that returns the sensor data as their output and sensor processing services that combine the data coming from different sensors in some way and produce a new output. As an example task in this environment, the data from several acoustic and infrared sensors can be combined together and after applying filters and special functions, this data may be used to identify the objects in the environment.
We have developed a service composition prototype that has two basic components: a composer and an inference engine. The inference engine is an OWL reasoner built on Prolog. Ontological information written in DAML is translated to RDF triples and loaded to a Knowledge Base (KB) which is used by the engine. The composer is the user interface that includes the workflow editor where user generates the composition and the filtering panel where constraints are defined on service attributes to filter the results.
The composer lets the user create a workflow of services by presenting the available choices at each step. The user starts the composition process by selecting one of the services registered to the engine. Other services that can provide the appropriate input for this service are found by the inference engine and presented in the UI as possible matches. The parameter descriptions in the profile allow defining two different types of matches between services, an exact match and a generic match. An exact match is defined between two parameters which are restricted to the same OWL class. The match between the services whose output type is a subclass of the other service's input type is called a generic match. The matches are sorted such that exact matches appear at the beginning of the list presented to the user since they are more likely to be preferred in the composition. The inference engine orders the generic matches such that the priority of the matches are lowered when the distance between the two types in the ontology tree increases.
The number of services displayed in the list of possible matches can be extremely high in many cases. For example, a power grid or telephone network might have many thousands of sensors each providing several services. In this case, non-functional attributes of the service such as sensor location, type, deployment date, sensitivity, etc will be useful to determine the most relevant service for the current task.
In our prototype, filtering is provided based on the profile descriptions of the services. The profiles have a hierarchy defined in service ontologies which is used as the first level filtering. An example in the sensor network is the SensorService which constitutes a superclass of AcousticSensorService and InfraRedSensorService. Selecting a service type filters the results to display only the services descending from the selected type.
The second level of filtering is done by specifying constraints on the non-functional profile attributes. Selecting a service type such as AcousticSensorService will cause the composer to create a GUI panel that shows the non-functional properties of this service type, e.g. microphone sensitivity, signal processing type, etc. All the properties inherited from superclasses will also be available in this panel. User can specify a value or a range for a specific attribute to filter out the irrelevant services as shown in Figure 2.
Each composition generated by the user using the existing prototype can itself be realized as a DAML-S CompositeProcess, thus allowing it also to be advertised, discovered, and composed with other services. In the composer, we generate exactly such a CompositeProcess description, and also create the corresponding ServiceProfile with user added non-functional properties. Such a description is immediately available to the system as a named service which can be filtered and composed in the normal way.
The current implementation of the system executes the composition by invoking each individual service and passing the data between the services according to the flow constructed by the user. This method is primarily dictated by DAML-S and WSDL specification but creates scalability and availability problems. For efficiency, we need a special framework where each node abides by a set of system rules to conduct the execution process by directly passing its result to the next service. In the prototype, we address this by adding the functionality of generating an XML workflow description that can be passed to the non-centralized system in SOAP (and forwarded as necessary). As the standards in this area of web services are settled, it will be easy to adapt the system to the new interface.
In this work, we have shown how to use semantic descriptions to aid in the composition of web services. We have developed a prototype system and shown that it can compose the actual web services deployed on the internet as well as providing filtering capabilities where a large number of similar services exist. Our prototype is the first system to directly combine the DAML-S semantic service descriptions with actual invocations of the WSDL descriptions allowing us to execute the composed services on the Web.