International Journal of Web Services Research

October-December 2008, Vol. 5, No. 4

Table of Contents

Editorial Preface i Web Services Security and Workflow Control Liang-Jie Zhang, IBM T.J. Watson Research Center, USA

Research Articles

1 A Model-Driven Development Framework for Non-Functional Aspects in Service Oriented Architecture Hiroshi Wada, University of Massachusetts - Boston, USA Junichi Suzuki, University of Massachusetts - Boston, USA Katsuya Oba, OGIS International, Inc., USA

32 Workflow Discovery: Requirements from E-Science and a Graph-Based Solution Antoon Goderis, University of Manchester, UK Peter Li, University of Manchester, UK Carole Goble, University of Manchester, UK

59 Communication Web Services and JAIN-SLEE Integration Challenges Paolo Falcarin, Politecnico di Torino, Italy Claudio Venezia, Telecom Italia, Italy

79 Interoperability Among Heterogeneous Services: The Case of Integration of P2P Services with Web Services Aphrodite Tsalgatidou, National and Kapodistrian University of Athens, Greece George Athanasopoulos, National and Kapodistrian University of Athens, Greece Michael Pantazoglou, National and Kapodistrian University of Athens, Greece International Journal of Web Services Research, 5(4), 79-110, October-December 2008 79

Interoperability Among Heterogeneous Services: The Case of Integration of P2P Services with Web Services

Aphrodite Tsalgatidou, National and Kapodistrian University of Athens, Greece

George Athanasopoulos, National and Kapodistrian University of Athens, Greece

Michael Pantazoglou, National and Kapodistrian University of Athens, Greece

ABSTRACT

Service-oriented computing (SOC) has been marked as the technology trend that caters for interoperability among the components of a distributed system. However, the emergence of various incompatible instantiations of the SOC paradigm, e.g. Web or peer-to-peer services (P2P), and the divergences encountered within each of these instantiations state clearly that interoperability is still an open issue, mainly due to its multi- dimensional nature. In this paper we address the interoperability problem by first presenting its multiple dimensions and then by describing a conceptual model called generic service model (GeSMO), which can be used as a basis for the development of languages, tools and mechanisms that support interoperability. We then illustrate how GeSMO has been utilized for the provision of a P2P service description language and a P2P invocation mechanism which leverages interoperability between heterogeneous P2P services and between P2P services and Web services.

Keywords: generic service model; grid services; heterogeneous services; peer-to-peer (P2P) services; P2P service description; P2P service invocation; service-oriented computing; Web services

INTRODUCTION problem in various ways. However, they have The software community has been confronted not yet managed to provide a widespread solu- with the issue of interoperability between tion that enables the interoperation of diverse software components during the last couple components developed by different providers, of decades. Various approaches such as object in multi-vendor platforms (Medvidovic, 1999). and component based approaches tackle this Service oriented computing (SOC) emerged as

Copyright © 2008, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 80 International Journal of Web Services Research, 5(4), 79-110, October-December 2008 an evolutionary step of object and component their basic activities. It is worth noting here based approaches, with the promise to sup- that, the interoperability problem exists, not port the loose coupling of system parts thus only between services of different types, but providing agility, flexibility and cost savings also between services of the same type. See for via reusability and interoperability. However, example the area of P2P services, where there the existence of many heterogeneous types of are no common standards or reference models; services and the vast amount of existing and existing P2P platforms, e.g. JXTA (Gong, 2001), emerging standards still constitutes a major Gnutella (Ivkovic, 2001) or Edutella (Nejdl, obstacle towards interoperability, as it will 2001)��, ��use proprietary advertising, discovery become apparent in the following. and invocation mechanisms, thus hindering The most well-known instantiations of the interoperability between these P2P services. service-oriented computing paradigm are Web Another example is the area of Web services, services (Christensen, 2001) and Grid services where, despite the use of standard protocols, (Czajkowski, 2004). However, other types of there are still interoperability problems between services such as Peer-to-Peer (P2P) services, see Web services. Efforts such as those undertaken for example the JXTA services (Gong, 2001), by WS-I (Ballinger, 2004) try to tackle the latter are currently gaining momentum. All these problem; specifically, WS-I has provided a basic types of services are usually built on top of interoperability profile for addressing some of XML standards (Bray, 2004) and other proven the interoperability problems encountered be- communication protocols such as HTTP (Field- tween Web services; such an effort foregrounds ing, 1999) and TCP/IP (Tanenbaum, 2003). The the need for addressing the problem in various establishment of a set of common characteristics dimensions. However, there are still a lot of for these service types including properties open issues which remain to be solved. such as self-description, internet accessibility This article provides a solution on In- and message-oriented communication has been teroperability between P2P and Web services. one of the main research topics in this area and The provided solution is based on a generic existing results comprise models such as the framework which provides for interoperabil- ones that have been specified by W3C in (Booth, ity between any type of service. This generic 2004), by Werner Vogels in (2003), and by Karl framework has been developed in the SODIUM Czajkowski, et al. in (2004). These features project1, which employs a unified approach along with the use of XML standards (Bray, towards the interoperability of heterogeneous 2004) provide an infrastructure that promises to service types. One of the advantages of this leverage interoperability among the components unified interoperability approach is that it al- of a service-oriented system. lows the various service types to retain their Nonetheless, although existing SOC instan- own traits and characteristics. In this article tiations, provide for a basic infrastructure that we present:�� (i) the foundation of the SODIUM tackles interoperability, they still do not fully work which comprises a generic service model address it. This is mainly due to the multidi- (GeSMO) that constitutes the underlying basis mensional nature of interoperability, as it has for the development of appropriate software for also been noted in (Fang, 2004; Burstein 2005). supporting service interoperability and, (ii) a Furthermore, the multiplicity of continuously specific solution that has been provided for the emerging service types, see for example Sen- integration of P2P services with Web services sor services (Gibbons, 2003) or UPnP services which has been utilized in the SODIUM and (Newmarch, 2005), is further aggravating the SeCSE2 projects.� problem, as, albeit these service types share The provided interoperability solution some common characteristics, they adhere to between Web and P2P services is described in incompatible models and standards and rely on detail in the rest of the article which we have distinct platforms and middleware to perform structured as follows: We first present a moti-

Copyright © 2008, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. International Journal of Web Services Research, 5(4), 79-110, October-December 2008 81

vating scenario which demonstrates the need the Scandinavian�� markets�� for transportation, for interoperability of heterogeneous services. emergency, security and the military. Actually, Then, we examine interoperability among this motivating scenario was used in one of heterogeneous types of services from different the SODIUM pilot applications which dem- dimensions, with an emphasis on Web and P2P onstrated the feasibility and usefulness of the services (see section “INTEROPERABILITY provided solutions. DIMENSIONS”); the issues that need to be In the crisis management area a common addressed in order to facilitate the integration task of paramount importance is determining of heterogeneous services are identified in the how to get to a crisis location as fast as pos- subsection “Interoperability Concerns for Het- sible, as time is a critical factor. For example, in erogeneous Services”. In the sequel, we present case of an accident where people are critically a generic service model (GeSMO) that takes into injured, it is imperative to reach these persons account the identified interoperability issues. In with the appropriate equipment within minutes, particular the provided constructs catering for as if the injury causes lack of oxygen to the the description of P2P services are presented brain for 3-5 minutes, brain cells will start to in the subsection “GeSMO Extensions for die and after approximately 15 minutes there Peer-to-Peer Services”. Then, in section “A will be permanent damages. Therefore, it is vital Peer-to-peer Service Description Language” that properly equipped ambulances and other we describe how GeSMO and its extensions rescue units are within a 15-minutes range at all for P2P services have been utilized for the times and places. In most cases this requirement provision of the Peer-to-peer service descrip- is difficult to be satisfied due to the vast set of tion language (PSDL), which is an extension parameters such as accident/injury probability, of WSDL (Christensen, 2001) and supports the population density and composition, accessi- description, discovery and invocation of P2P bility, time of day/week/month/year, weather services. An example of a PSDL description conditions, hospital locations and many others, document for the instant messaging service that which need to be considered. is used in the motivating scenario is presented It is thus vital that a crisis management in the subsection “A PSDL Example”. Then, system interoperates with various types of het- section “JXTA Service Invocation Mechanism” erogeneous systems in order to incorporate the illustrates the mechanism that has been built to required information. LOCUS decided to use support the invocation of JXTA P2P services. a service-oriented approach for the integration This mechanism utilizes JXTA service descrip- of all these types of systems, since there are a tions in PSDL so as to facilitate their seamless lot of available heterogeneous services which invocation. Next, in section “Application Case offer information useful to this crisis manage- Study”, we exemplify how P2P services provid- ment application. Such services are: ing location information have been integrated with Web services providing map information, • Web services: providing weather informa- for the implementation of a part of the motivating tion such as temperature and precipitation, scenario. Finally, we compare our work with traffic conditions from roadside speed some other related approaches and we conclude sensors and video surveillance cameras, this article with a discussion on open issues and • P2P services: providing information about on our future work plans. the locations and status of emergency vehicles or messaging facilities to the MOTIVATING SCENARIO emergency vehicles with reposition mes- Our motivating scenario is in the area of Crisis sage commands. Management. This scenario was provided by • Other types of services such as grid LOCUS (www.locus.no), a leading supplier services providing driving route calcula- of mobile and other types of applications in tions, historical incident information and

Copyright © 2008, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 82 International Journal of Web Services Research, 5(4), 79-110, October-December 2008

