A Coordination Middleware for Orchestrating Heterogeneous

A Coordination Middleware for Orchestrating

Heterogeneous Distributed Systems

Nikolaos Georgantas, Mohammad Ashiqur Rahaman, Hamid Ameziani,Animesh Pathak, and Valerie Issarny

INRIA Paris-Rocquencourt, [email protected]

Abstract. Integration of heterogeneous distributed systems becomesparticularly challenging when these systems have diverse coordinationmodels (e.g., client/server, publish/subscribe, tuple space). In this pa-per, we introduce a system integration solution based on orchestrationworkflow and a high-level data-driven coordination abstraction enablingapplication workflows that are agnostic to the underlying middlewareplatforms and associated coordination models of the constituent sys-tems. Our solution features an extensible generic coordination middle-ware, which enables middleware designers to easily incorporate supportfor new middleware platforms and facilitates application designers indesigning complex applications.

1 Introduction

In the near future, complex distributed applications will be to a large extentbased on the integration of extremely heterogeneous systems, such as lightweightembedded systems (e.g., sensors, actuators and networks of them), mobile sys-tems (e.g., smartphone applications), and resource-rich IT systems (e.g., systemshosted on enterprise servers and Grid infrastructures). These heterogeneous sys-tem domains have developed individually, with significant advancements in termsof coordination models (CMs), communication protocols, data representationmodels, as well as related middleware platforms that incorporate the formerthus providing integral support to applications. In particular with regard tomiddleware-supported coordination, the client/server (CS), publish/subscribe(PS), and tuple space (TS) models are among the most widely employed ones,with numerous related middleware platforms, such as: Web Services, Java RMIfor CS; JMS, SIENA for PS [1,2]; and JavaSpaces, Lime, DART for TS [3,4,5].

In the following, we outline a representative application scenario, where acomplex distributed application needs to be devised by integrating heterogeneoussystems that interact with varying CMs. This scenario concerns Search andRescue (S&R) operations after a disaster, such as a flood or an earthquake.

S&R operations are carried out in a highly hazardous environment withlarge numbers of injured parties entrapped in scattered places. In suchsituations, personnel from multiple agencies (i.e., fire-fighters, police,

J. Riekki, M. Ylianttila, and M. Guo (Eds.): GPC 2011, LNCS 6646, pp. 221–232, 2011.c© Springer-Verlag Berlin Heidelberg 2011

222 N. Georgantas et al.

Red Cross) must coordinate. To detect survivors, sensor nodes are in-stalled at various places of the hazardous area. Upon installation/move,such nodes communicate their GPS coordinates. S&R personnel also no-tify automatically at short intervals of their current positions via theirPDAs. Upon sensing some life sign, sensor nodes send out notifications.At the same time, nearby light-emitting actuators start lighting the placeto facilitate the rescuing effort. Sensors, PDAs, and actuators interactamong them and with external actors via a TS. The above positioningdata/life sign notifications are sent periodically/instantly via a CS in-vocation to a planning service that calculates distances and paths andprovides/recommends at real time the current/optimal deployment ofrescue forces. This output is then notified via a PS system to the co-ordinator of the operation on her smart phone and also to a numberof control/monitoring centers. The coordinator may approve and com-mand appropriate personnel via the PS system to rush into the spot.Commands reach the personnel via their TS-enabled PDAs.

To enable such a scenario, the heterogeneity between the involved system do-mains needs to be tackled. Existing cross-domain interoperability efforts arebased on, e.g., bridging communication protocols [6], wrapping systems be-hind standard technology interfaces [7], and/or providing common API abstrac-tions [8,9,10,11]. However, such efforts commonly cover part of the heterogeneityissues (regarding coordination, communication, data) and are applicable to spe-cific cases. In particular, existing solutions do not or only poorly address CMinteroperability.

