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? 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. :) > We need the ability to optimize > without sacrificing the level of abstraction required to effectively > implement the solution. I agree, which is one of the reasons I find REST so delightful to work with. The interface and concepts stay the same no matter how I build the network and servers for failover, duplication, backup and performance. I can optimize any part of the HTTP pipeline without changing a line of code, which to me is a huge win. > 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* > 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. > 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 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? > 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. What? I thought small tools were pretty much what SOA was all about, that the advantage of SOA was the decoupled set made the business more adaptable. > 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? :) I know heavy technology architects think of REST as a Mickey Mouse architecture, but need I remind you that Mickey Mouse is more famous than Sandman, no matter the merits of the characters. :) Meaning ; we who love REST also build real systems, and we're rather busy, too, so please don't insult us, even unintentionally. Alex -- --------------------------------------------------------------------------- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps ------------------------------------------ http://shelter.nu/blog/ --------
