Analysis of the current popular Java EE Web application architecture

1. Architecture Overview

The EE system includes Java Server Pages (JSP), Java SERVLET, Enterprise Bean,web Service and other technologies. The advent of these technologies provides a very competitive option for the development of Web applications in the e-commerce era. How to combine these technologies to form a stable architecture that adapts to the needs of the project is a very important step in the project development process. Completing this step can form a major milestone baseline. There are many benefits to forming this baseline:

Preliminary determination of various factors

To form an architectural baseline, the architect wants to sift through the technologies in the platform (System) and weigh the pros and cons. Often the architect should read a large amount of technical material in the process, listen to the project team members, consider the needs of the field experts, consider the cost of sponsors (including development costs and operating maintenance costs) limit. Once the architectural design has been reviewed, these factors initially have the role of the project in the overall process of positioning.

Orientation Technology Training

Once the architect-designed architecture has been approved to form a baseline, the technology used to develop and run the project is largely determined. Many project managers are concerned about the technical skills of the team members, who need training to provide training, but the project manager simply does not have a clear technical training requirement for the technology ocean the architect faces. How can we not train all the technology in the system? With the architectural milestones baseline, the project manager can determine what technology will be used in the development of the project, which is the most accurate to suggest that training needs should be. However, in actual project development, technical training can be performed concurrently with the architecture design before the baseline is determined.

Division of roles

With a good architectural blueprint, we can accurately divide the work. such as web design, JSP tag processing class design, SERVLET design, session bean design, there are various implementations. These tasks can be clearly identified in the architectural blueprint, enabling project team members to position their tasks well. A good architectural blueprint can also standardize tasks, which can be well divided into categories, with the same or similar workload and nature of tasks in the same class. This is a very good basis for estimating the workload.

Operation and Maintenance

Previously said that each task in the frame composition has a better positioning. Anyone can use it to quickly familiarize themselves with the entire project and to locate the error point more quickly when errors occur. In addition, with a clear architecture diagram, the project version management also has a good version of the tree trunk.

Scalability

Architecture is like a towering tree trunk, as long as the trunk root, trunk thick, long some offshoot, add some leaves easy undoubtedly. Similarly, there is a stable and proven architecture that adds one or two business components that are very fast and easy.

Everyone knows these benefits and is bent on forming a Java EE application architecture (like MFC in the Windows platform). There are two major stages in this journey:

1.1. Model 1

Model 1 is not really a stable architecture, not even a structure. The base of Model 1 is the JSP file. It extracts parameters from the HTTP request, invokes the appropriate business logic, processes the HTTP session, and finally generates an HTTP document. A series of such JSP files form a complete model 1 application, of course there may be other auxiliary classes or files. This is the case with early ASP and PHP technology.

In general, the benefits of this model are simple, but it mixes business logic with performance, which is not tolerable for large applications.

1.2. Model 2

After some practice and extensive experience and lessons learned, the Java EE application finally ushered in the MVC (model-View-control) model. MVC pattern is not the Java EE Industry People unconventional, so I talked about GF. The core of MVC is the loose coupling of three layers or even multiple layers. This is a boon and a lifesaver for component-based, technology-expanding Java EE systems.

It inserts a control component between the browser (this document is called a browser by the client Agent) and the JSP or servlet. This control component centralizes the distribution logic that handles HTTP requests sent by the browser, meaning that it distributes the request to the appropriate web-tier JSP or servlet based on the URL of the HTTP request, the input parameters, and the internal state of the current application. It is also responsible for selecting the next view (in the Java EE, Jsp,servlet will generate the HTML back to the browser to form a view). Centralized control components also facilitate security validation, logging, and sometimes encapsulating request data to the following Web tier layer. This set of logical implementations forms an application framework like MFC, where

1.3. Multi-layer applications

It is a typical multi-layer application model in the Java EE system.

Client tier Customer Tiers

Typically a browser or other application. The client layer generally supports the HTTP protocol, also known as the Client Agent.

Web tier Web application tier

