On Jan 12, 2008 2:46 AM, Patrick May <[EMAIL PROTECTED]> wrote: > Let's go through the steps involved in invoking a service in Jini, in > temporal order: > > 1. The infrastructure starts, including a lookup service (LUS).
[server] http://example.com/lus > 2. A new service starts. > 3. The new service registers a proxy with the LUS, using the standard > Jini discovery and registration protocol. [service] POST http//example.com/lus ? id=service123& type=bank_account_transfer href=url_encoded ( http://example.com/services/service123 ) > 4. A client starts. > 5. The client discovers the LUS using the standard Jini protocol. [client] GET http://example.com/wadl << 200 + WADL XML > 6. The client requests a service that implements a particular > interface. [client] GET http://example.com/lut ? type=bank_account_transfer > 7. The LUS returns a copy of the registered proxy. << 200, http://example.com/services/service123 (note that this is just the REST functionality. In reality you can have a GET on that URL download remote code, be it Java or more likely DHTML) > 8. The client dynamically downloads any required implementation > classes (transparently). Void; still using REST. > 9. The client uses the proxy. [client] GET http://example.com/services/service123?introspection > With Jini, the proxy can be a thin layer wrapping remote calls to the > service implementation, a full implementation in its own right, or a > combination thereof. When low latency is a requirement, implementing > all the service's behaviors in the proxy is essential. I think REST with a few bits of standardized sprinkle can do exactly the same, albeit not in a OO / Java way, and perhaps this discussion really is about the good and bad of the Java / OO marriage? > If HTTP is used to implement a RESTful architecture, it is not > possible to execute the service in the same process space as the > client. Sure you can, if you design it that way. REST doesn't provide this stuff for you, you're right there, but it certainly isn't impossible. In fact, you can use a REST service to download that very mobile Java code. And no, there's no standard for this right now. Yes, I'm sure someone is working on it. > Such an implementation does not meet the requirements of high > performance systems. Are you saying that you have a REST > implementation that provides the same features as Jini in terms of > dynamic, mobile code and co-location of execution within the same > operating system process? I do have experimented with REST services that stream custom DHTML code, so it certainly is doable, and possibly more flexible than the Jini solution, but no I can't offer that to my clients tomorrow (unless I do it for them, of course) like I could with Jini. > HTTP has nothing to do with it. The inherent latency of > communicating between separate processes and, potentially, separate > machines is the issue. But then, REST has nothing to do with it either. ... > > Our > > REST implementation with HTTP, by following HTTP specifications, offer > > redirections (permanent, temporary, etc.) and moving. In protocol > > semantics? We've got introspection (schema aware), APP, and binary > > support (extensible through Content-Type). Change? Big changes follows > > /v1, /v2 etc notions, all small changes are retrospectivly compatible. > > At some point there's semantics which you must put into your API, but > > with REST those semantics are limited to the resource which is a great > > advantage when you want to change your SOA around. > > Those kinds of modifications don't help address the issues of > performance, scalability, and resiliency that can be addressed in > Space Based Architectures with technologies such as Jini. Aren't you here just piling on specific technology requirements instead of addressing the issues at hand? No, REST can't be Jini nor Java Spaces, but is that the goal? > At the end > of the day, you're still making interprocess or intermachine hops to > particular URLs that the clients must be aware of. REST nor HTTP demands the inter-machine hop (although often practiced), but surely even Jini does the interprocess hop? In fact, what is your definition of an interprocess hop? > Is there a REST implementation that provides the capabilities of Jini > described above? Not that I know or have heard of. I don't know how large the Jini/JENA stack is, but since Jini has such a strong OO concept I'm not sure how much of it adresses Java and / or OO specific stuff as opposed to functionality and semantics defined. I'm thinking it shouldn't be too hard to do a REST version, but I'm now talking way ahead of myself based on knowing nothing about Jini. :) ... > > And I think this is where your idea of REST traverse well into the > > implementation domain, and as such most people would do an HTTP > > implementation. I certainly don't understand where the requirement of > > using a separate HTTP server comes from; the REST interface and > > notions are completely separated from the underlying implementation. > > Are there any implementations that don't use a separate HTTP server? I guess I was just questioning what "separate" here means. Are we talking about hops between HTTP servers (so, separate servers) or interactions between a Java application and a Java HTTP server (like Jetty) who might reside in different JVM contexts, or what? There's nothing that *requires* you to use more than one HTTP implementation / server, so I guess I'm misunderstanding something here. > I'd be interested to see how you handle dynamic, mobile code and in- > process execution with a REST implementation. Hey, I would too. My old job didn't do any such thing, but my new job (which is, um, my older job) certainly might have room for such. Let me get back to you on that one. :) ... > >> My other message goes into more detail, but one significant issue is > >> the latency inherent in invoking REST services. > > > > No, you mean HTTP. > > Again, what alternatives exist? JavaBeans are semi-RESTful, you know. :) With a few extensions, it shouldn't take much to make the perfectly RESTful within a Java context, although they wouldn't be beans anymore. If I'm not mistaken the RESTlets work in this way, but I'd have to look a bit for that. Anyway, with the "No, you mean HTTP" as a bottleneck for performance issue, I said this because there *are* certain aspects of HTTP and WWW that aren't optimized for speed, which is what most people raise as the main drawback of HTTP. However, I assert that with proper caching, proper resource orientation, and good use of HTTP proxies and load balancers you can solve most if not all of these performance issues. And this is using well-known and widely distributed technology. ... > >> Of course, whatever the problems with Java, they're nothing compared > >> to the painfully overwhelming inelegance of XML. > > > > No, I'd have to disagree with this. Sure, it has some worts (or beauty > > spots, you might say :) but all in all I can read any XML document and > > understand roughly what's going on with it, it's open and I can parse > > and introspect it, analyse it easily. > > You need to take a look at some of the XML generated by various word > processors or by SAP, for that matter. I've had the displeasure of > having to parse some of that and it is by no means intuitive. Nothing > about the XML syntax guarantees clarity. Nothing about the Java syntax guarantees the same, neither. I suspect I can try to make something using Jini and make a right good mess of it. There are no guarantees of this with any technology you choose, XML, Java, LISP, XSLT, you name it. People can make shit out of anything, which has been proven over and over again, and automatic word processing software are the epitome of bad XML, indeed. > Even when XML is handwritten, the ridiculous verbosity is an > impediment to understanding. There are far more elegant alternatives; > unfortunately XML has a lot of mindshare currently. People seem to > feel good about working hard to address a problem that never needed to > exist in the first place. <response by="Alexander Johannesen"> <opinion about="http://www.w3.org/XML/";> <benefits> <all-text /> <simple-syntax /> <handy-constraints /> <namespaces when="used for good" /> <support for="structured information" /> <support for="mixed content models" /> <support for="data modeling" /> </benefits> <drawbacks> <entity-handling /> <namespaces when="used for evil" see-also="../benefits/namespaces" /> <crap-in-crap-out /> </drawbacks> <alternatives> You tell me! </alternatives> </opinion> </response> Actually, there were problems that needed to be solved; textual integration format, especially structured and hopefully document-based. And as proprietary my XML above was, I'm sure you could understand what was going on and the message constructed, no? :) ... > >> 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. > > > > It's a big statement, for sure. Now I must ask, what does it mean to > > run something in "the same process space as the client"? > > With Java, it means running in the same JVM in an OS process. Why are you saying you can't run RESTful systems this way? Certainly within one JVM, and probably within same OS process, if you design it that way. I'm not sure why you equate RESTful systems with distributed HTTP implementations (even if that's often the case); you can optimize these things across every part of your HTTP stack, minimizing hops and processes as you go along. Or am I missing something? Alex -- --------------------------------------------------------------------------- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps ------------------------------------------ http://shelter.nu/blog/ --------
