Jbpm4的IOC容器

       和Jbpm3一样，Jbpm4实现了自己的IOC容器。以现在的眼光看来，应用程序里一个IOC容器几乎是居家必备的，否则，又要平白多出一坨一坨的工厂类和单态类来。

一、    Jbpm4 IOC容器介绍
IOC容器的目的是管理组件和实现组件之间的解耦。和Spring里的BeanFactory对应，Jbpm4里的接口是Context，具体实现则是WireContext。Context实际在Jbpm4里有更多的含义，它与Environment一起，共同构成了代码运行的运行期环境。在这个环境里可以获取系统的组件，更为重要的是提供了数据库连接（session）和事务（这个稍后会讲）。

先来看看Context接口的核心方法：

      Object get(String key);

  <T> T get(Class<T> type);

 

很明显，提供两种从容器里获取组件的方法，一种是通过name，一种是通过type。

对于IOC容器来说，一般情况下都会提供一种加载的方式，比如从xml文件进行加载、从资源文件进行加载。Jbpm4透过WireParser具备从xml加载的能力。

此外，WireContext通过一个Map缓存初始化后的组件。

二、    Jbpm4 IOC容器实现
容器的实现有五个关键类和接口，分别是：WireParser、Binding、Descriptor、WireDefinition和WireContext。
 

WireParser读取xml文件，同时WireParser会加载一系列的Binding(默认从jbpm.wire.bindins.xml文件读取加载)。

Binding负责根据xml里元素的tag将xml元素转换为对应的Descriptor。

Descriptor负责初始化对象。它们被添加到WireDefinition。

WireDefinition被WireParser返回给WireContext。WireContext创建对象时会访问WireDefinition里的Descriptor，同时将初始化对象的任务委托给Descriptor自身。

需要注意的是：Jbpm4在初始化对象时有着四种策略，分别是：延迟创建和初始化、延迟创建和立刻初始化、立刻创建和延迟初始化、立刻创建和立刻初始化。

立刻创建：在WireContext创建完毕后对象就已经创建。
延迟创建：调用WireContext的get方法获取该对象时才创建该对象。
初始化：一般完成对象属性的注入等操作。

三、    Jbpm4 IOC容器在Jbpm4里的应用
IOC容器在Jbpm4里最重要的作用就是加载Jbpm的总的配置文件（默认是jbpm.cfg.xml），这也是整个Jbpm应用的起点。大概扫一下这个配置文件：

<?xml version="1.0" encoding="UTF-8"?>

<jbpm-configuration xmlns="http://jbpm.org/xsd/cfg">

  <process-engine-context>
 
    <repository-service />
    <repository-cache />
    <execution-service />
    <history-service />
    <management-service />
    <identity-service />
    <task-service />

    <hibernate-configuration>
      <cfg resource="jbpm.hibernate.cfg.xml" />     
    </hibernate-configuration>

    <hibernate-session-factory />
 
  </process-engine-context>

  <transaction-context>
    <repository-session />
    <pvm-db-session />
    <job-db-session />
    <task-db-session />
    <message-session />
    <timer-session />
    <history-session />
  </transaction-context>

</jbpm-configuration>

 

可以看到配置文件被分为了两部分，分别是：process-engine-context和transaction-context。在实际应用中，它们分别对应着两个不同的WireContext:ProcessEngineContext和TransactionConext。ProcessEngineContext覆盖了jbpm4里最重要的服务类，这些类是全局唯一的，当然，ProcessEngineContext也是独此一份。本是同根生，命运各不同。TransactionConext则是在每次openEnvironment时重新创建，因为其包含了数据库连接和事务。

贯穿于整个Jbpm4中，这两个Context被压到Environment里（Environment和线程绑定），在任何需要的地方都能提供一条龙的服务。于是，在很多领域类里，利用这些服务实现充血模型就是很顺理成章的一件事了。

总结: ProcessEngineContext给引擎领域模型提供全局的组件查找；TransactionConext提供数据库相关服务。

评论

11 楼 hvang1988 2009-09-02  

大哥我想在myeclipse6.5中安装jbpm4.0的图形插件，弄了好几天了
网上视频也看了，但是就是安装不上
不管是复制文件，还是link文件都不管用
通过菜单help->software update->manage cofig enable选择的插件，提示feature.xml有错等等，真是没办法了

网上有视频是在eclipse中安装的jbpm4.0，我现在用的是MyEclipse6.5
我现在的情况是在网上下载了一个可以安装的插件，但是生成的文件和jbpm4.0的不同
到底怎么安装，大哥指点啊

10 楼 phoenix.clt 2009-07-14  

supercwg 写道

期待关于JBPM4和Spring集成的教程啊 ...................

      <!--
      <standard-transaction-interceptor />
      -->
      <spring-transaction-interceptor current="true" />

    <!--
    <transaction />
    -->
    <hibernate-session current="true" close="false"/>

在 jbpm.cfg.xml 中把这两个地方改了就可以了，其它不用动。

9 楼 phoenix.clt 2009-07-14  

wubo19842008 写道

hantsy 写道

ronghao 写道

nychen2000 写道

我本人对jbpm4了解的还不是很深入，我仅仅针对jbpm4的设计提几个问题。

