I look at the confusing landscape where the “Web Services” flags fly, and I see some things that are proven good practice, and some other things that are mostly theory. I think we could all be saner about all this if were careful to distinguish between theory and practice.
WS-Good Practices ·
Pass Messages · The idea here is that you integrate applications over the net by explicitly sending messages back and forth, not using an API like RMI or DCOM that tries to sweep all that stuff under the rug. The key insight (which the global telephone system among others learned years ago) is that network integration takes place at the level of bits-on-the-wire, not of object brokers or any other abstraction.
Use XML · If you’re going to package up data in messages to ship it around, XML is usually a good way to package it up. There are exceptions, of course: large binary objects like video streams are an obvious one. But across the universe of business data, XML hits a sweet spot for packaging up a high percentage of it.
There are a few nice things about XML (in particular the internationalization) but the key advantage is that it’s a thick enough buffer that when you get an XML message from me, you typically can’t peek through it to see whether I’m running Windows and SQL server or Solaris and MySQL. This is a Good Thing.
Asynchrony Beats RPC · For big systems with open-ended scaling requirements, architectures that are asynchronous and queued rather than call and response generally seem to win, big time. It’s not an accident that IBM and Tibco were making millions selling big robust asynchronous queuing infrastructure long before anyone started talking about “Web Services.”
Programmer Hand-Holding · The reaction in the Windows community to the Visual Studio support of WSDL has been overwhelmingly positive. That’s not the way I write software; since I’m usually working on low-level infrastructure, I need to know all about the bits on the wire and the network traffic flows. But for someone working on a mainstream business app, the ability to point your developer-tool at a WSDL file and get an application stubbed out for you is very attractive. Here we have all the lessons of Visual Basic being taught once again.
This one’s a little on the risky side, because it probably doesn’t scale to really big, really distributed, really scalable systems (at least in some cases). But it’s not going away.
WS-Theory ·
Composable Message Architectures · One of the base principles of the “WS-* Stack” is that when you’re building a message-based interchange, you can compose your payload into a message with info about addressing (WS-Addressing), security (WS-Security), policy (WS-Policy), choreography, and all sorts of other stuff. This had all better be rigidly orthogonal, or we’re looking at a combinatoric explosion in complexity. And it’s going to be hard to make them orthogonal, because Abstractions Leak.
I’m not saying it can’t be done, I’m just saying it’s going to be hard to get it right, that this is the realm of wouldn’t-it-be-nice theory, and you shouldn’t be betting your business on it in the short term.
Automated Service Discovery and Negotiation · This is the notion, first floated in UDDI, that you could have a directory of services accompanied with rich metadata about service interfaces and metadata, and that seekers of services would auto-discover them, negotiate details of service, and proceed to get the job done.
And if you believe that, you might want to invest in this Personal Atomic Car that I’ve been building. Once again this is an area with (I believe) all sorts of promise, and a fertile territory for research. But it’s nothing like a proven engineering approach. The benefits you get from the Web Services strategy are big enough that you don’t have to bet on automated discovery/negotiation for it to be worthwhile. Which is a good thing, because that would be a risky bet indeed.
Declarative Application Building · This is the idea, most publicly on display in the various flavors of BPEL and WS-Choreography, that you don’t need to write a bunch of icky procedural code to deploy your sophisticated Web-Services application. You write a bunch of declarative statements, which is good, only they’re in XML, which is better. Once you’ve written them, your application builds itself!
Sounds great, right? Except for I’ve seen this movie before; twice, in fact. The first time was during the Eighties with the advent of the 4GL’s (“Fourth-Generation Languages”), whose value proposition read more or less exactly the same: build your application declaratively and let us take care of the details. Then again in the Nineties, there was a (now mostly forgotten) class of application called “Workflow”; the idea was you diagrammed out your business processes as a sequence of events. You could put in conditional branches and loopback conditions, and there were these way-cool graphic front-ends so you could actually see the processes right there on the screen. Then the workflow applications would route your work among the fallible human cogs who actually did it, only there wouldn’t be expensive mistakes any more.
There were some problems, though. It turned out with 4GL’s, you could build 90% of your application in no time at all, but there always seemed to be one or two little pieces that were necessary but required some tricky procedural code and took endless effort to get done, and sometimes you couldn’t.
And as regards the workflow products, I never once heard of a single successful deployment of a complex automated-workflow scenario on any scale. It works OK for simple workflows, like at an HMO: so many thousand transactions come in the door every day, most get approved and paid, a smaller proportion get kicked up to second level, then human judgment takes over. But complex workflows resist automation, mightily.
Once again, I’m not saying it can’t be done, or that it’s not a good idea. I’m just saying that it’s not a safe bet today for the prudent businessperson.
Leaky Abstractions · As I noted above, and as most famously described by Joel Spolsky, our profession has a problem in that our abstractions are leaky. Consider the example of relational database access. When good object-oriented languages like Java became ubiquitous, a lot of people thought it would be a good idea to abstract all that SQL syntax, and those rows and columns, away behind classes and objects. With a few exceptions, it generally doesn’t work. An application that tries to the ignore the fact that it’s talking to a repository with SQL semantics is apt to end up being fragile and slow.
I suspect the same will be true in the domain of Web Services; applications that try to abstract away the fact that they’re exchanging XML messages will suffer for it. Thus, I tend to consider any “Web Services” specification that’s more than two steps away from XML for content and URIs for addressing to be somewhat suspect.
The Standards Process · This essay is about theory and practice, and we ought to have learned by now that standards are terrific when applied to proven industry practice but high-risk in the domain of theory and science. SQL and XML were both exercises in writing down something that had already been proven to work.
When committees get together either in an informal cabal or an official standards process, and go about inventing new technologies, the results are usually pretty bad. ODA (Never heard of it? Exactly); OSI Networking; W3C XML Schemas. The list goes on and on.
Here at Sun · I’ve talked to a lot of people internally and worried out loud about the WS-* stack: whether it will actually work, whether it will interoperate, whether the complexity will be tractable, whether it will be secure, whether it’s going to have patent lock-ins. Mostly, they say “yep, yep, yep, we worry about those too.”
I think somebody needs to stand up and start waving a flag that’s labeled “WS-Simplification” or “Real Web Services” or something, that’s all about building applications with what’s here today and what works today: XML, HTTP, URIs, SOAP, WSDL, and that’s about it.
People who need solutions today are building successfully today with that toolkit and I know because I’ve seen them. Save the future for the future and don’t bet on research projects, leaky abstractions, or the inventiveness of committees.
I haven’t figured out yet how to organize making that happen.
