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 finds in a grid application (job management services, resource management services, security services, etc.) by specifying a set of standard interfaces for these 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 JobSubmisionInterface 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 had several shortcomings which made it inadequate for OGSA's needs. OGSA overcame this obstacle by defining an extended type of Web Service called Grid Service (as shown in the diagram: Grid Services are defined by OGSA). A Grid Service is simply a Web Service with a lot of extensions that make it adequate for a grid-based application (and, in particular, for OGSA). In the diagram: Grid Services are an extension of Web Services. Finally, since Grid Services are going to be the distributed technology underlying OGSA, it is also correct to say that OGSA is based on Grid Services.

OGSA alone doesn't go into much detail when describing Grid Services. It basically outlines what a Grid Service should have (that Web Services don't) but little else. That is why OGSA spawned another standard called the Open Grid Services Infrastructure (OGSI, also developed by The Global Grid Forum) which gives a formal and technical specification of what a Grid Service is. In other words, for a high-level architectural view of what Grid Services are, and how they fit into the next generation of grid applications, OGSA is the place to go. For an excruciatingly detailed specification of how Grid Services work, OGSI is the place to go. In the diagram: Grid Services are specified by OGSI (as opposed to simply 'being defined' by OGSA). The Related Documents section has a link to the Grid Service Specification.

The Globus Toolkit is a software toolkit, developed by The Globus Alliance, which we can use to program grid-based applications. The third version of the toolkit (GT3) includes a complete implementation of OGSI (in the diagram GT3 implements OGSI). However, it's very important to understand that GT3 isn't only an OGSI implementation. It includes a whole lot of other services, programs, utilities, etc. Some of them are built on top of OGSI and are called the WS (Web Services) components, while other are not built on top of OGSI and are called the pre-WS components. We'll take a closer look at the GT3 architecture shortly.

Consider the following simple example. Suppose you want to build a new house. The first thing you need to do is to hire an architect to draw up the blueprints, so you can get an idea of what your house will look like. Once you're happy with the architect's job, it's time to hire an engineer who will plan all the construction details (where to put the master beams, the power cables, the plumbing, etc.). The engineer then passes all his plans to qualified professional workers (construction workers, electricians, plumbers, etc) who will actually build the house.

We could say that OGSA (the definition) is the blueprints the architect creates to show what the building looks like, OGSI (the specification) is the structural design that the engineer creates to support the architect's vision for the building, and GT3 is the bricks, cement, and beams used to build the building to the engineer's specifications.

So how does this all actually work? Let's take a look at all the steps involved in a complete Web Service invocation. For now, don't worry about all the acronyms (SOAP, WSDL, ...) We'll explain them in detail in just a moment.

We have just seen a simple Web Service invocation. At one point, the UDDI registry 'told' the client where the Web Service is located. But...how exactly are Web Services addressed? The answer is very simple: just like web pages. We use plain and simple URIs (Uniform Resource Identifiers). If you're more familiar with the term URL (Uniform Resource Locator), don't worry: URI and URL are practically the same thing.

For example, the UDDI registry might have replied with the following URI:

http://webservices.mysite.com/weather/us/WeatherService

