jBPM(19):JbpmContext类构造方法需要什么?

   在前几篇博客(jBPM(十三): 从ObjectFactory到ObjectInfo ,jBPM(十四): 见证一ObjectInfo实例的诞生 ,jBPM(十五)：配置文件到ObjectFactory 和jBPM(十六): 记录JbpmContext实例的诞生 )中,我们梳理了jBPM配置文件解析及配置信息在Java的表示,也以例子方式见证了一个ObjectInfo的应用,即JbpmContext实例的诞生.

    有了前面的认识, 接下来的几篇中,我们将以JbpmContext类为核心来展开对jBPM的梳理.

    在jBPM(十六): 记录JbpmContext实例的诞生 中我们见证了以反射方式生成的jbpmContext实例, 那么在创建一个JbpmContext实例时都用到了些什么? 也即JbpmContext构造方法需要什么样的参数.

    那么这些参数都是些什么? 又都是从哪来的? 看构造方法(JbpmContext只有一个构造方法),它是这样声明的:
        JbpmContext(Services services, ObjectFactory objectFactory)
用 到了Services和ObjectFactory. 从前面的分析得知,ObjectFactory代表了整个配置文件信息,那么Services呢? 我们可以从JbpmContext的诞生地JbpmContextInfo类里的方法createObject找到答案: new Services(serviceFactories, serviceNames, saveOperations). 再接着问: 构造一个Services所需的三个参数是什么意思? 它们从哪来?

    结合JbpmContextInfo的构造方法和前面对jBPM配置文件的解析,我们不能得出这样的结论:
        1, serviceFactories对应着<jbpm-context>标签下的几个service元素. 其间的转化详见JbpmContextInfo构造方法对<jbpm-context>标签的解析.
        2, saveOperations? default.jbpm.cfg.xml配置文件中没有相关信息, 这是怎么回事? 结合Services构造方法中对saveOperations的处理,我们发现jBPM对saveOperations的默认支持是 SaveOperation接口的四个实现类:CheckUnpersistableVariablesOperation, HibernateSaveOperation,SaveLogsOperation,CascadeSaveOperation). 这里有一个注意点: 在利用jbpm.cfg.xml配置jBPM时,若另加SaveOperation的实现类, 最好把默认的四个也给加上, 否则新加的实现类在配置时会覆盖掉jBPM内置的.
        3, serviceNames没什么可说的, 它是记录了service元素的name属性. 在Services内部,serviceNames也只是用来代替Map.Entry对Map遍历.
------------------
另:
1,  jBPM对配置文件的解析没用到schema, 若有问题就直接抛出异常. 这样就要写jbpm.cfg.xml时,小心, 因IDE没有对其校验. 当然这个解析过程也给我们展示了如何解析XML文件.
2, 与相对的SaveOperation接口(及其实现类)都是什么? 它们是干啥的? 这个问题,先记在这,日后再详细讨论.