Automated Synthesis of Mediators to Support Component ... · to Support Component Interoperability ... mediation based on pre-deﬁned patterns but without ensuring that such mediation

HAL Id: hal-01076176https://hal.inria.fr/hal-01076176

Submitted on 21 Oct 2014

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

Automated Synthesis of Mediators to SupportComponent Interoperability

Amel Bennaceur, Valérie Issarny

To cite this version:Amel Bennaceur, Valérie Issarny. Automated Synthesis of Mediators to Support Component In-teroperability. IEEE Transactions on Software Engineering, Institute of Electrical and ElectronicsEngineers, 2015, pp.22. �hal-01076176�

https://hal.inria.fr/hal-01076176

https://hal.archives-ouvertes.fr

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING 1

Automated Synthesis of Mediatorsto Support Component Interoperability

Amel Bennaceur and Valerie Issarny

Abstract—Interoperability is a major concern for the software engineering field, given the increasing need to compose components

dynamically and seamlessly. This dynamic composition is often hampered by differences in the interfaces and behaviours

of independently-developed components. To address these differences without changing the components, mediators that

systematically enforce interoperability between functionally-compatible components by mapping their interfaces and coordinating

their behaviours are required. Existing approaches to mediator synthesis assume that an interface mapping is provided which

specifies the correspondence between the operations and data of the components at hand. In this paper, we present an approach

based on ontology reasoning and constraint programming in order to infer mappings between components’ interfaces automatically.

These mappings guarantee semantic compatibility between the operations and data of the interfaces. Then, we analyse the

behaviours of components in order to synthesise, if possible, a mediator that coordinates the computed mappings so as to make

the components interact properly. Our approach is formally-grounded to ensure the correctness of the synthesised mediator.

We demonstrate the validity of our approach by implementing the MICS (Mediator synthesIs to Connect Components) tool and

experimenting it with various real-world case studies.

Index Terms—Interoperability, Constraint Programming, Automated Synthesis, Mediators, Protocols

✦

1 INTRODUCTION

Interoperability is a fundamental challenge for soft-ware engineering [1]. Today’s systems are increasinglydeveloped by reusing and integrating existing com-ponents. However, even though these componentsshould be able to integrate since, at some high levelof abstraction, they require and provide compatiblefunctionalities, the conflicting assumptions that eachof them makes about its running environment hindertheir successful interoperation. Indeed, componentscannot readily be reused when inconsistent semanticsare buried in their interfaces or behaviours [2].

There exists a wide range of approaches to en-able independent components to interoperate [3],[4]. Solutions that require performing changes tothe components are usually not appropriate sincethe components to be integrated may be built bythird parties (e.g. COTS—Commercial Off-The-Shelf—components or legacy systems); no more appropriateare approaches that prune the behaviour leading tomismatches since they also restrict the components’functionality [5]. Therefore, many solutions that ag-gregate the disparate components in a non-intrusiveway, i.e. without changing the internal implementationof these components, have been proposed [4], [6]–[9]. These solutions use intermediary middleware

• A. Bennaceur is with the Department of Computing, The OpenUniversity, United Kingdom. This work was performed during herPhD studies at Inria.E-mail: [email protected]

• V. Issarny is with the MiMove team, Inria, France.E-mail: [email protected]

entities, called mediators [10], [11] (also called connectorwrappers [6] or mediating adapters [7]), to connectheterogeneous components despite disparities in theirdata and/or interaction models by performing thenecessary coordination and translations while keepingthem loosely-coupled.

Nevertheless, creating mediators requires a substan-tial development effort and a thorough knowledgeof the application-domain. Moreover, the increasingcomplexity of today’s software components, sometimesreferred to as Systems of Systems [12], makes it difficultto develop ‘correct’ mediators manually [13]; correctmediators guarantee that the components interactwithout errors (e.g. deadlocks) and reach their ter-mination successfully. Therefore, formal approachesare necessary to characterise components precisely,reason about their interaction, and generate mediatorsautomatically [7], [14].

First, automatically generating mediators helps de-velopers to manage the bulk of the systems they needto integrate. Indeed, developers increasingly have toincorporate to their systems convenient services suchas instant messaging or social interaction. Although,most of these services provide similar functionalities,their interfaces are usually heterogeneous. For example,Google Talk and Facebook chat both have instantmessaging capabilities but expose them using differentinterfaces. Similarly, Facebook and Google+ allowsocial interaction between their users using distinctinterfaces. By providing an automated mediationsolution, developers no longer have to struggle withheterogeneous interfaces since the generated mediatorsperform the necessary translations to compensate for


the differences between these interfaces. The auto-mated generation of mediators also enables seamlessand spontaneous interaction between components inhighly dynamic and extremely heterogeneous envi-ronments by computing, at runtime, a mediator thatensures their interoperation.

Existing approaches to the automatic generation ofmediators assume the correspondence between theoperations of the mediated components to be givenin terms of an interface mapping [14] (also called adap-tation contract [7]). Identifying such correspondencerequires not only knowledge about the componentsbut also knowledge about the domain itself.

Research on knowledge representation and artificialintelligence has now made it possible to model andautomatically reason about domain information pre-cisely, if not with the same nuanced interpretation thata developer might [15]. In particular, ontologies buildupon a sound logical theory to provide a machine-interpretable means to reason, automatically, about thesemantics of data based on the shared understandingof the domain [16]. They play a valuable role insoftware engineering by supporting the automatedintegration of knowledge among teams and projectstakeholders [17]. Ontologies have also been widelyused for modelling Semantic Web Services and achiev-ing service discovery and composition [18]. OWL-S(Semantic Markup for Web Services) uses ontologiesto model both the functionality of a Web Service andthe associated behaviour, i.e. the protocol according towhich this Web Service interacts [19]. Besides ontology-based modelling, WSMO (Web Service ModellingOntology) relies on ontologies to support runtimemediation based on pre-defined patterns but withoutensuring that such mediation does not lead to an erro-neous execution (e.g. deadlock) [20]. Hence, althoughontologies have long been advocated as a key enablerin the context of service mediation, no principled ap-proach has been proposed for the automated synthesisof mediators by systematically exploiting ontologies.We argue that interoperability should not be achievedby defining yet another ontology nor yet anothermiddleware but rather by exploiting the knowledge en-coded in existing domain-specific ontologies togetherwith the behavioural description of components andusing them to generate mediators automatically. Thesemediators bridge the interoperability gap betweenheterogeneous components by delivering informationwhen it is needed, in the right format, with the originalbusiness context intact.

This paper focuses on functionally-compatible com-ponents, i.e. components that at some high level ofabstraction require and provide compatible function-alities, but are unable to interact successfully due tomismatching interfaces and behaviours. This paperconcentrates on service-based components (e.g. WebServices) rather that code-based components (e.g. Java

libraries). We propose an approach that combinesontology reasoning and constraint programming inorder to generate a mapping between the interfacesof these components. Then, we use the generatedmappings and examine the behaviours of both com-ponents to automatically synthesise a mediator thatensures their safe interaction. The mediator, if it exists,enables the components to progress synchronouslyand reach their final states with the guarantee that thecomposed system is free from deadlocks. Specifically,our contributions are:

• Efficient interface mapping using semantic reasoningand constraint programming. We reason about thesemantics of data and operations of each compo-nent and use a domain ontology to identify thesemantic correspondences between the interfacesof the components, i.e. interface mapping. Inter-face mapping guarantees that operations fromone component can safely be performed usingoperations from the other component.

• Automated synthesis of mediators. We explore the be-haviours of the two components and generate themediator that composes the computed mappingsso as to force the components to progress syn-chronously. The mediator, if it exists, guaranteesthat the mediated system is deadlock-free.

• Tool-support for automated mediation. We furtherdemonstrate the feasibility of our approachthrough the MICS (Mediator Synthesis to ConnectComponents) tool and illustrate its usability usingreal-world case studies involving heterogeneouscomponents. Our semantic-based approach to theautomated generation of mediators leads to a con-siderable increase in the quality of interoperabilityassurance between heterogeneous components:it removes the programming effort and ensuresthat the components interact successfully whilepreserving efficient execution time.

This paper is organised as follows. Section 2 intro-duces the interoperable file management example thatillustrates the need for mediators to facilitate interoper-ation between independently-developed components.It also presents the formalism we use to specify ourinputs, which consists of ontologies to model domainknowledge and labelled transition systems to modelthe behaviour of components. Section 3 moves intothe solution space, defining the formal methodologyto compute interface mapping efficiently. Section 4describes the algorithm used to generate mediators.Section 5 presents the MICS tool used to synthesisemediators and deploy them in the environment. Sec-tion 6 reports on the experiments we conducted tovalidate our approach. Section 7 examines relatedwork. Section 8 discusses future work. Finally, Section 9concludes the paper.


2 INTEROPERABILITY USING MEDIATORS

To highlight the problem of interoperability in dis-tributed systems, we examine the case of two heteroge-neous file management systems: WebDAV and GoogleDrive. We present the models we use to describe themand outline our approach for the automated synthesisof mediators that enable the successful interoperationof these systems despite differences in their interfacesand behaviours.

2.1 The Interoperable File Management Example

The migration from desktop applications to Web-basedservices is scattering user files across a myriad ofremote servers (e.g. Apple iCloud, Google Drive, andMicrosoft Skydrive). This dissemination poses newchallenges for users, making it more difficult for themto organise, search, and manipulate their files usingtheir preferred applications, and share them withother users. This situation, though cumbersome froma user perspective, unfortunately reflects the way filemanagement applications—like many other existingapplications—have evolved. As a result, users areforced to juggle between a plethora of applicationsto manage their files instead of using their favouriteapplication regardless of the service it relies on or thestandard on which it is based.

Among the protocols allowing collaborative man-agement of files, WebDAV (Web Distributed Authoringand Versioning) is an IETF specification that extendsthe Hypertext Transfer Protocol (HTTP) to allow usersto create, read and change documents remotely. Itdefines a set of properties to query and manageinformation about these documents, organise themusing collections, and defines a locking mechanismin order to assign a unique editor of a documentat any time. Another example is the Google Driveservice that lets users create, store, and search Googledocuments and collections. It also allows users toshare and collaborate online in the editing of thesedocuments. These functionalities can be accessed usinga Web browser or using the Google proprietary API.

WebDAV to Google Drive Mediator

Fig. 1. Connecting a WebDAV client to Google Drive service

Although WebDAV and Google Drive offer simi-lar functionalities and use HTTP as the underlyingtransport protocol, they are unable to interoperate. Forexample, a user cannot access his Google Drive doc-uments using his favourite WebDAV client (e.g. MacFinder) as depicted in Figure 1. This is mainly dueto the syntactic naming of data and operations usedin each application, and the protocols according to

which these operations are performed. Our goal isto synthesise a mediator automatically in order toallow these two components to interact properly. Inorder to reason about component interoperability andautomatically synthesise the mediator, we need tomodel the components and their domain as describedin the following.

2.2 Modelling Domains using Ontologies

Each application domain has its own vocabulary. Thisvocabulary has to be modelled explicitly in orderto allow computers to conduct automated reasoningabout the domain. Ontologies provide experts with ameans to formalise the knowledge about the domainas a set of axioms that make explicit the intendedmeaning of a vocabulary [21]. Besides general purposeontologies, such as dictionaries (e.g. WordNet1), thereis an increasing number of ontologies available forvarious domains such as biology, geoscience, and socialnetworks, which in turn foster the development ofa multitude of search engines specially targeted forontologies on the Web [22].

Ontologies are supported by a logic theory toreason about the properties and relations holdingbetween the various domain entities. In particular,OWL (Web Ontology Language2), which is the W3Cstandard language to model ontologies, is based ondescription logics. More specifically, we focus on OWLDL, which is based on a specific description logic,SHOIN (D) [16]. In the rest of the paper, DL refersto this specific description logic.

While traditional formal specification techniques(e.g. first-order logic) might be more powerful, DL of-fers crucial advantages: it excels at modelling domain-specific knowledge while providing decidable andefficient reasoning algorithms [23]. DL specifies thevocabulary of a domain using concepts and relation-ships between these concepts. Each concept is given adefinition as a set of logical axioms, which can eitherbe atomic or defined using different operators suchas disjunction (⊔), conjunction (⊓), and quantifiers(∀, ∃). Relationships between concepts are definedusing object properties. The semantics of DL is definedin terms of an interpretation I consisting of a non-empty set ∆I (the domain of the interpretation) and aninterpretation function, which assigns to every atomicconcept A a set AI ⊆ ∆I and to every object propertyR a binary relation RI ⊆ ∆I × ∆I . We provide anoverview of the semantics of the basic DL operatorsin Table 1 and refer the interested reader to [16] forfurther details.

For example, consider the extract of the file man-agement ontology depicted in Figure 2. We buildthis ontology by extending the NEPOMUK FileOntology.3 The NEPOMUK File Ontology (NFO)

