SOPHIE: Use case and evaluation

Available online at www.sciencedirect.com

Information and Software Technology 50 (2008) 1266–1280 www.elsevier.com/locate/infsof

SOPHIE: Use case and evaluation Sinuhe Arroyo *, Miguel-Angel Sicilia University of Alcala´, Polytechnic School, Computer Science Department, Ctra. Barcelona km 33, 6, Madrid, Spain Received 3 July 2006; received in revised form 7 January 2008; accepted 9 January 2008 Available online 17 January 2008

Abstract Services communicate with each other by exchanging self-contained messages. Depending on the specific requirements of the business model they serve and the application domain for which services were deployed, a number of mismatches (i.e. sequence and cardinality of messages exchanges, structure and format of messages and content semantics), can occur which prevent interoperation among a priori compatible services. This paper presents the evaluation of SOPHIE, a conceptual framework for supporting the conceptualization of ontologybased services choreographies. In doing so a three fold approach is taken that considers formal, epistemological and technical aspects. The formal evaluation tries to prove the consistency, completeness and conciseness of ontological model used. The epistemological evaluation enumerates the improvements and differentiating aspect of SOPHIE with respect to existing related work and reviews a number of application areas where the work was successfully applied. Finally, the technical feasibility evaluation tries to demonstrate the viability of the approach from the point of view of the engineering process required to allow the interaction of heterogeneous Semantic Services. Ó 2008 Elsevier B.V. All rights reserved. Keywords: Semantic services; Choreography; Evaluation

1. Introduction The new requirements in the design of software systems call for well decoupled approaches where components interoperate by exchanging self-contained messages. These systems realize their functionality by defining from a highlevel point of view their dynamics. Still, components autonomously define their control flow and the message interface that enables others consuming their functionality. As the use of services is catching up, more and more interest is being place in the development of initiatives that enable their agile interoperation. With the aim of fulfilling the communication necessities, the concept of choreography, as a means to model the external visible behavior of services has been sketched. Services communicate with each other by exchanging self-contained messages, enabling them to make or to *

Corresponding author. Tel.: +34 91 886 6603. E-mail addresses: [email protected] (S. Arroyo), msicilia@ uah.es (M.-A. Sicilia). 0950-5849/$ - see front matter Ó 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.infsof.2008.01.001

respond to requests. Upon the reception of a message, services react by executing some internal processes and possibly responding with other messages. Depending on the specific requirements of the business model they serve and the application domain for which services were deployed, a number of mismatches can occur which prevent interoperation among a prior compatible services.  Sequence and cardinality of messages exchanges. Services follow different conversational patterns, which define the order and number in which messages are sent and/ or received in a univocal way. A number of scenarios can be sketched that prevent interoperation: a. Messages being sent/received in a different order than expected (Sequence). b. Too many messages being sent that are not compliant with the number expected by the receiving party – e.g. messages being split into smaller ones, extra acknowledgements or control messages – (Cardinality).

S. Arroyo, M.-A. Sicilia / Information and Software Technology 50 (2008) 1266–1280

c. Too few messages are sent that are not compliant with the number expected by the receiving party – e.g. one message containing the content of various others, missing acknowledgements or control messages – (Cardinality).  Structure and format of messages. Services use different conceptualizations and naming conventions for encoding contents and characterizing messages. Even when all the information expected is enclosed in messages, the means to assert compatibility, identify and reorganize the contents and structure of messages and rename messages as appropriate, so they match the conversational model of the receiving party, need to be put in place.  Content semantics. Depending on the application domain services make use of a wide range of terminological conventions to represent concepts encoded into messages and the messages themselves. Prior to effective message exchanges the means to identify equivalent concepts needs to be put in place so messages and the pieces of data they contain can be understood by interacting services. Due to the fact that the semantics, sequence, cardinality, structure and format followed by interacting services is wide, the means to overcome heterogeneities need to be put in place. Current technologies present an ‘‘ad-hoc” approach for overcoming mismatches which need to be improved so services can interact in a more dynamic and decoupled fashion. Likewise the nature of services, the messages exchanged, their content and the patterns followed are characterized by different levels of heterogeneity. Initiatives to overcome mismatches based on semantic descriptions should be envisioned as a core driving force that provides the means to readily overcome heterogeneity by means of mediators. In fact, realizing a choreography service with semantic support for optimizing interoperation among heterogeneous services crafts new challenges and trade-offs. As the number of interacting parties grows, so does the heterogeneity of the conversational patterns and the vocabularies describing particular application domains [1]. Furthermore, many of the assumptions made for traditional approaches, such as, homogeneous and coupled platforms, centralized communications and control, or known in advanced participants are no longer valid in the service-based paradigm. SOPHIE defines a multipart conceptual framework, which puts in place a meditation layer among the message exchanges of heterogeneous Semantic Services. The syntactical model details the syntax of the framework as three different complementary aspects, namely: structural, behavioral and operational. The structural model deals with the provision of a reusable collection of entities following different levels of abstraction. The behavioral model is targeted to the description of the dynamic interaction

1267

among the entities defined in the structural model. The operational model facilitates the means to allow the interoperation among different behavioral models. Finally the semantic model provides the means to describe the structural and behavioral models, in order to produce the structural model as a result of a reasoning task. SOPHIE takes as a grounding concept the decoupled and distributed nature of the web and services. In doing so it does not impose any restriction about a central point of execution and control of the communication among services. Rather, it allows the operational model to be located at a central location, distributed over the web as a service/s, or as an extension to the message interfaces of the parties. The semantic modeling provided by SOPHIE provides the main required mapping mechanisms for logic implementing business integration scenarios that diverge in data structures or sequence of message exchange to serve as a compatibility framework for existing standard business scenarios. This paper presents the evaluation of SOPHIE1 ([2,3]), a conceptual framework for supporting the conceptualization of ontology-based services choreographies realized as a Service-Oriented Architecture. In doing so a three fold approach is taken that considers formal, epistemological and technical aspects. The remaining of the paper is structured as follows. Section 2 shows a high level architecture of the framework, together with the main actors involved and core ideas behind the framework. Section 3 presents a formal evaluation where the consistency, completeness and conciseness of the conceptual model are proved. In doing so, the ontology that summarizes the concepts of the framework and guides the definition and mediation of conversational patterns is checked, with the aim of ensuring that the model is correctly designed. Section 4 introduces the results of an epistemological [16] evaluation that enumerates the improvements and differentiating aspect of this work with respect to related work. Additionally, a complete list of references detailing the application of SOPHIE to different domains (hypermedia, e-Learning, ubiquitous and pervasive computing, etc.) is briefly reviewed. The driving idea is to demonstrate that the approach and framework defined are expressive enough and satisfies the requirements of the wide range of application domains that SOPHIE aims to address. Section 5 deals with the technical aspects of the evaluation, which demonstrates the viability of the approach from the point of view of the engineering process required to allow the interaction of heterogeneous Semantic Services. Consequently, a real use case in the field of telecommunications has been chosen that proves the successful application of the concepts and technology developed in SOPHIE. Finally, Section 6 outlining the conclusions of this research pointing out possible paths that further extends the work.

