The next issue we must consider is the process for updating the menu. Unlike the ComponentLocator class, the ApplicationMenu must refresh itself each time the menu is updated. The solution to this problem is the use of the Service Activator pattern discussed in appendix A. In this pattern, a client subscribes to a JMS queue to receive asynchronous messages. The client listens for a message and performs some logic when a message is received. In our case, we configure a JMS queue and add the ApplicationMenu as a subscriber. Any
time the menu.xml file is updated, we send a message that causes the Applica-tionMenu to refresh itself. Figure 6.6 depicts the administrative interface to the ApplicationMenu.
Figure 6.6 Administrative interface to ApplicationMenu
The final two components in our architecture are the presentation components. In chapter 5, we introduced the combination of a filter, a servlet, and a bean as an implementation of the Model-View-Controller pattern. In this paradigm, the servlet acts as the controller receiving requests and choosing the appropriate combination of data (model) and presentation (view) to render to the caller. The bean acts as the model and is only concerned with data. The filter acts as the view and renders the data in the appropriate format. The flexibility of this paradigm allows us to implement a J2EE architecture that can easily handle multiple presentation formats with minimal impact to the underlying data.
In our case study design, the BugAccessorBean and the ApplicationMenu act as the model. The DiagnosticApp is our controller servlet and the XSLT-Filter is our view. Our current requirements indicate that we must produce only WML, but this presentation framework is flexible enough to accommodate additional presentation formats if necessary. Figure 6.7 is the complete class diagram for our application.