Hi Gregg, I wrote: > > GET > > http://example.com/some_service/resource?transactionID=xxx&leaseID=yyy
Gregg Wonderly <[EMAIL PROTECTED]> wrote: > The use of those parameters in the URI is a proprietary type of solution. The implementation certainly is, but the interface is not. But this was just an example. I don't know Jini or Jiri, but I'm sure there's ways to RESTify their semantics. > It works for that service because I know how to use that service. Which isn't different to "Jini 'services' works because you know how to use Jini." I understand what you're trying to say, I just don't agree with it, and, I suspect, you guys see REST well outside any internal API structure, yet that's exactly what I'm talking about. > With Jini, there is a single way to do it, through the Jini > lease service. [...] That separates the implementation of > the lease and transaction, completely from the actual service. But in the end, it's an API with semantics that someone has agreed upon. It's the API part that can be compared to REST, not the semantics themselves, nor the executable code. > The Lease and the Transaction object are marshalled around the network and > become live objects everywhere that there are participants. RESTful > services might let me transfer the marshalled representation, but what > is the value added besides that transport, especially when TCP > can provide the exact same guarantees with the Jeri stack running > over it, and it's already in place. So what you're talking about here is that Jini is transport independent, and that this transparency is overly important. Ok. In theory so is REST, but with HTTP being the biggest implementation that most people talk about, I guess there's a number of technologies implied. You can implement non-HTTP RESTful systems in any technology you like, but I tend to think that reusing the defined semantics of HTTP is a no-brainer. ... > REST (with HTTP as it's most visible implementation), is > about accessing resources to perform limited operations on them. Limited operations? No, you can perform any operation you like, but the *interface* has limiting constraints. We must not confuse resources with objects or API's; they can themselves be operations, stacks, proxies, caches, leases, transactions, queues and so forth. This is why I say Jini can probably by defined equally well with REST instead of a Java API. > Jini is about implementing distributed systems (more than 2 > participants) which require standardizations across the board > to allow everyone to have the same view of the > world. For that, I'd choose HTTP for sure, given its track-record of being designed for exactly that, with scaling to millions as part of what it does quite well. [UNIX allegory] > REST, because it doesn't explicitly detail many > things that the Jini specfication does, isn't anything more than a data > transport mechanism, from a standards perspective. I'd say state and caching goes beyond that, but hey, REST isn't *supposed* to handle all that Jini handles; it's just an architectural style with an interface. On *top* you put APP or WADL, or, in a dream, a Jini implementation. :) > Custom implementation can be > done quite readily to ammend URIs and returned results with proprietary > information that the client and service share the knowledge of. At some point in the Jini stack I assume a developer writes custom code. This whole debate is, as I've tried to say before, about *where* in the abstraction we write that custom code. Yes, you're right that Jini - being a stack, a platform, and API and lots of Java code - can do a lot of stuff that REST can't and shouldn't do, because REST is an interface and Jini a whole technology stack. I'd like to bring this back to the SOA perspective, though, because in the end our clients aren't going to care too much about the inner workings of of the stack and technologies as long as the job gets done and it offer possibilities for the future. We agree on this, yes? And can we agree that in a SOA we are concerned about decoupling and defining our apps and protocol interactions through this mysterious notion called 'services'? For me it's important that the interface to my SOA is technology platform independent (or more specifically, programming language independent), and I fail to see Jini in that way. You say there are ways to do external invocation (if I remember correctly), but you are still tied to Java as a network owner. Now, if you're happy to marry Java, I think Jini sounds like good stuff, but I'm not prepared to marry that bitch, especially not given the shere amount of legacy systems and non-Java developers out there. Through REST they can choose pretty much any underlying technology that fits the organizations strategy. Didn't I just see HTTP over TCP/IP implemented in Lego (the plastic toy bricks) the other day? :) > Because Jini is a spec and uses a spec based programming language, there > are countless things that you can depend on being there, or have > expectation to work as specified. With RESTful systems, everything > that the URI supports and that the returns can convey are documented > externally to any programming environment. Hmm, I'm not following this at all anymore. A "spec based programming language"? Are you referring to the Java language spec? Also, you say "everything that the URI supports", but I'm pressed to understand what you *cannot* address through a URI. You can always look at something like RESTlets for Java implementations, like extensions to JavaBeans (which are semi-RESTful on the interface side of things). In theory you can make implementations that make REST as much part of your programming platform (or language spec, if you like) as to be almost (if not completely) transparent to the programmer. *And* use it for external interactions too. How cool is that? ... > Right, but the fact that you have to interact with an arbitrary > implementation means that a client that might drop into such > a system has to have explicit knowledge of all the systems > it needs to interact with. With Jini, that knowledge is exactly > one interface, because its through a service, not through > an arbitrarily decided/spec'd parameter to a URI. I must be in a stupid frame of mind today, but what is the difference between an arbitrarily decided/spec'd parameter to a URI and an arbitrarily decided/spec'd method-call (even if it's in an interface)? In the end they are two different implementations on the *same* semantic meaning. One is married to Java/.Net/OO, and the other is not, so are you saying that the OO aspect of Jini is what makes Jini a winner, even when we're talking about SOA (with perhaps more than one OO implementation). That actually reminds me that OO is a reasonable example of REST, in the sense that by reading PHP OO you can pretty much work out what it does even if you're a Java OO developer. The same works with REST. And the very thing you and I are really talking about is the *semantics* Jini places on top of its language implementation, so in other words you can express and interact these semantics with OO, or you can, I assert, express and interact with them through REST. I hear your point of the single interface (and I suspect you mean OO Interface here?), but you're still bound to understand the semantics of that interface, no matter which implementation you choose. So is this then turning into a OO vs. anything else as a programming / development model for SOA? Because as such I'd say that if you think OO is the Saviour to all your SOA woes, then yes, REST will fail you. (However you can percetly well serialize and stream OO objects or API's across a RESTful system, through XML or anything else you choose, text or binary serializations) ... > > But I do do RESTful systems with transactions, leasings, locking and > > more (well, I try to keep it as simple as possible), so REST *can* > > certainly do it even though it isn't specific about it or part of its > > interfaces. > > Yes, but each time, you implement it, you are implementing something that > the client tells the server to do in their request. A third party can't be > involved without some other explicit interface to provide for that > interaction. Hmm, so you mean beyond client-server, where Jini works as a broker system, or events system, to messaging across various systems? I don't see why not RESTful systems can do that (the interface side of things), but HTTP certainly isn't designed for that (even though I'm sure you can extend it to do it still). Again I'd stress that REST is an architectural style, not an enterprise business API and stack. > Because > the notion of transaction is in the Jini spec, that interface is already > defined and available. It's that standardization that makes > development go faster. Sure, no disagreement there. In the REST world there's a few best practices, but certainly no standard way of dealing with it. ... > http://some.service.host/someresource?role=admin > http://some.service.host/someresource?role=manager > http://some.service.host/someresource?role=user > > The ServiceUI standard would be equivalent to role=XXX as being the > REQUIRED way for any URI on the planet to ever provide for different > role usages of the same resource. REST doesn't "specify" this detail, Nor should it. That's the job of the next layer, such as the Atom Publishing Protocol which defines a generic repository API in a RESTful way, for example. > nor does any other layer above > it. It's that lack of detail in the specification which makes me (and I > guess others) feel like I can't "depend" on HTTP for anything > more than "transport". But with Jini, you're relying on Jini to work in order to rely on anything else but transport over Java. Aren't you just saying that Jini works as a Java code proxy, but you're still dependent on Java doing the transport and that a JVM is required at both ends? That to me is more serious constraints in a SOA. ... > The subtly for me is that Java's semantic meanings are well defined, and > extensible through Java programming constructs. XML has no implicit > semantics, except for external references, Well, there's a few more bits, like defined behavior, semantic attributes (@id and @idref) and document references, but yes, it's by far more open-ended that something like a programming language. However, that's its design, and hardly something you can hold against it. ... > So, yes there might be some remedial similarities, but in the end, because > Jini is using Java mobile code, we can do much more on the client to > change the users experience and interface to the service than you can if > everything is a URI. Can you change its dependency on Java? Or the OO paradigm? Or the Jini specification / API? I think, all in all, Jini sounds great, if you're prepared to marry those three things into your SOA. [REST being free from semantic constraints] > Because there are no restrictions, there are no standards. ?? HTTP is a standard. APP is a standard. What do you mean? > Because there are no standards, the clients have to understand > all of the semantics of the URI processing needed. This is no different than needing to understand the Jini APIs. And there are standards for these interactions, with more emerging all the time (S3, Google services, SellPoint, etc.) > Because Java mobile code already exists and the Jini security > model locks down what can and can not occur from the downloaded code, why > would I choose to explicitly make HTTP-RESTful interactions a "public" part > of my application design? Because the world is more than Java? Or OO? And I'd stress, especially in a SOA wold. ... > I think we are starting to communicate! Sorry it won't happen again, and I think I've rectified the situation with this latest email. :) ... > As I tried to say earlier, if I, as a client of such a service, use such > things in a URI, how does another service that I am interacting with > know what to do with those things? Some form of standardization is > required. It's that standardization of a transactional service which > Jini provides. Yes, we agree that there's only tiny parts of Jini that we in all seriousness can compare to REST. For the rest of what Jini does, we need to compare that to some RESTful standard that does similar things. I'm sure someone is working on it, although I don't know of any right now. ... > I'm trying to illustrate the additional things in Jini to make it clear > that we are talking about more than transferring bits and the > RESTful operations Yes, I think that's clear. I'm starting to wonder how Jini fits the SOA moniker though, with loose coupling and strong coupling at the same time. I guess that becomes a business strategy decision more than anything. ... > > I'm pretty sure if my RESTful system doesn't > > scale or doesn't prform as expected, you can't chuck Jini on top / > > under it to make it perform better (as there are several stacks of the > > normal application stack I remove due to the resource orientation). > > Hmm, sounds like another article I need write. One day. When I get > > time. :) > > But you can, because as I illustrated above, the clients interaction with > the service can be dynamically changed to optimize almost anything > that the client does to interact with the service, because the code you > change runs on the client. So, you can use Jini right now on my C++ and Perl developed RESTful system to make it go faster? I have serious doubts about that. :) Anyway, back to stacking boxes ... Alex -- --------------------------------------------------------------------------- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps ------------------------------------------ http://shelter.nu/blog/ --------
