Preparing a good application architecture for J2EE
Author: Gong Yongsheng article taken from: open systems world - SEOUL December 25, 2002
There will be a good system with a good architecture. National e-government clearly proposes an infrastructure to standardize and protect current e-government implementation. From the architectural needs, this paper analyzes the application architecture that follows J2EE specifications. The content includes 5-level division, role division, and JSF web application architecture, aimed at communicating with the majority of architect designers.
Architectural needs
The RUP (Unified Software Process) has the following requirements: a requirement describes the conditions or capabilities that the system must meet, it can be directly from the user, and in some formal documents such as contracts, standards, standards, etc.. Demand can be divided into two categories, which are architectural needs and business functionality. Architecture requirements are those that affect the system architecture, with universality, such as for a maintenance subsystem, there must be security, high reliability, good scalability and cross-platform. Business features require business problems that are mainly solved by the system, with special nature, such as online tax returns, online booking, etc. As the application continues to develop and large scale development, architectural demand is increasingly becoming the core of system development and implementation. For example, e-government clearly propose the concept of "application support platform", including document exchange, old system integration, workflow, report printing, and single landing. J2EE specification and technologies based on this normative, is a good competitive choice for realizing architectural needs.
J2EE Web programming architecture
J2EE Web Application Architecture (just like MFC in Windows Platform) experienced longer development, this route mainly experienced model 1 and model 2 two stages. Model 1 Model 1 is actually not a stable architecture, even talking about the formation. The foundation of the model 1 is the JSP file, the JSP file extracts parameters from the request of HTTP, calls the corresponding business logic, handles the HTTP session, and finally generate the HTTP document. A series of such JSP files form a complete model 1 application, of course, there may be other auxiliary classes or files. Early ASP and PHP technology belong to this situation. In general, the advantage of this model is simple, but it is mixed with business logic and performance. For large applications, this disadvantage is that people can't help. Model 2 Model 2 Insert a control component between customer-level applications and JSP or servlets. This control component focuses on the distribution logic of HTTP requests sent by the client-level app. That is, it will send the request to the corresponding Web stage JSP or Servlet based on the URL input parameters of the HTTP request and the internal state of the current application. In addition, it is also responsible for choosing the next view (in J2EE, JSP and servlet generate HTML returned to the browser to form a view). The centralized control components are conducive to security verification and logging logs because sometimes it also requests data to the following Web Tier. This set of logic implements an application framework like MFC (Figure 1).
Figure 1 Model 2 Application Frame in J2EE Application
Currently, for components, the J2EE system that is covered by continuous expansion is mainly used by MVC mode, which is implemented by mode 2. After some practice, MVC mode, the J2EE application finally welcomes the MVC (Model - View-Control) mode after learning and summarizing the lessons. The MVC mode is not a new J2EE industry. The core of MVC is to do three or even multi-level loose coupling. There are two types of application systems: interactive and workflow. The former needs a lot of interactions with users, and the latter only needs a small number of users to intervene, and can even run in the background. In the B / S website application, the user interacts with the website by submitting requests, accessing the device constantly displays the page corresponding request, which is a typical interactive application. Architecture designers generally use MVC mode when designing such applications. The MVC mode disperse the functionality of data management and display to different objects to reduce the coupling between the objects. It divides the application into three parts, which are models, views, and control, and minimize the coupling between the parties. Each portion handles a specific task and is responsible for completing communication with other parts. The model part represents business data and access and modifying data. When the data changes, it is responsible for notifying the view part and provides the ability of the view query status. In addition, it also provides application functions to control. The view part displays the contents of the model in its own way. It accesss the data of the model, and updates the display of the model when the data of the model changes. The view also transmits the information obtained from the user to the control section. The control section defines the behavior of the application. It distributes user requests and selection performance views, and is responsible for explaining user input, and then calls the model's functionality. In standalone GUI programs, user input includes mouse click and menu selection, in a web application, user input includes HTTP GET and POST requests for Web-level resources. The control section selects the view to display according to the status of the user interaction and the model. An application is generally selected to select a control. Figure 2 shows the relationship between the three parts of an MVC application. Assigning duties between models, views, and control helps to reduce code repeat and reduce maintenance difficulties. Because commercial logic and data separation are increasing data sources, operations become relatively simple when changing data representations, and does not need to change business logic, and add new customer types. It is easy. Figure 1 MVC model diagram
Architecture cube
Architectural Cube is analyzed from three latitudes, and these three latches are grades, layers, and capabilities, respectively. Multi-level division Everyone will not forget the hardware bare metal, operating system and application of tiering ideas, and must not forget the seven-layer model of the ISO network protocol. In the architectural cube (as shown in Figure 3), the lower platform refers to the operating system layer, the upper platform refers to the J2EE application server, the virtual platform refers to some of the API and component providers, the application refers to a project application that solves some user needs development. . Middleware components of component providers, such as Silverstream's Director can be positioned in the virtual platform layer. Capacity division capacity is a series of Abplace requirements. Under normal circumstances, the design pattern mainly considers these ABLITY requirements. At designing applications, considerations in capacity is a process of weighing various factors. Multi-level application
Figure 3 Architectural Cube
Figure 4 J2EE application five-level map
The three-story structure here should be a five-level structure here. Figure 4 is a typical multi-level application system in the J2EE system, and the classified five levels are: ◆ Client Tier customer level, generally browser or other applications, and The program running on these browsers. The client is generally supporting the HTTP protocol, also known as the customer agent. ◆ Web Tier Web Application Level, in J2EE, this level is run by web container, including JSP and Servlets and other web parts. ◆ EJB Tier Enterprise Component, Enterprise Component Level Run by the EJB container, which supports EJB technology. ◆ Eai Tier system integration, including JDBC, Web Services, Javamail, JINI, JMS, and JTA, this layer is either a corresponding contact station at both ends, or in the middle, set a system responsible for coordination, centralized data, and control, such as Web Services Register server, mail server, etc. ◆ EIS Tier Enterprise Information System Level, Enterprise Information System includes traditional information systems, such as financial systems, CRM systems, etc., feature support for database systems. The web application framework (such as Struts, JSF) is currently mainly in the Web level, designed to regulate the development of this layer of software. Customer Level When you implement a customer-level for your application, you need to consider the factors of networks, security, and platforms. 1. Network network should mainly consider the following: ◆ Non-zero time network delay; ◆ Limited bandwidth; ◆ Unreliable network. A good client should have the following features: ◆ Connect the server if necessary; ◆ Only the necessary data on the network; ◆ Work can also be better when you connect the server. 2. Security We must consider the relationship between the client and the firewall, so some client technology cannot pass the firewall. If the client is outside the enterprise, it is necessary to strengthen the security issues such as verification. 3. Platform We have to consider the platform's computing power, such as the browser is generally used to browse, so that the browser's web level program cannot return simple data, it must return the browser such as HTML to express the documentation. Independent applications can download data and can draw a variety of performance. Another thing to consider is the size of the platform. The desktop PC can display a lot of content at a time, and there is a keyboard and a mouse and other input devices. The mobile phone does not have these conditions. When designing the client content for your mobile phone, there is a lot of input and a large display of layout requirements. 4. Designing a multi-customer design web application can only support a single-class client with a protocol, or support multiple types of clients with different protocols, security policies, performance logic, and workflows. The web client may include different versions of different browsers, such as the MIDP (Mobile Information Device Profile client and client client. Long-term application design should support new types of clients. Each type of client requires its own controller, and some clients require different view components due to dimensional factors. Multi-control provides an extension capability that supports any client type, each of which implements workflow, performance logic, security constraints such as your client type. All controls can also share the model part, which ensures unified application behavior across the client type, and makes maintenance and testing simple, easy. A protocol routing component provides a single entry that controls all client types, providing an entry point for implementing some functions across the client type, Figure 5 reflects this design structure. Figure 5 Customer multi-customer type diagram
5. Customer-Level Available Technical Customer Level Programs Run on the device to access the system, currently the main technologies are: ◆ Various client scripts, including Java Script, VB Script, Java small applications, and CSS technology This technology is used to customize the style of the client page or even content; ◆ Web Start technology, this technology is used to remotely deploy independent applications; ◆ Develop a separate application technology, the development of independent applications can be used Development platform, such as Windows 32 programs, Java independent procedures, etc .; ◆ security mechanism, security mechanisms are used to limit access to programs downloaded from the network to run access on the machine, JDK V1.3 has provided a flexible Customized security mechanism. Web and EJB level MVC are mainly reflected in these two levels. The following focuses on the composition of the SUN's Blue Pass WAF architecture. Figure 6 Sun WAF Control Partial Map
Figure 6 reflects the composition of the "Control" section in the WAF architecture. Where Servlet Filter and Front Controller are front-end control; Request Processor, Web Controller, and EJB Controller are part of the sub-control section; the Template Service and Screen Flow Manager control section implement the selection and generation of the view; other controls provided by the program developer according to functional requirements Part, there is a (Action class) belonging to the control section, there is a view part (such as JSP pages and other resource files), and there is also a model portion (such as enterprise bean). As can be seen from Figure 6, the control portion consists of several components, and they work together to achieve the demand for scalability and maintenance. These control components are: ◆ A front-end control servlet, which receives and handles the HTTP request, then completes the division request and selection together with other control components, generates the work of the view; ◆ In the EJB level EJB control class interpret event and execute EJB level EJB action. Events and actions can also be configured in an XML file, developers easy to define new business logic. The presence of Web-level actions and EJB-level action classes allow developers to choose the appropriate level implementation application; ◆ Servlet filter is placed in front of the front-end control servlet, used to add some functions for all requests, such as encryption and decryption; ◆ one Template Service servlet assigns screen data to the screen definition parameters and organizes the class resource to form a view and responds to the user. The screen definition is in the external configuration file, developers easy to implement the customs of the view. Web and EJB levels are the most important part of the application. Usually require support for load balancing technology, high availability technology, and database connection pools. Web levels are currently: ◆ Java Pages, this technique is mainly used in the view part of the MVC mode; ◆ Java servlets, this technique is mainly used in the control section of the MVC mode, often used in the transfer file, generates binary data response The aspect; ◆ Java bean, this technology is mainly used in the MVC mode model part. It is a temporary model that often appears in parameter delivery, return results, etc., ◆ XSLT, as part of the scalable style page XSL, XSLT Used to convert an XML document, such as converting an XML document into an HTML document. EJB level is currently: ◆ Enterprise bean, where the session bean is mainly used as a control section, and the entity bean is used as a model part. The message bean is used in the integrated layer; ◆ Java bean, this technology is mainly used in the MVC mode It is a temporary model that often appears in parameter delivery, return results, etc., to avoid the consumption of enterprise beans. In order to solve the integration of EIS (Enterprise Information System), J2EE platform provides the following four technologies (Figure 7): Figure 7
◆ J2EE connection system, the J2EE connection system provides a standard framework for J2EE applications and EIS systems in an enterprise, which enables external EIS's adapters to work with the J2EE application server in plug-ins. Enterprise applications can use the standard interface of the adapter to operate safely, transactional and high telescopic. ◆ JMS (Java Information Services), Java Information Services is a standard programming interface that supports enterprise communication systems, with a common interface that spans different types of communication systems. After the Java application uses JMS API and businesses to connect, the application can create and send messages using the functions provided by the communication system, reach the purpose of asynchronous communication with other application systems. ◆ JDBC API, is the standard interface integrated with relational database systems. The Java application uses this interface to get database connections, query data, and perform other database functions. ◆ Web Services technology, this technique allows EIS to provide some service access points, and new applications can obtain data through these points, or you can submit data. Role and architecture relationship
Most of J2EE will involve role division, such as the servlet specification, which means what to do, and what to do in the application developer. Architecture and roles are closely linked, because good architecture follows rigorous specifications, and allows roles to work together, thus accelerating development. In the application development and deployment life cycle, the J2EE platform defines some roles to complete their work. They are J2EE product providers, application component providers, application integrators, deployers, system administrators, and tool providers, and the relationship between them can be seen in Figure 8. The definition of roles helps to clarify the responsibility of different participants in application development, deployment, and runtime. Different characters do not mean different participants, one participant can have multiple characters, one role can be borne by multiple participants.
Figure 8 J2EE platform role diagram
These roles are defined below, and some sub-roles are defined in some specification, such as enterprise bean providers, EJB container providers, and EJB server providers defined in the EJB specification. The J2EE product provider J2EE product provider implements a J2EE product, which provides other features defined in the component container, J2EE platform API, and J2EE specifications. A J2EE product can of course also implement an interface that is not specified in the specification. J2EE product providers also offer application deployment and management tools. Deployers allow deployers to deploy components to the J2EE product, manage tools allow system managers to manage J2EE products and deployment applications. Application component provider Application component provider produces basic construction blocks of J2EE programs, they have expertise in developing two aspects of reusable components and business sectors. Application component providers do not have to know the operating environment of their components. This platform role has the following sub-roles: ◆ page author; ◆ document editor; ◆ bean developer, etc. These sub-roles are working with tool providers. Application Integrators Apply Integrators get components from the application component provider and integrate these components together to form a complete J2EE application. Their expertise provides solutions for specific issues. Application integrators can not be familiar with the source code of their integrated components, in order to know how to create an application with these components, they make full use of components. Like the application component provider, applying integrators do not have to know the application's operating environment. They often work with the GUI tool developed by the application component provider or tool provider. Application integrators are only responsible for providing integration instructions that describe external dependence, and solve these external dependencies are the work of deployers. Deployers deployers are an expert in a particular operating environment, responsible for deploying J2EE components and applies to actual environments. He uses the J2EE product provider's tool to perform deployment, install components and applications on the J2EE server, and configure the configuration to resolve the external dependence of component developers and integrators declaration. System administrator system administrators are responsible for configuring and managing business computing and network facilities, and monitor the health of the J2EE app. He generally monitored and managed work with J2EE product providers. Tool Provider Tools providers provide tools for application components. These tools are generally unrelated to the platform.
The latest JSF architecture JSF briefly describes that JSF technology is a user interface framework for building a web application that is running on the JSP server and displays the user. Its main function is: ◆ Indicates the UI component, and can manage their status well; ◆ Process the user interface event and enter the check in the server; ◆ Define page navigation; ◆ Support internationalization; ◆ Provide it with JSP Custom label library. Developers can do with minimal price: ◆ User interface events generated by the server-side code processing; ◆ Map user interface components to server data; ◆ Construct user interface with a reuse and scalable component library; ◆ Save and restore user interface status across a service request. The biggest benefit of JSF technology This technology provides a performance and behavioral thorough ability, while JSP can only be partially isolated. JSF has previously moved only the fine-grained isolation completed under the client UI system (DOM) to the server side, and the client only needs to explain the standard HTML syntax, which has reached the fully thin client target. Another main purpose of JSF is to use the familiar UI components and web level concepts and do not limit developers to some specific script techniques or marker languages. JSF provides a JSP tag library to achieve binding to JSP, but developers can use other performance techniques because JSF relies directly on the JavaServlet API. The JSF application consists of the JSF application, which is the same as the previous Java web. It runs in the Java Servlet container, including: ◆ JAVABeans components that become models in JSF technology; ◆ Event (servlet event) listener; ◆ Ordinary label Library; ◆ Web page (HTML, JSP, etc.); ◆ Service Help class; ◆ A customized UI component is explained on the page; ◆ In the server-side UI component; ◆ Verifier, UI event handling Merry, navigator. To express UI components on the web, each JSF application must contain a custom label library, which does not require HTML or other tag language hard coding UI components. The general JSF implementation will provide such a label library, and developers can define and implement label libraries themselves. The UI component interface in JSF technology is on the client, but the operation and status are saved on the server. The application can manipulate the status of the component, and can also use the server code to process the event generated by the client. Before changing server-side data, JSF technology allows the validity of each component to verify the data of each component, and does not submit through the data of the validity test, the error message will automatically display next to the generated component. JSF technology also provides an independent class completion page navigation task. Figure 9 shows the composition of JSF technology in a JSF program.
Figure 9 jaf composition
The JSF involved in JSF involves various roles of page authors, interface components developers, application developers, tool providers, and JSF implementors. The page author is responsible for the user interface of the web application; interface component developers are responsible for providing reusable interface component library application developers responsible for the development and user interfaces do not directly contact the server functionality; tool providers are responsible for research tools to assist JSF The development of applications; JSF implementors provide JSF runtime environments requiring JSF specifications.
to sum up
In order to meet the architectural needs, there must be a good application architecture. This facilitates the communication of the project team, and can accelerate the development speed, increase the reuse, and fully safeguard the successful implementation and operation of the project.
