引言

IBM 对 ESB 的立场是——并且一贯是——认为 ESB 作为 SOA 中的一种体系结构模式发挥了根本性的作用。ESB 是实现成功 SOA 采用的重要入口点，并且是任何面向服务的解决方案的关键成功因素。事实上，作为对 SOA 中的 ESB 承诺的一部分，IBM 提供了实现 ESB 模式的三个战略产品。

本系列的第 1 部分描述了企业服务总线 (ESB) 体系结构模式如何适应 IBM SOA Foundation，以及 ESB与 Foundation 的其他部分如何相关。

本文介绍以下主题：

• 设计良好和实现良好的 ESB 能够为面向服务的解决方案提供的价值
• 一些在设计和实现 ESB 时要遵循的最佳实践
• IBM 对作为 SOA 组成部分 ESB 的承诺

与 SOA 相关的 ESB

IBM SOA Foundation 白皮书描述了 IBM 交付 SOA 价值的整体方法。SOA Foundation 的参考体系结构（图 1显示了逻辑模型视图）的核心中具有 ESB。该参考体系结构的描述声明“ESB 的存在是简化服务调用任务的基础”。虽然该白皮书是在 2005 年末发布的，但是其中预述的论点却随着时间推移而通过我们在采用 SOA 的客户方面的经验得到加强。

本系列的第 1 部分表明了 ESB 是称为 SOA 的更大体系结构模式中的一个关键体系结构模式。充当中间层的 ESB 提供了服务交互中参与者之间的松散耦合连接，从而提供了 SOA 的中枢。作为中间层，ESB 执行服务虚拟化以协调服务请求程序和服务提供程序之间的差异，并提供面向方面的连接以用作诸如管理和安全性等 SOA 策略的执行点。松散耦合允许解决方案中的组成部分之间彻底分离关注事项（时间上、技术上和组织上的分离），从而同时支持业务流程和 IT 系统的灵活性和敏捷性。

通过 ESB 实现的松散耦合的部分优点（包括本系列的第 1 部分详细描述的服务虚拟化和面向方面的连接中所固有的优点）如下：

• 请求程序和提供程序不必就消息格式、消息传输甚至目标地址达成一致。
• 请求消息可由多个提供程序中的任何一个进行处理，请求程序不必显式地确定提供程序。这种路由可以基于相应的版本、服务质量或其他度量。
• 现有的请求程序无需更改即可连接到新的提供程序。
• 现有的提供程序无需更改即可对新的请求程序公开。
• 可以对请求程序做出更改而不影响提供程序，或者对提供程序做出更改而不影响请求程序。
• 解决方案的横切方面，例如安全性和管理等等，可由 ESB 进行添加、执行或加强。
• 可以实现新级别的动态行为，因为 ESB 能够为请求程序和提供程序之间的每个交互实时执行策略。

作为 SOA 入口点的 ESB

一次性全面采用 SOA 可能是一项艰巨的任务。IBM 已确定了五个SOA 入口点，这些入口点提供了有关如何开始渐进地采用 SOA 的指导。渐进的采用方法允许企业以最适合需要的方式和步调采用 SOA。为什么我们要确定五个入口点？简单的原因在于众口难调；企业的在成熟度级别和特定需求方面各不相同，适合于一家企业的入口点可能不适合于另一家企业。这五个入口点基于已导致我们的客户成功实现了 SOA 的方法。存在两种类别的入口点：

• 以业务为中心的入口点——人员、信息和流程——允许您从一种侧重于基本企业资产的方法开始。
• 以 IT 为中心的入口点——连接性和重用——允许您为 SOA 奠定技术基础。

您也许已经从SOA Foundation 白皮书中预料到，连接性意味着使用 ESB 来“通过更加安全、可靠和可伸缩的方法简化 IT 环境，从而在企业内外进行连接”。IBM 认为，虽然 ESB 无疑是一种以 IT 为中心的 SOA 方法，但是“它本身交付了实际业务价值，并且是将来的 SOA 计划的核心构件”。本文中的一个关键问题（将在下面进行讨论）是如何最好地使用 ESB 来形成将来的 SOA 计划的构件，以及如何通过连接性入口点获得最大的业务价值。

存在多种利用连接性入口点的方法。有时客户已经在其环境中定义了一些服务（也许是通过合作伙伴），不过是直接连接的服务；这种情况导致缺乏灵活性并增加管理成本。如上所述，在此类环境中插入 ESB 可以提供直接的松散耦合优点。此外，ESB 的存在为将来定义附加服务、创造附加重用机会、支持新的重用渠道、降低管理成本和获得更多敏捷性的工作创造了条件。

客户通常知道 ESB 的价值并渴望开始从 ESB 中实现好处，但是他们还没有在其环境中定义服务。我们看到了两种已采用过的成功技术，这两种技术帮助在这种情况下从 ESB 获得好处。客户经常混合使用重用和连接性入口点。他们确定需要作为服务来连接的功能或应用程序（请求程序或提供程序）。同时，他们将 ESB 插入该体系结构，以提供新的服务请求程序和提供程序之间所需的松散耦合。混合方法得以流行的一个重要因素是 ESB 产品的转换和变换功能。此类功能允许使用同一个 ESB 产品作为某种形式的适配器，以便以更加可重用的形式公开功能或应用程序，并提供所需的服务虚拟化和面向方面的连接。这里成功的关键是谨慎地开始，公开少量的服务并开发对应的中介，但是这些服务和中介都在为考虑中的整个最终范围而设计的体系结构之内。

有些客户插入 ESB 以建立组织中连接的所需方向，尽管起初还没有确定要连接的服务。在此情况下，ESB 是组织的总体参考体系结构的一部分；参考体系结构提供了体系结构方向，并强制要求最终将作为解决方案一部分而创建的所有服务（请求程序和提供程序）进行松散耦合连接。ESB 是用于实现该松散耦合的首选机制。采用 ESB 实际上消除了解决方案中的直接连接不知不觉地增长的可能性。这里成功的关键是：

• 采用一个要求并演示 ESB 使用的参考体系结构。
• 考虑解决方案的整个最终范围，并支持最佳的 ESB 产品选择。
• 随着解决方案的发展而实施强有力的治理，以确保利用 ESB 来连接到引入解决方案的新服务（请求程序和提供程序）。

SOA 入口点最佳实践

存在一组 IBM 强烈建议用于任何 SOA 采用的最佳实践。这些最佳实践的最重要元素是建立一个路线图并渐进地实现该路线图，该路线图定义了实现所需业务目标的采用计划（请参见参考资料部分以获得指向文章“Service Oriented Architecture:An Introduction for Managers”的链接）。该路线图包括两个重要组成部分：

1. 战略远景，业务或 IT 的方向陈述（包括参考体系结构和治理计划），可用作决策制定、组织参与和标准采用的指导原则。
2. 一组项目计划，定义实现项目以满足当前业务驱动因素的即时和将来需要。

此类路线图允许您渐进地实现 SOA，以在每个项目步骤中回报业务价值。

您应该在执行该路线图的早期确定您业务的最佳 SOA 入口点。您应该基于从您的总体战略远景和当前 SOA 成熟度级别得出的要求来选择该入口点。该入口点可能是也可能不是连接性入口点；它可能是上述入口点的混合。但是，连接性入口点是最普遍的入口点，因为有如此多的客户具有将请求程序连接到提供程序的即时需要，并希望获得 ESB 提供的松散耦合的好处。IBM 提供了一个在线工具Business Value Analyzer，以帮助您选择 SOA 入口点。

另一个最佳实践是建立治理框架以确保组织遵循该路线图（请参见参考资料以获得指向文章“SOA Governance and Service Lifecycle Management”的链接）。SOA 所促进的灵活性增强和跨组织性质要求组织建立治理框架，以实现主动的决策制定、准确的跟踪、改进的服务能力和更好的交流。有效的治理通过在增添价值的同时平衡风险和回报，从而帮助实现企业的业务目标。

正如上面所建议的，渐进的 SOA 采用是成功的关键。IBM 建议从试验项目开始，该试验项目：

• 处理得到充分了解、重要但不关键的业务需要。
• 实现参考体系结构的某些重要方面（也许是 ESB 和一组示例服务、提供程序、请求程序，这些方面用于演示 SOA 的使用）。
• 需要一个超出当前能力的可达范围。
• 积累 SOA 技能。
• 用作对采用 SOA 治理和新的服务生命周期管理流程所进行的试验。
• 产生将会投入生产应用并将交付投资回报的结果。

