| Coborbgen | |
MERANT provides support for Object Request Broker (ORB) technology as part of the CORBA standard.
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.
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.
The Common Object Request Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG).
CORBA has location transparency.
CORBA is component orientated.
CORBA has language transparency.
CORBA is a standard rather than a specific product. Specific products that conform to the CORBA specification include:
There are many others.
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 itself.
Services common to many applications
Standard industry specific solutions.
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:
Compliance with the ORB standard guarantees portability and connectivity across distributed systems.
Object services are perhaps the next most important aspect of the entire OMA. Object services include:
To provide transaction synchronization across the elements of a distributed application.
To protect distributed applications from unauthorized attempts to access information or interfere with their operations.
To provide for specific components registering their availability, in order that others can then find them dynamically at run time by looking for a specific interface; for example, find the printer component.
To provide for storage of the current state of components. You can save your current component state for re-loading later, in order that you can carry on where you left off.
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.
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.
This section describes the history and goals of the OMG.
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.
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.
Object Management Group's corporate offices are located at:
Framingham Corporate Center Object Management Group, Inc. 492 Old Connecticut Path Framingham, MA 01701 U.S.A. Ph: +1-508-820 4300 Fax: +1-508-820 4303 Web address:http://www.omg.org
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.
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.
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.
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:
first_operation:
next_operation
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 above diagram illustrates the following sequence of events.
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.
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:
Each entry point is handled as a specific operation that can be called by other CORBA components.
COBOL specific datatypes that cannot be described using IDL are handled within a thin COBOL wrapper.
Any ORB specific initialization required is also generated within an ORB specific wrapper.
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.
| Coborbgen | |