[ogsa-wg] FW: [dais-wg] WSRF Embodiments and DAIS

[Dave Berry]

FYI, the DAIS WG has raised the following issues with the OASIS WSRF
group.
 
-----Original Message-----
From: Susan Malaika [mailto:malaika at us.ibm.com] 
Sent: 17 December 2004 10:21
To: dais-wg at gridforum.org; wsrf at lists.oasis-open.org
Subject: [dais-wg] WSRF Embodiments and DAIS




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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20041218/2676370b/attachment.html