[dais-wg] WSRF Embodiments and DAIS
Savas Parastatidis
Savas.Parastatidis at newcastle.ac.uk
Wed Jan 5 11:44:47 CST 2005
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: owner-dais-wg at ggf.org [mailto:owner-dais-wg at ggf.org] On Behalf Of
Ian Foster
Sent: Tuesday, December 21, 2004 1:21 PM
To: dais-wg at ggf.org; wsrf at lists.oasis-open.org
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:
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 <http://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 <http://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 <http://www.globus.org/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dais-wg/attachments/20050105/e2ac823a/attachment.html
More information about the dais-wg
mailing list