In this paper1, we propose a model-based system integration approach thatcan deal with diverse existing systems, focusing in particular on integratingtheir heterogeneous CMs. Firstly, our solution features workflow-based orches-tration of the constituent systems. Orchestration workflow is a well-establishedparadigm for composing different systems under the control of a central coordi-nating entity. A number of models, languages and associated support platformshave been proposed for designing and executing orchestrations, however, focus-ing almost exclusively on service-oriented systems, i.e., assuming CS coordina-tion. Among them, BPEL is the most widely used solution, a standard for WebServices orchestration2. Envisaging heterogeneous orchestrations, we extend theworkflow-based orchestration model to cover diverse CMs. However, this resultsin additional complexity for the application designer, who is required to deal inher workflow with all the heterogeneous CMs of the constituent systems. Thus,secondly, our solution introduces a single higher-level CM to abstract from theunderlying CMs of the constituent systems. We call the former application CMand the latter middleware CMs, thus introducing a decoupling between the ab-stracted CM to be employed in application workflow design and the native CMsof the constituent systems to be employed in the execution of the application1 This work has been partially supported by the ITEmIS project (http://itemis-

anr.org/) funded by the French National Research Agency (ANR).2 http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html

A Coordination Middleware 223

workflow. To elicit a unique application coordination abstraction, we observethat conveying application data is a common denominator of all middlewareCMs. This leads us to propose data-driven application-level coordination. Wespecifically introduce Global Data Space (GDS) as part of our workflow model, aspecial TS abstracting interactions between workflows and constituent systems.Inherent properties of the TS model, such as time and space decoupling amongcommunication entities [4], make it sufficiently generic for abstracting complexdistributed applications that integrate heterogeneous systems.

Our systematic abstraction approach is carried out in two stages. First, a mid-dleware platform is abstracted under a corresponding middleware CM amongthe three principal ones, i.e., CS, PS and TS. To this aim, we elicit genericcoordination primitives for each model comprehensively covering their essentialsemantics, after having thoroughly surveyed the related literature. Then, thesethree models are abstracted further into the unique application CM. We intro-duce high-level generic coordination primitives for the GDS model (derived fromthe TS primitives) and mappings between them and the primitives of each one ofCS, PS and TS. Our two-step abstraction and decoupling between application-and middleware-level coordination enable orchestrations that are agnostic to theunderlying middleware platforms of the heterogeneous constituent systems.

The above concepts are incorporated into an abstract coordination middle-ware architecture (Section 2), which we implement into a prototype extensiblecoordination middleware by building upon BPEL and its extensibility supportmechanism (Section 3). We further explicitly identify the roles of the appli-cation and middleware designers and provide them with design-time support:enabling the former to easily design application workflows integrating heteroge-neous constituent systems; and the latter to rapidly add support for new mid-dleware platforms into the prototype coordination middleware. We demonstratethe applicability of our approach by implementing the representative scenariointroduced above. Based on this implementation, we evaluate our approach byapplying design time metrics for measuring the support offered to the applica-tion and middleware designers (Section 4). Our solution considerably reducesthe efforts of both designers in dealing with multiple heterogeneous middlewareplatforms. We complement this paper with a comparison of our approach withrelated work (Section 5), and conclude by discussing future work (Section 6).

2 Abstract Coordination Middleware Architecture

We introduce an abstract model-based architecture that embeds our applicationand middleware CMs, their coordination primitives, and the refinement map-pings between them. The abstract architecture is depicted in Fig. 1, togetherwith the architecture implementation elements, which will be introduced in Sec-tion 3. The architecture is structured in three abstraction levels. We present inthe following each one of these levels, and briefly discuss the elicited primitivesand their mappings.Application Coordination Level. The application coordination level providesa high-level abstraction of a complex distributed application. Such an application

224 N. Georgantas et al.

local coordination primitives

tasksremote interface description

GDS

remote coordination primitives

GDS

remote coordination primitives

CS, PS, TS

remote middleware API

middleware platforms

remote interface description

CS, PS, TS

remote interface description

middleware platforms

application coordination level