“response range” calculations based on LOCUS company would like to utilize existing current positions and conditions. services (mentioned before) which have either been developed in-house or are provided by Figure 1 presents an example of a workflow trusted partners. For example, a Web service based on this scenario, the tasks of which can can be used to determine which ambulance be satisfied by various types of services3. As it is closest to the place of the accident, while can be seen in this figure, first we need to get a P2P instant messaging service can be used information about the person who is calling to satisfy the last task of the workflow which and identify the accident location; see tasks requires to send a map to the ambulance with GetCallerInfo and GetCallerPosition.�� Then,�� the appropriate route information. we need to identify the closest to the accident Therefore, the integration of heterogeneous location, properly equipped ambulance; see services is of paramount importance, in order to task GetBestSuitedAmbulance. Subsequently, satisfy the needs of service-oriented applications we need to calculate the shortest route to the such as the above. accident location and to draw the route from the ambulance’s current location to the ac- INTEROPERABILITY cident location on a map (see related tasks DIMENSIONS DetermineShortestRoute and GetMap) which In this section we briefly recap the results of needs to be sent to the ambulance (see task current research on service interoperability and InformAmbulance). then we present our approach. Thus, according The services satisfying these tasks, do not to the majority of the proposed interoperability need to be developed from scratch; instead the

Figure 1. Composition example for crisis management scenario

Figure 2. Service interoperability dimensions

service interoperability

Signature Protocol Semantic

Programming language interoperability (iDls)

Platform interoperability (rPC)

Figure 3. Extended set of interoperability dimensions

service interoperability

Signature Protocol Semantic Quality Context

models (Fang, 2004; Vallecillo, 2000; Murer, high importance to context-aware applications, 1996), service interoperability has been divided where Ruiz et al proposed the addition of the into the signature, protocol and semantic levels. quality dimension; see Figure 3. A classification scheme for interoperability that Each of these dimensions describes specific considers the evolution of distributed computing interoperability concerns to be tackled when from the emergence of RPC or component mod- integrating two service-oriented systems. These els, such as DCOM (Microsoft, 1996) and EJBs concerns are briefly presented below: (DeMichiel, 2006), to CORBA (Siegel, 1996), has been proposed in (Vallecillo, 2000) and it • The signature dimension addresses the is presented in Figure 2. As we can see in this interface definition conformance. This figure, the problem of interoperability is divided includes the operations, types and order of into three levels: service level, programming parameters of a service interface as well as language level and platform level. The service standards such as the interface definition level in particular is further decomposed in languages (IDL). three interoperability dimensions i.e. signature, • The protocol dimension addresses the protocol and semantic dimensions. order in which the methods of a service Extensions to these three dimensions of are invoked. The Web Service Choreog- the service interoperability level have been raphy Description Language (WS-CDL) been provided in (Strang and Linnhoff-Popien, (Kavantzas, 2005) can be seen as an effort 2003) and in (Ruiz et al, 2000). In particular, to resolve this interoperability problem. Strang and Linnhoff-Popien added a context • The semantic dimension addresses the dimension to service interoperability which is of problem of common understanding

Copyright © 2008, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 84 International Journal of Web Services Research, 5(4), 79-110, October-December 2008

Figure 4. Additional service interoperability defined at the service interoperability level, dimensions orthogonal to the aforementioned dimensions, in order to address interoperability from a global perspective (see Figure 4), providing Service interoperability in this way a more complete view of service interoperability. Business Domain The introduced orthogonal dimensions of service interoperability are: the business application domain, the application and the platform dimensions. These dimensions have been layered in a top-down manner, starting from the most Platform abstract system concepts related to business domain down to implementation specific concepts such as platform specific ones. Specifically, the introduced dimensions are as follows:

between service providers and service • Business Domain: Interoperability at this consumers. This problem can be tackled dimension represents the ability of two through ontologies and semantic service business systems to interoperate. This in- description frameworks such as OWL-S cludes sharing of common domain concepts (Martin, 2004), WSMO (Bruijn, 2005), and processes which could be described SAWSDL (Farrell, 2006) or WSDL-S using various standards and protocols (Akkiraju, 2005). such as RDF (Beckett, 2004), OWL (Mc- • The quality dimension addresses the con- Guinness, 2004), OWL-S (Martin, 2004), formance of the quality requirements of a WS-CDL (Kavantzas, 2005), and ebXML service consumer and the quality properties BPSS (Dubray, 2006)�. offered by the service provider. Solutions • Application: Applications are specific to this issue can be provided by description implementations of parts of business do- frameworks such as WS-QoS (Gramm, mains. Thus, application interoperability 2004), or WS-Policy (Bajaj, 2006). represents the ability of two specific busi- • The context dimension refers to the confor- ness system implementations to interoper- mance between the context representations ate. This includes the use of compatible data used by service providers and the context structures, functionality and orchestrations representations requested by service that may be described using standards clients. Context-level interoperability is such as WSDL (Christensen, 2001) and important when employing services in WS-BPEL (Alves, 2006). ubiquitous computing environments. This • Platform: Platform interoperability problem could be tackled through the represents the ability of the middleware use of common ontologies and ontology underlying two or more applications to frameworks e.g. RDF (Beckett, 2004), interoperate. This includes features such OWL (McGuinness, 2004) or via the use as the use of compatible data type repre- of context description frameworks such as sentations (e.g. real numbers having the ConteXtML (Ryan, 2005) same accuracy and same format), interface specification mechanisms (e.g. interface The aforementioned service interoper- definition languages) or architectural styles ability dimensions (Figure 3) are the most (e.g. use of message-oriented communica- commonly used. We argue that an additional tion styles). As it can be seen, this dimension set of interoperability dimensions needs to be differs from the platform interoperability

Figure 5. An integrated view of service interoperability dimensions

service interoperability

Business Domain semantic

Protocol Context Application

Quality

Platform signature

layer appearing at the bottom part of Figure interoperability problem when integrating 2 in that it addresses both programming two systems that implement two incompatible language and platform interoperability processes (i.e. processes with incompatible cho- dimensions. reographies). Such an incompatibility is at the protocol level. This problem may exist either due We believe that the utilization of a multi- to the fact that the two systems support different viewpoint approach facilitates the clearer as- and thus incompatible business processes (in sessment of system interoperability. Thus, the which case we have an interoperability problem dimensions depicted in Figure 3 take an internal at the Business Domain level), or because their look on the aspects that need to be considered developers have selected different algorithms when dealing with the integration of two sys- for their implementation (in which case we have tems, whereas the dimensions in Figure 4, which an interoperability problem at the Application are orthogonal to the former ones, represent a level). Similar arguments may be provided for system architect’s ‘coarse’ point of view on the rest of interoperability dimensions. the levels affected by the integration. Thus, There are also other frameworks such as we can integrate these two sets of dimensions the one presented in (Nezhad, 2006) focusing into a single framework. Figure 5 illustrates on Web service related interoperability. This this integrated view of service interoperability framework leverages a different point of view dimensions along with the associations between for classifying Web service interoperability the concepts of the two individual frameworks. problems and hence, incorporates a different Such an integrated view facilitates the clas- set of dimensions compared to the ones pre- sification of the interoperability concerns for sented in Figure 5. Although this classification service interoperability from two distinct points framework has been constructed to support of view. the categorization of Web service related in- As it can be seen in Figure 5, the semantic teroperability issues, it can also be used for the and signature interoperability dimensions are classification of interoperability issues of other clearly mapped to the orthogonal dimensions types of services as well. Thus, its dimensions of Business Domain and Platform respectively; can easily extend the ones of our integrated the protocol and context dimensions are shared framework without introducing any inconsis- between the dimensions of Business Domain tencies, since they have been conceived from and Application and Platform, while the quality a different point of view. However, we believe dimension is shared among the Application and that there is no need to extend the dimensions Platform dimensions. In order to better explain of our framework in Figure 5, since these are these mappings, let us consider the potential generic enough to cater for the identification

Copyright © 2008, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 86 International Journal of Web Services Research, 5(4), 79-110, October-December 2008 of all interoperability concerns that are also have access to the network through another addressed in (Nezhad, 2006). peer (proxy peer). In the following, we present how the • Syntactic Features: The different models integrated service interoperability framework supported by the investigated types of ser- depicted in Figure 5 can be used for the classifi- vices result in a set of syntactic diversities cation of interoperability problems which arise as well. Briefly, while Web services adhere when integrating heterogeneous services. to the WSDL defined service model (i.e. a service comprises a set of distinct opera- Interoperability Concerns for tions) and utilize the SOAP message format, Heterogeneous Services P2P services adhere to a suppressed service As it has been mentioned in the introduction, model where each service comprises a contemporary instantiations of the SOC para- single operation, and employ proprietary digm, such as Web and P2P services, are ruled by message formats (see for example JXTA different models, protocols and standards. The Org, 2006). Furthermore, for the descrip- range of discrepancies and diversities among tion of P2P services it is necessary to use services spans across all of their aspects, such as concepts denoting the P2P network topol- description and discovery mechanisms, quality ogy (e.g. peer, peer group, etc). characteristics or service provision platforms. • QoS Properties: The origins of Web Based on the results of a thorough investigation services are in business-oriented systems, on existing types of services that was undertaken whereas P2P services, such as instant mes- for the purposes of the SODIUM project, we saging or file sharing systems, have been came up with a set of incompatibilities. The derived from community-oriented systems. service types that we have investigated are that Albeit there are certain implementations of Web, Grid and P2P services.�� In this article that do not adhere to the following claim, we focus on the incompatibilities between Web we may argue that the origins of each of and P2P services which are the following: these service types have dictated specific quality properties for each of them re- • Supported Models: Web services and spectively. Thus, P2P services in general P2P services adhere to different models do not have to be reliable, secure and of of operation; specifically Web services high performance, whereas Web services follow the stateless service model, al- should be. though recently the concept of stateful Web services has arisen (Czajkowski, 2004) All these incompatibilities and differences whereas P2P services are leaning towards among the investigated types of services lead to the stateful service model, though some a number of interoperability concerns that can stateless implementations also exist (Nejdl, be classified according to the previously iden- 2001). tified interoperability dimensions (illustrated • Targeted Clients: Although there might be in Figure 5). These concerns are summarized specific security constraints dictating a dif- below: ferent case, Web services in general may be invoked by any client with internet access, • The incompatibility of the supported provided that the client has the necessary models has an impact on all interop- infrastructure (e.g. a SOAP engine) to erability dimensions but quality and exchange messages (e.g. SOAP messages) context. with the service provider. When it comes to P2P services, the respective client must The stateful service model that is accommo- be either a member of the P2P network or dated by P2P services and stateful Web services, necessitates the use of additional features and

