On 11/12/06, Andrew S. Townley <[EMAIL PROTECTED]> wrote: > > > > > > > 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.
I've given that a shot too... still not getting anything. My fustration on formalism remains. > > 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. I'm probably a bit blind, but I don't see the massive independent evolvability on the Web as something amazing, its been IT history for a long time that if you can properly separate systems then you'll have a better time at evolving them. You could do that with MQSeries, and I've done it with ERPs, Mainframes, Unix, Windows, Java, .NET, all able to evolve independently but communicate via standardised protocols. > 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. +1 on that. SOA != WS && SOA != REST > > > 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. Pretty much, but its not complete (which is fine). > 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... Not disagreeing on the later, but REST is to me a very minor technical evolution of TCP/IP and does progress the real "next" challenge which is to standardise application/service/enterprise/business level interactions and their semantics. It could help at the stack level, but it doesn't progress the harder challenges. > > 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. :) WS-* is already out there in production in many enterprises demonstrating exactly the advantages that REST claims. One of the bits that this whole REST v WS debate tends to miss is that the important factor is people, WS-* with its "pretty" GUIs and its security, reliability etc standardisation helps with the people factor. > > > 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. Evangelism about technology is a bad thing(tm). > > 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. +1 > > 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?". +1 And the real cost there for is in the maintenance of systems, not in their development. So any approach must factor in the cost of change, and the thing about change that we have learnt of the years is a) The quality of the support team is liable to be less than the original dev team b) Formalism and process wins over technology. c) Systems are in operation, when successful, for many times their expect lifecycle. Technology will not be able to solve basic business problems, if you change things then there is an impact, you can minimise or hide the impact but it cannot be reduced to zero. Hell it could be argued that physics sort of demands that! > > 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 don't disagree that we should be looking to improve things, I just don't think we will do that by looking at the problem at the base layer. When man flew it was because he understood aerodynamics, over just trying to copy the birds. Right now this REST v WS-* is techies trying to solve the problems by focusing on technology. > > 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. Agreed, which is why I think that REST is a dead end, its down at the exchange level, its not at the business level. IMO in ten years time we will be laughing at the idea that the execution context was the stuff of such debate. > > 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 > >
