Sunday, March 06, 2005


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.


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! :)

1 comment:

Josh said...

I agree that the WS-* stuff is a mess. I used to support the idea of "web services" but have come to the same conclusion that text files back and forth is about the best we can get. Sure, you may get web services to work between two of your systems but good luck figuring out how all the pieces fit together. As usual the big software vendors are trying to support the "uber use case" while most of us customers need more straight forward solutions. We (the customers) suffer as the big vendors create more and more "standards" that no one can get a grip on let alone actually put to use.

The companies that seem to have the most success with web services are those offering software as a service: EBay, Amazon, Google, Yahoo!, and many other ASPs. They pretty much have to offer web services or their developer base is non-existant. The old, big software companies don't have that kind of pressure to make web services work. They have pressure to make sure web services are so complex that they require an army of consultants and very powerful (ie expensive) software.

It'll be interesting to see how customers handle web services moving forward. Will we actually make use of all the WS-* standards or settle on something else?