和Jbpm3一样，Jbpm4实现了自己的IOC容器。以现在的眼光看来，应用程序里 一个IOC容器几乎是居家必备的，否则，又要平白多出一坨一坨的工厂类和单态 类来。
一、Jbpm4 IOC容器介绍
IOC容器的目的是管理组件和实现组件之间的解耦。和Spring里的 BeanFacTory对应，Jbpm4里的接口是Context，具体实现则是WireContext。 Context实际在Jbpm4里有更多的含义，它与Environment一起，共同构成了代码 运行的运行期环境。在这个环境里可以获取系统的组件，更为重要的是提供了数 据库连接（session）和事务（这个稍后会讲）。
先来看看Context接口的核心方法：
Java代码
Object get(String key); T> T get(Class<T> type); 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代码
<?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> <?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提供数据库相关服务。
一个人负心，或许是因为他的记忆力不好。
