Using SOM for Tool Integration

By [[]]

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.