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.
After taking some time to envision what might be possible for an ODMA64 implementation of an Open Document Management API [2], I began to look at further details for a roadmap that could end there. At this point, it looks like there are four overlapping and mutually-supporting stages:
Preserving the ODMA Core conserving the historical materials and adding versions that are more appropriate with contemporary tools and libraries
ODMA32 2.5 Integration surrounding the ODMA32 Connection Manager with higher-level integration layers that happen to permit confirmation of new connection manager releases as well as experimental use of integration points that anticipate ODMA 3.0 simplifications
ODMA64 3.0 Interoperability breaking with the past to achieve simplified interoperability on 64-bit systems with exclusive reliance on Unicode
Although a few items are slated to commence in March 2008, most of the activity is without fixed calendar commitments and with no detailed deliverables. Here's the current level of thinking.
There are four critical features that have ODMA be effective in bridging desktop software products to document-management systems:
Simple Integration in Desktop-Software User Interfaces With the cooperation of desktop programs, the ODMA-integrated document management systems present their dialogs as dialog boxes of the desktop programs. This provides direct connection into the flow of information-worker activities. User attention is not taken away from the desktop software. The additional dialogs that accompany creation and use of managed documents are provided automatically. There is nothing for the user to forget to do. This is what users see and what makes ODMA so appealing for using already-available productivity software with managed documents.
Easy Deployment to the Desktop The ODMA Connection Manager, the enabling middleware, is deployed to office desktop systems along with the ODMA-compliant document-management system client software. ODMA-aware productivity software automatically discover the presence of the Connection Manager; the Connection Manager completes the connection to the document-management system that is to be used in the application setting. The configuration of desktop and document-management connections is managed by ODMA-specific settings in the Windows registry. No software modification is involved.
Trouble-Shooting Support ODMA 2.0 Connection Manager software provides logging functions that are usable in confirming and trouble-shooting connections between desktop software and document-management integrations. There are also utilities that can be operated to verify correct operation and to experiment with configuration changes.
Low Barrier to Entry for Document-Management Vendors This characteristic of the ODMA deployment and integration model is appealing for new, small, and specialized document-management vendors. Instead of making difficult per-desktop software (version) custom integrations, the supplier of an ODMA-compliant DMS can be assured that most ODMA-aware desktop programs will "just work" with that DMS.
There is a similar advantage for specialized ODMA-aware desktop software, although ODMA integration is more difficult and takes more preparation when designing desktop software. It is not necessary to build-in any knowledge of individual ODMA-compliant document-management systems, however.
All future development is focused entirely on preserving and enhancing these four qualities. In many cases, it is a matter of providing improved guidance and documentation. Tutorials, supplemental utilities, reference implementations, improved samples, and implementation kits will also be provided over time.
The ODMA SDK packages and other materials have become stale on the ODMA Interoperability Exchange site. As part of a general site repaving operation, the core materials of ODMA 1.0, ODMA 1.5, and ODMA 2.0 will be re-organized and preserved on the site and on an anniversary CD-ROM. The CD-ROM will be preserved at AIIM International as well, so that the historical materials are not lost.
Along with preservation of the historical materials, the ODMA32 Core will also be supplemented [3]:
Existing materials will be identified better in the files themselves, and also repackaged for more-convenient separate use. These will also be available on the ODMA Interoperability Exchange site.
The identified and repackaged materials will be made available as downloads of the ActiveODMA SourceForge project. The source code and documentation will be placed on the ActiveODMA subversion source-control system as a foundation for further work.
Some of the developer materials, such as header files, will be supplemented with versions that are more appropriate for development of production ODMA-based programs. These changes will be made in parallel with other activities where the changes can be tested in actual usage. This work has already begun on behalf of ODMJNI 1.0 and it will parallel other ODMA32 2.5 developments.
Existing samples circulated as part of the ODMA Core will be replaced by ones that correct known defects and provide more effective demonstration of the use of ODMA features.
At some point, there may be a maintenance release of an upgraded ODMA32 2.0 Connection Manager. This connection manager will contain some minor corrections and be thoroughly confirmed via automated tests produced before any Connection Manager changes are considered. ODMA-aware applications and ODMA-compliant DMS integrations should see no difference whatsoever. Some areas of ODMA effectiveness will be strengthened.
ODMA Core preservation activities will be initiated in March 2008, following the Public Beta release (0.60) of ODMJNI 1.0. The activity will be carried out in parallel with further ODMJNI releases as well as other ODMA32 2.5 integration activities.
ODMA32 2.5 is the achievement of supplemental integration layers surrounding ODMA32 2.0. The idea is to enhance the opportunities for ODMA integration with provisions of this kind:
Native COM-based Libraries There's development of Win32 Native Unicode-based libraries that deliver COM binary interfaces instead of the ODMA API. The use of ODMA32 and the C Language ODMA API is completely hidden. This allows creation of ODMA-aware applications using object-oriented technology.
Managed Code Libraries The Native COM-based libraries are used to build Java and .NET libraries that can be used to make Java-based and .NET-based ODMA-aware desktop software. If there is any remaining point, an ActiveX library could also be produced.
Native DMS-integration Fixtures Components needed to build ODMA-compliant DMS integrations are developed as integration kits and also as a basis for test fixtures that allow end-to-end exercise of the ODMA Connection Manager from the Native COM-based Libraries (and above) through to test DMS-integration fixtures below. This creates the possibility of automated regression testing of the ODMA32 Connection Manager. With that possibility, maintenance upgrades to the ODMA 2.0 Connection Manager can be considered.
Managed-Code DMS Integration Interop Although more difficult, experimental interop layers between Native DMS-integration layers and managed-code implementations (Java or .NET) of ODMA-compliant DMS integrations can be attempted.
ODMA32 Exploration for ODMA 3.0 Integration As preparation for ODMA64, the native DMS-integration and Interop fixtures might be arranged to allow preparation of DMS integrations that only use features that will be supported under ODMA 3.0 for ODMA64. This will simplify development of ODMA-aware ODMA32 DMS integrations, especially when the Document Management System is already designed around Unicode.
ODMA32 2.5 developments are already underway. Beyond the delivery of the ODJNI 1.0 Public Beta release in March 2008, there is no fixed schedule. The further development and release of ODMA32 2.5 components will be leisurely, paced by ODMA Core continuation work.
The ODMA32 2.5 supplements, along with maintenance updates to the ODMA Core and the ODMA Connection Manager, should continue to be available and usable so long as the Win32 platform remains in use on x86 architectures. No further development is expected for ODMA32 beyond 2.5.
Initial thoughts toward a potential ODMA64 appeared in November 2007 [2]. I am now thinking that creation of ODMA64 for 64-bit platforms will mark the introduction of ODMA 3.0 [4]. ODMA 3.0 will only be supported on 64-bit processors. It will not be backward compatible with the ODMA 2.0, although there will be useful overlap with ODMA 2.5 provisions.
Development of ODMA64 is not expected before 2010. Whenever development does occur, there are three key provisions:
The ODMA Effectiveness qualities are completely preserved (section 1).
Anticipation of ODMA64 will be worked out via ODMA32 2.5 supplements that provide proof-of-concept and also a way to stage ODMA32-based software for migration to ODMA64 by abandoning those features that will not survive into ODMA64.
The ODMA64 Connection managers and supplemental software should be portable to non-Win64 64-bit platforms. There will need to be GUI dependency coordination between ODMA-aware desktop software and ODMA-compliant DMS integrations, but this will be done in a way that does not involve ODMA64 Connection Managers.
I am still bemused that, 10 years after the AIIM ODMA Consortium shipped the last version of the ODMA Core components, based on the ODMA 2.0 specification, I am still supporting this long niche software and its integration model [1]. Not only that, I am now proposing further development in this interesting little middleware laboratory.
This article celebrates the 10th anniversary of the ODMA 1.0 specification and availability of the initial middleware for 16-bit Windows and Win32. The AIIM ODMA Coalition ceased formal activity following the completion of the ODMA 2.0 specification and the 1998 availability of the final ODMA Core, still for 16-bit Windows and Win32.
[2] Dennis E. Hamilton: DMware: How About That ODMA64?Professor von Clueless in the Blunder Dome (web log), 2007-11-10. Updated 2008-02-15.
Initial thoughts on taking ODMA into the 64-bit world. I have updated this note to extend the timeline into 2010, allowing more room for polishing the ODMA32 Core and building up the ODMA32 2.5 supplemental integration layers first.
[3] Dennis E. Hamilton: ODMA32 Core. ODMdev Development Note d071004 0.01, AIIM ODMA Interoperability Exchange, February 15, 2008.
This Development Note will be used to track polishing of ODMA32 Core up through any ODMA 2.5 maintenance release of the ODMA32 Connection Manager, followed by any migration to an ODMA64 3.0 core. ODMA 3.0 will not be backward compatible to ODMA 2.0 (or 2.5), using the change of platform to switch over to exclusive use of Unicode and also drop out unsuccessful ODMA 2.0 features.
[4] Dennis E. Hamilton: ODMA64 3.0 Interoperability. ODMdev Development Note d071002 0.02, AIIM ODMA Interoperability Exchange, February 15, 2008.
