Hi Eric, On Jun 8, 2007, at 10:35 AM, Eric Newcomer wrote:
> 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. > > I have to admit that I don't find this particularly convincing, considering that it very much depends on what these people have been doing before. Logically, the fact that they have moved from some proprietary or EAI approach to WS and found it useful does not mean that WS has benefits over REST. Personally, I absolutely agree that WS may offer significant value - but I've not yet seen someone move from a REST approach to WS-*. Any pointers would be very welcome ... [...] > 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 think we're mixing two topics here -- one is how well the technology itself implements an architectural style, the other one how it is used. HTTP implements REST, and SOAP/WSDL/WS-* implement an abstract architecture/architectural style (which has no name AFAIK, so let's call it WS-Architecture). You seem to suggest that the industry hasn't done a good job of implementing WS-Architecture in the past, probably thinking about RPC- style static code generation, SOAP Encoding etc. This may be true. In contrast, HTTP seems to be a pretty good implementation of the REST style. But both - HTTP and SOAP/WSDL/WS-* - can be abused, and I don't see what this proves about one or the other. If anything, I believe it's a useful exercise to take any POX application, and convert it to the RESTful variant, and see the benefits. In my experience, they are very obvious. [...] > 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. A valid point. I would argue, though, that companies are more and more becoming like the Web (in terms of change dynamics, distributed ownership, ability to enforce consistency, the need to adapt to change) - in fact I believe it's inevitable that they (or their IT systems) are going to "merge" with the Web in the long run. If so, I find it much more likely that the architecture for this will resemble the Web's architecture instead of those of internal applications. > 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. True, although I don't see why this is relevant to our discussion - both RESTful HTTP applications and Web services have this capability. > 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. I agree. > 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. It's entirely possible that recent versions of IONA Artix have brought significant improvements, but the last time I worked with it these abstractions were as leaky as a metal bucket after a machine gun attack. > > 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. > > Actually the issue of XML databinding is orthogonal to the WS-vs.- REST discussion, since tools such as JAXB and its many competitors (both in the Java space and on other platforms) are not tied to WS anymore, but rather to XSD. > > 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. > > I agree. In fact my company makes and sells a code generation product - so I'm the first to agree that there are places where this has its value :-) I'll just argue that it's not a good match for loose coupling of systems. > > 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. > > Yes, I think I'll have to agree with this for now. Pete has pointed to Atom as a possible solution: http://wanderingbarque.com/ nonintersecting/2007/05/25/message-level-security-and-rest/ I don't think this is a convincing competitor, yet, but I very much believe that the Web folks, including Google, Amazon and Yahoo!, will come up with something that will work in conjunction with REST very soo. Best regards, Stefan
