Link from http://blog.csdn.net/hongkong2007/archive/2007/08/23/1755894.aspx
1. PATTERNS AMONG THE THREE FRAMEWORKS
This portion discusses the patterns used in the JAVA EE and Spring. JAVA EE 5, the updated version of J2EE, introduced many patterns from lightweight frameworks.
1.1 Object Orientation
JAVA EE 5 the updated version of J2EE, introduced the new Java Persistence API. In this API, entities are POJOs(Plain Old Java Objects), they support for inheritance and polymorphism. They are object-oriented.
Spring framework are designed with POJOs, it is object-oriented.
There is a real value in practicing OO. Applied effectively, OO can deliver very high code reuse and elegant design.
1.2 Dependency Injection
JAVA EE 5 makes it easier to access to resources through Dependency Injection. In the Java EE 5 platform, dependency injection can be applied to all resources that a component needs, effectively hiding the creation and lookup of resources from application code. Dependency injection can be applied throughout Java EE 5 technology -- in EJB software containers, web containers, and clients.
Spring can eliminate the need to use a variety of custom properties file formats, by handling configuration in a consistent way throughout applications and projects. Dependency Injection realizes this.
1.3 Combination with Other Frameworks
All the three frameworks, J2EE, JAVA EE and Spring, can be used with other frameworks such as Struts, Tapestry etc.
1.4 MVC Pattern
J2EE, JAVA EE support MVC pattern and can be used with other MVC frameworks, such as Struts.
Spring also provides a powerful and flexible MVC web framework that is integrated into the overall IoC container. In the Spring MVC framework, an application context is defined for each web application containing common objects. Spring provides the ability to instantiate such a context through a listener or servlet without dependence on the Spring MVC framework, so it can also be used in Struts, WebWork or other web frameworks.
1.5 Distributed Object
J2EE and JAVA EE support object distribution, database distribution, and multiple client types.
Spring its own architecture does not support object distribution, but it has excellent support for architectural refactoring. For example, it’s possible to add EJBs with local interfaces or AOP to business objects without modifying a line of calling code.
2. COMMON PURPOSES OF EVOLUTION OF THE THREE FRAMEWORKS
This portion discusses the common purposed of design of evolution of the three frameworks; it is helpful for us to get a generic model from them.
J2EE is designed to meet the requirements of distributed enterprise applications, its infrastructure comprise a lot of functionality. It concerns quantity attributes, such as performance, scalability, security, asynchronous communication, distributed transaction etc. These features do not represent in this paper because they are too verbose to write.
Spring is designed for purpose of simplicity contrast with J2EE, it is easy to refactory, to test, and to deploy. It wants to realize most of the quantity attributes through frameworks combined with it.
JAVA community saw the strength of Spring, they try to simplify J2EE. But it is heavy weight from the origin. It is hard to do this for them. In some aspects you can see the improvement of it at least. As for weather it is excellent it is too early to say.
2.1. Productivity
J2EE are designed to make developers concern business logic to promote the productivity, but its complexity of deployment and the poor testability make it failed in this aspect.
JAVA EE 5, its updated version, simplifies the deployment of applications through annotations.
Spring has better productivity as a lightweight framework partly because it is comparatively simple.
2.2. Simplicity
J2EE are known as its complexity. So in its updated version, JAVA EE 5, simplify a lot, such as using annotation, Dependency Injection. Though JAVA EE 5 is still complexity compare with lightweight frameworks, it has been improved toward this object.
Architecture of Spring is designed much more simple than J2EE. This characteristic is also its most strength.
2.3. Primacy of Requirements
J2EE has a lot of features driven by technology not the business requirements, JAVA EE 5 has improved some of them, i.e., EJB 3.0 is a specification is now built around the proven needs of the development community, standardizing existing best practices instead of being the result of design by committee.
Spring is a simple framework, which is design to avoid the complexity to satisfy most developers.
2.4. Testability
In the J2EE, EJB is the most frustrated design because its test depends on the container. Business logic coded in EJB is very hard to test.
In the JAVA EE 5, this situation has been improved. EJB 3.0 can be tested out of the container easily.
Spring is always has good testability because it is designed with JOPOs, it does not depend on any container.
3. GENERIC FRAMEWORK MODEL
It can meet the requirements of simplicity, distributed enterprise applications; asynchronous communication can be realized easily. Other features can be met, such as performance, scalability, distributed transaction-processing, security, Object Relational Mapping (ORM) etc.
Figure 1 shows the layers structures of the generic framework.
Figure 1 Layers Structures of the Generic Framework
3.1 UI layer
It is all the UI parts of an application, such as HTML, JavaScript, JSP, SWING, Servlets, or Ajax. JSP Tag Libraries is also considered to be part of this layer. In general, this layer is responsible for receiving the user requests, managing clients-side state, performing dynamic validation on client input, delegating to the business logic layer, and responding to user requests after process results returned. Figure 2 shows the possible components of this layer.
Figure 2 UI layer components
MVC pattern
MVC pattern is popular in this layer. In the generic model, it is a good choice. There are many benefits using MVC in a design:
· Model and View components can vary independently enhancing maintainability, extensibility, and testability.
· Separating Controller from View permits run-time selection of appropriate Views based on workflow, user preferences, or Model state.
· Make it convenient for teamwork to allocate tasks; experts of different domain can woke together.
· Separating Controller from Model (application behavior from data representation) allows configurable mapping of user actions on the Controller to application functions on the Model.
Separating Model from View (that is, separating data representation from presentation) makes it easy to add multiple data presentations for the same data, and facilitates adding new types of data presentation as technology develops.
Ajax
Ajax is a new web technology; it is used to build Web 2.0 applications. It can transfer user requests asynchronous, enhance user experience through eliminating web pages refresh and making web pages friendly.
3.2 Business logic layer
The main function of this layer is business logic processing. It receives the request of the UI layer, interactive with database persistence layer, and then transfers the response to UI layer. The components of this layer can be JOPOs and EJBs. Here we recommend JOPOs, for it support OO, if there are distributed objects requirements, you can choose EJB 3.0 components, EJB support OO from EJB 3.0 version. MDB(Message-Driven Beans) of EJB is recommended to process asynchronous communication. Components of this layer are shown in Figure 3.
Figure 3 Components of Business Logic Layer
3.3 DB Persistence Layer
Database persistence layer is usually realized by POJOs. There are many structures realize O/R mapping, such as EJB, JDO, Hibernate. Components are shown as figure 4.
Figure 4 Components of DB Persistence Layer
Hibernate offers a caching object, this mechanism is a good choice. it can make perfect performance. SQL, JDBC all can be your choice too. If you need database distributed, Entity Beans of EJB 3.0 just meet it. It is also POJOs, and support distributed applications.
3.4 Database layer
This layer usually is relational databases offered by database vendors. It can be OO database certainly, but such products are rare and immature, that means more risk.
3.5 Patterns
· OO
It is a well-known software development method for us. In this generic framework model it is recommended.
· Multi-layer Architecture
This generic framework is a multi-layer architecture.
· Dependency Injection
Dependency Injection is used across the framework to make source access easier.
· MVC
MVC is used in UI layer in this generic framework model.
· AOP
AOP is an alternative pattern in this framework.
· Distributed Objects
It is an alternative pattern in this framework.
3.6 Deployment of the generic framework model
The framework can use one web server, alternative Application servers rely on if it use distributed middleware. If EJB is used then it is necessary, you can use one or more Application servers to balance the load for better performance.
Figure 5 Deployment of the Generic Framework Model
4. Progress of Project Prototype
The system of prototype of our team is a framework based on java platform. The driver system is a Web-based Flight Reservation System. The framework is logical, the instantiation of it are some packages of API.
We have finished most of the design of the driver system involving functional design and architectural design. This is described in the 4.1. Next two weeks we will finish the implementation of the system based on our generic model.
4.1 Driver Design
Driver system is a Web-based Flight Reservation System. A passenger signs on the flight reservation system. He searches for flights; if he finds the one he wants to reserve he will make reservation. If seat select available on the flight he can select one. Then he should pay for the flight to bank, the reservation will be finished successfully.
4.1.1 System analysis
Figure 6 shows the Use case diagram of a Flight Reservation System
Figure 6 Use case diagram of A Flight Reservation System
Description of use case Search for flights is following.
Case name: Search for flights
Case conditions:
Invariants: none
Pre-conditions: for reservation system, status is active
For passenger, system access status is signed on
Basic course conditions:
Invariants:
For reservation system state is active
For passenger, system access status is signed on
Pre-conditions:
For flight, some flights are available
Post-conditions:
For passenger, available flight is found
Alternative courses:
Exception handlers:
No flights are available
Description of use case Make reservation is following.
Case name: Make reservation
Case conditions:
Invariants: none
Pre-conditions: for reservation system, status is active
For passenger, system access status is signed on
Basic course conditions:
Invariants:
For reservation system state is active
For passenger, system access status is signed on
Pre-conditions:
For flight, some flights are available and some seats are assignable
Post-conditions:
For reservation, selected fight and seat are assigned
For flight, seating alternative was selected
Alternative courses:
Exception handlers:
No flights are available or no seats assignable
Sequence diagram of Make reservation use case:
Figure 7 Sequence diagram of Make reservation use case
Figure 8 shows part of the class diagram of the Fight Reservation System.
Figure 8 Class Diagram of the Fight Reservation System
4.1.2 Architecture of driver system
The architecture of the system is designed based on the generic framework model. According to the requirements of the system design a reasonable architecture.
Architecture of the driver system is shown in Figure 9.
Figure 9 Structures of the driver system
According to the generic framework model and the system requirements, the system is designed using POJOs mostly. In the UI layer, Ajax is used to improve user experience. As for the specific non-functional requirements of the system, MDBs(Message-Driven Beans) are used. In the DB Persistence layer, adopt cache technology to improve performance.
In the Make reservation use case, let’s think of a synchronous realization. A client performs multiple synchronous calls to the server to execute the use case. Each step of the process requires a separate network call and block on the part of the clients. The bottleneck is obviously unacceptable. Furthermore, executing the logic in this fashion reduces the maintainability and reusability of the system and does not provide transaction consistency or isolation for the use case.
If realize such a function through a component, such as Session Bean, there will be several drawbacks:
Unacceptable Response Time. A user interacting with a Web site will not stick around for longer than a couple of seconds. The execution of this use case requires a lot of background processing that could span multiple databases on different airline systems. Because the call to the Business logic layer is a “synchronous” call, the client would have to block until the entire process has been completed.
Unreliable/not fault tolerant. This use case could potentially involve different resources from separate databases or servers. If any one of those servers were down, the entire process would fail, and the user’s reservation request would be lost. Even if the UI layer were communicating with only one application server, the process would fail if the server were down.
Using Session bean does not completely solve the problems of response time and reliability. The client still has to block while a complex and time-consuming reservation use case runs. The use case will also fail if the application server or any or the systems it relies on is not running at the time the use case is executed.
The takeaway point from our discussion is that we need a fault-tolerant server-side abstraction that serves as an intermediary, executing use cases in one call and one transaction, while doesn’t require a client to block and wait for the use case to complete. Message-driven beans are designed just for this.
Therefore:
Use message-driven beans to create a fault-tolerant, asynchronous façade. Clients should have access to message-driven beans only, not to DB Persistence layer.
Using MDBs, it will linearly to through the process of executing the use case: register the user with the airline, check if seats are available, and reserve a seat. While this time-consuming process is occurring, the end user is free to surf around the site or go about his business.
An important advantage of MDBs is asynchronously executed use cases can be guaranteed. That is, if the transaction failed at any point, the transaction will be rolled back and the JMS message will be put back in the queue. The transaction will then be retried later, without the knowledge of client. If the use case succeeds/fails then the system will notify the users by email.
Conclusions
This paper abstracts common patterns and common purposes of design of the three framework based on java platform. Get a generic framework of java platform. And describes the progress of prototype of our team. This generic model is a summary of many analysts’ notions. It is significant to architects.
References
[1] The ServerSide URL: http://www.theserverside.com
[2] Floyd Marinescu, EJB Design Patterns, 2002.
[3] Rod Johnson with Juergen Hoeller, Expert One-on-One J2EE Development without EJB, 2004.