RE: [dais-wg] WSRF Embodiments and DAIS

Happy New Year to all!!!

 

 

Dear Ian,

 

I see that no one has replied to your
message.

 

I can’t, of course, speak for the
DAIS WG but I would like to comment on your suggestion that WS-Addressing is
all that is required for consuming a WS-RF-based service. I believe this to be
an oversimplification. For example, just because my middleware gives me TCP/IP
socket programming interfaces it doesn’t mean that I can suggest that the
same middleware supports HTTP although, of course, socket programming is all
that is needed to implement HTTP-based communication. The same is true of WSRF.
Just because some middleware has support for WS-Addressing, it doesn’t
mean that it automatically supports WSRF. Could we say something similar about
WS-AtomicTransaction and all the other specs that use WS-Addressing?

 

Yes, it is possible to write SOAP messages
that can communicate with a WS-RF-based service but the same could be said
about WS-AtomicTransaction and WS-Security without having explicit support for
them. In fact, I remember Don Box demonstrating SOAP-based interactions using
only emacs and http. Also, Jim Webber and I are presenting a tutorial at
WWW2005 on Web Services (shameless plug :-) where one of the examples requires
someone (probably me since I type faster) to type the SOAP messages. I
personally don’t count that as middleware support :-)

 

Please, don’t take my comments as a concern
against WSRF. That’s not my intention. Just giving my views on your
question since no one else replied.

 

Best regards,

--

Savas Parastatidis

http://savas.parastatidis.name

  

From:
 [mailto:] On Behalf Of Ian Foster

Sent: Tuesday, December 21, 2004
1:21 PM

To: ;


Subject: Fwd: [dais-wg] WSRF
Embodiments and DAIS

 

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: 

X-Original-To: 

Delivered-To: 

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: , 

X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001

From: Susan Malaika <>

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: 

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