In Java EE, this layer is run by the Web container, which includes Web Parts such as JSPs, Servlets, and so on.

EJB Tier Enterprise Component layer

The enterprise component layer is run by the EJB container and supports services and technologies such as EJB, JMS, JTA, and so on.

EIS Tier Enterprise Information System layer

Enterprise Information System includes the traditional information system such as finance, CRM, etc., which is characterized by database system support.

The application framework is currently focused on the Web layer and is designed to standardize the development of this layer of software. In fact, the enterprise component layer can also implement this model, but currently mainly in the form of design patterns exist. And some frameworks can be expanded, with the participation of enterprise component layer components, the framework will appear more compact, more natural, more efficient.

2. Candidate programmes

Currently, the framework for implementing Model 2 is also emerging, and the more well-known frameworks are listed below.

2.1. Apache Struts

Struts is a free open source Web layer application framework, Apache software fund dedicated to struts development. Struts are highly configurable, and have a growing list of features. A front-end control component, a series of action classes, action maps, utility classes that handle XML, server-side Java Bean autofill, Web Forms that support validation, internationalization support, HTML generation, implementation of performance logic and templates make up the soul of struts.

2.1.1. Struts and MVC

The purpose of Model 2 is the same as that of MVC, so Model 2 can basically be equated with MVC. Embodies the operation mechanism of struts:

2.1.1.1. Control

, its main component is a general-purpose control component. This control component provides an entry point for handling all HTTP requests sent to struts. It intercepts and distributes these requests to the corresponding action classes (which are subclasses of the action Class). In addition, the control component is responsible for populating the from Bean with the corresponding request parameters and passing it to the action class. The action class implements the core business logic, which can be accessed by accessing a Java bean or invoking an EJB. The last action class passes control to the subsequent JSP file, which generates the view. All of these control logic is configured using a file called Struts-config.xml.

2.1.1.2. Model

The model exists in the form of one or several Java beans. These beans are divided into three types:

form beans (Form beans)

It holds the data from the HTTP POST request, and in struts all form beans are subclasses of the Actionfrom class.

Business logic Beans

Designed to handle business logic.

System State Beans

It holds session information for a single customer that spans multiple HTTP requests, as well as the system state.

2.1.1.3. View

The control component continues to transmit HTTP requests to the JSP file that implements the view. The JSP can access the beans and generate the resulting document feedback to the customer. Struts provides a JSP tag library: Html,bean,logic,template and so on to achieve this goal, and is conducive to separate performance logic and program logic.

2.1.2. Struts Detail Analysis

2.1.2.1. View-Control-model

The user issues a *.do HTTP request, the control component receives the request, finds the action map for the request, checks whether the corresponding Action object (action instance) was created, and if not, calls Actionmapping to generate an action object. The control component saves the action object for later use. The Actionmapping method is then called to get the Actionform object. The actionform is then passed as a parameter to the perform method of the Action object, which is returned to the control component as a Actionforward object after the method is finished. The control component then obtains the path and redirection properties of the next view from this object. If redirection calls Httpservletreponse's method to display the next view, or RequestDispatcher is called sequentially, the ServletContext method continues the HTTP request to the next view.

When an action object runs the Perform method, an error message may appear. The action object can save these error messages to an Error object, and then call its own Saveerrors method to save the error to the properties of the request object. The action object then calls the GetInput method of the Actionmapping object to get the input parameter from the action map, that is, to generate a view of the inputs, and to generate a Actionforward object with the input parameter returned. The input parameter of the JSP typically has a http:errors custom tag that reads these error messages and displays them on the page.

2.1.2.2. Model-to-view

Model-to-view refers to the process by which a view loads system data into a view before it is displayed. System data is generally the information of Java beans within the model. It shows the processing logic of the JSP with Html:form custom tags, which is forward by the control component.

Html:form custom Label processing objects are obtained from the application scope (by querying the properties of the ServletContext object) to obtain objects previously placed by the control component Actionservlet the action map, by Html:form The Action property searches for Actionform name, type, and range information, finds actionform in the appropriate range, and populates the HTML form form with its information (the actual fill action is in the processing object for custom tags such as nested html:text). Otherwise, a Actionform object is created within the appropriate scope.

