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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] What Does SOAP/WS Do that A REST System Can't?

[ Lists Home | Date Index | Thread Index ]

Michael Champion wrote:

> In a resource-oriented architecture, new features are handled by
> defining new URIs to manipulate,, new interpretations of HTTP return
> codes,  new synatax or semantics of the documents transferred,
> whatever. How can  clients nott need to understand those details in
> order to use the features?   Or better yet, point me to a concrete
> example on the Web.
> 
> Dare mentions than in a service-oriented aggregator, " If later on a a
> new service shows up (e.g. getRecentBookmarks() to get RSS feeds from
> del.icio.us) then the client has to be upgraded."   Sure, but
> SOMETHING on the client has to change in a RESTful version as well ...
> not the method for retrieving data, which can be GET, but the logic
> for doing anything that understands the distinction between a news
> story and a bookmark has to come from somewhere.


That's the point. You get more flexibility as to where and how you apply 
processing logic. That's a huge software win that one might not 
appreciate from a the vantage of a whiteboard. In a getThis, getThat 
protocol framework, you seem to end up playing infrastructure catchup 
and trying to keep clients and servers in sync. Basically by hardcoding 
This and That into the method names you're making questionable 
assumptions about the range of operations you will need to support.

Abstractly speaking it's all processing, concretely speaking having 
control of how processing occurs and how code is dispatched is critical. 
Systems with flexible and deferred dispatching modes are almost always 
cheaper and easier to maintain.

For a not completely dissonant comparison, in OO systems where not all 
possible types can be ranged over at design time (because no-one knows 
how many more types there will be alter on), plugin and delegation absed 
  architectures are almost always preferrable way to deal with that 
problem.

cheers
Bill





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS