|
|
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 app. We've decided that there's no justification for making the app distributed. The requirements are purely for a web app, so we don't need to enable remote access via RMI. If this app ever needed to support remote access, it would be much more likely to involve XML-based web services. A collocated web app 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 app more robust, as it depends on web tier state. However, it would make things a lot more complicated. Since the tutorialing 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 app. This enables us to avoid problems with EJB coding 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 app'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 app to run on only a single server. However, using JMS will ensure that the app will continue to behave correctly if it is ever deployed in a cluster of servers. There is no reason to use XML in the app's internals (for example, to hold data from database queries and pass it around the app 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 app accessing local EJBs) of the four we discussed in .
|
|