1. http://www.w3.org/TR/wordnet-rdf/2. http://www.w3.org/TR/owl2-overview/3. http://www.semanticdesktop.org/ontologies/nfo/


<<OWLClass>>MoveFile

≐ ReadFile ⨁ WriteFile ⨁ DeleteFile

<<OWLClass>>Document

≐ Presentation SpreadSheet TextDocument

MindMap BolbDocument

isPartOf{some}

<<OWLClass>>Resource

≐ File Collection

<<OWLClass>>TextDocument

<<OWLClass>>SpreadSheet

<<OWLClass>>Presentation

<<OWLClass>>MindMap

<<OWLClass>>BolbDocument

<<OWLClass>>ResourceProperties

∃Title.String

∃CreationDate.Date

∃LastUpdate.Date

∀Notes.String

hasProperties{some}

<<OWLClass>>Metadata

<<OWLClass>>Content

hasPart{some}

hasPart{some}

<<OWLClass>>ReadFile

<<OWLClass>>WriteFile

<<OWLClass>>DeleteFile

<<OWLClass>>File

≐ Metadata ⨁!Content

<<OWLClass>>Collection

hasPart{some} hasPart{some}hasPart{some}

<<OWLClass>>DownloadDocument

<<OWLClass>>UploadDocument

<<OWLClass>>DeleteDocument

<<OWLClass>>URI

<<OWLClass>>DestinationURI

<<OWLClass>>SourceURI

hasURI{some}

Subsumption

Object Property - ontological relation

Ontological concept, originally defined in NFO

property{cardinality}

...<<OWLClass>>

Legend

Ontological concept, not included in NFO...<<OWLClass>>

Fig. 2. The file management ontology

DL Opertor Semantics

Conjunction (C ⊓D)I = CI ∩DI

Disjunction (C ⊔D)I = CI ∪DI

Universal quantifier (∀R.C)I = {x ∈∆I | ∀y.(x,y) ∈ RI ⇒ y ∈ CI}Existential quantifier (∃R.C)I = {x ∈∆I | ∃y.(x,y) ∈ RI ∧ y ∈ CI}

Aggregation (C ⊕D)I = {x ∈∆I | ∃y.(x,y) ∈ hasPartI

∧ y ∈ CI ∧∃z.(x,z) ∈ hasPartI ∧ z ∈DI}

C and D are concepts and R is an object property.

TABLE 1. Overview of DL operators

defines the vocabulary for describing and relatinginformation elements that are commonly used infile management applications. A Resource can bea file or a directory (i.e. a collection of files). InDL, this is written: Resource

.= File ⊔ Collection.

The dot above the “equals” symbol designates adeclarative axiom, a.k.a., user-defined axioms. In ad-dition, a Resource concept has some resource prop-erties: Resource ⊑ ∃hasProperties.ResourceProperties.ResourceProperties has a title of the built-in typeString as well as dates for creation and last update.ResourceProperties may also have one or more notesof the the built-in type String.

We describe the aggregation of concepts, wheredifferent concepts are composed together to builda whole, using the W3C recommendation for part-whole relations—hasPart.4 A concept E is an aggre-gation of concepts C and D, written E = C ⊕ D,providing both C and D are parts of E, i.e. E =(∃hasPart.C) ⊓ (∃hasPart.D). For example, the File

concept is defined as the aggregation of the Metadata

and Content concepts, meaning that each file instancef ∈ File encompasses a Metadata instance (∃m ∈Metadata ∧ (f,m) ∈ hasPart), as well as a Content

instance (∃c ∈ Content ∧ (f, c) ∈ hasPart).DL is used to support automatic reasoning about

concepts and their relationships, in order to infer newrelations that may not have been recognised by the

4. http://www.w3.org/2001/sw/BestPractices/OEP/SimplePartWhole/

ontology designers. Traditionally, the basic reasoningmechanism is subsumption.

Definition 1 (Subsumption): A concept C is sub-sumed by a concept D, written C ⊑ D iff any instance(sometimes called individual) of C also belongs to D.In addition, all the relationships in which D instancescan be involved are applicable to C instances, i.e. allproperties of D are also properties of C.

For example, since File ⊑ Resource andResource ⊑ ∃hasProperties.ResourceProperties, itcan be inferred that a File also has some propertiesFile ⊑ ∃hasProperties.ResourceProperties. Subsumptionis a partial order relation, i.e. it is reflexive,antisymmetric, and transitive. As a result, theontology can be represented as a hierarchy ofconcepts, which can be automatically inferred byontology reasoners based on the axioms defining theontological concepts.

2.3 Modelling Components by Combining Ontolo-gies and Labelled Transition Systems

While ontologies allow domain knowledge to bedefined formally, describing knowledge about thesoftware components themselves is equally important.To enable automated reasoning about interoperabilitybetween components, we must represent explicitly allthe knowledge implicitly encoded in each component.This knowledge is explicitly represented in the compo-nent model that describes the component’s capability,interface signature and behaviour. Figure 3 depicts themodel of the WebDAV client.

The capability gives a macro-view of the componentby specifying the high-level functionality it requiresfrom or provides to its environment [19]. For example,the WebDAV client (denoted WDAV) whose model isdescribed in Figure 3 requires a file management capability.

The interface signature, or simply interface, of thecomponent gives a finer grained description of theoperations and data that the component manipulates.More precisely, the component’s interface defines the


WDAV Model

Interface signature ( )

Behaviour

<Authenticate, {Username, Password}, {Authorisation}>

<Lock, {SourceURI}, {Acknowledgment}>

<MoveFile, {SourceURI, DestinationURI}, {Acknowledgment}>

<ReadFile, {SourceURI}, {File}>

<WriteFile, {File}, {Acknowledgment}>

<DeleteFile, {SourceURI}, {Acknowledgment}>

<Unlock, {SourceURI}, {Acknowledgment}>

<Logout, , {Acknowledgment}>

Behaviour ( )

Capability ( )

Requires fileManagement

Authenticate

LockMoveFile

ReadFile

WriteFile

DeleteFile

Unlock

Logout

;

PWDAV=(Authenticate ! P1),P1 =(Lock ! P2 | Logout ! END),P2 =(MoveFile ! P2 | ReadFile ! P2

| WriteFile ! P2 | DeleteFile ! P2

| Unlock ! P1).

IWDAV

PWDAV

CapWDAV

Fig. 3. Model of the WebDAV client

set of observable actions that the component exchangeswith its running environment. It is partitioned intorequired and provided actions, with the understandingthat required actions are received from and con-trolled by the environment, whereas provided actionsare emitted and controlled by the component. Arequired action α = 〈op, i, o〉, where the symbolsop, i, and o are references to concepts in a domainontology O, represents a client-side invocation ofan operation op by sending the appropriate inputdata i and receiving the corresponding output data o.For example, the 〈ReadFile, {SourceURI}, {File}〉 action,belonging to WDAV’s interface, designates a requiredaction that perform the ReadFile operation by takingSourceURI as input and producing File as output.ReadFile, SourceURI, and File are all concepts in the filemanagement ontology depicted in Figure 2. In orderto reason about the meaning of actions rigorously,the component model is focused on the semanticdescriptions of actions, specified using references tothe domain ontology, rather than their syntactic de-scriptions, specified using XML schemas. On the prac-tical side, the syntactic descriptions of all operationsand input/output data include semantic annotationsreferring to concepts in the domain ontology. Theseannotations can either be specified by the developer ofthe component or automatically inferred using learningtechniques [24], [25].

The dual provided action β = 〈op, i, o〉 uses theinputs and produces the corresponding output.5 SinceWDAV only invokes operations from the WebDAVservice, its interface contains only required actions.

The behaviour of a component specifies its interactionwith the environment and models how the actionsof its interface are coordinated in order to achievethe specified capability. We build upon state-of-the-artapproaches to formalise component interactions [6]using Finite State Processes (FSP). FSP [26] is a process

5. We use the overline as a convenient shorthand to denoteprovided actions.

algebra that has proven to be a convenient formalismfor specifying concurrent components, analysing, andreasoning about their behaviours. The syntax of FSPis summarised in Table 2, while the interested readeris referred to [26] for further details. The behaviouralspecification of the WebDAV client (PWDAV) in FSP isdepicted in Figure 3. To simplify the presentation, theactions are represented using the operation conceptalone. Note that all the concepts used to describeactions belong to the file management ontology eventhough they are not represented in Figure 2. WebDAVclients first login. To perform any operation, clientshave to lock the resource, execute the desired opera-tion(s) and then unlock it again. Finally, they log outto terminate.

The semantics of FSP is given in terms of LabelledTransition Systems (LTS) [27]. The LTS associated withPWDAV is depicted in Figure 3. The LTS interpreting aprocess P can be regarded as a directed graph whosenodes represent the process states and each edge islabelled with an action belonging to the component’sinterface. There exists a start node from which theprocess begins its execution. There exists also a finalstate, which is associated with the END process, thatindicates a successful termination of the FSP process.The expression s

a! s′ specifies that if the process is in

state s and engages in an action a, then it transits to

state s′. The expression sX⇒ s′ where X = 〈a1, . . . , an〉,

ai being actions of the component’s interface, is usedas a shorthand denoting that P transits from state s

to state s′ after it engages in a sequence of actions X .When composed in parallel, processes synchronise ondual actions while actions that are in the alphabet ofonly one of the two processes can be executed inde-pendently. Hence, we assume synchronous semantics.Although the asynchronous semantics can be easilyimplemented, it is hard to reason about interactingprocesses under these semantics; in general, propertiesof the system such as deadlocks are undecidable [28].

FSP Syntax

αP P ’s alphabeta→ P Action prefixa→ P |b→ P ChoiceP ;Q Sequential compositionP‖Q Parallel compositionEND Built-in process, denotes successful termination

TABLE 2. FSP overview

Finally, we can reasonably assume that the semanticannotations as well as the behavioural specificationof a component are either provided with or derivablefrom the component’s interface. First, there are variousapproaches and standards that emphasise the needand the importance of having such a complete speci-fication [20], [23], [29]. Second, there is an increasingnumber of advanced learning techniques and tools tosupport the inference of ontological annotations [24] aswell as the extraction of behavioural models [25], [30], [31].


Component 1 Component 2Running-System

Level

Model Level

Emergent Middleware

Model of

Component 1

(Cap1, I1, P1)

Model of

Component 2

(Cap2, I2, P2)

Cap1 matches Cap2

Interface Mapping

Map (I1, I2) and Map (I2, I1)

Mediator Synthesis

Mediator M such that P1 and P2 progresssynchronously and reach their final states

Deployment

Functional Compatibility1

3

2

4

Ontology

O

MIC

S

Fig. 4. Overview of our approach to the automated synthesis of mediators

2.4 Automated Synthesis of Mediators: Overview

Although the WebDAV client requires a file manage-ment functionality that may be provided by the GoogleDrive service, their interactions lead to an erroneousexecution, namely a mismatch. In general, mismatchesmay occur due to inconsistencies in:

• The names and types of input/output data and op-erations. For example, resource containers arecalled folders in Google Drive and collections inWebDAV. Google Drive also distinguishes betweentypes of documents (e.g. presentation, spread-sheet) whereas WebDAV considers them all asfiles.

• The granularity of operations. WebDAV providesan operation for moving files from one locationto another whereas Google Drive does not. Still,the move operation can be realised using existingoperations to achieve the same task, i.e. it can becarried out by performing the upload, download,and delete operations offered by Google Drive.

• The ordering of operations. WebDAV requires oper-ations on files to be preceded by a lock operationand followed by an unlock. Google Drive doesnot have such a requirement. Still, it allows usersto restrict or release access to a document bychanging its sharing settings. Hence, althoughthe operations of the two systems can be mappedto one another, the sequencing of actions requiredby WebDAV is not enforced by Google Drive.

The mediator solves the aforementioned mismatchesby compensating for the differences in the data andoperations of the components under consideration, andby coordinating their behaviours in order to respectthe sequences of actions expected by both of them.In order to reason about component interoperationautomatically and generate the appropriate mediator,we rely on the rigorous modelling of both componentsas defined in Section 2.3. Also, as discussed in Sec-tion 2.2, we use an off-the-shelf ontology O to representdomain knowledge and utilise it to reason about the

relations holding between the data and operationsof the two components. We assume that the modelsof the components are valid, i.e. they represent theactual functional (capability, interface) and behaviouralsemantics of the components at hand, and that all theontological concepts referred to in the models of bothcomponents belong to the ontology O. We recognisethat this might not be the case in practice and planto deal with partial or changing models as well asheterogeneous ontologies in future work.

We also use the ontology O to verify, prior to anymediation, whether it makes sense for the componentsto interact with each other by checking if they arefunctionally compatible, i.e. if the capability required byone component subsumes the capability provided bythe other component in a way similar to capabilitymatching in Semantic Web Services [32] (see Figure 4-❶).

