Object Distribution

Object Distribution

The first of the problems addressed by EJBs is that objects in an enterprise-scalable system need to be distributed. In short, this means that the parts of your program should be able to be deployed to as many different physical machines and in as many separate operating system processes as appropriate to achieve the performance, scalability, availability, and reliability goals of your system.

Another reason to distribute objects is to take a system that is logically layered and implement the layering as physical tiers—in this way a set of distributed objects can be accessed from multiple, independently developed systems so long as those objects provide a single, common, networked API for the new systems to build on.

In the previous chapters, applications handled distribution by either HTTP or a remote connection to a database management system. HTTP provides a very simple, stateless means of accessing coarse-grained distributed resources. This works well for HTML pages and other document-centered resources, but it does not support the rich semantics that are often required for distributed business applications.

HTTP is one of a number of distribution technologies today, but in the Java world, two technologies stand out as especially widespread and important: OMG CORBA object distribution model and Sun Java Remote Method Invocation (RMI) protocol.

Not coincidentally, they are the two that form the core of the distribution solution for EJBs. Since this book is not about either CORBA or RMI, we refer the reader to other works like [Orfali] that provide a more detailed overview of these technologies.

We do need to look at a couple of the pros and cons of each technology to understand why the EJB model has evolved as it has. Along the way, we will point out areas that we will cover more in-depth as we begin to examine the EJB distribution model.

1 A Quick Overview of CORBA

CORBA was developed by a consortium of companies during the early 1990s to provide a common language and vendor-neutral standard for object distribution. CORBA has been well accepted since its inception, with a number of products and vendors supporting the CORBA standard, and a long history of successful projects developed using it.

The heart of CORBA is the idea of a special-purpose piece of software, an ORB that facilitates communication between object spaces. The CORBA model requires an ORB on both ends of the distributed system. The ORB is responsible for handling the marshaling of parameters from outgoing method invocations to a CORBA proxy, and responsible for receiving messages on the other end of a conversation and turning them into local messages to a CORBA stub that can then act on the received message and return a response to the calling object.

There are two more major pieces of the CORBA model: IDL, the language in which CORBA interfaces are defined; and CORBA Services, which provide standard ways for CORBA objects to interact. CORBA Services include things like naming, transactions, etc., which we will see are major parts of building a distributed system. By default, CORBA uses IIOP for low-level communication between ORBs.

CORBA is a robust and complete set of technologies that are both mature and well understood. Some of the advantages of CORBA are:

  • It is a standard interface. This makes it possible for multiple vendors to implement their own products based on the standard, and makes it possible for these products to interoperate.

  • It is computer language neutral. CORBA clients and servers can be written in a variety of computer languages, including Java, C++, C, Smalltalk, and Ada. The only requirement is that the remote interfaces for CORBA-distributed objects be written in CORBA IDL, which is translated into classes in the target implementation language through a postprocessor (a CORBA compiler).

  • It provides a specification of common services that are required by most distributed applications, simplifying application development by eliminating the need for each program to recreate its own implementation.

However, the technology cannot be all things to all people. Two disadvantages to using CORBA to build distributed systems in Java are:

  • Developers must use two languages: IDL and Java

  • Very few vendors implement all of the optional services like security and transactions, making it difficult to buy a complete infrastructure.

As a result, CORBA has not made the great inroads into corporate Information Systems (IS) departments that its originators had hoped. Instead, developers started to look for simpler solutions, but solutions that perhaps were not as flexible and powerful. Out of that search grew the interest in Java RMI.

2 A Brief Overview and History of RMI

Java RMI is a standard part of the Sun JDK 1.1 and the Java 2 platform. RMI is an all-Java distribution solution. Its primary advantages are that it features a very simple programming model that does not require programming in two languages (Java and IDL) like CORBA, and does not require you to purchase additional ORB and CORBA tools.

RMI's programming model is very simple. It has the notion of a remote object and a remote interface as its two primary constituents. A remote object is an object whose methods can be invoked from another JVM, potentially on a different host. A remote object is described by one or more remote interfaces, which are Java interfaces that declare the methods of the remote object. RMI is the action of invoking a method of a remote interface on a remote object.

Remote interfaces are standard Java interfaces that extend java.rmi.Remote.

Remote objects can be any class of objects that implement a remote interface, although more often than not remote objects extend java.rmi.server.UnicastRemoteObject.

An advanced feature in RMI that is not in CORBA is distributed garbage collection. A feature that is not directly supported in CORBA is the notion of pass-by-value objects. In RMI, any Java object that implements java.io.Serializable can be passed as a method parameter to a remote object, and it will be serialized on the client end, and deserialized on the server end, allowing the server to operate on a local copy of the parameter.[1]

[1] Java serialization is a technology that is often poorly understood. For an explanation of serialization, see [Horstmann]

While RMI is very powerful, it doesn't support multiple languages, nor does it support all of the services that CORBA supports. For instance, RMI includes a naming service, but not other CORBA Services like transactions or persistence.

Also, there is a perceived lack of security in systems using RMI. While RMI includes a security manager that allows applets to use RMI, its lack of authentication and other security protocols, and the lack of support for RMI in corporate firewall systems have made its introduction more problematic than that of CORBA, which does not have these perceived problems. These reasons lead to the combination of the two technologies (RMI over IIOP).

RMI over IIOP combines the best features of RMI with those of CORBA. Like RMI, RMI over IIOP allows developers to develop purely in Java. Developers do not have to develop in both Java and IDL. Like RMI, RMI over IIOP allows developers to write classes that pass any serializable Java object as remote method arguments or return values. However, RMI over IIOP uses IIOP as its communication protocol, so it is interoperable with other CORBA applications. The combination of these two technologies forms an unbeatable combination of power and ease of use.

3 Some of the Remaining Holes

So, RMI makes distributed programming a much simpler proposition for Java programmers, and RMI over IIOP gives programmers the ease of use of RMI combined with the interoperability of CORBA. However, there are still many hard problems left in building distributed systems. In particular, RMI did not include direct support for a common distribution idiom that had initially emerged to circumvent a drawback for CORBA. One of the CORBA Services that had been proposed, partially to deal with the fact that CORBA had no facilities like distributed garbage collection, was the CORBA Lifecycle Service. At the heart of this service specification was the idea of a factory[2] object that served as a source of other distributed objects. The factory created objects and retrieved existing instances where appropriate. Most CORBA systems had evolved into using this idiom, even where the Lifecycle Service was not fully implemented.

[2] A factory object's job is to create other objects. The Factory Method and Abstract Factory Design Patterns [Gamma] are specializations of this more general pattern.

4 Where This Leads Us

Luckily, developers can now take advantage of both of these useful pieces of technology that have addressed the prior issues of CORBA and RMI. EJBs use RMI over IIOP as their base distribution technology. Likewise, in J2EE, the EJB home interfaces play the role factory objects, incorporating object lifecycle management. We will examine these issues in more depth when we introduce the EJB programming model in Chapter 19.

     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows