Summary

Let's finish by reviewing some of the key issues we've covered in this chapter and the decisions we've taken for our sample application.

We've decided that there's no justification for making the application distributed. The requirements are purely for a web application, so we don't need to enable remote access via RMI. If this application ever needed to support remote access, it would be much more likely to involve XML-based web services. A collocated web application architecture can provide excellent web services support, so this would prove no problem to add. Enabling web tier components and EJBs to be run on separate servers wouldn't make the application more robust, as it depends on web tier state. However, it would make things a lot more complicated.

Since the booking process is transactional, we've decided to use EJB to implement it. As we don't want a distributed model, we'll be using EJBs with local interfaces, meaning that we don't need to worry about the performance overhead of remote calling, or the requirement for coarse-grained EJB interfaces.

Using local interfaces means that we don't need to put all business logic (or necessarily all data access) inside the EJB container. Due to the complexity of working with EJB, we won't be using EJB unless it delivers clear value; hence, we won't be using EJB for the non-transactional parts of the application. This enables us to avoid problems with EJB programming restrictions (for example, relating to singleton functionality).

Choosing not to implement business logic inside the EJB container doesn't mean that we tie business logic intimately to the web interface. Web interfaces change, and it's important to retain a distinct layer of business interfaces that we could expose as web services. These will be ordinary Java interfaces, implemented in either the web tier or by EJBs accessed locally.

None of the application's functionality is asynchronous, so we will use JMS in Phase 1 of this project only to publish reference data update events, enabling caches holding genre, show and performance data to requery the database only when a change is known to have occurred. The Observer design pattern would provide a simple solution were the application to run on only a single server. However, using JMS will ensure that the application will continue to behave correctly if it is ever deployed in a cluster of servers.

There is no reason to use XML in the application's internals (for example, to hold data from database queries and pass it around the application until it can be displayed by XSLT). However, XSLT may be a valid choice as a web tier view technology.

This is the second architecture (Web application accessing local EJBs) of the four we discussed in Chapter 1.



Expert One-on-One J2EE Design and Development
Microsoft Office PowerPoint 2007 On Demand
ISBN: B0085SG5O4
EAN: 2147483647
Year: 2005
Pages: 183

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net