1.1. OGSA, WSRF, and GT4

If you've started looking at GT4, you've probably encountered at least these two acronyms: OGSA and WSRF. But... what do they mean? How are they related to the Globus Toolkit 4? This section attempts to clarify these important concepts. First of all, let's start by taking a look at OGSA and WSRF without seeing just yet how they are related to GT4.

Figure 1.1. Relationship between OGSA, WSRF, and Web Services

Relationship between OGSA, WSRF, and Web Services


A grid application will usually consist of several different components. For example, a typical grid application could have:


If you have absolutely no idea of what I have just said (and feel slightly confused), remember that the tutorial assumes that you know what Grid Computing is. If you don't, please read the Prerequisites documents section to get up to speed.

Furthermore, all these services are interacting constantly. For example, the Job Management Service might consult the Resource Discovery Service to find computational resources that match the job's requirements. With so many services, and so many interactions between them, there exists the potential for chaos. What if every vendor out there decided to implement a Job Management Service in a completely different way, exposing not only different functionality but also different interfaces? It would be very difficult (or nearly impossible) to get all the different software pieces to work together.

The solution is standardization: define a common interface for each type of service. For example, take a look at the World Wide Web. One of the reasons why the Web is such a popular Internet application is because it is based on standards (HTML, HTTP, etc.) agreed upon by all the different major players (Microsoft, Netscape, etc.). Imagine, on the other hand, that you could only use a Microsoft browser to access websites implemented with Microsoft technology (ditto for Netscape, Opera, etc.) It would be definitely uncool. Thanks to standards, I can use my favorite browser (provided it follows standards, which most modern browsers do) to access most of the websites out there (regardless of what technology is used to implement the website). Why? Because a set of common languages was agreed upon for all the browsers and websites out there. Standardization is definitely a good thing.

The Open Grid Services Architecture (OGSA), developed by The Global Grid Forum, aims to define a common, standard, and open architecture for grid-based applications. The goal of OGSA is to standardize practically all the services one commonly finds in a grid application (job management services, resource management services, security services, etc.) by specifying a set of standard interfaces for these services. At the time of writing this tutorial, this "set of standard interfaces" is still in the works. However, OGSA already defines a set of requirements that must be met by these standard interfaces. In other words, OGSA has already gone as far as identifying the most important services one encounters in Grid applications, and which most stand to benefit from standardization.

OGSA requires 'stateful services'

However, when the powers-that-be undertook the task of creating this new architecture, they realized they needed to choose some sort of distributed middleware on which to base the architecture. In other words, if OGSA (for example) defines that the JobSubmissionInterface has a submitJob method, there has to be a common and standard way to invoke that method if we want the architecture to be adopted as an industry-wide standard. This base for the architecture could, in theory, be any distributed middleware (CORBA, RMI, or even traditional RPC). For reasons that will be explained further on, Web Services were chosen as the underlying technology.

However, although the Web Services Architecture was certainly the best option, it still didn't meet one of OGSA's most important requirements: the underlying middleware had to be stateful (don't worry if you don't know what a "stateful" service is, it is explained in the next section). Unfortunately, although Web services can in theory be either stateless or stateful, they are usually stateless and there is no standard way of making them stateful. So, clearly, something had to be done!


Enter the Web Services Resource Framework, a specification developed by OASIS. WSRF specifies how we can make our Web Services stateful, along with adding a lot of other cool features. It is important to note that WSRF is a joint effort by the Grid and Web Services communities, so it fits pretty nicely inside the whole Web Services Architecture (in the diagram: WSRF extends Web Services).

So what exactly is the relation between OGSA and WSRF? It's very simple: WSRF provides the stateful services that OGSA needs. In the diagram: WSRF specifies stateful services (as opposed to those services simply 'being required' by OGSA). Another way of expressing this relation is that, while OGSA is the architecture, WSRF is the infrastructure on which that architecture is built on.

How does this relate to GT4?

Now that we've cleared up what OGSA and WSRF are, we are ready to complete the above diagram to see how GT4 fits into the picture:

Figure 1.2. Relationship between OGSA, GT4, WSRF, and Web Services

Relationship between OGSA, GT4, WSRF, and Web Services

The Globus Toolkit 4

The Globus Toolkit is a software toolkit, developed by The Globus Alliance, which we can use to program grid-based applications. The toolkit, first and foremost, includes quite a few high-level services that we can use to build Grid applications. These services, in fact, meet most of the abstract requirements set forth in OGSA. In other words, the Globus Toolkit includes a resource monitoring and discovery service, a job submission infrastructure, a security infrastructure, and data management services (to name a few!). Since the working groups at GGF are still working on defining standard interfaces for these types of services, we can't say (at this point) that GT4 is an implementation of OGSA (although GT4 does implement some security specifications defined by GGF). However, it is a realization of the OGSA requirements and a sort of de facto standard for the Grid community while GGF works on standardizing all the different services.

Most of these services are implemented on top of WSRF (the toolkit also includes some services that are not implemented on top of WSRF and are called the non-WS components). The Globus Toolkit 4, in fact, includes a complete implementation of the WSRF specification. This part of the toolkit (the WSRF implementation) is a very important part of the toolkit since nearly everything else is built on top of it. However, it's worth noting that it's also a very small part of the toolkit. At this point, we'll repeat something we said at the very beginning of the tutorial:

At the end of this tutorial you will know how to program stateful Web Services using GT4. This will allow you to progress towards using the higher-level services of the toolkit. However it is important to understand that you cannot program Grid-based applications using only the Java WS Core included in this tutorial. This tutorial should be approached as a stepping stone towards more powerful tooling, not as a definite guide on GT4 programming.

I'm sorry to insist so much on this, but this really is a very important concept. Never forget that, on the long road towards true Grid Nirvana, WSRF is indeed a necessary step, but only the first step.

Finally, take into account that GT4 isn't the only WSRF implementation out there. For example, another complete implementation of the WSRF specification is WSRF.NET.

The mandatory layered diagram

If there's something we computer geeks like in documentation, it's layered diagrams! So, this section really wouldn't be complete without a diagram that explains the relationship between OGSA, WSRF, and GT4 using the wonderful language of layers.

Figure 1.3. Layered diagram of OGSA, GT4, WSRF, and Web Services

Layered diagram of OGSA, GT4, WSRF, and Web Services