processes e.g. resource lifetime properties and The use of incompatible structures and lifetime management mechanisms or processes elements for the description of service syntactic supporting the discovery of resources. These characteristics has an effect on the languages additions have several ramifications on the used for their descriptions as well as on the platforms that are leveraged for the provision middleware used for the provision and usage of and invocation of stateful services, on the steps such services. Therefore, in order to facilitate that need to be followed for the integration of the integration of services with incompatible such services, as well as on the semantics used syntactic features, specific middleware needs for their description. to be provided, accommodating mappings of the features of one service type to the features • The difference on the targeted clients has of another service type. an impact on the signature and protocol dimensions as well as on the platform • The incompatibility of QoS properties and application dimensions. has an effect on the quality dimensions as well as on the platform and applica- As it has been mentioned before, the invo- tion dimensions. cation of P2P services can only be performed by peers of the P2P network using the API, Considering for example the issues of mechanisms and protocols supported by the security, billing or availability, appropriate network. It henceforth, becomes apparent that middleware and processes need to be used interoperability among services which have so as to cater for the provision, monitoring or different targeted clients e.g. Web and P2P management of such quality properties. Thus, services, should take into account the APIs, the integration of services which are either mechanisms and protocols supported by each demanding or providing incompatible quality service type. characteristics has to be supported by appropriate middleware as well as by the use of specific • The incompatibility of the syntactic process steps within an application. features has an effect on the signature and platform dimensions. Based on the results of our analysis that is illustrated in Table 1, the signature and

Table 1. Effect of service differences on interoperability dimensions

Differences Between Web, Grid and P2P Services Supported Syntactic QoS Proper- Targeted Clients Models Features ties Business Domain X Application X X X Platform X X X X Semantic X Protocol X X Context

Interoperability Dimensions Quality X Signature X X X

Copyright © 2008, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 88 International Journal of Web Services Research, 5(4), 79-110, October-December 2008 protocol interoperability dimensions as well regards Grid services, GeSMO was influenced as the platform and application interoperability by the WSRF specification (Czajkowski, et al. dimensions are the ones that seem to be highly 2004). However, the following characteristics affected by the integration of heterogeneous render GeSMO an ideal basis for supporting services. Thus, a solution for the integration other types of services. Specifically, the model of heterogeneous services should pay special exhibits the following properties: attention on these dimensions. We would like also to mention that, as it • Generality: The model is generic enough, can be noticed, none of the identified discrep- as it provides a core part which contains ancies among P2P and Web services resulted concepts common to all investigated ser- in interoperability concerns for the context vice types. On the other hand, it provides dimension. This is due to the fact that our specific characteristics for each supported investigation was focused on the interoper- service type that are accommodated in the ability problems that emerge when integrating various modules of its extension layer. heterogeneous services in general, regardless Modeling of service types beyond the of their context. Web, grid and P2P services that are cur- In the following section we present our rently supported, such as sensor services or approach in addressing the aforementioned UPnP services can be easily accommodated interoperability dimensions which emerged by adding extra modules in the GeSMO by the differences between the investigated extension layer containing the specific service types. characteristics of the new service types. • Abstraction: The core part of the model GENERIC SERVICE MODEL incorporates abstractions of all common Based on the findings of the previous section we concepts of the addressed types of services, developed a generic service model (GeSMO) e.g. the model contains concepts such as which addresses service interoperability. GeS- “service” and “message” which are part MO provides the basis for the development of of all types of services; these abstract appropriate middleware, languages and tools, concepts can then be instantiated to the which facilitate the interoperation of heteroge- concepts supported by each specific type neous services. Its current version focuses on of service. the syntactic aspects of a service; thus, it mainly • Extensibility: The model can be easily addresses the signature and platform service extended with new features and properties, interoperability dimensions. This was deemed as well as with new service types. There necessary for the quick provision of input that are two ways of extending the model: a) by would consequently be used in the development specialization of existing concepts; b) by of the rest of the SODIUM project results i.e. appending new concepts in case there are tools and languages. However, as it will become no appropriate existing ones to be used as apparent in the following, GeSMO is open and a basis for specialization. For example, the extensible, so it can easily support any other introduction of elements for the modeling required interoperability dimensions. of grid services has been achieved through As we have mentioned before, GeSMO the utilization of these mechanisms; in was based on a thorough investigation of the particular, elements for modeling the notion current state of the art on contemporary types of “resource” were appended to the model of services. Specifically with respect to P2P whereas the notion of “grid service” was services, GeSMO has been primarily influenced introduced as a specialization of the “Web by the work in JXTA (JXTA Org, 2006) as the Service” concept. latter is one of the very few P2P networks that • Modularity: GeSMO has been structured inherently support the notion of a service. As in a modular manner; thus, information

elements derived from specific viewpoints it facilitated the communication among the have been encapsulated within specific project stakeholders. packages; for example, concepts related to the description of a service are contained The architecture selected for the develop- within a description viewpoint package as ment of the generic service model (GeSMO) is it has been shown above. Such a modular a layered one, consisting of the following layers structure allows for the easy modification which are depicted in Figure 6: and/or extension of the various parts. • Expressiveness: The model is expressive • The core service concepts layer which enough to accommodate several service models concepts that are common to all primal activities such as description, investigated types of services, i.e. Web, discovery, invocation, and composition. Grid and P2P services; In addition, appropriate extension points • The extended service concept layer, on were defined so as to accommodate ad- top of the core layer, which provides for ditional features such as Semantics and the distinct features of each service type; QoS descriptions, etc. This expressiveness • A number of layers orthogonal to the core facilitated the development of tools & layer and its extensions, which provide mechanisms which, based on the model, appropriate extension points for modeling were able to support the unified discov- features related to semantics, quality, trust, ery, composition and execution of Web, security and management; these features Grid and P2P services (Tsalgatidou, et al. can be applied to all concepts of the core 2006) layer and of its extensions; this approach • Simplicity: The model is simple enough renders GeSMO flexible enough with re- to be easily used by a variety of users and spect to the adoption of constructs for the tools. For example, within the context of the representation of all these cross-cutting SODIUM project the model was exploited aspects in which currently there are no in two ways: (a) it served as the basis for prevailing protocols or models. the development of service modeling, service discovery, service composition and The concepts of the core part of GeSMO service execution languages and tools; (b) are presented next, followed by the extensions that we have developed for P2P services.

Figure 6. GeSMO’s layered architecture

ics ant extended Service Sem ce Concepts rvi Se of ty ali Qu y Core rit cu Se Service d an st ru Concepts t t en em ag an M

Copyright © 2008, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 90 International Journal of Web Services Research, 5(4), 79-110, October-December 2008

Figure 7. Generic service model viewpoints

Basic Viewpoint

Description Structure Viewpoint Viewpoint

<> <> <>

Communication Viewpoint Message Structure Service Viewpoint <> <>

Abstract Semantic & QoS Viewpoint Viewpoint

Figure 8. A service from an abstract point of view

Semantics

interprets interprets 0..* 0..* interprets 0..* Functional Non-Functional Behavior Characteristic Characteristic * * has has has QoS Software System

Service

Figure 9. Basic service model

Software System

1..* offered by Net Address resides at Service Provider

1..* describes 1 exchanges specifies 1..* 0..* Description Message defines

Figure 10. Description point of view of a service

Behavior Service

describes 1 describes

describes describes Semantics Description Syntactic Element 0..* 1..*

specifies 0..* describes QoS 1..* 0..* Communication Free Text Description Mechanism

Figure 11. Structural point of view of a service

1..* Service Syntactic Service Interface Element

defines 1..* Operation

1..* exchanges 1..*

Message

1..* Message abides by Data Element Type

Figure 12. Semantic and QoS point of view for a service

Service

1..*

0..* Service Interface 0..* QoS Semantics 0..* defines 1..* 0..* 0..* Operation

1..* exchanges 1..* Message

Copyright © 2008, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 92 International Journal of Web Services Research, 5(4), 79-110, October-December 2008

The Core part of GeSMO semantic and quality-of-service (QoS) point of The notion of service is the fundamental ele- view depicted in Figure 12. As it can be seen, ment in the core part of GeSMO model and it is a service, its operations and the exchanged modeled through various points of view. Figure messages may have semantic interpretation. In 7�� depicts the service concept along with the addition, a service and its operations may also viewpoints that were used for its refinement. be associated with specific QoS properties. As we can see in Figure 7, the viewpoints As we mentioned in the beginning of this that were used for refining the concept of ser- section, the aforementioned concepts along with vice are: the abstract point of view, the basic the additional ones which have been defined in point of view, the description point of view, (Tsalgatidou, 2005) establish the core part of the the structural point of view and the semantic GeSMO model. In the following paragraphs, we and QoS point of view. These views are further present how these concepts were extended in detailed in the following figures. order to support the rendering of P2P services in Figure 8 depicts a service from an abstract general as well as the description of JXTA P2P view as a software system which has a set of services offered by the JXTA platform. These functional and non-functional characteristics concepts served as the basis for the specification and exhibits a specific behavior. Its behavioral, of a language used for the description of P2P and functional and non-functional properties may JXTA services, as well as for the development have a semantic interpretation, whilst some of of a P2P service invocation mechanism. Both its non-functional properties can be considered the language and mechanism are described later as QoS properties. on in this article. Figure 9 depicts the basic service model where a service is a self-described software GeSMO Extensions for system that resides at a network address, is Peer-to-Peer Services offered by a service�� provider�� and exchanges The GeSMO peer-to-peer service model extends messages which are defined in its description. the GeSMO core concepts with additional ele- The description of a service conveys a lot ments needed for the description of P2P services. of important information, therefore we have As it can be seen in Figure 13, the additional developed a distinct description point of view concepts catering for the description of P2P which is presented in Figure 10. As we see in services are: this figure, a service description may convey information about the behavioral, semantic • P2P service which represents a service and quality features of a service. In addition, it provided by a peer or a group of peers in provides information about the communication a P2P network mechanisms that may be used for accessing • Peer which represents a node in a P2P net- the service. work, capable of communicating with other As regards the syntactic elements of a peers and provide them with services service, more information is provided by the • Peer group that represents the logical structural point of view, which is depicted in grouping of peers within a P2P network Figure 11. According to this view, a service • PSDL (P2P Service Definition Language) provides one or more interfaces consisting of description which is a document defined operations that group a set of messages. Each according to the PSDL language that is message comprises a set of elements which described in the following section. This adhere to specific data types. Messages are used document conveys information on what for the communication between a service and a P2P service does and how it can be in- its respective clients. voked. An additional point of view provided by the core part of GeSMO for a service is the

