White Papers

EsiObjects V4.0

Historical Overview

MUMPS (MGH Utility Multi-Programming System), known as M today, is an ANSI, FIPS and ISO standard programming language. It was developed at the Laboratory of Computer Science of the Massachusetts General Hospital in 1967 in response to a need for a language that would simplify and accelerate the development of applications.

Over the years, M grew in popularity as a fast, inexpensive database system that ran on mid-range computers such as Digital Equipment Corporation's PDP-11 series. Within the United States, it was sold primarily within the medical marketplace. However, outside of the United States, it was used to implement a diverse set of database applications.

Within the late 1970's, the MUMPS Development Committee (MDC) came into being and published the first ANSI standard through the X11.1 subcommittee. Since the 1980 standard, the language has gone through three revisions.

Today, MUMPS is a highly portable system that runs on all popular operating systems. It is used extensively where scalability is unattainable by competing technologies.

The Language View

For those readers that are unfamiliar with M, the following sections will attempt to explain the components of the language that are essential to the object paradigm. Readers familiar with M may want to go to the next section.

An Expression

Central to the M language is the concept of an expression. The diagram below illustrates the levels of an expression as defined by the M ANSI X11.1 standard.

M Expression Structure

A full description of an expression is beyond the scope of this paper. However, the expression is a powerful, highly recursive structure that forms the heart of the M language specification. For a complete view of the expression construct, please refer to the American National Standard for Information Systems - Programming Languages -M, ANSI/MDC X11.1-1995.


The diagram below places the expression diagram central to the commands. For the purposes of discussion, the commands have been organized into four general groups:

  1. Flow Control Commands

  2. Data Manipulation Commands

  3. I/O Commands

  4. System Commands

Language View of M

The box at the top represents a line of code in an M routine. It illustrates the structure of an M command. One or more of these command structures can be used to form a line of code. One or more lines make up a routine. A routine is an entity that can be filed under a name.

When discussing M commands, one must keep in mind that M was originally designed as an integrated programming and runtime environment that contained its own operating system. Consequently, the language contains all commands needed to build large application systems.

As in any procedural language, M contains Flow Control Commands. These commands alter the execution flow of the interpreter. For example:

Do Count

will execute the subroutine Count within the currently executing routine. The next command position on that line will be stacked. Once a Quit command is executed within the Count subroutine, the stack is popped and execution is returned to the next command (or argument) within the calling routine.

Data Manipulation Commands are those commands that are used to manage the data flow between disk storage and local storage. These commands will be discussed in The System View section.

I/O Commands are used within M to communicate with system devices such as dumb terminals, sequential devices such as tapes and cartridges, memory communication devices and many others. These devices are owned by the operating system. The programmer can Open a device to gain exclusive (sometimes shared) ownership of the device. Multiple devices can be owned. To use any one device, the programmer must specify the device with the Use command. This makes the device current and all I/O will be directed through that device until another Use command is issued. I/O is directed to the current device via the Read and Write commands. Once the device is no longer needed, it is closed and returned to the system pool.

System Commands are low-level commands that are restricted in use. Generally, the M system vendor uses them since they are used to directly access computer memory and disk blocks. These commands are used within system level utility programs.

System View

The diagram below superimposes the language view on top of System and Process Spaces. This diagram illustrates how the language elements interact with the system components.

System View of M

The Process Space at the top of the diagram contains various structures important to the M programming and execution environment.

At the top, the routine discussed previously resides in the process space. A routine is always associated with an execution context since it is the blueprint for interpretation.

On the left, devices are accessed through the I/O commands. When opened, these devices are owned by the process. When not owned, the system owns them.

More importantly, the right side of the diagram illustrates the data manipulation components of M. A Local Symbol Table is maintained within the process space. It stores local symbols (arrays) that conform to the standard array structure. Below that, in System Space is the Database. This environment stores persistent arrays that are logically identical in structure to the local arrays.

These two structures are important to the storage and processing of data. Because the same logical structure is supported in both environments, data in the database can be brought into local storage for manipulation without conversion. Once modified, it can be moved back to persistent store.

The Physical Database View

Obviously, the Database component is central to the M environment. To understand why M has evolved as a fast, scalable database system, one must understand some details of its physical implementation. These details are not specified in the ANSI standard. However, they are commonly implemented by most M systems. Most M systems offer the following database features:

  1. Arrays are implemented using self-optimizing (balanced) multi-way tree structures.

  2. Efficient key compression minimizes the physical structures of the database and maximizes access to data records.

  3. Large in-memory cache structures provide fast access to frequently accessed data.

  4. Access block pointers minimize searching through pointer structures.

  5. Before image journaling permits rollback in the event of system crashes.

These features have proven to be crucial to extending M into the object domain.

M as a Foundation for Object Oriented Databases

M inherently contains some fundamental features that are desired features of Object Oriented systems. Here are the most important:

  • Late binding at runtime due to indirection and the interpretive nature of the language.

  • Hierarchical database based on a persistent array structure.

  • Automatic garbage collection (when tree nodes are killed, any blocks freed up will be returned to the free block pool).

  • One polymorphic data type.

The EsiObjects project, described in the next section describes ESI's approach to migrating M to objects.

EsiObjects Goals

Extending M Technology into the Future

Overview of the EsiObjects Project

The following sections will outline ESI's EsiObjects (pronounced 'easy objects') project goals, the motivation for investing in this technology and the philosophy behind the development effort. Additionally, the last section describes the object model, language and middleware requirements needed to migrate M to modern, state-of-the-art object technology.

Project Goals

The following are EsiObjects’ project goals:

  • Build an ANSI Standard M language compiler with Object-Oriented (OO) extensions.

  • Offer an extensive development and runtime environment on Microsoft’s Windows platforms.

  • Integrate features to assist in the migration of heritage M application systems.

  • Leverage the underlying M strengths into an Object Oriented database system using the Object Data Management Group's standard Object Oriented Database Management System (OODBMS) specification.

  • Simplify development by providing the developer with libraries of reusable foundation and business framework classes.

  • Provide a high performance runtime environment.

  • Access server side objects via commercial-off-the-shelf packages such as Visual Basic, Delphi, C++ and Java via open, standard middleware packages

  • Expose server side objects to the enterprise via standard, high performance, open client server and Internet technology:

  • Fundamental TCP/IP Gateway

  • Java Proxy Classes using standard TCP/IP secure socket technology

  • Common Object Model (COM) Proxy

  • Common Object Request Broker Architecture (CORBA) middleware technology.

Development Motivation

The EsiObjects project is the result of over 10 years of research and development. It was developed in response to a strong movement toward Object Orientation (OO) within the Information Technology (IT) industry.

The IT industry has undergoing a paradigm shift. Traditional procedural programming and relational databases are giving way to OO Programming and OO Database Management Systems (OODBMS). The OO paradigm introduces a different way of observing and modeling the target problem domain. It doesn't replace everything we've learned, it enhances it by using the best approaches of the old, combined with powerful new concepts such as dynamic binding, encapsulation, polymorphic behavior and inheritance. Additionally, rather than replacing the traditional programming and database ap­proaches, it will, over time, switch roles with them. The OODBMS will provide a cen­tral repository for data simply because it organizes data in an intuitive way. Having this intuitive design at the center of the database, different views into it can be developed easily, including a relational view.

From ESI's perspective, the M language and its underlying technology were natural building blocks upon which the object paradigm could be superimposed. In the tradition of perpetuating the good aspects of M Technology and eliminating (or hiding) the undesirable aspects, ESI created the EsiObjects system. Simply put, we concluded that M should follow the unmistakable lead of the industry - move to objects!

Development Philosophy

The EsiObjects product has been built on a sound Research and Development foundation. The rules were simple. Do it right - if it isn't right, do it over! We feel that it is very important to have a solid foundation to build upon. EsiObjects V4.0 is the culmination of that philosophy.

Many philosophical decisions affected the outcome of the current product. However, one requires some explanation. Why did ESI choose to implement this system at the language level? Why not implement it at the application level?

The reasons are quite simple:

  • First, we wanted to bring everything we learned about M and Object Orientation to the M community through the ANSI standardization process. After all, OO is fundamentally a language issue.
  • Secondly, it pushes powerful functionality down to the language level and makes it available in a flexible context for the programmer.
  • Third, it provides backward compatibility to the traditional language elements in addition to extending the language into the object domain. This offers the technology a migration path!
  • Fourth, it gave ESI the independence to implement any new features without waiting for M vendors.


Central to EsiObjects development is a strict adherence to Model-View-Controller (MVC) concept. Simply put, this concept enforces a separation of data (the model), from the interface primitives (the controller). These two sides are brought together into individual views as illustrated below. These views reflect different ways of looking at the same data.

As outlined in the first section, M contains all the commands to do I/O and database programming. Unfortunately, the integrated nature of M programming and the requirements for speed, led M programmers to violate the MVC paradigm. When the GUI revolution occurred, most organizations had to separate the model side from the controller side at great expense.

EsiObjects Features

Building a Robust, Extensible, Scalable Object Oriented System

EsiObjects Features

The EsiObjects Development Environment has been designed for productivity. The client side consists of a graphical environment written in C++. All products of the development environment are stored in the M server.

The development environment offers the programmer a comprehensive array of capabilities designed to enhance productivity and streamline full life-cycle software engineering. The following lists some prominent features of EsiObjects.

  1. Integration of class development tools into Rational Corporation’s Rose design tool suite. Libraries, Classes, Interfaces and services (methods, properties, events and relationships) developed in EsiObjects are exportable to Rose. In addition, designs created in Rose are importable into EsiObjects. The goal is to offer the user a set of tools that will cover all aspects of the software-engineering life cycle.

  2. Personalized development environment. The programmer can modify the look and feel of all editing environments as well as create templates for each development object type. For example, if the programmer wants template code or information created within a method or property at creation time, the Options entry in the Tools menu permits this sort of customization.

  3. Multiple session support. Within the framework of true client server support, programmers can maintain multiple distributed development environments. Switching between systems is as simple as pointing and clicking.

  4. Support for concrete and virtual libraries that are used to partition classes at logical boundaries within an application. Classes can be linked between libraries with full inheritance.

  5. Full support for event handling through three commands (Event, Watch and Ignore). Both push and pull models are supported. Programmers can create event handlers that can be linked to an event via the Watch command. When the event is fired, watching objects are notified and the call back is executed. Event processing is absolutely a requirement to object oriented systems. Since most of EsiObjects is built using all these features, event handling is fundamental to all reusability provided by EsiObjects.

  6. A Visual Development Environment (VDE) based on the common look and feel of Visual C++ and Visual Basic. All components of the environment are designed to increase productivity through workflow enhancements. For example, the VDE contains a Session Browser window that holds and displays all libraries and folder structures for quick browsing and editing. Additionally, as a programmer, you can add hierarchical work folders to store objects being worked on from any level within the library structure. All EsiObjects menu operations are applicable to each folder.

  7. All code modules (methods, properties and event handlers) support version control with locking and unlocking of the code objects.

  8. Comprehensive search and edit capabilities. All code and documentation objects can be searched by string (* and ? wildcards supported), date range and programmers initials. Hits are recorded and displayed in a work folder. Double clicking on a hit will invoke the method, property or event editor with the found string highlighted. Additionally, all the functionality of the EsiObjects systems can be applied in the same way it is in normal work folders.

  9. Full support for exporting and importing libraries, classes, interfaces, methods, properties or events to external flat files.

  10. Support for Bulk Transfer of objects. That is, when a client makes a request from the server for an object, the programmer can stipulate that the object and its selected properties be collected on the server and returned to the client minimizing network transfer. The bulk transfer of cells, lists, named value lists, tables, stream and text objects are supported.

  11. Comprehensive Object Browser that lets the programmer browse through objects for the purpose of viewing and modifying its contents (variables and relationships).

  12. Interactive Debugger based on the Object Browser that supports viewing an object execution context through variable and code panes. Like the Object Browser, the debugger contains a command shell for the purposes of executing code and evaluating expressions within the context of the currently browsed object. Additionally, it contains an Object Browser tab sheet that lets you interactively browse any objects within the execution context.

  13. Variable Scoping and Declaration. EsiObjects provides true variable scoping that insures encapsulation within the object and execution contexts. Additionally, a Variable Editor permits variables to be declared with initialization and binding attributes. For example, variables can be defined as initialized automatically or manually. Automatic initialization means that when an object instance is created, the variable is also created and bound to a value. The value can be any specified expression or another object. Variable declarations are not required - they can be dynamically created. In this case the compiler will issue a warning.

  14. Library of reusable classes such as:

    • Superset of the ODMG collections (Sets, Bags, List, etc.) with associated Iterator classes for each collection class.
    • Immutables such as date and time classes.
    • Data Manager class that is used for instance extent (indices) tracking. Search criteria and filer classes provide the rich reusability required for searching the indices. The Data Manager object uses the Dictionary collection to store and manage indices. The Dictionary uses EsiObjects event processing to automatically manage update of index when the associated property of the indexed object is modified.
    • Name Pools that can be used to form instance hierarchies with full inheritance. Name pools are shared objects and can be passed between objects. Name pools take advantage of polymorphic behavior for the purpose of generalizing and application. Hierarchical name pool objects can contain the same variable name, but with different values. Switching between the pools is as simple as setting the $Pool special variable to the pool you want activated.
    • Transport Types that offer bulk transfer capabilities that minimize network request.

Required Models

Extending M into the Object Domain

Object Oriented Requirements

ESI's effort to apply object extensions to the M environment can be categorized as follows:

  • Models required for a fully functional object database system.

  • Language enhancements needed to programmatically access the functionality.

  • Middleware required for exposing EsiObjects to the enterprise.

Illustrated below is a diagram of the M environment. The server side of EsiObjects is largely implemented and executes in the M environment. The object model is implemented using M arrays and code. The language enhancements are implemented via the EsiObjects compiler. Finally, to expose database objects to the enterprise, a TCP/IP Gateway has been implemented.

The Client and Application Server sides of EsiObjects contain all the software written in C++, Java and Visual Basic to support sophisticated development and runtime environments.

EsiObjects Model View

Required Models

To evolve M to an object oriented database system required the implementation of a true object model. The EsiObjects model was originally based on the Smalltalk model.

Secondly, event processing was added to the object model. The addition of event processing truly enhances the object model, extending it to real world applications.

Object Model

The M language implements one data structure, balanced, multi-way trees, referred to as sparse arrays. Arrays can exist locally to a process or as persistent structures on disk that are globally accessible. The array is used to implement the object structure that can be viewed as an encapsulated symbol table. The symbol table is used to hold all the data that gives an object its state.

Objects are central to the EsiObjects system. Everything in EsiObjects is an object, including EsiObjects itself. A strict definition of an object is religiously adhered to.

The EsiObjects object model is based on the classification approach. There are two types of classes within EsiObjects:

  1. Concrete Classes
  2. Virtual Classes

Concrete Classes

Concrete classes support the instantiation of fully encapsulated objects that have well defined support of interfaces, methods, properties, events and variables.

EsiObjects Class Structure

A Class is an object the holds the definitional information about an instance. Much of the functionality of an instance is inherited from the class and its parents that created it. Classes are instances of a class called Class, which is the class of all classes.

First, an instance of a class contains the raw data that makes it what it is and gives it state. It is addressable by an identifier that gives it a unique identity called an OID (Object IDentifier). Once an instance is created, it is always associated with the class through a 'kind-of' relationship. The instance inherits all the class’s interfaces and services that are a part of the interface (methods, properties, relationships and events). By default, all classes have a default Primary interface. If you want factory constructors and destructors, you must create a Factory interface. Interfaces serve to organize the services for specific views into the instance. The example above adds the Admission interface. It would presumably contain only the services needed for the patient admission view of the class Patient.

The primary interface would contain all the basic services for Patient. Factory contains those class services needed to create an instance of Patient. This is where the constructor and destructor live. If they exist, they are automatically invoked when an object is created or destroyed respectively.

Any number of Interfaces can be created for each class. Organizing services into interfaces lets you remove sensitive or internal functionality from the Primary interface. Organizing services into interfaces also allows for cleaner functional grouping. Another benefit is that having specialized interfaces reduces the prospects of multiple inheritance conflict.

Virtual Classes

Virtual classes have content, but objects belonging to these classes do not have state. They are lightweight and immutable. They are used to wrap existing structures within a legacy M database. They provide the façade that is supported by all the tools. However, the content of the object is the data structure of the legacy environment. Needless to say, these objects are instrumental to migrating legacy applications to object technology.

Nested Classes

A nested class shares the same namespace as its parent class. It is an integral part of its parent's namespace. It does not inherit any of its parent's services. However, it can inherit from any other class in any library by linking it to that class.

In the Concrete Classes section above, the diagram illustrated using an interface to add Admissions services. Patient admission information is better defined within the context of the Patient class. Nested Classes would be used to accomplish this.

Event Model

EsiObjects not only extends the underlying database model with a standard object specification, it adds full event handling capabilities to the model. Objects must have a non-procedural way of communicating changes of state to other objects. The event model offers an easy-to-use push, as well as pull, event-processing model. Full event processing in conjunction with a standard data model adds up to extensibility.

The event model is not only available to you as a programmer; it is fundamental to the operation of EsiObjects. It is used in numerous locations to communicate events that other objects are interested in watching.

Required Language Enhancements


A central concept to OO is messaging. Traditional M communications between modules is through variables or parameter passing via the DO command or Extrinsic Functions. However, in an OO environment, objects communicate with each other via messages. This communication must be based upon a weak, not a strong binding.

The EsiObjects messaging construct is as follows:



BaseObject is the initial object the message is being sent to.

Callref is the name of a method or property to be executed.

  • MethodName(ParameterList) is a value producing construct . Returned values are placed in a special variable $RETURN.

  • RelationshipName(ParameterList) is a value producing construct. Relationships can have a cardinality of one to one or one to many. Additionally, a relationship may have an inverse relationship. Returned values are placed in a special variable $RETURN.

  • PropertyName(ParameterList) is a unique structure. Properties are executable but act like variables. The programmer can define one to nine accessors (code) that are mapped to the language construct being used. They are:

  • Assign - accessed when a message is used on the left side of the SET command.

  • Value - accessed when a message is used on the right side of a SET command.

  • Get - accessed when a message is used in the first parameter of a $GET function.

  • Data - accessed when a message is used within the $DATA function.

  • Order - accessed when a message is used as the first parameter of the $ORDER function.

  • Create - accessed when the CREATE object command is executed.

  • Query - accessed when a message is used as the parameter of the $QUERY function.

  • Kill - accessed when the KILL command is executed.

  • Validate - accessed when the EsiObjects $VALIDATE field value function is accessed.

In other words, the programmer now has the power to totally change the meaning of M language elements based upon the object context it's in!

These executable objects are followed by optional parameter lists and can be chained where the preceding Callref produces an object id that acts as its BaseObject.

The full message syntax is functionally loaded and beyond the scope of this paper.

Symbolic References

As stated above, the M language supports one data structure, the array. It defines the scope of the array as simply local to the current process or global to all processes within a certain class of users.

EsiObjects extends the scoping of symbols. Scoping in M is based on job context. EsiObjects bases a symbol's scope on the concept of an object. The traditional % symbol name has been extended to include a scoping indicator, so as to make the symbols scope obvious to the programmer. Scoping of symbols is fundamental to encapsulation.

The following represents the symbol structure:


EsiObjects supports a number of symbol scopes. Here are a few:

  • Temporary - Variables are confined to a single method call. The temporary variable Hello is referenced as T%Hello.

  • Parameter - Variables are identical to temporary variables in scope. A variable Hello passed in via a parameter would be referred to as P%Hello. It has the same scope as a Temporary Variable.

  • Instance - Variables are confined to the scope of an object, and are specific to that object. A variable Hello instantiated within the context of an object would be referred to as I%Hello.

  • Class - Variables are physically confined to class objects and inherited by an instance of the class. If a class object has a variable Hello, then any instance of that class can refer to C%Hello because it is inherited. Class variables are typically used only by the class methods to create in­stances.

  • Universal - Variables are available across the scope of all objects. They are traditional un-New'ed local or global variables. A universal variable Hello would be referred to as U%Hello. The use of universal variables is generally discouraged, but occasionally necessary.

  • Name Pool - Since objects can be viewed as autonomous symbol tables that hold other symbols and the symbol name serves as a handle to that table, it follows that these tables can be linked into hierarchies. Inheritance rules apply to these hierarchical tables. A special syntax has been added to reference any one of these symbol pools. N%(I%Parts)Quantity would refer to the symbol Quantity in the Name Pool pointed to by the Instance variable I%Parts.

  • Constant - Using the CN%Pi construct will force the compiler to treat Pi as a constant.

Support Functions and Special Variables

As a consequence of extending the M language, several functions and special variables were added to support the programmer.


Several commands have been added to the language. Two groups are particularly important.

First, the CREATE and DESTROY commands are used to respectively create and destroy objects.

The second group contains three commands that implement event processing in EsiObjects. ANSI M does not have an event processing model. For object processing to be complete, event processing must be a part of the model. Three commands were added to the language:

  • EVENT - Fires a specific event to be acted upon by objects watching for such an event.

  • WATCH - Takes out a watch on events or property changes.

  • IGNORE - Turns off watches for specific events.

Required Middleware

Illustrated below, the middleware services integrate the presentation tier, the application server and data server tiers into one homogeneous computing environment. These services include:

  • TCP/IP Gateway

  • COM and Java Proxies


EsiObjects Development and Runtime View

COM and Java Proxies

COM and Java Proxies are based ion the TCP/IP Gateway. They provide the connectivity between a Windows or Java based client (or application server) and the Database Server. Both Proxies are generated by the EsiObjects system based on the server side object interfaces you want to expose. A duplicate of those object interfaces are made available to the client or application server with all the TCP/IP connectivity built in.


As an optional add-on, a CORBA ORB is available with EsiObjects (the ORB implements the communications component of the OMG CORBA ORB specification only). It was developed for the Government Clinical Patient Record (G-CPR) program and is written in EsiObjects. It acts as a client and server ORB.

A complete Interface Definition Language (IDL) compiler comes along with the communications ORB. CORBA interface specifications can be defined within a text document and then compiled into EsiObjects Libraries, Classes, Interfaces, skeletons and stubs. The IDL compiler is written in C++ and EsiObjects.

Additionally, a Management Console makes all ORB configuration and management functions available to you via a Java GUI.

EsiObjects Development Environment

A State-of-the-Art Development Environment

EsiObjects Class Development Environment


EsiObjects Client Environment

The EsiObjects client development environment can be viewed as two layers. The EsiObjects Container Environment consists of those general windows or window panes needed to support the EsiObjects Class Development Environment (CDE). The CDE contains all the tools needed to develop the definitional components of an object oriented database application. These tools can be grouped functionally into the following categories:

  • Session Browser tools needed to help facilitate your workflow.

  • Class development tools needed to create all the definitional components of an object.

  • Tools needed to test and debug your application.

  • Import and Export tools needed to transport the application components to and from external systems for sharing or backup.

In terms of the Model-View-Controller paradigm described at the beginning of this paper, EsiObjects provides the tools needed to develop the model side of an application.

EsiObjects Container Environment

The client side of the Class Development Environment is based on Microsoft Windows. Fundamental to the EsiObjects environment is a Windows container. A container provides all the support for windows implemented within that container. The EsiObjects container contains several windows that support the CDE set of tools or any other tool set that may be developed in the future. These support windows are:

  • Main - This is the main EsiObjects window. It contains a menu that lets you access the components listed below. It also gives you access to printing and help services.

  • Session Browser – This window contains tab sheets that contain graphical representation of libraries, classes, state variables, interfaces and services as well as folders defined in EsiObjects.

  • Output – This window contains three tab sheets. The Build sheet is used by the system to display information about compiles, syntax checks, etc. The Debug sheet is used by the system to display system information. The Output sheet is available to you for displaying application level information. It provides a convenient way to track execution when testing your application among other things.

  • Documentation – This window is used by the system to display documentation for the currently selected object. The text is stored in Rich Text Format to be compatible with other Microsoft tools such as Word.

  • Session Control – This window allows you to establish connections to one or more EsiObjects servers.

  • User Options – This window contains three tab sheets that allow you customize your development environment.

Each of these components will be explained in the Container Support Environment section further on in this guide

EsiObjects Class Development Environment (CDE)

The EsiObjects object model is based on the classification system. The CDE environment contains all the tools needed to develop and test these classes. Class development tools available in the CDE are:

  • Browser tools designed to let you migrate all components within an EsiObjects session. You use browsers to find the definitional object you want to work on.

  • Editors are tools that let you modify an object found through the Browser.

  • Debugger is an interactive tool that lets you step through the execution sequence of your application. It automatically displays the stack and symbol table states after each step.

  • Transport tools are used to transfer definitional level and instance level data and code between environments via external files. The transport tools can be used to share your work within a project or to back up it up for safekeeping.

EsiObjects Server Environment

When the EsiObjects client is started up on a PC and a session connection is made to a process that is started up on the server, an environment object is created in the server process. It is an instance of the class ESI$ServerEnvironment. The client owns the environment object on the server. The environment is always active as long as a session connection is maintained and can be referenced via the $ENVIRONMENT special variable.

The environment object is always instantiated as part of the EsiObjects session connection. There is only one environment object associated with a session. EsiObjects supports multiple development sessions. That is, a programmer can have multiple sessions defined and have an EsiObjects environment associated with each session. This provides a flexible approach to development since browsers and editors can be brought up simultaneously while attached to separate sessions.

The Main Window

The Main Window Explained

This is the main window of the EsiObjects environment. It appears whenever the system is launched, and serves as the primary EsiObjects work area.

EsiObjects Main Window

The Main Menu contains cascading menus of all the functions available in EsiObjects. The menus will always look alike. Only those commands that are applicable to the currently selected item in the Client Area will be highlighted and activated. All others will be grayed out. The Main Menu contains all commands that are applicable to a selected object where popup menus generally contain only the most frequently used commands.

The window's Client Area is where EsiObjects places all visual objects launched from a browser or menu such as the method editor, property editor, etc.

The Session Browser is contained in tab sheets that contain structural library and folder views of EsiObjects.

The Main Window ToolbarMainWindowToolbar provides quick access to a variety of important functions that also appear on the Main Menu.

The Documentation Window always contains the documentation for the item selected in the Client Area.

The Output Window contains the Output, Debug and Build tab sheets. The Output sheet is available to you as an area to output information via the $ENV.Ouptut message. The Debug area is used by EsiObjects to display errors and the Build sheet is used by EsiObjects to display compile and syntax checking information.

The Status BarMainWindowStatusBar on the bottom of the EsiObjects window provides information on the current status of EsiObjects.

Main Window Menu

Main Menu Commands

The Main Menu of EsiObjects is designed to display all functions available to EsiObjects no matter what object is currently selected. In other words, the Main Menu will always look the same and have the same commands on them. Only those commands that are active for the selected object will be highlighted. All other commands will be grayed. Good object oriented systems present a common view to the user, hiding the complexity from them.

Main Menu Add-in Programs

Add-ins are supplemental programs that extend the capabilities of EsiObjects by adding custom commands and specialized features.

You can obtain add-ins from independent software vendors, or you can write your own. Writing your own will be addressed as a separate topic.

Main Window Toolbar

The Main Window Toolbar provides quick access to a variety of important functions. Most of these functions can be performed in other ways; the toolbar is one of the most convenient ways to get at them. It can be shown or hidden from the Main Window's View menu, by selecting the Toolbar item.

Main Window Toolbar

Main Window Status Bar

The Status Bar on the bottom of the main window provides information on the current status of EsiObjects. It can be displayed toggling the main window's View | Status Bar command.

Main Window Status Bar

The Session Browser

The EsiObjects development environment is designed to provide all the necessary tools needed to develop an object oriented application.

The Session Browser is a window that contains tab sheets. Each tab sheet represents a connected server side session. It contains a graphical representation of all library structures within EsiObjects as well as work folders that you created to hold work. Browse operations are permitted on each structure. These operations let you find objects easily within the main structure.

Work folders let you create hierarchical folders containing pointers to specific objects within the main structure at any level. The following is a picture of the Session Browser.

EsiObjects Session Browser

The Output Window

The Output Window appears as a resizable window. It can be resized and docked to any of the four edges of the Main Window. The Output Window contains three tab sheets: the Output, Build and Debug sheets. The Output sheet is accessible by the programmer. It is useful for debugging as well as other tasks.

