J2SE 1.4
breathes new life into the CORBA community, Part
1
Tutorial Details:
J2SE 1.4 breathes new life into the CORBA community, Part 1
J2SE 1.4 breathes new life into the CORBA community, Part 1
By: By Tarak Modi
Get started developing enterprise CORBA applications with the latest version of J2SE
ver the past decade, CORBA, or the Common Object Request Broker Architecture, has lived up to its initial promise of providing developers an open, standard, and vendor-, platform-, and language-neutral specification for heterogeneous computing. Using the Internet Inter-ORB Protocol (IIOP), a CORBA-based program from any vendor, on most computers, operating systems, programming languages, and networks, can interoperate with a CORBA-based program from the same or different vendor, on most other computers, operating systems, programming languages, and networks. Similarly, Java has lived up equally well to its promise of providing Write Once, Run Anywhere portability, a highly productive implementation environment, and a robust platform. Is it any surprise then that the marriage between CORBA and Java is a match made in heaven?
This article, the first in a series of four, will begin with a brief history on the evolution of CORBA. I will then summarize the major additions to CORBA 2.3.1, the version that J2SE 1.4 supports. Finally, I will end the article with a whirlwind tour in which we'll create an application using CORBA and J2SE.
Read the whole series, "J2SE 1.4 Breathes New Life into the CORBA Community:"
Part 1: Get started developing enterprise CORBA applications with the latest version of J2SE
Part 2: Gain code portability with the Portable Object Adapter
Part 3: Create enterprise-level apps with the POA
Part 4: Portable interceptors and the Interoperable Naming Service
A quick history lesson
In 1991, the Object Management Group (OMG) introduced CORBA 1.1, which defined the interface definition language (IDL) and APIs that enabled client/server object interaction within a specific implementation of an object request broker (ORB). CORBA 2.0, adopted in December 1994, took a major step forward and defined true interoperability between ORBs from different vendors via IIOP, which is the TCP/IP mapping of the General Inter-ORB Protocol (GIOP). CORBA 2.0 mandates that all compliant ORBs support IIOP to ensure interoperability.
Since then, CORBA has evolved slowly (the current version is 2.6.1), but each stage in that evolution has seen the addition of solid features geared towards creating scalable enterprise systems. Sun Microsystems started supporting CORBA in 1998 with the release of JDK 1.2 and the addition of Java IDL and a simple ORB. That began the long-lasting relationship between Java and CORBA. Today, four years later, J2SE 1.4 continues this marriage with support for CORBA 2.3.1. (As mentioned previously, the most recent version of CORBA is 2.6.1; its only significant difference from 2.3.1 is CORBA messaging, added in version 2.4.)
The basic CORBA architecture
Figure 1 shows the essence of a CORBA method invocation. As in most distributed systems, the client references a server application's (or object's) proxy. In CORBA, that proxy is called a stub. The client interacts with this stub as if it were the server and makes method invocations on it. The stub passes the request to the ORB, which, in turn, locates the server application, activating it if necessary. The ORB interacts with the server application through yet another proxy called a skeleton. Ultimately, the server application processes the client request, and the results return to the client through the same chain.
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.
Note: Depending on the CORBA implementation you use, the ORB may be a single executable, multiple executables, or some combination of executables and shared libraries (such as DLLs on Windows). CORBA does not specify how an ORB is implemented. That makes sense: First, how a vendor implements the ORB depends highly on the capabilities of the device (hardware and operating system) upon which the ORB will run. Second, the implementation also depends on other value-adding services, such as load balancing and fault tolerance, that the vendor provides as competitive differentiators. Since the OMG cannot possibly know and control both these aspects, it has refrained from defining an ORB's physical implementation details.
What's new in J2SE 1.4?
As I mentioned earlier, the relationship between Java and CORBA started in 1998 with JDK 1.2, when Sun introduced Java IDL, a Java API for interoperability and integration with CORBA. Java IDL included both a Java-based ORB, which supported IIOP, and the IDL-to-Java compiler, idltojava , for generating client-side stubs and server-side code skeletons. In 1999, Sun released JDK 1.3, newly rechristened as J2SE, and introduced a new, 100% Pure Java IDL-to-Java compiler, idlj , along with support for IDL abstract interfaces and value types. Today, with J2SE 1.4, Sun completely supports the Portable Object Adapter (POA), portable interceptors, Interoperable Naming Service (INS), GIOP 1.2, and dynamic anys. I'll briefly touch upon all of these components in subsequent sections of this article.
J2SE 1.4 also includes a new naming service implementation called Object Request Broker Daemon (ORBD), which lets clients transparently locate and invoke persistent objects on servers in the CORBA environment. ORBD is a daemon process containing a bootstrap service, a transient naming service, a persistent naming service, and a server manager. J2SE 1.4 also supports (for backwards compatibility) tnameserv , which is a transient naming service implementation that originated in JDK 1.2. I recommend using ORBD in all your new applications. We'll be using it in our Hello World example later in this article. I'll talk more about transient and persistent object references in Parts 2 and 3 of this series.
In addition, J2SE 1.4 includes a new tool called servertool , which provides a command-line interface for application programmers to register, unregister, start up, and shut down a persistent server with ORBD. I'll use this tool in Parts 2 and 3 of this series.
Portable Object Adapter
An object adapter in CORBA glues the server applications (objects) and the ORB together. An object adapter creates object references, managing objects' life cycles, dispatching client requests from the ORB to the correct object, and returning request results to the ORB. Until version 2.2, the CORBA specification only described a simple and vague object adapter, appropriately called the Basic Object Adapter (BOA). Since the BOA as described by the specification proved inadequate for creating enterprise applications, each ORB vendor added its own proprietary extensions, sometimes even using the same names as other vendors to create an illusion of interoperability and code portability. CORBA 2.2 introduced the POA, which addressed many of the BOA's deficiencies. True to its name, the POA guarantees code portability across ORBs. The POA has also introduce
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: J2SE 1.4
breathes new life into the CORBA community, Part
1
View Tutorial: J2SE 1.4
breathes new life into the CORBA community, Part
1
Related
Tutorials:
 RMI over IIOP -