2.1.3. Pros and cons

Advantages:

Some developers have started to adopt and promote this framework

As an open source project, there are many advanced implementation ideas

Good support for large-scale applications

There is a centralized page navigation definition

Disadvantages:

Not the industry standard

Lack of support for development tools

Complex Taglib, which takes a long time to master

HTML form and Actionform are more closed, but this is the essence of it.

Modifications suggest that the Actionform property's settings and accessors be modified to read or generate XML documents, and then the HTML form and the Actionform are exchanged with XML documents to make them loosely coupled, adapting to the easily changing data structure of the application.

2.2. JATO

The Jato application framework is the old name of the iplanet application framework. It is a mature and powerful application framework for developing Web applications based on the Java EE standard. Combines concepts such as display fields, application events, component hierarchies, and page-centric development methodologies, as well as MVC and service-to-worker service-to-workers design patterns. The Jato is suitable for medium, large and ultra-large scale Web applications. But it is not an enterprise Layer application framework, that is, it does not directly provide the method of creating enterprise layer components such as EJB, WEB services, but it can construct the customer application to access the enterprise layer components.

This framework features three main components:

iplanet application Framework Core;

iplanet application framework components;

iplanet application Framework extension.

The application framework core defines the basic interface, the object protocol, the simple component, and the minimum core of the Iplanet application framework program. Includes view simple components, model simple components, request distribution components, and reusable command objects. The Iplanet Application framework component provides developers with a high-level reuse component that leverages the basic interfaces, protocols, and components defined by the framework core, which have horizontal components that are not related to a particular visual effect, while also having a vertical component that is intentionally provided to accommodate a specific practical environment and improve usability. Framework extension implements a framework-compatible approach to accessing non-EE environments. Typically, extensions are used by framework applications to seamlessly access the Java EE container-specific features. The Jato platform stack diagram clearly expresses the situation.

Jato's greatest power: for fast-developing users, you can increase productivity with framework components and extensions, and for users who require greater flexibility, you can implement the interface provided by the framework core to maintain the framework compatibility of your application.

This diagram represents the implementation of a JATO application that can be implemented simply by controlling the component Module1servlet, the View component Listcustomersviewbean and the model component Customersmoduleimpl, and a listcustomers.jsp file for the Client Agent display interface. And clearly indicate the inheritance relationship between these components and the JATO framework components.

The Jato Tag library provides an interface between a View object and a JSP file. The tag handler in the library is responsible for synchronizing and exchanging information between the View object and the JSP-generated client document. This diagram clearly expresses this correspondence.

The front-end control component receives any request from the user, which can be specified in Web. XML with the request distribution component responsible for view management and navigation, and the front-end control component encapsulated in Applicationservletbase. Application developers need to implement one such inheritance for each subsystem (human resources, finance, CRM, etc.).

The request distribution component distributes the request to the worker, and the worker implements the command interface. This interface can be implemented by the application developer. Jato provides a default implementation: Defaultrequesthandingcommand, which passes the request to a specific event of the view component.

A combined view is a hierarchical relationship when the view component is displayed to the user: The root view is an object of the Viewbean class, and the container view is an object of the class Displayfield. Containerview class. The hierarchical relationships of the view component classes are as follows:

2.2.2. Analysis of advantages and disadvantages

Advantages:

This framework is adaptable to a wide range of interfaces that provide the underlying interface, as well as immediately available components

Development concepts similar to client RAD development tools such as page-centric (equivalent to VB form), event handling, and so on.

Good support for large-scale applications

Disadvantages:

Not the industry standard

There is currently no support for development tools (however Jato has been prepared for tool support)

No page navigation defined, the developer specifies a specific navigation URL in the view

Modify Suggestions

Change the number of View/model corresponding to XML document transfer data, plus centralized page navigation definition

