Aaron is the founder of Mantis Development Corps and director of the Media Grid and Web3D Web (http://Web3DWeb.com/). He teaches computer graphics and Internet/web-application development at Boston College, and is also author of J2EE 1.4 Essentials (http://www.wiley.com/compbooks/walsh/). Aaron can be contacted at aaron@mantiscorp.com.
Global Grid Forum, OGSA, and OGSI
Over the past decade, the technology behind computational grids has evolved from raw concept into tangible reality. Grids are generally distinguished from the field of traditional distributed computing by their ability to share resources such as processing power and databases on a large scale and with high performance. To date, grid technology has been used primarily by researchers for building specialized scientific and engineering applications. More recently, however, grids have migrated into the corporate world. Utility computing, on-demand computing, and autonomous computing are just a few of the buzzwords describing technology that is based, to some degree, on large-scale resource sharing across organizational boundaries.
Of the many grid technologies available to Java developers, the Globus Project's Globus Toolkit is perhaps the most well known and widely adopted. In this article, I briefly discuss the Globus Project, then examine the latest version of the Globus Toolkit, with which you can create Java-based grid services and grid clients.
The Globus Project
The Globus Project (http://globus.org/) was started in 1996 as a collaborative research and development project for building foundation technologies that enable computational grids. The project is based at the Argonne National Laboratory's Mathematics and Computer Science Division, the University of Southern California's Information Sciences Institute, and the University of Chicago's Distributed Systems Laboratory. In addition to universities and government agencies, the Globus Project is also sponsored by IBM, Microsoft, and Cisco.
The open-source Globus Toolkit is the project's key deliverable. As a unified collection of grid software services and libraries, the Globus Toolkit Version 2.4 provides a standard development framework you can use to develop special-purpose grids. The toolkit supports discovery, management, and monitoring of grid resources, as well as file management and security features. The Globus Toolkit is used by grid projects around the world and is the foundation on which many commercial grid projects are currently being built.
Version 3 of the Globus Toolkit has been released and shipped earlier this year. Globus Toolkit 3 gives Java developers a standard solution for developing and deploying grid services and clients. The Media Grid that powers the Web3D Web (http:// Web3DWeb.com/), for example, uses GT3 to enable digital media delivery and processing services on a massive scale.
Globus Toolkit 3
Globus Toolkit 3 (GT3) was officially released as open source by the Globus Project recently. As a high-performance grid framework, GT3 relies on native code that is exposed to Java developers through standard APIs. In other words, you can harness the power of GT3 using pure Java.
GT3 is an open-source implementation of the Open Grid Services Infrastructure (OGSI); see the accompanying text box entitled "Global Grid Forum, OGSA, and OGSI." By providing a number of premade OGSI services and the ability to create custom OGSI-compliant services as needed, the toolkit gives you a powerful framework for building grids based on standard web services. The OGSI specification builds on grid- and web-service technologies to define how "grid services" are created and managed, and how information can be exchanged among grid services. According to the specification, a grid service is merely a web service that conforms to specific interface and behavior conventions that define how clients interact with that service.
Simply put, a grid service is a special-purpose web service designed to operate in a grid environment. To this end, OGSI uses the Web Services Description Language (WSDL) to define compliant grid services that are accessible over the Internet using SOAP/HTTP. The current OGSI 1.0 specification implemented by GT3 extends WSDL 1.1 to define grid services and will eventually support WSDL 1.2. OGSI 1.0 defines a component model by extending WSDL 1.1 and XML Schema Definition (XSD) to support a number of useful and innovative enhancements, including: stateful web services; support for inheritance of web-service interfaces; asynchronous state change notifications; references to service instances; service collections; and service state data.
Although the full GT3 run time is a Linux product, the Java-based OGSI reference implementation portion of Globus Toolkit 3 can run in any of the following four Java environments on any platform (provided Java 1.3.1 or higher is available):
- Embedded in any existing Java 2 Standard Edition (J2SE) application.
- Standalone in a lightweight J2SE server (used primarily for testing and development work).
- Java 2 Enterprise Edition (J2EE) web container by deploying to a servlet container such as Apache Jakarta Tomcat.
- J2EE Enterprise JavaBean (EJB) container by using a Globus code generator that enables stateful Entity and Session beans to be exposed as OGSI-compliant grid services.
GT3 features a core architecture built on OGSI primitives and protocols. Figure 1 illustrates the GT3 core architecture, which is designed to make OGSI-based grids easy to create and use. The GT3 core provides an open-source implementation of all interfaces defined by OGSI 1.0. In addition, it provides various hosting environments layered on top of an abstract container. Conceptually, the GT3 core is a suite of building blocks that provide the main functionality necessary for a variety of grid applications. GT3 also provides a security framework, various system services (logging, management and administration, and so forth), and a development environment that includes code-generation tools to make life easier on grid application developers.
The white boxes in Figure 1 indicate components provided by the GT3 core, while gray boxes are considered outside of the core. User-defined services provided by application developers, for instance, are not considered part of the GT3 core. Similarly, the web-services engine and base services are not officially part of the core, although they are provided with the full GT3 run time (base services enable execution, data management, and information services; user-defined services are any services built using GT3 components).
The OGSI Reference Implementation in Figure 1 supports all of the interfaces defined by OGSI 1.0, in addition to related APIs and tools used to create compliant grid services. The Security Infrastructure implementation, meanwhile, provides a variety of security features such as SOAP and transport-level message protection; end-to-end mutual authentication; and single sign-on authorization. The OGSI Reference Implementation and Security Infrastructure don't provide run-time services directly—they are infrastructure building blocks used by other parts of the GT3 architecture.
The services and primitives that make up the GT3 core interact with an abstract OGSI run-time environment, known as the "Grid Services Container." This container hides low-level implementation details (such as the underlying database used for data persistence) from you so that you can focus on developing grid services and clients at a higher level.
Creating Grid Services
Creating a grid service with Version 3 of the Globus Toolkit is a four-stage process:
1. Create the service interface.
2. Generate stub and support code.
3. Implement the service.
4. Deploy the service.
You define grid services interfaces by writing Java code, from which the toolkit generates the appropriate WSDL interfaces, or you can create the WSDL interfaces manually. Listing One, for example, is the Java interface code for the Counter example program provided with the toolkit, while Listing Two shows key portions of a corresponding WSDL interface. Only the abstract definition of the service (including the types, message, and portType parts of WSDL) are necessary when creating a WSDL interface directly, since the binding and service portions are generated by the toolkit.
After defining the interface for your grid service, you must then generate the stub and support code for your service. At this stage, you use the Ant tasks and XML batch file tools provided with GT3 to generate the code needed to host your grid service. Listing Three, for instance, is the Ant command used to generate a WSDL interface from the Counter Java interface in Listing One. After the WSDL interface is available, you can then generate the Java stubs that let your service data be accessed via SOAP over HTTP. Listing Four is the Ant command that generates these stubs for the Counter example (Listings Three and Four are excerpts of the build.xml file that comes with this example).
Upon generating stubs and support code, you actually implement the service. Listing Five shows the Java implementation of the Counter grid service, for which the class CounterImp.java is defined. This class extends the base grid services implementation, GridServiceImpl, and implements the CounterPortType interface created in the previous step. In cases where you don't want your grid service to be dependent on implementation classes provided with GT3 (such as GridServiceImpl), you can provide an implementation using an operation-provider (delegation) approach instead. (For details, see the Java Programmer's Guide Core Framework, available through the GT3 download area.)
After providing an implementation for your service, it's ready to be deployed. To do so, you must write a deployment descriptor that describes and configures your service, then bundle the descriptor and the various files that comprise the service into a Grid Archive (GAR) package. GAR packages can be deployed to any suitable grid service hosting environment. Listing Six is a key excerpt of the deployment descriptor for the Counter grid service example that comes with GT3, while Listing Seven is the Ant command that builds the GAR package for this service.
Creating Grid Services Clients
Creating grid services is only half the battle: To be of any real value, a grid service is accessed and used by a grid client. Although you can create grid services clients using the standard JAX-RPC API, you'll find it much easier to use the JAX-RPC extensions provided with GT3. Standard JAX-RPC doesn't directly support grid services, and you'll save a lot of time by simply using the helper JAX-RPC classes provided with GT3 as illustrated by Listing Eight.
Getting Started with Globus Toolkit 3
GT3 is freely available at http://www.globus.org/. To get started, simply download and install the toolkit, then turn to the example programs that come with it (the Counter example presented here is just one of many GT3 grid-service examples). You will find the related User's Guide Core Framework and Java Programmer's Guide Core Framework documents essential, and can find links to both through the GT3 download area. Whereas the User's Guide Core Framework tells you how to install/configure the toolkit and run the various example programs that come with it, the Java Programmer's Guide Core Framework provides details on how you can create grid services using Java. You'll also find the Grid Service Development Tools Guide useful in learning the various Ant commands that you can use to create and manage your services (it's also available through the GT3 download area).
DDJ
Listing One
/* "Counter" interface example provided with Globus Toolkit 3. Refer to
* guide/src/org/globus/ogsa/guide/impl/Counter.java for complete example.
*/
package org.globus.ogsa.guide.impl.guide;
public interface Counter {
public int add(int value);
public int subtract(int value);
public int getValue();
}
Back to Article
Listing Two
<types> ... <xsd:element name="add"> <xsd:complexType> <xsd:sequence> <xsd:element name="value" type="xsd:int"/> </xsd:sequence> </xsd:complexType> </xsd:element> ... </types> ... <message name="AddInputMessage"> <part name="parameters" element="tns:add"/> </message> ... <gwsdl:portType name="CounterPortType" extends="ogsi:GridService"> <operation name="add"> <input message="tns:AddInputMessage"/> <output message="tns:AddOutputMessage"/> <fault name="Fault" message="ogsi:FaultMessage"/> </operation> </gwsdl:portType>Back to Article
Listing Three
<ant antfile="${build.services}" target="generateWSDL">
<property name="interface.package" value="org.globus.ogsa.guide.impl"/>
<property name="interface.name" value="Counter"/>
<property name="generated.dir" value="guide"/>
</ant>
Back to Article
Listing Four
<ant antfile="${build.services}" target="generateStubs">
<property name="schema.file.dir" value="guide/Counter"/>
<property name="schema.file" value="counter_service.wsdl"/>
</ant>
Back to Article
Listing Five
/* "Counter" implementation example provided with Globus Toolkit 3. Refer to
* uide/src/org/globus/ogsa/guide/impl/CounterImpl.java for complete example.
*/
public class CounterImpl extends GridServiceImpl implements CounterPortType {
private int val = 0;
public CounterImpl() {
super("Guide Counter");
}
public int add(int val) throws RemoteException {
this.val = this.val + val;
return this.val;
}
public int subtract(int val) throws RemoteException {
this.val = this.val - val;
return this.val;
}
public int getValue() throws RemoteException {
return this.val;
}
}
Back to Article
Listing Six
<?xml version="1.0" encoding="UTF-8"?> <deployment name="defaultServerConfig" xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"> <service name="guide/counter/CounterProviderFactoryService" provider="Handler" style="wrapped"> <parameter name="name" value="Guide Counter Provider Factory"/> <parameter name="instance-name" value="Guide Counter Proivider Counter"/> <parameter name="instance-schemaPath" value="schema/guide/Counter/counter_service.wsdl"/> <parameter name="instance-className" value="org.globus.ogsa.guide.Counter.wsdl.CounterPortType"/> <parameter name="instance-baseClassName" value="org.globus.ogsa.impl.ogsi.GridServiceImpl"/> <parameter name="instance-operationProviders" value="org.globus.ogsa.guide.impl.CounterProvider"/> <parameter name="persistent" value="true"/> <parameter name="schemaPath" value="schema/ogsi/ogsi_notification_factory_service.wsdl"/> <parameter name="baseClassName" value="org.globus.ogsa.impl.ogsi.PersistentGridServiceImpl"/> <parameter name="handlerClass" value="org.globus.ogsa.handlers.RPCURIProvider"/> <parameter name="className" value="org.gridforum.ogsi.NotificationFactory"/> <parameter name="allowedMethods" value="*"/> <parameter name="factoryCallback" value="org.globus.ogsa.impl.ogsi.DynamicFactoryCallbackImpl"/> <parameter name="operationProviders" value="org.globus.ogsa.impl.ogsi.FactoryProvider org. globus.ogsa.impl.ogsi.NotificationSourceProvider"/> </service </deployment>Back to Article
Listing Seven
<ant antfile="${build.packages}" target="makeGar">
<property name="gar.name" value="${build.lib}/guide.gar"/>
<property name="garlib.dir" value="${build.lib}"/>
<property name="garserverdeployment.file" value="guide-config.wsdd"/>
<property name="garschema.origin" value="${build.schema}/guide"/>
<property name="garschema.path" value="guide"/>
</ant>
Back to Article
Listing Eight
/* "Counter" grid service client JAX-RPC example provided with Globus * Toolkit 3. Refer to GT3 Java Programmers Guide Core Framework for details. */ OGSIServiceGridLocator gridLocator = new OGSIServiceGridLocator(); Factory factory = gridLocator.getFactoryPort(handle); GridServiceFactory gridFactory = new GridServiceFactory(factory); LocatorType locator = gridFactory.createService(); CounterServiceGridLocator counterLocator = new CounterServiceGridLocator(); CounterPortType counter = counterLocator.getCounterPort(locator); int val = counter.add(2);
