Chapter 19. Building a Presentation Tier for EJB

The Different Types of Presentation Tiers

At first, you might think it's a little strange to have a chapter on presentation topics in an EJB 2.0 book. But let's face it, almost any EJB application must have some sort of external interaction with the system. This interaction might be in the form of a graphical user interface (GUI) hosted on a wireless device, an applet in a Web browser, or other EJBs in a different container. In any case, typically there is some type of remote client interface that you will need to design and build for your EJB applications.

Arguably, the most common interface being built today is one hosted by a Web server. Usually, the presentation is displayed in a browser and the output is normally HTML, although it's becoming very common to see the Wireless Markup Language (WML) being used to display output on a mobile device. For now anyway, it's probably safe to say that many EJB applications being built right now use some type of browser to display output.

Regardless of which type of presentation technology you are using in the presentation layer, there are some common design issues that you should keep in mind when designing a presentation tier that accesses an EJB application. The main issue is that EJB is a distributed component-based architecture. Instead of making a normal method call within a single address space, most calls are remote procedure calls (RPC).

For a refresher on how EJB uses RPC to communicate between the client and the server, see Chapter 3, "EJB Concepts."

Some additional complexities that must be dealt with when building a presentation architecture in a distributed environment just don't exist for a typical single JVM application. The main thing to guard against is exposing too much knowledge of the underlying architecture to the presentation tier.

The presentation tier is supposed to be thin, and the business logic that you might expect to find in a two-tier Web application normally is moved back to the application server, leaving just a very small layer of presentation logic in the Web tier. The more that your presentation architecture can hide the EJB technology, the easier time your presentation programmers will have building and maintaining the presentation layer. By hiding the complexity of EJB and the supporting technologies, you can allow the presentation developers to concentrate on the job they are best at doing.

Using the Remote Proxy Pattern

One of the easiest ways to hide the complexities for the presentation tier is to not let the presentation tier know that it's communicating with EJB. This might sound funny at first, but it's a very common design pattern. One of the ways to hide this fact is by using what is known as the Remote Proxy pattern.

In the Remote Proxy pattern, a client uses a proxy object to hide a service object that is located on a different machine from the client objects that want to use it. In the case of a presentation layer, which needs to make a method call onto an enterprise bean, the presentation would instead make the call onto the remote proxy object, and the proxy object would call the enterprise bean on the client's behalf .

So, instead of every presentation tier component having knowledge of enterprise beans and dealing with such things as the home and remote interfaces, the presentation tier components make a normal method call on the remote proxy, and the remote nature of the call is transparent or hidden from the components. The object that implements the remote proxy pattern lives in the presentation tier with the rest of the presentation tier components . Figure 19.1 shows a remote proxy being used to call a session bean method for a client.

Figure 19.1. A remote proxy being used by the EJB presentation tier.

The remote proxy can just be a normal Java class that contains the methods that the presentation tier would normally call on the application tier. Generally, each Web tier user would have a separate remote proxy object, because there might be security information that needed to be passed on during the remote call for each user. The remote proxy object could have instance variables that hold the home and remote interfaces for the enterprise beans in the application tier. As you saw in Chapter 16, "Patterns and Strategies in EJB Design," only session beans should actually be exposed to the clients , so the remote proxy objects typically only deal with session bean home and remote interfaces.

The method signatures in the remote proxy should match those signatures declared in the remote interfaces of the session beans. In this way, a tool can be used to generate the proxies for the presentation tier automatically. If any of the session bean remote interfaces need to change, you can just regenerate the proxies.