EJB Layer Architectural Patterns 17 The scalability and fault-tolerance benefits that the Message Facade pattern has over the Session Facade pattern are significant.In terms of performance,a message-based system will scale better than a clustered session bean approach because message beans pull work rather than have work pushed to them.The pull approach scales better when we cluster boxes together because it makes optimal use of system resources. Developers should evaluate each use case in their designs carefully,asking themselves if the use case is of a synchronous or asynchronous nature.This will be a decisive factor in choosing one pattern over the other. Related Patterns Session Facade
The scalability and fault-tolerance benefits that the Message Façade pattern has over the Session Façade pattern are significant. In terms of performance, a message-based system will scale better than a clustered session bean approach because message beans pull work rather than have work pushed to them. The pull approach scales better when we cluster boxes together because it makes optimal use of system resources. Developers should evaluate each use case in their designs carefully, asking themselves if the use case is of a synchronous or asynchronous nature. This will be a decisive factor in choosing one pattern over the other. Related Patterns Session Façade EJB Layer Architectural Patterns 17
Chapter One EJB Command An EJB client needs to execute business logic in order to complete a use case. How can a developer implement a use case's business logic in a lightweight manner,decoupling the client from EJB and executing the use case in one transaction and one network call? 米米米 A critical architectural decision when designing an EJB system is where to put the business logic.The business logic of a use case is the logic that either delegates to the appropriate method on your domain modelor xecutes logi that operates across multiple other entity beans and/or session beans(work- flow logic). Placing business logic on the client(servlets,applets,and so on)has serious negative consequences,affecting performance and maintainability,as explained in the Session Facade Pattern.The ese problems can be corrected by using the Session Facade pattern,which requires that business logic be placed in session bean methods,where each method on a session bean maps to a particular unit of work,or use case.In doing so,the client is shielded from the object model on the server and use cases are executed in one transaction and in one network round trip. The Session Facade pattern itself is a staple in EJB development,but also comes with its own shortcomings.Calling the session facade directly from the client can cause dependencies between the client and the server teams on a large project and complicate client code because of tight coupling to EJB,as discussed in the Business Delegate Pattern.These problems can be alleviated by using business delegates,which add a layer of objects that encapsulate all access in the EJB layer.Business Delegates can help keep client code simple minimizing dependencies between client and server. Then Session Facade pattern in combination with the Business Delegate pattern provides a best practice for writing business logic in a format that decouples the client from the implementation details of the server and allows the execution of use cases in one network call and in one transaction.As always,there are trade-offs Slower development process.Because use case logic(which frequently can change)runs in a ession bean,whenever a use case needs to be changed(that is,to add a parameter to a method or return an extra
EJB Command An EJB client needs to execute business logic in order to complete a use case. How can a developer implement a use case’s business logic in a lightweight manner, decoupling the client from EJB and executing the use case in one transaction and one network call? * * * A critical architectural decision when designing an EJB system is where to put the business logic. The business logic of a use case is the logic that either delegates to the appropriate method on your domain model or executes logic that operates across multiple other entity beans and/or session beans (workflow logic). Placing business logic on the client (servlets, applets, and so on) has serious negative consequences, affecting performance and maintainability, as explained in the Session Façade Pattern. These problems can be corrected by using the Session Façade pattern, which requires that business logic be placed in session bean methods, where each method on a session bean maps to a particular unit of work, or use case. In doing so, the client is shielded from the object model on the server and use cases are executed in one transaction and in one network round trip. The Session Façade pattern itself is a staple in EJB development, but also comes with its own shortcomings. Calling the session façade directly from the client can cause dependencies between the client and the server teams on a large project and complicate client code because of tight coupling to EJB, as discussed in the Business Delegate Pattern. These problems can be alleviated by using business delegates, which add a layer of objects that encapsulate all access in the EJB layer. Business Delegates can help keep client code simple, minimizing dependencies between client and server. Then Session Façade pattern in combination with the Business Delegate pattern provides a best practice for writing business logic in a format that decouples the client from the implementation details of the server and allows the execution of use cases in one network call and in one transaction. As always, there are trade-offs: ■■ Slower development process. Because use case logic (which frequently can change) runs in a session bean, whenever a use case needs to be changed (that is, to add a parameter to a method or return an extra 18 Chapter One
EJB Layer Architectural Patterns 19 attribute),the session bean method that implements that use case may need to be changed.The process of changing a session bean is not trivial-a change often requires editing three different files(interface, bean class,deployment descriptor)as well as redeployment into the EJB server and possible restarting of the server.Additionally,the busi- ness delegate that encapsulates the changed session bean on the client will usually also need to be changed. Division of labor ina large project is more difficult.Dependingon the strategies used to partition work across developers on a project,the session facade is often a bottleneck which different teams or developers will fight over,since it can be the subject of frequent change as a project progresses. Server resources often controlled by just one team in a large corpora- tion.For la arge corporations with established and working sets of deployed EJBs,it can be difficult for teams working on other projects to effect any changes on existing classes. In short,developing with a session facade and business delegates can result in long change-deploy-test round trips,which can become a bottleneck in a large project.The crux of the problem is that the business logic is being placed in a layer of session EJBs,which can be pretty heavyweight to develop with. Therefore: Use the Command pattern to wrap business logic in lightweight command beans that decouple the client from EJB,execute in one network call,and act as a facade for the EJB layer. A command bean is just a plain Java class with gets,sets,and an execute method,as described in the original Command pattern(Gamma,et al.,1995). Applied to EJB,the e Command pattern provides a lightweight solution for achieving the same benefits as the Session Facade and Business Delegate pat- terns:a facade that hides the object model on the EJB layer,execution of a use case in one t ction and one network call,and complete decoupling of the client from EJB.The Command pattern achieves these by providing clients with classes that they interact with locally,but which actually execute within a remote EJB server,transparent to the client. Commands are used to encapsulate individual units of work in an applica- tion.A use case such as placeOrder,transferFunds,and so on,would have its business/workflow logic encapsulated in a special command made just for that use case,as shown in Figure 1.7
attribute), the session bean method that implements that use case may need to be changed. The process of changing a session bean is not trivial—a change often requires editing three different files (interface, bean class, deployment descriptor) as well as redeployment into the EJB server and possible restarting of the server. Additionally, the business delegate that encapsulates the changed session bean on the client will usually also need to be changed. ■■ Division of labor in a large project is more difficult. Depending on the strategies used to partition work across developers on a project, the session façade is often a bottleneck which different teams or developers will fight over, since it can be the subject of frequent change as a project progresses. ■■ Server resources often controlled by just one team in a large corporation. For large corporations with established and working sets of deployed EJBs, it can be difficult for teams working on other projects to effect any changes on existing classes. In short, developing with a session façade and business delegates can result in long change-deploy-test round trips, which can become a bottleneck in a large project. The crux of the problem is that the business logic is being placed in a layer of session EJBs, which can be pretty heavyweight to develop with. Therefore: Use the Command pattern to wrap business logic in lightweight command beans that decouple the client from EJB, execute in one network call, and act as a façade for the EJB layer. A command bean is just a plain Java class with gets, sets, and an execute method, as described in the original Command pattern (Gamma, et al., 1995). Applied to EJB, the Command pattern provides a lightweight solution for achieving the same benefits as the Session Façade and Business Delegate patterns: a façade that hides the object model on the EJB layer, execution of a use case in one transaction and one network call, and complete decoupling of the client from EJB. The Command pattern achieves these by providing clients with classes that they interact with locally, but which actually execute within a remote EJB server, transparent to the client. Commands are used to encapsulate individual units of work in an application. A use case such as placeOrder, transferFunds, and so on, would have its business/workflow logic encapsulated in a special command made just for that use case, as shown in Figure 1.7. EJB Layer Architectural Patterns 19
0 Chapter One TransferFunds withdrawAccountID depositAccountID execute0) getWithdrawAccountBalanceO getDepositAccountBalanceO Figure 1.7 Transfer Funds Command cient view. The client interaction with a command is very simple.Once a client gets a command(either by creating one or getting it from a factory,depending upon implementation),it simply sets attributes onto the command,until the com- mand contains all the data required to execute a use case.At this point the client can call the command's execute method,then simply executes gets on the command until it has retrieved all the data resulting from the execution of the command/use case. When the client executes the command,interesting things happen behind the scenes.Instead of executing locally,the command is actually transferred to a remote EJB server and executed within the EJB server's JVM.All the EJBs called by the command during the execution of its use case thus occurs within the EJB server itself.When the command has completed executing,it is returned to the client,which can then call get methods to retrieve data.By having the command execute within the EJB server,a use case can execute within just one transaction.The implementation mechanics of this behavior will be explained later in the discussion of this pattern. Using the transferFunds example,a client would set the IDs of the account from which to withdraw money,the account to which to deposit money,and the amount to transfer.After calling execute on the transferFunds command, the client can get the final balances of the accounts,as shown in Figure 1.8
Figure 1.7 Transfer Funds Command client view. The client interaction with a command is very simple. Once a client gets a command (either by creating one or getting it from a factory, depending upon implementation), it simply sets attributes onto the command, until the command contains all the data required to execute a use case. At this point the client can call the command’s execute method, then simply executes gets on the command until it has retrieved all the data resulting from the execution of the command/use case. When the client executes the command, interesting things happen behind the scenes. Instead of executing locally, the command is actually transferred to a remote EJB server and executed within the EJB server’s JVM. All the EJBs called by the command during the execution of its use case thus occurs within the EJB server itself. When the command has completed executing, it is returned to the client, which can then call get methods to retrieve data. By having the command execute within the EJB server, a use case can execute within just one transaction. The implementation mechanics of this behavior will be explained later in the discussion of this pattern. Using the transferFunds example, a client would set the IDs of the account from which to withdraw money, the account to which to deposit money, and the amount to transfer. After calling execute on the transferFunds command, the client can get the final balances of the accounts, as shown in Figure 1.8. setTransferAmountID(double) execute() getWithdrawAccountBalance() getDepositAccountBalance() withdrawAccountID depositAccountID transferAmount withdrawAccountBalance depositAccountBalance TransferFunds 20 Chapter One
EJB Layer Architectural Patterns 21 Servlet Transfer Funds Command setDepositAccountID(id2) execute( getWithdrawAccountBalanceO getDepositAccountBalanceO Figure 1.8 Using a Transfer Funds command Probably one of the most comprehensive implementations of the Command pattern is IBM's Command framework,which ships with Websphere,part of IBM's patterns for e-business.There are many different ways to implement the EJB Command pattern,but all of them have the same three elements Command Beans.A simple Java bean class with gets,sets,and an exe- cute method that contains the business logic required to execute a use case.The command beans are the only part of the Command pattern that need to be written by application developers,the other compo- nents explained below are reusable across projects. Client-side routing logic.Usually a framework of classes that is responsible for taking a Command and sending it to the remote EJB server.This routing logic is usually not visible to the client,and is triggered by calling a command's execute method.The routing logic/ framework is a generic set of classes that can be reused across projects
Figure 1.8 Using a Transfer Funds command. Probably one of the most comprehensive implementations of the Command pattern is IBM’s Command framework, which ships with Websphere, part of IBM’s patterns for e-business. There are many different ways to implement the EJB Command pattern, but all of them have the same three elements: ■■ Command Beans. A simple Java bean class with gets, sets, and an execute method that contains the business logic required to execute a use case. The command beans are the only part of the Command pattern that need to be written by application developers, the other components explained below are reusable across projects. ■■ Client-side routing logic. Usually a framework of classes that is responsible for taking a Command and sending it to the remote EJB server. This routing logic is usually not visible to the client, and is triggered by calling a command’s execute method. The routing logic/ framework is a generic set of classes that can be reused across projects. setWithdrawAccountID(idf) Servlet Transfer Funds Command setDepositAccountID(id2) execute() getWithdrawAccountBalance() getDepositAccountBalance() EJB Layer Architectural Patterns 21