1

SOPHIE is an acronym for Semantic services chOreograPHi servIcE.

1268

S. Arroyo, M.-A. Sicilia / Information and Software Technology 50 (2008) 1266–1280

Initiating Party

Answering Service

1 generate Operational Model

Choreography Framework

correlate Message 2

remove Operational Model 3

Fig. 1. Choreography service.

2. SOPHIE SOPHIE is a conceptual framework and architecture for a choreography service. Services that use the choreography service fall into two main categories, namely, initiating parties and answering services. Both parties produce and consume messages. Additionally, initiating parties indicate the choreography framework by means of any of its constituent correlating services that the infrastructure for the interoperation of heterogeneous message exchanges should be established. Fig. 1 shows a high level architecture of the conceptual framework. Informally, initiating parties indicate that want to communicate with an answering service by means of ‘‘generateOperationalModel” (1). Once the external2 ontology mapping service has mapped the choreography ontologies for the creation of the operational model that facilitates the interoperation among the heterogeneous message exchanges, parties can start submitting messages by means of the ‘‘correlateMessage” (2) primitive. Messages will go through the designated operational model, forwarding the framework the message(s) to the receiving party according to its choreography. Finally, when the conversation is finished, either party indicates that the operational model for a given conversation can be put off line, by means of the primitive ‘‘remove OperationalModel”. 2.1. Basic principles The conceptual model presented in this thesis describes the structure, behavior, operation and ontologies of conceptual framework for choreography as separate concerns. The semantic model details the semantic support. The structural concern provides the grounding pillars of the framework. The behavioral concern enables to model the conduct of the structural model. Finally, the operational concern facilitates the interoperation of different 2

Notice that the referred ontology mapping service is not part of the SOPHIE framework as such, but rather, SOPHIE communicates with ontology mapping services available to achieve its purpose.

behavioral models. This approach provides straight forward mechanism to extend the different concerns, for example Petri nets, temporal logic or transaction logic can be used instead of Finite State Machines (FSMs) ([8,22]) for the behavioral concern. The work presented here defines the behavioral model as FSMs. Still, any other suitable paradigm can be easily plugged-in. The terms used, in particular the terms choreography, state and guarded transition, follow the formalism proposed in [20,8]. Furthermore, the semantic model is currently based on WSML [17]. Nonetheless, the design supports extending the grammar and ontology of SOPHIE to accommodate any other ontology language. Since the work models a software system that is distributed over the Web and communicates by exchanging messages, some abstractions are needed to represent software services, network nodes, communication, and in general to model the interaction between services. Here the elements of the model are defined. 2.1.1. Entities The generic term entity denotes applications, components, and every active or passive entity inside or outside the choreography framework. Examples of entities are conversations, services – semantic or not –, ontologies, etc. Entities have a name and a location on the net. Passive entities, such as messages, conversations, ontologies, etc can participate in the interaction by means of other active entities. Active entities are linked to a number of passive resources. They are mainly characterized by its ability to communicate autonomously by means of message exchanges. Initiating parties and answering services are active entities (parties) that produce and consume messages in a conversation. Active entities play both roles at the same time. However, initiating parties commence the conversation, while answering services react on the messages received from them. For simplicity both active entities are modeled as separate parties. Additionally, correlating services define active entities that enable interoperation among all other active entities.

S. Arroyo, M.-A. Sicilia / Information and Software Technology 50 (2008) 1266–1280

2.1.2. Conversations A conversation represents the logical entity that enables to group a set of related message exchanges among parties. While a message exchange represents a particular portion of an interchange, a conversation is a container for related message exchanges. Conversations are composed of a number of building blocks. Elements represent elementary data units that build documents. Documents are complete, self-contained groups of elements that are transmitted over the wire within messages. Messages characterize pieces 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 provide the means for modeling its sequence and cardinality defining the order parties send and receive messages. A set of messages sent and received among parties, optionally following Message Exchanged Pattern are referred as message exchange. They characterize a well defined part of a conversation. A conversation can thus be defined as a set of message exchanges among parties with the aim of fulfilling some goal. Every conversation relies upon a communication facility referred as communication network. 2.1.3. Choreographies A choreography describes the behavior of the answering service from the initiating party point of view [20]. It governs the message exchanges among parties in a conversation. A choreography as presented in this work is based on the formalism provided by Finite State Machines (FSMs).3 FSMs enable the specification of sequences of states a choreography goes through during its lifetime, together with its responses to events. In this sense, the main building blocks of finite state machines are up to some extent redrawn. A state is a situation during the lifetime of a choreography during which it waits for some event or satisfies some condition. Conditions are modeled as booleanExpression. Boolean expressions are expressions evaluated to ‘‘true” or ‘‘false” as in any programming or ontology language. An action represents the atomic task of sending a message to a party. Events represent occurrences of stimulus. They do not specify state transitions. Transitions among states are defined by guarded transitions. Guarded transitions model the relations between two states by means of events, actions and guard conditions. Guard conditions are rules that specify a target state. Parts relate guarded transitions and message exchanges, defining the message exchange in terms of state transitions. Finally, a choreography comprises a set of parts that define a conversation.

3 Activities, entry actions and exit actions have been deliberately left out of the scope of the work, as they are not required for purpose of the thesis.

1269

2.1.4. Logic boxes The atomic building blocks that enable to solve the mismatches among interacting parties are referred as logic boxes. A logic box facilitates the means to reorganize the content of documents, their mapping to messages, and the order and cardinality of messages, enabling the interoperation among heterogeneous message exchanges. 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 model the relation among the message exchange pattern followed by the initiating party, and the one used by the answering service. Logic diagrams are assimilated, for implementation purposes, to correspondence tables. A correspondence table is a logical structure, similar to routing tables, which define relations among incoming and outgoing messages as a realization of a logic diagram. A number of logic diagrams defining a conversation are referred as logic group. 2.1.5. Ontologies Ontologies define the concepts and relations that are used within the framework. They facilitate a formal and consensual ([14,15]) vocabulary as data and information machine-processable semantics for the shared and common understanding of a domain [13]. Ontologies can be mediated for the understanding of interacting parties. Domain ontologies supply the general vocabulary to describe the application domain of parties. A choreography model is an ontology that summarizes the concepts and ideas presented in this research. Choreography ontologies import concepts from the choreography model and domain ontologies, making available the terminology that describes the choreography of parties. Ontology mappings characterize the conceptual entity that helps linking similar ontological concepts and instances. 2.2. Related technologies In the following different technologies that are related to the definition of a conceptual framework for choreography are concisely reviewed. In doing so, their core characteristics are presented, their drawbacks are identified and the main ideas reused in this research are summarized. Table 1 presents a preliminary classification along three dimensions. The first dimension depicts the relation with the underlying communication framework, differentiating among tight and loose. The second dimension addresses the semantic support provided. Finally, the third dimension discriminates them depending on whether or not they follow a layered model. Based on these depiction four main categories of languages are distinguished:

