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) held in Karlsruhe, Germany in November this year (acceptance rate was 16%). You can access the full paper here.

In this work we define a model and an algorithm for execution of services which interfaces we model using Abstract State Machine (ASM) using 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, for example, interfaces in WSDL only defining a set of operations with input and output messages and message exchange patterns). 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 defining services’ input and output messages. Process interoperability needs to be ensured when one service expects to exchange messages in an order that is not directly matching the other service’s choreography.

We showcase the use of the model on a scenario which describes a mediation problem defined by the SWS Challenge initiative. In the scenario, a trading company, called Moon, uses a Customer Relationship Management system and an Order Management System to manage its order processing. Moon has signed agreements to exchange Purchase Order messages with a company called Blue using the RosettaNet standard PIP3A4. There are two interoperability problems in this scenario. First, at the data level the Blue uses PIP3A4 to define request and confirmation messages while Moon uses a proprietary XML Schema for its OMS and CRM systems. Then, 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 customer ID from the CRM system, create the order in the OMS system, add line items into the order, close the order, and send back a confirmation message.

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. 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 system 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. Such questions remain open for our future research.