Fwd: [dais-wg] WSRF Embodiments and DAIS

Ian Foster foster at mcs.anl.gov
Tue Dec 21 07:20:53 CST 2004


I wanted to ask if I could get some clarification regarding the concerns of 
the DAIS-WG relating to the use of WSRF.

When you talk about "non-WSRF middleware", you seem to be concerned in 
particular about clients. Now the only requirement beyond WS-I compliance 
that is placed on a client of a WSRF service is that it support 
WS-Addressing, and WS-Addressing is widely supported by essentially all 
major Web services implementations: Axis, BEA, IBM, Microsoft at least. 
Thus, this doesn't seem to me to be a major concern.

Are there other concerns that you have?

Ian.


>>>Delivered-To: grdfm-dais-wg-outgoing at mailbouncer.mcs.anl.gov
>>>X-Original-To: grdfm-dais-wg at mailbouncer.mcs.anl.gov
>>>Delivered-To: grdfm-dais-wg at mailbouncer.mcs.anl.gov
>>>X-Greylist: delayed 1340 seconds by postgrey-1.16 at 
>>>mailbouncer.mcs.anl.gov; Fri, 17 Dec 2004 04:47:14 CST
>>>Importance: Normal
>>>Sensitivity:
>>>Subject: [dais-wg] WSRF Embodiments and DAIS
>>>To: dais-wg at gridforum.org, wsrf at lists.oasis-open.org
>>>X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
>>>From: Susan Malaika <malaika at us.ibm.com>
>>>Date: Fri, 17 Dec 2004 02:21:15 -0800
>>>X-MIMETrack: Serialize by Router on D03NM123/03/M/IBM(Release 6.51HF338 
>>>| June 21, 2004) at
>>>  12/17/2004 03:21:20
>>>X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at 
>>>mailbouncer.mcs.anl.gov
>>>Sender: owner-dais-wg at ggf.org
>>>X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at 
>>>mailbouncer.mcs.anl.gov
>>>
>>>
>>>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
>>
>>_______________________________________________________________
>>Ian Foster                    www.mcs.anl.gov/~foster
>>Math & Computer Science Div.  Dept of Computer Science
>>Argonne National Laboratory   The University of Chicago
>>Argonne, IL 60439, U.S.A.     Chicago, IL 60637, U.S.A.
>>Tel: 630 252 4619             Fax: 630 252 1997
>>         Globus Alliance, www.globus.org
>
>_______________________________________________________________
>Ian Foster                    www.mcs.anl.gov/~foster
>Math & Computer Science Div.  Dept of Computer Science
>Argonne National Laboratory   The University of Chicago
>Argonne, IL 60439, U.S.A.     Chicago, IL 60637, U.S.A.
>Tel: 630 252 4619             Fax: 630 252 1997
>         Globus Alliance, www.globus.org

_______________________________________________________________
Ian Foster                    www.mcs.anl.gov/~foster
Math & Computer Science Div.  Dept of Computer Science
Argonne National Laboratory   The University of Chicago
Argonne, IL 60439, U.S.A.     Chicago, IL 60637, U.S.A.
Tel: 630 252 4619             Fax: 630 252 1997
         Globus Alliance, www.globus.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dais-wg/attachments/20041221/3755b8e9/attachment.html 


More information about the dais-wg mailing list