The Grid for e-collaboration and Virtual Organisations J. VALLÉS 1, T. DIMITRAKOS2, S. WESNER3, B.. SERHAN3, P. RITROVATO4 1 Schlumberger, Diagonal 210, 4, Barcelona, 08018, Spain Tel: +34 93 486 18 18, Fax: + 34 93 486 07 66, Email:
[email protected] 2 Central Laboratory of the Research Councils, Rutherford Appleton Laboratory, UK, Email:
[email protected] 3 High Performance Computing Centre, University of Stuttgart, Stuttgart, Germany Email:{wesner,serhan}@hlrs.de 4Centro di Ricerca in Matematica Pura ed Applicata, Università di Salerno, Fisciano (SA), Italy Email:
[email protected] Abstract: In this paper the benefits of the integration of three emerging business concepts and enabling technologies: network enabled Application Service Provision, Grid computing, and Web Services are discussed. We introduce the concept of dynamic Virtual Corporations and discuss the resulting new possibilities for collaboration of entities across organisational boundaries. Finally we introduce the concept of Grid-based Application Service Provision (GRASP), which builds a new emerging technology and business paradigm on top of such integration. We conclude with a critical review of these concepts and technologies, highlighting the areas where further research and development is needed, and on indicating how their integration can support enterprises to create competitive advantages. 1. Introduction The objective of this paper is to illustrate the benefits of an emerging integration of concepts and models from Application Service Provision, Grid Computing and Web Services, as realised in the platform developed by the European project GRASP, emphasising its role in improving collaborative working in dynamic Virtual Organisations. The paper is organised as follows: Section 2 briefly outlines existing concepts underpinning the evolution of Application Service Provision. Section 3 outlines the technological basis supporting new ways of inter-enterprise collaborations. Section 4 focuses on dynamic Virtual Organisations as an enabler of new ways of collaborations. Section 5 reports our experience from analysing and exploiting the Virtual Organisation concept, and the associated enabling technologies, in order to support a new generation of ASP models that underlie the evolution from internet-enabled ASP to full-fledged Utility Computing. The paper concludes in section 6 by highlighting business benefits and experiences from advanced applied research. 2. Application Service Provision Concepts Application service provision (ASP) is a business model originally derived from the idea to sell software applications as automated services over the Internet or a private network, rather than as a product or a purely personal service. The availability of the Internet to everybody and the use of standardised interfaces and methods for accessing information and services enabled e-commerce in general and also opened the market for the ASP model. In [2],[3] two different types of ASPs are identified. The “traditional” ASP and the Internet
Business Service Provider (IBSP also referred to as the “network-centric” ASP). We examine each type in turn. 2.1 – Existing ASP models In the traditional ASP model Clients enjoy the benefit of offloading complex and expensive IT to the ASP while maintaining control and visibility of business processes. This can be understood as an evolution of outsourcing. However, performance, security, reliability and maintenance are still bound to constraints of solutions that have been originally designed for specialized in-house implementations. IBSPs can be understood as ASPs providing applications that are network-centric (e.g. being themselves a bundle of loosely coupled Internet-enabled services) and Internetenabled by design. In contrast to traditional ASPs, providing application services that are Internet-enabled by design IBSPs have the possibility to build in the necessary performance, security, and management controls and balances. Instead of adapting the source code of their applications in order to provide personalized services, IBSPs usually try to ensure that the applications are designed in a way that supports customization through changing the configuration of the application rather than the source code of its components. IBSPs therefore move closer to building their businesses on a utility model than traditional ASPs. 3. Service Orientation This section briefly summarizes the systems engineering concepts underpinning Service Orientation and their concrete realisation in the Web Service architecture [5][6], Grid Service Specification [7] and the Open Grid Service Architecture [9],[10]. 3.1 Elements of SOA Service oriented architectures (SOA) aim to provide the shared organizing principles that underpin the collaborative operation of services in open dynamic distributed systems. The focus is on how services are described and organized to support their dynamic, automated discovery and use at run-time and are not based on manually hardwired interactions, such as those used in EDI (Electronic Data Interchange) systems. Web Services can be seen as the realisation of the SOA architectural concept. The fundamental characteristics of SOA include: Service providers – publishing the availability of their services. Service brokers – registering and categorizing published services and providing search services. Service requesters – using broker services to find a needed service and then employing that service. Computer-accessible, hierarchical categories, or ontologies – based upon what the services in each category do and how they can be invoked. These taxonomies aim to assist the dynamic automated discovery of appropriate services. In order to enable the collaboration among entities within these main roles standardized network protocols and service descriptions are needed. Service descriptions are key to all three roles providing the information needed for an e-collaboration between the e-business services. In a service-oriented view, the interoperability problem can be broken down into two sub problems: the definition of service interfaces and the identification of the protocol(s) that can be used to invoke a particular interface.
3.2 Grid Service Architectures The explosion of Grid projects and applications worldwide has led to a diversity of approaches. Some Grid computing toolkits are widely used, but none of them has universal acceptance and their deployment often requires infilling of other domain specific services. A Grid client is therefore constrained to use the conventions of the service it requires. Even worse, when a client requires multiple services it may be faced with multiple conventions. Currently, Grid computing is finding its first applications in commerce and industry supporting distributed collaborative design and engineering, or distributed supply chains. In order to compensate for a proliferation of proprietary and heterogeneous Grid tools, that lack interoperability, the Global Grid Forum (www.ggf.org) has initiated a standardization initiative providing a common conceptual architecture (OGSA) [9] and a standardized interoperability framework (OGSI) [10] for Grid computing based around the Grid service [7]. A Grid service instance is a (potentially transient) service that conforms to a set of conventions (expressed as WSDL [8] interfaces, extensions, and behaviours) for supporting the basic functionalities that enable dynamically evolving Virtual Organisations (VO), such as on-demand creation of transient service instances, lifetime management, discovery of characteristics, notification, etc. Grid services enable the controlled management of the distributed and often long-lived state that is commonly required in sophisticated distributed applications. An OGSA compliant grid is a distributed component system that utilizes basic elements and patterns of a distributed system, like Service discovery – requires the ability of a service to describe itself. This is covered inside the mandatory GridService port type, which contains a FindServiceData function. Additionally a service can act as a registry if it implements the optional Registry port type. Dynamic Service creation – is a central element of OGSA. It is supported by the idea of factory services, which implement the optional Factory port type. A factory service is responsible for creating a new Grid Service instance and providing the client with a handle for accessing the service. Lifetime management – is a basic issue in distributed systems and is therefore addressed in the mandatory GridService port type. The basic idea is a Soft-State approach. This means that each service has a limited lifetime, therefore no distributed garbage collection is needed that tracks the necessity of services within the Grid and destroys them. An interested client may extend the lifetime if the policy of the service allows it. If the lifetime is expired, the service may terminate. Notification – is important because of the dynamic nature of the collaborating services. There are many scenarios imaginable, where a service creates another service and needs to be informed about specific events or changes in the state of the created service. Therefore a service can implement one or both of the optional NotificationSource and NotificationSink port types, which allow subscription for asynchronous message delivery. 3.3 The role of Web Services for OGSA The realisation of the concepts of OGSA can be naturally mapped on Web Services technology. The OGSI specification describes the services identified in the OGSA specification using Web Service Standards such as XML Schema and WSDL with only minor extensions. The Web Services framework offers already functionality as required in the OGSA specification for GridServices such as dynamic discovery and composition of services in heterogeneous environments and service description. Another important aspect is the already widespread use of Web Services allowing the use of established standards but also tools for development process.
4. Virtual Organisations as key for e-collaboration The Virtual Organisation as defined in [9] assumes that resources offered by the participants within this group can be shared. This section will first try to give a short motivating example from the engineering domain what could be reasons for building a VO. The second part will discuss the different lifecycle phases of such a VO and outlines the potential problems. 4.1 Virtual Organisations for solving complex problems in the engineering domain There are many areas right across the engineering product lifecycle where the implementation of VO-enabling mechanisms will be required. VOs could be formed to (among other things): • Prepare bids in response to customer offers-to-tender, • Perform requirements capture and preliminary design, • Produce detailed designs and proof-of-concepts, • Manage risk-sharing partners and prime-contractors, • Provide specific technical solutions in a given domain or problem area, • Assemble and manage the supply chain, • Co-ordinate product disposal. Of course the examples provided above will lead to different type of VOs as they differ in the specific aim, the number of partners, the lifetime and the complexity. However there are a number of issues in common. An engineering VO can be characterised as one that is: Objective driven – i.e. the construction and operation of the VO is defined by a specific aim (of course the aims can be different). Time limited – this may range from a few days or weeks (e.g. when bringing multienterprise teams together to solve a particular in-service problem) through to many years (e.g. when forming a VO to manage a 20-year service and support contract). Multi-enterprise – there will generally be a large number of partners with a huge variety of sizes, roles, requirements and capabilities. These partners will often be mutually involved in other parallel (and possibly competing) VOs. Dynamic – the VO will not be restricted to its original members, and partners may be required to join, leave and re-join at different times during the operation of the VO. Such VOs will not be owned by one legal entity but got constructed out of entities from different organisational domains. Within this VO it is supposed that the entities can exchange data, computational services, information and knowledge services. They will enable the collaboration of different types of participants with a much higher flexibility in a shorter time as it is possible so far. 4.2 The lifecycle of a Virtual Organisation A Virtual Organisation has four major phases. Identification – The capabilities of the services that are needed for a specific aim must be identified. These properties are the basis for a service discovery and the selection of services and also the organisations providing these services. Formation – Set up a relationship and enable the interoperation of the services provided by different organisations and also the clients. As typically not only basic services are needed but also complex workflows must be set up for achieving goals this step also includes the generation of workflow description and the establishment of orchestration services that perform these workflows during the operation phase. Operation – During this phase all collaborators within the VO can potentially at any time consume services in order to achieve the goal of the VO. The generated workflows get
executed and control mechanisms that ensure the availability and potential recovery mechanism are in place. Dissolution – This phase has the goal of cleaning up what has been done during the Formation phase and to dissolute the VO. An overview of this lifecycle emphasising tasks related to the management of secure collaborations in dynamic virtual organisations is provided in Figure 1. These major phases follow the decomposition of VOs to VO constituents targeting specific sub-goals associated, for example, with activities in an overall collaborative business process. The lifecycle template can dynamically adapt to such nested or iterative VO structures For example if during the Operation phase it emerges that more resources are needed to achieve the goal of the VO and the VO must be extended, the VO should either dissolute immediately or adapt by redistributing tasks among VO participants and/or introducing new members. Business Businessprocess processnullification nullification Disengagement Disengagementofofresources resources Maintenance Maintenanceofoftrust trustknowledge knowledge Nullification Nullificationofofcontracts contracts Posterior Posterioranalysis analysis
Collaborative Collaborativebusiness businessprocess processenactment enactment Autonomic Autonomicsecurity securitymanagement management Trust Trustmanagement management Policy Policyenforcement enforcement Contract Contractperformance performanceassessment assessment
Identification Identificationofofcollaboration collaborationobjectives objectives Discovery Discoveryofofcollaborators collaborators Policy Policyinspection inspection Trust Trustassessment assessment
Trust TrustEstablishment Establishment VO VOregistry registry Digital Digitalidentity identity&&location locationmanagement management Contract Contractnegotiation negotiationand andvalidation validation Collaborative CollaborativeBusiness BusinessProcess ProcessInitiation Initiation
Figure 1: An overview of a dynamic VO lifecycle, emphasising the core functionality supporting secure collaborative processing during the each phase of the life-cycle. 5. Grid Based Application Service Provision (GRASP) This section show how the interoperability capabilities of Grid Services, the concept of the Virtual Organisation enables new ways of collaboration between participants within an ASP scenario. An essential property of Application Service Provision in the classical definition is the “one-to-many model”, which is a generalization of the client-server interaction architectural model where the same application is offered to many customers. As we move from traditional ASP, through IBSP to Grid enabled ASP, we expect this classical model to give way to two new models. 5.1 The “federated” ASP model The “federated” model, which can be described as the collaboration of many (ASP) GridService providers that provide services that can be combined to complex services addressing a customer need that each of them could not achieve themselves. So in this model there
is a “virtual” ASP Provider potentially built from services offered from many different organisations. This model has potentially two new types of business models, the Grid Service Provider (GSP) and the Grid Enabler (GE). The Grid Service Provider differs from the traditional Application Service Provider as it is not offering Applications but Services. So a Grid Service Provider still provides service to many clients (following the classical model) however the services are from a different granularity and not necessarily consumed by the end client but also from other services. The Grid Enabler is offering services by for example orchestration of existing Grid Services building the glue for the collaboration between the services. Beside orchestration other services that covers multiple services including Accounting & Billing, Service Level Agreement Monitoring can be part of the business model of the Grid Enabler. A VO built from a set of Grid Service Providers and Grid Enablers that will be configured during the Formation phase show a completely different concept for ASP by moving from a single vendor model to a group of providers collaborating. 5.2 The “many-to-many” ASP model The “many-to-many” model, which is essentially an evolution of the classic “one-to-many” ASP model, achieved by evolving its foundation from the client-server to the serviceoriented paradigm: the entity can take the role of either a consumer or a service provider in the context of the same application depending on the required interactions. Furthermore, ASP users may count their material contribution to the provision of the overall application provision as a means of payment towards using that application. Similar to the “federated model” the provision of the ASP service is based on GSPs and GEs. The only difference that the role of the service consumer has been eliminated and a Grid Service Provider/Consumer replace the pure consuming client from the other models. 5.3 The GRASP project At present a few initiatives, such as the EU GRASP project (www.eu-grasp.net) are experimenting with the use of novel technology paradigms such as Grid computing in order to support the operation and evaluate the sustainability of these new models of ASP and thus contribute to the evolution from traditional ASP via IBSP to new paradigms. GRASP is an industry driven European research project, which is exploring the use of Grid Services paradigm as a means of providing a timely and effective technological basis supporting the evolution of the ASP market towards a sustainable Utility Computing model. To achieve this GRASP is developing an architectural framework for Grid-based Application Service Provision (GRASP), a prototype realization of this framework in a GRASP platform and “proof-of-concept” implementations of “federated” and “many-to-many” ASP models in multiple domains. From a business perspective, GRASP is a practical experiment, exploring the usefulness of the Grid / Global Computing paradigms as facilitators of Utility Computing (with special focus on the ASP market). From a technological perspective, GRASP is developing an architectural framework aiming to close the gap between the effective deployment of Grid infrastructures, Web Service based enabling technologies, and enterprise models for application service provision. Our intention is to improve enterprise application service provision models so as to be able to take full advantage of the flexibility offered by Web Services as a standardized means of integrating components of heterogeneous systems both within local, as well as wide area networks, and of the additional functionality and reliability offered by Grid Services for supporting dynamic resource allocation, life-time management of dynamic service instances, resources integration and efficient distributed computation. We expect that when
properly integrated within a business workflow this bundle can soften enterprise borders, giving way to new, more flexible ways of secure and reliable collaboration In order to support the ASP models outlined above the GRASP infrastructure must introduce additional services to the one proposed in OGSI specification. Orchestration – One of the most important aspects of the new ASP models is that no longer one single vendor controls the whole process. This means that a mechanism is needed that orchestrate the services offered by different vendors and ensure a controlled collaboration. The GRASP orchestration service will be based on BPEL4WS and provide the possibility for a hybrid orchestration for Grid Services but also for Web Services. SLA Monitoring – The Orchestrator can only fulfil its task in controlling the collaboration between the different services if enough information for the decision process is available. The SLA monitoring services monitor, enforce and provide notifications in order to assist the Orchestrator in this task. Accounting & Billing – Without Accounting & Billing no Application Service Provision can be performed. As the services are no longer controlled by one single entity but from many different service providers over time new ways on collecting provided services must be introduced. Especially for the “many-to-many” model new solutions must be identified. For a more detailed description of the GRASP architecture, including the above mentioned services, please refer to [11]. 6. Conclusions After giving a short introduction how ASP is performed as of today and what technological possibilities new service oriented architectures for Grid computing can offer the concept of a Virtual Organisation has been outlined. In section 5 two new collaboration based ASP models has been presented and how their realisation within GRASP is supported through additional type of services. However, in order for this vision of dynamic VO to become reality we need to develop further novel architectural frameworks that are complementary to the GRASP model. The most urging need, especially in relation to commercial uptake, is to secure VO collaborations and improve the way they are managed by the VO ecosystem. For our VO vision will only come about if enterprises and individuals are confident that the Virtual Organisations will deliver services 'as advertised', not only in terms of functionality but also in terms of confidentiality, privacy, quality of service, etc. This is particularly challenging when the services depend on multiple contributing providers, many of whom may not be known to the consumer of the overall service. It is also an issue when VOs accommodate commercial competitors. The VO participants may gain by sharing resources, information and knowledge within targeted collaborations that are technically enabled by VOs, while being concerned about protecting their main assets and reputation within such collaborations. Confidence that a partner will behave appropriately comes from a combination of trust and control measures that constrain that behaviour. Existing tools and techniques for contracting, trust and security management rely heavily on human intervention from system administrators and systems security officers using separate management applications in order to effect changes to the security configurations in response to security relevant events. In establishing dynamic virtual organisations ondemand, the scale, impact and frequency of configuration change increases dramatically and the variety of security mechanisms employed by the partners in the virtual organisation further impedes their deployment. Clearly, security management must become autonomic and adaptation must occur automatically, in real-time, rather than through human intervention. This will have to be complemented by extensible and machine processable standards for negotiating, validating and amending collaboration agreements, encoded by means of electronic contracts, which can be autonomically enacted by the platform.
For secure collaborations in dynamic VOs to become a reality, it is necessary to perform an integrated research and development effort towards producing the key missing technologies in order to support secure collaborative processes within dynamic VOs. This requires multidisciplinary research into complex, adaptive and self-organising systems in order to deliver a novel reference trust, policy and contract management framework that will enable secure collaborations within on-demand created and self-managed dynamic VOs built on top of the emerging convergence of Web Services, agent and Grid technologies. 7. Acknowledgements Many of the results and ideas presented in this paper emerged from research within the project Grid Based Application Service Provision (http://eu-grasp.net), from discussions in the context of the iTrust Thematic Network (http://www.itrust.uoc.gr), and during the preparation of the TrustCoM Integrate Project proposal aiming at the development of a trust and contract management framework for secure and dynamically evolving Virtual Organisations. 8. References [1] Falkowsky, Tanja (2002) Feasibility Study on the Use of the ASP Business Model for Enterprise Application Software. Diploma Thesis, Technical University Braunschweig. (http://groups.haas.berkeley.edu/fcsuit/PDFpapers/DiplomaThesis_TanjaFalkowski.pdf ) [2] Summit Strategies. Market Analysis Report, Traditional ISVs: Moving Along the Software-as-Services Curve. March 2002. [3] Summit Strategies. Market Analysis Report, Out of the Box: Top Nine Net-Native Software-as-Services Design Differentiators. June 2002. http://store.yahoo.net/summitresearchcenter/sofasser.html [4] Vijay Machiraju, Jerry Rolia, Aad van Moorsel, Quality of Business Driven Service Composition and Utility Computing, Software Technology Laboratory, HP Laboratories Palo Alto, HPL-2002-66, March 15th , 2002 [5] Web Services Architecture. W3C Working Draft. http://www.w3.org/TR/2002/WDws-arch-20021114/ [6] Security in a Web Services World: A Proposed Architecture and Roadmap. A Joint White Paper from IBM Corporation and Microsoft Corporation. April 7, 2002. V.1.0. http://www.verisign.com/wss/architectureRoadmap.pdf [7] S. Tuecke, K. Czajkowski, I. Foster, J. Frey, S. Graham, C. Kesselman; Grid Service Specification. Open Grid Service Infrastructure WG, Global Grid Forum [8] Web Services Description Language (WSDL) 1.1 www.w3.org/TR/wsdl.html [9] I. Foster, C. Kesselman, J. Nick, S. Tuecke, The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration. Open Grid Service Infrastructure WG, Global Grid Forum, June 22, 2002. (extended version of [6]) http://www.globus.org/research/papers/ogsa.pdf [10] I. Foster, C. Kesselman, J. Nick, S. Tuecke. Grid Services for Distributed System Integration. Computer, 35(6), 2002. http://www.gridforum.org/ogsiwg/drafts/GS_Spec_draft03_2002-07-17.pdf [11] Theo Dimitrakos, Damian Mac Randal, Fajin Yuan, Matteo Gaeta, Giuseppe Laria, Pierluigi Ritrovato, Bassem Serhan, Stefan Wesner, Konrad Wulf. An Emerging Architecture Enabling Grid-based Application Service Provision. In proceedings of the 6th IEEE International Enterprise Distributed Object Computing Conference (EDOC 2003). Brisbane Australia, September 2003. Published by IEEE Computer Society.
