Webx-CommandDispatcher distribution service

I. Introduction

Command pattern is a set of Framework centered on Use Case Based on Spring Framework. It combines several classic JavaEE design patterns to enable application developers to focus more on business logic when implementing Use cases.

Structure:

The entire business layer is configured using the Spring framework. Spring is a lightweight IoC framework. With Spring, the business logic can be minimized.

Flowchart of calling the business logic layer at the presentation layer:

II. Specific Process

1. Client

How to call a business logic? The caller of the business logic (usually the presentation layer) does not have to worry about how the business logic is implemented. For the client, it can only see command dispatcher, for example:
A CommandDispatcher is used to delegate services to the Web layer components that need to call business operations. However, the commandDispatcher is a Bean, it exists in Spring containers (refer to the web layer module ioc ). The disadvantage is that the web layer is infiltrated by command and coupled with business implementation to a certain extent.

Steps:

A) create a Command and fill in the parameters required by the business logic.
B) Pass the Command object to CommandDispatcher to complete the call of the business logic.
C) if necessary, return results of the business logic can be obtained.

// Step 1. assemble a command. // The command name is "userCommand" and "userCommand" contains many sub-commands related to users. // while "registerUser" is a sub-command. (Sub-Command parameters are optional) command Command = new CommandSupport ("userCommand", "registerUser"); commandName. getParameters (). put ("name", "michael"); commandName. getParameters (). put ("password", "helloworld"); commandName. getParameters (). put ("email", "michael@hello.world"); // Step 2. result = getdispatcher(cmd.exe cute (command); // Step 3. process the returned result if (result. isSuccess () {User user User = (User) result. getModels (). ge T ("user"); // generally, this type of operation returns the sequence ID created by the database. Int id = user. getId ();...} else {ResultCode errorCode = result. getResultCode (); if (errorCode = UserResultCode. USER_ALREADY_EXISTS ){...}...}

2. Server

Server, it does not need to know about the client. What the server needs to do is simply to receive command requests from the system and then execute the corresponding business logic.

Steps:

A) create an ApplicationObject (AO ).
Implements the ApplicationObject interface, but it is recommended to inherit from ApplicationObjectSupport

public class LoginAO extends ApplicationObjectSupport {}

B) Execution

Similar to the action in WebX, AO can automatically call the corresponding method according to the event parameter in command, for example, new CommandSupport ("loginAO", "login"), as long as the following method is implemented.

public Result doLogin() {    Account user   = userManager.login(userId, password);    Result  result = new ResultSupport();    if (user == null) {        result.setSuccess(false);        result.setResultCode(                LoginResultCode.INVALID_USER_OR_PASSWORD);    } else {        result.setDefaultModel("user", user);    }    return result;}

If the event parameter is not provided or the event does not match, the default doPerform () method will be executed.

3. CommandDispatcher implementation

CommandDispatcher is a "distributor ". Its function is to find and execute the corresponding business logic object based on the command name. Each business logic object corresponds to one or more related use cases. For example, in the user management system, user creation, deletion, modification, and other operations can be considered as a use case, therefore, we can write a business logic object-"UserManagementAO"-to process this use case. "AO" is the abbreviation of "ApplicationObject". Each AO must implement the ApplicationObject interface.

CommandDispatcher has multiple implementations to meet multiple needs:

Serial number	CommandDispatcher implementation	Description
1.	Stateless Session Bean (CommandDispatcherBean)	Use Stateless Session Bean to distribute Command. This implementation allows distributed business logic calls.
2.	Message-driven Bean (CommandDispatcherClient)	Message-driven Bean is used to distribute the Command and JMS is used to send the Command request. This implementation allows asynchronous business logic calls.
3.	Plain Javabean (CommandDispatcherLogic)	Distribute Command by using common Javabean. This implementation is very suitable for calling commercial logic in a non-EJB environment.
4.	NOOP (CommandDispatcherNoop)	A distributor that does not do anything. This implementation is very suitable for debugging programs in the program development stage. Or when the business logic is not yet developed, the caller can use the distributor to "call" the business logic so that the caller's code can be smoothly developed.
5.	Selector (CommandDispatcherSelector)	The dispatcher can automatically select other CommandDispatcher Based on the Command content. In this way, we can more easily control the CommandDispatcher behavior. For example, the caller can convert the processing of a Command to asynchronous processing using Message-driven bean without knowing it completely.

Although there are so many CommandDispatcher implementations, the presentation layer does not need to understand these details at all. All CommandDispatcher configurations are made through spring.

4. Summary

Command Pattern is based on the request-response mode. The client creates a command, and the server responds to the command and returns the result to the client-similar to the WEB layer mode. The client and server are connected through command dispatcher.
What are the advantages of this model?
The biggest benefit is that the client and server are completely separated. Neither Web-tier nor Biz-tier need to understand the details of command distribution-these details are transparent to the code.
Secondly, all CommandDispatcher is configured through spring, so it is easy to create a new CommandDispatcher mode. Currently, synchronous and asynchronous operations are supported.
So what are the disadvantages of this model? Any design pattern is applicable and unfavorable. Command Pattern is no exception.
The biggest disadvantage of this mode is that there is no uniform method to know the number and type of parameters required by the business logic layer. It is also difficult to know the number and type of returned values. This will increase the Client/Server programmer communication costs.