On 5 Jan 2008, at 17:11, Alexander Johannesen wrote:
> On Jan 4, 2008 11:48 AM, Patrick May <[EMAIL PROTECTED]> wrote:
>> 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.
>
> Yes, you've said so already, but what are they?
Our responses seem to have crossed in the ether (or our distinguished
moderator held them both to maximize confusion). In any case, I
explained this in my follow up to Mr. Gall. I hope you'll respond to
that message if it doesn't answer all of your questions.
> I asked if it was
> performance of the obvious XML pipelines (which indeed are
> computational intensive), but you're saying there's more. I'm still
> very, very keen on getting a serious answer on this, because I'm
> investing a lot of my time and betting on REST being right for what
> I'm doing, so if you're sitting on information that would render my
> universe null and void, I'd like to find out what it is. :)
My other message goes into more detail, but one significant issue is
the latency inherent in invoking REST services.
>> Using Jini and JavaSpaces we got all of the
>> benefits of a point-to-point topology with none of the drawbacks.
>
> Apart from Java, I suppose. *grin*
I think we'd agree there. Java's only saving grace is mobile code.
Other than that, it's an ugly, limited, and uninteresting language.
The concepts behind Jini, though, can be and have been implemented in
other languages.
Of course, whatever the problems with Java, they're nothing compared
to the painfully overwhelming inelegance of XML.
>> 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.
>
> Others have asked about this, and I'd like to ask for some examples of
> what this means, because, frankly as the word stands I do this all the
> time.
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.
>> 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.
>
> Why wouldn't other solutions be able to do this? *puzzled* Unless you
> live off selling Jini ...
The problem is the inherent latency of other solutions, again.
Problem domains such as online gaming or risk analytics require sub-
millisecond response times. One network hop, and in many cases one
interprocess hop, is unacceptable.
>> 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.
>
> Which you provided in the form of Jini, sure. But that doesn't explain
> what those other solutions did wrong. Or are you saying that no matter
> how brilliantly optimized these other solutions were, performing at
> their potential peek, Jini just performed better?
That is exactly what I'm saying. If companies can do what they need
to do with their existing app servers, ESBs, or other standard tools,
they won't take the risk of using something less mainstream like
Jini. They use it because they have to.
>> 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.
>
> So if people talk about REST, they're not making real systems with it?
Not while they're talking about it. ;-)
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)
