Application design consideration

 

+

Search Tips   |   Advanced Search

 

Tuning the appserver and resource parameters can have the greatest effect on performance of the applications that are well designed.

Design aspects include...

 

Persistence

J2EE applications persist data to relational databases. Most enterprise applications have significant database access. The architecture and performance of the persistence layer is critical

CMP entity persistence provides maximum security, maintenance, portability and performance.

If applications use enterprise beans with no EJB entities, the persistence mechanism usually involves the JDBC API. Optimize SQL statements used within these applications.

Configure the database server to support the optimal performance.

Think about using prepared statements and batching.

Use the facade pattern, which wraps all JDBC functions with a stateless session bean.

See also: Tuning appservers

 

Model-view-controller pattern

One of the standard J2EE programming architectures is the model-view-controller (MVC) architecture, where a call to a controller servlet might include one or more child JavaServer Pages files to construct the view. The MVC pattern is a recommended pattern for application architecture. This pattern requires distinct separation of the view (JSP files 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, ensure that the size of the state data and the time that the state is stored are kept to the smallest possible values. Also, 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 J2EE 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 J2EE programming model that include Web services.

Application designers must consider caching when the application architecture is designed because caching integrates at most levels of the programming 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

J2EE workloads typically consist of two types of operations. You must perform the first type of operation to respond to a system request. You 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 you 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 J2EE Java Message Service (JMS) and message-driven beans (MDB) as well as asynchronous beans that are explained in the Tuning JMS 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.

Additional reference:

IBM WebSphere Developer Technical Journal: The top 10 (more or less) J2EE best practices

Improve performance in your XML applications, Part 2


 

Related tasks


Tuning the application serving environment