Yeeeehaw! Steve Jones <[email protected]> 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? :) >> 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. > 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. > 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? >> 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. > 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? > 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. > 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. >> 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? Tech that reduces them should be the aim here, unless you want to embrace middle-ware hell and middle-management bliss. And also, what on earth does it mean that REST don't help create blame points? There is no difference between our two contender in the amount of shit they can create given the right idiot behind the wheel. 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. > 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 b) enterprises who dare dynamic interfaces end in death and complexity >> 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? 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. "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. :) > 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). 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. >> 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? > 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? > 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), 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 *all* in IT. Regards, Alex -- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps --- http://shelter.nu/blog/ ---------------------------------------------- ------------------ http://www.google.com/profiles/alexander.johannesen ---