A significant role of the mediator is to convert dataavailable on one side and make it suitable and relevantto the other. This conversion can only be carried outif there exists a semantic correspondence between theactions required by one component and those providedby the other component, that is, interface mapping(see Figure 4-❷). The main idea is to use the domain-specific information embodied in the ontology O inorder to select among all the possible combinations ofthe actions of the components’ interfaces only thosepreserving the semantics of data and operations andfor which automated transformations can be safelyperformed. Subsequently, we generate the mappingprocesses that receive the input/output data from onecomponent, execute the necessary transformations, andsend it back to the other component.

One important aspect of interface mapping is thatit can be ambiguous, i.e. the same sequence ofactions of one component may be achieved usingdifferent sequences of actions provided by the othercomponent. It then becomes crucial to combine themapping processes in a way that guarantees thatthe two components progress and reach their final


states without errors that cannot be caught by thetype system alone (e.g. deadlock). The gist of theapproach is then to generate a mediator M thatcoordinates the mapping processes and guaranteesthat the behaviour of the mediated system, whichis represented through the parallel composition ofthe LTSs of both components together with that ofthe mediator is free from deadlocks (see Figure 4-❸).Notions such as bisimulation or refinement [33] cannotbe applied since they assume the use of the same setof actions (alphabet). Neither is it possible to relabelthe LTSs beforehand since the mappings are not onlybased on one-to-one correspondences but rather many-to-many, and also because the same action (sequenceof actions) may be translated differently depending onthe state in which the system is.

Finally, the mediator is deployed and enacted as anemergent middleware [34], which interprets the mediatormodel and executes the necessary transformations toallow the components to interact properly (see Figure 4-❹).

In Section 3 we explain how to compute interfacemapping while in Section 4 we present how to syn-thesise the mediator. In Section 5, we describe MICS,the supporting tool for the automated synthesis anddeployment of mediators.

3 AUTOMATED MAPPING OF INTERFACES

Establishing the semantic correspondence between theactions of the components’ interfaces is a crucial steptowards the synthesis of mediators. In this section,we first specify the conditions under which such acorrespondence may be established. Then, we showhow to compute interface mapping efficiently usingconstraint programming [35].

3.1 Mapping Component Interfaces

Let us consider two components’ interfaces I1and I2. Mapping I1 to I2, written Map (I1, I2),consists in finding all pairs (X1, X2) whereX1 = 〈α1, α2, . . . , αm〉 , αi=1..m ∈ I1 andX2 =

⟨

β1, β2, . . . , βn

⟩

, βj=1..n ∈ I2 such that X1

maps to X2, denoted X1 7! X2, if the required actionsof X1 can be safely performed by calling the providedactions of X2. In addition, this pair is minimal, that is,any other pair of sequences of actions (X ′

1, X′

2) suchthat X ′

1 maps to X ′

2 would have X1 as a subsequenceof X ′

1 or X2 as a subsequence of X ′

2. The interfacemapping is then specified as follows:

Map (I1, I2) ={ (X1, X2)|X1 = 〈α1, α2, . . . , αm〉 , αi=1..m ∈ I1

∧X2 =⟨

β1, β2, . . . , βn

⟩

, βj=1..n ∈ I2∧X1 7! X2

∧ 6 ∃ (X ′

1, X′

2) | X ′

1 = 〈α1, α2, . . . , αm′〉, αi=1..m′ ∈ I1∧X ′

2 =⟨

β1, β2, . . . , βn′

⟩

, βj=1..n′ ∈ I2∧ (X ′

1 7! X ′

2) ∧ (m′ < m) ∧ (n′ < n)}

Likewise, Map (I2, I1) represents the set of all pairs(X2, X1), where X2 is a sequence of required actionsof I2 and X1 is a sequence of provided actions of I1,such that X2 maps to X1 and this mapping is minimal.

Each mapping relation is associated with a processthat specifies how the sequences of actions are coor-dinated. In the following, we specify the conditionsthat represent the safety properties which should besatisfied by the mapping relation (7!) in order toguarantee the correct replacement of actions. We firstgive a formal definition in the one-to-one case (m = 1and n = 1), which we extend to the one-to-many(m = 1 and n ≥ 1) and many-to-many (m ≥ 1 andn ≥ 1) cases. Note that we do not distinguish betweenthe aggregation (⊕) and disjunction (⊔) constructorswhen computing the interface mapping as they bothrepresent compositions of concepts. The distinctionis however maintained at the ontological level, andalso for data translations: in the case of disjunctionE

.= C ⊔D, the translation consists in producing an

instance of E by assigning to it either an instance of Cor an instance of D. While in the case of aggregationE

.= C⊕D, an instance of E is produced by combining

its parts, i.e. both C and D instances, in the appropriateway.

Definition 2 (One-to-One Mapping): A required ac-tion α = 〈a, Ia, Oa〉 ∈ I1 maps to a provided action

β =⟨

b, Ib, Ob

⟩

∈ I2 noted α1−17−! β, iff:

1) b ⊑ a 2) Ia ⊑ Ib 3) Ia ⊔Ob ⊑ Oa

The idea behind this mapping is that a requiredaction can be achieved using a provided one if theformer supplies the required input data while the latterprovides the necessary output data, and the requiredoperation is less demanding than the provided one.This coincides with the Liskov Substitution Principle [36]where ontological subsumption can be used in wayssimilar to subtyping in object-oriented systems.

As a result, we generate the mapping process M1−1

that synchronises with each component by executingits dual action in order to let the two componentsprogress as depicted in Figure 5. The states of the map-ping process are labelled so as to reflect the progressof the components; each label is the concatenationof the label of the state of Component 1 and that ofComponent 2. M1−1 performs β (trace 0.0′ ! 0.1′) soas to synchronise with α (trace 0.1′ ! 1.1′). Hence, the

one-to-one mapping process corresponding to α1−17−! β

is defined as follows: M1−1(α, β) = (β ! α ! END).

Component 1

Component 2

Matching Process

M1−1(α, β)

α

β

αβ1.100.100.00

00 10

0 1

Fig. 5. One-to-one mapping process: M1−1(α, β)


Let us consider the 〈ReadFile, {SourceURI}, {File}〉action required by WDAV and the〈DownloadDocument, {SourceURI}, {Document}〉 actionprovided by the Google Drive service, whichwe denote GDrive. We can verify from thefile management ontology in Figure 2 that:1) DownloadDocument ⊑ ReadFile, 2) SourceURI ⊑SourceURI since subsumption is reflexive, and3) Document ⊑ File. As a result, we generate acorresponding mapping process M1−1(ReadFile,DownloadDocument)=(DownloadDocument ! ReadFile

! END)., which requires DownloadDocument andprovides ReadFile. Therefore, it needs to: (i) receiveSourceURI once ReadFile is invoked, (ii) invokeDownloadDocument using SourceURI as input data andreceive the associated Document, and (iii) constructand return File (since Document ⊑ File) as a result ofthe invocation of ReadFile.

Definition 3 (One-to-Many Mapping): A requiredaction α = 〈a, Ia, Oa〉 ∈ I1 maps to a sequenceof provided actions X2 =

⟨

β1, β2, . . . , βn

⟩

where

βi=1..n=⟨

bi, Ibi , Obi

⟩

∈ I2, noted α1−n7−!

⟨

β1, . . . , βn⟩

, iff:

1)n⊔

i=1

bi ⊑ a

2) Ia ⊑ Ib1

3) Ia⊔

(

i−1⊔

j=1

Obj

)

⊑ Ibi

4) Ia⊔

(

n⊔

j=1

Obj

)

⊑ Oa

The first condition states that the operation a can beappropriately performed using bi operations, that is,the disjunction of all bi is subsumed by a. The secondensures that the sequence of provided actions can beinitiated since the input data of the first action Ib1 canbe obtained from the input data of the required actionIa. The third condition specifies that the input data ofeach action can be obtained from the data previouslyreceived either as input from α or as output from thepreceding βj (j < i). The fourth condition guaranteesthat the required output data Oa can be obtained fromthe set of data accumulated during the execution ofall the provided actions.

As a result, we generate the mapping processM1−n(α,X2), depicted in Figure 6, which performs allthe provided actions (trace 0.0′ ! ·· · ! 0.n′) so as tosynchronise with the action α (trace 0.n′ ! 1.n′). The

mapping process corresponding to α1−n7−!

⟨

β1, . . . , βn⟩

is: M1−n(α,X2) = (β1 ! β2 ! ·· · ! βn ! α! END).

Component 1

Component 2

Matching Process

β1 βn

βnβ1

β2

β2

…

…

α

α

M1−n(α, X2)0.n0 1.n0

00 10 n0

0 1

0.00 0.10

Fig. 6. One-to-many mapping process: M1−n(α,X2)

Let us consider the 〈MoveFile,{SourceURI,DestinationURI}, {Acknowledgment}〉 actionrequired by WDAV and the three actions:(i) 〈DownloadDocument,{SourceURI},{Document}〉,(ii) 〈UploadDocument,{Metadata,Content,DestinationURI},{Acknowledgment}〉, and (iii) 〈DeleteDocument,{SourceURI}, {Acknowledgment}〉 provided by GDrive.First, the condition on the semantics of theoperations is verified, that is, DownloadDocument ⊕UploadDocument ⊕ DeleteDocument ⊑ MoveFile. Werecall, as stated at the beginning of this section, thatwe do not distinguish between the aggregation (⊕)and disjunction (⊔) constructors when computingthe interface mapping. Then, both DownloadDocument

and DeleteDocument can be performed as they onlyexpect SourceURI as input, which is produced byMoveFile. UploadDocument requires some input data,which can only be provided by DownloadDocument

since Document =Metadata⊕Content (see Figure 2) andthus must be executed after DownloadDocument. Hence,we can have the following mapping:

MoveFile 7! 〈DownloadDocument, UploadDocument,DeleteDocument 〉

We can generate a corresponding mapping processM1−n(MoveFile, 〈DownloadDocument, UploadDocument,

DeleteDocument〉), which: (i) receives SourceURI andDestinationURI as a result of the invocation of MoveFile,(ii) invokes DownloadDocument with SourceURI asinput data, and receives the corresponding Document,(iii) invokes UploadDocument using Metadata andContent (since Document = Metadata ⊕ Content) andDestinationURI, which was previously received, (iv)invokes DeleteDocument using SourceURI and receivesthe associated Acknowledgment, and (iiv) sends backthe Acknowledgment expected by MoveFile.

Since there is no data dependency betweenUploadDocument and DeleteDocument, there exists an-other mapping using these same actions in a differentorder: MoveFile 7! 〈DownloadDocument, DeleteDocument,UploadDocument 〉

Definition 4 (Many-to-Many Mapping): A sequenceof required actions X1 = 〈α1,α2, . . . ,αm〉 whereαi=1..m=〈ai, Iai

,Oai〉 ∈ I1 maps to a sequence

of provided actions X2=⟨

β1, β2, . . . , βn⟩

whereβj=1..n=

⟨

bj, Ibj ,Obj

⟩

∈ I2, noted 〈α1, . . . ,αl, . . . ,αm〉m−n7−!

⟨

β1, . . . , βn⟩

, iff:

1)n⊔

j=1

bj ⊑m⊔

i=1

ai

2)l⊔

i=1

Iai⊑ Ib1

3)

(

l⊔

j=1

Iaj

)

⊔

(

i−1⊔

h=1

Obh

)

⊑ Ibi

4) Oah= ∅ for 1 6 h 6 l− 1 (where l ∈ [1,m+1])

5)

(

h⊔

i=1

Iai

)

⊔

(

n⊔

k=1

Obk

)

⊑ Oahfor l 6 h 6m


The first condition states that the ai operationscan be performed using bj operations. The secondcondition states that the first provided action can beperformed since the necessary input data Ib1 can beobtained from the data previously received. The thirdconditions ensures that the input data of each actioncan be obtained from the received input data andthe output data of the preceding actions. The fourthcondition states that we can cache the input data ofthe required actions and allow them to progress if theydo not necessitate any output data. We recall that arequired action represents a client-side invocation ofan operation by sending the appropriate input dataand receiving the corresponding output data, whilea provided action uses the inputs and produces thecorresponding output. Let l be the index of the firstrequired action that necessitates some output data.l = 1 means that the first required action necessitatessome output data while l = m+ 1 means that noneof the required actions necessitates output data. Sincethe first l − 1 actions do not necessitate any outputdata, they can be executed before the provided actions.Finally, the last condition states that the output data ofthe remaining required actions, i.e. from l to m, can beobtained from the previous input data together withthe output data of the provided actions.

Consequently, we generate the mapping processMm−n(X1,X2) depicted in Figure 7. Mm−n(X1,X2) firstsynchronises with the l − 1 first required actionssince no output data is necessary for them to beexecuted (trace 0.0′ ! ·· · ! (l− 1).1′). But only afterperforming all provided actions (trace (l − 1).1′ !·· · ! (l − 1).n′), can Mm−n(X1,X2) synchronise withthe subsequent required actions, from l to m (trace(l − 1).n′ ! ·· · ! m.n′) since the output data nec-essary for their achievement are produced by theprovided actions. The mapping process corresponding

