Chapter 1: Introduction

1.1 Overview

MERANT provides support for Object Request Broker (ORB) technology as part of the CORBA standard.

1.1.1 CORBA as a Solution

When developing an application that is to be distributed across a range of different platforms, you need to consider the following issues:

CORBA has been developed to provide a solution to what is a complex problem.

1.1.2 The CORBA Standard

The goal of the CORBA standard is to automate the handling of a number of distributed application issues. For example:

By releasing programmers from these issues, they can be free to focus upon the development of the distributed business logic.

An example of automation that is already in widespread is the use of standard interfaces. By using these standard interfaces, we no longer have to worry about writing device drivers for specific devices.

Likewise, with CORBA, you need not worry any longer about handling specific protocols and communications ports. More importantly, you can define abstract interfaces for distributed applications and let the ORB handle the details for you.

1.1.3 CORBA - Definition

The Common Object Request Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG).

1.1.4 CORBA Products

CORBA is a standard rather than a specific product. Specific products that conform to the CORBA specification include:

There are many others.

1.1.5 The Object Management Architecture (OMA)

Although CORBA forms the major part of the OMA, the complete OMA has several other architectural components. Together with CORBA, these other architectural components offer a complete solution for the development and deployment of distributed applications.

The three most important OMA architectural components are: The Object Request Broker (ORB)

The ORB is the communications core of the CORBA standard. The ORB provides the infrastructure that enables components to converse, independently of the specific platforms and techniques used to implement them.

To use any language, including COBOL, to write distributed components such as these, you can:

  1. Within a distributed application, use the standard CORBA Interface Definition Language (IDL) to define the interfaces to the various components.

  2. Using specific IDL mappings, generate stubs that link it all together into the ORB and enable the components to interact.

Compliance with the ORB standard guarantees portability and connectivity across distributed systems. Object Services

Object services are perhaps the next most important aspect of the entire OMA. Object services include:

These, and other related standard object services, provide a lot of the environmental functional value within CORBA. These services free programmers from the need to provide such specific functionality within their distributed applications.

Implementations of these services, that all use the same OMG defined interfaces, are now becoming commercially available from a number of different vendors. These implementations offer users real choice.

User-written applications use standard IDL specified interfaces to interface to these services. You can view these interfaces as pre-built standard CORBA applications that provide the user-written application with functionality. For example, a server component can register its current location using a standard Trading Service interface. Then, any client that wishes to discover and use that server component would use the Trading Service to find the component. In this way, clients can dynamically discover other components at run time, without having to maintain a static configuration file containing specific host names. This is just one example of the considerable value added by one of the many standard object services. Domain Interfaces

Another important architectural component within the OMA is the emerging Domain Interface. Domain interfaces represent vertical areas that provide functionality of direct interest to end-users in particular application domains.

Domain interfaces are standard interfaces with a specific industry focus. For example, if you were tasked to write a general ledger facility, you could use a predefined standard interface for a CORBA general ledger facility rather than write your own interface. Your users could then use that general ledger facility in conjunction with other applications that exploit that specific interface.

Through the use of OMG standarized interfaces, therefore, you can deploy the best-of-breed to meet your specific requirements and also future-proof your investment.

Of course, there will never be a standard interface for every requirement. However, it is envisaged that you will be able to save yourself a lot of effort by making use of the many OMG defined off-the-shelf components that conform to specific industry standards.

1.2 The Object Management Group (OMG)

This section describes the history and goals of the OMG.

1.2.1 OMG History

The OMG was founded in May 1989 by eight companies:

In October 1989, the OMG began independent operations as a non-profit making corporation. Through the OMG's commitment to developing technically excellent, commercially viable and vendor independent specifications for the software industry, the consortium now includes over 900 members, making the OMG the world's largest software development consortium.

OMG headquarters are in Framingham, Massachusetts, USA, with international marketing partners in the UK, Germany, Japan, and Australia.

1.2.2 OMG Goals

The OMG was formed to create a component-based software marketplace by hastening the introduction of standardized object software. The organization's charter includes the establishment of industry guidelines and object management specifications to provide a common framework for application development. Conformance to these specifications will make it possible to develop a heterogeneous computing environment across all major hardware platforms and operating systems.

OMG defines object management as software development that models the real world through representation of "objects." These objects are the encapsulation of the attributes, relationships and methods of software identifiable program components. A key benefit of an object-oriented system is its ability to expand in functionality by extending existing components and adding new components to the system. Object management results in faster application development, easier maintenance and re-usable software.