Figure 13. P2P service model

Description describes Provider

0..1 describes contains 1..* PSDL Peer Peer Group Document 0..1 1..* describes offers 1..* supports 1..* 0..* P2P Service

Service

Figure 14. JXTA service model

Communication PSDL Mechanism

<> <> <> 0..1 Module Specification Pipe describes PSDL 1 specifies Advertisement

specifies 11 0..* <> Pipe Advertisement

The PSDL concept was specifically added JXTA is one of the most well known and in order to facilitate the description of P2P mature platforms that can be used for the devel- services with additional information elements. opment of P2P services. Also, as we mentioned Hence, a PSDL document does not aim at before, it is one of the very few P2P platforms replacing the existing description constructs that inherently support the notion of service, provided by the underlying P2P platform, but therefore it is the most prominent candidate to rather to enhance them with information that be modeled by GeSMO. With respect to JXTA these constructs lack. Furthermore, PSDL services (Gong, 2001), JXTA offers constructs descriptions provide the basis upon which such as pipes, module specification advertise- mechanisms and middleware can be built so ments and pipe advertisements. Pipes are com- as to facilitate the more efficient discovery and munication mechanisms used for handling the utilization of P2P services. exchange of messages among peers, thus facili- The aforementioned concepts represent a tating the interactions between service request- basic set of elements that may be used for the ors and service providers. Pipe advertisements description of any kind of P2P service. However, and module specification advertisements are when it comes to modeling P2P services offered specializations of the advertisement construct by specific platforms such as JXTA (JXTA Org, and are used for publishing information about 2006) or Edutella (Nejdl, 2001), additional ele- pipes and services, respectively. ments or specializations of the aforementioned Figure 14 illustrates the specializations ones might be needed. of the P2P service model, which are provided by GeSMO for the representation of the afore-

Copyright © 2008, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 94 International Journal of Web Services Research, 5(4), 79-110, October-December 2008 mentioned JXTA concepts. An extended PSDL ity problems. Thus, the intrinsic similarities description for the JXTA platform describes the between the concepts and the structure that pipes that can be used for exchanging messages were required to be supported by the PSDL with a service and provides references to their and those of the WSDL language (i.e. the respective Pipe Advertisements. A P2P service use of the syntactic elements modeled in the module specification advertisement provides a core layer of GeSMO (see Figure 11)), the reference to the PSDL description document of availability of ample tools and middleware that service. This association is accomplished supporting the construction and utilization of through the use of an extension element (i.e. WSDL documents�� and�� the WSDL support for SURI element (Duigou, 2003, pp. 23-24)) that extensibility, led us to use WSDL as a basis for is inherently supported by the JXTA Module the development of PSDL. Specification Advertisement. Although W3C (www.w3c.org) has lately The specification of the PSDL language released the specification of WSDL2 .0 (Chin- which utilizes the aforementioned GeSMO nici, 2006) most of the existing tools and extensions for the description of P2P service middleware have not yet completely adopted is presented next. this new version of the specification. Therefore, the version of WSDL that we used as a basis A PEER-TO-PEER SERVICE for the development of the PSDL language is DESCRIPTION LANGUAGE the WSDL 1.1 (Christensen, 2001). The peer-to-peer service description language As far as the elements of WSDL 1.1 (PSDL) was introduced as a mechanism that (Christensen, 2001) are concerned, the ones leverages interoperability between P2P ser- catering for the description of a Web service vices as well as between P2P and other types abstract interface (e.g. PortType, Operation, of services.�� Specifically,�� it incorporates a set Message and Types elements) can be reused in of extensions upon the WSDL specification the description of a P2P service abstract interface (Christensen, 2001) which were developed with as well, since both PSDL and WSDL utilize the goal to support the description, discovery the same concepts. However, with respect to and invocation of P2P services. The design of the concrete information part of a service, the PSDL was influenced by: elements provided by WSDL can not cater for the description of the concrete details of a P2P • the concepts and properties of the P2P service. Thus, in order to render PSDL able to service model as they have been perceived deliver its intended functionality, i.e. descrip- in GeSMO, tion, discovery and invocation of P2P services, • the existing mechanisms (i.e. middle- we had to introduce appropriate extensions ware, languages and tools) supporting the which are presented in the following. description, discovery and invocation of According to (Christensen, 2001), WSDL services, and provides the necessary extension points which • the need to be extensible and customiz- can easily accommodate our requirements. The able so as to enable the description of P2P binding and port elements of the WSDL lan- services offered by various types of P2P guage provide the basis upon which P2P related platforms. concepts can be constructed. The introduced elements were devised in a way that enables Instead of developing PSDL from scratch, the description of various types of communica- we decided to develop it as an extension to tion/interaction patterns between a P2P service WSDL. The main reason for this decision was provider and its respective clients.�� Moreover, our intention to reuse existing standards rather these elements were defined with extensibility than introducting another totally new language and customizability in mind, in order to easily and thus complicate further the interoperabil-

Table 2. Imported Namespaces and associated prefixes

xsd http://www.w3.org/2001/XMLSchema wsdl http://schemas.xmlsoap.org/wsdl/

Table 3. Namespaces for introduced concepts

gesmo http://metis.di.uoa.gr/Sodium/gesmo/services/P2P/ jxta http://metis.di.uoa.gr/Sodium/gesmo/services/P2P/jxta/

provide for the properties and characteristics of The notation and the conventions that will various P2P service provision platforms. be used hereafter for the description of the Apart from the PSDL language which provided extensions are as follows: facilitates the description of P2P services, one may argue that extensions and modification • The name of each element is going to be might be needed in other widespread protocols preceded by its associated prefix that is and standards of service oriented computing specified in the tables above. Moreover such as for example SOAP in order to further the names of the WSDL elements that are support interoperability among service types. going to be used in the following are in There are projects striving towards the adoption italics. of the SOAP protocol for exchanging messages • The definition of each of the introduced among peers of a P2P network (e.g. http://soap. elements (i.e. elements whose prefix is dev.java.net/), however, we decided not to ensue going to be ‘gesmo’ or ‘jxta’) adheres to such an approach because our intention was to an informal XML grammar, which uses the retain the autonomy of the existing P2P plat- same notational conventions as the ones forms and middleware without affecting their specified in (Christensen, 2001, section primal features, such as their communication 1.2). In addition to the specified notational mechanisms. Therefore, we focused on the conventions the ‘|’ character is used as provision of the PSDL language. separator among a list of optional values In the following, we will illustrate and that can be assigned to an attribute or as a elaborate on the extensions that we have separator among a list of sub-elements that developed, to support the representation of may be assigned to a specific element. P2P services and their customizations for the • The elements whose names start with a description of JXTA services. Subsequently, we capital letter are abstract elements4 whilst are going to exemplify how the PSDL language the elements whose name doesn’t start with is used for the description of an Instant Mes- a capital letter can be instantiated within a saging service. document. The namespaces that were used as the basis for the development of appropriate exten- PSDL Language Elements sions along with their associated prefixes are Since PSDL is based on the WSDL 1.1 speci- presented in Table 2. fication (Christensen, 2001), it inherits and The namespaces and assigned prefixes retains the structure of the WSDL elements. of the introduced elements are presented in In addition, it extends WSDL with the infor- Table 3. mation components that have been presented above. We need to stress here that only some

Copyright © 2008, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 96 International Journal of Web Services Research, 5(4), 79-110, October-December 2008

Figure 15. PSDL extensions to WSDL

wsdl:message wsdl:operation wsdl:fault wsdl:binding jxta: binding -action gesmo: P2PBinding -pattern wsdl:description

jxta:provider -name -id wsdl:service wsdl:port -type jxta:pipe jxta:pipes gesmo:P2Pservice -name -name -uri -binding jxta:moduleadv -name -uri

of the elements of WSDL 1.1 are extended in related to i) the interaction patterns supported PSDL, whilst the rest of the WSDL concepts, by a service, ii) the operations associated with elements and mechanisms (e.g. the import these patterns, and iii) the protocols used for and include WSDL mechanisms) are reused the message exchange. On the other hand, the without any modification. An illustration of gesmo:P2PService component is an extension the WSDL information components that have of the wsdl:service element, which conveys been utilized to accommodate the concepts of information related to i) the wsdl:ports where the PSDL language and the provided extensions a service resides and ii) the wsdl:bindings that are presented in Figure 15. Please note that the one may use to access each wsdl:port. provided extensions appear in the colored boxes, The formal definition of those elements is while the WSDL elements are white. presented next. More details on those elements along with their definitions are presented in the following. gesmo:P2PBinding: This element denotes First we present some general concepts that can that the underlying communication mechanisms be used in the description of various P2P services and the associated protocols will be related to and then we illustrate the concepts that can be P2P technology. An illustration of the attributes used in the description of JXTA services. and sub-elements of this element is presented in Figure 16. According to this description,� General P2P Service Related PSDL the P2PBinding element has a name and an Elements interface attribute. The name attribute is used The gesmo:P2PBinding and the gesmo:P2PSer- for the element identification and the interface vice components are abstract constructs that attribute holds a reference to the associated provide the foundation for the development of interface (i.e. related wsdl:portType element) P2P platform related elements. These elements element. A P2PBinding element may include a serve as placeholders where concrete informa- documentation sub-element as well as a set of tion supporting the binding and invocation of feature, property or operation sub-elements. P2P services may be conveyed. Please note that, the P2PBinding element Specifically, the gesmo:P2PBinding is abstract, thus it can’t be instantiated and in- component is an extension of the wsdl:bind- cluded in a P2P service description document. ing component, which provides information Appropriate extensions of this element need to

