DIPData, Information and Process Integration with Semantic Web Services

FP6 – 507483

Deliverable

WP6: Architecture and Interoperability

D6.8

DIP Revised Architecture

Michal Zaremba, Matthew MoranAdrian Mocan, Emilia Cimpian

Thomas Haselwanter, Maciej Zaremba

December 15, 2005

Executive Summary

This deliverable provides the conceptual description and framework for the Web ser-vices architecture used in DIP. The document provides a structural view of the compo-nents required by the architecture and the interactions between them. A brief textualdescription is provided for each component along with a description of the components’interfaces, described using Java.

This deliverable presents the vision and architecture of a distributed system, wheresemantically described components can be plugged in and out, and where the descrip-tion of the invocation order of the components is separated from their implementation.While we assume that for the Semantic Web services (SWS) infrastructure, a minimalset of components for discovery, mediation, composition, invocation etc. are required,the system should support the hosting of additional components, whose functionalitymay be unknown at system design-time. The architecture is designed to allow new orupgraded components to be plugged in without affecting the stability of the system.

WSMX is provided as open-source software at SourceForge.net and formed an in-tegral part of the W3C member submission for Semantic Web services submitted byDERI, Galway (NUIG) and DERI Innsbruck (Leopold Franzens Universitaet, Inns-bruck). WSMX also provides the basis for the newly formed OASIS Technical Com-mitte for specifying a Semantic Execution Environment (OASIS SEE TC). The focusof this OASIS committee is to further develop the Semantic Web services architectureand description of execution semantics initiated through WSMX.

The architecture described here is relevant for all deliverables in DIP responsiblefor providing a functional component for the DIP Semantic Web services executionenvironment prototype.

Disclaimer: The DIP Consortium is proprietary. There is no warranty for the accu-racy or completeness of the information, text, graphics, links or other items containedwithin this material. This document represents the common view of the consortiumand does not necessarily reflect the view of the individual partners.

Deliverable 6.8 ii December 15, 2005

Document Information

IST ProjectNumber

FP6 – 507483 Acronym DIP

Full Title Data, Information, and Process Integration with Semantic Web ServicesProject URL http://dip.semanticweb.org/

Document URLEU Project Officer Kai Tullius

Deliverable Number 6.8 Title DIP Revised ArchitectureWork Package Number 6 Title Architecture and Interoperability

Date of Delivery Contractual M24 Actual 05-Dec-05Status version 001 final �

Nature prototype � report � dissemination �

DisseminationLevel

public � consortium �

Authors (Partner) Michal Zaremba (NUIG), Matthew Moran (NUIG)Adrian Mocan (NUIG), Emilia Cimpian (NUIG)Maciej Zaremba (NUIG), Thomas Haselwanter (UIBK)

Resp. AuthorMatthew Moran E-mail matthew.moran@deri.orgPartner NUIG Phone +353 (91) 495-017

Abstract(for dissemination)

This deliverable describes the Web services Execution Environment (WSMX) Ar-chitecture for the DIP project. The document provides both a high-level overviewof the necessary system components and the interactions between them (con-ceptual architecture) as well as a low-level definition of component interfaces,connectivity and the applied events mechanism used by the current referenceimplementation.

Keywords Execution environment, architecture, Semantic Web, Semantic Web services, ex-ecution semantics, SOA

Deliverable 6.8 iii December 15, 2005

Version LogIssue Date Rev No. Author Change21 Jun 05 1 Matthew Moran Draft for D6.5 (internal architecture deliver-

able)27 Jun 05 2 Matthew Moran Updated based on comments of Edward Kil-

garriff28 Jun 05 3 Matthew Moran Updated based on comments of Laurentiu

Vasiliu15 Sep 05 4 Matthew Moran Draft for D6.81 Dec 05 5 Matthew Moran Updated summary. Updated section 3

to include newer architecture diagram andslightly modified component descriptions.Updated section 4 to provide revised de-scriptions and UNL activity diagrams forWSMX execution semantics. Revised sec-tion 5 slightly to remove redundant para-graphs. Revised Appendix A to ensureAPI matches revised DIP architecture API(D6.9).

5 Dec 05 6 Matthew Moran Final updates to draft for review15 Dec 05 7 Matthew Moran Updates after review

Deliverable 6.8 iv December 15, 2005

Project Consortium Information

Partner Acronym ContactNational University of Galway NUIG Prof. Dr. Christoph Bussler

Digital Enterprise Research Institute(DERI)National University of Ireland, GalwayGalwayIrelandE-mail: chris.bussler@deri.ieTel: +353 91 512460

Fundacion De La Innovacion.Bankinter Bankinter Monica Martinez MontesFundacion de la Innovation. BankInter,Paseo Castellana, 2928046 Madrid,SpainEmail: mmtnez@bankinter.esTel: 916234238

Berlecon Research GmbH Berelcon Dr. Thorsten WichmannBerlecon Research GmbH,Oranienburger Str. 32,10117 Berlin, GermanyE-mail: tw@berlecon.deTel: +49 30 2852960

British Telecommunications Plc. BT Dr. John DaviesBT Exact (Orion Floor 5 pp12)Adastral Park MartleshamIpswich IP5 3RE,United KingdomEmail: john.nj.davies@bt.comTel: +44 1473 609583

Swiss Federal Institute of Technology,Lausanne

EPFL Prof. Karl AbererDistributed Information Systems LaboratoryEcole Polytechnique Federale de LausanneBat. PSE-A1015 Lausanne, SwitzerlandE-mail : Karl.Aberer@epfl.chTel: +41 21 693 4679

Essex County Council Essex Mary Rowlatt,Essex County Council,PO Box 11, County Hall, Duke Street,Chelmsford, Essex, CM1 1LX,United Kingdom.E-mail: maryr@essexcc.gov.ukTel: +44 (0)1245 436524

Forschungszentrum Informatik FZI Andreas AbeckerForschungszentrum InformatikHaid-und-Neu Strasse 10-1476131 KarlsruheGermanyE-mail: abecker@fzi.deTel: +49 721 96540

Deliverable 6.8 v December 15, 2005

Institut fur Informatik,Leopold-Franzens Universitat Innsbruck

UIBK Prof. Dieter FenselInstitute of computer scienceUniversity of InnsbruckTechnikerstr. 25A-6020 Innsbruck, AustriaEmail: dieter.fensel@deri.orgTel: +43 512 5076485

ILOG SA ILOG Christian de Sainte Marie9 Rue de Verdun, 94253,Gentilly, FranceE-mail: csma@ilog.frTel: +33 1 49082981

inubit AG inubit Torsten Schmale,inubit AG,Lutzowstraße 105-106D-10785 Berlin,GermanyE-mail: ts@inubit.comTel: +49 30726112 0

Intelligent Software Components, S.A. iSOCO Dr. V. Richard Benjamins, Director R&DIntelligent Software Components, S.A.Pedro de Valdivia 1028006 Madrid, SpainE-mail: rbenjamins@isoco.comTel. +34 913 349 797

NIWA Web Solutions NIWA Alexander WahlerNIWA Web SolutionsNiederacher & Wahler OEGKirchengasse 13/1aA-1070 Wien, AustriaE-mail: wahler@niwa.atTel. +43 1 319 5843 11

The Open University OU Dr. John DomingueKnowledge Media Institute,The Open University, Walton Hall,Milton Keynes, MK7 6AA, UKE-mail: j.b.domingue@open.ac.ukTel.: +44 1908 655014

SAP AG SAP Dr. Elmar DornerSAP Research, CEC KarlsruheSAP AGVincenz-Priessnitz-Str. 176131 Karlsruhe, GermanyE-mail: elmar.dorner@sap.comTel: +49 721 6902 31

Sirma AI Ltd. Sirma Atanas Kiryakov,Ontotext Lab, - Sirma AI EAD,Office Express IT Centre, 3rd Floor135 Tzarigradsko Chausse,Sofia 1784, BulgariaE-mail: atanas.kiryakov@sirma.bgTel.: +359 2 9768 303

Deliverable 6.8 vi December 15, 2005

Unicorn Solution Ltd. Unicorn Jeff EisenbergUnicorn Solutions Ltd,Malcha Technology Park 1Jerusalem 96951,IsraelE-mail: Jeff.Eisenberg@unicorn.comTel.: +972 2 6491111

Vrije Universiteit Brussel VUB Carlo Wouters,Starlab- VUBVrije Universiteit BrusselPleinlaan 2, G-101050 Brussel, BelgiumE-mail: carlo.wouters@vub.ac.beTel.: +32 (0) 2 629 3719

