使用 Apache Synapse 将现有的系统转化为 SOA 平台
2007 年 9 月 06 日
如果您正计划将现有的中间件转换为面向服务的体系结构（SOA）平台，那么可 以考虑使用 Apache Synapse。这是一种替代专有企业服务总线（ESB）的、易于使用的、开放源代码产品，其成本更低并且所需进行的工作更少。本文向您全面地介绍了 Apache Synapse，并提供了一个用例，以说明如何使用 SOA 方法集成并重用现有的应用程序。<!-- START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- include java script once we verify teams wants to use this and it will work on dbcs and cyrillic characters --> <!-- END RESERVED FOR FUTURE USE INCLUDE FILES-->
Synapse 是一个简单的 XML 和 Web 服务管理与集成代理，可用于构成 SOA 和企业服务总线（ESB）的基础。Synapse 最近刚刚由 Apache 孵化器“孵化”完成，现在是 Web 服务项目中一项成熟的 Apache 活动，并且是非常成功的 Apache Axis2 项目的一个分支。它提供了中介、管理、以及在各种不同的应用程序之间转换 XML 消息的能力。
Apache Synapse 项目最近发行了版本 1.0。您可以在 Apache Synapse 网站（请参见参考资料 中提供的链接）上阅读更多关于这个重要的发行版的信息。
大多数公司热衷于将它们现有的中间件转换为 SOA 平台，通常这需要花费很大的代价。Apache Synapse 是一个简单的、高质量开放源代码的替代方法，为实现 SOA 提供了一种途径，它可以公开现有的应用程序，而无需重新编写任何代码。重用、集成、管理和控制 与现有应用程序的交互，而无需对它们进行更改，这种能力使得 Synapse 成为一项颇具吸引力的选择、以及实现 SOA 策略的关键途径。
不幸地是，ESB 概念定义得非常糟糕。然而，我们提供了一个简单的、实际的定义：连接、转换、管理 。
ESB 模型促进了与服务契约和与服务契约相关联的元数据的基于 SOA 的集成，如 Web 服务描述语言（WSDL）、模式或策略。ESB 模型（请参见图 1）确保进入该总线的每条消息最终都能到达正确的位置。
  |