to 〈α1, . . . ,αl, . . . ,αm〉m−n7−!

⟨

β1, . . . , βn⟩

is as follows:Mm−n(X1,X2) = (α1 ! ·· · ! αl−1 ! β1 ! ·· · !βn ! αl ! αl+1 · · · ! αm ! END).

Component 1

Component 2

Matching Process

β1 βn

βnβ1

β2

β2

…

…

00 10 n0

0 1

Mm−n(X1, X2)

… …l-1 m

0.00 1.00 (l-1).10 … …(l-1).n0 m.n0(l-1).00

α1 α2 αl−1 αl αm

α1αl−1 αl αmα2

Fig. 7. Many-to-many mapping process: Mm−n(X1,X2)

To sum up, a sequence of required actions canbe mapped to a sequence of provided actions if thefollowing conditions are verified: (i) the functionalityoffered by the provided actions covers that of therequired actions, (ii) the input data of each providedaction can be obtained before its execution, and (iii) theoutput data of each required action can be obtainedbefore its execution. Even though these mappings donot cover every possible mismatch—this would mean

that we are able to prove computational equivalence—they cover a large enough set of mismatches withrespect to practical and real case studies and otherautomated approaches.

3.2 Interface Mapping using ConstraintProgramming

Mapping interface I1 to interface I2 consists insearching, among all the possible pairs of sequencesof required actions of I1 and sequences of pro-vided actions of I2, those which verify the condi-tions of the mapping relation specified in the pre-vious section. Furthermore, each pair of sequencesof actions is minimal, that is, any other pair ver-ifying the mapping relation would include a sub-sequence of the required or provided actions. Asinterface mapping is an NP-complete problem (seethe proof at http://www-roc.inria.fr/arles/software/mics/complexity.pdf and in [37]), weuse Constraint Programming (CP) to deal with iteffectively. Indeed, CP has proved very efficient whendealing with combinatorial problems [35].

Many arithmetical and logical operators are man-aged by existing CP solvers. However, although thereare some attempts to integrate ontologies with CP [38],none supports ontology-related operators such assubsumption or disjunction of concepts. In order to useCP to compute interface mapping, we need to enableontology reasoning within CP solvers. Therefore, wepropose to represent the ontological relations we areinterested in using arithmetic operators supported byexisting solvers. In particular, we devise an approachto associate a unique code to each ontological con-cept such that disjunction and subsumption relationsamount to boolean operations.

In the following, we introduce CP. Then, we formu-late the interface mapping as a constraint satisfactionproblem that can be solved efficiently using CP.

3.2.1 Constraint Programming in a Nutshell

Constraint programming is the study of combinatorialproblems by stating constraints (conditions, qualities)which must be satisfied by the solution(s) [35]. Theseproblems are defined as a constraint satisfaction problemand modelled as a triple (X,D,C):

• Variables: X = {x1, x2, . . . , xn} is the set of variablesof the problem.

• Domains: D is a function which associates to eachvariable xi its domain D(xi), i.e. the set of possiblevalues that can be assigned to xi.

• Constraints: C = {C1,C2, . . . ,Cm} is the set of con-straints. A constraint Cj is a mathematical relationdefined over a subset xj = {xj1, x

j2, . . . , x

j

nj} ⊆X ofvariables which restricts their possible values. Con-straints are used to determine unfeasible valuesand delete them from the domains of variables.


Solving a constraint satisfaction problem consistsin finding the tuple (or tuples) v = (v1, . . . , vn) wherevi ∈D(xi) and such that all the constraints are satisfied.Thus, CP uses constraints to state the problem declar-atively without specifying a computational procedureto enforce them. The latter task is carried out by asolver. The constraint solver implements intelligentsearch algorithms such as backtracking and branchand bound which are exponential in time in the worstcase but may be very efficient in practice. The CPsolver also exploits the arithmetic properties of theoperators used to express the constraints to quicklycheck, discredit partial solutions, and prune the searchspace substantially.

We represent interface mapping Map (I1,I2) as aconstraint satisfaction problem as follows:

• Variables: X = {X1,X2} where X1 representsa sequence of required actions of I1 and X2

represents a sequence of provided actions of I2.

• Domains: D(X1)=|I1|⋃

k=1

Pk(I1) and D(X2)=|I2|⋃

k=1

Pk(I2)

where Pk(S) denotes the set of k-permutations ofthe elements of the set S. Indeed, X1 is a sequenceof actions (hence the permutations) of I1 of lengthk varying between 1 and the cardinality of I1,i.e. 1 < k < |I1|. Similarly for X2. Note that tokeep the domain finite, each action can appear inthe sequence at most once.

• Constraints: the constraints are defined by theconditions of the mapping relation (7!) speci-fied in Section 3.1. As for the minimality ofthe mapping, we eliminate redundant solutionsusing the subsequence relation, which is a partialorder relation defined on the domain of eachvariable. Let us consider two sequences of actionsA =〈a1, a2, . . . , am〉 and B =〈b1, b2, . . . , bn〉; A is asubsequence of B iff m < n and ∀k ∈ [1..m],ak = bk. Exploiting this partial order relation forthe branch and bound algorithm used to solvethe constraint satisfaction problem allows us tokeep only the minimal mappings that verify therest of the constraints.

The solutions of the constraint satisfaction problemare the smallest, according to the subsequence relation,pairs of action sequences (α,β) ∈D(X1)×D(X2) suchthat the required actions of α can safely be achievedusing the provided actions of β.

3.2.2 Representing Ontological Relations

Our goal is to leverage CP solvers to perform interfacemapping since none of existing CP solvers deals withontology-based operators. To this end, we define a bitvector encoding of the ontology which is correct andcomplete regarding the subsumption and disjunctionaxioms. Correctness means that if the encoding assertsthat a concept subsumes another concept or that a concept isa disjunction of other concepts then these relations can be

verified in the ontology. Completeness means that if theontology states that a concept subsumes another oneor that a concept is a disjunction of other concepts thenthis statement can also be made using the encoding.

Algorithm 1 EncodingOntology

Require: Classified ontology OEnsure: Code[]: maps each concept C ∈ O to a bit vector1: for all C ∈ Concepts(O) do2: Set[C]← {NewElement()}3: end for4: for all C ∈ Concepts(O) do5: for all Des ∈ Descendants(C) do6: Set [C]← Set [C] ∪ Set [Des]7: end for8: end for9: disjunctionAxiomList = Sort(DisjunctionAxioms(O))

10: for all A =n⊔

i=1

Ai ∈ disjunctionAxiomList do

11: D ← Set [A] \n⋃

i=1

Set [Ai]

12: for all d ∈ D do13: Set [A]← Set [A] \ {d}14: for all Ai do15: di ← {NewElement()}16: Set [Ai]← Set [Ai] ∪ {di}17: for all Asc ∈ Ascendants(Ai) do18: Set [Asc]← Set [Asc] ∪ di19: end for20: end for21: for all Des ∈ Descendants(A) | d ∈ Set [Des] do

22: Set [Des]← (Set [Des] \ {d})⋃

(

n⋃

i=1

di

)

23: end for24: end for25: end for26: Code[]← SetsToBitVectors(Set[])27: return Code[]

The algorithm for encoding an ontology (Algo-rithm 1) takes the classified ontology as its input,i.e. an ontology that also includes inferred axioms,and returns a map that associates each concept witha bit vector. We first use sets to encode the ontologyconcepts such that subsumption coincides with setinclusion and disjunction with set union. Then, werepresent the sets using bit vectors whose size is thenumber of elements of all sets. Each bit is set to 1 if thecorresponding element belongs to the set and to 0 otherwise.The type of elements of the sets does not matter, they arejust temporary objects used to perform the encoding.

The first step of the encoding algorithm is to assigna unique element to the set that represents eachconcept (Lines 1−3). Then, we augment the set of eachconcept with the elements of the sets associated withthe concepts it subsumes, i.e. its descendants (Lines4−8) since subsumption essentially comes down to setinclusion of the instances of concepts.

We then move to disjunction axioms. We sort theaxioms so that each element is made up of simpleconcepts or preceding concepts in the list (Line 9). For

each disjunction axiom A =n⊔

i=1

Ai, we consider the set

D of elements that belong to the set representing A

but which are not included in any of the sets of its


Presentation

{1,2}

SpreadSheet

{1,3}

TextDocument

{1,4}

Document

{1,2,3,4,5}

File

{1,2,3,4,5,6}

Presentation

{1,2,51}

SpreadSheet

{1,3,52}

TextDocument

{1,4,53}

Document

{1,2,3,4,51,52,53}

File

{1,2,3,4,51,52,53,6}

Presentation

00010011

SpreadSheet

00100101

TextDocument

01001001

Document

01111111

File

11111111

Step 1: Considering the hierarchy Step 2: Considering disjunction Step 3: Encoding into bit vectors

Fig. 8. Illustrating ontology encoding on an extract of the file ontology

composing classes Ai (Line 11). These elements areeither the distinguishing element of A, or put into A’sset by one of its sub-concepts during the previous step.The latter case represents the case where a conceptis subsumed by the disjunction A but not by any ofits individual concepts. To preserve the subsumption,each element d ∈ D is divided into n elements, each ofwhich is added to one of the composing classes Ai=1..n.Hence, we first remove d from A (Line 13). Then, wecreate a new element di and add it to Ai’s set as wellas to the sets of its subsuming concepts, which includeA (Lines 14−20). We also replace the element d in A’sdescendants by the new elements it was divided into(Lines 21−23). Finally, we encode the sets using bitvectors where each bit indicates whether or not anelement belongs to the set (Line 26).

The size of the bit vector depends on the size ofthe ontology together with the number of disjunctionaxioms it includes. Let m be the number of concepts inthe ontology. The first step of the encoding algorithmis to assign a unique element to the set that representseach concept. Hence, each element associated witha concept C will be converted into a bit in the bitvector representing the concept Code[C]. Consequently,we will have an m-bit vector. Then, we augmentthe set of each concept with the elements of itsdescendants, which does not involve adding newelements. As a result, we still have an m-bit vector.Let k be the number of conjunction axioms. For each

axiom A =n⊔

i=1

Ai, we split the element belonging to

A but not to any of its composing concepts Ai, if any,into a maximum of n objects, hence adding n bits.Consequently, the number of bits would be m+ k ∗ n′

where n′ is the degree of the disjunction axioms, i.e. themaximum of all n.

As a result, subsumption can be performed usingbitwise and as follows:

C ⊑D ⇐⇒ Code[C]∧Code[D] = Code[C]

Disjunction is performed using bitwise or:

A =n⊔

i=1

Ai ⇐⇒ Code[A] =n∨

i=1

Code[Ai],

The proof of the correctness and completeness of thisencoding can be found at http://www-roc.inria.fr/arles/software/mics/encodingProof.pdf

and also in [37].

Let us consider the extract of the file managementontology depicted in Figure 8. File subsumes Document

which is defined as the disjunction of Presentation,SpreadSheet, and TextDocument. During the first step, weassociate an element, which we represent as a naturalnumber, to each concept and put it into its ascendants.The element ‘1’ represents the bottom concept ⊥subsumed by all concepts. Then, we consider theDocument = Presentation ⊔ SpreadSheet ⊔ TextDocument

disjunction. The ‘5’ element belongs to Document butnot to any of its composing concepts, so we split itinto three elements (‘51’, ‘52’, and ‘53’) and assign eachof them to a composing element in step 2. In step 3,we encode sets as bit vectors. For example, Presentationincludes 1 at the position of ‘1’, ‘2’, and ‘51’ elements;and 0 at all other positions. The bitwise AND betweenthe codes of File and Document corresponds to the codeof Document (11111111 ∧ 01111111 = 01111111), whichis equivalent to stating that File subsumes Document.The bitwise OR between the codes of Presentation,SpreadSheet, and TextDocument is 01111111, which corre-sponds to the code of Document. Note that this extractof the file ontology contains five concepts (m = 5) andone disjunction axiom (k = 1) with three composingconcepts (n = n′ = 3), as a result the codes of theconcepts are 8-bit vectors.

The encoded ontology is used by the CPsolver when computing the interface mappingin order to check if a constraint is verified.For example, to map 〈ReadFile,{SourceURI},{File}〉from the interface of the WebDAV client to〈DownloadDocument,{SourceURI},{Document}〉 from theinterface of the GoogleDocs service, the CP solververifies the subsumption between output data, that is,File ⊑ Document. This verification is performed usingthe code associated with each concept.

4 AUTOMATED SYNTHESIS OF MEDIATORS

To enable functionally-compatible components to in-teroperate, the mediator must not only solve the differ-ences between their interfaces but also coordinate theirbehaviours in order to ensure their correct interaction.Hence, given Map (I1,I2) and Map (I2,I1), where everyrequired action is involved in at least one mapping,we must either generate a mediator M that composesthe associated mapping processes in order to allowboth components to interact correctly, or determinethat no such mediator exists.


Definition 5 (Mediated Behavioural Compatibility):Let P1 and P2 represent the components’ behaviours.If a mediator M exists, then we say that P1 andP2 are behaviourally compatible through a mediator M ,written P1 ↔M P2.

In order to allow the components to interact correctly,the mediator M must coordinate their behaviours soas to ensure that the parallel composition P1‖M‖P2

successfully terminates by reaching an END state.We incrementally build a mediator M by forcing

the two processes P1 and P2 to progress consistentlyso that if one requires the sequence of actions X1,the other process is ready to engage in a sequence ofprovided actions X2 to which X1 maps. Given that aninterface mapping guarantees the semantic compatibil-ity between the actions of the two components, thenthe mediator synchronises with both processes andcompensates for the differences between their actions.This is formally described as follows:

if P1X1⇒ P ′

1 and ∃ (X1,X2) ∈Map (I1,I2)

such that P2X2⇒ P ′

2 and P ′1 ↔M′ P ′

2

then P1 ↔M P2 where M =Mm−n(X1,X2);M′

Similarly, for the other process:

if P2X2⇒ P ′

2 and ∃(X2,X1) ∈Map (I2,I1)

such that P1X1⇒ P ′

1 and P ′1 ↔M′ P ′

2

then P1 ↔M P2 where M =Mm−n(X2,X1);M′

The mediator further consumes the extra providedactions β so as to allow the components to progressusing the process Mβ = (β ! END). Extra providedactions are actions offered by one component but notrequired by the other and need to be invoked to allowthe former component to progress. As long as the inputdata necessary to invoke the action has been received,the mediator can call it and ignore the output produced.However, we do not handle extra required actionssince it involves offering some functionality, which themediator cannot handle by itself. The support of extraprovided actions is as follows:

if P1β! P ′

1, and ∃P2 such that P ′1 ↔M′ P2

then P1 ↔M P2 where M =Mβ ;M ′

if P2β! P ′

2, and ∃P1 such that P ′1 ↔M′ P2

then P1 ↔M P2 where M =Mβ ;M ′

Finally, when both processes terminate, i.e. reach anEND state, then the mediator also terminates:

END ↔END END

Note that the interface mapping is not necessarilya function since the same sequence of actions can bemapped to different sequences of actions, which weconsidered in the definition of the recursive algorithmfor mediator synthesis (see Algorithm 2).

The algorithm starts by checking the basic configu-ration where both processes reach their final states. Inthis case, the mediator is the END process (Lines 1−3).Then it considers the states of both processes and for

Algorithm 2 SynthesiseMediator

Require: P1, P2

Ensure: A mediator M1: if P1 = END and P2 = END then2: return END

3: end if4: M ← END

5: for all Pia→ P ′

i=1,2 do6: mappingList ← FindEligibleMappings(a, Pi, P3−i)7: while ¬found and mappingList 6= ∅ do8: Map(X1, X2)← selectMapping(mappingList)

such that PiX1⇒ P ′′

i and P3−iX2⇒ P ′

3−i

9: M ′ ← SynthesiseMediator(P ′′

i , P ′

3−i)10: if M ′ 6= fail then11: found← true12: Mm−n(X1, X2)← GenerateMapProcess(X1, X2)13: M ′′ ←Mm−n(X1, X2);M ′

14: end if15: end while

16: if ¬found and ∃β | P3−iβ→ P ′

3−i then17: M ′ ←SynthesiseMediator(Pi, P

′

3−i)18: if M ′ 6= fail then19: found← true20: M

β← GenerateExtraProvidedActionProcess(β)

21: M ′′ ←Mβ;M ′

22: end if23: end if24: if ¬found then25: return fail26: end if27: M ←M |M ′′

28: end for29: return M

each enabled required action a, it calculates the listof mappings that can be applied, i.e. pairs (X1, X2)such that X1 starts with a and P2 is ready to engagein X2 (Line 6). It selects one of them and makes arecursive call to test whether it can lead to a validmediator (Lines 8−9). The selection of the mapping touse may be motivated by some non-functional propertyor the length of the sequences of actions involvedin the mapping but, for instance, let us assume thatthe algorithm simply selects the first valid mapping.The result is that a correct mediator is not unique. Ifthe selected mapping leads to a valid mediator, thealgorithm generates the associated mapping processand puts it in sequence with the returned mediatorM ′. Otherwise, it tries another mapping until a validmapping is found or all the possible mappings havebeen tested (Lines 7−15). In the latter case, it checkswhether the mediator can bypass a provided actionin order to obtain a valid mediator. In this situation,the algorithm generates the appropriate process Mβ

and puts it in sequence with the generated mediator(Lines 16−23). If the required action cannot be mappedto any action given the states of both processes, thealgorithm fails (Lines 24−26). Otherwise, it adds thenew trace to the previously calculated mediator (Line27). The algorithm explores all the outgoing transitionslabelled with required actions (Lines 5−28) in orderto make sure that for any required actions in whichthe components can engage, we are able to find acomposition of mapping processes that will lead the


components to reach their final states. The algorithmdoes not systematically explore transitions labelledwith provided actions because the synchronisationis triggered by required actions, which initialise theinteraction by sending the input data. The mediatorM hence synthesised guarantees that the parallelcomposition P1‖M‖P2 is deadlock free.

Theorem 1: if P1 ↔M P2 then the parallel composi-tion P1‖M‖P2 is deadlock free.

Proof: By construction, the mediator is synthesisedonly if both P1 and P2 reach an END state. In addition,at any given state s of any of P1 or P2, everytransition associated with a required action α suchthat s

α⇒ s′ is involved in some mapping α 7! β.

Hence, there exists an associated mapping processMm−n(α, β) that is ready to engage in the sequenceof dual provided actions, i.e. Mm−n(α, β) is in state

sm such that smα⇒ s′m. Any transition associated with

a provided action β such that sβ⇒ s′: (i) synchronises

with a mapping process Mm−n(α, β) if there exists amapping α 7! β involving it, (ii) is an extra provided

action, in which case it is associated with sβ⇒ s′ from

the Mβ process, or (iii) is never triggered; we recall thatthe synchronisation is triggered by required actions,which initialise the interaction by sending the input data.

WDAV

Interface Mapping

Lock

Unlock

MoveFile

GDrive

Lock!!!!!!!!!!

SetSharingProperties

MoveFile!!!!!!!!<DownloadDocument, UploadDocument, DeleteDocument>

MoveFile!!!!!!!!!!!

<DownloadDocument, DeleteDocument, UploadDocument>

Unlock!!!!!!!!!!

SetSharingProperties

SetSharingProperties DownloadDocument

UploadDocument

DeleteDocument0.00b

SetSharingPropertiesUnlock

Lock

MoveFile

Mediator

SetSharingProperties /UploadDocument /DownloadDocument /DeleteDocument

000 1

0.00 0.00a 1.00a 1.00b

1.00c1.00d

Fig. 9. Synthesis of an extract of the WDAV -GDrive

mediator

Figure 9 depicts an extract of the LTSs representingthe behaviour of WDAV and GDrive. As a result ofthe interface mapping computation, the Lock andUnlock operations map to SetSharingProperties andthe MoveFile operation maps to DownloadDocument,UploadDocument, and DeleteDocument while the lasttwo operations can be executed in any order. Whenboth processes are at their initial states (0 and 0′

respectively), the only applicable mapping is Lock 7!SetSharingProperties since PWDAV is only able to per-form this action. After applying this mapping PWDAV

goes to state 1, PGDrive remains in state 0′, and a partialtrace of the mediator is created from 0.0′ ! 0.0′a !

1.0′a. Then, PWDAV can loop on the MoveFile required ac-tion, one of the possible mappings is chosen since bothare applicable as PGDrive loops on DownloadDocument,UploadDocument, and DeleteDocument. PWDAV stays instate 1, PGDrive also remains in 0′ while the mediatoris augmented with the trace 1.0′a ! 1.0′b ! 1.0′c !1.0′d ! 1.0′a. PWDAV can also branch on the Unlock

operation, which maps to SetSharingProperties andresults in the trace 1.0′a ! 0.0′b ! 0.0′ in the mediator.Finally, both processes reach their final states and themediator is successfully created.

5 IMPLEMENTATION: THE MICS TOOL

In order to validate our approach, we implemented theMICS (Mediator Synthesis to Connect Components)tool to generate the mediator model automatically.MICS is available at http://www-roc.inria.fr/arles/software/mics/.

Interface Mapping

< α , <δ, λ> >, < β , <ρ> > …

Mediator Synthesis

Mediator Model

α

δ λ

β

ρ

2

3

δ λ ρ

α βThing

Nothing

α = [01000] β = [10001] …

Ontology Encoding1

Intermediate input/output

Initial input

Final output

Module

MIC

S T

oo

l

NS2 Model

δ, λ, ρ

Prov B

δ

δλρ

ρ

NS1 Model

α, β

Req A

α β

α

Ontologies

Legend

Fig. 10. Overview of MICS

MICS takes as input the models of two functionally-compatible components together with a domain ontol-ogy and produces the mediator that enables them tointeroperate. MICS is made up of three modules.

The ontology encoding module (see Figure 10-❶) firstclassifies the ontology using the Pellet reasoner.6 Pelletis an open-source java library for OWL DL reasoning.Then, the ontology encoding module uses Algorithm 1to associate bit vectors to the concepts of this ontology.

The interface mapping module (see Figure 10-❷) com-putes the mapping between the interfaces of thecomponents given as input, as described in Section 3.2using the Choco constraint solver.7 Choco is anopen-source java library for constraint solving andconstraint programming. Choco does not manageontology relations such as subsumption but thanksto the bit vector representation of concepts and theassociated modelling of constraints, we are able to

6. http://clarkparsia.com/pellet/7. http://choco.emn.fr/


specify interface mapping as a constraint satisfactionproblem using operators supported by Choco.

The mediator synthesis module (see Figure 10-❸) relieson the generated mappings and uses Algorithm 2 tosynthesise mediators.

Once the mediator model has been generated, itneeds to be refined and deployed into a concreteartefact so as to realise the specified mappings andcoordination. This artefact is called an emergent mid-dleware [34]. The emergent middleware implementsthe mediator based on middleware since middlewareprovides reusable solutions that facilitate commu-nication and coordination between components. Toimplement mediators, we must bridge the gap betweenthe application level, which provides the abstractionnecessary to reason about the meaning of the actionsused by the components and analysing components’behaviours formally, and the middleware-level, whichprovides the techniques necessary to implement thesemediators. The focus of this paper is on the synthesisof mediators at the application level rather than ontheir implementation at the middleware level. We referthe interested reader to [39] that formalises the relationbetween the application and middleware levels andto [37] for further details about the implementationof mediators.

Figure 11 depicts an example of an emergent mid-dleware. The emergent middleware: (i) intercepts theinput messages, (ii) parses them in order to abstractfrom the communication details and represent them interms of actions as expected by the mediator, (iii) per-forms the necessary data transformations, and (iv) usesthe transformed data to construct an output messagein the format expected by the interacting component.

Steps i), ii) and iv) are performed using middleware-specific parsers and composers to instantiate the datastructures expected by each component and theirdelivery according to the format expected by thecomponent. We can either use existing middlewarelibraries to perform this task or rely on an interpre-tation framework such as Starlink [8] to generatethem at runtime. In the case of the interoperablefile management example, we deployed the mediatorover an Apache Tomcat container.8 The containerintercepts and filters out WebDAV messages. To parsethe WebDAV messages, we used Milton API.9

