Description is more important that transport

Harold Carr came and spoke to my graduate class on Middleware at BYU. Harold works for Sun and is the chief designer behind the PEPt architecture. PEPt separates presentation, encoding, protocol, and transport conceptually and architecturally to provide a framework for unifying various remoting strategies like RPC, CORBA, RMI, and, yes, Web services. I enjoyed the presentation very much, but it was one thought at the very beginning the resonated with me most of all: description is more important than transport.

This idea struck me because I've been thinking about description with respect to intermediation lately. Harold's statement is especially meaningful if you've ever used WSDL2Java or some other program that converts an interface description into the stubs that the client calls to actually use it. When I use WSDL2Java, I really don't care if the message is going by SOAP, IIOP, or carrier pigeon, at least from a functional perspective. I can teach people to use WSDL2Java and never teach them a thing about SOAP and their programs will work just fine.

The real power in this idea is that with a sufficiently flexible description language, we could write programs that are completely independent of the transport. That's really backwards from how most people think about Web services. In Web services, you tend to think about SOAP first and WSDL second, if you think about it at all. But the only reason we think that way is because that's how the designers put it together. With the right architecture, I ought to be able to describe my API in WSDL (or something like it) and bind it to any transport I want, including REST.