通过 SOA 实现的关注事项分离甚至允许试验项目以能够积累专业经验和验证业务价值但不中断主要操作的方式引入 SOA。

SOA 连接性入口点最佳实践

除了 SOA 最佳实践以外，还存在其他更特定于 ESB 的最佳实践：

• 仅当 ESB 在您的路线图中有意义时才采用 ESB。例如，如果 SOA 入口点以业务为中心，您可以推迟通过 ESB 实现的松散耦合，尽管您的参考体系结构中包括了 ESB。
• 基于您的参考体系结构和一组跨全套项目计划的实际要求来设计 ESB 并选择 ESB 产品。我们说实际是因为您应该集中于未来几年中的需要；到您超过该时间期限时，产品和需求已经发生了改变。如果仅考虑即时需求，尤其是忽略服务请求程序和提供程序的预期需要，则会导致选择非最优 ESB 产品。您必须明确地在公司的约束内行事，例如年度资金周期和预算，但您同时还希望将短期采购和决策与考虑中的长期（三至五年）目标保持一致。
• 根据情况考虑 ESB 联合。更大型的异构企业通常作为某种自治域的联合体出现，这些自治域基于各个业务部门或者职能或治理方面。在此类环境中，某些服务可以在单个域中进行共享或重用，而其他服务可以在整个企业中进行共享或重用。在这些情况下，我们建议采用某种形式的 ESB 联合，该形式的 ESB 联合与域联合的需要相匹配。ESB 联合允许在不同的域中使用不同的 ESB 产品，并支持域需求与产品功能之间的最佳匹配。路线图和参考体系结构应该为任何给定域的产品选择提供指导原则甚至选项，以确保实现企业范围的优化。我们进一步建议使用联合服务注册中心和存储库，为企业范围的管理和可重用服务的治理提供帮助。

您是否需要 ESB 来成功采用 SOA？

前面几个部分说明了从 ESB 开始成功的 SOA 之旅。另外四个入口点不需要 ESB 即可开始该旅程。然而 IBM 认为，无论其入口点是什么，绝大多数成熟的面向服务的解决方案都将包括 ESB，以最大化 SOA 中所需的敏捷性和灵活性。因此，虽然初始项目可以不包括 ESB，但是在您的长期业务和 IT 路线图中，ESB 应该是参考体系结构的一部分，以实现成功的 SOA。如果没有 ESB 提供的敏捷性和灵活性，您会发现在面临不可避免的变更时，管理解决方案将变得非常困难，并且开销很大。

这是否意味着在准备好包括 ESB 在内的所有体系结构组件之前，您还没有拥有真正的 SOA 呢？此问题没有正确或错误的答案，并且可能存在许多选项。在某种程度上，此问题并不重要——重要的是在实现新的 SOA 项目以及解决方案根据您的路线图逐渐变得成熟时，您要渐进地向业务交互越来越多的价值。

我们的客户好像同意这个观点。几乎我们的所有采用 SOA 的客户都从 ESB 开始，或最终在解决方案中使用了 ESB，并从 ESB 支持的灵活性和敏捷性中获得了重大的 IT 和业务价值。

IBM 的 ESB 产品系列

IBM 对 ESB 的重视及其对 ESB 的承诺体现在我们如何使用产品来履行对 SOA Foundation 的承诺上。IBM 推出了一个产品系列，其中包括三个实现 ESB 体系结构模式的产品：

• IBM WebSphere® Message Broker是一个成熟的产品，此产品在多年前就已实现了该模式。
• IBM WebSphere Enterprise Service Bus于 2005 年推出，此产品专门设计用于在侧重于标准的环境中实现该模式。
• IBM WebSphere DataPower Integration Appliance XI50于 2006 年推出，此产品以可容易地部署和管理的工具的形式封装了该模式。

为什么要推出三个产品？同样是由于众口难调。所有三个产品都实现了 ESB 模式，但是分别强调了使它们适合于特定情况的特定功能。您将在developerWorks上找到许多文章和IBM 红皮书®，编写这些内容的目的是为了帮助在面向服务的解决方案中使用这些产品。

结束语

本文再次强调了 IBM 一如既往的信仰，即 ESB 是称为 SOA 的更大模式中的一种基本体系结构模式。您通过阅读本文了解了 ESB 如何帮助从 SOA 获得业务价值，以及 ESB 如何成为成功的 SOA 采用的重要入口点——ESB 模式是如此重要，以致于 IBM 目前在 SOA Foundation 组合中推出了三个实现该模式的战略产品。

　　2005年11月， IBM、BEA、IONA、Oracle、S等几家厂商就合作建立新的业内规范来简化 SOA 应用发展达成了一致，共同发布了两项针对SOA的重要构件模型规范——SCA 0.9和SDO。此后，该团体陆续吸引了Red Hat、普元、TIBCO等多家公司的加盟，形成了OSOA（Open Service Oriented Architecture）联盟，目前成员数量达到18家。OSOA联盟旨在为SOA起草一系列的规范，并以免版税的许可方式提供给业界使用。AP

　　2007年3月，OSOA联盟宣布了SCA和SDO规范中关键部分的完成，发布了SCA 1.0和SDO 2.1，并将其正式提交给OASIS，通过其开放式标准过程进行推动。

　　SCA规范旨在简化服务的创建和合成，对于运用基于SOA方式服务的应用构建十分关键。随着SCA规范的完成，联盟合作厂商希望将其标准化过程提交给OASIS。此外，联盟厂商也已完成了SDO规范，旨在实现对多个站点中多种格式数据的统一访问，并将把SDO基于Java的规范开发和管理提交给Java社团过程（Java Community Process，JCP）组织，而基于非Java的规范（C++）提交给OASIS。

　　SCA和SDO规范能帮助企业更便捷地创建新的以及改造现有的IT资产，使之可复用、易整合，以满足不断变化的业务需求。这些规范提供了统一服务的途径，大大降低了在应用开发过程中，因程序设计语言与部署平台的不同而产生的复杂性。SCA和SDO规范都是用于简化业务逻辑和业务数据呈现的新兴技术。

　　“我们对OSOA联盟取得这一里程碑成就，并选择了在接下来通过开放标准过程继续推动这一重要工作表示欢迎和赞赏，”OASIS CEO和总裁Patrick Gannon说，“我们希望能进一步推进SCA规范，实现标准化，获得最广泛的行业应用。”

　　OASIS不只是研究和产生标准，同时也跟其他国际组织一起合作推动标准的采用和技术的发展。通过十多年的努力，OASIS已经得到广泛的承认，可以直接向国际标准组织、国际电联和联合国相关标准组织直接提交标准提案。

　　SCA是一种规范，它使开发人员可以将注意力集中在业务逻辑的编写上。更直接地说，它是一种大大改进了的部署描述符，它可以使用任何语言而不限于Java。此外，编程人员还可以使用编程式语言和声明式语言，比如BPEL和XSLT（eXtensible Stylesheet Language Transformation，扩展样式表转换语言）。SCA的特别之处在于，它对安全性、事务和可靠消息传递之类的特性使用了声明式策略的理念。

　　SCA是专门针对SOA设计的，而不像J2EE只是面向SOA做了修改。SCA关注的是如何描述按照各种编程模型和协议编写的组件所组成的程序集。SCA允许开发应用程序集而不考虑特定的API或具体语言。中间件

　　SCA的核心概念是服务及其相关实现。服务由接口定义，而接口包含一组操作。服务实现可以引用其他服务，称为引用。服务可以有一个或多个属性，这些属性是可以在外部配置的数据值。

　　SCA中的一个关键推动因素是SDO（Service Data Object，服务数据对象）。SDO用于表示业务数据、参数以及服务调用的返回值，当它遍历服务网络时，它还是一种表示数据的方式。注意，也可以使用XML Beans及其他技术。

　　SCA组件被组成为程序集。程序集是服务级的应用程序，它是服务的集合，这些服务被连接在一起，并进行了正确的配置。SCA程序集运行在两个级别：第一种情况，程序集是系统内的一组松散连接的组件；另一种情况，程序集是模块内的一组松散连接的组件。二者的区别在于，一般来说，模块是组件的集合，而系统是模块的集合。此外，系统对应于“大规模编程”（programming in the large或megaprogramming），而模块对应于“小规模编程”（programming in the small），比如构建当今的典型应用程序。

