Application design consideration
- Persistence
- Model-view-controller pattern
- Statelessness
- Caching
- Asynchronous considerations
- Third-party libraries
Persistence
Java EE applications persist data to relational databases.
For persistence, focus on...
- data consistency
- security
- maintenance
- portability
- performance of that solution
Java EE persistence options...
- container-managed persistence (CMP) - (Recommended)
- bean-managed persistence (BMP)
- session beans using JDBC
- Java beans using JDBC
For apps that use JDBC enterprise beans rather than EJB entity beans...
- Optimize JDBC SQL statements used within the application.
- Include prepared statements
- Include batching
- Use CMP
- Wrap JDBC functions with a stateless session bean using the session facade pattern
Model-view-controller pattern
One of the standard Java EE programming architectures is the model-view-controller (MVC) architecture, where a call to a controller servlet might include one or more child JSPs to construct the view. The MVC pattern is a recommended pattern for application architecture.
This pattern requires distinct separation of the view (JSPs or presentation logic), the controller (servlets), and the model (business logic). Using the MVC pattern enables optimization of the performance and scalability of each layer separately.
Statelessness
Implementations that avoid storing the client user state scale and perform the best. Design implementations to avoid storing state. If state storage is needed, verify the size of the state data and the time that the state is stored are kept to the smallest possible values.
If state storage is needed, consider the possibility of reconstructing the state if a failure occurs, instead of guaranteeing state failover through replication.
Specific tuning of state affects HTTP session state, dynamic caching, and enterprise beans. Refer to the follow tuning guides for tuning the size, replication, and timing of the state storage:
Caching
Most Java EE application workloads have more read operations than write operations. Read operations require passing a request through several topology levels that consist of a front-end Web server, the Web container of an appserver, the EJB container of an appserver, and a database. WAS provides the ability to cache results at all levels of the network topology and Java EE model that include Web services.
Application designers must consider caching when the application architecture is designed because caching integrates at most levels of the model.
Caching is another reason to enforce the MVC pattern in applications. Combining caching and MVC can provide caching independent of the presentation technology and in cases where there is no presentation to the clients of the application.
Network designers must consider caching when network planning is performed because caching also integrates at most levels of the network topology. For applications that are available on the public Internet, network designers might want to consider Edge Side Include (ESI) caching when WAS caching extends into the public Internet. Network caching services are available in the proxy server for WAS, WebSphere Edge Component Caching Proxy, and the WebSphere plug-in.
Asynchronous considerations
Java EE workloads typically consist of two types of operations. You must perform the first type of operation to respond to a system request. We can perform the second type of operation asynchronously after the user request that initiated the operation is fulfilled.
An example of this difference is an application that enables you to submit a purchase order, enables you to continue while the system validates the order, queries remote systems, and in the future informs you of the purchase order status. This example can be implemented synchronously with the client waiting for the response. The synchronous implementation requires appserver resources and you wait until the entire operations complete. If the process enables you to continue, while the result is computed asynchronously, the appserver can schedule the processing to occur when it is optimal in relation to other requests. The notification to we can be triggered through e-mail or some other interface within the application.
Because the asynchronous approach supports optimal scheduling of workloads and minimal server resource, consider asynchronous architectures. WAS supports asynchronous programming through Java EE JMS and message-driven beans (MDB) as well as asynchronous beans that are explained in the Tuning Java Message Service and Tuning MDB topics.
Third-party libraries
Verify that all the libraries that applications use are also designed for server-side performance. Some libraries are designed to work well within a client application and fail to consider server-side performance concerns, for example, memory utilization, synchronization, and pooling. It is suggested that all libraries that are not developed as part of an application undergo performance testing using the same test methodologies as used for the application.
Related tasks
Tuning the application serving environment
IBM WebSphere Developer Technical Journal: The top 10 (more or less) Java EE best practices
Improve performance in the XML applications, Part 2