Using SOM for Tool Integration

By Christina Lau

Abstract

IBM's System Object Model (SOM) is an object-oriented programming interface for building binary class libraries. When changes are made to a SOM class, client programs that use the SOM class will not need to be recompiled. The SOM Toolkit provides a set of frameworks for building object oriented applications. These include Distributed SOM, the Persistence Framework, the Replication Framework, and the Emitter Framework. In this paper, we discuss our experience using SOM to handle the control aspects of tool integration.

Introduction

It is generally believed that software developed using object-oriented techniques is easier to use, maintain, and extend. SOM complements existing programming languages by providing a language-neutral model for developing object-oriented applications[1]. To use SOM, a developer defines the class interfaces in a language called Interface Definition Language (IDL). The developer then implements the methods in any of the languages that are supported by the SOM compiler. Finally, the classes are compiled into a dynamic link library (DLL) to be distributed to clients. Clients can use these classes directly or can override existing methods to develop their own applications . As long as the class interfaces remain unchanged, a new DLL can be redistributed to clients without requiring them to compile their applications. This full backward binary compatibility of SOM is best demonstrated in the building of the OS/2 Workplace Shell[4] .

As the computer industry is moving toward distributed client-server systems, tools and applications have to interoperate in a heterogeneous environment. Existing integra -tion techniques such as Dynamic Data Exchange[5] do not extend well into such distributed environments . The Object Request Broker (ORB), as defined by the Object Management Group (OMG), provides mechanisms by which objects transparently make requests and receive responses. The ORB thus provides interoperability between applications on different machines[2] .

Distributed SOM (DSOM), which is built on top of SOM, was developed to comply with the OMG's specification of the ORB[1]. DSOM makes the location of an object transparent to clients . This means that a client program will always use the same invocation to access an object regardless of whether it is local or remote . Therefore a tool can use DSOM to interact with another tool without knowing where the other tool is located .

In this paper, we will look at how to use the infrastructure in SOM to build and integrate tools. We will then look at how these SOM -based tools can be easily used to compose new tools . Tool Composition refers to the ability to build new tools by using existing tools . Finally, we will look at the notification aspects of tool communication.

Defining a Tool as Classes in SOM

The first step to use SOM is to define a class interface . Suppose we want to define an edit tool called Lpex in SOM . We begin by defining the set of operations that are supported by the tool . The result is then represented in an IDL:

#include <somobj .idl >
interface FileObject;
interface Lpex : SOMObject
{
   void etart(in FileObject fileObj);

   // This method starts the Lpez
   // editor on the file object
   void save(in FileObject fileobj);
   // This method saves the file object
   void goToLine(in FileObject fileObj);
   // This method positions the cursor
   // to a specified line
 };

The SOM compiler can then be run to produce binding files and an implementation template for the Lpex class . Code can then be added to the implementation template to implement the tool operations. For example, the start method implementation might contain code to display an edit screen.

Notice that each method takes a FileObject as an input parameter. The FileObject is another SOM object that is used to store file-related information. One of the attributes is a file name. We will look at FileObject in more detail later on.

Tool Invocation

A client can use offset resolution to invoke the methods in the Lpex class . For example, another tool program that is written in C++ can use the following to invoke a method in the Lpex class.

#include <FileObject .zh>
#include <Lpex .xh>
int main(int argc, char *argv[] )
{
  Environment *env;
  FileObject *file;
  Lpex *lpez;
 
  env = somGetGlobalEnvironment();
 
  // create an instance of FileObject
  // set file name to test . c
  file = new FileObject ;
  file->_set_fileName(env, "test .c");

  // create an instance of Lpex
  lpex = new Lpez;
  // invoke start method
  lpex->start(env, file);
  // invoke goToLine method

  lpex->goToLine(env,file);

  ...

  // Free the instances
  delete file;
  delete 1pez;
}

Offset resolution is the fastest way to invoke a method but is also the most restrictive. The client must know the name of the class and the name of the method at compile time. The client must also have the bindings (.xh files) for the tool IDL. Therefore, this scheme is most suitable for tightly coupled tools. An example of tightly coupled tools is an edit, compile and debug tool set. In the next section, we will show how to use metaclasses and dispatch function resolution to achieve more flexibility for less tightly coupled tools.