登录
ESB是基于工业标准的JMS，将会提供一种企业级的骨干，以便可靠地将服务一起链接到内聚性操作单元中，它能够服务于大多数门户所需的全范围的集成场景。本文将会介绍ESB就位后可用的许多场景中的几个场景：
1. 前向缓存（Forward Cache）：为了低延迟、只读访问数据而将数据从分布式系统移动到靠近表示层的能力。
2. 联合查询（Federated Query）：在表示层有效地查询多系统并异步地聚集响应的能力。
前向缓存服务
“前向缓存服务”用例解决需要把数据从back-office系统暴露到表示层这样的问题。尽管表示层可以容易地通过请求/响应模型与back-office系统交互，但仍有一些原因使得这样做行不通：
1. back-office系统不能维持支持前端表示层所需要的负载。
2. 请求/响应模型的延迟超出了表示层容许的范围。
3. 将back-office系统直接暴露给表示层会有风险——稳定性或是对现有服务级别的冲击。
4. back-office系统可能与表示层处于不同的地域；在两个数据中心之间连接断了的情况下，数据对于终端用户来说应该仍然可用。
ESB可用于可靠地将变化转发到表示层中的缓存中。这里的关键单词是“可靠地”。在分布式基于SOA的环境中，需要将注意力集中到系统之间如何互操作以及在发生故障和停机时会发生什么事情上。很多时候，系统不能为这种类型的可靠性提供必要的消息重发和“未确定解决方案”。ESB可以消除系统中的这种复杂性（见图2）。
图2
从定义来看，ESB是一种可以在任意两个实体间可靠通信的分布式服务网络。ESB实现模块提供的部署选项允许将服务质量调整成刚好满足应用程序的需求。基于工业标准的JMS，两个实体使用标准接口可靠地进行通信；ESB处理路由的复杂性并保证更改通知的传递。
幸运的是，Avitek演示不需要彻底地改变以利用ESB。给定ESB的基于标准的方法，ESB实现模块通过JMS接口连接进来。Avitek演示中包含了一个MDB，该MDB对JMS连接进行侦听，以将XML记录“上载”到MedRec数据库。一旦记录被加载到数据库中，这些数据就对使用标准技术对数据库进行查询的前端门户可用。当然，这种模式还有待加强，以适应记录删除请求，或者甚至适应部分记录更新（参见图3）。
图3
但这与标准的JMS实现程序的区别何在呢？JMS实现程序能在单一域中确保信息异步的传递。试图连接多个JMS消息传递域通常需要某种定制的桥接，使得消息可以在多个域之间进行可靠的转发。然而ESB实现模块在分布式联合环境中提供本地的端到端JMS通信，这消除了对定制桥接的依赖。另外，ESB还提供附加的基于标准的连接，例如Web services和JCA适配器（参考侧栏“ESB提供商：附加值服务”），这允许在ESB上的任何地方灵活地部署服务。
另外需要考虑的是在表示层中数据如何进行缓存。Avitek演示依赖于将标准XML Schema存放在关系数据库中。可是在有各种各样信息单元的不同服务环境中，则更倾向于在不必定义关系结构的情况下存储和处理不同格式的XML。
ESB实现模块也许会提供嵌入式XML数据库，采用一种“无schema”的方法来存储、恢复以及查询XML文档，彻底的减少了为适应后端服务数据中的变化所需的数据库管理时间。
也应该讨论一些替代方法来与ESB进行比较和对比。BEA WebLogic 8.1也提供一些不同的方法，来满足在不同域之间的这种松耦合和可靠的消息传递。
| 第1页： 第1页 |
