Command Pattern

Consider our use case of having a Bank and a user who wants to perform banking opeations like withdraw, deposit, etc. The Session Pattern, allowed us to seperate and remove business logic from the client layer and place it is a "session facade layer" of classes (session beans). However, there is still some coupling between clients and the business logic use-case methods they request to be executed int the Session Facade layer classes (session beans).

 

 

Problems:

  • Still coupling between client and session layers.

A Solution.....the Command Pattern

Have plain classes (not beans) with "get", "set" and "execute" methods that act as "Command classes" and are the interface between a client and any underlying business logic (in the session layer).

Each Command class is used to encapsulate individual units of work in an application.

Example "TransferFunds" command class

 


1) Client creates command object (or gets one)
2) Client sets() attributes of command (data needed in use case).
3) Client calls command object's execute().
4) Now this code is actually run on the server (possibly same server as session and entity beans). This turns into invoking a session layer method (session bean) and in turn accessing data layer (entity beans) or other resources. SEE NOTE BELOW
4) Client calls gets() on command object to retrieve results of the execution of the use case.





 

NOTE: Setting up the infrastructure

How is the "translation" of the execute command to the execution of session beans and underlying entity beans to execute the requested use-case (business logic) performed. There are some frameworks developed that implement the Command Facade. IBM's Command framework (first part of Websphere) is one such product. Here are some of the elements:

  • Command Beans. Java bean (not EJB) class with gets, sets and execute method. Developer creates there own subclass.
  • Client-side Routing Logic. Framework of classes that is provided an takes a Comand object and sends it to the remote EJB server. This is not visible to the client and is triggered by calling a command's execute method. It is a set of generic classes provided that can be reused accross projects. (e.g. CommandExecutor, EJBCommandTarget classes could take a command and send it to a EJB server for consumption).
  • Remote Command Server. A service that simply accepts commands and executes them. A class, CommanServer, that is a stateless session bean that accepts a command as a parameter and executes it locally. This is a provided, generic class and is completely reusable across projects.

Synopsis: Command Facade

Name: Command Facade

Context

A client needs to execute business logic in order to complete a use case.

Problem (forces)

How can a developer implement a use case's business logic in a LIGHTWEIGHT manner, decoupling client from business logic, data layers and executing the use case in one transaction and one network call?

Solution

Use the Command pattern to wrap business logic in a lightweight command classes (beans) that decouple the client from underlying logic classses (session and entity beans), execute in one network call, and act as a facade for the logic layer (session and entity EJBs)

Related Patterns

Session Facade.

 

 

PROBLEM:

Need supporting classes....otherwise, a lot to develop (but, can reuse).