On 11 Jan 2008, at 12:56, Gordon Sim wrote:
> Patrick May wrote:
>> On 9 Jan 2008, at 10:51, Gordon Sim wrote:
>>> I don't think it makes sense to compare this feature either to REST
>>> as a
>>> style or to any implementation of it (e.g. HTTP). It seems to be
>>> outside
>>> the scope that REST addresses and therefore potentially orthognal. A
>>> more useful comparison might be between the use of RESTful HTTP
>>> versus
>>> the use of JERI.
>>
>> I'm not sure about this. I think that the difference shows an
>> inherent weakness of REST compared to Space Based Architecture. It is
>> possible to implement any REST system using SBA, simply by
>> implementing RESTful service interfaces. I don't believe it is
>> possible to implement every SBA system using a REST architecture. If
>> there is a REST implementation that does allow that, I'd be
>> interested
>> in learning more about it.
>
> My point was that I understand REST to be focused on remote
> interactions. Mobile code is outside of that scope in my view. The
> resource you retrieve RESTfully might well be represented by a 'mobile
> object' (e.g. a java applet).
>
> E.g. I could have a system that used RESTful HTTP to get a particular
> java object in serialised form that the application then unmarshals,
> casts to the appropriate interface and uses as a target for method
> invocation.
That is certainly doable, but it strikes me as the SOA equivalent of
the "Turing completeness" argument often heard in language debates.
Any Turing complete language can implement the same functionality of
any other Turing complete language, but what's interesting is how much
power and expressiveness the language provides to the programmer.
Similarly, since distributed systems require the movement of data, it
should be possible to implement Jini concepts in any SOA
implementation. What's interesting in this case is how easy that is
to do and what inherent support is provided.
Once you've implemented all the Jini features using a REST
implementation like HTTP, how much of REST is left? I suggest that,
relative to Jini, REST is a Blub (http://www.paulgraham.com/avg.html).
> If you are saying that Jini provides code that does this already and
> there isn't an equivalent, existing product that is RESTful thats very
> likely true.
>
> That seems to me to be a different thing from saying that a REST
> architecture prevents exploiting the benefits of mobile code though.
The original question that started this thread was why Jini was able
to solve a problem in extreme transaction processing that REST could
not. The answer is Jini's ability to take advantage of mobile code
and to co-locate business logic, data, and messaging in the same
operating system process. While it might be possible to build enough
of Jini on top of REST to accomplish this, current REST
implementations don't provide those capabilities.
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)
