Today we launched a new EMC Documentum developer-oriented community within the EMC Community Network. Front and center is the new developer edition of the EMC Documentum ECM Platform.

So, what does this developer edition include? We believe it includes a lot of goodness for the development of content-enabled applications.

• First of all, free software for developers
• A new one-click installation process for the core of the EMC Documentum ECM Platform
• xDB and new XML components – please visit the just-launched XML Technology Developer Community for more details about our native XML database and other technologies
• Integration between the resulting development environment and online community resources and support mechanisms – think of this as a starting point and means to the ends you want to pursue, not an end in itself

Essentially, we’re trying to provide a low-touch, DIY experience. That being said, by integrating your local installation to an online community, the developer edition enables you to reach out to fellow developers and EMC employees as your pursuit your content management development interests grows. For example, you’ll find a range of white papers, documents and videos, as well as sample code in, for example, Java and C# (.NET). Topical tutorials available online are drawn from our Education Services library.

So, what is the process to obtain the free developer edition? We hope that it’s straightforward.

1. Browse here and login into ECN/EDN
2. Navigate here and complete a short (less than 30 seconds) registration form. Click the “Continue” button to proceed to the download site. (You may need to add ecn_communications@emc.com to your email safe senders list so as not to miss messages from that address (i.e. have them interpreted by Outlook as junk).)
3. Navigate the EMC SubscribeNet links to arrive at the FTP download (or HTTPS-based download, if you prefer). Note that the download is a bit more than 1.73 GB and represents a Zip archive, which means that you should ensure adequate disk space to extract, deploy, etc.
4. Commence your download.

In a follow-up post, I’ll walk you through the installation experience and how to leverage the version of DFS that comes with the developer edition. BTW, if you’re too anxious to dive in and can’t wait for my post, go for it! There is an online getting started guide as well as an online tutorial for building your first application.

Cheers!

Update 5/20/2009: Well, I’m about to take a much needed vacation, and I have yet to follow-up with a walk-thru post. So, I wanted to at least provide some details here as to what this software requires system-wise. System requirements are as follows (and are displayed in the initial installer screen):

• No Microsoft SQL Server or SQL Server Express installed [1]
• No other Documentum software installed [2]
• Microsoft .NET 2.0 or higher [3]
• Browser with Sun JRE 5.0 update 16 or higher [4]
• Minimum of 3 GB RAM (4 GB RAM is recommended)
• 5 GB of free disk space [5]
• Intel x86 CPU
• Operating system–again 32-bit only for this release–is one of the following: Windows XP SP3, Windows Server 2003 SP2 or Windows Server 2003 R2 SP2
• You must be logged in as a member of the Windows Administrators group, but not necessarily as Administrator

Notes:
[1] Be aware that if you already have Visual Studio (e.g. 2005 or 2008) installed on your target machine, you may need to first uninstall the version of SQL Server that may have been installed with the IDE. If you are running Windows SharePoint Services or UDDI on your target (Windows Server 2003) machine, you may also need to see what embedded database is supporting these services before proceeding with this developer edition installation.
[2] Be sure to understand where you may still have Documentum-related configuration files on disk (e.g. dfc.properties, C:\Documentum, etc.).
[3] Microsoft .NET Framework 3.0 is required for WCF-based consumption of DFS endpoints; so, I recommend .NET 3.0, which includes (requires as its foundation) .NET 2.0. .NET 3.5 is also supported by DFS, if you prefer to leverage WCF “v2.”
[4] This is supported by Webtop and DA.
[5] Keep in mind that, as I noted above, the Zip archive download is a bit more than 1.73 GB. The total size of its extracted contents is not that much larger, but you’re also starting to approach 4 GB; so, I recommend that you have 10 GB free disk space in order to complete the installation with room to spare before cleaning up the extracted bits and the original archive to reclaim that 4 GB.

…and, welcome, CMS Watch readers!

Update 7/16/2009: Be sure to run Windows Update after installing DevEd. Typically, you’ll need to apply SQL Server 2005 SP3. Note that if you upgrade a DevEd environment from 6.5 SP1 to 6.5 SP2 (via uninstall-reboot-install) that you should still run Windows Update after your upgrade, and you may need to re-apply SQL Server 2005 SP3.

When upgrading a DevEd environment from 6.5 SP1 to 6.5 SP2, I also recommend that following the uninstall and reboot, that you confirm C:\Documentum and C:\Program Files\Documentum are empty before you proceed to install the newer DevEd.

Finally, if you’re reading this blog but not the installation guide, please note that you should uninstall DevEd via Start | Programs | Documentum | Uninstall, not via Add/Remove Programs under Control Panel.

Laurence Hart was kind enough to pick-up my previous post on content-enabled applications and add his thoughts to the subject, especially concerning the role CMIS can play.

From my first post: Content-enabled applications should facilitate the convergence of content, collaboration, interaction, and process.

I agree with Laurence (aka JaneDoePie) that content is an enabler, not the center. All content-enabled applications “should be shaped to work with and enhance the process the users use to perform their work.”

Laurence offers case management as his favorite, generic content-enabled application in order to further ground the point that success is determined by the combination of content, user experience (interaction, more than just UI, IMHO) and process (e.g. collaborative workflow).

I’m in the middle of reading Subject To Change, and already I’ve found its message highly relevant to the subject of content-enabled applications. For example, the book focuses on experience strategy and how to develop organizational empathy where the target users of your products or services are concerned. Specifically, in the case of case management, the book would argue that you, as case management application architect/designer, need to actually observe case workers in their native setting to appreciate how case management really works (or doesn’t). Go beyond theory and someone else’s analysis. Experience business activity firsthand in order to model reality into your solution.

Recently as part of the Case Management Solution Framework xCelerated Composition Platform (xCP) released for D6.5 SP1, a sample application for grants management was shipped that illustrates how Process Suite components can be used to build case-based, content-enabled applications. You can download this package from Powerlink (authentication required). The easiest way to run this sample application is to install it using the express installer, which will install all the right components (with their compatible versions) and the DAR file. You can also download the express installer from Powerlink (authentication required).Please see the update below for the correct link.

A goal of a solution framework is to make it easier to build content-enabled applications such as those for case management. A solution framework should allow you to invest more time in becoming empathic in order to ship solutions that resonate well with your users and drive more efficient business as a result.

In this response, I wanted to focus on empathy’s role. Separately, I plan to pick up the CMIS angle raised by Laurence. Thanks in advance for joining our discussion online…

Update 5/1/2009: A PM colleague pointed out to me that the link to the “one click” installer that takes one from state “zero” (i.e. Windows but not database) to state “ready for proof of concept” is as follows: https://emc.subscribenet.com/control/dctm/download?element=2193203 (authentication required). Cheers!

If you’re a .NET-based consumer of Enterprise Content Services (e.g. those offered via Documentum Foundation Services) and you experience a Windows Communication Foundation CommunicationException having to do with MaxReceivedMessageSize, you may be interested in the details of this post. This post applies both to direct-to-WSDL consumers and also to consumers that leverage the DFS productivity layer for .NET. Guidance herein has more to do with WCF in general; however, it will be offered in a ECS/DFS context.

Depending on the size of incoming messages from services to your application, you may discover the need to increase the maximum received message size. For example, your application experiences the following exception raised by WCF:

System.ServiceModel.CommunicationException : The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.

An example of exceeding quota could be application requests that result in data package-based responses with a large number of data objects and/or a set of data objects with significant metadata and/or content (e.g. ObjectService.get).

If you implement a direct-to-WSDL consumer of this service using Visual Studio and WCF’s Add Service Reference designer, you will by default introduce a per service binding application configuration file into the overall solution. Therefore, to declaratively increase the maximum received message size, you will edit app.config by focusing on increasing the value of the MaxReceivedMessageSize attribute on the appropriate (named) binding element from the default value in configuration as follows:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="ObjectServicePortBinding" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536" messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true">
          <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
          <security mode="None">
            <transport clientCredentialType="None" proxyCredentialType="None" realm="" />
            <message clientCredentialType="UserName" algorithmSuite="Default" />
          </security>
        </binding>
        . . .
      </basicHttpBinding>
    </bindings>
    . . .
  </system.serviceModel>
  . . .
</configuration>

As in the case of a direct-to-WSDL consumer, a productivity layer-based consumer of the DFS Object service may also need to declaratively increase the value of MaxReceivedMessageSize more compatible with actual runtime requirements.

In the etc\config directory path of your local DFS SDK you should find an example App.config file. Please note that this app.config file is oriented toward productivity layer consumers, not direct-to-WSDL consumers via WCF. That being said, the same binding attributes apply to a solution here, too. The difference is how the bindings are declared in app.config.

The productivity layer oriented declaration names a single binding, DfsDefaultService, to act as the binding for all DFS services, except for DFS runtime services, which have separate, named bindings declared. So, Object service gets its (WCF- based) binding configuration from the “DfsDefaultService” binding…and so does, for example, Query service.

To declaratively increase the maximum received message size in productivity layer oriented app.config, you will most likely edit the MaxReceivedMessageSize attribute on the “DfsDefaultService” binding element from the default value in configuration as follows:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  . . .
  <system.serviceModel>
    <bindings>
      <basicHttpBinding>
        . . .
        <binding name="DfsDefaultService" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferSize="1000000" maxBufferPoolSize="10000000" maxReceivedMessageSize="1000000" messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true">
          <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
          <security mode="None">
            <transport clientCredentialType="None" proxyCredentialType="None" realm="" />
            <message clientCredentialType="UserName" algorithmSuite="Default" />
          </security>
        </binding>
      </basicHttpBinding>
    </bindings>
  </system.serviceModel>
</configuration>

You may notice that the DFS SDK-based app.config binding element attribute values differ from direct-from-WCF defaults (i.e. maxBufferSize–1000000 versus 65536, maxBufferPoolSize–1000000 versus 524288, and maxReceivedMessageSize–1000000 versus 65536). This is simply a change to lessen the likelihood of encountering WCF CommunicationExceptions having to do with MaxReceivedMessageSize values.

