PreviousIntroduction Using Other Object DomainsNext

Chapter 2: Orbix Support in NetExpress

Orbix support in NetExpress provides COBOL support for Iona's Object Request Broker (ORB) technology (Orbix). Used in conjunction with Orbix, this Orbix support enables:


Note: Orbix is not available as a part of NetExpress. You must purchase Orbix from Iona before you can use the Orbix support provided in NetExpress. Contact numbers for Iona are given below.


Support for Orbix in NetExpress comprises:

Both the CORBA Wizard for Orbix and the CorbaGen utility provide the following support for the distribution of standard COBOL:

2.1 What is Orbix?

Iona's Orbix is an Object Request Broker (ORB) that conforms to the specifications defined by the Object Management Group's (OMG's) Common Object Request Broker Architecture (CORBA). It can also be extended with additional services such as OrbixTransactions and OrbixSecurity.

Orbix is currently the leading ORB on the market and is used by many major companies. It supports:

For further information about Orbix, refer to the Iona Orbix home page at:

		http://www.iona.com

2.2 Orbix Distribution Transparency

One of the key features of CORBA-based products is distribution transparency. This means that you can invoke a remote program, residing in a completely different environment, as if you were making a call to a local program without needing to write any specific communications code, handle any transport protocols, or even be concerned about the different representations of basic datatypes within different hardware environments. The Object Request Broker handles all of these issues for you.

Consider program A calling program B in a non-distributed environment. To create from this a distributed CORBA application, you need to:

So, in the distributed model Program A calls the client stub code. The stub packages up and passes the message to the ORB. The ORB locates the remote application and routes the message to its server stub. Once received by the server stub, the message is unpackaged into the format appropriate for the local environment and passed to the application as if it had come from a local application. The following diagram represents this:



Figure 2-1: Orbix Distribution Transparency

2.3 Orbix Location Transparency

The Object Request Broker is basically a mechanism for building and routing messages from clients to distributed components. Client programmers provide a unique object reference that identifies the component they want to interface to. The ORB uses this to route messages to the required component. Client programmers need not be concerned about how the connection is established, which protocol is used, or the differences between the client's environment and the component's environment. The ORB handles all of these issues.

Nor do client programmers need to be concerned with the actual location of the component they are interfacing to. When an object reference is specified, it could be for a component that is just another process within the same network node or a component which is running on another node on the far side of the world.

For simple examples a client can bind to the server. However for complete location transparency, the unique object reference for a component can be obtained via the ORBIX Naming Service.

2.3.1 The ORBIX Naming Service

To enable clients to operate within very large distributed environments (that perhaps are also constantly changing) they need to be able to locate components dynamically, at runtime. The ORBIX Naming service makes this possible.

When a component is activated, it can use the Naming Service Interface to register itself. Clients that wish to communicate with a component can ask the Naming service for the object reference of a component that has registered with the Naming service.

For more details on the naming service, consult the appropriate ORBIX documentation.

The one great benefit of this architecture is the dynamic discovery of components at run-time by clients. No hard-coded configuration files are required. As components are moved around to different locations or different hardware or software environments, clients can automatically locate them.

2.4 The CORBA Interface Definition Language

2.4.1 What is IDL?

A typical ORBIX 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. The CORBA Interface Definition Language (IDL) is a language independent mechanism, defined by the OMG, for specifying that interface.

Usually, IDL definitions are created within a normal text file using a standard text editor. For COBOL, however, the creation of IDL definitions has been automated.

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,
        out parm_struct arg2
     );
};

The above example shows:

For a more detailed discussion of IDL syntax, refer to the ORBIX Reference Guide that is supplied by Iona.

2.4.2 How is IDL used?

Once you have your complete IDL specification ready, the usual procedure is to:

However, the above has been automated for you, and in the case of the CORBA Wizard for Orbix, the IDL has been hidden to simplify the process.


Note: You must compile the IDL on the platform on which your component is to run. This is because the code produced by the IDL compiler is specific to the platform on which it runs. The generated code handles environment specific issues and insulates your application from such concerns, thus making it non-specific to any environment, and portable.


2.5 Developing Distributed COBOL applications using Orbix

This section describes the theory behind the development of a distributed ORBIX application. You may also like to refer to the simple, step-by-step, instructions contained within the readme.txt file that accompanies the demonstration CORBA application provided with NetExpress. This demonstration application and the readme.txt file can be found in the \DEMO\CORBA\ORDER directory under your NetExpress base installation directory.

2.5.1 Overview of the NetExpress CORBA Wizard for Orbix

