Hi Gregg, > I guess I've tried with lots of different posts to point out the issues as > I see them and have been unsuccessful. I'll try again, and perhaps > I'll fail, but here goes.
Thanks for being patient with us. :) > REST is at a lower level then Jini. REST is about GET, PUT, DELETE etc. > Those are interesting things but don't cover things like "GET with > Transaction using this Lease" or "Use the Transaction on this database > action to control the DELETE on that HTTP operation". I thought that was at a *lower* level, making REST higher level? But I see what you say (heh, funny English semantics). Not sure that necessarily means there's things that can and can't be done in neither, as we're really talking about at what level certain abstractions come into play. You can perfectly well define what you say above trough REST, for example ; GET http://example.com/some_service/resource?transactionID=xxx&leaseID=yyy You're right that REST doesn't concern itself with such details, and rightly so; it's an architectural style, not an API (although with bits of API in it, albeit minimal) nor an enterprise application framework. I think we're getting deeper into implementation specifics, and that that in itself is perhaps the biggest difference between REST and Jini at this stage. > Transactional systems have a wide > range of interfaces and needs. Needs, yes. Interfaces? Only in certain technological circles. You can well define this stuff through REST, be it through a simple interface and URL semantics, or parameterize it in a more API like fashion (although I don't like the latter). > The Jini spec contains the semantic specification and API specification for > all of these types of activities so that your software can utilize exactly the > features of the system as it is defined. Sure, and I don't think REST competes with Jini in this in as much as Jini being much closer to enterprise API's than the open-ended REST. Having said that, you still can define what Jini defines within the REST style. I guess you guys haven't seen it (neither have I, mind you), and hence "REST can't do it" ? ... > My point is that if you have used HTTP to do RESTful software, without > transactions, leasing, distributed locking, space-based-computing etc., > then your view of Jini is likely focused on what you perceive as the > differences. 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. Are we arguing about undefined performance issues? I tend to think that any performance issue is a design issue, and that the interfaces and abstractions are part of it; as such, REST gives me the freedom to design these abstractions the way I see fit (including for performance), while Jini is a more black-box approach. Sometimes black-box is good for customers, other times it's not. ... > However, the Java mobile code facilities are what make it possible to > decide, without client changes, what the service implementation needs > to be. I've outlined before that the three dividing spaces are proxy, > smart-proxy and local code. So if my RESTful SOA (ROA) has a generic XML interface, this also can make the implementation detached from the service definitions, right? (Apart from being "stuck" with XML, of course, in which we break out our Json or other Content-type based responses, like Atom Publishing Protocol (APP) and others) > Transactional (the effects must have transactional behaviors) processing is > vital for distributed system coherence. Leasing is vital for recovering > transient operations/resources in a distributed system. Sure, but REST has no restrictions on the semantics within the interfaces and systems you define *through* REST, apart from that state is represented (and not actually being) through hyperlinks and that each request is complete (which could be interpreted as orthogonal to transactions, although message-based or queue-based operations has been talked about and done with REST both here and other places (and I'd argue that the overhead of this far outweigh the benefits of atomic operations on an architecture as a whole). Maybe the "dispute" so far comes from *where* your abstractions through your interface cross with the underlying implementation details. Jini seems to be at a more specific point between the concrete and the abstract, while REST, in my eyes, is completely abstract. It leads me to think I should see about replicating Jini APIs in REST to see if what I say is true. (Will have to hold, though, as I'm in the middle of changing jobs *and* countries) > Sure, RESTful applications can do these things, but they are done with > programming libraries or systems which are not necessarily RESTful (but > might be). Not sure what you say here. RESTful applications are not RESTful? > So, the primary issue for me is that while REST might be used as part of > the implementation of such systems, it doesn't in and of itself provide these > features. Yes, it's true that REST doesn't specify a whole number of implementation specific stuff. Doesn't mean it can't do it, though, which a lot of people tend to say. > Jini's specification include all of these types of facilities and thus > provide more than what REST provides (even with HTTP). Something specific offers more facilities than something abstract? Hmm, I think we're comparing apples and bananas at this level of design, to be frank. Also, REST does the "reversal of functional specification" thing where the focus is on identity of "things" rather than the traditional identity of APIs, which certainly confuses a lot of people (including me at times). > I'm not sure how else to illustrate my viewpoints. Hopefully this is more > helpful than my last response seemed to be. Thank you, it helps a lot. I think our discussion is a bit apples and bananas, at least on a generic level. I understand that Jini offer specific things in terms of enterprise operations on top of more generic things which REST also offers, but I also suspect that REST philosophy is reversal of the Jini API way of thinking (API -> operation -> thing vs. thing -> operation/API), so in that sense they're hard to compare. 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. :) I'm still keen on finding out exactly why Patrich May's REST application didn't perform, though. I'm betting my boots on REST being the right solution for a lot of my enterprise woes, and I would *really* like to understand why it didn't cut it this time. And, dare I say it, I'll see if I can look into Jini, too. Kind regards, Alexander -- --------------------------------------------------------------------------- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps ------------------------------------------ http://shelter.nu/blog/ --------
