activiti和设计模式(1)

1. activiti的源码的主要的架构
2. activiti前两层包含的设计模式

从我的工作的经历以及了解到的内容，发送activiti可谓是一个扩展性极好的框架。
一个原因是因为工作流本身的业务复杂性本身要求activiti实现的灵活性，复杂的业务会对整个框架的扩展提出了极高的要求，如果扩展性不够好，复杂的业务可以把二次开发的人员直接逼疯！！

另外的一个原因，在于activiti的主设计人员已经经历了一次设计jbpmn，可能被坑过一次了，所以在第二次设计的时候，更加的完善。

至于为什么选择了从设计模式分析activiti，主要是想提供一个另外的角度，看看能不能学到点大神设计框架的精髓。

activiti的总体的架构，我们可以简单的从一张图上面，大致的了解：

我们首先分析，上面的两层，首先看代码：

public interface EngineServices {

  RepositoryService getRepositoryService();

  RuntimeService getRuntimeService();

  FormService getFormService();

  TaskService getTaskService();

  HistoryService getHistoryService();

  IdentityService getIdentityService();

  ManagementService getManagementService();

  DynamicBpmnService getDynamicBpmnService();

  ProcessEngineConfiguration getProcessEngineConfiguration();
}

我们可以从EngineServer得到各个服务的，官网上面具体的调用的案例也证明了这一点，例如启动一个流程的代码：

RuntimeService runtimeService = processEngine.getRuntimeService();
ProcessInstance processInstance = runtimeService.startProcessInstanceByKey("vacationRequest", variables);

我们可以明显的看出来，这个就是一个封装，针对引擎提供各个功能的分模块的封装，从接口的代码可以看出来分为了：
针对资源的RepositoryService
实时运行的RuntimeService
表单的FormService
任务的TaskService
历史的HistoryService
。。。。。

这个就是设计模式中的： Facade Pattern

The facade pattern (also spelled façade) is a software design pattern commonly used with object-oriented programming. The name is an analogy to an architectural façade.

A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can

make a software library easier to use, understand and test, since the facade has convenient methods for common tasks, make the library more readable, for the same reason, reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system, wrap a poorly designed collection of APIs with a single well-designed API.

按照GOF的说法，Facade模式的意图是：为了子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

其实activi在组织API的时候，采用了两次的Facade Pattern，第一次把各个功能归类，形成一个个的服务，例如在RepositoryService中包含了：

  DeploymentBuilder createDeployment();
  void deleteDeployment(String deploymentId);
  void deleteDeploymentCascade(String deploymentId);
  void deleteDeployment(String deploymentId, boolean cascade);
  void setDeploymentCategory(String deploymentId, String category);
  List<String> getDeploymentResourceNames(String deploymentId);
  InputStream getResourceAsStream(String deploymentId, String resourceName);    
  。。。。。。

针对流程定义的部署，查找删除等等操作，这样我们关于资源，或者流程定义的操作，就直接到RepositoryService中查找即可，这个是第一次的封装，也是第一次的Facade Pattern。

然后activiti 把归类好的服务，又进行了一次封装，统一归类到了EngineService，这样我们调用API的入口，就有了统一的入口，更加的方便快捷了，而且也为后面的spring的注入，提供了良好的基础。

采用Facade Pattern 二次归类是一种非常常见的归类API的方法。由于API过于繁杂，进行归类，在统一的一个类中进行展示，这样调用方在调用的时候，只需要根据想调用的功能到得到具体的server，找到具体的功能的API即可，寻找起来比较的方便，而且代码比较的清晰，明了。

• 上一篇 再次出发
• 下一篇 activiti和设计模式(2)