复杂性的简单管理
由于其业务可见性、灵活性及知识管理方面带来的高额利润，门户技术成为了用于对整个企业的商业活动进行监控、查找和管理的流行选择。对于构建高度动态的能够聚集、组织和表示来自多个后端系统的信息的企业门户来说，BEA WebLogic Platform具有很大的吸引力。不论门户是用功能丰富的WebLogic Portal Server环境实现，还是通过像Jakarta Struts这样的MVC框架实现，最新版的BEA WebLogic Platform 8.1提供了大量新特性用于创建功能强大的门户环境。
但是由于企业门户开始聚合数量不断增长的跨越不同技术领域、地理界限，甚至是组织界限的服务，所以门户架构师将需要找到管理环境复杂性的方法。无疑，在门户与每一个服务之间构建一次性、可靠、点到点的集成不能从开发、部署或运行时方面进行伸缩。所以需要一种“服务网络”的概念，它提供可靠传输、智能路由、高级服务管理特性，以及提供在高度分布式的联合环境下运作的能力。
幸运的是，一种称为企业服务总线（ESB；参见侧栏“ESB：您的Web 服务网络”）的新型基础结构提供了甚至最苛求的门户环境所要求的复杂级别。ESB是一种基于标准的面向服务的骨干，它能够进行可靠连接和协调数百个应用程序端点。
ESB为需要连接跨越不同数据中心分布的各种异构系统的企业提供了一种理想的体系结构，同时还保持了绝对的事务完整性。此外，它还提供几个通过部署时构造进行最初配置的高级服务，从而保护了门户应用程序，即不必经常对它进行修订和重新部署来管理后端上的更改。
即使是计划部署一个门户以将同构环境中的系统与许多后端服务集成，将ESB合并为集成网络也有明显的好处。综合性的ESB供应商将会提供out-of-the-box管理、安全性、可靠性、高性能的服务请求、本机XML处理、复杂路由和转换，以作为总线中的增殖特性。另外，作为面向服务体系结构（SOA）的一种基于标准的实现，ESB提供必要的抽象层来履行SOA的全部承诺。在不牺牲同构环境的传统价值（即管理、安全性、可靠性、伸缩性和性能）的情况下，ESB提供了将底层服务实现无缝地重新部署到其他技术、地理或组织领域的能力。
本文中，我们将通过两个关键用例来演示，使用BEA WebLogic Platform 8.1，将高度分布式的服务与门户及Web应用程序相集成时ESB的威力和灵活性。在两部分系列的下一部分中，将展示ESB如何通过操作感知、业务活动监控（BAM）和面向服务的业务过程管理来向组织提供附加值，从而让门户可以充分利用扩展企业中的服务的全部价值。
Avitek Medical Records：扩充其业务模型
WebLogic Platform 8.1配带一个综合的J2EE指南，称作“Avitek Medical Records（Avitek医疗记录）”，用来说明J2EE平台的所有核心特性。该指南建模的基本思想围绕这样一种门户(一种J2EE Struts应用程序)，它为病人、医生和管理者提供查看整个医疗记录集合的能力。另外，该应用程序展示了通过Web Services接口连接外部客户机的能力，它提供了不通过表示层直接与Avitek服务交互的能力。
作为本文的前提，我们假设Avitek上的“业务量在急剧增长”并且已经获得医疗记录的三个新的来源以集成到门户中。为了使情况复杂一点，新的来源在地理上跨越不可靠的网络分布，并且包含混合的技术环境（多种J2EE应用程序服务器供应商、Microsoft .NET和定制的解决方案）。实际上，Avitek类似一种能适应变化的体系结构，因为它们很可能会增量地获得信息的新来源，并会随着时间慢慢地将这些来源迁移到最新最好的技术上。
尽管Avitek Medical Records的体系结构宣称能够使用HTTP/Web服务来集成新的医疗记录来源，但是本文将通过一些关键用例来解释仅仅使用Web Services环境是不够的。
图1
在谈到纯HTTP/Web服务方法的生存能力时，还存在一些与通信模型（请求/响应模型、单向通信模型和异步服务模型等）的可靠性、性能、丰富性以及服务质量、性能、管理和安全性相关的问题。为此，我们建议修改Avitek的体系结构以与ESB的概念相结合（见图1）。
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也提供一些不同的方法，来满足在不同域之间的这种松耦合和可靠的消息传递。
可靠的Web服务
BEA WebLogic 8.1提供一种称为“可靠SOAP消息传递”的新特性。该特性允许两个不同的WebLogic服务器之间进行异步可靠的消息传递。虽然SOAP/Web服务是一种基于标准的方法，目前WebLogic 8.1通过专有的SOAP报头和交互协议来实现可靠性。也许将来的能够用像“WS—Reliability”这样的基于标准的方法来实现。即使是使用象“WS—Reliability”这样的基于HTTP的标准方法，需要高吞吐量和低延迟的特定用例将通过真正的“端到端”JMS解决方案来获得更好的服务。
为了可靠的连接两个跨越不同网络和地理界限的系统，必须在每一个域中都驻留某种基础结构，用以在发生故障时提供必要的“存储和转发”功能。ESB基础结构通常是“轻量级”、易管理并且重点只放在集成服务上。此外，将ESB基础结构部署到.NET 环境或甚至是另外的J2EE基础结构，可能会得到更好的组织结构。预先计划ESB当然可以避免以后可能出现的很多问题。
JMS消息桥
BEA WebLogic 8.1提供能够在两个不同的JMS实现之间转发消息的JMS消息桥。这种方法当然提供了相对HTTP/Web服务方法的优势，但ESB的基础结构能在本地总线上提供必要的转发、路由和消息优化功能。ESB也提供内聚管理和安全环境，简化了部署。
联合查询
这种“联合查询”用例解决了在表示层中需要对多种后端系统进行查询的问题。与“转发服务缓存”用例不同的是，后端系统中的数据不能合理地得到缓存。这是因为：
1. 后端系统中数据的变化速率使得数据无法合理地得到缓存：查询缓存的数据可能会造成数据不一致和结果错误。
2. 数据量太大：缓存转发的数据在技术上和经济上都不可行。
联合服务查询模式的另一方面是：请求花费的时间太长以至于无法完成（某些情况下，需要几天）。例如，一个独立系统可能会包含某种人工干预（例如确认）来完成工作流。因为其固有的异步特性，ESB能够为这种模式提供强大的基础。
联合查询模式至少有两种变体。这里讨论的变体根据查询的持续时间进行变化。
对于表1中讨论的两种联合查询模式，ESB使用JMS的基本“发布—订阅”消息传递模式来将请求有效地散播到多个后端系统（在本例中是订阅者）。这些模式说明了实现功能的非常简单的方法，ESB提供了实现大量技术所需的核心工具。ESB提供了一组丰富的通信模型，它们可以采用最有效的方式来适应门户与后端系统之间的各种交互。
表1
为了阐明这个观点，让我们考虑对三个后端服务上的查询。如果每个服务需要三秒钟进行处理，连续地调用这些服务将至少耗费九秒钟。ESB允许以并行的方式执行服务，使得全部的服务执行时间等于最长的服务的运行时间（在本例中是三秒钟）。虽然这可以使用集中式多线程技术来实现，但ESB允许并发处理跨总线进行分布，这样就消除了集中式的瓶颈，并提供了更大的可伸缩性潜力。
联合查询：实时请求
针对本例，我们增强Avitek，为医生提供在多后端系统中查询的能力，以便确定在某个时间段内得到输血的患者的名单。
为了实现这种新特性，必须使用WebLogic Server 8.1中新的“JMS包装”支持。这种特性能直接从EJB或者servlet中有效地发送或接收JMS消息。WebLogic Server 8.1能够有效的管理JMS连接池，以确保消息能够在门户应用程序和JMS实现程序（或在我们例子中是ESB）之间进行快速路由。下面给出它的工作原理：
无状态的会话bean包含了一个方法，它实现了已被广泛接受的“JMSReplyTo”模式。当客户端（servlet和JSP等）调用无状态会话bean上的方法时，该方法将请求发布给ESB，ESB再将请求分发到在配置主题上侦听的服务。这类服务的例子是JMS客户端、Web服务或甚至是与应用程序交互的JCA适配器。
无状态会话bean定义了一种方法，使得客户端可以发送任意字符串请求。在XML中可以对它进行格式化。
public boolean sendRequest(String requestData, ArrayList a) {
JMS对象一旦建立，标准的“JMSReplyTo”模型就用于将请求与“返回地址”一起发布。所有响应都会返回到这个无状态会话bean的实例上（参见清单1）。
最后，这个例子将等待来自ESB上的服务的特定数量的响应，或者直到超时发生为止（参见清单2）。
联合查询：长持续时间请求
对于本例，我们建立在前一个例子的基础上，只是假定来自总线上的服务的响应将以更加不可预知的方式返回。这种模式使门户用户可以浏览到Web 站点的其它区域，同时响应也以异步方式聚合在用户的会话中。用户甚至可以注销，然后重新登录以检查请求的状态（参见图4）。
图4
对于本例，消息驱动bean用于异步收集响应，并将其保存在数据库中。另一种情况是本地XML数据库可以派上用场。如果系统用变化中的XML响应信息响应，也许将整个XML响应简单地存储到“无schema”数据库中是最好不过的了。
ESB的一个主要特征是：所有的服务都通过一个“松耦合”的通信接口联系在一起。与本例有关的好处是：新系统可以联机进来，并立即被包括到联合查询中。由于基础机制是“发布—订阅”模式，所以新服务可以简单地订阅相关的主题并从门户接收查询请求。由于ESB允许在部署时动态发现和智能配置驱动的路由（基于内容和基于上下文等），所以可以保证门户不受ESB上的服务变化的影响。
联合查询：实时请求与长持续时间请求的组合。有时候，可能值得在某个时间帧内收集来自总线上不同系统的结果（实时请求），但在初始时间帧过期后以异步方式收集响应（长持续时间请求）。为此，我们引入单独的“通知主题”概念，以便当MDB成功地将响应保存到缓存时，允许无状态会话bean（SSB）接收通知。SSB可以使用任意的业务逻辑来决定何时停止等待，允许门户应用程序从缓存中读取数据并将结果显示给用户（参见图5）。
图5
小结
虽然BEA WebLogic Platform 8.1是一种能处理多种应用程序方案（包括门户）的强大平台，但也有某些类型的门户集成方案，它们是作为企业服务总线需要的。完全基于标准的基础分布式网络——ESB能够创建敏捷、可互操作及可靠的面向服务网络，以便把企业内外的服务链接在一起。由于今天Web服务标准发展到合并JMS提供程序的许多可用语义，所以ESB实现模块将继续实现标准并创建可互操作的网络，使JMS应用程序能够和Web 服务应用程序对话，反之亦然。同时，ESB将给某些门户和Web应用程序开发者添加重大的价值，他们尝试解决涉及异构系统、地理位置和组织的复杂集成方案。
下一部分中，我们将讨论操作感知、业务活动监控以及集成工作流如何可以给这些应用程序增加附加值。
ESB：你的Web服务网络
到现在，你可能会问，“Web服务怎样？”。Web服务的承诺当然是跨完全不同技术、地域以及组织界限的集成能力。把ESB看作是Web Services的健壮网络。ESB建立在Java Message Service（JMS）基础上，它提供所需的关键特性，以便为相互连接的服务建立可靠、安全、可管理及高度执行的骨干。实际上，在许多可用的Web服务工具包中，ESB的基础骨干已经变成可以识别的SOAP传输。针对新出现的许多Web Services标准，ESB提供了自己的解释与实现，使门户开发人员看不到不同服务间的网络级互操作细节。许多复杂的Web服务主题，比如路由、工作流、事务、单用户注册安全、审计、高级监控和管理，都可以通过ESB基础结构处理。
ESB实现模块:增值服务
如前所述，许多ESB 厂商提供增值服务以帮助建立健壮的集成环境。在“前向缓存”用例环境中，有一些需要考虑的其它问题：
l连通性：JMS中的“J”代表“Java”，这是否意味着所有的系统必须符合Java？当然不是！ESB 充当SOA 环境下的“瑞士”，将完全不同技术集成到普通的可互操作网络。寻找支持本地C/C++实现、MS/.NET、本地HTTP/SOAP支持及更高级别的适配器（JCA或定制）的ESB 实现模块，以自动化集成过程。
l转换：Avitek演示合并了在表示层中嵌入的转换，以便将医疗记录的不同表示转换成Avitek形式。然而，在联合开发环境中，系统某各部分的开发者可以建立到这种XML规范形式的转换。在本例中，将转换重新部署在接近初始点（和开发人员）不是更好吗？寻找在ESB中任何位置都可以配置转换的ESB实现模块。
关于作者：Hub Vandervoort是 Sonic Software专业服务部门的副总裁。他具有20多年的顾问和高级技术主管的经验，其中涉及网络、通信软件和Internet产业。在以前，Hub与人共同创建了三个创业风险投资公司，其中包括早期的面向消息中间件（MOM）领先厂商Horizon Strategies, Inc.。
Matt Rothera是Sonic Software（www.sonicsoftware.com）的见习经理，同客户一起工作，帮助规划、设计和部署实时、面向服务的体系结构。在超过15年的技术工作中，Matt已经同100个客户一起工作，把它们的服务与内部应用程序、商业合作伙伴和企业门户集成。