=Paper=
{{Paper
|id=Vol-140/paper-5
|storemode=property
|title=SOPHIE - A Conceptual Model for a Semantic Choreography Framework
|pdfUrl=https://ceur-ws.org/Vol-140/paper3.pdf
|volume=Vol-140
|dblpUrl=https://dblp.org/rec/conf/icws/ArroyoD05
}}
==SOPHIE - A Conceptual Model for a Semantic Choreography Framework==
https://ceur-ws.org/Vol-140/paper3.pdf
SOPHIE - A CONCEPTUAL MODEL FOR A SEMANTIC
CHOREOGRAPHY FRAMEWORK
Sinuhe Arroyo
Digital Enterprise Research Institute (DERI). University of Innsbruck, Austria.
Alistair Duke
BT, Next Generation Web Reasearch Group
Abstract:
Choreography models the external visible behavior of services as a set of message exchanges that realize Message
Exchange Patterns (MEP). A number of language exist that try to tackle the problem. However they constitute
incomplete solutions, either because they lack of support of semantics, have a tight relation to the underlying
communication framework, or mix structural, behavioral and operational aspects resulting in confusing specifications.
This position paper defines a conceptual model for SOPHIE, a choreography engine for Semantic Web Services
following a Semantic Service-Oriented Architecture. The conceptual model of SOPHIE is especially suitable for
supporting the fine grained interaction among services with different structural, behavioral or operational models. A
case study in the Telecommunication sector is presented.
Key words: Choreography, Semantic Services, MEPs.
1. INTRODUCTION
This paper presents the conceptual framework of a choreography engine named SOPHIE. A
number of approaches exist, such as ( BPEL4WS [Andrews et al., 2003], WS-CDL [Kavantzas et
al., 2004], WSCI [Arkin et al., 2002] or WSMO - Choreography [Roman et al., 2005]), that try to
model the external visible behavior of services, so interoperation among heterogeneous
interaction patterns can occur. Still none of these approaches represents a complete solution to the
problem due to: lack of proper support for semantics (BPEL4WS, WSCI, WS-CDL), lack of
technological independence and tight relation to the underlying communication framework
(BPEL4WS, WS-CDL), lack of a clear model that separates structural, behavioral and operational
aspects (BPEL4WS, WS-CDL, WSCI or WSMO-Choreography), lack of use of MEP as a central
unit to solve the mismatches among message exchanges (BPEL4WS, WS-CDL, WSCI or
WSMO-Choreography)
Thus, new initiatives are needed that overcome these limitations. SOPHIE (Semantic web
services chOreograPHi servIcE) proposes a framework, which in a first cut is divided into
syntactical and semantic models. The semantic model details the semantic support. The
syntactical model details the syntax of the engine. The syntactic model further depicts three
different complementary models, namely: structural, behavioral and operational. The structural
model deals with the provision of a reusable collection of entities following different levels of
abstraction that provides the basis for the description of a conceptual model. The behavioral
model cares for the description of the dynamic interaction among the entities defined in the
structural model. Finally, the operational model facilitates the means to allow the interoperation
among different behavioral models as shown in Figure 1.
Figure 2:Relation among models
A clear separation of aspects facilitates the addition, replacement and modification of the
underlying paradigms without imposing the need to redesign the overall conceptual model and
affecting the remaining aspects. For example Petri nets, temporal logic or transaction logic can be
used instead of Abstract State Machines (ASMs) for the behavioral model, or OWL instead of
WSML for the semantic one. The work presented here defines the behavioral model as ASMs,
and thus the terms used, in particular the terms choreography, state and guarded transition, follow
the framework proposed in [Roman et al., 2005] and [Booch et al., 1999]. Further the ontologies
of semantic model are WSMO ontologies [Roman et al., 2004]. Still, any other suitable paradigm
can be easily modeled.
2. SYNTACTIC MODEL
2.1 Structural model
A conversation represents the logical entity that permits a set of related message exchanges
among parties to be grouped together. Conversations are composed of a set of building blocks.
Elements represent units of data that build up documents. Documents are complete, self-contained
groups of elements that are transmitted over the wire within messages. Messages characterize the
primitive piece of data that can be exchanged among parties. As messages are exchanged, a
variety of recurrent scenarios can be played out. Message Exchange Patterns (MEP), identify
placeholders for messages, that allow sequence and cardinality to be modeled, defining the order
in which parties send and receive messages. A set of messages sent and received among parties
optionally following a MEP that account for a well defined part of a conversation, are referred to
as a message exchange. A conversation can be thus defined as a set of message exchanges among
parties with the aim of fulfilling some goal. Every conversation is carried out over a
communication facility, referred to as a communication network by parties. The specification
differentiates among two type of parties, initiating parties and answering services. Both parties
produce and consume messages, and additionally initiating parties take care of starting the
message exchange.
2.2 Behavioral model
A choreography describes the behavior of the answering service from the initiating party's
point of view [Roman et al., 2005]. It governs the message exchanges among parties in a
conversation. ASMs allow the sequences of states the choreography goes through during its
lifetime to be s pecified, together with its responses to events. In this sense the main building
blocks of abstract state machines are, to some extent, redrawn. A state is a situation during the
lifetime of a choreography which satisfies some condition or waits for some event. Events are
occurrences of a stimulus that can trigger a state transition. An action represents the atomic task
of sending a message to a party. Transitions among states are defined by guarded transitions.
Guarded transitions allow the relationship between two states, by means of guard conditions, to
be modeled. Guard conditions are Boolean expressions that are evaluated when the transition is
triggered. Parts permit the relationship between guarded transitions and message exchanges to be
expressed, thus defining the message exchange in terms of state transitions. Finally, a
choreography comprises a set of parts that define a conversation.
2.3 Operational model
The atomic building blocks that permit a number of mismatches among interacting parties to
be resolved are logic boxes. A logic box facilitates the reorganization of the content of
documents, its mapping to messages, and the order and cardinality of messages, thus enabling the
interoperation among parties following different message exchange patterns. Additionally, and
depending on the type of box, the differences in the vocabulary used to describe the application
domain can be overcome. Currently the specification defines five different types of logic boxes,
namely: refiner box, merge box, split box, select box, add box. Logic boxes are grouped into logic
diagrams. Logic diagrams permit the relationship between the message exchange pattern
followed by the initiating party, and the one used by the answering service to be modeled. A
number of logic diagrams defining a conversation are referred as a logic group.
2.4 Semantic Model
Ontologies define the semantics of the engine. They provide a vocabulary that can be
mediated for the understanding of interacting parties. Domain ontologies facilitate the general
vocabulary to describe the application domain of the answering service and the initiating party.
The Choreography ontology provides the conceptual framework and vocabulary required to
describe the behavioral model. In doing so it defines and allows instantiation of the entities of the
different models. They are defined as concepts of the ontology, taking part in a choreography.
Thus reasoning and the generation of the operational model based on the different behaviors and
structures is possible.
3. USE CASE
SOPHIE is currently being trialed as part of the DIP project B2B in Telecommunications case
study, hosted by BT. SOPHIE has been applied to BT Wholesale's B2B Gateway which allows
BT's ISP partners to integrate their Operation Support Systems with those of BT and, for
example, carry out tests on BT's network as part of their broadband assurance activities. The B2B
Gateway currently uses the Business Process Specifications of ebXML to represent the required
choreography.
The example applies the operational model of SOPHIE to the broadband test interface in
order to illustrate how a partner's differing choreography could be integrated. Figure 1 shows a
simplified message exchange pattern for the test interface. The service provider sends a
testRequest message to BT. The requested test is examined and then accepted or rejected (it may
be rejected if, for example, a test is requested on a line not owned by BT) resulting in a testAccept
or testReject message being sent to the service provider. Following an acceptance notification, the
test is carried out and the testCompleted message is sent which contains the result of the test.
Figure 2:In-Multi-Out Message Exchange Pattern
If the service provider were to use a different MEP where it expects BT to provide a single
response message (testReply) indicating whether the test was accepted or rejected and if accepted
the result of the test, then the operational model of SOPHIE can be applied. As stated above, logic
boxes constitute the key elements of the operational model. A logic box is represented as a tuple
of the form:
logicBox = [name, URI, type, sequenceNumber&sup?, inputMessages&sup*,
inputMep&sup?, outputMep&sup?, ontologyMapping&sup?]
Table 1: Tuple of a logic box
Where, type specifies the type of logic box, sequenceNumber labels the sequential order of
execution of the logic box, inputMessages define the messages sent by the initiating party, and
outputMep stand for the message exchanges patterns followed by the initiating party and the
answering service respectively, and ontologyMapping specifies a mapping among the domain
ontologies of the interacting parties.
In this example, a merge box is required. The merge box, maps the input messages sent by one
party following a particular message exchange pattern into a single output message, received by
the another party, following a different message exchange pattern. In this case BT's response
messages to the testRequest message are merged and send to the service provider." Additionally,
a merge box permits the types and names of elements, documents, messages and any other
entities (as specified in the structural model) according to the ontologies of the semantic model to
be matched. In this case it would allow the documents contained in the messages sent by BT to be
refined to reflect those expected by the service provider.
Figure 3 shows the merge box required in this case.
Figure 3: Merge Box for textReply message
Listing 2 shows the instance of the tuple for the merge box is:
name: testReplyMerge
URI: http://www.bt.com/assuranceIntegration/logicBox/ testReplyMerge/
type: mergeBox
sequenceNumber: 001
inputMesages: http://www.bt.com/message/testAccept/,
http://www.bt.com/message/testReject/,
http://www.bt.com/message/testResponse/
inputMep: http://www.bt.com/mep/outOnly/
outputMep: http://www.bt.com/messageExchange/inOnly/
ontologyMapping: http://www.bt.com/ontologyMapping/assuranceMapping/Listing/
Table 2:Instance of tuple for a logic box
The URIs for the messages and MEPs refer to entities that have already been defined
according to the structural model. Logic boxes can be combined to form logic diagrams allowing
more complex transformations to take place over conversations.
From the point of view of the case study, SOPHIE provides a comprehensive way to
semantically represent the choreography of the B2B Gateway's interfaces. With appropriate tool
support, it can ease the integration problem and allow dynamic integration between partners to be
realized. Tool support is required to automate the expression of ebXML Business Process
Specifications into the ontological format of SOPHIE and to support to user in performing
mappings between the choreographies of the different parties.
4. SUMMARY
Based on the work presented, the rationale is summarized as follows:
Separation of models
The definition of a conceptual framework requires to clearly differentiating the models that
build it. As a result a modular framework should be designed where the underlying different
paradigms of models can be readily added, extended or replaced in order to place the most
suitable one depending on the target application domain.
Semantic-driven
Semantic descriptions enable the dynamic interoperability among heterogeneous parties. As
new ontological languages based on different logical formalisms are developed, independence
from existing and emerging formalisms should be obliged in any conceptual design. In doing so,
the conceptual model is driven by the semantic description of its constituent entities, not making
any constraint or assumption on the ontological language used to model such descriptions.
Mediation
Mediation allows heterogeneous parties to communicate. It originates due to the natural
heterogeneity of the open environment where parties reside. Mediation by means of logic boxes
facilitates an intermediate layer among parties that provides a generalized solution to resolve
communication mismatches.
Technological independence
The design of a fully extensible conceptual framework should not make any assumptions
about underlying technologies. In particular, the details regarding transport and communication
frameworks, should be left aside, as do not help to neither characterize nor solve the problem
addressed in this thesis, and are subject to change. In doing so, a conceptual framework should
rely on such underlying technologies, defining a clear border, which allows keeping separated the
particular communication details from the conceptual model.
Global view vs. decentralized approach
Traditional models call for centralized approaches where the interaction among parties is
control from a unique point. In contrast, the nature of services is decentralized. While a
decentralized approach is preferred due to its flexibility, eventually a global point of view is
chosen to control the message exchange.
Separation of internal and external behavior
Choreographies deal with the external visible behavior of parties. Thus, the internal details
should be clearly separated from the external ones, allowing its independent definition. Deeply in
this direction, the description of collaborative process is out of the scope of this work, same as
orchestration in general.
SOA-based
As a realization of the all this basic principles, especially regarding semantic-driveness and
technological independence, the conceptual framework should be realized as a SOA with support
for semantics.
5. REFERENCES
[Andrews et al., 2003] Andrews, T., Curbera, F., Dholakia, H., Goland, Y., Klein, J., Leymann, F., Liu, K., Roller, D.,
Smith, D., Thatte, S., Trickovic, I., Weerawarana, S.: Business Process Execution Language for Web Services,
Available from "href="ftp://www6.software.ibm.com/software/developer/library/ws-
bpel.pdf">ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf.
[Arkin et al., 2002] Arkin, A., Askary, S., Fordin, S., Jekeli, W., Kawaguchi, K., Orchard, D., Pogliani, S., Riemer, K.,
Struble, S., Takacsi-Nagy, P., Trickovic, I., Zimek, S.: Web Service Choreography Interface (WSCI) 1.0, Available
from "href=" http://www.w3.org/TR/wsci/"> http://www.w3.org/TR/wsci/.
[Booch et al., 1999] Booch, G., Rumbaugh, J., and Jacobs, I. The Unified Modelling Language User Guide. Addison-
Wesley, 1999.
[Kavantzas et al., 2004] Kavantzas, N., Burdett, D., Ritzinger, G.,: Web Services Choreography Description Language
Version 1.0, Available from "http://www.w3.org/TR/2004/WD-ws-cdl-10-
20040427/">http://www.w3.org/TR/2004/WD-ws-cdl-10-20040427/.
[Roman et al., 2005] Roman, D., Scicluna, J., Feier, C., (eds.) Stollberg, M and Fensel, D.: D14v0.1. Ontology-based
Choreography and Orchstration of WSMO Services. , Available from "http://www.wsmo.org/TR/d14/v0.1/">
http://www.wsmo.org/TR/d14/v0.1/.
[Roman et al., 2004] Roman, D., Lausen, H. and Keller, U. (eds): Web Service Modeling Ontology. WSMO Working
Draft v0.3. , Available from "http://www.wsmo.org/2004/d2/v1.0/"> http://www.wsmo.org/2004/d2/v1.0/.
6. ACKNOWLEDGMENTS
The work is funded by the European Commission under the projects DIP, Knowledge Web,
InfraWebs, SEKT and ASG; by Science Foundation Ireland under the DERI-Lion project; by the
FIT-IT (Forschung, Innovation, Technologie - Informationstechnologie) under the projects RW²
and TSC.