Database-oriented, Java-enabled middleware is the oldest and best supported of these categories. It follows that, in order for Java to be successful, it would have to access most relational databases. The JDBC specifications have become the ODBC for the world of Java and are now found in most tools and application servers that support Java. You'll find detailed information about JDBC in Chapter 11.

In addition to connecting to databases, JavaSoft provides Remote Method Invocation (RMI). RMI is a simple synchronous mechanism that allows applets to communicate with other applets, invoking each other's methods, as needed. For instance, you can download an applet that's able to connect to an Enterprise JavaBean running on a remote Web server, and invoke a method that updates a database with customer information. This communication can take place in the same machine or over a network. A useful perspective on this process is as "a poor man's distributed object." RMI benefits EAI projects by sharing information with other applets and servlets scattered throughout an enterprise.

With RMI as an intramachine and intermachine IPC (Inter-Process Communication) mechanism for Java applets and applications, there are those who claim that RMI and CORBA provide the same value. This view is strengthened by JavaSoft's and OMG's exploration of the integration of RMI standards with CORBA standards. While the ultimate corporate strategy here might be to "gang up" on the Microsoft COM middleware revolution while adding value to each set of standards, the benefit to an EAI solution is less certain, depending on the specific requirements of the particular EAI project. In other words, don't buy into the message being spouted by that guy on the soapbox—at least, not yet.

There are many things to consider when comparing RMI to CORBA. First, RMI-enabled applets and applications can communicate only with other RMI-enabled objects. As a result, forget about invoking methods written in other languages, such as C++. In addition, RMI fails to provide a language-neutral messaging service. Unlike Java, RMI does not provide support for a wire protocol for security. Neither does it support the notion of transactions. RMI is unable to provide support for self-describing objects or dynamic invocations.

As always, before rushing forward based on exaggerated claims, the EAI architect and developer must "take a deep breath" and look at the specific project at hand. If the EAI project is "Java and nothing but Java" and there is no requirement to link external resources, or wire-level security—in short, if the EAI project skirts wide of the shortcomings of RMI—then RMI is fine. However, the architect and developer should remember that the decision to use RMI means conceding features that may be required as the application matures.

The bottom line here is that RMI technology is lightweight and bound to Java, while CORBA is robust and language neutral. RMI lacks the basic features of IIOP, and Java is not providing features that are found in most ORBs.

Some traditional, message-oriented middleware products like IBM's MQSeries support Java. However, the real story in this context is a new standard from JavaSoft called JMS (Java Message Service). JMS is attracting a critical mass of messaging vendors seeking to bind their products tightly with Java. Some of the larger vendors include BEA, IBM, SAGA Software, Active Software, and Oracle.

JMS adds a common API and provider framework that enables the Java developer to dispatch and receive messages with other Java-enabled applications or applets existing anywhere on the network (see Figure 12.1). JMS defines a common set of messaging concepts and programming strategies. JMS provides a good mix of the messaging features common to most messaging products—important but hardly revolutionary. The difficulty is to support these concepts and strategies from JMS-compliant vendor to JMS-compliant vendor. If successful, the resulting products will not only share common characteristics, but will have the ability to share messages as well—something that has yet to be perfected with more traditional, message-oriented middleware products.

JMS is comprised of three major entities: the JMS provider, JMS messages, and JMS domains. The provider implements JMS for a particular product (for example, a Java applet, servlet, bean, or application supporting JMS). The JMS messages are a set of messaging interfaces that define a common mechanism and format for moving information from providers. JMS messages consist of several parts, including the header, properties, and body (see Figure 12.2). The header supports the same set of header fields as are supported in traditional messaging products. Both the JMS client and provider use the header to identify and route messages. The JMS message properties allow developers to add additional information to the standard header, information such as application-specific properties, standard properties, and provider-specific properties. The body contains the data that is being transported.

Figure 12.1. JMS provides message transport services for Java.

Figure 12.2. JMS message structure

Messaging Models

JMS domains provide for the classification of messaging paradigms, including point-to-point and publish-and-subscribe. Point-to-point messaging generally relies upon queues to transport messages. Publish-and-subscribe, as you may remember from an earlier chapter, addresses messages to some node in a content hierarchy. As we've noted earlier, pub/sub is particularly useful to EAI projects because there it does not require an understanding about the resource that is being subscribed to. JMS provides client interfaces created for each type of domain.