One technique you can employ to determine what a reasonable MaxReceivedMessageSize value should be for your application is to set the value of your binding attribute/property to the absolute maximum in order to profile actual runtime message size using a web debugging proxy like Charles or Fiddler. That is, temporarily set MaxReceivedMessageSize to 2147483648 (i.e. Int32.MaxValue), pass your SOAP messages through, for example, Charles via port forwarding, review response message content length values, and reset your default runtime MaxReceivedMessageSize value accordingly.

If you prefer to take a declarative approach to WCF binding configuration for your application but you’re concerned about a user setting the value too low, you can always interrogate values at runtime in order to ensure that they’re sufficient.

For example, a productivity layer-based client could do as follows:

System.Reflection.FieldInfo appConfigInfo = typeof(ContextFactory).GetField("appConfig", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);
System.Reflection.FieldInfo agentServiceBindingInfo = typeof(AppConfig).GetField("m_agentServiceBinding", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);
System.Reflection.FieldInfo contextRegistryServiceBindingInfo = typeof(AppConfig).GetField("m_contextRegistryServiceBinding", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);
System.Reflection.FieldInfo defaultServiceBindingInfo = typeof(AppConfig).GetField("m_defaultServiceBinding", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);
BasicHttpBinding binding = new BasicHttpBinding();
binding.MaxReceivedMessageSize = 0x7fffffffL;
binding.MaxBufferSize = 0x7fffffffL;
agentServiceBindingInfo.SetValue(appConfigInfo.GetValue(contextFactory), binding);
contextRegistryServiceBindingInfo.SetValue(appConfigInfo.GetValue(contextFactory), binding);
defaultServiceBindingInfo.SetValue(appConfigInfo.GetValue(contextFactory), binding);

Of course, in a production app, I’d ensure that there is a log (auditable event) of such programmatic override activity. I might also consider presenting the user with a suggestion, requesting that the software be given the opportunity to auto-correct the value (e.g. updating the effective application configuration file).

Both Pie and Marko have blogged about content-enabled applications, or what Gartner calls CEVAs (content-enabled vertical applications).

As it so happens, I’ll be presenting there will be a session on this subject next month at EMC World 2009.

Based on my research of what folks label a content-enabled application, two things rise to the top: process (surrounding content) and subject matter expertise (individual or group surrounding process), and context. OK, three things.

For example, Forrester defines content-centric applications as “solutions that put the business’ content to use, and add context along the way–to support line-of-business needs.” Example solutions include customer self-service, claims processing, proposal management, contract management, and case management.

Other CEVA vendors argue that content-enabled applications are process-oriented, not content-centric. I tend to prefer this viewpoint. A claim is valueless in itself. Only once is claim is processed is value realized, including taking a future liability off the books.

Content-enabled applications should facilitate the convergence of content, collaboration, interaction, and process.

Before you leverage your content in an application to generate value, ask yourself few questions:

• Who uses the content? Why? How?
• What processes does the content support?
• If I’m not a subject matter expert for this type of content, who can I involve to design a better application experience?
• What processes does it support?
• What context is involved, either centrally or peripherally?

Start with something familiar to just about anyone these days: email (or IM, micro-blogging, etc.). Answer the questions. See how applications, for example, around email have evolved. Think about where current email applications may have untapped potential. Etc.

So, where have all the CEVAs gone (as Marko asks)?

• I think that we in the content management business do ourselves a disservice by overly complicating concepts (e.g. behind TLAs or FLAs). Although fine as a conceptual catalyst, CEVA is self-defeating, IMHO, as a rallying label.
• I agree that CMIS has great potential to increase the availability of content-enabled applications, if for no other reason, because application development that consumes the proposed standard should have a greater return on investment by being applicable to multiple content repositories. (ECM vendor partners are you listening?)
• In the end, it’s the application, not the content or the process or the people. That is, if you’re just adding a document and perhaps a workflow to some code, you may have an app…but it won’t be used. Focus on user experience (i.e. the meaningful, intuitive presentation of content, context and process together).

Back to EMC World…          

I’ll miss interacting with ‘Zilla at the conference. It was at EMC World in 2007 (also held in Orlando, FL) that I first met Mark in person.

If you are able to make the conference and consider yourself to be a “2.0 type,” you may be interested in Len’s advert. Looks like there is even a LinkedIn event established for the conference.

I plan to tweet the conference and otherwise engage with the community. In the meantime, if you plan to attend my session (as presented by others), please feel free to comment (here or ECN) on your thoughts about content-enabled applications and what you’d like discussed or demoed. Thanks in advance.

My colleague and technical writer, Joe Ferrie, just uploaded the second edition of the DFS 6.5 Development Guide to the EMC Developer Network (EDN) here. The information here is applicable to DFS 6.5 and DFS 6.5 SP1.

(I’m still working on this, but at least this content is available via EDN.)

Some highlights of this edition are as follows:

• A new content transfer chapter, with practical information about uploading and downloading content using Base64 and MTOM, as well as using UrlContent to get content from Accelerated Content Services (ACS). Examples are provided for WSDL-based consumers, as well as productivity layer consumers. Unified Client Facilities (UCF) now gets its own chapter.
• Details of Java productivity layer dependencies so that you can more easily understand what JAR files you need on your ClassPath given for your particular development scenario
• A new chapter comparing DFC and DFS, which is expected to be useful for DFC developers who are ramping up with DFS and want to compare the general approach and specific operations
• A revised explanation of the sometimes confusing restrictions on retrieving deep relationships in DataObjects.

Thanks, Joe!

Continuing my collaboration with John Sweeney (or his collaboration with me), today we’ll examine the DFS Schema service and do so in .NET as a direct-to-WSDL consumer. This tutorial builds upon a previous tutorial; so, if you’re not already familiar with it, please read this post and play with this sample. You’ll also need and be familiar with using Documentum Administrator (DA) and Documentum Composer 6.5 SP1.

Thanks to John for doing the legwork in this tutorial and for allowing me to share it all with you here. (Although, I’d really like to see John blog about this directly; he has a lot to share.)

Not only can the DFS Schema service return value-assist values, it also supports dynamic value assistance, including the handling of dependencies (e.g. one attribute value-assist dynamically built based on the value of another attribute).

This tutorial demonstrates how to use the DFS Schema service to perform dynamic value-assist tasks. Knowledge of Documentum Administrator, Documentum Composer 6.5 SP1, DFS 6.5 SP1, Visual Studio 2008 and WSDL-based consumption of DFS with .NET is assumed.

Before we begin, we’ll need to create users, groups and an object type to use as test data.

Step 1 – Create users and groups (to be performed with Documentum Administrator)

1. Create three groups named writers, reviewers and publishers in your repository.

2. Create six users. Name them appropriately, but for this tutorial, they will be referred to as User1–6. Put the users in the new groups, as specified in the following chart:

Group	Members
writers	User1, User2
reviewers	User3, User4
publishers	User5, User6

Step 2 – Create a new object type (to be performed with Documentum Composer 6.5 SP1)

1. Open Documentum Composer and create a new project.

2. Add a new type called kb_document with a supertype of dm_document.

3. Add a new attribute to the type named document_state (as shown in the following image).

4. Expand the document_state attribute and select Value mapping.

5. In the Conditional Assistance section, click New…

6. Add Draft,Review,Publish as values of Fixed List (as shown in the following image) and click OK.

Your Conditional Assistance section should now look like this:

7. Add another new attribute to the type named assigned_to as shown in the following image.

8. Expand the assigned_to attribute and select Value mapping.

9. In the Conditional Assistance section, click New…

10. Add the following query:

select users_names from dm_group where group_name = 'writers'

Set the other fields (as shown in the following image).

The value-assist list will be populated with users who are members of the writers group by default, when document_state does not have a value of Review or Publish.

11. In the Conditional Assistance section, click New…

12. Add the following query:

select users_names from dm_group where group_name = 'reviewers'

Set the other fields (as shown in the following image).

The value in the Expression field will cause the value-assist list to be populated with users who are members of the reviewers group, but only when document_state has a value of "Review."

13. In the Conditional Assistance section, click New…

14. Add the following query:

select users_names from dm_group where group_name = 'publishers'

Set the other fields (as shown in the following image).

The value in the Expression field will cause the value-assist list to be populated with users who are members of the publishers group, but only when document_state has a value of "Publish."

Your Conditional Assistance section should now look like the following:

15. Install the Documentum project to your repository.

