Overview of CORBA Java Programming


	Corporate Info \| News \| Solutions \| Products \| Partners \| Services \| Events \| Download \| How To Buy
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| PDF Files \| Contact \| Glossary

WebLogic Enterprise Doc Home \| CORBA Programming \| Previous Topic \| Next Topic \| Contents \| Index

BEA WebLogic Enterprise is an implementation of the Java 2 Enterprise Edition (J2EE) platform. As such, BEA WebLogic Enterprise includes CORBA (Common Object Request Broker Architecture) capability for standards-based interoperability and connectivity.

The BEA WebLogic Enterprise platform allows distributed Web-enabled Java applications to transparently invoke operations on remote network services using the industry standard Object Management Group (OMG) Interface Definition Language (IDL) and Internet Inter-ORBProtocol (IIOP) defined by the OMG. Run-time components include a fully compliant Java Object Request Broker (ORB) for distributed computing using IIOP communication.

To build Java applications that can access CORBA objects, you need the BEA idltojava compiler, a tool that converts IDL files to Java stub and skeleton files. The idltojava compiler is included with the BEA WebLogic Enterprise software.

This topic includes the following sections:

Where Do I Get the BEA idltojava Compiler?

The WebLogic Enterprise CD-ROM includes the BEA version of the idltojava compiler. Once you have installed BEA WebLogic Enterprise, you can find the idltojava compiler in WLEDIR/bin.

How Does the BEA idltojava Compiler Differ from the Sun Microsystems, Inc. Version?

The idltojava compiler provided with BEA WebLogic Enterprise includes several enhancements, extensions, and additions that are not included in the original compiler produced by Sun Microsystems, Inc. The BEA WebLogic Enterprise specific revisions are summarized here. For detailed information on using the idltojava compiler provided with BEA WebLogic Enterprise, see the topic Using the idltojava Command.

The BEA WebLogic Enterprise idltojava compiler:

Behavior and defaults of the flags differs from that described in the Sun Microsystems, Inc. documentation. (See idltojava Command Flags.)
Includes a new #pragma tag: #pragma ID <name> <Repostitory_id> (See Using #pragma in IDL Files.)
Includes a new #pragma tag: #pragma version <name> <m.n> (See Using #pragma in IDL Files.)
Extends the #pragma prefix to work on inner scope. A blank prefix reverts. (See Using #pragma in IDL Files.)
Allows unions with boolean discriminators.
Allows declarations nested inside complex types.

What Is IDL?

Interface definition language (IDL) is a generic term for a language that lets a program or object written in one language communicate with another program written in an unknown language. In distributed object technology, new objects must be able to be sent to any platform environment and have the ability to discover how to run in that environment. An ORB is an example of a program that uses an interface definition language to "broker" communication between one object program and another.

What Is Java IDL?

CORBA is the standard distributed object architecture developed by the OMG consortium. The OMG has specified an architecture for an ORB on which object components written by different vendors can interoperate across networks and operating systems. The OMG-specified Interface Definition Language (IDL) is used to define the interfaces to CORBA objects.

Sun Microsystems, Inc. defines "Java IDL" as:

The classes, libraries, and tools that make it possible to use CORBA objects from the Java programming language. The main components of Java IDL are an ORB, a naming service, and the idltojava compiler.

Note that Java IDL is not a particular kind of interface definition language (IDL) apart from OMG IDL. The same IDL can be compiled with the idltojava compiler to produce CORBA-compatible Java files, or with a C++ based compiler to produce CORBA-compatible C++ files. The compiler that you use on the IDL is what makes the difference. The OMG has established IDL-to-Java mappings as well as IDL-to-C++ mappings. The language-based compilers generate code based on the OMG CORBA mappings to their particular language.

The BEA WebLogic Enterprise system provides its own "brand" of Java IDL. In other words, as a J2EE implementation, WebLogic Enterprise provides all of the components you need to build Java applications capable of accessing CORBA objects. The key components in WebLogic Enterprise are listed below in the Accessing CORBA Objects from Java Applications section.

About CORBA and Java IDL

The following sections explain more about CORBA and Java IDL:

Accessing CORBA Objects from Java Applications

As a J2EE implementation, BEA WebLogic Enterprise provides all of the components you need to build Java applications capable of accessing CORBA objects. The key components are:

