Application design consideration


 

+

Search Tips   |   Advanced Search

 

  1. Persistence
  2. Model-view-controller pattern
  3. Statelessness
  4. Caching
  5. Asynchronous considerations
  6. Third-party libraries

 

Persistence

Java EE applications persist data to relational databases.

For persistence, focus on...

Java EE persistence options...

For apps that use JDBC enterprise beans rather than EJB entity beans...

 

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