i990501 NuovoDoc InfoNote  ODMA - Where's It Going? Appraisal 0.16

NuovoDoc>info> 1999>05> i990501c> 0.16 2013-08-22 12:43 -0700

• Latest version: The latest document-engineering version of this information is available on the Internet at
  <http://NuovoDoc.com/info/1999/05/i990501b.htm>.
• This version:  0.16 <http://NuovoDoc.com/info/1999/05/i990501c.htm>.  Consult that page for the latest status and for the most-recent electronic copies of the material.
• Next version: 0.31 <http://NuovoDoc.com/info/1999/05/i990501d.htm>

What keeps ODMA interesting, and what will keep it around? 

I say that ODMA has done its job and will continue to fulfill an increasingly marginal need.  The world is moving to another way of integrating on the desktop and across the enterprise.   This will relegate ODMA to an increasingly specialized role.  

There are five main points, addressed from the perspective of developers concerned about ODMA employment in document applications and in desktop interfaces of document-management systems:

• ODMA succeeded.
• ODMA is stable.
• ODMA is becoming invisible.
• ODMA doesn't have legs.
• ODMA has a specialized future.

-- Dennis E. Hamilton
InfoNuovo
1999 May 10

---

ODMA Succeeded.  In 1994, ODMA 1.0 established an open, public approach for interoperability and smooth integration between different document-management systems and document applications on the desktop.  The central idea: have document applications do as little work as possible to integrate ODMA access along with existing file-system access for documents.

• When an ODMA-aware application is installed on the Microsoft Windows desktop, the user or administrator can set preferences for the ODMA-registered Document Management System (DMS) to use by default with this application. 

  When an ODMA-aware document application begins to operate, it registers its presence with the ODMA Connection Manager in a single, simple operation.  If the Connection Manager is not present, the document application simply operates with the file system as usual.  If connection succeeds, the document application will offer DMS access as an option along with file-system access.

• ODMA document identifications are easy to carry and store wherever file names can be used.

  There is a simple trick: Every ODMA ID begins with the difficult-to-confuse prefix "::\ODM\".

  The application arranges to accept and retain ODMA IDs as easily as it carries file names.  When requesting an existing file, applications use the ODMA API whenever an ODMA ID is encountered.   When a new document is to be created, the document application offers the option of using ODMA to create a new, managed document, or using the file system to create a file-based document.  When an existing document is to be opened, the user has the option of locating a document in the DMS or locating a document in the file system.

• ODMA document applications don't have to be implemented with any assumptions about how a DMS stores files, how it creates documents, how it finds documents, and how it retrieves documents (see figure).

  Document applications need only work on files in the file system.  To access a document in a DMS, the DMS is given the ODMA ID of the document and identification of the format expected by the application.  The DMS delivers the file(s) of the document in a file-system folder that the document application can use.

  When the document application completes operating with a document, it informs the DMS via ODMA.  The DMS takes the changes from the file-system folder set up when the document was opened by the application.

  The document application doesn't have to implement any interactions with the operator about finding and storing documents in the DMS.  The DMS provides all user dialogs that may be needed in order to carry out requests from the document application.

• ODMA DMS drivers are simple plug-ins on the desk-top computer.

  There is one ODMA Connection Manager module and any number of plug-in DMS drivers. 

  Under Windows, DMS desktop interfaces are installed as simple Microsoft COM objects.   They are registered in a way that allows the ODMA Connection Manager to find them.

  The ODMA Connection Manager uses a small number of COM-specific operations to activate a DMS for use with an application.  The application uses a pure "C Language" interface to reach the ODMA Connection Manager.  The application doesn't have to be a COM application or be developed with any awareness of COM.

Figure.  ODMA Integration between application and DMS (block diagram) [download Visio version]

ODMA is stable.  The basic ODMA 1.0 functions remain at the sweet spot of 1997's ODMA 2.0.  It is easy to see how to employ ODMA as widely as possible:

• Q: What's the easiest way to integrate with as many Document Management Systems as possible?

  A: Support an ODMA 1.0-level API for optional operation.    Register the desktop application as an ODMA application and use the ODMA interface to bridge to any document-management system the customer wants to use.  Whatever other integrations one wants to be known for, ODMA is too simple to pass up.

• Q: How can I make is as easy as possible for users of a document-management system to create, submit, retrieve, and update their desktop documents?

  A: Provide an ODMA 1.5-level DMS Interface to the document-management system on the desktop.   Honor the ODMA document-identification and document-format agreements with the DMS Interface.  A DMS that does not support ODMA on the desktop is like an imaging system that does not support TWAIN for integration of scanners and other image sources.

ODMA is becoming invisible.  The desktop has moved to component models and to the Internet for distributed integration technologies.  ODMA is left behind or submerged in this approach.