MessageParsers/

Composers

MessageParsers/

Composers

?β1!ρ1

?ρ2 !β2?δ2

!α2

!δ1?α1

?λ1

t1

t2 t3

t4

Mediator Interpreter

Emergent middleware

Fig. 11. Emergent middleware

8. http://tomcat.apache.org/9. http://milton.ettrema.com/

Step iii) needs further computation. Even thoughsubsumption guarantees the semantic compatibilitybetween concepts, we still need to specify the necessarydata transformations in order for the mediator todeal with the syntactic difference between the in-put/output data. Data mapping is a large and complexproblem [40]. Still, we should distinguish two cases.In the case of simple types only, the translation isquite straightforward and often consists in simple castoperations. However, in most cases we need to dealwith complex data types, e.g. mapping two elaborateXML Schemas. We rely on existing approaches for datamapping that devise different techniques to infer thetransformations needed to translate from one XMLSchema to another. We refer the interested reader tothe complete survey by Shvaiko and Euzenat [40] fora thorough survey and analysis of the approaches thatcan be applied with this goal in mind.

6 EXPERIMENTS

A solution for mediator synthesis can only be useful ifit can be applied to various real-world cases. Section 4focuses on the theoretical aspect of the automatedsynthesis of mediators by proving that the synthesisedmediator guarantees that the components reach theirterminating states and that the composed systemis deadlock-free. This section presents the practicalaspect of the approach by reporting on the results ofexperiments using MICS to generate mediators for real-world case studies. More specifically, the case studiesserve to justify the following claims:

