Hi Gregg, On Jan 15, 2008 3:36 AM, Gregg Wonderly <[EMAIL PROTECTED]> wrote: > All of my arguments are about what is specified, not about what is > possible.
Hmm, I thought we were trying to find out what is possible within the specified framework? As a SOA designer I don't just work with stuff that's specified; sometimes *I* have to do the specifying, and I certainly write on this mailing-list in that respect. > Portability and inter-working comes > about from standards, not from continued, repeated integration work. That's an interesting take, as I always thought continued, repeated integration work was what created the standards. Or are you here just talking about integration work between systems that have had their full stack standardized and their behaviour is documented as "completely according to plan"? > Based on the specification of REST, my opinion is that it's > only about transferring bits. I am, more or less, dismissing the usefulness > of the RESTful interface, because it doesn't include distributed systems > concepts and implementation details in the specification. What sort of concepts and implementation details would satisfy your thirst? I'm trying to understand your concerns and specifics here in order for me to conceptually understand how to define the various parts of REST, HTTP and any underlying business logic. Essentially Jini delivers possibly all of these parts (including an ontology in the shape of interfaces, I suspect), while REST and HTTP deals with only aspects of it. > The > Content-Length: and Content-Type: headers, are a typing system, which > further aids in the client knowing what it gets. However, the client still > has to > understand what it got. I don't see Jini understand "what it got" just because it handle Java mobile code, comes with an ontology (in the shape of interfaces), and work as a proxy. At some point even the miracle of Jini is detached from the semantics of your business logic, no? I understand it helps a lot, especially considering that enterprise requirements are somewhat repetitious, but my big assert is that a lot of enterprise technology designs comes from an RPC / function -> data centric view of the world. No, I'm not saying WS-* these days can't deal with OO concepts, but we often think of APIs as toolchests of functions and applications we can apply to given sets of data, and in that notion lies something that REST breaks; identity of resources. I don't think I'm getting my message across very well, but I do feel I need to bang on about it a bit, because, frankly, my angle here is always about SOA and design, and how to improve this whole "loosly coupled but neatly joined" world of computing. Maybe the thing here is that you deal with already specified frameworks and APIs that are to behave accordingly (and that's your preference), while I design APIs from given platforms (and that's my preference). So even if our goals and outcomes are (reasonably) the same, our methods for designing our SOA systems are at pole opposites. This is not bad, though, but make comparisons and discussions a bit difficult, and I'll admit to that for sure; I love design, scrapping the establishment, and creating something new in the hopes of solving problems poorly addressed by the old. :) > The Web works okay, but clearly, distributing client knowledge, about > servers, is a never ending issue. URIs change, servers disappear overnight, > and all > kinds of things change (which version of the flash player do you need?) > that make the client's (the users) life difficult. If your JVM goes down, how does Jini save you? Surely you're talking about certain parts of your network having troubles. "The web" is the backbone of (and I assert) most of the important business and information needs going on today, so the web does more than "work okay"; it beats the pants of any other alternative out there, not on technological sexiness, but in real-life application. Sure, there's worts and all, and some of its success can be attributed to luck, but it would not have survived (and indeed didn't in its first iteration) if it didn't have merits on which to build on that solved real problems. Some of the principles of the web were always there but not specified very well, which is why REST as an architectural style came about, and the massively distributed nature of the web sits at the core of it. However, as mentioned before, the reversal of the addressable function space (resource -> operation as opposed to function -> data set) is a *huge* part of the key to why RESTful HTTP solves elegantly (in my eyes) problems that are hard in the "normal development world" of APIs, functions and data sets. Having said all that, I also only think RESTful HTTP deals with 80% of our distributed systems needs, and that there of course are things you need other solutions to handle. Maybe you're in that space, I don't know. And maybe I'm not, although I think I am, but then, because of the resource centric view that matches my knowledge management view and my Topic Maps view of the world, I also tend to think that I'm right and you're wrong, so there! :) No, I'm not right, but I'm right for how I work with systems and data sets is *really* what I'm trying to say, that REST deals with approaching data sets and identity in a way that leverages how I approach dealing with them as well. ... > Alex, I think you are focused only on technology neutral architecture > comparisons and the "what's possible". My arguments are about the > "technology specific features" and "what's specified". These are > good comparisons to have, but are arguments and discussion come > from 180 degree opposing positions it seems to me. You're probably right; I work very hard on SOA design probably a lot more from the ground up than what you do, but keep in mind that this discussion started because someone said "a RESTful system for a client failed *because* of REST, and we used Jini and it now works great", so that's the meat of the pie we're trying to suss out; what is it about REST that makes it unfit for certain scenarios (as an interface and architectural style) as opposed to someone just having done a shoddy development work (implementation). Surely someone can create shit using Jini too, no? My original posts asked if given a well-designed and thought-out Jini system (style and implementation in one) and a well-designed and thought-out REST implementation, which system brings what benefits and disadvantages, and I still think that's an important discussion to be having. Kind regards, Alexander -- --------------------------------------------------------------------------- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps ------------------------------------------ http://shelter.nu/blog/ --------
