Hi Stefan, Yes, I think your list is a pretty good summary. By the way the reason I'm saying there's value in Web services is that users of them say that they are getting real benefits, and this was said publicly at the recent W3C Workshop (the report should be out today in fact and I will post the link as soon as I can), and privately many times.
The problem is *as always* that comparing technologies to each other doesn't matter. What matters is comparing technologies to the user requirements, since technology is only valuable in its application (i.e. not in the abstract). Many of the debates we have on this list are abstract. During this latest round I also realized something else that is bugging me about it. A lot of people end up comparing the implementations of Web services specifications to what's in Roy's thesis about REST. If you also look at how people use HTTP you will see that in many cases it is not very RESTful. The concepts and ideas behind Web services are just as important to consider. Ok, so maybe the industry hasn't gotten the implementations right, but this could change. I have worked both on the vendor side and the user side. My first few jobs out of college were in IT. Then I joined Digital and have been on the vendor side the past 20+ years. So maybe I am forgetting what it was like on the user side by now, but I try hard not to. I think the influence of vendors over users is also overstated. I believe most users recognize the difference between marketing hype and reality - although of course there are always exceptions. However the industry definitely suffers from the "innovators' dilemma" or however you want to put it because the vendors pay more attention to the requirements of their big customers than they do to emerging technology trends. And as we all know, large corporations tend to be somewhat conservative in the adoption of technology, since for understandable reasons most of them like to avoid risky new stuff. You also get the phenomenon of customers asking for equivalent features and functionality in Web services that exist in the current middleware solutions they already use. Sometimes you hear them say things like "we will only adopt Web services when they are as reliable etc. as MQ Series." This is also a kind of false statement of requirements, since the users' requirements are typically not the same as the feature list of something like MQ, but because they use it successfully it's easier to just point to it and say they need the equivalent. I am sure that if many companies were to start from first principles they would discover that HTTP can be used for much more than they would think if they are just comparing it to MQ or CORBA or something. I think a lot of people also try to find out who to blame for the strange situation of the world, or find some reason why things don't make as much sense as they should if one person was in charge or had his or her way. The world is not under anyone's control, of course, and neither is the adoption of technology. The basic problem is the impedence mismatch between HTTP, which was designed for WAN use, and existing enterprise middleware, which was designed for LAN use. Another related issue is the different between uncontrolled communities of peers and how they work on the Web and how more strictly hierarchical organizations such as large corporations and governments view their employees and IT systems. Maybe this will change someday but right now these tend to be very different worlds, and this difference extends to the technology that gets adopted and used. The major benefit of Web services is abstraction - they have the capability to standardize existing IT systems so that it doesn't matter what you are using underneath them. People posting to this list correctly point out that many implementations of Web services tend to tie themselves to a particular product, language, or middleware technology. And the failure of Web services to achieve the promised levels of interoperability was also noted at the Workshop. However this doesn't mean Web services are incapable of this, only that it hasn't yet been accomplished. You are right to say that the multi-protocol issue is a difficult one to address, however if you look at what IONA has done we have solved this to a significant extent. In fact we allow you to switch data formats and protocols via configuration change. And we can support multiple protocols for the same services. Are there some constraints that allow you to do this? Sure, of course there are. But it can be done. The problem with HTTP is that it takes a lot of custom code to achieve the same capabilities as Web services based products provide. Again citing the Workshop guys from Yahoo explained that they are using both SOAP and REST based technologies successfully in different parts of the business. I actually had the chance to meet directly with some of their folks using Web services and there's no doubt they feel that the technology they're using meets their major requirements. The Yahoo guys made the comment that architecturally they tend to prefer REST or POX over HTTP but the developers complain about the amount of work it takes to parse the XML by hand, and would like to have some code generation tools like the Web services guys. I know that you don't like the code generation approach, and I appreciate the problems it can cause. However this is once again a situation in which there are no absolutes. Overall I would say the biggest lack in HTTP in comparison to Web services is security. And this is a big issue, especially for large financial institutions worried about identity theft etc. Hope this helps - more in the Workshop report coming soon. Eric ----- Original Message ---- From: Stefan Tilkov <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, June 7, 2007 2:02:39 PM Subject: [service-orientated-architecture] Benefits of WS-* over REST Hi Eric, On Jun 7, 2007, at 7:17 PM, Eric Newcomer wrote: > What's frustrating are statements like "Web services have no value" > or "Web services are just RPCs with angle brackets" that are not > fair descriptions, especially from folks who participated in the > Workshop in which every effort was made to accomodate the various > viewpoints and have a balanced discussion. I thought we had > achieved something there - acknowledging the pros and cons of both > approaches and getting past the oversimplifications and > overstatements - so it is discouraging to see it continue. That's > all. I honestly would like to see the pros and cons of WS-* and REST discussed. I don't believe we have, so far - on this list, the recurring theme is that somebody either (a) points out that REST is better or (b) REST is not suitable for machine-to-machine communication. [I'm guilty of (a), although I have a clear conscience about it :-) ] But I can't recall much serious discussion about the benefits WS-* has over REST. So, considering the benefits of SOAP/WSDL/WS- *, I can see them fall into two categories: Political (or "soft") factors: Reasons in this category are based on the acceptance of WS-* among vendors, analysts, and because of this, among end-users. I know from personal experience that (at least currently) it's much harder for a consultant to convince a client to use HTTP in a RESTful way instead of Web services, since Web services is all they ever hear about. This might mean that it's easier to get them to adopt the WS-* architecture, which may be a significant step forward for them. Let's just assume that in many cases, the "you will not be fired for choosing WS-*" attitude is a good enough reason. Technical (or architectural) factors: Politics aside, you seem to believe, no: you consider it _obvious_ that there are situations where WS-* is superior to REST from an architectural or technical point of view. What are those? I'll make some guesses (note that these don't reflect my opinions) (1) WS-* is "protocol independent" , while REST (in all practical relevance) is tied to HTTP. (2) The WS-* specs address "enterprise" concerns that REST/HTTP can't handle (3) It's much easier to expose an existing system that has a "transactional" interface (in the TP monitor sense) via WS-* than via REST, since the latter requires a real architectural change and the former doesn't Are there any other benefits that WSDL/SOAP/WS- * is claimed to have over REST/HTTP? For the record, I believe that (1) is an illusion since the HTTP protocol is just replaced with a different protocol, one that has no or at least a much worse design, and the protocol independence is an extremely leaky abstraction in real applications anyway; regarding (2), the specs that do address enterprise concerns are not yet widely adopted anyway and in many cases address something that doesn't belong in the infrastructure layer anyway. I do believe that (3) is a valid point. Best regards, Stefan -- Stefan Tilkov, http://www.innoq. com/blog/ st/ ____________________________________________________________________________________ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