1270

S. Arroyo, M.-A. Sicilia / Information and Software Technology 50 (2008) 1266–1280

Table 1 A first cut in classifying related languages Layered model

Relation with communication framework

No

No

Tight

Business Process Languages

Choreography Languages

Loose

Choreography Languages

Semantic-driven choreography initiatives

No

Yes

Yes

SOPHIE

Semantic support

 Technologies with a tight relation to the underlying communication framework, lacking of a layered model and no support for semantics, such as BPEL4WS.  Technologies with a tight relation to the underlying communication framework, which follow a layered model and no support for semantics, such as WS-CDL.  Technologies with a loose relation to the underlying communication framework, lacking of a layered model and no support for semantics, such as WSCI.  Technologies with a loose relation to the underlying communication framework, with support for semantics but lacking of a layered model, such as WSMO-Choreography and IRS-III choreography.

In the following, the evaluation follows frame of reference proposed in [13], which provides a criteria addressing various ontology design problems for various points of view.  Consistency. Checks whether all definitions are consistent and no contradictory knowledge can be inferred from other definitions and axioms.  Completeness. Makes sure that all knowledge that is supposed to be in the ontology is explicitly stated or that it can be inferred.  Conciseness. Ensures that unnecessary definitions and explicit redundancies between definitions do not exist and redundancies can not be inferred.

In [3], a detailed overview of the related languages detailed in Table 1 is presented. 3. Formal evaluation Just like in the case of any other design artefacts formulated for specific purposes [14], ontologies need to be evaluated against objective design criteria before they are used or reused. The aim is to check whether they satisfy the requirements that drove their specification. In so doing, questions aimed at asserting the representation accuracy of the elements with respect to the real world, relations to other ontologies, integration within larger ontologies or truthfulness and consistency, among others need to be addressed [16]. Currently, there is no set of general guidelines or specific ideas on how to evaluate ontologies. However, in order to judge the ontology competence and some design quality criteria, it is generally understood that ontology evaluation should review the developed ontologies and accompanying documentation, ideally against a frame of reference ([13,14]). Such frame should take care of validating the model from the user point of view [7], but also from the domain experts and ontology engineer’s point of view.4 Additionally, the correctness in building the ontology should be verified and validated so it can be ensured that the definitions provided implement and model correctly the requirements of the real world for which the ontology was created. 4 Note that since SOPHIE is a meta-model for the definition of choreographies, the users will be the designers of such choreographies.

3.1. Consistency evaluation In order to perform the consistency evaluation a number of design errors were tried to be identified. Table 2 summarizes the results of this task. In a nutshell, it can be stated that no classes defined as a specialization or generalization of itself were found, that neither exhaustive nor nonexhaustive subclass partition errors where identified, that the taxonomic relations were correctly used from the syntactical viewpoint – confirmed by the test conducted using the WSML Syntactic Validator [24] –, and finally, that the use of the ontology design semantics was right as no incorrect semantic classifications of concepts were discovered. Since none of the described problems were found, it can be stated that the conceptualization presented in Appendix B is consistent. 3.2. Completeness evaluation As far as the completeness evaluation concerns three different aspects were considered. Firstly, the evaluation tried to locate concepts whose classification was incomplete as Table 2 Consistency problems Problem description

Found

Circular definitions Class partition errors Grammatical errors Semantic errors

No No No No

S. Arroyo, M.-A. Sicilia / Information and Software Technology 50 (2008) 1266–1280

they could probably inherit from additional overlooked classes, yielding negative results. Secondly, disjoint omissions dealing with the existence of axioms stating that classes belong to different/additional partitions was addressed. This ontology design aspect is useful for advanced reasoning tasks and classifications. As the former is not required, and the later is explicitly defined by the sub-concept declaration, such axioms were not defined to avoid imposing unnecessary restrictions and increasing complexity. Evidently the evaluation of this aspect threw a positive result, which does not affect the usefulness of the conceptual model for the intended purpose. Finally, exhaustive knowledge omissions were took under consideration. This practice deals with the definition of necessary and sufficient axioms for those sets of classes that exhaustively define another one. In this case, such restrictive practice was not employed, as it seriously hampers the extensibility of the model enforcing every extension to modify some axioms in the original ontology. Obviously, the result of this evaluation provided the same result as previously also not affecting the usefulness and purpose of the conceptual model. Table 3 resumes the main findings regarding the identification of completeness problems. In this case, and from a formal perspective it can not be stated that the ontology presented in Appendix B is complete. However, since the aspects in which the evaluation failed do not limit the applicability and purpose of the model, it can be stated that the ontology is complete for the particular application and purpose for which is intended. 3.3. Conciseness evaluation Conciseness is proved by asserting that the conceptual model does not contain redundant or identical information that is either explicitly defined or that can be inferred. In so doing, direct and indirect redundancies of subclass and instance relations were tried to be identified. The analysis yielded that neither direct nor indirect sub-classing relations were repeated among the same or linked concepts. As the defined ontology does not contain any instances this check obviously threw a negative result. Table 3 Completeness problems Problem description

Found

Incomplete concept classification Disjoint knowledge omission Exhaustive knowledge omission

No Yes Yes

Table 4 Conciseness problems Problem description

Found

Redundant subclass of relations Redundant instance of relations Identical formal definitions of classes Identical formal definitions of instances

No No No No

1271

Based on this analysis it can be stated that the ontology presented in Appendix B is concise. Table 4 summarizes the results of this task. 3.4. Evaluation summary Based on the findings and results of the previously conducted evaluations it can be stated that the ontology presented in Appendix B:  Is syntactically correct, as it successfully passed the WSML Validator tests.  Is concise, as there is no redundant knowledge.  Is complete as far as the intended use concerns.  Is consistent, since the formalized knowledge has been checked against various related sources of knowledge. thus, from a formal point of view the conceptual model detailed in SOPHIE is valid. 4. Epistemological evaluation This part of the chapter presents an epistemological evaluation [16] that tries to cover a two fold purpose. On the one hand, present the main differentiating aspects and improvements introduced by SOPHIE with respect to related work. To achieve this goal, SOPHIE is carefully compared with various choreography-related technologies. On the other, prove that the model presented is expressive enough to face the requirements of the wide range of application domains that SOPHIE aims to address. In this regard, a number of publications where the work has successfully applied are briefly reviewed. 4.1. Differentiating aspects and improvements Generally speaking, abstracting services interaction in terms of the semantic models that build and describe MEPs provides some clear advantages as far as the dynamic interoperation concerns. Various initiatives have already tried, directly or indirectly, to address the choreography problem with different degrees of success. However, a common denominator to all of them is that they represent incomplete solutions that need to be extended in order to provide full support to the service-to-service interaction [3] (See Section 2.2 Related Technologies). In the following, the improvements and differentiating aspects of SOPHIE with respect to all these initiatives are carefully depicted. 4.1.1. BPEL4WS BPEL4WS is related to the work presented in this thesis since abstract processes enable the description of business protocols, which in turn provide a way to define conversations among services. However, it has been primarily designed as a composition language, focusing on the description of collaborative processes – orchestration –,

