Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Standard Edition >

J2SE 1.4 breathes new life into the CORBA community, Part 1

Get started developing enterprise CORBA applications with the latest version of J2SE

By Tarak Modi, JavaWorld.com, 08/30/02

  • Print
  • Feedback

Page 2 of 6

Figure 1. A typical CORBA method invocation sequence

Yes, I glossed over several details above. First, I described a synchronous request; that is, the client waits for its request's response before proceeding further. CORBA 2.3.1 also supports a deferred synchronous request—also called polling—in which the client can return periodically and ask the ORB if it has received a response to its prior request(s). Another request type is the one-way request, the CORBA name for fire and forget. Here the client makes the request and then forgets about it. CORBA does not mandate any guarantees about how ORBs implement these one-way requests. For example, an ORB that never delivers any one-way requests would be completely CORBA compliant (eeks!). Finally, CORBA 2.4 introduces a sophisticated asynchronous messaging architecture, which stretches beyond the scope of this series since it is not part of J2SE 1.4 (which, as you should have memorized by now, supports CORBA 2.3.1).

Other points that I glossed over include the communication protocol(s) involved in the method invocations and the ORB organization. Conceptually, the ORB is composed of two main parts: a client-side runtime and a server-side runtime. The stubs are part of the client-side runtime, and the skeletons are part of the server-side runtime. When only one ORB is involved in the picture, as in our example so far, the communication protocol used between the client- and server-side runtimes may be IIOP or any other protocol of the vendor's choice. Figure 2 illustrates that. Many commercial ORBs use a highly optimized and efficient protocol in such cases. But remember: All ORBs compliant with versions 2.0 and higher of CORBA must support communication using IIOP as well, to ensure interoperability across ORBs.

Figure 2. Interoperability between ORBs

Now look at Figure 3, which shows the same scenario as Figure 1, with one major difference: the client application is created to work with Vendor 1's ORB, and the server application works with Vendor 2's ORB. Luckily both ORBs are at least CORBA 2.0 compliant and can communicate via IIOP; otherwise (consistent) communications between them could not be guaranteed.

Figure 3. A client invoking a method on a server in another vendor's ORB. Click on thumbnail to view full-size image.

Now let's go into more detail about the client-side ORB runtime. As mentioned above, the stub is part of the client-side ORB. A stub is precompiled and tailor-made (and most likely compiler-generated) for a specific server application. But clients do not have to interact with a server application using these stubs. CORBA defines the dynamic invocation interface (DII), which is a general-purpose API for invoking methods on a remote server application. In most cases, the DII proves harder to use than stubs and slightly less efficient as well. However, you need to use DII sometimes—for the development of general-purpose tools, for example, or to make deferred synchronous method calls.

  • Print
  • Feedback

Resources