Service Communities: Applications and Middleware Stefan Tai
Nirmit Desai
1
Pietro Mazzoleni
2
IBM Research
North Carolina State University
University of Milan
[email protected]
[email protected]
[email protected]
ABSTRACT Businesses increasingly provide and use services, applying formal (Web) services technology for the description, composition, and management of software as services. At the same time, social communities are emerging on the Web, applying less formal practices and Web 2.0 technology for the dissemination and aggregation of diverse content. In this paper, we are interested in the combination of these two trends in the form of service communities: social and business communities exchanging services. We discuss applications of service communities and introduce the concept of Service Clubs as a structuring mechanism for communities. Clubs have been specifically designed to support community-based, per-project interaction and composition of services.
Categories and Subject Descriptors D.2.12 [Software Engineering]: Interoperability – distributed objects. K.4.4. [Computers and Society]: Electronic Commerce – distributed commercial transactions.
General Terms Management, Design, Experimentation
Keywords Service communities, marketplaces, middleware, service groups
1. INTRODUCTION We are observing a number of trends associated to the growth and use of the Internet. Services computing, most prominently described by the Web services platform is one such trend. The Web services platform consists of a number of (proposed) open XML-based standards for the description, composition through choreography, and management of services [9]. (Web) Serviceoriented architectures are increasingly being used to provide and use software as interoperable services over the Internet. Another major trend is related to the way that humans use the Internet. Social communities and community platforms such as MySpace.com, Flickr.com, and YouTube.com attract very large Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SEM 2006, November 10, 2006, Portland, OR, USA. Copyright 2006 ACM 1-58113-000-0/00/0004…$5.00.
numbers of individuals to share arbitrary content. From a technical viewpoint, community platforms are Web portals that provide basic functionality for the dissemination and aggregation of data in large-scale networks. Community practices center on the use of Web 2.0 technology that enables simple, more ad-hoc composition and content mash-ups, and documentation through less formal techniques such as social tagging. We are interested in the combination of these two major trends in the form of social and business communities exchanging services. We refer to such communities as service communities. In this paper, we define the notion of service communities and provide first results of ongoing exploratory work on service community applications and middleware. We describe examples of business-oriented service communities that illustrate and explain the motivation for our work. We further introduce the concept of Service Clubs as a structuring mechanism supporting service communities. We discuss the use of the clubs concept for our application examples, and sketch the architecture and design of the ClubMe middleware as a services community and collaboration platform. We argue that service communities and clubs are promising for individuals and businesses alike, as the number of service offerings increases and use of services no longer is a predominantly technical concern, but one that is about creating business value and involving humans that are part of business and social networks. We believe that service composition should be tailored to its application and user context. Clubs have been specifically designed to support community-based, per-project interaction and composition of services. Our work is positioned in the larger context of Services Science, which addresses the multi-disciplinary nature of service innovation [7]. In this context, services are interactions creating business and societal value, and correspondingly, Services Science integrates business, economy, technology, socialorganizational, legal, and other disciplines. We aim to contribute to the field of Services Science by innovating methods and middleware for service-oriented computing and service-oriented business ecosystems. The paper is structured into three main sections, describing applications of service communities, the concept of Service Clubs, and the design of the ClubMe middleware prototype. Related work and future work are discussed in the end.
1,2
The work by N. Desai and P. Mazzoleni was done while visiting the IBM T.J. Watson Research Center in Hawthorne, NY, USA.
2. SERVICE COMMUNITIES Service communities are motivated by the desire to better manage complex business ecosystems that comprise varying groups of stakeholders. As an example, consider the following scenario from the healthcare industry.
2.1 Healthcare Communities The process of drug discovery requires careful planning and execution of pre-clinical trials to determine the toxicity of a new drug. Pre-clinical trials involve diverse activities and experiments, which vary depending on the drug to be tested and the parties involved.
and e-commerce functionality (such as billing or providing market statistics and analytics). Benefits of service marketplaces include simplification of interactions due to establishing a single access location that integrates a potentially rich set of functionality. For example, single sign-on authentication or single finance and accounting for the use of multiple, different services can be supported. Marketplaces further create value-add by leveraging the community of partners that share common interests. For example, marketplaces can be set up to specifically address service providers and consumers interested in HR services for large corporations.
When a pharmaceutical company decides to begin a new preclinical trial, its R&D department first needs to identify the parties that will produce the drug (starting from a chemical compound) and the parties that will execute the experiments (according to a specific protocol). The parties can be internal or external. Additional parties may get involved to analyze data produced by the experiments. In the case that external parties are involved, such as hospitals, universities, or CRM (Clinical Research Management) companies, the R&D department has to choose the partners with which to do business and negotiate and agree on economical, legal, and scientific details. During the trial, all parties need to work closely with each other, exchanging information to monitor the process and possibly also modify the protocol. Complex algorithms need to be executed as well as dedicated data sources need to be accessed for analysis and integration of the data coming from the trial.
Service marketplaces and platforms, however, are only a starting point to create and manage the domain-specific, per-project communities discussed in the healthcare scenario above. General marketplaces may be (too) large in scale (in terms of members and services exchanged), and additional structuring mechanisms beyond simple service registries are required. For example, a runtime services grouping abstraction to loosely compose services of interest to select members is currently missing yet very desirable to have in support of the above healthcare scenario.
The complexity of the process is due to variations in the composition of the different (potentially autonomous) stakeholders, variations in regulations of the target market(s) of the drug, and variations in the tasks and type of experiments to perform. The problem of optimizing the different phases of drug research and discovery is recognized as one of the pressing needs of pharmaceutical companies in the years to come [4].
We define a Service Club as a dynamic group of services, where
2.2 Communities and Marketplaces In a scenario like the one presented, different groups of partners collaborate by communicating and exchanging information with each other, and by implementing processes that are tailored to the needs of a specific trial. The groups of partners can be considered communities (of varying scale), where members of the community interact with each other by providing and using services. Currently, there is little or no Internet-based system support for creating and maintaining such custom, per-project service communities. Existing approaches either address a specific technical concern only (such as selecting a service from a group of available services that offer the same functionality), or focus on community platforms that have little relationship to services computing and SOA. We review related work in Section 5. However, we can observe a number of service marketplaces emerging, including Salesforce.com, Reardencommerce.com, StrikeIron.com, and Jamcracker.com. These service marketplaces offer e-commerce capabilities to buy and sell services [6]. As such, they are closer to our notion of service communities. Marketplaces typically require a membership model for businesses and individuals, and marketplace functionality can include both technical (for example, service uptime monitoring)
3. SERVICE CLUBS We propose Service Clubs as a structuring mechanism to create and manage per-project (sub-) communities within larger-scale service communities and marketplaces.
3.1 Definition •
Only members can contribute services to the club for use by other members
•
Any kind of service can be contributed to a club
•
Membership criteria can be defined on a per-club basis.
Membership criteria can include the requirement for each member to implement one or more club-specific service interfaces. This allows “traditional” distributed computing techniques to be offered by the club, such as load balancing of services that implement the same interface or fault-management through group communication protocols. The main aspect of clubs, however, is to establish a dynamic community platform where services of interest to a community are grouped. Clubs are created to provide member-directed business and technical value-add. Clubs provide the mechanism for members to contribute various functional and extra-functional services. Clubs build on research and work on adaptive and extensible middleware, elevating these concepts to the services marketplace layer. Correspondingly, club services that are contributed can include services that intercept the invocation of other contributed services [10]. While each club describes a services composition itself – a club is a group of diverse services that are contributed by members – additional data management functions and choreography functions for services composition (such as sequencing of invocations) can be provided through the club.
Clubs also integrate selected community practices of Web 2.0, including community-based tagging to provide meta-information for services. Services contributed by members can be tagged using a set of (club-specific) community terms, and browsing and matchmaking functions be applied using these tags.
Service Marketplace with Clubs Service Club Club Management 1. create new or join existing club
Club management is provided by a Clubs middleware platform that supports clubs creation at any time, termination of existing clubs, and club membership management.
4a. join club
Registry
4b. discover club services
2. contribute services to a club 3. invite club members
Membership Service / Provider
Client
3.2 SOA Service Clubs are designed as an extension to standard SOA principles, starting from the basic SOA-triangle of service publication, service discovery, and service invocation involving a service provider, a registry, and a client (Figure 1).
Community Functions
5. invoke, compose dynamically
Service Registry
2. discover
club-specific + monitoring + interception + billing + other
1. publish
Service / Provider
Client 3. invoke
Clubs Registry
Figure 1: Basic SOA + other cross-clubs functions Service Marketplace Registry
Figure 3: SOA and Service Clubs
Membership 2b. discover
1b. publish
2a. register
1a. register Service / Provider
Client 3. invoke + monitoring + interception + billing + other
•
Private, trusted services offerings, using a membership-based access control and trust model
•
Social networks and interaction practices in services composition, leveraging a spectrum of formal and less formal services description, matchmaking, and composition techniques
3.3 Examples Figure 2: SOA and Marketplaces Figure 2 illustrates how the basic SOA style is refined when using marketplaces. A membership model for service providers and clients is added, and marketplace mediation to monitor, intercept, and apply other value-add functions is introduced. Figure 3 shows how the marketplace-based SOA can again be refined using the additional structuring mechanism of service clubs. Membership and marketplace value-add services are no longer applied to each member and each service use, but are introduced on a per-club (services group) basis. Clubs provide additional management services and also integrate community collaboration functions supporting community practices such as tagging, in addition to the more formal, standards-based (Web) services computing model. In summary, clubs are a runtime structuring mechanism that support •
Horizontal, vertical (domain-specific), per-project grouping of services
Consider again the healthcare scenario described in Section 2. We can easily identify at least three different Service Clubs, each one featuring different objectives, different members, and different services. A first example is a club created by the pharmaceutical company to group the stakeholders (universities, CMRs, hospitals, etc.) offering pre-clinical services. The membership-based aspect guarantees that only trusted parties will publish the types of experiments they can execute and also that customized information (such as community-specific offers) is visible only to members of the club. In addition, recognized experts can provide matchmaking services to compare the services offered by group members and/or third parties. As a second example, consider per-project clubs created by the R&D department in order to manage information and tasks associated to specific trials. Each club can group the (legal and financial) services that the pharmaceutical company will make available to the other parties. The stakeholders producing the drug can publish a service to order new quantities of drugs and to distribute information about the process used to create it. Finally, the stakeholders executing the trial can share, as services, the
possibility to access the data sources containing the information generated during the experiments. As an example of a club membership requirement, all members may have to provide a service implementing a club-specific interface to accept generic inquiries coming from other members. Using these per-project (per-trial) clubs, the pharmaceutical company is able to monitor all the internal and external communications about a trial (which are today distributed in emails) as well as reduce the time taken to gather the data coming from the experiments.
Club 3 Club 2 Club1
Club Services
Club Member A
Contribute
Dynamic composition
Mash-ups
Matchmaking
Club Analytics
Value-add Services community member
Club Member B Contribute
Service Provisioning
Service Management
Club Information
A third example of a club can be envisioned to group services used by researchers to analyze the data coming from the experiments and to improve decision-making for possible protocol modifications. The services contributed by members in this club can span from services to access to experimental data, services executing specific complex algorithms, analytic services, and services to access computational power as well as data storage to store complex data.
Membership Management
ClubMe Club Platform Club Member C Use
ClubMe Core Platform Club Factory
Admin
Club Management
4. MIDDLEWARE Services Community & Social Community
We now outline the architecture and design of the ClubMe middleware prototype supporting service communities through the concept of Service Clubs.
Figure 4: Service Clubs and the ClubMe middleware. Members of a larger community can create new, or become members of existing clubs. As club members, services can be contributed to the club. The ClubMe middleware supports club-independent management functions and functions supporting club-specific services.
4.1 Architecture and Design The ClubMe middleware consists of two sets of middleware services: •
Core services
•
Per-club services
The core services support the management of various clubs, including creation, termination, and social tagging of clubs. These operations are fundamental and independent of the objectives, domain, and members of any particular club. The per-club services support membership management, service management, service provisioning, and information dissemination for a particular club. The ClubMe middleware supports controlled membership and controlled social tagging, in line with the abovediscussed idea of striking a balance between very open and informal communities and more closed, formal computing networks. At the very basic level, a subject wishing to become a club member must meet membership criteria defined for a club, such as the requirement for a member to implement of a clubspecific service interface. Controlled tagging describes a model in which the set of tags that can be applied to clubs and contributed services is restricted by the administrators of the club. We are currently experimenting with different types of restrictions to provide different degrees of discipline and structure to otherwise too informal community practices. Specifically, the core platform supports the following service endpoints: •
Club Factory: This is the only public endpoint of the core platform, allowing members of the larger community to create new clubs by providing a name, membership criteria, and a set of initial tags for the club. As a result, a new clubspecific platform is spawned.
•
Club Admin: Available only to the creator and administrators of a club, this endpoint can be used to terminate the club, or to supply additional applicable tags for the club.
The per-club platform supports the following endpoints: •
Club Info: This is the only public endpoint of the per-club platform, providing general information about the club to the larger community. Such information may include a summary of the services available, membership criteria, and the social tags that describe the club. Subjects can apply for membership via this endpoint and may be approved or denied based on the membership criteria. Approved applicants are returned the club registration endpoint.
•
Club Registration: Approved applicants can join the club using this endpoint. Existing members can leave. Separation of approval and joining allows agents to apply, get approved, and share the endpoints with their principals allowing them to join.
•
Club Member Services: Members can contribute, consume, tag, and compose services via this endpoint. In addition to application services, value-add services such as club analytics and interface and tag-based services matchmaking can also be contributed by members (including administrators) and later be consumed by other members.
Only the endpoints and meta-information about the contributed application and value-add services are registered with the club; the actual services are hosted elsewhere. This proxy-based approach allows services to exist and be maintained independently of clubs by the service provides, and be (potentially) contributed to multiple clubs. For platform services that should not be distributed, we are currently developing a
model to co-locate and host services on the club platform. This approach is similar to our previous work [10].
business applications and into the broader context of Services Science and service-oriented business ecosystems.
We are currently investigating different models for the composition of contributed services. These include APIs that “decompose” BPEL-like functionality into a set of APIs for simplified, dynamic services choreography. For that purpose, club members can also create and use typed data variables to be stored and provided by the club.
From a technical viewpoint, clubs are related to group concepts in distributed computing. A variety of group concepts exist; these are mostly concerned with server replicas, addressing load-balancing, security, and fault-tolerance through coordination and consensus protocols [3]. Service clubs are not restricted to replicas or services that implement the same functionality; clubs can also be community-based collections of diverse services. The objective of Service Clubs is to introduce a structuring concept that also integrates less formal community practices for services computing.
Further, as different kinds of services are contributed to a club, different rules to their composition exist. Figure 4 illustrates the case where club member A contributes an application service to Club 1 while club member B contributes a value-add service to Club 1; the most important distinction between these two types of services is that value-add services are applied to or injected into the use of application services. Value-add services provide extra functionality such as monitoring, billing, security, reliability, matchmaking, and analytics. Thus, the usage of a contributed application service (as by club member C in Figure 4) may be intercepted by one or more selected value-add services. We are investigating the use of a declarative, policy-based model to direct application of value-add services to application services, again building on previous work [8]. Intuitively, as value-add services are generic in nature and may potentially be used with many application services, their contribution to a club should be more rigorously controlled than that for application services. As every club is a controlled member environment, and every member can determine which member owns and provides a club service, a basic, initial trust model is in place. Additional trust and access control mechanisms, for example those suggested by the Web services platform, can be used as well.
4.2 Implementation We have built a research prototype based on the above-described middleware framework, and are currently implementing and experimenting with some of the more specific extensions through services. We plan to make this core prototype and selected valueadd services (which can be added to clubs by inviting the service owner as a member) available for public use and experimentation. The prototype is built on open-source components, including Apache Tomcat 5.5, Apache Axis2, and Apache Derby. Development of Eclipse tooling and a Web-based user interface is in development, too.
5. RELATED WORK Our work is motivated by complex business applications and processes such as the Healthcare scenario described in Section 2, and by trying to combine the benefits of the two major emerging trends of (Web) services computing and social communities / Web 2.0 to support these business applications. The concept of Service Clubs applies to electronic marketplaces [6] and service-oriented business process management [5], however, aims to introduce increased flexibility and dynamics in the services managed and provided by marketplaces and used in business processes. This objective is in line with research on adaptive middleware, an example of which is the Cumulus architecture that supports an on-demand middleware-as-services model [10]. Service Clubs aim to raise these ideas to the level of
In the Web services context, a concept also termed “service communities” has been proposed [1][2]. However, these “communities” are essentially conventional object groups of distributed computing set in a Web services environment. The focus is on technical concerns such as QoS-based services selection, but not on business and social community concerns.
6. SUMMARY AND FUTURE WORK We described ongoing exploratory research on managing service communities using the design and runtime concept of Service Clubs. We motivated our work using a real-world scenario from the Healthcare industry, and outlined how clubs can help address to structure and implement such applications in Services Science. We re-visited the basic model for Web-services-based SOA to refine it for service marketplaces and Service Clubs, and presented the architecture and design of our middleware prototype supporting clubs. This paper reports on work-in-progress, where first results include the general concept of Service Clubs and a middleware prototype. The concept of clubs is deliberately kept simple, but as discussed in the paper, there are many areas for future work. These include •
Extensive experimental work creating and managing various sample clubs. Analysis and insight generation on business and social community practices for services computing.
•
Services supporting different services composition models, including process-based (BPEL) compositions as well as more ad-hoc services mash-ups, and related data management.
•
Refined membership management model (roles, permissions) and its impact on contributing, composing, observing, and using services.
•
Continued experimentation with different levels of formality (as alternatives or in combination) in the description, discovery (matchmaking) and composition of services.
•
Continued development of the ClubMe middleware prototype, both as a stand-alone system that can be deployed to create and manage clubs, as well as a component to existing marketplaces and services hosting and delivery sites.
7. REFERENCES [1] B. Benatallah, M. Dumas and Q. Sheng. Facilitating the Rapid Development and Scalable Orchestration of Composite Web Services. Distributed and Parallel Databases 17(1), 2005
[2] S. Dustdar and M. Treiber. VISCO – Vienna Service Communities. http://www.vitalab.tuwien.ac.at/projects/visco/ [3] R. Guerraoui, P. Felber, B. Garbinato and K. Mazouni. System Support for Object Groups. In Proceedings of the ACM Conference on Object-oriented Programming Systems, Languages and Applications (OOPSLA’98), 1998 [4] IBM Business Consulting Services. Pharma 2010: The threshold of innovation. February 2006. http://www1.ibm.com/services/us/index.wss/ibvstudy/imc/a1 001099 [5] R. Khalaf, A. Keller and F. Leymann. Business Processes for Web Services: Principles and Applications. IBM Systems Journal 45(2), 2006 [6] J. Sairamesh, R. Mohan, M. Kumar, L. Hasson, and C. Bender. A platform for business-to-business sell-side, private
exchanges and marketplaces. IBM Systems Journal 41(2), 2002 [7] J. Spohrer and D. Riecken. Services Science. Communications of the ACM 49(7), 2006 [8] S. Tai, R. Khalaf, and T. Mikalsen. Composition of Coordinated Web Services. In Proceedings of Middleware 2004, Springer LNCS 3231, 2004 [9] S. Weerawarana, F. Curbera, F. Leymann, T. Storey and D. Ferguson. Web Services Platform Architecture. PrenticeHall, 2005 [10] E. Wohlstadter, S. Tai, T. Mikalsen, J. Diament and I. Rouvellou. A Service-oriented Middleware for Runtime Web Services Interoperability. In Proceedings of the IEEE International Conference on Web Services (ICWS 2006), 2006
