登录
注册
浅谈：SOA实施现状及面临的挑战
作者：软件技术交流
日期：2007-09-17 16:04:39
摘要：在过去的几年里，大大小小的许多公司实施了众多的SOA项目，但结果多少让人失望。许多公司渐渐认识到：SOA实施起来比预料的要复杂，不但需要高度关注各个方面的企业数据，还要改变企业文化，程度之深超过以往任何一股技术潮流。
在过去的几年里，大大小小的许多公司实施了众多的SOA项目，但结果多少让人失望。许多公司渐渐认识到：SOA实施起来比预料的要复杂，不但需要高度关注各个方面的企业数据，还要改变企业文化，程度之深超过以往任何一股技术潮流。
众所周知，面向服务的架构不是什么新架构。SOA的几个先行者如通用对象请求代理体系结构(CORBA)和分布式组件对象模型(DCOM)使用松散耦合、面向服务的方法，已经成功地为不同应用架起了桥梁。SOA这股潮流新就新在SOA不仅仅涉及服务。日益兴起的互联网和XML为数据交互敞开了大门。
软件行业以前所未有的力度支持通用的数据交换格式(XML)和互联网传输协议。因而出现了一大批得到公认、开放的标准，它们能够实现SOA的承诺：支持业务流程的灵活配置、减少操作成本、能够动态发现服务，并且在诸多应用、部门和交易合作伙伴之间提供无缝集成。
但很遗憾，让企业和技术人员大失所望的是，SOA的这些美好承诺并没有得到兑现。这倒不是因为承诺本身有什么不对，而是因为如今实施的SOA大多数其本质都是试验性的。好消息是，我们可以从SOA试验项目中汲取宝贵经验，而这些经验有助于SOA试验项目变成能够充分发挥SOA潜力的企业级实施项目。
SOA的目标
我们在探讨通向SOA的道路面临的挑战之前，不妨先退后一步思考，重新分析一下启动SOA实施项目的组织通常有哪些目标。
一、获得流程的可见性和灵活性
席卷全球的SOA潮流无疑是合情合理的潮流。SOA已经逐渐融合了分布式计算领域的几个重大变化。许多组织总是大力投资技术，以便领先竞争对手，而SOA正是提供了这种突破性机会。与此同时，许多组织还一直在改善业务流程，以充分发掘竞争优势。
新出现的业务流程管理(BPM)有望不断改进流程、促进业务部门和IT部门之间实现前所未有的协作。SOA是集大成者，在它的统领之下，多家组织齐心协力，获得全面了解数据和流程的可见性、不断进行改进，并且以一种有效、透明的方式实施细粒度控制。
二、消除孤岛
SOA的第二个目标就是消除应用、部门、交易合作伙伴当中的孤岛(silo)。这些孤岛是由于多年的软件开发工作形成的，SOA有望消除这些孤岛，让组织获得更清楚地了解数据及流程的可见性。
三、管理更准确的数据
一家组织不但需要更有效地管理数据，还需要管理更准确的数据。确保这一点很重要：跨组织及交易合作伙伴生成及使用的数据是干净的、可靠的、安全的、妥善管理的、易于获取的。SOA的目标之一就是，为组合式数据服务平台提供一套统一的组件，这些组件用于数据存取、质量、转换、管理、缓存及其他许多以数据为中心的服务。
四、重复使用服务
SOA的一个相关目标就是有效地管理及重复使用企业的服务和数据。如果由组织内某一部门开发的服务在易于访问的注册中心里面采用标准格式发布并加以描述，它们就可以供该组织内外的其他任何部门使用。如果数据和服务属于所有者，使用者需要时，又可以共享它们，就能减少与维护及管理数据和服务有关的操作成本。重复使用是SOA最主要的优点之一。
五、统一组织目标
SOA的另一个目标就是协调业务部门和IT部门，共同实现组织的目标：有助于更好地开发灵活、可配置的业务流程。在过去，业务部门和IT部门几乎采用独立的方式来提高组织的经济效益。
而作为SOA的一个方面，BPM可以消除业务和IT之间的分歧，因为它采用了业务部门和IT部门之间通用并且都能理解的一套术语，通过建模、模拟、执行和监控等手段，能够不断改进流程。
SOA实施现状
我们已经知道了SOA的目标，现在看一下几个迫切需要实施SOA的行业实例。几个行业如今正面临法规驱动的监管压力，譬如金融服务业的《萨班斯-奥克斯利法案》和可扩展商业报告语言(XBRL)，或者是制药业供应链中的药品“谱系”。
这些法规遵从措施要求各组织从散布于诸多IT系统的孤岛收集数据，有时还要求与第三方的Web服务进行集成。这些数据往往必须进行清理，转换成标准格式，以便能够交换数据。
另一个例子出现在供应链上下游需要应对无线射频识别(RFID)技术的各个IT部门。RFID能够实时监控供应链，从而提高效率、改善运作。不过，大多数供应链和IT应用并不牢靠，因而没法使用RFID提供的实时、细化的数据。正如我们所知，SOA大大减小了集成的复杂性，并且让解决方案的完善能够适应未来需要，又不会给生产环境带来很大影响。
非SOA或者半心半意的SOA方案会导致需要定制集成，这需要大笔费用，还会使系统更加呈现紧密耦合的特性，从而使问题更为严重。
如今，大多数IT部门只是在尝试SOA而已。有些IT部门在小规模部署服务，供内部使用。许多部门正在遗留应用上面构建服务封装器(service wrapper)，以便获得重用性、降低运作成本。不管怎样，SOA实施的重心似乎放在了服务层上。
概念有待澄清
SOA这一术语其实用词不当。SOA与其说是一种架构，还不如说是一套方法，如今，SOA的每一层都有好多种实施方法。AMR研究公司近期的一份调查表明，Web服务是许多组织构建服务的最主要方法，但集成框架、平台、应用服务器和业务流程管理服务器也得到了积极使用。
构建服务层的选择非常广泛，这也许是桩好事；不过对考虑实施SOA的许多组织而言，这也是导致概念混淆的根源之一。
许多组织为了弄明白外人难以理解的技术行话，并且确认合适的服务实施方案，已耗费了太多的时间和精力，结果它们无力顾及行之有效的SOA的其他同样重要的部分，于是决定仅仅构建服务层，迫不及待地想感受投资带来的好处。
结果，实施的这些SOA到头来成了概念证明而已。它们并没有经过精心考虑，也无法解决重要的问题，如可扩展性、安全和治理。
成功实施企业级SOA面临许多挑战。许多组织把大部分精力用在了服务层上，但构架的核心部分：SOA注册中心和存储库却设计得不够好，无法进行有效扩展。
SOA原型证明了潜在的好处，但通向真正的企业级SOA这条道路显得困难重重，大多数组织都不敢上路。企业必须认识到：要发挥SOA的潜力，单单服务层是不够的。组织制订的目标与实现这些目标的SOA各部分之间要有切实的对应关系。
局限和挑战
现在我们不妨分析一下成功实施SOA所面临的种种挑战。
一、文化障碍
消除组织孤岛的目标不仅仅带来了技术上的挑战。许多公司没有为这种理念带来的深层的文化变革做好准备。许多人习惯于完全控制自己使用的特定应用软件的各方面需求。
如今他们却要依赖其他部门提供的服务。如果这种变革未认真处理好，就有可能导致有人对交出控制权心存不满，因为拥有数据和服务的是别人，而不是自己。如果不但与组织里面的部门共享服务，还与外面的交易合作伙伴共享服务，这个问题会进一步复杂化。
二、谁来负责
数据归属权和准确性方面有可能会让人混淆。设想一下：某个应用软件重复使用由另一个部门拥有或者开发的一项服务，这项服务可能反过来会使用属于几个不同部门的其他服务。如果该应用软件因底层服务出现问题而无法正常运行，想想一路查明问题出在哪一方，并且通过层层服务实行补救办法、最终修复应用软件会变得多么困难。
三、实施困难
除了文化和后勤方面的挑战外，成功实施SOA还涉及许多技术上的挑战。单单针对实施服务层，许多组织就在采取暂时性的措施。服务层其实只是SOA的一部分而已。即使如此有限的实施范围，人们也发现实际情况要比预计的来得复杂。他们发现，遗留系统的大小、数量和复杂性使得业务流程配置起来极其困难，这样实现SOA的其中一个主要目标就无从谈起。
新出现的大批服务导致数据管理方面存在可扩展性问题。一小批服务发布到注册中心、使用者发现后加以使用也许很容易。但SOA的真正优点、确实也是面临的挑战在于拥有成千上万的服务，它们必须有效地加以发布、发现及管理。
消除业务和IT之间的分歧、实现业务流程的灵活配置，这需要投资业务流程管理解决方案。可问题在于，正如服务层实施那样，如今BPM实施方面不但选择广泛，还同样让人混淆。
企业级SOA的组成部分
以下概述了实现企业级SOA所必要的几个组成部分。
一、服务层和注册中心
如今实施的SOA大多数关注服务层，进而关注发布及发现服务的注册中心。由于这种架构已落实到位，许多企业已经获得了大大改进的可见性，远胜过Web服务描述语言(WSDL)和UDDI等标准出现之前的时候。遗憾的是，正是由于满足于这种投资回报，大多数实施项目就止步不前——也就是说，等到试图对建立的模型进行扩展的时候，光有服务层和注册中心是根本不足以获得SOA的真正投资回报的。
二、SOA比看起来要复杂
等到通常基于服务层和注册中心的SOA实施项目开始获得一定成效时，IT部门和业务部门就会拼命添加越来越多的服务。发布及使用的Web服务数量急剧增加，这会立即让人把重点放在之前没有预料到的重要功能上。
需要的第一项功能就是联合信息管理功能。服务使用者一下子要面对成百上千的服务，所以需要数据和服务的联合视图，以便了解它们。需要的第二项功能是SOA数据缓存功能。要是没有某种缓存功能，就无法快速、可靠地访问来自SOA实施系统的海量数据。
人们清醒地认识到：数据和服务需要前所未有的治理水平，才能确保有效性，这就需要第三项功能：SOA治理。SOA治理是指定义及执行组织策略和标准的一种方法。这些策略针对诸多业务需求：管理责任和依赖关系、确保业务运作的连续性以及降低成本。因为这些策略定义了控制企业内部数量激增的服务的机制，集成了不断完善的标准，并且促进互操作性，IT部门也能从中得益。
只有组织采用有条不紊、精心制订的方法来满足这些需求，才能真正获得SOA的投资回报。
三、SOA存储库
SOA存储库能够提供的一套服务要比注册中心丰富得多，因为它不但可以访问围绕服务的元数据，还可以访问实际的SOA数据。因而，与注册中心基于元数据的简单服务相比，元数据以及存储库提供的基于数据的发现服务功能要强得多。存储库还提供了把策略管理与转换、联合、抽象及缓存SOA工件(SOA artifact)等功能集成在一起的优点。业务流程和组合式数据服务可以部署在SOA存储库上面并加以管理，以确保它们是集中的、透明的，因而是易于治理的。
由于所有上述原因，SOA存储库是精心设计的SOA的一个核心部分。
四、工作流和业务流程管理
我们前面提到了SOA的一个重要目标，获得业务流程的可见性和灵活性。服务层最能满足这个目标，可使用工作流或者业务流程管理系统。服务层已成为SOA当中发展速度最快的一部分。这个市场的厂商种类繁多，既有专业的BPM和工作流公司，也有企业应用集成(EAI)和应用服务器公司。
组织内部及组织之间流动的数据大部分是XML数据。只有基于最适合管理这种数据的基础设施来进行实施，才能充分发挥SOA的潜力。
经过周密计划的工作流或者BPM产品应当对业务用户和IT部门来说都很便利。它应当提供无需编写代码的流程建模、模拟、执行、监管和调试等功能。
理想情况下，这种产品应当与SOA存储库紧密地集成在一起，那样工作流和业务流程就可以作为元数据来部署，以便集中治理。它还应当支持可重复使用的组合式数据服务的开发、部署及使用。
正确实施SOA
对精心设计的一种面向服务的架构而言，功能齐全的SOA存储库是核心部分。一个良好的SOA存储库能够以原生方式嵌入数据管理和治理服务。它为一部全面的词典提供了语义调和功能。它可以把数据和服务组织成有意义的术语，并且提供生命周期管理和版本控制服务。它还提供了一整套数据服务，可以执行质量管理、验证、转换、联合、治理和缓存等操作。
如果把这些服务部署到SOA存储库上，与业务流程和工作流相关的工件、定制的组合式数据服务以及第三方服务也可以自动使用它们。
在附图中处于显要位置的另一个部分是BPM/工作流平台。应用层能够发现及使用直接来自服务注册中心/存储库层面的服务；也能通过工作流业务流程管理平台，获得更大的灵活性。尽管BPM/工作流平台为诸多应用提供了一套服务，但外部的服务层可以同时对服务进行注册，以便客户发现及使用。
我们已提到，存储库要处理海量的数据，因此，它在设计时应当注重性能和灵活性。如今实施的大多数存储库存在这个问题：它们基于传统的关系数据库，而这种关系数据库根本不够灵活，连中等规模的SOA实施系统带来的查询任务都无法处理。所有SOA数据——工件和消息——都采用XML格式，并且使用层次表示法，这不是非常适合于结构僵硬的关系数据库管理系统。
随着SOA实施系统不断扩展，纳入更多的端点/使用者、编制和用户，这个问题尤为严重。缺少功能强大的存储库还会导致治理和管理工作的复杂化。譬如说，如果想改变注册中心里面的一系列WSDL，使用XQuery的强大查询功能来实现就显得比较简单。因为XQuery可根据查询标准来选择合理的工件，并进行更新。因为SOA中的大多数工件是XML格式，所以需要以原生方式处理所有SOA XML数据的功能。因而，真正响应及时的SOA存储库必须实施在原生XML数据库(XDMS)上，而XQuery用于数据管理。
XQuery是一种非常灵活、功能强大的语言，用于XML数据检索及管理。如果结合原生XDMS(XML数据库管理系统)，那么除了传统方法外，又多了一种处理巧妙、高性能的选择。传统方法针对RDBMS SOA工件存储区，使用传统的解析方法，对XML进行中间层转换，这种转换既复杂，又缓慢。
XDMS可以加快SOA的实施，因为它使数据能够作为原生XML加以存储及处理。当然，不是所有的原生XML数据库其构建方式都是一样的，它们提供的功能也不是都一样的。良好的XDMS应当能够处理各种XML数据，不必事先知道XML模式(XML Schema)的结构。
事实证明，如果处理的XML文档来自数据结构不一的联合系统，那么这种功能就有很大优势。然后就可以在这样一个平台上构建功能强大的组合式数据服务。
用正确的方法使用SOA能够通过按需获得的信息、服务重复使用、流程优化、集成创新的第三方Web服务，获得业务效率、灵敏性及创新。让SOA注册中心和存储库成为SOA的基石，这可以确保企业的SOA基础设施能够得到最佳的管理和治理。
SOA能够实现一系列广泛的用例(use case)，可以跨不同的地理位置和交易合作伙伴涵盖各种系统。回到我们之前探讨的其中一个例子，许多制药公司使用全国药品代码(NDC)作为供应链和监管流程的一部分。如果新药添加、召回或者处方药的专利保护到期，这个NDC数据库就会不断更新。
实施了SOA的企业可以订购应用广泛的NDC数据库Web服务，这样就可以实时更新这些数据，因而新产品推出或者被召回产品从制药供应链撤下时，就可以有效地使用数据，实现灵活应对。
同样，由于监管部门的各种报告需求在不断变化，必须从不同的IT系统搜集数据。基于SOA的方法可以轻松解决这个问题：几个版本的类似Web服务可以在SOA存储库里面得到维护，并且可根据数据参数进行动态选择。
众所周知，面向服务的架构不是什么新架构。SOA的几个先行者如通用对象请求代理体系结构(CORBA)和分布式组件对象模型(DCOM)使用松散耦合、面向服务的方法，已经成功地为不同应用架起了桥梁。SOA这股潮流新就新在SOA不仅仅涉及服务。日益兴起的互联网和XML为数据交互敞开了大门。
软件行业以前所未有的力度支持通用的数据交换格式(XML)和互联网传输协议。因而出现了一大批得到公认、开放的标准，它们能够实现SOA的承诺：支持业务流程的灵活配置、减少操作成本、能够动态发现服务，并且在诸多应用、部门和交易合作伙伴之间提供无缝集成。
但很遗憾，让企业和技术人员大失所望的是，SOA的这些美好承诺并没有得到兑现。这倒不是因为承诺本身有什么不对，而是因为如今实施的SOA大多数其本质都是试验性的。好消息是，我们可以从SOA试验项目中汲取宝贵经验，而这些经验有助于SOA试验项目变成能够充分发挥SOA潜力的企业级实施项目。
SOA的目标
我们在探讨通向SOA的道路面临的挑战之前，不妨先退后一步思考，重新分析一下启动SOA实施项目的组织通常有哪些目标。
一、获得流程的可见性和灵活性
席卷全球的SOA潮流无疑是合情合理的潮流。SOA已经逐渐融合了分布式计算领域的几个重大变化。许多组织总是大力投资技术，以便领先竞争对手，而SOA正是提供了这种突破性机会。与此同时，许多组织还一直在改善业务流程，以充分发掘竞争优势。
新出现的业务流程管理(BPM)有望不断改进流程、促进业务部门和IT部门之间实现前所未有的协作。SOA是集大成者，在它的统领之下，多家组织齐心协力，获得全面了解数据和流程的可见性、不断进行改进，并且以一种有效、透明的方式实施细粒度控制。
二、消除孤岛
SOA的第二个目标就是消除应用、部门、交易合作伙伴当中的孤岛(silo)。这些孤岛是由于多年的软件开发工作形成的，SOA有望消除这些孤岛，让组织获得更清楚地了解数据及流程的可见性。
三、管理更准确的数据
一家组织不但需要更有效地管理数据，还需要管理更准确的数据。确保这一点很重要：跨组织及交易合作伙伴生成及使用的数据是干净的、可靠的、安全的、妥善管理的、易于获取的。SOA的目标之一就是，为组合式数据服务平台提供一套统一的组件，这些组件用于数据存取、质量、转换、管理、缓存及其他许多以数据为中心的服务。
四、重复使用服务
SOA的一个相关目标就是有效地管理及重复使用企业的服务和数据。如果由组织内某一部门开发的服务在易于访问的注册中心里面采用标准格式发布并加以描述，它们就可以供该组织内外的其他任何部门使用。如果数据和服务属于所有者，使用者需要时，又可以共享它们，就能减少与维护及管理数据和服务有关的操作成本。重复使用是SOA最主要的优点之一。
五、统一组织目标
SOA的另一个目标就是协调业务部门和IT部门，共同实现组织的目标：有助于更好地开发灵活、可配置的业务流程。在过去，业务部门和IT部门几乎采用独立的方式来提高组织的经济效益。
而作为SOA的一个方面，BPM可以消除业务和IT之间的分歧，因为它采用了业务部门和IT部门之间通用并且都能理解的一套术语，通过建模、模拟、执行和监控等手段，能够不断改进流程。
SOA实施现状
我们已经知道了SOA的目标，现在看一下几个迫切需要实施SOA的行业实例。几个行业如今正面临法规驱动的监管压力，譬如金融服务业的《萨班斯-奥克斯利法案》和可扩展商业报告语言(XBRL)，或者是制药业供应链中的药品“谱系”。
这些法规遵从措施要求各组织从散布于诸多IT系统的孤岛收集数据，有时还要求与第三方的Web服务进行集成。这些数据往往必须进行清理，转换成标准格式，以便能够交换数据。
另一个例子出现在供应链上下游需要应对无线射频识别(RFID)技术的各个IT部门。RFID能够实时监控供应链，从而提高效率、改善运作。不过，大多数供应链和IT应用并不牢靠，因而没法使用RFID提供的实时、细化的数据。正如我们所知，SOA大大减小了集成的复杂性，并且让解决方案的完善能够适应未来需要，又不会给生产环境带来很大影响。
非SOA或者半心半意的SOA方案会导致需要定制集成，这需要大笔费用，还会使系统更加呈现紧密耦合的特性，从而使问题更为严重。
如今，大多数IT部门只是在尝试SOA而已。有些IT部门在小规模部署服务，供内部使用。许多部门正在遗留应用上面构建服务封装器(service wrapper)，以便获得重用性、降低运作成本。不管怎样，SOA实施的重心似乎放在了服务层上。
概念有待澄清
SOA这一术语其实用词不当。SOA与其说是一种架构，还不如说是一套方法，如今，SOA的每一层都有好多种实施方法。AMR研究公司近期的一份调查表明，Web服务是许多组织构建服务的最主要方法，但集成框架、平台、应用服务器和业务流程管理服务器也得到了积极使用。
构建服务层的选择非常广泛，这也许是桩好事；不过对考虑实施SOA的许多组织而言，这也是导致概念混淆的根源之一。
许多组织为了弄明白外人难以理解的技术行话，并且确认合适的服务实施方案，已耗费了太多的时间和精力，结果它们无力顾及行之有效的SOA的其他同样重要的部分，于是决定仅仅构建服务层，迫不及待地想感受投资带来的好处。
结果，实施的这些SOA到头来成了概念证明而已。它们并没有经过精心考虑，也无法解决重要的问题，如可扩展性、安全和治理。
成功实施企业级SOA面临许多挑战。许多组织把大部分精力用在了服务层上，但构架的核心部分：SOA注册中心和存储库却设计得不够好，无法进行有效扩展。
SOA原型证明了潜在的好处，但通向真正的企业级SOA这条道路显得困难重重，大多数组织都不敢上路。企业必须认识到：要发挥SOA的潜力，单单服务层是不够的。组织制订的目标与实现这些目标的SOA各部分之间要有切实的对应关系。
局限和挑战
现在我们不妨分析一下成功实施SOA所面临的种种挑战。
一、文化障碍
消除组织孤岛的目标不仅仅带来了技术上的挑战。许多公司没有为这种理念带来的深层的文化变革做好准备。许多人习惯于完全控制自己使用的特定应用软件的各方面需求。
如今他们却要依赖其他部门提供的服务。如果这种变革未认真处理好，就有可能导致有人对交出控制权心存不满，因为拥有数据和服务的是别人，而不是自己。如果不但与组织里面的部门共享服务，还与外面的交易合作伙伴共享服务，这个问题会进一步复杂化。
二、谁来负责
数据归属权和准确性方面有可能会让人混淆。设想一下：某个应用软件重复使用由另一个部门拥有或者开发的一项服务，这项服务可能反过来会使用属于几个不同部门的其他服务。如果该应用软件因底层服务出现问题而无法正常运行，想想一路查明问题出在哪一方，并且通过层层服务实行补救办法、最终修复应用软件会变得多么困难。
三、实施困难
除了文化和后勤方面的挑战外，成功实施SOA还涉及许多技术上的挑战。单单针对实施服务层，许多组织就在采取暂时性的措施。服务层其实只是SOA的一部分而已。即使如此有限的实施范围，人们也发现实际情况要比预计的来得复杂。他们发现，遗留系统的大小、数量和复杂性使得业务流程配置起来极其困难，这样实现SOA的其中一个主要目标就无从谈起。
新出现的大批服务导致数据管理方面存在可扩展性问题。一小批服务发布到注册中心、使用者发现后加以使用也许很容易。但SOA的真正优点、确实也是面临的挑战在于拥有成千上万的服务，它们必须有效地加以发布、发现及管理。
消除业务和IT之间的分歧、实现业务流程的灵活配置，这需要投资业务流程管理解决方案。可问题在于，正如服务层实施那样，如今BPM实施方面不但选择广泛，还同样让人混淆。
企业级SOA的组成部分
以下概述了实现企业级SOA所必要的几个组成部分。
一、服务层和注册中心
如今实施的SOA大多数关注服务层，进而关注发布及发现服务的注册中心。由于这种架构已落实到位，许多企业已经获得了大大改进的可见性，远胜过Web服务描述语言(WSDL)和UDDI等标准出现之前的时候。遗憾的是，正是由于满足于这种投资回报，大多数实施项目就止步不前——也就是说，等到试图对建立的模型进行扩展的时候，光有服务层和注册中心是根本不足以获得SOA的真正投资回报的。
二、SOA比看起来要复杂
等到通常基于服务层和注册中心的SOA实施项目开始获得一定成效时，IT部门和业务部门就会拼命添加越来越多的服务。发布及使用的Web服务数量急剧增加，这会立即让人把重点放在之前没有预料到的重要功能上。
需要的第一项功能就是联合信息管理功能。服务使用者一下子要面对成百上千的服务，所以需要数据和服务的联合视图，以便了解它们。需要的第二项功能是SOA数据缓存功能。要是没有某种缓存功能，就无法快速、可靠地访问来自SOA实施系统的海量数据。
人们清醒地认识到：数据和服务需要前所未有的治理水平，才能确保有效性，这就需要第三项功能：SOA治理。SOA治理是指定义及执行组织策略和标准的一种方法。这些策略针对诸多业务需求：管理责任和依赖关系、确保业务运作的连续性以及降低成本。因为这些策略定义了控制企业内部数量激增的服务的机制，集成了不断完善的标准，并且促进互操作性，IT部门也能从中得益。
只有组织采用有条不紊、精心制订的方法来满足这些需求，才能真正获得SOA的投资回报。
三、SOA存储库
SOA存储库能够提供的一套服务要比注册中心丰富得多，因为它不但可以访问围绕服务的元数据，还可以访问实际的SOA数据。因而，与注册中心基于元数据的简单服务相比，元数据以及存储库提供的基于数据的发现服务功能要强得多。存储库还提供了把策略管理与转换、联合、抽象及缓存SOA工件(SOA artifact)等功能集成在一起的优点。业务流程和组合式数据服务可以部署在SOA存储库上面并加以管理，以确保它们是集中的、透明的，因而是易于治理的。
由于所有上述原因，SOA存储库是精心设计的SOA的一个核心部分。
四、工作流和业务流程管理
我们前面提到了SOA的一个重要目标，获得业务流程的可见性和灵活性。服务层最能满足这个目标，可使用工作流或者业务流程管理系统。服务层已成为SOA当中发展速度最快的一部分。这个市场的厂商种类繁多，既有专业的BPM和工作流公司，也有企业应用集成(EAI)和应用服务器公司。
组织内部及组织之间流动的数据大部分是XML数据。只有基于最适合管理这种数据的基础设施来进行实施，才能充分发挥SOA的潜力。
经过周密计划的工作流或者BPM产品应当对业务用户和IT部门来说都很便利。它应当提供无需编写代码的流程建模、模拟、执行、监管和调试等功能。
理想情况下，这种产品应当与SOA存储库紧密地集成在一起，那样工作流和业务流程就可以作为元数据来部署，以便集中治理。它还应当支持可重复使用的组合式数据服务的开发、部署及使用。
正确实施SOA
对精心设计的一种面向服务的架构而言，功能齐全的SOA存储库是核心部分。一个良好的SOA存储库能够以原生方式嵌入数据管理和治理服务。它为一部全面的词典提供了语义调和功能。它可以把数据和服务组织成有意义的术语，并且提供生命周期管理和版本控制服务。它还提供了一整套数据服务，可以执行质量管理、验证、转换、联合、治理和缓存等操作。
如果把这些服务部署到SOA存储库上，与业务流程和工作流相关的工件、定制的组合式数据服务以及第三方服务也可以自动使用它们。
在附图中处于显要位置的另一个部分是BPM/工作流平台。应用层能够发现及使用直接来自服务注册中心/存储库层面的服务；也能通过工作流业务流程管理平台，获得更大的灵活性。尽管BPM/工作流平台为诸多应用提供了一套服务，但外部的服务层可以同时对服务进行注册，以便客户发现及使用。
我们已提到，存储库要处理海量的数据，因此，它在设计时应当注重性能和灵活性。如今实施的大多数存储库存在这个问题：它们基于传统的关系数据库，而这种关系数据库根本不够灵活，连中等规模的SOA实施系统带来的查询任务都无法处理。所有SOA数据——工件和消息——都采用XML格式，并且使用层次表示法，这不是非常适合于结构僵硬的关系数据库管理系统。
随着SOA实施系统不断扩展，纳入更多的端点/使用者、编制和用户，这个问题尤为严重。缺少功能强大的存储库还会导致治理和管理工作的复杂化。譬如说，如果想改变注册中心里面的一系列WSDL，使用XQuery的强大查询功能来实现就显得比较简单。因为XQuery可根据查询标准来选择合理的工件，并进行更新。因为SOA中的大多数工件是XML格式，所以需要以原生方式处理所有SOA XML数据的功能。因而，真正响应及时的SOA存储库必须实施在原生XML数据库(XDMS)上，而XQuery用于数据管理。
XQuery是一种非常灵活、功能强大的语言，用于XML数据检索及管理。如果结合原生XDMS(XML数据库管理系统)，那么除了传统方法外，又多了一种处理巧妙、高性能的选择。传统方法针对RDBMS SOA工件存储区，使用传统的解析方法，对XML进行中间层转换，这种转换既复杂，又缓慢。
XDMS可以加快SOA的实施，因为它使数据能够作为原生XML加以存储及处理。当然，不是所有的原生XML数据库其构建方式都是一样的，它们提供的功能也不是都一样的。良好的XDMS应当能够处理各种XML数据，不必事先知道XML模式(XML Schema)的结构。
事实证明，如果处理的XML文档来自数据结构不一的联合系统，那么这种功能就有很大优势。然后就可以在这样一个平台上构建功能强大的组合式数据服务。
用正确的方法使用SOA能够通过按需获得的信息、服务重复使用、流程优化、集成创新的第三方Web服务，获得业务效率、灵敏性及创新。让SOA注册中心和存储库成为SOA的基石，这可以确保企业的SOA基础设施能够得到最佳的管理和治理。
SOA能够实现一系列广泛的用例(use case)，可以跨不同的地理位置和交易合作伙伴涵盖各种系统。回到我们之前探讨的其中一个例子，许多制药公司使用全国药品代码(NDC)作为供应链和监管流程的一部分。如果新药添加、召回或者处方药的专利保护到期，这个NDC数据库就会不断更新。
实施了SOA的企业可以订购应用广泛的NDC数据库Web服务，这样就可以实时更新这些数据，因而新产品推出或者被召回产品从制药供应链撤下时，就可以有效地使用数据，实现灵活应对。
同样，由于监管部门的各种报告需求在不断变化，必须从不同的IT系统搜集数据。基于SOA的方法可以轻松解决这个问题：几个版本的类似Web服务可以在SOA存储库里面得到维护，并且可根据数据参数进行动态选择。
