This document is also available in a non-normative PDF version.
The Web Services Execution Environment (WSMX) [Cimpian et al., 2005] is an execution environment for dynamic discovery, selection, mediation and invocation of semantic Web Services. WSMX is based on the Web Services Modeling Ontology (WSMO) [Roman et al., 2005] which describes all aspects related to the discovery, mediation, selection and invocation of Web Services.
WSMX is a reference implementation for WSMO. The goal is to provide both a test bed for WSMO and to demonstrate the viability of using WSMO as a means to achieve dynamic inter-operation of semantic Web Services.
After discovering a Web Service and its respective service description, one has to know the observable behaviour of the Web Service in order to achieve the desired functionality. WSMO [Roman et al., 2005] is the first service modelling languages clearly distinguishing the terms choreography and orchestration and providing means to express them in its service description. Other standards to define the exchange sequence only emerged on top of WSDL descriptions to solely describe business processes of composed web service. The most prominent work in this domain represents BPEL4WS [BPEL4WS, 2003], which distinguishes two ways of describing the business processes: executable business processes and abstract business processes. The first models the internal behaviour of a partner role in an interaction, while the second describes the message exchange behaviour of the involved parties. A different approach is followed by WS-CDL [WS-CDL, 2004], which only defines a non executable message exchange between partners in a Web Service collaboration. This corresponds to the abstract process definition in BPEL4WS [BPEL4WS, 2003].
Choreography and Orchestration in WSMO [Roman et al., 2005b] are part of the interface definition of a WSMO service description [Roman et al., 2005] and describe how to communicate with the service such that the service will provide its capability and how the service collaborates with other WSMO services to achieve its capability. Within this document we will define the syntax and semantics of the WSMO choreography interface and add concepts to the conceptual model to extend the abstract choreography description in WSMO to an executable one. To show the functionality of the component, we define a scenario describing a collaboration between two parties. The scenario assumes that the existence of the service provider was known beforehand and its service description including the choreography definition is published in a repository. The scenario describes how the functionality advertised by the service provider can be consumed by the service requester by elaborating WSMX. It further imposes requirements on the functionality of the choreography component itself.
TBC
Choreography in WSMO describes a concept aligned to the generic definition of the W3C glossary [W3C Glossary, 2004], but something different to the notion of Choreography in WS-CDL [WS-CDL, 2004] or in [Dijkman & Dumas, 2004]. In WSMO Choreography describes the behaviour of a service from one role instance. In [Dijkman & Dumas, 2004] this correspondents to the term interface behaviour. Since it is related exclusively to one role instance, the choreography in WSMO only describes send and receive events, denoted by a choreography ontology extension, called mode which can take the value out for send and in for receive events. Hence the WSMO choreography does not describe interactions between different roles. It concerns all possible interactions providing its capability
with their users. Any user of a Web service, automated or otherwise, is a client of that service. These users may, in turn, be other Web Services,
applications or human beings.
In the context of the choreography component in WSMX we have to further distinct between provider and requester choreographies similar to the distinction of provided and required interface behaviour in [Dijkman & Dumas, 2004]. The distinction is based on the initial communication task the user is required to use. A provider choreography can only use communication task types where a receive event occurs first. A reply task is not necessarily mandatory, but desirable in most cases. A requester choreography can only use communication task types where an event always occurs first, after which optional receive events may occur. The idea is that a requester choreography works as the counterpart of the provider choreography and that therefore the send event corresponds to the request event and vice versa. Only if the requester and provider choreography are perfectly symmetric a direct interaction is possible. It has also to be noted that the provider choreography defines the complete behaviour of a particular service. The requester choreography on the other hand might describe the complete behaviour or it might only describe the required behaviour for one specific interaction if the service provider is already known.
The current WSMX system supports four entry points, whereas currently one, namely the "Web Service execution with choreography", requires to call the choreography component in its execution semantics. The following entry-point initiates this execution semantic:
receiveMessage(OntologyInstance,WebServiceID, ChoreographyID):ChoreographyID
Once the service requester knows which Web Service to invoke, this entry point provides the means for the back-and-forth conversation between the service requester, WSMX and the service provider in order to achieve the functionality expected by the service requester. The service requester is providing all the necessary data to invoke the service by giving fragments of ontology instances (e.g. business documents such as catalogue items or purchase orders in its own ontology). To identify the functionality, the choreography component requires to provide within the WSMX architecture, we define a collaboration scenario between one service requester and one service provider.
As mentioned above the prerequisite is that the service provider is already identified as one suitable to fulfill the request of the service requester. The means how to achieve the prior knowledge about the service provider are manifold, but of no relevance for this deliverable. We refer to the WSMO [Keller et al., 2004] and WSMX Discovery [Lara et al., 2005] for detailed descriptions on how to discover service definitions.
The service provider offers a specific functionality and the necessary semantic descriptions as a Service. The business processes of the service provider (defining the tasks to perform for offering the functionality) are internally defined in its back end application and are out of the scope of this deliverable. It only provides the endpoints to consume the functionality of the Service and describes the required behaviour to achieve it in the interface description of a WSMO Web Service definition.
In this scenario, WSMX acts as an mediating entity between the service requester and the service provider. We assume that the service requester uses WSMX to actually invoke the desired service. It is obvious that in such case the interface definition of the service offered by the service provider has to be stored in any repository known to the WSMX applied by the service requester. This interface definition is described in the provider's choreography interface.
Iff the service requester's and service provider's interface behaviour match, i.e. if the order constraints for the sequencing of the messages sent and received and the information encoded in the messages by the requester match the sequence of messages and its information
received and sent by the provider, these two can collaborate. Their combined
behaviour is a choreography in the definition of [WS-CDL, 2004] or [Dijkman & Dumas, 2004]. In any other case the heterogenities between the two interface behaviour's have to be resolved by the Process Mediation component. A detailed description of the scope of the Choreography component is given in section 2.2, for more details on the functionality of the Process Mediator itself we refer the reader to [Cimpian & Mocan, 2005].
Before any conversation can take place WSMX has to offer the means for the service provider to store its choreography interface. Since the choreography interface is part of the Web Service description this functionality is provided by the methods offered by the Resource Manager interface [Zaremba et al., 2005].
When starting a collaboration the requester will either provide its choreography definition encoded in the message or it will pass a reference to the location of the choreography definition. The choreography component provides the following method to be called at the start of any collaboration to define the roles of the partners in the collaboration and uniquely identify the collaboration itself. Choreography in WSMO deals with binary collaborations only. To define n-ary collaborations one has to define it in the Orchestration interface of the service. For more details on this distinction we refer to [Roman & Scicluna, 2005]. However in the context of the discovery and the negotiation it might be necessary to initiate several provider choreography instances for one requesting choreography instance. To keep this extensibility the components interface allows to initiate the respective instances independently from each other via two seperate methods:
for requester choreographies:
public void initiateChoreography(Goal goal)
and respectively for provider choreographies:
public void initiateChoreography(WebService webService)
Any component calling one of these two methods expects the choreography component to parse the respective Choreography Interface descriptions and to build the class model. The logical interconnection between a requesting choreography instance and its respective one to many providing Choreography Interfaces is internally managed by use of the ConversationID assigned to every collaboration by the system. This allows the choreography component to keep track of the state of communication on either sides, the requester and provider choreography.
updateState(Origin, Message):AbstractGrounding
For every message received by WSMX the updateState method of the Choreography component is called to determine the subsequent state of the opposite choreography. The Origin paramter defines the participant where the Message was received from. Hence whenever such an event occurs (i.e. a message is received) the choreography component identifies the collaboration the message is part of and its respective state. Further it determines what message exchange should conclude in a given state, i.e. it evaluates the condition in the guarded transistions of the source choreography and target choreography and checks if the updates of the opposite state transition are sufficient to conclude the collaboration.
If there is no match in the update part of the guarded transition or even earlier if there are no conditions evaluating true in the opposite choreography description the process mediation component is called to resolve heterogenities in the two interface descriptions.
It has to be noted that the choreography component only deals with the choreographies of the involved participants but does not know anything about the concrete endpoints of the communication. It differs between the participants in the choreography who act out a certain role that is defined in this choreography. The actual grounding is dealt within the Invoker component. Hence the return value of the updateState method is an abstract references to a grounding information which is resolved in the component performing the lowering from the WSML representation to the target protocol. The rationale behind this is to allow a runtime binding of choreography participants to choreography roles and to be able to reuse choreography interface descriptions.
[BPEL4WS, 2003] T. Andrews et al.: Business Process Execution Language for Web Services Version 1.1, 2003. Available from http://www-128.ibm.com/developerworks/library/ws-bpel/.
[Cimpian et al., 2005] E. Cimpian, T. Vitvar, M. Zaremba (editors): Overview and Scope of WSMX. WSMX Working Draft v0.2, 2005. Available from http://www.wsmo.org/TR/d13/d13.0/v0.2/.
[Cimpian & Mocan, 2005] E. Cimpian, A. Mocan: Process Mediation in WSMX. WSMX Working Draft v0.1, 2005. Available from http://www.wsmo.org/TR/d13/d13.7/v0.1/.
[Dijkman & Dumas, 2004] R. Dijkman, and M. Dumas: Service-Oriented Design: A Multi-Viewpoint Approach. International Journal of Cooperative Information Systems 13(4): 337-368, 2004.
[Keller et al., 2004] U. Keller, R. Lara, and A. Polleres (editors): WSMO Web Service Discovery, WSML Working Draft v0.1. Available from http://www.wsmo.org/TR/d5/d5.1/v0.1/.
[Lara et al., 2005] R. Lara, H. Lausen, and I. Toma (editors): WSMX Discovery, WSMX Working Draft v0.2. Available from http://www.wsmo.org/TR/d10/v0.2/.
[Roman et al., 2005] D. Roman, H. Lausen, and U. Keller (editors): Web Service Modeling Ontology Standard. WSMO Working Draft v1.0, 2005. Available from http://www.wsmo.org/2004/d2/v1.0/.
[Roman et al., 2005b] D. Roman, J. Scicluna, and C. Feier (editors): Ontology-based Choreography and Orchestration of WSMO Services. WSMO Working Draft v0.2, 2005. Available from http://www.wsmo.org/TR/d14/v0.2/.
[Roman & Scicluna, 2005] D. Roman, J. Scicluna: Orchestration in WSMO. WSMO Working Draft v0.1, 2005. Available from http://www.wsmo.org/2005/d15/v0.1/.
[W3C Glossary, 2004] H. Haas, and A. Brown (editors): Web Services Glossary, W3C Working Group Note 11 February 2004. Available from http://www.w3.org/TR/ws-gloss/.
[WS-CDL, 2004] N. Kavantzas, D. Burdett, and G. Ritzinger (editors): Web Services Choreography Description Language Version 1.0.W3C Working Draft 17 December 2004. Available from http://www.w3.org/TR/ws-cdl-10/.
[Zaremba et al., 2005] M. Zaremba, M. Moran, and T. Haselwanter: WSMX Architecture. WSMO Working Draft v0.2, 2005. Available from http://www.wsmo.org/TR/d13/d13.4/v0.2/.
business process – collection of activities designed to produced specific outputs based on specific inputs;
state – a state is the complete set of properties describing a real world situation of an object at a given time;
role – participant in an interaction; the requestor or the provider of a service;
The work is funded by the European Commission under the projects DIP, Knowledge Web, InfraWebs, SEKT, SWWS, ASG and Esperonto; by Science Foundation Ireland under the DERI-Lion project; and by the FIT-IT (Forschung, Innovation, Technologie - Informationstechnologie) under the projects RW² and TSC.
The editors would like to thank to all the members of the WSMX working group for their advice and input into this document.