　　将组件连接到它所依赖的服务的方式就是服务网络“装配”的方式。程序集已经在许多技术和框架中广为应用，比如CORBA、J2EE、ATG Dynamo和Spring，也就是说，它并不是新出现的。从这些技术中我们可以知道，程序集提供了许多重要的优点，比如更轻松的迭代开发，以及避免使业务逻辑依赖于中间件容器。SCA使用程序集解决了许多SOA开发中的重要问题，包括：

　　*业务逻辑与底层基础架构、服务质量和传输的分离。

　　*“小规模编程”与“大规模编程”的联系。

　　*为架构的设计、编码和操作性部署在自底向上（bottom-up）和自顶向下（top-down）两种方法中来回切换提供了一种统一的方式。

XML技术自出现以来发展非常迅速，在许多领域内得到广泛的支持而有着广阔的应用前景。例如电子数据交换、电子商务等更是将XML作为一种基础性、支柱性的技术来看待。

1、数据库简史

数据库系统是随着计算机技术的不断发展，在特定的历史时期、特定的需求环境下出现的。在1946年的第一台计算机到20世纪60年代这漫长的20年里，计算机操作系统主要局限于文件的操作，对数据的管理也主要是通过文件系统来实现。进行计算所需要的各种数据存放在各自的文件里，使用这些数据时将文件打开，读取文件中的数据到内存中，当计算完毕后，将计算结果仍旧写入到文件中去，它的不足主要集中在无法对数据进行有效的统一管理。针对文件系统的重要缺点，人们逐步发展了以统一管理数据和共享数据为主要特征的系统，即数据库系统。1964年，美国通用电气公司开发成功了世界上的第一个数据库系统IDS(IntegratedDataStore)。IDS奠定了网状数据库的基础，并得到了广泛的发行和应用，成为数据库系统发展史上的一座丰碑。1969年，美国国际商用机器公司(IBM)也推出世界上第一个层次数据库系统IMS(InformationManagement System)，同样在数据库系统发展史上占有重要的地位。

70年代初，E.F.Codd在总结前面的层次、网状数据库优缺点的基础上，提出了关系数据模型的概念及关系代数和关系演算。在70年代，关系数据库系统无论从理论上还是实践上都取得了丰硕的成果。在理论上确立了完整的关系模型理论、数据依赖理论和关系数据库的设计理论；在实践上，世界上出现了很多著名的关系数据库系统，比较著名的如SystemR、INGRES、Oracle等。

与文件系统相比，数据库系统有几个方面的特点：向用户提供高级的接口；向用户提供非过程化的数据库语言(即SQL语言)；查询的处理和优化；并发控制；数据的完整性约束。

进入80年代之后，计算机硬件技术的飞速提高促使计算机应用不断深入，产生了许多新的应用领域，例如计算机辅助设计、计算机辅助制造、计算机辅助教学、办公自动化、智能信息处理、决策支持等。这些新的领域对数据库系统提出了新的要求。但由于应用的多元化，不能设计出一个统一的数据模型来表示这些新型的数据及其相互关系，因而出现了百家争鸣的局面，产生了演绎数据库、面向对象数据库、分布式数据库、工程数据库、时态数据库、模糊数据库等新型数据库的研究和应用。

2、XML简介

XML推荐标准1.0版发布于1998年2月，之后迅速在全球掀起了XML应用的浪潮。XML是一种描述型的标记语言，与HTML同为SGML(标准通用标记语言，ISO-8879国际标准)的一种应用。由于XML在可扩展性、可移植性和结构性等方面的突出优点，它的应用范围突破了HTML所达到的范围。

一篇XML文档由标记和内容组成。XML中有六种标记：元素(elements)、属性(attributes)、实体引用(entityreferences)、注释(comments)、处理指令(processinginstructions)和CDATA段(CDATAsections)。XML与HTML最显著的不同是XML文档中引入了“文档类型声明”(Document Type Declarations)。DTD使文档可以与分析器交流关于它的内容的元信息。DTD的出现，赋予了XML文档可扩展性、结构性和可验证性，使XML具备了类似于数据库的一些性质，可以利用XML来组织和管理信息；又可以与HTML一样在浏览器中方便地表示，在Internet上高效地传递和交换。考虑到与HTML的兼容，DTD并不是XML文档必需的成份。具有DTD的XML文档称作“Valid”，否则就是“Well-formed”。

目前，处理XML文档的方式主要有SAX与DOM两种。SAX(SimpleAPIforXML)是一种基于流的、以事件处理方式工作的接口。SAX 2.0在2000年5月发布，增强了许多功能，包括对名字空间的支持。DOM(Document Object Model)则是在对XML文档进行分析后，在内存中建立起一个完整的树结构，然后在此基础上进行各种操作。简单地比较来看，SAX对系统资源要求低、速度快，但对文档的操作是只读的；DOM的处理能力强大，但要求大量的系统资源，尤其是对于大的文档。而后还出现了Xpath和Xpointer用以完成XML的搜索和转换；XSL、XSLT和SOAP用以完成XML的远程对象访问，XML Query Languages的出现使XML查询语言可用于任何XML文档。

3、XML与数据库

XML文件是数据的集合，它是自描述的、可交换的，能够以树型或图形结构描述数据。XML提供了许多数据库所具备的工具：存储(XML文档)、模式(DTD，XMLschema，RE1AXNG等)、查询语言(XQuery，XPath，XQL，XML-QL，QUILT等)、编程接口(SAX，DOM，JDOM)等。但XML并不能完全替代数据库技术。XML缺少作为实用的数据库所应具备的特性：高效的存储、索引和数据修改机制；严格的数据安全控制；完整的事务和数据一致性控制；多用户访问机制；触发器、完善的并发控制等。因此，尽管在数据量小、用户少和性能要求不太高的环境下，可以将XML文档用作数据库，但却不适用于用户量大、数据集成度高以及性能要求高的作业环境。

随着Web技术的不断发展，信息共享和数据交换的范围不断扩大，传统的关系数据库也面临着挑战。数据库技术的应用是建立在数据库管理系统基础上的，各数据库管理系统之间的异构性及其所依赖操作系统的异构性，严重限制了信息共享和数据交换范围；数据库技术的语义描述能力差，大多通过技术文档表示，很难实现数据语义的持久性和传递性，而数据交换和信息共享都是基于语义进行的，在异构应用数据交换时，不利于计算机基于语义自动进行正确数据的检索与应用；数据库属于高端应用，需要昂贵的价格和运行环境。而随着网络和Internet的发展，数据交换的能力已成为新的应用系统的一个重要的要求。XML的好处是数据的可交换性(portable)，同时在数据应用方面还具有如下优点：(1)XML文件为纯文本文件，不受操作系统、软件平台的限制；(2)XML具有基于Schema自描述语义的功能，容易描述数据的语义，这种描述能为计算机理解和自动处理；(3)XML不仅可以描述结构化数据，还可有效描述半结构化，甚至非结构化数据。

4、XML文件的存储

XML文件的存储方式有三大类：(1)将文件存储于文件系统(StoringDocumentsinthe File System)；(2)将文件存储于BLOB(Storing Documents in BLOBs)，利用数据库的事务管理、安全、多用户访问等优点。此外许多关系数据库提供的检索工具可以进行全文检索、近似检索、同义词检索和模糊检索。其中某些工具将会支持XML，这样就可消除将XML文件作为纯文本检索所带来的问题。(3)将文件存储于原生XML数据库(Native XML Databases，NXD)。NXD是专用于存储XML文件的数据库，支持事务管理、安全、多用户访问、编程API和查询语言等。与其它数据库的唯一区别在于其内部模型是基于XML的。其中，最重要的存储方式当属原生XML数据库。

4.1、原生XML数据库

原生XML数据库(NativeXMLDatabases)为XML文档定义了一个(逻辑)模型，并根据该模型存取文件。这个模型至少应包括元素、属性、PCDATA和文件顺序。其例子有XPath数据模型、XMLIn-foset以及DOM所用的模型和SAX 1.0的事件。它以XML文件作为其基本存储单位，对底层的物理存储模型没有特殊要求。例如，它可以建在关系型、层次型或面向对象的数据库之上，或者使用专用的存储格式，比如索引或压缩文件。

