 |
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.
Blog Feed Recent Items 
The nfoCentrale Blog Conclave nfoCentrale Associated Sites |
2008-05-26DMware: 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:
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-umsIn the course of active ODMA definition work, there have been three versions of ODMA:
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
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 LaboratoryIt 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.
|
||
|
You are navigating Orcmid's Lair. |
template
created 2004-06-17-20:01 -0700 (pdt)
by orcmid |