2.3. JSF (JavaServer Faces)

JSF is a framework for developing a Web application user interface that is being defined by a team of experts, including sun, and JSF technologies include:

A set of APIs that implement UI components, manage the state of components, handle events, enter checksums, define page navigation, support internationalization and access;

A JSP custom tag library implements the interface with the JSP.

JSF is very simple and is a well-defined programming model. Using this technology, developers can program the event handlers on the server side by combining the reusable UI components in the page, connecting the data sources of these components and applications, and routing the events generated by the customer. JSP handles all the complex work behind the scenes, allowing developers to focus on application code.

2.3.1. STRUTS, Jato, and JSF comparisons

There is some overlap between them, but the focus is different.

Both struts and Jato provide an MVC-style application model, and JSF only provides programming interfaces on the user interface. This means that the former two cover a wider range than the latter. JSF can be a part of the first two in UI development.

The release version of the JSF specification will be released by the end of 2002, and the implementation may be later than this time. There will also be tools to support the application development of this framework.

2.4. WAF

WAF is the abbreviation for Web application framwork and is the application framework proposed in the Sun Blue Book Example program. It implements MVC and other good design patterns.

2.4.1. Detail Analysis

2.4.2. View-Control-model

, two XML configuration files written by the developer define the operational parameters of the WAF. Screendefinition.xml defines a series of screens (screen). Mapping.xml defines the screen that should be displayed after an action, but does not specify where the screen is to take the data.

The user issues an HTTP request (*.screen), which is received by the Templateservlet screen front-end control component, which extracts the request information, sets the requested object Currentscreen property, and then sends the request to the template JSP. When the template JSP receives the request, the template tag in the JSP looks at the current screen and gets the specific parameters of the screen from the screen definition file (screendefinition.xml), and then generates the HTML back to the customer.

Let's say that the HTML form that is returned to the customer includes HTML forms that the user submits after entering a certain amount of data, making an HTTP request (*.do). This request is received by Mainservlet, which extracts the request information, looks at the action map file (Mapping.xml), sets the Action object (Httpaction object) to handle the request, and gives it to the Requestprosessor object for processing. The Requestprosessor object invokes the action object to complete the task, and if further processing is required, the Requestprosessor object invokes the event-handling mechanism of the Webclientcontroler object. After processing the request, the Mainservlet gets the next screen from the screen Flow management object and passes the request to the JSP file on the screen.

It is worth mentioning that the Webclientcontroler event processing mechanism eventually uploads the HTTP request data to the Ejbaction object for processing. In this way, the Httpaction object and the Ejbaction object form a two-level processing mechanism, which is closely related to the request object and encapsulates the data to form an event object, which is then passed to the Ejbaction object, which is independent of the request object. This approach can form a session-level data processing mechanism. Shows this method. The HTTPAction1 object processes a request and puts the data into a state Sessionbean, HTTPAction2, and when HTTPAction3 receives the HTTP request, it passes the control to Ejbaction, The latter acquires state sessionbean data, processes the request, and succeeds in clearing the state Sessionbean the contents. This mechanism is very suitable for multiple input pages to satisfy the input data of a business (such as a shopping cart).

2.4.3. Analysis of advantages and disadvantages

Advantages

Screen navigation defined explicitly

Provides a space for the framework's expansion

Disadvantages

Source of confusion, stability and reliability of no one to verify.

Just a frame torso, no formal model layer, the concept of view is not strong

No model-to-view definition

Revise comments

There is only one frame torso that provides the flexibility to implement your own application framework. There is no rigid view concept that provides an extensible interface for Web page input to the model, such as inserting XML data interchange.

Willing to understand the framework of technology or source of friends directly seeking exchange sharing technology: 2042849237

Some of the distributed solutions, the friends who are willing to know can find our team to discuss.

More detailed source code reference: Http://minglisoft.cn/technology

Java EE distributed architecture, restful, Kafka, shiro,spring Mvc,mybatis,redis,dubbo,zookeeper

Analysis of the current popular Java EE Web application architecture