NXD最适于存储以文档为中心的文件。这是由于NXD保留了文件、顺序、处理指令、注释、CDA-TA块以及实体引用等，而支持XML的数据库XED(XML-enableddatabase)无法做到。XED是在原有数据库基础上扩展了XML支持模块，完成XML数据和数据库之间的格式转换和传输。从存储粒度上，可以把整个XML文档作为RDBMS表中一行，或把XML文档进行解析后，存储到相应的表格中。为了支持W3C的一些XML操作标准，Xpath、XED提供一些新的原语(如Oracle9iR2增加了一些数据包来操作XML数据等)，并优化了XML处理模块。

NXD一般采用层次数据存储模型，保持XML文档的树形结构，省掉了XML文档和传统数据库的数据转换过程。NXD还适用于存储“天然格式”为XML的文件，NXD还可以存储半结构化数据、在某种特定情形下提高存取速度以及存储没有DTD的文件(良构的文件)。

4.2、原生XML数据库的结构

原生XML数据库的结构可分为两大类：基于文本的和基于模型的。

基于文本的NXD(Text-BasedNativeXMLDatabases)将XML作为文本存储。它可以是文件系统中的文件、关系数据库中的BLOB或特定的文件格式。基于文本的NXD与层次结构的数据库很相似，当存取预先定义好层次的数据时，它比关系数据库更胜一筹。和层次结构的数据库一样，当以其它形式比如转置层次存取数据时，NXD也会遇到麻烦。这个问题的严重程度尚未可知，很多关系数据库都使用逻辑指针，使相同复杂度的查询以相同的速度完成。

基于模型的NXD(Model-BasedNativeXMLDatabases)是根据文件构造一个内部模型并存储这个模型。有些数据库将该模型存储于关系型和面向对象的数据库中，例如在关系型数据库中存储DOM时，就会有元素、属性、PCDATA、实体、实体引用等表格。其他数据库使用了专为这种模型优化了的存储格式。使用专用存储格式的基于模型的NXD如果以文件的存储顺序读取文件，其性能与基于文本的NXD相似。

4.3、原生XML数据库的特性

原生XML数据库的特性(FeaturesofNativeXML Databases)有：(1)文件集(Document Collections)，支持集合(Collection)的概念，其作用相当于关系数据库中的表和文件系统中的文件夹。(2)查询语言(Query Languages)，最常用的有XPath(对多个文件的查询作了扩充)和XQL，以及专有的查询语言。(3)更新和删除(Updates and Deletes)，NXD对文件的更新和删除方式从简单的替换或删除现有文件，到修改当前活动的DOM树，以及用于指定如何修改文件片断的语言。(4)事务、锁定和并发(Transactions，Locking，and Concurrency)，支持事务处理。锁定通常是对整个文档的，所以多用户并发性相对较低。问题的大小取决于应用程序以及“文件”的构成。(5)原生数据库提供应用程序接口API(Application Programming Interfaces，APIs)。(6)NXD的一个重要特性是它可以为XML文档提供“往返车票(round-trip)”。可以将XML文件存放在NXD中，而且再取回“同样的”文件。对于以文档为中心的应用程序来说非常重要，因为CDATA部分、实体用法、注释和处理指令是这些文档不可缺少的组成部分。特别是对于法律和医学文件，按规定这些文档必须要保持原样。(7)外部数据(Remote Data)，某些NXD可包含有外部数据，它来自存储在数据库中的文档。通常这些数据通过OD-BC、OLE DB或JDBC从关系数据中取出，模型可以是基于表格的或对象-关系型映射。(8)支持元素和属性的索引。

5、结论

XML技术的出现，使数据处理从文件方式到数据库系统再到文件方式的循环，但新的文件方式已经与最初的文件系统有了本质的区别----格式化文档。XML和关系数据库在数据应用和数据管理方面各有优势。

一方面，我们要研究数据库的新技术、探索数据库的发展方向；另一方面，在数据库的基本实现基础上，添加必要的新技术是探索新数据库的发展方向。

    目前，正当用户们准备引入真正的XML数据库产品之时，Microsoft和IBM等传统数据库厂商已经发起了更加猛烈的竞争攻势。此外，Oracle和Sybase也在努力说服企业IT部门采用自己的下一代数据存储技术以及与之相关的数据管理和应用开发工具。

498)this.style.width=498;" border=1>

热烈欢迎XML

在IDC最近发布的一份报告中，500家受访企业的IT部门中有29%称，正在大量使用XML存储库和数据库；约有同样比例的受访者称，正在探索这方面的使用前景。此外，这项研究还发现XML技术的使用是非常广泛的，包括编辑器、基于XML的电子表格和XML图表等。其中，约有三分之一的受访者都在使用其中的一种技术，其比例与声称正在探索此类技术使用前景的受访问者几乎相同。随着用户兴趣的提高，传统数据库厂商开始调整自己的产品计划，而原有的XML服务器厂商则更加野心勃勃地投身于市场的竞争。

微软公司在2005年年底发布了代号为Yukon的SQL Server 2005。该产品可以存储和处理XML数据，且无须将这些数据转换为关系列和行，更不需要将其存储为二进制大型对象。编程人员可以使用XML Query或称XQuery来检索XML数据。这种语言即将获得World Wide Web Consortium（W3C）的批准。

IBM正在对其DB2 Viper进行测试。该产品可以存储传统的关系数据和XML数据。按计划，Viper将于今年晚些时候正式推出。IBM已经明确指出，Viper的XML数据管理能力完全符合面向服务架构（SOA）的要求。在面向服务的架构中，用户可以使用标准的Web服务界面对程序和所有格式的数据进行分类、查找、访问和使用。

目前，W3C创建XQuery最终建议的工作已经完成。XQuery 将创建出一种标准的查询语言，能够对已经存储的XML数据进行访问和处理。在XML的环境中，该语言相当于SQL语言在关系数据库中的地位，并且可以大幅度地简化XML应用的编程过程。

XML将提高非结构性文件的通用表达能力，这类文件包括文档、报告和表格。Gartner集团高性能市场事业群的副总裁Rita Knox说：“高端出版应用（如航空航天和汽车工业的技术手册）在很久以前就开始使用XML。但目前，XML正在朝着更贴近人们日常生活的领域进军（如银行业）。美国银行业中正在开发一种名为可扩展商业报告语言（XBRL）实现通用的XML表达，主要用于向联邦储蓄保险公司发送资产及负债报告和其他信息。”
拿来做些什么

厂商的热捧并不奇怪，但更为关键的问题是提供内容服务方面能够用XML做些什么事？IDC内容技术项目主管Melissa Webster说，下一阶段的开发工作就正在这些方面作出努力。

大体上看，原有的XML数据库产品和传统数据库中新展现出的XML能力在基础工作方面的表现都非常好，比如良好的扩展性、出色的性能、管理XML文档版本的能力，以及链接内容中各部分的能力等等。但Webster也认为，真正的优势来自两个更高级的领域。其中一个就是连续修改内容，例如将技术手册的更新或修改与工程师创建的注释和说明结合在一起。Webster将这一方面的能力称为配置管理。

其二，是将已存储的XML信息与关键业务流程联系起来。例如处理一份按揭贷款或修理一架喷气式客机，您可以从飞机的CAD工程图纸开始着手，并为发动机维修技师生成最终技术文档，然后将修理单与特定的说明和图纸一并提交给有关的维修人员。同时，维修工作流中的重要事件将被反馈到发动机的维修历史中，并将这些内容写入那些提交给制造商和联邦航空管理局的报告中。

Webster指出：“过去，技术手册与使用它的业务流程相互隔离。在此过程中，需要有人才能把两者联系起来。而现在，则可以借助智能XML内容服务把业务流程和特定内容结合起来。”

这种潜力进一步刺激了原有XML产品厂商在市场中的野心。尽管IBM、Microsoft和Oracle等厂商在这方面的声势很大，但投资者们显然非常看好像Mark Logic这类新兴的XML内容服务厂商。

Mark Logic公司负责客户解决方案的副总裁Max Schireson指出：“如果XML内容只是由XML包装的简单数据，那么，用户就没有理由不用Oracle或Microsoft的产品。” 但是，如果是在复杂的文档和流程中，关系数据库就很难对文档和其他内容实施有效的智能管理了。

比如O'Reilly Media公司使用Mark Logic服务器创建了一个系统。利用该系统，大学教授可以针对不同的课程创建定制的阅读教程。教授们可以对O'Reilly 那些以XML文档形式存储的图书和出版物内容库进行复杂搜索，他们还可以添加一些自己编写的内容，并且根据需要下订单，由出版商负责将其印刷出来并直接交付到教授们的手中。

链接：XML数据库的应用先驱

其实，XML数据库最初只是应用于一种特殊产品。 Command金融出版社是美国纽约的一家金融信息出版商，该公司使用Ixiasoft XML服务器来存储和管理其共有基金客户的募股说明书。每一家客户都有多种基金，因此该公司需要每年出版大量的此类信息。Command公司IT部门的项目管理主管Will Montgomery说：“很多数据都是独一无二的，但其中也有很大一部分对于所有客户的基金来说都是通用的。”

过去，在编写、校对、修改和再次校对等过程中，即使是那些通常应保持完全一致的模板文件也必须经常修改。Montgomery说：“如果客户有100个基金，他们就必须进行数百次修改。” 而在使用Ixiasoft XML服务器之后，客户在Microsoft Word 2003中完成这些修改工作只需一次即可，修改后的内容可随时复制到有关的文档。
现在，Command金融公司正在评估另外一种做法，即在股东报告这种非结构性文件中使用这种技术。

一.学术界与工业界的两种不同索求

Ronald Bourret 在他那篇著名的《XML Database Products》中，将XML数据库产品分为中间件(Middleware)、支持XML的数据库(XML-Enabled Databases)、纯XML数据库(Native XML Databases)、XML服务器(XML Servers)、Wrappers、内容管理系统(Content Management Systems)、XML查询引擎(XML Query Engines)、XML Data Binding、Discontinued products等九种，在业界影响很大。但是，在XML数据库的研究和开发人员眼里，或许只有支持XML的数据库、纯XML数据库能够称得上是真正意义上的XML数据库。支持XML的数据库可以被看做是支持XML数据的数据库系统，它可能是关系数据库、对象数据库等。就在一年半以前，还有相当多的人在争论关系库支持的XML数据库和纯XML数据库孰优孰劣的问题。但是，纯XML数据库却在这种争论中悄然进步，在技术上有了长足的发展。

人们已经越来越倾向于认为XML数据库就是纯XML数据库。随着金融界确立XBRL(XML的一个子集)标准和政府规范电子政务的XML格式，实践推动着XML数据库技术不断向前发展。

XML数据库系统从最初简单的查询引擎，不断地加入查询优化、事务处理、触发器、并发控制、代数系统等传统的数据库技术，一步步地从性能和功能上完善自己。

从目前XML数据库的产品情况来看，学术界的实验系统和市场产品之间有着些许微妙的差别，尽管它们的主流技术是一致的。

学术界完成的实验室原型系统一般侧重于下面的一些特点：

● 专注于查询性能的提高，对查询优化的研究较多。为了提高查询效率，学术界十分重视索引结构的设计，先后提出二十几种适合于XML数据的索引方式，比如影响很大、简单易用的三元组索引，并在此基础上开发出了以结构化联接为基础的查询模式匹配方法。

● 强调平台无关性。在XML数据库研究的早期，业界曾存在一个争论:到底将XML数据存储在关系库中，还是另外开发存储XML的物理数据库。这在一定程度上影响着XML的研究者，在设计索引结构时必须考虑使索引过的XML数据可以存储在多种数据库结构中。

● 从理论的角度较多地考虑了XML数据库的模式设计规范化问题。设计了基于键的函数依赖推理，在如何优化XML数据库设计、消除数据冗余和不一致方面有了一些实质上的进展。

工业界的XML数据库产品更加强调实用，有着一些与学术界原型系统不尽相同的特点：

● 现有的主流XML数据库产品都在底层提供collection数据结构，以存储XML元素节点，通过B+树结构来索引这些元素节点。这一点与关系库系统的底层处理如出一辙。在collection之上一般还会有一级或两级索引，以加快查询处理速度。这一点比平台无关的实验原型系统更高效实用。

● 市场上的数据库产品通过引入日志管理，建立了较完善的事务处理机制，这为上层的数据库应用开发提供了便利。目前的商用XML数据库一般提供事务处理功能，包括提交、回滚和日志文件。通过提供事务日志机制，纪录系统执行的每个事务的详细情况，保证在系统出现问题后可以完全恢复。

● 增强了对异构数据源的集成管理。树型结构的XML数据有其难以管理的一面，但是，XML技术的可扩展性又使得它具有集成异构数据源的强大能力。因此，市场上的XML数据库产品普遍具有较强的集成多种数据源的功能。这也是当前市场上的XML数据库产品的一大亮点。

二.实验室的原型系统和商用化产品

最近几年以来，在学术界和工业界的共同推动下，如雨后春笋般诞生出大量的XML数据库原型系统和商用产品。

在Ronald Bourret的《XML Database Products》中一共列了36种XML数据库产品，大致上可分为三大类型：

● 商业类(commercial)：如Ipedo、Tamino、Natix、Xyleme等。其中，美国Ipedo公司的Ipedo XML Database和德国Software AG公司的Tamino是其中的佼佼者，成为目前市场上的主流产品。

● 研究类(research)：如Stanford大学早期开发的Lore等。

● 开放源码类(open source)：其中影响较大的是Berkeley DB XML、dbXML、XDB和Xindice。

需要指出的是， Lore database systems 只是Stanford大学早期针对半结构化数据而开发的数据库系统。Lore连同其专设语言Lorel都是为半结构化数据而写的。尽管说XML数据在某种程度上也是一种半结构化数据，但是，两者之间还是有着一些差别，导致Lore database systems很难成为一种完全意义上的XML数据库系统。

事实上，在学术界，真正受到关注的XML数据库原型系统有三家：密歇根大学安阿伯分校的Timber、西雅图华盛顿大学的Tukwila和威斯康星大学麦迪逊分校的Niagara。其中，影响最大的是Timber，在该系统的实施过程中，产生了许多有关XML数据库的新的概念和方法。当然，多伦多大学的Tox也是一个相当不错的系统，尤其是其出色的索引结构。但是，总体上不如前面的三家有名。

三.核心技术的进展

综合XML数据库的实验室原型和商业产品的共性，XML数据库的核心技术主要包括：

1.查询语言

自从1995年XML技术的研究和开发逐渐升温以来，形形色色的XML查询语言不断问世。比较有代表性的如早期的XML-QL、XQL、UnQL，后来的Quilt、Xpath，以及由Quilt发展而来的XQuery。在W3C的极力推动和学术界、工业界的大力支持下，XQuery逐渐在这些查询语言中脱颖而出，成为事实上的工业标准。

XQuery的FLWR语句规范，有着与关系数据库的SQL完全类似的表达方式，使得它在一般用户眼里，也变得友好起来。

而Xpath可以理解为是XQuery的一个子集。Xpath表达式在相关文献中被证明与查询模式树是等价的，这也与学术界推崇的模式树查询方式一致，使得实验室系统可以毫不困难地处理Xpath查询表达式，并能进行查询优化。这一点在XML数据库研究中显得颇有价值。

2.XML文档解析

在图1中，将XML文档载入数据库时，会经过一个XML数据解析器。数据解析器会依据一定的规则对XML数据进行解析后装入数据库。目前的数据解析器一般提供SAX(simple API for XML)和DOM(document object model)两种方式。

SAX和DOM是针对XML文档的两种不同的应用程序编程接口API。SAX更多地依赖语法制导(syntax driven)，而DOM则提供一组功能程序来开发与XML数据相关的应用。

SAX解析器是边读入边解析，带有一定的实时性，特别适合于XML流数据的处理。而DOM解析器是待整个文档均导入内存后才开始解析，在一定程度上受到内存容量的限制。目前的XML数据库产品均支持这两种解析方式。

3.查询处理

查询处理的方式和效率，一直是XML数据库研究和开发者关注的首要问题。

如图1所示，XML数据库的查询处理一般是从解析查询语言(如XQuery)的查询语句表达式开始的。XML数据库的查询解析器将表达式解析为一棵查询模式树(有的系统叫做语法树)。

假设一个XQuery表达式为：

book [tittle = ‘XML’] // [ year = ‘2000’]

它所对应的模式树如图2所示，它表示我们要查询的 book节点满足下面的条件：

● 有一个子节点tittle，它的内容为串值XML;

● 它有一个后代节点year，它的内容为串值2000。

从语义上来说，就是：查找“一本2000年出版的、名为XML的书”。

接下来就是到XML数据库中去匹配这棵树，得到最终的XML结果文档。

在如何匹配模式树的技术上，实验室原型系统与商业产品之间有着一些差别。

比如，在Timber中，考虑了一种叫做“结构化联接”的技术。它的基本思路是将上述的模式树分解为二元关系序列。而在此之前，也已经将XML文档库做了索引处理，文档中每个元素节点均被标以一个三元组索引，形式为：(文档标识符，开始位置：结束位置，层号)。

于是，该查询模式可以分两步来完成:在索引过的XML数据库中匹配上述分解的二元结构关系;将查找到的二元结构匹配结果组装(stitching)成最终的符合上述查询表达式的完整文档。

结构化联接技术在2002年被提出并在Timber中实现以后，在学术界引起过较大的反响。自2002年以来不断有技术上的改进文章出现在数据库的三大国际会议(VLDB、SIGMOD/PODS、ICDE)上，其中较有影响的成果是隐检整枝联接(holistic twig join)技术，可以用相互连接的多栈结构一次性生成查询结果文档。

在商用产品中，由于文档元素节点均存储在B+树结构中，可以直接到底层的数据库中去查找相关的匹配节点序列，再根据其指针关联，将结果节点集组装成结果文档。

总的来说，实验室产品在输入节点序列较长时效率会较高，尤其是隐检整枝联接技术。而商用产品在查询的文档较大时更显优势。

在查询处理阶段，实验室产品做了而商用产品没做的事情就是模式树的最小化。它的主要思想就是，模式树的匹配效率依赖于模式树的规模(元素节点的多少)。而一般的模式树均存在一定量的冗余节点，可以通过最小化算法予以去除。

根据复旦大学数据库研究中心XML小组的实验结果表明，在随机建立的XML查询模式树集合中，最小化算法平均可以消除30%的冗余节点。

当然，模式树最小化算法的时间复杂度比较高，目前的关注点主要在于时间复杂度的降低上。最新算法的时间复杂度已经降低到低阶的多项式时间了。这项技术的实用化是值得期待的。

4.事务处理和版本控制

目前的商用XML数据库一般提供事务处理功能，包括提交、撤回和日志文件。我们知道，事务为数据库的一组操作，这些操作组成一个逻辑单元，执行时要么全部完成，要么全部不做(do all or do nothing)。XML数据库通过提供事务日志机制，纪录系统执行的每个事务的详细情况，保证在系统出现问题后可以完全恢复。

事务遵循的ACID性质 (原子性、一致性、独立性和持久性) 保证了大部分事务处理稳定地运行。

商用XML数据库也包含对XML文档的版本控制功能。使用版本控制，用户或应用程序可以检入(check in)或检出(check out)XML文档，利用版本号、日期或者标签获得以前版本的文档，以及显示XML文档的版本历史信息。每一个处于版本控制之下的文档都有自己的历史信息，纪录了修改文档的作者以及时间等。使用者可以根据文档或用户或日期来查看整个的版本历史信息。

版本控制允许用户通过查询更新原信息。通过更新引擎可以注释、修改和精炼信息。内置的版本系统跟踪信息的变化，提供这些变化的历史信息。

应该说，在事务处理和版本控制机制上，实验室产品的考虑是不够的，所提供的事务处理的功能显得简单。尽管加州大学洛杉矶分校的数据库实验室在XML的版本控制方面有一些突出的成果，但是，目前尚未形成产品。

还有一个需要说明的是多事务并发控制机制和加锁协议。这项技术的研发目前刚刚起步。现今的商用XML数据库只在逻辑层面提供并发加锁协议，但粒度为整个文档。随着单个XML文档的增大，这个粒度显然太粗。这一点可能要等待研究界开发出粒度为文档元素节点的并发协议了。

5.代数系统和模式规范化

代数表达式和数据库模式设计理论曾经是关系数据库理论的精髓。代数系统成为关系库查询优化的重要工具，而范式理论的提出也曾为RDBMS设计优化的库结构提供了依据。那么，人们不禁要问，在XML数据库中是否存在相类似的理论和方法?

由于这两个问题有一定的难度，注定只能是由学术界的实验系统先行一步。

学术界公认的三大实验系统都设计了相应的代数系统，其中影响最为广泛的是Timber中实现的TAX(Tree Algebra for XML)。TAX以整个文档树作为操作的基本单位，在逻辑层提供选择、投影、联接等类似关系库的9种基本操作和5种附加操作，以匹配模式树得到实例树(witness tree)为基本操作方法。在物理层提出7种基本操作实现上述逻辑运算。

Timber依据TAX对XML查询语句进行改写和优化，但是效果并不理想。业界对TAX存在问题的看法是，过分地模仿了关系库的代数系统而忽略了对XML文档本身特点的考虑。

XML模式规范化理论的早期开拓者是宾夕法尼亚大学的樊文飞等人。从定义XML的键(key)和函数依赖，到XML和DTD范式，再到基于约束的XML数据库的模式规范化，XML数据库的模式规范化理论在稳步地推动着。国内的复旦大学数据库研究中心等单位也有着不错的研究进展。在未来两年内，估计会有较成熟的XML数据库模式设计理论投入到实验室产品和商用系统中。

6.多数据源的集成

多数据源的集成是数据库市场对XML数据库系统提出的要求。从1970年IBM公司的E.F.Codd提出关系数据库的概念以来，关系数据库在几乎所有的应用领域都取得了巨大成功。XML数据库是一个新事物，它从诞生的那一天起，就面临着关系数据库一统天下的局面。有人说，关系数据库完全战胜层次和网状数据库用了将近20年时间，XML数据库也会用20年时间战胜关系数据库。这种看法并不全面。至少从目前来看，两者应该各展所长，共同服务于巨大的数据库市场。

那么，XML数据库的优势在哪呢?用XML技术来进行多数据源的集成就是其中之一。

从2001年以后，面对多数据源的集成这个传统关系型数据库系统做不了的事情，Ipedo等商用数据库系统将自己的数据库系统扩展为一个集成平台，它可以将关系数据库系统、MIS系统、OA系统、文件系统等集成在同一个平台上，给用户提供统一的界面。如Ipedo公司的Ipedo XML智能平台，为用户提供XML View来统一访问底层的异构数据。人们也从这一点上进一步看到了XML技术的力量。

四.未来的技术发展方向

经过近5年业界同仁的共同努力，XML数据库技术取得了很大的进展，已经有若干种XML数据库产品问世并服务于社会生活的各个方面。但是，XML数据库的事业才刚刚开始，还有很多问题等待着我们去解决。

未来几年，XML数据库技术有可能在下述方面取得进展：

● 异构数据源的集成。XML数据库对多数据源的集成，是对XML技术可扩展性这一长处的极好发挥。但是，就目前的集成程度和在应用层上所提供的功能来看还是远远不够的。如何从对数据的集成过渡到对系统的集成，从而在远景目标上实现类似于网格计算(grid computing)概念的系统，恐怕是XML数据库工作者的核心任务之一。

● 底层索引结构。目前的商用XML数据库系统优于实验室原型系统的特点之一就是其底层的索引结构。但是，现有的商用XML数据库的底层索引结构一般都是B+树。虽然B+树索引是一种成熟的索引结构，但是，研究结果显示，在XML数据库中，它的性能表现并不是最好的。学术界已经开发出了若干种适用于XML数据的索引结构，如XR树、XB树等，需要XML数据库工作者来进一步关注。

● 并发加锁协议。在现有的XML数据库系统中，加锁的粒度是整个文档，事务并发的层次也在文档一级。随着应用级文档的日益增大，这个粒度在一定程度上将会成为系统效率的瓶颈。如何通过边锁(edge lock)机制来实现元素节点级粒度的加锁?这一工作现在吸引了不少研究者的目光,而且，上述的锁协议是在逻辑层，如何将它映射到底层的B+树索引(或者XR树索引)上，也是必须要做的一件事情。

● XML模式规范化是一个值得关注的方向。一旦取得突破，将会使我们可以像在关系库中那样方便地设计XML数据库的结构，消除数据的冗余和不一致现象。目前，这一领域已经成为学术界关注的热点。但是，完整的、为业界所公认的理论体系尚未建立。

        在未来，到底SOA将扮演一个怎样的角色？企业千差万别，IT系统又是各具特色，他们该如何寻找SOA路线图？实现“SOA就绪”？怎样让SOA发挥更大的效益？是什么使得CIO们在SOA面前变得永无宁日？ 

