View source for Dynamite business systems with DSOM and OpenDoc

''by [[Larry Baptist]]''

Based on a presentation to The Enterprise Computing SIG of the ''Bay Area OS/2 Users Group'' (California)

John Mount, a systems manager at the Bank of America, is using DSOM and OpenDoc in a real-world, real-time, real-important business application. In this system, the Funds Dealer Support System, availability and reliability mean real bucks! And DSOM and OpenDoc are delivering the goods.

DSOM/OpenDoc are being used to deliver position and limits information to the five traders who make the Bank's position as it trades in the Wholesale Treasury Time Deposit Market. This system replaces an Excel spreadsheet-based system which took five minutes to show the latest trade. Now, for instance, the traders see more than one trade - they see their entire cash flow status and within two seconds!

Besides being fast, this system has two other OpenDoc and DSOM-based design points that make it extremely valuable and worthwhile. They are the system's ability to integrate with existing, legacy client/server systems and the end user's ability to create their own user interfaces.

Since us techies are wowed by performance, we'll dig into that part of it first....

==Fast, on a regular PC==
Using a 120 MHz Pentium DSOM server connected to a server running a SQL Server database, John sees a time lapse of one to two seconds between the entry of position and its appearance on all of the dealers' workstations. In that one to two seconds, there might be as many as 120,000 object interactions, involving 6,000 trades. It's scalable: John says it will scale up to 10,000 trades without much of a decrease in responsiveness.

Major scale-up needs will be addressed by using multiple DSOM servers in a distributed processing, workload sharing design.

==Easy legacy integration==
The DSOM Server interfaces with IMS on the mainframe which provides the data for a deal. It also provides the current limits, which are used to control trading risk. Thanks to DSOM, it was easy to interface with their mainframe system. SOM lets you interface objects from disparate programming environments, objects from different compilers, even different languages. DSOM lets you interface disparate platforms across a network.

==Reduced network traffic==
Another reason John is using DSOM is that it provides a point-to-point mechanism for communicating across the network, which puts less of a traffic load on it than the usual broadcasting method.

John plans to use multiple DSOM servers, but, so far, using SOM 2.1, he can't get it to work. OpenDoc doesn't work with SOM 3.0 yet, only 2.1. This is a pity, since SOM 3.0 is a major improvement over 2.1.

Still, John is getting his most fundamental DSOM-needs met. So, the good news is that it's adequate now and it'll get better, as things progress and OpenDoc gets rebuilt using SOM 3.0.

==OpenDoc - ideal UI==
It's not an accident that OpenDoc provides an ideal interface for the user. It was deliberately designed to be so.

People are used to the idea of using a document to carry out a task. It's a natural way to work. Realizing this, the Apple designers who initiated OpenDoc selected the document as the UI metaphor.

The document concept is extended by its being a container of containers, where each sub-container is an object (or, in VisualAge parlance, a part). Each container has its own data and program logic. The document provides a context and common environment for the parts, which can be designed as a logical hierarchical system of objects and/or can be independent, there-if-needed parts (such as a clock).

You can go even further and build multi-windowed apps and cross fertilize them by embedding pieces of one into another, just like using OLE embedding (in fact, you can use OLE, itself).

Actually, it's easier to do embedding in OpenDoc than OLE. The document is integrated whole due to the overall document being a container and supplying commonly used infrastructure for the parts. But each part is fully and comprehensively supported by its own tailored program logic, so the subcontainers are independent and integrated. These capabilities ARE special, but they aren't what makes OpenDoc such an unusual and cool UI.... it's the ability for the user to tweak, modify, and add to the parts in the user interface that's so powerful and spectacular!

==User-added/modified UI==
The individual user can tailor the parts for themselves, individualizing the system for their own needs.

Of course this ability to make such easy modifications works for the developers as well, making them highly productive. The system is readily modified (no recompiling for these changes) and the changed files can simply be distributed and copied into the end users' machines. Also, any end-user' PC becomes an instant test bed for acceptance testing by temporarily copying the new files into their machine and going at it.

The system is readily expanded by using embedding. It's a better embedding than Microsoft's OLE embedding, however.

Microsoft's OLE lets you embed part of one program into another. But generally to modify its manifestation in one program you have to go the original program. If, using Distributed OLE, the original program is distant, or unavailable, the embedded piece can't be modified.

OpenDoc is different. In OpenDoc, each part has its own "editor" which presents it, saves it, and lets it be modified by the user within the OpenDoc window itself. If it's a spreadsheet part, the user can add a new row or column, add a new calculation altogether, or put in individual changes to take care of immediate needs.

As the user makes changes, Bento's persistent-object storage services save the user's changes so that they are permanent.

==More user empowerment==
Had enough good news yet? Well, we're not done with user empowerment.... The components of a document are tied together and controlled by the OpenDoc Scripting Language. For OS/2, this is REXX or BASIC.

If the users have the skills and knowledge, they can edit the script for themselves, adding new pieces and changing how the system operates.

==Sophisticated apps==
John's users are very demanding - they want a lot of use configurability. OpenDoc has not been a handicap; John has been able to satisfy some pretty sophisticated requirements, such as:
* Fine-grained, user-defined fields in the window.
* User-defined interaction between fields.
* User-created docs can be embedded by the user in the subwindows.
Derrick Schneider, who works for John and who gave the presentation on the system, says, "This is not just hype, it really works". And he surely does know what he's talking about.

==Learning-curve payoff==
The system is in its second incarnation. The first version had only one component and leaned heavily on embedding. It took five months to develop (ouch!). The second version took three weeks (wow!). The difference was due somewhat to some first-time problems Derrick had making some things work and getting used to OpenDoc's idiosyncrasies. Also, he relied heavily on Apple' OpenDoc Guide, which is the best resource, but is written for Mac developers

Such is life on the learning curve. It's noteworthy, though, that once he got past the learning and immaturity stuff, the development efficiencies and reusability of the sub processes of DSOM/OpenDoc paid off big.

==Just the factoids, ma'am==
There are some very interesting factoids concerning OpenDoc:
* OLE components can be wrapped and used in OpenDoc parts.
* OS/2 OpenClass objects can be used in OpenDoc parts to implement the graphical user interface.
* Standard parts are available to support implementing parts containing the following data types: text, numeric data, audio clips, images, and videos.
Derrick Schneider discovered, though, that pioneering has it's unpleasantness (arrows and hatchets in the back)....

==All is not goodness==
Here's Derrick's list of the "Bad and Ugly"
* Currently, you can only use OpenDoc with SOM 2.1; Using multiple DSOM Servers has to wait until IBM delivers an OpenDoc based on SOM 3.0.
* Configuration is a nightmare. This is because everyone makes a different SOM and because the interface repositories are especially confusing.
* Documentation is sparse. (Note: I saw a new, very comprehensive-looking book on OpenDoc in Stacey's last week, entitled, BYTE Guide to OpenDoc, an Osborn McGraw-Hill book.)
* Diagnosing problems is almost impossible... You find yourself asking, "where in the process didn't something happen?" You do a lot of things like DosBeep to see what's happening at each point.
* VisualAge C++'s Visual Application Builder cannot create OpenDoc component (next release?)
* The IPMD debugger doesn't work well with OpenDoc - it's not seamless. 

==Credits==
Derrick Schneider presented, "Arrows in Our Backs - Pioneering OpenDoc"; to the Enterprise SIG on June 17, 1996. He previewed the presentation he gave the next day at Object World.

==More credits==
The following references were used in preparing this article:
* Essential OpenDoc, by Jessie Feiler and Anthony Meadow, Addison-Wesley Publishing Company.
* OpenDoc and Human-Computer Interaction, by Ralph M. Pipitone, in the September/October 1995 edition of Personal Systems magazine.
* The Essential Distributed Objects Survival Guide, by Robert Orfali, Dan Harkey, and Jeri Edwards, John Wiley & Sons, Inc.
* Building a SOM OpenDoc Part, by Robert Orfali, Dan Harkey, and Jeri Edward March 1995 issue of Dr. Dobb's magazine.

==Free stuff at Club OpenDoc==
The OpenDoc Toolkit for OS/2, NT, and AIX, as well as SOM Developers Toolkit for 2.1 and 3.0 are available through Club OpenDoc (download 'em or have 'em delivered).

You'll find this and other free stuff at http://www.software.ibm.com/clubopendoc/.

{{IBM-Reprint}}
[[Category:SOM Articles]]