The Open Grid Services Architecture:

Transcription

1 The Open Grid Services Architecture: Where the Grid Meets the Web Domenico Talia University of Calabria The Internet is still used primarily for person-to-person communications, with computers storing and delivering information that is meaningful only to humans. Emerging Web services provide a framework for application-toapplication interaction that grants access to business-to-business, e-science, and e-government services over the Internet. These services will allow a more extensive use of the Web s functionality by supporting automated processes involving machine-to-machine cooperation and interaction. In the meantime, a significant network infrastructure for exchanging programs and computing services as well as data is emerging. This infrastructure the Grid supports the creation of integrated computing environments in which distributed organizations can share data, programs, and computing nodes to implement decentralized services in science and business. In short, we can consider the Web an information Grid and the Grid an extended Web that goes beyond information sharing to allow users to share computer resources. Just as the Web grew from an infrastructure for scientific collaboration to a major communication medium for e-business, the Grid might find its main arena in commercial distributed applications (business-to-business, e-commerce, enterprise computing, and so on). Recently, the Globus Project and IBM initiated a development effort to align Grid technologies with Web services technologies, using the Open Grid Services Architecture. OGSA enables the integration of services and resources across distributed, heterogeneous, dynamic environments and communities. To achieve this integration, the OGSA model adopts the Web Services Description Language (WSDL) and defines the Grid service concept. Grid Computing A Grid is a geographically distributed computation platform composed of a set of heterogeneous machines that users can access via a single interface. Grids therefore provide common resource-access technology and operational services across widely distributed virtual organizations composed of institutions or individuals that share resources. Grid computing differs from conventional distributed computing in that it focuses on large-scale resource sharing, offers innovative applications, and, in some cases, is geared toward high-performance systems. Although originally intended for advanced science and engineering applications, Grid computing has emerged as a paradigm for coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organizations in industry and business. Thus, today Grids can be used as effective infrastructures for distributed high-performance computing and data processing. Grid applications include intensive simulations on remote supercomputers, cooperative visualization of very large scientific data sets, distributed processing for computationally demanding data analyses, and coupling of scientific instruments with remote computers and data archives. IEEE INTERNET COMPUTING /02/$ IEEE NOVEMBER DECEMBER