The question remains for the architect and developer: Which model to use, and when? The JMS point-to-point defines how a client works with queues. For example, it defines how a JMS-enabled application finds queues, sends a message to them, and/or receives messages from them. The JMS client is able to send a message to a specific queue. The receiving applet or application need not be engaged in order for the message to be placed in the queue. The receiver picks up the message from the queue when it has time. In other words, this is an asynchronous messaging model. It is one best applied when applications need to communicate with one another but, in doing so, do not need to delay the target or source application from processing tasks.

As with traditional queues, JMS queues may contain a mixture of messages. A shortcoming of JMS is that it does not define facilities to administer queues. However, this is not as significant as it might first appear because JMS implementations leverage static, not dynamic, queues.

There are several Java concepts to keep in mind when working with JMS queues. Among them are: the Queue object, the TemporaryQueue, QueueConnection Factory, QueueConnection, QueueReceiver, QueueSender, and a QueueSession. Together, these represent a set of classes that a developer can leverage within a JMS-enabled application.

The Queue object, the heart of this beast, encapsulates a provider-specific queue name. This object identifies a queue to a JMS method from the client. A QueueConnection is an active connection to a JMS point-to-point provider. The JMS client leverages the QueueConnection to create instances of QueueSessions, which produce and consume messages.

The TemporaryQueue is created for the duration of the QueueConnection. True to its name, it is a system-defined queue, only available to the QueueConnection object that created it as a temporary storage location. The QueueConnectionFactory creates an instance of a QueueConnection object within a JMS provider. The client uses a QueueReceiver to receive messages that exist in a queue. A QueueSender, in contrast, places messages in a queue.

If the point-to-point model doesn't meet the needs of the project, the JMS pub/sub model might. The JMS pub/sub model describes how JMS clients publish messages and subscribe to them from a well-defined node by using a content-based hierarchy structure. This model, as we have noted in our earlier discussion of middleware models, is superior to simple, point-to-point models and is most practical when considering JMS for use with traditional EAI projects. (Although either model can be used with EAI implementations.)

JMS refers to these "nodes" as "topics." A topic is, in fact, a small message broker that gathers and distributes messages from other entities (see Figure 12.3). JMS uses topics as quasi-intermediaries. They create messages that are separated logically from subscribers. Topics are adaptive. They can adjust as subscribers and publishers appear and disappear.

By drilling down to the next "topic level," it becomes apparent that a topic is really nothing more than a Java object that encapsulates a provider-specific topic name. Most pub/sub vendors group topics into hierarchies, allowing subscribers to subscribe to any part of the hierarchy. JMS does not place such restrictions on its users. Instead, it organizes topics and the granularity of subscriptions in a completely open manner. There are no set policies for how developers should do this. This "openness" is a step in the right direction because strict pub/sub policies are, by definition, limiting.

Figure 12.3. JMS is able to gather and distribute messages throughout an enterprise.

Calling application servers "middleware" is a bit misleading. However, because that is the way they are generally classified, we do the same here. As we discussed in Chapter 7, an application server is any product that provides a host for application logic and that processes all (or part) of an application. For example, an interface logic can be defined by using client-side development tools, with all business logic processes server-side using a remote application server. The benefit to this scenario is that both application logic and access to resources can be shared through a centralized entity.

The new generation of Java-enabled application server vendors (WebLogic, iPlanet, and Inprise) provide a hosting environment for server-side Java. These environments do a number of things, including accessing remote resources such as database servers, mainframes, ERP applications, and even other Java applications (see Figure 12.4).

Application servers control access to these environments by using "units-of-work," or transactions. By using a transactional paradigm, they are able to recover from system- and resource-level problems and to scale to high user and processing loads. To accomplish this, they use tracks, such as multiplexing database requests. However, every product implements such features in unique ways and so should be explored carefully before being implemented.

These environments include integrated development environments (IDEs). IDEs assist the developer in creating the logic for the application server, using an easy-on-the-eyes graphical user interface. They may also provide client-side tools or client-side development features through a partner.

Figure 12.4. Typical Java-enabled application server architecture

How then do these application servers differ from Java-enabled TP monitors? From an architectural or features point of view the answer is, "not much." However, TP monitors generally do Java only as an afterthought at the interface level. Java-enabled application servers are built from the ground up to support transactional, server-side Java.

