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. 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. 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). In the beginning, SOAP was proposed as an extension to HTTP. Certainly Henrik Frystyk Nielsen felt that way (I still have his presentation from 2000 in which he states this explicitly) and as you also know SOAP was a kind of follow on to the W3C's failed HTTP-NG project (which was actually a lot more like CORBA than SOAP is). Personally I was coming at Web services in the context of XML. In those days people used to ask me about the most important thing about Web services. I always said "XML, XML, XML." So one of the things that's happened in the implementations is that customers started asking for language mappings, and tools vendors (and my employer included) went off and started trying to automatically convert XML data types to Java, VB, C#, C++, etc. (I have written previously about how this represents a basically impossible task and is somewhat counter intuitive in any case to think that a highly flexible and customizable text based interpretive language could be automatically and faultlessly converted to a compiled, static, and binary language.) 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? It's also important to remember that Roy's thesis wasn't published until 2000, which was after SOAP was started. And a lot of things were changing in those early days - including the fact that XML Schema wasn't done when the original SOAP RPC encoding was specified. I am not sure which is the bigger issue - the lack of what I'd call "real" XML processing or the introduction of custom interfaces into Web services. I don't really want to get into the whole WS-* thing - it's clear that if you look at every spec that claims to have some relationship to Web services it has the appearance of an out of control mess. But it is also clear that no one implements them all, and as you know many OMG specifications (or IETF for that matter) have never been implemented, either. 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. 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? Eric ----- Original Message ---- From: Mark Baker <[EMAIL PROTECTED]> To: [email protected] Sent: Saturday, February 24, 2007 10:53:52 PM Subject: Re: [service-orientated-architecture] SOA Pizza Order Surprises On 2/23/07, Eric Newcomer <[EMAIL PROTECTED] com> wrote: > > > > It seems like on this thread, whatever the question, the answer is "uniform > interface." > > Maybe it' just me. It's not just you. In my estimation, the uniform interface is the greatest advance in the history of large scale distributed computing ... well, in conjunction with standardized identifiers I suppose. So it's really no surprise that it's the answer to many questions. 8-) But FWIW, the uniform interface isn't the only way to get self-descriptive messages. If the interface is standardized then it is self-descriptive. That's why SOA/WS (and ONC, DCE, CORBA, DCOM, RMI et al) - which unapologetically do *not* constrain the interface - never had, and will never have, self-descriptive messages in the general case. It's the main reason we don't see those systems on the Internet. *ALL* Internet based systems have standardized operations. This is not a coincidence. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbake r.ca Coactus; Web-inspired integration strategies http://www.coactus. com ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited
