Once you have a list of requirements, analyze them and design a set of components and objects that fulfill the requirements. At this point, start thinking about application boundaries, but don’t lock yourself into saying “This is an EJB” or “This is a JMS message.” The main goal is to determine a clear set of client applications and the components that support them. For this book, the design of client applications with a user interface is left to the reader. Our focus is on the libraries that the client might use to communicate with the supporting components. The one exception is the use of Web pages as an interface to an application on the server. The book discusses these; you should use good Web page and Web site design techniques to augment the discussion. Keep in mind that some “client” applications may not have a user interface at all. They may be report generators or the like.

Take the components that your programs need, and determine what communication mechanism they should use to interact. Possible choices are HTTP, RMI, CORBA, sockets, and JMS. HTTP is normally used for applications that use a Web page front end, but it can also be useful in situations in which the components are separated by a firewall. With the availability of RMI and CORBA, sockets should be used only when required to support existing protocols or applications. RMI and CORBA both use the concept of distributed objects, discussed in Chapter 12, “Overview of Distributed Objects,” to enable interapplication communication. For applications being written in pure Java, RMI provides the most native distributed object choice. Applications that need to connect to programs written in other languages should probably choose CORBA. As mentioned in the preface, this book doesn’t cover CORBA, but the discussions on RMI are relevant. Finally, JMS allows programs to communicate via encapsulated messages. Messages can be sent between Java programs and even to non–Java programs, depending on the provider. More discussion on reasons you might choose JMS is provided in Chapter 19, “What Are Messaging and the Java Messaging Service?”

Given the components and the protocols between them, the next step in the development process is to determine what type of component to implement. JavaServer Pages and servlets can be used to drive a Web page user interface. Servlets can also provide generic services over HTTP or some other protocol. Enterprise JavaBeans are used to define components that live on a server of some type, such as an application server. Using EJBs, you can leverage services provided by the server, such as transaction management and resource optimization. RMI and JMS can be used with EJBs or servlets as well as in applets or applications. For example, you can create an application that provides services by receiving JMS messages and sending JMS messages for the reply.

The final step in this process is to write the client applications and components and, of course, test them. The goal for this book is to not only help you write the applications and components but to provide some ideas and tips for making the decisions we’ve discussed. In particular, the last three chapters in this book start with a review of the technologies and describe situations in which they should be used. Then two large examples are described in detailed, real–world applications.

Why Use Java for Enterprise Development?

Of course, you may still be asking the question, “Why should I use Java for my enterprise development?” It is certainly a valid question, and we would be hard pressed to argue that Java is perfect for every single programming situation. However, there are a number of great reasons to use Java for enterprise development and development in general. Let’s look at the specific advantages of the Java enterprise technologies.

First, despite some hiccups, Java is extremely portable. This doesn’t mean solely that the programs can move between computers; it means that components such as Enterprise JavaBeans can be moved between different application servers. Using EJB, you can develop an application on one server and deploy it on another one. This can save cost, because developers don’t all need a deployment environment available to them. Of course, you should always test on the deployment environment before actually deploying your enterprise applications. Sun has made “Write Once, Run Everywhere” a mantra and is constantly improving the availability of Java and the enterprise Java technologies. With companies such as IBM, BEA, Oracle, and Sybase on board as well as a host of innovative startups such as Cloudscape, it isn’t hard to see how Java will continue to grow and improve.

Second, the standards defined by the enterprise Java technologies reduce education cost. Once you learn the specifications described in this book, you can apply them on multiple servers. Compare this to the old way of doing things, when programmers specialized in a particular database or transaction monitor.

Technologies such as Enterprise JavaBeans and servlets split an application into components and centralize code. With RMI, JNDI, and JMS, it is easy to manage the relationship between components. In other words, you can leverage technologies such as application servers to help break your code into manageable components, both during development and once they are running.

These technologies leverage the advantages of Java. For example, servlets allow you to plug custom code into a Web server, as a plug–in or extension library would. However, servlets have garbage–collection and exception–handling abilities, so a problem in a servlet should not affect the server as a whole. The same is true for Enterprise JavaBeans that may be deployed on a database or application server. In both cases, Java is creating a safety zone around each enterprise application to protect it from naughty neighbors.

And the list goes on. We could spend several pages talking about why you should use these technologies. This list is a great start, though, and once you see what the technologies are and how they work, you will be able to fill in the list for yourself. So let’s get started.

Summary

As you work through the concepts and examples in this book, keep in mind the goals you have for your Java applications. Consider where each technology can be used, and think about which one is the right technology to use. Hopefully, as you reach the two final large examples at the end of the book, you will begin to think of new ways to combine the enterprise Java technologies. Ultimately, your success creating enterprise applications is limited only by your ability to choose the right technology for the job and apply it appropriately.

The next two chapters introduce JDBC. This introduction is provided for programmers who have no JDBC experience and is not intended as a complete discussion of the Java database access libraries. If you are already familiar with JDBC, you may want to skip ahead to Chapter 4, “What Is JNDI?”