Uh-oh, it looks like your Internet Explorer is out of date.

For a better shopping experience, please upgrade now.

Java Enterprise in a Nutshell

Java Enterprise in a Nutshell

5.0 1
by William Crawford, Jim Farley, David Flanagan

Nothing is as constant as change, and this is as true in enterprise computing as anywhere else. Since Java Enterprise in a Nutshell was first published in September of 1999, a dozen or more new APIs have been added to the platform, reflecting the new and different ways developers implement their enterprise objectives. And now developers are being called on to add


Nothing is as constant as change, and this is as true in enterprise computing as anywhere else. Since Java Enterprise in a Nutshell was first published in September of 1999, a dozen or more new APIs have been added to the platform, reflecting the new and different ways developers implement their enterprise objectives. And now developers are being called on to add even greater, more complex levels of interconnectivity to their applications, as the concepts behind Web Services solidify and implementation decisions need coding.Java developers today need a clear understanding of the new APIs, tools, capabilities and pitfalls in J2EE 2.0 so they can plan a technology and implementation strategy for new enterprise projects. Fortunately, this is exactly what they get with the new Java Enterprise in a Nutshell, 2nd edition!Completely revised and updated for the new 2.0 version of Sun Microsystems Java Enterprise Edition software, Java Enterprise in a Nutshell 2nd edition covers all of the J2EE APIs, including RMI, Java IDL, JDBC, JNDI, Java Servlet, and Enterprise JavaBeans, with a fast-paced tutorial and compact reference on each technology. Then Java Enterprise in a Nutshell goes even further, providing a classic O'Reilly-style quick reference for all of the classes in the various packages that comprise the Enterprise APIs - covering the core enterprise APIs as well as numerous standard extensions.

Product Details

