On 4 Jan 2008, at 21:19, Nick Gall wrote:
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."
That is not local to the client. With Jini, a service is accessed by
retrieving a proxy from a lookup service. This proxy provides the
interface for the service. The implementation of the functionality
provided by the service may be running elsewhere on the network or it
may be contained within the proxy itself (or some combination thereof).
Your example is a remote call that happens to execute on the same
machine, but not in the same process, as the client. This introduces
additional latency that is unacceptable in some problem domains.
Jini service implementations can be modified without impact to the
users of those services as various NFRs are addressed. REST
implementations do not allow this level of optimization to take place
transparently to the client.
> 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.
I don't see any competition. There are things that REST simply can't
do. ;-)
First, Jini is a technology and REST is an architectural style.
This is not entirely accurate. Jini is a particular implementation
of a more general architectural style. The concepts underlying Jini,
including the appropriate way to address Deutsch's Eight Fallacies of
Distributed Computing, constitute a full architectural style. One
full featured variant of this style, as you note below, is Space Based
Architecture.
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
architectural style (of which Jini/JavaSpaces in a technology
instance) to the REST architectural style (of which the WWW is a
technology instance).
SBA uses the equivalent of clustered JavaSpaces to provide a shared
distributed memory and Jini services to co-locate business logic,
messaging, and data into cohesive modules that run in the same process
space. These modules become the unit of scalability; if a particular
business use case needs greater throughput, more instances of that
module are instantiated.
That leads me to question your next statement:
Second, (IMO) the two styles are pretty compatible, eg one can
accommodate the other.
I disagree. It is certainly possible to implement a system under an
SBA using a RESTful style of interaction with services. It does not
appear to be possible to do the reverse. The requirement to use a
separate HTTP server to invoke services in a REST architecture
prohibits some types of solutions, such as the one I described above.
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 followed the link to http://www.fridgebuzz.com/2003/12/restful-tuplespaces.html
and Ms. Williams seems to support my view. While it is possible to
invoke a JavaSpace-like API from a RESTful interface, it is by no
means straightforward. In fact, some of the contortions start looking
like "stupid REST tricks" (with apologies to David Letterman), even
before the introduction of concepts like notifications.
Note also that these significant issues arise even without attempting
to address the capabilities of a full SBA.
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.
Actually, SBA uses the space as a means to several ends, not as an
end in itself. The essence of SBA is to co-locate business logic,
messaging, and data into cohesive, scalable units. A distributed
space is a straightforward means of achieving these goals, hence the
inclusion of "space" in the name of the architecture.
REST accomodates a wide variety of "space-based" architectural
styles via its open-ended "cache" constraint.
How would this address the issues I raised above? Further, how would
you model notifications in a REST implementation?
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???
Space Based Architecture is much richer than just the entities
available via the space. As I noted upthread, once people find out
that SBA can address the NFRs of performance, scalability, and
resiliency in both extreme and less demanding environments, they see
no reason not to use it to achieve the benefits of standardization
across their application suite.
Regards,
Patrick
----
[EMAIL PROTECTED]
S P Engineering, Inc.
Large scale, mission-critical, distributed OO systems design and
implementation.
(C++, Java, Common Lisp, Jini, middleware, SOA)