1272

S. Arroyo, M.-A. Sicilia / Information and Software Technology 50 (2008) 1266–1280

rather than in the detailed description of the external visible behavior – choreography –. Thus, many of the requirements needed to define service-to-service conversations have not been addressed. In BPEL4WS, a number of points requiring further work were identified. In the following particular features added by SOPHIE with respect to this specification are detailed.  BPEL4WS opted for a compact conceptual framework that gathers under the same umbrella structural and behavioral aspects.  BPEL4WS decided not to support the use of MEP as core building block that helps modeling the different aspects involved in choreography.  BPEL4WS currently lacks semantic support and the means to overcome heterogeneity among heterogeneous message exchanges are not defined. Also, to be defined are the methods and techniques that facilitate asserting compatibility among message exchanges.  BPEL4WS choose to have a close relation with the underlying communication framework, namely WSDL and SOAP.  BPEL4WS relies on the use of variables and scopes which are more strongly related to the private behavior of the process than to the external visible one. This results in centralized approach, not always in line with the decoupled nature of services. Additionally, even though, roles might not hold through out the interaction, partners are tied to roles in conversations this could lead to a loss of semantics and therefore complicating the understanding and tracking of message exchanges. Finally, BPEL4WS includes wide support for transactions, which are of course necessary when modeling orchestrations, but less required in the finer grained context of choreographies. 4.1.2. WS-CDL WS-CDL is another effort directed towards addressing issues related with the modeling of message exchanges and the order in which they should occur. It provides an XML-based language for the description of peer-to-peer collaborations between parties by defining, from a global viewpoint, their common and complementary observable behavior. However, the goal is that of providing a language through which message-based interfaces can be described, rather than a fully-fledged choreography framework for the efficient message-based interactions among heterogeneous services. As a consequence, a number of the fundamental principles that drive choreography are missing. The following paragraphs depict the features improved in SOPHIE with respect to the latest WSCDL specification.  WS-CDL is aimed at providing a language to describe message-based interfaces rather than fully fledge choreography framework.

 WS-CDL opted for a design paradigm that tries at the same time to define a model and a XML syntax, not differentiating among structural, behavioral and operational aspects.  WS-CDL supports the recording of semantic descriptions. However, their nature, purpose and use is not yet defined in the specification.  WS-CDL relies on manual support solving heterogeneities and correlating messages.  WS-CDL uses public variables and activities to describe the context of the interaction and to model the functionality of parties respectively. This centralized control mechanism differs with respect the natural decoupling that services follow.  WS-CDL opts for not directly supporting the use of MEPs, understood as a key element for solving heterogeneity among message exchanges.  WS-CDL made the design choice of using channels which seem to add a new restriction to the interaction, which should be overcome by the addressing mechanism of the message exchange. In this direction, the specification also opted for a tight coupling to SOAP and WSDL. Additionally, the explicit association of roles to participants as modeled in relationships constrains the representation of services interaction. Such relation is better favored if it is transparent to the language and dependent only on the particular part of the message exchange conducted. Moreover, the specification currently does not include support policies on how to deal with deadlocks, the means to assert compatibility, the techniques to dynamically generate mediators nor mapping infrastructures. Finally, the interaction follows an asymmetric nature biased towards the receiver rather than the sender, refereeing to the operation performed when information is received, but not the action(s) (or operations) leading to the sending of information [7]. 4.1.3. WSCI WSCI is one of the most complete initiatives dealing with message exchanges among services, even though is not the latest effort. The aim of WSCI is the definition of message dependencies among interacting Web Services taking under consideration sequencing rules and message correlation. Unfortunately, just like in other cases, the specification offers but a few of the different aspects required to provide a complete framework and conversational model. In addition to that, it facilitates only the means to manually describe intermediate mapping models among messages, always from a global point of view. In the following those points where SOPHIE has tried to extend the WSCI specification support are enumerated.  WSCI offers limited coverage for the different aspects involved in defining choreographies since it does not currently provide an extensible conversation metamodel, to enable the description of generic abstractions.

S. Arroyo, M.-A. Sicilia / Information and Software Technology 50 (2008) 1266–1280

 WSCI sketches the concept of state to model behavior. However, the idea seems to be partially integrated in the specification, which could complicate the understanding of the work, especially due to the lack of a clear separation of concerns.  WSCI lacks semantic support and the means to mediate among heterogeneous messages. Intermediate mappings need to be manually generated always considering interactions among services from a global and centralized point of view in clear contradiction with the decoupled nature of services.  WSCI decided to adopt a tight coupling to Web standards (SOAP, WSDL), which prevents the use of other communication framework.  WSCI prefers not to rely on the use MEPs as a means to describe the behavior of parties and cornerstone to solve heterogeneities. Furthermore, the specification includes support for exception handling. Depending on the nature of the exception, should either be supported by the MEPs of interacting parties or not at all in choreography, in case it represents internal and private information not affecting the behavior of the other party or the message exchange. Additionally, the specification supports transactions, which seem to be more related with private implementation aspects than with the modeling of choreographies 4.1.4. WSMO-Choreography WSMO-Choreography is one of the most advanced and developed initiatives dealing with choreography and its issues from a semantic point of view. The overall goal of the specification is that of describing the behavior of services from the user point of view [20]. In the following the main deficiencies of the specification that are improved in SOPHIE are presented.  WSMO-Choreography opted for a compact conceptual dosing where the various models involved in defining choreographies are grouped. It does, however, provide a clear cut between modeling and mediation aspects.  WSMO-Choreography is clearly semantic driven; still the techniques and mechanisms to assert compatibility among message exchanges are not yet fully available.  WSMO-Choreography decided to remain neutral as far as the nature of control concerns, either central or distributed. As can be inferred from related WSMO literature [10], it seems that the specification will be supporting a centralized approach.  WSMO-Choreography chooses not to currently support the use of MEP to describe service-to-service interactions. However, it seems that in a close future the specification will follow this path. The specification clearly shows a great deal of interesting and increasingly mature work. In the future it is foreseen that the currently remaining open issues will be

1273

tackled. It is interesting to notice the similitude among logic boxes and the list of resolvable mismatches as detailed in [10]. 4.2. Application domains In the following, the application domains where SOPHIE has been deployed are described. SOPHIE provides a conceptual framework for integration (data and MEP). Thus, the examples presented in the following deal with integration of services in different application domains. In a nutshell, the SOPHIE framework provided the means to describe the MEPs of interactive parties, assert whether their conversational patterns were compatible and overcome technological differences between interacting parties. 4.2.1. General B2B integration B2B deals with the exchange of messages between trading partners [9]. Successful B2B integration needs to solve message heterogeneity at two different but complementary levels. On the one hand, trading partners define its own data format for the message exchange, resulting in a wide range of formats that need to be supported. On the other, each trading partner follows different B2B protocols, which result in un-compatible message exchange sequences. In order to cope with heterogeneity and enable successful B2B integration, these two aspects need to be overcome. In [6], SOPHIE was applied to a business integration scenario dealing with Request for Quote (RFQ) and Quote process as presented in OAGIS5 (ch. 55.0). This is an archetypical business integration scenario that proceeds in several phases to fulfill the collaboration of a buyer and a supplier in the process of negotiating goods or services. The SOPHIE semantic modeling framework provided the required mapping mechanisms among heterogeneous data conventions and message exchange patterns, probing its usefulness as compatibility framework for standard business scenarios. 4.2.2. Telecommunications Telecommunications is a fast-paced industry characterized by continuous change and fierce competition. Market dynamics change frequently and service providers constantly try to out-do one another with the introduction of novel products and services. To remain competitive service providers need to reduce integration costs. The concepts and principles presented by SOPHIE have proved to be particularly useful in enabling companies to remain competitive. Generally speaking, service providers export different message interfaces and follow heterogeneous data conventions. SOPHIE ([2,3], and [23]) has eased the integration process of new service providers, in this case, within support systems. In short, the SOPHIE 5

http://www.openapplications.org/.

1274

S. Arroyo, M.-A. Sicilia / Information and Software Technology 50 (2008) 1266–1280

framework was used to describe the MEPs patterns of interacting parties and to produce the intermediate models for service-to-service interaction. 4.2.3. e-Learning e-Learning tackles the network-enabled transfer of skills and knowledge. Standardized e-Learning systems are centered on self-standing and reusable content units known as learning objects. As the standards and technology aroundlearning objects evolve new levels of transportability across platforms and communication between objects are required. With the aim of favoring such requirements, learning objects are assimilated with (Web) Semantic Services. However, heterogeneity remains as far as communication platforms and protocols concerns. Taking as starting point the enhanced interoperability facilities made available by the Semantic Web, the concepts and ideas provided by SOPHIE [5] have been reused to overcome communication mismatches while composing learning material. In doing so, SOPHIE facilitated the means to readily solve the natural heterogeneity – data and protocol – among services in the eLearning field as a result of a reasoning task that allowed the generation of mappings among message interfaces. 4.2.4. Ubiquitous, pervasive and context aware Ubiquitous pervasive and context aware computing, deals with the access to information and services from mobile devices. It enables obtaining user-tailored information, filtering the overwhelming flow of data and extracting the relevant and needed knowledge. As information might come from highly heterogeneous and wide spread sources delivered and received following various protocols, applications need to adapt as dynamically as possible to changing situations. In so doing, the means to map and align heterogeneous message contents and communication patterns needs to be available. An education travel use case dealing with mobile applications [4] was presented. Users were guided through Barcelona, receiving relevant information about the environment and important sights from servers following different protocols and data representations. In this scenario, SOPHIE was applied to the definition of the conversational patterns followed by interacting devices, providing a mediation layer that overcame heterogeneity. 4.2.5. Hypertext and hypermedia Open hypermedia systems provide a decoupled approach to structural computing resulting in architectures in which user agents as browsers or other intermediate entities build the structure of hypermedia by communicating with distributed servers. As a result, the consideration of the different MEPs that may be implemented, and the resulting behavior of systems according to them is raised. The general structure of hypermedia facilitated its application to a wide variety of domains.

In this case, SOPHIE has been applied to the description of the structural model of message patterns [2]. Furthermore, the work provided a detailed list of possible courses of system-to-system interaction, which extends the simple request-responses pattern. Finally, the influence of such heterogeneity of communication patterns was analyzed from the perspective of composing structure in hypermedia. This represents a first attempt to advance current Service-Oriented specifications for decoupled hypermedia to cover the heterogeneity of potential system behaviors. 5. Technical feasibility evaluation As a proof of concept, the conceptual model of SOPHIE was implemented as part of the ‘‘Case Study B2B in Telecommunications” deliverable [23] within the DIP project [11]. In this section a detailed description of the use case together with the specific design details of the system are provided. In doing so, the main driving principles of the work are technically evaluated. One of the foundational design principles of SOPHIE is the technological independence. However, it is no possible to provide a working prototype of the work without making some technological choices as far as programming language, communication and implementation frameworks concerns. As implementation framework, the current architecture and technology around the Web and Semantic Services has been taken as a staring point. Regarding the programming language, Java was selected due to its wide acceptance and portability. Regarding the communication framework, the technology around SOAP was considered the most appropriate, due to, on the one hand, the support provided by the programming language, and, on the other, to its wide acceptance and ease of use. Nevertheless, any other combination of available or future implementation and communication frameworks or programming languages could and should also be used, as there is a clear separation of aspects between the core work of SOPHIE and these matters. In traditional approaches, one more choice would need to be made regarding the preferred modeling ontology to describe services and reason about their descriptions, which implicitly affects the Semantic Language and underlying logic formalism. Two main streams are available. On the one hand, OWL [18] and OWL-S [19] provide a complete Description Logic-based approach. On the other WSMO [21] and WSML [17] facilitate a widely accepted F-Logicbased modeling ontology. It is the task of the reasoner to support and understand such descriptions regardless of the underlying semantic language and logic formalism used, providing the mapping among concepts that SOPHIE requires. As currently no reasoners are available that support both paradigms (Description Logic and F-Logic), it was decided to describe services following the WSMO/L approach.

S. Arroyo, M.-A. Sicilia / Information and Software Technology 50 (2008) 1266–1280

In the following, the use case is carefully described and the application of the principles and ideas behind SOPHIE carefully depicted. 5.1. Use case description The use case describes the BT Wholesale B2B Operational Support Systems (OSS) Gateway (AKA eCo) [12], which aims at enabling Telecommunications companies to operate more effectively. It shows how semantically described message interfaces can reduce the time and costs involved in integrating the heterogeneous OSS systems of partner companies, in order to establish a workflow throughout the supply chain. The AKA eCo Platform provides functionality to carry out assurance related operations on BTs network. These are primarily split into four areas:  Network testing. BT provides wholesale network access, which third party suppliers use to provide other services to the customer. If a customer reports a problem with the service, the supplier needs to identify which part of the network that problem resides on, and request a test to check it.  Fault identification/reporting. If a fault is identified with the network, the third party supplier will require that BT identifies the source of the problem and reports back to the supplier on the nature of the problem.  Fault correction. If the problem is identified to be with BT owned network or equipment that cannot be resolved automatically, it is necessary to appoint an engineer to fix the problem.  Provision. If the supplier is providing a product that requires BT to test or activate equipment before it can fulfill the order of a customer, BT will need to provision this functionality. The use case simulates the activities necessary to undertake, after the raising of an error by a Customer of the Service Provider. 5.1.1. Actors involved In the following the actors involved in the use case are presented:  Service Providers. Customers of BT Wholesale. Service Providers have customers of products partially dependent on services bought from BT Wholesale. They provide on-line customer support in the case of malfunctioning equipment or faulty services.  Customer. Customer of the service provider. They can raise errors with its service provider by using the customer support system.  BT Wholesale. Provider of wholesale telecommunications equipment and services. Should a customer raise an error with its service provider, the provider can

1275

