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.
This paper presents the conceptual framework of a choreography engine named SOPHIE. A
number of approaches exist, such as
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. 2. 2.1
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
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
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
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.
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. logicBox = [name, URI, type, sequenceNumber&sup?, inputMessages&sup*,
inputMep&sup?, outputMep&sup?, ontologyMapping&sup?]
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.
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.
Based on the work presented, the rationale is summarized as follows:
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 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 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.
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.
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.
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.
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.