The acceptance and use of object-oriented architectures is widespread and growing. Virtually every major provider and user of computer systems in the world is either using or planning to implement object-oriented tools and applications. Within the next five years, revenue from the sale of object-oriented software is projected to exceed three billion dollars. The component software market is here.

1.2.3 Contacting OMG

Object Management Group's corporate offices are located at:

Framingham Corporate Center
Object Management Group, Inc. 
492 Old Connecticut Path
Framingham, MA 01701

Ph: +1-508-820 4300
Fax: +1-508-820 4303

Web address: 

1.3 The CORBA Interface Definition Language (IDL)

The CORBA IDL is a key component within the OMG's OMA architecture. IDL enables everything to work together in a transparent language-neutral manner.

1.3.1 What is IDL?

A typical CORBA application consists of several interacting components. A component acting as a client makes use of services provided by one or more servers. A component acting as a server in one interaction can also act as a client in other interactions.

Components can only interact via a well-defined interface. IDL is a language independent mechanism, defined by the OMG, for specifying that interface.

Fundamentally, IDL is an abstract definition of an interface. Once defined, you can use IDL to generate the code that ties together all parts of the interface.

1.3.2 How is IDL Created?

Usually, IDL definitions are created within a normal text file using a standard text editor. By convention, a file containing IDL has the suffix .idl.

However, for COBOL, the creation of IDL definitions has been automated. By processing a normal COBOL program with the appropriate tool, you can generate an IDL file that uses the abstract IDL syntax to describe the interface to the program.

1.3.3 What does IDL look like?

Each IDL file can contain either a single interface definition or multiple interface definitions.

Each interface definition defines the interface in terms of the operations that can be invoked and the parameters to those operations. The following example illustrates this:

     //     Sample IDL

     interface sample 
         struct parm_struct {
             string<50> message;       
             float      calc_result;            
             long       code;           

         exception FaultDetected {string reason; };
         unsigned long first_operation(
                             in string<12>   arg1,
                             out parm_struct arg2,
                             out string<80>  arg3)      
                     raises (FaultDetected) ;
         unsigned long next_operation(
             in    short       arg1,
             inout parm_struct arg2 

The above example shows a definition for an interface called sample that contains:

1.3.4 How is IDL Used?

To illustrate IDL usage, consider the case where program A makes a call to program B. If we want Program A to call Program B in a distributed CORBA environment, the following steps are necessary:

  1. Generate an abstract definition of the interface to program B using IDL.

  2. Process the IDL with a CORBA implementation's IDL compiler to produce client and server stubs.

The above diagram illustrates the following sequence of events.

  1. Program A makes a call to what it thinks is program B, but is in fact the client stub for the interface to Program B.

  2. The client stub packages up the call and pass the call to the ORB for delivery to the server.

  3. The server stub receives the call, unpacks the call and passes the call to program B.

Note that program A and program B do not have to be written in the same language. Each does not have to know what language the other is written in. Program A could be a Java client, and Program B could be a COBOL server. In this case, the IDL compiler would be used to generate a Java client stub, and a COBOL server stub.


From the terminology that is used within the CORBA sphere, for example Object Management Group, Object Request Broker, and Object Management Architecture, you may consider using CORBA with distributed objects only.

However, CORBA is used with distributed components. Within a CORBA context, it is quite acceptable to write your distributed CORBA components using either pure OO languages such as Smalltalk or Java, pseudo OO languages such as C++ or a normal procedural language such as C or COBOL. In fact, the very first language binding defined within the CORBA specification was for C and not C++.

The use of the word Object within CORBA is a reference to the fact that CORBA uses an Object Model to solve the problem of designing, developing and deploying distributed components. Each of these processes exposes an interface that supports a series of operations to clients. This concept hides implementation specific details such as the language in which a component is written.

1.5 MERANT CORBA Support

A specific utility is available for each CORBA implementation supported by MERANT. The utility accepts one or more standard COBOL programs as input and generates everything required to make the programs into distributed CORBA components.

This means that when processing the COBOL, the utility generates the following output:

1.6 CORBA Implementations Supported by MERANT

Based on contractual agreements and the vendor's product availability, MERANT plans to provide CORBA support for products from the following vendors:

MERANT will not provide support for all products on every platform. For details related to a specific platform, please contact your sales representative.

Copyright © 2000 MERANT International Limited. All rights reserved.
This document and the proprietary marks and names used herein are protected by international law.