Deliverable 6.8 vii December 15, 2005

Table of Contents

1 Introduction 1

1.1 Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivation for the Architecture . . . . . . . . . . . . . . . . . . . . . . 21.3 Architecture Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Architecture versus Design & Implementation . . . . . . . . . . . . . . 31.5 Organisation of the Document . . . . . . . . . . . . . . . . . . . . . . . 4

2 Architecture Overview 5

2.1 A P2P Network of WSMX Nodes . . . . . . . . . . . . . . . . . . . . . 52.2 Overview of a single WSMX Node: SOA vs Layers . . . . . . . . . . . 5

3 Structural View 7

3.1 Architecture Components . . . . . . . . . . . . . . . . . . . . . . . . . 73.1.1 Core Component . . . . . . . . . . . . . . . . . . . . . . . . . . 83.1.2 Resource Manager . . . . . . . . . . . . . . . . . . . . . . . . . 83.1.3 Service Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.4 Non-functional Selector . . . . . . . . . . . . . . . . . . . . . . . 93.1.5 Data Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.6 Process Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.7 CommunicationManager . . . . . . . . . . . . . . . . . . . . . . 103.1.8 Choreography Engine . . . . . . . . . . . . . . . . . . . . . . . . 113.1.9 Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.10 Orchestration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.11 Web Service Modelling Toolkit . . . . . . . . . . . . . . . . . . 113.1.12 Reasoner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.13 Adapter Framework . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.14 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Behavioural View 13

4.1 Separating Component Behaviour from Implementation . . . . . . . . . 13

5 WSMX Execution Semantics 17

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.1.1 Purpose of this section . . . . . . . . . . . . . . . . . . . . . . . 17

5.2 Modeling Execution semantics . . . . . . . . . . . . . . . . . . . . . . . 175.3 WSMX Mandatory Execution Semantics . . . . . . . . . . . . . . . . . 17

5.3.1 One-way Goal Execution . . . . . . . . . . . . . . . . . . . . . . 195.3.2 List of Web services Fulfilling a Given Goal . . . . . . . . . . . 225.3.3 Web Service Execution with Choreography . . . . . . . . . . . . 225.3.4 Invoke a Known Web service . . . . . . . . . . . . . . . . . . . . 25

5.4 Dynamic execution semantics . . . . . . . . . . . . . . . . . . . . . . . 25

6 Summary 27

A Appendix: Functional Component Interfaces 29

Deliverable 6.8 viii December 15, 2005

Deliverable 6.8

1 Introduction

This deliverable describes the architecture of an open-source execution environmentfor Semantic Web Service (SWS) called Web service Execution Environment (WSMX).WSMX is a comprehensive software framework for the discovery, selection, mediation,invocation and interoperation of Web services based on their semantic descriptions. Itis a reference implementation of the Web services Modeling Ontology (WSMO) [10]which defines a conceptual model for various aspects of Semantic Web services. Byimplementing an environment supporting service requester goals and goal driven dis-covery and invocation, WSMX enables service requesters and providers to come to-gether to achieve specific tasks even when these service requesters and providers arenot aware of each other in advance and may have significant differences in their dataand public behaviour models.

The work described in this deliverable was carried out jointly under the auspices ofthe DIP project funded by European Union’s IST programme (no. FP6 - 507483)and the DERI-Lıon project funded by Science Foundation Ireland (SFI grant no.SFI/02/CE1/I131) . The editors would like to thank the members of the WSMO,WSML, and WSMX working groups for their advice and input into this document.

1.1 Revision History

The first version of the architecture (M12) represented a high level approach identifyingthe main components required for a Semantic Web services architecture. As shown infigure 1.1, the second and the third versions of the architecture (M18 and M24) refinedthe architecture and focussed on the implementation of core functional components,in order to allow parallell prototype development. The fourth version (M30) will be afurther refinement, also taking account of components identified in the M12 document,but not yet developed (e.g. security). The final version of the DIP Architecture (M36)will include further refinements, which will be driven in particular by the ongoingimplementation of the case-study prototypes.

Figure 1.1: Revision History of the DIP Architecture

1

Deliverable 6.8

1.2 Motivation for the Architecture

In general where advances in computer and information science occur their uptake isgreatly assisted by having tools and frameworks that allow both software engineersand potential users to try out the new technology. WSMX aims to address both theseinterest groups. WSMX is provided as open-source software with a license intended tomake it as easy as possible for anyone to use the software for research or commercialpurposes. The open-source model is intended to encourage software developers todevelop functional components that exploit the extra knowledge made available inSemantic Web service descriptions. The WSMX architecture includes a mechanism toallow components e.g. discovery, to be developed by a third party and plugged in tothe WSMX framework with minimum requirements on the component’s developers.

From the perspective of potential users of Semantic Web services, WSMX providesa means to focus on maximising the benefits offered by being able to unambiguouslydescribe the functional and non-functional aspects of Web services without having toinvent a framework that knows how to handle those descriptions. WSMX provides theglue that brings the features promised by Semantic Web service technology to life. Inthe same way as middleware systems hide the detail of how they link autonomous het-erogeneous applications and systems together, a Semantic Web services environmentsuch as WSMX hides the detail and complexity of how the requester and provider ofWeb services can communicate with each other even where they do not know eachother in advance, speak different languages and expose different behaviours at theirservice interfaces. WSMX has the potential to offer a credible lightweight solution tothe problems faced in integrating applications and business systems across the Web.

There are no comparable architectures of execution frameworks for Web servicesbased on WSDL [4] descriptions. Specifications such as SOAP [9] and WSDL pro-vide powerful underlying tools which WSMX also uses. However the technologies fortraditional Web service discovery, composition and invocation are limited by the ab-sence of semantics which keeps much of the responsibility for linking Web servicestogether on the shoulders of the developers creating the services, the clients and, inthe case of composition, the designers of the workflow descriptions (e.g. using BPEL1 or Microsoft Biztalk 2).

1.3 Architecture Style

Software architectures are concerned with providing a high level description of a systemexplaining how the system, from a design perspective, addresses the problems it needsto solve. It takes account of the immediate and longer term requirements of the system,the existing technologies, new technologies that are coming on-stream and providesthe vision of how the system can be designed to achieve its goals. WSMX is a serviceoriented architecture (SOA) that adopts the two principles below taken from the Webservices Modelling Framework (WSMF) [7].

• Component decoupling

This is a principle of SOAs that emphasises the strong de-coupling of the variouscomponents that realize a software system. Making components self-contained

1http://www.oasis-open.org/committees/tc home.php?wg abbrev=wsbpel2http://www.microsoft.com/biztalk/default.mspx

2

Deliverable 6.8

supports a clear separation of concerns. Each component has a well definedfunctionality that can be utilized by other components.

• Standardization of external behaviour of components

The external interfaces of the components within the WSMX architecture arenot expected to change very often. By having well defined component interfacesand behaviour descriptions, we separate the implementation of the individualcomponents from the operation of the system as a whole. One of the long-term aims for WSMX is the support of dynamic execution semantics. Executionsemantics provide a formal description of the operation of a system. By dynamicexecution semantics, we mean that it should be possible to load a description ofhow WSMX should operate at runtime without having to restart the system. Forexample, a particular deployment of WSMX might never require data mediationbecause all data and processes available to the WSMX are homogeneous. In sucha case an execution semantics might be defined to ignore this component. Thiscan be relevant in systems where, for optimization reasons, even a pass-throughcall to a component where the component takes no action might be too timeconsuming.

We can also imagine scenarios where a deployment of WSMX is provided witha new component whose functionality was not considered in the overall WSMXdesign - it may be a specific requirement for that specific deployment. Thiscould lead to a requirement to extend the principle of standardized componentinterfaces in the future.

An initial set of components have been identified to make WSMX a reality andto provide the basic functionality required for executing SWS, namely discovery, me-diation, composition and invocation. By adopting the SOA style and by building ahighly flexible messaging infrastructure at its heart, WSMX is well placed to includenew components offering functionality as required. Indeed the possibility of addingnew components on the fly is a strong motivational factor in the ongoing design anddevelopment of WSMX.