EsiObjects Output Window

The Build pane is used by the EsiObjects compiler and syntax checker to output compilation and syntax check messages. The Debug sheet is used by the EsiObjects system for tracing and debugging.

Documentation Window

The Documentation Window is where all documentation is entered and displayed for the object currently selected. For example, if a method is selected in the Session Browser, the documentation for that method will automatically be displayed in that window. All text-editing operations are common to operations commonly found in a word processor. The text is stored in Rich Text Format (RTF). Associated with the window is a Toolbar and Popup Menu that let you perform fundamental operations.

EsiObjects Documentation Window

Session Control

As illustrated below, Session Control allows the EsiObjects client to connect to a supported M database via a TCP/IP connection. Access to multiple databases on different servers through different sessions can be established on one client.

Session Control lets you maintain connections to multiple servers. When you connect to a session, all library and folder structures available in that session are displayed on a tab sheet within the Session Browser. The session name is displayed on the tab. The tab sheet that has focus identifies the active session. Clicking on a session tab lets you quickly switch between sessions.

EsiObjects Session Control

User Options

User Options sheets let you create template information for documentation and source code associated with each method, property or event. A User Options property form lets you customize your user environment. It consists of three tab sheets: the User, Format and Preferences sheets.

User Tab Sheet

The illustration below describes all components of the User tab of the Options property sheet.InitialText.MacroSubstitutionGuide

User Options User Sheet

Format Tab Sheet

The Format sheet lets you select how the text is rendered to you, that is, the font and size of the text. The Preferences sheet lets you tailor your EsiObjects operating environment to your needs. Illustrated below is the Options property sheet Format.

User Options Format Sheet

Preferences Tab Sheet

This sheet allows specific options to be activated by checking the appropriate check box. Options that are checked are enabled. Options that are not checked are disabled.

User Options Preference Sheet

Help Documentation

Help Documentation Explained

The EsiObjects Help documentation is available as Adobe Acrobat files. There are four guides and one tutorial that are designed to cover all aspects of using the EsiObjects system. The guides and tutorial are described in the following sections.

Administrator’s Guide

Assumptions about reader:

  • Have administrative skills at the OS and M levels.
  • Has a PC user skill.

Goals of this guide are:

  • Explain the EsiObjects client-server Environment.
  • Describe how to use MSM’s RVG capability.
  • Describe how to set up and use EsiObjects for each of the supported M systems: MSM, DSM, Cache and GT.M-I86-Linux.

Language Reference Guide

Assumptions about reader:

  • Knows object oriented concepts.
  • Has programmed in other languages.

Goals of this guide are:

  • Explain all code body structures.
  • Describe the syntax of the language.
  • List and describe all Commands.
  • List and describe all Functions.
  • List and describe all Special Variables.
  • List and describe all Operators.

Programmer’s Reference Guide

Assumptions about reader:

  • Knows object oriented concepts.
  • Knows the MUMPS language plus the EsiObjects extensions.

Goals of this guide are:

  • Give an overview of EsiObjects.
  • Describe how to use Objects.
  • Describe how to integrate Objects.
  • Outline the Guidelines for using Objects.
  • Describe client-server Programming using EsiObjects.

Tools Guide

Assumptions about reader:

  • Knows object oriented concepts.
  • Knows how to use PC applications.

Goals of this guide are:

  • Give an overview of EsiObjects Environment.

  • Describe each component of the EsiObjects Environment and how to use it.

  • Describe each component of the Class Development Environment and how to use each one.

  • Describe the Transport tools and how to use each one.

Getting Started Tutorial

This tutorial is delivered with EsiObjects. It covers OO concepts and teaches you how to use the EsiObjects tools by actually constructing a small Customer application.

Interoperability Overview

Illustrated below are all combinations of the EsiObjects middleware solutions. The possible combinations are:

  • The Development Stations interoperate with the development environment on the Database Server through the TCP/IP Gateway. This connectivity is controlled through sessions.

  • The Windows Runtime Stations interoperate with the database through the COM Proxy. The COM Proxy is identical in operation to the Java proxy. The only difference is that it is exposed as an ActiveX control to the client.

  • Internet Browser Stations interoperate with a Java Application Server. The Java Proxy Classes that reside on the server are proxies for classes that exist on the Database Server. Embedded in the Java methods is the TCP/IP connectivity necessary for communications between the Application and Database Servers.

  • The optional EsiObjects CORBA ORB permits enterprise wide interoperability. The EsiObjects ORB can act as a client to external ORBs or as a server to those external ORBs. It exposes objects within EsiObjects as CORBA objects to the enterprise. The EsiObjects CORBA implementation comes with an Interface Definition Language (IDL) compiler that will compile standard IDL specifications into EsiObjects class definitions. Additionally, the ORB has a Management Console GUI front-end that lets you configure, maintain and test the ORB connections.