middleware coordination level

middleware platform level

orchestration workflow BPEL

EA XSDs

BPEL EA

XSDs

code templates supporting generic

primitives of CS, PS, TS

XML-based languages (XSDs)

CSDL, PSDL, TSDL

XML-based language (XSD)

GDSDL

GDSEA2xEA transformation

GDSEA2x

L

s

xDL2GDSDL transformation

ML b

sforma

GDSDL

Extended BPEL engine support

refinement mapping

refinement mapping

Abstract architecture element Architecture implementation element

Fig. 1. Abstract Coordination Middleware Architecture and its Implementation

is designed as an orchestration workflow constituted by tasks. Tasks employlocal coordination primitives for control passing (e.g., implementing constructslike sequence, parallel execution, etc.), and for data passing (e.g., via globalvariables accessible to all tasks) among them. Some of the tasks employ remotecoordination primitives for control and data passing from/to external systemsthat are integrated by the workflow. Remote coordination is based on the GDSmodel. Thus, application workflows can be designed based on the GDS CMfor interacting with external constituent systems. We point out that given theGDS abstraction, the application workflow designer needs not deal with theheterogeneous CMs and middleware platforms of the constituent systems. Toproperly interact with such systems, the workflow designer needs to have theirinterface descriptions, which should also be expressed based on the GDS model.

Middleware Coordination Level. The middleware coordination level offersits proper remote coordination primitives for interaction with the constituentsystems, as well as the interface descriptions of such systems, to which the inter-action should conform. These coordination primitives and interface descriptionscomply with the CS, PS and TS CMs. Hence, the interaction with the constituentsystems is performed at this level based on the systems’ native CMs. The mid-dleware coordination level provides a refinement to the application coordinationlevel with respect to the primitives and interfaces. Thus, there is a refinementmapping between these elements and the respective GDS-based elements. Therest of the elements of the application coordination level (local coordinationprimitives, tasks not dedicated to remote interaction) remain intact when thisrefinement is applied.

A Coordination Middleware 225

Middleware Platform Level. The middleware platform level enables the finalrefinement mapping of remote coordination primitives and interface descriptionsto the ones provided by the concrete middleware platforms of the constituentsystems. This means that interaction with the constituent systems is performedat this level via the APIs of these middleware platforms. Hence, these platformsshould be incorporated by our coordination middleware implementation. In thesame way, interface descriptions of constituent systems comply to their middle-ware platforms APIs.

Coordination Primitives. As already discussed, we have elicited generic prim-itives and their arguments for the CS, PS and TS models after extensively sur-veying these models and related middleware platforms in the literature. We thenderived primitives for the GDS model from the TS primitives. Due to space re-strictions, we cannot present the complete primitives and their mappings; weonly briefly discuss the primitives and illustrate their mapping with an example.

CS primitives are inspired from BPEL and Web Services interaction primi-tives, covering one-way asynchronous and two-way synchronous interaction inboth directions between client and server. For PS, we cover queue-, topic- andcontent-based systems [12], integrating the diverse event types under a genericfilter parameter. For TS, we integrate support for asynchronous notification [3]and explicit scoping [5]. GDS primitives are special TS primitives.

Fig. 2 depicts two TS primitives, the derived GDS primitives, and how a CSprimive is mapped onto the ordered sequence of these GDS primitives. Morespecifically, the two-way interaction of the CS invoke primitive is mapped ontoa sequence of outGDS and takeGDS primitives. While most explanations aregiven in the figure, we point out the introduction of the explicit scoping pa-rameters mainscope and subscope in the GDS primitives. These two parametersenable restricting the scope of the entities that share GDS data. We map thedestination and operation parameters of invoke to mainscope and subscope;thus, the input and output data carried by invoke will be accessed only by thesingle CS destination peer.

3 Coordination Middleware Implementation

