Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	e-docs.beasys.com   |   Site Map   |   Search   |   PDF Files   |   Contact   |   Glossary
WLE Doc Home   |   idltojava Compiler and Related Topics   |   Previous   |   Next   |   Contents   |   Index

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

The WLE 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. Runtime 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?

• How does the BEA idltojava compiler differ from the Sun Microsystems, Inc. version?

• What is IDL?

• What is Java IDL?

• About Distributed Applications

• About CORBA and Java IDL

• What's next?

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 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 BEA WLE idltojava compiler provided with WLE includes several enhancements, extensions and additions that are not included in the original compiler produced by Sun Microsystems, Inc. The WLE specific revisions are summarized here. For detailed information on using the idltojava compiler provided with WLE, see the topic Using the idltojava Command.

The WLE idltojava compiler:

• The 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 WLE system provides its own "brand" of Java IDL. In other words, as a J2EE implementation, WLE provides all of the components you need to build Java applications capable of accessing CORBA objects. The key components in WLE are:

• WLE idltojava compiler- A tool for converting IDL interface definitions to Java stub and skeleton files

• WLE CORBA Object Request Broker (ORB)

• Java Naming and Directory Interface (JNDI)-The standard naming service available in the Java 2 Enterprise Edition (J2EE)

• Bootstrap Object and FactoryFinder-WLE objects that work in conjunction with the naming service to supply local and remote object references

About Distributed Applications

The term distributed computing refers to the paradigm in which data and applications in a system are spread out over multiple hosts on a network. Over time, more and more enterprises are moving applications and data to where they can operate most efficiently in the enterprise, to some mix of desktop workstations, local area network servers, regional servers, Web servers, and other servers. "Client-server" computing fits into this model in that it implies that clients will provide certain capabilities for a user and request others from server applications that provide services for the clients. The servers can be on remote machines. The Web's HTTP protocol is an example.

The e-business market that is emerging today in the context of the World Wide Web demands an object-oriented view of distributed computing as a basis for business systems.

This section discusses general concepts that relate to all distributed computing environments:

• Multi-Tiered Applications

• User Interface Tier

• Service or Business Logic Tier

• Data Store (Database) Tier

Multi-Tiered Applications

Traditional enterprise applications are, for the most part, self-contained monolithic programs with limited access to one another's procedures and data. They are usually cumbersome to build and expensive to maintain because even simple changes require the entire program to be recompiled and retested.

By contrast, applications built using distributed objects such as CORBA naturally lend themselves to a multi-tiered architecture, resulting in a useful separation of concerns.

A three-tiered application has a user interface code layer, a computation code (or business logic) layer, and a database access layer. All interaction between the layers occurs via the interfaces that all CORBA objects must publish. Figure 1-1 illustrates the transition from monolithic applications to multi-tiered, modular applications.

Figure 1-1 Transition from Monolithic to Multi-Tiered Applications

User Interface Tier

The user interface (UI) tier is the layer of user interaction. Its focus is on efficient user interface design and accessibility throughout your organization. The user interface tier can reside on the user's desktop, on your organization's intranet, or on the World Wide Web (Internet). Several user interface implementations may be deployed which access the same server. The UI tier usually invokes methods on the business logic tier and thus acts as a client of the business logic servers.

Service or Business Logic Tier

The service, or business logic layer, is server-based code with which the client code interacts. The business logic layer is made up of business objects: CORBA objects that perform logical business functions such as inventory control, budget, sales orders, and billing. These objects invoke methods on the Database tier objects.

Data Store (Database) Tier

The data store layer is made up of objects that encapsulate database routines and interact directly with the DBMS product(s). For example, a hypothetical get_Sales_Sum method might be implemented to obtain data from a relational database via the appropriate appropriate JDBC SQL SELECT statements.

About CORBA and Java IDL

The following sections explain more about CORBA and Java IDL:

• About CORBA

• Accessing CORBA Objects from Java Applications

• A Quick Review of CORBA Concepts

• Defining and Implementing CORBA Objects

• Client Implementation

• The FactoryFinder

About CORBA

The Common Object Request Broker Architecture (CORBA) is the standard distributed object architecture developed by the OMG Consortium. The OMG has specified an architecture for an open software bus, or Object Request Broker (ORB), on which object components written by different vendors can interoperate across networks and operating systems. This standard allows CORBA objects to invoke one another without knowing where the objects they access reside or in what language the requested objects are implemented. The OMG-specified Interface Definition Language (IDL) is used to define the interfaces to CORBA objects.