The Micro Focus CORBA Wizard for Orbix can be used to automate the development of distributed ORBIX applications within NetExpress projects.

To start the Wizard, select New from the NetExpress File menu and then select CORBA Wizard for Orbix. The Wizard presents a series of pages which it uses to gather enough information to create a NetExpress Orbix Project.

Your NetExpress Orbix Project will not contain any IDL. The IDL is generated and saved in the project directory. The Wizard calls the Orbix IDL compiler to produce the required stubs, then places those into the project.

Once the project has been created, you can build your Orbix executables by simply selecting Build from the Projectmenu. The Wizard will have established within your project all the correct options required.

2.5.2 Overview of the NetExpress Orbix Support Tools

On the Tools menu within NetExpress the following Orbix Support utilities are available:

2.5.3 Overview of the CorbaGen Command Line Utility

The Micro Focus CorbaGen command line utility may be used to automate the development of distributed ORBIX applications within the context of a NetExpress command prompt. When run it will accept one or more COBOL source files as input, and extract the interface details for them. Then, depending on the command line directives supplied, generate the following:


Note: You do not have to use COBOL clients to call ORBIX COBOL servers. You can use the generated IDL to build clients written in some other language (such as Visual Basic or Java). Language transparency between components is fully supported.


2.5.4 Basic Steps for Migrating Legacy Applications

The following list identifies the tasks involved in the migration of a legacy COBOL application to the ORBIX distributed environment.

  1. Initially, you will need to identify and isolate the business logic that is to form your ORBIX Server Component.

Note that ORBIX Components can support more that one interface and can also be clients to interfaces supported within other Components.

You may also choose to identify and isolate some business logic that will act as a client to the server logic. If you do this, you will be able to test the server logic locally before you proceed to add any distribution support by building them as two modules that call each other on the same platform.

You could also choose to use the client logic to test out the server logic after you have added the ORBIX Distribution support, even if your production clients that make calls to the distributed business logic will actually be written in some other language such as Java or Visual Basic.

As an alternative to using the CORBA Wizard for Orbix, you can use the CorbaGen utility from the NetExpress DOS prompt. Initially the utility will be used to generate all the support required. To build your executables, you would run the makefile generated by it.


Note: The above assumes that each ORBIX Component will be either a server or a client for one specific interface. In reality, you may wish to build ORBIX components that support more than one interface, or act as a server for one interface and the client of some other Component's interface. If you wish to do this, you may need to modify the support generated within the wrapper for your ORBIX component so that it will support all the interfaces you require access to.


2.5.5 Basic Steps for Developing new ORBIX Applications

The following list identifies the tasks involved in the development of new ORBIX applications.

  1. Design the interface for your new component.

  2. Write the server logic and code separate ENTRY statements for each operation supported by the interface.

  3. Use either the CORBA Wizard for Orbix or the CorbaGen utility as described within the previous section.

2.6 The CORBA Wizard for Orbix

The CORBA Wizard for Orbix is a NetExpress Wizard that can be used to automate the development of distributed ORBIX applications within NetExpress projects. To start the Wizard, select New from the NetExpress File menu and then click on CORBA Wizard for Orbix. The following screen is displayed:



Figure 2-2: Welcome to the Wizard

This screen introduces the Wizard and briefly describes its purpose. To proceed, click on the Next button:


Note: Every Wizard page has a Cancel button and a Help button. Cancel can be used at any stage to cancel the wizard, and Help can be used at any stage to invoke the online help for the Wizard.


2.6.1 Create a New Project

When you start the Wizard with no NetExpress project open, clicking on Next displays the following:



Figure 2-3: Creating a New Project

Here you can specify the name of your new NetExpress project, and also the directory within which the project is located. Once you are satisfied, click on Next, the following is displayed:



Figure 2-4: Selecting Files for a New Project

This second page enables you to select the files that make up your new NetExpress project. You cannot proceed until you have selected at least one file. Files are selected by clicking the Add button - this invokes a standard file selection dialog. Once you have selected at least one file, the Next button is enabled.

Clicking on Next creates the new project.

2.6.2 Selecting Files for the Orbix Server

Once you have created a project (or if a project was already open when you started the Wizard), the following is displayed:



Figure 2-5: Selecting Files for the Orbix Server

You can select files from the list of Available project files and add them to your Orbix server by clicking on the Add button. The selected files are removed from the left-hand list box and displayed in the right-hand list box, Orbix Server Files. You can remove files from the list of Orbix Server Files by selecting them within the right-hand list box and clicking on Remove.

