Developing Clients

This document was not updated for the J2SE^TM release. If you downloaded this document as part of the J2SE^TM documentation bundle, check the Web site at http://java.sun.com/j2se/1.4.2/docs/guide/idl/jidlClients.html for updates.

When updated, topics in this section will include:

• ORBs and Invocations
• Static Invocation
• Dynamic Invocation

For a client to invoke a CORBA object operation, both the client and the server (the object implementation) must use a CORBA software component called an ORB (object request broker). ORBs are the common denominators that bridge the differences in location, platform, and programming language that can separate a client and a server. ORBs can contact each other across the network, can create and interpret object references (CORBA object handles), and can marshal parameters into and out of the format used by IIOP. In addition to enabling client/server communication, ORBs provide other services, but they are not described here.

The two ways to invoke an operation on a CORBA object are:

• Static invocation, which is used most often and most resembles conventional Java programming, is type-checked by the compiler. But it can only be used for objects whose interface definitions exist when the invoking client is compiled.

• Dynamic invocation is more flexible because clients can invoke objects they discover at runtime. However, compile-time type-checking is impossible with dynamic invocation. Although it's possible to type-check parameters at runtime, doing so requires a CORBA Interface Repository, which the current release of Java IDL does not provide.

To make a static invocation on a CORBA object, a Java client needs an object reference to the servant that performs the operation. The object reference has two important functions:

• It uniquely identifies the servant, wherever it is located.

• It implements the client stub interface, making the reference a local proxy for the servant object.

OMG IDL is the language in which CORBA object interfaces are defined. For each OMG IDL module, the idlj compiler generates a Java package. For each interface Foo defined in an OMG IDL module, the generated package contains the following items of interest to the client programmer:

• A Java signature interface Foo, which extends org.omg.portable.IDLEntity, org.omg.CORBA.Object, and the operations interface. The signature interface is used as the signature type in method declarations when interfaces of the specified type are used in other interfaces. From the client's point of view, an object reference for a CORBA Foo object implements this interface.

  Note: The Stub implements the Foo interface, where it generates code for each method to marshall the arguments, invoke the method, and then unmarshall the arguments.

• A Java operations interface FooOperations, which is used in the server-side mapping and as a mechanism for providing optimized calls for co-located clients and server. The server developer provides implementation for the methods indicated by the operations interface.

  Note: The server writer usually extends FooPOA and provides implementation for the methods provided by the operations interface.

• A Java class FooHelper, that defines auxiliary methods, notably narrow(), which is the CORBA counterpart of Java casting.

• A Java class called FooHolder, that holds a public Foo member. Holders are required for CORBA operations that take out or inout arguments, which, unlike CORBA in arguments, don't map directly to Java's pass-by-value semantics.

CORBA dynamic invocation uses an object called a request to hold everything pertinent to an invocation: the object reference, the name of the operation, its parameters, and space for the result. The client builds a request object describing an operation, then calls the request's invoke method, which dispatches the request just as a stub would. When the invoke method returns, the result is available in the request object.

The key to dynamic invocation is the ability of requests to hold self-describing data. This facility enables a request object to represent any invocation of any operation, regardless of its parameters. Each self-describing data element has a special type known in OMG IDL as Any. An Any consists of a typecode (whose values are defined by OMG IDL) and a value; the typecode specifies the type of the value.