| Introduction | Using Other Object Domains | |
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:
Wrappers are used to handle Orbix distribution concerns in isolation from the actual business logic. This includes issues such as Orbix initialisation, or the handling of COBOL specific data types within the Orbix ORB's language-neutral distributed environment.
IDL is used by the Orbix IDL compiler to generate stubs that will connect components to Orbix. IDL can also be used to enable components written in other languages supported by an ORB to transparently interface to Orbix Components written in COBOL.
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
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:
This describes all the different entry points into program B as operations, each of which contains a distinct set of parameters. This collection of operations and parameters is known as an interface definition and is given a specific interface name. The interface definition is produced within a separate file (usually with a .idl suffix) using the standard, language independent CORBA IDL (Interface Definition Language).
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
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.
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.
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.
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.
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.
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.
On the Tools menu within NetExpress the following Orbix Support utilities are available:
This is used to start up the local Orbix Daemon. The Orbix Daemon is supplied as part of Iona's Orbix and is used to perform the initial handshake between Orbix components.
This is used to register the details of your current Orbix COBOL Server with the Orbix Daemon. Note that the Daemon must be started first. You can specify the interface name, and the path to the executable Orbix COBOL Server so that the daemon will know how to start it up in response to requests from clients.
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:
CORBA IDL that describes the interface to the COBOL code. The primary entry point and each specific ENTRY statement is defined as an IDL operation.
This module is the primary entry point for the ORBIX COBOL Component that will act as a server for the interface defined within the generated IDL file. Within it is code that will:
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.
The following list identifies the tasks involved in the migration of a legacy COBOL application to the ORBIX distributed environment.
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.
The following list identifies the tasks involved in the development of new ORBIX applications.
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.
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.
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.
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:
The type of wrapper that will be generated to connect the Component to Orbix can be specified. The IDL will be used to generate either C++ or OrbixCOBOL stubs.
Trace messages can be generated within the server wrapper.
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.
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.
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.
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.
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.
Several Orbix Support options are available from the NetExpress Tools menu.
This starts the local Iona Orbix Daemon.
Select this option to display the following:
Figure 2-10: Register Server
Specify the name of your Orbix Server's interface, and the path to the executable server, then click on OK. This constructs an Orbix putit command and executes it to register the server details with the Orbix Daemon.
Note that the fields on this dialog are initially filled in for you if you are currently within an open NetExpress Orbix project.
The CorbaGen utility is a command line tool that can be used from a NetExpress command prompt to provide ORBIX support for COBOL applications.
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:
|
/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:
|
/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:
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.
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:
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.
Follow the procedure below:
Use the corbagen command line utility with the /debug option. The makefile that is generated contains all the options you require to build executables that can be animated using NetExpress.
To compile and link your ORBIX executables, process the makefile with nmake.
Once you have your Executables, the next step is to animate using NetExpress. To do this, start NetExpress from a command line prompt as follows:
mfnetx program-name
where program-name is the name of your .exe module.
When NetExpress starts, you can proceed to animate the selected ORBIX application.
If animating the client, you should first register your server with ORBIX, so that animation starts automatically in response to requests from the client.
If animating the server, you should start the server animation. While the server is waiting for client input, you can start your client manually from a NetExpress Command prompt.
Follow the procedure below:
When using the CORBA Wizard for ORBIX, there is a debug option that you need to select. On the Set Client and Server options panel, you need to tick the Debug and Trace Messages box. This action generates debug messages within the generated code and, also, sets automatically the required animation options within your NetExpress project.
If you have already generated your ORBIX application, you have two choices:
Select Generic Debug Build as the type of build. Then, under the Project menu, select the Rebuild option to build your executables.
To animate your client, first register your server with ORBIX. Once registered, you may right click on your ORBIX Client's .exe and pick Animate from the list of available options.
When animating your server, you right clink on your ORBIX server's .exe and pick Animate. While the server is waiting for client input, you can start your client manually from a NetExpress Command prompt.
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.
| Introduction | Using Other Object Domains | |