Explaining the concept of the service-activator pattern

Suppose a client needs to request a business service, which is a process that takes a long time. In this case, the client should not wait in a synchronous way until the end of the process. Instead, there must be a way to make an asynchronous service call that does not block the client or user. This service can then be activated at some point in the future. There may be several reasons for the delay of a process. For example, there may be a database query that consumes a lot of time, or an access to a legacy system that is beyond the control of the current application. The pattern of asynchronously performing the required task is known as the service activator.

So, the service activator pattern is always used when the client needs to call a service asynchronously. This means that the client makes the request and does not wait for the response.

We can imagine some alternative solutions to this problem. One method would be to send the request to a queue, while another service would read the request from this queue and execute the task within it. Alternatively, when the client requests a service, this service could be placed in a database, and there could be a listener or a job that would check the tasks that had not yet been performed. If a task had not yet been performed, it would be executed. 

In fact, the JEE specification gives us very good solutions that are used to implement the service-activator pattern. These solutions are described as follows:

• Java Message Service (JMS)
• EJB asynchronous methods
• Asynchronous events: producers and observers

These three solutions were offered in the given order within the evolution of the JEE specification. We'll look at each of these solutions in more detail in the following sections.