Eliotte nails WS-* web services. There has been constant attempts from WS-* web service proponents to claim that there was one big tool shed and that people could pick their favorite type of web services. The hidden message is that there are various options, that WS-* might be best for serious work whereas REST web services are better for the little guy. In other words, WS-* didn’t fail, we just have different solutions to different problems. It is not so.
WS-* is North Korea and REST is South Korea. While REST will go on to become an economic powerhouse with steadily increasing standards of living for all its citizens, WS-* is doomed to sixty years of starvation, poverty, tyranny, and defections until it eventually collapses from its own fundamental inadequacies and is absorbed into the more sensible policies of its neighbor to the South.
The analogy isn’t as silly as it sounds either. North Korean/Soviet style “communism†fails because it believes massive central planning works better than the individual decisions of millions of economic actors. WS-* fails because it believes massive central planning works better than the individual decisions of millions of web sites.
So there you go. Please be a WS-* advocate if you want, but you are applying nice ideas that will never work no matter what. There is no truce, you are just lost souls.
REST works great for just about everything. WS-* can do certain jobs, especially where reliability or certain security needs exist, better than REST. You write “Please be a WS-* advocate if you want, but you are applying nice ideas that will never work no matter what.” I’ve seen WS-* solutions work, so your statement is not correct. Why not let the customer specify his or her needs and let the programmers implement the best solution using REST or WS-*?
We’ve all heard of people smoking and living to be a hundred. Should we conclude that smoking can sometimes work, and that we should let people decide?
No way. Smoking is bad for you, bad for the people around you, it is bad for your kids and so on.
Yes, you can make Web Services work, but this does not make it a viable solution. You know, people also design Web sites using C++. You have people who build GUI applications in Fortran. And so on.
Thanks James for the reference. SOA does not solve the data interoperability problem, quite the contrary. It adds layers of complexity on top of it.
Look at http://www.genome.jp/kegg/soap/
for a description of one very well functioning web service used in the area of biology. There are many schools and institutes working on projects involving genes. There are a great many data models and data formats in use to describe genes in the various IT systems used by the schools and institutes working of gene research. Slowly, but surely, XML and ASN.1 are becoming the standard formats. Because the data schemas at various institutes are different, the only good way to exchange data between data bases is using SOA. WSDL is used as the base of interface programming and data schema definition of SOAP clients. Other than using Corba, I don’t know how these gene researchers could efficiently exchange the huge amounts of information they exchange. How could you efficiently exchange these huge amounts of information between multiple schools and institutes with REST?
Daniel,
SOA does indeed add layers of complexity on top of data interoperability difficulties. On the other hand, being able to share data schema information in a standard format using WSDL can reduce the difficulties arising from data interoperability in some cases. Perhaps just because I have more experience with WS-* than with REST, I don’t see how multiple nonhuman consumers can easily be presented the data they require in the format they require without using WSDL. WSDL reduces the effort required to program the clients and also allows for quick updates when things change and can also be helpful troubleshooting.
(…) I don’t see how multiple nonhuman consumers can easily be presented the data they require in the format they require without using WSDL.
Well, let us see. Browsers are nonhuman consumers and they are presented the data they require in the format they require without using WSDL.
I wrote non-human Web Service clients for several Web Services (Google, Amazon, and so on) and the server presented them with the data in the format they required without WSDL.
Here is the process:
What if different services you access produce different formats? Well, this ought to be documented. Then your client ought to know how to read these different formats (otherwise, WSDL won’t help you) and to choose the right format based on the server specs (which are human readable, maybe posted on a web site?).
What if data formats change? Well, if they do, then you will know right away and can easily see what they problem is with a GET query. Then just update your client accordingly.
Oh, you want clients that will automatically reprogram themselves when remote APIs change, is that it? Well WSDL does not do this. Strong AI is needed if you want clients to reprogram themselves without help. And when this starts happening, we will have Battelstar Galactica all over again, and the Cylon will invade us and stuff. Bad, bad.