Session Facade
An EJB client needs to perform a business logic in order to complete a use case. How can the EJB client execute a business logic in a transaction and a large number of (BULK) network calls? To perform a typical use case, multiple server-side objects (such as session or entity beans) typically need access and possible modifications. The problem is that multiple fine-grained modes of session and entity beans add multiple network calls (and possibly multiple transactions), and leads to code-maintainable code because of data Take the workflow / commercial logic spread between the client. Consider an online banking situation, a servlet accepts the request to transfer deposits from an account to another as a web client. In this scenario (shown in Figure 1.1), a servlet must check to ensure that the user is authorized, remove the deposit from a bank account Entity Bean, and store it into another bank account Entity Bean. When performing an Entity Bean's Home and Remote Interface, this method will not be scalable when heavy load is executed, because the entire situation requires at least 6 network calls: 3 find the right Entity Bean, there are three actual Transfer deposit. Also, because Entity Bean is a transactional organism, each of each to the entity requires a separate server-side transaction, which needs to be synchronized with the remote entity through the data storage and maintenance of the application server. Worse is that this method cannot guarantee the safety of the customer's money. If you have a mistake, the customer's money will have been removed, and his money will be lost. User authorization check, take money, and completely separated the money, and if the money fails, the money will not roll back, the result is a non-contiguous state. The problem here is that when the method of the Entity bean is called directly, each method call is a separate working unit and is a separate transaction. A solution is to add additional logic in our Entity Bean to complete a number of operations in a separate customer call. This solution introduces maintenance issues because our Entity Bean layer will not be applied to many different ways. If we add application logic to our Entity Bean while each time you need to enhance our Entity Bean, our EntityBean will soon become bloated and difficult to understand, maintain and reuse. We are effectively integrated our application logic (verbs) and our persistence logic (nouns), but this is a poor application design. Another method is to divide a polymerization, through JTA's big transaction for our client. This will work under an "all or no" (all-or-nothing) of the method to call the method of each Entity Bean. If the money fails, then the money will be rolled back (roll back) and the user's money will become safe. However, this improved solution also has a lot of disadvantages: 1. High network overhead. We will have 6 network calls to reduce performance. (Unless we use local interface). 2. Poor concurrency. This transaction will last for a long time if the client is far from the server (such as an Applet or Application and remote EJB system interaction, may even pass through the Internet or a firewall). This will result in excess locking, increase the possibility of conflict and deadlock, and reduce the concurrency of other clients access the same Entity Bean instance. 3. High coupling. Our clients write directly to an Entity Bean API, which will make the client and the Entity bean together. If the Entity Bean layer needs to change in the future, we must also change the client. 4. Differential reuse. The business logic of the use case for executing the "Transfer deposit" is directly embedded to the client.
Then it will be valid in the client. Other types of clients (Java Application, Applet, Servlet, etc.) cannot reuse this business logic. This is a difference in applying logic and business logic together. 5. Different maintenanceability. JTA's use leads to completing the middleware logic and application logic of the transaction together. Through the declarative (Declarative) transaction, it will be cleaner, so we can screw (Tweak) and tune our middleware and will not affect our business rules. 6. Different development roles separation. A common practice in large projects is separated from the development tasks of the layer logic programmer (such as Serlet and JSP developers) and business logic / middleware (EJB developers). If the business logic and the client / represent layer are encoded, a clear role is not possible. Business logic and representing the logical programmer will step on their respective veins, if the same is denoted by layer programming. Our discussion conclusions are the abstraction of a server-side as an intermediary and buffer of Entity Beans. Session bean is designed for this. Therefore: The Entity Bean layer is encapsulated with a Session Bean layer called Session Facade. The client should only access SessionBean and cannot access the Entity Bean. The Session Facade mode applies the benefits of traditional FACADE patterns to EJB, by fully hiding the object model on the server, by using the Session Bean layer as the client's alone access point. Figure 1.2 depicts the architecture to be improved by this method. The Session Facade mode also passes the benefits of completing this use case's business and workflow logic by executing the execution of the enhanced use case of a network call and provides a clean layer. Session Facade is usually implemented as a stateless session bean. (Although this mode can be implemented with a status session bean.) In order to depict the benefits of this paradigm work and this Paradigm, let us use our previous example. The business logic of the use case we use to transfer deposits will now be replaced in a session bean, which is a method called TransferFunds (Userpk, Accountpk, Accountpk, Amount). The Bank Teller session bean is therefore completed a large number of operations for the Users and Bank accounts, as shown in Figure 1.3. Because Bank Teller Session beans coexist, it should be communicated with the EntityBean by Hard-Coded and EntityBean, so the network overhead that needs to be executed is reduced to a call (from the client to the call of Bank Teller) . Similarly, all updates to the Entity Bean layer should be done in the transaction initiated by Bank Teller, defined in its deployment discriptor, almost always, with TX_Required settings. This effectively wraps the entire use case with one thing to ensure that all the updates to Entity Beans are completed in the transactions initiated by the Bank Teller's TransferFunds method. The Session Facade mode is the most basic EJB mode in today's use (this is why it is the first mode of this book). It not only provides performance benefits, but also recommended the standard architecture of your J2EE app for EJB system, the client, and the server are separated by a session bean layer, and this session bean is mapped (and includes business logic) ) All applications in all applications. Further use Bank Teller examples, in Bank applications, more use cases than the transfer deposits. Using the Session Facade mode, the session bean will be created to group usage to make similar functions in a bean.
So we can add additional assistance (Ancillary) to Bank Teller (such as withdrawfunds, depositfunds, getBalance ()). In addition, in Banking applications, the use cases of different purposes can also be packet into a session bean. For example, each bank has a deposit department (Loans Department). The use case of the operation of the modeling deposit department is not related to the use case of the Bank Teller. Therefore, they make points into a LoanService session bean. Similarly, a Banking application will also need a session bean to encapsulate and investment (investment). Using the sessionFacade mode, this BAKING application architecture layout will be as shown in Figure 1.4. The session facade mode works so good, so it is often easily abused. I can usually find the items that SessionFacade misuse: 1. Create a session bean giant class (GOD-Class). Often developers put all the usage in the system in a session bean. This leads to bloated sessionBeans and reduces development of productivity because all developers need this class. The session bean should be divided into the associated examples of the group group (House Groupings). 2. Place the domain (Domain) logic in the session bean. A well-designed OO domain model should include business / use case logic in your application (Fowler, 2001). Most Session Facade methods should be just an agent (delegate) suitable Entity Bean unless the case contains a workflow logic that needs to be across different beans and is not directly connected. 3. Repeat of business logic across Facade. As the project grows, often the session bean method contains duplicate code, such as performing logic to checkcredithistory, may be part of any number of workflows. This solution is to add a service layer (as a session bean or a normal Java class) to encapsulate this reusable, use-case-independent, business logic. This service layer is hidden on the client. It is useful when the volume of the project becomes larger, using conventional reconstruction sessions (repeating logic discovery and extracted). The following is the benefits of the Session Facade mode: 1. Low network overhead. When the session bean layer adds a layer to call, the client can now transfer deposits only in a network call instead of 6 network calls. On the server, the session bean and the Entity Bean are called through localInterface so that no network overhead is caused. Even if the Entity Bean is only used to make Remote Interface, most application servers will optimize communication between Collocated EJBs. 2. Clean and strict commercial logic and the separation between layers. By using Session Facade, you need to perform logic of business logic, completely packaged after the method of session beans. The EJB client does not need to care about the story of the layer, and for a unit's work is not required to perform more than one method. This strictly separates business logic from representing logic. 3. Transaction integration. Our session bean encapsulates all logic to complete bank transfer in a transaction. SessionBean is therefore a matter of Facade, locating the server, and keeps them short. The transaction is also improved in the session bean method, which is configurable by deployment descriptor. 4. Low coupling. The request between the client and the Entity bean is buffered by the session bean.
