Blunder Dome Sighting  
privacy 
 
 
 

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: Software Craftsmanship Wiki
 
SeaFunc: 2008-02-20 Functional Programming Meetup
 
ODF-OOXML: nfoWorks for Harmony?
 
DMware: Office System Developer Conference 2008
 
Cybersmith: 10 Golden Rules for Mastery
 
Toolcraft: Making Discs from CD/DVD Image Download...
 
VC++ Novice: Obtaining VC++ 2005 Express Edition
 
VC++ Novice: Visual Studio 2008 Express Edition Ar...
 
CP4E: Novice Computer Programming and the OLPC XO
 
DMware: How About That ODMA64?

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

2008-02-18

 

DMware: ODMA Futures Roadmap

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:

    1. Enhancing ODMA Effectiveness
      preserving the sweet spot and improving its support
         
    2. Preserving the ODMA Core
      conserving the historical materials and adding versions that are more appropriate with contemporary tools and libraries
        
    3. 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
        
    4. 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.

1. Enhancing ODMA Effectiveness

There are four critical features that have ODMA be effective in bridging desktop software products to document-management systems:

  1. 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.
      
  2. 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.
      
  3. 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.
      
  4. 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.

2. Preserving the ODMA Core

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.

3. ODMA32 2.5 Integration

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.

4. ODMA64 3.0 Interoperability

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.

[1] Dennis E. Hamilton: ODMA: The Little Middleware that CouldOrcmid's Lair (web log), 2005-12-20.
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.
  

 
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 $