- Doc Structure
- A Globus Primer
- Globus Is Modular!
- Installing GT
- Platform Notes
- Migrating from GT2
- Migrating from GT3
- PDF version
- Best Practices
- Coding Guidelines
- API docs
- Public Interfaces
- Resource Properties
- Performance Studies
Table of Contents
The following provides available information about migrating from previous versions of the Globus Toolkit.
GWSDL to describe service messages and operations. GT4 uses standard WSDL with one extensibility attribute to describe resource properties. Please see the WS-ResourceProperties specification for details on expressing the resource properties in
In GT3 every service inherited some basic operations and functionality (from
GridService port type) as required by the OGSI specification. However, in GT4 there is no such requirement (because the WSRF/WSN specifications do not require it). Also, the
Factory port type defined in the OGSI specification does not exist in WSRF/WSN specifications. Therefore, there is no standard create operation or functionality provided by GT4.
In GT3, the business logic of the service and the state were coupled together in one class. In GT4, the business logic and the state are decoupled and placed in two separate classes. The business logic is put in a service class while the state is put in a resource class. The service is stateless while the resource is stateful. Also, GT4 introduces ResourceHome classes that are responsible for managing and discovering resources. Please see the programming model overview for details.
Even though a GT4 developer needs to modify two or three separate files the coding effort is about the same as in GT3.
In GT3, most of the configuration information was stored in the
server-config.wsdd file. In GT4, since the business logic and state were decoupled, the service information is still kept in server-config.wsdd but resource information is now placed in the new jndi-config.xml file. Please see the JNDI section for more details.