Are WS-splat specs like SUVs?
Loek Bakker always comes up with some very catchy metaphors for SOA technologies (remember the ESB as a "one-day fly"?), and has come up with another good one for the WS-* (or WS-splat) set of specs: they are the sport utility vehicles (SUVs) of the information superhighway.
Mike Champion went a step further and christened a new spec: WS-SUV.
This is bound to create as many and as passionate rifts as the current WS-*/SOAP vs. REST debate. There are plenty of folks who love their SUVs, no matter how much gas they need. Likewise, WS-* has a pretty impressive base of support.
Loek says, however, that:
"...not only is the popularity of both SUVs and SOAP services fading: the power promised by the marketing behind both is impressive as well.... SUVs are not very practical in every day life: it is hard to find a large enough parking spot, the automobile needs a lot of gas and it is not the most comfortable car in the world... SOAP services on the other hand very often have a payload with a lot of redundancy due to the WSDL spec, they require quite some bandwidth (as a result), and especially with the full WS-* stack they are not comfortable for developers. ...there is a huge gap between expectations/image and reality."
Loek seems to be saying that SOAP and WS-* are the gas (resource)-guzzlers of the SOA space. But remember, we're trying to replace or streamline the 18-wheeler tractor trailers (legacy systems) that have been lumbering on the road for years. SOAP and WS-* provide the most effective means yet to surface such back-end applications as componentized services. Besides, what's the alternative?
And, car purchases are made mainly from the heart. Technology decisions come mainly from the brain. If most enterprise decision-makers agreed that the SOAP/WS-* specs were overburdensome, there's no reason why they wouldn't have tossed them out the door a long time ago, with no remorse.
That being said, I've discussed both XML and SOAP performance issues in this blogsite, and, indeed, they can be complex, and there may be a certain amount of overhead that will tax our systems. Some experts I've spoken with say it's important to just concentrate on the specs you need, and not worry about all 60, because you will only need a few. Others warn, however, that XML and SOAP is the kind of stuff that will eventually bring networks down. A couple of months back, blogging colleague Phil Wainewright provided a very good summary of the challenges around SOA performance, and the plusses and minuses of various strategies to compensate, including appliances, binary XML, and caching.
Loek concludes: "If you do not need the off-road capabilities or if you never flick the 4WD switch, probably you do not need an SUV. If you do not need the SOAP extension/WS-* possibilities or if you never make clever use of the SOAP header, probably you do not need SOAP services." The key is always to accomplish the same with "far less complexity, cost and more comfort."