Universal WSDL for ECM? Double Ish.

James is at it again... this time inciting me by claiming I support crapy WSDLs as an Enterprise Content Management (ECM) standard.

I like SOAP and SOA... but I hope it wont come as a shock that I hate WSDLs, and I'm hardly a Java fanboy. So the odds are quite quite low that I'd support a crap WSDL standard that names elements arg0, uses a session ID, demands a plethora of complex types, or is to Java-y.

As I've said before in my anti-ReST rants, WSDLs and the Microsoft WS-* stack ruined the simplicity of SOAP on purpose. Why? According to Tim O'Reilly, a Microsoft architect confessed that they did it to force people to use Microsoft tools to SOAP-enable their applications. Typical... unfortunately the Java folks followed suit, and now anything other than bare-bones SOAP is a nightmare to code without an IDE.

Even if that weren't true, I still don't like the idea of WSDLs because it lulls people like James into a false sense of security... once we have WSDLs, it will be easy to get all of our systems to communicate!

Bullsh!t.

They said the same damn thing about everybody using databases, everybody using portal servers, everybody using XML data files, etc... and I'm not amused. Integrating systems always requires a thoughtful hand, unless the applications are nearly worthless commodities... such as a toaster and an electrical plug.

The problem is not lazy developers, the problem is the fundamental difference between syntax and semantics and its effect on the human/computer interface. Even in mind-numbingly well defined web services problems -- such as stock trading data -- people call the same thing by different names. Why? Because its useful. It adds value. And that causes people who create web services for stock market info to give different variable names to the same exact thing... even though the terminology of the stock market has been the same for decades.

So... lets assume they eventually get together and agree on terms, and now all APIs to stock market info are exactly the same. Great! Now their service is a worthless commodity. In order to survive, they need to innovate. What does that mean? Inventing new ways of looking at the same data... then others will follow... again, using different words for the same damn thing. Suddenly, their APIs no longer mesh.

Whoops!

Anybody recall when linguists decided to invent Esperanto? Gosh, imagine it! A universal language that everybody can communicate with! All language problems were instantly solved overnight! Hmm... then why on earth did they also have to invent Interlingua, Ido, and other IALs? Because they were solving the wrong damn problem.

Now, I'm not saying all standards are crap, I'm saying that there are already four of them that treat ECM like a worthless commodity. There's absolutely no point in demanding a fifth one that's exactly the same, except based on fancy-new-buzzword-X. That is, unless there's something specifically wrong with the existing ones that can only be solved with a WSDL. Otherwise, what's the point? His complaints thus far can be solved with a tiny bit of refactoring, and better documentation.

And finally, nothing gets done without incentives. Plenty of ECM vendors have done quite well by delivering what the business users want. Some anticipated demand, some created demand, but most were followers. Unless somebody actually sees or anticipates a demand for a fifth, sixth, or seventh ECM standard based on WSDLs, its relatively pointless to give people the same mistake in a different wrapper.

SOA is still not being done well in the enterprise... people need to fail a little before best practices emerge. Until other apps are as SOA enabled as (certain) ECM systems, its a bit pointless to push so hard. I stand by my original statement that a decent ECM standard won't be worthwhile until 2009... but my current money is on something similar to WebDAV or APP; it won't be a Java-specific standard (JSR170 or JSR283), nor will it be anything as pointlessly complex as WSDL... plus it won't take off until Microsoft endorses it.

So ultimately, James and I agree. A WSDL standard for ECM would be a nightmare... but not because of limitations in the ECM market: rather because of limitations and broken promises on behalf of WSDLs.

UPDATE: I may have read a little too much into James' post... see my re-response.