EsiObjects Interoperability Solutions

Instance Management Environment

The Instance Management Environment consists of all functionality dedicated to the management and integrity of instances created from classes defined in the CDE. This environment is based on the Object Data Management Group (ODMG) specification for an Object Oriented Database Management System (OODMB). This specification implements all those things necessary for managing instances: Extent Tracking (an integral part of EsiObjects V4.0), Indices control and the Object Query Language (OQL) that is based on SQL2 and is specified as a functional language.

The Instance Management Environment contains a client side GUI that allows you to construct OQL statements by simply dragging and dropping (based on the way Access does it). The collected results can be fired into an ODBC interface.

EsiObjects and the Open Source Initiative

The Open Source Initiative is a phenomenon that is at the foundation of the Internet. Software products that have grown out of this initiative like the Linux operating system and the Apache Web Server have evolved into robust, highly functional software systems. They attained this status by making the source code freely available to the world and not charging runtime fees.

The full EsiObjects V4.0 system will be made available under Open Source. ESI will be responsible for insuring solid version releases, however, all source code will be available. EsiObjects and its derivative products will be divided into two levels where the responsibilities of ESI and Participants will differ.

EsiObjects CDE and IME

The main components of EsiObjects will remain the responsibility of ESI. ESI will be responsible for integrating any external enhancements to the product. That responsibility will include deciding whether the enhancement is in common to all users and to thoroughly test, document and release it if it is.

There are three first level EsiObjects components.

  1. EsiObjects Core - This consists of M Routines and Globals. These routines and globals implement the Object Model (based on Smalltalk), Compiler (full 95 ANSI plus all object extensions), TCP Communications (redirector, etc.), Event Processing Support (model side implemented by EVENT, WATCH and IGNORE commands), etc.
  2. Class Development Environment - There are two parts to this - the Client side development environment written in VC++ and the model (server) side contained in the ESI library. EsiObjects supports libraries that let you organize Classes in some arbitrary fashion. The ESI library holds all the classes that implement the EsiObjects class development and runtime environments. Everything in EsiObjects is an object including itself. Also included is a VB project that implements bi-directional transfer of models between Rational Rose and EsiObjects.
  3. Instance Management Environment - This library contains the first pass at implementing the ODMG specification for an ODMS. It's a work-in-progress. However, this specification implements all those things necessary for managing instances: Extent Tracking (built into V4), Indices control and the Object Query Language (OQL) that is based on SQL2 and was specified as a functional language. This has a VB client project with it that lets you construct OQL statements by simply dragging and dropping (based on the way Access does it). The collected results can be fired into an ODBC interface.

Combined, these form the true core of EsiObjects. Everything will be released under the Open EsiObjects License (including internal and external documentation sources). ESI will have special responsibilities for this level.

EsiObjects Derivative Works

The second level of source release consists of derivative works, complete or incomplete. Included are:

  1. The Base Library (Immutables (Time and Date stamps), DataManager, Criteria and Collections including List, Array, Set, Bag, Log, Map, MultiMap, Dictionary, etc.) This library is currently a part of the EsiObjects distribution and will continue to be. It contains all the reusable foundation classes needed to jump-start an application.
  2. The Business Framework and Business Objects libraries that were built over the years based on Gamma's et. al book Design Patterns. The framework contains the common components of an application. The business objects are those objects used in an application such as Address, etc.
  3. Application Repository Tools (ART) Libraries. These are all the tools that permit extraction of File Manager DD's and generation of what we call Surrogate Classes (surrogate of FM Files and Fields). They create a façade into a File Manager database.
  4. The CORBA ORB permits enterprise wide interoperability. The EsiObjects ORB can act as a client to external ORBs or as a server to those external ORBs. It exposes objects within EsiObjects as CORBA objects to the enterprise. The EsiObjects CORBA implementation comes with an Interface Definition Language (IDL) compiler that will compile standard IDL specifications into EsiObjects class definitions. Additionally, the ORB has a Management Console GUI front-end that lets you configure, maintain and test the ORB connections.
  5. The COAS Server is a standard API for extracting observation information from a clinical database. Currently this API interoperates with the VA’s VISTA System.
  6. Object File Manager Library, which contains classes that replicate File Manager in OO form.


EsiObjects is a sophisticated Object Oriented Database System based on an integrated multidimensional database system and the Object Data Management Groups OODBMS specification. It contains extensive productivity tools for development of applications complemented by mature, re-useable classes. It provides the most popular middleware and interchange services such as CORBA as well as COM and Java Proxies based on the TCP/IP gateways.

The EsiObjects object model supports virtual objects that are used to wrap legacy databases as well as real objects. The ability to wrap existing databases and the ability to create real objects within the same environment offers a migration path unrivaled by the competition.

Stormwoods LLC ©
For more information, please view related sites:

Stormwoods LLC || Out of the Slipstream|| GT.M