Browse Prior Art Database

A Means to Provide Runtime Support for Service-Data to Grid Services. Disclosure Number: IPCOM000021953D
Original Publication Date: 2004-Feb-17
Included in the Prior Art Database: 2004-Feb-17
Document File: 5 page(s) / 51K

Publishing Venue



Grid services are defined by the current OGSA specification from the Global Grid Forum (GGF), and by a newer series of specifications known as the OGSI 1.5. Grid services are built on web services, and as such, depend on a hosting environment such as WebSphere. One the features of stateful grid services is 'service data'. This disclosure contains a means for a grid service infrastructure to provide service data to its hosted grid service implementations that is simple, powerful and extensible.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 37% of the total text.

Page 1 of 5

A Means to Provide Runtime Support for Service -Data to Grid Services.

The invention presents a simplified interface to the grid service developer (through *Java). Key methods defined allow these capabilities; add a service data element callback or value, remove a service data element, set an service data element as available or unavailable for notification, trigger notification for a service data element, and handle queries (by name, by Xpath or Xquery expression) of the entire service data set for a grid service. Other features of our invention; service data elements can be added and removed dynamically, the burden of creating the XML for query responses is removed from the GS developer, and improved performance is achieved by generating XML on-demand, only a single copy of the actual service data element value is maintained, commit points for service data element change are easily managed by the grid service developer. This approach also makes it much simpler to convert an existing system or application API, or other function to a grid service, because the existing implementation can provide as service data, existing internal data, in a very simple way. This ability to convert an existing application or web service into a grid service easily, without lots of internal modifications to the existing implementation, is a key design objective of this approach. Such a design objective promotes grid services by lower the development cost to create them. The following Java interface defines the interface seen and used by the grid service developer.


Page 2 of 5

* <li>Converting existing web service, API's, or other function,

* to a GS is easier, because re-organization of existing

* internal implementation is unnecessary.

* </ol>

* @version %I%, %G%

* @since OGSA rel. 1


//----------------------------------------------------------------- public interface ServiceDataSetInterface {


* A GS implementation calls a setSDEvalueCallback() method to

* establish a callback for a given SDE. This callback method

* is called by the ServiceDataSet when it needs to know the

* SDE's current value. (The current value of an SDE is needed

* a) to respond to a FindServiceData operation, and b) to

* properly trigger notification of a change in value.)


* Tooling generates the calls for the GridService portType

* service data, and possibly for additional service data.

* <p>

* Dynamic SDE's are supported; if the SDE in 'sdename' is

* not in the .gsdl, its added.


* @param sdename the name of the SDE

* @param currentvalue the current value for the SDE. Note that GS

* can change value via call to a *value() method.

* @param parentsdname the SDE name of the parent service data element.

* @param sdeindex an arbitrary, but unique across all a GS's SDEs,

* index that is used as param in the call-back.

* (See

* @param callback object instance that has callback method

* @param withgetter object instance that has a method named "get"...