Sunday, September 09, 2007
ECM: Craig Randall vs Eric Barroca
In my Links for Labor Day 2007 I posted my observations of Documentum and Nuxeo. Eric Barroca chose to respond while Craig Randall exercised his right to remain silent...
For the record, every single vendor in the world of ECM either produces horrific WSDL or gets it twisted by focusing on REST with the notion that the world is all about them and that they shouldn't acknowledge that ECM is a participant in a larger context.
Anyway, I figured I would share Eric's most thoughtful posting:
It takes a person with real class to acknowledge not only their strengths but their weaknesses in a public forum. Generally speaking, customers really desire to hear that you acknowledge your faults and that you are passionate about fixing them. Nothing should be personal except what you choose to make personal.
An understanding that an ECM platform shouldn't take sides on the SOAP vs REST debate but should support both is exactly the right answer. I wonder if the folks over at Stellent, Alfresco and Filenet agree?
I really appreciate a discussion not just around product features but honest conversations around how products are built. The underlying design of a platform is important in that ECM folks may need to extend core functionality to help integrate with BPM, ERP, CRM and other enterprise applications. Clean APIs and Web Services help enable this so getting the interfaces right is important.
It is good to see that they aren't noodling thinly-veiled wrappers over existing APIs but evaluating what is the best way in terms of current customer usage while not comprimising the principles of what it means to build thoughtful SOAs.
Now the only thing outstanding is for me and Eric to figure out how to work together to increase the security of the Nuxeo platform. I am firm in my belief that I should put my money where my mouth is and spend time helping them embrace Secure Coding practices as the first step. At a later date, I will also help them incorporate XACML and replace legacy ACL approaches.
The wonderful thing is that contribution is easy with Nuxeo in that the entire code-base is available. I originally noodled doing something similar with Alfresco but their platform is not truly open unless you use the distorted definition embraced by many analyst firms.
I look forward to a continuing dialog and contributing over the winter holidays...
| | View blog reactionsFor the record, every single vendor in the world of ECM either produces horrific WSDL or gets it twisted by focusing on REST with the notion that the world is all about them and that they shouldn't acknowledge that ECM is a participant in a larger context.
Anyway, I figured I would share Eric's most thoughtful posting:
- This WSDL is a WSDL automatically generated by JBoss's WS stack (Axis in this case) from some classes. And it has been copied into the SVN to ease the development of a .NET client. We are well aware of the fact that it's horrible since we had to use it. But we can take the blame and we are well aware about this issues when WSDL are auto-generated by the WS stack. We are even currently working on this issue to improve the service platform (you can see some thought about the service approach here: Nuxeo EP: the Service Oriented ECM Platform).
It takes a person with real class to acknowledge not only their strengths but their weaknesses in a public forum. Generally speaking, customers really desire to hear that you acknowledge your faults and that you are passionate about fixing them. Nothing should be personal except what you choose to make personal.
- We have already done some work on at "service" level by enabling a fully extensible architecture and a nice service-oriented / component-oriented API for use from Java (thanks to the OSGi-based NXRuntime's infrastructure). We also have worked on an extensible REST framework, based on RESTlet, for the platform which allows any component to easily contribute REST interfaces.
An understanding that an ECM platform shouldn't take sides on the SOAP vs REST debate but should support both is exactly the right answer. I wonder if the folks over at Stellent, Alfresco and Filenet agree?
- And now, we are going to start on offering a clean and lean SOAP infrastructure. We have already the base framework where any component can declare some Web Services contributed to a central WS entry point (to share authentication, for example, or common parameters). We now need to find a way to have a nice generated WSDL from the WS stack. You can see the base WS infrastructure in the nuxeo-platform-ws component, with already some contributions to it (see, for instance, the Audit component or the Intuition component — which is a webservice offered to the Sinequa Intuition search engine). So... we are working on it and are currently starting our effort evaluating the wonderful world of Java WS stacks.
I really appreciate a discussion not just around product features but honest conversations around how products are built. The underlying design of a platform is important in that ECM folks may need to extend core functionality to help integrate with BPM, ERP, CRM and other enterprise applications. Clean APIs and Web Services help enable this so getting the interfaces right is important.
It is good to see that they aren't noodling thinly-veiled wrappers over existing APIs but evaluating what is the best way in terms of current customer usage while not comprimising the principles of what it means to build thoughtful SOAs.
Now the only thing outstanding is for me and Eric to figure out how to work together to increase the security of the Nuxeo platform. I am firm in my belief that I should put my money where my mouth is and spend time helping them embrace Secure Coding practices as the first step. At a later date, I will also help them incorporate XACML and replace legacy ACL approaches.
The wonderful thing is that contribution is easy with Nuxeo in that the entire code-base is available. I originally noodled doing something similar with Alfresco but their platform is not truly open unless you use the distorted definition embraced by many analyst firms.
I look forward to a continuing dialog and contributing over the winter holidays...