Message facade
An EJB client wants to call multiple EJB methods in an environment's usage, and do not require immediate reflection from the server. How can I let the EJB client call multiple session beans in a transaction, don't need to be blocked and waiting for each bean reflection? Especially in large systems, scalability indicate that a use case is separated from the client's separation, and does not require the client waiting for execution. This type of behavior is called asynchronous behavior, allowing clients to interact with the maximum reaction time and user interface (UI), because they don't need to sit down and wait for the use case to start. This method allows large systems to scale because the use case can be queued in a batch and executed, transparent to the user, and the user can move to the next portion of the UI. If most of the use cases of the queuing have begun to develop, the part of the system execution can also be extended and the availability and quality of the client is required through the system upgrade. Consider a simple web-based route registration system, a servlet in this system accepts a request for a particular flight for a user. In this scenario, a servlet must be registered with a route to determine if the seat is available at a flight, and a user is scheduled for a user, as shown in Figure 1.5. In this example, we have a client to perform multiple asynchronous calls to the server in order to perform a use case. Each step of this process requires an isolated network call and blocks the part of the client. This bottleneck is obviously unacceptable in a system like a route. Also, logic reducing the system's maintenanceability and reusability at such a style, and does not provide transaction consistency and separation for the use case. The most common solution is to use the Session Facade mode. With this mode, an application creates a session bean layer that contains business logic filled with commercial use cases. Each Session bean represents a large block of Entity Beans or other server-side resources in a large block call, as shown in Figure 1.3 of the Session Facade mode. Unfortunately, even the entire use case is packaged by the Session Facade method, this method still has the following shortcomings: 1. The reaction time cannot be accepted. Users interacting with a Web site will not wait for several seconds. This use case's execution requires many background processes that extends multiple databases of different route systems. Because the call to the EJB layer is a synchronous call, the client will be blocked until the entire process ends. 2. Unreasonable / non-wrong mechanism. This use case can potentially involve EJB and 3 separate databases distributed in 3 separate EJB servers (one for users, one is a route, one is a flight). If a machine in any of these servers, the entire process will fail, and the user's predetermined request will be lost. Even if the servlet layer is communicating with only one EJB server, the process will fail if the server is behind. Use Session Facade to solve coupling, performance, maintainability, reusability, and consistency, but do not completely solve the problem of reactions and reliability. When a complex and time-consuming predetermined use case is run, the client will still be blocked. If the EJB server or any of its dependencies do not run when the use case is executed, then the use case will fail. Our discussion is that we need a server-side abstraction with a fault-tolerant mechanism, which acts as an intermediary, performs the use case in a call and one thing (protect the client is not affected by the complexity of the server-side object model), no need The client is blocked and waited for use. Message-Driven Beans is specifically designed for this. In summary: Use the Message-Driven Bean to create a fault-tolerant, asynchronous FACADE.
The client should only access the Message-Driven Bean without accessing the entity bean. Using Message-Driven Bean as Facade, the SESSION FACADE mode is enhanced by increasing asynchronous, fault-tolerant mode. When we use Message Facade, the business logic in each of an application maps to its own MDB. Consider the previous example. Our business logic that is scheduled to book a seat at a flight will now be replaced in the reservoSeat MDB onMessage () method. The purpose of this MDB is to encapsulate all the business and workflow logic related to a seat on a flight and perform asynchronously, as shown in Figure 1.6. Here we have a servlet client to create a Java Message Service (JMS) message and passing the required parameters. This servlet constructs a message that accommodates all the required parameters (user's Primary Key, flight number, route primary key) and sends this message to a JMS target that is created for a predetermined seating case. By accepting messages at the right target, the client can freely continue (display the next web page). At this point, the MDB container will try to transfer the message to the next available RESERVESEAT MDB. If all RESERVE-SEAT MDB in the pool is being used when accepted, the JMS server should wait until the next change is available. Execute this use case with Session Facade, a fully used session bean pool will have only one fail point, and the client will only be handled. When an MDB becomes available, the container will execute the onMessage () method. At this point, the RESERVESEAT MDB will linearly pass the process of performing the use case: register the user to the route, check if the seat is available, and set a seat. When consuming a lot of time, end users can surf the site on the site and do their (or her). Message Facade is an important advantage of Session Facade to be guaranteed asynchronous execution. That is, if the transaction fails anything (possibly the route system is lost or other system failure occurs), things will roll back and the JMS message will be put back into the queue. The transaction will try again later and do not need the client's knowledge. This behind-the-scenes also shows a problem. If the use case failed or succeeded, what about the client know? For example, if a seat cannot be predetermined because the aircraft is all scheduled, the client needs to know. In a synchronization model (using session facade), the client will immediately know. In an asynchronous model, the client will no longer wait for the use case to succeed and needs to be woken up with the form of a specific application. The most common solution is email. If the use case is successful or failed, then the system will notify the user with email. Some companies may implement a system as follows: use people to make a call, and so on. If the application requirements are allowed, some applications can use the "pull" model. That is, the end user will be assigned a specific location they can check the status of their request, and the track number (Tracking Number) used by the modern tour guide service. The conclusion here is that when using the Message Facade mode, the developer must design a new way to transfer the results to the client. One disadvantage to using the Message Facade mode is that commercial logic is simultaneously distributed to MDB (for Message Facade) and Session Beans. This may be the most concerned, but it is better to keep commercial logic in an application.
A clever approach to this problem is to implement all the use cases in Session Facade and use the Message Facade agent session facade. This method, all asynchronous, fault-tolerant structures such as MDB are preserved, while maintaining logic is only limited to the session bean layer. The advantages of the Message Facade model include all the advantages listed in the Session Facade mode and add the following advantages: 1. Reflect time / asynchronous communication immediately. When a client passes a JMS message, it will freely process freely without waiting for the server to complete the use case and reflect. A longer, complex use case can therefore be started and the control flow immediately returns to the user. 2. Eliminate a separate point of failure. Using Messaging will ensure that your app continues to work even if the EJB server or other subsystem it rely on. For example, if the database is lost, the MDB transaction will not be completed, and the reservoSeat message will remain in the queue and try again later. If the EJB container is lost, the message will also be stored. If we use a synchronization model such a fault tolerance, it will be impossible. Of course, if your JMS server is not clustered and is lost, it also represents a separate failure point, but at least potentially dangerous number is reduced. However, as a by-product using MDB, Message Facade also has the following disadvantages: 1. MDB has a weak type (dynamic) input parameter. MDB's role is to consume JMS messages, which look like when compiling. This is different from Session / Entity Bean, which increases the Java's built-in-strength type method and the parameters of Remote and Local Interface to capture usual errors. Developers need additional attention to use the appropriate content you need to use to Load a JMS message. A solution to this problem is to encapsulate all data from JMS to a custom data transfer object, and serialize this object to a JMS message. 2. MDB does not have any return values. Since MDB calls are asynchronous, Message Facade cannot be used as a use case that needs to return values after execution. Using Message Facade, on the surface and using Session Facade, all session bean methods in Session Facade simply returns VOID. However, using JMS as a transmission mechanism to return from MDB to message creator to get a reaction, please refer to the book "Mastering Enterprise Java Beans, Second Edition" to see discussions about this mechanism. 3. MDB does not spread abnormal to the client. Unlike Session / Entity Beans, MDB cannot throw out an exception or RemoteException from any them. MDB must thus process all exceptions present in some specific application formats. (That is, if you have any questions, send the user to the user, record errors into a management log, and so on. Message Facade is a very powerful model for building decoupling, highly scalability. A typical EJB system will likely use the combination of Session Facade and Message Facade. Session Facade is a clear selection of "Read" type operations, where the client needs some data from the server, or when the client needs explicit waiting cases. Message facade is a clear update operation selection, where the client does not need to see the update immediately. Message Facade is obvious to the advantages of the scalability and fault tolerance of Session Facade. Contemporary, a message-based system will be more scalable than the cluster's session bean method because MDB "pull"; operation rather than "push" to them.