• we automatically generate mediators that not onlytranslate one action required by one componentinto an action provided by the other, but alsosequences of actions between components,

• the synthesised mediators introduce an acceptableoverhead, even though optimising the perfor-mance of mediators is not our main focus, and

• we can synthesise mediators at runtime providedadequate domain knowledge.

Case Studies Highlight

Instant Messaging one-to-one mapping

File Management one-to-many mapping

Event Management one-to-many mapping & loops

GMES one-to-many mapping & extra action & runtime

TABLE 3. Summary of the case studies

Table 3 summarises the type of mappings necessaryto deal with to enable components to interoperate ineach case study. We begin with the instant messagingcase study to illustrate one-to-one mappings. We thenmove to the file management case study, which wepreviously used to illustrate our approach, to highlightone-to-many mappings. The third case relates tointeroperability between event management systems,


which are concerned with the organisation of eventslike conferences, seminars, concerts. This case studyillustrates the case of loops, i.e. when an action isachieved by executing another action multiple times.Finally, we present the GMES (Global Monitoring ofEnvironment and Security10) case to illustrate the needfor mediation at runtime between components thatare dynamically discovered and whose interactionis spontaneous.

In the following sections (Section 6.1 to 6.4), weprovide a description of each case focusing on theperformance of the synthesised mediator. Details aboutthe ontology and the behaviours of the components canbe found elsewhere [37]. The aim of these case studiesis to highlight the type of mappings supported bythe approach and show that the mediator introducesan acceptable overhead. In Section 6.5, we measurethe time necessary to perform each step of the synthesis ofmediators for each case study. The aim is to evaluate thecontribution of each step in the overall synthesis time.

6.1 Instant Messaging: One-to-One Mapping

Description. The evolution of instant messaging (IM)applications provides an insight into today’s commu-nicating applications where different protocols andcompeting standards co-exist. Popular IM applicationsinclude Windows Live Messenger, which is basedon MSNP, Yahoo! Messenger which is based on theYMSG protocol, and Google Talk which is based on theExtensible Messaging and Presence Protocol (XMPP)standard protocol.11 These IM applications offer similarfunctionalities but a user of MSN Messenger wouldbe unable to exchange instant messages with a userof Google Talk. Indeed, even though XMPP is aW3C standard, many IM systems continue to useproprietary protocols. Thus, users have to maintainmultiple accounts and applications in order to interactwith one another. Our aim is to let users install theirfavourite IM applications and synthesise a mediatorthat performs the necessary translations to makedifferent IM applications interoperable.

In [41], we focus on the role of ontologies tosupport one-to-one mapping between heterogeneousIM applications. We started by defining an IM on-tology and used it to annotate the interfaces of theIM components. Then, we used the actions of eachcomponent’s interface to describe its behaviour. Themediator synthesised based on these models simplyperforms one-to-one mappings between the interfacesof the IM applications. We deployed the synthesisedmediator on the Starlink framework [8]Performance. To evaluate the performance of themediator, we measured the time for exchanging a100-character message between pairs of IM appli-cations considering combinations of MSNP, YMSG,

10. http://www.gmes.info/11. http://www.xmpp.org/

and XMPP. The message exchange consists in thefirst IM application sending a message and the otherreplying by sending back the message unchanged. Weuse the notation A/B to designate message exchangebetween an application using protocol A to send themessage and an application using protocol B is tosend back the message. We repeated the experiments50 times and report the average time in Figure 12.The non-mediated interactions include message ex-change between applications using the same protocol,MSNP/MSNP, YMSG/YMSG, and XMPP/YMSG. Inaddition, applications using MSNP and YMSG areable to interact using a proprietary gateway.12 Hence,we also represent non-mediated interactions for theMSNP/YMSG case, as well as YMSG/MSNP case sinceIM is a peer-to-peer application. The performanceof the mediator compared to interactions betweennon-mediated clients depends on the type of the IMprotocol used: while the overhead is negligible forthe XML-based XMPP system, it is significant in thecase of the binary YMSG protocol. It is also worthnoticing that even the gateway-based solution usedin the case of MSNP/YMSG interoperation introducesan overhead of 50% compared to the non-mediatedMSN interactions and more compared to the YMSGinteractions. Yet the time for exchanging a messageremains less than 1s. Guidelines for response time ininteractive applications specify that 1s is the limit tokeep the user’s flow of thought seamless [42]. Hence,we can state that the mediator introduces an acceptableoverhead.

MSNP/MSNP

MSNP/YMSG

MSNP/XMPP

YMSG/YMSG

YMSG/MSNP

YMSG/XMPP

XMPP/XMPP

XMPP/MSNP

XMPP/YMSG

0 100 200 300 400 500 600 700 800

Round Trip +me for exchanging a 100‐character message (ms)

Non‐Mediated Mediated

Fig. 12. Time for mediated and non-mediated interac-

tions between IM components

6.2 File Management: One-to-Many Mapping

We used the file management case to illustrate ourapproach throughout this paper, in this section weevaluate the performance of the synthesised mediator.Performance. We measured the time to perform asimple conversation, which includes authenticating,

12. http://www.microsoft.com/presspass/press/2006/jul06/07-12iminteroppr.mspx


moving a file from one folder to another, and listing thecontent of the two folders. We used a 4KB file to lessenthe network delay. We repeated each conversation50 times and report the average execution time inFigure 13. We use the notation A/B to designatea conversation between a client A an a service B.In the case of the WebDAV client interacting withthe Google Drive service (WebDAV/GoogleDrive),the overhead is negligible compared to the GoogleDrive interactions, while it is 75% more than theWebDAV native interactions. This is mainly due to thenetwork communication time since the former requires3 operations (i.e. 6 messages) while the latter requiresonly one operation (i.e. 2 messages). In the case ofa Google Drive client interacting with the WebDAVservice, the mediator introduces an 18% time overheadcompared to native Google Drive interactions while itis twice the time compared to non-mediated WebDAVinteractions. This time increase is due to the fact thatthe Google Drive actions are translated on a one-to-one basis (e.g. a DownloadDocument to a ReadFile andUploadDocument to WriteFile) instead of being mergedinto a single MoveFile operation. Such an optimisationis however hard to predict as the behaviour of theGoogle Drive client specifies that these three operationscan be performed in any order.

0 200 400 600 800 1000 1200 1400 1600

GoogleDrive/WebDAV

WebDAV/GoogleDrive

GoogleDrive/GoogleDrive

WebDAV/WebDAV

Time to perform a conversa0on (ms)

Non‐Mediated Mediated

Fig. 13. Time or mediated and non-mediated interac-

tions between WebDAV and Google Drive

6.3 Event Management: One-to-Many Mappingand Loops

Description. Event organisers usually rely on existingand specialised event management systems to preparetheir events as they generally offer an economical andbetter quality solution compared to building their ownsystem. In order to use an event management service,an organiser has to include within its application aclient able to interact with the service provider. De-pending on the event they are in charge of, organisersmay have to integrate with multiple event manage-ment providers. However, event management systemsoften exhibit different interfaces and behaviours.

We investigated this case study with an industrialpartner Ambientic.13 Ambientic provides a suite of

13. http://www.ambientic.com/en/

mobile application to facilitate the organisation ofevents and improve collaboration between the differentstockholders. Ambientic needs solutions to interfacewith multiple existing event management servicesas required by its customers. However, developinga client for each event management service rapidlybecomes fastidious. Our solution intends to simplifyand automate the support of multiple services.

We considered two event management systems:Amiando14 and RegOnline.15 We focused on the sce-nario where a customer searches for events that includesome keywords in their title, and then examines theinformation about the events found. In Amiando,customers have to send an EventFind request withthe keywords to search for. The EventFind responseincludes a list of event identifiers. To get the infor-mation about an event, customers must invoke theEventRead operation with the event identifier as aninput parameter. In RegOnline, customers have onlyto send a GetEvents request including the keywordsto search for. As a result, the client obtains the listof events verifying the search criteria, each of whichassociated with the corresponding information.

We built upon the eBiquity event ontology16, whichdefines the vocabulary for describing and relatinginformation elements that are commonly used inevent management systems. We used the ontologyto annotate the interfaces of the components. Thenwe used the actions of the components’ interfacesto describe their behaviours. The performance of themediator synthesised based on the resulting modelsare described in the following.

0 200 400 600 800 1000 1200 1400 1600 1800 2000

Amiando/RegOnline

RegOnline/Amiando

Amiando/Amiando

RegOnline/RegOnline


Non‐mediated Mediated

Fig. 14. Time for mediated and non-mediated interac-

tions between Amiando and RegOnline

Performance. To evaluate the performance of themediator, we performed a simple conversation, whichconsists of a search based on a substring of thetitle of events, then getting a list of 10 events withthe corresponding description for each event. Werepeated each conversation 30 times for each possi-ble pair of Amiando and RegOnline and report theaverage execution time in Figure 14. Even without

14. http://developers.amiando.com/15. http://developer.regonline.com/16. http://ebiquity.umbc.edu/ontology/event.owl


any mediation, Amiando necessitates 3 times moretime than RegOnline. This is due to the fact that itmust send several messages on the network, each ofwhich contains the information of one event whereasin RegOnline, the description of all events is sentin a single message. This is reflected in the case ofRegOnline client interacting with the Amiando serviceas the mediator has to make many requests in orderto create the message required by the client. One wayto remedy this overhead is to send requests in parallel,but the synthesised mediator is not equipped for thatand performs the translations only in sequence. Foran Amiando client, using the RegOnline service iseven more efficient than using its own service. Thereason is that the mediator invokes RegOnline onceand keeps the results; hence when the Amiando clientsends an EventRead the response is ready and no extraprocessing is necessary.

6.4 GMES: Runtime Mediation

Description. To provide insight into the benefits ofusing the synthesis of mediators to support interoper-ability at runtime, we now present the experiment weconducted in the context of the GMES initiative, whichwas used as a demonstrator for the EU CONNECT

project [43]. GMES is the European Programme forestablishing a European capacity for Earth Observation.In particular, a special interest is given to the supportof emergency situations (e.g. forest fire) across differentEuropean countries. Indeed, each country defines anemergency management system that encompassesmultiple components that are autonomous as well asdesigned and implemented independently. Nonethe-less, there are incentives for these components to becomposed and collaborate in emergency situations.GMES makes a strong case of the need for solutionsto enable multiple, and most likely heterogeneous,components to interoperate in order to perform thedifferent tasks necessary for decision making. Thesetasks include collecting weather information, locatingthe agents involved (e.g. firemen), and monitoring theenvironment.

Country 1 Country 2

Weather Service

Positioning-A

Weather Station Client

Positioning-BC2 Positioning-B Subscriber

UAV ClientUAVUGV

SOAP

SOAP

SOAP

CORBA

AMQP

SOAP

Weather Station

Fig. 15. Illustrating interoperability in GMES

Figure 15 depicts the case where the emergencysystem of Country 1 is composed of a Command and

Control centre (C2) which takes the necessary decisionsfor managing the crisis based on the informationabout the weather provided by the Weather Servicecomponent, the positions of the various agents infield given by Positioning-A, and the monitoring of theenvironment using UGV (Unmanned Ground Vehicle).Country 2 assists Country 1 by supplying componentsthat provide C2 with extra information. These com-ponents are Weather Station, Positioning-B, and UAV(Unmanned Aerial Vehicle). However, C2 cannot usethese components directly. Indeed, Weather Stationprovides specific information such as temperatureor humidity whereas Weather Service, which is usedby C2, returns all of this information using a singleoperation. The UGV requires the client to login, thenit can explore the environment by moving forward orbackward as well as turning while UAV is requiredto takeoff prior to performing any of these operationsand to land before logging out. Both UGV and UAVare managed through SOAP-based controllers, hencethe components’ models do not include the low-levelinformation for managing the robots. Note that GMESfurther illustrates differences between the componentsat the middleware level, e.g. SOAP and CORBA orAMQP. These differences must be handled during theimplementation of the synthesised mediator. We referthe interested reader to [39] for a formal analysis ofcombined application-middleware differences betweencomponents while further details about application ofthis analysis in the GMES case can be found in [37].

In this case study, we first built a GMES ontologyand asked the developers of each system, which werepart of the CONNECT consortium, to use it to annotatethe interface of their components. A discovery enabler,provided by the CONNECT consortium [44] was usedto locate the components, extract their models, andtrigger the synthesis of mediators for functionally-compatible components. We evaluate the performanceof the mediator in the following.

C2/Weather Service

Weather Station/Client

C2/Weather Station

