In J2EE project design and application, the appearance of the session is a common mode. It makes it more distributed, and the code coupling is reduced, and network traffic is reduced. He overall he gave the client's coarse-grained access to protect the server's code. Some people say that the conventional appearance mode is a must-have design plan, which is not exaggerated. In a successful distributed application, it is a bit unimaginable.
The appearance of the session is different from the front-end controller, and he has its own application area to solve different problems. When the client is connected to the server, especially when interacting with EJB, the appearance of the session plays an important role. The appearance of the session can reduce the role of the client and server-side coupling, and of course, the degree of decrease depends on the implementation of the appearance of the session. With the value of the value, use can reduce coupling, and use it to use the XML to be used to unpack the coupling.
Let's take a simple example to see how the session appearance mode reflects these advantages. Consider an example of customer transfer in a banking system. Imagine such a scenario: Customers make remote operations in ATM to their accounts, transfer their money from savings account to often use accounts. In the application, the system must first verify the identity of the customer, then remove the money to turn from the savings account, and then use this part of the money. We use three EJBs to represent this check-in account (Customer EJB), and the storage account operation (SavingAccount EJB) and the operating process that the client should comply with the following sequence diagram:
To understand the above operational processes, first understand the working principle of EJB. Essentially EJB is a framework structure, so understanding the working principle, it is to understand the operational mechanism of this framework. There are three parts in EJB, which are used for clients with server-side. For example, Customer EJBs that provide validation operations, he has a local interface, remote interface and server method implementation class three parts. The recommended naming scheme is that the local interface is named CustomerHome. The remote interface is named Customer. The server method implements the class to name Customerbean. In the implementation, because the test itself is an abstract behavior, the user name, password, account A series of information such as an account itself is independent of a specific customer. So he only needs to be a stateless ejb, not related to the specific user. In this way, he can fully have multiple instance objects in the container pool, implement parallel pairs of verification of various users, and improve access speed. The storage account EJB (SavingAccount EJB) and the current account EJB (CheckingAccount EJB) are not, the naming rule is similar, and they are also stateless session beans, the reason is similar.
The client first get the user authentication, then you can cancel the account on the savings account, and you can dump the current account again. We have implemented using EJBs. The client interacts with three EJBs in turn. We choose CheckingAccound EJB to do research objects to see how clients interact with this bean, from EJB to the client, we can see the principle of EJB. The client calls local method CheckingAccountHome gains reference to EJB, and the Home interface will have one or more Creat () methods. This interface is interact with CheckingAccountBean and has an ejbcreatea () method in the implementation. This interaction is achieved by a container. The Creat () method returns a remote interface. In this case, CheckingAccount has, the client gets a reference to the remote interface, and there will be some methods in the remote interface. The client implements business logic for remote operations through these methods. The implementation of these methods must be implemented in CheckingAccountBean. The above process We have seen that the client has to interact with the remote interaction before obtaining the implementation method. In the nucleus, it is also necessary to obtain the correct authentication twice, and the operation of the savings account is the same. After understanding the operating process and the EJB principle, we analyze the above-mentioned client calling business logic at least three defects: First, there is no scalability.
Second, this method does not have a guarantee.
Again, the business logic is directly exposed, and the security is worrying.
There is no scalability to say that customers have to make a call for each remote EJB. Above we see a simple transfer business logic requires the client directly to interact with the server six times. If there are other logic or add a business method, the client has to re-add multiple calls. If there is a different approach to different clients, the method call is even more busy. Poor telescopic performance is reflected here.
During the entire transfer process, it is actually just a transaction process, either transder, either unsuccessful. So you must guarantee Saving Account and CheckingAccount in a transaction. However, in the above processing, we see this guarantee is required to be on the client. In order to ensure the consistency of the two accounts, the client must put the call package to the two EJBs in a transaction. Due to the unreliability of the network, delay and errors are likely to occur at this time, the time of transaction is naturally long, and the possibility of errors naturally increases, and the deadlock may cause, and consistency is difficult to guarantee.
Not noted that the client is called to the remote method, discovery is directly called. Obviously, this method is directly exposed to the client any modes to directly lead to the server side without privacy, obviously the security process of the method call is not allowed. Of course, when checking the EJB method call permission, the EJB specification also defines the corresponding roles and security controls, although this method of pushing security issues to the deployment phase is allowed. But this is different from the web application, and it is also necessary to seek more secure measures to solve the problem for very strong applications.
In order to overcome these defects, we can introduce the concept of firewall - using the session façade mode plus a session bean between the client and the business method, so that the client and remote interaction have a "firewall", you can get all The benefits of the firewall, the sequence diagram is as follows:
Under the current network, the network is still a bottleneck relative to the computer. After using the Session Façade mode, we reduce the six or more network connections to one. Access to business methods becomes local access. Under the conditions of the computer and the container, the processing speed is naturally better than the network. Different customers are the same one-time call, and the scalability scalability is shown. More importantly, session façade bean packs all methods of business logic, focus on controlling transactions; business methods are not directly exposed to clients, consistency and security have guaranteed - the strict requirements of transaction processing The server-side container guarantees that there is no doubt that reliability is greatly enhanced. In this bank system application, we use the method Transfer () to pass data between the client and EJB, of course, through the session façade, how to pass, will be discussed in the example of the SESSION FAçade mode extension. In summary, we don't have to call each time a fine-grained approach, you can pass all parameters to the server, complex business logic methods, also processed to the client to hide the customer is not visible. Although complexity is pushed into the session façade bean, the logic is more independent and coupled is smaller.
In actual applications, we often use value object patterns to replace the Transfer () method. Value objects are passed between the client and the EJB layer and exchange data. A value object is actually a serialized class packaged for business data. Below is the value object of this bank system instead of the Transfer () method: AccountTransferValueObject.
public class AccountTransferValueObject implements java.io.Serializable {private String customerPK; private String fromAccountPK; private String toAccountPK; private float amount; ... public String getCustomerPK () {return customerPK;} public String getFromAccountPK () {return fromAccountPK;} public String getToAccountPK () {return toAccountPK;} public float getTransferAmount () {return amount;} public void setCustomerPK (String customerPK) {this.customerPK = customerPK;} public void setFromAccountPK (String fromAccountPK) {this.fromAccountPK = fromAccountPK;} public Void settoaccountpk (string toaccountpk) {this.toaccountpk = toaccountpk;} public void settransferamount (float amount) {this.amount = amount;}}
With a value object, the client is packaged in the value object when the data is required, and then send it to the EJB layer via the network, passing the service logic processing through the session facade bean. Similarly when the business logic interacts with the client, the EJB layer creates a value object to package the business method to pass the data that needs to be passed, passed to the client through the session façade bean. to be continued
