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

[John Fuller <jfuller@wernervas.com>]

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
> Reply-To: service-orientated-architecture@yahoogroups.com
>
>
> 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.
> >
>
> Seehttp://www-106.ibm.com/developerworks/webservices/library/ws-add/ 
> 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:
> http://groups.yahoo.com/group/service-orientated-architecture/
>  
> 	• 	To unsubscribe from this group, send an email to:
> service-orientated-architecture-unsubscribe@yahoogroups.com
>  
> 	• 	Your use of Yahoo! Groups is subject to theYahoo! Terms of Service.