克服 SOA 实施过程中的障碍

Jonathan Mack 说，现在 SOA 实施“并不像许多分析机构或 Web 研讨会所指出的那样普遍”。原因很简单：成功的 SOA 实施是颇具挑战性的。Jonathan Mack 概述了三大挑战：

• 解决早于 SOA 的架构——将现有企业资产整合到 SOA 里去。
• 说服公司采用 SOA——用具体的事实（而不是总体的陈述）阐述为什么 SOA 能够产生与其成本相称的效益，得公司涉众（stakeholders）信服。
• 设计最有效的 SOA 路线图——定义实现 SOA 愿景的过程。

虽然大部分 SOA 实践者们提倡在现有企业应用之上构建一个瘦服务层、尽量重用已经存在的功能，但这样实施的挑战性常常比通常认为的要大得多。Jonathan Mack 指出：

过去构建的遗留系统（legacy systems）是一些零散的批处理或在线处理程序，它们必须按特定的顺序组合起来才能产生有意义的业务功能。那些遗留的处理程序是用于满足实际需要的， 它们常常是根据实际开发流程得到的、而不是与具体的功能相对应。从服务的观点来看，这些程序缺乏一致性和含义。

关于解决这一问题的实际办法，Jonathan Mack 概述如下：

• 为你将构建的服务增加一个瘦服务层作为过渡。所以要创建一些便于插入服务层的组件，以便遗留系统的程序员们可以按他们过去的方式进行工作（即用明确定义的输入输出来设计程序）。
• 从一开始就在服务层中留好监控与异常处理钩子（hooks）。SOA 最重要的优点之一，就是它可以精确监控应用的活动。
• 若服务（service）比点对点的交互（point-to-point interaction）更具优势，那就构建专门的服务。应为服务的构建定义和发布明确的标准。最重要的一则标准就是：该服务存在多个客户。
• 不要迷信卓越中心（Centers of Excellence）。确保拥有一个小型团队，选择成员时应特别注重他们与其他开发者协同工作的能力。从一开始就通过合作共同构建将来作为服务层基础的公共服务。
• 尽量构建直接与主机（mainframe）交互的原子服务，尽量用 ESB 软件来构建合成服务。保持原子服务层与合成服务层的分离。

可重用性（reusability）是 SOA 的一大卖点。不幸的是，这常常是一种信念，而非事实。能够支持这一观点的数据很少很少。Jonathan Mack 说：

要使重要涉众（stakeholders）信服，你的阐述要更加具体才行。虽然用图来解释“SOA 如何能帮助解决错综复杂的 系统所面临的问题”很不错，但公司里的涉众想更具体地知道这一努力将如何产生与成本相称的效益。而且，他们很擅长分辨 ROI 预估里数字的虚实。不论 你采用何种方式实施 SOA，假如你希望被认真对待的话，你就必须提供非常实在的数字。

至于 SOA 路线图，最近出现了两种流行的 SOA 实施途经：

• 企业级（自上而下的）SOA 实施途经：风险很高，最初预算要几百万美元。另外，根据不同的规模与复杂程度，这类项目的耗费基本无法准确预估。
• 草根级（自下而上的）SOA 实施途经：将 SOA 元素（包括服务和基础设施）作为现有业务驱动的 IT 任务来实现。这种途径一般不会成功。一来，最终得到的服务仅限于特定的业务问题，对企业的其他部分来说可能不适用（甚至是错的）。二来，构建 SOA 层所需的时间与开销将有损于项目里的其他业务需求。

Jonathan Mack 提出的另一种途径是：

逐步构建 SOA。大部分厂商已经觉悟过来，认识到了这是最合理的途径。然而，这做起来并不容易。企业服务总线 （Enterprise Server Bus，ESB）的核心元素——对不同系统间的信息进行转换与转化的能力，以及路由消息的能力——以及用于传递消息的消息传递基础设施，这些必须从一开始 就要具备。公共（共享的）服务（如登录、监控和异常处理等）也应该是最早实现的。

SOA 围绕 IT 业吵闹了将近 10 年，由于整体复杂性，至今仍没有万无一失的成功实施方案。每一个新的 SOA 项目“必须有明确的务实态度，必须对成功的实施步骤（及代价）有深入的研究和理解”。

查看英文原文： Overcoming Obstacles in Implementing SOA