ligang1111

      此文是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之上的可执行流程语言。这并不总是一对一的映射。