We present in this section our implementation of the abstract coordination mid-dleware architecture, building on BPEL. BPEL already implements some ofthe elements of the abstract architecture. It offers complete language support(tasks, local coordination primitives) for developing workflows and executingthem via its engine. However, it provides limited remote coordination primitivesand related remote interface description (based on WSDL), as well as limitedmiddleware platform level support, targeting only Web Services. Nevertheless,BPEL allows enhancing the base language with extension activities (EAs) andassociated user-defined refinement mappings at the middleware platform level.We exploit this powerful feature to implement the novel elements of the abstractarchitecture.

226 N. Georgantas et al.

Fig. 2. An example of coordination primitives and their mappings

We identify three roles related to our coordination middleware. The coordina-tion middleware designer (this is us) develops the core coordination middleware.A middleware platform designer can incorporate support for a new middlewareplatform into the core middleware. An application workflow designer can designa workflow that integrates a number of heterogeneous constituent systems.

In the following, we present the core middleware implementation and itsintegrated support for the middleware platform (hereafter, middleware) and ap-plication designers. We demonstrate the applicability of our approach by imple-menting the application scenario outlined in the Introduction. In particular, ourscenario implementation, depicted in Fig. 3, integrates: (1) sensors, actuatorsand personnel equipment communicating over a DART TS [5]; (2) the planningservice implemented as an Apache Axis2 Web Service3; (3) a JMS PS systembased on Apache ActiveMQ4 that the coordinator of the operation uses to re-ceive recommendations and to send commands; and (4) the application workflowdeveloped and running on the Apache ODE BPEL workflow engine5.

Core Middleware. The core coordination middleware provides generic supportfor application workflow development based on the GDS model, and for theCS, PS and TS models at middleware coordination level. The core middlewareimplementation elements are depicted in Fig. 1. We introduce new BPEL EAs(in the form of XML Schema or XSD) representing the required application- andmiddleware-level remote coordination primitives. At platform level, we introducesupport for the middleware-level EAs. In particular, we provide code templates(to be filled in by the middleware designers) for enabling later linking the CS, PSand TS generic primitives to middleware platforms that will be incorporated intothe core middleware. Regarding interface descriptions at middleware level, weintroduce three XSD-based description languages (DLs), inspired from WSDL:

3 http://axis.apache.org/axis2/java/core/4 http://activemq.apache.org/5 http://ode.apache.org/

A Coordination Middleware 227

Fig. 3. Search and Rescue Operations

CSDL, PSDL and TSDL, conforming to the respective CMs and their genericprimitives. For interface descriptions at application level, we introduce in thesame way one more language based on the GDS model: GDSDL which will beused by the workflow designers. Finally, to facilitate the task of the workflowdesigners, we propose two XSLT-based transformations [13], which implementthe refinement mappings between the application and the middleware levels:(1) xDL2GDSDL, transformation of middleware-level interfaces to application-level interfaces, and (2) GDSEA2xEA, transformation of application-level EAsto middleware-level EAs, where x=CS/PS/TS.

Integrating a New Middleware Platform. The core middleware providesgeneric support for the CS, PS and TS models as well as for the GDS model, interms of primitives, interfaces, code templates and XSLT-based transformations.Based on this, on-demand integration of a new middleware platform is basicallya set of design-time activities as follows: (1) Embedding platform-dependentcode into the code templates so as to employ the platform API. (2) Refiningmiddleware-level EAs and the interface xDL; this is about type refinement, sothat generic data types of the core middleware are customized to the specificmiddleware platform. (3) Refining application-level EAs and the GDSDL; thisis the same type refinement as in the previous step. In case the new middle-ware platform introduces features not covered by the core middleware, the coremiddleware can be extended to embed these features. We incorporated threeplatforms into the core middleware: Apache Axis2 (CS middleware), ActiveMQJMS (PS middleware) and DART (TS middleware).

Designing an Application Workflow. Based on the generic support of thecore coordination middleware and the on-demand integration of middleware plat-forms, the application workflow designer can design a new workflow, using hersole knowledge of the GDS CM. In particular, she can design a data-orientedworkflow of heterogeneous constituent systems independently of their CMs. The

