Organizations have been constantly evolving and adapting the last few years to find a cost-effective innovative business model what will provide sustainability and create more business value. Certainly cloud, mobile and social remain key areas of focus in CIO/CTO's office. Product vendors and System Integrators (SIs) are constantly working to support organizations to achieve their business goals with the help of cutting edge tools, technologies and services in these three areas.

On the other hand, service orientation is not a competing business model or architectural style at all, rather this style is complimentary to cloud, mobile and collaboration. Many large organizations have already started their journey of service orientation few years back and have matured enough to handle some of the complexities around it with a strong governance model, whereas some organizations are at an early stage of SOA maturity.

I will not focus on generic SOA principles and its implementation in this article. So much has been written and talked on SOA. Rather I will try to restrict myself to the subject ‘how SOA is relevant to ECM'.

Setting the Context

It has been more than a year since I wrote an article on ECM & Portal integration - '5 Things to Consider when Integrating your Content Management System and Portal'. I received very interesting responses, comments and questions publicly/privately on this. Obviously that led me to believe that large organizations and product vendors, especially those using best of breed ECM & portal platforms and building ECM centric custom applications and frameworks, are really looking for this kind of integration solution. I will take the opportunity and try to answers some of the fundamental questions I have been asked like:

  • Why do we really need another set of custom services/wrapper service? Services are already shipped with the ECM product. Why can't we go ahead and directly use those from portal/client application instead of building another custom layer/wrapper on top? Frankly speaking, some readers were even bit upset. They think 'this is all mere wastage of time building reusable custom ECM services'.
  • How can we manage/maintain these custom ECM services?
  • Implementing SSO is killing us and this is too complex a deal. Too much of understanding, skill-set, effort is required to implement this. Is there any cookie-cutter approach?

All are very interesting questions indeed and all are very relevant questions. Before I start answering those above, I'd like to point out very clearly that no one architectural pattern exists that can suit and solve all business problem(s) for all organization(s). Every organization has a different way of functioning and will be dealing with different levels of complexity and tools, technology situation. So, architecture decisions will be driven by many business factors and non-functional criteria existing in that specific business house.
Readers should have a basic understating of tools/technologies related to ECM, SOA and SSO.

ECM Custom Service/Wrapper Service -- We Really Need Those?

If you look closely, all the leading ECM vendors enable basic fine-grained content management services in the form of SOAP or REST (Native or CMIS) to expose the ECM product functionalities/features. So now the question arises why those fine grained services cannot be consumed directly from the client application/custom solution? Well, there is no one liner easy answer to this. It all depends on the business context of the enterprise where the solution would be deployed.

First of all ask yourself, do these fine grained services provided by ECM vendor bring any business value for your enterprise directly or indirectly? Let us not get confused with Web Services and true SOA services. Do these fine grained services (provided by the ECM vendor) satisfy some of the basic principles what you generally follow while defining your SOA services for your enterprise like:

  • Reusability
  • Coarse-grained (With optimal granularity)
  • Composite
  • Encapsulation (Hiding the implementation details)

If the answer is ‘no’ and we are talking about a large organization where different business unit(s) will be consuming the ECM services, you probably would like to build a coarse-grained, reusable custom ECM service layer. The reasons are two-fold as we make the decision for building custom/wrapper ECM service layer. Let's do a deep dive to understand the reasons with a specific set of business and technical examples.

Business Reasons for Custom Service/Wrapper Service

  • Sometimes large enterprises use more than one content management system due to lack of IT governance and decentralized IT decision making. So over the period of time, the organization builds silos. Sometimes, organizations inherit this kind of situation through merger or acquisitions. But business may like to do their content centric operations in a transparent and seamless fashion from their business application or portal while content is being managed in different disparate repositories/content management systems. So there has to be generic and composite content related services and those need to be designed/built across these varied repositories to serve the business. (Note: An effort towards consolidation and coming out with an 'Unified' infrastructure and repository in a virtualized environment/private cloud might be another approach/possibility to deal with this kind of situation, but it will depend on cost along with other factors like tools/technology maturity in the ‘ECM Cloud’ space .)
  • In some cases, for good reasons large organizations run different repositories/content infrastructure (mostly from same vendor) for varied business functions (DMS, XML Content Management, Transactional Content Management, Digital Asset Management etc). But the business interfacing application may need to access and consume the ECM services from all content repositories simultaneously. So, you may need to build composite services.
  • You will always find that a set of content centric business functions is of common nature across the different business units of an organization. The way (logic) content does get into  the repository and consumed by different organizational business units may have similar pattern. As example, when you are bringing content from different parts of the organization, you might have a common rule to attach a Lifecycle policy specific to each business unit and initiate a workflow process. Besides organization wide common rule, we may need to implement business unit specific logic for content related operations.
  • Let us take another example, in a typical auto claims case management system, the claimant likes to initiate and track its claim via a self service portal and mobile device. An adjuster also like to see the claimant policy information and body shop address using his mobile device. So, we need to consume same service via different channels.
  • If you are a product or service company building an insurance solution, you may need to build a set of common ECM services for creating and retrieving content at different stages of insurance lifecycle (like new business, underwriters, policy holder services, claims processing) based on certain predefined rules.

Fine grained ECM services shipped with ECM vendors cannot handle all alone the above custom needs. You have to build business logic with the help of the fine grained services that come with an ECM vendor to get true business value out of them. Now you need to really decide whether you would like to write this business logic -- at the client end or it would be the ideal candidate to write, manage and maintain those as 'ECM Services'.

I would vouch for writing this logic as ECM services especially in the case of large enterprise and product development situations. The reason is not only for commonness and reusability, but this also could give an opportunity for easy maintenance, registration, discovery, strong governance and can be even supported by a chargeback model if required.

Technical Reasons for Custom Service/Wrapper Service

Now what are the technical reasons behind building reusable ECM services having Organization/Departmental business logic built on top of OOTB services provided by product? All the leading ECM product vendors provide fine grained exposed APIs in form of Web Services to connect into the content repository and do the varied ECM operations. Now just think about a large organization where you share your content repository and expose the WSDL (Web Service Definition language) across the business units for consuming the services from their respective clients. Well, you can still go ahead and do that, but you would like to think about the following implications:

  • While you are exposing all the fine grained services (which might be very high in number) to all your clients, you lose control of who consumes what and in turn you also lose control over SLAs for performance (throughput , response time etc.) and other non-functional aspects that you have promised your service consumer. Practically, you have almost no governance of your ECM services. If you have a SOA infrastructure (Registry/Repository) in place with added tool/capability, you can overcome this situation to some extent, though it would not be so easy to manage the huge number of fine grained service(s) and their SLAs.
  • Once you start consuming the vendor specific APIs from a client, it is obvious that your client application also will inherit that dependency. So, every time the ECM product vendor changes the API you are using, you may need to incorporate the relevant change into all your client application(s). So you lose the flexibility that will in turn increase maintenance. No need to mention that you need to rewrite content centric logic/API in all of your client applications if you ever plan to change your underlying ECM platform.
  • As business unit starts consuming these fine grained services to build business logic from their custom solution/client applications, organizations lose the opportunity to have common logic, reusability, better maintenance and more importantly better governance.

So, we should be clear enough by this time, there is a need to write reusable, coarse-grained custom/wrapper ECM services to manage the enterprise ECM business need. Well, let us not forget the real fact though that these leading ECM vendors have made life lot easier (while building true content centric business services following SOA principles) by exposing the content management features as Web Services with proper tooling in place.

Now we may not need to take such a robust service approach always especially when you are operating in the SMB area and you know for sure that you have just one (or a couple) of internal consumers to consume the ECM services and do not see much reusability opportunity. Or you are building an application that is not really content centric -- only few lightweight touchpoints are there as far as the ECM is concerned. In those cases, you may attempt to consume the fine grained services and write the minimal business logic in the client layer itself.

Managing ECM Services?

I do not really find much difference between managing ECM services and non ECM services. You may like to use the same SOA infrastructure that you are already running in your enterprise to manage non ECM services or you may like to evaluate and introduce one if you do not have one already. As you do for any SOA initiative, you need a business service registry/repository for the following:

  • Creating Taxonomy and Asset Type
  • Importing, browsing of Asset (XSD, WSDL) & Metadata Management
  • Asset Versioning
  • Promotion of Asset (Dev, Stage, Prod)
  • Service Lifecycle Management (Planned, Approved, Realized, Certified, Operational, Retired etc.)
  • Policy Management (WS-I Compliance, Web Service Permissions, Contract Permission, username token/LDAP)

Ideally there should be a one stop portal/dashboard which will enable the following:

  • A Business Unit should be able to make request for a new ECM service with relevant details, browse through and register the existing published ECM services using defined organization/product specific taxonomy and metadata
  • SOA Governance Board should be able to publish the standard(s) and review the architecture, design details, reuse aspect of new ECM service at every stage against the published standard
  • IT Stuff/ECM Service developers should be able publish the artifact (XSD, service contract etc) into registry for new ECM service along with service metadata
  • Monitoring interface should be able to provide ECM service usage details, transaction details, outage details and performance statistics and SLA compliance details
  • SOA Architect/Administrator(s) should be able to create design & run-time policy, do versioning of existing service, and manage the service life cycle (review/approve/certified/retired etc.) for the new service and old service
  • Web services/Operations generally need to be secured using any add-on tool (like Actional Intermediary) or by some other mechanism. Actually this provides a proxy access point (Policy governed endpoint) for accessing the operations. Bottom line is SOA Architect/Administrator needs to find a way to protect the ECM service end point.


Above is a typical pictorial representation how ECM services can be managed using an SOA infrastructure.

Is There A Cookie-Cutter Approach for SSO?

SSO is the key for any successful CMS integration with a portal or custom application following service oriented approach. But unfortunately, we sometimes overlook it and give it less priority. As a first step, we may need to clearly articulate the non-functional requirements of SSO and architecture option(s) to achieve this. This will help stakeholders understand the level of complexity really involved to implement this.

To start with, there are few things to look at and analyze:

  • The WebService security standards (like SAML, WS-Security etc.) being supported by ECM product in use
  • Need to get a stock about the SSO provider (like OAM, Netegrity etc.) being supported OOTB by the ECM vendor
  • Web Service security standards and SSO provider are being used by the organization

Secondly, you may like to start looking at the functional requirements and non-functional requirements in terms of:

Business critical application -- As example, you would like to track/audit all the transactions (CRUD) performed by actual user(s). In this case, we may need to use a ‘token’ generated by a standard SSO provider being used in your organization and pass it to underlying ECM Platform from your client application to get it validated once again by the same SSO provider to access the underlying ECM resource. Now you need to understand that the ECM product you are running in your organization may not support the specific SSO provider, which is standard for your organization. So what is a way out in those situations? You need to write extra plug-in/extra piece of custom code that will sit on the ECM environment and do validation for the ‘token’ against ‘SSO’ provider.

If ‘SAML’ is the standard being followed by your organization, SAML Assertions (assembled in form of a token) is generated by SAML aware SSO provider/security engine and passed to ECM platform from the client application. The SAML token gets validated by a SAML aware SSO provider/security engine. Now we must remember, underlying ECM platform needs to support SAML to make it work. In general, SAML is used when SSO needs to be established across multiple organizations/business houses.

Business non-critical Application -- The solution may not demand to track the transactions and it is also not so sensitive to security. In this situation, we can take a ‘delegated user’ approach where a pre-configured ECM user (with authentication details) will be doing the job on behalf of actual user, or at least this pre-configured ECM user will help to create a login session in ECM for the actual user.

So we have to understand, analyze, consider the above factors and come up with short term and long term SSO solution approach with options and recommendations. There are no short-cuts to this.

Final Thoughts

So you can clearly see, we need to take some critical architecture/design decisions while working on any ‘ECM SOA’ enablement program. The key is to understand the business context, the maturity of the organization along with the tools/technology situation, engage with customer at right level and come up with option(s) and recommendations. The complexity of the implementation will vary based on the path you choose.