So far we have talked about how WSMX looks on the inside but a second crucialaspect of WSMX is how it adapts to a distributed system model. In other words,by design WSMX is not intended as a standalone centralised system. Rather eachdeployment of WSMX is intended to be considered a node in a peer to peer (P2P)network. In this network, each node of WSMX will have the same lightweight eventdriven SOA at its core. Components will be plugged into any node of WSMX asrequired. Architecturally speaking, it is not necessary that any particular functionalcomponent be deployed on the same physical server as WSMX itself although, in theshort to mid-term, phase of development, this is the most likely design that will beimplemented. By viewing WSMX as a federation of nodes in a P2P network, additionalapproaches for service discovery and composition open up.

1.4 Architecture versus Design & Implementation

This deliverable provides both a high level conceptual architecture with an overviewof system components and their functionality, as well as come detail on more technical

3

Deliverable 6.8

aspects of the system design. Despite the inclusion of these more detailed techni-cal design aspects of WSMX , this document is not intended as a technical systemdocumentation or as a programmers reference. A detailed technical design documentdescribing the implementation aspects of WSMX will be included with the open sourcecode and documentation.

1.5 Organisation of the Document

The rest of this document is organised as follows. Section 2 provides a high levelview of the architecture both in terms of the functional components of WSMX andhow WSMX can operate in a P2P network. Section 3 provides a structural view ofWSMX with functional descriptions of the components currently defined for a WSMXnode and the definition of their interfaces. Section 4 describes the execution semanticswhile Section 5 discusses the behavioural view of WSMX - how the execution semantics(described in section 4) are reflected in the architecture. Section 6 provides a documentsummary.

4

Deliverable 6.8

2 Architecture Overview

This section is intended to provide an overview of two aspects of WSMX architecturebrought up in the introduction. The first is the idea that each deployment of WSMXis intended to be considered as a node in a P2P network. The second aspect we lookinto here is how the architecture of WSMX relates to the style of grouping systemfunctionality into layers where the interaction between layers is well defined.

2.1 A P2P Network of WSMX Nodes

In general a P2P network is one in which there is no central controlling entity. Eachnode in the network can communicate with any other node to co-operate together inperforming some task(s). The most well known P2P networks in recent years havebeen concerned with sharing video and audio files among a community of users. Eachuser has software enabling the P2P network on their machine and the addresses ofmachines in the network are available to all users of the P2P services. In reality, manynetworks advertised as P2P have a central node used for member management. Havinga central node means having a central point of failure. With WSMX we aim for a trueP2P system where the failure of any node in the network will not result in the entirenetwork breaking down.

P2P networks offer the advantage of allowing data and functionality to be split upacross the network while at the same time allowing peers to co-operate in achievingtasks requiring this data or functionality even though it may be distributed acrossdifferent locations. From the WSMX perspective, a typical use-case is for servicediscovery. A WSMX node receives a goal definition and uses the discovery componentat that node to search for matching services. The search takes place across Web servicedescriptions that are known to the service registry for that node. Where no match isfound, in a P2P network, the first WSMX node will forward the discovery request toanother WSMX node known to it. Again if the second node has no success, it willpossibly forward the request again to a third WSMX node and so on. We envisage thatthere will be a need to be policies in place to control the depth of recursion allowed.

As each WSMX node will be itself a Web service with a WSMO semantic descrip-tion, the invocation of a component in another WSMX node in the network will bethe same as for any other Web service invocation. Figure 2.1 shows how a simple P2PWSMX network with three nodes would look. In the figure each WSMX has a differentbackend system associated with it. For the discovery example mentioned earlier, eachWSMX node may have different service descriptions in its registry corresponding tospecific functionality offered by the associated backend application.

A P2P network architecture of WSMX nodes is a long term vision for WSMX. It islikely that the development of this aspect of WSMX will be driven by the requirementsof service discovery as Web services are situated all around the Internet and it isextremely unlikely that one single global registry of service descriptions will ever exist.

2.2 Overview of a single WSMX Node: SOA vs Layers

The most dominant style adopted by WSMX is that of a Service Oriented Architecture,a software system consisting of a set of collaborating software components (or services)

5

Deliverable 6.8

Figure 2.1: WSMX Nodes in a P2P Network[11]

with well defined interfaces that, by exchanging messages, together perform a set oftasks. It is not necessary for the components to necessarily live in the same addressspace, nor even in different address spaces on the same machine. They may very welllive on physically separated servers communicating over a network channel throughmultiple communication protocols.

Loose coupling of system components is the cornerstone of SOAs. This is reflectedin WSMX where independent pieces of functionality are provided in components. EachWSMX component provides a service that consists of a logical unit of system code,application code, persistency layers and a public interface to access the service. In shortanything that as a unit can carry out an application-level operation. Services are oftencharacterized by exactly these operations, which they provide to other components.Preferably these services have machine-processable meta-data descriptions.

The internal communication model for WSMX is based on event-based messagingwhich supports the decoupling of indiuvidual components. Communication is handledthrough the interfaces of the components; the implementation of each component is ofno concern to any other component needing to interact with it. The decoupled natureof WSMX is intended to allow for load-balancing and clustering of components forfuture optimization. The benefit of the approach is increased flexibility, better exten-sibility and improved reusability. Having an SOA facilitates, but does not guarantee,that these goals will be achieved but is a good basis from which to start.

6

Deliverable 6.8

3 Structural View

This section takes a more detailed look at the various components that have beendefined as part of the architecture for WSMX. The components discussed here arethose that are mandatory for the current version of WSMX. To enable WSMX toprovide an industrial-strength integration framework based on Semantic Web serviceswill require additional components. In particular, this would include components forsecurity, reliability, transactionality, negotiation, monitoring and so on.

This section is organised as follows. We first look at the overall structural view ofthe WSMX architecture. The following subsections describe the intended functionalityof each of the components. The purpose of these descriptions is to give a high-leveldescription of what each component provides along with a definition of the interfacethe component must support. Detailed specifications of the design and implementa-tion of individual components are the responsibility of the component owners withinthe technical work packages of DIP. Summary interface descriptions are included inAppendix B, expressed using the Java programming language, version 1.5. The DIPdeliverable, DIP D6.9 Revision of API, provides a comprehensive description of theAPI including full Java package names for the datatypes used.

3.1 Architecture Components

The WSMX architecture consists of a set of loosely-coupled components as presented inFigure 3.1. These can be plugged-in and plugged-out from the system. Consequently,components within WSMX can be added, replaced or removed while the system isrunning. Components themselves are pure Java components. Deploying a componentto WSMX simply involves copying the Java implementation to a designated folder.Likewise undeploying a component involves removing the Java implementation fromthe same designated folder.

Interfaces are defined for each component and are used as the means of inter-component interaction. Where necessary mockup components are implemented as partof WSMX until the development of the real components reaches the stage where theycan be meaningfully deployed. In this way there is an ongoing lifecycle of developmentand testing of components.

The architecture diagram of Figure 3.1 shows WSMX in the context of three relatedexternal systems. The first of the green boxes above WSMX represents front-endtool for visualising and managing the four top-level elements of WSMO (goals, Webservices, ontologies and mediators) and for creating mappings for data and processmediation. This is the Web Service Modelling Toolkit (WSMT)1 [8]. The second greenbox represent tools for managing and monitoring the components deployed to WSMXand the execution of tasks using these components. Finally, the third external relatedsystem is the Adapter Framework, shown between WSMX and the service requestersand providers on the left of the diagram. WSMX uses the conceptual model of WSMOto provide its internal data model. Communication between WSMX and the outsideworld is carried out using WSML messages. Where an external system wishing touse WSMX does not support WSML, an adaptor is required to translate between the

1http://sourceforge.net/projects/wsmt

7

Deliverable 6.8

Figure 3.1: WSMX Architecture

export format of the external system and WSMX e.g. between a proprietary XMLSchema and WSML.

3.1.1 Core Component

The Core Component is the central part of WSMX. It manages interaction between theother components through the use of component-wrappers that are automatically cre-ated when a component is deployed. The core can be thought of as passing a typedtoken to component-wrappers. The type of the token can be read by each wrapperand used to decide if the event represented by the token is intended for that wrapper’scomponent. If so, the wrapper makes an invocation on the Java API provided by thecomponent requesting the component to carry out its task.

Interface. There is no specific interface defined for the Core Component that canbe invoked by other components. Instead the core component is started as part ofthe start-up sequence for WSMX and runs as an independent process managing theevent-based communication mechanism of WSMX.

3.1.2 Resource Manager