2 OGSA Resources Global Grid Forum Globus Project Grid Computing: Making the Global Infrastructure a Reality www. grid2002.org Grid Web Services 2002 Workshop workshops/gce/webservmay02 OGSA news, articles, definition, and status Open Grid Service Infrastructure working group org/ogsi-wg Physiology of the Grid In the past five years, toolkits and software environments for implementing Grid applications have become available. These include Legion (legion. virginia.edu), Condor ( condor), and Unicore ( In particular, Foster and Kesselman s Globus Toolkit ( toolkit) is the most widely used middleware in scientific and data-intensive Grid applications, and is becoming a de facto standard for implementing Grid systems. The toolkit addresses security, informationdiscovery, resource- and data-management, communication, fault-detection, and portability issues. It does so through mechanisms, composed as bags of services, that execute operations in Grid applications. Today, Globus and the other Grid tools are used in many projects worldwide. Although most of these projects are in scientific and technical computing, the growing number of Grid projects in education, industry, and commerce necessitates a convergence of requirements and technologies in those heterogeneous application areas. This shift in application areas has seen a parallel shift toward open-standard services, which distributed organizations can compose in various ways. The Globus research team is driving this effort with its contributions to OGSA definition and by evolving this toolkit toward the OGSA model. At the fourth Global Grid Forum (GGF) meeting in February 2002, the Globus team and IBM proposed a first OGSA specification (see the sidebar, OGSA Resources ). Currently, the GGF is coordinating a worldwide effort for a complete OGSA specification. Toward an Open Framework Several Grid-based middleware and applications, such as grid portals, search engines, data grids, and authorization services, have recently begun to provide services on the Grid infrastructure. The services are separate and not interoperable. The need for integration and interoperability among the increasing number of applications is driving Grid technologies toward an open Grid architecture offering an extensible set of services that virtual organizations can aggregate in various ways. To achieve this goal, OGSA defines the Grid service concept, based on principles and technologies from both the Grid computing and Web services communities. Web services describe the software components to be accessed, methods for accessing the components, and discovery methods that let users and applications identify relevant service providers (for details, see Curbera and colleagues 1 ). Web services are independent of programming languages and system software. The W3C and other standards bodies are defining Web services standards, which form the basis for major new industry initiatives such as Sun s One, Microsoft s.net, and IBM s Dynamic e-business. The OGSA model adopts three Web services standards: Simple object access protocol (SOAP, WSDL ( and Web Services Inspection Language (WSInspection, www-106.ibm.com/developerworks/ webservices/library/ws-wsilspec.html). Web services and OGSA aim to enable interoperability between loosely coupled services independent of implementation, location, or platform. OGSA defines standard mechanisms for creating, naming, and discovering persistent and transient Grid service instances; provides location transparency and multiple protocol bindings for service instances; and supports integration with underlying native platform facilities. To do this, OGSA defines a set of WSDL extensions, using extensibility elements allowed by WSDL, and conventions on the use of Web services for Grid computing. The OGSA effort aims to define a common resource model that is an abstract representation of both real resources, such as processors, processes, disks, and file systems, and logical resources. It provides some common operations and supports multiple underlying resource models representing resources as service instances. 2 In OGSA, all services adhere to specified Grid service interfaces and behaviors defined in terms of WSDL interfaces and conventions and mechanisms for creating and composing sophisticated distributed systems. Service bindings can support reliable invocation, authentication, authorization, and delegation. To this end, OGSA defines a Grid service as a Web service that provides a set of welldefined interfaces and follows specific conventions. The interfaces address 68 NOVEMBER DECEMBER IEEE INTERNET COMPUTING

3 discovery, dynamic service creation, lifetime management, notification, and manageability. The conventions address naming and upgrade ability. Conventions allow Grid users to determine when a service changes and when those changes are backwardly compatible with respect to interface and semantics, but not necessarily to network protocol. OGSA also defines mechanisms for refreshing a client s knowledge of a service, including operations it supports and network protocols the client can use to communicate with the service. Grid services also address authorization and concurrency control. This core set of consistent interfaces, which can be used to implement all Grid services, facilitates the construction of hierarchical, higher-order services that can be treated uniformly across layers of abstraction. Unlike Web services, which address persistent service discovery and invocation, the OGSA model also supports transient service instances created and destroyed dynamically. Thus, a Grid service is a potentially transient Web service based on grid protocols expressed using WSDL. A transient service instance might be a query against a data warehouse, a network resource allocation, an advance reservation for processing capability, or a forum discussion session. OGSA Services Grid services are characterized by the capabilities they offer. A Grid service implements one or more interfaces that correspond to WSDL porttypes. Each Grid service interface defines a set of operations that are invoked by exchanging a specified sequence of messages. The set of porttypes supported by a Grid service, along with some additional versioning information, are specified in the Grid service s servicetype, a WSDL extensibility element defined by OGSA to support port- Types collections. The related serviceimplementation element represents a particular implementation semantic of a servicetype. Grid service semantics can be inferred through the names assigned to the porttype, servicetype, and serviceimplementation elements. In fact, a Grid service definition includes some uniquely named porttypes grouped under a servicetype name and, after implementation, the assigned serviceimplementation name. To date, developers have proposed several Open Grid Services Architecture WSDL porttypes in Grid Services Grid service operations are defined by their associated Grid service interface, which corresponds to a Web Service Description Language (WSDL) porttype. Each porttype relates to one or more operations, which a client can invoke by exchanging a specified sequence of messages with the service instance.the following OGSA interfaces/wsdl porttypes have been proposed thus far. GridService, which defines three operations.findservicedata queries information sources about the Grid service instance, seeking basic introspection information (handle, reference, primary key, home handlemap), richer per-interface information, and service-specific information.this operation provides extensible support for various query languages. SetTerminationTime sets (and gets) termination time for a Grid service instance. Destroy terminates the Grid service instance. Factory with the operation CreateService, which creates a new Grid service instance. HandleResolver with the operation FindByHandle, which returns the Grid service reference (GSR) currently associated with the supplied Grid service handle (GSH). Registration, which defines two operations. RegisterService conducts soft-state registration of GSHs; and UnregisterService deregisters a GSH. NotificationSource with the operation SubscribeToNotificationTopic, which subscribes to service-related event notifications, based on message type and interest statement. The operation allows for delivery via third-party messaging services. NotificationSink with the operation DeliverNotification, which performs asynchronous delivery of notification messages. Standard interfaces for authorization, policy management, concurrency control, and the monitoring and management of potentially large sets of Grid service instances will be defined in the near future. OGSA interfaces/wsdl porttypes, described in the sidebar, WSDL porttypes in Grid Services. Service Instance Semantics OGSA defines the semantics of a Grid service instance how it is created, how it is named, how its lifetime is determined, and so on. Although OGSA is prescriptive on matters of basic behavior, it does not regulate a service s configuration and deployment on the grid infrastructure. In other words, OGSA does not address implementation programming paradigms, specific languages, implementation mechanisms and tools, or operative environments. This lets the Grid services model abstract for software and hardware details offering a set of high-level standard interfaces. A Grid service must implement the GridService porttype because it serves as the base interface IEEE INTERNET COMPUTING NOVEMBER DECEMBER

4 OGSA and Web Services A Grid service is a potentially transient Web service with specified interfaces and behaviors. A Grid service interface is a WSDL porttype. A Grid service definition is a WSDL extension (servicetype) containing a set of porttypes and servicetype compatibility statements to support interface upgrade and implementation information. A Grid service handle (GSH) is a globally unique URL. A Grid service reference (GSR) is a WSDL document with extensions. OGSA registry returns WS-inspection documents. The Globus Toolkit 3.0 is the first prototype implementation of the specifications of OGSA. definition in OGSA. It is analogous to the root Object class in object-oriented languages, in that it encapsulates the component model s root behavior. The GridService operation FindServiceData, which queries and retrieves service data, requires a simple by name query language, and is extensible to allow for the specification of the query language used (for example, Xquery). The GridService porttype provides documentcentric and remote procedure call (RPC) messaging approaches. In document-centric messaging, both input and output are XML documents, while the RPC approach uses more strictly defined APIs, but offers better performance. Grid Service Handles OGSA services can be dynamically created by the CreateService Factory operation or created manually, and destroyed, via soft state when the client time-out expires or explicitly by the Destroy operation. The CreateService operation returns a Grid service handle (GSH), which is a globally unique URL that names the service instance and distinguishes it from all other Grid instances. The GSH format is <GSHomeHandleMapID>/ <GSInstanceID>, where <GSHomeHandleMapID> is <scheme>://<hostname>[:port]/<path> and <GSInstanceID> is a single-path component. The GSH does not carry enough information for a client to communicate directly with the service instance. Thus a GSH must be mapped (using the HandleResolver) to a Grid service reference (GSR) that contains the information a client needs to communicate with the service through one or more protocol bindings. A GSH is valid for the lifetime of the Grid service instance, while a GSR might become invalid. If this occurs, the client must map the service s GSH to a new GSR. The GSR format is specific to the binding mechanism used by the client to communicate with the Grid service instance. For example, if the client uses a SOAP binding, the GSR assumes an annotated WSDL document format. A registry is a Grid service that supports service discovery by maintaining collections of GSHs and their associated policies. Clients can query a registry to discover services availability, properties, and policies. Two elements define a registry service: the Registration interface, which allows a service instance to register the GSH with the service, and an associated service data element that contains information about registered GSHs. A registry implements a Registration porttype that lets clients register (RegisterService) and unregister (UnRegisterService) registry contents. Clients can use the FindServiceData operation to retrieve information about registered GSHs. Notification Model OGSA s notification component delivers interesting messages from a source to a notification sink. A notification source is a Grid service instance that implements the NotificationSource porttype and sends a notification message. A notification sink is a Grid service instance that implements the NotificationSink porttype and receives a notification message. To start notification from a particular Grid service, a user invokes the subscribe operation on the notification source interface, giving it the service GSH of the notification sink. A stream of notification messages then flows from the source to the sink, while the sink sends periodic keepalive messages to notify the source that it is still interested in receiving notifications. To ensure reliable delivery, a user can implement this behavior by defining an appropriate protocol binding for the service. A significant aspect of the OGSA notification model is a close integration with service data: A subscription operation is simply a request for subsequent delivery of service data that meet specified conditions. In fact, associated with each Grid service instance is a set of service data, which is a collection of XML elements encapsulated as servicedata elements. Each element s packaging includes a name that is unique to the Grid service instance, a type, and time-to-live information that a recipient can use for lifetime management. For example, a declaration of servicedata in a port- Type that defines a CPU interface appears as: 70 NOVEMBER DECEMBER IEEE INTERNET COMPUTING

5 Open Grid Services Architecture <porttype name= CPU > <gsdl:servicedata name= tns:cpuspeed /> <gsdl:servicedata name= tns:cpuload > <xsd:float>0.00</xsd:float> </gsdl:servicedata> </porttype> Two servicedata are included: CPUspeed and CPUload. The definition for the CPULoad servicedata element contains the initial service data value element. Service data include both metadata information about the service instance s structure and state data the service instance s properties. There are two ways to associate service data with a service instance. First, a service description can contain structural service data elements (SDEs) as part of its service description. Second, each instance maintains a collection of its own instance-specific SDEs, or instance SDEs, that can include additional dynamic or static SDEs. Clients use the FindServiceData operation to query this collection of instance SDEs. OGSA Implementation The research and industry communities, under the guidance of the GGF, have contributed to the design and extension of OGSA. In addition to the definition process, the GGF and other OGSA contributors are developing an implementation process. Because OGSA can operate independently on any software base, implementations can stem from current Grid systems, such as Globus, Legion, and Unicore, as well as from new environments stimulated by OGSA s openness. The Globus team is currently developing version 3 of the Globus Toolkit (GT3), which is an OGSA-based opensource implementation of the interfaces and behaviors defined by the Grid service specification. The GT3 architecture includes the GT3 core, which implements the Grid service interfaces and behaviors as defined in the OGSA specification; GT3 base services, which exploit the GT3 core to implement both existing Globus Toolkit capabilities (for example, resource management, data transfer, and information services) and new capabilities (such as reservation and monitoring); GT3 collective services, which implement data Grid services (reliable file transfer and replica location, for example) and a set of higher-level services that can target both GT3 core and GT3 base services (data management, workload management, diagnostics, and so on). The Globus team has demonstrated a first implementation of the GT3 core and expects a full public release of a Java-based GT3 at the end of Unicore has recently implemented a Grid service demonstrator built around its Grid environment. The Grid Interoperability Project ( -interoperability.org) framework will explore the interoperability between this demonstrator and the early GT3 release. Other Grid environments will likely evolve toward OGSA specifications, increasing the variety of solutions Grid users can use in their applications. The OGSA model will provide an effective open framework for developing grid portals. Moreover, the Grid service ports offer the Grid programmer high-level programming mechanisms that can improve both the design effort and the quality of the constructed applications. Looking Ahead The development of OGSA represents a natural evolution of Web services. By integrating support for transient, stateful service instances with existing Web services technologies, OGSA significantly extends the power of the Web services framework, while requiring only minor extensions to existing technologies. Recently, companies such as IBM, Sun, Microsoft, Avaki, and others have expressed support for OGSA. In the near future, an OGSA approach could fully integrate Grid and Web technologies. Combining these two distributed computing paradigms could improve both well-established and novel applications made possible by the support of the open Grid service model. References 1. F. Curbera et al., Unraveling the Web Services Web: An Introduction to SOAP, WSDL, and UDDI, IEEE Internet Computing, vol. 6, no. 2, Mar./Apr. 2002, pp I. Foster et al., Grid Services for Distributed System Integration, Computer, vol. 35, no. 6, June 2002, pp Domenico Talia is a professor of computer science at the University of Calabria, Rende, Italy. He is working on Grid computing, parallel data mining and knowledge discovery, and parallel programming languages. He is a member of the IEEE Computer Society and the ACM. Readers can contact him at talia@deis.unical.it. IEEE INTERNET COMPUTING NOVEMBER DECEMBER