Monday, August 20, 2007
Enterprise Content Management and tales of Horrific WSDL
My significant other and I had an interesting chat. She felt that there was a business opportunity in taking the notion of a software appliance, an enterprise service bus and ECM products and creating an integration appliance that allows one to search multiple products whether it be Alfresco, Nuxeo, Stellent, Documentum or FileNet but she ran into the horrific WSDL problem that ECM vendors have been releasing as Web Services...
She made her first mistake by asking my opinion on all of the WSDL in the ECM domain she has collected as my response was that while some where better than others, they were all horrible. Generally speaking, good SOA usually starts with modeling WSDL first whereby you first figure out the notion of a service interface that is product agnostic. Very few, if any of the current WSDL produced by ECM vendors even meets this first requirement.
It shouldn't surprise you that Billy Cripe, Brian Huff and others in the ECM domain would create WSDL that is all about their product and not about anything that even remotely feels like a contract. Some of the common badness she has witnessed in several products includes but is not limited to:
Of course the most egregious thing that I witnessed was the notion of the client having to know how to build a query. Shouldn't the world of ECM support something standard in the form of a Document Query Language that all products implement? Should a client have to understand all the flavors of different query languages? Shouldn't at the web service interface at least support the notion of an interface to help build queries using standardized name/value pairs and predicates?
Maybe someone could tell me why the entire ECM domain at large is so damn behind the times? Is it filled with lame brains who will accept anything as incremental progress and aren't either smart and/or vocal enough to demand something better of their vendors?
What I witnessed today was simply fugly. I am refusing to even help my significant other with her idea until the ECM domain starts realizing that they are doing a disservice to their customers and more importantly publicly acknowledges that they aren't up to standard with other product domains such as CRM, ERP and BPM when it comes to good design.
On the remote chance, any Enterprise Architect happens to read this then you should assume that the Web Services being sold by ECM vendors today simply isn't worthy of production implementation and you may need to help them see the light. For me, I am encouraging my wife to give up on this domain as a lost cause...
| | View blog reactionsShe made her first mistake by asking my opinion on all of the WSDL in the ECM domain she has collected as my response was that while some where better than others, they were all horrible. Generally speaking, good SOA usually starts with modeling WSDL first whereby you first figure out the notion of a service interface that is product agnostic. Very few, if any of the current WSDL produced by ECM vendors even meets this first requirement.
It shouldn't surprise you that Billy Cripe, Brian Huff and others in the ECM domain would create WSDL that is all about their product and not about anything that even remotely feels like a contract. Some of the common badness she has witnessed in several products includes but is not limited to:
- Throwing Faults that 100% mirror the Java language and include things like the notion of a Bean and Message
- Naming elements arg0 and other intuitive names
- Creating a web service that requires state and including weird notions such as retrieving the HttpSessionID
- Creating ComplexTypes when SimpleTypes such as xsd:String could have been used
- Spreading duplication across multiple XSD files
Of course the most egregious thing that I witnessed was the notion of the client having to know how to build a query. Shouldn't the world of ECM support something standard in the form of a Document Query Language that all products implement? Should a client have to understand all the flavors of different query languages? Shouldn't at the web service interface at least support the notion of an interface to help build queries using standardized name/value pairs and predicates?
Maybe someone could tell me why the entire ECM domain at large is so damn behind the times? Is it filled with lame brains who will accept anything as incremental progress and aren't either smart and/or vocal enough to demand something better of their vendors?
What I witnessed today was simply fugly. I am refusing to even help my significant other with her idea until the ECM domain starts realizing that they are doing a disservice to their customers and more importantly publicly acknowledges that they aren't up to standard with other product domains such as CRM, ERP and BPM when it comes to good design.
On the remote chance, any Enterprise Architect happens to read this then you should assume that the Web Services being sold by ECM vendors today simply isn't worthy of production implementation and you may need to help them see the light. For me, I am encouraging my wife to give up on this domain as a lost cause...
