Transfer from JR Author: Tarak Modi Although many articles have discussed J2EE best practices. So why do I have to write an article again? What is this in this article different from the previous article? Where is it better than other articles? First, the target reader in this article is a architect that is engaged in technical work. In order to avoid wasting everyone, I will avoid the best practices of some Chen rot, such as "Build Daily", "Test Everything" and "Integrate Offenden. Any competent architect. The projects have a clear and defined team structure. They also use code inspections, build code (time daily or when needed), test (unit, integration, and system), deployment, and configuration / release management. With a recorded process. Second, I will skip the best practice, such as "interface-based design", "using the famous design model", "using the service-oriented architecture". On the contrary, I will focus on I have learned and used a number of 6 (not a lot of) in-Trench courses. Finally, the purpose of this article is to let you think about your architecture, provide work code examples or solutions beyond this article. Range. Let me introduce this 6 lesson: Lesson 1: Do not bypass server-side verification as a software consultant, I have had the opportunity not only designed and implemented web applications, but also assessed / reviewed many webs. Application. In complex, and in applications encapsulated in a JavaScript client, I often encounter a web page that performs a large number of checking users. Even if the HTML element has the properties of data validity, such as Maxlength. Only After all the input information is successfully verified, the HTML form can be submitted. As a result, once the server receives the notification form (request), it is properly executed. Here, do you find a problem? Developers have done a lot of important assumptions For example, they assume that all web applications are equally honest. Developers also assume that all users will always use the browser they tested to access the web application. There are many other assumptions. These developers have forgotten the utilization The free tool is easy to simulate the behavior of the browser through the command line. In fact, by typing the appropriate URL in the browser window, you can send any "posted" form, despite this, by disabling these pages Request, you easily block such "form sending". However, you can't prevent people from simulating or even create their own browsers to invade your system. The fundamental problem is that developers cannot determine client authentication and server authentication Main differences. The main difference between the two is not where verification happens, such as at the client or on the server. The main difference is the purpose of the object behind. Client verification is only convenient. Execute it provides users with quick feedback ?? Make the application seem to respond, give people an illusion that runs desktop applications. On the other hand, server-side verification is required to build a security web application. No matter what is input on the client side, it can Make sure that all data from the client to the server are valid. Thus, only server-side verification can provide a safe application level. Many developers have fallen into a buzzer: only verification of all data in the client can ensure safety. Below is a common example of this view: a typical login page has a text box for entering a user name and a text box for entering a password.
At the server side, someone may encounter some code in receiving the servlet, which forms the SQL query in the following form: "SELECT * from securityTable where username = '" Form.GetParameter ("UserName") "' and Password = '" Form.GetParameter (" Password ") "; "and executes these code. If the query returns a certain line of the result set, the user logs in success, otherwise the user logs in failed. The first question is to construct SQL's way, but now let us ignore it temporarily. What if the user enters "Alice '-" in the user name? Assuming users named "Alice" have been in SecurityTable, then this user (more appropriate manner is hacker) successfully logged in. I will use the reason why this happens to be left as a problem for you. Many creative client validations prevent a general user from logging in from the browser. But what do we do with a client that has disabled JavaScript, or those who can use other similar browser programs directly send commands (HTTP POST and GET commands), what do we do? Server-side verification is necessary to prevent this type of vulnerability. At this time, SSL, firewall, etc. are not used. Lesson 2: Safety is not an additive, such as Lesson 1, I have been fortunate to study many web applications. I found that all JavaServer Page (JSP) has a common topic, which is a layout similar to the following pseudo code: <% user user = session.getattribute ("user"); if (user == null) {//// Redirect to // the logon page ...} if (! User.Role.equals ("manager")) {// redirect to the // "unauthorized" Page ...}%> If the project uses a MVC framework such as Struts, all ACTION beans have similar code. Although the last code may run very well, if you find a bug, or you have to add a new role (for example, "guest" or "admin"), this will represent a nightmare. In addition, all developers need to be familiar with this coding mode whether you are young. Of course, you can use some JSP tags to organize the JSP code, you can create a basic action bean that clears the derived action bean. Despite this, since the safety-related code will be distributed into multiple places, the nightmares when maintaining are still exist. Since the security of the web application is forced to establish the level of application code (by multiple developers), the web application is still likely to have weaknesses. It is very likely that the fundamental problem is to handle security issues when the project is close to completion.
Recently, as a architect, I have experienced some of the six versions to implement the project in more than a year, but until the fourth edition we mentioned safety ?? Even if the project will be highly sensitive Personal data is exposed to the web, we have not noticed security. In order to change the release plan, we have been involved in the battle with project funders and their managers to include all security-related features in the first edition and put some "business" function in subsequent versions. In the end, we have won the victory. And because the security of the application is quite high, protecting the private data of the customer, this is proud of this, our customers are very happy. Unfortunately, in most applications, security does not increase any actual business value, so until finally solve. When this happens, people rushed to develop and safely related code, and did not consider the long-term maintenance or robustness of the solution. Another sign that ignores the security is a lack of comprehensive server-side verification, as I am in Lesson 1, this is an important part of the security web application. Remember: J2EE Web Applications is not just use of appropriate declarations in web.xml and ejb-jar.xml files, nor using J2EE technology, such as Java authentication and authorization service, JaaS ). It is concurrently designed and implements a architecture that supports it. Lesson 3: Internationalization (I18N) is no longer a trip to talk about the fact that many English non-nominal people will visit your public web application. With the implementation of e-government, this is especially true because it allows people to interact with government agencies online online. Such examples include rehabilitation driver's licenses or vehicle registration certificates. Many first languages are not English people likely to visit such an app. Internationalization (ie: "I18N", because in the "Internationalization" word, there are 18 letters between the letter i and the letter n, which allows your application to support multiple languages. Obviously, if you have hard-coded text in your JSP page, or your Java code returns a hard coded error message, then you have to spend a lot of time to develop this web application Spanish version. However, in a web application, in order to support multiple languages, the text is not the only part of the "avatar". Because there is a text in many images, the graphics and images should also be configurable. In extreme cases, images (or color) may have a completely different in different cultural contexts. Similarly, any Java code that format numbers and dates must also be localized. But the problem is: Your page layout may also need to change. For example, if you use an HTML form to format and display menu options, application heads, or footholds, you might have to change the minimum width of each column and other possible aspects of each column for each support. In order to adapt to different fonts and colors, you may have to use a separate style sheet for each language. Obviously, now create an international web app is facing architectural challenges rather than the application challenges. A good web application means that your JSP page and all business-related (applications unique) Java code does not know localization unconsciously. The lesson to remember is: Don't support internationalization because Java, J2EE supports internationalization. You must remember to design an international solution from the first day. Lesson 4: Avoiding common error in MVC, J2EE development is sufficiently mature, in representing layers, most items use certain forms of MVC architecture, such as Struts.
In such a project, the phenomenon I often see is misuse of MVC mode. Here are a few examples. Common misuse is all of the business logic in the model layer (eg, in the Struts Action bean). Don't forget, the model layer of the layer is still part of the layer. The correct way to use the model layer is to call the appropriate service layer service (or object) and send the result to the view layer. In terms of design patterns, the MVC represents the model of the layer should be implemented as an appearance of the business layer (FA? ADE). A better way is to use the business delegate mode in the Core J2EE Patterns. This section excerpts from the book excel the point and advantage of implementing your model as business delegate: Business delegate plays a role in client business. It abstracts, and then hides the implementation of business services. Using Business Delegate, you can reduce business services that represent layer clients and systems. The degree of coupling. Depending on the implementation strategy, Business delegate can protect the client unusabogenic effects in the implementation of the business service API. Thus, when the business service API or its underlying, it is possible to potentially reduce the number of times the representation layer client code must be modified. Another common error is to place a number of logic indicated in the model layer. For example, if the JSP page needs to be formatted in a specified manner or sorted data in a specified manner, some people may place the logic in the model layer, which is wrong place for the logic. In fact, it should be in a group of Helper classes used in the JSP page. When the business layer returns data, the Action Bean should forward the data to the view layer. Thus, there is no need to create excessive coupling between the model and the view, you can flexibly support multiple view layers (JSP, Velocity, XML, etc.). Also allow the view to determine the best way to display data to the user. Finally, most of the MVC applications I have ever seen have a controller that is not fully applicable. For example, most Struts applications will create a basic Action class and complete all security-related features. All other Action beans are derived classes for this base class. This feature should be part of the controller, because if there is no security condition, first call the action bean (ie: model). Remember, one of the most powerful features of a well-designed MVC architecture is a robust, scalable controller. You should use this capability to strengthen your own advantages. Lesson 5: Don't be bound by JOPO. I have witnessed many projects to use Enterprise Javabean in order to use Enterprise JavaBean. Because EJB seems to bring superiority and self-respecting performance, sometimes it is a coolness factor. And other times, it will cause J2EE and EJB to be confused. Remember, J2EE and EJB are not consent. EJB is just part of J2EE, J2EE is a series of technologies including JSP, Servlet, Java Message Service (JMS), Java Database Connection (JDBC), JaaS, Java Management Extensions (JMX), and EJB, and also related to how to use These technologies have established a set of guidelines and patterns of solutions. If EJB does not need to use EJB, they may affect the performance of the program. Compared to old web servers, EJB generally has more requirements for application servers. All value-added services provided by EJB generally need to consume greater memory and more CPU times.
Many applications do not need these services, so the application server is to compete with the application. In some cases, unnecessarily use EJB may cause the application to crash. For example, I have recently encountered an application developed on an open source application server. Business logic is packaged in a series of stateful session beans. Developers have a lot of "passivation" for these Beans in the application server. The client requires an application to deploy on a commercial application server, and the server is part of the client technology stack. The application server does not allow the "Passivation" function to be closed. In fact, the client does not want to change any set of application servers with its cooperation. As a result, the developer has encountered a lot of trouble. (It seems) interesting things is that developers don't give this reason why the code is implemented with EJBs (and still state session beans). Not only the developers will encounter performance issues, but their procedures are not working there. In web applications, there is no formatted normal Java object (POJO) is an EJB powerful competitor. Pojo is a lightweight, unloaring an additional burden as EJB. In my opinion, the advantages of many EJBs, such as objects into the pool, estimated too high. Pojo is your friend, don't be bound by it. Lesson 6: Data Access does not host O / R mapping I have participated in all web applications with data accessible from other places, and therefore require a data access layer. This is not to say that all items need to be identified and established such a layer, which means that the existence of such layers is not implicit. If it is an implicit data layer, the data layer is part of the business object (ie: business service) layer. This applies to small applications, but usually in contact with architectural guidelines accepted by large projects. In summary, the data access layer must satisfy or exceed the following four standards: a transparency business object can use the data source without knowing the details of the data source implementation. Since the implementation is hidden inside the data access layer, the access is transparent. Easy to migrate data access layers make applications easy to migrate to other database implementations. The business object does not understand the underlying data implementation, so the migration only involves modifying the data access layer. Further, if you are deploying a factory strategy, you can provide specific factory implementations for the storage of each underlying storage. If so, migration to a different storage implementation means providing a new factory implementation for the application. Try to minimize the complexity of the business objects because the data access layer manages all data access complexity, which simplifies the code of the business object and other data clients using the data access layer. Data Access Layer, not a business object, containing many code related to implementation (eg, SQL statements). This brings higher efficiency, better maintainability, and improves code readability. Connect all data access in separate layers Since all data access operations are now delegated to the data access layer, you can see this separate data access layer as you can isolate other parts of your application. Layer. This centralization can make the application easy to maintain and manage. Note: These criteria do not explicitly call the demand for the O / R (object to the relationship) mapping layer. The O / R mapping layer is typically created with an O / R mapping tool, which provides an object to view and perceive the relational data structure (Look-and-Feel). In my opinion, using O / R mapping in the project is similar to using EJB. In most cases, it does not require it. For relational databases containing medium-size, multi-relational relational databases, O / R mappings become quite complicated.
