GT Components are grouped into five main functional areas:

• Common runtime components provide low-level infrastructure for communication and threading, as well as libraries and tools for service and state management. The C, Java, and Python subsystems provide support for services written in C, Java, and Python, respectively. This tutorial is designed to teach you how to build a service using GT's Java runtime; C and Python runtime components are outside the scope of this tutorial.
• Data services address the requirements for locating, replicating, transferring and accessing data stored in either files or databases. A specific focus of components in this area is the management of very large scale datasets both in terms of number of data objects (i.e. files) and the size of those individual data objects. The data components are outside the scope of this tutorial.
• Security components address cross-cutting issues of authentication and authorization of both users and services. With GT4, the security implementation has moved from primarily a collection of libraries to a more service-oriented structure, as illustrated by the introduction of standalone delegation and authorization services. This tutorial includes an introduction to authentication and authorization.
• Execution components provide for the deployment, execution and management of applications. Previous versions of the toolkit focused primarily on the execution of user-provided programs. However, newer services have generalized these functions to address deployment and management of community services as well as providing enhanced capability with respect to configuring and managing the execution environment in which applications and service run. Execution components are outside the scope of this tutorial.
• Information components are concerned with the monitoring and discovery of both GT and non-GT services and capabilities. Starting with GT3 and continuing in GT4, many of the basic functions of state publication and management have been incorporated into the common runtime component of the system. The information components build on this by providing an extensible infrastructure for aggregating service state information, providing interfaces for publishing information from non-GT services, and notifying users when events of interest occur. The GT4 Index service and WebMDS are used in this tutorial.

StickyNote executes inside a hosting environment, also called a container. The GT4 container provides functionality useful to many different types of Grid-related services: security processing, notification infrastructure and state managment. The fact that the hosting environment provides this functionality means that service programmers don't need to write it themselves.

The hosting environment we'll be using for this tutorial is part of the GT4 Java Runtime, and is referred to as "Java WS Core". The following picture shows the two StickyNote clients we'll be using in this exercise, write-note and show-note. Also shown is the GT4 Java web service container, hosting the StickyNote service:

Software tools used in this and subsequent exercises:

• jdk: the Java software development kit, used to compile and run demonstration code
• jakarta ant: an open source tool for building Java code (similar to "make")
• a GT4 binary installation: a subset of the Globus Toolkit which includes the wsrf and wsmds modules distributed with 4.0.2

The following picture shows a deployed stickynote service, with clients invoking operations, and the GT4 container dispatching them to the appropriate write and show code:

And here is a picture of a StickyNote service with multiple notes (resources) defined, one of which is set to "hello.":

Note that the use of resources is not mandated. Stateless (operation-only) services are also supported in GT4.

The following figure shows that a StickyNote with three note resources has four different EPRs associated with it. Messages can be addressed to any one of these four of these endpoints because they each have their own EPR:

Here is an overview of the resource/EPR creation process:

Important note: EPRs only refer to resources. EPRs are like network-wide pointers - the actual resources exist in the GT4 container. If the file created by the client is deleted, it in no way causes the resource to be removed. Likewise, if the resource is destroyed, the file will remain, but will point to something that no longer exists.

There are at least two benefits of the operation provider programming model:

1. operation providers facilitate code reuse
2. the "load only what you need" approach helps minimize service footprints