?
第一部分:http://www.javaeye.com/topic/838680
部门域是一个 ESB 的基本组成单元，在一定的交易量内，他甚至可以独立的存在于企业中。部门域中的 ESB 可以独立的做水平的扩展，来进行性能的伸缩，而且，这种性能的伸缩在某一个度内应该是相对廉价的。
???????? 在部门域的视角，我们不用关心 ESB 的内部实现，在一般情况下，只有以下四个场景
l? 同步请求服务
l? 异步请求服务
l? 同步提供服务
l? 异步提供服务
域内的系统只需要知道以上四种场景基本上就已经可以了，其他的 ESB 会在内部进行整合。如果是一个旧系统的交易， ESB 也会通过不同的适配器进行整合，这些我们会在 ESB 内部视图进行阐述。
部内域内主要涉及多个应用系统、一个 ESB 两种元素，他们存在着所有的应用系统都要通过 ESB 这个元素来进行交互，他们是一个星型的拓扑结构，这也是为什么在 ESB 的系统中可用性的质量属性会占在第一位的原因。
?
图表 4 ? 1
?
ESB 是核心，这个元素我们将会在 ESB 的内部视图中祥细进行阐述。他在部门域内，它的主要的作用是
l? 传输服务： 必须确保通过企业总线互连的业务流程间的消息的正确交付，传输还包括基于内容的路由功能。
l? 中介：提供位置透明性的服务路由和定位服务；多种消息传递形式；支持广泛使用的传输协议。
l? 多种服务集成方式： 如JCA ，Web 服务，Messaging ，Adaptor 等.
域内应用系统是企业内部信息的实际产生和消费者，当他需要为信息的其他消费者提供服务，或者要消费其他系统的信息时，就会和 ESB 产生关系。
现在的企业大都会和企业外部的系统产生关系，这是不可必免的。我们不应在应用系统内部直接和外部的系统产生关系，这样会耗费更多的时间在安全管理上，而且很多时候这些外系统并不是只有一个应用在使用。在这种情况下不但会增加了单个应用系统的复杂度，而且还会出现一些冗余。我们完全可以能过 ESB 的整合功能，统一的完成这些事，让应用系统更简单。
BPM 系统实际上是应用系统的一部分，把 BPM 独立出来的展示出来，是因为 BPM 在 ESB 架构中占有比较大的地位。在实际的 ESB 应用中，我们可以使用 ESB 内部的各种路由和端点的组合来达来一定的 BPM 的功能要求，但这样实际上会复杂化 ESB 。如果能使用 BPM 来做这个交易的流程的编排，那能减化 ESB 内部的复杂性。
如果应用系统中没有 BPM 这类的应用系统，如果可能的话，我们最好能使在企业域中加入一个 BPM 的组件来获得 BPM 的功能。 ESB 也需要能很好的和 BPM 应用系统进行交互。
在以下的场景中，一次请求实际上会通过两个或再多的场景，之所以会这样，是因为 ESB 会屏蔽 ESB 的请求方和服务方的细结，当系统要和外部系统进行交互时，只应知道 ESB 这个系统。这也是为什么可测试性在 ESB 系统很重要的原因。在 ESB 系统中，整合测试是非常重要的。
在同异步服务提供的场景下，因为交易的请求方只知道 ESB ，或者这时候根本就还没有请求方，在这种场景下的测试就非常的重要了， ESB 不但要承担一些技术上的测试，还要和服务方进行一些业务的测试，这样才能保证这支交易可用。
这个是一个最简单的应用场景（图表 4 ? 2 ），在这个场景中 ESB 只要是做交易的转发，当然中间也可能做不同部文之问的转换，但这一切应该在部门这个视角上应该透明的，使用都不应该使用服务的这些细节，这些细节，我们会在 ESB 的内部视角中进行阐述。
?
图表 4 ?2
?
?
如果一个服务，不能在短时间能完成操作，这个时候，这个服务就不能使用同步请求，而应该使用异步请求，然后当这个服务完成操作后，再回调一个方法来返回结果 ，当然，你也可以不进行结果的返回。
?
图表 4 ? 3
?
?
?
?
图表 4 ? 4
1.1.1? 异步提供服务
图表 4 ? 5
?
相关文章
