Tell everyone that you aren’t going to have time to write many entries and people start blogging about cool and interesting topics. Here is a quick rundown of the ECM WSDL analysis and my thoughts.

• Our old buddy James McGovern started the whole thing off. He has apparently been sharing is frustration with his significant other and he wrote a post on the sad state of WSDLs in the ECM space. They are ugly and poorly written in his experience. Not having delved into any out of the box WSDLs in ECM, I can hardly argue. It wouldn’t shock me though. Hopefully the DFS ones will measure up better. James then starts to talk about the ECM systems having a standard Document Query Language and a common WSDL built upon that structure. Sounds good to me. In fact, it is a nice, positive contribution to the whole ECM standards issue.

• Bex Huff then gets wound up. Part of the reason is that James referred to him by name when listing known ECM architects that may have contributed to current WSDLs out there. Bex reiterates his positions (No new standards, REST is bad, Microsoft killed WS-*) from previous posts with fresh examples. I don’t agree with Bex on some of it, but I will respond to that in more detail later.
• James then linked to Bex’s post, and added a nice clarification. I’m posting the entire comment as it sums-up James’ thought process to date:

Brian Huff got it somewhat twisted due to my calling out patterns across vendors and not enumerating them on a per-vendor basis. Brian, don’t worry as we are on the same page and agree on more things that appears on the surface. I was simply commenting on the horrific WSDL at large that exists. Some of the WSDL I have seen in the world of ECM feels more like a weakly defined upgrade path where they took their suboptimal query languages and proprietary APIs and simply wrapped them without any thought about doing it the right way of WSDL first. We both agree that arg0 is fugly but it is even worse as I held back and didn’t comment on the simple opportunity to enumerate all possible values that could be passed as schema does support the notion of xsd:choice. Even worse is when you run across namespaces that read exactly like the underlying java classes. Let me say that standard WSDL in the ECM domain isn’t possible until vendors at least figure out a standard query language to handle all the semantics you mentioned.

• Bex then reacts by saying that he may have read too much into James’ post. Then something amazing happened. Bex agreed with James. Bex still loves his SOAP messages and I am not in a position to dissuade him. He does provide a link to a Stellent SOAP message. I’ll make you go to his post to get a look at it.

ECM Platforms and Content Rich Applications

James then writes a great post with the input of his significant other. Go read it and come back….

My first impression is that I like his significant. She seems very rational and not bitter from repeated issues that this environment can throw at you, and has thrown at James. They, giving both credit, then talk about how ECM vendors view ECM as the center-of-the-world. They are correct, ECM is not the center, as such. ECM is a platform, not the end all, be all of life. As I stated recently, the Enterprise in Enterprise Content Management needs to refer to supporting the Enterprise, not doing everything for the Enterprise. To quote them, ECM is a participant … and should defer/support transactions in a larger context.

ECM vendors need to provide a strong ECM platform. From this, there should be the ability to plug different Content Rich Applications (CRA) into the platform, like SharePoint and WCM applications. The vendors can provide their own offerings, and even provide a tight integration as a competive edge. However, in the grand scheme of things, CRAs need to become plugable into multiple ECM platforms. This also means having the ECM vendors making their own CRAs, like eRoom, plugable as well. Imagine if I had a FileNet ECM platform and was able to plug Interwoven’s WCM CRA into it. Ok, maybe a bad example, but you get my point.

In this same way, ECM needs to be the support for serving content to other applications such as BPM engines. This is the example that they give. The process should be just like plugging in a lamp. This is the lower hanging fruit. Security, Metadata, and Content. There are details buried there, but from a high level, that is it.

I am planning another post on ECM and SOA and why Standards are needed. I have decided to convince Bex of the need for Standards. I figure if I can convince him, I can convince anyone.

[Edit 8-23: James wrote another post on this topic directly responding to Bex that already slipped off his main page.]