12 most important J2EE Best Practices (2)

4. Plan to use J2EE Security from the very beginning.
Enable WebSphere security. This allows your EJB and URL to at least allow access by all authorized users. Don't ask why-Just follow the instructions.

There were very few customers who planned to enable WebSphere J2EE Security from the very beginning, and we were surprised by the 1.1 straight forward. It is estimated that only about 50% of customers plan to use this feature from the very beginning. For example, we have worked with some large financial institutions (banks, agents, and so on) and they do not intend to enable security. Fortunately, this problem can be solved during pre-deployment checks.

It is dangerous not to use J2EE Security. Assuming that your applications require security (almost all applications need it), you can bet that your developers can build their own security system, this system is better than the one you bought from the J2EE manufacturer. This is not a good bet. It is extremely difficult to provide security for distributed applications. For example, you need to use a network security encryption token to control access to ejbs. In our experience, most self-built security systems are insecure and have major defects, which makes the product system extremely vulnerable.

Some reasons for not using J2EE Security include: worry about performance degradation, believe that other security (such as netegrity SiteMinder) can replace J2EE Security, or do not know the security features and functions of Websphere Application Server. Do not fall into these traps. Especially, although products such as netegrity SiteMinder provide excellent security features, they alone cannot protect the entire J2EE application. These products must be combined with J2EE application servers to fully protect your system.

Another common reason for not using J2EE Security is that the role-based model does not provide adequate granularity access control to meet complex business rules. Despite the fact, this should not be the reason for not using J2EE Security. On the contrary, J2EE authentication and J2EE roles should be combined with specific extension rules. If a complex business rule requires a security decision, write the corresponding code. The security decision should be based on the usable and reliable J2EE authentication information (user ID and role ).

5. create what you know.
Repeated development work will allow you to gradually master all the J2EE modules. All modules should be involved from the very beginning rather than from the very beginning.

We must acknowledge that J2EE is a huge system. If a development team only begins to use J2EE, it will be difficult to grasp it at once. There are too many concepts and APIs to be mastered in J2EE. In this case, the key to successfully master J2EE is to start with a simple step.

This method can be best implemented by creating small and simple modules in your application. If a development team creates a simple domain model and a backend persistence mechanism (probably using JDBC) and performs a complete test on it, this will enhance their self-confidence, so they will use this domain model to master front-end development using Servlet and JSP. If an development team finds it necessary to use EJB, they will similarly start to use simple session facades on the persistent EJB component of container management, you can also use JDBC-based data access objects and Dao instead of skipping them to use more complex structures (such as message-driven bean and JMS ).

This method is not a new method, but few developers use it to develop their skills. On the contrary, most development teams try to build all the modules right away, involving both the view layer, model layer, and controller layer in MVC, the result is that they are often under pressure of progress. They should consider some agile development methods, such as extreme programming (XP), which adopt an incremental learning and development method. In XP, there is a process called modelfirst, which involves first building a domain model as a mechanism to organize and implement user scenarios. Basically, you need to build a domain model as the first part of the user scenario you want to implement, and then build a user interface (UI) on top of the domain model as the result of user scenario implementation. This method is very suitable for an developer to learn only one technology at a time, rather than asking them to face many situations at the same time (or asking them to read a lot of books), which will cause them to crash.

Also, repeated development at each application layer may contain some appropriate patterns and best practices. If you start to apply some modes such as data access objects and session facades from the underlying layer of the application, you should not use the domain logic in your JSP and other view objects.

Finally, when you develop some simple modules, you can test the performance of your applications at the beginning. If you do not perform performance tests until the end of application development, this will often have disastrous consequences.

6. Always use session facades when using the EJB component.
Never expose the entity bean directly to any user type. The object bean can only use the local EJB interface (local EJB interfaces ).

When using the EJB component, using a session facades is undoubtedly the best practice. In fact, this general practice is widely applied to any distributed technology, including CORBA, EJB, and DCOM. Fundamentally, the more underlying your application's "cross-region" distribution is, the less time it takes to consume small pieces of data due to repeated Network Relay. To achieve this goal, you can create a large-granularity facades object, which contains the logic subsystem. Therefore, you can call a method to complete some useful business functions. This method not only reduces network overhead, but also greatly reduces the number of accesses to the database by creating a transaction environment for the entire business function in EJB.

The local EJB interface (used since the EJB 2.0 specification) provides a Performance Optimization Method for coexistence ejbs. The Local interface must be explicitly accessed by your application. This requires code changes and prevents application changes when configuring EJB in the future. Since the session facades and the entire EJB contained in the session should be local to each other, we recommend that you use a local interface for the Entity Bean after the session facades. However, the implementation of session facades itself (for example, stateless session bean) should be designed as a remote interface.

To optimize the performance, you can add a local interface to the session facades. In most cases (at least in Web applications), your EJB client and EJB will coexist in the same Java Virtual Machine (JVM. In another case, if the session facades is called locally, you can use the J2EE application server configuration optimization (configuration optimizations), for example, "no local copies" in WebSphere ". However, you must note that these alternative schemes change the pass-by-value method from pass-by-value to pass-by-reference ). This may cause subtle errors in your code. When you want to use these solutions, you should consider their feasibility from the very beginning.

If you use a remote interface (instead of a local Interface) in your session facades, you can also configure the same session facades in J2EE 1.4 as a Web service in a compatible manner. This is because JSR 109 (Web Service deployment in J2EE 1.4) requires that the remote interface of the stateless Session Bean be used as the interface implemented by the EJB web service and EJB. This is worthwhile because it can increase the number of client types for your business logic.

7. Use stateless Session Bean instead of stateful Session Bean.
In this way, your system can withstand the wrong termination. Use httpsession to store user-related statuses.

In our opinion, the concept of stateful Session Bean is outdated. If you think about it carefully, a stateful Session Bean is actually exactly the same as a CORBA object in architecture. It is nothing more than an object instance bound to a server, it depends on the server to manage its lifecycle. If the server is disabled, the object does not exist, and the client information of the bean does not exist.

The fault transfer (Failover) provided by the J2EE application server for stateful session bean can solve some problems, but the stateful solution is not stateless and easy to expand. For example, in WebSphere Application Server, requests for stateless session beans are achieved through balanced loading of member clusters where stateless sessions are deployed. On the contrary, the J2EE application server cannot load stateful bean requests in a balanced manner. This means that the loading process of servers in your cluster will be unbalanced. In addition, using stateful Session Bean will add some status to your application server, which is also a bad practice. This increases the complexity of the system and complicate the problem in the case of a fault. A key principle for creating a robust distributed system is to try to use stateless behavior.

Therefore, we recommend that you use the stateless Session Bean Method for most applications. Any user-related status that needs to be used during processing should be transmitted to the EJB method in the form of parameters (and stored by using a mechanism such as httpsession) you can also retrieve data from persistent backend storage (for example, by using an entity bean) as part of an EJB transaction. This information can be cached in the memory when appropriate, but it is potentially challenging to store this cache in a distributed environment. The cache is very suitable for read-only data.

In short, make sure that the scalability is taken into account from the very beginning. Check all ideas in the design and consider whether your application can run properly when it is running on multiple servers. This rule is applicable not only to the application code in the preceding situations, but also to mbean and other management interfaces.

Avoiding stateful usage is not just a recommendation for IBM/websphere, it is a basic J2EE design principle.