Formal Model for Semantic-Driven Service Execution

Published by Tomas  Vitvar on August 8, 2008 in Publications,Research

Our work on formal model for semantic-driven service execution (co-authored by me, Adrian Mocan, and Maciej Zaremba) will be published in proceedings of the 7th International Semantic Web Conference (ISWC) to be held in Karlsruhe, Germany in November this year (acceptance rate 16%). You can access the full paper here.

In this work we define a model and an algorithm for execution of services which interfaces are modeled using Abstract State Machines (ASM) that use ontological concepts for their vocabularies (we call this description a choreography). Ontologically-enhanced ASM allows to model services’ interfaces with more descriptive information (as opposed to e.g. interfaces in WSDL only defining a set of operations with input and output messages and message exchange patterns for those operations). In this work we build additional layer of ASM descriptions on top of WSDL descriptions (XML Schema and Interface) and show how a conversation between two services can be executed.

The important aspect of service execution is to maintain services’ interoperability at the data and process levels. Data interoperability needs to be ensured when services use different information models used to define services’ input and output messages, and process interoperability needs to be ensured when one service expects to exchange messages in an order that is not directly matching the order of the other service. We illustrate the usage of the execution model on the case scenario implemented on our WSMO, WSML, and WSMX technologies as the figure below depicts.

The scenario describes a mediation problem defined by the SWS Challenge initiative. In the scenario, a trading company, called Moon, uses a Customer Relationship Management system (CRM) and an Order Management System (OMS) to manage its order processing. Moon has signed agreements to exchange Purchase Order (PO) messages with a company called Blue using the RosettaNet standard PIP3A4. There are two interoperability problems in the scenario: At the data level, the Blue uses PIP3A4 to define the PO request and confirmation messages while Moon uses a proprietary XML Schema for its OMS and CRM systems. At the process level, the Blue follows PIP3A4 Partner Interface Protocol (PIP), i.e. it sends out a PIP3A4 PO message, including all items to be ordered, and expects to receive a PIP3A4 PO confirmation message. On the other hand, various interactions with the CRM and OMS systems must be performed in Moon in order to process the order, i.e. get the internal ID for the customer from the CRM system, create the order in the OMS system, add line items into the order, close the order, and send back the PO confirmation.

By using ASMs and ontologies we automatically adjust the order of messages conforming to both services’ descriptions while at the same time we resolve data interoperability conflicts by using ontology alignments between services’ information models. The following Figure depicts the model in a form of a state diagram.

In our paper we describe in detail the algorithm for services execution operating according to the model depicted in the figure above. The input for the algorithm are two services both having defined their choreographies as ontologized ASMs over WSDL interface operations (in addition, a grounding between ASM rules and underlying WSDL interface operations is also defined), and ontology alignments between both services’ ontologies. In a nuthshell, when a message is available from one service, the algorithm process the message, that is, it transforms the message to the others service’s ontology and places the message for evaluation by its choreography.

It is important to note, that our algorithm works well in cases when the two choreographies are compatible, that is, interoperability can be achieved by adjusting the order of messages. The algorithm in its current form will not work when there is a message requested by one service that the other service never sends. In such cases, the message would have to be created on the fly based on some background knowledge that the algorithm should posses while at the same time solutions for such problems would need to build on a concrete semantics of messages. For example, the algorithm should know that a message is an acknowledgment message, etc. These questions remain open for our future research.

Leave a Reply