C2/Positioning-A

Positioning-B/Subscriber

C2/Positioning-B

C2/UGV

UAV/Client

C2/UAV

We

ath

er

P

ositio

nin

g

Ve

hic

le

0 50 100 150 200 250 300 350


Country 1 Systems (Non‐Mediated)

Country 2 Systems (Non‐Mediated)

Country 1 → Country 2 (Mediated)

Fig. 16. Time for mediated and non-mediation interac-

tion between GMES components

Performance. For each scenario, we measured theaverage time necessary to perform a meaningfulconversation. In the weather scenario, the conversation


Instant Messaging File Management Event Management GMES

Weather Positioning Vehicle

Number of concepts (Disjunctions) 10 (0) 78 (7) 8 (2) 283 (2) 283 (2) 283 (2)

Time for encoding (ms) 300 ms 2502 ms 834 ms 9689 ms 9689 ms 9689 ms

|I1| × |I2| 9 × 5 9 × 7 2 × 2 3 × 4 1 × 1 7 × 11

Time for mapping (ms) 37 ms 672 ms 247 ms 342 ms 20 ms 567 ms

|States(P1)| × |States(P2)| 7 × 4 3 × 2 2 × 3 2 × 2 1 × 1 2 × 4

Time for synthesis (ms) 4 ms 5 ms 5 ms 2 ms <1 ms 7 ms

TABLE 4. Processing time (in milliseconds) for each mediation step

includes authentication, obtaining weather informa-tion, and logging out. In the positioning scenario, asingle operation is performed in order to locate theagents. In the vehicle control scenario, conversationsconsist in authentication, takeoff (in the case of UAVonly), moving forward, turning left, moving backward,turning right, landing (in the case of UAV only), andlogging out. We repeated each conversation 50 timesand computed the average duration. The results arepresented in Figure 16. In the weather scenario, themediated interaction between C2 and Weather Stationtakes three times the time required for C2 to interactwith the associated Weather Service and twice the timenecessary for interaction between Weather Station andthe associated client. This is due to the accumulation ofthe communication time in the mediated case since, theservices being quite simple, the time to send/receivethe messages on the network is much bigger thatthe processing time. In the positioning scenario, theoverhead introduced by the mediator between C2 andPositioning-B is almost non-existent. The reason is theuse of a Publish/Subscribe communication paradigm(AMQP) by Positioning-B. Hence, the implementedmediator acts as a subscriber, receiving and transform-ing the data as they are published. As a result, themediator can reply to the positioning request sentby C2 without the need for sending a request toPositioning-B. In the vehicle scenario, the mediatedconversations between C2 and UAV require threetimes the time required for C2 to interact with UGVand nearly twice the time necessary for interactionbetween UAV and the associated client. Similarlyto the weather scenario, the mediated conversationsaccumulate the communication time with both systemswithout additional overhead due to the extra providedactions. Yet the time for mediated conversations alwaysremains less than 1s, i.e. below the response timerecommended for interactive applications to keep theuser’s flow of thought seamless [42].

6.5 Performance of MICS

In the previous section, we showed that automaticallysynthesised mediators enable heterogeneous compo-nents to interoperate while introducing an acceptable

overhead. Let us now consider the time taken tosynthesise mediators. Table 4 summarises the timeto perform each mediation step (ontology encoding,interface mapping, and behavioural synthesis of me-diators) for the aforementioned case studies.

First, the time for ontology encoding mainly dependson the size, i.e. the number of concepts, of the ontology.The greater the size of the ontology, the more time ittakes to encode it. The number of disjunctions alsoinfluences the encoding, for example the ontologyused for event management includes 8 concepts whilethe IM ontology includes 10 concepts but it takes 3times longer to encode the former as it also includesdisjunction concepts. The time to perform interfacemappings depends mainly on the type of mappingencountered. In the case of one-to-one mapping, thistime is minimal even with larger interfaces. In fact,computing one-to-one mappings can be performedin polynomial time, which the constraint solver isable to detect and hence calculate the mapping moreefficiently. Finally, the time for the synthesis is marginaleven though theoretically complex. This is because thebehaviour of each component remains simple whilethe complexity emerges from the interaction betweencomponents.