在一般情况下，我们的应用已经有了IOC容器，jbpm自己再搞一个，显然叠床架屋，我认为好的设计方案应该是可以集成到现有的容器中去。即使jbpm用在jboss自己的框架里面（seam）我认为再搞一个ioc容器白白增加使用困难。

就Transaction部分，我认为再搞一套也是多余。transaction更加应该融合到整个应用的transaction中去。

实际上jbpm4提供了选择，你可以使用它的IOC容器（当然非常轻量），也可以非常容易的切换到spring里面去，它和spring集成非常的容易，整个组件管理和事务全部托管给spring。

应该可以理解一个中间件需要自己的IOC实现，而非依赖其他。

Spring Modules 项目提供了很多第三方的 spring 集成，包括jbpm，不过用起来不是很爽。

spring modules 貌似停留在对jbpm3.1支持就不再更新了，不过我试过用spring modules配置jbpm3.2的版本都可以使用，不过对jbpm4的支持是肯定不成了。

jbpm4 内置了和 spring 的集成支持， 配置很简单，只需要在 jbpm.cfg.xml 中改两个地方就可以了。

8 楼 nychen2000 2009-05-17  

哈哈，LZ，我要和你打擂台了。

我写了一篇帖子“Fire workflow的IOC容器 vs Jbpm4的IOC容器”
http://www.iteye.com/topic/389414

7 楼 supercwg 2009-05-12  

期待关于JBPM4和Spring集成的教程啊 ...................

6 楼 wubo19842008 2009-05-12  

hantsy 写道

ronghao 写道

nychen2000 写道

我本人对jbpm4了解的还不是很深入，我仅仅针对jbpm4的设计提几个问题。

在一般情况下，我们的应用已经有了IOC容器，jbpm自己再搞一个，显然叠床架屋，我认为好的设计方案应该是可以集成到现有的容器中去。即使jbpm用在jboss自己的框架里面（seam）我认为再搞一个ioc容器白白增加使用困难。

就Transaction部分，我认为再搞一套也是多余。transaction更加应该融合到整个应用的transaction中去。

实际上jbpm4提供了选择，你可以使用它的IOC容器（当然非常轻量），也可以非常容易的切换到spring里面去，它和spring集成非常的容易，整个组件管理和事务全部托管给spring。

应该可以理解一个中间件需要自己的IOC实现，而非依赖其他。

Spring Modules 项目提供了很多第三方的 spring 集成，包括jbpm，不过用起来不是很爽。

spring modules 貌似停留在对jbpm3.1支持就不再更新了，不过我试过用spring modules配置jbpm3.2的版本都可以使用，不过对jbpm4的支持是肯定不成了。

5 楼 hantsy 2009-05-11  

ronghao 写道

nychen2000 写道

我本人对jbpm4了解的还不是很深入，我仅仅针对jbpm4的设计提几个问题。

在一般情况下，我们的应用已经有了IOC容器，jbpm自己再搞一个，显然叠床架屋，我认为好的设计方案应该是可以集成到现有的容器中去。即使jbpm用在jboss自己的框架里面（seam）我认为再搞一个ioc容器白白增加使用困难。

就Transaction部分，我认为再搞一套也是多余。transaction更加应该融合到整个应用的transaction中去。

实际上jbpm4提供了选择，你可以使用它的IOC容器（当然非常轻量），也可以非常容易的切换到spring里面去，它和spring集成非常的容易，整个组件管理和事务全部托管给spring。

应该可以理解一个中间件需要自己的IOC实现，而非依赖其他。

Spring Modules 项目提供了很多第三方的 spring 集成，包括jbpm，不过用起来不是很爽。

4 楼 hantsy 2009-05-11  

whaosoft 写道

jbpm我还只是听过呢~  听说挺难配置的~

jbpm 3.2 是用过，在Jboss 几乎不需要什么配置，下一个捆绑JBoss 的版本就行了。
在tomcat 也试过，需要少量额外的配置。

3 楼 ronghao 2009-05-11  

nychen2000 写道

我本人对jbpm4了解的还不是很深入，我仅仅针对jbpm4的设计提几个问题。

在一般情况下，我们的应用已经有了IOC容器，jbpm自己再搞一个，显然叠床架屋，我认为好的设计方案应该是可以集成到现有的容器中去。即使jbpm用在jboss自己的框架里面（seam）我认为再搞一个ioc容器白白增加使用困难。

就Transaction部分，我认为再搞一套也是多余。transaction更加应该融合到整个应用的transaction中去。

实际上jbpm4提供了选择，你可以使用它的IOC容器（当然非常轻量），也可以非常容易的切换到spring里面去，它和spring集成非常的容易，整个组件管理和事务全部托管给spring。

应该可以理解一个中间件需要自己的IOC实现，而非依赖其他。

2 楼 nychen2000 2009-05-11  

我本人对jbpm4了解的还不是很深入，我仅仅针对jbpm4的设计提几个问题。

在一般情况下，我们的应用已经有了IOC容器，jbpm自己再搞一个，显然叠床架屋，我认为好的设计方案应该是可以集成到现有的容器中去。即使jbpm用在jboss自己的框架里面（seam）我认为再搞一个ioc容器白白增加使用困难。

就Transaction部分，我认为再搞一套也是多余。transaction更加应该融合到整个应用的transaction中去。

1 楼 whaosoft 2009-05-11  

jbpm我还只是听过呢~  听说挺难配置的~