　　时下，SOA正成为国际大厂商和CIO们共同的热点话题。与此同时，各分析机构乐观预测，SOA将大行其道。但放眼全球，由于缺少更多的成功案例，SOA正逐渐招致CIO怀疑的目光。

　　在未来，到底SOA将扮演一个怎样的角色？企业千差万别，IT系统又是各具特色，他们该如何寻找SOA路线图？实现“SOA就绪”？怎样让SOA发挥更大的效益？是什么使得CIO们在SOA面前变得永无宁日？

　　我们走近大师——SOA的鼻祖人物Eric Newcomer，听听他的声音。

　　来自CIO的质疑

　　2006年，在日本举行的年会上，Gartner公司乐观预测，SOA即将成为应用主流，到2007年，会有超过50%的企业采用SOA体系，到 2010年该比例将会达到80%。但这一乐观预测遭到来自用户的广泛质疑，尤其是在中国，用户对于国际厂商的大玩SOA概念心存疑虑。这到底是为什么？

　　记者：关于SOA的讨论已经很多，众多厂商也在各种场合不遗余力地宣讲SOA，但到目前为止似乎鲜有成功案例，并没有大面积推广起来。甚至有人告诫用户：“如果一个厂商拼命地游说‘我们已经实施了大量的SOA成功案例’，那你就该小心这个供应商的用心了。”持这一观点的不乏SOA标准组织里的顶级专家，在您看来，其中的原因是什么？

　　Eric：许多机构仅凭它们在使用诸如SOAP、WSDL和（或）UDDL等Web服务技术，就认为它们已经采用SOA了，这对用户是一个误导。

　　其实，SOA是一种设计方式，它指导着业务服务在其生命周期（从构思开始，直到停止使用）中创建和使用SOA的方方面面。SOA也是一种定义和提供 IT基础设施（IT Infrastructure）的方式，它允许不同应用之间交互数据、参与业务流程（Business Processes），无论它们各自背后使用的是何种操系统或采用了何种编程语言。

　　从技术上而言，目前已经有很多厂商开发出具备SOA形态的产品，如果一个用户要想从局部实现SOA，比如在企业内部采用SOAP协议实现功能的调用，买一个产品很快就可以实现。但作为一种实现业务和IT高度融合的IT架构方法，“SOA化”是一种很长的过程，一个企业用户肯定需要更长的时间。以 IONA的客户为例，他们在SOA上的计划都是长期的、战略性的。以SOA的关键功能——集成来说，一个企业在长期运营过程中，将不断面对来自这方面的挑战，集成问题正成为那些CIO和IT经理们心照不宣的秘密。

　　其实，在SOA的成功案例方面，由于国外计算机技术发展较早，IT技术在企业业务系统的应用更为普遍；同时对现有系统进行SOA改造，以实现更灵活的IT系统，更好地支撑业务发展的愿望也更加迫切。瑞士信贷集团是IONA的客户之一，也是全球最早成功实施SOA的客户之一。到目前为止，瑞士信贷集团已经取得了令人瞩目的收益。它的生产环境中有1500多个服务，日处理量达到500万笔。由于采用了SOA的技术架构，使系统的总开发和集成成本下降了73％，同时实现了70％的服务重用。SOA是大趋势，我相信这方面的成功案例会越来越多。

　　记者：那到底是什么在影响SOA的进程？

　　从用户角度来看，有很多因素会影响企业接受SOA，其中的主要因素包括：

　　首先，企业必须投入足够的精力和人员进行技术和业务流程的培训，才能确保所开发的服务是可重用的。任何技术，无论看上去多么有前途，都有被误用的可能。任何服务的开发，不能只顾及眼前利益，也要（或许是更重要的）考虑长期利益。换句话说，各个服务的单独存在并无太大价值，除非这些服务能与其他服务一起被使用，并能根据业务的变化，快速组合成各种新的应用。

　　其次是如何更好地处理现有应用与新架构的关系。某些原有的应用需要加以调整或者借用另外的程序后才能融入SOA，应由业务分析师来定义业务流程,由系统架构师来将流程变为规约和规则，再由软件工程师来开发新的代码，而项目经理要跟踪整个过程，这是一项复杂的工作和过程。

　　第三是长、短期成本的管理。构建一个全面SOA的成本并不低，对现有系统进行再工程（Reengineering）的耗费是巨大的，并且回报期也比较长。

　　

SOA与技术无关

　　在SOA的拥趸中，不乏很多的中间件厂商，甚至包含着EAI（Enterprise Application Integration，企业应用集成）厂商，他们都打着集成的口号进军SOA。面对不同的编程语言、技术架构、技术标准和供应商，用户会问，SOA的实现是否与具体的技术有关？

　　记者：我们知道，IONA是包括W3C、OMG、OASISI在内的很多SOA标准组织的成员。目前，倡导SOA的供应商很多，每家都宣称推出了SOA的产品和架构，都提出要引导SOA潮流，这是不是会给您参与制定SOA的标准带来一些困难？

　　Eric：有些人可能会感到惊奇，但面向服务的架构（SOA）确实已经存在20多年了！因为SOA是基于一种设计理念及一系列设计原则的，而这些都是与技术无关——尽管SOA已经应用了这么多年，并遵守着一些公共原则。

　　在过去20多年里，可用于实现SOA的技术是多种多样的，它们包括：分布式对象──CORBA、J2EE、COM/DCOM；面向消息的中间件 ──WebSphere MQ、Tibco Rendezvous；事务处理监控器──CICS、IMS、Encinia、Tuxedo；B2B平台──ebXML、RosettaNet。

　　在这些技术中，有的适于构建SOA，有的则不然。一个技术，如果具有越多“与Web服务平台相当”的能力，它就越适于构建SOA。

　　对于任何用户而言，他们都希望能有一个统一的标准，以提高“技术的经济性”，这就是标准的价值所在，在SOA领域也是一样。一直以来，我都代表 IONA公司在SOA相关标准化组织里做相应的工作。最近，我代表IONA参加了一些标准方面的基础项目研究，IONA对这些基础项目的研究产生了积极而显著的影响。SOA其中的一个标准就是用编程工具来实现这一个技术，从而变成一种独立于厂商、独立于产品的SOA工具。对用户来说，这样实现SOA就会更为简便：比如，包括CA、IBM、BEA 在内其他公司也可以用，但是同时又保持独立。但在SOA发展的早期，很多实力雄厚的大公司都希望其中的SOA采用自己的标准，可是这样其他厂商就没有办法用这个工具。我代表标准组织成员之一IONA投了反对票，因为我们坚信，只有中立的技术，才能使最终用户和IT厂家受益；同时，技术中立也是IONA自始至终坚守的信念。

　　记者：SOA一个重要的功能是集成，以实现企业的信息系统的整合。一直以来，业界都存在着两个相互对立的观点：有人认为SOA将代替传统的EAI，而有人认为SOA概念的成熟将进一步推动EAI厂商的发展，您如何看待这两种对立的观点？

　　Eric：在我看来，SOA是革命性的技术进步，从某种意义上讲，SOA可以被看作是EAI的一种延续，但不是简单的延续。EAI与SOA同样解决企业集成的问题，但SOA解决的问题远比EAI解决的IT问题多得多、复杂得多，因此产生的影响要深远得多。

　　在企业IT系统中，有一部分集成问题是可以通过EAI来解决的。但是，EAI解决集成的问题往往是在事后，企业碰到了集成问题，才去想办法通过 EAI来解决。与之相反的是，SOA架构解决企业集成的问题是事先的，也就是说，企业在一开始搭建SOA这一IT架构的时候，就已经考虑了集成的问题。这是SOA区别于EAI的一个重大不同。

　　另外，EAI解决集成问题时，可能会带来更多其他集成问题，最终会带来一个更加复杂的IT架构。SOA解决这些集成问题时，是将现有的系统以统一的标准接口进行一次重新的梳理，不会再带来新的集成问题。它承认并尊重企业现有的IT架构，不会再引进不能兼容的新的IT架构。SOA会使得企业业务层面更加灵活，企业可以根据现有的企业IT系统的各种服务，组建新的流程，这就是SOA最大的特点之一。

　　记者：那IONA和这些中间件公司又有什么不同呢？

