On 2 Jan 2008, at 15:14, Alexander Johannesen wrote:
> On Jan 3, 2008 1:05 AM, Patrick May <[EMAIL PROTECTED]> wrote:
>> In this particular case we had to minimize the number of network hops
>> in the chain and provide shared state for stateless services. A
>> JavaSpace mediated approach with Jini services worked beautifully.
>
> Ok, but where's the connection to REST? Network hops and state issues
> are more common in SOA that about a RESTful interface, and are generic
> design issues. I'm really keen to understand why *REST* failed more
> than it being a more generic design issue which could have happened
> with pretty much any technology or architectural style.
My particular point is that the problems we encountered with this
problem domain were related to "generic design issues" that are not
present with Jini but that do exist with technologies such as REST,
Web Services, and several ESBs. We need the ability to optimize
without sacrificing the level of abstraction required to effectively
implement the solution. Using Jini and JavaSpaces we got all of the
benefits of a point-to-point topology with none of the drawbacks. 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.
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.
Once these customers found that Jini and related technologies could
handle their heavy lifting, they started to realize that it could be
used for their less extreme SOA requirements as well. Scalability,
high throughput, low latency, and resiliency are widely applicable
NFRs. This has led to implementations ranging from order management
systems to distributed reporting and, in some cases, changes to
company standards.
There is value in standardizing on a small set of tools, but if and
only if those tools can address all the needs of the organization.
Jini and related technologies are proving their worth from the ground
up in these environments. To go back to Gregg's original question, I
think this is why he doesn't see more discussion of Jini -- we're too
busy building real systems with it. Longer term, that's more far more
likely to result in the success of the technology than top-down
mandates from "architecture" teams with no responsibility for
delivering working systems in a timely fashion.
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)
