ment of OWL-S 1, which defines an upper ontology for ser- vices thereby providing the means for software agents to not. âA full version of this paper is available ...
Semantic Enhancement of a Web Service Integration ∗ Gateway Dominic Greenwood, Jozef Nagy and Monique Calisti Whitestein Technologies AG Zürich, Switzerland {dgr,
jna, mca}@whitestein.com
ABSTRACT This paper reports on a technology enabling bidirectional semantic interoperability between FIPA compliant agents and Web services, using OWL-S as a common service description language. This is an an extension of previously reported work consisting of a gateway for WSDL encoded Web service descriptions. This paper reports on the enhanced model, a semantic integration gateway, its architecture and operation. We discuss how the Gateway allows agents and Web clients to invoke both atomic services and composition patterns consisting of both agent services and Web services represented as unified workflow patterns. This is achieved by using OWL-S to express the service descriptions of both agent and Web services, with JADE agents engineered to facilitate the service composition process.
Keywords Semantic Web Services, Integration Gateway, JADE Agents, OWL-S, workflow invocation
1.
INTRODUCTION
In a bid to further enhance the nature of electronic commerce and business interactions, many of those responsible for making choices regarding technology provisioning are rapidly beginning to address the tangible prospects offered by Web service technology. Simple, yet effective in nature, Web services are fast emerging as the dominant means for connecting remotely executing programs via well established internet protocols and commonly used machine readable representations. This paper presents a formulation of how Web services, when enhanced with semantic service descriptions, can be more effectively manipulated by software agents, and in addition composed into unified workflow patterns with agent services to form interesting new functional modalities. To provide FIPA compliant agents with the means to interact with Web services, and vice versa, a Semantic Integration Gateway is introduced. This Gateway is an iterative development of the Web Services Integration Gateway [4] available as a component of the JADE agent development framework (v3.3). There is a growing grassroots community interested in determining ways in which the traditional Web service technology stack can be enhanced to provide Semantic Web services. This effort is strongly characterised by the development of OWL-S 1 , which defines an upper ontology for services thereby providing the means for software agents to not ∗A full version of this paper is available at http://www.whitestein.com/pages/downloads/publications.html 1 Ontology Web Language - Service Ontology
only access, but reason more effectively about how to best make use of a service - especially in the context of composed groups of services. The structure and use of OWL-S in the context of this work is discussed in Section 2. Software agents are now increasingly used in commercial applications [1] to address complex engineering problems, and similar to Web services, can be used to encapsulate some business or application logic. Agents differ in that they do not simply expose functionality as methods over a fixed protocol, but instead often offer multiple services, or behaviours, that can be processed concurrently and activated by specifying goals. In this perspective, identifying a means of connecting agents and Web services is the motivation and central foundation of our work. Due to the technology mismatches between Web services and FIPA compliant software agents, we propose an approach that uses a Semantic Integration Gateway as a means to encapsulate and automate the functionality required to connect the two domains, while ensuring minimal human intervention and service interruption. This Gateway is controlled by a software agent, capable of connecting Web services and software agents, i.e. a Web service becomes able to invoke a registered agent service and vice versa. Once this interconnection is established, software agents capable of comprehending OWL-S can use the Gateway to enable advanced operational and usage modalities of Web services. Several arguments have been established to support this case, including those made in [3] [5] [6]and [7]. The body of this paper is divided into two sections: Firstly, a discussion concerning the semantic coupling of agents and Web services, followed by an architectural and operational description of the Semantic Integration Gateway.
2. SEMANTIC COUPLING The standard Web service stack employs WSDL as the means to specify service descriptions. WSDL 2 is however limited in its ability to express semantic information about a service that could be used by an agent for intelligently manipulating it. For this reason, the Semantic Integration Gateway uses OWL-S to provide a richer form of service description to agents, specifically through use of the OWL-S Grounding Ontology to map standard WSDL elements onto ontology elements. The OWL-S atomic process is mapped onto WSDL operations; the set of inputs and outputs onto the atomic process is mapped onto the WSDL message concept, and the OWL-S class types of the inputs and outputs 2
The Gateway currently conforms to WSDL1.1
of an atomic process are mapped onto the WSDL extensible concept of abstract type. In the opposite direction the OWL-S WsdlGrounding class is used, whose instances contain a list of WsdlAtomicProcessGrounding instances that map onto the specific elements of the WSDL specification. The precise details of the mapping is beyond the scope of this paper but are largely conformant to the guidelines issued by the OWL-S consortium. We have also made use of OWL-S to export the service descriptions of FIPA compliant agents within a JADE platform, normally held as a Java bean hierarchy. This not only implies that OWL-S can be used as common service ontology for manipulating and reasoning about agent and Web service descriptions, it also simplifies the Gateway translation mechanism that maps OWL-S bidirectionally onto WSDL. OWL-S provides the means to describe services according to three aspects. The service profile defines what the service expects of its consumers and what it provides for them. The service process model defines how the service operates, and the service grounding defines how the service is accessed for use. Typical use of the Gateway will be by one or more agents acting as composition coordinators to build a process model from selected services. The criteria for selecting services to participate in the process is a function of their service profile, i.e. input, output, pre-conditions and effects. Each process model is seen by the agent as a specification of how the clients of a service transaction interact with that service. OWL-S defines atomic, composite and simple processes. As yet, we have considered only the use of atomic processes (a service expecting and returning a single message) and composite processes (each message sent by a client advances the process). The use of OWL-S to compose agent and Web service interactions in this manner enables interesting combinatorial modalities. The value of harnessing this semantic expressivity is highlighted in [2] and [8], with one of the most significant facets being the ability to automatically and dynamically locate and use interchangeable services through matching semantic abstractions.
Directory Facilitators. It is not registered directly in UDDI directories, as its functionality is exposed outside the agent platform via a Web server. • All invocation related interactions between the Gateway and agents use ACL encoded FIPA-Request and FIPA-Inform performatives. This is essentially all that is needed to invoke standard request-response Web services.
3.
As shown, the Gateway consists of several components, each linked either directly or indirectly to two registries - a Directory Facilitator (DF) for storing agent service descriptions and a UDDI service for storing Web service descriptions. The DF is the same instantiation as that used by all agents within the agent platform and is not visible outside the platform. The UDDI belongs solely to the Gateway, is visible internally to the Gateway and externally to Web services and Web service clients, but not directly to agents. The Gateway itself is registered as an agent service in the platform DF. Each registry exposes the standard operations: Registration, deregistration, modification and discovery. Use of these registries is central to the Gateway architecture. Any service description that is registered with either the DF or UDDI registry is automatically translated into an entry for the other. This duplication ensures that any registered Web service is visible to agents via the DF and any registered agent service visible to Web service clients via the UDDI.
SEMANTIC INTEGRATION GATEWAY
The Gateway is designed as a collection of functional modules housed within a JADE agent platform. The Gateway offers automatic, bidirectional operation allowing both FIPA compliant agent services and Web services to be registered with it. Agent services and Web services can thereby publish their service descriptions to consumers outside their normal operational domain. The Gateway can then intercept calls to these registered services allowing agents to invoke Web services and vice versa by transforming message encodings and creating service access endpoints.
3.1 Assumptions The following assumptions were made when designing the Gateway architecture: • All agents are assumed to be FIPA compliant and capable of communicating with FIPA-ACL encoded messages. • All Web services operate using the standard Web service stack consisting of WSDL for service descriptions, SOAP for message encoding and UDDI for directory services. • All agent services ontologies are exposed in OWL-S format. • The Gateway is registered as an agent service in FIPA
3.2 Gateway Architecture The problem to be solved with the Gateway is to provide an automatic means of mapping the functional and representational dependencies associated with the invocation of agent services onto those associated with Web services and vice versa. Our proposed solution, as illustrated in Figure 1 introduces an intermediary processor (Gateway) into the communication path between these service calls.
Figure 1: Gateway architecture overview
The Gateway Agent At the heart of the architecture is the Gateway Agent which is implemented as a standard JADE agent, but with be-
haviours controlling access to a number of local components (codecs, Web server, etc.), operating as independent threads. The Gateway Agent is responsible for the following tasks: • Receiving notifications from the agent platform DF that an agent has registered an ACL Service Description (SD) that it wishes to expose for invocation as an external Web service. • Administering the mapping of newly registered ACL SDs into tModels for publication via the Gateway UDDI. • Receiving notifications from the Gateway UDDI that a Web service has registered a WSDL SD to be exposed for invocation by agents. • Administering the mapping of newly registered WSDL SDs into OWL-S service ontologies and ACL SDs for publication via the agent platform DF. • Receiving requests from platform agents to invoke an external Web service. These requests are expected strictly in the form of FIPA Request messages. Responses from a Web service are returned to the agent in the form of FIPA Inform messages. • Forwarding requests for service invocation received from external Web services, in the form of FIPA Request messages. Again, responses are expected to be in the form of FIPA Inform messages.
3.3 Gateway Operation The Gateway has four principal modes of operation: (1) Mapping a newly registered agent service into its counterpart Web service counterpart, (2) The inverse mapping of (1), (3) Invoking a Web Service from an agent and (4) Invoking an agent service from a Web service client. When initiated the Gateway agent starts it first registers with the local agent platform DF.
Registering an Agent Service As illustrated in Figure 2, service registrations are received by the gateway via the agent platform DF in the agent case or by the Gateway UDDI in the Web service case.
The ACL-SL0/tModel-SOAP Codec This module is a complex codec that bidirectionally translates FIPA SL0 service descriptions into UDDI tModels and FIPA ACL messages into SOAP messages. These two codecs are unified because ACL/SL0 can be translated into either tModels or SOAP messages according to the usage case. The module is responsible for the following tasks: • Parsing ACL messages received from the platform DF to extract the SL0 encoded service descriptions (SD) held within their content. • Translating the SL0 SD into a UDDI tModel and returning the results to the Gateway agent for registration with the UDDI. • Parsing ACL-SL0 messages sent to the Gateway to invoke a Web service into a corresponding SOAP message. • Operating bidirectionally to translate SOAP and tModels into correctly encoded ACL-SLO messages and DF entries.
The OWL-S/WSDL Codec This module is a codec that bidirectionally translates OWLS encoded service ontologies into WSDL encoded service descriptions. It uses the mapping guidelines described in the OWL-S specifications.
The Axis Web Server This module is used to both interface with external Web services and their clients, and internally publish OWL-S schema of agent service ontologies. It is responsible for the following tasks: • Externally (outside the agent platform) publishing agent services as endpoints that can be called by Web service clients. • Handling invocation requests for published agent services, issued by Web services. • Internally (within the agent platform) publishing OWL-S service ontologies that have been produced from the WSDL service descriptions of registered Web services.
Figure 2: Registering an agent service The standard JADE DF has been extended to incorporate a monitor that verifies if any agent service registrations are of ACL type ’web-service’. If this is the case, the Gateway agent is informed by issuing a FIPA Inform message. The Gateway, on reception of this message, initiates a behaviour which first calls the ACL-SL0/tModel-SOAP Codec to translate the ACL message and contained SL0 3 encoded service description into a tModel. Once the ACL message has been decoded the value of ontology slot is used to resolve the published location of the OWL-S service ontology associated with the service (if one is available). This reference is passed to the OWL-S/WSDL Codec and translated to a WSDL representation of the service description that can be used by Web services to identify the features of the exposed agent service. Once produced, this WSDL description is published via the Web server and a reference included into the tModel, which can then be registered with the Gateway UDDI. Finally, if this process is successful, the Gateway agent initiates a new external endpoint on the Web server to expose an instantiation of the newly created WSDL service description for invocation by Web services and Web service clients. Similar to registration requests, de-registration and modification requests received by the platform DF of type ’webservice’ will cause appropriate ACL messages to be sent to 3 Currently the Gateway SL codec is restricted to parsing SL0.
the Gateway DF, initiating removal/modification of UDDI entries, WSDL schema and invocation endpoints. Discovery requests received by platform DF require no action by the Gateway.
Registering a Web Service With reference to Figure 2, Web service registrations are received by the Gateway via the Gateway UDDI, which is designed to trigger a behaviour within the Gateway agent on reception of a new registration. Subsequently the process path is essentially the inverse of that described in the previous section: First the tModel is passed through the ACLSL0/tModel-SOAP Codec to produce an SL0 version of the service description. Simultaneously, the WSDL description of the Web service is parsed into an OWL-S representation by the OWL-S/WSDL Codec, the resulting service ontology published internally to the agent platform via the Web server and a reference to it added to the ontology slot of an ACL message created by the Gateway agent to register the new SL0 service description with the platform DF. Finally, the Gateway agent updates an internal knowledge base that lists all Web services that have a current registration with the platform DF. This allows the Gateway agent to quickly establish whether an incoming Web service invocation request from an agent is valid without needing to verify against the UDDI. Requests for de-registration and modification are treated similarly, with the former leading to removal of the DF and UDDI registrations. Discovery requests to the UDDI again require no action by the Gateway.
Invocation of a Web service by an Agent Under the assumption that an agent has established the identity of the Web service it wishes to invoke by searching its local DF, it sends a standard ACL FIPA Request message to the Gateway containing the identity of the Web service to be invoked and any parameters as properties of the request. Initially a received ACL message is parsed by the Gateway as would a normal agent parse an incoming message. Next, the Web service identified in the message content as being that to be invoked is verified as being registered with the Gateway (against the Gateway agent’s internal list - see Section 3.3). If not, an error is returned to the invoking agent, otherwise a SOAP message is constructed using the WSDL service description of the Web service to be invoked. If no response is expected from the Web service this SOAP message is then sent; otherwise, a temporary endpoint is established on the Gateway Web server to receive responses 4 . On reception of the response the incoming SOAP message is parsed into an ACL FIPA Inform message and sent to the invoking agent. Finally, the temporary endpoint is removed.
Invocation of an agent service by a Web service client For a Web service client to invoke an agent service, the Gateway must first expose that service as a Web service endpoint (as described previously). If this is the case, the incoming SOAP message from the Web service client is parsed into an ACL FIPA Request message containing the SL0 encoded service request and sent to the agent containing the service 4 Error messages returned from the invoked Web services are treated separately
to be invoked. Once the receiving agent processes the service invocation, if required, it will return a response to the Gateway as a FIPA Inform message. This response is then parsed by the Gateway into a SOAP message and returned to the invoking Web service client. The Gateway agent uses the FIPA conversation id ACL message parameter to track conversation contexts between itself and any agents participating in requests for, or delivery of service. This helps to ensure that messages are correctly correlated.
4. CONCLUSIONS This paper reports on the architecture, operation and use of a Semantic Integration Gateway that enables seamless, bidirectional and automatic connectivity between agent services and Web services. The Gateway supports the cross registration of both agent services and Web services, i.e. agent services can be registered in UDDI and both WSDL and OWL-S Web service descriptions in FIPA DF repositories. From this point, any registered Web service can be invoked by an agent by addressing an invocation call to the Gateway. Equally, as the Gateway exposes registered agent services as endpoints using an internal Web server, Web services can also make invocation calls into an agent platform. The Gateway makes use of OWL-S service ontologies to represent the native service descriptions of both agent services and Web services in a common, semantically expressive encoding. This allows agents to compose mixed workflows, as OWL-S process models, consisting of both agent services and Web services as required.
5. REFERENCES [1] M. Calisti. Adaptive solutions for dynamic markets. In AgentLink Technology Conference, Zurich, Switzerland, 2004. [2] N.J. Davies, D. Fensel, and M. Richardson. The future of web services. BT Technology Journal, 22(1):76–82, January 2004. [3] David Booth et. al. Web service architecture w3c working note. In W3C Working Notes, 2004. [4] D. Greenwood and M. Calisti. An automatic, bi-directional service integration gateway. In Proc. of the 2nd International Workshop on Web Services and Agent Based Engineering, New York, U.S.A., July 2004. [5] M. Lyell, L. Rosen, M. Casagni-Simkins, and D. Norris. On software agents and web services: Usage and design concepts and issues. In Proc. of the 1st International Workshop on Web Services and Agent Based Engineering, Sydney, Australia, July 2003. [6] E.M. Maximilien and M.P. Singh. Agent-based architecture for autonomic web service selection. In Proc. of the 1st International Workshop on Web Services and Agent Based Engineering, Sydney, Australia, July 2003. [7] K. Sycara, M. Paolucci, and J. Soundry N. Srinivasan. Dynamic discovery and coordination of agent-based semantic web services. IEEE Internet Computing, 8(3):66–73, May 2004. [8] J.M. Vidal, P. Buhler, and C. Stahl. Multiagent systems with workflows. IEEE Internet Computing, 8(1):76–82, January/February 2004.
