Apply today for a FREE subscription to CIO Magazine!
Fri, Feb 8, 2008 20:24 EST

|
Posted by: Esther Schindler in Soapbox Topic: DevelopmentBlog: Developer Wisdom
Current Rating: |
Could the open-source community use a library packaging technology that enables languages to share class libraries regardless of the language an application was written in? I dare say it could, especially since the code to accomplish that goal was written (and shelved) more than ten years ago. All it takes to make that code available is to ask IBM to release SOM and DSOM as open-source.
System Object Model (SOM) and distributed SOM (DSOM) are technologies based on the interface defininition language (IDL) standard, enables a software developer to establish communication between disparate objects which may not be written in the same language. It fixes the fragile class tree in C and C++, though SOM isn't limited to those languages.
There isn't any technology available today that allows different libraries to freely interact with each other like that. Sure, there have been attempts (which one developer called "feeble") to accomplish the same thing that SOM did (among them are XML-RPC and JSON-RPC), but those have annoying limitations. XMLRPC and JSONRPC target some of what DSOM does. But they don't have the goal of linking disparate languages/libraries in an OOPy way. Please don't think I'm disparaging what these technologies can do; they're useful. My point is that SOM is at least another way to approach the task, and it could be argued (by people far more technical than I) that SOM could do it better.
As a practical example, imagine that someone created a C++ library that was the answer to all IMAP needs. A developer couldn't access that library from Python, unless she wrote custom code from scratch. And that wouldn't help a developer who uses Java. With SOM, the library would be available no matter which language you chose.
That example ought to give you a sense of the business advantages to SOM. Less code to write means faster, cheaper development. If SOM were part of the equation, you could avoid being marooned in the wrong environment to solve the problem.
I could continue about SOM's technical advantages... but plenty of that information is already available online. Alas, IBM no longer lists the Redbooks for SOM and DSOM, and sorry—you can't borrow my print copy.
Maybe you disagree that SOM will solve all sorts of problems for Linux. That's okay. Even if it solved a few problems, it'd be a vast improvement... and the only thing standing in the way is IBM. Unlike OS/2, which has so many fingerprints on it that IBM can't open-source it, IBM owns SOM. It's already been ported to several environments, such as AIX and System/390. Although SOM was among the shiniest bits of technology in OS/2, it's not tied to that OS. SOM was part of the foundation of OpenDoc and thus Mac OS X is a distant relative.
In fact, SOM is very much in the same position that REXX was, and IBM released Object Rexx to the community a few years ago.
I have a copy of the SOM/DSOM source code somewhere in the piles of CDs here at the bitranch. It was distributed to companies that signed up as OpenDoc developers (I'm tempted to add, "all three of us"). Without digging out the code for a full in-depth examination, I think I can safely say that it was clean enough at the time for IBM's lawyers to let it be shared with OpenDoc partners, which then included Apple and WordPerfect Corp. (There is also an OpenDoc Bible book contract in that folder, too, but the reasons
At last, some sense in this world. Despite its eccentricities SOM is just to good to leave mouldering on the shelf. The big question is, how to spark the interest of a champion inside IBM.
Can't you do basically the same thing using UNO or XPCOM?
We thought about that idea quite some time ago at netlabs.org, SOM was really unique and we think it would be valuable for other platforms as well. SOM got well documented by IBM, there are plenty of articles in IEEE magazines and there is a pretty good description of SOM in various patents IBM filed for SOM. There are also various books available about topics related to SOM. For that reasons we simply started implementing SOM from scratch.
Our rewrite of SOM, called NOM (Netlabs Object Model) is the base of our upcoming Voyager project. Basic functionality of the object model already works in prototypes. We also fixed some of the issues SOM had, for example the lack of garbage collection.
NOM doesn't provide all the functionality of SOM yet but we have everything needed for a start and new things (like DSOM/DNOM) could be added without problems. For sure the people working on it are coders that used SOM the past >10 years, so they know what works and what doesn't (thus we could fix some more annoyances SOM had).
We do not think that the source code of SOM is essential for our project to be successful. What we would love to see however, is that IBM releases the SOM related patents to the "open source patent pool" they once initiated some time ago.
"There isn't any technology available today that allows different libraries to freely interact with each other like that."
Wow. I guess those of us who have been using Free/Open Source CORBA ORBs for years to get IDL-defined cross-language (platform and network) objects are delusional. Or the author is.
I think the author confused the basic CORBA technology that (D)SOM and OpenDoc are based on with the desktop and document libraries built on top of them. IDL and cross-language objects are readily available in multiple implementations of CORBA and are widely used.