|
让我们来看看构建 Synapse 的原则。
Synapse 构建于 XML 和 Web 服务标准之上。从最基础的角度而言，Synapse 建立在通过网络传送消息的思想之上。消息可以采用任何格式，但是 Synapse 将它们放到一个逻辑信息集（请参见参考资料 以 获取更详细的信息）中，并采用包含 Header 和正文的信封的 SOAP 方法对其进行建模。通过使用 Web 服务标准，如 WS-ReliableMessaging 和 WS-Security，您可以使用 Synapse 以确保应用程序之间安全的、可靠的连接。Synapse 可以负责这些类型的服务质量（QoS）功能，而无需修改现有的应用程序。例如，通过在现有的 XML/HTTP 服务前面直接放置一个 Synapse 实例，您就可以添加对 WS-Security 的支持。这样可以添加对数字签名的支持，在 B2B 环境中是很重要的。
随 着 Web 的出现，HTTP 已经成为通用的信息传输方法。由于它具有防火墙友好性、广泛的可用性、得到广泛的承认、以及 HTTP 在全球范围内受到广泛支持，大多数企业已经使用 HTTP 公开他们的服务。可以以两种不同的方式 — 来看待 HTTP，将其视为实际的交互协议，或视为传输协议。那些将 HTTP 视为交互协议的人将遵循 REST（请参见参考资料 以获取更详细的信息）模型，并且倾向于严格遵守 HTTP 动词（GET、PUT、POST、DELE）语义。还可以将 HTTP 作为防火墙友好的传输方式，在这种情况下，通常的模型是发送 XML 文档，然后再从响应中获取 XML 文档。
SOAP 是一种通用的、传输方法独立的消息传递格式。因为它与平台、传输方法和语言无关的本质，所以它已被许多应用程序所采用，从帮助 eBay PowerSellers 管理他们的店铺，到跨网络发送打印作业。它也是许多高层次规范的基础。它可以与其他机制一起使用或者单独使用，实际上，SOAP 和 HTTP 构成了通用的交互模型，并且可以连接企业边界内外的异类系统。
尽管 Synapse 支持许多不同的传输方式，包括 Java™ 消息服务（JMS）、邮件、XML/HTTP 和 SOAP，其核心仍然使用了 SOAP 模型。这意味着什么呢?从最基础的角度而言，这意味着有反映 SOAP 信封的内部数据结构。例如，to 和 replyTo 地址使用 WS-Addressing 规范进行建模。当消息流通过 Synapse 引擎时，可以使用标准中介将消息与各种格式之间进行转换，包括 REST、SOAP、JavaScript Object Notation (JSON) 和 JMS。此外，可以通过编写自定义中介对其进行扩展。
勿 庸置疑，目前 XML 已经成为通用数据格式，受到几乎所有编程语言的广泛认可和支持。这使得异类应用程序能够使用共同的数据模型来传递数据，而任何语言都可以很容易理解这个数 据模型。在 Synapse 中，所有的内容都是与 XML 有关的，并且其思想是在网络中尽可能地使用 XML，从而将您的整个网络变为一个总线。这样做的原因之一是，网络中所有的 XML 交互构成了 ESB，可以使用 Synapse 对这个总线进行管理（请参见图 2）。
| |
|
可以使用不同的方法来部署 Synapse。部署 Synapse 的最简单的方法是使用代理 概念。
在 代理模型（如图 3 所示）中，您明确地定义一个新的端点（代理），Synapse 在该端点上进行侦听。实际上，这就像一个新的服务，除了服务逻辑是通过远程服务来实现之外。在这个模型的最简单的实例化过程中，您可以直接将代理侦听器连 接到远程端点。然而，即使在这种简单的情况下，您也可以完成一些有价值的事情。例如，您可以在 XML/HTTP、SOAP 以及 JMS 之间进行切换。您可以打开或者关闭某些协议，如 WS-Addressing、WS-ReliableMessaging 和 WS-Security。并且在 Synapse 1.0 发行版中，您可以在这些协议之间定义一组相同的服务并平衡负载。
在 这一方法中，您可以对客户端进行配置，以便将所有的消息发送到 Synapse。例如，Synapse 可以作为一个 HTTP 代理。这是非常方便的，因为几乎每个 Web 客户端都可以配置 HTTP 代理，而无需改变应用程序代码。所以，通常只需要对通过 Synapse 的消息进行重定向即可。Synapse 有一个缺省的活动序列，应用于按这种方式到达的任何消息。然后，可以使用诸如基于内容的筛选（XPath 或者 Regex）之类的技术，以便有选择地将这些策略应用于特定的消息。
| |
|
Apache Synapse 实现了通用的中介框架。如前所述，您可以指定一个对消息进行操作（基于它所到达的端点、或基于某种筛选）的中介序列 。Synapse 的目标是支持一组有价值的、即时可用的中介。这类内置中介包括：
- 记录日志到 log4j。
- 修改 Header，包括 WS-Addressing Header。
- 运 行脚本，包括 JavaScript、Groovy、Ruby 和 Bean Scripting Framework (BSF) 所支持的其他脚本。E4X 支持允许 JavaScript 直接操纵 XML 消息，而不需要使用像 DOM 这样的 API。在 Ruby 中也存在类似的支持。
- 启用和终止 WS-Security 与 WS-ReliableMessaging。
- 在 SOAP 版本和 XML/HTTP 之间进行切换。
- XML 模式验证。
- 发现消息中的错误或者丢弃它们。
| |
|
正如前几部分中所介绍的，Synapse 可以连接和管理您的服务，并为您的服务提供中介。
除 了在内部网中进行操作之外，Synapse 还可以用作您企业的网关，并且更有效地管理对合作伙伴公开的服务。网关模型可以包括使用 Apache Rampart 框架应用身份验证机制、以及对进入的消息进行授权，以支持 WS-Security 和 WS-SecureConversation。通过将网络内部的虚拟 URL 映射为真实 URL，Synapse 可以使得您的企业能够在隐藏内部基础结构细节的同时，为外部系统维护统一的寻址方案。您可以在组织内部使用相同的模型，以便独立于具体的实现，提供一套清 晰的、可管理的总线级别服务。集中式的连接模型也促进了对 QoS 各个方面的更好管理。
例如，可以使用 Synapse 将简单的 GET HTTP 请求映射为与后端连接的 XML/JMS。使用这种方法，可以对更大范围的客户端公开遗留的资源，包括 Asynchronous JavaScript + XML (Ajax) 应用程序和移动设备。
Synapse 为管理策略和服务的其他方面提供了一致的模型。通过将 Synapse 作为中间层，您可以控制诸如身份验证、审核、日志之类的方面，或者诸如故障转移和负载平衡之类的 QoS 方面。这使得您的组织可以更高效且更有效地管理资源。可以通过配置一个简单的 XML 文件来启用所有这些特性，而无需编写任何代码。
下面提供了一些示例：
- 可以将 http://stockquote.com?symbol=RHAT 映射为一个服务，并作为一个基于负载平衡策略（如 Round Robin）的集群进行部署。如果是主服务器加后备服务器的情况，当主服务器关闭时，故障转移中介可以将它映射到后备服务器。
- 可以为所有的对 http://abcbank.com/personal 的请求进行身份验证、日志记录、以及随机地进行日志记录和审核标注。
- 可 以对 http://abcbooks.com/suppliers?category=XXXX 应用中介，以便根据供应商类别添加不同的策略。例如，如果 category=silver，那么供应商的信用额度是 5000；如果 category=gold，那么供应商的信用额度可以是 10000。
Synapse 可以将您的遗留应用程序转换为先进的 Web 服务。Synapse 可以用作代理，并且可以通过完成下面的一项或者多项工作实现服务和应用程序的虚拟化：
- 对 SOAP 消息（Header 或正文）执行 XSL 转换（XSLT）
- 使用 JavaScript/E4X 转换程序直接将 XML 映射为 JavaScript
- 使用传统的 Java 对象（POJO），您可以在其中编写 Java 逻辑，以便对消息进行操作
- 将 JSON 映射为 XML，其中可以将 JSON/HTTP 流作为 SOAP 消息发送，反之亦然
- 执行附件中介，其中可以将带附件的 SOAP 转换为 Message Transmission Optimization Mechanism (MTOM)、将 Base64 转换为 MTOM，反之亦然。
- 执行您自己的自定义转换
这为重用您现有的应用程序、以最少的投资对它们进行集成以提供更好的服务提供了机会。有了 Synapse，您可以将整个网络转换为 ESB，这个 ESB 提供了集中式和一致的方法，以便管理所提供的服务。
| |
|
下面的案例研究说明了如何使用 SOA 方法集成和重用现有的应用程序，以便处理信用卡支付系统的中间件操作。
ABC 银行已经决定提供一个基于 Internet 的支付网关。该应用程序需要接受在线信用卡支付请求，检查欺诈行为，然后使用 Visa 或者 MasterCard 系统对请求进行验证。这个银行拥有一些现有的应用程序，包括检测欺诈性交易的应用程序、审核系统、短消息服务（SMS）应用程序、以及用于信用卡处理的 Visa 和 MasterCard 应用程序。
您 可以使用 Synapse 集成、管理、控制这些现有的应用程序，并使用 SOA 方法将这些现有的应用程序转换为服务。使用基于脚本的中介（允许重用现有的应用程序，而无需重写代码）可以完成一些简单的逻辑，比如防止欺诈的初始审查、 基于内容的路由、以及欺诈评分处理。如果这些脚本来自于动态注册中心，那么它可以提供修改相关逻辑而无需重新启动Synapse、以及干扰交易的灵活性。
正 如图 5 中的图表所示，首先使用脚本中介对请求进行审查，防止欺诈交易的可能性。如果它是可信的，使用切换中介将它发送到 Visa 或者 MasterCard 服务，到底是哪个服务依赖于银行卡的类型。如果欺诈审查流程确定需要将该交易发送到欺诈评分系统，那么将其转发到欺诈评分服务。欺诈评分服务为这个交易分 配一个欺诈分值。然后，欺诈警报服务使用切换中介来确定活动过程，以便根据欺诈分值来定义相应的传输逻辑路径。
如前所述，配置这个逻辑就像编写一个 XML 文件那样简单。然而，详细地描述代码示例已经超出了本文的范围。我提供了代码示例附件（请参见 参考资料 以获取 synapse.xml 的链接）以说明其易用性，并且大多数代码都是自我说明的，如果您遵循图 5 中的图表。您可以使用参考资料 部分中提供的链接，下载完整的 synapse.xml 文件。
| |
| |
Synapse 提供了一个简单的、易于使用的、开放源代码替代方法，以最少的成本和工作量，将您现有的中间件重新构造为 SOA 平台。通过中介或者转换现有的服务，而无需进行编码，Synapse 实现了重用的最大化，并且提供了一种优秀的模型，以便将您的服务集成到 ESB 模型。