JavaWorld
December 1999
RMI over IIOP -
JavaWorld
December 1999
|
Java security evolution
and concepts, Part 1: Security nuts and bolts - JavaWorld April
2000
Java security evolution
and concepts, Part 1: Security nuts and bolts - JavaWorld April
2000
|
J2SE 1.4
premieres Java's assertion
capabilities, Part
1
J2SE 1.4
premieres Java's assertion
capabilities, Part
1
|
J2SE 1.4
premieres Java's
assertion capabilities, Part 2
J2SE 1.4
premieres Java's
assertion capabilities, Part 2
|
Java security evolution
and concepts, Part 5
Java security evolution
and concepts, Part 5
|
Trace your steps in Java 1.4
Trace your steps in Java 1.4
|
Discover and publish Web services with JAXR
Discover and publish Web services with JAXR
|
Rumble in the
jungle: J2EE versus .Net, Part
1
Rumble in the
jungle: J2EE versus .Net, Part
1
|
J2SE 1.4
breathes new life into the CORBA community, Part
1
J2SE 1.4
breathes new life into the CORBA community, Part
1
|
Business process
automation
made easy with
Java, Part 1
Business process
automation
made easy with
Java, Part 1
|
J2SE 1.4
breathes new life into the CORBA community, Part
2
J2SE 1.4
breathes new life into the CORBA community, Part
2
|
J2SE 1.4
breathes new life into the CORBA community, Part
3
J2SE 1.4
breathes new life into the CORBA community, Part
3
|
Check out three
collections libraries
Check out three
collections libraries
|
J2SE 1.4
breathes new life into the CORBA community, Part
4
J2SE 1.4
breathes new life into the CORBA community, Part
4
|
J2EE 1.4 eases Web service development
J2EE 1.4 eases Web service development
|
Overcome J2SE
1.3-1.4 incompatibilities
Overcome J2SE
1.3-1.4 incompatibilities
|
Taming Tiger
Taming Tiger, Part 2
Understanding generics
Welcome to the second part of this three-part series on Sun Microsystems' latest release of the Java 2 Platform, Standard Edition (J2SE). To refresh your memory, Part 1 was a quick introduction to J2SE 1.5
|
Bridging the Gap: J2SE 5.0 Annotations
Bridging the Gap: J2SE 5.0 Annotations
It takes a long time for the Java community to fully absorb a major new JDK release; it seems to take about two more releases after a brand new version of the JDK before everything settles down. Application server v
|
Network Programming with JavaTM 2 Platform, Standard Edition 1.4 (J2SETM)
This article provides an overview of the new features and enhancements in the Java 2 Platform, Standard Edition 1.4 (J2SE), and shows you how to use them effectively.
|
Five Reasons to Move to the J2SE 5 Platform
Five important reasons to move to the Java 2 Platform, Standard Edition (J2SE platform) 5.0, supported by data and references to prove that the 5.0 release will reduce development and runtime costs.
|
|
|
|
