asap message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: FW: WSRF and Fujitsu
- From: Keith Swenson <KSwenson@us.fujitsu.com>
- To: "ASAP (E-mail)" <asap@lists.oasis-open.org>
- Date: Tue, 27 Apr 2004 11:49:00 -0700
FYI,
message to David Snelling of WSRF working group.
-Keith
David,
Congratulations on getting the WSRF
group going. I can imagine that this is a tremendous amount of work.
I have reviewed the Resource
Properties, and generally feel that the spec is well written (complete) and that
the functionality is very useful, and very compatible with work going on at
OASIS Asynchronous Service Access Protocol.
However,
there is
one overwhelming problem: it references WS-Addressing which is not a ratified
standard, and has not even been offered to a standards body. We have no
guarantee that WS-Addressing will be offered royalty free, nor do we have any
guarantee that it will not change from its current form. We can not accept
this. There is a potential political play,
if WSRF becomes dependent on WS-Addressing, they can avoid having to submit
WS-Addressing to process of review and approval, and still retain unilateral
control of it. It would be unwise to get into this
position.
WS-Addressing has some problems but
they are hard ones to argue in a "design-by-committee" environment. WSRF
is all about "resources" and is by design "resource-oriented". In the web,
a "resource" has an address, simple enough. A URI (or URL) is a
sufficient way to indicate the address of a resource. But the people who
designed most of the SOAP framework take an "operation-oriented" approach: the
critical address is that of the operation (or method) and resources are passed
as parameters to the operations. This approach, especially in a grid
environment, is a real limitation on flexibility. While the URI for a
particular resource might include the address of the operation, and an objectid
combined together in a way that makes sense to the implementation, WS-Adressing
forces the operation address (the <To> tag) and the object id (the
<SomeResourceId> tag) to be explicitly identified. By forcing the
service to expose this detail, it reduces the amount of flexibility that an
implementation has. One must have a very good reason to limit the
flexibility of an implementation, and I do not see any very good reason within
WS-Addressing to make these two components of the
address explicit.
For example, the caller of a
resource, has no guarantee that the object ID can be pulled out and used with a
different operation address -- unless someone wants to define exactly how you
identify all the operation addresses that an object id is useful for, and there
is no proposal, nor is anything likely to be proposed in the near future.
One must ask the question why these parts of the address are being made explicit
when the caller can not actually use the parts separately. A good
guideline for a protocol standard that will get wide usage is specify only those
things that need to be specified, and to carefully avoid specifying things that
do not make a difference.
A far better approach, and one that
OASIS Asynchronous Service Access Protocol is using, is simply to specify the
resource with a URI. The server has complete freedom on how it encodes the
object id into the URI. The internal workings of the service are less
exposed, and therefor less constrained by the protocol.
I am very interested in knowing how
you feed about WS-Addressing, and whether you concur with this, and whether you
can help to correct this specification. Good luck at the meetings this
week.
-Keith
Keith D Swenson, kswenson@fsw.fujitsu.com
Fujitsu
Software Corporation
1250 E. Arques Avenue, Sunnyvale, CA 94085
(408)
746-6276 mobile: (408) 859-1005
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]