Blunder Dome Sighting  

Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.

Click for Blog Feed
Blog Feed

Recent Items
Cybersmith: No-friction Bits and Pieces
VC++ Novice: Is Native C++ a Dead Language?
nfoWorks: What Are those Harmony Principles, Agai...
nfoWorks: Tracking OOXML DIS 29500 into the Blue
nfoWorks: The ISO/IEC Harmonization Opportunity
nfoWorks: In Search of Initiative
nfoWorks: The Harmony Get-Ready
DMware: Documents as Evidence
VC++ Novice: DreamSpark for Students
DMware: ODMA Futures Roadmap

This page is powered by Blogger. Isn't yours?

Locations of visitors to this site
visits to Orcmid's Lair pages

The nfoCentrale Blog Conclave
Millennia Antica: The Kiln Sitter's Diary
nfoWorks: Pursuing Harmony
Numbering Peano
Orcmid's Lair
Orcmid's Live Hideout
Prof. von Clueless in the Blunder Dome
Spanner Wingnut's Muddleware Lab (experimental)

nfoCentrale Associated Sites
DMA: The Document Management Alliance
DMware: Document Management Interoperability Exchange
Millennia Antica Pottery
The Miser Project
nfoCentrale: the Anchor Site
nfoWare: Information Processing Technology
nfoWorks: Tools for Document Interoperability
NuovoDoc: Design for Document System Interoperability
ODMA Interoperability Exchange
Orcmid's Lair
TROST: Open-System Trustworthiness



DMware: ODMA's Dark Matter

I'd originally thought of posting about "ODMA in the Cloud."  That doesn't work in the Web x.0 sense of the Internet "cloud."  It does work to think of ODMA being "out there," unseen, yet its mass -- however tenuous -- is felt.  Here's what I mean by all of that.

Into the Hidden Universe and Beyond ...

The Open Document Management API consists of three important elements:

  1. A standard: the specification of an application interface and integration model that is relied on by a community
  2. A Software Development Kit: an SDK providing header files and some samples that are intended to support programming against the API and developing services that offer the API (via the integration model)
  3. Middleware: The ODMA Connection Manager, a software module that is installed as a bridge between applications (clients) and document-management subsystems (integrations) on the same computers

ODMA is a middleware arrangement in much the same way that ODBC and TWAIN are.

From the beginning with ODMA 1.0 in 1995, the elements of ODMA have been freely available: the API is free to use, and the middleware software is freely distributable and installable on Windows-equipped computers.  (There have been occasional mumblings about support for non-Windows platforms, but that has not happened so far.)

In this way, ODMA has been cast upon the waters.  There is no reason to know where ODMA integrations are installed, how many of them there are, and how varied they are.  It can be presumed that ODMA adoption and usage has been steadily decreasing since completion of ODMA 2.0 in 1998, yet there is regular access to the ODMA Interoperability Exchange site where all of the elements remain available.

ODMA No-see-ums

In the course of active ODMA definition work, there have been three versions of ODMA:

  • ODMA 1.0, the original form
  • ODMA 1.5, introducing some additional administrative support and a form of federated search, and
  • ODMA 2.0, apparently over-reaching the sweet spot along with tidying-up some operability cases.

There are different specifications, ODMA Connection Manager implementations, and SDKs for the three versions.

The promise is that versions are upward compatible.  In addition, an ODMA-aware desktop application can specify the version of ODMA that it is designed for.  Configurations of ODMA are expected to decline to serve an application that depends on a version later than the level supported by the installed Connection Manager and document management system that is being accessed.

What we don't, and pretty much cannot, know is which

  • versions of ODMA Connection Manager are still in use, and in what quantity
  • versions of ODMA integration are supported by ODMA-compliant document-management systems
  • versions of ODMA are required by ODMA-aware desktop applications and how prevalent and varied they are, even though it is clear that ODMA 1.0 is the most-commonly required support that application programs require

Although there is a registry of ODMA-aware applications and ODMA-compliant DMS integrations, contribution of this information (and avoiding of duplicate DMS IDs and application IDs) is completely voluntary.  Much of the information in the registry is out-of-date (as is much of the identified software) and there's not much to be done about it.

There is, in typical fashion, no good way to know how many implementations deviate from the specifications and how many may have "forked" the API and/or the Connection Manager software to accomplish a custom arrangement. 

The only time that potential breakdowns of implementations and implementation-quality issues surface is when someone seeks support on one of the e-mail lists provided for ODMA support.

ODMA as Interoperability Laboratory

It is surprisingly commonplace that people implement specifications such as ODMA without consulting with each other or self-styled experts such as myself.  It is clear that checking is mostly for successful operation with an important software product (typically Microsoft Word) or a given document management system (Novell Groupwise, Lotus Notes, and Documentum, among others).

There has not been, as well as I recall, any concerted interoperability testing of ODMA implementations beyond that required for a few early demonstrations at trade shows.

There are places where ODMA is known to be under-specified.  These are invitations for developers to invent an answer.  This is in addition to the ordinary risks of misinterpreting the specification and failing to confirm that interpretation (probably thought to be obviously correct).

Along with that, there are some promises made in the specifications that were claimed but not actively verified.  One is the promise that the specification is upward compatible.  For example, ODMA-aware applications developed against the ODMA 1.0 specification should be able to work perfectly well with other elements developed against the ODMA 2.0 specification.  That promise has been broken, although it is not clear whether that has been much of a hindrance, and if not, why not.

It is both surprising and somewhat discouraging that there have never been any complaints about those breakages and a few others that have come to light over the years.

There are defects in the specification, there are defects in implementations, and ODMA integrations seem to be limping along mostly without serious incident, nonetheless.  Of course, I am unlikely to be told where an ODMA integration was abandoned because it didn't work successfully with products that mattered in a particular situation.

I think that many features of the ODMA situation are typical of interoperability arrangements, how they can erode, and how they can be evolved toward a condition of reliability and stability.   On the presumption that it is valuable to do so, at least for what it provides as useful experiment, I am going to recount a number of lessons that I have already experienced.  These arose in my efforts to support software products having different programming and integration models (e.g., Java, .NET, and COM/ActiveX) than that of the native Win32 elements of ODMA. 

Looking at how ODMA interoperability is enhanced is an opportunity to see how the same kinds of considerations also apply in more complex situations where demands for strong interoperability are expected to increase, not diminish.

Construction Structure (Hard Hat Area) You are navigating Orcmid's Lair.

template created 2004-06-17-20:01 -0700 (pdt) by orcmid
$$Author: Orcmid $
$$Date: 10-04-30 22:33 $
$$Revision: 21 $