But as with any technical discuss there is another thing that should drive you when you look to your decisions. This is whether you want to get fired for a decision when something goes wrong, and whether you want your skills to be relevant in 3 years time.
REST v WS is pointless from a technical perspective IMO, and will become more so as tooling sets improve.
From a business perspective however the choice is much more stark, and really doesn't come down well for the folks in the REST camp.
Out in the big wide world of the great employed of IT there are four dominant software players, these people represent probably the majority of IT spend in themselves and influence probably a good 95% of the total IT strategy out there on planet earth. Those four companies are SAP, Oracle, IBM and Microsoft.
These are the companies who your CIO goes to visit and sits through dinners and presentations on their product strategy, and what they are pushing is WS-* in all its ugly glory. This means that in 3 years time you 100% will have WS-* in your company, in a company you work with, or in a company you want to work with. Sure you can argue that its harder and more difficult than REST, in the same way as you can argue that Eiffel, PHP or Ruby are more productive languages. Some people will get to use these language commercially, some people will get to use REST commercially.
Everyone will have to use WS-* commercially if they want to interact with systems from the major software vendors.
I'm not saying its right, just that its reality. The best technology isn't the technical purest, the most productive or the easiest, its the one that the most people use and which has the widest acceptance and adoption. For shifting data across the internet this means its what SAP, Oracle, IBM & Microsoft say, its also what the various vertical standards (who the big boys aim to implement "out of the box") who have also all gone for WS-*.
The technical discussion is pointless, the commercial discussion is mute. But hey lets continue having the discussion on REST v WS because it makes us feel cool and trendy. Its about time that IT people realised that we need to have discussions based on commercial realities not on technical fantasies.
Technorati Tags: SOA, WS, REST, Service Architecture
38 comments:
+1. I'm presently editing my own post on the whole debate, as well, and my conclusions are similar to yours. WS is here to stay, love it or hate it. As you rightly point out, the big four are far more important to large enterprises than Amazon or eBay.
Seems like a rather defeatist attitude. Try telling Google to listen to your big 4?
Hey, both of those are better than my current job!
Managers and power point jockies listen to the big four. Engineers like to Google, Amazon, etc...
:-)
"Everyone will have to use WS-* commercially if they want to interact with systems from the major software vendors."
So the major software vendors will no longer produce systems which work on the Web..?
I don't want to tell google to listen to the big four (although they do use Google SOAP so they do appear to be listening).
Business listens to SAP, IBM, Oracle & Microsoft, and for most of us its them that pay the wages.
And Danny, if you think that Amazon and Google will have more impact on technical standards than IBM... well some information to back that up would be great.
Steve, I believe the Web will have more impact on technical standards than IBM. That's Amazon, Google *and* the millions of other sites and services.
While the WS-* stack may have parts derived from the Web, I'd suggest the misalignment from WebArch is likely to prove a handicap long term.
While it seems likely that the big four you mention will push WS-* more, it doesn't follow they will abandon more straightforward Web technologies.
Another consideration is that the major vendors don't have ultimate control of the global marketplace. For example, even if they did drop all their other avenues in favour of WS-*, there'll still be plenty of work for people that know the LAMP stack.
Danny, who do you think created all those Web standards? Google, Amazon or more ridiculously LAMP... err no have a check out at The Internet Engineering Steering Group which has IBM as the chair... or how about HTTP 1.1 with Microsoft.
The point I'm making isn't that no-one knows LAMP or REST or whatever, but that hundreds of billions of dollars is backing the WS-* approach, and a few techies and "cool" companies are backing REST. So sure be cool and do something trendy, but if you want a career in five years time make sure you know WS-*, because while you might have to use the REST APIs for Yahoo, you are almost 100% going to working at a company that has Microsoft, SAP, Oracle or IBM Web Services.
"a few techies and "cool" companies are backing REST"
Everybody who backs the Web backs REST (at least in the way "REST" is being used in this discussion). By that measure, the investment being made in Web services is relatively miniscule.
But this discussion really won't go anywhere until you understand the architectural differences and the costs of those differences.
Billions of dollars was also invested in Java by big corporations to write internal webapps, and I don't see Java being a big player on the real internet.
You heard of ebay?
Mark read the Mythical Man Month it has a good section on why its better to have a consistent architecture than continue to argue over supposed technical perfection.
The job of engineers is to advise and make decisions based on technical merit. The job of the business is to override those decisions and ignore that advice, if necessary, based on commercial needs. That's just basic Separation of Concerns.
Asking engineers to make decisions based largely on commercial merit isn't likely to lead to their making optimal decisions either for the business or for their careers.
IBM et al were big backers of CORBA too. How well did that work out? Microsoft sunk a ton of money into OLE/COM/ActiveX/COM+ etc.. Didn't exactly take over the world did it? IT groups that fixate on ill-defined "standards" that only interoperate when all the planets align just so and swallow whatever swill their favorite member of the "big four" are dishing out today are so far behind the curve that they are of no consequence.
Engineers absolving themselves of commercial responsibility is just the sort of thing that has got us into this position. Engineers should deliver what works and that has to include the commercial considerations rather than architectural purity. Otherwise IMO its not engineering its just amateur dramatics.
On the "What about CORBA" line, well I remember trying to use non-CORBA approaches in the early 90s and while CORBA didn't survive that long it was a damned sight better using CORBA than rolling your own (which was pretty much the choice). So actually CORBA delivered some big benefits to distributed projects.
What is the big fear about engineers not just being drones who make non-business decisions? Does everyone want to be outsourced?
"...who do you think created all those Web standards?"
- well HTTP 1.1 lists Roy Fielding as an author, who's also known as the guy who first wrote down REST... I wouldn't be so quick to ridicule LAMP either, given that the 'A' has considerably more market share for web servers than your Big Four combined.
But ok, if you're so sure these specs will conquer all, why not demonstrate your conviction by simply serving this blog using the WS-* stack? Just mail us the WSDL ;-)
Oh boy, now I've heard it all, the MySQL and PHP/Perl guys are claiming Apache as their own...
Apache Contributors Ummm appears to be quite a few IBMers on there, and quite a few other big companies. I'm not saying that other people haven't helped with various standards, but its very wrong to claim that large companies haven't driven this.
WS-* is aimed at computer to computer, HTML is aimed at computer to person (via a browser). Different tools for a different purpose.
Now, nobody said anything about engineers absolving themselves of commercial responsibility. Good engineers realise that commercial considerations are one of many important factors which need to be taken into account when making a decision. But they're not the only factor. I've seen so many bad decisions arising from that kind of "let's do it way 'x', because everyone else is doing it that way" (or my personal favourite "it's a de-facto standard, don't you know") thinking, which doesn't take into account whether the technology in question is a good fit for what you're trying to achieve.
I can't think of any better way to get yourself outsourced than turning your back on the engineering expertise you've spent your career trying to develop and trying to turn yourself into an overnight mini-CIO, basing every decision on the whims of the marketplace and competing with the people who've spent their careers doing that. And I'd be more than a little worried for the future of a company which had so many back-seat drivers second-guessing the decisions of senior management.
Anto,
I'm not saying be a sheep (and the REST crowd can equally be accused of grass grazing in a similar way to the XP crowd), I'm saying that "good fit" is what matters and that almost all the time WS-* will be a "good fit", not the technically purest or the "best" fit from an engineering perspective but a "good fit".
So the default should be "will WS-* work here" and if it does... then just use it, because commercially that also makes the most sense. Having a REST v WS-* pissing contest makes no sense as its not about what is "best" but about whether the commercial/business standard choice is a "good fit". This is all old Mythical Man Month stuff about architectural consistency.
So WS-* becomes just another Frozen Accident in the evolution of software which we continue to cling onto long after we've forgottent what it's for?
Long live the pissing contest!
So the best path would be to:
1. Use WS in day job for a living.
2. Come up with some world-changing service in spare time.
3. Build that in REST(-style) for discoverability and scalablity.
4. Go IPO.
5. GET MONEY FAST!
Honestly, SOA vs REST (or WS vs REST) discussion is moot if what you want is non-open (= not open as the Internet/Web) software interconnection. This comparison only matters when you're aiming for internet-scale service, with extreme serendipity between disconnected nodes (which SOA people would never understand the concept).
>> Engineers absolving themselves of commercial responsibility is just the sort of thing that has got us into this position.
- What position and how did engineers absolving commercial responsibility have anything to do with it?
>> Engineers should deliver what works and that has to include the commercial considerations rather than architectural purity.
- Isn't this exactly the case for REST?
>> What is the big fear about engineers not just being drones who make non-business decisions? Does everyone want to be outsourced?
- Ugh. This law should be applied everywhere: http://discuss.fogcreek.com/joelonsoftware4/default.asp?cmd=show&ixPost=124505&ixReplies=33
tai - extreme seredipity between disconnected nodes? And a .com business plan. Please tell me you wouldn't use that approach in a job interview or why trying to get VC funding.
Bean - The position we are in is where 80% of IT spend is on Business as Usual, where the majority of projects fail to deliver against the original expectations, and where a series of silver bullets have been proposed (ERP, EAI, BPM, XP, REST, SOA etc etc) that are really just another set of technology doing the same thing in a slightly different way. Did all those EAI projects deliver the value? Did all those ERP solutions deliver the value? Nope. And a major reason is that IT becomes obsessed with technology and what can be done rather than what should be done.
If you can create a commercial case for using REST over WS-* that includes TCO and ensures that it works consistently with the other parts of the enterprise then great. The problem is that WS-* will exist in the rest of the enterprise and externally, so REST is optional while WS-* is mandatory.
Everything should have a commercial case.
That post is pure drivel.
Talk to the folks at Amazon about REST vs. WS.
Or consider some basic economic principals.
The amount of overhead associated with WS is simply absurd and unjustifiable in the majority of cases.
WS is effectively dead outside of the Ent. Middleware sector, and has been for quite some time.
Enjoy your stale kool-aid.
Steve, Amazon and Google already have had more impact than IBM in the last several years.
WS-* is a pile of over-engineered, tedious, boring, inefficient CRAP designed by and for people who appreciate complexity for its own sake and pawn this nonsense off as having an exclusive lock on consistent design.
There are a few places where you can make a strong case for SOA and WS-like approaches.
Internet-scale services is not one of them.
Rapid prototyping and innovation aren't, either.
Middleware -- oh boy! What fun.
Zzzz....
"The point I'm making isn't that no-one knows LAMP or REST or whatever..."
Me and my one-man six-figure+ per year LAMP consulting practice are laughing all the way to the bank at this.
You must have been living under a rock for the last 5 years.
"If you can create a commercial case for using REST over WS-* that includes TCO and ensures that it works consistently with the other parts of the enterprise then great. The problem is that WS-* will exist in the rest of the enterprise and externally, so REST is optional while WS-* is mandatory."
1. Amazon
2. It is pretty clear that you do not know what REST is.
Your book sales must really be tanking, if you are resorting to nonsensical fear-mongering aimed at the uninformed by attacking something else instead of simply articulating the benefits (and there are some) of WS-* and SOA.
Sad...
>> where a series of silver bullets have been proposed (ERP, EAI, BPM, XP, REST, SOA etc etc) that are really just another set of technology doing the same thing in a slightly different way
>> a major reason is that IT becomes obsessed with technology and what can be done rather than what should be done.
Great! You just mentioned all the reasons to NOT use WS-* and use REST instead.
>> If you can create a commercial case for using REST over WS-* that includes TCO and ensures that it works consistently with the other parts of the enterprise then great. The problem is that WS-* will exist in the rest of the enterprise and externally, so REST is optional while WS-* is mandatory.
Agree with the other commenter above. It seems you are not aware of what REST is. While you say WS-* WILL exist in the enterprise, REST is already there!
Loving the vitriol... from those that wish to remain anonymous...
Anyway lets address a few points
1) As I said in my post, REST people talk about Google and Amazon and nothing else... err guys that is exactly what you've just done
2) I'm not arguing about technical perfection, I'm just pointing out that WS-* is, and will be, the commercial reality (beyond Google/Amazon the number of REST references is tiny in comparison with WS-*)
So guys, please try and talk about the _commercial_ advantages of REST, and don't try and use lines like "bloated" which refer to technology opinions.
If I'm wrong then great, but so far all of the comments have done exactly as expected, chanted the mantra of "cool" from Google/Amazon, and added no actual data.
And g, I really hope you are boasting about a six figure salary in sterling not dollars.
Wow, you did get some vitriol!
There are quite a few IBMers amongst Apache Contributors...and Apache is primarily straight (RESTful) HTTP. So it doesn't seem like they have immediate plans to turn everything into WS-*.
"WS-* is aimed at computer to computer, HTML is aimed at computer to person (via a browser). Different tools for a different purpose." - sure. But who was talking about HTML? That's just the payload, surely?
The payload delivered from the server computer to the user's computer. HTML may be a format inclined towards immediate rendering on the client computer (via a browser), but that's orthogonal to the transport. You also have an Atom feed, which needs at least one more level of processing before rendering (and is eminently suited for further processing, like server-side aggregation/filtering/republication).
But either way, the point remains. This blog is currently delivered RESTfully, if you're so convinced of WS-*, why not offer a service endpoint to the data in SOAP or whatever? Surely there couldn't be commercial disadvantages..?
I've had that RESTful blog thing again, but RSS isn't really computer to computer, there is a fixed format and its designed to send information to people, not computer to computer. I like RSS as a presentation aggregator its a good lightweight solution, but I don't see RSS as computer to computer because its intent is to get information to people.
BEA are fans of both, I guess they don't count though, being a relative pipsqueak at only $1.2b...
This is just a stupid posting. "Want a career? Learn WS". Just because the big 4 say so.
I remember when the big vendors said EJB is for everything java server side! Enough said.
"I don't see RSS as computer to computer because its intent is to get information to people"
Ultimately, yes, just like WS-* and computing in general.
But RSS is in essence a wrapper around (usually) a HTML content payload, with a bunch of metadata. Not unlike doc/literal SOAP. It *is* designed for computer-computer communication. The metadata in particular makes it amenable to subsequent processing - either for sortable presentation or for aggregation/republication. I read your feed not directly, but via Bloglines, another remote host.
...and how about the Blogger API (and Metaweblog API) used for blog authoring? They follow the same RPC paradigm as most WS-*. If client to server content delivery can be done using RPC, then why not server to client?
[Although it demonstrates publishing can be done this way, XML-RPC is a lousy approach, fortunately there's the (RESTful) Atom Publishing Protocol]
People. You use the right tool for the job.
REST - you have to code XML parsers for the response data every time.
WS-* - sure, it's overkill if you use the whole stack, but it's designed for heavy lifting. Either way, being able to generate stubs and value objects from the WSDL in your language of choice is worth every cent.
Both are valid. If you want to spend hours navel gazing and debating the merits, be my guest. I've got some work to do.
Steve, you use IBM as one of your justifications, yet IBM employs a vocal REST advocate in Joe Gregorio (http://bitworking.org/) and they just hired Damien Katz (http://ajaxian.com/archives/apache-couchdb-congrats-to-ibm-and-damian-katz) so he could work full time on CouchDB, a fully RESTful system.
I think what you have in IBM is a company milking what they have in WS-* because that what smart companies do, but also investing in REST because they know that REST is the future REST has only just reached its tipping point and is definitely the future from a commercial perspective if for no other reason than people are much more apt to write RESTful clients than SOAPy clients when given the option: http://www.oreillynet.com/pub/wlg/3005
Make no mistake, I believe in REST because of its commercial benefits and not just because of it's technical merits.
Basically, WS-* is like a supernova that burns brightest just before its light is fully extinguished shortly thereafter, and it is like companies that are most profitable just before they milk dry their last remaining bits of market value after which its successors quickly take the market lead, as REST is currently doing now.
Oops, forgot to check the "email me follow up comments" box, so I'm doing that now.
Its a very nice blog for...
architects in bangalore , architects in bangalore , interior designers in Bangalore , interior designers in Bangalore , architects in bangalore , architects in bangalore , interior designers in bangalore
Post a Comment