BEA WebLogic Enterprise idltojava compiler-a tool for converting IDL interface definitions to Java stub and skeleton files. The idltojava command compiles standard CORBA IDL source code into Java source code. (You can then use the javac compiler to compile that source to Java bytecodes.) For a detailed description of the idltojava compiler, see Using the idltojava Command.
BEA WebLogic Enterprise CORBA Object Request Broker (ORB)-the ORB together with the idltojava compiler can be used to define, implement, and access CORBA objects from Java applications. The BEA WebLogic Enterprise system supports both transient and persistent CORBA objects. Transient objects are those whose lifetimes are limited by their server process's lifetime. Persistent or stateful objects are those which can store state and reinitialize themselves from this state each time the server is restarted. (For more on using persistent objects, see the topic Persistent State and User Exceptions IDL Example and the section on Joint Client Server Applications in CORBA Server-to-Server Communication in the BEA WebLogic Enterprise online documentation.)
Java Naming and Directory Interface (JNDI)-the standard naming service available in the Java 2 Enterprise Edition (J2EE). The capability of looking up and locating objects in BEA WebLogic Enterprise is provided by the Java Naming and Directory Interface (JNDI), a standard J2EE naming service. JNDI is used along with the BEA WebLogic Enterprise Bootstrap object and FactoryFinder to resolve object references.
Bootstrap Object and FactoryFinder-BEA WebLogic Enterprise objects that work in conjunction with the naming service to supply local and remote object references. The client application uses the Bootstrap object to obtain initial object references to key objects in a BEA WebLogic Enterprise domain, one of which is the FactoryFinder. The FactoryFinder, in turn, is used to locate factory objects. Factories are used to create application objects.

The BEA WebLogic Enterprise Java CORBA ORB supports both transient and persistent objects.

The BEA WebLogic Enterprise Interface Repository is not required. An interface repository is provided for dynamically determining interfaces. See the command idl2ir in the Commands, System Processes, and MIB Reference and the Interface Repository Interfaces chapter in the CORBA Java Programming Reference in the BEA WebLogic Enterprise online documentation.

Defining and Implementing CORBA Objects

The goal in CORBA object development is the creation and registration of an object server, or simply server. A server is a program which contains the implementation of one or more object types that has been registered with the ORB. For example, you might develop a desktop publishing server which implements a "Document" object type, a "Paragraph" object type, and other related object types.

CORBA Object Interfaces

All CORBA objects support an IDL interface; the IDL interface defines an object type. An interface can inherit from one or more other interfaces. IDL syntax is very similar to that of Java or C++, and an IDL file is functionally the CORBA language-independent equivalent to a C++ header file. IDL is mapped into each programming language to provide access to object interfaces from that language. With Java IDL, these IDL interfaces can be translated to Java using the idltojava compiler. For each IDL interface, idltojava generates a Java interface and the other .java files needed, including a client stub and a server skeleton.

An IDL interface declares a set of client-accessible operations, exceptions, and typed attributes (values). Each operation has a signature that defines its name, parameters, result, and exceptions. Listing 1-1 shows a simple IDL interface that describes the BEA WebLogic Enterprise sample application called simpapp_java.

Listing 1-1 An IDL Interface for the BEA WebLogic Enterprise Java Simpapp Sample Application

#pragma prefix "beasys.com"

interface Simple
{
     //Convert a string to lower case (return a new string)
     string to_lower(in     string val);

     //Convert a string to upper case (in place)
     void to_upper(inout string val);
};

interface SimpleFactory
{
     Simple find_simple();
};

An operation may raise an exception when an error condition arises. The type of the exception indicates the kind of error that was encountered. Clients must be prepared to handle defined exceptions and CORBA standard exceptions for each operation in addition to normal results.

Java Language-based Implementation

After defining the IDL interfaces, the developer can build two basic types of applications with BEA WebLogic Enterprise:

A remote joint client/server or client, which uses files from the idltojava command for its client stubs (and optionally also its server skeletons).
Note: A remote joint client/server is a client that implements server objects to be used as callback objects. The server role of the remote joint client/server is considerably less robust than that of a BEA WebLogic Enterprise server. Neither the client nor the server has any of the BEA WebLogic Enterprise administrative and infrastructure components, such as tmadmin, JNDI registration, and ISL/ISH (hence, none of scalability and reliability attributes of BEA WebLogic Enterprise).
A server, which uses files from the m3idltojava command for its server skeletons.

