EMC Documentum is a leading player in the enterprise content management space. That's not news. What is, is the way the company has, with the release of Documentum v6 (D6), embraced Services Oriented Architecture (SOA) as a first-class principle in its core architecture.
D6 Presents a Full SOA Story
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.
Introducing Documentum Foundation Services (DFS)
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:
* Object Service: provides fundamental operations for creating, retrieving, updating, and deleting repository objects. Copy and move operations are also available.
* Version Control Service: provides operations such as checkin and checkout that concern object versions.
* Query Service: provides operations for obtaining data from repositories using ad-hoc queries.
* Schema Service: provides operations for examining repository metadata (data dictionary).
* Search Service: provides operations concerning full-text and property-based repository searches.
* Workflow Service: provides operations that obtain data about workflow process templates and an operation for starting a workflow process instance.
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.
A Real World Example
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.
The DFS Bits 'n' Pieces
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!
Your Deployment Choices
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.
What does it take?
The SDK facilitates DFS development, both for services and consumers. The development process can be outlined as follows:
# Write Java service code, which can be a POJO (Plain Old Java Object) or a business object in the Documentum Business Object Framework (BOF).
# Annotate the code to provide information about the code. This information is used for code generation later.
# Use DFS tools to generate artifacts such as WSDL proxies or Java client libraries.
# Build tests from Java clients.
# Package services as WAR (Web ARchive) or EAR (Enterprise ARchive). The same tests can now be run remotely.
# Validate WSDL with non-DFS-generated clients.
Moreover, the SDK allows the developer to focus on implementing the business logic in step 1 while automating most of the other steps.
Roll Up Your Sleeves
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.