Introduction To CORBA
A D V E R T I S E M E N T
Introduction to the networking of distributed objects and the use of CORBA.
The Java Developer Connection (JDC) presents a Short Course introducing the Common Object Request Broker Architecture (CORBA) written by Java Software licensee, the MageLang Institute. A leading provider of Java technology training, MageLang has contributed regularly to the JDC since 1996.
The Magelang Institute has been dedicated to promoting the growth of the Java technology community through evangelism, education, and software since 1995. You can find out more about their activities, including community-driven FAQs and online learning, at JGuru.com
The Common Object Request Broker Architecture (CORBA) from the Object Management Group (OMG) provides a platform-independent, language-independent architecture for writing distributed, object-oriented applications. CORBA objects can reside in the same process, on the same machine, down the hall, or across the planet. The Java language is an excellent language for writing CORBA programs. Some of the features that account for this popularity include the clear mapping from OMG IDL to the Java programming language, and the Java runtime environment's built-in garbage collection.
This introductory course will give you an overall view of how CORBA works, how to write CORBA applications in the Java programming language, and illustrates Sun's Java 2 ORB implementation of CORBA as well as Inprise's VisiBroker for Java. The approach to presenting CORBA taken in this course is through an example stock trading application.
Concepts After completing this module you will understand:
The basic structure of a CORBA application
Why the Java programming language is an ideal language for CORBA programming
How to specify distributed object interfaces in IDL
What areas of CORBA you should pursue for further study
Objectives
By the end of this module you will be able to:
Write simple CORBA interfaces in IDL
Use the Java classes generated by the IDL compiler
Create CORBA client applications in the Java language
Implement CORBA distributed objects in the Java language
Find distributed objects at run time
Prerequisites
A general familiarity with object-oriented programming concepts and the Java programming language. If you are not familiar with these capabilities, see the Java Tutorial. The Magercises require the ability to modify and build simple Java programs
The Benefits of Distributed Computing
The motivations for structuring a system as a set of distributed
components include:
- An increased ability to collaborate through better connectivity
and networking
- The potential to increase performance and efficiency through the
use of parallel processing
- Increased reliability, scalability and availability through
replication
- A greater cost-effectiveness through the sharing of computing
resources (for example, printers, disk and processing power) and the
implementation of heterogeneous, open systems
Along with these impressive advantages comes additional complexity to the
development process. The programmer now has to handle situations like the
following:
- Network delay and latency
- Load balancing between the different processing elements in the
system
- Ensuring the correct ordering of events
- Partial failure of communications links, in particular with
regard to immutable transactions (i.e., transactions which must
yield the same result if repeated�for example, the accidental
processing of a bank transaction twice should not erroneously affect
the account balance)
One of the earlier techniques in reducing the programmer's work (to
develop these distributed applications) was the remote procedure call (RPC).
Remote Procedure Calls
RPCs have already been introduced in Linux Journal in an excellent
article by Ed Petron, �Portable Database Management with /rdb�, October
1997. The motivation behind RPCs is to make network programming as easy as
making a traditional function call. Linux provides the Open Network
Computing flavor of remote procedure calls (ONC-RPC), which was originally
developed by Sun Microsystems (Mountain View, CA) for use in its Network
File System (NFS) implementation.
RPCs do nothing more than hide the implementation details of creating
sockets (network endpoints), sending data and closing the sockets as
required. They are also responsible for converting the (remote) procedure's
(local data) parameters into a format suitable for network transportation
and again into a format that can be used on the remote host. This
network-transparent transmission of data ensures both end machines can
interpret the information content correctly.
Quite often, different representation issues are involved in this process
(for example, byte ordering, ASCII to EBCDIC, etc.). Additionally, pointers
(references to address locations in a virtual memory space) cannot be passed
directly from one process/machine to another. Instead, a �deep copy� needs
to be performed, copying the data pointed to by the pointer which is then
sent �across the wire�. The entire procedure of transferring the data from
the native format of a machine into a network-transparent format is called
�marshalling�. The reverse procedure is called �de-marshaling�. The ONC-RPC
uses a special type of marshaling called external data representation (XDR).
Figure 1 shows the sequence of events involved in a remote procedure call.
The mechanisms and semantics of ONC-RPCs are discussed in much greater
detail in RFC 1831, RFC 1832 and RFC 1833.
|
