On Jan 3, 2008 7:48 PM, Patrick May <[EMAIL PROTECTED]> wrote: > A RESTful interface, posting documents to URLs, would not allow that > level of optimization. For example, dynamic lookup of a service that, > transparently to the client, executes locally is not possible with REST.
Huh? I must be misunderstanding your claim. What would you call http://localhost:4664/search?q=foo ? This is how Google Desktop "transparently to the client, executes locally." There are lots of other examples of transparent (re)directs of URL to "local" resources, eg Greasemonkey, Google Gears. > My more general point is that Jini and Jini-like technologies are > unique in their ability to address the most computationally and data > intensive problem domains, while still providing the benefits of SOA. > The customers I mentioned in my original email in this thread were > hitting the wall in terms of what their existing application servers > and message buses could handle. They were simply unable to scale > further without a new software architecture. I'm not sure why you and Gregg seem to be trying to paint REST and Jini as competitive alternatives. First, Jini is a technology and REST is an architectural style. Thus the proper analysis is to determine in what ways Jini/JavaSpaces adheres to REST principles and it what ways it deviates from them. If you want to compare architectural style to architectural style, you'd have to compare the Space-based <http://en.wikipedia.org/wiki/Space-based_architecture>architectural style (of which Jini/JavaSpaces in a technology instance) to the REST architectural style (of which the WWW is a technology instance). Second, (IMO) the two styles are pretty compatible, eg one can accommodate the other. But don't take my word for it, see the circa 2003 compare/contrast of the two styles (captured by Mark Baker) for yourselves: http://www.markbaker.ca/blog/2003/12/23/the-resttuple-space-meme-makes-the-rounds/. I see REST and "spaces" as somewhat orthogonal. As others have pointed out, REST focuses on the "interface" aspect, while "space based" architectures focus on the "provider" aspect, ie issues concerning how to distribute a "space" for reliability and scalability. REST accomodates a wide variety of "space-based" architectural styles via its open-ended "cache" constraint. IMO. REST will evolve by ADDING constraints that make it more space-based. Certainly, a RESTful Semantic Web architectural style would be a step in that direction. The major issue, as always, is what kind of information "entity" the "space" exposes: evolving from tuples, to Java objects, to hypermedia, to RDF??? -- Nick
