jBPM(十一): 从JbpmContextFilter说起

 

    在jBPM(十):webSale的"页面流"介绍 中,我们对webSale做了个简要的介绍,其中并没有涉及到jBPM深层次的代码调用,从这篇开始,我将试着梳理总结研究jBPM的心得.每一 人请求都是先要通过filter的, 这里从webSale要通过的JbpmContextFilter说起.

    原来是误解
        在jBPM(十):webSale的"页面流"介绍 的讨论中,觉得发现了JbpmThreadsServlet的妙用, 现在回过头来再看发现原来是一个误会. 那误解是什么? 为什么会有误解呢? 这两个问题可以从我们熟悉的Spring里ContextLoaderListener说起.   
        我们知道ContextLoaderListener通过其属性contextLoader新建了一个WebApplicationContext, 这样我们就可以通过IoC的方式来get/set那些依赖类了.
        有了上面spring中的认识, 这里看到JbpmThreadsServlet里的JbpmContext jbpmContext = getJbpmConfiguration().createJbpmContext(jbpmContextName)代码,就很"自然"认为 jbpmContext像是Spring的ApplicationContext那样是整个系统的container,而这样 JbpmThreadsServlet虽是一个servlet但它却起了类似于ContextLoaderListener一个listener的作用.

        那破除这个误解的关键点又在什么地方?  就是渐渐发现原来那个JbpmContext是每一次请求(经过JbpmThreadsServlet的请求)都会new一个出来的.  这是怎么发现的? 其中又涉及到哪些奥妙呢?

        所有一切都得从JbpmConfiguration类及其对象的创建说起(因jbpmContext 是由JbpmConfiguration的方法createJbpmContext生成的). 也就是JbpmThreadsServlet类中的getJbpmConfiguration方法.

    JbpmConfiguration类及其对象的创建
        我们先看这个类的实例是怎么创建的. getInstance方法, 我们所熟悉的单例模式. 这里只不过是通过一个Map属性来存储所有可能创建出的实例, 比较说这个方法比传统的单例模式要先进些,也借用前些在看一个看似矛盾的说法: 多单例模式. 
        不管是否用单例模式(或多单例模式),类的构造方法总是要调用的吧. 其实严格来说并不叫单例模式, 只是长的像些, 不过通过getInstance的方式,  JbpmConfiguration自身充当了其自身实例管理的功能.  我们再看这个类的构造方法及其调用.
       代码是这样的:
            ObjectFactory objectFactory = parseObjectFactory(jbpmCfgXmlStream);
            instance = new JbpmConfiguration(objectFactory);
        这样JbpmConfiguration就创建出一个实例来. 注意这里的ObjectFactory接口, 在JbpmContext创建时会重点用到它,这段时间的介绍也基本上是围绕它展开的.

-------------------
    至此, 我们看到了JbpmConfiguration实例的创建, 而JbpmConfiguration是jBPM的起点,属于外围. 在这里, 我想总结下为什么在花专门的时间来研究下jBPM的外围代码. 大致在如下几个理由:

1. 好奇心驱使. 应该说,我是那种看到优秀代码就好奇的人, 只要条件允许总是想看看高手是怎么来设计/实现的. 根据以往的经验来看, 这个好奇心给自己的设计/编码有了不小的提高.
2. 想分清jBPM的外围与内核代码, 以便以后研究核心代码时不再受那些外围代码的迷惑. 现在这样先从外围代码起步,就可以划整为零地各个击破.
   

 

评论

1 楼 Storm1988 2009-04-28  

总结来讲就是说，JbpmConfiguration是用来管理整个工作流引擎的，与工作流引擎里面具体流程关系不大。

同时JbpmConfiguration提供了类似单例模式的方式以获取实例。

不知道总结的对吗？？