| Throughout this chapter, we have been discussing Web services, and the respective technical underpinnings of Web services. The basic premise of this architecture is the creation of interoperable services and their respective applications. Readers are by now aware that Grid Computing is the process of resource sharing among a collection of participants : This involves interoperable access to sharable resources. The architectural evolution of Grid Computing selects Web services as the technology for defining these interoperable resources. The main criteria on this selection are the open protocol base and the interoperable messaging solutions, as proposed by the Web services architecture. We have already discussed the evolution of grid services and its adaptability to the emerging technologies. In the next section, we will explore the details on how grid services are defined around Web services architectures, and the standardization process of grid services. Given the previous discussion, we can now spend some time in exploring the relation between Web services and grid services, how we can differentiate each of them, and in what situations they share similarities. An application or service may have the ability to maintain a state, and that state may be pertaining to the user of that application. For example, a purchase order system keeps a user's order information between the interaction, the user , and the system (i.e., verify order, change order, update order, etc.), until the order is submitted for delivery. This state information (i.e., purchase order) may be local to the application or the service, or it may be stored in an external state machine(s) such as databases, other resources, local session state, and the resource/service object. It is noteworthy to understand how the above state is managed in Web service scenarios. Generally speaking, we can classify service state management into two forms. These two forms are as follows : -
Interaction aware state. Normally, in the world of the Web and Web services, a client may interact with a service for a long period of time, as we have discussed in the above purchase order case. These interactions are correlated using some information passed from the client to the service, along with the message. This can be a simple cookie, a session ID, or complex correlation information. The advantage of this architecture design point is that the server side is not managing any specific client state information, or creating a specific instance for a client. The server-side implementation is very scalable and stateless in nature. It is not preventing the real state being persisted in a state machine external to the application; instead, this is correlated to a specific client's state using the session ID. This is, typically, how normal Web and Web services are defined. -
Application aware state. In these situations, services are aware of its client and create a specific instance of the service for the specific client, and pass that instance information (e.g., primary key) back to the client for interaction. At this stage, the client is holding a reference to the specific instance of the service/application, and hence, can interact with the service instance without passing any correlation information. These services are typically referred to as stateful services, because the state information is held in the service itself and not passed back to the client. One important item to notice about this state management, similar to the above case, is that the service need not sustain the state; rather, the service may delegate the state to other state machines. The only requirement is that the client owns a reference to the service instance. Grid services are stateful Web services with a well-defined set of interfaces and behaviors for interaction. The following discussion explores the above concepts. Interaction Aware State Information This discussion addresses the previous introductory topic, interaction aware state information, which is related to state management. Figure 5.18 depicts these state machine scenarios we have just introduced, and subsequent discussions further examine this concept. Figure 5.18. Information aware stateless Web services.  Figure 5.18 depicts a client talking to a Web service named "A." In this scenario, the client is maintaining some session ID, and each time it interacts with the Web service, it passes that correlation information (e.g., purchase order key) to the service end point. This enables the runtime function to dispatch the calls to any Web service of the type "A." The service is then able to handle the request for the client, based upon the session ID passed along with the respective request. This is a very scalable approach. Application Aware State Information This discussion addresses the previous introductory topic, application aware state information, which is related to state management. Figure 5.19 depicts these state machine scenarios we have just introduced, and subsequent discussions further examine this concept. Figure 5.19. Application-based stateful Web services.  Stateful Web Services In this case, the service itself maintains some state information for the client. Hence, each client is provided a specific instance of a Web service to engage. This is analogous to the object-based system, whereby the object clients create an object instance of the type of object class, and then maintains a pointer to that instance, and subsequently interacts with that instance. Each object instance maintains its nonstatic state information in its memory location. Similarly, the Web service client maintains a reference to an instance of the service, and then communicates to that specific service instance. The instance holds the state of the client, and can make and execute the business decision based on that current state information. For example, the service instances maintaining a purchase order within a given instance. Grid Services This discussion provides information related to grid services, and the comparisons to stateful Web services. Figure 5.20 shows the OGSI interaction with the stateful Web services machine(s). Figure 5.20. Grid services.  Grid services are, in fact, stateful Web services. The service itself maintains some state information, and it exposes a set of standard interfaces to enable interactions with its client. These exposed interfaces enable the client to get/set the state information, in addition to the normal service behaviors. These exposed interfaces are defined in the OGSI specification. This specification provides mechanisms to: -
Service lifecycle management -
Instance state introspection and discovery -
Instance state change event notification In addition to the above behaviors, OGSI provides for a unique handle for the stateful Web service, called the grid service handle (GSH). Generally speaking, a grid service can be accessed through a grid service reference (GSR), which then forms the binding-level information to access a service instance. This interface-enabled access to a stateful Web service then provides interoperability at the message level. |
