& XSLT Rich Salz wrote:

> > ... the extreme of providing a single poiunt of access (e.g. 
> > http://foo.org/myService ) to POST everything to just doesn't seem to 
> > cut it when it comes to scalability and integratability.
> 
> 
>  How so?  I can see why the single point is better for integration -- 
>  you only change one message posted to one URL, as opposed to one 
>  message posted to "n" URL's -- not worse.  And I don't see the 
>  difference in scalability at all.  Can you explain?
> 
- The example task is to get the address of a person -

Scalability:

With the single-service approach I have something like this:

POST /myService

person-id: 778
method-name: getAddress

...service returns address....

In order to understand the message, a system component must understand 
the particular semantics of the message content. The consequnce is that 
an intermediate cache cannot decide if the message is cacheable unless 
it knnows the application semantics. Consequnce: you cannot build 
application semantics independent caches.

With REST you'd have:

GET /persons/778

server responds:
Content-Type: application/rdf+xml

<ex:person rdf:about=""> 
   <rdfs:label> Joe Smith</rdfs:label>
   <ex:address> 77 Park Av., Laketown</ex:address>
</ex:person> 

 HTTP semantics define GET responses as cacheable, so any generic HTTP 
intermediary knows it can cache the response.

That improves scalability, IMHO.

---------

I do not have time right now, will address the integratability part later.

Jan




>      /r$
> 

-- 
Jan Algermissen
Consultant & Programmer
http://jalgermissen.com



-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>