Figure 16. P2PBinding abstract element

? [ | | ]*

Figure 17. P2PService abstract element

? *

be created in order to convey information related holders that support the structure of the PSDL to specific 2P P service provision platforms. language. gesmo:P2PService: The gesmo:P2PSer- vice element contains information about the JXTA specific PSDL Elements endpoints where the service resides. Each JXTA provides a set of protocols and tools which P2PService element should have a name which leverage the development of P2P services and uniquely identifies this element within a service applications. According to (Sun Microsystems, description document. An illustration of the 2005), JXTA services may be provided to their structure of this element is presented in Figure clients via various mechanisms, i.e. through 17. As it can be seen, a P2PService element may pipes directly or via proxy modules which have contain additional documentation information to be installed by clients prior to accessing a as well as a set of wsdl:ports that its clients service. In the work presented here, we describe should use in order to access the service. the support that we have provided for JXTA Note that, the P2PService element is also services accessible through pipes. abstract, therefore appropriate extensions need Although our model can be extended to to be provided in order to convey additional support JXTA services accessible through proxy information related to specific 2 P P service modules, we have chosen not to address such provision platforms. services, mainly due to the following reasons: We would like to note here again that the the first one being the deviation from the service gesmo:P2PBinding and the gesmo:P2PService model (Vogels,2003) that this approach would abstract elements were introduced so as to introduce, i.e. the resulting model would re- serve as placeholders for future extensions of semble more to a distributed component model the PSDL language catering for specific types rather than a service model; and the second of P2P services e.g. Gnutella P2P services. reason being the complexity and source of Thus, these elements merely stand as boundary inconsistencies that this would result in, e.g.

Copyright © 2008, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 98 International Journal of Web Services Research, 5(4), 79-110, October-December 2008

Figure 18. Binding type declaration

Figure 19. Provider element

the discovery and invocation of such services this binding could be either synchronous or would also involve the discovery and invocation asynchronous. of appropriate proxy components. jxta:provider: The jxta:provider element The elements that have been introduced has been introduced to support the specification for the description of a JXTA service are the of the JXTA service provider and the type of jxta:binding, jxta:provider, jxta:pipes, jxta:pipe the service. The PSDL specification dictates and jxta:moduleAdv, as it can be seen in Figure that only one instance of this element must be 15. More details on each of these elements are present within an enclosing port element and presented next. its properties should correspond to the ones of jxta:binding: In order to provide for the the service at hand. specification of JXTA binding schemes that The attributes of this element, which can may be used by a JXTA service,�� we have intro- be seen in Figure 19, provide for the distinc- duced the jxta:binding concept. This element tion among the types of services that may be is used for extending the wsdl:binding element provided in a JXTA network (i.e. either Peer or in order to declare that this is a JXTA binding Group services according to (Sun Microsystems, and in order to specify the action and the com- 2005)) and for the specification of the name munication pattern that will be supported by of the service provider. Therefore the “name” this binding. attribute is used for describing the name of As it is illustrated in Figure 18, an ele- either the peer or the group which offers a spe- ment of this type has two optional attributes; cific service and the “type” attribute specifies the “action” attribute which is used for the whether this is a peer or a group service (see specification of the type of actions that are (Sun Microsystems, 2005). supported i.e. send-receive, send or receive, jxta:pipes: The jxta:pipes element pro- and the “pattern” attribute which is used for vides for the description of the list of pipes that the specification of the interaction type, i.e. are supported by a specific endpoint in order synchronous or asynchronous. for someone to able to exchange messages with The type of binding that is supported by a service. Specifically the jxta:pipes element a P2P service depends on the type of the pipe conveys a listing of the pipe advertisements that will be used for communicating with that that one should use in order to establish pipe service. Hence, if a service uses a bi-directional connections with a JXTA service. pipe for receiving and replying to messages this As it can be seen in Figure 20,�� a jxta:pipes service supports send-receive actions. Depend- element should contain at least one “pipeAd” ing on if this is a blocking or a non-blocking element. Although, in most of the cases the use communication the interaction pattern for of�� a single pipe is adequate for the establishment

Figure 20. Pipes element

Figure 21. PipeAdv element

Figure 22. ModuleAdv element

of a communication channel among a JXTA ment. Furthermore, an instantiation of the jxta: service and its respective client the jxta:pipes pipeAdv element should have a reference to element may contain additional jxta:pipeAd the pipe advertisement file (by using the “uri” elements in order to be able to support more attribute) that a client should use in order to complex communication schemes - which are establish a pipe connection with the service. not excluded by the JXTA framework (Sun Finally, an instantiation of this element could Microsystems, 2005) - that require the use of have a description of the binding that this pipe more than one pipes for the same endpoint. supports. In case this is omitted��,�� the binding of Furthermore, the jxta:pipes element may have the enclosing Port element is used instead. a “name” that is used for referring to that ele- jxta:moduleAdv: The jxta:moduleAdv ment within a specificwsdl:port . element was introduced so as to cater for jxta:pipeAdv: The jxta:pipeAdv element the specification of the module specification is used for providing information regarding advertisement that a JXTA service is using the pipe advertisement that a client may use for its description (see Figure 22). A module in order to open a message exchange chan- specification advertisement is an advertise- nel with a service. In addition��,�� a jxta:pipeAd ment document that is leveraged by the JXTA element provides information related to the network so as to provide for the specification types of interactions that are supported via the of JXTA services. More details on the Module respective pipe. Specification Advertisement can be found at As it is illustrated in Figure 21 each instan- (Duigou, 2006). tiation of the pipeAdv element should have a An instantiation of this element (see Figure “name” which uniquely identifies this element 22) has a “name” and a “uri” attribute. The within the list of pipeAdv elements that may “name” attribute is used for the identification be contained in an enclosing jxta:pipes ele- of the moduleAdv element within the enclosing

Copyright © 2008, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 100 International Journal of Web Services Research, 5(4), 79-110, October-December 2008 wsdl:port element. The “uri” attribute on the will be as the one illustrated in Figure 23. other hand provides for the specification of a The service described is a JXTA peer service reference to the module advertisement file of called “IMService”, which comprises a single the service at hand. operation called “sendReliableMessage”. This This concludes the definition of PSDL and method accepts messages of type “IMessage” the description of its elements. and returns messages of type “IMResponse”. As it can be easily seen, the description of the A PSDL Example abstract part of the “IMService” service is the The elements of the PSDL language can same as that of a Web service. The elements be used to describe any JXTA service that that have been introduced for the specification adheres to the language constraints, as they of a JXTA service can be identified within the were specified above. Taking for example an binding and service WSDL elements. Instant Messaging (IM) service that reliably The jxta:binding element included in exchanges messages with its clients through a the “JxtaBidiBind” element denotes that the bi-directional pipe (Sun Microsystems, 2005, “IMServiceIF” port type, that is referenced pp 14-17), its service description document by the binding’s type attribute, is an interface

Figure 23. Instant messaging service description in PSDL

of a JXTA service. This binding supports send- The architecture of the provided JXTA receive message exchanges using the default P2P service invocation mechanism has been synchronous communication pattern. Accord- based on the use of the web service invocation ing to the information that is conveyed in the framework (WSIF) (Duftler, 2001). This design “JXTABidiPort” element, we can see that the decision was driven by the similarities of the “IMService” service, which adheres to the PSDL and the WSDL languages and by the fact “IMServiceIF” port type, is a peer service. This that WSIF is offered as open source. service provided by a peer of a JXTA network WSIF accommodates the necessary pro- whose name is “Jemini”. Clients of that service gramming abstractions that enable the invoca- may use the “BidiPipe” pipe advertisement in tion of WSDL compliant services over various order to access this service, whilst its module communication protocols and message formats. specification advertisement that is called“IM - It enables either the dynamic or the static (i.e. ServiceModuleAd” can be retrieved at a specific via appropriate stubs that are created at design location that is specified by the uri attribute of time) invocation of services irrespectively of the jxta:moduleAdv element. the protocol bindings and the implementation This PSDL description document can be details that they use. In order to facilitate the fed as input to the JXTA service invocation invocation of any type of code that may be mechanism that is described next, so as to fa- available at the network, the framework pro- cilitate the flexible invocation of the described vides appropriate extension points that can be service, without the developer caring for the utilized by developers so as to accommodate underlying JXTA network details. the peculiarities of specific implementations and communication protocols. JXTA SERVICE INVOCATION Currently, the WSIF framework pro- MECHANISM vides extensions that enable the utilization Based on (Sun Microsystems, 2005), a JXTA of implementations such as Java code, EJBs service, that is made available to its clients and J2EE Connectors in a service-oriented through pipes, can be invoked via messages that manner. Nonetheless, developers are able to are a priori known to the service and its clients. create ‘WSIF Providers’ (i.e. extensions to the WSIF framework) along with appropriate The service advertisement mechanism provided 5 by the JXTA framework does not convey appro- extensions to the WSDL language that enable priate information elements that could facilitate the utilization of additional types of services. the documentation of the exchanged messages. Such a ‘WSIF Provider’ was developed by the Thus, the description as well as the interpreta- authors of this article in order to support the tion of messages is normally embedded within invocation of JXTA services in a more flexible the service and the client code. and service-oriented way. An illustration of the Therefore, for someone to utilize JXTA provided component and its placement within P2P services in the same way as other types the JXTA reference architecture is presented of services,�� e.g. Web services��,�� and to compose in Figure 24. them with other services, appropriate�� invo��- The provided mechanism (‘WSIF Invoca- cation mechanisms need to be put in place. tion Service’ component illustrated in�� Figure�� 24) These mechanisms should enable the dynamic is an extension to the JXTA platform reference invocation of JXTA P2P services based on an- architecture (Gong, 2001) that leverages other notated service description documents. Such JXTA supported services and core components a mechanism was developed by the authors so as to enable the flexible invocation of JXTA of this article so as to enable the invocation of services. Specifically the ‘WSIF Invocation JXTA P2P services via the SODIUM execution Service’ component utilizes the PeerGroup engine based on the use of PSDL description component and the pipe service to support the documents. establishment of pipe connections between a

Copyright © 2008, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 102 International Journal of Web Services Research, 5(4), 79-110, October-December 2008

Figure 24. “WSIF Invocation Service” component integration with the JXTA Reference Archi- tecture

APPLICATIONS/ SUN JXTA 3rd Party 3rd Party MIDDLEWARE Applications Applications Middleware

Core Services Sun Services WSIF Invocation Indexing SERVICES Presence CMS Service Searching

JXTA Core Peer PeerGroups Peer Pipes CORE Monitoring

Security

WSIF Invocation Service WSIF Platform JXTA WSDL4J JXTA WSIF Extensions Extensions

JXTA Pipe Connection Handler

service and a client. Consequently the ‘WSIF enable the establishment of pipe channels and Invocation Service’ component can be utilized the exchange of messages. by other JXTA applications so as to facilitate Although JXTA supports the exchange of the dynamic invocation of JXTA services that either XML or Binary messages (Sun Micro- are described using the PSDL language. systems, 2005), our current implementation of As it can be seen in Figure 24��, t��he com- the ‘WSIF invocation service’ facilitates only ponents that have been added to the WSIF the exchange of XML formatted messages. This Platform in order to support the invocation of decision was influenced by our need to have a JXTA services are the “JXTA WSDL4J Exten- clear mapping between the message representa- sions” and the “JXTA WSIF Extensions”. The tion conveyed in a PSDL description document “JXTA WSDL4J Extensions” contains all the and the message that is exchanged through a necessary extensions to support the parsing of a pipe connection. Nonetheless, the invocation PSDL description document and its mapping to mechanism may be extended in order to facili- in-memory objects, whereas the “JXTA WSIF tate the transformation of messages to a Binary Extensions” comprises the extensions that are format that will be used over a pipe connection mandated by the WSIF framework (WSIF between a service and its clients. However, the Org, 2006) to enable the dynamic invocation description of such a transformation mechanism of JXTA services. The “JXTA Pipe Connection falls outside the scope of this article. Handler” on the other hand leverages services In spite of the placement of the “WSIF and components of the JXTA platform so as to Invocation Service” component within the JXTA Reference Architecture (Sun Microsys-

tems, 2005) (see Figure 24) we do not imply types of services i.e. Web, grid, and P2P services. a tight bond between the JXTA platform and We would like also to note that this invocation the service invocation mechanism. Provided mechanism can be easily used by any engine that appropriate extensions are developed for supporting execution of service compositions the PSDL language as well as for the ‘WSIF which contain P2P services described by PSDL Invocation Service’ so as to cater for the de- documents. scription and invocation of other types of P2P We believe that it has now become apparent services e.g. Gnutella services (www.gnutella. that the work described above (i.e. the GeSMO org) or Edutella services (Nejdl, 2001), this model and its extensions for P2P and JXTA mechanism can be easily plugged in to those services, the PSDL Language and the provided platforms so as to facilitate the interoperation JXTA service invocation mechanism) provides of their respective services. This is possible be- for the interoperability between P2P services cause, service consumers may invoke any type and between P2P and Web services. In order to of service via the WSIF framework in a way better support our argument we illustrate next an that is independent of the underlying bindings example from an application which leverages and protocols. Thus, a client which might be P2P and Web services for the implementation a node of a Gnutella network is able to invoke of the motivating scenario that was presented services provided by peers of a JXTA network in the beginning. and vice-versa. The level of interoperability that is achieved APPLICATION ��CASE STUDY by the ‘WSIF Service Invocation’ component is An important part of the motivating scenario sustained by the extensibility traits of the WSIF described earlier in this article is related to the framework (WSIF Org, 2006) and of the PSDL identification of the location of an accident, the language. This level of interoperability has also identification of the nearest rescue unit and the facilitated the integration of the ‘WSIF Service calculation of the shortest route between them. Invocation’ mechanism with the Execution According to this scenario, when someone calls Engine component of the SODIUM platform to report an accident, his/her location can be which supports the integration of heterogeneous

Figure 25. Rescue route calculation

Copyright © 2008, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 104 International Journal of Web Services Research, 5(4), 79-110, October-December 2008 easily spotted either if he/she is calling from a between P2P and Web services in particular, via fixed-line or from a mobile phone. Appropriate the P2P service description language (PSDL) Web services providing the location of the caller and the JXTA service invocation mechanism. already exist and can be used for this task. Therefore, the related work that follows refers Rescue units on the other hand are already to any of these results. equipped with communication devices which The convergence of Web service and P2P leverage P2P services in order to exchange computing models is an issue that has been location or other types of information (e.g. com- tackled by many researchers (Papazoglou et mands and other types of messages). Based on al, 2004; Benatallah et al, 2003). A plethora of the caller location the closest and most properly approaches have been proposed on how this equipped rescue unit is selected and dispatched can be achieved. In (Papazoglou et al 2004) a to the accident place. P2P architecture is used for the organization Maps with appropriate directions are of federated UDDI registries. The introduced transferred to rescue units in order to reach the federated model enables the formation of syn- accident location in time. Such maps and rout- dicates where services of the same domain can ing directions can be calculated using already be advertised. This approach departs from the existing Web services providing map and other one that we have presented within this article related info (e.g. Google Maps) along with other as we are considering P2P services as another services performing route calculations. service-oriented computing paradigm that can The pilot application that was developed be utilized in the same way as Web services. within the context of the SODIUM project Regarding the P2P service publication and dis- integrates the existing Web and P2P services covery, we reuse the mechanisms supported by (mentioned before) using the models and the the underlying P2P network infrastructures. mechanisms that have been described above The SELF-SERV platform that is proposed in order to support this scenario. The pilot was by (Benatallah et al, 2003) is also using a P2P deployed in Norway at LOCUS, the company infrastructure as the enabling technology which which provided the motivating scenario. Figure leverages the utilization of Web services, i.e. 25 depicts the outcome of the developed ap- the discovery and composition of Web services, plication which is a satellite map, provided by in a P2P organized manner. This approach the Google Map service, with the calculated also does not regard P2P services as another route drawn upon it. This map along with the instantiation of the service-oriented computing calculated route is sent to the ambulance that paradigm, as we do. Therefore our approach is closest to the accident with the use of a P2P is different from the one followed within the service; all ambulances are peers of the same SELF-SERV platform. p2p network. Integration of the P2P and Web services We believe that through this case study, it worlds was also attempted in (Qu, 2004), by becomes apparent that the integration of P2P means of two interaction scenarios: i) exposing services with Web services is of great impor- the existing Edutella/JXTA services as Web tance and facilitates a lot the development of services, and ii) integrating Web service-en- service-oriented applications which need to abled content providers into Edutella/JXTA. integrate such heterogeneous services. The ultimate goal of the proposed approach was to establish integration of Web and P2P RELATED WORK services at the service layer through the use of The main contribution of this article is in service proxies. Although sharing some common ideas, interoperability and service modeling in general, our approach is distinguished by the fact that via the proposed interoperability framework the P2P and Web service technologies retain and the generic service model (GeSMO), and their autonomy. No additional components or in the interoperability among P2P services and infrastructure modifications are required in

our approach, besides the description of P2P there are certain similarities between our service services with the use of PSDL, or some other invocation mechanism and the GAT toolkit, our WSDL-based language. approach is different in that it has a direct sup- P2P service description and invocation was port for the notion of JXTA service whilst GAT also tackled in (Oriol, 2002). Therein, a num- utilizes underlying JXTA communication and ber of alternative, distributed implementation naming mechanisms to support the exchange of infrastructures were proposed, which served the information among Triana’s Group units. purpose of automating service discovery and invocation. Still, the approach was described CONCLUSION from a different point of view than ours, address- Service oriented computing (SOC) has emerged ing service description and invocation from a as the computing paradigm for developing large- relatively higher level. In fact, our P2P service scale, distributed applications, by integrating description language along with the WSIF- existing pieces of software exposed as services. based invocation mechanism could be used Although the primary objective of SOC was complementary with respect to that approach. to leverage interoperability among the various Combining our results with other similar efforts heterogeneous software platforms and systems, is one of our future research plans. its various diverse instantiations (e.g. Web and In (Elenius, 2004), a framework named P2P services) introduced new interoperability Oden was proposed, which utilizes the OWL-S issues. Thus, despite that the integration of the specification to annotate JXTA service descrip- various heterogeneous types of services has been tions with semantics. The results of this effort called for in many vital application domains, included automated P2P service discovery and the incompatible underlying models, protocols invocation. However, the issue of P2P and Web and standards of such heterogeneous services services integration and interoperability goes render this an arduous task. Given this situation beyond the scope of the Oden framework. As op- along with the absence of a set of common, posed to that, in our approach, we mainly focus widely-accepted standards governing all these on establishing a unified manner of describing service-oriented technologies, we argue that and invoking heterogeneous services, and here interoperability can be supported through the we describe how this unified solution has been establishment of a unified approach in terms of applied in the integration between Web and P2P models, languages and tools which are based on services. To this end, we would like to note that, a common set of conceptual primitives. PSDL descriptions could be further annotated In this article, we went through the foun- with semantic and QoS properties, so as to fa- dations of our unified approach towards the cilitate P2P service discovery without affecting integration and interoperability of heteroge- the developed invocation mechanism. neous services, and exemplified how such an Triana (Churches,�� 2006) is a platform that approach was applied for the integration of Web enables the distributed execution of scientific and P2P services. In summary, we presented the workflows. It leverages GAT (Allen, 2003) dimensions influencing interoperability among to support the provision of the necessary ab- the various service-oriented technologies and stractions that facilitate the distribution and presented an integrated classification scheme monitoring of workflows which is based on for these dimensions. Then, we examined the Triana Group unit concept. GAT acts as an the impact of the discrepancies among the overlay above the JXTA infrastructure which investigated types of services on the identified enables the distribution of Group units among interoperability dimensions. The generic service the peers of a JXTA network. GAT leverages model (GeSMO), which was developed in order the underlying JXTA Pipe and ID mechanisms to address some these interoperability dimen- to support the coordination and communication sions was then described. Finally, we focused among the distributed Group units. Although, on the description of the extensions provided