The ResourceManager is the interface for WSMX persistent storage. The componentimplementing this interface is responsible for storing every data item WSMX uses. TheWSMO API provides a set of Java interfaces that can be used to represent the domainmodel defined by WSMO. WSMO4j2 provides both the API itself and a referenceimplementation but it is not a pre-requisite that implementations of the ResourceManager use WSMO4j.

Currently WSMX defines interfaces for six repositories. Four of these repositoriescorrespond to the top level concept of WSMO i.e. Web services, ontologies, goals,and mediators. The fifth repository is used by WSMX for non-WSMO data items e.g.events and messages. Finally, the sixth repository is used to register WSDL documentsand to link them to the corresponding WSMO descriptions. The WSDL descriptions

2http://wsmo4j.sourceforge.net/

8

Deliverable 6.8

are required to ground WSMO service descriptions to SOAP or SOAP/HTTP.

Interface. Tables A.1, A.2, A.3, A.4, A.5 and A.6 describe these interfaces.

3.1.3 Service Discovery

The Discovery component is concerned with finding Web service descriptions that matchthe goal specified by the service requester. It is not in the scope of this architecture doc-ument to specify how the discovery is implemented but the intent is that the WSMOdescription of the goal a user wishes to achieve (described in terms of a desired capa-bility with preconditions, assumptions, effects and postconditions) is matched to theWSMO description of Web services known to WSMX (described in terms of offeredcapabilities). The discovery component returns a (possibly empty) list of Web servicedescriptions.

Interface. Table A.7 describes the interface.

3.1.4 Non-functional Selector

