Sure, and that's why the REST advocates don't like Web services. I am only pointing out that the right comparison for a Web services implementation is an HTTP implementation, not Roy's thesis, and that such an implementation may or may not be RESTful, just like a Web services implementation may not be.
Of course one can point to designs, architectures, constraints, and intentions and point out differences but in the reality of what people implement the distinctions are typically not as clear. I just don't think comparing a Web service implementation to Roy's thesis is a good way to debate the pros and cons. Eric ----- Original Message ---- From: Anne Thomas Manes <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, June 8, 2007 12:30:11 PM Subject: Re: [service-orientated-architecture] Benefits of WS-* over REST Eric said: And finally I do not think HTTP implements REST, if I understand it correctly, one can do REST over HTTP pretty easily but one can also do plenty of non REST stuff (for example WS-*, on which I think you'd agree). If you strictly follow the method semantics defined in the HTTP 1.1 protocol, then it is RESTful. But HTTP 1.1 doesn't enforce those method semantics. That would be considered "abuse", though. Anne On 6/8/07, Eric Newcomer <[EMAIL PROTECTED] com> wrote: Hi Stefan, A couple of quick points - I find it not a very good practice to argue with customers who say they are getting value out of something... Also I cannot accept your analogy about Artix being leaky, we are running it very successfully in dozens of production applications that use it for protocol abstraction. In fact protocol abstraction was part of CORBA as well via GIOP, which may not be as well known but nonetheless this is a proven area of technology - the same interface can definitely support different data serialization formats and communication protocols. And finally I do not think HTTP implements REST, if I understand it correctly, one can do REST over HTTP pretty easily but one can also do plenty of non REST stuff (for example WS-*, on which I think you'd agree). I liked Anne's summary that REST may well be architecturally superior, but the major issues here are not really about technology but rather its application. We all know the "Betamax didn't win" and similar stories. Digital was full of the best technology around but it's gone. Etc. And in this case we are always reminding ourselves that SOA is not about technology, rather it's about an approach to IT design, but we get into these "which technology do I like better" arguments. As technologists we feel we must have an opinion about this, and somehow it matters to us which technology seems better, like whether a Porsche is better than a VW if we like cars, but to some people a car is just transportation. What matters is the value for the customer, and if the customer gets better results with Web services than REST this is not something for us to debate. Of course that doesn't stop us ;-) Eric ps apologies for leaving out the smiley face on yesterday's email about responding to posts on this list - here it is ;-) ----- Original Message ---- From: Stefan Tilkov <stefan.tilkov@ innoq.com> To: service-orientated- architecture@ yahoogroups. com Sent: Friday, June 8, 2007 9:05:41 AM Subject: Re: [service-orientated -architecture] Benefits of WS-* over REST 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://wanderingbar que.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 Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search. ____________________________________________________________________________________ Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/