228 N. Georgantas et al.

specific design-time activities are as follows: (1) Transforming native interfaces ofthe constituent systems to corresponding xDL description, and then to GDSDLdescription by employing the xDL2GDSDL transformation. (2) Designing theGDS-based workflow by writing tasks that employ appropriate GDS EAs. (3)Refining the GDS-based workflow into an executable workflow by using theGDSEA2xEA transformation. (4) Finally, deploying and executing the work-flow on a BPEL support platform, e.g., Apache ODE.

4 Middleware Evaluation

We have evaluated our middleware by applying design time metrics for measuringthe support offered to middleware and application designers, as introduced inthe previous section. Due to space limitations, we present herein our evaluationresults only for the former support. More specifically, we measure the effort ofthe coordination middleware designer for implementing the core middleware, andthe effort of middleware platform designers for integrating two new middlewareplatforms into the core middleware, namely the JMS and DART platforms ofour application scenario.

Coordination Middleware Designer. Table 1 summarizes her effort in pro-viding support for the PS and TS CMs at middleware coordination level, in termsof implemented numbers of: (1) BPEL EAs representing coordination primitivesand their arguments, (2) XSD elements of xDL interface description languages,(3) XSLT expressions of xDL2GDSDL transformations, and (4) Lines of code ofcode templates at middleware platform level.

Table 1. Effort of the coordination middleware designer

PS TS

BPEL EAsPrimitives Arguments

3 7

Primitives Arguments

5 9

xDLs (XSD elements)PSDL

11

TSDL

14

Transformations (XSLT expr)PSDL2GDSDL

42

TSDL2GDSDL

63

Code templates (LOC) 1002 1912

Middleware Platform Designer. Table 2 shows the efforts of the JMS (a PSmiddleware) and DART (a TS middleware) designers for integrating their plat-forms into the core middleware, in terms of implemented numbers of: (1) NewBPEL EAs representing new coordination primitives and/or new arguments, incase they are not covered by the already implemented generic core middlewareprimitives, (2) New XSD elements of xDLs, as for data type refinement, (3) NewXSLT expressions of xDL2GDSDL transformations, in case this is needed dueto xDL refinement, and (4) New lines of code incorporated into code templates

A Coordination Middleware 229

Table 2. Effort of the middleware platform designers

JMS DART

BPEL EAsNew primitives New arguments

0 (0%) 4 (36%)

New primitives New arguments

0 (0%) 2 (18%)

xDLs (New XSD elements)PSDL

6 (35%)

TSDL

2 (12.5%)

Transformations (New XSLT expr)PSDL2GDSDL

0 (0%)

TSDL2GDSDL

0 (0%)

Code templates (New LOC) 508 (34%) 311 (14%)

at middleware platform level. Besides absolute values, Table 2 also shows theratio of the designers’ actual effort over the total effort they would have had toput in case the core middleware had not been already available. The outcomeratio numbers point out the significant support offered to the middleware plat-form designers, resulting in considerable easiness for integrating new middlewareplatforms and related high extensibility of the coordination middleware.

5 Related Work

Distributed system interoperability approaches at the middleware level are clas-sically based on bridging communication protocols, wrapping systems behindstandard technology interfaces, and/or providing common API abstractions.However, most of these efforts focus on a single CM, which is already a hardproblem. Nevertheless, there are some solutions combining together diverse CMs.Common API abstractions enable developing applications that are agnostic tothe underlying CMs. Then, some local mapping is performed between the APIoperations and the diverse CMs/related interaction protocols supported. In thiscategory, ReMMoC [8] is an adaptive middleware for mobile systems, enablingclients that can interact with both RPC servers and PS systems via a commonprogramming interface. Such systems are described with extended WSDL de-scriptions. Same as ReMMoC, our solution also offers a common API abstraction,which however additionally covers TS systems. Following a similar approach, anAPI (and partial protocol stack) conforming to one CM can be locally mappedto an interaction protocol conforming to another CM. Thus in [9], the authorsimplement the LIME TS middleware on top of a PS substrate. Similarly, work in[10] enables Web services SOAP-based interactions over a TS binding. Contraryto these specific solutions, our approach aims to cover a much wider range ofCM interoperability. Wrapping systems behind standard technology interfacesenables accessing these systems by using CMs that are different from their nativeones. In [7], a gateway allows high-level access to the data and operations of awireless sensor network via Web service interfaces. Again, our solution is muchmore general. Additionally, the TS model with its looser coupling offers greaterflexibility in abstracting heterogeneous CMs than a service interface. Bridging is

