While Documentum v5.3 had support for implementing web services via the Web Services Framework (WSF), it was a relatively limited set of technologies designed for making Service-based Business Objects (SBO) available as web services. Essentially, you could take a piece of business logic in Documentum and make a web service out of it.
Suppose that there is custom logic to validate the provided information, store a document in a Documentum repository, and then send it as an email attachment to a specified recipient. WSF would allow you to make this functionality available as a web service.
D6 introduces Documentum Foundation Services (DFS), which is an entirely new set of products that completely replaces WSF. DFS enables development and deployment of ECM services and service consumers using a true service oriented architecture. Let’s explore what DFS has to offer.
DFS provides a set of ready made services and tools for creating custom services and service consumers. The DFS-provided services are called Enterprise Content Services (ECS) and include the following:
Note that all of the above functionality (and more) is available through Documentum Foundation Classes (DFC). ECS makes the above functionality available as web services which are ready to be consumed by applications or other custom services that you may want to create.
With the advent of the DFS/ECS service points, now any consumer can easily access the Documentum repository as long as it understands web services. And developers can now compose distributed applications easily using ECS as a component.
The DFS Software Development Kit (SDK) is a set of tools included in the DFS for creation of custom services as well as consumers of services (both ECS and custom). The SDK hands the developer the real power, above and beyond the former WSF possibilities. Developers can now easily generate new services from regular Java code and these services can easily utilize the ECS.
Suppose that you are building a Loan Management application which deals with several documents for each account. For example, a loan account may be associated with an application, a photo ID, and a proof of income. This application can become a consumer for the ECS to store these documents in a Documentum repository and access them as needed.
Even better, you can create a custom service with operations at an appropriate level for your Loan Management application. In turn, this service can implement and hide the interaction with the lower-level interaction with ECS.
As a part of its plumbing, DFS includes a server runtime and a client runtime. The server runtime is used by the services while the client runtime can be used by consumers of these services. The services are also exposed via WSDL (Web Service Definition Language) so they can also be accessed by regular web service clients.
One benefit of using the client runtime is that it can provide location transparency, i.e. the same consumer code can access the services whether they are deployed locally or remotely. When the consumer is collocated with the service, the overhead of SOAP message exchange between the consumer and the service can be bypassed – you can just holler; you don’t need to pick up the phone when the other guy is in the same room!
By default, DFS is deployed along with the Content Server. However, D6 offers the flexibility of deploying DFS instances on additional application server instances. This feature opens up numerous options for developing and deploying DFS services and consumers.
For example, developers can have their own sandboxes on their laptops where they can break the code as much as they need to before they are comfortable deploying it where others can access it. You could even have DEV and QA instances on the same physical machine if you were short on hardware resources.
If you were supporting multiple versions of your code, this flexibility helps you access the same Documentum repository through different versions of the service code. If you sell a product that incorporates DFS services, combine this flexibility with virtualization products (such as VMWare) to facilitate certification on different platforms and configurations.
In production, you could have multiple application server instances to distribute load or to provide isolation for security or performance reasons. These examples just get you started on the common scenarios, be creative to maximize these options according to your specific technical environment and processes.
The SDK facilitates DFS development, both for services and consumers. The development process can be outlined as follows:
Moreover, the SDK allows the developer to focus on implementing the business logic in step 1 while automating most of the other steps.
Documentum Foundation Services bring SOA to Documentum and Documentum to the larger SOA picture in an enterprise. These new capabilities along with promotions such as the EMC Developer Challenge should drive SOA adoption in the Documentum developer community.
ECM is finally staking a claim as a core component of service-oriented distributed applications. If you are a Documentum customer, this may be the perfect time to plan the next leap and get your hands dirty with DFS.
Pawan Kumar is the author of the book Documentum Content Management Foundations and the founder of the online Documentum community dm_cram. He frequently shares his thoughts on Content Management etc.