Guys, PatrickM, GreggW (and to some degree, SteveJ), I think we need to summarize. I'd like to write a reply to each, but there's now too much repetition across the posts, and I'm running out of time as I'm moving countries on Monday and aren't nowhere ready yet and my wife is wondering what I'm doing on the computer at this hour. So. Here' we go ;
Jini = Java, uses strong OO concepts and Interfaces for ontological meaning, highly configurable, proxied, remote code, solves real high-performance distributed "enterprise" problems, uses the various Java models (security, locality, etc.), is well thought-out, and uses Java as a way to "put things together" REST = a style of "putting things together" using URIs as interfaces into "resources" with limited methods, into systems of virtual state HTTP = a text-based implementation of REST on top of TCP/IP WWW = a haphazard version of HTTP Not sure if our comparison between REST and Jini have made much sense so far as Jini is just *so* much more than REST. In fact, I think the only part of Jini that it makes sense to compare would be using Interfaces; the rest is plain systems design. Our comparison of Jini and HTTP is also a bit tricky. Jini again seems to embrace the full Java world, which means that if Java *is* your world, Jini is kick-ass, funky, sexy and all that and HTTP is an ugly kludge. However, if you're not in the Java world you can't use Jini, and are left to use whatever that platform can offer. Further, comparing Jini to WWW is just plain crazy, ust as crazy as the WWW itself is. Nuff' said. I think Gregg is saying that the rest of us are silly :) for not simply embracing Java and Jini, and turn to a real system that deals with real issues in a really good way, and perhaps Patrick and Steve are the same. I think that view is a tad naiive, but I understand the argument and the pipe-dream it offers (unless you're married to Java and you're a monogamist). I'm a SOA designer, and as such it is my no. 1 job to make sure all our systems talk to each other nicely. We're not 100% Java (or any other technology with more than 40%), so it's important to me that there's ways of leveraging those facts. I cannot choose Java and convert all programs to Jini as our services are both in-house at various shops, and also includes vendors and external services. Choosing only Java is *not* an option, even if we understand the amazingness of Java and Jini, and that all our problems would be (apparently ;) solved through its use. My angle on this in terms of SOA is to create systems all can use that are technology agnostic as much as possible. So, when Patrick says that he had to kill a RESTful system and use Jini to make it work properly, I'm extremely interested in knowing why *REST* failed as opposed to more normal implementation problems (shoddy developers, lack of understanding of technologies, poorly put together solutions, etc.) I understand Jini does most of this out of the box the right way. But I have a developer who's got a simple Perl script that needs to find the id of some customer from a departement in Bangalore who uses .Net for everything, who in turn needs to know customer data from my section who uses Java and eXist. Our R&D section of Ruby/Python/Luna developers wants to reuse parts of our infrastructure to experiment with large data sets. One of our vendors have delivered an FOSS PHP solution for customer support. Our CMS is a C#/.Net solution. I've also got an internal employee app that's been hacked at for the last 6 years, is a mix of PHP, C, Apache and Perl and uses a slew of conceptual models to talk to its *own* internals (good grief!), and now needs to also communicate these internals with others in our SOA. How can we all tie these things together? Traditionally (at least, these days) that would be SOAP / WS-* with all the problems and conceptual challenges that entails, and I now see REST as a very elegant, simple and smart way to handle these situations. I see HTTP as a good-enough implementation to make it happen. And I don't see Jini help me here. Now, that's the Jini vs. REST/HTTP part. The next issue was Patricks story of having a REST application that needed to be converted to Jini to work properly. Now, I can understand that some apps require extreme performance, and yes, that that RESTful (if it was truly RESTful) system might have been such a system, but the original question was why *REST* was the performance problem as opposed to shoddy HTTP implementation. I can understand Jini being the replacement as it probably offers a solution out of the box which REST can't, but that's not a problem with REST as much as no one having a RESTful solution that solved that problem. Anyways, I think that's it for me for now. I'm off to pack the last few boxes, and make yet another million phone calls. And thanks for a very interesting discussion. Alex -- --------------------------------------------------------------------------- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps ------------------------------------------ http://shelter.nu/blog/ --------