The Non-functional Selector (labelled Selection Figure 3.1 is a component used to selectthe most suitable service from a list of matching services matched by discovery. Forexample, a service requester may define preference for the selection of the most suit-able discovered Web service. If discovery results in more than one service that satisfiesthe goal, the selection interface is used to chose one based on specified preferences pref-erences. Selection does not involve making an invocation on the service.

Interface. Table A.8 describes the interface.

3.1.5 Data Mediator

A WSMX DataMediator component has the role of reconciling the data heterogeneityproblems that can appear during discovery, composition, selection or invocation of Webservices. This interface is dedicated for the runtime phase of the mediation process.The run-time component implementing this interface has the role of retrieving fromstorage the already-created mappings, to transform them into rules, and finally toexecute them against the specified incoming instances (input) in order to obtain thetarget instances (output). Since the mappings represent the connection point betweenthe two sub-components (design-time and run-time) one of the dependencies for therun-time component relates to the mapping storage level. Another crucial dependencyrelates to the reasoning system used for executing the rules in the final stage of themediation process.

Interface. Table A.10 describes the interface.

3.1.6 Process Mediator

A WSMX Process Mediator has the role of reconciling the public process heterogeneitythat can appear during the invocation of Web services. That is, ensuring that thepublic processes of the invoker and the invoked Web service match. Since both the

9

Deliverable 6.8

invoker and the Web service publish their public processes as choreographies, andthe public processes are executed by sending/receiving messages, the process media-tion component will deal with reconciliation of message exchange patterns based onchoreography.

The current version of the Process Mediator takes as input, the choreographies ofthe requester and provider, the entities that are required to be sent from one to theother for a particular message exchange and the direction of communication (requester-to-provider or provider-to-requester). The Process Mediator then identifies whereexactly the message should be sent and how the data provided should be used.

The current version of the Process Mediator is intended to be invoked by the Chore-ography Engine. This strong dependency will be reviewed for the future versions ofthe architecture.

Interface. Table A.11 describes the interface.

3.1.7 CommunicationManager

The CommunicationManager is responsible for dealing with the protocols for sending andreceiving messages to and from WSMX. Its external behaviour is accessed throughthe Invoker and Receiver interfaces. The WSMX Receiver interface expects the contentsof all messages it receives to be expressed in WSML. Each WSML messages mayrepresent a goal to be achieved or be a message corresponding to a choreographyor orchestration instance that already exists. The Communication Manager acceptsthe message and handles any transport and security protocols used by the messagesender. The execution semantics of WSMX determine how the WSML message shouldbe handled based on the defined execution semantics of the system.

The Invoker is used by the execution semantics of WSMX when a Web service needsto be invoked. The invoker receives the WSMO description of the service, the endpointfor the invocation and the data that that particular endpoint expects to receive (thinkof endpoint here as operatons in a WSDL service description). It is responsible formaking the actual invocation of an operation on a service. In the majority of existingWeb service implementations, this means ensuring that the semantic description ofboth the data and the behaviour of the Web service are grounded to the correspondingWSDL descriptions. In this version of the architecture, grounding is handled by theAdapter Framework outside WSMX. This implies that any Web service not usingWSML as its data exchange language will require an adapter in order to be invokedfrom the architecture. This will be reviewed with respect to the case-study prototypesfor the next version of this deliverable.

The external behaviour of the system is defined in the EntryPoint interface. In thecontext of WSMX, entry points are the collection of methods that WSMX exposes asthe only way to interact with it. The intent is that the EntryPoint interface be imple-mented by any WSMO-compliant Semantic Web services environments to facilitateseamless run-time integration of these systems.

Interface. Table A.12 describes the Invoker interface and table A.13 describes theReceiver interface.

10

Deliverable 6.8

3.1.8 Choreography Engine

A WSMO Choreography defines how to interact with a Web service in terms of exchangingmessages the so-called communication patterns.

After discovering a Web service description, one has to know the observable behav-iour of the Web Service in order to achieve the desired functionality. Choreography andOrchestration comprise part of the interface definition of a WSMO service description.Choreography describes how to communicate with the service such that the service willprovide its capability. Orchestration describes how the service collaborates with otherWSMO services to achieve its capability. The choreography engine is responsible forusing the choreography descriptions of both the service requester and provider to drivethe conversation between them. It is the responsibility of the choreography engine tomaintain the state of a conversation and to to take the correct action when that stateis updated. For example, the update of the state of a choreography instance may bethe result of a message received from a service provider. The consequent action, asdescribed in the choreography instance, could be to forward the unchanged messageto the service requester.

Interface. Table A.14 describes the Choreography component interface.

3.1.9 Parser

The Parser checks if the syntax of received WSML descriptions is correct. Only if cor-rect, the descriptions are parsed into WSMO4j data objects used as the internal datarepresentation for WSMO.

Interface. Table A.15 describes the Parser component interface.

3.1.10 Orchestration

The functionality and interface for the WSMX Orchestration are not defined in thisversion of the architecture.

3.1.11 Web Service Modelling Toolkit

The Web Services Modeling Toolkit (WSMT) provides user interface tools for WSMXmanagement and monitoring including a WSML editor. The architecture and designof WSMT is described in the WSMX deliverable D9.1. Its current documentation isavailable at [8].

3.1.12 Reasoner

The WSML Reasoner is required by several other components in the architecture, no-tably discovery and both the process and data mediator components. The current draftrelease allows for hierarchical queries on concepts, such as requests for subconcepts orsuperconcepts, entailment and, some support for queries against the knowledge baseavailable to the reasoner. Interface. Tables A.16 and A.17 describe the Reasoner

component interface.

11

Deliverable 6.8

3.1.13 Adapter Framework

The adapter framework on the left of Figure 3.1 is not part of the internal architecturefor WSMX but is essential for supporting external applications, that do not directlysupport WSML, but that may wish to use WSMX for goal-based Web service execu-tion. For example, an adapter may be required to take the output of an SAP ERPback-end system and transform it into a WSML message that can be passed to WSMXfor processing. The adapter, in this case, would also be used to transform the WSMLmessage, received from WSMX, back into a format supported by the ERP system (aWSDL endpoint, in most cases).

3.1.14 Security

The requirement for a security component has been recognised since the first draft ofthe DIP architecture in M12. This component will be addressed in the next release ofthe DIP architecture.

12

Deliverable 6.8

4 Behavioural View

WSMX is a Service Oriented Architecture (SOA), which means that it is a softwaresystem consisting of a set of collaborating software components with well definedinterfaces that together perform a task. These components do not necessarily live in thesame address space, not even in different address spaces on the same machine, insteadthey may very well live on different continents communicating over a network channelthrough multiple protocol stacks. This situation creates its own unique demands,born out of latency, memory access, concurrency and failure of subsystems, which thearchitecture must be able to cope with. All these aspects are going to be addressedin subsequent steps during designing and implementing reference implementation ofWSMX.

SOAs differentiate themselves from other distributed systems through the conceptof loose coupling brought to its extremes. Strong de-coupling of the various compo-nents that realize an e-commerce application is one of the major features of WSMO. InWSMX conceptually independent pieces of functionality has been grouped in compo-nents. Each of the WSMX components provides services - a single of which is a logicalunit of system code, application code, persistency layers, in short anything that as aunit can carry out an application-level operation. Services are often characterized byexactly these operations, which they provide to other components. Preferably serviceshave descriptions in machine-processable meta-data. The architecture described inthis document includes an internal communication mechanism for an SOA based onan events-based mechanism. However one can also envision an infrastructure coordi-nated without events.

In WSMX, communication between components takes place through events. Itenables the good practice of implementation-hiding, in which the implementation ofa service should be of no concern to the client of the service. All of this togethershould result in increased flexibility, better extensibility and dramatically improvedreusability. In particular it facilitates the addition, upgrade or removal of functionalcomponents while at the same time maintaining the stability of the system. Situationswhere new components are added to WSMX that were not considered during the initialdesign are examples of where there would be benefits for a flexible, dynamic mechanismof defining how the system operates. This is what we mean when we discuss the topicof dynamic execution semantics for WSMX.

4.1 Separating Component Behaviour from Implementation

Execution semantics provide a formal description of the operation of a system. Havingdynamic execution semantics extends this idea further to mean that the behaviour of asystem does not need to be only defined at design time. By separating the descriptionof the behaviour of WSMX from the implementation of the functional components,we aim to allow the execution semantics of the system to be flexible and evolve overthe lifetime of the system itself. This section aims to provide some background tohow execution semantics are applied to WSMX. Section 5.1 describes the executionsemantics themselves.

As described by [12] in the context of WSMX, there was an initial focus on mod-eling the execution semantics of WSMX so that software developers could understandthe behaviour of the system and to enable model-driven execution of the system’s

13

Deliverable 6.8

components. Describing execution semantics explicitly oustide the component imple-mentation provided a clean way of separating the functionality of components fromthe the operational semantics that WSMX could support. One benefit is that it assistsin managing the lifecycle of components. They can be added, removed and updatedin the WSMX without having to recode or redesign the software.

The initial version of WSMX included only one possible execution semantic whichwas hard-coded into components of the system. This approach very quickly showedweaknesses of WSMX design revealed by new requirements and use cases providedby potential users of the system. The initial architecture approach was refined toaccommodate a mechanism to incorporate new components and methods enablingadding and removing any new formal definitions of execution semantics describingoperational behavior of the system without the need to recompile the whole platformany time such new execution semantic becomes available. The first step to enable newexecution semantics in the system has been the design of execution semantics (or inSOA terminology - ”business processes”) - a group of business activities undertakenby a management component in pursuit of a common goal.

Initially Petri nets [1] were used to model the execution semantics of WSMX be-cause of their well-defined formal semantics. However, they proved difficult for manyto interpret. In this version, we use UML Activity Diagrams and rely on the formalismdefined for them in the work of [6].

Each execution semantics can be considered to represent a process. Whatever toolis used for the definition of the process must make it possible to verify certain propertiesof the model; it must check some simple properties such as syntactical correctness,unreachable states or unsatisfiable conditions. While we define the process, we madean abstract declaration that services will be requested by using services interfaces (seefigure 4.1), but actually we do not bind the process to the concrete service, which isgoing to be invoked during run time.

Figure 4.1: Sample Abstract Execution Semantics Definition

14

Deliverable 6.8

Apart from process definition, we recognized another requirement to enable dy-namic execution semantics - a runtime ability to plug-in and plug-out components. InWSMX we enable reconfiguration, management, and monitoring of available softwarecomponents. We maintain that system must be capable to host deployable componentsand to reconfigure them during initialization and during runtime.

The persistent configuration support is responsible for loading the various compo-nents into memory, for which sophisticated and decentralized configuration systemsprovide the necessary flexibility. Configuration of the individual components can ei-ther be deliver as a descriptor file or as code annotations. Having abstract processdefinition and components installed in the system, wrappers are generated for compo-nents (see figure 4.2) when the components are deployed. The purpose of the wrapperis to separate components from transport layer for events.

WSMX is an event-based system, where each component has an associated wrap-per that exchanges events with the WSMX Core. Component wrappers are generatedautomatically when a component is deployed to WSMX. Wrappers exhibit an asyn-chronous form of communication. One wrapper raises an event with some messagecontent and another wrapper can at some point in time consume this event and reactupon it. Developers of individual components do not need to be concerned about howthis happens. Additionally, where one component needs to invoke another, they askthe WSMX core to give them an instance of the desirted component and use this as ifit were an instance of a local Java class. The components never need to be explicitlyaware of the wrappers and never invoke them directly.

Figure 4.2: Process, its wrappers and context

Figure 4.3 depicts how components are decoupled from the process (describedin the execution semantics). The deployment of any new execution semantics willremain transparent to components. Based on an execution semantics definition, these

15

Deliverable 6.8

wrappers will only be able to consume and produce particular types of events. In arunning system dynamic execution semantics are achieved by mapping abstract systembehavior into real event infrastructure of the system.

Figure 4.3: Event SOA for WSMX

16

Deliverable 6.8

5 WSMX Execution Semantics

5.1 Introduction

In a nutshell, execution semantics specifies system behavior in a formal way whichmakes it unambiguous and enables its simulation and analysis prior to the execution.WSMX is based on an event-driven architecture composed of loosely coupled compo-nents which facilitates the creation of various execution semantics for a system sincethe activities of the components are stimulated by events as they occur and there areno fixed bindings between components. Components can create or consume events butthey cannot invoke each other directly (strictly speaking, only the core component caninteract with other components).

5.1.1 Purpose of this section

In this section, we define the execution semantics of WSMX. We briefly list two differ-ent modelling techniques for execution semantics in the existing literature and chooseone as appropriate. Using this technique we present the execution semantics of fourmandatory WSMX behaviours (each WSMX instance has to provide them), so thatits operational behavior is formally and unambiguously specified. We are aware thatthere will be a demand for defining execution semantics for WSMX by third partiestailored to their needs and this is addressed in a separate section.

Section 5.2 lists two methods that can be used for modeling execution semantics.Section 5.3 provides a detailed description of four mandatory execution semantics thathave to be provided with each instance of WSMX, and Section 5.4 gives a descriptionof dynamic execution semantics that can be plugged into WSMX at runtime.

5.2 Modeling Execution semantics

Several methods exist to model software behaviour. Some of them model systembehaviour in a general way like UML diagrams, other impose more formal requirementson a model like Petri-net based methods. These methods have different characteristics:some are more expressive than others, some are more suited for a certain problemdomain than others. Some methods are graphical like UML or Petri nets, some arebased on logic terms like fuzzy logic; some methods have tool support for modelling,for verification, for simulation or for automatic code generation and others do not.

We impose two major requirements on the methodology utilized for model- lingWSMX behaviour. Firstly it has to use understandable and straightforward graphicalnotation, secondly it has to be unambiguous. These two requirements are met by UMLActivity Diagrams with the semantics defined by Eshuis in [6].

5.3 WSMX Mandatory Execution Semantics

Four execution semantics are defined that we consider mandatory for the basic oper-ation of any running instance of WSMX. These are described in further subsectionsof this document. The WSML message content determines which of the predefined

17

Deliverable 6.8

execution semantics will be selected. Since WSMX is an event driven system, its be-haviour is specified by the order of events. Event exchange is conducted via TupleSpace[2] which provides persistent shared space enabling seamless interaction betweencomponents without direct events exchange between them. In the future WSMX willuse a Triple Space[3] where exchanged entities are RDF triples what provide far moreelaborate querying capabilities.

Interaction is carried out by exploiting a publish-subscribe mechanism. Executionsemantics are started according to selected entry-point method (i.e. it initiates ex-change of events via Tuple Space). WSMX works with the WSMO conceptual modeland with the wsmo4j data model that is compliant with the WSMO specification v1.0.

The WSMLDocument Java class is a conatainer for any valid WSML document.A valid WSML document is one conatining any combination of WSML expressionsthat can be validated by a tool such as the Web services Modelling Toolkit (WSMT)1.A class definition of WSMLDocument is included in the forthcoming DIP deliverable,D6.9 DIP Architecture API.

Figure 5.1: General entry point selection path

Each WSMX execution semantics follows the path depicted on figure 5.1. Usingan adapter to communicate with WSMX is not necessary if the service requestorcan understand WSML. In such a case, the service requestor itself has to implementreceive(WSMLMessage, Context) method in order to receive asynchronous WSML messagesfrom WSMX.

The execution semantics of WSMX follows the component-based paradigm, takingadvantage of various loose coupled WSMX components as depicted on Figure 3.1.This means that the execution semantics of the complete system treats componentsas ’black-boxes’ - we do not model decisions that take place inside those components.For a complete model of the behaviour of the system, the internal behaviour of thecomponents needs to be taken into the account. Modelling the execution semanticsof the individual components is, however, the responsibility of the component owners.

1http://sourceforge.net/projects/wsmt

18

Deliverable 6.8

The following subsections will present the execution semantics of WSMX in moredetail.

5.3.1 One-way Goal Execution

The following entry-point initiates this system behavior.achieveGoal(WSMLDocument):Context

The service requestor, which expects WSMX to discover and invoke a SemanticWeb service without exchanging additional messages can use this entry-point by pro-viding the goal description, and optionally, the input data required to achieve thegoal, both expressed in terms WSML in a single input parameter of type WSMLDoc-ument. It is intended that it should be possible to specify preferences (again, in termsof WSML) that could be used by the selection component. However, preferences arenot yet specified in the conceptual model provided by WSMO and are not part ofthe architecture for this version. The returned Context is a unique identifier for theconversation between the goal requester and WSMX.

This execution semantic assumes that the service requestor provides all the datarequired to achieve its goal in the parameter, WSMLDocument. The intention isthat this execution semantic is asynchronous with the assumption that to receive anyreturn data, the invoker of the entry-point must provide a call-back entry point. Thiscall-back must be described in their choreography.

In Figure 5.2 the definition of the system is given. The behaviour of the discoverycomponent is specified in more detail in Figure 5.3.

First, a list of SWS is created by combining internally known Semantic Web ser-vices with the ones from external repositories. From this list, one service is pickedat a time, and an attempt at matching is made. If necessary, data mediation is re-quested (denoted by the arc ’need DM’) when the ontology of goal and SWS beingmatched differ. If this data mediation succeeds, the matching can continue. If thedata mediation fails, the next SWS is taken from the lsit (if mediation cannot resolvea mismatch between the goal and the SWS, the SWS is discarded as being suitablefor the goal). The discovery process continues (with or without data mediation) untila list of matching Semantic Web services is completed. The list of discovered servicedescriptions is stored by WSMX along with the Context associated with the instanceof the execution semantics.

Where multiple services are discovered, the selection component selects the Se-mantic Web service out of the list returned by discovery component that fits best (theselection mechanism is not defined here). Finally, the Invoker component makes aninvocation on the selected Semantic Web service.

The process of discovery depicted on Figure 5.3 includes Matching. The matchingis (from the viewpoint of the WSMX system) a nondeterministic choice, either amatching is found, or an error occurs or a data mediation is needed; this choice ismade not by the WSMX system, but by the matching process that infers on user’sgoal and semantic description of a Web service. The same pattern is repeated formodelling the other components, all of whose outcomes are nondeterministic exclusiveORs (from the viewpoint of WSMX). Both the Data Mediation component and theselection component can either fail or succeed.

19

Deliverable 6.8

One−way goal execution

Error

execution completed

GOAL

_

Data Mediator

Selection

Invoker

Discovery ok

need DM

msg to send

DM error

Selection error

Invoker errorInvocation ok

Discovery_ Discovery error

Choreography Engine

_

selected SWS

_

CE error

DM ok

Created with Poseidon for UML Community Edition. Not for Commercial Use.

Figure 5.2: Overview of one-way goal execution

20

Deliverable 6.8

Discovery inside WSMX

Initial state

list of WS

internal WS repository external WS repositories

->list of WS

internal WS repository-> external WS repositories->

matching

add WS to the list

discovery finished

list of discovered WSs

WS matched

matching->

data mediationneed data mediationmatching error

list of WS-> no more WS on the list

Initial state->

GOAL

goal

data mediation error

data mediation ok

need more WS

picked WS->

Figure 5.3: Discovery inside WSMX

21

Deliverable 6.8

The Invoker component is responsible for sending outgoing messages by makinga service invocation. The data content of all messages coming into or going out ofWSMX are expressed in WSML. Where the service provider or the service requesterdoes not support WSML, an adapter is required as an intermediary to transformthe message into the approproate syntax. The unique Context for each conversationbetween requester and provider is included in all messages.

5.3.2 List of Web services Fulfilling a Given Goal

The following entry-point initiates the creation of the list.getWebServices(WSMLDocument):Context

The UML activity diagram for discovery is shown in figure 5.3. A list of SemanticWeb services is created by the discovery component for a given goal and instance ofontology (and possibly) preferences. Only the discovery and data mediation compo-nents carry out their tasks. Each Semantic Web service on the list is already mediatedto the requestor ontology if necessary and has a choreography. Since the returnedlist of Semantic Web services is specified in the same ontology as the requestor’s, therequestor can understand them and make a choice which one should be executed. Ex-change message patterns are specified by choreography, thus both parties expose theirexpectation with regard to the exchanged messages and their order. The Context re-turned by the method representing this entry-point acts as a handle to the converstionbetween the invoker of the entry-point and WSMX.

The intention is that this execution semantic is asynchronous and the assumptionis made that to receive the discovered Web services, the invoker of the entry-pointmust provide a call-back entry point to do this. This call-back must be described intheir choreography.

This behaviour is quite relevant when a decision about which Semantic Web serviceto execute has to be made outside WSMX system. The decision could be taken manu-ally or by some Semantic Web service evaluation program. The process of generatinga list of Semantic Web services that meet a given goal is depicted in Figure 5.4. Thediscovery component runs in loop until the desired number of Semantic Web servicesis collected or until there are no more of them to discover. Finally, list of discoveredSemantic Web services is sent to the service requestor.

5.3.3 Web Service Execution with Choreography

The following entry-point initiates this execution semantic:invokeWebService(WSMLDocument, Context):Context

Once the service requestor knows which Semantic Web service he wants to use,back-and-forth conversation has to be carried out with the WSMX system to provide allthe necessary data to make the execution of this Semantic Web Service feasible. Thisexecution semantic involves process mediation component [5] that mitigates differencesin the choreographies of the interacting parties. By giving fragments of ontologyinstances (e.g. business documents such as Catalogue Items or Purchase Orders in agiven ontology) it provides all the data required by the Semantic Web service.

22

Deliverable 6.8

List of Semantic Web Services fulfilling given Goal

execution completed

Discovery

_

Data Mediationneed DM

_

DM ok DM error

Discovery ok/ list of SWS

error

Discovery error

Created with Poseidon for UML Community Edition. Not for Commercial Use.Figure 5.4: Goal-based Discovery

23

Deliverable 6.8

Execution with choreography

Choreography Engine

execution completed

Process Mediation

init

Error

Invoker

Data Mediation

[ ]/ _

PM error PM ok

[ ]/

ontology instance/ context

DM error

no msg to send/completed

msg to send

msg send

DM ok

need DM

sending error

[ ]/

_

need PM

Created with Poseidon for UML Community Edition. Not for Commercial Use.

Figure 5.5: Overview of Web service execution with choreography

24

Deliverable 6.8

As presented on Figure 5.5, the conversation between the given parties takes placeaccording to service requestor’s and SWS’s choreography. Context previously ob-tained from Register communication with WSMX execution semantic is sent alongwith WSMLDocument as the parameters of this execution semantics and must be pre-served by both interacting parties. This approach facilitates keeping track of ongoingconversation status and refers to additional data required to make communication be-tween the two parties feasible (e.g. data related to process mediation like previouslyreceived messages or status of internally initialized choreographies).

Next, process mediation is invoked. Process mediation mitigates a differences be-tween choreographies of interacting parties (in this case requestor’s and service’s). Forinstance, it can change sequence of messages, generate some dummy messages, pre-serve some messages to send them later on or drop some of received messages. Ingeneral, its goal is to enable communication between parties despite their different ex-pectations of communication patterns (i.e. choreographies). In each invocation of theProcess Mediator, a Context is used to determine the step being currently processedand to update the choreographies of the interacting parties. Process Mediation canalso require some additional data preserved in the Context, such as previously receivedmessages.

Process mediation requires, as input, instances of choreographies of the interactingparties as well as instance data. If necessary the data mediation component is re-quested when differences between ontologies occur. The ready message and recipientaddress is forwarded to the Invoker component. Next, a message is sent asynchro-nously. The response message is received by the Receiver component and then it isagain passed on to the process mediation.

5.3.4 Invoke a Known Web service

The following entry-point initiates this execution semantic:invokeWebService(WSMLDocument):Context

This entry-point in used when the Web service to be invoked is already known tothe service requester without using WSMX as a discovery agent. In this case thereis no Context before invokeWebService(WSMLDocument) is called. The WSMLDocumentparameter contains all the information required by WSMX to make the invocation. Ata minimum, this includes an identifier for the Web service. Instance data may also beincluded in the document if required. A unique Context is created for the conversationand is returned to the entity calling the entry point.

5.4 Dynamic execution semantics

Since WSMX consists of loosely-coupled components, one could easily imagine otherexecution semantics that will appear in the future. Thanks to its architecture WSMXcan be easily enhanced with new components. Components can be dynamicallyplugged in to or plugged out of the system. New versions of components can replaceoutdated ones in this manner. Components can be deployed on remote machines andstill be able to subscribe to WSMX events through Tuple Space and to process them.This gives the designer a flexible way to create new execution semantics.

25

Deliverable 6.8

The new executions semantic specifications need not be restricted to one language.They even need not be based on one paradigm (in this deliverable we consider onlycolour Petri net based representation). In order to create interoperable WSMX sys-tems, WSMX should take advantage of efforts like M3PE 2 or WFMC3 with its XPDLinitiative. These efforts are concerned with creating interoperable workflow languagethat other languages would be able to map to. Their ultimate goal is to be able toexecute any workflow specification within one engine.

2http://www.m3pe.org/3http://www.wfmc.org/

26

Deliverable 6.8

6 Summary

In this document we described the architecture of the current version of WSMX. Inparticular we focused on how WSMX has evolved as a Service Oriented Architecture(SOA) from earlier versions. The adoption of the principles of component decouplingand standardized component interface definitions provide WSMX with flexibility asthe implementations of functional components mature and components are removedor added.

The document described the structural view of the current WSMX components,listing and describing their publicly observable interfaces. In the section on dynamicexecution semantics we discussed the benefits of separating the functional and be-havioural description of a system. By adopting an architecture where the executionsemantics can be updated or changed on-the-fly, we are aiming at providing as flexiblea system as possible as well as attempting to future-proof the design. We can not pre-dict all possible components and combinations of components that could be useful ina WSMX deployment but we aim to support the plug-in and out of such componentsas they become available and are required.

27

Deliverable 6.8

References

[1] W. Aalst, K. Hee, and G. Houben. Modelling workflow management systems withhigh-level Petri nets. In G. Michelis, C. Ellis, and G. Memmi, editors, Proceedings

of the second Workshop on Computer-Supported Cooperative Work, Petri nets and

related formalisms, pages 31–50, 1994.

[2] G. Alonso, D. Agrawal, A. E. Abbadi, C. Mohan, R. Gnthr, and M. Kamath.Exotica/FMQM: A Persistent Message-Based Architecture. Proceedings of IFIP

Working Conference on Info Sys for Decentralized Organizations, Trondheim, Au-gust 1995.

[3] C. Bussler. A Minimal Triple Space Computing Architecture. Technical report,Digital Enterprise Research Institute, April 2005.

[4] R. Chinnici, M. Gudgin, J.-J. Moreaum, S. Weerawarana, and J. Schlim-mer. Web Services Description Language (WSDL) Version 1.2. World WideWeb Consortium, March 2003. Available from http://www.w3.org/TR/2004/

WD-wsdl20-20040326/,.

[5] E. Cimpian and A. Mocan. Process Mediation in WSMX. WSMX Working Draftv0.2, 2005.

[6] R. Eshuis and R. Wieringa. Comparing Petri Net and Activity Diagram Variantsfor Workflow Modelling: A Quest for Reactive Petri Nets. Lecture Notes in

Computer Science, 2472:321–351, 2003.

[7] D. Fensel and C. Bussler. The Web Services Modeling Framework (WSMF).Electronic Commerce Research and Applications, 1(2):113–137, 2002.

[8] M. Kerrigan. D9.1v0.2 The Web Services Modelling Toolkit (WSMT). Technicalreport, 2005. http://www.wsmo.org/TR/d9/d9.1/v0.2/.

[9] Nilo Mitra (Ed.). SOAP Version 1.2 Part 0: Primer. World Wide Web Consor-tium, June 2003. Available from http://www.w3.org/TR/soap12-part0/,.

[10] D. Roman, H. Lausen, and U. Keller. Web Service Modeling Ontology Standard.WSMO Working Draft v02, 2004.

[11] L. Vasiliu, M. Moran, C. Bussler, and D. Roman. WSMO in DIP. Technicalreport, June 2004. Available at http://www.wsmo.org/2004/d19/d19.1/v0.1/

20040621/.

[12] J. M. Wing. A specifier’s introduction to formal methods. IEEE Computer,23(9):8–26, Sept. 1990.

28

Deliverable 6.8

A Appendix: Functional Component Interfaces

This appendix contains a set of tables that provide the interface for the functionalcomponents of the architecture. The interfaces describe the method names, as well asinput and output parameters. All inputs and outputs are data primitives (int, stringetc.) or are taken from the WSMO4j1 object model. The full API for the architectureis publishes as JavaDoc HTML pages in the DIP public deliverable D6.9.

Table A.1: Goal Resource Manager InterfacesMethod Summary

void storeGoal(Goal goal)

This method takes aWSMO4J Goal object and stores itwithin the Resource Manager

void removeGoal(Goal goal)

This method removes aWSMO4J Goal object from the Re-source Manager

Set<Goal> retrieveGoals()

Get all goal descriptions fromthe repository

Set<Goal> retrieveGoals(Namespace namespace)

Get all goal descriptions forthe specified namespace

Goal retrieveGoal(Identifier identifier)

Get the goal for the specidiedidentifier

Set<Identifier> getGoalIdentifiers()

Get all goal identifiers fromthe repository

Set<Identifier> getGoalIdentifiers(Namespace namespace)

Get all goal identifiers fromthe repository for a particularnamspace

boolean containsGoal(Identifier identifier)

Determine if the repositorycontains the goal corresponding tothe identifier

1http://wsmo4j.sourceforge.net/

29

Deliverable 6.8

Table A.2: Mediator Resource Manager InterfaceMethod Summary

boolean containsMediator(Identifier identifier)

Determine if the repositorycontains the mediator correspondingto the identifier

Set<Identifier> getMediatorIdentifiers()

Get all mediator identifiersfrom the repository

Set<Identifier> getMediatorIdentifiers(Namespace

namespace)

Gets a set of mediator identi-fiers from the repository for the spec-ified namespace

Set<Namespace> getMediatorNamespaces()

Gets all namespaces contain-ing mediator descriptions

void removeMediator(Mediator mediator)

Remove a mediator from therepository

Mediator retrieveMediator(Identifier identifier)

Returns a mediator objectcorresponding to the identifier fromthe repository

Set<Mediator> retrieveMediators()

Returns a set of all mediatorobjects from the repository

Set<Mediator> retrieveMediators(Namepace namespace)

Returns a set of all mediatorobjects for the specified namespace

void storeMediator(Mediator mediator)

Save a mediator to the repos-itory

30

Deliverable 6.8

Table A.3: Web Service Resource Manager InterfaceMethod Summary

boolean containsWebService(Identifier identifier)

Determine if the repository containsthe WebService corresponding to the iden-tifier

Set<Identifier> getWebServiceIdentifiers()

Get all WebService identifiers fromthe repository

Set<Identifier> getWebServiceIdentifiers(Namespace namespace)

Gets the set of WebService iden-tifiers corresponding to a particularnamespace from the repository

Set<Namespace> getWebServiceNamespaces()

Gets all namespaces containing Webservice descriptions

void removeWebService(WebService webService)

Remove a WebService from therepository

WebService retrieveWebService(Identifier identifier)

Returns a WebService object corre-sponding to the identifier from the repos-itory

Set<WebService> retrieveAllWebServices()

Returns a set of all WebService ob-jects from the repository

Set<WebService> retrieveAllWebServices(Namespace namespace)

Returns a set of all WebService ob-jects for the specified namespace

void storeWebService(WebService webService)

Save a WebService to the repository

31

Deliverable 6.8

Table A.4: Ontology Resource Manager InterfaceMethod Summary

boolean containsOntology(Identifier identifier)

Determine if the repository containsthe Ontology corresponding to the identi-fier

Set<Identifier> getOntologyIdentifiers()

Get all Ontology identifiers from therepository

Set<Identifier> getOntologyIdentifiers(Namespace namespace)

Gets the set of Ontology identifierscorresponding to a particular namespacefrom the repository

Set<Namespace> getOntologyNamespaces()

Gets all namespaces containing on-tology descriptions

void removeOntology(Ontology ontology)

Remove an Ontology from therepository

Ontology retrieveOntology(Identifier identifier)

Returns a Ontology object corre-sponding to the identifier from the repos-itory

Set<Ontology> retrieveAllOntologys()

Returns a set of all Ontology objectsfrom the repository

Set<Ontology> retrieveOntologys(Namespace namespace)

Returns a set of all Ontology objectsfrom the repository

void storeOntology(Ontology ontology)

Save a Ontology to the repository

32

Deliverable 6.8

Table A.5: Non WMSMO Resource Manager InterfaceMethod Summary

Set<Context > getContexts()

Get all contexts in the repos-itory. Contexts are used to identifyinstances of execution semantics.

Set<MessageId> getMessageIds(Context context)

Get all message identifiers fora specific context.

Map <Context, Set <MessageId>> getMessageIds(Set <Object>searchTerms,

boolean conjunctive)

Gets a map of contexts tosets of message ids where the mapmatches the searchterms joined us-ing the conjunctive in the input pa-rameters

Set <MessageID> getMessageIds(Context context,

Set<Object>searchTerms, boolean conjunc-

tive)

Gets a set of MessageIdsfor messages in the specified con-text where the set matches thesearchterms joined using the con-junctive in the input parameters

void saveMessage(Context Context, MessageId

messageId, String message)

Save a message received orbeing sent from WSMX. The mes-sageId is generated by the executionsemantics.

Map<MessageId, String> load(Context context)

Gets a map of messageIds tothe associated messages (as strings)corresponding to the specified con-text

String load(Context context, MessageId messageId)

Gets the string content of themessage corresponding to the speci-fied context and the messageId

Map<Context, Map<MessageId, String>> loadAll()

Get a map containing all mes-sageIds and the corresponding mes-sage strings for the specified context

33

Deliverable 6.8

Table A.6: WSDL Resource Manager InterfaceMethod Summary

void registerWSDL(WebService webService, WS-

DLDocument wsdlDocument)

Register a WebService with anassociated WSDL document

WSDLDocument getWSDL(WebService webService)

Get the WSDL document forthe specified Webservice

void deregisterWSDL(WebService webService)

Deregister the WSDL docu-ment from the specified WebService

Table A.7: Service Discovery InterfaceMethod Summary

List <WebService> discover(Goal goal)

Calls discovery providing agoal and expects result as a (possi-bly empty) list of WebServices

Table A.8: Selection InterfaceMethod Summary

WebSer-

vice

select(List<WebService> webServices)

Select the Web service descrip-tion that best fits the specified Goaldescription

Table A.9: Negotiation InterfaceMethod Summary

List<WebService> select(Collection<WebService> services,

Preferences preferences)

Negottiate with Web servicesto find Web services that can delivera specific product or service

34

Deliverable 6.8

Table A.10: Data Mediator InterfaceMethod Summary

Map<Entity,

List<Entity>>

mediateData(Ontology sourceOntology, On-

tology targetOntology, Set<Entity> data

Transforms a set of source on-tology instances into instances of thetarget ontology.

List<Entity> mediate(Ontology sourceOntology, Ontology

targetOntology, Entity data)

Transforms a give source on-tology instance into instances of thetarget ontology.

35

Deliverable 6.8

Table A.11: Process Mediator InterfaceMethod Summary

Map<<Identifier>,

List<Entity>>

generate(Identifier sourceOntology, Identifier

targetOntology, Set<Entity> data, int invo-

cationDirection)

Generates a map containingthe identifier of the transition rulein the source or target choreopg-raphy instance that should receivethe next message along with a listof entities that go to make up thatmessage. The input is the identi-fiers of the source and target on-tologies, the entities available for themessage, and the the direction ofthe message (source-target or target-source). This method has not beenimplemented in the current ProcessMediator.

Map<<Identifier>,

List<Entity>>

generate(Ontology sourceOntology, Ontol-

ogy targetOntology, Set<Entity> data, int

invocationDirection)

Generates a map containingthe identifier of the transition rulein the source or target choreopgra-phy instance that should receive thenext message along with a list of en-tities that go to make up that mes-sage. The difference in inputs, withthe method above, is the provisionof full ontologies rather than iden-tifiers. This method has not beenimplemented in the current ProcessMediator.

Map<<Identifier>,

List<Entity>>

generate(Choreography sourceChoreogra-

phy, Choreography targetChoreography,

Set<Entity> data, int invocationDirection)

Generates a map containingthe identifier of the transition rulein the source or target choreopgra-phy instance that should receive thenext message along with a list of en-tities that go to make up that mes-sage. The difference in inputs is theuse of the choreography descriptions.This method has been implementedin the current Process Mediator.

36

Deliverable 6.8

Table A.12: Invoker InterfaceMethod Summary

void invoke(WebService service, List¡Entity¿ data,

EndpointGrounding grounding

Invoke the Web service usingthe list of entities as the data tobe passed to the service, and thegrounding as an object describingthe endpoint on which the invoca-tion should be made.

Table A.13: Receiver InterfaceMethod Summary

Context receive(WSMLDocument wsmlMessage,

Context context)

Receive a WSML message cor-responding to a particular conversa-tion context if one exists. If this isthe first message in a conversation,the context is created by WSMX andreturned to the WSMX client. Oth-erwise the value of the returned con-text is the same as the value of thecontext passed as an input parame-ter.

37

Deliverable 6.8

Table A.14: Choreography Engine InterfaceMethod Summary

void registerChoreography(Goal goal)

When a goal is received, thechoreography instance of the re-questor needs to be registered

void registerChoreography(WebService webSer-

vice)

When a WS that satisfy a cer-tain goal is discovered, an instanceof its choreography needs to be reg-istered.

void updateState(URI origin, Identifiable mes-

sage)

Attempt to update the inter-nal state of the choreography engineand determine if the received mes-sage from a given origin results ina valid next state. If it doesn’t, thismethod throws a subclass of Compo-nentException that carries more in-formation why the resulting state isnot a valid one ie if we expect to getcredit card data from the client nextbut receive location information in-stead.

Table A.15: Parser InterfaceMethod Summary

Set<Identifiable> parse(WSMLDocument wsmlDocument)

Parse the received WSML intocorresponding WSMO4j objects.

38

Deliverable 6.8

Table A.16: Reasoner InterfaceMethod Summary

Set<Instance> getAllInstance(Concept concept, IRI ontol-

ogy)

Retrieves all the instances ofa concept.

Set<Concept> getAllSubconcepts(Concept concept, IRI on-

tology)

Retrieves all the sub-conceptsof a concept.

Set<Concept> getAllSuperconcepts(Concept concept, IRI

ontology)

Retrieves all the super-concepts of a concept.

boolean isInstanceOf(Instance instance, Concept con-

cept, IRI ontology)

Check if an instance is the in-stance of a certain concept.

void register(Ontology ontology)

Registers an ontology to thereasoner.

void register(Set<Ontology> ontologies)

Registers a set of ontologies tothe reasoner.

void deRegister(IRI ontology)

Removes an ontology from theknowledge base.

void deRegister(Set<IRI> ontologies)

Removes a set of ontologiesfrom the knowledge base.

boolean subsumes(Concept superConcept, Concept

subConcept, IRI ontology)

Checks if a certain concept isa super-concept of another conceptin a given ontology.

Set<Map<Variable,

Term>>

executeQuery(LogicalExpression query, IRI

ontology)

Executes a logical expressionquery in given ontology.

boolean executeGroundQuery(LogicalExpression

query, IRI ontology)

Executes a true/false groundexpression query in a given ontology.

39

Deliverable 6.8

Table A.17: Reasoner Interface ContinuedMethod Summary

boolean entails(IRI ontology,

Set<LogicalExpression> expressions)

Checks if a set of given logicalexpression are logically entailed bythe ontology identified by the IRI.

boolean entails(IRI ontology, LogicalExpression ex-

pression)

Checks if a given logical ex-pression is logically entailed by theontology identified by IRI.

boolean isSatisfiable(IRI ontology)

Checks if an ontology is satis-fiable.

40