This document is also available in non-normative PDF version.
The goal of the Web Service Execution Environment (WSMX) is to create an execution environment for the dynamic discovery, selection, invocation and inter-operation of Semantic Web Services. In any of these processes, mediation may be required at both data and process levels.
This deliverable tackles the process mediation problem, starting with a description of what we understand by a process and process compatibility in the context of Semantic Web Services, outlining the current state of the art in process representation and process mediation, and continuing with our approach to process representation and mediation. At the end of this document, we present our final conclusions and suggestions for future steps in the development of a robust and reliable mediation system. There are also two annexes with this deliverable; the first one presents an example of how the process mediation should work, considering the choreographies of a requestor of a service and of the Semantic Web Service that offers it; the second annex contains a small glossary.
Processes mediation is concerned with determining how two public processes can be matched in order to provide certain functionality. In other words, how two business partners can communicate, considering their public processes.
Process mediation is a complex task, and this document does not address all the problems and all the mediation scenarios that may appear in a business context, but only a small subset of them; this subset will be extended as our work progresses.
In the first subsection of this chapter we describe what we understand by a business process and provide a rationale for addressing only the public process heterogeneity. The following subsection describes what process compatibility means in the context of Semantic Web Services, providing a list of heterogeneity mismatches that our Process Mediation Prototype should be able to automatically overcome, and also a list of mismatches that no mediation prototype, no matter how advance, can address.
A process is a collection of activities designed to produce a specific output for a particular customer, based on a specific input; an activity is a function, or a task that occurs over time and has recognizable results [BTP, 2003].
Depending on the level of granularity, each process can be seen as being composed of different, multiple processes. The smallest process possible consists of only one activity. Figure 1 presents a graphical representation of a process obtained by combining multiple processes. The output of one or more processes is considered to be the input of another, or many other processes.
Figure 1. Process consisting of multiple processes
One can distinguish between two types of processes: private processes, which are carried out internally by an organization, and usually are not visible to any other entity, and public processes, which define the behaviour of the organization in collaboration with other entities [Fensel and Bussler, 2002].
Public processes (called abstract processes or business protocol in Business Process Execution Language for Web Services [BPEL4WS, 2003]) define the behaviour of a business entity (endpoint) in collaboration with another endpoint, which is expressed by the exchange of messages. To establish communication, each endpoint has to understand the behaviour of the other and more importantly, their behaviors have to match. The matching means that the two endpoints have to have symmetric behaviour, for example when one of them is sending a message, the other one has to know that it is going to receive it.
Consider the following example: a Virtual Travel Agency (VTA) service offers the possibility of on-line ticket booking for certain routes, and a requestor of such a service attempts to invoke it. In their internal ontology, both of them have the following concepts:
concept station nonFunctionalProperties |
The assumption that both the requestor and the provider of the service understand the same concepts was made only for the sake of simplicity. If they use different conceptualizations of the same domain, an external Data Mediator [Mocan, 2005] should be invoked to solve the data heterogeneity problem.
A public process for the requestor could be that after sending two instances of station, it expects to receive an instance of route. The equivalent public process from the requestor side could be that it expects two instances of station in order to generate an instance of route. The relations between the two instances of station and the instance of route are not specified in the public interface of either of the two endpoints.
Figure 2 is a graphical representation of the requestor’s public processes.
Figure 2. Example of a public process
Private processes (called executable business processes in BPEL4WS [BPEL4WS, 2003]) model the actual behaviour of an endpoint involved in an interaction, that is, the internal processing of events.
For example, in the previously described scenario, the computations performed by the VTA in order to generate the instance of route are not visible to the outside world. The private process of generating this instance could check, for example, whether the two instances of station exist in the particular software package’s own ontology (otherwise it is impossible for it to have a route between them) and whether the requestor specified which station is the start and which the end point of the trip.
In this context, we understand process compatibility to mean full matching of the communication patterns between the source and the target of the communication; that is, when one of them is sending a message, the other one is able to receive it. We are not addressing the private process compatibility because the private processes are not visible to the outsiders, and there is no usability of mediating between them.
Since a business communication usually consists of more than one exchange message, finding equivalences in the message exchange patterns of the two (or more) parties is not at all a trivial task. Intuitively, the easiest way of doing this is to first determine the mismatches, and then search for a way to eliminate them. In [Fensel and Bussler, 2002], the three possible cases of mismatches which may appear during message exchange are identified:
Precise match: The two partners have exactly the same pattern in realizing the business process, which means that each of them sends the messages in exactly the order that the other one requests them. In this ideal case the communication can take place without using a Process Mediator. However, this does not mean that the services of a Data Mediator may not be required.
Resolvable message mismatch: Here, the two partners use different exchange patterns, and several transformations have to be performed in order to resolve the mismatches (for example when one partner sends more than one concept in a single message, but the other one expects them separately. In this case the mediator can “break” the initial message, and send the concepts one by one).
Unresolvable message mismatch: One of the partners expects a message that the other one does not intend to send (considering the example from Section 2.1.1., if the provider of the service expects to receive an intermediary station, and the requestor does not intend to send it). Unless the mediator can provide this message, the communication reaches a dead-end.
In order to communicate, two endpoints have to define compatible processes, or use an external mediation system as part of the communication process. The role of the mediator system will be to transform the client’s messages and/or the Web service’s messages, in order to obtain a sequence of equivalent processes.
In the following subsections we describe the resolvable message mismatches that our Process Mediator is intended to address, and the unresolvable message mismatches that a Process Mediator cannot address. The ideal case of precise match does not raise any problems from the communication pattern point of view, so we ignore it in our discussion.
Some of the communication mismatches can be addressed by means of a mediation system. In this section we provide a list of resolvable mismatches that our mediator is intended to address.
a) Stopping an unexpected message (Figure 3. a)) – If one of the partners sends a message that the other one does not want to receive, the mediator should just retain and store it. This message can be sent later, if needed, or it can just be deleted after the communication ends.
b) Inversing the order of messages (Figure 3. b)) – If one of the partners sends the messages in a different order than the other partner expects, the messages that are not yet expected will be stored and sent when needed.
c) Splitting a message (Figure 3. c)) – If one of the partners sends in a single message multiple information that the other one expects to receive in different messages, the information can be split and sent in a sequence of separate messages.
d) Combining messages (Figure 3. d)) – If one of the partners expects a single message, containing information sent by the other one in multiple messages, the information can be combined into a single message.
e) Sending a dummy acknowledgement (Figure 3. e)) – If one of the partners expects an acknowledgement for a certain message, and the other partner does not intend to send it, even if it receives the message, an acknowledgment can be automatically generated and sent to the partner which requires it.
Figure 3. Resolvable message mismatches
This list of resolvable message mismatches contains only the initial set of mismatches that our Process Mediator is intended to address. In future work, the Process Mediator will be further extended, in order to address more possible resolvable mismatches.
There are several communication mismatches that can not be addressed by a Process Mediator.
a) Generating a message (Figure 4. a)) – If one of the partners expects a message containing information that the other partner did not previously send, the Process Mediator is not able to generate this missing information, because, it does not have the required information.
b) Sending a dummy acknowledgement (Figure 4. b)) – If one of the partners expects an acknowledgement for a certain message, but the other partner does not want to receive the message, the process Mediator cannot send a dummy acknowledgement. Although this may seem similar with case e) from the previous section, the difference is that in this case the Business Partner 2 does not receive the message; by sending the acknowledgement the Process Mediator could alter the entire communication between the two parties.
Figure 4. Unresolvable message mismatches
This chapter presents the current state of the art in process representation (Section 3.1) and in process mediation (Section 3.2). Since there are many approaches for both process representation and process mediation, we do not claim to present all the existing approaches in these two fields, but to provide a short introduction of what has already been done.
In order to address the process mediation problem, we have to have a clear understanding of what a process means, and of the existing technologies in representing the processes.
An adequate process representation technology must support the modeling of the processes, respect the correctness of their execution, and also allow the automation of business processes within organizations. Since a description of the current existing technologies in representing the processes is out of the scope of this chapter, and there are already a number of surveys of this field available (like [Solanki and Abela, 2003] or [Peltz, 2003]), we will briefly present only aspects of BPEL4WS [BPEL4WS, 2003].
The reason for focusing on this particular notation is that BPEL4WS allows the processes to export and import functionality by using Web Services interfaces exclusively.
BPEL4WS distinguishes two ways of describing the business processes: executable business processes and abstract business processes, also known as business protocols. The first ones model the internal behavior of a participant in an interaction, while the second ones describe the message exchange behavior of the involved parties. The key distinction between the two classes of processes is that the executable business processes model data in a private way, that need not be described in the public protocols.
From the mediation point of view, we are only concerned with the second category, which is addressed by the WSMO choreography, the internal behavior of the participants not being relevant for communication. In the rest of this chapter, both terms, business process and business protocol, will be used with the same meaning: the message exchange behavior.
Conforming to the BPEL4WS Specifications, the definition of a business protocol involves the specification of all the visible messages exchanged between the involved parties, without any reference to their internal behavior.
The BPEL4WS definitions for both the internal processes and the communication protocols consist of four major components: variables, partnerLinks, faultHandlers, and description of the normal behavior. The variables define the data variables used by the process, in terms of WSDL message types, XML Schema simple types or XML Schema elements; the partnerLinks specify the different parties that are involved in the process; the faultHandlers contain fault handlers that define the responses in case of a failure.
Additionally, the protocol definition must include conditional and time-out constructs, exceptional conditions and recovery sequences and cross partner coordination of the outcome. The conditional and time-out constructs are used for modeling data dependent behavior; the exceptional conditions and recovery sequences are as important as the ability to define the behavior of a business protocol assuming that everything is working well; the cross partner coordination of the outcome is needed for different units of work and at different levels of granularity, the reason for this being that long-running interactions may include multiple nested units of work.
Process mediation is still a little explored research field, in the context of Semantic Web Services. The existing work represents only visions of mediator systems able to resolve in a (semi-)automatic manner the process heterogeneity problems, without presenting sufficient detail about their architectural elements. Still, these visions represent a starting point and are valuable references for future concrete implementations.
Two integration tools,Contivo [Contivo] and CrossWorlds [CrossWorlds] seem to be the most advanced examples in this field.
Contivo is an integration framework which uses metadata representing messages organized by semantically defined relationships. One of its functionalities is that it is able to generate transform code based on the semantic of the relationships between data elements, and to use this code for transforming the exchange messages. However, Contivo is limited by the use of a purpose-built vocabulary and of pre-configured data models and formats.
CrossWorlds is an IBM integration tool, meant to facilitate B2B collaboration through business processes integration. It may be used to implement various e-business models, including enhanced intranets (improving operational efficiency within a business enterprise), extranets (for facilitating electronic trading between a business and its suppliers) and virtual enterprises (allowing enterprises to link to outsourced parts of an organization). The disadvantage of this tool is that different applications need to implement different collaboration and connection modules, in order to interact. As a consequence, the integration of a new application can be achieved only with additional effort.
Through our approach we aim to provide dynamic mediation between various parties using WSMO for describing goals and Web Services. As described in this paper this is possible without introducing any hard-coded transformations.
As in WSMO Choreography and Orchestration [Roman et al., 2005] the representation of a WSMX business process is based on the Abstract State Machine [Gurevich, 1995] methodology. ASMs have been chosen as the underlying model of choreography and orchestration for the following three reasons:
1. Minimality: ASMs provide a minimal set of modeling primitives, i.e., they enforce minimal ontological commitments. Therefore, they do not introduce any ad hoc elements that it would be questionable to include in a standard proposal.
2. Maximality: ASMs are expressive enough to model any aspect around computation.
3. Formality: ASMs provide a rigid mathematical framework to express dynamics.
For a detailed explanation on ASMs we refer the reader to [Börger, 1998].
In order for this deliverable to be self-contained, we describe in the next paragraphs the main features of WSMX processes, i.e. the main features of WSMO choreography, as described in [Roman et al., 2005].
Taking the ASMs methodology as a starting point, a WSMX process is state-based and consists of two elements: states and guarded transitions.
Class wsmxProcess hasState type ontology hasGuardedTransitions type guardedTransition |
All the wsmxProcess elements are defined in WSMO Choreography Orchestration, but for consistemcy reasons we will provide them here as well.
State
A state is described by an ontology as defined in [Roman et. al., 2004] Section 4.
Guarded transitions
Transition rules that express changes of states by changing the set of instances.
A state is described by a set of explicitly defined instances and values of their attributes or through a link to an instance store.
In extension to a standard WSMO ontology, an ontology that is used to describe states in a WSMX process introduces a new non-functional property. When a concept, relation or function in a process is defined, the attribute mode can be defined as a new non functional property. It can take one of the following values:
For more details on WSMO Grounding we refer the reader to [Kopecky and Roman, 2005].
The signature of the states is defined by WSMO identifiers, concepts, relations, functions, and axioms. This signature is the same for all states. The elements that can change and that are used to express different states of a choreography, are the instances (and their attribute values) of concepts, functions, and relations that are not defined as being static. In conclusion, a specific state is described by a set of explicitly defined instances and values of their attributes or through a link to an instance store.
Considering the previous example described in Section 2.1.1., the requestor of the service has the attribute mode set to out for the concept station, and set to in for the concept route:
concept stationInChoreography subConceptOf station nonFunctionalProperties |
Guarded Transitions are used to express changes of states by
means of rules, expressible in the following form:
if Cond then Updates.
Cond is an arbitrary WSML axiom, formulated in the given signature of the state.
The Updates consists of arbitrary WSMO Ontology instance (see Section 4.7 of WSMO 1.1) statements.
In the previously described example, the guarded transition that states that the requestor first sends two instances of station and then expects to receive an instance of route is the following:
?x memberOf routeinChoreography[ sourceLocation hasValue ?startLocation_, destinationLocation hasValue ?endLocation_]<- ?sourceLocation_ memberOf stationInChoreography and |
Please note that there is no assumption made in this rule about the relation between the two instances of stationInChoreography; as much as this rule states, there can even be only one instance. The additional conditions imposed on the two instances of stationInChoreography, and on their relation with the instance of routeInChoreography can be modelled in the internal ontology of the requestor. How much information is made public using choreography, and how much remains private in the internal ontology is strictly a modelling choice. The ideal case is for the choreography to make public exactly the amount of information needed to allow external users to interact without errors, but every participant may choose to publish more or less than is actually needed.
This chapter is structured in two sub-sections: Section 5.1 describes the Process Mediation interactions with other WSMX components, together with the interfaces that the process Mediator should implement, while Section 5.2 presents the process mediation algorithm.
When the WSMX receives a message [Zaremba, 2005], either from the requestor of the service or from a Web Service, it has to check if it is the first message in a conversation. If it is the first, the system creates copies (instances) of both the sender and the targeted business partner choreographies, and stores these instances in a repository. If it is not the first message of a conversation, the WSMX has to determine the two choreography instances corresponding to the conversation (their IDs), and the id of the conversation. These computations performed on the message are done by other two components, Receiver and Choreography Engine (described in [Zaremba, 2005]). After the IDs of the two choreography instances are obtained, the Process Mediator (PM) receives them, together with the message, consisting of instances of concepts from the sender’s ontology. Based on the IDs, the PM loads the two choreography instances from the Repository (where they were previously stored by the Choreography Engine), by invoking the Resource Manager. All the transformations performed by the PM will be done on these instances. If different ontologies have been used for modeling the two choreographies, the PM has to invoke an external Data Mediator [Mocan, 2005] to transform the message into the terms of the target ontology (Figure 5).
Figure 5: Overview of Web Service execution5
After various internal computations described in the following section, the PM determines whether, based on the incoming message, it can generate any message expected by either one of the partners. The generation of any message determines a transformation in the chorography instance of the party that receives that message. After sending the message, the process mediator re-evaluates all the rules, until no further updates are possible.
The interactions between the Process Mediator and other components are represented in Figure 6.
Figure 6: The Process Mediator’s interactions
The Process Mediator should implement the following interface:
public interface ProcessMediator {
public Map<Identifier, List<Identifiable>> generate(
Identifier source,
Identifier target,
Set<Identifiable> data)
throws ComponentException, UnsupportedOperationException;
public Map<Identifier, List<Identifiable>> generate(
Ontology source,
Ontology target,
Set<Identifiable> data)
throws ComponentException, UnsupportedOperationException;
public Map<Identifier, List<Identifiable>> generate(
Choreography source,
Choreography target,
Set<Identifiable> data)
throws ComponentException, UnsupportedOperationException;
}
|
When the Process Mediator is invoked, it should receive information about which the two participants in the conversation are, in terms of what ontologies or choreographies they use, and also the actual data sent by one of the partners. The information about the two participants in the conversation can be transmitted as Identifier objects of an ontology or of a choreography (the first method), as Ontology objects (the second method) or as a Choreography objects (the last method). The data sent by one of the partners is already parsed [Zaremba, 2005] and decomposed in ontology elements; all the process mediator needs to receive is a set of Identifiable objects, each Identifiable (as the name says) uniquely identifying an element from an ontology.
The returned Map object, for all three methods, contains two pairs. The first element of a pair is the identifier of the targeted partner (the result of receiving a message from one participant can be sending a message to its partner or to the initial sender – for example in the case of sending an acknowledgement); the second element is a list containing the actual information to be sent.
The Process Mediator is triggered when it receives a message, and the two choreography instances IDs. The message contains instances of concepts, in terms of the sender's ontology.
After being invoked, the PM performs the following steps:
The only thing that should be kept in an internal storage is the actions the Process Mediator needs to take when receiving a message. This could be useful if the same two partners are later involved in a second conversation.
This algorithm is implemented by the PM in order to solve the communication heterogeneity problem.
The following figure presents the steps performed during the process mediation, as well as the involved components. The ovals are used for representing actions, while rectangles are used for representing components. The components from the bottom part of the figure are external components, not part of the Process Mediator.
Figure 7: Interaction Diagram for the Process Mediator’s Components
The links with the Choreography Engine are not represented in the above figure. The Choreography Engine is the one that triggers the entire process, by calling the Generate method.
The Process mediator consists of three components: Choreography Parser, WSML Reasoner, and an internal Repository.
Choreography Parser
The Choreography Parser has the role of determining if any instance obtained after the data mediation process is expected by the targeted partner. That is, the choreography parser will have to perform the following operations:
The interface implemented by this component is depicted in the following listing:
public interface ChoreographyParser {
public boolean required(Identifiable data);
}
|
As stated in the interface, the Choreography Parser does not have to return the value of the mode attribute, but only a boolean value: true if the data is required by the targeted partner at some point in time (the mode is set to in or shared) or false otherwise.
Internal Repository
The Internal Repository is used for storing information that will be sent to one of the partners at some point in time. It offers the methods store, retrieve, delete and update.
WSML Reasoner
The WSML Reasoner is the most complex component of the Process Mediator. It’s task it to extract one by one the instances from the repository, and to check if by sending that instance at least one condition of one transition rule can be fulfilled.
The interface of the WSML Reasoner component is as follows:
public interface WSMLReasoner {
public Set<Identifiable> expected(Identifiable target);
}
|
The expected method has only one parameter, the Identifiable object corresponding to the targeted partner, and returns the set of elements expected at that particular point in the communication (there may be cases when two or more of the instances previously stored in the repository are expected at the same time).
This deliverable tackles the behavioural heterogeneity of two business partners and proposes a solution for solving this heterogeneity. Taking in consideration only the public processes of an entity, the mediation of their behaviour may be needed when a requester attempts to invoke and execute a Web Service of a provider, and the communication patterns of the service requestor and the service provider do not match.
Each time a message is sent by one of the two parties involved in the conversation, the process mediator has to determine if the message is expected by the other party. The mediator also has to consider situations when only part of a message or a combination of this message with a previously received one is expected..
The document presented an overview of the addressed mismatches, and the way the process mediation is able to automatically solve these problems. The interface that our Process Mediator should implement, as well as the interfaces and the interactions of different subcomponents are also presented.
Based on this deliverable, the next step in our work will be the development of a Process Mediation Prototype. Also we plan to extend the addressed mismatches, with new and more complex cases raised by the use-cases.
[van der Aalst et al., 1994] W.M.P. van der Aalst, K.M. van Hee, G.J. Houben: Modelling workflow management systems with high-level Petri nets. In G. De 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.
[BPT, 2003] Business Process Trends, Glossary, available at http://www.bptrends.com/resources_glossary.cfm, 2003.
[Bussler, 2003] C. Bussler: B2B Integration. Berlin, Heidelberg: Springer, 2003.
[BPEL4WS, 2003] Specification: Business Process Execution Language for Web Services Version 1.1, available at http://www-128.ibm.com/developerworks/library/ws-bpel/, 2003.
[Contivo] Available at: http://www.contivo.com/.
[CrossWorlds] Available at: http://www.sars.ws/hl4/ibm-crossworlds.html
[Fensel and Bussler, 2002] D. Fensel and C. Bussler: The Web Service Modeling Framework WSMF, In Electronic Commerce Research and Applications, 1(2), 2002.
[Hollander, 2003] D. Hollander: Semantic Integration, How You Can Deliver Business Value Today, 2003.
[Kopecky and Roman] J. Kopecky, and D. Roman: WSMO Grounding, WSMO deliverable D24.2 version 0.1. available from http://www.wsmo.org/2005/d24/d24.2/v0.1/20050119/
[Mocan, 2005] A. Mocan (ed.): WSMX Data Mediation, WSMX Working Draft v0.2, available at http://www.wsmo.org/2005/d13/d13.3/v0.2/, 2005.
[Peltz, 2003] C. Peltz: Web Service Orchestration. A Review of emerging technologies, tools, and standards. Hewlett Packard, CO., January 2003.
[Ratzer et al., 2003] A.V. Rantzer, L. Wells, H.M. Lassen, M. Laursen, J.F. Qvortrup, M.S. Stissing, M. Westergaard, S. Christensen, and K. Jensen: Cpn tools for editing, simulating and analysing coloured petri nets. In W.M.P van der Aalst and E. Best, editors, Applications and Theory of Petri Nets 2003: 24th International Conference, ICATPN 2003, volume 2679 of Lecture Notes in Computer Science, pages 450{462. Springer-Verlag, 2003.
[Roman et al., 2004] D. Roman, H. Lausen and U. Keller (eds): Web Service Modeling Ontology (WSMO) WSMO Working Draft v1.1,. available at http://www.wsmo.org/2004/d2/v1.1/, 2004.
[Roman et al., 2005] D. Roman, J. Scicluna, Cristina Feier (eds.): Ontology-based Choreography and Orchestration of WSMO Services, WSMO deliverable D14 v0.1. available at http://www.wsmo.org/TR/d14/v0.1/, 2005.
[Solanki and Abela, 2003] M. Solanki and C. Abela: The Landscape of Markup Languages for Web Service Composition, May 2003.
[Zaremba, 2005] Michal Zaremba (ed.): WSMX Architecture, WSMX Working Draft v0.2, available at http://www.wsmo.org/2005/d13/d13.4/v0.2/, 2005
[Zaremba and Oren, 2005] Maciej Zaremba, E. Oren: WSMX Execution Semantics, WSMX Working Draft v0.2, available at http://www.wsmo.org/TR/d13/d13.2/v0.2/20050425/wsmx-d13.2.pdf, 2005.
In this subsection, we define the Virtual Travel Agency (VTA) service's ontology, its choreography ontology and the corresponding transition rules.
Listing 7 presents the VTA service ontology, defining the concepts needed for performing on-line ticket reservation:
namespace
<<http://www.wsmo.org/TR/d13/d13.7/ontologies/VTAServiceOntology/>> ontology<<http://www.wsmo.org/TR/d13/d13.7/ontologies/VTAServiceOntology>> nonFunctionalProperties concept
station concept
route concept
routeOnDate concept time subConceptOf
xsd:time concept date subConceptOf
xsd:date concept price subConceptOf
xsd:integer concept
person concept
creditCard concept
reservation |
Listing 8 presents the VTA service choreography’s ontology (any business partner express its public processes as WSMO choreography).
| namespace<<http://www.wsmo.org/TR/d13/d13.7/ontologies/VTAServiceChorography>> vtas: <<http://www.wsmo.org/TR/d13/d13.7/ontologies/VTAServiceOntology>> dc: <<http://purl.org/dc/elements/1.1#>> ontology
<<http://www.wsmo.org/TR/d13/d13.7/ontologies/VTAServiceChorography>> importedOntologies <<http://www.wsmo.org/TR/d13/d13.7/ontologies/VTAServiceOntology>> concept station
subConceptOf vtas:station concept route
subConceptOf vtas:route concept routeOnDate
subConceptOf vtas:routeOnDate concept time subConceptOf vtas:time concept date
subConceptOf vtas:date concept price subConceptOf vtas:price concept person
subConceptOf vtas:person concept creditCard
subConceptOf vtas:creditCard concept reservation
subConceptOf vtas:reservation |
Listing 9 presents the guarded transitions that lead the execution of the process.
|
choreographyVTAServiceChoreography
statevtasc <"http://www.wsmo.org/TR/d13/d13.7/ontologies/VTAServiceChorography"> guardedTransitionsreservationServiceTransitionRules /*an
instance of route can be
created only after two instances of station
exist;since the concept station has
the mode set to
in,
these instances need to be providedby the
environment; the instance of route will be
sent to the requestor of the service*/ /*an
instance of routeOnDate
is created, assuming that instances of route, date,time and
price
already exist; since only date
has the mode set
toin, only an
instance of date
is expected from the environment*/ /*an
instance of the reservation
concept is created, assuming that instances ofrouteOnDate,
creditCard
and person
already exist. The instances of creditCardand
person
have to be obtained from the environment*/ |
Note that these rules do not reflect the actual computations done by the system in order to create certain instances, they just express the message sequencing. For example, for generating an instance of route, the system has to internally check whether the two stations are the beginning and the end of the trip, and whether it can provide a connection between these two stations. However, all these computations are private, and they are not visibleto the outside world. Based on the transition rules, the order of sending/receiving messages (communication pattern) can be established.
In the previous example we described a service that provides on-line ticket booking facilities. In this chapter, we will describe the requestor of such a service. Listing 10 present its ontology, Listing 11 its choreography’s ontology and finally, Listing 12, its transition rules.
| namespace<<http://www.wsmo.org/TR/d13/d13.7/ontologies/VTARequestorOntology>> dc <<http://purl.org/dc/elements/1.1#>>, xsd <<http://www.w3.org/2001/XMLSchema#>> ontology <<http://www.wsmo.org/TR/d13/d13.7/ontologies/VTARequestorOntology>> nonFunctionalProperties concept
station concept date
subConceptOf xsd:date concept
myRoute concept
person concept time
subConceptOf xsd:time concept price
subConceptOf xsd:integer concept
creditCard concept
creditCardAcknowledgement concept
reservation |
| namespace<<http://www.wsmo.org/TR/d13/d13.7/ontologies/VTARequestorChorography>> vtar <<http://www.wsmo.org/TR/d13/d13.7/ontologies/VTARequestorOntology>> dc <<http://purl.org/dc/elements/1.1#>> ontology <<http://www.wsmo.org/TR/d13/d13.7/ontologies/VTARequestorChorography>> nonFunctionalProperties importedOntologies <<http://www.wsmo.org/TR/d13/d13.7/ontologies/VTARequestorOntology>> concept station
subConceptOf vtar:station concept date
subConceptOf vtar:date concept myRoute
subConceptOf vtar:myRoute concept person
subConceptOf vtar:person concept time
subConceptOf vtar:time concept price
subConceptOf vtar:price concept creditCard
subConceptOf vtar:creditCard concept
creditCardAcknowledgement subConceptOf
vtar:creditCardAcknowledgement concept reservation
subConceptOf vtar:reservation |
| choreography
VTARequestorChoreography
state vtarc <"http://www.wsmo.org/TR/d13/d13.7/ontologies/VTARequestorChorography"> guardedTransitions reservationRequestorTransitionRules /*creates an instance of my route, assuming
that two instances of stationand an instance of
date are already created; since both station and date have the value
of mode set to controlled, the requestor does not expect any input in
order to create the instance of myRoute*/ /*an
instance of time is expected (the departure time), after the instance
of myRoute was sent to the service*/ /*an
instance of price is expected (the price of a ticket), after the
instance of myRoute was sent to the service*/ /*after receiveing the time and price
instances, the requestor creates an instance of the concept
creditCard*/ /*the requestor is expecting the
confirmation of the credit card (internally it will check whether all
the attributes from the confirmedCreditCard's instance have the same
value as the attribute of the creditcard's instance, but these
computations don't have to be public)*/ /*after receiving the confirmation of the
credit card, the requestor will send the name of the person who needs
the reservation*/ /*an
instance of reservation is expected, after instances of myRoute and
person have been created*/ |
In this scenario, the exchange of messages is as follows:
Considering the previously described choreographies, Figure 6 presents a graphical representation of the communication patterns of the two participants:
Figure 6. Communication patterns of the service requestor and service provider
The Process Mediator has to translate any incoming message in terms of the targeted partner ontology, and to decide whether, based on this message, it can generate any message, for either one of the two partners, that could trigger an action (not necessarily to change a state, but to eliminate one condition for changing a state).In what follows, we analyze step by step the flow of messages and the internal transformations that take place on the requestor and provider side.
1. PM receives an instance of myRoute – after translating this instance in terms of the service’s ontology, the PM will obtain two instances of station and one of date. Conforming to the choreography ontology of the requestor, all these three instances are expected, but the guarded transitions show that only two of them (the instances of station) are expected at this phase. The instance of date is not yet expected since the first condition (?forRoute_ memberOf vtasc:route) of the rule that checks whether an instance of date exists is not satisfied. As a consequence, the PM will send the two instances of station and store the instance of date.
2. Internally, the provider creates the instance of route, which will be sent to WSMX.
3. After translating the route’s instance in terms of the requestor’s ontology, and analyzing the two choreographies, the PM discards the instance of route (nobody is expecting any information contained by that instance) and sends the previously stored instance of date, while at the same time deleting it from its internal repository.
4. The provider creates an instance of routeOnDate and sends it to WSMX.
5. PM translates the routeOnDate in terms of the requestor’s ontology into two instances of station, an instance of time and one of price. Nobody is expecting any more instances of station, so these two can be deleted. The price and time instances are sent.
6. The requestor sends the details of a credit card (an instance of the creditCard concept) to the WSMX.
7. Based on the two choreographies, the PM sends the corresponding instance of a creditCard for the provider, and creates an acknowledgement (instance of creditCardAcknowledgement) to be sent to the requestor.
8. The instance of person is send by the requestor to WSMX.
9. PM sends the corresponding instance of person.
10. The service sends to WSMX an instance of the reservation concept.
11. PM send the reservation instance to the requestor. Since at this moment none of the two participants is expecting anything more, the PM considers the communication over.
activity – function or task that occurs over time and has recognizable results;
business entity – participant in an interaction; the requestor or the provider of a service;
business process – collection of activities designed to produced specific outputs based on specific inputs;
endpoint – business entity;
process equivalence – full matching of the communication pattern of the two participants in a conversation.
The work is funded by the European Commission under the projects DIP, Knowledge Web, Ontoweb, SEKT, SWWS, Esperonto and h-TechSight; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government under the CoOperate programme.
The editors would like to thank to all the members of the WSMO working group for their advises and inputs to this document.
1 All the concepts and axioms from this document are described using Web Service Modeling Language (http://www.wsmo.org/wsml/) version 0.1; all the tools developed so far in WSMX are using this version of WSML; the authors intend to follow the newer releases of WSML as soon as tool support will be provided for it.
2 dc: The Dublin Core Element Set v1.1, available at: http://purl.org/dc/elements/1.1#.
3 xsd: XML schema, available at: http://www.w3.org/2001/XMLSchema#.
4 The syntax used in this listing is equivalent with the classical if-then-else syntax.
5 Source [Zaremba and Oren, 2005]; the tool used is CPNTools [Ratzer et al., 2003], which make it possible to model so-called high-level Petri-nets [van der Aalst et al., 1994], extending classical Petri nets with hierarchy, colour and time.
6 The interface is described in Java 1.5. The classes used in describing the methods are defined in WSMO4J, an API and a reference implementation for building Semantic Web Services applications compliant with the Web Service Modeling Ontology; available at: http://wsmo4j.sourceforge.net/index.html