Like JBPM3, JBPM4 has achieved its own IOC container. From the perspective of the present, an IOC container in the application is almost a must, otherwise, there will be no more than a lump of factory class and a single State class.
Introduction of JBPM4 IOC container
The purpose of the IOC container is to manage the decoupling between components and implementation components. And spring in the beanfactory corresponding, JBPM4 interface is the context, the implementation is wirecontext. The context actually has more meaning in Jbpm4, together with environment, it forms the runtime environment of code running. In this environment, you can get the components of the system, and more importantly, provide a database connection (session) and transactions (this will be said later).
Let's look at the core approach to the context interface:
Java code
Object get (String key);
T> T Get (class<t> type);
Object get (String key);
<T> T Get (class<t> type);
Obviously, there are two ways to get a component from a container, one through name, and one through type.
For the IOC container, it usually provides a way to load, such as loading from an XML file, loading from a resource file. JBPM4 has the ability to load from XML through Wireparser.
In addition, Wirecontext initializes the component with a map cache.
Ii. implementation of the JBPM4 IOC container
The implementation of the container has five key classes and interfaces, respectively: Wireparser, Binding, descriptor, wiredefinition, and Wirecontext.