EJB Command An EJB Client In order to complete a use case, you need to perform business logic. How to make a developer implement a use case business logic with a lightweight attitude, make the client and EJB decouple and use a transaction and a network call execution case? An important architectural decision when designing the EJB system is where business logic is placed? A use case business logic is a suitable method representing your domain model or executes logic (workflow logic) across multiple other Entity Beans and / or Session Beans. Put your business logic to the client (servlet, applet, etc.) has a serious negative effect, affect performance and maintainability, as explained by Session Facade mode. The problem can be corrected using the Session Facade mode, and the business logic needs to be placed in the session bean, and each method of the session bean is mapped to a specific work unit, or use case. In this way, the client is masked from the object model from the server side and performs the use case in a transaction and a network call. Session Facade model is the key to EJB development, but there is also its own shortcomings. Calling SESSION FACADE directly from the client to lead the dependence between the client and the server (in a large project and complex client code) because of the tight coupling of EJB, as discussed by Business Delegate mode. These issues can be solved with Business Delegate to add an object layer that encapsulates all access to the EJB layer. Business delegate can help client code, so that the dependence between the client and the server is less dependent. The SESSION FACADE mode and the Business Delegate mode are then provided together to decouple the client from the server-side implementation detail and allow the best practices to write business logic in a network call, and a format that performs the use case in a transaction. As usual, there is trade-off: 1. Slow development process. Since the use case logic (often changed) runs in a session bean, an exemplary needs to be changed (that is, adding a parameter to a method or returning an additional attribute), implementing the session bean method of that use case may need to be modified. The process of changing a session bean is not negligible - a change typically requires 3 different files (interface, bean class, deployment descriptor) and retransciting the EJB Server and possible reconciliation servers. Additional, Session delegate in the client will also need to be modified. 2. The labor division of labor in large projects will be more difficult. Depending on the policy across developers allocation work, Session Facade is a bottleneck that leads to different groups or developers to fight each other because it will be the subject of regular changes as project progresses. 3. Server resources in a large company are often controlled by a group. It is difficult for a large company with established and work-published EJB collection, it is difficult for other projects to impover and change their existing classes. Simply put, use Session Facade and Business Delegate development can lead to long-term changes -> Release-> Trip, which will become a bottleneck of large projects. The key to the problem is that commercial logic is placed in a session bean layer, which is almost heavyweight. In summary: Using the Command mode to encapsulate business logic to a lightweight Command Bean, allow the client to decouple from the EJB, execute in a network call, as a Facade of the EJB layer. A Command Bean is just a normal Java class with GET, SET, and an Execute method, and the same as the original Command mode (Tour Guide (GOF), 1995).
Applying to EJB, Command mode To achieve the same benefits of session facade and business delegate, a lightweight solution is provided: an object model that hides the EJB layer, performs a use case in one thing and a network call to complete the client Facade decoupted from EJB. Command mode reaches this by providing local interactions, but actually executing on a remote EJB server and transparent to clients. Command is used to encapsulate separate work units in your application. For example, the use of PlaceOrder, TransferFunds, and the like will have its business / workflow logic to encapsulate only specific Command for that case, as shown in Figure 1.7. The client interacts with a Command is very simple. Once a client gets a Command (Create one or from a factory, depending on the implementation), it is just a simple to set the property, until the Command contains all the data that needs to perform the use case. At this time, the client can call the Command's Execute method, then simply perform the GET on Command until all Command and the results data of the use case are obtained. When the client executes Command, interesting things happen behind the scenes. Not local execution, Command is actually transmitted to a remote EJB server and executes in the JVM of the EJB server. However, all EJBs called by the Command during the execution case occurred on the EJB server, and one use case can be executed in one thing. The implementation mechanism of this behavior will be explained in this mode. Use the Transfunds example, a client will set the ID of the account that is used to pay, save money, and transfer the amount of money. After calling the Execute of Transfunds Command, the client will get the balance of the last account, as shown in Figure 1.8. One of the most complete implements of the Command mode is the IBM's Command Framework, and the WebSphere will appear together, which is part of the IBM as an e-commerce. There are many ways to implement EJB Command mode, but they have three elements: 1.command bean. A simple Java Bean with a GET, SET, and an Execute method that requires a business logic that needs to perform a use case. Command bean is the only part of the COMMAND mode that the application developer needs to be written, and other components explained below can be multiplexed across engineering. 2. Client routing logic. Usually responsible for executing commands (Command) and send it to a class of a class of remote EJB servers. This routing logic usually is not visible to the client, triggered by calling the Execute method of Command. Routing Logic / Frame is a collection of ordinary categories that can be reused across engineering. 3. Remote Command Server. Command Server is a simple acceptance command (Commands) and performs their services. Apply to EJB, the Command Server class is a STATELESS session bean that accepts commands (Command) as a parameter and implemented locally. Command Server is also ordinary and fully cross-project. The interaction between the client and the three components is shown in Figure 1.9. In this example, the client calls the ExecuteCommand method on the routing logic component. In the IBM Command Framework, the client only needs to call Command's own Execute, because method calls are actually received by Command's superclass, which is part of the routing logic framework. After the scene, Commandexecutor proxy has an EJB Command target (because it is part of the routing logic, "there is no call to the map 1.9), it is encoded to know EJB and know how to send commands to Command Server Stateless SESSION bean.
By accepting commands (Command), Command Server simply calls Command's Execute method, Command and continue its business logic. The benefits of the Command mode are as follows: 1. It is convenient for RAD because of a lightweight development / distribution process. Write a use case as a COMMAND bean compared to a session bean approach to a relatively easier and fast distribution and testing. Regular changes can be made on a normal Java class, rather than a complete EJB. 2. Separate business logic from representing logic. Command's commercial logic within Command as a Facade of the object model on the Command, only exposes a simple Command interface to let clients. This separation allows clients and servers to evolve. 3. The mandatory example is executed in a separate Round TRIP. Because Command actually executes on the EJB server, only a network call (and a transaction) is required to complete a complex use case. 4. Make the client to decouple from EJB. The client is a complete detail detail from the server - all they can see is a Command bean, and the Command Bean looks like a local class. 5. Command (Command) can be executed local or dummy data. Empty or virtual commands (Command) can be created before the project is started, allowing a layer developer to write, compile, and test their code for business logic and EJB groups. Many aspects of Command mode sound like an ultimate solution, combined with the benefits of Session Facade and Business Delegate, and a lightweight basis. , However, benefits and usually balanced by important trade-off: 1. Very crude particle size transaction control. Because Command is just a normal Java Bean, there is no automatic tag a Command to go to a specific transaction setting or the approach to the ISOLATION level, and you can use the Session Bean method. Command can only be run under transaction settings of the Command Server in their COMMAND SERVER. The result is to distribute multiple Command Server Session Beans with different JNDI names and transaction settings (configured in Deployment Descriptor). Routing logic components need to be configured to send specific commands (Command) to Command Server. That is to say, a way to send read-only Command to the session bean without transaction, however, the update command can run with TX_Required and sequentially, and can be run under Command Server. 2.Command is stateless. The Command object cannot store any status to the session bean executing it. It is impossible to use the Command mode in the EJB layer storage status. 3. Clummed error handling. Because the Command frame is generic, only CommandException from Command can be thrown. This means that the application is abnormal, such as NomoneyAccountexception, needs to be captured and encapsulated with the CommandException. The client then needs to go to the Command object for a specific exception perspective. Because the exception is not explicitly claimed, the client lost the benefits of the compile period checking exception handling. 4.Command will become unaffected in large projects. With thousands of Command, large projects exploded, many Command has a repeated part of the business logic, especially when different project team uses the same backend domain model. This makes it difficult to maintain the commercial logic layer compared to the session facade (a good packet to the number of SESSION beans) that implements the use case in the session bean method. This kind of surge will be a serious problem of large projects. 5.Command Server EJB-JAR is closely coupled to Command Beans and other EJBs.