CORBA objects differ from typical programming language objects in these ways:

• CORBA objects can be located anywhere on a network.

• CORBA objects can interoperate with objects on other platforms.

• CORBA objects can be written in any programming language for which there is a mapping from OMG IDL to that language. (Mappings currently specified include Java, C++, C, Smalltalk, COBOL, and Ada.)

Accessing CORBA Objects from Java Applications

To make it possible for you to access CORBA objects from your Java applications, WLE provides the following features which are integral to the "Java IDL" programming model:

• WLE idltojava compiler-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.

• WLE 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 WLE 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 Understanding Server-to-Server Communication in the WebLogic Enterprise online documentation.

• Java Naming and Directory Interface (JNDI)-The capability of looking up and locating objects in WLE is provided by the Java Naming and Directory Interface (JNDI), a standard J2EE naming service. JNDI is used along with the BEA WLE Bootstrap object and FactoryFinder to resolve object references.

• Bootstrap Object and FactoryFinder-The client application uses the Bootstrap object to obtain initial object references to key objects in a WLE 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 WLE Java CORBA ORB supports both transient and persistent objects.

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

A Quick Review of CORBA Concepts

The concepts introduced in this section are more completely discussed in the CORBA/IIOP 2.0 Specification.

Figure 1-2 shows a method request sent from a client to a CORBA object implementation in a server. A client is any code (perhaps itself a CORBA object) that invokes a method on a CORBA object. The servant is an instance of the object implementation - the actual code and data that implements the CORBA object.

Figure 1-2 Method Request from a Client to a CORBA Object

The client of a CORBA object has an object reference for the object and the client uses this object reference to issue method requests. If the server object is remote, the object reference points to a stub function, which uses the ORB to forward invocations to the server object. The stub code uses the ORB to identify the machine that runs the server object and asks that machine's ORB for a connection to the object's server. When the stub code has the connection, it sends the object reference and parameters to the skeleton code linked to the destination object's implementation. The skeleton code transforms the call and parameters into the required implementation-specific format and calls the object. Any results or exceptions are returned along the same path.

The client has no knowledge of the CORBA object's location, implementation details, nor which ORB is used to access the object. Different ORBs communicate via the OMG-specified Internet InterORB Protocol (IIOP).

A client may only invoke methods that are specified in the CORBA object's interface, which is defined using the OMG Interface Definition Language (IDL). An interface defines an object type and specifies a set of named methods and parameters, as well as the exception types that these methods may return. An IDL compiler such as idltojava translates the CORBA object definitions into a specific programming language according to the appropriate OMG language mapping. Thus, the idltojava compiler translates IDL defintions into Java constructs according to the IDL-Java language mapping.

The stub and skeleton files are generated by the idltojava compiler for each object type. Stub files present the client with access to IDL-defined methods in the client programming language. The server skeleton files glue the object implementation to the ORB run time. The ORB uses the skeletons to dispatch methods to the object implementation instances (servants).

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 and which 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 WLE sample application called SimpApp .

Listing 1-1 An IDL Interface for the WLE 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 WLE:

• 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 WLE server. Neither the client nor the server has any of the WLE administrative and infrastructure components, such as tmadmin , JNDI registration, and ISL/ISH (hence, none of scalability and reliability attributes of WLE)

• A server, which uses files from the m3idltojava command for its server skeletons.

The client development sequence is:

1. Define IDL interfaces for the client.

2. Run the idltojava compiler on client IDL files.

3. Implement client calls (and optionally server skeletons).

4. Compile all .java files into .class files.

5. Run the client class having a public main method which calls the WLE server and optionally also provides servants for its objects (when acting as a server).

The server development sequence is:

1. Define IDL interfaces for the server.

2. Run m3idltojava on the server IDL files.

3. Implement servant objects.

4. Compile all .java files into .class files.

5. Create the XML Server Descriptor File.

6. Use the buildjavaserver command to create a jar file.

7. Configure the JavaServer with the new jar file in a UBBCONFIG

8. Run tmloadcf on the ubbconfig file to generate a binary tuxconfig file

9. 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.)

For example, here is how a WLE 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 which 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 WLE 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 WLE.

• 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 WLE FactoryFinder interface and the NameManager give you a mechanism for registering, storing, and finding objects across multiple domains or within a single domain in WLE.

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

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

What's next?

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

• Using the idltojava Command

• Java IDL Examples

• Java IDL Programming Concepts

• IDL to Java Mappings Used By the idltojava Compiler

• The Java IDL API