SOA（服务导向架构）与其说是一种技术，倒不如说是一种思维方式，它是一项大胆的基础架构变革，帮我们通过技术和协同工作实现了文化变迁。如今，很多CIO都感受到了SOA的热度，福布斯500强中的大部分企业也都在考虑实施他们的SOA方案。然而如何才能成功实施SOA，让这颗看起来很诱人的葡萄吃起来也甜？笔者总结了七大秘诀与读者分享。
秘诀一：大处着眼，小处入手
组织内需要经常维护的地方也许为证明SOA方案的价值提供了大好机会。
SOA在业务方面最基本的承诺是，让企业能够迅速对自己进行重组，因此对用户来说，一开始就要寻找提高灵活性的机会。企业越有活力，从精心实施的SOA中得到的好处就越多；而在SOA方面与你有着同样远景的人越多，就越好。尤其是，如果你的业务管理班子里面有影响力的人知道，降低成本并加强应对变化的能力最终可以为整个企业带来回报，便更会对SOA产生浓厚的兴趣。
这种共同的愿景可能很宽广，不过有必要从小处着手。AmberPoint公司的营销副总裁Ed Horst已目睹了不少过于野心勃勃的项目惨遭失败，所以他建议：“别试图开展太大的计划。我们所见过的最成功的第一个项目都是规模很小的项目，大约6到10种服务把两三个系统集成起来，六个月左右时间就可以完成。”小处着手是SOA成功起步的关键。
秘诀二： 规划合理的业务需求
与相关业务人员一起把诸多流程分解成服务，然后才可以进行各种技术决策。
别指望全靠你自己对业务流程进行分解后，它们就会起作用。应当与相关业务人员合作，一起分析你已经确认的部门里的流程，并进行合理化精简；繁重工作主要应由业务人员来完成，因为他们需要想方设法弄清楚如何重新设计流程。共同明确分解后的流程，然后决定哪些流程有必要实现自动化。
解决办法就是纠正你的基础理念——特别是从旁边关注业务的规划及弹性，提高自身的技术水平，确保设计与需求相吻合。设法建立一个结构清晰，设计合理的管理进程，并能够预见进程的发展结果。
秘诀三： 调查现有资源
认真清点现有的资源，确定你的第一个部署项目会涉及哪些应用和数据源。
现在所有流程开始面对实际技术，你在实施之前，要认真分析可以利用哪些现有资源。SOA的一条基本原则（尤其是在早期阶段）就是，尽可能利用已有资源，避免被可能阻碍将来相互兼容或扩展的方法或技术所束缚。
清点资源是个分阶段进行的过程。首先，你需要把部署的第一个项目涉及的数据源和现有应用登记下来——别忘了防火墙外面你可能需要连接的合作伙伴的服务，也要像对待内部服务一样认真登记这些服务。其次，清查你现有的哪些技术会对SOA起到作用。这确实是一项重要工作，但不一定非要全部完成之后才能实施第一个项目。但如果你的最终目标是SOA，而不是有限的项目，那么上述两个步骤都是不能被忽视的。
SOA涉及一系列广泛的技术，你还应当认真分析所用的商用企业软件的Web服务接口。这方面的技术相当多，但你用不着为需要改变、添加或者保留什么而在技术方面煞费苦心地进行决策。单单弄清楚如何把有关系统之间的数据对应起来并加以规范就够你忙的了。正如洛克希德公司的Timothy Vibbert强调的那样，不同系统之间的数据“可能有15种不同的方式针对同一个数据元素定义15次。”对这些元数据进行调和是项困难而乏味的工作。
即便你在SOA方面不是很在行，对聘请顾问又有所顾虑，也别感到绝望。如果你的企业所用的定制代码并不多，应用的主要是一些现成软件，不妨逐一联系你的软件厂商，向他们讨教SOA的规划和功能方面的意见。你可能会获得将影响项目进度及将来选择平台的宝贵信息。
秘诀四：连接首批服务
选择最适合部署首批服务的平台和协议，同时充分利用现有的技术和技能组合。
现在是进行尝试的时候了。手里拿着规划方案，把某个方面作为试点项目。找出一系列相关应用当中关键的冗余部分，明确规范首批服务，并决定由谁使用哪些工具来构建服务，然后开始提供。测试后，你就可以开始改动应用，以调用新构建的共享服务。
一项服务应当具有哪些特点？洛克希德公司的Timothy Vibbert这样列举：“它们可以重复使用、有契约、松散耦合、没有状态，而且可以被发现。”大多数SOA专业人员会补充：服务还应当是“粗粒度”的，也就是说，它应当对应于某个业务流程步骤或者功能，而不是对应于应用软件组件。这有助于确保可以重复使用，并且避免与其他功能重复。
H&R Block税务公司的Scott Thompson对粗粒度方法具有的价值可是深有体会。他说：“在早期设计阶段，我们开发的服务往往与对象层相一致，而不是与真正的业务服务相一致，所以这些服务的可重用性不如我们当初所希望的。于是我们回过头去，重新设计了许多服务，以提高可重用性。”
譬如说，几个独立应用可能会以各自的方式为顾客开账户。如果创建一种单一的粗粒度服务，那样每个应用可以调用它来开账户，因而可以消除冗余性、减少应用维护。在此过程中，还有可能获得其他好处：更准确的法规遵从信息、使用单一资料库而不是多个数据堆从而提高了安全、加强网站管理。
服务通常作为Web服务来发布，因为定义Web服务的一些标准协议本来就是独立于平台和编程模型的。而实际上，SOA通常可以提供其他类型的服务，譬如可通过Java消息服务（JMS）协议访问的服务。那么你该如何确定使用哪种服务呢？洛克希德公司的Vibbert说：“一方面它取决于有效载荷。如果来回传送的消息数据量比较小，Web服务就很适合。或者如果对时间并不敏感，Web服务可能也是最佳选择。但如果大量的数据来回传送或者对时间敏感，就恐怕不能采用Web服务，而是要构建可以通过JMS或者其他某种二进制协议访问的服务。”
由于Web服务具有兼容性，服务可以部署到Java应用服务器、Windows服务器或者遗留系统本身上，开发人员一般可选择自己偏爱的工具和平台来提供服务。SOA注册服务提供商Flashline的CEO Charles Stack说：“面向服务的架构为你带来的好处之一就是，选择哪种平台并不重要。你可以在服务层改变部署平台，而不会影响面向服务的架构。服务为你免除了基础设施方面的顾虑。如今，这些事情已经不是像以前那样具有战略意义的决策了。”
秘诀五：选择并部署注册中心或存储库
注册中心或存储库提供了发现服务的场所，并且为有关SOA的重要元数据建立了信息交换中心。
许多组织都会部署注册中心作为发现服务的机制，这标志着SOA计划开始启动。注册中心至少可以防止出现重复工作，开发人员只要查看注册中心，就可以确定某项服务是否已经创建。正如洛克希德公司的Timothy Vibbert强调的那样：“注册中心可能只是列出服务的网站。它有可能是通过人工来发现，不过可以发现服务。”
但随着服务及使用服务的应用不断增多，你就需要一个真正的注册中心。哈特福德公司的Ben Moreland说：“我们在2003年选择了通用描述、发现和集成（UDDI）注册中心，在2004年投入使用。我们利用了它的动态绑定功能，为我们提供在客户和服务创建者之间的松散耦合。”
部署的SOA系统大多数采用某种商用注册中心或者存储库，以提供比UDDI规范所定义的功能更深层的功能，目的主要是为了能有一种更加结构化的方式来存储及管理服务元数据。不过让问题复杂化的是，“注册中心”和“存储库”之间的区别相当模糊。通常的定义是，注册中心包含服务方面的数据，如服务位于何处、使用什么XML模式等等；而存储库包含的是服务本身。不过实际上，服务仍在部署平台上使用，所以存储库其实包含较深层次的元数据。另外，注册中心一般都提供存储库的功能，只不过名义上不叫存储库罢了。
选择注册中心很可能是你在实施SOA过程中会遇到的第一个采购决策，也很可能是头一回在单一厂商的方案和最佳SOA方案之间遇到的根本选择。各大平台厂商，包括BEA Systems、IBM、微软、Oracle和Sun都有自己的注册中心或者存储库；但也不乏专业厂商，其中包括Above All Software、Flashline、Infravio、SOA Software和Systinet。视产品而定，你可能会发现丰富的功能：以图形化方式表示Web服务描述语言（WSDL）和服务之间关系的功能、可以限制对某些服务进行访问的基于身份的安全机制、有助于管理服务策略的规则引擎以及更多内容。
说到注册中心或者存储库，David Aubrey认为应当采用单一厂商的产品。Aubrey是总部设在纽约的财务应用软件公司KomatiSoft的高级设计师，他说：“不管你使用哪种框架，厂家都会竭力建议使用存储库。除非绝对有必要，否则我不会使用第三方的替代方案，至少现在不会。关键在于能够与框架和规则引擎兼容，而现有厂商能保证做到这一点。如果引入第三方解决方案，整个协同作用就有可能成问题。”
Flashline的Stack持相反的观点，他说： “如果你使用某家厂商的专有平台，为面向服务的架构搭建基础设施，我认为你犯了重大错误。我们从基础设施的角度提醒所有客户，要重视开放性，因为不然你会陷入窘境：被某家厂商的专有平台所套牢。”
秘诀六：开始处理管理问题
管理服务接口的定义、决定谁将负责哪些服务将成为最大的难题，这对大企业来说更是如此。
注册中心绝不仅仅是这样一种容器：服务由元数据来描述；由客户及其他服务来发现。注册中心也是SOA管理的中心，在这里，IT人员可以列出服务拥有者、管理版本控制、确保符合企业需求以及完成更多工作。你越早开始考虑如何进行管理，就越好。
最好把治理定义成工作流程规则的集合体——谁负责哪些服务、质量保证人员发现问题后采取什么措施，还要管理服务接口的定义。这些定义好比由SOA的破坏作用逐步改变的IT组织图。福雷斯特调研公司的副总裁Randy Heffner说：“你可以把服务接口看成是设计公司业务的基础。它们理应得到重视。”
一家大金融集团一位不愿透露姓名的技术主管称，从根本上来说，SOA是一种新的IT模式。他说：“如果依赖性和复杂性增强，就会带来一系列全新的问题。SOA越是成功，管理就越成为问题。”这位技术主管认为，应当采用分散管理而不是集中管理，类似民主国家的联邦、州和地方各级政府之间的关系那样。
据Moreland声称，2004年哈特福德公司成立了一个企业架构部门，对项目施行管理方法。他说，一开始，管理方法完全涉及部门之间的沟通。“我们头一回让设计师们一起探讨，他们来自不同的业务部门，而解决的其实是同一些问题。现在，我们能做到这点：如果某个项目不符合参考架构或者某个业务部门的蓝图，我们就会停止项目。而我们能够这么做是因为得到了上层管理班子的授权。”
Moreland举了个具体例子说明良好管理可以避免哪几类问题。最近，哈特福德公司的一个业务部门发布了采用相应SOAP格式的一项实用服务。公司的另一个部门运用了这项服务，但之后还要求该服务返回XML里面的两个附加数据值。Moreland回忆说：“那第一项服务的拥有者说：‘我没有资金、预算或者资源这么做。我被其他事情缠住了，没法分身。”他说，在这种情况下，良好的管理就规定，这项服务应当由设有专门队伍的某个部门拥有，为整个企业维护及改动服务。
秘诀七：实施安全计划
在防火墙内部，安全也许比较简单。但涉及多方的交易往往需要基于标准的验证。
几年前行业开始大力宣传Web服务时，人们提出的第一个异议就是：安全怎么样？这是因为，早在那个时候，人们强调的是跨越企业边界的XML集成。相比之下，SOA往往专注于单一企业或者密切相关的企业的架构。在这种情形下，一种基本的假设就是，一切交易都在一个庞大的可信区域里面进行。
福雷斯特公司的Heffner说：“许多人有这样的观点：如果我在防火墙里面进行这种交易，并采用受限制的网段或者其他什么措施，那么我的服务环境没有比较深层的某种安全机制也是可以的。但一旦换成了外部连接环境，大家都说：只有在安全的前提下我才会交易。”
虽然SOA侧重于内部架构，但与合作伙伴之间的企业对企业集成却是自然的延伸。如果需要跨越防火墙，解决方案也许就是使用双向的SSL连接这么简单。不过你在技术方面匆忙下结论之前，Heffner建议你先要确定企业是“轮毂”（hub）还是“轮辐”（spoke）。
Heffner说，轮毂完全有权制定法则。“如果你是沃尔玛，那么作为轮毂，你完全有权规定准备采用什么架构，因为大家都得按你说的来做。”对于作为轮辐的别人来说，“一定要向合作伙伴即你准备连接的人员看齐，看看他们在采用哪种安全架构。
然后确定采用什么策略来实现纯粹的边缘安全，于是你可以使用XML安全网关，在这一层进行验证/授权，”或者实行更深层的安全，那样XML文档在企业内部传送时就可以一路进行验证。
幸好，业界已经为保护传输后的XML消息商定了一种简单的框架：Web服务安全（WS-Security），这也许是仅次于SOAP和WSDL的最常使用的一种Web服务规范。如今，许多企业结合Web服务安全和安全声明标记语言（SAML）令牌，以便在多方交易的每个阶段声明用户身份，这个解决方案对金融服务组织来说特别有用。
另外几种安全规范现处于不同的发展阶段。Web服务信任（WS-Trust）是Web服务安全的延伸，它能确保服务请求者得到了合理验证，才可以确保发放安全令牌。Web服务安全会话（WS-SecureConversation）把来自有效验证的信任关系延伸到了消息群组。而Web服务安全策略（WS-SecurityPolicy）使诸多服务能够交换安全策略，并且协商进行验证和授权，不需要用户干预。虽然这三种规范在XML消息经常跨域传送的环境下相当重要，但都还没有得到广泛应用。
MCI公司的IT首席设计师Bob Laird说：“这是我们在竭尽全力的另一个方面，只有出现了新的标准和方法后，才能简化这项工作。”同时，Laird专注于性能牢靠的外部防御系统，这项工作包括让他现有的基础设施安全管理人员认识到新的流量和交易，并且购买专用的SOA防御硬件，譬如Sarvega公司的XML防火墙。