TP monitors, such as BEA's Tuxedo and IBM's CICS, are best known for providing transaction-processing capabilities. With several traditional TP players entering the market using Java as a programming mechanism, as well as a way to draw more attention to themselves, these well-known TP monitors have had to adjust. They say you can't teach an old dog new tricks. Well, these old dogs are definitely learning new tricks. Both Tuxedo and CICS are providing Java links to their TP monitor environments. This creates a situation in which it is possible to build applications using a Java client and invoke transactions housed within a TP monitor environment. These transactions may be built in any of the number of languages that the TP monitor supports.

The benefits of this capability should be clear. The two largest TP monitor vendors are moving in this direction, adding Java language capabilities within their environments. The result of this development will be that "traditional" programming languages such as C or COBOL will no longer have to be used to create transactions. It will be possible to simply use Java.

What we are seeing is a blurring of the once-clear line between TP monitors and the new application servers. These new products are moving aggressively to make sure that they don't lose their market share to the less-mature, Java-enabled application server. While these products have yet to provide the scalability and the fail-safe environments traditional TP monitors provide, they are generally much easier to build applications around.

Although there has been a great deal of talk about linking Java, CORBA, and other distributed object technologies, the number of software development projects using this type of technology are few and far between. In other words, the talk has been, thus far, mostly talk. However, as many application servers look to merge with distributed objects, the talk is growing more serious.

CORBA extends the distributed features of Java using CORBA infrastructure. Even with the integration of RMI, Java applets were not designed to communicate across application address spaces. RMI provides an easy-to-use approach to distributed computing but does not support the advanced architectural features of CORBA-compliant ORBs.

CORBA allows Java applets to communicate with other objects written in different languages across different address spaces by using the common pipe of IIOP (Internet Inter-ORB Protocol, see Figure 12.5). This allows developers to create truly distributed applications using any number of languages. CORBA provides a rich set of distributed object services that are built on top of the Java language. For example, the developer may create the client-side ORBs using Java, and the business logic at the middle-tier using C++.

Java lends little to the world of distributed computing save for a very nice, object-oriented programming language, and a very nice binary application distribution mechanism. Still, Java is a good match for CORBA. Java's infrastructure seems to "pick up" where CORBA's "leaves off." All the while, it allows CORBA to do what CORBA does, which is provide a distributed object infrastructure that allows applications to extend their reach across networks, component boundaries, operating systems, and programming languages.

The integration of Java and CORBA lets developers do such things as move intelligent behavior from one ORB to another using the common infrastructure and interfaces of CORBA. As a result, both clients and servers are able to dynamically gain behavior as required for the application development effort. CORBA also provides a language-independent partitioning technology, as well as the technology to allow applications to run on a client or server without having to recompile (albeit, adaptations must be made for each platform).

Figure 12.5. Using IIOP to allow Java applets, servlets, beans, and applications to communicate

A Java ORB is an ORB that supports a Java language mapping of the IDL. In most cases, Java ORBs are implemented in Java itself. The language mapping, or language binding, allows CORBA-compliant ORBs to be implemented using Java. Unfortunately, not all Java ORBs available today support the complete CORBA functionality.

In the simplest form of the Java-enabled CORBA ORB architecture, the client and the server are both implemented in Java. Using this architecture, the Java virtual machines on each platform allow each applet or application to execute. The applet or application shares a common ORB, which provides interprocess communication services. The client communicates with the ORB in order to transmit a request for an operation invocation to the server. The server, in turn, sends the results of the ORBs back to the client.

Iona and Inprise are the two dominant players in the Java/CORBA space. Inprise sells Visibroker for Java, with native implementation of the IIOP. Visibroker supports the OMG's IDL-to-C++ mapping and the OMG's IDL-to-Java mapping, maintaining full compliance with the latest from the OMG, the CORBA 3.0 standard. Inprise's strategy is to combine Visibroker with the suite of application development tools that they offer, including JBuilder. Iona offers OrbixWeb, a Java-enabled CORBA ORB that provides many of the same features as Visibroker, including the ability to create CORBA ORBs using Java. In spite of the fact that Inprise has more experience with Java and CORBA and seems to have a tighter integration with a solid set of tools, Iona seems to be cornering the CORBA ORB market.