230 N. Georgantas et al.

about interworking between heterogeneous interaction protocol stacks. The En-terprise Service Bus (ESB) paradigm is currently the dominant bridging solutionfor the integration of heterogeneous systems, with realizations that are estab-lished industrial (open- and closed-source) products such as Apache ServiceMixand IBM Websphere ESB6. ESBs typically rely on transforming heterogeneousinteraction protocols of systems plugged on the bus to a single messaging busprotocol that interconnects the endpoints representing these systems on the bus.Such transformations are carried out by adapters, which may also map betweendifferent CMs. For instance in [6], an external TS is connected through adaptersto a distributed ESB topology and is accessible via the bus messaging-basedinterface. However, such adapters are proprietary and ad hoc, and concern eachtime a specific middleware platform. Recent realizations of ESBs enable multipleCMs on the bus, such as messaging and PS, which, nevertheless, are supportedin parallel; hence, plugging systems with diverse coordination semantics on thebus still requires adapting to the (now richer) bus semantics. In contrast, oursolution proposes a generic and systematic way for adapting between heteroge-neous CMs. Acknowledging the flexibility of the TS model, a number of systemintegration efforts have adopted TS as the common coordination facility. Someof these approaches enrich TS with PS semantics, or offer a REST (REpresenta-tional State Transfer)-based API in addition to the TS-based API [14]. Similarefforts introduce extended TS as an alternative solution to the realization of theESB paradigm [15]. Some of these ESBs offer various coordination semantics (byemulating different CMs) and related APIs, such as CS- and PS- in addition toTS-based. The difference of our solution lies in using the GDS TS model as adesign-time artefact, while runtime interactions are performed by employing thenative CMs of the constituent systems.

6 Conclusion

Integrating heterogeneous systems in an orchestration workflow while preservingtheir native CMs is challenging. We have identified three levels of coordination(i.e., application, middleware and platform levels), for which we have incorpo-rated generic support into a core coordination middleware. Appropriate genericprogramming abstractions in terms of data-driven primitives and interfaces areprovided to application designers. Using these primitives, they can easily developapplication workflows, focusing on only the application logic as opposed to puz-zling with underlying middleware platforms of constituent systems. Middlewaredesigners can also easily incorporate new middleware platforms on demand intothe core coordination middleware. Our BPEL-based implementation of the coremiddleware and associated evaluation results show that our solution considerablyfacilitates the tasks of both designers. Certainly, there are outstanding issues re-garding our solution that we are considering in our current and future work.We identified the TS model as the most appropriate one for abstracting anyother CM, and we introduced GDS TS as application-level CM to be employed6 http://servicemix.apache.org, http://www-01.ibm.com/software/integration/wsesb/

A Coordination Middleware 231

in workflows. We intend to carry out a precise evaluation of the preservation(or loss) of semantics introduced by this abstraction and the related mappingsbetween GDS and CS, PS and TS. In the same direction, we wish to evalu-ate the applicability of our solution in real-life use cases, which raises the issueof abstracting complex middleware platforms having rich features. We want tosee how much of these features is preserved by our proposed CS, PS, TS, andfurther GDS abstractions, and what the related trade-off is between generic pro-gramming interfaces offering simplicity and the resulting loss of platform-specificfeatures. On the other hand, although our model-based solution involves mostlydesign-time mappings and should thus introduce only small runtime overhead,we intend to accurately evaluate the performance of our coordination middle-ware. Finally, in the medium term, we aim to develop user-friendly tools for theapplication and middleware designers and investigate data-driven choreographyof heterogeneous systems.

References

1. Monson-Haefel, R., Chappell, D.: Java Message Service. O’Reilly & Associates,Inc., Sebastopol (2000)

2. Carzaniga, A., Wolf, A.: Content-based Networking: A New CommunicationInfrastructure. LNCS, pp. 59–68 (2002)

3. Freeman, E., Arnold, K., Hupfer, S.: JavaSpaces Principles, Patterns, and Practice.Addison-Wesley Longman Ltd, Essex (1999)

4. Murphy, A.L., Picco, G.P., Roman, G.C.: LIME: A Coordination Model and Mid-dleware Supporting Mobility of Hosts and Agents. ACM Transactions on SoftwareEngineering and Methodology (TOSEM) 15(3), 328 (2006)

5. Bakshi, A., Pathak, A., Prasanna, V.: System-level Support for Macroprogram-ming of Networked Sensing Applications. In: Int. Conf. on Pervasive Systems andComputing (PSC). Citeseer (2005)

6. Baude, F., Filali, I., Huet, F., Legrand, V., Mathias, E., Merle, P., Ruz, C.,Krummenacher, R., Simperl, E., Hammerling, C., Lorre, J.P.: ESB Federationfor Large-scale SOA. In: Proceedings of the 2010 ACM Symposium on AppliedComputing, SAC 2010, pp. 2459–2466. ACM, New York (2010)

7. Aviles-Lopez, E., Garcıa-Macıas, J.: TinySOA: a Service-oriented Architecture forWireless Sensor Networks. Service Oriented Computing and Applications 3(2), 99–108 (2009)

8. Grace, P., Blair, G.S., Samuel, S.: A reflective framework for discovery and interac-tion in heterogeneous mobile environments. SIGMOBILE Mob. Comput. Commun.Rev. 9(1), 2–14 (2005)

9. Ceriotti, M., Murphy, A.L., Picco, G.P.: Data sharing vs. message passing: Synergyor incompatibility?: An implementation-driven case study. In: SAC 2008: Proceed-ings of the 2008 ACM Symposium on Applied Computing, pp. 100–107. ACM,New York (2008)

10. Wutke, D., Martin, D., Leymann, F.: Facilitating complex web service interactionsthrough a tuplespace binding. In: Meier, R., Terzis, S. (eds.) DAIS 2008. LNCS,vol. 5053, pp. 275–280. Springer, Heidelberg (2008)

232 N. Georgantas et al.

11. Pietzuch, P., Eyers, D., Kounev, S., Shand, B.: Towards a common api forpublish/subscribe. In: DEBS 2007: Proceedings of the 2007 Inaugural Interna-tional Conference on Distributed Event-Based Systems, pp. 152–157. ACM, NewYork (2007)

12. Eugster, P.T., Felber, P.A., Guerraoui, R., Kermarrec, A.-M.: The many faces ofpublish/subscribe. ACM Comput. Surv. 35(2), 114–131 (2003)

13. Kay, M.: XSLT 2.0 Programmer’s Reference. Wiley Pub., Chichester (2004)14. Nixon, L.j.b., Simperl, E., Krummenacher, R., Martin-Recuerda, F.: Tuplespace-

based computing for the semantic web: A survey of the state-of-the-art. Knowl.Eng. Rev. 23(2), 181–212 (2008)

15. Mordinyi, R., Kuhn, E., Schatten, A.: Space-based architectures as abstractionlayer for distributed business applications. In: Proceedings of the 2010 InternationalConference on Complex, Intelligent and Software Intensive Systems, CISIS 2010,pp. 47–53. IEEE Computer Society, Washington, DC, USA (2010)