J2EE system includes java server pages (JSP), java SERVLET, enterprise
bean, WEB service and other technologies. The emergence of these technologies provides a very competitive option for the development of WEB applications in the e-commerce era.
1. Architecture overview
J2EE system includes java server pages (JSP), java SERVLET, enterprise
bean, WEB
service and other technologies. The emergence 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 meets the needs of the project is a very important step in the project development process. Completing this step results in a baseline of major milestones. Forming this baseline has many advantages:
Preliminary determination of various factors
In order to form an architecture baseline, architects need to screen the technologies in the platform (system) and weigh various pros and cons. In this process, architects often have to read a lot of technical materials, listen to the suggestions of project team members, consider the needs of domain experts, and consider the cost of sponsors (including development costs and operation and maintenance costs) limits. Once the architectural design has been reviewed, these factors are initially positioned to determine how useful the project will be throughout the course of the project.
Oriented technical training
Once the architecture designed by the architect has been approved to form a baseline, the technology used for project development and operation is basically determined. Many project managers are worried about the technical skills of the prepared project team members; they need training provided by the training department, but in terms of the technical ocean faced by architects, project managers simply cannot put forward clear technical training needs. Why can't all the technologies in the system be trained! With the architectural milestone baseline, the project manager can determine what technology will be used for this project development, which should be the most accurate for the training needs. However, in actual project development, technical training can be carried out concurrently with the architectural design before the baseline is established.
Role division
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, and various implementations. These tasks can be clearly marked on the architectural blueprint, so that project team members can position their tasks well. A good architectural blueprint can also normalize tasks, and can well divide tasks into several categories, and tasks in the same category have the same or similar workload and nature. This has a very good basis for estimating the workload.
Operation and maintenance
As mentioned earlier, each task has a better positioning on the architecture diagram. Anyone can use it to quickly become familiar with the operation of the entire project, and can locate the error point relatively quickly when errors occur. In addition, with a clear architecture diagram, the project version management also has a good version tree trunk.
The extensible
structure is like the trunk of a towering tree. As long as the trunk is firmly rooted, the trunk is thick, there are some side branches, and some leaves are added easily. Again, with a stable and proven architecture, adding a business component or two is very quick and easy.
Everyone knows these benefits and is bent on forming such a J2EE application architecture (like MFC in the windows platform). In this journey, it has gone through two major stages:
1.1. Model 1
Model 1 is not actually a stable architecture, and it can't even be said to have formed an architecture. The basis of Model 1 is the JSP file. It extracts parameters from HTTP requests, invokes corresponding business logic, handles HTTP sessions, and finally generates HTTP documents. A series of such JSP files form a complete Model 1 application, of course there may be other auxiliary classes or files. This was the case with the early ASP
and PHP technologies.
In general, the advantage of this model is simplicity, but it mixes business logic and presentation, and this disadvantage is intolerable for large applications.
1.2, Model 2
After some practice, and extensive reference and lessons learned, J2EE applications finally ushered in the MVC (Model-View-Control) pattern. The MVC model is not unconventional by people in the J2EE industry, so I talked about Guangfa for reference earlier. The core of MVC is to achieve loose coupling of three or even multiple layers. This is a boon and savior for the component-based, technology-expanding J2EE system.
It inserts a control component between the browser (this article refers to the client agent as the browser) and the JSP or SERVLET. This control component concentrates the distribution logic of processing HTTP requests sent by the browser, that is, it will distribute the request to the corresponding
JSP or WEB layer according to the URL of the HTTP request, input parameters, and the current internal state of the application. SERVLET.
In addition, it is also responsible for selecting the next view (in J2EE, JSP, SERVLET will generate html back to the browser to form a view). The centralized control component also facilitates security verification, logging, and sometimes encapsulating request data to the WEB
tier below. The realization of this set of logic forms an application framework like MFC.
1.3. Multi-layer application
Client tier The client tier is
generally a browser or other applications. The client layer generally supports the HTTP protocol, also known as client proxy.
WEB tier WEB application tier
In J2EE, this layer is run by the WEB container, which includes WEB components such as JSP, SERVLET, etc.
EJB tier Enterprise Component Layer
The enterprise component tier is run by the EJB container and supports EJB, JMS, JTA and other services and technologies.
EIS tier Enterprise information system layer
The enterprise information system includes the traditional information systems in the enterprise such as finance, CRM, etc. It is characterized by the support of the database system.
The application framework is currently mainly concentrated in the WEB layer, aiming to standardize the development of this layer of software. In fact, the enterprise component layer can also implement this model, but currently it mainly exists in the form of design patterns. And some frameworks can be expanded. With the participation of enterprise component layer components, the framework will appear more compact, more natural, and more efficient.
2. Candidate solutions
Currently, frameworks for implementing Model 2 are emerging, and the more well-known frameworks are listed below.
2.1, Apache Struts
Struts is a free and open source WEB layer application framework, and the apache software foundation is committed to the development of struts. Struts is highly configurable, and has an ever-growing list of features. A front-end control component, a series of action classes, action mapping, utility classes for processing XML,
automatic filling of server-side java beans, WEB forms that support validation, internationalization support, HTML generation, implementation of presentation logic and templates. soul.
Model
Models exist in the form of one or several java beans. These beans are divided into three types:
Form beans (form Beans)
which saves the data from the HTTP post request. In Struts, all Form beans are subclasses of the ActionFrom class.
Business logic beans
are dedicated to handling business logic.
System state beans
which hold session information for a single client across multiple HTTP requests, as well as system state.
The view
control component continues the HTTP request to the JSP file that implements the view. JSPs can access beans
and generate resulting documents for feedback to clients. Struts provides JSP tag library:
Html, Bean, Logic, Template, etc. to achieve this purpose, and is conducive to separate presentation logic and program logic.
Struts detailed analysis
view-control-model
The user sends a *.do HTTP request. After the control component receives the request, it looks up the action mapping for this request, and then checks whether the corresponding action object (action instance) has been created. If not, call actionmapping to generate an action object, and the control component will save this action object for later use.
Then call the actionmapping method to get the actionForm object. Then pass the actionForm as a parameter to the perform method of the action object. After this method ends, it will return an actionforward object to the control component. The control component then gets the next view's path and redirect properties from this object. If it is a redirection, the HTTPSERVLETREPONSE method is called to display the next view, otherwise,
the requestdispatcher and SERVLETcontext methods are called successively to continue the HTTP request to the next view.
When the action object runs the perform method, an error message may appear. The action object can save these error information to an error object, and then call its own saveerrors method to save the error to the property of the request object.
Then the action object calls the getInput method of the actionmapping object to get the input parameter from the action map, that is, the view that generates the input, and uses the input as the parameter to generate an actionforward object to return. The JSP of this input parameter generally has the HTTP:errors custom tag to read these error messages and display them on the page.
Model to View
Model to View refers to the process of loading system data into the view before the view is displayed. The system data is generally
the information of the java bean in the model. The diagram shows the processing logic of the JSP with the html:form custom tag forwarded by the control component.
html:form custom tag processing object from application
scope (implemented by querying the properties of the SERVLETCONTEXT object) to obtain the action mapping and other objects previously placed there by the control component actionSERVLET,
and find the actionform name, type and scope from the action attribute of the html:form, and search in the corresponding scope actionform, if there is one, use its information to fill the html
form form [the actual filling action is in the processing object of the nested html:text and other custom tags]. Otherwise create an actionform object in the corresponding scope.
Advantages and disadvantages
Advantages:
Some developers have begun to adopt and promote this framework as an open source project, there are many advanced implementation ideas, good support for large-scale applications, and centralized web page navigation definition
Disadvantages:
not industry standard
support for development tools The taglib is not
complicated enough, it takes a long time to master
the combination of html form and actionform, but this is also the essence of it.
It is suggested
to modify the setter and accessor of the actionform attribute to the method of reading or generating the xml document, and then
use the xml document to exchange data between the html form and the actionform, so as to make it loosely coupled and adapt to the application of the easily changing data structure.
JATO
JATO Application Framework is
the old name for iPlanet Application Framework. It is a mature and powerful application framework based on J2EE standard for developing WEB applications. Combines concepts such as display fields, application events, component hierarchy, and page-centric development approaches, as well as MVC and the service-to-workers design pattern.
JATO can be applied to medium, large and super large-scale WEB applications. But it is not an enterprise layer application framework, that is to say, it does not directly provide
methods for creating enterprise layer components such as EJB, WEB services, etc., but it can be used to construct client applications that access enterprise layer components.
This framework function mainly consists of three parts:
iPlanet application framework core;
iPlanet application framework components;
iPlanet application framework extension.
The Application Framework Core defines basic interfaces, object protocols, simple components, and the minimal core of an iPlanet Application Framework program. Includes view simple components, model simple components, request dispatch components, and reusable command objects. The iPlanet application framework components use the basic interfaces, protocols and components defined by the framework core to provide developers with high-level reused components. These components are not only horizontal components that are not related to specific visual effects, but also specially provided to adapt to specific practical environments and improve usability. Vertical type components. Framework extensions implement methods for accessing non-J2EE environments in framework-compatible ways. Typically, extensions are used by framework applications to seamlessly access J2EE container-specific functionality. The JATO platform stack diagram clearly expresses this situation.
JATO最大的威力在：对于快速开发用户，你能利用框架组件和扩展提高生产率，对于要求更大灵活性的用户，你能实现框架核心提供的接口来保持应用的框架兼容性。
实现一个JATO应用程序，可以简单地实现控制组件module1Servlet，视图组件ListCustomersViewBean和模型组件CustomersModuleImpl，以及一个给客户代理显示界面的ListCustomers.jsp文件。并清楚地表明这些组件与JATO框架组件的继承关系。
JATO标签库提供了VIEW对象与JSP文件的接口。库中标签处理程序负责实现VIEW对象和JSP产生地客户端文档的信息同步和交换。
MVC分析
前端控制组件接收用户发来的任何请求，这个可在WEB.xml中指定请求分发组件负责视图管理和导航，和前端控制组件封装在ApplicationSERVLETBase一起实现。应用程序开发者需要为每一个子系统（人力资源，财务，CRM等）实现一个此类的继承。
请求分发组件分发请求给工作者，工作者实现了command接口。应用开发者可以实现这个接口。JATO提供了一个缺省实现：DefaultRequestHandingCommand，这个实现会把请求传给视图组件的特定事件。
组合视图是指视图组件在显示给用户时的层次关系：根视图是一个ViewBean类的对象字段是一个DisplayField类的对象，容器视图是一个ContainerView类的对象。视图组件类的层次关系如下图：
优缺点分析
Advantages:
This framework has a wide range of adaptability, that is, it provides a low-level interface, and there are also ready-to-use components. It
has similar development concepts as client-side RAD development tools, such as page-centric (equivalent to VB's FORM), event processing, etc.
For large-scale Application support is better
. Disadvantages: It
is not an industry standard.
Currently, there is no support for development tools (however, JATO has already prepared for tool support). There is no definition of
web page navigation. Developers specify specific navigation URLs in the view
.
VIEW/MODEL is correspondingly modified into xml document to transmit data, plus centralized web page navigation definition
JSF (JavaServer Faces)
JSF is a framework for developing WEB application user interface that is being defined by expert groups including SUN. JSF technology includes:
a set of API, which implements UI components, manages the state of components, handles events, input validation, defines page navigation, supports internationalization and access;
a JSP custom tag library implements the interface with JSP.
JSF is very simple and a well-defined programming model. Using this technology, developers combine reusable UI components in the page, connect these components to the application's data source, and route client-generated events to server-side event handlers for programming. JSP handles all the complex work behind the scenes, allowing developers to focus on the application code. There is some overlap between
STRUTS, JATO and JSF comparisons , but the emphasis is not the same. Both STRUTS and JATO provide an MVC-style application model, while JSF only provides a programming interface on the user interface. This means that the former two cover a wider range than the latter. JSF can be part of UI development for the first two. WAF WAF is the abbreviation of WEB APPLICATION FRAMWORK, which is the application framework proposed in the SUN Blue Book example program. It implements MVC and other good design patterns. 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 should get data. The user sends an HTTP request (*.screen), which is received by the TemplateSERVLET screen front-end control component, which extracts the request information, sets the CurrentScreen property of the request object, and sends the request to the template JSP. After the template JSP receives the request, the Template tag in the JSP inspects the current screen, obtains the specific parameters of the screen from the screen definition file (Screendefinition.xml), and then generates html and returns it to the client.
Assuming that the HTML returned to the client includes an HTML form, the user submits after entering certain data, and issues an HTTP request (*.do). This request is received by MainSERVLET, which extracts the request information, inspects the action mapping file (mapping.xml), sets the action object (HTTPAction object) that handles this request, and passes it to the requestprosessor object for processing. The Requestprosessor object calls the action object to complete the task. If further processing is required, the requestprosessor object will call the event processing mechanism of the WEBclientcontroler object. After MainSERVLET processes the request, it gets the next screen from the screen flow management object, and passes the request to the JSP file of this screen.
It is worth mentioning that the WEBclientcontroler event processing mechanism finally transfers the data of the HTTP request to the EJBAction object for processing. In this way, the HTTPAction object and the EJBAction object form a two-level processing mechanism. The former level is closely related to the request object, encapsulates the data to form an Event object, and then passes it to the EJBAction object, which has nothing to do with the Request object.
This method can form a session-level data processing mechanism. The figure below shows this method. The HTTPAction1 object processes a request and puts the data into a state SessionBean, and the same is true for HTTPAction2. When HTTPAction3 receives the HTTP request, it transfers the control to EJBAction,
which obtains the state SessionBean data, processes the request, and clears the state SessionBean after success. Content. This mechanism is very suitable for multiple input pages to meet the input data of a business (such as a shopping cart).
Advantages and disadvantages analysis
advantages
The definition of screen navigation clearly
provides a space for the extension of the framework. The source code is relatively
messy
, and the stability and reliability are not verified.
It is just a frame torso, there is no formal model layer, the concept of view is not strong,
there is no model-to-view definition
modification advice
, there is only one frame torso, which provides flexibility for implementing your own application framework. There is no rigid view concept, and it provides an extended interface for input to the model in the web page, such as inserting XML data exchange.