Supporting OGSI and WSRF Specific Functionality in
Intermittently Available Network Environments
Alastair Hampshire1, Chris Greenhalgh1
1
School of Computer Science and IT, University of Nottingham, Jubilee Campus, Wollaton
Road, Nottingham, NG8 1BB, UK
{axh, cmg}@cs.nott.ac.uk
Abstract
The Open Grid Services Infrastructure (OGSI) defines a standard set of facilities which allow the
creation of wide area distributed computing applications, i.e. applications which cross
organisational and administrative boundaries. A number of projects have demonstrated significant
potential for OGSI to support applications, such as ubiquitous and mobile computing applications,
which require the integration of devices which are wirelessly and therefore only intermittently
connected to the fixed network. However, OGSI currently assumes the availability of a permanent
network connection between client and service.
This paper identifies a number of requirements specific to the use of OGSI in intermittently
available network environments. Building on earlier work to provide reliable invocation delivery
between intermittently connected and permanently connected clients and services, this paper
addresses these OGSI specific requirements. A prototype framework has been implemented and
tested to demonstrate the viability of the approach.
1 Introduction
Grid Computing symbolises a vision in which
users share and access compute and storage
resources, such as databases, processor servers
and mobile devices, which are distributed across
large geographical areas and span multiple
organisational
boundaries
[Foster
and
Kesselman, 1999]. One approach to grid
computing
utilises
a
service-oriented
architecture in which clients interact with
resources through entities known as grid
services. The Open Grid Services Infrastructure
(OGSI) [Tuecke et. al., 2003] and subsequently
the Web Services Resource Framework
(WSRF) [Frey et. al., 2004] define a standard
set of framework facilities for interacting with
these grid services.
There are many applications which would
benefit from using service-oriented grid
techniques to support devices which are
wirelessly
and
therefore
intermittently
connected to a fixed network infrastructure. For
example, Storz et. al. [Storz, Friday and Davies,
2003] identify significant commonality between
the functionality of grid technologies and the
requirements
of
ubiquitous
computing
applications on their underlying computing
infrastructure and therefore assert that there is
significant potential for the grid to be used as
the computing infrastructure for large scale
ubiquitous systems. However, standard OGSI
does not support intermittent network
connectivity; an extended period of network
non-availability will cause a standard OGSI grid
service invocation to fail.
This paper describes a framework which
supports OGSI functionality, specifically,
notifications, handle resolution and lifetime
management, in intermittently available
network environments. A prototype toolkit has
been implemented and tested to demonstrate the
viability of the approach. The paper also
proposes how the framework could migrate to
support WSRF specific functionality. The work
builds on an earlier exploration into the
placement of mobile sensing devices on the grid
[Barratt, 2003] and extends the framework
described in [Hampshire, 2004] which supports
reliable
interaction
with
intermittently
connected grid clients and services. The work
described in this paper will allow grid
technologies, specifically OGSI and WSRF, to
better support applications deployed on
intermittently available devices, thus widening
the grid user community to include new classes
of application domain such as ubiquitous and
mobile computing.
Intermittently
Available
OGSI Client
Client
intermediary
Fixed
OGSI
Client
Fixed
OGSI
Service
Server
intermediary
Intermittently
Available
OGSI Service
Normal OGSI communication
Framework supported communication
Figure 1. Framework supported intermittently available OGSI clients and services interacting with
permanently available standard OGSI grid clients and services
2 Related Work
This section firstly describes service oriented
grid technologies, focussing in particular on the
features of OGSI this paper aims to support in
intermittently available network environments,
i.e. lifetime management, handle resolution and
service data notifications. Next, this section
describes an initial exploration into the use of
OGSI to support mobile sensing devices which
motivated the work in this paper. Finally, this
section describes earlier work by the authors to
support reliable interaction with intermittently
available OGSI clients and services, upon which
the work in this paper builds.
2.1 Service-Oriented Grids
This section firstly describes the OGSI
specification which defines a standard set of
framework facilities for the creation of grid
applications. The second part of this section
describes the Web Services Resource
Framework, which supersedes the OGSI
specification.
2.1.1 The Open Grid Services Infrastructure
The Web Services Architecture (WSA) [Booth
et. al., 2004] provides an open standard
definition of a Web Service (WS), a language
neutral software component with a well defined
interface which uses XML as a common data
format, permitting Internet based information
exchange. OGSI extends the WSA with
functionality such as state management,
notifications and lifetime management. The
Globus Toolkit 3 (GT3) [Sotomayor, 2004]
provides an implementation of the OGSI
standard.
The OGSI idiom uses grid factory services
to create grid service instances. A client (or
clients) then interacts with the grid service
instance, which is able to maintain state data for
the duration of the client(s) interaction(s). OGSI
defines the use of a Grid Service Handle (GSH)
and a Grid Service Reference (GSR). A GSH is
a persistent handle to the service, but does not
contain protocol or location information. The
GSR is a transient network pointer with an
associated lifetime, which can be used to locate
and invoke the grid service. The GSH can be
resolved to a GSR using a Handle Resolver
Service.
In OGSI, Service Data (SD) is a collection
of XML elements which represents the state of a
grid service instance. The OGSI specification
defines a set of operations as a common way for
accessing, querying and updating SD. OGSI
allows clients to register an interest in a
particular piece of service data; all interested
clients are notified when a change to the service
data value occurs.
Because OGSI uses factories to create
transient service instances, some mechanism is
required to determine when it is safe to destroy
the instance. Therefore, transient grid services
are created with a finite lifetime and clients may
request extensions to the lifetime. When the
lifetime expires, the service instance can be
destroyed and its associated resources
recovered.
2.1.2 The Web Services Resource Framework
One of the claimed advantages of Web Services
(WS) over Grid services is in their lack of perclient state which, it is argued, allows easier
replication of services under heavy load,
recovery from failure etc. The Web Services
Resource Framework (WSRF), a re-factoring of
OGSI, logically separates the state (“resource”)
from the service itself. Additional OGSI
functionality, e.g. notifications, lifetime
management, renewable references etc, is
provided by a number of separate WS
specifications.
2.2 Initial Exploration
The Equator eScience program, in collaboration
with the MIAS IRC explored the extent to
which the grid could be used to support mobile
sensing applications. Part of this process
included the development of an OGSIcompliant grid infrastructure to support mobile
sensing devices, which was subsequently used
to support a wearable medical monitoring
device [Barratt et. al, 2003] and an
environmental monitoring device deployed on a
fresh water lake in the Antarctic [Benford et. al.,
2003]. Wireless networks were used to allow
communication with fixed network services to
provide facilities such as data storage and
computation. These applications require wide
area cross organisational resource sharing (e.g.
between Nottingham University and the
Australian Antarctic division) and rely heavily
on state management (e.g. sensor readings),
making a service-oriented grid architecture the
ideal solution.
This initial exploration identified OGSI’s
inability to cope with intermittent network nonavailability as a critical problem to the support
of mobile or ubiquitous applications on the grid.
2.3 Framework to Extend OGSI to
Intermittently Available Network
Environments
An earlier paper describes a framework which
allows intermittently available OGSI clients and
services to interact with existing, unmodified
grid clients and service [Hampshire, 2004]. This
is achieved by splitting invocations into wired
and wireless hops with an application layer
intermediary (typically SOAP), as shown in
figure 1. Between an existing OGSI client or
service and the intermediary, standard OGSI
invocation semantics can be used. Between an
intermittently available grid client or service
and the intermediary, alternative invocation
paradigms, e.g. reliable delivery, can be used to
support the distinctive characteristics of the
underlying wireless network. However,
additional OGSI functionality, specifically
notifications, handle resolution and lifetime
management, which requires specific support to
function
appropriately
in
intermittently
available network environments is not
addressed by the framework.
The rest of this paper describes the problems
associated with handle resolution, lifetime
management and notification delivery in detail;
proposes a number of extensions to the
framework to address these problems; and
demonstrates the viability of the approach
through a number of application tests.
3 Exploring the Problem
A number of issues, outlined below, limit or
constrain the use of OGSI and GT3 in
intermittently available network environments.
3.1 Lifetime Management
As already discussed in section 2.1.1, transient
OGSI grid services have finite lifetimes; when
the lifetime expires, the service is destroyed
allowing resources occupied by the service to be
reclaimed. Clients can request extensions to
service lifetimes or can explicitly request the
destruction of the service.
In the case of an intermittently available
OGSI grid service, the lifetime may expire
whilst the service is temporarily unavailable.
Whilst the service is unavailable, a client
application may request a lifetime extension;
however the request will fail, leading to
premature destruction of the service in question.
Further, an intermittently connect grid client
may initiate a lifetime extension request while
temporarily unavailable; should the service’s
lifetime expire before the client is reconnected,
the service will be prematurely destroyed.
Therefore, a framework to support
intermittently available grid services should
ensure services remain alive whilst offline.
3.2 Handle Resolution
By default, the GSH to GSR mapping for an
OGSI grid service implemented using GT3 is
stored in a handle resolver deployed in the same
service container as the grid service itself. In the
case of an intermittently connected service, the
handle resolver will only be intermittently
available; a handle resolution request may
therefore fail. At best, client application will
inform the user to try again later; at worst the
client will assume that a failed handle resolution
means the grid service has been destroyed and
inform the user accordingly. Therefore a
framework to support intermittently available
grid clients and services should allow handle
resolution to take place regardless of service
availability.
3.3 Service Data Notifications
Using standard OGSI functionality, all
notifications produced by a temporarily
unavailable grid service will be lost. Similarly,
all notifications sent to unavailable grid clients
will be lost. Therefore, a framework to support
intermittently available grid services should
ensure the delivery of all notifications produced
whilst ‘off-line’. In addition, the framework
should ensure the delivery of all notifications to
intermittently available clients.
4 Approach
This section introduces a number of extensions
to the framework described in section 2.3 to
address the requirements identified in section 3.
4.1 Lifetime Management
As described in section 3.1, an intermittently
available transient service instance may
undesirably expire whilst unavailable, due to
undelivered lifetime extension requests.
Creating services with sufficiently long timeout
values would provide a simple solution to this
problem; however this would impede the
functionality of lifetime management by
delaying the destruction of defunct grid
services. Further, the length of time for which a
service is unavailable at any one time may be
unknown and unpredictable.
To overcome this problem, an intermittently
available grid service could automatically
extend its lifetime whilst unavailable. When the
service is about to expire, the network
availability should be ascertained by polling a
component on the fixed network, potentially the
intermediary described in section 2.3. If the
network is unavailable, the service’s lifetime
should be extended. The process repeats when
the lifetime again expires. The intermittently
available service should also remain alive for a
period of time after reconnection; as long as is
required to ensure that, in all reasonable cases,
any stalled lifetime extension requests have
reached the service.
An intermittently available grid client may
ensure that all grid services in which it has an
interest are kept alive whilst the client is
unavailable. This involves instructing a third
party component on the fixed network to send
periodic ‘keep alive’ requests on the client’s
behalf whilst the client is unavailable. This third
party lifetime manager could co-ordinate across
several clients to periodically send just one
‘keep alive’ request on behalf of several
unavailable clients. Further, considering the
scenario where 10 intermittently available grid
clients are interacting with one grid service; a
third party lifetime manager need, in theory,
only act on behalf of the clients to keep the
service alive if all 10 clients are unavailable.
4.2 Handle Resolution
As already discussed in section 3.2, if a client
attempts to resolve a GSH to a GSR for a grid
service deployed on a temporarily unavailable
device using the normal mechanism, the
resolution will fail; in the worst case, this will
be interpreted as an indication that the grid
service has been destroyed.
To address this issue, a GSH to GSR
mapping should be placed in a third party
handle resolver service which is permanently
available on a fixed network. This third party
handle resolver allows handle resolution to take
place when an intermittently available service is
unavailable. In accordance with the OGSI
specification on GSH structure, the GSH for a
given intermittently available grid service
contains two pieces of information:
• URL of the home handle resolver service
• handle mapping key which identifies the
GSR in the handle mapping table.
Handle
resolution
for
intermittently
available grid clients is more problematic. It is
unlikely to be possible to cache, on the client
machine, all handle mappings which may be of
use to the client. Therefore the intermittently
available client should either perform handle
resolutions reliably, or the client may be
designed to interpret failed handle resolutions
as, potentially, a consequence of network
unavailability.
4.3 Service Data Notifications
As described in section 3.3, all notifications
produced by a temporarily unavailable grid
service will be lost. Similarly, all notifications
sent to a temporarily unavailable grid client will
be lost.
To guarantee the delivery of notifications
from an intermittently available grid service,
failed notifications should be queued for later
retry; this could be achieved by using this
framework described in section 2.3 to reliably
deliver notifications or alternatively a specialist
third party notification manager could be used.
Guaranteeing delivery of notifications to
intermittently available grid clients is more
problematic. The client must request that a
permanently available third party on the fixed
network queues any notifications which arrive
whilst the client is off-line. These queued
notifications can be resent once the client
becomes re-available.
Considering the situation where several
intermittently available grid clients request
notifications for the same piece of service data:
the third party could receive one notification
from the grid service and then distribute the
notification to each interested client. This both
provides reliable notification delivery and
reduces fixed network usage by combining a
notification delivered to several interested
parties into one invocation.
Under some circumstances, a client may
only be interested in the latest SD; any failed
notifications will be made redundant by
subsequent notifications. Therefore, a toolkit to
support grid service notifications over
intermittently available networks could,
optionally (at the request of the client or
specified by the service administrator), drop all
but the latest undelivered notifications.
5 WSRF Migration
This section looks at how the migration from
OGSI to WSRF effects the work presented in
this paper. Foster et. al. claim “The WSResource Framework retains essentially all of
the functionality present in OGSI...”
[Czajkowski et. al., 2004] and “...our
expectation is that the effort required to modify
an OGSI-based system or specification to use
WSRF will be small.” [Foster and Snelling,
2004].
5.1 Lifetime management
The lifetime management functionality in OGSI
has been replaced by the WS-Resource Lifetime
specification [Srinivasan and Banks, 2004].
Essential this retains the same functionality,
with an extendable termination time after which
the resource can be destroyed. Therefore the
mechanism for extending the lifetime of
intermittently connected OGSI services
described in this paper is still relevant to
intermittently connected WSRF resources.
5.2 Handle Resolution
The OGSI handle resolution functionality was
to be replaced by the WS-Renewable
References specification. However, in March
2005, a decision was made to drop the WSRenewable References specification. The WSAddressing [Box et. al., 2004] specification
defines the format of an endpoint reference,
however it is likely that these endpoints will be
discovered using some third party component,
such as a UDDI registry [Clement et. al., 2004].
Therefore the third party handle resolution
mechanism described in this paper is not
relevant to WSRF.
5.3 Notification Delivery
The WS-Notification family of specifications
[Vambenepe, 2004, Graham and Murray, 2004,
Chappell and Liu, 2004] have replaced the
OGSI notification functionality; however, these
specifications are not part of the WSRF
specification family, but rather apply generally
to web services. A service produces a list of
topics, to which a client can subscribe and
subsequently receive notifications about. To
support intermittently available WSRF resource
which make use of notification, some form or
reliable delivery is required, as with OGSI
notification.
6 Validation
The extensions described in section 4 have been
implemented and validated to ascertain the
viability of the approach. The implementation
of the work presented in this thesis builds on
and extends the functionality provided by GT3.
6.1 Lifetime Management
Implementing intermittently available service
lifetime management functionality required
modification to the GT3 source code which
performs standard lifetime management; on
lifetime timeout, the additional functionality
performs a network connectivity check and
extends the service’s lifetime appropriately. To
test the functionality, a simple test service has
been implemented.
The following test scenario was conducted:
a client invokes a factory to create a service
instance with a lifetime of 5 minutes. The client
then requests that the service instance be
artificially kept alive whilst unavailable,
extending the lifetime by 2 minutes with each
lifetime expiration; the first lifetime expiration
after a disconnection which caused at least one
lifetime expiration to occur, the service’s
lifetime is extended by 4 minutes, in-order to
allow any on route requests to be honoured. The
lifetime extension periods are not fixed at 2 and
4 minutes, but are chosen to best suit the service
in question. 30 seconds after the start of the test,
the service’s machine is disconnected for 10
minutes. Finally, once the service’s machine has
been
reconnected,
the
operation
‘testThisService’ is called, to ascertain if the
service is still alive. The same scenario is
repeated without the lifetime extension
functionality.
During the 10 minute period of network
disconnection, the service’s lifetime was seen to
expire 3 times. On each occasion the lifetime
was extended appropriately. On the first
expiration after reconnection, the lifetime was
seen to be extended by a further 4 minutes. The
service was seen to be available to the client 12
minutes after its creation. The service was seen
to be destroyed 15 minutes after its creation. By
comparison, a standard OGSI grid service with
no lifetime extension support, was seen to
timeout and be destroyed whilst unavailable (5
minutes after its creation); the service was
shown to be unavailable when invoked 12
minutes after its creation.
The results of test 1 showed that a number of
notifications had been lost whilst the network
was unavailable; test 2 showed all notifications
produced by the service being collected by the
client, despite periods of network nonavailability. However, some notifications were
seen to arrive out of order; when a service is
reconnected, new notifications are sent
immediately, whilst previous failed notifications
must await a timeout before being retried. If
order of notifications is important then a
notification ID could be used to reconstitute the
order at the receiving client.
6.2 Handle Resooution
This paper had described a number of
extensions to the OGSI standard which support
OGSI functionality in intermittently available
network environments. The work is motivated
by the potential for OGSI to usefully support
ubiquitous and mobile computing applications
which require the use of wirelessly connected
and therefore intermittently available devices.
This paper builds on earlier work which
produced a framework to seamlessly integrate
intermittently connected devices with a
traditional fixed OGSI grid infrastructure.
This paper has identified that reliable
invocation delivery alone is not sufficient to
fully support intermittently available OGSI grid
clients and services. There are a number of
requirements particular to OGSI idioms in
intermittently available network environments
which must be supported; specifically these are
handle resolution, lifetime management and
notification delivery.
This paper has proposed solutions to the
above stated requirements of OGSI grid clients
and services in intermittently available
environments: transient service lifetimes should
be extended whilst the service is disconnected;
handle mappings should be placed in a
permanently available handle resolver; and
notifications should be delivered reliably. A
prototype framework has been implemented
which demonstrates the viability of the
approach. The work described in this paper
together with the framework proposed in
[Hampshire, 2004] effectively extend OGSI to
new application areas such as mobile and
ubiquitous computing, thus widening the grid
user community.
To implement third party handle resolution, a
handle resolver service was implemented which
conforms to the OGSI specification. A number
of extension to GT3 where implemented which:
• Discover an appropriate third party handle
resolver. This was achieved using a
network scoped multicast discovery
protocol, although alternative mechanisms,
such as static configuration could have
been used.
• Produces a alternative to the standard OGSI
GSH which points to the newly discovered
third party handle resolver.
• Submits a handle mapping to the newly
discovered third party handle resolver.
A test service was implemented which uses the
modified version of GT3 to publish a third party
handle mapping. A test client was shown to be
able to retrieve a service’s GSR when the
service itself was unavailable.
6.3 Notification Delivery
To implement reliable notification delivery
functionality, a modified version of the GT3
notification sink stub class was implemented
which reliably delivers OGSI service data
notifications using the framework described in
[Hampshire, 2004].
A simple test service was implemented
which periodically modifies its own service data
and therefore delivers a notification to an
interested client application which records the
number of notifications received. The network
between client and service was intermittently
disconnected. Two test were conducted: test 1 in
which standard GT3 and therefore OGSI
semantics were used to deliver notification and
test 2 in which the modified version of GT3 was
used.
7 Conclusions
References
Banks, Tim, Srinivasan, Latha (2004), “Web
Services Resource Lifetime 1.2”, OASIS
Working Draft, June, 2004.
Barratt, Carl, et al. (2003) ,”Extending the Grid
to Support Remote Medical Monitoring”, UK eScience All Hands Meeting 2003.
Benford, Steve, Crout, Neil, Crowe, John,
Egglestone,
Stefan,
Foster,
Malcom,
Greenhalgh, Chris, Hampshire, Alastair, HayesGill, Barrie, Humble, Jan, Irune, Alex,
Laybourn-Parry, Johanna, Palethorpe, Ben,
Reid, Timothy and Sumner, Mark (2003), “eScience from the Antarctic to the Grid”, UK eScience All Hands Meeting 2003.
Booth, David, Haas, Hugo, McCabe, Francis,
Newcomer, Eric, Champion, Michael, Ferris,
Chris and Orchard, David (2004), “Web
Services Architecture”, W3C Working Group
Note, February 11, 2004.
Box, Don, Christensen, Erik, Curbera,
Francisco, Ferguson, Donald, Frey, Jeffrey,
Hadley, Marc, Kaler, Chris, Langworthy,
David, Leymann, Frank, Lovering, Brad, Lucco,
Steve, Millet, Steve, Mukhi, Nirmal,
Nottingham, Mark, Orchard, David, Shewchuk,
John, Sindambiwe, Eugène, Storey, Tony,
Weerawarana, Sanjiva and Winkler, Steve
(2004), “Web Services Addressing (WSAddressing)”, W3C Member Submission,
August 10, 2004.
Chappell, Dave, Liu, Lily (2004), “Web Service
Brokered Notifications 1.2”, OASIS Working
Draft, July, 2004.
Clement, Luc, Hately, Andrew, von Riegen,
Claus and Rogers, Tony (2004), “UDDI Version
3.0.2”, UDDI Spec Technical Committee Draft,
October 19, 2004.
Clement, Luc, Hately, Andrew, von Riegen,
Claus and Rogers, Tony (2004), “UDDI Version
3.0.2”, UDDI Spec Technical Committee Draft,
October 19, 2004.
Czajkowski, Karl, Ferguson, Don, Foster, Ian,
Frey, Jeff, Graham, Steve, Maguire, Tom,
Snelling , David, Tuecke, Steve (2004) “From
Open Grid Services Infrastructure to WSResource
Framework:
Refactoring
&
Evolution”
Foster, Ian and Kesselman, Carl (1999), “The
Grid: Blueprint for a New Computing
Infrastructure”, Morgan Kaufmann, 1999.
Foster, Ian, Snelling, David (2004), “WSResource Framework: Frequently Asked
Questions”,
http://www.globus.org/wsrf/faq.asp#wsrf9
(verified 16th March 2005).
Frey, Jeffery, Graham, Steve, Czajkowski, Karl,
Ferguson, Don, Foster, Ian, Leymann, Frank,
Nally, Martin, Storey, Tony, Tuecke, Steve,
Vambenepe, William and Weerawarana,
Sanjiva (2004), “Modelling Stateful Resources
with
Web
Services”,
http://www106.ibm.com/developerworks/library/wsresource/ws-modelingresources.html (verified
15 June 2004).
Graham, Steve, Murray, Bryan (2004), “Web
Service Base Notifications 1.2”, OASIS
Working Draft, June, 2004.
Hampshire, Alastair (2004), “Extending the
Open
Grid
Services
Architecture
to
Intermittently Available Wireless Networks”,
UK e-Science All Hands Meeting 2004.
Sotomayor, Borja (2004), “The Globus Toolkit
3
Programmer's
Tutorial”
http://gdp.globus.org/gt3tutorial/singlehtml/progtutorial_0.4.3.html
(verified 12/05/05).
Tuecke, S., Czajkowski K., Foster, I., Frey, J.,
Graham, S., Kesselman, C., Maguire, T.,
Sandholm, T., Vanderbilt, P. and Snelling, D.
(2003), “Open Grid Services Infrastructure
(OGSI) Version 1.0”. Global Grid Forum Draft
Recommendation, 27 June 2003.
Vambenepe, William (2004), “Web Service
Topics 1.2”, OASIS Working Draft, July, 2004.