Ontology(Encoding( Interface(Mapping( Mediator(Synthesis(

96.57%

3.41% 0.02%

GMES‐Weather

87.98%

10.85% 1.17%

Instant Messaging

78.70%

21.14%

0.16%

File Management

87.34%

12.41% 0.25%

Event Management

99.78%

0.21% 0.01%

GMES‐Posi8oning

94.41%

5.52% 0.07%

GMES‐Vehicle

Fig. 17. Comparison of the time necessary for each

mediation step

Figure 17 illustrates the time ratio for each mediationstep. It can be seen that the ontology encoding isthe most time-consuming step. Still, ontologies are


static entities since they represent knowledge andunderstanding of the application domain and are notspecific to the components to be mediated. Hence,the ontology encoding can be performed beforehandand used when the need arises. The time ratio forinterface mapping varies greatly between case studiesaccording to the type of mapping: whether one-to-oneor one-to-many. Finally, the time for generating themediator based on the computed mappings representsonly a small part of the overall processing time andis negligible compared to ontology processing. So,although the use of ontology allows us to reasonabout the semantics of data and operations and henceincreases the level of automation, it comes with a cost.While standards such as OWL-S [19] or WSMO [20]amalgamate data semantics and behaviour and useontology to represent and reason about both, ourapproach only uses ontologies when needed and relieson appropriate formalisms for behaviour analysisthereby making the best use of both formalisms. Thisseparation is even more important when it comes tokeeping the mediator up to date to cope with changesin the models of the components or the ontology asdiscussed in Section 8. When the model of a componentchanges, the synthesis of the mediator can be based onthe previous interface mapping and ontology encoding,which are the most time-consuming phases. Whenone of the components changes its interface, thenthe synthesis has to resume from interface mapping.Finally, if the ontology evolves, the synthesis has tobe restarted from the ontology encoding.

7 RELATED WORK

Interoperability has received a great deal of interestand led to the provision of a multitude of solutions,both theoretical and practical, albeit primarily orientedtoward design time. In [4], we survey the differentapproaches to mediation and give initial thoughtsabout an ontology-based approach to the dynamicsynthesis of mediators. In this section, we summarisevarious approaches to mediation seen from the perspec-tive of its underpinning fields: software architecture,middleware, formal methods and Semantic Web.

Software Architecture. Early work on interoperabilityin the software architecture field involved identifying,classifying and giving generic rules and guidelines todevelopers in order to increase reuse and achieve inter-operability by alleviating architectural mismatches [3].Spitznagel and Garlan [6] introduce a set of transforma-tion patterns (e.g. data translation), which a developercan apply to basic connectors (e.g. RPC) in order toconstruct more complex connectors so as to solvearchitectural mismatches. Chang et al. [45] proposeto use healing connectors in order to solve integrationproblems at runtime by applying healing strategiesdefined by the developers of the COTS components atdesign time. With a focus on behavioural mediation,

Inverardi and Tivoli [46] define an approach to com-pute a mediator that composes a set of pre-definedpatterns in order to guarantee that the interaction ofcomponents is deadlock-free. These patterns representsimple mechanisms that the mediator executes tosolve differences between the interfaces or behavioursof components. However, the specification of thepatterns to be used is left up to the developers. Inour approach, the differences between the interfaces ofthe components are solved using mapping processes,which are automatically computed given some domainknowledge modelled using an ontology. It is the roleof the domain expert to define this ontology, which isrelated to the application domain rather than to thesoftware components involved.

Middleware. Middleware stands as a conceptualparadigm to connect applications effectively despiteheterogeneities in the underlying hardware and soft-ware. Enterprise Service Buses [47] are open standard,message-based middleware solution that facilitates theinteractions of disparate distributed applications andservices. ESBs generally include built-in conversionacross standard middleware technologies (e.g. SOAP,JMS) and provide a set of predefined patterns that canbe used to create customised mediators. However, ESBsconsider the interoperability problem from an enterprisesystems perspective, where interactions are planned andlong-lived and are inappropriate for cases where thecomponent are only known at runtime. In our ap-proach, each component is independently specified andthe appropriate mediator is produced automatically,given some domain knowledge.

Formal Methods. Formal methods focus on the be-haviour of software systems, which they rigorouslyanalyse in order to reveal potential execution errors.Once potential execution errors (a.k.a. mismatches) aredetected, they can be solved either by eliminating theinteractions leading to the errors or by introducing amediator that forces the components to coordinate theirbehaviours correctly. Existing solutions to synthesisemediators assume to be given an abstract specificationof the mediator, an adaptation contract [7] or aninterface mapping [14]. Nezhad et al. [48] proposea semi-automated approach to identity interface map-ping by comparing the XML schemas describing thesyntax of actions. Other approaches combine XMLmatching and behavioural reasoning to synthesisethe mediator [49], [50]. The major difference betweenthese approaches and ours is the consideration of theaction semantics, which allows us to compute thecorrespondance between sequences of actions and tomanage a larger range of mismatches, which cannotbe directly handled considering the syntax of actionsalone. Cavallaro et al. [51] consider the semantics ofdata and rely on model checking to identify mappingscripts between interaction protocols automatically.However, they propose to align the vocabulary of theprocesses beforehand, but many mappings may exist


and should be considered during mediator synthesis.Semantic Web. The Semantic Web is an extension of

the Web in which information is given well-definedmeaning, using ontologies, in order to better enablecomputers and people to work in cooperation [52].WSMO [20] defines a description language that inte-grates ontologies with state machines for representingSemantic Web Services. It also proposes a frameworkto mediate interaction between services on the basis ofpre-defined mediation patterns. However, there is noguarantee that the composition of these patterns willbe deadlock-free. Vaculın et al. [29] devise a mediationapproach for OWL-S processes. They first generate allrequesters paths, then find the appropriate mappingfor each path by simulating the provider process. Thisapproach does not deal with the case of one actionthat can be mapped to different other actions.

Even though a lot of progress has been made bothin understanding and achieving interoperability, itremains an open issue as we can unfortunately observeit in our everyday life. We believe that the automationof mediator synthesis has a great potential and showhow it can be achieved in this paper.

8 FUTURE WORK

In the previous sections, we presented an approachfor the synthesis of correct mediators that enableheterogeneous components to interoperate. In thissection, we discuss some possible enhancements ofthis approach.

Ontology Heterogeneity and Quality. It is crucial tothink about ontologies as a means to interoperabilityrather than universality. It is often the case that manyontologies co-exist and need to be matched withone another. Ontology matching techniques primarilyexploit knowledge explicitly encoded in the ontologyrather than trying to guess the meaning encoded in theschemas, as is the case with XML schemas for example.More specifically, while XML schema matching tech-niques rely on the use of statistics measures of syntacticsimilarity, ontologies deal with axioms and how theycan be put together [40]. In the future, we aim toextend our model so as to consider the heterogeneity ofthe ontologies themselves and reason about interfacemapping under imprecise information. In addition,empirical studies, which involve users with differentexpertise in ontology languages and knowledge of theapplication domain, would allow us to evaluate theeffort necessary for developing ontologies as well asto assess the quality of the resulting ontologies andtheirs potential heterogeneity.

Goal-driven Mediation. In our approach, we postulatethat all actions required by one component musthave a semantically compatible action or sequenceof actions provided by the other component. Thisrequirement allows us to prove that the mediatedsystem is free from deadlocks. The user may beinterested in achieving a specific task only and we

can permit interaction between components if wecan mediate their behaviour to perform this specifictask [53]. To paraphrase, instead of generating themediator process M such that P1 and P2 reach theirfinal states and P1‖M‖P2 is deadlock free, we generateM such that the composition satisfies a given goalG, i.e. P1‖M‖P2 |= G. However, this general case ofmediator synthesis is known to be computationallyexpensive: when G is expressed as an LTL formula, itmay reach complexity of double exponent in the sizeof G [54]. Yet there exist subclass of formulas for whichthe synthesis problem can be solved in polynomialtime [55]. Further investigation is necessary to evaluatehow relevant these cases are.

Multi-Party Mediators. With the advent of social-based interactions and the increased emphasis oncollaboration, interoperability between multiple (morethan two) components is gaining momentum. Onesimple solution to handle this case is by combiningassembly methods (e.g., [56]) with pairwise mediators.The former consider the structural constraints andspecify a coarse-grained composition of componentsbased on their capabilities, while the latter take careof enforcing this composition despite the interface andbehavioural differences that may exist between eachpair of components. Another direction is to perform theinterface mapping to find the correspondence betweenthe required actions of one components and sequencesof actions from all other components. These mappingsthen should be composed in order to enable eachcomponent to reach its terminating state as well as toensure that the system composed of all components isdeadlock-free. While the interface mapping is similarto the case of two components, further investigation isnecessary to evaluate the complexity of the simultane-ous exploration of multiple components’ behaviourswhile composing the interface mappings.

Coping with Changes. Our ultimate goal is to make themediator evolve gracefully as additional knowledgebecomes available, components change, or ontologyevolves. In addition, we may use machine learningtechniques to infer the model of the system. Whilemachine learning improves automation by inferringthe model of the component from its implementation,it also induces some inaccuracy that we must handle.Therefore, we have to keep monitoring the systemand the environment to detect changes and updatethe mediator accordingly. In this context, incremental re-synthesis would be essential to cope with both the dynamicaspect and partial knowledge about the environment.

9 CONCLUSION

Interoperability is a key challenge in software engineer-ing whether expressed in terms of the compatibilityof different components and protocols, in terms ofcompliance to industry standards or increasingly interms of the ability to share and reuse data gatheredfrom different systems. The possibility of achieving


interoperability between components without actuallymodifying their interfaces or behaviour is desirableand often necessary in today’s open environments [57].Mediators promote the seamless interconnection of het-erogeneous components by performing the necessarytranslations between their messages and coordinatingtheir behaviour. Our core contribution stems from theprincipled automated synthesis of mediators. In thispaper, we presented an approach to infer mappingsbetween component interfaces by reasoning about thesemantics of their data and operations. We then usethese mappings to automatically synthesise a correct-by-construction mediator. An important aspect of ourapproach is the use of ontologies to capture the semanticknowledge about the communicating components. Thisrigorous approach to generating mediators removesthe need to develop ad hoc bridging solutions andfosters future-proof interoperability. We believe thatthis work holds great promise for the future.

ACKNOWLEDGMENTS

We gratefully acknowledge Daniel Sykes, Animesh Pathak

and Thiago Teixeira for their insightful comments. We thank

Thierry Martinez for his help on MICS as well as Emil An-

driescu and Roberto Speicys Cardoso for their collaboration

in the Event Management case study. The authors would

like to thank the referees for their thorough reviews, helpful

comments, and corrections that have improved this paper.

They would like to acknowledge that this research was

supported by the FP7 CONNECT project and ERC Advanced

Grant no. 291652 (ASAP).

REFERENCES

[1] D. Konstantas, J.-P. Bourrires, M. Lonard, and N. Boudjlida,Interoperability of enterprise software and applications. Springer-Verlag, 2006.

[2] D. Garlan, R. Allen, and J. Ockerbloom, “Architectural mis-match: Why reuse is still so hard,” IEEE Software, 2009.

[3] M. Shaw, “Architectural issues in software reuse: It’s not justthe functionality, it’s the packaging,” in Proc. SSR, 1995.

[4] V. Issarny, A. Bennaceur, and Y.-D. Bromberg, “Middleware-layer connector synthesis: Beyond state of the art in middlewareinteroperability,” in SFM-11, 2011.

[5] M. Autili, P. Inverardi, A. Navarra, and M. Tivoli, “SYNTHESIS:A tool for automatically assembling correct and distributedcomponent-based systems,” in Proc. ICSE, 2007.

[6] B. Spitznagel and D. Garlan, “A compositional formalizationof connector wrappers,” in Proc. ICSE, 2003.

[7] R. Mateescu, P. Poizat, and G. Salaun, “Adaptation of serviceprotocols using process algebra and on-the-fly reductiontechniques,” IEEE Trans. on Soft. Eng., 2011.

[8] Y.-D. Bromberg, P. Grace, L. Reveillere, and G. S. Blair, “Bridg-ing the interoperability gap: Overcoming combined applicationand middleware heterogeneity,” in Proc. Middleware, 2011.

[9] C. Gierds, A. J. Mooij, and K. Wolf, “Reducing adapter synthesisto controller synthesis,” IEEE T. Services Computing, 2012.

[10] G. Wiederhold, “Mediators in the architecture of future in-formation systems,” IEEE Computer, vol. 25, no. 3, pp. 38–49,1992.

[11] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Designpatterns: elements of reusable object-oriented software. PearsonEducation, 1994.

[12] M. W. Maier, “Integrated modeling: A unified approach tosystem engineering,” Journal of Syst. and Softw., 1996.

[13] E. Morris, L. Levine, C. Meyers, P. Place, and D. Plakosh,“System of systems interoperability (sosi): final report,” DTICDocument, CMU/SEI, Tech. Rep., 2004.

[14] D. M. Yellin and R. E. Strom, “Protocol specifications andcomponent adaptors,” ACM Trans. Program. Lang. Syst., 1997.

[15] N. Shadbolt, T. Berners-Lee, and W. Hall, “The semantic webrevisited,” IEEE Intelligent Systems, 2006.

[16] F. Baader, D. Calvanese, D. L. McGuinness, D. Nardi, and P. F.Patel-Schneider, The Description Logic Handbook. CambridgeUniversity Press, 2003.

[17] C. Calero, F. Ruiz, and M. Piattini, Ontologies for SoftwareEngineering and Software Technology. Springer-Verlag, 2006.

[18] S. B. Mokhtar, N. Georgantas, and V. Issarny, “COCOA:Conversation-based service composition in pervasive comput-ing environments with qos support,” J. of Syst. and Soft.., 2007.

[19] D. L. Martin, M. H. Burstein, D. V. McDermott, S. A. McIlraith,M. Paolucci, K. P. Sycara, D. L. McGuinness, E. Sirin, andN. Srinivasan, “Bringing semantics to web services with OWL-S,” in Proc. WWW, 2007.

[20] E. Cimpian and A. Mocan, “WSMX process mediation basedon choreographies,” in Proc. Business Process Mgmt Work., 2005.

[21] N. Guarino, “Helping people (and machines) understandingeach other: The role of formal ontology,” in Proc. CoopIS, 2004.

[22] M. d’Aquin and N. F. Noy, “Where to publish and findontologies? a survey of ontology libraries,” J. Web Sem., 2012.

[23] A. Borgida and P. T. Devanbu, “Adding more “DL” to IDL:Towards more knowledgeable component inter-operability,” inProc. ICSE, 1999.

[24] N. Oldham, C. Thomas, A. P. Sheth, and K. Verma, “METEOR-S web service annotation framework with machine learningclassification,” in Proc. SWSWPC, 2004.

[25] A. Bennaceur, V. Issarny, D. Sykes, F. Howar, M. Isberner,B. Steffen, R. Johansson, and A. Moschitti, “Machine learningfor emergent middleware,” in Proc. of the Joint workshop onIntelligent Methods for Soft. System Eng., JIMSE, 2012.

[26] J. Magee and J. Kramer, Concurrency : State models and Javaprograms. Hoboken (N.J.) : Wiley, 2006.

[27] R. M. Keller, “Formal verification of parallel programs,” Com-mun. ACM, 1976.

[28] D. Brand and P. Zafiropulo, “On communicating finite-statemachines,” Journal of the ACM, 1983.

[29] R. Vaculın and K. P. Sycara, “Towards automatic mediation ofOWL-S process models,” in Proc. ICWS, 2007.

[30] D. Lorenzoli, L. Mariani, and M. Pezze, “Automatic generationof software behavioral models,” in Proc. ICSE, 2008.

[31] I. Krka, Y. Brun, D. Popescu, J. Garcia, and N. Medvidovic,“Using dynamic execution traces and program invariants toenhance behavioral model inference,” in Proc. ICSE, 2010.

[32] M. Paolucci, T. Kawamura, T. R. Payne, and K. P. Sycara,“Semantic matching of WS capabilities,” in Proc. ISWC, 2002.

[33] C. A. R. Hoare, “Process algebra: A unifying approach,” in 25Years Comm. Seq. Processes, 2004.

[34] G. S. Blair, A. Bennaceur, N. Georgantas, P. Grace, V. Issarny,V. Nundloll, and M. Paolucci, “The role of ontologies inemergent middleware: Supporting interoperability in complexdistributed systems,” in Proc. Middleware, 2011.

[35] F. Rossi, P. Van Beek, and T. Walsh, Handbook of constraintprogramming. Elsevier Science, 2006.

[36] B. Liskov and J. M. Wing, “A behavioral notion of subtyping,”ACM Trans. Program. Lang. Syst., 1994.

[37] A. Bennaceur, “Dynamic synthesis of mediators in ubiquitousenvironments,” Ph.D. dissertation, Universite Paris VI, 2013.[Online]. Available: http://hal.inria.fr/tel-00849402/en

[38] F. Laburthe, “Constraints over ontologies,” in Proc. CP, 2003.[39] A. Bennaceur and V. Issarny, “Layered Connectors: Revisiting

the Formal Basis of Architectural Connection for ComplexDistributed Systems,” in Proc. ECSA, 2014, to appear. [Online].Available: http://hal.inria.fr/hal-01015897

[40] P. Shvaiko and J. Euzenat, “A survey of schema-based matchingapproaches,” J. Data Semantics IV, 2005.

[41] A. Bennaceur, V. Issarny, R. Spalazzese, and S. Tyagi, “Achiev-ing Interoperability through Semantics-based Technologies: TheInstant Messaging Case,” in Proc. ISWC, 2012.

[42] J. Nielsen, Usability Engineering. San Francisco, CA, USA:Morgan Kaufmann Publishers Inc., 1993.


[43] V. Issarny, B. Steffen, B. Jonsson, G. S. Blair, P. Grace, M. Z.Kwiatkowska, R. Calinescu, P. Inverardi, M. Tivoli, A. Bertolino,and A. Sabetta, “CONNECT challenges: towards emergent connec-tors for eternal networked systems,” in Proc. ICECCS, 2009.

[44] N. Bencomo, A. Bennaceur, P. Grace, G. S. Blair, and V. Is-sarny, “The role of [email protected] in supporting on-the-flyinteroperability,” Computing, vol. 95, no. 3, pp. 167–190, 2013.

[45] H. Chang, L. Mariani, and M. Pezze, “In-field healing ofintegration problems with cots components,” in Proc. ICSE,2009.

[46] P. Inverardi and M. Tivoli, “Automatic synthesis of modularconnectors via composition of protocol mediation patterns,” inProc. ICSE, 2013.

[47] F. Menge, “Enterprise Service Bus,” in Proc. of the Free and opensource soft. conf., 2007.

[48] H. R. M. Nezhad, G. Y. Xu, and B. Benatallah, “Protocol-awarematching of web service interfaces for adapter development,”in Proc. WWW, 2010.

[49] A. Brogi and R. Popescu, “Automated generation of bpeladapters,” in ICSOC, 2006, pp. 27–39.

[50] A. Algergawy, R. Nayak, N. Siegmund, V. Koppen, andG. Saake, “Combining schema and level-based matching forweb service discovery,” in Proc. ICWE, 2010, pp. 114–128.

[51] L. Cavallaro, E. D. Nitto, and M. Pradella, “An automaticapproach to enable replacement of conversational services,” inProc. ICSOC/ServiceWave, 2009.

[52] T. Berners-Lee, J. Hendler, O. Lassila et al., “The semantic web,”Scientific american, 2001.

[53] L. Cavallaro, P. Sawyer, D. Sykes, N. Bencomo, and V. Issarny,“Satisfying requirements for pervasive service compositions,”in Proc. [email protected], 2012.

[54] A. Pnueli and R. Rosner, “On the synthesis of a reactivemodule,” in Proc. POPL, 1989.

[55] R. Bloem, B. Jobstmann, N. Piterman, A. Pnueli, and Y. Sa’ar,“Synthesis of reactive(1) designs,” J. Comput. Syst. Sci., vol. 78,no. 3, pp. 911–938, 2012.

[56] D. Sykes, J. Magee, and J. Kramer, “Flashmob: distributedadaptive self-assembly,” in Proc. SEAMS, 2011.

[57] L. Baresi, E. Di Nitto, and C. Ghezzi, “Toward open-worldsoftware: Issue and challenges,” Computer, 2006.

Amel Bennaceur received the PhD degreein Computer Science from the University ofParis VI in July 2013. She is now a ResearchAssociate at the Open University, UK. Herresearch interests include dynamic mediatorsynthesis for interoperability and collaborativesecurity. See http://amel.me for further detailsand a list of publications.

Valerie Issarny is Directrice de Recherche atInria, France. Her research interests relateto distributed systems, software engineer-ing, middleware, pervasive computing, andservice-oriented computing. She has beeninvolved in a number of European and Frenchprojects and initiatives in the above areas.She has further been member of organisa-tion and programme committees of leadingevents in those fields. Since 2013, she isthe scientific manager of the Inria@Silicon

Valley program and coordinate the Inria CityLab initiative on smartcities promoting citizen engagement, and that is developed in closecollaboration with researchers of CITRIS, the Center for InformationTechnology Research in the Interest of Society, at University ofCalifornia, Berkeley. Further information about Valerie’s researchinterests and her publications can be obtained at: https://www.rocq.inria.fr/arles/issarny.

Documents

Automated Synthesis of Mediators to Support Component ... · to Support Component Interoperability ... mediation based on pre-deﬁned patterns but without ensuring that such mediation