On Sun, 2006-12-10 at 13:30, Steve Jones wrote: > With all due respect here I think you are massively missing the > point. My issue on REST is that no-one can explain to me how to > formally document an interaction in a standard way and that people > can't even agree on the "right" definition for a URI. Its fine to > _claim_ that something requires a new way of thinking but having read > the REST paper (and various other works) I'm not seeing much different > (architecturally) over the Unix pipes solution of the late 80s & early > 90s. Just because something moves over a standard port doesn't (IMO) > make it special.
I didn't intend to make you upset, and I realize you're pretty frustrated at this stage. All I can say is that I had to read the dissertation at least twice over a period of months of background thinking/digesting what it was trying to say and relating that to the Web, caching and aspects of HTTP I hadn't ever really paid attention to before I even started to see the light bulb dimly come on. In a lot of ways, re-reading the HTTP specification (numerous times) helped it make sense--sorta. My best public attempt so far was RRMTP, and I got it a bit wrong on a couple of fronts. Mostly, it isn't hypermedia--but that's on purpose. A number of people think it's too complex, but that's mostly just because the state transitions try and make my resource (a box to hold an arbitrary octet stream message) behave consistently for all of the HTTP verbs and allow clients to get the right responses during the overall message exchange life cycle. Even to get that far, I had to figure out what the hell my resources should be, which was very, very hard, because the original things I came up with didn't really play well with the semantics of HTTP. After re-reading the HTTP spec again, thinking some more and trying some stuff, I realized I needed a new abstraction that wasn't part of my original problem domain. I suppose you could argue at this point that my approach makes it harder, therefore REST is harder than to expose a message queue metaphor via HTTP. However, when I came up with RRMTP (as flawed as some people may think it is), it gave me a whole lot more flexibility within the rest of the overall architecture that I didn't have before. Even though it isn't my job anymore, I still have a few ideas on how RRMTP could be really useful. They're a bit further down the list of priorities at the moment, however. > Saying "the Web is different" is a fairly glib statement if it can't > be backed up with "why". So far the advantages I've seen with REST in > terms of simplicity have been stripped away when you actually ask for > the simplicity to be defined. I didn't provide a "why" because I don't think I have a better answer than anyone else on this list. As I said, many other people are much further along with the REST epiphany than me (sorry I left Stefan out of the earlier message, btw). I *think* I know some of it, but I don't have all the answers, and there's still some problems I can't figure out how to solve (or I'm not willing to make the trade-offs required to "follow the rules" as I understand them). Maybe I'm just being thick (or stubborn), but if one *can* figure out a way to apply REST to both integration-oriented SOA and information-oriented SOA to deliver the same sort of independent evolvability (if that's really a word) that all of us have seen manifested on the Web, that would be something truly impressive. To be honest, I'm also not that focused on the integration-oriented SOA space at the moment, because I think what SOA is about to me is bigger than that. That doesn't mean that it's not important, but I sorta have the "been there, done that, bought the t-shirt" kinda feeling about it. > At the moment I see a massive hype around REST which doesn't take into > account the engineering disciplines of the last 30 years and which > appears to being pushed as a magic bullet. Lets be clear, I've used > MQ, CORBA, RMI, WS-* (.NET and Java), custom, Unix pipes, ftp, shared > directories and other mechanisms in commercial projects, and I've only > played around with REST, and every single one of them has issues and > advantages technically. Maybe the hype doesn't, but I'd say the dissertation's pretty well grounded in the software industry's experience of the last 30 years. But, again, I think the difference is contextual. The thing that I think distributed computing can learn from REST, even if we end up with something else, is to *somehow* have a ubiquitous message transfer mechanism that provides late binding and allows the inevitable change that happens in technologies to occur in a controlled and well defined way (thanks to Jan for jogging my memory about this). Look how much having TCP/IP as *the* basis for most networking has allowed us to achieve... You may say that SOAP+WSDL achieves this, but I don't believe that myself. If I'm wrong, then I've learned a lot from being wrong. :) > But in EVERY project I've ever had the major issue has not been the > technology but the communication between teams and organisations on > the application and business level interactions that we have been > delivering. The percentage of time spent on this part has dwarfed the > time spent developing the bit of code that shifts information from A > to B. What I'd like to see is people concentrate on solving that > problem rather than yet another "magic" improvement to shifting data > around. REST has clearly not advanced the state of the art for this > problem, and has indeed regressed against previous approaches. I won't argue with you that 9 outta 10 times the business/personnel problems trump the technology ones. However, I still believe the first 3 chapters from Boehm's Software Engineering Economics, and I haven't really seen much that says 26 years later we're much better at changing his 30/70 ratio. The only way I see to change that is to be smarter about the way we design software systems. In this respect, I guess I'm more pragmatic than evangelical concerning REST. I truly believe that SOA (the business concept) is the best thing yet to provide the drivers for an evolvable technology platform for intra and inter-organizational collaboration, but if we're really going to build a platform or infrastructure that will evolve with the business as well as do something about the astronomical total costs of ownership, we'd better get it right this time (or at least as close as we can make it). Otherwise, the technology debacles are really going to hurt us badly. ERP and EAI were smaller-scale, but the world was smaller then too. We can't ignore the Web or the public Internet or what made them work if we're going to solve the Internet-scale SOA problem. To me, that's the problem we need to solve at a technology level. There's no central control, and there's no guarantees about (hardly) anything, but there's still gotta be a way to make it all hang together so you can do business with your customers and your partners without worrying about "If I change this, a) what's going to break? b) how much is it going to cost? and c) how long is it going to take?". Pipedream? Maybe...but then again, so was the airplane, a man on the moon and being able to make free telephone calls (with video!) from one side of the globe to the other. I'm not saying REST is the answer (maybe because I don't fully get it yet), but I am saying that I don't think we'll get where we need to be by solving problems the same way we've been doing it for the last 30 years. ast > On 09/12/06, Andrew S. Townley <[EMAIL PROTECTED]> wrote: > I started to write a response to Gervas & Sanjiva's emails, > but then it > got long enough and tangential enough to what we were > discussing that I > decided to post it instead. > > Basically it tries to illustrate why Steve and other people > (including > myself, depending on the day) may be having so hard a time > understanding > REST. It also echos what Jan said about the relationship of > WS-* to > CORBA, but not quite so succinctly... ;) > > You can find it here if you want to read it: > > http://atownley.org/2006/12/socio-political-and-commercial-motivations-for-ws/ > > Cheers, > > ast > -- > Andrew S. Townley <[EMAIL PROTECTED]> > http://atownley.org > > > > > > -- Andrew S. Townley <[EMAIL PROTECTED]> http://atownley.org