Copyright © 2008, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 106 International Journal of Web Services Research, 5(4), 79-110, October-December 2008 in GeSMO for P2P services, and specialized in our future work. Furthermore, future plans re- the case of JXTA services. garding GeSMO include the provision of exten- As it was discussed in this article, the sions to accommodate other types of services, layered architecture of GeSMO renders it such as sensor services, and the incorporation extensible and independent from the various of additional P2P networks and platforms that service types and their related standards, thus, provide for other P2P services, besides the a perfect basis for the development of unified JXTA platform. languages and tools. We defended this argument by presenting PSDL, a WSDL-based language ACKNOWLEdGMENT which uses appropriate GeSMO concepts and is This work has been partially supported by the used for the description, discovery and invoca- Special Account of Research Funds of the Na- tion of P2P services, enabling in this way P2P tional and Kapodistrian University of Athens services to be integrated and interoperate with under contract 70/4/5829 and by the European Web services. Along with PSDL, we presented Commission (under contract IST-FP6 004559 an effective mechanism for the invocation of for the SODIUM project and IST-FP6 511680 JXTA P2P services. We believe that the com- for the SeCSE project). Finally, the authors bination of this invocation mechanism (being would like to thank all the SODIUM partners based on the WSIF framework) with the PSDL which contributed in this work and in particular language (being based on WSDL) provides a LOCUS for their input in the motivating scenario novel solution for the integration of Web and and in the case study. P2P services. It should be noted that the extensibility of REFERENCES the approach presented in this article was exemplified by the extensions of GeSMO within the Akkiraju, R., Farrell, J., Miller, J., Nagarajan, M., context of the SODIUM project, so as to address Schmidt, M.-T., Sheth, A., Verma, K., (2005) Web grid services as well. Therefore, all SODIUM Service Semantics, WSDL-S, W3C Submission, tools and languages support Grid services, too, http://www.w3.org/Submission/WSDL-S/ via appropriate extensions on GeSMO; hence Allen, G., Davis, K., Dolkas, K., Doulamis, N., they provide a platform which supports the Goodale, T., Kielmann, T., Merzky, A., Nabrzyski, J., unified discovery, composition and execution Pukacki, J., Radke, T., Russell, M., Seidel, E., Shalf, of Web, grid and P2P services. Furthermore, J., and Taylor, I., (2003), Enabling Applications on the presented solution was integrated with the the Grid: A GridLab Overview, International Jour- results of another European project, namely nal of High Performance Computing Applications: SeCSE, which supports the development of Special issue on Grid Computing: Infrastructure and Applications, August 2003 service-oriented applications. We would like also to note that GeSMO and its extensions have Alves, A., Arkin, A., Askary, A., Bloch, B., Curbera, been included in a proposal submitted to OMG F., Ford, M., Goland, Y., Guízar, A., Kartha, N., Liu, as a response to a Request for Proposal for a C. K., Khalaf, R., König, D., Marin, M., Mehta, V., UML Profile and Metamodel for Services6 . Thatte, S., Rijn, D., Yendluri, P., Yiu, A., (2006), Finally, we would like to mention that, Web Services Business Process Execution Language Version 2.0 Public Review Draft, 23rd August 2006, GeSMO served as a basis for handling in- available at http://docs.oasis-open.org/wsbpel/2.0/ teroperability at the signature or platform level, therefore it needs to be further extended Bajaj, S., Box, D., Chappell, D., Curbera, F., Daniels, in order to fully address the interoperability G., Hallam-Baker, P., Hondo, M., Kaler, C., Langwor- problem. In this regard, issues related to other thy, D., Nadalin, A., Nagaratnam, N., Prafullchandra, interoperability dimensions such as protocol, H., Riegen, C., Roth, D., Schlimmer, J., Sharp, C., Shewchuk, J., Vedamuthu, A., Yalçinalp, Ü., Orchard, quality or application, as well as semantic or D., (2006), Web Services Policy 1.2 - Framework business domain are going to be addressed in (WS-Policy), W3C Member Submission April

2006, available at http://www.w3.org/Submis- Programming Scientific and Distributed Workflow sion/2006/SUBM-WS-Policy-20060425/ with Triana Services, Concurrency and Computation: Practice and Experience Special Issue: Workflow in Ballinger, K., Ehnebuske, D., Ferris, C., Gudgin, M., Grid Systems 2006, V(18) n(10), 1021-1037 Nottingham, M., Yendluri, P., (2004) Basic Profile Version 1.1, WS-I specification, 8 August 2004, Czajkowski, K., Ferguson. D., Foster, I., Frey, J., http://www.ws-i.org/Profiles/BasicProfile-1.1- Graham, S., Maguire, T., Snelling, D., Tuecke, S., 2004-07-21.html (2004), From Open Grid Services Infrastructure to WS-Resource Framework: Refactoring & Evolution, Beckett, D., McBride, B., (2004), RDF/XML Syntax Version 1.0, Whitepaper, February 2004. Specification (Revised), W3C Recommendation, DeMichiel, L., Keith, M., (2006), Enterprise Java February 2004, available at: http://www.w3.org/ Beans, Version 3.0: EJB Core Contracts and Require- TR/rdf-syntax-grammar/ ments, Release 8 May 2006, available at http://java. Benatallah, B., Dumas, M., and Sheng, Q. Z.,(2003), sun.com/ The SELF-SERV Environment for Web Services Dubray, J. J., Amand, S., Martin, J. M., (2006), Composition, IEEE Internet Computing Jan/Feb ebXML Business Process Specification Schema Issue, Vol. 7 (1 ). IEEE Society 2003 Technical Specification v2.0.4, Committee Speci- Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, fication, 13 October 2006, available at http:// E., Yergeau, F., (2004), Extensible Markup Language www.oasis-open.org/committees/documents. (XML) 1.0 (Third Edition), W3C Recommendation php?wg_abbrev=ebxml-bp 04 February 2004, http://www.w3.org/TR/2004/ Duftler, J. M., Mukhi, K. N., Slominski, A., Weerawa- REC-xml-20040204/ rana, S., (2001), Web Services Invocation Framework Burstein, M., Bussler, C., Zaremba, M., Finin, T., (WSIF), OOPSLA 2001 Workshop on Object-Ori- Huhns, N. M., Paolucci, M., Sheth, P. A., Williams, ented Web Services: Supporting the Development, S., (2005), A semantic web service architecture, In Deployment and Evolution of Web Services, October IEEE Internet Computing, vol 9 issue 5, Sept.-Oct. 2001 - Tampa, Florida, USA 2005, 72-81 Duigou, M., (2006), JXTA v2.0 Protocols Specifi- Booth, D., Haas, H., McCabe, F., Newcomer, E., cation, IETF Working Group Draft Specification, Champion, M., Ferris, C., Orchard, D., (2004), August 2006 Web Services Architecture, W3C Working Group Elenius, D. and Ingmarsson, M. 2004. Ontol- Note, February 2004, available at http://www. ogy-based service discovery in p2p networks. In w3.org/TR/ws-arch/ Proceedings of the First International Workshop Bruijn, J., Bussler, C., Domingue, J., Fensel, D., on Peer-to-Peer Knowledge Management, Boston, Kifer, M., Kopecky, J., Lara, R., Oren, E., Polleres, Massachusetts, USA, August 2004, CEUR-WS, A., Stollberg, M., (2005), Web Service Modeling On- August 2004, Vol. 108. tology (WSMO), WSMO Final Draft February 2005, Fang, J., Hu, S., Han Y., (2004), A Service Interoper- available at http://www.wsmo.org/TR/d2/v1.1/ ability Assessment Model for Service Composition, Christensen, E., Curbera, F., Meredith, G., Weerawa- In Proceedings of the 2004 IEEE International rana, S., (2001) Web Services Description Language Conference on Services Computing (SCC’04), Sept. (WSDL) 1.1 W3C Note 15 March 2001, available 2004, Shanghai, China at: http://www.w3.org/TR/wsdl Farrell, J., Lausen, H., (2006), Semantic Annotations Chinnici, R., Gudgin, M., Moreau, J.-J., Weerawa- for WSDL, W3C Working Draft 28, Sept. 2006 rana, S., (2003), Web Services Description Language Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masin- (WSDL) Version 2.0 Part 1: Core Language, W3C ter, L., Leach, P., Berners-Lee, T., (1999), Hypertext Candidate Recommendation, 27 March 2006, avail- Transfer Protocol - HTTP/1.1, IETF, June 1999 able at http://www.w3.org/TR/wsdl20/ Ivkovic, I., (2001), Improving Gnutella Protocol: Churches, D., Gombas, G., Harrison, A., Maassen, J., Protocol Analysis and Research Proposals, LimeWire Robinson, C., Shields, M., Taylor, I., Wang, I., (2006), Gnutella Research Contest, September 2001

