1.2. Architecture

This chapter describes the architecture of the Nablarch application framework.

Warning

The architecture described in this chapter does not apply to JSR352-compliant Batch Application (See Architecture Overview of JSR352-compliant Batch Application for more details).

1.2.1. Main components of the Nablarch application framework

The main components of the Nablarch application framework are as follows:

../../../_images/fw-design.png

1.2.2. Handler queue

A handler queue refers to a queue in which a group of handlers performing traverse processing for requests or responses is defined in a predetermined order.

The handler queue executes the same processes as the chain execution of a servlet filter as shown in the following figure.

../../../_images/handlers.png

The handler mainly performs the following processes.

  • Filtering of requests. (accepts only requests with access permissions, etc.)
  • Conversion of request and response.
  • Acquiring and releasing resources. (acquiring and releasing database connections, etc.)

Tip

Processing of requests and responses, as well as common processing are handled by implementing a handler in the project.

Although there are many cases where common processes are implemented in the parent class of the class that implements business logic, implementing them as a separate handler it is recommended. (to add processes before and after individual handlers, Interceptor it is recommended.)

When implemented by individual handlers
Since the responsibility of individual handlers are clarified, testing is easy and maintainability increases. Since the process for each handler is independent, it is possible to easily add and remove common processes.
When implementing common processes in the parent class
When common processes increase, the parent class expands and has multiple responsibilities. Not only does this increase maintenance costs, but also complicates testing and becomes a hotbed for bugs. Even if the class to be inherited originally is not inherited correctly, detecting failures is difficult because the process can be executed without abnormal termination, depending on the content of the common processes.

Nablarch executes the handlers defined in the handler queue in order from the top for the requests received. If a response for a request is returned in the handler process, the handlers executed for the response so far are executed in the reverse order.

Some handlers do not function normally unless they are configured in a handler queue considering the context. Since the constraints of handlers (context, etc.) are described in the chapters for each handler, see the documentation for each handler when constructing the handler queue.

1.2.2.1. Interceptor

An interceptor is a handler that is dynamically added to the handler queue during execution.

For example, if a process (handler) is added only for a specific request, or to execute a process (handler) by switching the configuration value for each request, an interceptor would be more suitable than a handler.

Tip

Interceptors perform the same process as the interceptors defined in CDI (JSR-346) of Java EE.

Important

The execution order of interceptors must be configured in the configuration file. Note that if not configured, the execution order of interceptors will be depend on JVM.

The execution order of interceptors provided by default in Nablarch must be configured as follows.

  1. nablarch.common.web.token.OnDoubleSubmission
  2. nablarch.common.web.token.UseToken
  3. nablarch.fw.web.interceptor.OnErrors
  4. nablarch.fw.web.interceptor.OnError
  5. nablarch.common.web.interceptor.InjectForm

See nablarch.fw.Interceptor.Factory for details on configuring the execution order of interceptors.

1.2.3. Library

A library refers to a group of components that can be called from a handler, such as database access, file access and log output.

Refer to Libraries Provided by Nablarch for the libraries provided by the Nablarch application framework.