request certain tests to be made by BT Wholesale, to assure that it is not their equipment or services responsible for the error.  B2B Integration Platform. It uses SOPHIE to implement an interoperation layer that helps heterogeneous OSS to be integrated in the BT Wholesale supply chain. Fig. 2 facilitates a graphical view of the Network Testing functionality of the use case. 5.1.2. Use case realization The exact procedure involved in the current realization of this use case goes as follows. Each customer of BT Wholesale needs to be able to raise a request for BT to perform a test on its network. Each message is the service providers request to conduct a test on BTs network or BT’s response to such requests. The process will return either the result of this test or details of any errors that occurred, (e.g. the test has been rejected). If the request is rejected, the customer is provided with the failure reason. Fig. 3 shows a sequence diagram of the current solution. Grounding this in the use case, the Service Provider, BT, publishes its B2B integration services (including Assurance, Fulfillment and Billing services). Service Requesters then follow their own conversational patterns defined as part of their Semantic Services interface to make service requests to BT [12]. Therefore, allowing differing choreographies to be used by communicating parties. SOPHIE was used to describe interacting choreographies, evaluate them in order to determine their compatibility and create run-time correlating services that carry out the mapping required between the differing conversational patterns of interacting services. 5.2. SOPHIE implementation In the following, the details on how SOPHIE has been applied to solve the heterogeneity problems is presented. The domain and individual choreography ontologies of interacting services, together with the most relevant aspects of the services themselves are presented. Furthermore, the details of the mappings and correspondence tables that enable the bidirectional communication are depicted. 5.2.1. Domain ontologies Domain ontologies are used to represent specific party information that details the meaning of the concepts used in messages, relating them to their meaning in a particular application domain. In this case, the domain ontology is a conceptualization of the data passed between the users of the assurance integration functionality of eCo. In the Telecommunications Sector the Tele Management Forum (TMF)6 has defined a data model known as the SID (Shared Information Data) that represents a static 6

http://www.tmforum.org/.

1276

S. Arroyo, M.-A. Sicilia / Information and Software Technology 50 (2008) 1266–1280

Fig. 2. Assurance integration use case: Network Testing use case.

Fig. 3. B2B assurance integration sequence diagram for any test request.

view on the data and business entities used in telecommunications. Where possible, concepts in the domain ontology that can be related to entities in the SID have been defined such that they either directly subclass a SID concept and then extend where necessary, or define relationships between existing SID concepts. The full domain ontology can be found in Appendix 1 of the ‘‘Case Study B2B in Telecommunications” deliverable [12]. Table 5 shows a fraction of the trading partner and BT domain ontologies, tPOnt and eCo. The trading partner ontology (tPOnt) contains a concepts ‘‘testParameter”, ‘‘testResult”, ‘‘testPerformer” and ‘‘testCategory”. The BT ontology (eCo) contains equivalent concepts ‘‘parameter”, ‘‘result”, ‘‘performer” and ‘‘category”. 5.2.2. Choreography SOPHIE7 has provided the paradigm used to define the choreographies of the trading partners and BT as Whole7

The evaluation focuses at the message exchange level as it is considered enough to prove the consistency of the model. In later versions of the work, probably full conversations will be exemplified.

sale Provider. Using the previously defined domain ontology and the choreography ontology model defined in Appendix B, it is possible to specify a choreography that depicts the structural and behavioral models. To do so, it imports from both (domain and model choreography) ontologies. Fig. 4 shows the MEPs followed by both interacting parties. If the service provider were to use a different MEP and terminology than BT Wholesale, then the operational model of SOPHIE can be applied. In this case, the Service Provider uses the message exchange tPontTestRequest following the MEP request-response while BT Wholesale makes use of the message exchange eCoTestRequest following theIn-Multi-Out one. More concretely, the Service provider starts the message exchange with the MRequest message, while BT Wholesale expects the message testRequest. Additionally, BT provides two different response message (failure and success), indicating whether the test was accepted or rejected, and if accepted, the result of the test, while the Service Provider awaits the reception of a single message named MCompleted accounting for both of them.

S. Arroyo, M.-A. Sicilia / Information and Software Technology 50 (2008) 1266–1280

1277

Table 5 Example of the domain ontologies tPOnt and eCo concept testParameter nonFunctionalProperties dc#description hasValue”in parameter” endNonFunctionalProperties

concept parameter nonFunctionalProperties dc#description hasValue”test parameter” endNonFunctionalProperties

concept testResult nonFunctionalProperties dc#description hasValue”out parameter” endNonFunctionalProperties

concept result nonFunctionalProperties dc#description hasValue”test result” endNonFunctionalProperties

concept tesPerformer subConceptOf legalPerson nonFunctionalProperties dc#description hasValue”Gateway user conducting specific Tests” endNonFunctionalProperties

concept performer nonFunctionalProperties dc#description hasValue”Gatway User performing a request” endNonFunctionalProperties

concept testCategory nonFunctionalProperties dc#description hasValue”category of the test” endNonFunctionalProperties

concept category nonFunctionalProperties dc#description hasValue”test category” endNonFunctionalProperties

Service Provider

BT Wholesale testRequest

Table 6 Service Provider structural model Elements

testPerformer (testPerformerCustomerID, testPerformerPartyID), testConductor (testConductorAgencyID, testConductorPartyID), testReference (testIdentifier, testDate), testCategory, testParam1, testParam2, . . ., testParamn, testResult1, testResult2, . . ., testResultn, testOK

Documents

DRequest, DCompleted

Messages

MRequest, MCompleted

Documents-Elements mapping

DRequest. {testPerformer, testConductor, testReference, testCategory, testParameters} DCompleted. {testReference, testCategory, testOK, testResults}

Messages-Documents mapping

MRequest. {DRequest} MCompleted. {DCompleted}

MRequest failure success MCompleted

Fig. 4. Request–response and in-multi-out message exchange pattern.

5.2.2.1. Structural model. The test requester follows the message exchange ‘‘request-response” based on the structural model8tPontStr, detailed in Table 6. The test conductor follows the message exchange ‘‘inmulti-out” which uses the structural model eCoStr, detailed in Table 7. 5.2.2.2. Behavioral model. As far as the behavioral model concerns, Table 8 depicts the most relevant entities required to assert interoperability among the behavioral models tPontBhv and eCoBhv. 5.2.2.3. Choreography ontologies. Table 9 shows a fraction of choreography ontologies tPontChor and eCoChor for the initiating party (Service Provider) and answering service (BT Wholesale) respectively. It depicts some elements, documents, boolean expressions and actions as used by the parties to model a message exchange.

8 With the aim of facilitating the reader understanding testPerformer, testConductor, testReference are presented at this point as complex data structure. However, as far as SOPHIE concerns they are single elements, built as a result of the concatenation of their constituents. The same principle applies to the elements performer, conductor and reference of the BT Wholesale structural model.

Table 7 BT Wholesale structural model Elements

performer (customerID, performerPartyID), conductor (agencyID, conductorPartyID), reference (identifier, date), category, parameter1, parameter2, . . ., parametern, result1, result2, . . ., resultn, accepted

