| As shown in Figure 11.1, the GT3 architecture is a combination of: -
GT3 core -
Base services -
User -defined services Figure 11.1. The Globus GT3 core architecture.  The GT3 core forms the basic building blocks for grid services. This core consists of: -
OGSI reference implementation. Provides OGSI-defined interfaces, messages, and grid behaviors. This implementation enables interoperability with the Web service engine and hosting platforms. Tools provided with this implementation infrastructure assists us with grid services creation. -
Security infrastructure. Provides the basic grid security, including message and transport level protection, end-to-end mutual authentication, and authorization. This security framework is working in conjunction with the WS-Security specifications. -
System-level services. Includes logging services, administrative services, handle resolver services, routing services, and other important complimenting services. These services are built on the top of the OGSI reference implementation and security implementation. They provide system-level services available to other OGSI services for better manageability and customization. The higher-level base services are built on the top of the GT3 core. Some of the services provided by the GT3 base are information services, data management services, and job execution services. We are postponing this discussion until Chapter 14, which will focus on these topics. In Chapter 14, we also address each of these services available within the GT3 software bundle, the information model exposed by these services, and its usage patterns. User-defined services are application-level services that are created to exploit the OGSI reference implementations and security infrastructure. These services may in turn work with other high-level services to provide an improved collective behavior related to resource management. Some such services include meta schedulers , resource allocation managers, and collaborative monitoring services. This GT3 software introduces the notion of a grid service container, which forms an abstract notion of a runtime environment. This runtime environment provides capabilities for grid service persistence management, lifecycle management, and instance management. We call this container "abstract" because the real functionality implementation is likely to be using some existing hosting environment capabilities. For example, a service implemented as EJB may have a lifecycle managed by the J2EE EJB container. The current GT3 container is implemented on a J2SE/J2EE Web container. At the same time, we can create grid services EJBs by using the delegation service programming model defined by GT3. Note that the service lifecycle and management is still under the preview of the Web container. Yet another important component requires our continued attention. This is the Web service engine, which is (again) responsible for managing the XML messages from a grid service client to the service. The functionality includes message decoding, unmarshalling, type mapping, and dispatching calls to the service methods . The layered architecture enables OGSI reference implementations to utilize any Web service engine of choice. Even though we can be selective in our choice of Web service execution engines, the current GT3 implementation is not entirely flexible. The current GT3 relies on the Apache Axis Web service engine for some of its programming models (i.e., MessageElement and type mapping) and message flows (i.e., grid handlers). We can further explore the details of the implementation architecture model with the default software framework implemented in the Globus GT3 toolkit. We will begin our discussion with the server-side framework components . Default Server-Side Framework As shown in Figure 11.2, the major architecture components of the server-side framework are as follows : -
Web service engine provided by Apache AXIS framework. The GT3 software uses the Apache AXIS framework to deal with normal Web service behaviors such as SOAP message processing, JAX-RPC handler processing, and Web services configuration. -
Globus container framework. The GT3 software provides a container to manage the stateful Web service through a unique instance handle, instance repository, and lifecycle management that includes service activation/passivation and soft-state management. Figure 11.2. The current GT3 server-side reference implementation model.  Message Processing Details As already mentioned, GT3 utilizes Apache AXIS as their Web service engine, which executes in a J2EE/J2SE Web container, and provides a SOAP message listener (i.e., the AXIS Servlet). It is responsible for SOAP request/response serialization and deserialization, JAX-RPC handler invocation, and grid service configuration. As shown in Figure 11.2, the GT3 container provides a "pivot" handler to the AXIS framework in order to pass the request messages to the Globus container. The Globus GT3 container architecture is utilized to manage the stateful nature of Web services (readers must be aware that grid service instances are stateful Web services) and their lifecycle. Once a grid service instance is created by the service factory, a unique GSH is created for that instance by the framework. Note that the actual creation of a service depends on the service configuration properties, and the details are deferred to the programming model discussion in the next chapter. This instance is registered with the container repository. This container repository acts as a repository of all the stateful service instances. The other framework components and handlers contact the repository to invoke service methods, get/set service properties (e.g., instance GSH, GSR, etc.), activate/passivate service, resolve grid service handles to reference, and persist the service. Pivot Handlers Pivot handlers are responsible for creating Web service instance and invoking operations on the service. There are different types of handlers available based on the style (document/rpc) of the SOAP message. In GT3, we are using "wrapped"-style messaging, which is a special case of "document"-style messaging, where each parameter is bundled and treated separately. GT3 provides "RPCURIHandler" as a special case implementation of a "JavaProvider" of the AXIS framework. It handles wrapped messages and contacts the container repository, based on the service instance handle, to find the correct service and invoke the operations on it. |
Based on the above discussion, now we are familiar with the high-level default framework implementation that comes with GT3. Let us now explore the GT3 architecture components in detail, using the above server-side implementation model. Globus GT3 Architecture Details This section introduces the Globus GT3 architecture discussion. This architecture is an open -ended reference framework, with specific implementations worthy of review. Grid Service Container The Globus container model is derived from the J2EE-managed container model, where the components are free from complex resource manageability and runtime infrastructure usage. These complex management processes include transaction, concurrency, connectivity, persistence, lifecycle, and security management. In such a managed environment, the container is responsible for managing and controlling these attributes. This helps to achieve a basic QoS requirement for the components. In addition, the programming model becomes less complex to implement. The OGSI specification introduces and imposes a number of QoS requirements and behaviors on a grid service. The rendering of OGSI in a managed environment forces GT3 to reinvent a container model for grid services. In our previous discussions, we have explained these default implementation behaviors. The GT3 container is responsible for instance management, persistence, lifecycle management, and activation/ deactivation of grid services. It also provides a repository for service instance identity and management. In general, this container provides the following value-added features: -
Lightweight service introspection and discovery -
Dynamic deployment and soft-state management of stateful grid services -
Transport-independent, message-level security infrastructure supporting credential delegation, message signing, encryption, and authorization OGSI Reference Implementation The OGSI Reference implementation is a set of primitives implementing the standard OGSI interfaces, such as GridService, Factory, Notification (Source/Sink/Subscription), HandleResolver, and ServiceGroup (i.e., Entry/Registration). Among these, GT3 implementation provides the base implementation of GridService and Factory interfaces. This forms the basis of GT3 service implementation, container configuration, and the service invocation design pattern. These implementations can be extended to provide more behaviors. We will see the implementation and configuration details of these interfaces later in the next chapter. GT3 provides implementations for all other interfaces defined by the OGSI. However, these implementations are dependent on the service requirements. In complex scenarios, these implementations can be replaced with more sophisticated services pertaining to the service requirements. For example, the simple point-to-point notification framework provided by GT3 may not always be sufficient, and should be replaced by asynchronous JMS-based message queues. Security Infrastructure GT3 supports transport-level and message-level security. Another notable feature provided by GT3 is a declarative security mechanism for authentication and authorization using the service deployment descriptors. This provides an extended plug-and-play security architecture using the JAAS framework. Transport-Level Security This is based on the GSI security mechanism, as it exists today in GT2. To communicate over this secure transport layer we need to use a different invocation scheme other than http; this is called httpg . We have to be aware that the current transport-level security may be depreciated in favor of the message-level security introduced through the WS-Security architecture. Message-Level Security As we have seen in the previous section regarding WS-Security, the message-level security is implemented at the SOAP message level. We can see that there are two message-level security mechanisms: GSI Secure Conversation and GSI XML Signature. GSI Secure Conversation Let us further explore a few points, as illustrated in Figure 11.3. -
Initially the client establishes a security context with the service, utilizing a system-level service known as the "Secure Conversation Service." This security establishment is accomplished utilizing the Generic Security Services (GSS) API. -
Once the security context is established, the client will use this context to sign on, verify, encrypt, and decrypt the request/response messages. -
On subsequent calls, it passes the shared secret key along with the message. Figure 11.3. The establishment of a secure conversation.  GSI XML Signature The GSI XML signature is a simple XML message encryption mechanism, where the message is encrypted using the X.509 certificate capability. This provides additional flexibility, as any intermediary can validate the certificates and, hence, the message. We will discuss the details of the message, the transport-level security mechanisms, security programming, and the declarative security model for grid services in the next chapter. Security Directions The future security in GT3 will be aligned with the Global XML architecture standards on security. The WS-Security then becomes the default message-level security mechanism. The WS-Trust capability is used for security context creation, WS-SecureConversation for secure exchange of the aforementioned tokens. Figure 11.4 shows this architectural direction. Figure 11.4. Emerging security standards and its implementation with a grid service.  The plug-and-play nature of GT3 security enables us to create the above architectural model, with our choice of service/security provider options. In addition, the future security mechanisms must provide facilities for supporting WS-Federation, for federating across virtual organizations and trust domains. System-Level Services Some of the system-level services are introduced to provide a framework to achieve the required QoS in a production environment. These services must provide logging, management, and administrate provisions for a grid environment. The functions can be used as standalone facilities, or they can be used in concurrence with each other. Some of the existing GT3 system-level services are: -
Logging service. This enables dynamic modifications of logging filters for the current runtime environment, or this can be persisted for subsequent executions. In addition, this service enables the grouping of log message producers to adjust the size of backlogs and to provide customizable message views. -
Management service. This service provides a facility to monitor the current status and the load of a service container. It also provides functionalities to activate and deactivate service instances. -
Admin service. This service provides administrative activities, including pinging the hosting environment and shutting down the container. Hosting Environments The current GT3 code is developed in Java and supports the following types of hosting environments: -
Embedded utilities to be utilized with client and lightweight service deployments -
Standalone containers for service hosting -
Servlet-based environments, as we noted in Figure 11.2 -
EJB-based environments utilizing a delegation model to support existing EJB components, implemented as services Load Balancing Features in GT3 Generally speaking, a grid service is created in the same hosting environment where its factory is located. This is fine in most cases; however, there may be cases when the service needs to be created in a different hosting environment than the local hosting scenario. The reason may be many, including load balancing, user account restrictions, and backend resource requirements. In such situations, the factory needs to create a service in a hosting environment other than the local one, and the service calls must then be routed to the hosting environment where the service is operating. The local host now acts as a virtual hosting environment, but the client is unaware of this. The client performs the normal operations as usual and the GT3 framework handles the routing. This routing information is embedded with the SOAP header. Figure 11.5 illustrates such a virtual-hosting and load-balancing process. The most prominent example is the GT3 GRAM implementation. This environment provides a virtual-hosting environment for user account restrictions and load balancing. Figure 11.5. A virtual host and load balancing environment.  In the next chapter, regarding programming discussions, we will further explore the details of this load-balancing feature provided by the GT3 framework. Client-Side Framework GT3 does not dictate an architectural framework for grid service clients . The default implementation comes with a number of tools supporting Apache AXIS and the corresponding Java code generation. The framework follows the JAX-RPC programming model. The AXIS framework provides the runtime JAX-RPC engine for client-side message processing and dispatching. As shown in Figure 11.6 Globus GT3 uses the normal JAX-RPC client-side programming model and the AXIS client-side framework. Figure 11.6. GT3 software framework, focusing on aspects of the client-side architecture components.  In addition to the normal JAX-RPC programming model, Globus provides a number of helper classes at the client side in order to hide the details of the OGSI client-side programming model. We will further address these details in the next chapter on the programming model. Message Preprocessing Handlers Handlers provide the mechanism for processing raw SOAP messages. This is mainly utilized for handling SOAP headers that are implemented to communicate security, correlation, and transactional semantics about a message exchange. The GT3 architecture utilizes the JAX-RPC handlers and the AXIS handlers to accomplish this SOAP message-processing functionality. These handlers are applicable at both client- and server-side implementations. We will see further details of this in the following chapter. |
