FYI,
the DAIS WG has raised the following issues with the OASIS WSRF
group.
The Oasis WSRF group asked the GGF DAIS working group to
consider the WSRF "WSDL 1.1 Binding Element Embodiment". An item was
posted to the DAIS mailing list entitled "DAIS mapping and WSRF embodiments" on
23 November 2004. There has been discussion among the DAIS community on the use
of the WSRF embodiments. Some of the DAIS community involved in the
discussions are the implementers of the first open source version of DAIS known
as OGSA-DAI; they are the first users of DAIS; they are active in promoting DAIS
among data grid communities around the world. These are some interim
conclusions:
1. Multiple kinds of DAIS Users
It is
still not clear if DAIS should mandate WSRF because some of the participants in
the DAIS group rely on non-WSRF middleware. DAIS could go some way towards
satisfying WSRF and non-WSRF users by placing the resource identifier in the
DAIS messages (so a single DAIS message format could be used by both WSRF and
non-WSRF DAIS users).
A note on resource properties:
- Resource properties requests cannot include resource identifiers in
the message body. The resource identifier must be placed in the
header.
A suggestion for the WSRF group :
- It would be helpful to know if specifying a resource identifier in the
DAIS messages as well as in the header is acceptable to the WSRF folk.
2. Multiple resources in a single request (see
below for use cases)
Currently, each DAIS service request accesses a
single resource, and the resource being accessed determines the underlying
resources that should be accessed too, e.g., the exposed single resource can
perform resource name mappings . In this case, the WS-Resource concept may (or
may not) be used to represent the exposed resources in DAIS. (depending on
whether DAIS adopts WSRF)
In some proposed extensions and
applications of DAIS, multiple resources of different types are accessed through
a single service request. It is required that the multiple resources be visible
to the client. The WS-Resource concept could be used to represent a
collection of resources. An identifier to represent the collection could be
placed in the header, while the individual resource identifiers in the
collection could appear in the message content.
A note on resource
properties:
- Resource properties requests could result in properties for all the
resources in the collection being examined. (see below for alternatives for
representing the resource properties documents)
A
suggestion for the WSRF group :
- It would be helpful to know if representing a collection of resources
as a WS-Resource is a recommended use of
WSRF.
3. WSRF "WSDL 1.1 Binding
Element Embodiment"
If DAIS does adopt WSRF then the "WSDL 1.1
Binding Element Embodiment" is helpful because it permits a client
supplied resource identifier to appear in the message header (in other
words the resource identifier is not opaque to the client). However note that
there are client side prerequisites for the "WSDL 1.1 Binding Element
Embodiment", e.g., the client software would have to know to place the resource
identifiers in the right place in the header
A suggestion for
the WSRF group :
- It would be helpful to know if there are any tools that support
embodiment "WSDL 1.1 Binding Element
Embodiment"
.................................................................
Use
Cases
.........
Here are some use cases for multiple
resources in a single request:
U1. In an interaction with a
DAIS service, many resources may be created to represent the results of
requests. There may come a time when several of these resources can safely
be removed. In such a setting, the options are to:
U1.1. Invoke something like "remove() => EPR representing resource"
for
each of the resources.
U1.2 Invoke something
like "remove([EPR representing resource-1, ...,EPR
representing
resource-n]) => EPR representing service" once.
How would
option U1.2 be modeled through WSRF?
U2. In an interaction
with a DAIS service, it may be necessary to aggregate multiple results sets and
return the combined result set via ftp. In such a setting, the options are
to:
U2.1 Invoke something like "ftp (..) => EPR for resource1"
for each of the resources and then aggregate the results on the client
U2.2 Invoke something like :
- "aggregate ([EPR representing resource-1, ...,EPR
representing resource-n]) => EPR representing service"
- "ftp (..) => EPR representing aggregated
resource"
(the result aggregation would be done at the
server.)
How would option U2.2 be modeled
through WSRF?
(BTW it is possible that a combined aggregate and ftp operation would
be desirable)
U3. In an interaction with a DAIS
service, it may be necessary to issue a query over multiple databases and files.
In such a setting, the options are to:
U3.1 Invoke something like "query (..) => EPR for resource1"
for each of the resources, returning each query result to the client,
and then aggregate the results on the client
(the result aggregation process could be very complex.)
U3.2 Invoke something like "copy (..) => EPR for
resource1" for each of the resources and then issue the queries locally
on the client
(this means having a query engine on the client.)
U3.3 Invoke something like "query([EPR representing
resource-1, ...,EPR representing resource-n]) => EPR representing service"
once
(the query result aggregation would be done at the server.)
How would option U3.3 be modeled through WSRF?
Alternatives for modeling resource properties documents
for U1.2, U2.2,
U3.3
.............................................................................
<ResourceNames>
<ResourceName>resource1</>
<ResourceName>resourceX</>
</>
Or as complex as
<Resources>
<Resource>
<ResourceName>resource1</>
<ResourceType>RDB</>
<ResourceSchema>....</>
</>
<Resource>
...
</>
</>
A suggestion for the WSRF group :
It would be helpful to know which modeling approach is
preferred
Thanks to everyone who contributed and reviewed
this note. Happy Happy Holiday Season :-)
Susan
Malaika