Documents

requestDoc, successDoc, failureDoc

Messages

testRequest, failure, success

Documents-Elements mapping

requestDoc. {performer, conductor, reference, category, parameters} successDoc. {reference, category, accepted, results} failureDoc. {reference, category, accepted}

Messages-Documents mapping

testRequest. {requestDoc} success. {successDoc} failure. {failureDoc}

1278

S. Arroyo, M.-A. Sicilia / Information and Software Technology 50 (2008) 1266–1280

Table 8 Behavioral model of both parties

Actions Boolean Expressions

Service Provider

BT Wholesale

SendMRequest receiveMCompleted

outFailure, OutSuccess RecTestRequest

5.2.2.4. Compatibility. The service provider defines the structural model for compatibility as the entities:  / = {testPerformer, testPerformerCustomerID, testPerformerPartyID, testConductor, testConductorAgencyID, testConductorPartyID, testReference testIdentifier, testDate, testCategory, testParam1, testParam2, . . ., testParamn, testResult1, testResult2, . . ., testResultn, testOK} where / =ˆ /.  r = {DRequest, DCompleted} where r =ˆ r.  d = {MRequest, MCompleted} where d =ˆ d. and the message exchange pattern ‘‘request-response”, to model the external behavior as the actions and boolean expressions:  a = {sendMRequest}, ˆa = {sendMRequest}  b = {receiveMCompleted}, ˆb = {receiveMCompleted} BT defines the structural model for compatibility as the entities:

 /0 = {performer, customerID, performerPartyID, conductor, agencyID, conductorPartyID, reference, identifier, date, category, parameter1, parameter2, . . ., parametern, result1, result2, . . ., resultn, accepted}, where /0 =ˆ /0 .  r0 = {requestDoc, successDoc, failureDoc}, where r0 =ˆ r0 .  d0 = {testRequest, failure, success}, where d0 =ˆ d0 . And the message exchange pattern In-Multi-Out, to model the external behavior, as the following actions and Boolean expressions:  a0 = {outFailure, outSuccess} and the sufficient set 0 ˆ a0 = {outFailure, outSuccess}  b = {recTestRequest} and the sufficient set 0 b = {recTestRequest} ˆ Both parties make available their domain and choreography ontologies, tPont, eCo, tPontChor and eCoChor respectively. The mapping function WX defines the following entities as compatible:  ˆ /, ˆ/0 : {testPerformer}  {performer} {testPerformerCustomerID}  {customerID} {testPerformerPartyID}  {performerPartyID} {testConductor}  {conductor} {testConductorAgencyID}  {agencyID} {testConductorPartyID}  {conductorPartyID}

