- The physiology of the Grid. - 1 Globus Project and Globus Toolkit are trademarks of the University of Chicago.. - OGSA also defines interfaces for the discovery of Grid service instances and for the creation of tran- sient Grid service instances. - OGSA’s support for the discovery of service properties facilitates the mapping or adaptation of higher-level Grid service functions to such native platform facilities.. - We emphasize that the OGSA and associated Grid service specifications continue to evolve as a result of both standard work within the Global Grid Forum (GGF) and implementation work within the Globus Project and elsewhere. - Web services are programming language–, programming model–, and system software–neutral.. - SOAP is independent of the underlying transport protocol. - Then, we introduce the specific aspects that we standard- ize in our definition of what we call a Grid service. - In a service- oriented view, we can partition the interoperability problem into two subproblems, namely, the definition of service interfaces and the identification of the protocol(s) that can be used to invoke a particular interface – and, ideally, agreement on a standard set of such protocols.. - The service interface definition and access binding are also distinct from the imple- mentation of the functionality of the service. - Grid service discovery mechanisms are important in this regard, allowing higher-level services to discover what capabilities are supported by a particular implementation of an interface. - Finally, we note that an implementation of a particular Grid service interface may map to native, nondistributed platform functions and capabilities.. - 8.4.2 Service semantics: The Grid service. - To this end, OGSA defines what we call a Grid service: a Web service that provides a set of well- defined interfaces and that follows specific conventions. - Two other important issues, authentication and reliable invocation, are viewed as service protocol bindings and are thus external to the core Grid service definition but must be addressed within a complete OGSA implemen- tation. - The interfaces and conventions that define a Grid service are concerned, in particular, with behaviors related to the management of transient service instances. - A service’s description indicates the protocol binding(s) that can be used to communicate with the service. - The interfaces (in WSDL terms, portTypes) that define a Grid service are listed in Table 8.1, introduced here, and described in more detail in Section 8.6 (and in Reference [36. - a standard representation for service data, that is, information about Grid service instances, which we structure as a set of named and typed XML elements called service data elements , encapsulated in a standard container format;. - a standard operation, FindServiceData (within the required GridService interface), for retrieving service data from individual Grid service instances (‘pull’ mode access. - standard interfaces for registering information about Grid service instances with registry services (Registry) and for mapping from ‘handles’ to ‘references’ (HandleMap – to be explained in Section 8.6, when we discuss naming).. - Table 8.1 Proposed OGSA Grid service interfaces (see text for details). - GridService FindServiceData Query a variety of information about the Grid service instance, including basic introspection information (handle, reference, primary key, home handleMap:. - SetTerminationTime Set (and get) termination time for Grid service instance. - Destroy Terminate Grid service instance NotificationSource SubscribeTo-. - Registry RegisterService Conduct soft-state registration of Grid service handles UnregisterService Deregister a Grid service handle. - Factory CreateService Create a new Grid service instance. - HandleMap FindByHandle Return Grid Service Reference currently associated with supplied Grid service handle. - Dynamic service creation: The ability to dynamically create and manage new service instances is a basic tenet of the OGSA model and necessitates the existence of service creation services. - We address this requirement by defining two standard operations: Destroy and SetTerminationTime (within the required GridService interface), for explicit destruction and soft-state lifetime management of Grid service instances, respectively. - Other interfaces: We expect to define additional standard interfaces in the near future, to address issues such as authorization, policy management, concurrency control, and the monitoring and management of potentially large sets of Grid service instances.. - OGSA defines the semantics of a Grid service instance: how it is created, how it is named, how its lifetime is determined, how to communicate with it, and so on. - A particular hosting environment defines not only implementation programming model, programming language, development tools, and debugging tools but also how an implementation of a Grid service meets its obligations with respect to Grid service semantics.. - Grid semantics may be implemented directly as part of the service or provided via a linked library [39].. - In the OGSA context, the container (hosting environment) has primary responsibility for ensuring that the services it supports adhere to Grid service semantics, and thus OGSA may motivate modifications or additions to the container/component interface.. - However, we can expect a hosting environment to address mapping of Grid- wide names (i.e., Grid service handles) into implementation-specific entities (C pointers, Java object references, etc. - lifetime management of Grid service instances;. - The OGSA Factory, Registry, GridService, and HandleMap interfaces support the creation of transient service instances and the discovery and characterization of the service instances associated with a VO. - (In effect, a registry service – a service instance that supports the Registry interface for registration and the GridService interface’s FindServiceData operation, with appropriate service data, for discovery – defines the service set associated with a VO.) These interfaces can be used to construct a variety of VO service structures, as illustrated in Figure 8.2 and described in the following text.. - When a factory receives a client request to create a Grid service instance, the factory invokes hosting-environment-specific capabilities to create the new instance, assigns it a handle, registers the instance with the registry, and makes the handle available to the handleMap service. - These three examples, and the preceding discussion, illustrate how Grid service mech- anisms can be used to integrate distributed resources both across virtual multiorgani- zational boundaries and within internal commercial IT infrastructures. - We illustrate in Figure 8.3 the following stages in the life of a data-mining computa- tion, which we use to illustrate the working of basic remote service invocation, lifetime management, and notification functions.. - The user application invokes ‘create Grid service’ requests on the two factories in the second hosting environment, requesting the creation of a ‘data-mining service’ that will perform the data-mining operation on its behalf, and an allocation of temporary storage for use by that computation. - Each request involves mutual authentication of the user and the relevant factory (using an authentication mechanism described in the factory’s service description) followed by authorization of the request. - Each request is successful and results in the creation of a Grid service instance with some initial lifetime. - ‘keepalive’ requests to the two Grid service instances that it has created.. - Because of the application failure, keepalive messages cease, and so the two Grid service instances eventually time out and are terminated, freeing the storage and com- puting resources that they were consuming (not shown in figure).. - We now present a more detailed description of the Grid service abstraction and associated interfaces and conventions.. - More specifically, OGSA represents everything as a Grid service: a Web service that conforms to a set of conventions and supports standard interfaces for such purposes as lifetime management. - A Grid service implements one or more interfaces, where each interface defines a set of operations that are invoked by exchanging a defined sequence of messages. - Grid service interfaces correspond to portTypes in WSDL. - The set of portTypes supported by a Grid service, along with some additional information relating to versioning, are specified in the Grid service’s serviceType, a WSDL extensibility element defined by OGSA.. - Grid services can maintain internal state for the lifetime of the service. - We use the term Grid service instance to refer to a particular instantiation of a Grid service.. - Thus, every Grid service instance is assigned a globally unique name, the Grid service handle ( GSH. - that distinguishes a specific Grid service instance from all other Grid service instances that have existed, exist now, or will exist in the future. - (If a Grid service fails and is restarted in such a way as to preserve its state, then it is essentially the same instance, and the same GSH can be used.) Grid services may be upgraded during their lifetime, for example, to support new protocol versions or to add alternative protocols. - Instead, this information is encapsulated, along with all other instance-specific information required to interact with a specific service instance, into a single abstraction called a Grid service reference (GSR). - Unlike a GSH, which is invariant, the GSR(s) for a Grid service instance can change over that service’s lifetime. - Note that holding a valid GSR does not guarantee access to a Grid service instance: local policy or access control constraints (e.g., maximum number of current requests) may prohibit servicing a request. - In addition, the referenced Grid service instance may have failed, preventing the use of the GSR.. - Defining a specific set of services would result in a specific rendering of the OGSA service model.. - Table 8.1 presents names and descriptions for the Grid service interfaces defined to date. - OGSA defines a class of Grid services that implement an interface that creates new Grid service instances. - The Factory interface’s CreateService operation creates a requested Grid service and returns the GSH and initial GSR for the new service instance.. - OGSA addresses this problem through a soft-state approach [21, 40] in which Grid service instances are created with a specified lifetime. - The initial lifetime can be extended by a specified time period by explicit request of the client or another Grid service acting on the client’s behalf (subject of course to the policy of the service). - Our approach to Grid service lifetime management has two desirable properties:. - A client knows, or can determine, when a Grid service instance will terminate. - Negotiating an initial lifetime: When requesting the creation of a new Grid service instance through a factory, a client indicates minimum and maximum acceptable initial lifetimes. - Requesting a lifetime extension: A client requests a lifetime extension via a SetTermina- tionTime message to the Grid service instance, which specifies a minimum and maximum acceptable new lifetime. - The use of absolute time in the SetTerminationTime operation – and, for that matter, in Grid service information elements, and commonly in security credentials – implies the existence of a global clock that is sufficiently well synchronized. - While the GSH is guaranteed to reference the created Grid service instance in perpetuity, the GSR is created with a finite lifetime and may change during the service’s lifetime. - While this strategy has the advantage of increased flexibility from the perspective of the Grid service provider, it introduces the problem of obtaining a valid GSR once the GSR returned by the service creation operation expires. - At its core, this is a bootstrapping problem: how does one establish communication with a Grid service given only its GSH? We describe here how these issues are addressed in the Grid service specification as of June 2002, but note that this part of the specification is likely to evolve in the future, at a minimum to support multiple handle representations and handle mapping services.. - An implementation of the HandleMap interface may wish to keep track of what Grid service instances are actually in existence and not return references to instances that it knows have terminated. - However, possession of a valid GSR does not assure that a Grid service instance can be contacted: the service may have failed or been explicitly termi- nated between the time the GSR was given out and the time that it was used. - To ensure that we can always map a GSH to a GSR, we require that every Grid service instance be registered with at least one handleMap, which we call the home handleMap. - Current work within GGF is revising this Grid service component to allow for other forms of handles and mappers/resolvers and/or to simplify the current handle and resolver.. - Associated with each Grid service instance is a set of service data, a collection of XML elements encapsulated as service data elements. - The packaging of each element 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.. - query language and is extensible to allow for the specification of the query language used, which may be, for example, Xquery [41].. - The Grid service specification defines for each Grid service interface a set of zero or more service data elements that must be supported by any Grid service instance that supports that interface. - Associated with the GridService interface, and thus obligatory for any Grid service instance, is a set of elements containing basic information about a Grid service instance, such as its GSH, GSR, primary key, and home handleMap.. - One application of the GridService interface’s FindServiceData operation is service discovery. - A Grid service that supports service discovery is called a registry. - We note that specification of the attributes associated with a GSH is not tied to the registration of a GSH to a service implementing the GridService interface. - Notification semantics are a property of the protocol binding used to deliver the message. - In order to support discovery and change management of Grid services, Grid service interfaces must be globally and uniquely named. - Such operations allow potentially large sets of Grid service instances to be monitored and managed from management consoles, automa- tion tools, and the like. - GSR format : Recall that the Grid Service Reference can take a binding-specific format.. - The successful deployment of large-scale interoperable OGSA implementations would benefit from the definition of a small number of standard protocol bindings for Grid service. - the capabilities of the current protocols and arrive at a common service infrastructure.. - OGSA can be viewed as a distributed object system [43], in the sense that each Grid service instance has a unique identity with respect to the other instances in the system, and each instance can be characterized as state coupled with behavior published through type-specific operations. - Grid service implementations can target native platform facilities for integration with, and of, existing IT infrastructures. - (2001) The anatomy of the grid: Enabling scalable vir- tual organizations. - (1992) Communications of the ACM . - Communications of the ACM . - (2001) An Overview of the Web Services Inspection Language, www.ibm.com/developerworks/webservices/library/ws-wsilover.. - (1994) An overview of the spring system
Xem thử không khả dụng, vui lòng xem tại trang nguồn hoặc xem
Tóm tắt