I assume people reading this article are already familiar with SOA & SOAP. SOA principles are not new for someone who has explored it from the days of RMI/CORBA or Microsoft COM/DOM. One such technology that is still popular even today & significantly unique & worth mentioning here  is REST ( termed as Representation State Transfer). REST is a style of architecture where a collection of distributed hypermedia resources are addressed & accessed without any additional burden of a messaging layer such as SOAP & without the need to manage session tracking via HTTP cookies, making possible to build robust applications simpler, faster & easier. REST lays emphasis on how resources are defined & addressed. See video here ..

We all know DFS stands for Documentum Foundation Services and there are 13 foundation/standard/platform services and many additional Extended services that are technology platform specific such as DFS content services for SAP. Let us first recap a bit on the importance of SOA. We have known of business logic tier and database tier in traditional JEE applications. The business logic tier consists of functions which are reusable validating business logic & processing it. If you extend these systems furhter then you’are talking about integrating & interacting many such systems with each other.  As we all know, such interactions are not possible because each application system has its own language, datatypes etc. So they dont understand each other even if they are able to talk. Then, here comes a WSDL and believe me the whole SOA revolves round this. It is the core contractual document(an xml file) that defines the services that can be called and what is expected as arguments before you make a call. More importantly such interactions can be packaged into a standard service and of course the essence of interaction is to embody the business logic into that service. But the trick here is you can change business logic by keeping the contract/wsdl constant. But its important to remember that a contract is once and for ever unless you want to rebuild the whole thing again. So be cautions to build a fairly robust WSDL contract.

Briefly, different applications can enable integration by exposing their business functionality as services and it is not possible to invoke a service without a prior agreement in the form of a WSDL file.

Typically a DFS WSDL will have the following  elements defined.

1) Types: defines data types
2) Message: “” typed definition
3) Operation: “” description of operation
4) Binding:  “” protocol & dataformat
5) PortType: “” abstract set of operations
6) Port: “” Single endpoint wit binding + network address
7) Service: “” Group of related endpoints

I believe you will be able to understand that all the elements come with <> and you can add your imagination to my brief description. Discussing the full WSDL will be too elemental.

The UDDI Registry: All services must be registered with a UDDI Registry for easy discovery by other services trying to find them(unlike REST). So instead of looking into the whole web they can look at just one place. UDDI stands for Universal Description & Discovery Interface. Every time a service is registered, the UDDI-Registry retains a copy of the WSDL for its own reference. A registration involves the U-Registry knowing its descriptions and all the operations defined in it.

=====

Insert diagram here ..

====

Coming back to services, the standard services are categorized into 5 categories.

1. Core: has
   • Object Service
   • Version Control
   • Query
   • Query Store
   • Schema
   • Lifecycle
   • Access Control
   • Virtual Document
2. Search
   • Search Service
3. BPM
   • Workflow
   • Task Management
4. Collaboration
   • Comment
5. ci(content intelligence)
   • Analytics service

Importance: DFS Data model defines a set of object types covering multiple aspects of a service orient application. These object types are often defined in method arguments &  retrun types. In a standard SOAP model (non-documentum) you may find these as Integer, String etc.

for eg. the method create..

DataPackage create(DataPackage objDataPackage, OperationOptions objOperationOtions) {
….
….
}

Data model can be classified into

1. Primary –> DataPackage, DataObject, ObjectIdentity etc.
2. Profile   –>  PropertyProfile, ContentProfile, SchemaProfile, DeleteProfile etc.
3. Others   –> relating to identity, persistent objects, permissions, schema, exceptions etc.

Let us try to understand the most important & commonly used data model object types.

1. ObjectIdentity: instance contains a repository name & one of  the three  unique identifier objects viz. ObjecId, ObjectPath & Qualification. Therefore creating an ObjectIdentity instance takes the form of
   ObjectIdentity   objectIdentityInstance =  new ObjectIdentity <generic> (any_of_the_3_unique_identifier_objs, repoName);
   where the generic can be an ObjectId or Qualification or ObjectPath

   for eg. to create a qualification ObjectIdentity,String repoName = “myrepository”;
   Qualification objQualification = new Qualification(“dm_document where object_name=’mydocument.doc’”)
   ObjectIdentity    qualObjectIdentity = new ObjectIdentity<Qualification>(objQualification, repoName);