Step 3 – Retrieve the value-assist list (using C# and the .NET Framework 3.0 or higher)

Note: the ServiceContextHeader class used in this tutorial comes from this prior sample, as noted above.

The following code snippet will return group members in the ValueAssist Values list. A PropertySet is created for document_state. The value of document_state will alter the dynamic-assist values for the assigned_to property.

// Get a reference to the DFS Schema service
SchemaServicePortClient schemaService =
    new SchemaServicePortClient("SchemaServicePort"); 

StringProperty sp = new StringProperty();
sp.name = "document_state";
// assigned_to will have different dynamic-assist values, 
// depending upon the value set here
sp.Value = "Publish"; // or Review or Draft

// Create a PropertySet for document_state, which assigned_to depends upon
PropertySet ps = new PropertySet();
ps.Properties = new Property[1];
ps.Properties[0] = sp; 

using (OperationContextScope scope =
           new OperationContextScope(schemaService.InnerChannel))
{
    // Add the ServiceContextHeader info to the outgoing request
    OperationContext.Current.OutgoingMessageHeaders.Add(
        new ServiceContextHeader(repositoryName, userName, password)); 

    // Get the values for the assigned_to property
    ValueAssist valueAssist = schemaService.getDynamicAssistValues(
        repositoryName, "DEFAULT", "kb_document", "assigned_to", ps, null); 

    // Display the values
    if (valueAssist != null || valueAssist.Values != null)
    {
        foreach (string s in valueAssist.Values)
            MessageBox.Show(s, "Value Assist Value");
    }
}

The following table shows the expected results:

document_state value	assigned_to values
Draft	User1, User2
Review	User3, User4
Publish	User5, User6

It is worth noting that if you execute SchemaService.getTypeInfo for kb_document, and examine the assigned_to property, you can determine that the property has dependencies. The returned TypeInfo.PropertyInfos[n].Dependencies will contain an entry for document_state. You can check this beforehand as a way of determining if setting one property (document_state) should trigger a refresh of the value list (calling getDynamicAssistValues again). This is very useful for a picklist property page where the values of one list depend on the value of another.

Here endeth the lesson…

Update 2/6/2009: In order for you to spend more time understanding dynamic value assistance with DFS, I’ve uploaded a Visual Studio project to EDN here. Enjoy.

Earlier today I posted to EDN a new sample project that demonstrates consuming DFS web services directly from their WSDL in a Visual Studio 2008 environment. Right up front, I want to credit my colleague John Sweeney, who really should start blogging, with providing the original work contained in this sample. My subsequent contribution was mostly UI/UX-related. Thanks, John!

After downloading and extracting the sample to your local development machine, open the solution in Visual Studio 2008. The default code assumes that you’re running the DFS web services locally (i.e. IP 127.0.0.1 and port 8080). You should, of course, modify the IP address and port to match your particular development environment.

The main intent of this sample is to demonstrate various ways to authenticate via DFS. It’s worth noting that this sample doesn’t cover single sign-on (SSO) support in DFS, nor does it cover WS-Security header-based authentication. Good demos to be certain…

As the user interface (UI) above tries to clearly state upfront, content repository (aka Docbase) name cannot be null or empty, regardless of authentication approach. Given authentication via ServiceContext header, user name and password cannot be null or empty. Given authentication via ContextRegistry runtime service, when token is null or empty, user name and password cannot be null or empty, and when user name and password are both null or empty, token cannot be null or empty.

One thing that is still a bit obscure in the current UI is that authentication via DFS can be a two-step or one-step process, depending on the situation. If you choose "Via ContextRegistry…" and a Context Registry token isn’t provided to DFS, two runtime service invocations will be made. In all other cases, there is one service invocation.

Assuming that your connection details are valid given your authentication approach, this sample will (a) retrieve a repository list, (b) retrieve cabinets, and (c) retrieve content (i.e. transfer MenuItemTemplate.ini to your desktop).

A previous direct-to-WSDL DFS consumer sample I posted, targeted .NET 3.0 and WCF "v1." This sample targets .NET 3.5 and WCF "v2" instead, along with support for Silverlight 2. It accomplishes this change via LINQ to XML (e.g. leverages System.Xml.Linq.XDocument instead of System.Xml.XmlDocument).

If you need to target this sample at .NET 3.0, in addition to adjusting the project build properties, removing the project reference to the System.Xml.Linq.dll assembly, and removing the System.Xml.Linq namespace declaration in ServiceContextHeader.cs, you’ll need to change the relevant code within OnWriteHeaderContents. For example:

  XDocument doc = null;
  using (StringWriter sw = new StringWriter(CultureInfo.CurrentCulture))
  {
      XmlSerializer xs = new XmlSerializer(typeof(ServiceContext));
      xs.Serialize(sw, serviceContext);
      doc = XDocument.Load(new StringReader(sw.ToString()));
  }

would become:

  XmlDocument doc = null;
  using (StringWriter sw = new StringWriter(CultureInfo.CurrentCulture))
  {
      XmlSerializer xs = new XmlSerializer(typeof(ServiceContext));
      xs.Serialize(sw, serviceContext);
      doc = XmlDocument.LoadXml(new StringReader(sw.ToString()));
  }

etc.

Although, it’s not currently employed in the sample, there is also code to add a ContentTransferProfile to the ServiceContext header.

As always, consult the DFS Developer Guide for complete details on everything that may be passed in the ServiceContext header.

I do expect that this sample will be incorporated into the DFS SDK and DFS technical publications content; however, I wanted to get this into your hands sooner rather than later. Cheers…

My friend and colleague Paul Warren recently posted content that talks about the creation of Enterprise Content Services (like those in DFS) in the context of an integrated development environment (IDE):

• Creating DFS services using Documentum Composer
• Creating DFS services using the Eclipse IDE for Java EE Developers

WTP support is something the Composer team is hard at work on, and this will change the nature of DFS tooling, too.

Essentially we’re working together to promote more standard developer workflow and development lifecycle by embracing tools developers already use to build services. While WTP assumes Eclipse and Composer is indeed powered by Eclipse, that doesn’t mean that Eclipse is the only IDE for Enterprise Content Service development. We’re working on changing the nature of the DFS SDK, too, to better emphasize, for example, how to use Visual Studio and Windows Communication Foundation directly to build service consumers.

What tools, including IDEs, do you use to build Enterprise Content Services and ECS-based solutions?

You may have seen this week’s press release (PR) concerning the launch of the EMC Documentum 6.5 platform. Given that this blog is referenced in the PR’s sidebar, I thought it would be appropriate for me to offer my perspective on this release.

When the Documentum Foundation Services (DFS) team first embarked on its mission to better service-orient the Documentum platform, I suggested that, over time, the very focus of our daily work–services and common service infrastructure–would become less “talked about.” I suggested that services alone deliver less value than services in the context of processes and processes in the context of solutions.

So, ultimately EMC has to deliver relevant, robust solutions to market much more than just web services. This is exactly the focus of the EMC PR–and each solution discussed is built using Enterprise Content Services (ECS).

Take CenterStage (aka “Magellan”), Media WorkSpace, and My Documentum as D6.5 solution examples. One user experience differs fairly significantly from another user experience (e.g. CenterStage Essentials versus Media WorkSpace). Looking under the covers, one implementation (i.e. presentation layer and application behavior) also differs from another implementation. However, common business logic is provided to each solution via a consistent set of services (e.g. Object, Query, Schema, Access Control, etc.).

Each solution is worth its own coverage, but I will allow solution teams to accomplish this (e.g. content like this).

Instead, I’d like to focus on the progress achieved in the D6.5 release where services and common service infrastructure are concerned:

1. The number of out-the-box Enterprise Content Services (ECS) in DFS has more than doubled in 6.5, from the six to 13. The total number of ECS across D6.5 has grown nearly fourfold, from six to 23.

• Six original services with DFS 6.0: Object (enhanced in 6SP1 to support external objects; enhanced again in 6.5 to support aspects), Query, Schema, Search (enhanced functionality in 6.5 for clusters), Version Control (enhanced in 6.5 to support aspects), Workflow
• Seven new services with DFS 6.5: Access Control, Analytics, Comment, Lifecycle, Query Store, Task Management (WS-HumanTask), Virtual Document
• Plus 10 additional, new services beyond (i.e. not packaged with) DFS 6.5:
  Content Delivery, Electronic Signature, ERP Integration (SAP), Federated Proxy, Formal Record, Physical Records Library, (Records Management) Policy, (Content Transformation) Profile, Retention Markup, (Content) Transformation

Bottom line #1: there are many more services with D6.5 from which to compose content-centric applications.

2. Common service infrastructure has been significantly enhanced at the same time. For example:

• Contract first (or WSDL first) development of services is supported in addition to code first development.
• Design time discovery of services is supported via a new service catalog or an existing UDDI v2 compliant service registry. Classification of service occurs via the concept of catalogs and categories, by default.
• Modularity has increased at the binary (e.g. JAR file) level to promote better composition (i.e. only take what you need).
• Single sign-on (SSO) support has been improved.

Bottom line #2: you have more options now to provide, discover and consume services.

Certainly there is a lot more to each bullet point above, and I plan to drill down into several points in future posts.

…and I didn’t even use the term “Web 2.0″…until now.

In our previous conversation, we left with a missing header to resolve. This post will resolve this issue and wrap-up the sample DFS Object service consumer based on direct proxy via Visual Studio/WCF.

First, we need to introduce a new internal class, ServiceContextHeader, as follows:

internal class ServiceContextHeader : MessageHeader
{
    private string repositoryName = null;
    private string userName = null;
    private string password = null;

    public ServiceContextHeader(string repositoryName, string userName, string password)
    {
        this.repositoryName = repositoryName;
        this.userName = userName;
        this.password = password;
    }

    protected override void OnWriteHeaderContents(XmlDictionaryWriter writer, MessageVersion messageVersion)
    {
        // Please note that there can be more to a ServiceContext instance than
        // what this intentionally simple example specifies. This message header
        // implementation doesn't cover all aspects of ServiceContext.

        // In order to proxy ServiceContext, you must first establish a service
        // reference to the DFS runtime Context Registry service.
        ServiceContext serviceContext = new ServiceContext();
        RepositoryIdentity repositoryIdentity = new RepositoryIdentity();
        repositoryIdentity.repositoryName = repositoryName;
        repositoryIdentity.userName = userName;
        repositoryIdentity.password = password;
        serviceContext.Identities = new Identity[1];
        serviceContext.Identities[0] = repositoryIdentity;

        // We haven't communicated with the DFS runtime Context Registry service;
        // so we don't have a token to "write," nor are we specifiying locale in 
        // our ServiceContext instance.

        StringWriter sw = new StringWriter();
        XmlSerializer xs = new XmlSerializer(typeof(ServiceContext));
        xs.Serialize(sw, serviceContext);
        String xml = sw.ToString();
        sw.Close();

        XmlDocument document = new XmlDocument();
        document.LoadXml(xml);

        foreach (XmlNode node in document.LastChild.ChildNodes)
        {
            XmlElement element = (XmlElement)node;
            XmlReader reader = new XmlNodeReader(element);
            writer.WriteNode(reader, true);
        }
    }

    public override string Name
    {
        get { return "ServiceContext"; }
    }

    public override string Namespace
    {
        get { return "http://context.core.datamodel.fs.documentum.emc.com/"; }
    }
}

Next, we need to “inject” this class into our application’s request message processing. So, we need wrap our original call to ObjectService.get() as follows:

DataPackage dataPackage = null;
using (OperationContextScope scope = new OperationContextScope(objectService.InnerChannel))
{
    OperationContext.Current.OutgoingMessageHeaders.Add(new ServiceContextHeader(repositoryName, userName, password));

    dataPackage = objectService.get(objectIdentitySet, operationOptions);
}

In a less contrived context (i.e. your production application), there are other approaches to be considered, and I recommend that you at least read Nick Allen’s post on the subject.

Now, let’s re-run the modified example and examine the SOAP request message:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <s:Header>
        <ServiceContext xmlns="http://context.core.datamodel.fs.documentum.emc.com/">
            <Identities xsi:type="RepositoryIdentity" userName="_USER_" password="_PWD_" repositoryName="_DOCBASE_" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
        </ServiceContext>
    </s:Header>
    <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <get xmlns="http://core.services.fs.documentum.emc.com/">
            <forObjects isInternal="false" xmlns="">
                <Identities repositoryName="_DOCBASE_" valueType="OBJECT_ID" xmlns="http://core.datamodel.fs.documentum.emc.com/">
                    <ObjectId id="09003023800037c6"/>
                </Identities>
            </forObjects>
            <options xmlns="">
                <Properties isInternal="false" xmlns="http://core.datamodel.fs.documentum.emc.com/"/>
                <Profiles xsi:type="q1:PropertyProfile" isProcessIncludedUnknown="false" filterMode="SPECIFIED_BY_INCLUDE" xmlns="http://core.datamodel.fs.documentum.emc.com/" xmlns:q1="http://profiles.core.datamodel.fs.documentum.emc.com/">
                    <q1:IncludeProperties>object_name</q1:IncludeProperties>
                </Profiles>
            </options>
        </get>
    </s:Body>
</s:Envelope>

Much better! And, as important, the dialog reveals the same object name as the same example based on the DFS SDK .NET assemblies.

You can download the Visual Studio 2008-based solution for today’s (fully resolved) sample here.

I hope that this series of posts on how the EMC Documentum platform, and especially DFS, supports Microsoft-oriented developers has been helpful.

Cheers…

Update 8/9/2008: There is actually one additional change that is required to properly retrieve the object’s name for presentation on the form. In the previous post, after calling ObjectService.get() and finding the “object_name” property, our form label was set as follows:

    lblObjName.Text = property.ToString();

However, this needs to change in order to avoid prefacing the string value with ToString() content:

    StringProperty s = property as StringProperty;
    lblObjName.Text = s.Value;

This sample has been updated to include this change. Kudos to John Sweeney for the assist.

OK, back to the Olympics…

Rather than leverage the DFS SDK-based .NET assemblies to consume DFS services, some may prefer to leverage Visual Studio’s ability to proxy WSDL/XSD directly and choose instead to involve the Windows Communication Foundation (WCF) designer via Add Service Reference… In this post, I will discuss just such a sample application.

As in the previous example, we’ll build the same Windows Forms application to accomplish the same task (i.e. object name retrieval given object id); however we’ll ignore the .NET productivity layer and proxy the Object service contract directly using Visual Studio and WCF.

After launching Visual Studio, choosing File | New | Project… and creating a new Windows Forms Application project called ObjectServiceConsumer, go to the Solution Explorer, select the project node, right-click and choose Add Service Reference…

Enter the address for the DFS Object service instance to proxy (e.g. the same instance used in the previous example’s browser-based accessibility test). Click Go, and you should see something similar to the dialog captured above. Set the namespace for this reference and choose OK.

Return back to Visual Studio, double-click Form1.cs, after building the same dialog as in the previous example, double-click on the Retrieve button. This will tell Visual Studio to transition from (Windows Forms) designer mode to code editing mode.

Implement your button click handler as follows:

string repositoryName = txtbxRepoName.Text;
string userName = txtbxUserName.Text;
string password = txtbxPwd.Text;
string objId = txtbxObjId.Text; // e.g. a document id of 09123456789abcde

try
{
    ObjectId objectId = new ObjectId();
    objectId.id = objId;
    ObjectIdentity objectIdentity = new ObjectIdentity();
    objectIdentity.Item = objectId;
    objectIdentity.repositoryName = repositoryName;
    ObjectIdentitySet objectIdentitySet = new ObjectIdentitySet();
    objectIdentitySet.Identities = new ObjectIdentity[1];
    objectIdentitySet.Identities[0] = objectIdentity;

    PropertyProfile propertyProfile = new PropertyProfile();
    propertyProfile.filterMode = PropertyFilterMode.SPECIFIED_BY_INCLUDE;
    string[] includeProperties = {"object_name"};
    propertyProfile.IncludeProperties = includeProperties;
    OperationOptions operationOptions = new OperationOptions();
    operationOptions.Profiles = new Profile[1];
    operationOptions.Profiles[0] = propertyProfile;

    DataPackage dataPackage = objectService.get(objectIdentitySet, operationOptions);

    Property[] properties = dataPackage.DataObjects[0].Properties.Properties;
    foreach (Property property in properties)
    {
        if (property.name.Equals("object_name"))
        {
            lblObjName.Text = property.ToString();
        }
    }

    Console.WriteLine("Successfully retrieved object name for object id" + "'" + objId + "': " + lblObjName.Text);
}
catch (Exception ex)
{
    lblObjName.Text = "<error>";
    Console.WriteLine(ex.StackTrace);
    Console.WriteLine("Failed to retrieve object name with exception " + ex.Message);
}
finally
{
    Console.WriteLine("Your cleanup logic goes here.");
}

A few points concerning the above code:

• There is a private field on the Form class, objectService, that is of type ObjectServicePortClient (i.e. from the WCF-generated proxy code) and is set to null initially.
• In the Form class constructor, after the standard Windows Forms InitializeComponent(), objectService is set as follows: new ObjectServicePortClient(“ObjectServicePort”);
• “ObjectServicePort” is a named binding in the WCF-generated proxy code (i.e. declared within app.config).
• As in the previous example, I’m using a pre-release version of DFS 6.5 for this example, but I’m not using anything that isn’t available in DFS 6.0 SP1–this is a very simple example by design.
• You should notice some cosmetic differences between the code above and the code here (e.g. more verbose, fewer conveniences, etc.).

You should now be able to build your application and run it. When you enter a valid object id for the specified repository connection, you should see the object name replace “<tbd>” on the dialog.

But, you don’t. Why?

Well, first of all, if you are running your application server with a console window for output message capture, you likely saw the following message:

. . . com.emc.documentum.fs.rt.SerializableException: Authorization failed, could not find identities in service context with token “temporary/127
.0.0.1-1216079837407–1167916486618885387″
        at com.emc.documentum.fs.services.core.ObjectServiceWebService.get(ObjectServiceWebService.java:268) . . .

Looking at the code above, it’s hopefully clear that the variables userName and password aren’t employed. (If you’re using the JetBrains ReSharper add-in for Visual Studio, the IDE (plugin) actually visually indicates this condition.)

So, let’s do some detective work.

Using a web debugging proxy (e.g. Charles), re-run the above code (i.e. with port forwarding in place). After valid data entry and clicking the Retrieve button, you should see an entry in your web debugging proxy session. Examine the SOAP request message (i.e. “pretty printed” for readability’s sake):

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <get xmlns="http://core.services.fs.documentum.emc.com/">
            <forObjects isInternal="false" xmlns="">
                <Identities repositoryName="_DOCBASE_" xmlns="http://core.datamodel.fs.documentum.emc.com/">
                    <ObjectId id="09003023800024ec"/>
                </Identities>
            </forObjects>
            <options xmlns="">
                <Profiles xsi:type="q1:PropertyProfile" isProcessIncludedUnknown="false" xmlns="http://core.datamodel.fs.documentum.emc.com/" xmlns:q1="http://profiles.core.datamodel.fs.documentum.emc.com/">
                    <q1:IncludeProperties>object_name</q1:IncludeProperties>
                </Profiles>
            </options>
        </get>
    </s:Body>
</s:Envelope>

Next, go back to the previous example, and re-run it to capture its SOAP request message. Before you hit Run, though, comment out the following line of code:

context = contextFactory.Register(context);

(We’ll talk more about this in a future post.)

The DFS SDK .NET assemblies-based application issues the following SOAP request message:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <s:Header>
        <ServiceContext token="temporary/127.0.0.1-1216195928765-692634301" xmlns="http://context.core.datamodel.fs.documentum.emc.com/">
            <Identities xsi:type="RepositoryIdentity" userName="_USER_" password="_PWD_" repositoryName="_DOCBASE_" domain="" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
            <RuntimeProperties/>
        </ServiceContext>
    </s:Header>
    <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <get xmlns="http://core.services.fs.documentum.emc.com/">
            <forObjects isInternal="false" xmlns="">
                <Identities repositoryName="_DOCBASE_" valueType="OBJECT_ID" xmlns="http://core.datamodel.fs.documentum.emc.com/">
                    <ObjectId id="09003023800037c6"/>
                </Identities>
            </forObjects>
            <options xmlns="">
                <Properties xmlns="http://core.datamodel.fs.documentum.emc.com/"/>
                <Profiles xsi:type="q1:PropertyProfile" filterMode="SPECIFIED_BY_INCLUDE" xmlns="http://core.datamodel.fs.documentum.emc.com/" xmlns:q1="http://profiles.core.datamodel.fs.documentum.emc.com/">
                    <q1:IncludeProperties>object_name</q1:IncludeProperties>
                </Profiles>
            </options>
        </get>
    </s:Body>
</s:Envelope>

Yep, there’s definitely a missing header in today’s sample, as coded above.

It’s also worth noting a few things before continuing:

• The code above requires SSL to avoid cleartext data being sent over the wire. Of course, SSL–and replacing http://… with https://…–only provides transport-level security that is point-to-point in nature (i.e. compared with message-level security that is end-to-end in nature).
• valueType=”OBJECT_ID” – this is missing on the <Identities> element in today’s example but is present in the previous example
• <Properties xmlns=”http://core.datamodel.fs.documentum.emc.com/”/> – this is missing in today’s example but is present in the previous example
• filterMode=”SPECIFIED_BY_INCLUDE” – this is missing on the <Profiles> element in today’s example but is present in the previous example
• isProcessIncludedUnknown=”false” – this is present in today’s example but is missing in the previous example

Before we solve the case of the missing header, let’s resolve the differences just listed:

...
ObjectIdentity objectIdentity = new ObjectIdentity();
objectIdentity.valueType = ObjectIdentityType.OBJECT_ID; //FIX
objectIdentity.valueTypeSpecified = true; //FIX
...
propertyProfile.filterMode = PropertyFilterMode.SPECIFIED_BY_INCLUDE;
propertyProfile.filterModeSpecified = true; //FIX
...
OperationOptions operationOptions = new OperationOptions();
...
operationOptions.Properties = new PropertySet(); //FIX
...

As for the isProcessIncludedUnknown-based difference aforementioned, a quick read of the reference-level documentation for PropertyProfile.setProcessIncludedUnknown() is helpful: “If false, ignore any property in the includeProperties list that is not a property of the repository type. If true, throw an exception if such a property is specified in the includeProperties list. Default value is false.” That is, the WCF-generated proxy makes this default explicity in its SOAP messages; so, although the two XML messages have this difference, they are functionally equivalent.

Next: Leveraging WCF extensibility to add the missing header that the DFS Object service expects…

In a previous post, I introduced web service support in the EMC Documentum platform for the Microsoft-oriented developer. (BTW, sorry for the time lapse since that post to this one–busy getting an important set of products ready for on-time release. ) In this post, I will focus on such support as provided with DFS via the .NET assemblies (aka productivity layer) within the DFS SDK.

Let’s build a simple Windows Forms application using Microsoft Visual Studio 2008. The purpose of this application will be to retrieve the object name from a piece of content in a Documentum repository associated with a particular object id:

After launching Visual Studio, choosing File | New | Project… and creating a new Windows Forms Application project called ObjectServiceConsumer_PL, go to the Solution Explorer, select the References node under the project, right-click and choose Add Reference…

Navigate to your DFS SDK installation and select the set of .NET assemblies that support the DFS Object service. For example, I tend to install the SDK directly under my C: drive; so, I navigated to C:\emc-dfs-sdk-6.5\lib\dotnet:

(Yes, I’m using a pre-release version of DFS 6.5 for this example, but I’m not using anything that isn’t available in DFS 6.0 SP1–this is a very simple example by design.)

The result under the References node should be as follows:

If you’re already developing with .NET 3.5, you may notice that a couple of .NET 3.5 assemblies are missing in the above view. That’s because I decided to target .NET 3.0 for this example since I don’t require anything more from Windows Communication Foundation since its first release (i.e. DFS supports WCF “v1″ in .NET 3.0).

At this point, verify that you will be able to access an instance of the DFS Object service from your application. That is, deploy emc-dfs.ear file via the standalone DFS installer or with the Content Server installer. Launch your browser of choice and retrieve DFS Object service WSDL (e.g. http://localhost:8080/services/core/ObjectService?wsdl). You should see the service contract in your browser.

Return back to Visual Studio, double-click Form1.cs, after building the dialog shown above, double-click on the Retrieve button. This will tell Visual Studio to transition from (Windows Forms) designer mode to code editing mode.

Implement your button click handler as follows:

string repositoryName = txtbxRepoName.Text;
string userName = txtbxUserName.Text;
string password = txtbxPwd.Text;
string objId = txtbxObjId.Text; // e.g. a document id of 09123456789abcde

try
{
    ContextFactory contextFactory = ContextFactory.Instance;
    IServiceContext context = contextFactory.NewContext();
    RepositoryIdentity repoId = new RepositoryIdentity(repositoryName,
                                                       userName,
                                                       password,
                                                       "");
    context.AddIdentity(repoId);

    context = contextFactory.Register(context); // Module and ContextRoot from app.config
    ServiceFactory serviceFactory = ServiceFactory.Instance;

    IObjectService objectService =
        serviceFactory.GetRemoteService<IObjectService>(context); // Module and ContextRoot from app.config

    ObjectId objectId = new ObjectId(objId);
    ObjectIdentity objectIdentity = new ObjectIdentity(objectId, repositoryName);
    ObjectIdentitySet objectIdentitySet = new ObjectIdentitySet(objectIdentity);

    PropertyProfile propertyProfile = new PropertyProfile();
    propertyProfile.FilterMode = PropertyFilterMode.SPECIFIED_BY_INCLUDE;
    propertyProfile.IncludeProperties.Add("object_name");

    OperationOptions operationOptions = new OperationOptions();
    operationOptions.Profiles.Add(propertyProfile);

    DataPackage dataPackage = objectService.Get(objectIdentitySet, operationOptions);

    List<Property> properties = dataPackage.DataObjects[0].Properties.Properties;

    if (properties != null)
    {
        properties.ForEach(delegate(Property property)
                               {
                                   if (property.Name.Equals("object_name"))
                                   {
                                       lblObjName.Text = property.ToString();
                                   }
                               });
    }

    Console.WriteLine("Successfully retrieved object name for object id" + "'" + objId + "': " + lblObjName.Text);
}
catch (Exception ex)
{
    lblObjName.Text = "<error>";
    Console.WriteLine(ex.StackTrace);
    Console.WriteLine("Failed to retrieve object name with exception " + ex.Message);
}
finally
{
    Console.WriteLine("Your cleanup logic goes here.");
}

As noted above in code comments, you should add an Application Configuration File item to your project. After doing so, open the new app.config file in Visual Studio, select its contents and paste (overwrite) them with the contents copied from the sample App.config file in the DFS SDK (i.e. C:\emc-dfs-sdk-6.5\etc\config\App.config). Be sure to modify data relative to your running DFS Object service instance (e.g. ModuleInfo element attributes like port).

You should now be able to build your application and run it. When you enter a valid object id for the specified repository connection, you should see the object name replace “<tbd>” on the dialog.

Obviously this is a trivial sample. However, as I mentioned this is be design, since what I want to do next is contrast this sample with the same goal implemented without DFS SDK .NET assemblies (i.e. using just Visual Studio, its WCF designer and DFS WSDL/XSD content).

You can download the Visual Studio 2008-based solution for today’s sample here.

Next: Using DFS WSDL/XSD (sans DFS SDK .NET assemblies) from Visual Studio…

Shortly after the Documentum 5.2.5 release, customer interest in web services piqued in conjunction with Documentum’s investment in services via service-based business objects. SBOs, as they’re typically referred to, are supported in the Business Object Framework (BOF), which is the codified customization framework for DFC.

So, in order to preserve customer investment in SBOs, the Web Service Framework (WSF) was first released as part of the 5.3 platform release.

Not every SBO is designed to be projected as a web service, though. So, best practice documentation was published to the developer network, which for the most part just captures common sense. (I used to call these web service SBOs “WSBOs.”)

However, service-orientation at the time of D5.3 development was noticeably different than at the time of D6 development. There needed to be a way to target a broader base of existing service implementations (e.g. POJOs) into the realm of Enterprise Content Services.

Rather than controlling web services by insisting on a DFC/BOF (SBO) investment, it was clear that EMC Documentum needed to participate with broader business systems and processes. So, targeting plain old Java objects became a requirement, while also supporting DFC/BOF-based implementations for existing customers.

Rather than forcing service chains to align on content transfer approach, it was clear that EMC Documentum needed to support content transfer choice, empowering each link (service) in the chain to process content on its terms (e.g. as a file or as a stream).

At the same time, the 6.0 platform release provided additional facilities concerning distributed content. So, any new service-oriented offering from EMC Documentum needed to integrate with these facilities and increase their adoption via ease-of-use (integration).

Documentum Foundation Services (DFS) was first released as part of the 6.0 platform release and was designed to meet these, and several other, objectives.

Which brings us back to the .NET-oriented developer. How does DFS service these individuals?

• DFS provides an optional productivity layer
• DFS is based on open standards that Microsoft Visual Studio also supports (conclusion)

More on each approach, next…

In early 2002 Microsoft released .NET 1.0, and it was quite clear that .NET would quickly supplant COM as the mainstream runtime for the Microsoft platform.

Fortunately, .NET provided good (bi-directional) interop with COM (e.g. callable wrappers and interop assemblies). Furthermore, software publishers (ISVs) could produce primary interop assemblies (PIAs) to add functional, deployment and administrative value above that produced by simply pointing Visual Studio at a type library.

So, based on customer requirements and demand, the DFC PIA was born and was first released with DFC 5.2.5.

Beyond just producing a strong-named assembly using a Documentum private key, DFC PIA included additional performance tuning as well as some convenience features like advertising deprecated APIs, IntelliSense support in Visual Studio via robust XML documentation, and HTML Help content with example usage. By virtue of being a strong-named assembly, subsequent versions of the DFC PIA shipped with a publisher policy file and assembly, allowing customers to redirect their DFC PIA 5.2.5 consumers to a newer version of the PIA.

Both Documentum Desktop and Documentum Application Builder announced end-of-life plans around D5.3; so the internal need for DJCB was coming to a close. This opportunity was leveraged to reconsider current platform support for .NET developers and what would be needed in the future (e.g. web services). Several data points arose that suggested the need to reset interoperability as follows:

• Java and .NET are both managed language platforms. A key management facility in both is known as garbage collection. A garbage collector (GC) is responsible for reclaiming resources based on object reference state and other criteria. The Java GC and the .NET GC don’t recognize each other; yet both GC’s can be resident in the same process space. Given this situation, the potential for resource exhaustion due to improper object reference coding arises. In .NET, all COM objects including objects implementing COM interfaces must be released using Marshal.ReleaseComObject or Marshal.FinalReleaseComObject; otherwise, the underlying resources cannot be reclaimed by a GC.
  • Marshal.ReleaseComObject/Marshal.FinalReleaseComObject is low-level “plumbing” code, and as such is typically not the primary domain concern of the business developer.
  • Recall that the DFC .NET interface is the projection of a DFC COM interface, which is, in turn, a projection of a DFC Java interface. The implementation of this interface projection is shared amongst a Java archive (JAR file), a Java-COM bridge DLL and an in-process assembly (PIA). All of this, again, is low-level plumbing that the business developer would rather not be burdened with; however, appropriate Marshal.ReleaseComObject/Marshal.FinalReleaseComObject calls have been delegated unto them.
• DJCB (and therefore DFC PIA) is about core DFC, not about DFC customizations via BOF (i.e. type-based or service-based business objects–TBOs or SBOs). So, to get similar .NET interop for a custom business object, you would have to re-apply Java-COM bridge technology to that API–assuming that it’s well-formed for .NET interop–and then produce a PIA for the custom business object using the bridge’s COM type library–all low-level plumbing.
  • “Java-COM bridge + PIA” doesn’t scale as well as web services in terms of integration cost. DFS supports web services natively and was designed from the very beginning with SOA in mind.
• COM has a hard limit of no more than 255 methods per interface. Most object-oriented systems may not encounter this constraint; however, DFC does with respect to sysobject-derived interfaces. That is, DFC 5.3 was OK; however, DFC 6.0 and thereafter surpassed this upper limit. So DJCB literally cannot be revised to accommodate the DFC 6.0 interface, again due to COM-based limitations. Since DJCB is so-constrained, DFC PIA is also limited.
  • Arguably, this highlights the value of Aspects in DFC/BOF.
  • This also highlights why DFS is absolutely not a web service projection of the DFC API. Rather DFS is a coarser-grained API that is less chatty and less overwhelming to understand (e.g. where total number of API methods is concerned).
  • In other words, DFC 6.0 was not developed with DJCB/PIA exposure, unlike DFC 5.3 and 5.3 service packs.
• There are aspects of the DFC Java API that are not interoperable. Perhaps the most requested feature request concerns byte stream support. That is, DFC specifies ByteArrayInputStream, but .NET doesn’t recognize this Java type.
  • DFS supports byte streaming use cases as follows:
    1. The application invokes DFS from the middle tier, gets a byte array–DFS doesn’t write to disk–which is then returned by the application to the end user.
    2. The application invokes DFS from the middle tier, gets a URL which is then which is then passed by the application to the end user. The end user can stream the content using the URL.
    3. The application invokes DFS from the middle tier. UCF client is deployed on the end user box. Content is streamed by UCF from the CS machine directly to the end user.
  • Also ByteArrayInputStream can be impractical even for Java-based solutions, since the type puts all data in memory (e.g. large file transfer concerns).

Next: Data access (ADO.NET)…

Prior to DFS, the primary solution-building, business logic-focused EMC Documentum platform API was Documentum Foundation Classes (DFC).

When I joined Documentum (now EMC) over ten years ago, DFC was under development as part of the significant 4i release (aka “Project Piper”). Back then Microsoft shipped a leading JVM and had one of the best IDEs for Java in Visual J++, according some of my then hardcore Java programming friends. The MSJVM intrinsically supported–among other “features” like delegates that led to the Java cold war (lawsuit) between Sun and Microsoft–interoperability with Microsoft’s major runtime play at that time called COM.

The aforementioned cold war led to Microsoft dropping development and support of MSJVM (and led to .NET, J# and JLCA), ending its Java support with the then-outdated 1.1.4 release from Sun. This meant that in order to support COM-based interop from Java you had to either build or buy. And a build-versus-buy decision was especially relevant to Documentum at the time given that the most widely used client/application was Desktop (aka Desktop Client, or just DTC–later called Desktop Development Kit), not to mention the MFC-based Developer Studio (later called Documentum Application Builder (DAB), which is now replaced by Composer). We opted for build, since there was no buy option available then that met our requirements, and the Documentum Java-COM Bridge (DJCB) was born and was first released with DFC 5.0.

DJCB enabled us to project DFC Java types as DFC COM types via COM type libraries and IDL. It also enabled Documentum to adopt newer JVM technology (e.g. Java 2 collections, Sun Hotspot JVM performance improvements, etc.). Furthermore, in the strong Documentum tradition of supporting existing IT infrastructure such as operating systems, relational databases and application servers, whose JVM was running became less of an issue (e.g. Sun, IBM, BEA (now Oracle), etc.).

Here is perhaps an interesting portion of the original DJCB function specification dated 9/5/2001, which I authored with Victor Spivak, describing why DJCB was pursued:

Why does Documentum need any bridge?

Documentum Foundation Classes, or DFC as it is more commonly referenced, is Documentum’s platform-independent business logic layer. A key benefit of the Java language is platform independence, or “Write Once, Run Anywhere” (i.e. anywhere that supports the Java platform); therefore, DFC is implemented in Java.

Documentum is a platform provider, and as a platform company it supports the two dominant platforms of today: Windows and Java. A significant amount of Windows development is COM-based, and from a developer’s point of view, Documentum APIs on Windows are COM interface methods, etc.

When the DFC first decided to use Java as its implementation language, the Java platform was alive and well on Windows. In fact, Microsoft provided a fairly transparent bridge between COM and Java through its Java Virtual Machine (JVM) very soon after Java’s formal introduction to the general software development community. This bridge benefited Documentum a great deal; through a single implementation with minimal wrapping, Documentum could provide a business logic layer (DFC) that was consumable on both Windows and Java environments. … 

Why does Documentum need a new bridge?

The settlement of the lawsuit between Sun and Microsoft has effectively frozen Microsoft’s use of Java in Windows at version 1.1.4. For its own use, Sun has already completed its end-of-life (EOL) of 1.1.4–only 1.1.8 remains available and supported in the Java 1.1 platform. Since Microsoft’s Java-COM bridge is built into its JVM, this bridge is also frozen at version 1.1.4. However, Java hasn’t stopped growing or maturing.

The Java platform tripled in size between Java 1.1 and Java 1.2, and the Java 2 platform  has continued to grow beyond version 1.2. The current release is 1.3 and version 1.4 is available today as a beta product. …

Clearly the Java platform of today is significantly different than version 1.1.4 of the Java platform.

Developers of a platform adopt the models of that platform. Java 2 offers models that are unsupported by DFC today because DFC is constrained by obsolete bridge technology. That is, Java developers using DFC may be forced to use proprietary workarounds to standard solutions that Java 2 provides (e.g. Java Collection Framework).

Java developers expect to leverage and interact with the facilities of the Java 2 platform (i.e. version 1.2 or later). Their encounter with the current DFC programming model may less than desirable as long as DFC is constrained to a much older Java platform and development model. Critical aspects of the Java platform such as security, extensibility, collections, serialization, multithreading, have undergone significant change. DFC will benefit from these changes but it must first be able to depend on more current Java environments–something it cannot do under the current Microsoft–provided bridge.

It’s not necessary to maintain a lowest common denominator approach any longer in DFC. A new bridge can and should be developed that enables DFC to leverage the Java 2 platform for its own benefit and for the benefit of all Java developers who rely on Documentum as part of their business solutions. Providing more mature facilities in DFC to Java developers should not come at the expense of COM developers [i.e. C++/"Classic VB" developers that use COM to achieve binary compatibility]. Existing DFC APIs continue to appear as COM objects with DJCB as they have with the Microsoft bridge. …

Looking at the need for a new bridge another way, Documentum’s customers as well as Documentum itself suffers from the Sun-Microsoft lawsuit and settlement. Documentum cannot afford to drop its support of COM in the business logic layer. Documentum can also not afford to hand-tie Java business logic to an obsolete version of Java. Developers approaching the Documentum platform from a Java perspective expect our Java APIs to be Java 2-like. DJCB is about healing the wounds caused by Sun and Microsoft to our developer base… DJCB maintains a COM developer’s expectations of DFC leverage, while enabling DFC to meet the expectations of Java developers leverage Documentum’s business logic layer implemented in Java.

Next: DFC PIA…

Executive Summary

Since this is a longer post (actually a set of posts), allow me to summarize the main points from the get-go as follows:

• DFC Primary Interop Assembly (PIA) and the underlying Documentum Java-COM Bridge (DJCB) support the DFC 5.3 API. That is, interface changes in DFC 6.x are not reflected in the DJCB and therefore are also not reflected in the PIA.
• DFC PIA and DJCB were officially deprecated in the EMC Documentum 6.0 platform release (aka D6).
• Since D6, EMC Documentum Foundation Services (DFS), is the fully supported and recommended platform API for interoperable solutions development (e.g. using .NET frameworks such as ASP.NET or Windows Forms).

Interoperability Review Details

Most folks that know EMC Documentum business logic software is predominantly implemented in Java (e.g. DFC/BOF, UCF, ACS/BOCS, etc.). However, this should not indicate a lack of support for other platforms such as .NET. So, let’s talk about .NET support, first by reviewing the past and finally by focusing on the present.

• DFC, Microsoft developers, COM and DJCB
• DFC, Microsoft developers, .NET and DFC PIA
• Data access, Microsoft developers and DAS
• Web services, Microsoft developers, WSF and DFS

During EMC World last week, my Grenoble colleague Pierre-Yves “Pitch” Chevalier presented this subject on behalf of Marc Brette, who couldn’t make the event this year but authored the presentation. Pie attended the session and blogged about it here. Having received the presentation from Pitch and Marc, you can download it here. Cheers…

Tom and I were able to present to another great set of attendees–lots of healthy curiosity and great questions. Now that the labs have been conducted, here are the presentation slides–version from today, which was slightly modified from Monday’s deck.

It’s been a great talking with a lot of folks about DFS and content management in general. Thanks to everyone who shared their current experience with DFS, their ideas and their issues. The product will be better because of you. Thanks!

This afternoon, colleagues Mike Mohen and Paul Kwitkin presented a well-attended session, “Documentum Foundation Services – Best Practices and Real World Examples.” It’s always a good thing to have someone else be able to tell folks how well your software performs under load and back it up with hard numbers and context. Usually this session takes about four hours to present in depth; so, Mike and Paul did a good job distilling the essence down to just an hour or so.

Mike and Paul work in CMA’s Professional Services organization, helping customers deploy enterprise solutions that typically involve out of the box services from DFS as well as custom service development and custom service consumer (solution) development. What we do in engineering it what Professional Services does in terms of building services and service consumers. It’s also the very same advice offered at today’s session, which will be repeated on Thursday. So, this material is not just about you, our audience, but it’s very much about EMC, too.

I’ve already asked Mike for his presentation, demos and source code; so, once I receive this content, I’ll make it available here.

Earlier today, I sat in on Victor Spivak’s “Documentum Architecture Deep Dive” session. (Pie blogged about this session in a fair bit of detail here and here.) As you might expect, DFS was a prominently discussed within the broader context of all Documentum architecture. (For those who don’t know, Victor is EMC Content Management and Archiving division’s Chief Architect. Victor is also an EMC Fellow and a really good guy.)

It’s really quite exciting to see such a consistently strong turn-out for the developer-oriented sessions at this year’s EMC World conference–much stronger than last year. It’s a privilege to have so many folks interested in what you’ve worked so hard with others to produce–both to tell you what works and what doesn’t.

Already this week I’ve received great feedback that will make DFS an even better product in future releases. Once my customer meetings this week subside a bit, I hope to share what I’ve learned with you here in more detail.

Update 5/21/2008: Here are the slides Mike and Paul presented. Looks like the real world examples will become available soon, too. Cheers.

Update 10/24/2008: You can access the recording of this session, now, here.

EMC World is happening this week in Las Vegas. Last night the festivities were kicked off nicely by The Goo Goo Dolls. The concert sounded great, and the band seemed to be enjoying themselves–not to mention a majority of the some 9300 conference attendees. The result was substantially better then the forgettable act last year in Orlando.

This afternoon I’ll be presenting a two-hour, hands-on lab with my colleague Tom Heller. I’m looking forward to going beyond just introducing Documentum Foundation Services like last year to level-setting attendees in order to support them in quickly building their own service and consuming applications.

Once the lab today and again this Wednesday are completed, I will post my presentation here.

In the meantime, there are more folks blogging EMC World from a content management perspective than last year. EMC itself is also trying to be more open and online about its conference. Please check out the following content sources:

• Laurence Hart (aka Pie)
• Lee Dallas & Marko Silanpää (aka BMOC)
• Len Devanna (e.g. wiki, Twitter, Flickr, YouTube, etc.)

Stay tuned for more news from Las Vegas.

Ever since we produced an object model poster for EMC Documentum 5.3, folks have requested more such posters. So, when DFS released with EMC Documentum 6.0, we thought it made sense to pursue a data model poster.

Thanks to the work of Oleg, Meir, Patricia and others, I’m pleased to report that the DFS data model poster for the 6.0 SP1 release is on its way to the printers. You can download its PDF rendition here.

Also, if you’re coming to EMC World next month in Las Vegas, it’s my understanding that there will be a large number of posters available to attendees–not to mention a number of presentations and a hands-on lab concerning DFS.

Cheers!

In response to the DFS area within the EDN forums, Sergey at DFS Notes has been kind enough to post a three-part tutorial as follows:

1. Part 1 – Environment setup for DFS SDK and (“Hello World”) service creation
2. Part 2 – Java client creation
3. Part 3 – .NET remote client

Here are a few more details to complement this tutorial:

• In DFS 6.0 (v1), BEA Weblogic Server 9.2 (plus BEA Smart Update-based patches) is supported and the unit of deployment is an EAR file. In DFS 6.0 SP1, supported JEE application servers were increased to also include Oracle Application Server 10g Release 3 (10.1.3.x) and IBM WebSphere Application Server V6.1, Fix Pack 11. Certified JEE application server support will continue to grow in future releases (e.g. JBoss) as well as support both for application servers biased toward EAR files and toward WAR files.
• The version of Ant used during DFS 6.0 development was 1.6.5; however the version of Ant required for use with the DFS SDK is 1.7.0. Ant 1.7.0 is the first version of the Apache open source project to formally support Ant libraries (or antlibs), and DFS SDK 6.0 SP1 has a dependency on Antlib for .NET 1.0 in order to build .NET productivity layer support for your custom services. (You can also leverage NAnt, if you prefer.) So, before you commence a build using the DFS SDK 6.0 SP1, you should verify the version of Ant that will be applied, by typing “ant -version” in a Command Prompt window, for example, is “1.7.0.” If you forget to do this or proceed despite not seeing “1.7.0″ and you encounter a “java.lang.NoSuchMethodError: org.apache.tools.ant.util.FileUtils.getFileUtils()” exception while attempting to build your custom service EAR file–even though you’ve installed Ant 1.7.0, you may need to verify that ant.jar is referenced before dctm.jar is referenced on your active ClassPath.
• Java 5 Standard Edition is required for EMC Documentum 6.0 where platform development is concerned (e.g. using the DFS SDK). EMC Documentum 6.0 SP1 certifies support for Java 6 Standard Edition only on the browser host, not on the application server. You may encounter deployment issues if you build your custom service with Java SE 6.0.
• Versions of JAX-WS and JAXB included in the DFS SDK 6.0 SP1 are as follows: JAX-WS 2.1.2 reference implementation from Sun and JAXB 2.1.4 reference implementation from Sun. If you encounter a “java.lang.LinkageError” exception while building your custom service EAR, then you may need to employ standard “endorsed” library techniques to ensure proper JAXB class loading.

Thanks to Sergey for posting his tutorial, and thanks to Saša at Pexim Content Manaqement Solutions for sharing his development experience with me, which contributed to the above content.

The following new features are provided in EMC Documentation Foundation Services (DFS) for Documentum 6 SP1, which officially released yesterday (12/21/2007):

• Support for deployment using IBM WebSphere and Oracle application servers
• Productivity layer for .NET consumers
• Object service enhanced to support external sources

DFS now supports free-standing deployment on IBM WebSphere V6.1 and Oracle Application Server 10.1.3.x. This means that the EAR file containing out-of-the-box core platform services, emc-dfs.ear, can be successfully deployed into these application servers. Deployment of core platform services via an installer continues to be BEA WebLogic based–either alongside the Java Method Server app server instance established during Content Server installation or into a cluster-ready, separate middle-tier deployment during standalone DFS installation.

The DFS SDK now includes a.NET productivity layer (consumer library) for development of .NET-based DFS consumers. The .NET productivity layer is functionally equivalent to the Java productivity layer, with the exception that a .NET client can consume DFS services only remotely (as web services).

The DFS .NET productivity layer is Common Language Specification (CLS) compliant; therefore, you are free to develop above DFS using your CLS-compliant language of choice (e.g. C#, VB.NET, Managed C++, even IronRuby, IronPython, etc.). Samples of C# DFS consumers are provided in the SDK as well as new XML Documentation (i.e. C# equivalent to Java’s Javadoc) and HTML Help (.chm) documentation.

DFS service development tools have been enhanced to provide a facility for generating CLS-compliant .NET productivity layer support for your won services, too. The DFS .NET productivity layer is based on Microsoft’s Windows Communication Foundation (WCF) framework within .NET 3.0.

The core platform Object service has been enhanced to support retrieval of content from external sources accessible to the Search service. Since its initial release in D6, the core platform Search service getRepositoryList operation returns a list of available sources–both managed sources such as Documentum content repositories and external, unmanaged sources such as Google or anything else supported via an ECIS adapter. (You can checkout the source of several ECIS adapters via the EMC Developer Network (EDN) Component Exchange.). The Search service execute operation returns the result of a search query run against a list of sources, both managed and external. Now with SP1, the Object service get operation can retrieve content from the external sources in addition to managed sources, based on the search query results.

There’s more to tell, but I have some Christmas shopping and gift wrapping to do!

“The companies that figure out how to harness the power of open platforms while providing adequate incentives to all stakeholders are poised to reap great rewards.” -from Wikinomics

A few months ago, I blogged about this thought-provoking book. Around the same time I began to promote the idea of taking aspects of our product documentation (e.g. development guides) and “wikifying” them. I contend that it’s better to replace the current delivery model (i.e. a PDF drop per release) with a new model that harnesses the power of the web and the energy of the Documentum community. Better for writer (uptake, feedback), better for all cross-functional product team members (accessibility, performance, quality, functionality, architecture, usability), better for the overall community (collaboration, connectedness).

The Django Book is an example application (user experience) of what I’d like very much to see become of the DFS Development Guide content—Wikibooks (e.g. this) is another example.

As you might expect our Technical Publications group leverages XML (DocBook to be more specific) as the underlying markup for its deliverable, which are released in PDF form. This is great news, since XML to wiki markup format transformations are fairly straightforward. By taking the underlying XML content and projecting it into a wiki–for example, off the EMC Developer Network (EDN) web site–rather than a PDF document can open up documents like the DFS Development Guide to our developer/admin/user community. By doing so, I believe that such documents can be revised, extended and planned more effectively. For example:

• I find a gap I can fill. So, I simply create the missing wiki page(s)–I don’t have to wait until the next release of the software or the PDF document.
• I find a gap I don’t know how to fill. So, I add a topic to the wiki’s “wish list” page, and someone else with the ability to author the missing content gains my respect and builds his or her reputation in the DFS community.
• I can share how I took an existing code sample and tweaked or extended it to satisfy a new requirement.
• I can talk about how DFS did or did not work with my existing IT environment–and expect more timely, specific/targeted response in return.
• Etc.

Once the wiki exists, it can (and IMHO should) become the truth of its subject matter. In fact, PDF documents simply become the output of convenience (e.g. Atlassian’s Confluence wiki allows you to quickly rendition any wiki page as a PDF or, via a plugin, an entire wiki space as a single PDF document–links and all). Snapshots are just snapshots, and the current state of information is open for all to access and contribute.

To quote one of my colleagues: “The idea that we can control and perfect the quality of the information internally and shield it from possible inaccuracies introduced by customers is pretty flawed.”

When I talk with developers, partners and customers in the Documentum community to explain the idea of such wikis, the universal response is, to paraphrase, “sure…and yesterday would be great!” To trim it down to a single word: “Duh!”

So, to quote Jerry Maguire, “Help me help you” by posting a comment here, sending an email to the good folks at EDN and/or posting to the EDN forums, or call your main EMC point of contact to make your voice heard and your vote count. Thanks!

Update 12/27/2007: Thanks to Anne Gentle’s link to my post, I found Wiki Patterns, which offers an open catalog of patterns and anti-patterns concerning people using and adoption of wikis (e.g. a WikiGnome versus a WikiTroll).

Today I had the privilege of talking about EMC Documentum Foundation Services (DFS) to roughly a 100 or so customers, partners and integrators at Momentum Europe 2007, held at Grimaldi Forum, Monaco. As promised, my slides are here, and the demo client in both Java and .NET (C#) can be downloaded via Zip archive here.

Before my session during the day’s keynote, the winners of the D6 Web Services Challenge were announced. As an internal judge, I was quite impressed by the breadth of submissions and how little time it took to develop them using DFS. The winners are as follows:

• 1st Place – Incident Management System: Armedia
  This Windows Mobile 6 application simulates a field employee using a handheld device to capture notes in the field, and import them to Documentum. It allows for the mobile device camera to directly import images to Documentum, plus importing of images from an external service, in this instance Flickr. This application was built in only 10 days by a team of three individuals.
• 2nd Place – 5MD gTop: Rob Cleghorn, Alexandre Alvares, Andrew McAllister, James Maughan, and Simon Green
  This five man team is so named due to the five days they dedicated to their effort to build a highly functional Web based user interface to Documentum leveraging Google Web Toolkit. In the words of one judge: “A clear example of the power of the new Rich Internet Application (RIA) and SOA programming model in action.”
• 3rd Place – PDF Publishing and Search: Alan Greendyk
  This single person entry leverages the power of Flex programming and Adobe LiveCycle Data Services to illustrate a publishing application pushing content into Documentum, with an extended search capability to fetch content from the Documentum repository.

The press release for this announcement is here. There should be more details about the winning entries up on EDN soon, too.

Congratulations to Armedia, the team from BNP Paribas (Cleghorn et al), and Alan Greendyk from Wachovia!

Laurence picked up on this earlier today: EMC’s D6 Web Services Challenge. Whether you’re an established partner or an up-and-coming consultancy of one or more individuals, you’re invited to take the challenge and submit your entries in the next couple of months (i.e. by 9/28/2007 per contest rules). First prize is $50,000, with total prizes  amounting to $100,000! This is a great chance to get your name and company established as a leader where the new Documentum Foundation Services (DFS) are concerned. So, please consider taking the challenge!

Yesterday and today I had the privilege of supporting my colleague Charlotte Townsley as the subject matter expert during her EMC Documentum Foundation Services (DFS) sessions as part of the D6-focused Techset event. (For those not familiar with Techset, it’s an event Documentum ran and continues to run as part of the larger EMC Content Management & Archiving (CMA) business, providing timely valuable details concerning an upcoming platform release.)

I’m guessing that roughly 200 attendees–EMC field personnel, including consultants, plus EMC partners–participated in one of the two day-long sessions that featured instructor-led presentation plus lab work. Each day’s audience was definitely into the material based on the level of interaction and depth of questions asked.

I’m really looking forward to receiving feedback from these individuals as they “take to the streets” armed with DFS.

For those who attended Tuesday’s DFS session, I threw together the following graphic for today’s attendees:

It’s purpose is to help clarify where the DFS runtime is involved, among other things. The top two flows represent remote consumer interactions, and the bottom/third flow represents a local consumer-provider interaction.

By the way, if you’re interested in learning more about DFS and how to use it to build custom services and service-consuming applications, please consider the upcoming DFS Fundamentals course from our Educational Services team. (The Techset sessions on DFS represent just a portion of that class.)

Cheers!

Laurence oversimplifies and confuses matters where ECM standardization is concerned. However, it’s perfectly valid to leverage a blog as a learning medium and to “think out loud” therein. So, I’ll respond here both to clarify what EMC is doing in this space and perhaps to offer some guidance to those thinking about ECM standards.

Let’s proceed, point-by-point:

• To repeat myself, customers (i.e. the end users, developer and administrators they represent) require standardization. They expect ECM leaders like EMC to support industry standard–drive them, too!
• As an “ECM person” I can confidently say that the “ECM world” is definitely ready for standardization. (I don’t know who Laurence is otherwise referring to.)
• I like to think about ECM standardization in light of ECM commoditization. Gartner coined the term “Basic Content Services” (BCS) to describe this reality–that actions like checkin, checkout, version, etc. are fundamental, not differentiating, operations. BCS simply confirms that LCD is a fact of life–something to embrace, not avoid.
• Remember: there is “enterprise software,” and there is “software that runs the enterprise.” Software running a typical enterprise must interoperate. (It likely also differentiates itself well where feature/function, value, performance, scalability, adaptability, etc. are concerned.)
• Read RESTful Web Services. Understand the true comparison between approaches lies between REST and RPC, not REST vs. SOAP. Also I don’t see this as a one-or-the-other decision–I’m not alone here, either. And, yes, this debate can become “religious” in nature.
• I do, indeed, expect there to be an emphasis on SOA with the launch and release of EMC Documentum 6.0 (D6). I encourage you, whether you’re a developer, partner, customer project lead or CIO to kick the tires of this major platform release and put DFS through its paces. Ultimately the judgment on “truth versus fiction” where SOA enablement in D6 is concerned rests with you. That being said, DFS represents a substantial engineering investment–one that I’m proud to represent.

It’s great to see an increase in attention paid to standardization, service-orientation and resource-orientation in ECM. If you have feedback to offer, in terms of standard services/resources, operations/methods, use cases, etc. herein, I’d love to hear from you. Leave a comment on my blog or post me an email. Cheers!

Update 7/11/2007 (via DonR): The REST vs. WS-* war analogy deepens, thanks to Elliotte. WS-* is North Korea, and REST is South Korea.

Update 7/12/2007: Richard Monson-Haefel, glad to witness the trend now toward REST, says: WS* is intelligent. REST is wise.

Update 7/15/2007 (via my feed reader): Ted Neward chimes in on the Chappell…Elliotte… analogies thread.

Update 7/25/2007 (via my feed reader): David Chappell updates us with responses to his original remarks.

Yesterday, Laurence Hart (a regional ECM consultant) felt compelled to talk about standards in the context of enterprise content management and asked if they’re getting too much attention. In the process, he linked to one of my EMC Documentum Foundation Services (DFS) posts.

First, let’s talk about ECM standards. Are they getting too much attention, as Laurence suggests, or not enough attention? I would argue the latter based on recurring conversations with customers and also simply by acknowledging the whole of content we all live in.

While it may be true that compliance with standards is an oft-used tactic to satisfy an RFP checkbox that can in turn lead to increased sales–generally speaking not just in ECM space–taking this kind of approach to standards is ill-formed and serves neither the customer nor the service provider. Standards are not an end to themselves; they should represent means to worthwhile ends–and customers ultimately decide what is worthwhile and valuable. Customers increasingly tell me that the right ECM standard is valuable to them and something they want to see implemented by EMC Documentum.

Why?

The following figures comes my EMC World presentation on DFS:

Today’s content-centric and content-driven applications need to access ECM services from multiple content stores (e.g. EMC Documentum, SharePoint, Amazon S3, Salesforce.com, etc.). Unless there is an ECM standard for content service providers, the application developer is burdened with adapting to each store as a set of one-off’s. This causes application development not to scale, and the result is fewer applications that make all enterprise content available to knowledge workers. Rather than estimating the cost of implementing an adapter, the application developer and his or her CIO would rather know what new content can come “online” into existing solutions over time and based on standards.

That’s addressing briefly how ECM standards are relevant for customer applications and solutions. What about customer service implementations? What about ECM service providers themselves?

As with most technology providers, ECM software revenue travels up the value mountain. By this I mean that yesterday’s value proposition is today’s commodity and tomorrow’s legacy (e.g. Laurence’s reference to ODMA). While life as a typical ECM provider may have began with a repository, it won’t stay there. In fact, it’s already moving. So, companies like EMC must look to software services to provide customers value long-term. A service that can easily represent and compose with other content stores, not just its native repository, is a more valuable service. The more I can virtualize enterprise content–the more I can provide a consistent service layer above that content–the more relevant I become to your enterprise and its knowledge work.

Laurence stated: “Standards are enclosed in the SOA efforts of [EMC's] vision.” DFS is the SOA enabler coming in EMC Documentum 6.0, and as you’ll hear me say in my EMC World presentation, DFS is indeed influencing EMC’s work in the ECM standards space.

Roughly a year ago, I blogged about iECM, and I closed by saying that I would provide updates-as-blog-posts as ”iECM progresses toward its stated goals.” Since then I haven’t blogged another word about iECM.

What I can say today is that EMC is working on ECM standardization with other industry leaders, and that EMC is very committed to the important work of making ECM interoperability in a standard way. Just as soon as I can say more, I will!

Earlier this week I presented Documentum Foundation Services to a full house at SDC07. I see that John Newton picked up my post. (BTW, I very much agree with John that EMC could do a much better job of opening up the event, both to those in attendance and those unable to attend, by blogging. Transparency is here to stay.)

John suspects that DFS contains EMC Documentum’s “long awaited web services interfaces.” Actually, DFS is more about SOA enablement than about just web services, but it is true that DFS provides WSDL contracts for a number of core platform services.

On Thursday I presented a repeat of Monday’s conversation to about 70 SDC07 attendees. Since the repeat session occurred during the very last hour of the conference and the previous evening featured the attendee party at Universal Studios Islands of Adventure, I felt the turn-out to be quite good.

My presentation–as presented on Thursday–is here. I was also able to record Thursday’s presentation. Here is that recording, which runs a little over 51 minutes. Lastly, here is the small DFS remote client sample that was discussed during my presentation. I revised the sample slightly from what was presented during Monday’s session to highlight the variety of ways to determine how a particular service contract can be bound by a client.

Whether you choose to comment here on this blog or on EDN, I do hope to hear from you.

Let’s build a community around DFS together. Cheers!

Update 8/29/2007: The good folks at EDN have produced media that combines my presentation slides synchronized with my audio presentation of them during SDC. Enjoy!

Update 1/13/2008: I’ve begun to move my DFS-related media into the Documentum community area within the EDN. This will allow me to better follow and follow-up on individual media (e.g. point out when a sample is out-dated, etc.). It also helps better promote EDN.