| Orbix Support in NetExpress | |
This book explains how to access distributed components using COBOL programs.
There are two methods of accessing distributed components:
See the chapter OLE Automation for a discussion of this method.
See the chapter Orbix Support in NetExpress for specific details.
Developing an application that is distributed across a range of different platforms is a complex task. The following issues need to be considered:
To solve concerns such as these, the Object Management Group (OMG) has defined the Common Object Request Broker Architecture (CORBA). This is a part of an overall architecture known as the Object Management Architecture (OMA).
Another term that is often used in association with CORBA is Object Request Broker or ORB. To clarify the terminology: CORBA is the standard defined by the OMG, and an ORB is a specific implementation of the CORBA standard.
The goal of the CORBA standard is to automate the handling of distributed application issues such as those outlined above. This leaves programmers free to focus on the development of the distributed business logic.
Specific examples of products that conform to the CORBA specification include:
The CORBA specification defines an open standard for middleware. It specifies how an Object Request Broker (ORB) is used to establish client/server relationships. It enables distributed applications to communicate with one another regardless of where they are located (location transparency), who has designed them (component orientated), or what language they are written in (language transparency).
CORBA is the core part of the Object Management Architecture (OMA) that is defined by the Object Management Group (OMG).
The complete Object Management Architecture has CORBA at its heart, but also has several other architectural components that together with CORBA offer a complete solution for the development and deployment of distributed applications. The three most important OMA architectural components are:
The Object Request Broker itself
Services common to many applications
Standard industry specific solutions
The Object Request Broker is the communications core of the CORBA standard. It provides the infrastructure that enables components to converse, independently of the specific platforms and techniques used to implement them (note that such distributed components can be written using any language including COBOL).
Compliance with the ORB standard guarantees portability and connectivity across distributed systems.
Typically, a user defines the interfaces to the various components within his or her distributed application using the standard CORBA Interface Definition Language (IDL). Then, using specific IDL Language mappings, generates stubs that link it all together into the ORB and enable the components to interact.
Object Services are perhaps the next most important aspect of the entire OMA. These include:
Provides transaction synchronisation across the elements of a distributed application.
Protection of distributed applications from unauthorised attempts to access information or interfere with their operations.
Specific components register their availability, others then dynamically find them at runtime by looking for a specific interface (for example, find the printer component).
Clients can look for a specific type of service and also add specific constraints to the search (for example, list all printer components on the second floor that support colour).
Storage of the state of components (save my current storage so that I can reload it later and carry on where I left off).
User-written applications interface to these services using standard IDL specified interfaces. You can view these as pre-built standard CORBA applications that provide functionality used by the user-written application. For example, a server component may register its current location using a standard Trading Service interface. Then, any client that wishes to discover and use that component would use the Trading service to find it. This means that clients can dynamically discover other components at run time and do not have 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.
Another important architectural component of 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.
These are standard interfaces with a specific industry focus. Take, for example, the case where a user is writing a general ledger facility. Instead of defining his or her own interface, the user can use a pre-defined, standard interface for a CORBA general ledger facility. This will enable it to be used in conjunction with other applications that exploit that specific interface.
Users can deploy the best-of-breed to meet their specific requirements, and also future-proof their investment through the use of OMG standardised interfaces.
Of course, there will never be a standard interface for every requirement but it is envisaged that users will be able to save themselves a lot of effort by making use of the many OMG defined off-the-shelf components that conform to specific industry standards.
The OMG was founded in May 1989 by eight companies: 3Com Corporation, American Airlines, Canon, Inc., Data General, Hewlett-Packard, Philips Telecommunications N.V., Sun Microsystems and Unisys Corporation. 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.
The OMG was formed to create a component-based software marketplace by hastening the introduction of standardised object software. The organisation'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 CORBA Interface Definition Language (IDL) is a key component within the OMG's OMA architecture. It enables everything to work together in a transparent language-neutral manner.
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. The CORBA Interface Definition Language (IDL) is a language independent mechanism, defined by the OMG, for specifying that interface.
IDL is basically an abstract definition of an interface, and once defined, can be used to generate the code that ties it all together.
Usually, IDL definitions are created within a normal text file using a standard text editor. By convention a file containing IDL has an .idl suffix.
However, for COBOL the creation of IDL definitions has been automated. By processing a normal COBOL program with the appropriate tool, an IDL file can be generated that describes the interface to it using the abstract IDL syntax.
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:
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:
The following figure illustrates what it all looks like when it has been compiled and linked together.
Figure 1-1: IDL
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.
The client stub packages the call and passes it to the ORB for delivery to the server.
The server stub receives the call, unpacks it and passes it to program B.
Note that program A and program B do not have to be written in the same language. Nor does either 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.
Terms such as "Object Management Group", "Object Request Broker" and "Object Management Architecture" that are used within the CORBA sphere, may tempt you to think that CORBA can only be used with distributed objects.
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', not C++.
The use of the word "Object" within a CORBA context 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 expose an interface that supports a series of operations to clients. This concept hides implementation specific details such as what language a component is actually written in.
Within NetExpress, the CORBA implementation that is supported is Orbix from Iona. The support provided for Orbix consists of:
Copyright © 1998 Micro Focus Limited. All rights reserved.
This document and the proprietary marks and names
used herein are protected by international law.
| Orbix Support in NetExpress | |