ithout a doubt, Web services have hit the mainstream and have demonstrated their value. They were designed largely to address interoperability and distributed computing and both goals were realized by layering technologies over existing implementation environments. Web services have not only changed the way that applications are built, but more importantly, they have enabled entirely new classes of solutions. For the first time we have foundations that enable the construction of applications that allow participation from individuals and computing systems in different organizations, operating within a diverse set of IT environments.
As game changing as they are though, Web services aren't always enough. Sure, if you are offering a stock ticker service then you likely needn't address anything beyond platform independence and remote invocation, however, if you are building Enterprise Content Management (ECM) services and applications you must leverage the paradigms and tools that are coarsely categorized as service oriented. ECM systems capture, store, secure, and manage the documents and other content assets of enterprises so that information can be found, retrieved, delivered, and retained when needed.
Regardless of industry, all organizations and corporations, from small to very large, have content management needs that are fulfilled with some type of automated solution. The effectiveness of such solutions has been repeatedly proven over the last 20 years. In the early part of this history a content-centric solution was generally built over a single content repository and this resulted in ECM architectures that tightly coupled the storage, management, and delivery functionalities. The content management needs have changed and today the user requires solutions that span multiple content repositories. For example, an insurance claims processing application will draw together accident reports from one system, customary repair costs from another, and allow a claims adjuster to produce documentation that is stored in a third; coordinating regulated process over this heterogeneous environment requires a richer development and deployment infrastructure than what was previously available. A service-oriented approach fits the bill.
While there are many elements of service orientation that could be applied to this complex solution space, there is really only a handful that stands out as the foundation of service-oriented architectures (SOA) for ECM. To build an ECM system interface you can't just start writing Web services; instead, you have to be aware of interoperability constraints, take advantage of the WS-* and other Web services-related specifications, and create service interfaces that can be utilized from a number of different application development environments, including graphical tools targeted at a new class of developer. This is far more than a simple technological change. In this article, I'll discuss these broader shifts and explain how a careful and deliberate approach to planning an ECM services implementation will result in a more efficient and flexible system that delivers ROI.
SOA Adds Agility
Enterprise Content Management systems have been indisputably successful over the last 15 to 20 years demonstrating significant ROI and enabling solutions that were previously impossible to achieve. And while steadfastly dependable, in many cases the systems have become rather large and difficult to upgrade; the average time between major releases across the largest ECM vendors can be measured in years rather than months, and customer upgrades to new releases require lengthy planning cycles. SOA affords an opportunity to change this.
|When initially deployed, for example, ECM services may be invoked with a username and password for authentication, however, an enterprise SOA upgrade may allow connection to the same ECM services with a single sign-on token.|
Web services that are decoupled both from other services as well as from the content management system itself will modularize ECM capabilities allowing for fundamental units to be independently upgraded. For example, imagine that a Web service that generates a PDF rendition from a document checked into the repository has recently been optimized. Using SOA, this Web service can be tested and deployed without changing services such as check-out and check-in. This avoids the expensive and time consuming, yet often mandatory, recertification of these core ECM library services.
This agility, however, does not come for free by simply offering Web service-based interfaces. Rather, the design of the Web services must deliberately focus on meeting this objective. The mechanics of recording audit history upon document check-in is critical in regulated environments; therefore, in the example above, audit history recording must be sufficiently isolated from the activities of a new rendition generating servicethe level of tolerance for interference is zero.
Planning for agility does not apply only to the construction of the Web services themselves; it also involves anticipation of incremental evolution of the services infrastructurethat is, where you're taking your ECM environment in the future. The environment in which Web services operate can be as simple as an application server that services HTTP requests, or it may include a vast array of other components such as single sign-on, message queues, UDDI directories, and an enterprise service bus (ESB).
Content management Web services will be deployed within ecosystems that range over the entire spectrum from basic to sophisticated and will be expected to continue functioning as the services infrastructure is incrementally upgraded. When initially deployed, for example, ECM services may be invoked with a username and password for authentication, however, an enterprise SOA upgrade may allow connection to the same ECM services with a single sign-on token. Again, the ECM services must be designed to anticipate such environmental changes.