Table 9 Fragment of the choreography ontologies tPontChor, eCoChor concept testPerformer subconceptOf {K#element, tPont#testPerformer}

concept: performer subconceptOf {K#element, eCo#tperformer}

concept testParameter subconceptOf {K#element, tPont#testParameter}

concept parameter subconceptOf {K#element, eCo#parameter}

concept testResult subconceptOf {K#element, tPont#testResult}

concept result subconceptOf {K#element, eCo#result}

concept testCategory subconceptOf {K#element, tPont#testCategory}

concept category subconceptOf {K#element, eCo#category}

concept DRequest subconceptOf {K#documenty}

concept requestDoc subconceptOf {K#document}

concept DCompleted subconceptOf {K#document}

concept succesDoc subconceptOf {K#document} concept failureDoc subconceptOf {K#document}

concept MRequest subconceptOf {K#message, tPont#testRequest}

concept testRequest subconceptOf {K#message, eCo#requestMessage}

concept sendMRequest subconceptOf {K#action}

concept recTestRequest subconceptOf {K# booleanExpression}

concept receiveMCompleted subconceptOf {K#booleanExpression}

concept outFailure subconceptOf {K#action} concept outSuccess subconceptOf {K#action}

S. Arroyo, M.-A. Sicilia / Information and Software Technology 50 (2008) 1266–1280

{testReference}  {reference} {testIdentifier}  {identifier} {testDate}  {date} {testCategory}  {category} {testParam1}  {parameter1} {testParamn}  {parametern} {testResult1}  {result1} {testResultn}  {resultn} {testOK}  {accepted}  ˆr, ˆr0 : {DRequest}  {requestDoc} {DCompleted}  {successDoc, failureDoc}  ˆd, ˆd0 : {MRequest}  {testRequest} {MCompleted}  {success, failure}  ˆa, ˆa0 , ˆb andˆ b0 : {sendMRequest}  {recTestRequest} {receiveMCompleted}  {outSuccess, outFailure} Given the above it can be deduced that there exists a covering relation among the sufficient sets of the structural models, and among the sufficient sets of the behavioral models of both message exchanges. The covering relation implies that the structural and behavioral entities of both messages exchanges are contained in the structural and behavioral entities of each other’s model, under the mapping function WX . As a consequence, both message exchanges are structurally compatible, expressed as tPontStrHSW eCoStr. Additionally, they are behaviorally compatible expressed as tPontBhvHBW tCoBhv. Thus, it can be concluded that both message exchanges are compatible, expressed as tPontTestRequestHCW eCoTestRequest. Since both message exchanges are compatible, there exists a logic diagram which allows mapping the content, sequence and cardinality of both message exchanges. Taking as input ontological mapping WX, the operational model that allows overcoming the heterogeneities of the parties can be produced. Fig. 5 details such model. A refiner box is used to map the elements and documents within the message ‘‘MRequest” to the message ‘‘testRequest” as expected. Additionally, a select box was put in place to map the elements and documents used in the messages ‘‘failure” and ‘‘success” to the message ‘‘MComplete” containing the document ‘‘DCompleted”. Figure 6.4 shows the resulting logic diagram. 5.2.2.5. Correspondence tables. The logic diagram detailed in Fig. 4 is implemented using two correspondence tables.

MRequest

R

MCompleted

S

testRequest

failure

Table 10 Service Provider correspondence table l

l0

MRequest.DRequest.testPerformer MRequest.DRequest.testConductor MRequest.DRequest.testReference MRequest.DRequest.testCategory MRequest.DRequest.testParameters

testRequest.requestDoc.performer testRequest.requestDoc.conductor testRequest.requestDoc.reference testRequest.requestDoc.category testRequest.requestDoc.parameter

Table 11 BT Wholesale correspondence table l

l0

failure.failure.Doc.reference failure.failure.Doc.category failure.failure.Doc.accepted – success.successDoc.reference success.successDoc.category success.successDoc.accepted success.successDoc.results

MCompleted.DCompleted.testReference MCompleted.DCompleted.testCategory MCompleted.DCompleted.testAccepted MCompleted.DCompleted.testResults MCompleted.DCompleted.testReference MCompleted.DCompleted.testCategory MCompleted.DCompleted.testAccepted MCompleted.DCompleted.testResults

Table 12 APIs and functionality of related components Class

Functionality

Data Mediator OntologyResourceManager Registry

Design and run time mediation Storage and retrieving of ontologies Storage and retrieving Semantic Service descriptions

One for the messages sent by the Service Provider and received by BT Wholesale, and another one for the messages sent by BT Wholesale and received by the Service Provider. Table 10 implements the refiner box that maps the ‘‘MRequest” and its contents to the ‘‘testRequest” one, as expected by BT Wholesale. Table 11 implements the select box that maps the ‘‘failure and ‘‘success” messages and its contents to the ‘‘MCompleted” one, as expected by the Service Provider. Notice that the ‘‘failure” message does not send a result element, thus the correspondence table uses the wild card ‘‘-” to accommodate the outgoing element and value. 5.2.3. APIs and functionality of related components The proposed prototype needs to interact with a number of Services. To do so, the API details of such components need to be known. Table 12 provides description of the top level classes of the API that the prototype uses. The first column gives the name of the class, while the second summarizes the features intended for that part of the API. The full definition of the individual components API is available on SourceForge9.

success

Fig. 5. Resulting logic diagram.

1279

9 https://sourceforge.net/project/showfiles.php?group_id=113321& package_id=154563.

1280

S. Arroyo, M.-A. Sicilia / Information and Software Technology 50 (2008) 1266–1280

6. Conclusion and future work This paper has presented the evaluation of SOPHIE following a three fold approach that considers formal, epistemological and technical aspects. The formal evaluation proved the consistency, completeness and conciseness of ontological model used. Such model was found syntactically correct, concise, complete and consistent. Thus, it was stated that from a formal point of view the conceptual model detailed in SOPHIE is valid. The epistemological evaluation enumerated the improvements and differentiating aspect of SOPHIE with respect to existing related work. Additionally, a number of publications where the work was successfully applied were briefly reviewed. By these means it was proved that the model presented is expressive enough to face the requirements of the wide range of application domains SOPHIE aims to address. The technical feasibility evaluation demonstrated the viability of the approach from the point of view of the engineering process required to allow the interaction of heterogeneous Semantic Services. A detailed description of a use case part of the DIP [11] project where SOPHIE was successfully applied was depicted. Thus, it was stated that from a technical point of view the conceptual model detailed in SOPHIE is feasible. Future work should deal with improving the abilities of the choreography service to, by extending the different conceptual models with the addition of new formalisms remains open. Also, the definition of a mapping language that permits executing an operational model in traditional workflow engines represents an interesting research field. Areas of this work that definitely need to be researched are the assessment of performances, QoS and security, as the discussion about these topics is well out of the scope of the work. In addition to that, the extension to support different communication frameworks constitutes an interesting research area. Furthermore, the inclusion of support for a full range of data types is an obvious requisite that needs to be tackled. In addition to the work presented here, it would be interesting to realize a real implementation of SOPHIE that extends the current prototype. From a different perspective, the study of the application side is also an open door. This would involve the characterization of the requirements that application domains pose on the conceptual framework, plus the development of a methodology for the design of choreographies that integrates well-established business specifications such as ebXML. Moreover, a choreography editor for such methodology supporting the reuse and modification of conversational patterns such as OAGSIS, could extend the work. References [1] S. Arroyo, H. Sung-Kook, D. Fensel, Searching for semantic web services. A Google based approach, Journal of Digital Information Management (JDIM), 0972-7272 3 (3) (2005).

[2] S. Arroyo, J.M. Lo´pez Cobo, M. Sicilia, Patterns of message interchange in decoupled hypermedia systems, Journal of Networks and Computer Applications. (To appear 2008). [3] S. Arroyo, A. Duke, J.M. Lo´pez-Cobo, M.A. Sicilia, A model-driven choreography conceptual framework, Computer Standards & Interfaces 29 (2006) 325–334. [4] S. Arroyo, R. Kummenacher, A choreographed approach for ubiquitous and pervasive learning, in: Miltiadis D. Lytras, Ambjorn Naeve (Eds.), Ubiquitous and Pervasive Knowledge and Learning Management: Semantics, Social Networking and New Media to Their Full Potential, IDEA Group Inc., 2007, ISBN 1599044846. [5] S. Arroyo, SOPHIE – modeling choreographies: prospects for application to learning objects, Learning Objects and Learning Designs 1 (2) (2005). [6] S. Arroyo, M.A. Sicilia, J.M. Dodero, Choreography frameworks for business integration: addressing heterogeneous semantics. Computers in Industry 2007, Computers in Industry 58 (2007) 487–503. [7] A. Barros, M. Dumas, P. Oaks, A critical overview of the web services choreography description language (WS-CDL), BPTrends (March) (2005). [8] G. Booch, J. Rumbaugh, I. Jacobs, The Unified Modelling Language User Guide, Addison-Wesley, 1999. [9] C. Bussler, B2B Integration – Concepts and Architecture, SpringerVerlag, 2003. [10] E. Cimpian, A. Mocan, D13.7 v0.1 Process Mediation in WSMX. WSMX Working Draft. Available from: , July 2005, 2005. [11] DIP-Data, Information, and Process with Semantic Web Services. Available from: . [12] A. Duke, C. Mack, B. Peissl, A. Wahler, S. Watkins, C. Wouters, D8.2: Platform Requirements Specification, DIP Project, WP8 B2B in Telecommunications. Available from: . [13] D. Fensel, Ontologies: Silver Bullet for Knowledge Management and Electronic Commerce, Springer-Verlag, Berlin, 2001. [14] T.R. Gruber, A translation approach to portable ontology specifications, Knowledge Acquisition 5 (1993) 199–220. [15] T.R. Gruber, Toward principles for the design of ontologies used for knowledge sharing, Interantional Journal of Human-Computer Studies 43 (5/6) (1995) 907–928. [16] A. Maedche, B. Motik, Lj. Stojanovic, R. Studer, R. Volz, Ontologies for enterprise knowledge management, IEEE Intelligent Systems 18 (2) (2003) 26–33. [17] J. de Bruijn, H. Lausen, R. Krummenacher, A. Polleres, L. Predoiu, D. Fensel, The WSML Family of Representation Languages. Available from: , 2005. [18] OWL Web Ontology Language Overview, W3C Recommendation. Available from: , February 2004. [19] OWL for Services. Available from: , 2003. [20] D. Roman, J. Scicluna, C. Feier, in: M. Stollberg, D. Fensel, (Eds.), D14v0.1. Ontology-based Choreography and Orchestration of WSMO Services. Available from: , March, 2005. [21] D. Roman, H. Lausen, U. Keller, (Eds.), Web Service Modeling Ontology. WSMO Working Draft v0.3. Available from: , 2004. [22] F. Wagner, Modeling Software with Finite State Machines: A Practical Approach, Auerbach Publications, 2006. [23] S. Watkins, S. Arroyo, A. Duke, M. Richardson, B. Schreder, A. Wahler, D8.3: WP 8: Case Study B2B in Telecommunications”, DIP (Data, Information and Processes) Project, WP8 B2B in Telecommunications. Available from: . June 2005. [24] WSML Validator V1.2 (d16.1v02). Available from: , March, 2005.