Copyright © 2008, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 108 International Journal of Web Services Research, 5(4), 79-110, October-December 2008

Gibbons, P., Karp, B., Ke, Y., Nath, S., Seshan, S., Oriented Programming (ECOOP’96), pp. 150–158, (2003), ��IrisNet: An Architecture for a World-Wide dpunkt, July 1996 Sensor Web, IEEE Pervasive Computing, V(2), N(4), October-December 2003 Nejdl, W., Wolf, B., Qu, C., Decker, S., Sintek, M., Naeve, A., Nilsson, M., Palmer, M., Risch, T., (2001), Gong, L., (2001). JXTA: a network programming EDUTELLA: A P2P Networking Infrastructure environment, IEEE Internet Computing, May/Jun Based on RDF, Edutella White Paper, November 2001, Vol. 5 (3), pp. 88-95. 2001, available at http://edutella.jxta.org/reports/

Gramm, M., Ritter, A., Schiller, J. H., (2004). ��Ef- edutella-whitepaper.pdf ficient selection and monitoring of QoS-aware web Nezhad, H.R. M., Benatallah, B., Casati, F., Toumani, services with the WS-QoS framework. In Proceedings F., (2006), Web service interoperability specifica- of 2004 IEEE/WIC/ACM International Conference tions, IEEE Computer, vol. 39 no. 5, May 2006, on Web Intelligence, Beijing, China, September pp 24-32 2004, 152-158. Newmarch, J. (2005) UPnP services and Jini clients. Hoff, H., Gronmo, R., Skogan, D., Strand, A., (2005), In Proceedings of the 2005 Conference on Informa- D7 Specification of theV isual Composition Language tion Systems: Next Generations, ISNG 2005, Las (VSCL), SODIUM (IST-FP6-004559) Project’s Vegas, Nevada, USA. Deliverable, June 2005 Oriol, M. (2002) Peer Services: From Description to JXTA Org, (2006) Project JXTA, available at http:// Invocation. In Proceedings of the 2002 International www.jxta.org/, accessed 21 December 2006 Workshop on Agents and Peer-to-Peer Computing, July 2002, Bologna, Italy, Springer Berlin / Heidel- Kavantzas, N., Burdett, D., Ritzinger, G., Fletcher, berg, LNCS 2530/2003, 21-32 T., Lafon, Y.,Barreto, C., (2005), Web Service Cho- reography Description Language (WS-CDL) ver 1.0, Pantazoglou, M., Tsalgatidou, A., and Athanaso- Nov 2005, http://www.w3.org/TR/ws-cdl-10/ poulos, G. (2006), Discovering Web Services and JXTA Peer-to-Peer Services in a Unified Manner, Martin, D., Burstein, M., Hobbs, J., Lassila, O., Mc- In Proceedings of the 4th International Conference Dermott, D., McIlraith, S., Narayanan, S., Paolucci, on Service Oriented Computing, December 2006, M., Parsia, B., Payne, T., Sirin, E., Srinivasan, N., Chicago, USA, Eds. A. Dan and W. Lamersdorf, Sycara, K., (2004) OWL-S: Semantic Markup for 104-115 Web Services, W3C submission, Nov. 2004 http:// www.w3.org/Submission/OWL-S/ Papazoglou, M., Krämer, B., Yang, J., (2004), Le- veraging Web Services and Peer-to-Peer Networks, McGuinness, D., Harmelen, F.,(2004), OWL Web Book Chapter in Advanced Information Systems, Ontology Language Overview, W3C Recommen- Feb 2004, Springer Berlin / Heidelberg 2681/2003, dation, February 2004, available at http://www. 485-501 w3.org/TR/owl-features/ Pautasso, C., Alonso, G., (2004) “From Web Service Medvidovic, N., Rosenblum, D., Gamble, R., (1999), Composition to Megaprogramming” In Proceed- Bridging Heterogeneous Software Interoperability ings of the 5th VLDB Workshop on Technologies Platforms, Technical Report, USC-CSE-99-529, for E-Services (TES-04), Toronto, Canada, August Center for Software Engineering, USC, November 29-30, 2004 1999 Qu, C., and Nejdl, W. (2004) Interacting the Edutella/ Microsoft Corporation (1996), Distributed Compo- JXTA Peer-to-Peer Network with Web Services. In nent Object Model Protocol-DCOM/1.0, draft, No- Proceedings of the 2004 Symposium on Applications vember 1996, available at http://www.microsoft. and the Internet, IEEE Computer Society.

com/Com/resources/comdocs.asp Ryan, N., (2005), Smart Environments for Cul- Murer, T., Scherer, D., Wuertz, A., (1996), Improving tural Heritage, In Proceedings of 24th International component interoperability information, Proceedings Symposium on Reading the Historical Spatial In- of Workshop on Component-Oriented Programming formation in the World, pp 17-33, Kyoto, Japan, (WCOP’96) at 10th European Conference on Object- February 2005

Ruiz, A., Corchuelo, R., Martín,O., Durán, A., Toro, Vallecillo, A., Hernandez, J., Troya J., (2000), M., (2000), Addressing Interoperability in Multi- Woi’00: New issues in object interoperability, Organisational Web-Based Systems, Proceedings LNCS (1964): ECOOP’2000 Workshop Reader, pp. of the 2nd ECOOP Workshop on Object Interoper- 256–269, Springer ability (WOI’2000), Sophia Antipolis, France, June 12, 2000 Vogels, W., (2003), Web Services Are Not Distrib- uted Objects, IEEE Internet Computing, Nov.-Dec. Siegel, J., (1996), CORBA Fundamentals and Pro- 2003 gramming, Wiley, 1996 WSIF Org, (2006), Web Service Invocation Frame- Strang, T., Linnhoff-Popien, C. (2003), Service work, accessed at 21 December 2006, available at Interoperability in Ubiquitous Computing Environ- http://ws.apache.org/wsif/ ments, Proceedings of International Conference on Advances in Infrastructure for Electronic Business, Education, Science, Medicine, and Mobile Technolo- Endnotes 1 Sodium project http://www.atc.gr/sodium/ gies on the Internet (SSGRR2003w), L’Aquila, Italy, 2 SeCSE project http://secse.eng.it/ January,2003 3 The visual language used in this example is the Sun Microsystems, (2005), “JXTA v2.3.x: Java Visual Service Composition Language devel- Programmers Guide”, available at: http://www.jxta. oped in the SODIUM project (Hoff, 2005). org, April 2005 4 More details on the abstract XML elements and attributes can be found at (Fallside, 2004) Tanenbaum, A. S., (2003), Computer Networks, 5 WSIF leverages WSDL4J to support the parsing Prentice Hall, fourth edition, 2003, ISBN: 0-13- and the in-memory representation of WSDL 066102-3 information elements. However, WSDL4J supports only WSDL 1.1 descriptions. Furthermore Tsalgatidou, A. Athanasopoulos, G., Pantazoglou, according to WSDL 1.1 extensions may be M., Pautasso, C., Heinis, T., Gronmo, R., Hoff, H., provided only to the Service, Port and Binding Berre, A-J., Glittum, M., Topouzidou, S. (2006) elements. Developing Scientific Workflows from Heteroge- 6 The OMG UML Profile and Metamodel for neous Services, ACM SIGMOD-RECORD v(35) Services (UPMS) RFP document can be re- n(2) 22-28, June 2006 trieved from the following link: http://www. Tsalgatidou, A., Athanasopoulos, G., Pantazoglou, omg.org/cgi-bin/doc?soa/06-09-09.pdf M., (2005), Generic Service Model Specification, Technical Report, available at: http://www.di.uoa. gr/~gathanas/TR/gesmo-1.0-report.pdf

Aphrodite Tsalgatidou is a permanent member of the academic staff at the Department of Informatics and Telecommunications of the National and Kapodistrian University of Athens since 1999. She holds a diploma degree in chemistry from the same institution and an MSc and a PhD in computer science from the University of Manchester, England. Previously she was with the Hellenic Telecom Organization and a research director in a private company. Aphrodite is the director of the S3 Laboratory (www.s3lab.com) which pursues research in service engineering, software engineering and software development; she has participated in and/or managed a large number of projects in these areas and has published relevant papers. Her current research focuses on service interoperability, service discovery and composition, peer-to-peer systems and business process management and interoperability.

George Athanasopoulos is a researcher and member of the S3 Laboratory (www.s3lab.com) and a PhD- candidate at the Department of Informatics and Telecommunications of the National and Kapodistrian

Copyright © 2008, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 110 International Journal of Web Services Research, 5(4), 79-110, October-December 2008

University of Athens (www.di.uoa.gr). He holds a diploma from the Department of Computer Engineering and Informatics of the University of Patras (www.ceid.upatras.gr) and has participated in various research and development projects during his work experience. His research interests include service-oriented computing with a focus on the context-adaptable composition of heterogeneous services comprising various types of services such as Web services (either stateless or stateful), P2P services, sensor and actuator services, etc. Additional research interests are related to distributed systems and software architecture modeling as well as modern programming methodologies.

Michael Pantazoglou is�� a PhD student and research scientist at the Department of Informatics and Tel- ecommunications of the National and Kapodistrian University of Athens. He holds a diploma degree in informatics and telecommunications from the same institution. Being a member�� of the S3 Laboratory, ��he has participated in several research and development projects. His current research interests include service- oriented technologies with a focus on service discovery, semantic technologies, P2P computing, and the application of information retrieval and natural language processing techniques in data management.