On 8 Jan 2008, at 16:50, Alexander Johannesen wrote:
> On Jan 7, 2008 3:25 AM, Patrick May <[EMAIL PROTECTED]> wrote:
>> 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).
>
> Our RESTful SOA does exactly this, where the main URL tree is simple a
> proxy to other services, internal and external, which directs based on
> a number of parameters.
Let's go through the steps involved in invoking a service in Jini, in
temporal order:
1. The infrastructure starts, including a lookup service (LUS).
2. A new service starts.
3. The new service registers a proxy with the LUS, using the standard
Jini discovery and registration protocol.
4. A client starts.
5. The client discovers the LUS using the standard Jini protocol.
6. The client requests a service that implements a particular
interface.
7. The LUS returns a copy of the registered proxy.
8. The client dynamically downloads any required implementation
classes (transparently).
9. The client uses the proxy.
With Jini, the proxy can be a thin layer wrapping remote calls to the
service implementation, a full implementation in its own right, or a
combination thereof. When low latency is a requirement, implementing
all the service's behaviors in the proxy is essential.
If HTTP is used to implement a RESTful architecture, it is not
possible to execute the service in the same process space as the
client. Such an implementation does not meet the requirements of high
performance systems. Are you saying that you have a REST
implementation that provides the same features as Jini in terms of
dynamic, mobile code and co-location of execution within the same
operating system process?
> I don't see the technology being a limiter by
> this. I suspect you don't like HTTP, which, all in all, is a different
> issue.
HTTP has nothing to do with it. The inherent latency of
communicating between separate processes and, potentially, separate
machines is the issue.
> Further , you said ;
>
>> 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.
>
> That depends on what you mean by "modification." In addressing?
No. Addressing is addressed by the standard Jini protocols. By
modification I mean the ability to dynamically update the
implementations of services without changing the clients of those
services. With Jini I can change the process space within which the
service behavior executes, without impact to any other component of
the system, for example.
> Our
> REST implementation with HTTP, by following HTTP specifications, offer
> redirections (permanent, temporary, etc.) and moving. In protocol
> semantics? We've got introspection (schema aware), APP, and binary
> support (extensible through Content-Type). Change? Big changes follows
> /v1, /v2 etc notions, all small changes are retrospectivly compatible.
> At some point there's semantics which you must put into your API, but
> with REST those semantics are limited to the resource which is a great
> advantage when you want to change your SOA around.
Those kinds of modifications don't help address the issues of
performance, scalability, and resiliency that can be addressed in
Space Based Architectures with technologies such as Jini. At the end
of the day, you're still making interprocess or intermachine hops to
particular URLs that the clients must be aware of.
> I'm trying to find out why you think REST (often as opposed to HTTP)
> have these limitations you speak of. Can you say some specific
> limitation you know of, like a use case? In other words ;
Is there a REST implementation that provides the capabilities of Jini
described above?
>> 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.
>
> And I think this is where your idea of REST traverse well into the
> implementation domain, and as such most people would do an HTTP
> implementation. I certainly don't understand where the requirement of
> using a separate HTTP server comes from; the REST interface and
> notions are completely separated from the underlying implementation.
Are there any implementations that don't use a separate HTTP server?
> I'm pretty sure that all you say Jini can do above you can do with a
> REST interface.
I'd be interested to see how you handle dynamic, mobile code and in-
process execution with a REST implementation.
>> My other message goes into more detail, but one significant issue is
>> the latency inherent in invoking REST services.
>
> No, you mean HTTP.
Again, what alternatives exist?
>> Of course, whatever the problems with Java, they're nothing compared
>> to the painfully overwhelming inelegance of XML.
>
> No, I'd have to disagree with this. Sure, it has some worts (or beauty
> spots, you might say :) but all in all I can read any XML document and
> understand roughly what's going on with it, it's open and I can parse
> and introspect it, analyse it easily.
You need to take a look at some of the XML generated by various word
processors or by SAP, for that matter. I've had the displeasure of
having to parse some of that and it is by no means intuitive. Nothing
about the XML syntax guarantees clarity.
Even when XML is handwritten, the ridiculous verbosity is an
impediment to understanding. There are far more elegant alternatives;
unfortunately XML has a lot of mindshare currently. People seem to
feel good about working hard to address a problem that never needed to
exist in the first place.
>> I went into more detail in my other message, but the short version is
>> that, with Jini, I can implement my services in such a way that they
>> transparently execute in the same process space as the client. You
>> can't do that with REST.
>
> It's a big statement, for sure. Now I must ask, what does it mean to
> run something in "the same process space as the client"?
With Java, it means running in the same JVM in an OS process.
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)