O'Reilly Media, Incorporated
Publication date:
In a Nutshell (O'Reilly) Series
Edition description:
Second Edition
Product dimensions:
6.02(w) x 8.98(h) x 1.75(d)

Read an Excerpt

Chapter 4: Java IDL

4.4.3 Stringified Object References

As we've seen, Sun's implementation of Java IDL provides a nonstandard way to initialize an ORB to reference a remote Naming Service, so that one of the ORB's initial references is to the root context of the remote Naming Service. But what do you do if you want an object from a remote Naming Service, and your Java IDL implementation doesn't provide a way to directly initialize a reference to the remote service? Or, worse yet, what if the object that you want isn't stored in a Naming Service or available through any other CORBA service? How can your client get a reference to the object?

The CORBA standard comes to the rescue again. Part of the standard, called Interoperable Object References (IORs), includes a syntax for representing a remote object reference in the form of a printable string of characters. This stringified object reference includes enough information for a remote CORBA client to locate the object's home ORB and convert the string to a runtime stub reference to the object. Two methods on the ORB interface, object_to_string() and string_to_object(), let you convert a CORBA object reference to string form and back again.

Example 4.9 shows how to create an instance of our server implementation of the ThisOrThatServer interface, register it with the ORB, and generate a stringified object reference from the CORBA server object. A stringified reference to a remote object is called an Interoperable Object Reference (IOR) because it uses a format for object references that can be freely distributed between ORBs running a cross the network. In order for the IOR you generate to be acceptable to another ORB, both your ORB and the remote ORB have to be using the same inter-ORB communication protocol (IIOP, DCE-CIOP, etc.). In this example, our client and host are both running IIOP.

Example 4.9: Registering an Object/Getting Its Stringified Object Reference

import org.omg.CORBA.*; public class ServerInit {   public static void main(String[] argv) {   } }

The ServerInit class contains a main() method that is intended to be run on the server host for our remote object. The main() method first initializes a connection to the local ORB and then creates an instance of the ThisOrThatServerImpl class. This instance serves as the server implementation of our remote object. We create a stringified reference to the object using the object_to_string() method on the ORB and then output the stringified reference, so that it can be copied and sent to clients. Finally, by doing a synchronous wait() on a local object, the main() method goes into a wait state. This wait() is necessary to keep the ORB running so that it can respond to client requests. If we let the main() method exit, the server object we created is destroyed, and the IOR we generated is no longer valid.

A sample client for our object is shown in Example 4.10. The client accepts a stringified object reference as a command-line argument to its main() method. Then it initializes a local ORB reference and uses its string_to_object() method to convert the stringified reference to a live object reference. To do this, the ORB parses the encoded information in the stringified reference, makes a connection with the remote ORB serving the object, and generates a CORBA object reference for the client.

Example 4.10: A Client Utilizing a Stringified Object Reference

import org.omg.CORBA.*; public class ServerStringClient {   public static void main(String[] argv) {   } }

Before we can run the client, the remote object has to be registered with its ORB, so that we can get the stringified object reference:

objhost% java ServerInit ThisOrThatServer IOR: IOR:000000000000002349444c3a6a656e2f636f7262612f546869 734f72546861745365727665723a312e30000000000001000000000000003000010000000000 0a6c6f63616c686f737400043200000018afabcafe00000002496bb469000000080000000000 000000

Somehow, you have to get this IOR to the client host. You could embed the stringified object reference within a hidden field in a HTML page, so that a Java client can access it using a URL object. Or you could set up a simple server on a given port on your host that broadcasts the stringified object reference to whoever makes a socket connection. Or you could email the string to a colleague, and she can type the stringified reference into the startup command for her CORBA client. In any case, the client is invoked with the IOR as a command-line option:

clienthost% java ServerStringClient IOR:000000000000002349444c3a6a656e2f636f 7262612f546869734f72546861745365727665723a312e300000000000010000000000000030 000100000000000a6c6f63616c686f737400043200000018afabcafe00000002496bb4690000 00080000000000000000

The client uses the argument to reconstitute a remote reference to the server object, so that it can invoke methods on the remote object.

4.5 What If I Don't Know the Interface?

In the examples we've seen so far, we've always assumed that the Java interfaces for the remote objects are available at compile time. But what happens if they aren't? You might get a reference to a CORBA Object from a Naming Service, for example, and not know what interface that object implements. I mentioned earlier that you can use an org.omg.CORBA.Object reference directly to make requests and exchange data with its remote object.

The CORBA standard defines two complementary APIs for this purpose: the Dynamic Invocation Interface (DII) that a client can use to make remote method requests of a server object, and the Dynamic Skeleton Interface (DSI) that a server-side skeleton can use to forward method invocations to its server implementation object. Both of these APIs provide the same essential function: a dynamic interface to an object whose interface is not known at compile time. The DII offers this functionality to clients of CORBA objects, and the DSI provides it to the server-side skeletons that bridge the object implementation with the ORB.

The DII and DSI may seem like sidebar topics in the CORBA world, but in reality they are at the heart of CORBA and how it works. When we generate Java stubs and skeletons from IDL interfaces, the code that is generated uses the DII and DSI to execute remote method calls. The details of how this is done are shielded from you, the developer, by the Java interface you use to interact with the remote object. But it's still worthwhile to understand how CORBA objects implement their distributed nature, especially in situations where the Java interface for the remote object is not there, and you need to deal directly with these details.

In this section, we take a look at how the DII works and how you might use it in a client. We won't cover the DSI in this book, since its practical uses are even more limited for the average developer. Note, however, that the API of the DSI is analogous to that of the DII, so you shouldn't have much trouble mapping the following explanation to the DSI as well.

4.5.1 Dynamic Invocation Interface

The Dynamic Invocation Interface provides abstract representations of remote method requests and their arguments. In simple terms, this means it includes objects that represent remote method requests and parameters that are passed with these method requests. Methods on these objects allow you to set the parameters to the request, make the request, and get the results. DII's central classes are:


A request to invoke a method on a remote object. Created by the client and issued through the ORB to the server object.


A named parameter to a method request. Conceptually, this is a name tied to an Any value. The name of the value must match the name of the parameter as specified in the IDL interface the remote object satisfies.


A list of NamedValue parameters used to represent an argument list passed into a remote method request.


A general argument value. An Any object can contain the Java equivalent of any basic IDL type or an Object that can be described in IDL.


A list of NamedValue objects used to specify any details of the client environment that shouldn't be passed as method arguments.

Once you get an org.omg.CORBA.Object reference to a remote object (using any of the approaches we've already covered), you can create and issue a method request to the object by building a parameter list for the method call, making a NamedValue object to hold the result, making a Context object and putting any useful environment values in it, and then using all of these items to create a Request object that corresponds to a particular method on the object. Example 4.11 shows a sample DII client that gets a reference to a remote object through a Naming Service and then makes a dynamic call to its doThis() method.

Example 4.11: Client Using DII to Make Remote Method Call

import org.omg.CORBA.*; import org.omg.CosNaming.*; public class DIISimpleClient {   public static void main(String argv[]) {   } }

Note that in most situations you will have the Java interface for the remote object available in your client along with its helper class, so you'll be able to narrow the Object reference to a specific type. One exception might be if you're building some kind of software development tool, and you want to provide a dynamic execution utility for the CORBA code being developed. The previous example demonstrates how a CORBA method call can be carried out at this lower level, in case you ever find it necessary to do so. And when you're trying to fix a problem with your CORBA application, it's always better to understand what's going on under the hood, so to speak.

Meet the Author

William Crawford has been developing web-based enterprise applications since 1995, including one of the first web-based electronic medical record systems (at Children's Hospital in Boston) and some of the first enterprise-level uses of Java. He has consulted for a variety of institutional clients, including Boston Children's Hospital, Harvard Medical Center, numerous startups and several Fortune 500 companies. Prior to an acquisition he was CTO of Invantage, Incorporated in Cambridge, MA. He received a degree in history and economics from Yale University. He is the co-author of Java Servlet Programming, 2nd Edition, Java Enterprise in a Nutshell, 2nd Edition, and two forthcoming O'Reilly titles. Will is currently Principal Software Architect at Perceptive Informatics, Inc.Massachusetts, provider of software and services to the pharmaceutical industry. He can be reached at http://www.williamcrawford.info

Jim Farley is a software engineer, computer scientist, and IT manager. His recent activities have included heading up the engineering group at the Harvard Business School and bringing good things to life at GE's Research and Development center. He's dealt with computing (distributed and otherwise) in lots of different ways, from automated image inspection to temporal reasoning systems. Jim has Bachelor's and Master's degrees in computer systems engineering from Rensselaer Polytechnic Institute.

David Flanagan is a computer programmer who spends most of his time writing about JavaScript and Java. His books with O'Reilly include Java in a Nutshell, Java Examples in a Nutshell, Java Foundation Classes in a Nutshell, JavaScript: The Definitive Guide, and JavaScript Pocket Reference. David has a degree in computer science and engineering from the Massachusetts Institute of Technology. He lives with his wife and son in the U.S. Pacific Northwest bewteen the cities of Seattle, Washington and Vancouver, British Columbia. David has a simple website at http://www.davidflanagan.com.

Customer Reviews

Average Review:

Post to your social network


Most Helpful Customer Reviews

See all customer reviews

Java Enterprise in a Nutshell 3 out of 5 based on 0 ratings. 1 reviews.
Guest More than 1 year ago
This book is a good quick reference to the J2EE technology. True to the name, this book outlines all the J2EE 1.3 technologies including JDBC, RMI (and CORBA), Servlets, JSP, JNDI, EJB, XML, JMS, JavaMail. It also contains a couple of reference chapters including SQL, RMI tools, IDL reference, CORBA services, IDL Tools, and EJB QL. The API coverage of the book is pretty complete with good code samples in each chapter outlining the APIs. Unfortunately, 50% of the entire book (about 500 pages) are java class references (Javadocs) which in my opinion will be a lot more effective with just an URL pointing to the official on-line API references. This makes the book a little too bulky to carry around. As the name suggest, this book do not attempt to show you how everything comes together building a full fledge J2EE application, but to briefly introduce to the reader all the J2EE 1.3 compliance APIs as individual pieces. Therefore, do not expect this book to teach you how all the APIs come together. Anyhow, this is a good book to have if you are familiar with the concepts of the J2EE APIs and need to quickly lookup an example on how the API works.