2. DataObject – reprsents a repository object along with its properties, content, identity & relationship to other repository objects information. The signature for creation is new DataObject(ObjectIdentity objId, String objectType); 2.1 Collections: Various collection objects are used in DataObject apart from ObjectIdentity.  Collection objects may describe a) Content, b)Property Set, c)Relationships or d)Permissions.

   a) Content – objects contain data about file content associated with the repository object
   b) PropertySet – a collection of named properties corresponding to the properties of the persistent reposiroty object,
   in simple words it represents the properties of the dm_sysobject(& its subclasses) of the content repository.
   e.g.
   DataObject dataObject = new DataObject(ObjectIdentity objId, String objectType);
   PropertySet propertySet = new PropertySet();
   //single valued properties
   propertySet.set(“object_name”, “myworddocument.doc”);//repeating attribute

   String[] strArrKeywords = {“keyword1″, “keyword2″, “keyword3″ …. };

   StringArrayProperty strArrProperty = new StringArrayProperty(“keywords”, strArrKeywords);
   propertySet.set(strArrProperty);
   dataObject.setProperties(propertySet);
   
   c) Permission – specifies a specific basic, extended or custom permissions reprsenting  the current user’s permission on the repository object. Every DataObject comes with a list of Permission objects. The client cannot change & update the Permission list. Changing permission set of the repository object is done via Access Control Service
   d) Relationship – defines relationship between one repository object (represented by DataObject) & another repository object.
   d.1) ObjectRelationship-represents a relationship to a new or existing repo. object. It is used by an update operation either to update or create target objects.
   d.2) ReferenceRelationship-represents a relationship to an existing repo. object.
   Ref.Rel. object can be used to link a repo. object to an existing folder or it can also be used to create relationship between two objects. But cannot be used to update or create target objects for eg. creating a new folder or set of new documents.

   d.1 & d.2 are subclasses of class Relationship.

3. DataPackage: is a container class for DataObjects representing a repository and typically used to pass or obtain(from return
   e.g. keyword) DataObjects from object service operations like create(), get() & update()

   continued from code above …
   DataPackage dataPackage = new DataPackage();
   dataPackage.addDataObject(dataObject); or DataPackage dataPackage = new DataPackage(dataObject);

4. Profile: objects give you the ability to control the behaviour and contents of the DataPackage through a set of operations.
   PropertyProfile, ContentProfile, PermissionProfile & SchemaProfile are some of the examples.
   Usage e.g.DeleteProfile deleteProfile  = new DeleteProfile();
   deleteProfile.setDeepDeleteFolders(true);
   deleteProfile.setDeepDeleteChildrenInFolders(true);
   OperationOptions operationOptions = new OperationOptions();
   operationOptions.setDeleteProfile(operationOptions);

   ServiceFactory serviceFactory = ServiceFactory.getInstance();
   ContextFactory contextFactory = ContextFactory.getInstance();
   IServiceContext context = contextFactory.newContext();
   IObjectService objectService = serviceFactory.getRemoteService(IObjectService.class, conext);
   //ObjectIdentitySet //**todo
   objectService.delete(objectIdentitySet, operationOptions);
   

Content Transfer: DFS supports the standard Base64 & MTOM and proprietary UCF content transfer mechanisms.

• Base64: should be used when content is placed within a SOAP message
• MTOM: stands for Message Transmission Optimization Mechanism.
  It optimizes the performance of content transfer by an encoding/decoding technique.
• UCF: used for content transfer between client & server. It is light-weight & provides support for standard formats such as xml & word docs.
  UCF also supports invoking the native client application to viewing content after content transfer.

When to use what?

Base64 is know expand the content by upto 1.3 times so it is not preferable for batch jobs with content files larger than 5KB

MTOM adds process overhead in en/decoding and makes the effort ineffective for files less than 5kb

UCf is ideally what you to choose.

A ContentTransferMode is set by a service client before making a content transfer request. The mode can be set in various ways

1. using ContentTransferProfile and storing it in a ServiceContext or passed in OperationOptions object
2. Using the Content object
3. Both: 1 & 2 can be used at a time, but the settings in profile take the precedence

Exceptionn Types:

All DFS exceptions are serializable which means the DFS runtime can marshall & unmarshall the exception stack trace between client/server.

ServiceException: directly extends java.lang.Exception and is the Core DFS exception & can be used liberally to catch all core exceptions