　　Eric：其实，IONA的第一代CORBA产品Orbix就是最早的实现分布式SOA架构的基础架构解决方案，正是这种分布式SOA基础架构解决方案帮助IONA成为这一领域的领导者。在过去几年里，IONA帮助包括德国邮政、美国独立电信公司CLEC、美国证券、荷兰银行、渣打银行、蒙特利尔银行、富士通等在内的航空、金融、制造业、零售业和电信行业领域的多家世界500强企业成功实现了SOA。通过SOA/CORBA解决方案的应用，这些客户都得到非常高的投资回报。

　　IONA的第二代SOA产品就是Artix ESB基础架构解决方案。如何灵活、平滑地构建SOA系统是目前一个具有代表性的IT系统的技术难题。通常用户使用的IT系统由多家供应商提供，编程语言一般要采用java、.NET、C++等，服务器端会采用java、.NET、C++、CORBA等，中间件还会包括BEA的Tuxedo、IBM的WebSphere，甚至还要在大型机上安装包括SAP、Oracle在内的套装软件解决方案。这样复杂的IT系统分布在企业IT系统的不同角落。对用户来说，他们迫切需要用最好的方法，把这些不同的应用、技术、端点进行集成，从而为企业的业务提供最高效的支持。轻量级、分布式SOA架构方式是IONA区别于其他传统中间件公司的最显著特征，IONA公司SOA的这种理念也获得了Gartner的高度认同。

　　同时，技术中立和对其他中间件厂商技术良好的支持也是IONA解决方案的显著特点。一套成功的企业级SOA解决方案要求各个不同的应用程序都能够以安全、可靠、易操作的方式相互集成，而不论他们的底层操作平台存在多大的不同。IONA的Artix恰恰可以做到这一点。

　　

SOA方法论与路线图

　　在很多技术问题之外，SOA的成功实施需要一个企业或组织做大量的工作，也就是说，SOA的实施是一个永续的过程。应该说，每个企业的业务和IT系统都是不同的，是否存在SOA就绪的方法论和路线图？

　　记者：面对SOA，很多用户却不知道如何下手，应该采用什么样的方法？IONA是否从历史案例中总结出经验？

　　Eric：从用户方面来看，“自上而下”和“自下而上”的方法均可以使用。第一种方法是自顶层向下，从业务逻辑开始；另外一种方式就是从底层开始，直接去做代码的编写，然后再考虑如何在上层支持业务逻辑，最后再将其构建成为完善的SOA。总结起来，就是9个字， “思于博，始于细，成其大”，这也是IOAN的企业理念。首先要根据企业的业务需要，通盘考虑需要的SOA架构，用中国的一个成语，叫“胸有成竹”；其次是从一个局部做起，以渐进的方式向SOA架构演进，避免大而全的SOA实施，这样可以最大程度地规避项目风险，降低初期投入；再次就是在局部成功实施 SOA的基础上，构建完整的SOA架构系统。

　　作为全球分步式SOA的领导者，在IONA公司的SOA成功案例中，大多通过分布式的、基于标准的途径实现。其中最主要的特点就是用户可以渐进式地采用SOA。用户根据应用系统的发展情况确定要使用规模，从非常小的局部开始，最后再扩展到整个系统的应用中，不断向大规模SOA演进，获得很大的灵活性。这样做的目的很明显，就是要降低客户初期的以及大规模实现SOA时的成本，IONA不需要企业用户再去购买服务器。具有讽刺意味的是，现在100%的SOA解决方案提供商都希望用户采购他们的应用服务器，然后在这些应用服务器之上去构建用户的SOA体系，用户的成本就大大提高了。

　　其次是使用国际标准，体现可兼容性，体现技术上的中立。可以说，用户业务是随时变化的。因此基于开放标准的解决方案对他们来说至关重要，这样可以广泛兼容现有系统，并为快速响应未来的业务变化打下坚实的基础。

　　记者：企业在实现SOA过程中，应如何发挥SOA最大功效？

　　Eric：应用程序供应商也逐渐采用SOA体系，如Oracle、SAP、i2等企业，这将会使SOA体系得到更为广泛的采用。需要指出的是，虽然SOA的一个核心思想是实现程序和服务的重复利用，重复利用带来的利益可在所有应用程序中实现，但并不是说，SOA体系能够在每个项目中都取得显著成果和效益。

　　一个企业要想最大化地发挥SOA的功效，需要在以下几个方面进行深入思考并做好准备，从而实现“SOA就绪”。

　　1．可能需要建立新的成本/利益模型。

　　2．利用新的团队建立业务框架模型。这个团队对业务进行整体规划和设计（包括BPR在内），打破单个业务使用独立IT系统的模式，特别是那些可以重复使用的，并判断哪些流程适合这一模式。

　　3．要求应用开发商不断提高技能并提供服务。要求应用程序开发商使用多种新的技术开发重用软件、不断提高服务能力正成为用户一项重要的技能。

　　4．建立区别于传统的技术支持中心。

　　我们可以把SOA看作是工厂里的产品装配线。它是一笔对将来业务运营的投入，所以在这笔投入发挥效益之前，需要做相关的计划、设计和开发工作。正如生产线上制造的第一辆车的花费要比第一千辆高出很多一样，用SOA部署的第一个服务所需的花费要比部署第一百个多出很多。SOA的主要优势是逐渐体现出来的，不能一蹴而就。

　　记者：这么说来，SOA对一个企业来说将是一个长期的过程，是什么原因促成SOA过程的长期化呢？

　　Eric：有几个常见的导致业务集成的驱动力使得企业需要在SOA上长期不断投入：

　　兼并与收购：兼并和收购活动常常使得一个企业的CIO解决“有多个IT系统处理相似事务”的问题以体现兼并和收购的商业价值。

　　内部重组：尽管企业内部重组所产生的影响不如兼并和收购那样巨大，但也可以造成许多相似的问题，而且出现的频率更高。

　　应用和系统整合：如果相似的事务可以被多个IT系统处理，这就需要通过合并或者替换，以节省资金，减少人数，让业务操作运营更加流畅。比如一家电信公司有多个不同的计费系统，那合并和简化将是明智之举。

　　不一致、重复和零散的数据的共享：有时候，很多重要的业务数据分布在多个不同系统上。用户必须对它们加以合并和过滤才能有助于决策。比如，销售部门的领导希望员工和客户看到的都是同一个视图界面。

　　新业务战略：一个持续创新的公司经常要根据变化的业务环境贯彻新的业务战略，这就要求原来的各个IT系统能够以崭新的方式一同工作。最终，同行业的其他公司也必须做出同样或类似的改变才能保持竞争力，比如电信行业中的运营商和SP的关系、实时精准制造等。

　　遵守政府条例：为了遵守新的政府条例，企业可能需要重新定义业务流程以保护消费者或符合新的信息披露要求，比如本地电话携号转网和企业遵守萨班斯法案等。

　　保持业务流程流畅：在过去的业务流程中，数据常常需要通过手工录入到不同的系统当中；如今，很多系统都被新的支持“无需人工干预就可以进行多系统间事务处理”的系统所代替。比如，一家公司以前通过传真接收定单，然后手工将定单信息录入到定单管理系统和制造控制系统中；而现在，该公司功过网站接收定单，定单信息被自动录入到定单管理系统和制造控制系统当中。

　　SOA治理（SOA Governance）的目的是让软件治理与业务治理相互配合，包括协调各领域之间的软件开发、软件获取及软件、重用。以取得最大程度的机动性和规模经济性与范围经济性。SOA治理认为服务是整个生命周期都需要管理的企业资产。

　　Eric Newcomer简介

　　Eric Newcomer是IONA科技公司的首席技术官（CTO）, 主要负责指导并协调完成公司技术蓝图以及与标准采用、体系架构、产品设计相关的产品战略规划。Eric有26年的计算机从业经验，其中有15年是在 DEC/Compaq公司度过的。在DEC/Compaq公司工作期间，他担任了各类公司层技术与管理职位。

　　Eric Newcomer是制定SOAP1.2标准的全球广域网协会（W3C）XML协议工作组的创始成员，参与编写了W3C Web服务架构规范，编写了Web服务符合应用程序框架（WS-CAF）系列规范，并担任OASIS组织中的WS-CAF技术委员会联合主席、OASIS 组织和WS-I组织的首席代表。并与Phil Bernstein合作出版了《Principles of Transaction Processing》（1997）， 出版《 Understanding Web Services 》（2002）, 与Greg Lomow共同编写 《Understanding SOA with Web Services》（2004）。