A Look Inside J2EE Patterns(4) (轉)

A Look Inside J2EE Patterns(4) (轉)[@more@]

On the fourth day of Patterns, our journey continued through the Business tier and onwards into the tier. The first hour of class was spent completing the Service Locator (HomeFactory) lab. The labs were proving to be challenging and Owen was actively assisting students who were detened to get their code succesully compiled and deployed. Day 4 was an interesting class, with the morning spent discussing The Business Delegate Pattern and Marchitecture. In the afternoon, we moved on to J2EE Web Patterns and the .

:namespace prefix = o ns = "urn:schemas--com::office" />

The Business Delegate Pattern

The problem that the Business Delegate pattern solves is the tight coupling between the client and EJBs or destinations. This tight coupling reduces the separation of roles between client programmers and server s component programmers and ultimately results in client side code that must know how to access EJBs and include exception and error handling code.

The Business Delegate pattern solves this problem by creating a layer of delegation that communicates with EJBs and takes care of exception and error handling all on behalf of the client. The Business Delegate may also cache results from the server side that the client may need. For testing purposes, the delegation layer may simulate logic or generate dummy data. The Business Delegate also helps with reusability in that the EJB access and exception handling code that comprise it, are now reusable across multiple clients accessing the same EJBs.

The class was excited to jump right into the Business Delegate lab. In terms of patterns, we were now approaching the 'final frontier' of Business tier patterns that bordered on the Web tier. In fact, the whole purpose of this lab was to decouple the two tiers. In the Business Delegate lab, which still dealt with our web-based game application, we had to implement a GameSystem Delegate which would hide the details of EJB interactions. Because we would be wrap the business delgate, we were required to provide some additional functionality such as caching e addresses and providing some log in validation.

After the lab, Owen drew a UML diagram on the board and made us identify all the patterns that were being used in the system. It was a small test to see what all we had learned over the past three days. Pointing to various parts of the diagram, he ranly asked students to identify the pattern being used. "DAO" shouted one, "Session Facade" shouted another, "Command Pattern" exclaimed a third. All correct. We had made Owen proud. A more sensitive instructor would have shed a tear of joy. Before being able to use patterns, it made sense that we should know their vocabulary, and be able to immediately identify them.

"Hopefully, patterns will simplify your design and decouple the layers of your system, isolate changes between the layers and encapsulate variations," Owen reminded the class.

MVC

Looking out from our 11th floor window onto Broad Street, you could see the sunlight creeping in through the buildings and shimmering on the pristine sidewalk. Between the buildings, you could catch a glimpse of the deep blue East river, flowing calmly on a mild October morning. The view outside the window was pure artistry: a clean separation of city, river, and sky.

In order to achieve reusable and extensible software, it is essential to separate the View from the Logic that creates the View. When a new feature needs to be added to the GUI, it should be unnecessary to modify more than the View. The goal of the MVC pattern is to decouple the view (the presentation layer) from the model (the business layer) and have a controller that coordinates between the two.

MVC solves the problem of tightly coupled code in which changes to either the user interface or business logic impacts code from either the model, or the view, respectively. A pure code solution results in difficult to maintain classes that embed HTML within code; conversely, a pure solution embeds Java code inside HTML, which produces ugly, hard to understand and maintain web pages.

The solution is to isolate the view to JSP and HTML, isolate the controller to Servlet code, and isolate the model to all Java classes containing nothing web-centric. On one of the slides we looked at a ControllerServlet class and studied its service method in which the request object is examined and directed to an appropriate JSP page based on its session information and what type of page it's trying to access. In this example, the Servlet acted like a gatekeeper and controller to our application, preventing any unauthorized access to classified information.

Your Friendly Neighbourhood J2EE Pharmacy

During break, I spoke to Brian Hanuska who does consulting for a Pharmeceutical firm. I asked him how is company is making use of J2EE technologies and what motivated him to take the Patterns course.

"We currently have a search application that is using Convera's Retrievalware indexing tool to allow us to do cross repository searching. It utilizes JNI. We are about to expose the search tool as a Web service throughout the company. To do this we will have to create a connector so that the app is compliant with the J2EE spec (EJB's can not invoke JNI for security reasons). This system would be suited for refactoring through the use of patterns and antipatterns (it's implementation is itself an antipattern).

One of our applications is used to track clinical trials and it utilizes the Struts framework. It talks to Documentum, and a bunch of databases. It employs container managed persistence, container managed relationships, voice XML, SSB, SFB, and many others. It is a load balanced, clustered system (6 WLS servers in the cluster).

Another application is a protein analysis database. This system uses JMS to distribute the processing of work required for research that can lead to new drugs. This system saves a great deal of time for the researchers. It also has a Web front end for the users to submit the proteins, and to check on the results as they are processed, since the results take a long time to process.

I took this course to better learn how patterns can be applied in our company, so that we can continue to create reusable components. Also to explain what patterns were chosen and why a pattern was chosen over another similar pattern."

When we got back from the break, Owen was joking about how developers are generally lazy when it comes to trying to fix problems with their code. They'll try to recompile their code several times (without making any corrections), hoping that things will somehow just fix themselves. He told us a joke to illustrate the point.

"A manager, an engineer, and a developer are going down a hill in a jeep when it suddenly loses control and goes into a ditch. They each attempt to offer a solution to the problem. The manager says 'Let's have a meeting to discuss a solution'. The engineer says 'Let's disemble the jeep, and examine every part to find out where the problem is.' The developer says, 'Let's push it back up the hill and try again.'

J2EE Web Patterns and Struts

Within J2EE applications, MVC is not specific enough to provide tactical coding principles. Decisions still need to be made on where to place JNDI lookup code, data access code, security checks and View routing information. We looked at several Web tier patterns that address some of these issues such as the Front Controller, the View Helper, the Composite View, and the InterceptingFilter Pattern. These patterns are usually used in concert with one another.

The Front Controller acts as a centralized controller that routes all incoming requests; it decides what other objects to use when building the request. Some requests require the use of the model and can benefit from the use of a View Helper that encapsulates accessing that model.

Usually used with the Front Controller, the View Helper further separates the view from the model. It encapsulates model accessing logic within a separate class allowing the view to be completely shielded from the model implementation.

The Composite View is a conglomerate of several smaller views, usually involving use of the 'include' statement. Information regarding which files are included where and when can be divered through the use of properties files and a View Mapper component. The Composite View pattern allows for the reuse of view components such as headers, footers, animations and login dialogues.

Another interesting Web tier pattern we looked at was the InterceptingFilter Pattern, which is included in the J2EE Servlet (2.3). This pattern encourages the application of individual filters to a request so that it is easily routed and processed within its proper context. You can reuse and reorder your filters depending on the needs of your request object. Examples of InterceptingFilters are Security Filters, Validation Filters, and even I18nFilters if your Web application supports internationalization.

Towards the latter part of the afternoon, we looked at Struts, an framework that enables rapid Java Web application development utilizing a 'Pull MVC' architecture, a Front Controller, a View Helper, and the DTO. Struts is designed to be used in the Web layer of a J2EE application. Through the use of frameworks (such as Struts) and components that are largely generated from existing data sources, the developer is left with much less code to write, de, document, and maintain. Struts is well established and based upon existing standards and being an open source framework, it is maintained and improved upon by a savy and motivated community of programmers.

Our study of Struts included a look at the ActionServlet (the Controller), which, amongst other things, serves to bundle and route HTTP requests to specific Action classes and JSPs as mandated by the configuration file. The Model in Struts is embodied by Java Beans and ActionFoclasses. The importance was emphasized of ensuring that business logic within classes is decoupled from the Struts framework for greater reusability, so that it is possible to switch to an alternate view and framework in the future if the need arises.

The View in Struts is embodied by JSP pages and Servlets as well as non-Java web resources such as XML and HTML pages. A rich set of s is associated with the Struts framework and can aid in building complex views. Struts JSPs also provide formatting and error handling capabilities. We examined the struts-config.xml file that described the Action and ActionForm classes used in a sample application. We then looked at the ApplicationResources.properties file that contains instructional text messages for the user, error pages, and text for headings and titles. Owen walked us through the source code of various Action classes and JSP files to show us the dynamics of Struts, and how the three layers, namely, the Model, the View, and the Controller, communicate and interact with one another.

The Home Stretch

On the final day of J2EE Patterns, we attempt to teverything together and apply all that we learned in the past week. Some of the topics we cover on the last day of J2EE Patterns are the Webwork open source framework and Antipatterns. We also engage in a 'Pattern Hatching' exercise and later split up into groups to apply the patterns we learned in the final lab.