On 11 Jan 2008, at 17:51, Alexander Johannesen wrote:
> 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 )
Jini discovery does not require knowledge of specific servers and
ports. Multiple lookup services are allowed and these, like any other
service, can start and stop at any time. This makes for a very
flexible, scalable, and resilient infrastructure.
>> 4. A client starts.
>> 5. The client discovers the LUS using the standard Jini protocol.
>
> [client] GET http://example.com/wadl
>
> << 200 + WADL XML
Again, a Jini client doesn't need to know about a particular server.
Discovery of lookup and other services is completely dynamic.
>> 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)
Is there any REST implementation that does this? With Jini you get a
proxy that implements the interface you're interested in. Whether the
implementation is local, remote, or some combination is completely
transparent to the client. With your suggestion, the client would
have to know that it was getting a particular object and know how to
invoke it. That differs significantly from the usual REST approach of
passing a document to a URL.
>> 8. The client dynamically downloads any required implementation
>> classes (transparently).
>
> Void; still using REST.
I don't understand your response. This is one of the great strengths
of Jini: Service implementations can be added and modified
dynamically. The client doesn't need to know everything at compile
time.
>> 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?
Please explain how "standardized sprinkle" is going to change an
approach that relies on passing documents to URLs to one that allows
behavior to be dynamically co-located completely transparently to the
client.
>> 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.
As I mentioned in my reply to Gordon, this is equivalent to arguing
that all Turing complete languages are equally expressive and
powerful. There are tasks that are easier to accomplish in some
languages than in others. There are tasks that are better supported
by some SOA approaches than others. High throughput, low latency,
highly scalable, resilient systems can be developed in SBA
implementations like Jini more easily than in existing REST
implementations.
>> 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.
That is essentially the point I was making with my original
comments. The customer I was discussing needed a low latency,
scalable, resilient system. The only technology available now that
met those needs was a commercial product built on Jini.
>>> 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?
I was trying to address your question about the types of
modifications supported by Jini. The big three NFRs addressed by SBA
are performance, scalability, and resiliency, with total cost of
ownership a close fourth. In practice, with today's existing
implementations, neither REST nor the WS-* horde can address those
requirements for the most demanding problem domains. SBA can and can
also provide value in less demanding problem domains. That's why
we're seeing customers spreading SBA out from the extremes.
>> 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?
The term means communication between operating system processes on
the same machine. Jini does not require an interprocess hop. A space
based architecture implementation allows business logic, data, and
messaging to be partitioned such that an end-to-end business use case
can be executed in a single operating system process (a JVM, in the
case of Jini). These processes are the unit of scalability in an
SBA. If you need higher throughput, you run more instances. The
processes are also the unit of recovery. In a resilient system, the
combination of business logic, data, and messaging is backed up to
another node and can take over processing immediately if the primary
fails.
>>> 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.
By "separate" above I mean in a separate operating system process
from the client.
>>>> 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.
In my experience this is not possible. The examples I provided in my
original email (risk analytics, on-line gaming, algorithmic trading,
etc.) require extremely low latency. I work with customers who have
tried to use their existing tools and have hit the wall in terms of
performance and scalability. The only non-custom solution available
today is based on Jini.
>>>> 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.
But you said that you "can read any XML document and understand
roughly what's going on." That's just not the case with the XML
generated by many common enterprise products, most definitely
including SAP.
> 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.
While I agree with your first phrase, I find that XML encourages poor
practices. It is overly verbose and provides no guidelines for when
to use, for example, attributes rather than child elements.
>> 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 can get the jist, but getting the jist isn't good enough for
automatic processing. To the extent that XML is human readable, it is
overly verbose and adds little value. To the extent that it is used
to communicate between software systems, it is not human readable and
more efficient alternatives exist.
This is a side issue, though, so I'll leave you to playing with your
angle brackets. ;-)
>>>> 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?
Is there any REST implementation that actually works this way?
Regards,
Patrick
----
[EMAIL PROTECTED]
S P Engineering, Inc.
Large scale, mission-critical, distributed OO systems design and
implementation.
(C++, Java, Common Lisp, Jini, middleware, SOA)
