OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

asap message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Fwd: [service-orientated-architecture] Pass-by-RESTference

URI v. WSA, more thoughts

Begin forwarded message:

From: Michael Champion <mc@xegesis.org>
Date: February 2, 2004 10:15:58 AM CST
To: service-orientated-architecture@yahoogroups.com
Subject: Re: [service-orientated-architecture] Pass-by-RESTference

On Feb 2, 2004, at 9:13 AM, Mark Baker wrote:

> On Mon, Feb 02, 2004 at 06:32:22AM -0600, John Fuller wrote:
>> I suppose a related question is what do you all think of passing
>> WS-Addressing
>> endpoint references to explicitly refer to resources at endpoints
>> rather than
>> encoding the resource references in a URI?
>> (Ex: WS-Resource specs from the grid community v. classic REST)
> I don't understand why anybody would want to do that.

for the rationale. (I'm pretty sure that Mark can point us to several
pieces he wrote critiquing WS-Addressing)

As I understand it (and I have no dog in this fight!), the point of
WS-Addressing is to:

- provide a protocol independent notion of an endpoint; URIs
intrinsically refer to a protocol, and this means they are abstract at
best (and kludgy at worst) for identifying endpoints of services that,
for example, run on mainframes and are directly accessed only by
proprietary message queueing systems. One can of course talk about the
URI of the HTTP gateway to such a service, but that may obscure all
sorts of important information (e.g., which particular mainframe is
best suited to handling a service request).

- provide a notion of an endpoint that can change as the result of the
processing of a service request. For example, the initial request
might be to a gateway URI, but various routing and load balancing logic
might be used to identify a specific bit service providing software
whose identify and addressing information needs to be preserved
throughout a multipart transaction.

- "Flexible and dynamic exchange of endpoint information in tightly
coupled environments where communicating parties share a set of common
assumptions about specific policies or protocols that are used during
the interaction" As I understand it, sometimes a service requester
does know "too much" (by the standards of SOA or REST theory) about the
implementation topology and wants to make sure that the proper agent
services it. For example, one might know that a particular mainframe
could handle the request locally because it has the master copy of
one's data, and specify that the request be routed to that particular
implementation address.

I'm not sure how this relates to Pass by RESTference, but it seems like
it would be possible to use the WS-Address of a "resource" (mainframe
file, database record, whatever) that maintains the state of a
transaction rather than a URI. Of course, one can always use a URN
(abstract, non-dereferenceable URI) or one of those http URIs that
refer to an abstraction to identify such information, but this takes
one into a philosophical and practical swamp that the W3C Technical
Architecture Group has been wallowing around in for years. If
WS-Addressing gets real world traction, the world may simple choose to
drive around the swamp rather than build a road through it.

I think it's important to note that a lot of these things that *sound*
like they *should* be unnecessary given a *theoretical* model of SOA or
whatever were proposed by experienced people at big companies who are
presumably being yelled at by their customers to solve their real
problems. Take that with as many grains of salt as you wish, but
ignore existing reality at your peril.

Yahoo! Groups Links

To visit your group on the web, go to:

To unsubscribe from this group, send an email to:

Your use of Yahoo! Groups is subject to theYahoo! Terms of Service.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]