WS-Nothing

A couple of weeks ago I participated on an application server panel at Web Services Edge hosted by Anne Thomas Manes. There was quite a bit of discussion about WS-This and WS-That and WS-Foo and WS-Bar. Essentially, this Web Services thing has devolved into a huge unintelligible morass. The panel was covered today in LinuxWorld, which liked an ad-hoc term I used: WS-Nothing.

Vendors Have Been Arguing for So Long That You Have to Send Text Files Around

On the panel, I said that we vendors have lost sight of the fact that we have been bickering so long that the only way our products can talk to each other is to send text files around. We are now in the process of screwing even that up with all of these competing specifications about how to mark up self-describing text files.

It is of no supprise that Web Services have not had a big uptake with customers; they don't even know where to start. The point of web services is interoperability, and if the Web Service produced by a particular application server only works with that application server, you might as well use a binary protocol.

WS-Nothing

If you ignore the vendors and get back to the core theme of a Web Service and what it is meant for, it is actually pretty easy to get started. Developers should use the WS-Nothing methodology: Concentrate on the definition of the data coming and the data going out of the service. Everything else, such as security, routing, transaction context, etc. should be defined by policy and layered in later.

Even if someone does manage to figure out which ones to use and hardcoded them in (say SAML Artifact and WS-Routing), they will probably end up having to change it around for future consituents. Partner A uses SAML Artifact but then Partner B is signed up, which mandates a certificate check, and you end up having to do a big if/then/else at a minimum or probably two hard coded services.

So use WS-Nothing and simply implement what your service needs to do from a data in and out perspective. Layer in the WS-Gunk later as a wrapper. Or even better, at runtime based on policies.

PS: Calling this "aspect oriented" is already making it too complicated. Data in, data out, WS-Gunk added later. No big words. No complexity. Remember, it's just text files! :)