On Jan 7, 2008 3:25 AM, Patrick May <[EMAIL PROTECTED]> wrote: > 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.
Sure, thanks for taking the time to explain things. I've got some comments to that here. You said ; > With Jini, a service is accessed by retrieving a proxy from a lookup > service. This proxy provides the interface for the service. The > implementation of the functionality provided by the service may be > running elsewhere on the network or it may be contained within the > proxy itself (or some combination thereof). Our RESTful SOA does exactly this, where the main URL tree is simple a proxy to other services, internal and external, which directs based on a number of parameters. I don't see the technology being a limiter by this. I suspect you don't like HTTP, which, all in all, is a different issue. Further , you said ; > Jini service implementations can be modified without impact to the > users of those services as various NFRs are addressed. REST > implementations do not allow this level of optimization to take > place transparently to the client. That depends on what you mean by "modification." In addressing? 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. I'm trying to find out why you think REST (often as opposed to HTTP) have these limitations you speak of. Can you say some specific limitation you know of, like a use case? In other words ; > I don't see any competition. There are things that REST simply can't do. ;-) Keep shootin' :) >> First, Jini is a technology and REST is an architectural style. > This is not entirely accurate. Jini is a particular implementation of a > more general architectural style. I think he was pointing out that *REST* is an architectural style, not implemented technology (such as HTTP being one). This is partly by biggest gripe, that when people say "REST can't do X", they really mean "HTTP can't do X", which often tends to be "someone didn't fully understand (how to use) HTTP", although the latter statement may not apply to our conversation right now. Just speculatin' :) > It is certainly possible to implement a system under an SBA using a RESTful > style of interaction with services. It does not appear to be possible to do > the > reverse. The requirement to use a separate HTTP server to invoke services > in a REST architecture prohibits some types of solutions, such as the one I > described above. 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. I'm pretty sure that all you say Jini can do above you can do with a REST interface. We're talking about using interfaces for different things, from end-user interactions all the way in to API core systems. Technically, you can do both with the same technology (be it Java or Perl or all the others) but with different architectural constraints on top. I guess the only thing that you might point to giving you problems in REST would be that each request must be complete, but you yourself decide where that starts and stops in your design, so I'm not willing to blame it on the interface at this stage. Anyway, onwards ; > My other message goes into more detail, but one significant issue is > the latency inherent in invoking REST services. No, you mean HTTP. ... > 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. Ok, so I'm an XSLT buff, but I assert with this as with everything else that even when the underlying technology is elegant, give the tool to a monkey and they will try to use it to wipe their bottoms. Crap in, crap out, and I'm not prepared to blame it on the technology. XML done right *is* elegant. The trick is to do it right. This crazy notion even works for Java. :) > 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"? > 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. REST doesn't have this problem. HTTP often does. ... > > So if people talk about REST, they're not making real systems with it? > > Not while they're talking about it. ;-) Unlike you who can do Jini and talk about it here at the same time. It's *that* good! :) Regards, Alex -- --------------------------------------------------------------------------- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps ------------------------------------------ http://shelter.nu/blog/ --------
