Michael, On Aug 12, 2010, at 11:56 AM, Michael Poulin wrote:
> > > I do not have any points to argue with Anne, everything is accurate and > consistent as usual. But I have (hopefully) related questions. > > To me, one of the major differences between the REST and WS-* is in that > "REST is a resource-oriented architecture" while WS-*, more accurately - the > things performing real activities reached via WS-*, is an > operation/function-oriented architecture. The difference between them is that REST guarantees you certain system properties because REST constrains architectural elements. WS-* does not constrain anything and hence does not guarantee any system properties. > When we model real business world in IT automation [via services and > processes (as service implementations)], we primarily deal with > operations/functions. Resources are also very important but only after we can > do something (realising WHAT and WHY). > > So, the questions are: (erm - hasn't that debate come to age by now? :-) > 1) how effective REST in the realising business functionality? What is the KPI for 'effective'? I can't see any integration inside an enterprise that can not be effectively done with HTTP. > 2) since WS-* and REST have relatively separate areas of 'expertise', Hmm - what are those areas of expertise? > would not it be a good idea to stop conquer territories of each other and > just use any one of the them where it fits the purpose? Another purpose - > another fit - another one to use. No other purpose. REST fits just perfectly well for enterprise integration. The idea is to do away with WS-* *completely* and replace it with HTTP. Jan > > - Michael > > From: Anne Thomas Manes <[email protected]> > To: "[email protected]" > <[email protected]> > Sent: Tue, August 10, 2010 3:10:35 PM > Subject: Re: [service-orientated-architecture] Steve on REST and Clojure > > I think the crux of this debate has to do with architecture rather > than technology. WS-* is a method-oriented architecture, it defines > its own application protocol (SOAP), and it uses HTTP (or MQ or ESB) > as a pipe. REST is a resource-oriented architecture and uses the HTTP > *application* protocol. Many folks that claim to "use REST" in fact > are using POX over HTTP, but they have not actually adopted a > resource-oriented architecture, and they aren't using HTTP as an > application protocol. If you "use REST" (i.e., as middleware) but > don't change the application architecture, you won't gain the big > benefits of REST, and you lose the benefits afforded by WS-*. it's the > worst of two worlds. But I'll point out the most B2B integration > relies on POX over HTTP. > > The biggest impediment to adopting REST is the learning curve > associated with grokking the architecture. As Jan said, he needed to > implement a few big projects before he really got it. Media types > provide the means for you to define explicit, machine-readable > contracts (e.g., via XML Schema). But the beauty of REST is that a > "service interface" (i.e., a resource) can support multiple media > types, making interface versioning much simpler. You can add support > for new media types whenever you like without breaking existing > clients. > > Regarding WS-* vs REST adoption: > > People flocked to WS-* and ESBs because they use the same familiar > programming models we've used for the past 20 years. That, and the big > vendors have pushed them that way. > > REST requires a different programming model and a different > application architecture. The benefits (scalability, flexibility, > serendipity, etc) make it worthwhile, but you have to be willing to > let go of 20 years worth of ingrained enterprisey programming models. > It's a significant barrier to adoption. > > The industry is experiencing a similar debate regarding database > architecture, i.e., SQL vs noSQL. The enterprisey perspective is > typically unwilling to let go of relational integrity and traditional > query languages. But if you a seeking massive scalability, you have > to. I'd like to see some of the industry's great data management > thinkers get out of the box and start thinking about building the next > great data management system build on hypermedia and integrated > metadata. But most are stuck in the rut of defending the relational > model. > > Anne > > On Monday, August 9, 2010, Steve Jones <[email protected]> wrote: > > > > On 4 August 2010 13:25, Alexander Johannesen > > <[email protected]> wrote: > > > > Yeeeehaw! > > > > Steve Jones <[email protected] <jones.steveg%40gmail.com>> wrote: > > > >> No I just want something beyond Google/Amazon/Yahoo. Just > >> one or two traditional companies leveraging REST. > > > > > > National Library of Australia. Or a few others I can think of, but > > you're going to say that these aren't traditional enough and / or real > > companies and / or serious businesses or somesuch, aren't you? :) > > Nope that would be a good one... reference would help. > > > > > >>> I feel you're asking about that new fangled invention, the "car" or > >>> whatever they call it, by looking in the barn for them. :) > >> > >> Nope, I'm being told that the flying car is really popular... but its just > >> all those regular cars on the road that I can see. > > > > > > No, no, no, you can't just go and change my allegory like that. > > Uncouth. Actually, who told you REST is a flying car? You're > > misinformed. > > Well apparently it makes everything easier, is completely dynamic and so > > much better than everything else... but you just don't see it around very > > often... > > > > > >> The reality is that the real challenge in computing is the one the > >> enterprise faces, namely the people side of the problem is the real > >> issue not the technology side. > > > > > > What a crack of nonsense. "The real challenge", eh? And only the > > enterprise face this problem? I feel you're playing up something > > terribly vague as something clear cut. > > Nope. Its basic Mythical Man Month stuff. There are no technology silver > > bullets and the real effort remains in the thinking and communication parts > > of the problem. > > > > > >> REST hasn't proven an ability to help there while WS-* (for all its many > >> faults) has. > > > > > > Hmm. What do you use as evidence that REST hasn't helped the "people > > side of the problem" as opposed to WS-*? What does that even mean? > > Big projects use WSDLs as a contract between different areas. These > > contracts are testable and able to be done upfront, this enables teams to > > work independently and thus increase their efficiencies. > > > > > > > >>> I know that > >>> until I really dug deep in REST I didn't see much advantage from SOAP > >>> stuff, but after doing a few runs of massively distributed systems > >>> something clicked. And perhaps there is a massive amounts of clicks > >>> that needs to happen, lots of little epiphanies that is required for a > >>> better adaption. > >> > >> But here in lies the problem. Most solutions don't require massively > >> distributed > >> solutions to work well > > > > > > Are you sure about that? Because as soon as the pipeline is clogged > > with too many connections, load-balancing, proxies and splitters are > > exactly what implies a distribution of the problem. We're not going > > into the future thinking the data dn the connections are going to be > > lower, are we? Seriously, even in the mires of dogmatic enterprise > > there is a huge push for better handling loads and volume, and the > > answer to that isn't faster CPU's, but distribution. > > > > Yup I'm sure about that because 99% of people in IT can't handle > > distributed systems problems. > > > > > >> in fact massively distributed and "working well" in support are pretty > >> much at opposite ends of the spectrum in most enterprises. > > > > > > Umm, this must be a unique viewpoint by the enterprises you serve. In > > all other that I've been to, "working well" means just that it works > > well, and if that includes distributed solutions, then that's what > > they do. Why on earth would these two be at opposite ends? Didn't > > Google teach you anything? > > Yup they did, part of it is the quality of people they have in support > > which is stratospherically above every enterprise I've ever seen. The > > challenge in a lot of enterprises is "smart" solutions that hit support and > > become problem children. > > > > > > > >> I've done massively distributed systems, and the quality of people > >> you need in support is a legion ahead of where most organisations > >> have support. > > > > > > Bah. Software and hardware are getting far easier with this all the > > time. I recently had a distributed system put together by a flock of > > abstract penguins. It's not that hard anymore, just a technical > > procurement of skills. The real challenge is - as always! - in design, > > which certainly doesn't only apply to distributed systems. > > The challenges are indeed in design, and support. The biggest challenge > > in my job is always reducing complex problems down into simple chunks. > > > > > >> This is the problem on technically focused "better mousetraps" they > >> are missing the point that that technology isn't actually the problem its > >> people, and in particular support, that are the real challenge. > > > > > > But if technology doesn't mean a thing, why are you looking for the > > whole REST vs. WS-* dichotomy? I think I'm missing something here. > > I'm saying that REST v WS-* has been a pointless debacle in the continuing > > drive of IT "professionals" to drive new technologies that fail to solve > > old problems. > > > > > > > >>> The ESB is > >>> *perfect* for the blame game, and satisfies a many managers at the > >>> same time! :) > >> > >> Certainly there is a blame point, but the issue with REST isn't that it > >> doesn't have a blame point its that it doesn't help CREATE the blame > >> points. > > > > > > Ok, you're scaring me now. Why the hell would you *want* blame points? > > > > Seriously? Why would I want to be clear where the actual problems were and > > have clearly defined borders against which people can be explicitly > > measured and tested? > > > > Tech that reduces them should be the aim here, unless you want to > > embrace middle-ware hell and middle-management bliss. > > So favour a lack of clarity and continual finger pointing? > > And also, what > > on earth does it mean that REST don't help create blame points? > > REST has a lack of standardised contractual approaches. > > There > > is no difference between our two contender in the amount of shit they > > can create given the right idiot behind the wheel. > > Actually REST can create bigger shit thanks to its dynamic contracts. > > I was pointing out > > the ESB trap, not the REST vs. WS-* battle; ESB is traditionally > > steeped in WS-*, but that's just a side-effect. Like you said earlier, > > the "real issue" is with how people are using these things, no? ESB > > comes with contractual nonsense in terms of where blame should be put; > > it shifts blame around rather than solving the problem. IMHO, of > > course. > > Whereas IMO and experience having that formalism (which is admittedly rare > > in ESB programmes) is actually the thing that makes the programmes > > successful and helps to deliver the value. Having a lack of control and > > enabling fluid change always results in finger pointing hell. > > > > > >> The good thing about WS-* is that you create a contract and > >> every bugger has to use it, people who don't are wrong. With > >> dynamic interfaces you don't have that rigour and in an > >> average enterprise this is death and complexity. > > > > > > What evidence do you present for ; > > a) dynamic interfaces don't have contractual rigour > > > > Errr the bit where they are dynamic and can change without informing the > > consumer via a standardised approach... How do I formally publish a REST > > interface to a consumer BEFORE the service is delivered and manage the > > change in semantic behaviour of the REST solution between multiple > > consumers and providers? > > > > b) enterprises who dare dynamic interfaces end in death and complexity > > I could, if NDAs didn't prevent me, name about eight companies off the top > > of my head where back in the old C days a really clever approach to code > > using dynamic interfaces (pointers to functions et al) really screwed up > > the code as it hit support. I myself made the mistake of creating a > > dynamic interface solution in CORBA in the mid-90s which required lots of > > funky coding and re-direction and created a really slick mechanism for > > deploying change without having to update the IDLs... I know for a fact > > that although it worked perfectly while I was there and reduced the > > development cycles it was dead 3 months after I left as it dropped into > > support and was (in the words of one individual) "too weird" for them to > > support > > > > > >>> like the cost of maintaining several but similar layers of technology. > >>> ESB vendors will slowly move to REST, and customers will slowly > >>> follow, even if it takes another 10 years or so. > >> > >> Which means by my reckoning that REST will have put enterprise IT > >> back by 15 years because it doesn't address the real problems that > >> exist in enterprise IT, instead it seeks to solve a problem that isn't > >> there. > > > > > > Again, this is utter nonsense. What on earth is a "real" problem? > > PEOPLE and more specifically how teams communicate and increase the > > separation between their areas and enable systems to be developed as > > independent entities which collaborate rather than as big blobs which are > > melded. This is the real problem with IT, particularly at scale, and has > > been for 30+ years. Approaches such as Design by Contract (late 80s, early > > 90s) demonstrated some progress in this and from experience the rigour of > > doing interface first delivery certainly helps on large scale programmes. > > > > You > > are probably thinking of something specific that fits your paradigm, > > but I doubt very much that there is only one way to solve whatever > > problem you're thinking of. Come on, there are no "real" problems as > > opposed to other problems that aren't worthy of your attention, you > > just have some specific solutions in mind to problems the rest of us > > haven't been told of yet. > > > > Maybe it is something specific to my way of viewing the world, and I look > > forwards to someone making my life easier by showing a better way of > > working in complex programmes. A new technology is highly unlikely to be > > that thing however if it continues to concentrate on the IT plumbing. > > > > > > "REST will put the enterprise back 15 years?" You aren't serious about > > such a statement, are you? Seriously? Because, well, you know, it's > > stupid. :) > > Okay not back, just no progress. REST is good for website design but that > > is (IMO) not much of a challenge anyway, REST has not shown how it improves > > the situation beyond the website. > > > > > >> The real problem of enterprise IT is how to get disparate > >> teams working together and defining the clear boundaries between > >> them that ensure they can work independently and test > >> independently and control their area. > > > > > > So? (I mean, apart from this hardly being *the* real problem we all > > have) Where in REST vs. WS-* (we should come up with a name for this) > > does this even bring points to the SOAP side? Are you back to > > contracts? I think several people in the past have pointed out that a) > > REST lowers the need for contracts (depending on the job), and b) you > > can still have them if you want (but you make them yourself). > > Nope, people have said it but I've never actually seen how that works in > > practice. writing your own contractual approach is just a step backwards > > and does not aid in the collaboration between people and organisations. > > All this > > point is boiling down to is that no big standard of contractual REST > > hasn't been made yet (but, there might be a reason for that, like the > > actual need for it being low), and that I grant you, but that's not a > > problem with REST, it's a problem with those who need and make big > > standards to support themselves.IAhhhh I see. Or rather I 100% disagree. > > The reason that REST is avoiding things like contracts (IMO) and security > > architectures and definitions around more complex pieces which are required > > in enterprise computing is that they are actually hard things. Its much > > easier to say "oh its the web" and ignore the problems and come up with a > > personal half-baked solution that works for your project but no-where else. > > > > > >>> Hmm, I can think of a handful of technologies that are technically > >>> better than what ultimately became the success story. Success has > >>> often *very* little to do with technical merits or the problem at > >>> hand. Often it is pure luck and someone just friggin' did it first > >>> that way, and it stuck. > >> > >> I can think of loads of better people solutions that failed due to > >> technical > >> bigotry (Eiffel and Ada v C for instance). > > > > > > What's a "people solution"? And what do you mean by bigotry here? > > "C is more efficient because it uses less characters" was a refrain I > > regularly was told about why C was "better" than Ada. This amazingly fails > > to recognise where the real challenges lie in IT. > > > > > >> IT continues to miss the point (IMO) on where the real challenges are. > > > > > > Aren't you broadly assuming millions of people are all wrong, only you > > are right? > > > > Nope, I'm actually assuming that folks like Fred Brooks, Yourdon, De Marco > > et al remain pretty much as right now as they were when they wrote their > > top books in the 70s and 80s. > > > > > >> This is why companies like SAP make a fortune and people who code > >> custom solutions don't get why. > > > > > > Huh? SAP is making a fortune because you *can* customize it (I've > > never heard of anyone using it out of the box without modification), > > > > Really? I have. Most of the time people customise SAP its because they > > can't change the way they think and shouldn't have bought a package in the > > first place. > > > > > > so I don't understand your hint that SAP somehow hits the sweet-spot > > (in fact I've customized SAP enough to know just how much it *isn't*). > > Some companies make a fortune with custom solutions, some are open, > > some have good ideas and poor tech, some have good tech but poor > > ideas, some have cool names, some have excellent sales people, some > > have bad technicians, some have open API's, others have the E-R > > patented (or want to), some have locked down everything, and lots of > > them are somewhere in the middle. And lots and lots and lots of people > > in both camps understand perfectly well why SAP makes a mint and they > > don't. > > > > In other words, what you're saying here is just fluff. Lots of > > companies are making lots of money by making shit, and others are > > making lots of money by making gold. And we're *al > > > > > ----------------------------------- Jan Algermissen, Consultant NORD Software Consulting Mail: [email protected] Blog: http://www.nordsc.com/blog/ Work: http://www.nordsc.com/ -----------------------------------
