« Ouch | Main | QOTD »

Small Is The New Big. Or Something.

Mike Champion:

"I've yet to see compelling, detailed, practical examples where real business are solving the problems that WS-* addresses with only HTTP XML (unless one ignores the bazillion person-hours and immense amounts of code that industrial-strength web sites have so far had to deploy). And I'm still waiting for pragmatic guidance on exactly how to put these ideas in practice for an organization that needs something more complex than a stock quote service."

What are the complex problems that WS addresses? If WS-* is solving them why are people complaining about WS-* instead of exalting them? What is it about WS-* that would reduce code and bazillions of man-hours for industrial strength websites?

I have this sneaking suspicion that some complex problems are complex because there are intrinsically difficult issues, but that some complex problems are complex because of arbitrary and self-created matters, brought about by the technology, the process, bogus requirements. I'm not disputing at all there are classes of systems that are as Mike says they are, just wondering if perhaps they are edge cases, and how and why WS-* helps there, in a way where you could point to a solution and say WS-* was critical to success.

As for XSD it just does not seem to be helpful. I think that has to do with not only XSD being complicated (due to a requirements creep toward genericity that resulted in something of a monster spec). It's also quite low-level, and in practical terms tends to expose a platform's type system, which is invariably implementation specific. Which is to say there's an encapsulation problem when using XSD - too much how, not enough what. It would be cleaner to expose domain level structures like "Customer" that obey a RELAX or RDF schema, than an assemblage of somebody else's x86 CPU optimized primitives. The applications can map the domain object any way they see fit, rather than telling each other how to do it.

There is one nice feature about the REST or XML-over-HTTP approach - you can definitely scale down. Scaling down is important because if you can't scale down you presumably have to start big, which is risky for any project, unless you believe big working systems derive from big working systems.

Elsewhere I liked Steve Loughran's just use XMPP suggestion. XMPP rocks. Publicly the fuss around XMPP will be in the commercial sector - about Google Talk and Voice Over IM. I think it could quietly become the "other" protocol for the get-it-done school of systems integrations, mainly in situations where push or timeliness is a serious need, and people are talking crazy talk, like long haul JMS integrations. A while back Cote' and I had an email exchange about messaging and system monitoring. XMPP came up as something that has nice scale characteristics for recording events in a messaging system. This isn't just the usual scale handwaving - it's important because for every message that passes through a system or cluster of systems you'll have more than one interesting event to record. My experience seems to average out at 10 events per message. If so, the eventing/monitoring system has to scale at least order of magnitude greater than the messaging system. [Here's an example of a SOA that melted down for exactly that reason.] And if you have an event backchannel that scales at 10x the messaging system, at that point you may wonder whether you couldn't use the backchannel altogether.

February 23, 2006 09:26 PM


Mike Champion
(February 23, 2006 11:21 PM #)

I few years ago I was very sympathetic to the REST side in the permathread because it seemed at the time that Don Box and company were touting SOAP/WSDL Everywhere, and that is clearly a bad idea ... "Scaling down is important because if you can't scale down you presumably have to start big, which is risky for any project" is exactly what I mean.

Now Box is saying something very different -- sure WS-* doesn't scale down, so don't use it when you don't need it. What's left to disagree about is whether the compexity of WS-* is gratuitous and self inflicted or whether it addresses non-cornercase real business needs. We shall see of course; all I can say is that before I got sucked into the enterprise developer focused world of my last couple of employers, I would have agreed that the complexity is for evil/clueless purposes. Now I don't; the paying customers in my world DEMAND that intellisense and databinding stuff that people in the web geek world think is gratuitous fluff. It also remains to be seen whether RELAX NG, RDF Schema, etc. are also just simpler tools for simpler jobs than XSD, or really do more with less. I'd be extremely happy to be proven wrong that XSD is a necessary evil!

Dan Hatfield
(February 24, 2006 02:44 AM #)


Care to clarify what you mean by intellisense and data binding with respect to WS-*?

Trying to understand exactly what you are saying paying customers are demanding...

I've seen my fair share of enterprise projects. And there's no doubt that some customers just love complexity or DEMAND it. I've usually found this to be closely related to legacy system and integration work -- something alot of web developers don't understand becuase they often do "green field" development.

But I'm still not sure I've seen a standard set of requirements that just "DEMANDED" a WS-* solution -- they've all been corner cases.....

Mike Champion
(February 24, 2006 03:21 AM #)

Hmm, that was meant to be in relation to XSD, not WS-*... and the static typing vs dynamic languages issues, but that's another permathread. And hardly anyone "demands a WS-* solution", they just want things to work. Sorry for the unclarity.

I agree that the lovers of complexity (and X/O mapping) in the world tend to be integrators rather than greenfield developers. IIRC, integration consumes something like 60% of enterprise development costs, so we are not talking about corner cases, however.

In case Patrick Logan is following the comments thread for the record I'm an extremely reluctant convert to the position that XSD is a "necessary" evil, although I've believed for a long time that it is *evil*. I do take issue with the implication that the complexity in the XML (or WS-* for that matter) space is somehow beneficial to the purveyors of wizard-ish tools. I've met more rabid XSD haters at Microsoft than I ever did on the outside, and the complexity of the overall XML pile-of-stuff costs MS far more than it gets back in Visual Studio revenue for tools that address (or perpetuate) it. If someone would figure out how to knock XSD off the hill, there would be a big party in Redmond :-) Trouble is, none of the current contenders seem up to the job ...or at least none offer a big enough benefit to justify the switching costs.