ODMA: Where's It Going?

ODMA has done its job.  Now ODMA is fading away. 

In the four years since the last update of this analysis, ODMA has been steadily disappearing from use.  ODMA functions are now too narrow and constrained to satisfy the ordinary expectations and requirements for document-processing systems, especially in international settings.

The ODMA API will slowly disappear.  It's limitations are too awkward for newer, Unicode-based applications to accommodate.  Developers no longer acquire the necessary skills for using the API and building native Windows components that honor it.  

ODMA usage will linger in legacy support and perhaps special-purpose niches and experimental applications.

1. Success

1.1 In 1994, ODMA 1.0 delivered smooth integration between document-management systems and document applications on the desktop.

1.2 Users of ODMA-aware desktop applications can operate with documents from locally-connected document-management systems in the same way that file-system documents are used.  It is not necessary to leave the desktop application in order to interact with document-management functions that apply to the document being worked on.

1.3 Developers of document-management systems can provide a single ODMA-compliant desktop component to integrate with every ODMA-aware application on the desktop.

1.4 ODMA integration separates all document-management-specific behavior from the desktop application, and vice versa.  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.

1.5 The desktop 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.

Figure 1.  ODMA Integration between application and DMS

1.6 The single ODMA Connection Manager provides plug-and-play connection between all ODMA-aware applications and all DMS interfaces available on the same desktop computer.

2. Stability

2.1 The Basic ODMA 1.0 functions are preserved in all versions.  Addition of further features ended with the 1997 release of 2.0.

2.2 The easiest way for a desktop application to integrate with ODMA-aware DMS integrations is to require only ODMA 1.0 functions.  Additional functions can be discovered dynamically when that is useful for the application.

2.3 DMS integrations can be designed to support all ODMA 2.0 functions while operating smoothly with applications that rely only on the ODMA 1.0 functions.

3. Disappearance

3.1 The desktop has moved to component models and to the Internet for distributed integration technologies.  ODMA is left behind.

3.2 While ODMA arises in legacy situations, it is disappearing relative to the continuing expansion of other approaches for connection applications and services:

• Component models (especially ActiveX) for integration on the native Windows platform
     
• Direct integration over the web via Web Folders and WebDAV
      
• System frameworks, including Java and .NET, that require quite different application development, deployment and integration approaches
      
• New office-application models around smart clients, web services,  and web-hosting

3.3 As document-management adopters migrate from legacy systems to non-ODMA-compliant DMS products, support for ODMA by desktop applications becomes invisible and irrelevant.

4. Limitations

4.1 The ODMA API requires the use of C++ and the Windows Platform SDK on native (i86) Windows.  Use of different programming languages and development tools, if possible at all, is complicated.

4.2 The ODMA Connection Manager uses its own "class loader" to access the services of an ODMA-compliant DMS integration.  Creating a Dynamic Link Library (DLL file) in the proper format requires use of C++ and the Windows Platform SDK on native (i86) Windows.

4.3 The communication of text information through the ODMA API is limited to single-byte or double-byte code sequences corresponding to the local Windows system-default code page.  The specification is vague in this area and usages of bytes with values in range 0x80-0xFF in API text elements has risky interoperability.

4.4 There is no explicit provision for communication of Unicode encoding forms via API text elements.

5. Niche

5.1 The beneficiaries of ODMA are DMS customers, developers and vendors, especially in small and specialized document-management markets.  The value of ODMA hinges on the continuing availability of ODMA support in the desktop applications of choice.

5.2 In practice, ODMA is a legacy-supporting feature of desktop applications.  Support is not expanding into more applications.  Generally, support is at best stable.

5.3 Steps can be taken to remove some ODMA limitations.  The benefit is to niche cases:

• Special-purpose ODMA-aware applications developed to access document-management systems as part of a work process
      
• Custom integration of an existing repository for access from conventional and special-purpose desktop applications as part of a system integration or vertical-application integration
      
• Experimental and prototype development using ODMA as a lightweight path for early integration and testing.

5.4 Whether there is further development depends on the existence of volunteers that are both willing and able to make the kind of community contribution that brought ODMA into existence in the first place.