Core WS Standards for ECM Should Be Mandatory
Getting content, say from a user's desktop, into the repository, ensuring it is not tampered with while in transit and securing it once stored, are two of the basic concerns for an ECM system interface. No one wants their employee performance appraisal accessible by any of their colleagues; ECM systems provide access controls that require a user to identify themselves, often with a username and password, before access is granted to managed content. Fortunately there are Web services standards that offer solutions.
Security, both at the point of access and while content is in transit is addressed through the WS-Security standard. WS-Security extends SOAP to address message integrity and confidentiality and also defines a mechanism for the inclusion of security tokens within the SOAP envelope.
WS-Security does not provide a security solution, rather it defines a means by which Web services and security solutions are to cooperate in the SOA. In order to ensure that security is soundly addressed it must be an infrastructure component with which all business critical applications, including an SOA-ready ECM system, must interact. With the availability of such infrastructure elements then, the Web services developer needn't reinvent mechanisms for message integrity and access control, rather the developer should design services that utilize WS-Security; reuse the capabilities implemented in Web service runtimes such as Axis and Systinet.
|Providing ECM Web services that meet the requirements of WS-I BP 1.1 will ensure that they can be deployed on a variety of platforms and be consumed by applications running on similarly varied platforms.|
Enterprise content management necessarily involves the transport of all types of content from where it is now, say on the user's desktop, into the content repository and while some data transported with the content, such as the author of the document, is well suited for transport within the XML-based SOAP envelope, the binary files must receive special attention. For this purpose, there are two standards that have emerged as the dominant ones and these must be supported by ECM Web services: base64 encoding and SOAP Message Transmission Optimization Mechanism
Base64 takes each byte from an unstructured binary stream and maps it to a character suitable for inclusion in an XML document. And while this approach clearly suffers from inefficiency concerns, its simplicity and ubiquity make it suitable in situations where the encoded payloads are small and infrequently passed (e.g. human-based processes such as expense report submissions). MTOM, which was created to optimize even standard XML via SOAP, addresses efficient transfer of binary content with serialization of multi-part/MIME content and is the transfer mechanism of choice for batch uploads (e.g. automated document scanning) or large binary files (e.g. CAD drawings). Your choice of content transfer mechanism should predominantly be driven by the application scenario, how frequently content is uploaded or downloaded, and the relative sizes of the payloads.
Finally, to ensure platform independence for the ECM system the WS-Interoperability Basic Profile (WS-I BP) specification, which tightly constrains the use of SOAP in support of interoperability, should be supported. WS-I BP also places more stringent requirements over the use of WSDL, eliminating certain ambiguities that could present interoperability challenges. Providing ECM Web services that meet the requirements of WS-I BP 1.1 will ensure that they can be deployed on a variety of platforms and be consumed by applications running on similarly varied platforms.
The Application Developer for ECM in the SOA
The developer of the content-rich application does not fit a single profile. While historically most have been programmers (Java or .NET) who are at least one level removed from the business user whose concerns they are addressing, recent innovations are making application development directly available to the business analyst.
Consider first the business analyst. This "developer" will use technologies such as business process management (BPM) tools or portal systems to build and configure the applications they construct. These tools provide intuitive, often graphical, drag-and-drop, non-coding interfaces to facilitate the composition of services into new targeted applications. The provider of ECM services must carefully consider two main things to ensure that their offerings can be utilized by this new breed of developer. First, the services offered must expose a level of detail and control that is consistent with the needs of the business analyst and this means a coarser granularity than what is typically offered the serious programmer. Instead of offering numerous interfaces for tasks such as creation of an object in the repository, identification of an object type, assignment of contextual labels, and making the content available to other ECM users, for example, a single, simple interface for uploading content into the repository is called for. The second concern for the service producer is that the BPM and portal-based tools require services to be described in a standardized form. Fortunately, the Web Services Description Language (WSDL) is already in widespread use and likely something the Web services developer is already well familiar with.
|Figure 1. The client library searches HTML content for embedded graphics, packages all binaries in a single SOAP message, and dispatches that message to the service endpoint. (Note: service endpoint depicted with conventions introduced by David Chappell.)|
There is, of course, still a need for traditional programmers and providing them with the tools to efficiently construct and deliver powerful ECM systems should also be a primary concern of the services provider. To address platform interoperability a common approach in the SOA is to depend entirely on the services themselves for the reusable components of an application. Using an IDE to generate proxies from a WSDL definition does bind the application to the platform at the right time, however, the client-side classes that are generated as a result are reduced to facilitating message transfers. The unfortunate consequence is that we've essentially ignored the need for implementation reuse in client side processingwe aren't providing services that run on the client, yet sometimes this is exactly what we need.
From ECM, for example, let's consider the example of managing HTML content. Even in the simplest sense a typical Web page is really a collection of documents, the main HTML page plus files containing the images on that page. When an application developer wishes to provide their user with a capability to upload a Web page into a repository they have to write code that 1) scans the HTML file in search of <img> tags, 2) collects the HTML file and those image files and 3) packages them for transfer, all before they can use the webPageImport service you provide. Rather than requiring each application developer to produce their own implementation of this functionality, which is arguably part of content management, I suggest you provide them a reusable implementation in the form of a client-side library (see Figure 1). That being said, I caution you not to overuse this approach as you will have to produce libraries for each of the client-side platforms independently, sacrificing interoperability. However, in most domains, such as ECM, true need is minimal. The key is to balance the usefulness of such libraries against the platform interoperability needs.
ECM and SOA: Made for Each Other
The complex world of ECM is a textbook example of the important benefits that are conferred by a service-oriented architecturethe benefits can be huge. Through the creation of ECM services, large, complex systems will be more effectively deployed, configured, and maintained. Further, ECM functionalities will be more easily integrated with other core business functions such as ERP and CRM systems.
Application of service orientation concepts to the ECM architecture must be carefully thought out and deliberately applied so as to meet the specific needs of the content-centric enterprise. Service orientation is not simply about Web services, interoperability, and distributed computing. Services design goals should include the both enabling a more fluid, adaptable IT ecosystem as well as functioning within such an ever-changing environment.
Building services around the vast array of standards and standards-based tools available today will produce truly interoperable and widely reusable system components. And finally understanding that the traditional applications programmeras well as a new breed of application developer, the business analystare your target consumers will broaden your impact. For those who are tasked with providing ECM capabilities, regardless of the industry, service orientation and the Web services-based standards compliance will provide the tools for future success.