This could easily be the address of a web page. However, remember that Web Services are always used by software (never directly by humans). If you typed a Web Service URI into your web browser, you would probably get an error message or some unintelligible code (some web servers will show you a nice graphical interface to the Web Service, but that isn't very common). When you have a Web Service URI, you will usually need to give that URI to a program. In fact, most of the client programs we will write will receive the Grid Service URI as a command-line argument.

Now that we've seen the different players in a Web Service invocation, let's take a closer look at the Web Services Architecture:

OK, now that you have an idea of what Web Services are, you are probably anxious to start programming Web Services right away. Before you do that, you might want to know how Web Services-based applications are structured. If you've ever programmed with CORBA or RMI, this structure will look pretty familiar.

First of all, you should know that despite having a lot of protocols and languages floating around, Web Services programmers usually never write a single line of SOAP or WSDL. Once we've reached a point where our client application needs to invoke a Web Service, we delegate that task on a piece of software called a client stub. The good news is that there are plenty of tools available that will generate client stubs automatically for us, usually based on the WSDL description of the Web Service.

Therefore, you shouldn't interpret the "Typical Invocation" diagram literally. A Web Services client doesn't usually do all those steps in a single invocation. A more correct sequence of events would be the following:

Programming the server side is just as easy. We don't have to write a complex server program which dynamically interprets SOAP requests and generates SOAP responses. We can simply implement all the functionality of our Web Service, and then generate a server stub (the term skeleton is also common) which will be in charge of interpreting requests and forwarding them to the service implementation. When the service implementation obtains a result, it will give it to the server stub, which will generate the appropriate SOAP response. The server stub can also be generated from a WSDL description, or from other interface definition languages (such as IDL). Furthermore, both the service implementation and the server stubs are managed by a piece of software called the Web Service container, which will make sure that incoming HTTP requests intended for a Web Service are directed to the server stub.

So, the steps involved in invoking a Web Service are described in the following diagrams.

Let's suppose that we've already located the Web Service, and generated the client stubs from the WSDL description. Furthermore, the server-side programmer will have generated the server stubs.

By the way, in case you're wondering, most of the Web Services Architecture is specified and standardized by the World Wide Web Consortium, the same organization responsible for XML, HTML, CSS, etc.

This first feature is probably one of the most important improvement with regard to Web Services. Let's see what this feature is all about by using a simple example. Imagine your organization has a really big cluster capable of performing the most mind-boggling calculations. However, this cluster is located in your central headquarters in Chicago, and you need employees from your offices in New York, Los Angeles, and Seattle to conveniently use the cluster's computational power. This looks like a perfect scenario for a Web Service!

We could implement a Math Web Service called MathService which offered operations such as SolveReallyBigSystem(), SolveFermatsLastTheorem(), etc. At first, we would be able to perform typical Web Service invocations:

So far, so good. However, let's be a bit more realistic. If you're going to access a remote cluster to perform complex mathematical operations, you probably won't perform a single operation, but rather a chain of operations, which will all be related to each other. However, Web Services are stateless. "Stateless" means that Web Services can't remember what you've done from one invocation to another. If we wanted to perform a chain of operations, we would have to get the result of one operation and send it as a parameter to the next operation.

Furthermore, even if we solved the stateless problem (some Web Services containers actually work around this problem), Web Services are still non-transient, which means that they outlive all their clients. Web Services are also referred to as persistent (as opposed to transient; this doesn't mean 'persistent' in the sense of 'persisting data to secondary storage, a hard drive, etc.') because their lifetime is bound to the Web Services container (a Web Service is available from the moment the server is started, and doesn't go down until the server is stopped) In any case, this implies that, after one client is done using a Web Service, all the information the Web Service is remembering could be accessed by the next clients. In fact, while one client is using the Web Service, another client could access the Web Service and potentially mess up the first client's operations. This certainly isn't a very elegant solution!

Grid Services solve both problems by allowing programmers to use a factory/instance approach to Web Services. Instead of having one big stateless MathService shared by all users, we could have a central MathService factory in charge of maintaining a bunch of MathService instances. When a client wants to invoke a MathService operation, it will talk to the instance, not to the factory. When a client needs a new instance to be created (or destroyed) it will talk to the factory.

This diagram shows how there doesn't necessarily have to be one instance per client. One instance could be shared by two clients, and one client could have access to two instances. These instances are transient, because they have a limited lifetime which isn't bound to the lifetime of the Grid Services' container. In other words, we can create and destroy instances at will whenever we need them (instead of having one persistent service permanently available). The actual lifecycle of an instance can vary from application to application. Usually, we'll want instances to live only as long as a client has any use for them. This way, every client has its own personal instance to work with. However, there are other scenarios where we might want an instance to be shared by several users, and to self-destruct after no clients have accessed it for a certain time.

Finally, notice how Grid Services are potentially transient. This means that not all Grid Services have to use (by definition) a factory/instance approach. A Grid Service can be persistent, just like a normal Web Service. Choosing between persistent Grid Services or factory/instance Grid Services depends entirely on the requirements of your application.

Since we are now dealing with services that have non-trivial lifecycles (if we use a factory/instance model, instances can be created and destroyed at any time), lifecycle management mechanisms are provided in Grid Services. OGSI itself only supplies some very basic mechanisms, which are complemented by additional mechanisms in GT3, as we'll see later on.

Service Data, along with statefulness and transience, ranks very high in the list of 'the best things Grid Services add to Web Services'. In fact, Service Data is my personal favorite extension!

Service Data allows us to easily include a set of structured data to any service, which can then be accessed directly through its interface. Since plain Web Services only allow operations to be included in the WSDL interface, you could think of Service Data as an extension that allows us to include not only operations in the WSDL interface, but also attributes. However, Service Data is much more than simple attributes, since we can easily include any type of data (fundamental types, classes, arrays, etc.)

In general, the Service Data we include in a service will fall into one of two categories:

If you're not too sure what service data is, don't worry: a much more detailed explanation will be given when we start coding Grid Services with service data.

A Grid Service can be configured to be a notification source, and certain clients to be notification sinks (or subscribers). This means that if a change occurs in the Grid Service, that change is notified to all the subscribers (not all changes are notified, only the ones the Grid Services programmer wants to). In the MathService example, suppose that all the clients perform certain calculations using a variable called InterestingCoefficient which is stored in the Grid Service. Any of the clients can modify that value to improve the overall calculation. However, all clients must be notified of that change when it occurs. We can achieve this easily with the Grid Services notifications.

Later on, we'll see that notifications in OGSI are very closely related to service data.

Any service can be configured to act as a service group which aggregates other services. We can easily perform operations such as 'add new service to group', 'remove this service from group', and (more importantly) 'find a service in the group that meets condition FOOBAR'. Although the service group functionality included in OGSI is pretty simple, it is nonetheless the base of more powerful directory services (such as GT3's IndexService) which allow us to group different services together and access them through a single point of entry (the service group).

In the previous page we saw that a Web Service exposes its interface (the operations it can perform) through a WSDL document. The interface is usually called portType (due to a WSDL tag of the same name). A normal Web Service can have only one portType. Grid Services, on the other hand, support portType extension, which means we can define a portType as an extension of a previously existing portType.

For example, the OGSI specification mandates that all Grid Services must extend from a standard portType called GridService:

Thanks to portType extension, we can simply define our own portType as an extension of GridService. With plain web services, we would need to include the declaration of all the operations (including the GridService operations) in a single portType.

Besides the standard GridService portType, OGSI defines a lot of other standard portTypes we can extend from to add functionality to our grid service. For example, there is a NotificationSource portType which we can extend from if we want our service to act as a notification source (we'll take a close look at this portType and other standard portTypes when we start working with code). Notice how NotificationSource itself extends from GridService:

In general, we'll find that grid services can have three types of portTypes:

In the previous page we saw that Web Services are addressed with URIs. Since Grid Service are Web Services, they are also addressed with URIs. However, OGSI introduces a more powerful addressing scheme.

A "Grid Service URI" is called the Grid Service Handle, or simply GSH. Each GSH must be unique. There cannot be two Grid Services with the same GSH. The only problem with the GSH is that it tells me where the Grid Service is, but doesn't give me any information on how to communicate with the Grid Service (what methods it has, what kind of messages it accepts/receives, etc.). To do this, we need the Grid Service Reference, or GSR. In theory, the GSR can take many different forms, but since we will usually use SOAP to communicate with a Grid Service, the GSR will be a WSDL file (remember that WSDL describes a Web Service: what methods it has, etc.). In fact, in this tutorial we will only handle WSDL as a GSR format.

Yes, despite the fact that what you're reading is the Globus Toolkit Three Programmer's Tutorial, there are already plans for a fourth version. This new version, in fact, will be the first available WSRF implementation. The first stable release is expected in the third quarter of 2004.

At this point, alarm bells might be ringing loudly in your head. If the next version of the Globus Toolkit is just around the corner (with a new standard), then what is the point of spending a single nanosecond on GT3 and OGSI? Well, here's the good news: WSRF and OGSI are conceptually the same thing. The main differences between OGSI and WSRF are not 'big' differences (such as a paradigm shift). They are mainly syntactical in nature: WSRF is a refactoring of OGSI, taking into account all the comments from both the Grid community and the Web Services community, resulting in a more polished and stable standard. In fact, there's even a document available in the WSRF website that shows how there's a direct mapping from OGSI features to WSRF features.

So, what's the point in learning OGSI and GT3? Because the switch from OGSI to WSRF will be very simple if you've already gotten the hang of all the fundamental concepts: service data, notifications, lifecycle management, etc. If you wait for GT4 to come out, you'll have to learn all the theory then. It's like learning to program: Once you've mastered one programming language, moving to a new language is simply a question of learning the syntax of the new language (along with any particular idiosyncrasies that language might have)

Ok, so that previous paragraph might sound like a shameless pitch to get you to read the tutorial :-) Believe me, it's not. If you learn GT3 now instead of waiting for GT4, you'll be able to laugh at those who didn't learn GT3. Like this: "Ha, ha, ha! I scoff thine minuscule knowledge of service data and notifications! Tremble upon my encyclopedic knowledge of service-oriented grid applications!"

The GWSDL code we'll be using is the equivalent of the Java interface shown above. However, that interface might raise a couple of eyebrows. If we said that our MathService is going to allow addition and subtraction, why do add and subtract receive only one parameter? Did the author of the tutorial flunk lower school math? Addition and subtraction involves two numbers! And what's with that getValue method? An explanation is in order...

The reason why addition and subtraction have one parameter is because we're going to use our service as an accumulator to demonstrate how grid services are stateful (remember: stateful means the service remembers internal values from one call to the other). MathService will have an internal value which will initially be zero. Each call to add and subtract will modify that internal value, which we'll be able to access thanks to the getValue method. This will allow us to observe that the service remembers that internal value from once call to the next (unlike a plain stateless web service, which would be unable to 'remember' that value).

Ok, so supposing you either know WSDL or have visited the How to write a GWSDL description of your Grid Service page, take a good thorough look at this GWSDL code:

<?xml version="1.0" encoding="UTF-8"?>
<definitions 
name="MathService"
  targetNamespace="http://www.globus.org/namespaces/2004/02/progtutorial/MathService"
  xmlns:tns="http://www.globus.org/namespaces/2004/02/progtutorial/MathService"
  xmlns:ogsi="http://www.gridforum.org/namespaces/2003/03/OGSI"
  xmlns:gwsdl="http://www.gridforum.org/namespaces/2003/03/gridWSDLExtensions"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns="http://schemas.xmlsoap.org/wsdl/">

<import location="../../ogsi/ogsi.gwsdl"
  namespace="http://www.gridforum.org/namespaces/2003/03/OGSI"/>

<types>
<xsd:schema 
targetNamespace="http://www.globus.org/namespaces/2004/02/progtutorial/MathService"
  attributeFormDefault="qualified"
  elementFormDefault="qualified"
  xmlns="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="add">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="value" type="xsd:int"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="addResponse">
    <xsd:complexType/>
  </xsd:element>
  <xsd:element name="subtract">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="value" type="xsd:int"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="subtractResponse">
    <xsd:complexType/>
  </xsd:element>
  <xsd:element name="getValue">
    <xsd:complexType/>
  </xsd:element>
  <xsd:element name="getValueResponse">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="value" type="xsd:int"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>
</types>

<message name="AddInputMessage">
  <part name="parameters" element="tns:add"/>
</message>
<message name="AddOutputMessage">
  <part name="parameters" element="tns:addResponse"/>
</message>
<message name="SubtractInputMessage">
  <part name="parameters" element="tns:subtract"/>
</message>
<message name="SubtractOutputMessage">
  <part name="parameters" element="tns:subtractResponse"/>
</message>
<message name="GetValueInputMessage">
  <part name="parameters" element="tns:getValue"/>
</message>
<message name="GetValueOutputMessage">
  <part name="parameters" element="tns:getValueResponse"/>
</message>

<gwsdl:portType name="MathPortType" 
extends="ogsi:GridService">
  <operation name="add">
    <input message="tns:AddInputMessage"/>
    <output message="tns:AddOutputMessage"/>
    <fault name="Fault" message="ogsi:FaultMessage"/>
  </operation>
  <operation name="subtract">
    <input message="tns:SubtractInputMessage"/>
    <output message="tns:SubtractOutputMessage"/>
    <fault name="Fault" message="ogsi:FaultMessage"/>
  </operation>
  <operation name="getValue">
    <input message="tns:GetValueInputMessage"/>
    <output message="tns:GetValueOutputMessage"/>
    <fault name="Fault" message="ogsi:FaultMessage"/>
  </operation>
</gwsdl:portType>

</definitions>

	This file is $TUTORIAL_DIR/schema/progtutorial/MathService/Math.gwsdl. If you're wondering why you have to save it in that particular directory, take a look at the Tutorial Directory Structure appendix.

If you know WSDL, you'll recognize this as a pretty straightforward WSDL file which defines three operations: add, subtract, and getValue (along with all the necessary messages and types). Let's take a closer look at some important parts of the code. First of all, notice how the target namespace for the Grid Service is:

http://www.globus.org/namespaces/2004/02/progtutorial/MathService

Furthermore, we have to declare the following OGSI namespaces:

xmlns:ogsi="http://www.gridforum.org/namespaces/2003/03/OGSI"
xmlns:gwsdl="http://www.gridforum.org/namespaces/2003/03/gridWSDLExtensions"

We also have to import a GWSDL file that defines all the OGSI-specific types, messages, and portTypes.

<import location="../../ogsi/ogsi.gwsdl"
namespace="http://www.gridforum.org/namespaces/2003/03/OGSI"/>

Finally, notice how we have no bindings whatsoever in our GWSDL file (bindings are an essential part of a normal WSDL file). We don't have to add them manually, since they are generated automatically with a GT3 tool.

One of the nice things about (G)WSDL is that it's language-neutral. In other words, there is no mention to the language in which the service is going to be implemented, or to the language in which the client is going to be implemented.

However, there will of course come a moment when I'll want to refer to this interface from a specific language (in our case, Java). We do this through a set of stub classes (stubs where described in A short introduction to Web Services) which are generated from the GWSDL file using a GT3 tool. For that tool to successfully generate the stub classes, we need to tell it where (i.e. in what Java package) to place the stub classes. We do this with a mappings file, which maps GWSDL namespaces to Java packages:

http\://www.globus.org/namespaces/2004/02/progtutorial/MathService=
        org.globus.progtutorial.stubs.MathService

http\://www.globus.org/namespaces/2004/02/progtutorial/MathService/bindings=
        org.globus.progtutorial.stubs.MathService.bindings
  
http\://www.globus.org/namespaces/2004/02/progtutorial/MathService/service=
        org.globus.progtutorial.stubs.MathService.service

	Each mapping must go in one line (i.e. the above file should have three lines). This file is $TUTORIAL_DIR/namespace2package.mappings.

The first namespace is the target namespace of the GWSDL file. The other two namespaces are automatically generated when a GT3 tool 'completes' the GWSDL file (including the necessary bindings). For all the tutorial, we'll be placing all the stub classes in the following Java package:

org.globus.progtutorial.stubs

Since we're defining a service called MathService, we're specifically mapping the GWSDL file to the following package:

org.globus.progtutorial.stubs.MathService

However, take into account that the stubs classes are generated from the GWSDL file, so they won't exist until we compile the service (which is when the stub classes are generated). In other words, don't look for the org.globus.progtutorial.stubs package in $TUTORIAL_DIR, because you won't find them there. If you are of a curious predisposition, don't worry, as soon as we generate the stub classes, we'll take a (very brief) look at the directory where they are generated.

Remember that this is GWSDL, an extension of WSDL. Actually, this is not entirely true. GWSDL has certain features that WSDL 1.1 doesn't have, but which will be available in WSDL 1.2/2.0. Since WSDL 1.2/2.0 is still a W3C Working Draft (in other words, not a stable standard, and bound to change in the near future), the Global Grid Forum was unable to use WSDL 1.2/2.0 (with all its great Grid-friendly improvements) in OGSI. So, they created GWSDL as a temporary solution. In fact, the Global Grid Forum has said that, as soon as WSDL 1.2/2.0 is a W3C Recommendation (a stable standard), it will substitute GWSDL for WSDL 1.2/2.0. However, since the announcement of WSRF, this has changed (as OGSI will be discontinued when WSRF appears). WSRF will not use GWSDL, but it won't wait for WSDL 1.2/2.0 either, so it will use pure WSDL 1.1 for interface description.

So, what exactly are the improvements in GWSDL? Well, they're basically related to the improvements that Grid Services introduce with respect to Web Services (as seen in What is a Grid Service?). If you are WSDL-literate, you've probably already spotted one improvement in the above code:

<gwsdl:portType name="MathPortType" extends="ogsi:GridService">


</gwsdl:portType>

First of all, notice how we're not using the WSDL <portType> tag, but a tag from the GWSDL namespace: <gwsdl:portType>. This new tag has an extends attribute. This is the first major improvement in GWSDL: portType extension. You can define a PortType as an extension of one of more portTypes. In this case, we're extending from an OGSI PortType called GridService (all Grid Services must implement this interface).

The second major improvement is related to Service Data, which we will see in one of the following chapters.

<service name="progtutorial/core/first/MathService" provider="Handler" style="wrapped">

This specifies the location where our Grid Service will be found. If we combine this with the base address of our Grid Service container, we will get the full GSH of our Grid Service. For example, if we are using the GT3 standalone container, the base URL will probably be http://localhost:8080/ogsa/services. Therefore, our service's GSH would be:

http://localhost:8080/ogsa/services/progtutorial/core/first/MathService

<parameter name="name" value="MathService"/>

Although this might seem confusing, the <service> element has both a name attribute (the one seen above) and name parameter. The parameter simply contains a brief description of the service (e.g."MathService")

<parameter name="className" value="org.globus.progtutorial.stubs.MathService.MathPortType"/>
<parameter name="baseClassName" value="org.globus.progtutorial.services.core.first.impl.MathImpl"/>

In strict WSDD, this parameter would refers to the class which implements the service interface (in our case, MathImpl from the previous page). However, notice how the value of this parameter is the MathPortType stub interface mentioned in the previous page.

Since Grid Services are a tad more complex that plain web services, it's necessary to distinguish between the className and the baseClassName. The className refers to the interface that exposes all the functionality of the grid service (MathPortType), and baseClassName is the class that provides the implementation for our grid service. In our case, baseClassName is the MathImpl class we implemented in the previous page. When we see operation providers (in the next section) we'll see that the baseClassName doesn't need to include an implementation for all the methods exposed in the className (we'll see that it's possible to delegate some or all of the our methods to special classes called operation providers)

<parameter name="schemaPath" value="schema/progtutorial/MathService/Math_service.wsdl"/>

The schemaPath tells the grid services container where the WSDL file for this service can be found. No, that's not a typo, I said WSDL, not GWSDL. Remember that GWSDL is a (non-standard) extension of WSDL, so it must first be converted to WSDL so it can be truly interoperable with existing web services technologies. This WSDL file (Math_service.wsdl) will be generated automatically by a GT3 tool when we compile the service.

<!-- Start common parameters -->
<parameter name="allowedMethods" value="*"/>
<parameter name="persistent" value="true"/>
<parameter name="handlerClass" value="org.globus.ogsa.handlers.RPCURIProvider"/>

These are three parameters which we'll see in every grid service we program.

Ant, an Apache Software Foundation project, is a Java build tool. In concept, it is very similar to the classic UNIX make command. It allows programmers to forget about the individual steps involved in obtaining an executable from the source files, which will be taken care of by Ant. Each project is different, so the individual steps are described in a build file ('Makefile' in the make jargon). This build file directs Ant on what it should compile, how it should compile it, and in what order. This simplifies the whole process considerably. In fact, it reduces the number of steps to one! With Ant, all we have to worry about is writing the service interface, the service implementation, and the deployment descriptor. Ant takes care of the rest:

As you can see, Ant generates the GAR directly from the three source files. Internally, it is carrying out all the steps listed earlier, sparing us the cumbersome task of doing them ourselves. In a GT3 project, Ant uses two sets of build files: a couple of build files which are a part of GT3, and a build file we'll have to write on our own. The GT3 build files cover all the important steps (generating the WSDL code, generating the stubs, ...). Our build file essentially has all the unique parameters of our Grid Service, and a bunch of calls to the GT3 build files. At first, it is safe to know practically nothing about Ant and build files; you can usually write a 'generic' build file which will work with more than one Grid Service, and then you won't have to see build files ever again. In fact, this tutorial includes a handy build file that works with all the examples we'll see. However, as you move on to more complex projects, you'll probably need to write custom build files to fine tune the whole build process.

If you want to learn more about Ant, take a look at the Ant Website. It includes plenty of documentation, tutorials, etc.

For the rest of the tutorial, we are going to use a very handy Ant build file which will work with all the examples we'll see. That way, we won't have to rewrite the build file each time we get to a new example. The build file is included in the downloadable tutorial files (available in the tutorial website). Since this tutorial isn't meant as an Ant tutorial, we won't see what's inside the build file, but feel free to take a look inside.

Since using the Ant file directly implies passing a lot of parameters to Ant, we'll also use a handy shell script which makes things even simpler (also included with the tutorial files).

However, before doing anything, make sure you create a file called build.properties in $TUTORIAL_DIR with the following line:

ogsa.root=path to GT3 installation

Replace path to GT3 installation with the path where you installed GT3. For example:

ogsa.root=/usr/local/gt3

Using the provided Ant buildfile and the handy script, building a Grid Service is as simple as doing the following:

./tutorial_build.sh <service base directory> <service's GWSDL file>

The "service base directory" is the directory where we placed the server-deploy.wsdd file, and where the MathImpl.java file can be found (inside an impl directory). More details on this in the Tutorial Directory Structure appendix.

For example, to build our first example and generate its GAR file, we simply need to do the following:

./tutorial_build.sh \
org/globus/progtutorial/services/core/first \
schema/progtutorial/MathService/Math.gwsdl

	Make sure you run this from $TUTORIAL_DIR.

	Windows users can use a Python build script originally contributed by Michael Schneider. This script is called tutorial_build.py and is included with the downloadable tutorial files. If you prefer to use the Python script, simply replace tutorial_build.sh with tutorial_build.py in all the following examples.

If everything works fine, the GAR file will be placed in $TUTORIAL_DIR/build/lib. To be exact, the GAR file generated for this example will be the following:

$TUTORIAL_DIR/build/lib/org_globus_progtutorial_services_core_first.gar