JBoss jBPM项目的leader Tom Baeyens的想法，很有启发 这段时间，笔者一直在学习和分析jBPM的源代码，跟着Tom的思绪感悟了一把牛人的设计风格。同时，自己也在思考一个问题，jBPM到底是什么？ 框架？类库？我们先来看看框架和类库的概念吧！框架一般来说是满足某种领域需求的半成品，一般都提供了扩展点给用户定制开发自己的需求代码，所以从宏观上 来说，是有框架来调用用户所提供的定制code。而类库则不同，caller调用者主要是用户代码，类库通过其所提供的API来暴露出其功能性接口，以便 供用户代码调用，类库代码为callee，被调用者。jBPM作者的将其定位为嵌入式工作流引擎，所以应该是可以看做是类库，此类库主要是将原来散落在各 大系统各个角落的与流程推进路径相关代码集中到工作流引擎处管理。这样jBPM引擎与外部系统就必然存在着千丝万吕的关系。在软件工程上，被称为“紧耦 合”。似乎，搞软件开发的很惧怕这个词，其实也不然。Tom大侠给了一片很言简意赅的blog文章。个人觉得不错，就翻译出来了。

　　此文是Tom在读了InfoQ上的Fred Cummins所写的关于SOA中数据的一片论文后发表的感想，译文如下：

　　应用和功能一般都是在应用的竖井中开发的。有时它们是商业产品提供的现货，有时它们则是定制开发的应用。Fred用如下内容给出了一个有趣的话题。“那些注意力在数据管理的人们已经花了几十年将IT业趋向于采用数据库，他们的理由是紧耦合意味着更好的效率和一致性”。

　　随着集成技术和SOA的日益关注，存在一个普通的误解就是紧耦合不好。对于集成全异的系统来说，确实是正确的。但是，应用竖井内部的紧耦合却又是非常好的。

　　一般来说，应用竖井管理数据且包括支持相关的业务流程。这些业务流程可以用一个嵌入式的BPMS实现，当然也可以用编程语言来实现。这些流程可以拥有位置 于ESB之上而实现的流程所有的特性，如BPEL。它们是长时间运行、事务性，且包含人工任务和对总线上服务的调用等等。应用竖井流程与ESB上的流程的 区别只在于它们是应用竖井的一个集成部分，所以它们可以运行于各种不同的运行环境中，如用Java替代了XML/WSDL。这就是jPDL流程语言实现价 值的地方。它是真正的嵌入式可以与任何java环境结合。这就是为什么jPDL可以在基于java的portal、ECM（企业内容管理）系统以及定制 java应用中广泛应用的原因。它真正地适用于紧耦合的java环境。

　　一般来说，每个这样的应用竖井都提供了暴露操作的功能接口。UI用户接口将功能接口暴露给用户，同样的功能接口也能通过一个服务适配器暴露给ESB。

　　ESB的主要目的在于集成全异系统。所以其基于XML/WSDL。如果一个业务流程所需要的事件以及服务调用都发布到ESB上了，跟踪ESB级别流程的整个流程情况才会有意义。对于这种环境，BPEL是一种理想的流程语言。

　　许多人没认识到的是业务流程实现的位置是可以自由摆放的。如果某个给定的流程，其访问性功能和数据与一个应用竖井相关联，将其实现在应用竖井的内部也许更有意义。仍然是这个场景，服务可以被ESB上的其它系统所使用。

　　另一方面，如果流程必须和许多全异系统集成，大多数事件已经发布到ESB上了，且此流程不属于任何一个应用，那么将其实现为ESB上的一个BPEL更容易。

　　我要表达的主要的观点就是：业务流程的实现不应该绑定到集成技术上（比如说ESB）。它们也能放在应用竖井中。

　　这也暴露了在将分析者的业务流程映射为实现级流程时的一个难题。业务分析者在图里画盒子和箭头，他们并不关心这个架构背后为实现流程所提供的环境。所以一个分析型流程还要映射为应用竖井或ESB之上的可执行流程语言。这并不总是一对一的映射。