The benchmark document application suite -- Microsoft Office -- features application integration using ActiveX, Visual Basic for Applications (VBA), and scripting languages.   Java fits too.  So does the Web.  The suite is itself componentized for use in customized construction and deployment of enterprise collaborative and document-centered applications.   Think of it as the Collaborative Enterprise Desktop of choice.  Delivery of documents to and from this world is as component objects, containers, and object-oriented sequences of results.   ODMA, when accommodated at all, is submerged.   ODMA support is an incidental factor in this far-reaching object-oriented, distributable model. 

• Q: You mean I shouldn't bother with ODMA?

  A: No, that's not it.  The straightforward, simple ODMA interface provides easy access to a variety of DMS implementations at very low cost.  ODMA support by a DMS provides integration with document applications that have not, will not, or can not be moved to the Microsoft Office suite model.

• Q: Well, can I have ODMA as my only desktop integration solution for document applications and DMS interfaces?

  A: That just doesn't look like enough for Windows applications any more.  Don't ignore the synergies of desktop componentization, enterprise customization, and distributed application available in the Microsoft Office and Windows approach.  Having your product interplay smoothly with everything else that fits now and that will be there later is a very rich place to position products and solutions.  My unreliable sources tell me that there are tens of thousands of developers using Microsoft Office for building custom solutions.  I don't know what fraction of them are operating at the VBA integration level, but don't you want every one of them working on your side and integrating your product?

• Q: This seems too complicated.  For a small, struggling software company, how can we do both?

  A: (sigh)  However it looks now, what will change to make it easier later?

ODMA doesn't have legs.    I don't know how to say this better.  It looks to me that ODMA API boundary is situated at an optimal point from which there is no exit that preserves ODMA and what it does best.

In many ways, ODMA is very restricted.  It was meant to be.  The ODMA API was not designed for client-server operation or working with "standard" COM objects.   ODMA is highly-attuned to what is required on a desktop system.  It's greatest success, and all of the integration model, is specific to Windows running on a single computer.

• Q: What do you mean, not designed for client-server operation?

  A: Well, it is this kind of thing:

  1. The ODMA ID is a string in an 8-bit code that depends on the code page of the desktop system, making it difficult to export and transfer faithfully across enterprises and among international communities
  2. The transfer of string data has not been upgraded to Unicode, creating problems integrating desktop applications on Windows NT.
  3. The physical format of heavily-used string data and its transfer across the ODMA API is not one used by COM objects, Visual Basic, or Java and it doesn't transfer on networks well
  4. The transfer of files between applications and a DMS requires that the DMS have access to and create data in a file system that the application can also access.
• Q: (Petulantly)  Well, doesn't DMA suffer from some of these same limitations?

  A: Perhaps.  What difference does that make here?

• Q: Can't a DMS compensate for a lot of this?

  A: Yes it can.   And it is valuable to do so, providing distribution on the DMS side of the ODMA API and integration boundary.  This has been done with generic DMS Interfaces that operate atop DMA, and now generic DMS Interfaces that work on top of WebDAV.   There could also be generic DMS interfaces that work with some flavor of the Windows DNA Universal Data Access model.  Either way, the ODMA application is restricted to using and accommodating what can penetrate the API.  And a DMS interface may have to constrain what it can do in order to "impedance match" on its side of the ODMA API.

ODMA has a specialized future..   What's left for ODMA?

ODMA operates well and has appealing simplicity.  There are some simple steps to extend the life of the ODMA API:

1. Simple repairs.  Remedy the defects that interfere with cross-platform and heterogeneous operation between document applications and the DMS.
2. Give ODMA a genuine COM interface.  Yes, really.  Derive a clean COM API for use by document applications.  This also allows extension above the ODMA API to deliver components into the Collaborative Enterprise Desktop model for Windows.
3. Isolate Platform Dependencies.  The current integration model for the ODMA Connection Manager and plug-in of DMS Interfaces is snarled up in Windows dependencies.  Make a version that isolates platform dependencies and can be ported to other platforms such as Linux.  Stay friendly to Windows on Windows.  Just make it easier to have document management systems support equivalent document applications on other platforms. 

• Q: Will it matter?

• A: Maybe not.  ODMA has been a volunteer project all along.   It provided something that everyone could benefit from and that wasn't worth developing and perpetuating as a proprietary solution.  It matters whether the volunteer community has moved its attentions elsewhere or whether there is seen to be enough further benefit from raising the level of interoperability in ODMA itself..

---

You are navigating NuovoDoc

created 1999-05-10-10:00 -0700 (pdt) by orcmid $$Author: Orcmid $ $$Date: 13-08-22 12:43 $ $$Revision: 45 $