Alexander Johannesen wrote: > > > 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,
Yes, we've gone round-n-round at this point, and hopefully all of the thoughts that have motivated our positions have somehow leaked out in a consumable form. > 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; Thanks for the summary, it's a great description of what I think are the items of interest in this discussion. > 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). What I've tried to do is argue the point that you can't compare Jini to REST, because they don't cover the same level, depth or breath of software design and development in distributed systems. > 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. I think that the interesting thing is that you are still imagining that the only way to use Jini, is everywhere, because of the Java implementation. Instead, it might be more appropriate to think of Jini as the set of semantics that are in the specifications. I think that's important because if you meet those semantics in your C# software, which has a conversation with a piece of Java software, then you are able to use the Jini'ness of that Java software from C#. Gigaspaces has this type of facility available to allow a Javaspace to be accessed from C# for example. The important point, is that service->client and client->service communications, in Jini, has very limited requiremets. All that is required is that you have an invocation layer which meets the RMI programming model. That simply requires that items are passed by "value" between VMs (and the value might be a remote proxy). Everything else that JERI does, as the communication stack, is something built on this basic concept. Mobile code doesn't HAVE to be part of a particular client's use of a particular Jini service. This is very much like making the choice of whether your web page is just HTML, something that everyone understands, or what it will use 5 different plugins +DHTML+CSS+JS to provide a "GUI application" like UI to it's user. For simple clients (those that don't have a wide vocabulary), you don't through the complex UI at them. > 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. One of the interesting points for me along this line of thinking is how easy people make the decision to use HTTP+DHTML+CSS+JS as a "system all can use", when the actual fact is that it requires a browser, which I might not have on my compact cell phone, for example. So, I still have to push back on the concept that RESTful systems can actually be built technology agnostic. There is always specific content that someone/something has to be able to digest. The question is at what expense/effort does the content become digestible, or at what expense (performance is an expense of interest in this discussion) is it possible to generate the "technology agnostic" content for something else to consume. > 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? By picking a single technology for your system's facade, you can help manage how many different implementations of the same concepts developers are creating. For information publishing, you can't beat the convenience of things such as HTTP for letting people get something that they consume asynchronously to it's production or reproduction. Of course, eventing/messaging technologies become more important when there are things that happen and which need to provide timely triggers of subsequent use. When tight, atomicity and timing are needed, then you have to start optimizing beyond the function of a technology and understand how to exploit its features to get to the function/performance you need. I think this is the point that Patrick is coming from. I think Jini provides a pretty powerful set of tools that let you "go there" if you have to, and don't provide restrictions or compromises if you "don't need to". What I think is part of this discussion is whether the facilities exist, in any available technology, that either control/limit the ability or actually enable the ability to solve a particular class of problems. Patrick and I are arguing about the Jini specific facilities which I think you have a grasp on. > 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. In this day and age, we are often motivated to move toward direct, peer-to-peer communications. This means that all of these inter-language communications issues come out of the woodwork, everywhere. That's the space that I think many don't think Jini has the ability to play. If you have a system architecture where all of these things that are flowing between peers are actually work requests and returned results, then the Javaspaces programming model might be something to look at. It might sound like I'm suggesting an ESB kind of solution. To some degree, that's my point. Why? Because that provides a technology neutralization/unification facility that allows your software systems to still be arbitrary from a client perspective. But by using a Javaspace, it's possible to exploit Jini/Java fully, for new development that utilizes that mechanism. In particular go look at Gigaspaces implementation to see how they really are providing a multi-language solution to make use of the power of Javaspaces. That's not the only "interworking" solution. There is the "lookup server on a chip" from PsiNaptic.com which is not Java at all. It simply knows how to handle the Jini service registration and lookup protocol bits and thus can facilitate these things without a single like of Java. > 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. I'm going to let Patrick cover this one. > 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. Good luck with the move! Gregg Wonderly