You must select at least one file for your Orbix Server before the Next button is enabled. Once you are satisfied with your selection, click on Next.

2.6.3 Specifying Client and Server Options

This next page enables you to specify Client and Server options:



Figure 2-6: Specifying Client and Server Options

The following server options are available:

Optionally, you can also select support for an Orbix COBOL Client that will interface to the Orbix COBOL Server. If you select the Orbix COBOL client, clicking on Next displays a further Wizard page which prompts you to select the COBOL modules for your Orbix COBOL client.

2.6.4 Selecting Files for the Orbix Client

This page is only displayed if you have selected COBOL under Client Options on the previous page.



Figure 2-7: Selecting Files for the Orbix Client

You can add files to your Orbix client by selecting them and then clicking on Add. The selected files are removed from the list of Project files available for client and displayed in the right-hand list box, COBOL files for your Orbix Client. You can subsequently remove files from this list by selecting them and clicking on Remove.

You must select at least one project file for your Orbix Client before the Next button is enabled.

Once you are satisfied with your selection, click on Next.

2.6.5 Generating

From this page you can generate your distribution support files:



Figure 2-8: Generation

Click on the Generate button to generate the Orbix support file. As the generation process proceeds, messages are displayed within the list box. Once it is complete, the Next button is enabled. Click on Next.

2.6.6 The Final Page

Finally, a list of all the files that will be inserted into the project is displayed:



Figure 2-9: The Final Page

Click on Finish to transform your NetExpress project into an Orbix NetExpress project, inserting all the required Orbix support and setting all the correct options.

2.6.7 Building your Executables

Once you have generated your Orbix NetExpress project, you will find that it contains all the files and setting that you require to be able to build your executables. To build the executables, simply select the Rebuild option under the NetExpress Project menu.

2.7 Orbix Support Utilities

Several Orbix Support options are available from the NetExpress Tools menu.

2.8 The CorbaGen Command Line Utility

The CorbaGen utility is a command line tool that can be used from a NetExpress command prompt to provide ORBIX support for COBOL applications.

2.8.1 CorbaGen Syntax

The syntax of the CorbaGen command is:

CorbaGen [options] filename [filename...]

where:

filename

Is the name of a COBOL source file.

options

Are CorbaGen options.

Valid CorbaGen options are listed in the table below.

CorbaGen Option

Meaning

/cob option [/cob option...]

Where option is a COBOL Compiler option which is passed to CorbaGen.

Normally you should not have to use this option. However, in some instances, for example to specify a specific pre-processor, it may be necessary.

/make

Directs CorbaGen to generate a makefile to build executables.

/client basename

Passes the name of the client to CorbaGen. If specified:

  • A wrapper for a COBOL client is generated as well as a server wrapper.
  • The makefile builds an executable client as well as an executable server if the /make option is specified.

/v

Verbose option. If set, it will also set any verbose flags on commands within generated makefiles.

/debug

Directs CorbaGen to insert debug code into the generated server wrappers and to insert animation options on the COBOL Compiler's command line within the generated makefile. When run, any Orbix Components built with this flag set issue a text message with details:

  • for each call made into the legacy COBOL
  • for each return from a call to the legacy COBOL

/octet

This option specifies that COBOL DBCS types (PIC N and PIC G) are to be handled as arrays of octets. If not specified, the IDL wstring and wchar types are used (This alternative to the default is available because some versions of Orbix and some platforms do not handle the wchar and wstring IDL types).

Once invoked, the CorbaGen command:

2.9 Debugging and Animating ORBIX Clients and Servers

In general, the tests that you apply to your other applications can be used but the distributed nature of an ORBIX Component means that there are extra considerations that should be taken into account when testing.

2.9.1 How should I test ?

It is recommended that you test your COBOL server logic on a local host before you add ORBIX distribution to it. This testing should:

When testing an ORBIX Component, it is recommended that you follow a procedure similar to that outlined below:

2.9.2 How do I Animate my Code

To set up your ORBIX application for animation, choose one of the following approaches:

The following subsections describe each of these approaches in more detail.

2.9.2.1 Using corbagen to set up Animation

Follow the procedure below:

2.9.2.2 Using the CORBA Wizard for ORBIX to set up Animation

Follow the procedure below:

2.10 ORBIX Support Restrictions

The following restrictions apply when applying ORBIX support to a COBOL application:


Copyright © 1998 Micro Focus Limited. All rights reserved.
This document and the proprietary marks and names used herein are protected by international law.
PreviousIntroduction Using Other Object DomainsNext