Hi Eric, On 2/25/07, Eric Newcomer <[EMAIL PROTECTED]> wrote: > > > > Hi Mark, > > Yes, actually that was one reason I decided to post a reply. I had been > holding back because it seemed useless. But the argument was starting to > mixup uniform interfaces and self describing messages, which as you point out > is incorrect. > > It's another quibble, but I would not say that uniform interfaces are new. > You are right that their application in large scale distributed systems is, > and I agree with you that the benefit is often misunderstood. But > exaggerating the benefit also doesn't help.
Uniform *operations* aren't new, I agree. Most messaging systems use them, in particular an operation, normally implicit (i.e. not on the wire), that means much the same as HTTP POST. But I think the uniform *interface* as a single constraint is new, in that it unifies what were previously disparate operations from different protocols. It also paints an extensible path forward towards as-yet-undefined operations which is also quite valuable and, AFAIK, novel. I do think the benefit is huge though. Perhaps not on the order of world peace or a cure for cancer, but not too far from them 8-) > As I think you know that I personally hope we can get past this "vs" stuff > and start discussing which technologies are good for what etc. I do too, but unfortunately I think that in order to move forward fruitfully we need to understand the mistakes we've made in the past. Said another way, I think Web services proponents need to understand that the Web offers, in general, an *improvement upon the services model of Web services. Of course, we need to be able to do this in the most constructive, forward-looking way possible. > It may well be that to restore some kind of "balance" in the discussion it > was necessary to exaggerate the benefits of the REST approach but hopefully > that's not the case any more. > > I was looking back at my 2002 Web services book the other day (which was > written mostly in 2001), and although I think I got a lot of it right, we > were certainly thinking in those early days about Web services as an > extention to the Web (well at least I was, and I don't think I was alone). > > From page 20, one of the commentary sidebars: > > "Reinventing the Wheel > > "Some people say that Web services are reinventing the wheel because they > share many characteristics with other distributed computing architectures, > such as CORBA and DCOM. Web services do share considerable common ground with > these and other distributed computing architectures and implementations, but > there's also a good reason for inventing a new architecture. The Web is > established, and to take advantage of this tremendous global network, the > concepts of distributed computing need to be adapted. First, the Web is > basically disconnected; that is, connections are transient and temporary. > Distributed computing services, such as security and transactions, > traditionally depend on a transport level connection and have to be > redesigned to provide equivalent functionality for the disconnected Web. > Second, the Web assumes that parties can connect without prior knowledge of > one another, but following URL links and observing a few basic rules. For > Web services, this means that any client can access Web services published by > anyone else, as long as the information about the service -- the schema -- is > available and understandable and XML processors are capable of generating > messages conforming to the schema. > > "Traditional distributed computing technologies assume a much more tightly > coupled relationship between client and server and therefore cannot > inherently take advantage of the existing World Wide Web. Because Web > services adopt the publishing model of the Web, it's posisble to wrap and to > publish a specific end point, or business operation, using a Web services > interface definition, without requiring a specific type of client for that > end point. The paradigm shift that clients can develop and integrate later > has many advantages in solving the problem of enterprise integration." > > So this was in the early days, and the book is primarily about the > specifications, not the implementations (although there's some early product > stuff in one of the chapters). Those are good words which make for an excellent goal, but I don't think that even the specifications did things like "adopt the publishing model of the Web". > But I believe your argument is that the industry went the wrong way from > those early days by not recognizing that the uniform interface was part of > the required adaptation of traditional middleware concepts to the Web, is > that right? Yes. Very well said. > It is just hard to believe that the lack of uniform interfaces in SOAP and > WSDL is the cause of all the disconnect with the Web. I really think it's 99% of the problem, because it provides - as documented in Roy's dissertation - *so* much simplicity (amoungst other benefits). The cost is also very low in general, at least for data oriented systems. > On the other hand, recent studies show Web services are gaining ground with > enterprise developers. So is it just the impedence mismatch with the Web > that we need to solve? I'm not saying it's the only problem 8-) But it's a big one. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
