A new Architecture for OGSA-DAI
Atkinson, M.1, Karasavvas, K.1, Antonioletti, M.2, Baxter, R.2, Borley, A.3, Chue Hong, N.2, Hume, A.2, Jackson, M.2,
Krause, A.2, Laws, S.3, Paton, N.4, Schopf, J. M.5, Sudgen, T.2, Tourlas, K.1 and Watson, P.6
1
National e-Science Centre, 15 South College Street, Edinburgh EH8 9AA, UK
EPCC, University of Edinburgh, James Clerk Maxwell Building, Edinburgh EH9 3JZ, UK
3
IBM United Kingdom Ltd, Hursley Park, Winchester S021 2JN, UK
4
School of Computer Science, University of Manchester, Oxford Road, Manchester M13 9PL, UK
5
Mathematics and Computer Science Division, Argonne National Laboratory, Argonne, IL 60439, USA
6
School of Computer Science, University of Newcastle upon Tyne, Newcastle upon Tyne NE1 7RU, UK
2
Abstract
OGSA-DAI is a widely used middleware infrastructure, aligned with the Global Grid Forum’s (GGF)
OGSA vision, to facilitate uniform access to data resources using a service-oriented architecture (SOA).
It is intended to provide a reference implementation of WS-DAI. Initially OGSA-DAI was based on
the OGSI infrastructure but recent releases support WS-I, WS-I+, and WSRF. The change to these new
specifications raised new issues and requirements. It has been taken as an opportunity to review all
aspects of OGSA-DAI. This paper describes the new architecture for future releases and its rationale.
1
Introduction
The Open Grid Services Architecture – Data
Access and Integration (OGSA-DAI) project [1]
was established to provide a uniform way to
access data resources in alignment with OGSA
[2]. It enables client applications to submit
request documents in order to perform a set of
tasks on a remote data resource. The initial
versions of OGSA-DAI were built using the
OGSI infrastructure [3] provided by GT3 [4].
More recently OGSA-DAI has been released on
Axis [5], based on WS-I [6], the OMII_1
infrastructure [7], based on WS-I+ [8] and on
GT4 [9] based on WSRF [10]. OGSA-DAI
provides activities to access relational, XML
databases, and indexed files. It also provides
data translation and third-party delivery
activities. This activity framework provides
extensibility so that application developers can
add their own activities. OGSA-DAI will
provide a reference implementation of WS-DAI
[11]. This paper describes the architectural
requirements for future releases, the new
architecture’s functionality and components and
presents its rationale.
1.1
OGSA-DAI relied on the factory pattern to
create independent grid services with a one-toone relationship with the data they were
handling. This meant that grid service handles
provided a data naming system, failures were
localised to a particular session and that
persistence was only required for the accessed
and handled data.
1.2
New Requirements
The change from OGSI to WS-I+ and WSRF
demands a change in the architecture as web
services must now be considered long-running.
For example, the SIMDAT [13] project believes
its requests will run for several hours and
requires concurrent requests [14]. This change
has been taken as an opportunity to review all
aspects of the OGSA-DAI, taking into account
performance and operational issues uncovered
through extensive use. The following
architectural requirements were considered:
•
•
Experience
OGSA-DAI has over 1100 registered users [12]
including projects which require continuously
available data access and integration services.
The architecture of the early versions of OGSADAI was based on the assumption that web
services were light-weight. For example, it
assumed that new web services could be
launched to handle each session between a data
resource and a client. Similarly, it assumed that
a new service could be produced to handle each
data transfer to a data consumer. As a result
All of the existing activities and
facilities should continue to be
supported.
Each data service must support zero or
more data resources (DRs) – dynamic
configuration may add and remove
DRs.
•
This exposes complex naming
requirements to name DRs and to use
name systems provided by DRs.
•
Each data service should be resilient to
failures within activities and the data
resources they access.
•
Each data service should be
configurable on installation and
reconfigurable during operation.
•
Each data service should be
manageable and persistent, i.e. they
should recover after site, platform and
internal failures.
•
The
same
architecture
should
accommodate rapid requests for small
tasks (execution of an activity) and
tasks involving large volumes of or
continuous streams of data.
•
The data services should support
concurrent sessions and transactions.
•
The power of request documents
should be extended – to support a
broader set of data sources and
operations.
•
The data services should be able to
accommodate standard interfaces such
as transaction coordination services.
•
The data resources should be an
additional OGSA-DAI extensibility
point to allow the dynamic exposure of
new virtual data resources, e.g. to
support an OGSA-DQP [15] federation.
•
The extensibility framework based on
activities should be stabilised to protect
application developer investment –
taking into
requirements.
account
the
above
This architecture must be amenable to
implementation over a number of platforms
(WS-I/Axis, WS-I+/OMII, WSRF/GT4 and
other systems of interconnecting services) and
must be achieved incrementally without undue
disruption of the development process. The
further development of data integration
activities must also continue.
The new architecture should protect application
development investment. A client-side API
already hides variations in the web service
infrastructure so that investment in client
applications is protected from change and the
clients can be used unchanged on all new
versions of OGSA-DAI. A new context will be
defined for activities. In this case, OGSA-DAI
provides a container for the activities developed
by application programmers. It is intended that
the APIs in this context will remain stable and
will protect the activities from web service
infrastructure variations.
2
Overview of Architecture
The primary components of
architecture are shown in Figure 1.
Figure 1: New OGSA-DAI Architecture
the
new
The architecture looks forward to multiple data
services administered through a consistent
regime. In the figure we can see three data
services: one serves OGSA-DAI, one serves the
WS-DAI standard [11] perhaps as a
configuration of OGSA-DAI and one serves
Mobius [16].
2.1
Data Resources
By data resource (DR) we mean any entity that
can act as a source and/or sink of data together
with its associated management framework.
Currently, OGSA-DAI works with six relational
DBMS, two native XML DBMS, file systems,
and indexed files. Its scope however is more
general.
OGSA-DAI provides an extensible framework
that allows flexible representation of a data
resource. The latter need not be a single
physical resource, e.g. RDBMS, but they could
also represent complex virtual data resources.
For example, a federation of many physical data
resources can be represented as a single virtual
data resource. This allows for new data
resources to be easily added to OGSA-DAI, like
streamed data [17], or indeed any kind of entity
that can act as a data source and/or sink.
2.2
2.3
Activities and Tasks
Because of the large and extending variety of
data resources, it is necessary to devise an openended scheme for attaching data resources and
introducing the languages and operations they
support. We do this by providing activities, each
of which may address a different resource in an
appropriate language. They all fit in a consistent
framework.
In OGSA-DAI, an activity represents the basic
unit of work. A task is the execution of an
activity on some specified data with specified
parameters. Activities can provide any kind of
functionality but they can roughly be
categorised into three main functional groups:
(a) statement activities that provide access to
DRs (e.g. sqlQueryStatement, xPathStatement),
(b) translation activities that perform
transformation on the data (e.g. xslTransform,
zipArchive), and (c) delivery activities that
deliver or collect data to/from third-parties (e.g.
deliverToURL, deliverFromGFTP).
We differentiate between three types of
activities:
1.
Core activities: simple activities that
deal
with
internal
OGSA-DAI
functionality. These activities cannot
be overridden. For example, activities
that initiate an OGSA-DAI session or
transaction (see later sections).
2.
Supplied activities: current activities
provided in OGSA-DAI releases –
these may be overridden, e.g. when
testing a new version.
3.
Extension activities: written by
community developers for specific
purposes, e.g. for a new data resource
or an application-dependent data
transformation.
Potentially,
these
activities could override the supplied
activities.
Data Services
A data service (DS) provides the entry point for
clients who want to access data resources. It can
be discovered using a registry or from a DRAM
(see section 2.10). A data service could expose
zero – in case it only provides data translation
and/or delivery functionality – to many data
resources. A DS can be dynamically configured.
For example, new data resources can be added
dynamically or the authorisation settings to
access the DR(s) could be changed.
As we mentioned in the introduction, OGSADAI is built to support many different
platforms/specifications. For each one the client
would need to make the appropriate (SOAP)
requests depending on the DS. However,
OGSA-DAI provides a client-side library – the
client toolkit (CTK), which offers a
programming abstraction and provides a
common interface to all these platforms, i.e. the
same code can be used whether accessing an
OGSA-DAI WS-I or WS-RF data service.
Developers need only learn the application
programming interface (API) provided by the
client toolkit to access any OGSA-DAI data
service.
OGSA-DAI provides an extensible activity
framework. Developers can easily add their own
(extension) activities according to their needs.
This has proved to be a particularly flexible and
valuable extension point. In the new
architecture, it is enhanced to support additional
functionality, for example, permitting extension
activities to use session information, engage in
transactions and write diagnostic or audit
information to logs. The new architecture also
requires notifications be produced by activities
to permit monitoring, accounting and failure
detection.
Request for the execution of a number of
activities can be grouped together into a
document and sent to a data service into a single
message.
2.4
TADD, Requests and Results
A Task And Data Document (TADD) permits a
number of tasks to be specified, together with
their parameters, inputs, outputs, data flow
between them and control flow. This composite
format can be used to submit simple requests, to
avoid unnecessary round-trip latencies, to report
status and results, and to delegate or cascade
work. Its ability to contain data (e.g. for a bulkload activity) further reduces communication
that would be needed, for example, to collect
the data to bulk-load. A TADD can be used as
both a request and a result document, hence the
change of name from Request Document in the
previous architecture.
Control flow allows a client to specify the order
of task execution and which tasks can be run in
parallel. Data flow allows the connection
between activities to create pipelines for
efficient data processing, using streamed
interconnections between activities.
Each activity can support one or more
languages that define the request. For example,
SQL statement activity will accommodate any
dialect or version of SQL that the targeted data
resource will process. The XSLT transformation
activity takes XSLT and so on. This permits
clients to exploit any special properties of a data
resource or data transforming activity. It has the
downside that clients are not protected from the
variations that are common among relational
databases. In most current use the clients choose
data sources and are aware of the dialect used.
We are investigating the use of SwisSQL [18]
for code which requires independence from
target data resource.
It is worth noting that the client developers are
not expected to craft TADD documents by hand.
Instead, the client toolkit is used, which
provides an API to hide the details of a
request’s (TADD) format from developers – for
example they need not know or write any XML
to formulate requests. In addition, the client
toolkit shields developers’ code from future
changes to the TADD’s format and structure.
2.5
•
to accommodate external decisions, e.g.
intermediate results are stored in the
session and the client can decide how
the process continues,
•
retain results awaiting delivery or
collection (see later section on DIDs),
•
retain transactional information, and
•
retain security information, localised
identifiers, connection information
caches, and similar data.
Sessions are OGSA-DAI internal entities. For a
request to join a session the TADD will contain
the appropriate information, e.g. the session
identifier (SID). SIDs can be one of three types.
First, implicit SIDs, when the request contains
no information about sessions. This provides
backwards compatibility and simplicity for
single request sessions. In this case, a session
will be created only for this request. A request
containing an explicit OGSA-DAI session
identifier will join that session and it will be
able to access (and store) state to it. Finally, the
request can contain information for a new SID
(session) to be created. Such a request can also
contain session configuration parameters
(lifetime,
authorisation,
etc.).
Session
functionality will also be managed by the
appropriate core activities (e.g. createSession).
2.6
Transactions
Transactions are fundamental for many
techniques to ensure the integrity of a resource.
Two main applications are dealing with
potential
inconsistencies
introduced
by
concurrent access and recovery from failures in
case the system crashes or an error occurs while
executing a transaction. A transaction groups a
number of activities into one unit of execution
(e.g. for atomicity). Moreover, a single activity
might contain multiple lower-level operations.
These, also have to be transactional.
Transactional state is stored in a session.
OGSA-DAI will provide a consistent
transactional framework and facilities to allow
developers to add transactional behaviour to
their activities. This includes:
•
a backward-compatible and uniform
way to describe transactional metadata
and behaviour for each activity and for
each exposed data resource that
supports transactions,
•
the logical rules for combining the
behaviour of transactional activities
Sessions
A session allows sharing and management of
state (context) between several TADDs. Sharing
state enables us to:
and activities that access transactional
DRs, and
•
a set of core activities to manage
transactional behaviour (e.g. a
commitTransactionActivity).
The progress of a transaction will be recorded to
a transactional log that will be later used by the
recovery component to restore the DS and its
underlying resources to a consistent state.
A transaction coordinator component in the DS
will enable distributed transactions within that
DS, i.e. when a DS exposes multiple resources
and the TADD contains a transactional request
involving more than one resource. In addition,
we can have a distributed transaction involving
multiple DSs. In such a scenario there usually
are external coordinators to orchestrate
interactions between the participants (DSs).
Activities performed as a session or as the result
of an individual request document may be part
of some distributed transaction coordinated by a
standard coordination protocol. It is therefore
necessary to support the interfaces, functionality
and protocols required by a standard distributed
transaction coordinator, such as WSAtomicTransaction (WS-AT) [19] (also see
section 2.9).
2.7
DIDs
Data Identifiers (DIDs) are used to describe the
handling of intermediary and externally
available results. Data identified by DIDs can
contain the data provenance information, the
format the data is in, as well as the data itself.
DIDs are stored in a session, so that other tasks
in a request or subsequent requests that join the
session can access them. Although, DIDs
lifetime is that of the session, a set of core
activities will allow the client to further manage
them. For example, the client would be able to
discard a DID or make it externally visible by
creating a universally unique DID (UUDID)
that may outlive the session and be accessed by
an incremental data access protocol, such as
ByteIO [20] or by other sessions.
2.8
ODE
Data Services (DS) have at their core the
OGSA-DAI Engine (ODE) that provides a
framework for activity and task management.
The ODE is being revised to support dynamic
configuration, sessions, transactions, recovery
and concurrency.
The model of execution can be seen in more
detail in Figure 2. The response to a request is
generated by the ODE within a session, which is
either created of joined as we assume in the
diagram. The ODE analyses incoming TADDs
conducts authentication and constructs an
internal representation of the request (e.g. a
directed acyclic graph (DAG)). The Task Form
encapsulates data about authorisation, external
relationships, e.g. client identity, and so on, so
these may be used abstractly by tasks. The tasks
specified in the DAG are then checked for
authorisation over the authenticated user’s
privileges.
Figure 2: OGSA-DAI Engine Execution
Model
Further analysis and optimisation of the task
DAG would create an optimised execution plan
that would then be evaluated. Evaluation is
overseen by an internal monitoring system to
detect excess resource consumption and provide
resilience. The following figure illustrates the
internals of an execution coordination thread.
Figure 3: Execution Coordination Thread
A request can be part of a transaction, in which
case, appropriate measures can be taken. Then,
the result TADD (could be more than one) is
created so that it can be later populated and
potential third-party collections are initiated as
soon as possible. The optimised execution plan
is then evaluated by spawning activity threads
(according to the TADD’s control and data flow
description) which use pipes and a Transfer
Assembler pattern [21] to handle arbitrary scale
intermediates and results respectively. Thirdparty deliveries could be started as soon as data
are available and on activities completion the
result TADD(s) are populated with each
activity’s data and execution statuses as
appropriate. Finally, cleaning up takes place,
discarding state in terminating sessions,
informing the monitoring system of completion,
etc. and the result TADD is sent back to the
requester. Hibernation retains transaction and
session state in non-terminating cases. Lifetime
management is required over hibernated state to
avoid permanent resources loss when clients fail.
We are considering pooling mechanisms to
reduce initialisation overheads.
2.9
Special Interfaces
An important requirement is a DS’s ability to
accommodate standard web service interfaces,
particularly WS-DAI, or interfaces that require
specific message protocols, such as distributed
transactions coordination protocols (e.g. WSAtomicTransaction [19]). These special
interfaces will be implemented by binding their
ports to code that constructs an equivalent
execution graph. The results produced as a
TADD by the transfer assembler will be
translated to the expected result format. As a
matter of principle such functions should also
be available through a standard activity in a
TADD. Conversely, activities that workflow
enactments may require should also appear via
“standard” WSDL-defined ports. In this way,
functions required by one community via a
special
interface,
e.g.
WSRF
getResourceProperties, will also be available as
a task in a request document.
2.10 DRAM: Configuration and
Monitoring
The Data Resource Access Manager (DRAM)
is a persistent service that provides
administrator and management interfaces for a
set of data services. It provides the ability to
initiate and configure a DS as well as
monitoring and controlling it. For example, a
DRAM would know if the DSs that it manages
are still running and it will also be able to
reconfigure them to support an additional data
resource (DR). A DRAM will monitor a DS’s
status digest produced by its internal monitor. If
this shows potential problems it may
reconfigure or restart the DS from its last
checkpoint.
A DRAM can be discovered via a registry and it
constitutes a gateway to a set of DRs. It could
contain explicit DR names or use further
registries to get available resources. A DRAM
will have access to processing resources – like
single or multi-processor (SMP) machines,
processing farms, etc. – and can initiate and
configure a DS, on its available computational
resources, to access one or more of its supported
data resources. Data services supported by a
DRAM would be OGSA-DAI, Mobius, other
federation and integration services or indeed
any other service that exposes data resources.
The initial configuration of a data service is
described in the Data Service Description
Language (DSDL). Most aspects of a DS will
be described by this XML file, which should be
built as much as possible from existing
standards, such as Management of Web
Services (MOWS) [22]. Elements of DSDL will
include the type – and potentially configuration
– of a data service (e.g. OGSA-DAI), the DS’s
longevity, the name or description of a data
resource, and quality of service and security
requirements.
2.11 Naming
A name is used to identify an entity. The OGSA
work on naming [23] distinguishes between
three layers for names; human names (easily
generated and read by humans), which are
mapped to abstract names (persistent and
globally unique names), which are in turn
mapped to addresses (the physical locations of
the identified entities). Entities that need to be
named in OGSA-DAI include: registries, DSs,
DRs, DRAMs, sessions, transactions, result sets
(DIDs, UUDIDs), TADDs, activities and tasks.
There are many challenges involved in naming
data. Not only is there a large number of data
collections, but there are also many individual
naming systems - per technology provider (OS
and DBMS), per project, organisation or
community and those invented by individuals.
Moreover, there are many data values, such as
data sets awaiting delivery, which maybe
needed to be named, e.g. publicly as a UUDID
or privately for logs, audit trails and diagnostics,
where a UUID may suffice. The relationships
between names are complex, for example with
synonyms, names of copies and names of a
subset of some larger, possibly mutable, data set.
Architecturally, OGSA-DAI must accommodate
the naming schemes in use in the context in
which it is being applied and must meet
standard requirements, as well as application
requirements. This is more significant in the
new architecture as multiple data resources are
accommodated within on data service (for
efficiency and management reasons). This then
requires TADDs to contain tasks that operate on
a specified DR. This will be achieved by
including a name in the task specification. To
achieve backwards compatibility and to
accommodate standard protocols not equipped
with names, it is necessary to set a default DR.
This can be done at configuration time or within
a session or request using a core activity.
The current evaluation plan is to experiment
with handle.net [24] and then to accommodate
the OGSA naming standards. We anticipate that
the generality of handle.net is sufficient to meet
all of these requirements.
The cost of name resolution, possibly through
intermediate names could be high. However, the
DS can have a local resolver for all of its local
DRs and incrementally populate this by
interrogating data sources (such as file stores
and DBMS) as names are introduced in the
sequences of TADD messages. Caching can
reduce the mapping costs of external names, for
example those used in third-party transfers.
It is sensible to allow clients to reduce name
resolution costs by requiring that the language
design principle of substitutability is adhered to
in the syntax of TADDs. That is, wherever a
name is permitted, it should be possible to
substitute an address (represented as WSAddress) and in most cases, where the
resolution mapper can be reliably inferred, the
inverse is also true.
3
Status and Future Work
In the upcoming OGSA-DAI release 7, data
services
are
(re)configurable,
provide
concurrency, and support sessions and
transactions (first implementation stage of a
well-defined phased implementation plan). In
addition, all existing activities and functionality
are still supported, while a new extensibility
point, that of adding data resources dynamically,
has been added. A detailed status report
including benchmarks can be found in [12].
The next few releases of OGSA-DAI will
complete the engineering of this architecture
and exploit it with new data activities and data
resources. New activities will include interfaces
to other data stores, distributed query, resilient
multi-source unions, schema and data
integration, standard tools for extracting data
from files, and standard computations, such as
statistical analyses.
We expect to invest significant effort in
engineering good performance. This will
include improving parallelisation of data flow
and investigation of improved structured data
transfer formats, e.g. based on SOAP Message
Transmission
Optimization
Mechanism
(MTOM) [25] and Data Format Description
Language (DFDL) [26]. There are difficult
trade-offs between translation costs, transfer
costs and simple APIs for activity developers.
High-performance systems will need to be
closely coupled to data management and storage
systems. Integration with widely used
authorisation systems, e.g. Shibboleth [27],
accounting systems, portals, e.g. GridSphere
[28] or WebSphere [29], and diagnostic tools is
called for. It remains to be seen whether the
planned architecture will meet all of those needs
as we hope.
The activity framework is a powerful
mechanism for extension and for managing
complexity. It also provides a framework in
which to manage contributed extensions to
OGSA-DAI. In the longer-term we anticipate
dynamically installing extension activities
delivered via requests from clients planning to
use them. This will support incremental
development of continuously operating data
services and performance gains from moving
relatively small volumes of code to relatively
large volumes of data. However, this will
depend on the activity framework providing a
robust container and safety net.
4
Conclusions
In this paper we presented the OGSA-DAI’s
architecture evolution as it progresses to comply
with new specifications and service-oriented
architecture requirements in an open and highly
dynamic environment. First, we discussed the
rational for the change and a set of required
functionalities. Then, we presented an overview
of the architectural components and described
each one, the functionality it provides, and its
purpose within the overall design. Finally, we
concluded with a brief status report and future
directions.
Acknowledgements: This work is supported by
the UK e-Science Core Programme and in part
by the Mathematical, Information, and
Computational Sciences Division subprogram
of the Office of Advanced Scientific Computing
Research, Office of Science, U.S. Department
of Energy, under Contract W-31-109-ENG-38.
We also gratefully acknowledge the input of our
past and present partners and contributors to the
OGSA-DAI project including: IBM Corp. and
Oracle UK.
IBM and DB2 are trademarks of International
Business Machines Corporation in the United
States, other countries, or both. Java and all
Java-based trademarks are trademarks of Sun
Microsystems, Inc. in the United States and
other countries. Other company, product, or
service names may be trademarks or service
marks of others.
© Copyright International Business Machines
Corporation, 2005. © Copyright The University of
Edinburgh, 2005. © Copyright University of
Manchester, 2005. © Copyright University of
Newcastle upon Tyne, 2005.
5
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
References
Antonioletti, M., Atkinson, M, Baxter, R.,
Borley, A., Chue Hong, N., Collins, B.,
Hardman, N., Hume, A., Knox, A., Jackson,
M., Krause, A., Laws, S., Magowan, J.,
Paton, N., Pearson, D., Sugden, T., Watson,
P. and Westhead, M., The design and
implementation of Grid database services
in OGSA-DAI. Concurrency and
Computation: Practice and Experience,
2005. 17(2): p. 357-376.
Foster, I., Kishimoto, H., Savva, A., Berry,
D., Djaoui, A., Grimshaw, A., Horn, B.,
Maciel, F., Siebenlist, F., Subramaniam, R.,
Treadwell, J. and Von Reich, J., The Open
Grid Services Architecture, Version 1.0.
2005.
Tuecke, S., Czajkowski, K., Foster, I., Frey,
J., Graham, S., Kesselman, C., Maquire, T.,
Sandholm, T., Snelling, D. and Vanderpilt,
P., Open Grid Services Infrastructure,
Version 1.0. 2004.
Globus, Globus Toolkit 3.2.1. 2004.
Apache, Axis. 2005.
WS-I, Web Services Interoperability, Basic
Profile 1.0. 2004.
OMII, OMII_1. 2005.
Atkinson, M., DeRoure, D., Dunlop, A.,
Fox, G., Henderson, P., Hey, T., Paton, N.,
Newhouse, S., Parastratidis, S., Trefethen,
A., Watson, P. and Webber, J., Web Service
Grids: an evolutionary approach.
Concurrency and Computation: Practice
and Experience, 2005. 17(2): p. 377-390.
Globus, Status and Plans for the Globus
Toolkit 4.0 (GT4) as of May 1 2005. 2005.
OASIS, WS-ResourceFramework. 2005.
Antonioletti, M., Atkinson, M., Laws, S.,
Malaika, S., Paton, N., Pearson, D. and
Riccardi, G. Web Services Data Access and
Integration (WS-DAI). in 13th Global Grid
Forum. 2005. Seoul, Korea.
Antonioletti, M., Atkinson, M., Baxter, R.,
Borley, A., Chue Hong, N., Dantressangle,
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
P., Hume, A., Jackson, M., Karasavvas, K.,
Krause, A., Laws, S., Parsons, M., Paton,
N., Schopf, J., Sugden, T., Tourlas, K.,
Watson, P. and Vyvyan, D. OGSA-DAI
Status and Benchmarks. in UK e-Science
All Hands Meeting (to appear). 2005.
Nottingham, England.
SIMDAT, Consolidated Requirements
Report, Roadmap and SIMDAT
Infrastructure Design. 2005.
Borley, A., Personal Communication
(SIMDAT). 2005.
Alpdemir, N., Mukherjee, A., Gounaris, A.,
Paton, N. W., Watson, P., Fernandes, A. A.
A. and Fitzgerald, D. J. OGSA-DQP: A
Grid Service for Distributed Querying on
the Grid. in Ninth International Conference
on Extending Database Technology
(EDBT). 2004.
Hastings, S., Langella, S., Oster, S. and
Saltz, J. Distributed Data Management and
Integration Framework: The Mobius
Project. in GGF11 Semantic Grid
Applications Workshop. 2004. Berlin,
Germany.
Plale, B., Framework for Bringing Data
Streams to the Grid. Scientific
Programming, 2004. 12(4).
AdventNet, SwisSQL. 2005.
WS-AT, Web Services Atomic Transaction.
2004.
GGF, Byte-IO Working Group. 2005.
Gamma, E., Helm, R., Johnson, R. and
Vlissides, J., Design Patterns. 1995:
Addison-Wesley Professional.
OASIS, Web Services Distributed
Management: Management of Web
Services (MOWS). 2005.
Grimshaw, A., Naming in Distributed
Systems (OGSA Naming Design Team
working note OGSA-Naming-02). 2004.
Sun, S., Lannom, L. and Boesch, B.,
Handle System Overview, in Request for
Comments 3650. 2003, Internet
Engineeting Task Force (IETF).
W3C, SOAP Message Transmission
Optimization Mechanism. 2005.
GGF, Data Format Description Language
Working Group. 2005.
Internet2, Shibboleth Technical Overview.
2005.
Novotny, J., Russell, M. and Wehrens, O.
GridSphere: A portal framework for
building collaborations. in The First
International Workshop on Middleware for
Grid Computing. 2003.
IBM, WebSphere. 2005.