![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Writing and maintaining a simple StockQuote service and other stateless Web services is a fairly trivial endeavor. Aside from the specific operations offered by the service (in this case getQuote()) the user of the service doesn't need to know or do anything else -- just invoke the operation and get back the result. But, when a Web service wants to maintain persistent data (for example, become a stateful Web service) things become a little more complex.
Exactly how persistent data is queried by a client can vary. For example, the StockQuote service uses the getQuote() method to return a piece of data, a reasonable solution for that scenario. However, what if the Web service had several pieces of data it wanted to expose -- there is no standard (or easy) way for the client to get the list of data that it can query, nor is there even a standard way of getting or setting the data. For example, for each piece of data the service can offer a getFoo() and a setFoo() method, but is it then getfoo(), get_foo(), getFOO(), or getFoo()? Something as trivial as the exact format of the operation name can cause some annoying headaches. To help with issues such as these, a standard was developed called Open Grid Service Infrastructure (see Resources for a download link to a pdf file). The Grid infrastructure provides a standard way for clients to query the list of data (Service Data Elements or SDEs) that a service is exposing as well as a standard way of querying and setting that data.
Of course in order for the Grid infrastructure to manage this data for you it must be made aware of it. Depending on the implementation of the Grid specification, how you go about doing this will vary -- this article will refer to the IBM Grid Toolbox, which is based on the OGSA (Open Grid Services Architecture) implementation, which comes with the Emerging Technologies Toolkit (ETTK) (see Resources for a download link). In this implementation the port type in the WSDL for the service is modified with additional tags denoting the data you want to be made available; for example, you might add the following:
<sd:serviceData name="CounterState"
type="counter-state:CounterStateType"
minOccurs="1"
maxOccurs="1"
mutability="mutable"
modifiable="false"
nillable="false">
<documentation>Counter State Complex Type</documentation>
</sd:serviceData>
|
This will tell the Grid infrastructure that a piece of data called CounterState, and of type CounterStateType, should be exposed to the client as an SDE. Once this is done, through the Grid client-side APIs, the client will be able to ask for the list of available Service Data Elements exposed by this service and then query each one's value or set it -- if that is allowed.
Once persistent data is introduced into the picture, other issues related to the management of that persistent data become very important, issues such as the following:
- How long that persistent data remains around
- How the user sees that persistent data
- Whether all users see the same instance or have their own instance of that data
- How the user can query the list of available instances if they are separate instances of this data (for each user).
The Grid infrastructure also provides a standard way for clients to manage this information -- in particular, it allows clients a way to create new instances of a service (which implicitly means new instances of the Service Data Elements because SDEs are associated with instance of services) and provides methods for managing and discovering those instances.
As an example, take one of the sample Web services found in the ETTK -- the AddressBook service. In that example, all users of the service will see the same set of addresses stored in it. If you converted the service into a Grid service, each user could create their own instance of the AddressBook service, thus allowing them to modify the names and addresses without effecting any other user's information. And, similar to SDEs, users can query the system to obtain the list of AddressBook instances that are available. Of course creating new instances of services could lead to storage issues. To help resolve this issue, the Grid provides a mechanism by which instances can optionally be given expiration times -- which gives the system an opportunity to destroy old instances of services automatically.
Another useful feature offered by the Grid infrastructure is a notification system. So, aside from being able to simply query the current value of a piece of data being managed and exposed as a Service Data Element, a client can request to be notified when one of those Service Data Elements is modified. This works by the client invoking the subscribe operation on the Grid service, telling it which data it is interested in and the location of the client's notification receiver. So when the interested data changes, the Grid infrastructure (on the server) will send a notification message to the client. This of course means that the client must be running a SOAP server itself in order to receive the message.
Aside from receiving notifications when Service Data Elements are modified, a client can also be notified when new instances of services themselves are created. This is done in a similar fashion -- subscribing to the Grid's registry itself. If you look at the Grid AddressBook sample in the ETTK you'll see how it uses this notification system to allow multiple clients accessing the same Addressbook to receive updates automatically as one of the clients modifies fields within the data. In Figure 1 is the interface this demo uses.
Figure 1. Interface used in the ETTK demo
You can see there are two panels, each representing a client accessing the Grid's repository of address books. By using the top panel, new address book instances can be created. Then each client (in the bottom left or right panels) can select which address book instance to view by selecting it from their respective drop-down boxes. If both clients have selected the same instance, then, as changes are made in one, they are automatically (and immediately) visible in the other client's pane.
In a nutshell, the Grid infrastructure offers Web service developers a standard way of exposing persistent data and instances of their Web services regardless of their specific implementation. Likewise, clients will be able to manage their data and Web services no matter what implementation or environment their service might be running in.
In previous articles in this series there was more focus given to using Web services from a developer's perspective. In particular, code snippets and a more detailed explanation of exactly how to code up your Web services was given. Grid services, unfortunately, are a little more complicated than traditional Web services and, as such, most people find that they must use the tooling provided with the OGSA implementation. However, even with the tooling the steps involved and the necessary code changes require more in-depth discussions than there is space for in this article. With that in mind, this article has stayed at a high-level, exposing you to the overall concepts the Grid in an attempt to pique your interest. For a more comprehensive discussion and detailed coding examples you should look at the Web Services Track in the Emerging Technologies Toolkit. In there you'll find quite a lot of material to aide in your development and understanding of the Grid.
- Read about the Open Grid Services Infrastructure (pdf).
- Read more about the Open Grid Services Architecture.
- Download the ETTK from alphaWorks.
- Read more about Grid on the Grid Computing Zone on developerWorks.
- Read previous articles in this series by Doug Davis:
- Developing using the ETTK, Part 1: Web service basics (developerWorks, May 2003).
- Developing using the ETTK, Part 2: Creating RPC and Message services (developerWorks, May 2003).
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