The client development sequence is:

Define IDL interfaces for the client.
Run the idltojava compiler on client IDL files.
Implement client calls (and optionally server skeletons).
Compile all .java files into .class files.
Run the client class having a public main method which calls the BEA WebLogic Enterprise server and optionally also provides servants for its objects (when acting as a server).

The server development sequence is:

Define IDL interfaces for the server.
Run m3idltojava on the server IDL files.
Implement servant objects.
Compile all .java files into .class files.
Create the XML Server Descriptor File.
Use the buildjavaserver command to create a JAR file.
Configure the JavaServer with the new JAR file in a UBBCONFIG.
Run tmloadcf on the ubbconfig file to generate a binary tuxconfig file.
Run tmboot on the configuration file (tuxconfig).

An object implementation defines the behavior for all the operations and attributes of the interface it supports. There may be multiple implementations of an interface, each designed to emphasize a specific time and space trade-off, for example. The implementation defines the behavior of the interface and object creation/destruction.

Only servers can create new CORBA objects. Therefore, a factory object interface should be defined and implemented for each object type. For example, if Document is an object type, a DocumentFactory object type with a create method should be defined and implemented as part of the server. (Note that "create" is not reserved; any method name may be used.)

The following example shows how a BEA WebLogic Enterprise server registers a new object:

org.omg.CORBA.Object docoument_oref = TP.create_object_reference(
                     DocumentHelper.id(),  // Repository ID
                     docName,              // Object ID
                     null                  // Routing Criteria
                     );

The TP Framework takes cares of the actual object instantiation:

(new DocumentServant)

A destroy method may be defined and implemented on Document or the object may be intended to persist indefinitely. (Note that "destroy" is not reserved and any name may be used.)

The BEA Java CORBA ORB supports both transient and persistent objects. Persistent objects must be created as callback objects with the Portable Object Adapter (POA) to define a Persistent/User ID Object Policy.

Client Implementation

Client code is included on the CLASSPATH with idltojava-generated .java files and the ORB library.

Clients may only create CORBA objects via the published factory interfaces that the server provides. Likewise, a client may only delete a CORBA object if that object publishes a destruction method. A CORBA object may be shared by many clients on a network, so only the object server can know when the object has become garbage.

The client code only issues method requests on a CORBA object via the object's object reference. The object reference is an opaque structure that identifies a CORBA object's host machine, the port where the ISH is listening for requests, and a pointer to the specific object in the process. Because Java IDL supports only transient objects, this object reference becomes invalid if the BEA WebLogic Enterprise system is stopped and restarted.

Clients typically obtain object references from:

A factory object
For example, the client could invoke a create method on DocumentFactory object to create a new Document. The DocumentFactory create method would return an object refererence for Document to the client.

The use of a factory object to obtain object references is the recommended method for Java CORBA clients in this release of BEA WebLogic Enterprise.
A string that was specially created from an object reference

After an object reference is obtained, the client must narrow it to the appropriate type. IDL supports inheritance; the root of its hierarchy is Object in IDL, org.omg.CORBA.Object in Java. (org.omg.CORBA.Object is, of course, a subclass of java.lang.Object.) Some operations, notably name lookup and unstringifying, return an org.omg.CORBA.Object, which you narrow (using a helper class generated by the idltojava compiler) to the derived type you want the object to be. CORBA objects must be explicitly narrowed because the Java run time cannot always know the exact type of a CORBA object.

The FactoryFinder

The BEA WebLogic Enterprise FactoryFinder interface and the NameManager give you a mechanism for registering, storing, and finding objects across multiple domains or within a single domain in BEA WebLogic Enterprise.

For more information on how the FactoryFinder relates to Java IDL, refer to the topic The FactoryFinder Interface.

For detailed information on how to use the FactoryFinder Interface, see the FactoryFinder Interface chapter in the CORBA Java Programming Reference in the BEA WebLogic Enterprise online documentation.

What's Next?

To get started using Java IDL to build BEA WebLogic Enterprise Java CORBA applications, check out the following examples, concepts, and reference information: