级别： 初级 Paul Dreyfus, 编辑, IBM
2007 年 8 月 29 日 面向服务的体系结构 (SOA) 的优点，您一定能够耳熟能详了。在您的团队中，有些人说，他们无法理解 SOA，因为它太复杂了。另一些人则说，SOA 是一套可以应对所有 IT 问题的直接有效的解决方案。而您明白，事实就在两者之间，不过您还不确定该如何说服大家。这个月的观点与展望 专栏将为您介绍关于 SOA 的一些真知灼见。
引言：貌似简单，实则不然
 | | 作者 Paul Dreyfus 所述观点仅代表他个人的意见。他在陈述观点时，并不代表 IBM 或 IBM developerWorks 网站，如果他的某些关于 SOA 复杂性及其处理方法的看法与 IBM 和 developerWorks 的官方观点有相似之处，纯属巧合。如有任何看法或问题，可以通过 pdreyfus@us.ibm.com 与他直接联系。 |
|
在我的孩子们成长的过程中，我明白，随着他们年龄的增长，作父母的会越来越轻松。我的两个孩子现在都上了大学，从体力上说，照顾他们已经变得更容易了，特别是在他们拿到驾驶执照之后。不过我发现，从感情和心理方面来说，反而更累了。
比如说，他们会告诉您他们上的课程很简单，无论是做实验还是写论文都是轻而易举。我放松了下来，觉得他们又能拿下一个 A 了，以后他们会一帆风顺，先以优异成绩从大学毕业，再进研究所，然后找一份高薪水的工作，最后早早退休。
几个星期过去了。我常常从间接的渠道发现，这个“简单”的任务变得十分艰难了，结果虽然不至于特别糟糕，但却令人失望。虽然他们俩进入大学已经有一段时间了，但这种模式仍然一再重复着。每次他们告诉我什么东西“很简单”时，我都会产生一种一切顺利的幻觉。我想这使我产生了一种抗拒心理。（幸好，抗拒心理并不在这个专栏的讨论范围之内。）
各大技术供应商的做法就像我的孩子：他们告诉您，他们的解决方案很简单。之后，作为团队里的架构师，您常常只能按照这个“简单”的解决方案进行设计、开发和部署。在整个过程中，您会发现这个解决方案和“简单”这个词其实并无多大关系。那位面相和善的销售代表一直在告诉您，她有一个简单的补丁包，可以解决您的问题。就算您发现上述事实，难道她还会停止对您的游说吗？或者，您难道会从此不再相信她吗？说得更确切点，这难道就能让您的组织里的其他人，尤其是高级管理层改变看法吗？他们会认为这种解决方案本身是简单的，只是 IT 部门把它弄复杂了。
面向服务的体系结构 (SOA) 可能是个例外，大多数人并不会试图说服您，想让您相信设计和构建一个 SOA 是件轻而易举的事。不过，我想您可能不止一次听到过有人说，SOA 是解决所有 IT 问题的灵丹妙药。（好吧，也许它能解决您的所有 IT 问题，但有个问题是它解决不了的，它无法阻止管理层从主要的平台供应商那里源源不断地买进各种“简单易用”的解决方案。）
而且，事情听起来就像是：只要您采用了 SOA，您的 IT 系统一夜之间就能顺利运作了，维护和升级也变得特别容易。而且它们都与业务需求完全一致，能为您的公司节省或是赚下一大笔钱。对于管理层来说，SOA 似乎就是他们需要的所有东西，可以使 IT 完全符合业务目标的需要。他们可能会想，只要您把 SOA 给他们做出来，就能削减 IT 预算，加快项目计划的进展，编写的每一行代码都可实现重用，甚至他们可以因此不再向 IT 投入那么多的时间和资金。唯一的不足是，事实和他们想象的不一样。
这就是本月问题的关键所在：一方面，如果您相信关于 SOA 的宣传定位，您会觉得一切都很简单。而另一方面，一旦您调查了 SOA 的真实开发情况，会发现 SOA 出人意料地复杂。听听那些帮助您部署 SOA 的供应商们是怎么说的，当他们描述您必须要做的那些事情（服务分解、业务流程管理、编排、服务注册中心等等）时，所用的词深奥无比，让您感到晕头转向。与此同时，周围那些对技术缺乏深刻理解的人可能会一边四处奔走，一边想：“太酷了，我们有 SOA，现在一切都变得简单了。”
为什么一个被认为是十分直接明了的东西，最终却变得如此艰深？而另一方面，随着时间的推移，这样复杂的东西又怎能获得支持？
正如观点与展望专栏先前的几期说的那样，我们请 IBM 的 IT 架构师向我们阐述如何既避免使 SOA 变得如此复杂，又不至于使 SOA 方法过于简化。我们先来听听他们的意见，之后我会介绍几点一般的提示，当您着手实现 SOA 时，请把它们记在心里，我会为您提供相关的资料供您参考，使您在复杂和简单之间取得折衷。最后，我们再来看看主要平台供应商们对这一问题负有什么责任，我们将呼吁他们采取措施以改善问题。
下面，我们看看专家们有什么话说。
打好基础
 之所以会出现过于复杂和过于简化的 SOA 解决方案，原因之一是需求管理做得太差。对于某个特定的问题空间，如果某个人不理解其中真正的需要和约束，那么我们有理由认为，他的设计不会特别准确。当然这不是 SOA 所特有的，因为所有系统实现活动都会受到这一问题的影响。不过，在像 SOA 这样受到高度追捧的技术性方法中，有一种单纯为了技术原因就创建解决方案的冲动，而不会仅仅满足于业务需求。这不会使 SOA 的有效性变得荡然无存，它只意味着人们在实现此类设计时必须多加小心。
如果您想避免落入“过于复杂”和“过于简化”这两大陷阱，您需要牢记下面的一些要点：
-
让业务需要成为功能组件选择中的驱动因素。如果您已经有了预定的想法，认为 SOA 解决方案中应当包括集成、注册中心和编排组件，您可能是对的，但您不应该为了这个原因就选择那些实体。您应确保这些元素带来的是一些可靠的设计特性，而且这些设计特性符合某个业务需要。
-
为了建立需求有效性，请确保您使用的是被证明有效的方法。 SOA 需求中使用了大量的新术语，但在核心部分可以（而且应当）用已确立的需求管理实践来验证。例如，有一项实践是通过从不同角度进行分析来审查需求的稳健性。为此，您可以使用 IEEE Recommended Practice for Software Requirements Specifications (IEEE standard 830)，它描述了可用于此类分析的各种特性（分析是否正确，是否明确、完整，是否具有一致性、可验证性、可追踪性等等）。
-
不要因为存在着约束就自动对您的设计进行过分简化：您应当先调查、记录，然后再采取行动。如果您没有更深入地验证核心需求，您可能也没有对给定的约束进行验证。这些约束极有可能是参加项目的某些人士带给您的。请确保这些约束不是由不相干的政治因素、个人意见或技术原因造成的。您可能会在毫无必要的情况下失去业务必需的某些功能。
如果您试图避免出现一个过度简化/复杂的 SOA，我建议您集中精力，先打好基础。这需要您把注意力放在核心的软件工程知识领域（属于需求管理的范围）中。SOA 代表的是一次进化，而不是一次革命：您以前了解的那些用来实现一个良好的解决方案体系结构的各种实践依然适用。
每项有价值的东西都来之不易
 客户常常问我这个问题。首先，我的反应是问对方：“您说的是结构的复杂性，还是因难度过高而带来的复杂性？”
我们先来看看结构的复杂性。SOA 旨在提高业务流程之间和 IT 应用程序之间的模块化和重用程度。用于实现这些目标的方法、工具，以及供应商的中间件产品不应比原先更复杂。无论是 SOA 编程模型还是基础的供应商产品都不会使 SOA 解决方案变得更复杂。反而是解决方案的总体体系结构会采用那些往往会导致结构实现复杂化的 SOA 技术。
开发者常常忘记体系结构才是 SOA 的中心主题。一个 IT 项目要取得成功，IT 系统的体系结构和设计仍然是最重要的因素。下面是一些被证明确实有效的体系结构方法和最佳实践，它们在实现组合应用程序时依然发挥着关键作用。最重要的是，对体系结构不良的现有应用程序中的服务进行扩展，将得到性能不佳的服务。记住，应用程序会把它的性能特性传递给它所提供的服务，并进而传递给客户。
现在我们看看因难度过高而带来的复杂性。对此，我可以很讨巧地回答一句：“之所以复杂，因为所有有价值的东西都来之不易。”而更令人满意的答案，则是设法标识出 SOA 实现中潜在的缺陷，并找出避免出现这些缺陷的方法。我可以提供一些被证明有效的最佳实践，供您在踏上 SOA 之旅时使用。
- IT 管理人员和业务部门必须以战略角度看待 SOA。虽然您可以在 IT 层实现重用的价值，但除非业务干系人能认识到 SOA 的潜力，否则您永远无法也无法发挥 SOA 的全部能力。
- 无论什么形式的 SOA 治理都是十分重要的，它可以确保在业务、应用程序和基础设施层妥善管理服务重用。
- 一个定义良好的企业体系结构会对有效的 SOA 策略提供支持，它可以帮助您将业务任务与 IT 功能联系起来，并保证 SOA 项目的资金投入以支持各项业务活动。
- 有效的服务生命周期管理是十分关键的。在服务注册中心和存储库的使用过程中，如果没有一个定义良好的服务生命周期流程在自动运行，代码库的管理工作会变得更加复杂。
- 如果您使用企业服务总线 (ESB) 网关模式，可以避免出现复杂难解的服务。运用这一体系结构模式，将帮助您对安全需求、数据来源和流程协调进行管理。
让 SOA 成为资产，而不是负担
 “能力越大，责任越大。”（--蜘蛛侠）同样地，灵活性越高，复杂性就越高。SOA 将独立应用程序拆分为组合应用程序，而服务使用者和提供者则运行在多台计算机的多个进程中。部件和部件间的连接越多，出错的机率就越大。我们如何才能对这种复杂性进行管理，使它为我们所用呢？
我相信一个良好的企业服务总线 (ESB) 引擎和服务注册中心引擎可以在处理实时问题方面发挥巨大的作用，它们不但能使 SOA 更为健壮，而且使组合应用程序与它的前身，即独立应用程序相比，可靠性和可伸缩性都得到了提高。我们知道如何使应用程序集群化，以使提供者和使用者变得可靠。方法是，确保使用者在需要时能调用可用的提供者。一个可靠的 ESB 和注册中心将负责这一功能；只要使用者能调用 ESB，而 ESB 能调用多个提供者，那么 ESB 就能对使用者使用可用的提供者的方式进行优化。
组合型 SOA 应用程序和 ESB 还创建了更多需要管理和监控的部件，但它们同时也会创造更多的机会。一个好的监视解决方案，不但应监视每个单独的服务提供者，还能监视服务提供者集群、使用者应用程序（至少可对那些基于服务器和被托管的应用程序进行监视）、ESB 和注册节点，甚至能监视 ESB 中每个服务的各条调用管道。在过去那些幸福的岁月里，我们只需要监视某个应用程序是否运行就万事大吉了，与此相比，现在要监视的东西实在太多了。不过，这也使我们有机会监视粒度更为精细的部件，这令问题的确定变得复杂起来，但同时也变得更富洞察力。
如果是一个独立应用程序停止工作，天知道它里面出了什么问题？不过要是一个服务使用者罢了工，您就可以说出这是因为服务提供者停止工作的缘故，您还能确定是哪个服务和提供者发生了损坏。然后您就可以更准确地解决问题了。一个好的监视软件，当它与 ESB 和注册中心协同工作时，可以检测到出现故障的提供者，并在问题影响到使用者之前就停止对提供者的调用路由。
重用是软件开发中的至宝，它并不是轻易就能实现的。SOA 使重用变得更复杂，但同时也更强大了。代码需要作为专供重用的组件和服务来开发。组织必须跟踪他们的可重用资产，以免重复创建它们。需要以某种方式实现使用者和提供者才能使用经过协商确定的服务 API、格式和传输，或者应针对 ESB 开发中间层。服务版本应当得到管理，以便在旧版的提供者寿终正寝之前，让使用者通过迁移与之分离。开发可重用资产的部门应该有能力将成本转移给因重用该资产而受益的部门。这一切为组织提供了良机，使之能更好地管理资产，增加对资产的重用，但这同样需要大量的工作。
因此，SOA 绝非万能灵药。SOA 在使 IT 与业务保持一致方面大有助益，这对 IT 具有重要意义，它使 IT 成为业务的推动者，而不是障碍。但是 SOA 也需要您付出成本和精力。您要做好准备，以适当的方法实现 SOA，使它成为资产，而不是负担。
降低 SOA 复杂性的一般策略
既然我们的小组成员已经谈了他们的看法，不妨让我来提供一些一般性的方法，它们也许能帮助您消除 SOA 的复杂性。我在这里很小心地选择我的措词：注意我提供的不是一些“简单的提示”或是一个“十佳方法排行榜”。从本质上来讲，SOA 是一种相当复杂的东西，如果有人能提供某种“提示”（听起来似乎很容易）以降低这种复杂性，那么您的必要工作量就能大大减少。可以说，所有这些工作都是物有所值的：最终您会得到一个灵活高效的，基于组件的系统，它一定能使您的 IT 工作与业务目标保持一致。（请了解关于 IBM 的方法和 SOA 的优点的详细信息。关于 SOA 的更多文章和教程，请参阅 developerWork 中的 Architecture 和 SOA and Web services 内容区域。）
下面是一些可供您参考的策略：
清晰的沟通
与先前的许多基于组件的体系结构（CORBA、COM、DCOM、Apple 的 OpenDoc，这些只是其中的一小部分）类似，目前人们倾向于用一种清晰而醒目的方法阐述观点，而不是用一大堆专业术语（或是更难理解的行话）对如何实现观点进行粗线条、抽象化的描述。请访问主要 SOA 供应商的网站：您将看到一些相当优雅的顶级 SOA 描述。例如，IBM SOA 网站上的描述。
不过，如果您深入一点，了解如何开发 SOA 并在它的基础上实现一个系统，那么情况将有所不同。您看到的语言将变得很抽象，很难迅速理解。围绕在 SOA 周围的专业化语言似乎要拒人于千里之外，看来您在弄懂这种语言之前也只能硬着头皮瞎猜了。
之所以会如此，其原因是：SOA 并不适合初学者。它是专供经验丰富的软件工程团队使用的。因此我不会对某个供应商百般挑剔，毕竟大家都在努力改善对如何实现 SOA 的描述的方法。如果您需要一个好榜样，想看看供应商是如何通过努力工作来清晰地描述 SOA 的，那么我会再次建议您访问一个 IBM 网站，这回是 developerWorks 的 SOA and Web services 专区。但不管大家怎么努力，SOA 实现中的细节对于非专业人士而言还是很难理解，这使 SOA 看起来比实际上更复杂。
那么，如果您正在谈论 SOA 或撰写与之相关的文章，您该怎么做呢？不要想当然地以为您的听众或读者具有高级工程学学历或丰富的软件经验。您应该使用简单的语言和术语，句子应当清晰明了，避免使用行话，不要使用高深的业内用语。用简单的语言定义专门术语，其目标是让非专业人士，甚至是外行人也能听懂您的定义。清晰的沟通能帮助您的听众或读者理解您要做什么、构建什么，您的设计是怎样的，SOA 有什么优点，构建 SOA 的难度如何，以及其他必要的知识，以便让他们能够弄清您的 SOA 究竟是什么东西。
最后一点的重要性怎么说也不为过：我们需要那些未承担 IT 职能的非技术型决策者（即高层管理人员）清晰地理解 SOA 的优势。我们希望他们能够认识到，运行良好的 IT 能够带来运行良好的业务，而采用 SOA 则是为了实现 IT 与总体业务目标保持一致而迈出的关键一步。我们希望他们能够理解，SOA 带来了前所未有的 IT 灵活性和高效性。我们要让他们相信，SOA 提供了一条明确的途径，使您可以利用新旧应用程序，将整个业务的人员、流程和信息联系起来。唯有清晰的沟通，才能让他们看到这一切，并说服他们给予您足够的信任，将您在设计和实现 SOA 时所需的资金和控制权交到您手中。
良好的需求
我有一位当木匠的朋友有一句名言：“开始时差之毫厘，结束时谬之千里。”想想看，屋里有一条光束，本来要指向屋子的正中央，但向左偏了一英寸。起先，您想让木料横跨屋顶，但当光束照射到房间的另一端时，如果您按光束的方向放置木料，得到的就只能是一根毫无用处的大梁。
怎样才能让构建者不致于犯下“开始时差之毫厘”的错误呢？良好的体系结构规划，实际上就是对构建需求进行“建模”。那么，有什么东西既能帮助工程师们按原先的设想实现 SOA 构造，又能让系统的业务所有者清楚地理解究竟要构建什么东西呢？这件东西就是清晰的需求，它是由系统设计师和架构师们以清晰明了的方式表述的。
我们的专家指出，对于一个良好的 SOA 实现而言，良好的需求是必不可少的，因此我只要强调这一点就够了，我建议您访问 developerWorks 的 Rational RequisitePro 页面，以获取更多信息，了解如何收集、定义、分析需求并对其建模。
现实主义
也许这一点是显而易见的，用不着多费唇舌，但如果您在 IT 系统中采用了 SOA，那么在其间的任何一个阶段，您都必须确保您的计划和关于这些计划的沟通具有现实性（特别是后者）。不但您本人要讲究实事求是，而且您还要在上司、下属，以及软件和软件的供应商面前坚持现实主义原则。对于您的计划、计划所花费的时间和成本，以及伴随它们而来的风险和收益，您都必须保持现实的头脑。
还记得在我谈论我的孩子和他们的大学经历时说过的吗？采用 SOA 之类的方法是十分诱人的，它看起来十分简单，而且，您可能会认为 SOA 能解决所有的 IT 问题，甚至业务问题也能迎刃而解。而您希望只需对 SOA 投入少量努力，无需为计划付出足够的注意和资源就能取得成功。而另一方面，您也可能把目标定得过高，付出过多，花费大量的时间和金钱，而结果却不尽如人意。
如果您的业务经理访问了 SOA 供应商的网站，他们会得出印象，认为 SOA 能比他们实际期望的做得更多，或是拥有更快的速度，花费的金钱或精力更少。如果 SOA 的表现不如他们预想的好时，您认为谁会遭受责难呢？而另一方面，如果他们认为用 SOA 来完成工作显得过于昂贵、过于耗时，他们会不经深思地就将其拒之门外。
类似地，您的下属也可能形成他们自己的观点，认为 SOA 比它的实际水平更难或更简单。一旦雇员形成了这样的印象，他们就会不高兴或心怀恐惧，这两种情绪使他们很难将工作做好，也使您管理他们的难度加大。
如果您要确保在整个项目中贯彻现实主义原则，您能做些什么呢？信任您的直觉，是一个好的开始。当您或别人说话过于夸张时，您会有所察觉。如果是您自己，请停止信口开河；如果是别人，您要向他们提出质疑。一般情况下，您不应该害怕事实；正如常言所说，事实将赐予您自由。如果您面对不真实的东西保持了一份诚实之心，可能会遭受短暂的痛苦，但总比坚持错误的观点而承受更多的痛苦好得多。当然，您在项目开始时可以采用言过其实的策略，并确保在项目结束（项目失败）之前逐渐改弦易张。我们的同事中总会有深谙这套把戏的专家，我们可能会在知情或不知情的情况下完成所有工作。但作为一名架构师，您大概不会靠着这样的手段来发展您的职业生涯吧。
不过，除了敏锐的直觉之外，还有其他因素能帮助我们采用某个现实的方法：另外，一些正在变得越来越重要的原则也能助我们一臂之力：即我要在下面说到的 IT 和 SOA 治理。
治理
也许我们向专家提出的问题偏离了重点。问题不在于 SOA 太复杂。SOA 的复杂性是无庸质疑的。所以关键是，不要给这些复杂性赋予什么正面或负面的价值。重点在于客观地认识复杂性，更重要的是，如何对其进行管理。从多种角度来说，SOA 的全部意义就在于认识和描述某个复杂的系统，然后为设计、构建和管理该系统提供各种具体的方法。
为了向您提供一些用来认识和妥善管理 IT 系统（特别是基于 SOA 的系统）复杂性的工具，IBM 和其他软件供应商最近对治理进行了大量的讨论。简言之，治理是属于您自己的管理机构，可以用来为 IT 决策制订规则并加以执行。
治理提供的方法能帮助您将本文讨论的策略付诸实践。如果您使用的是一个良好的治理流程和结构，您还必须进行良好的沟通，并将需求准备妥当，而且，您还应保持现实的头脑。治理将确保您和您的整个团队（包括工程师、业务所有者、财务人员等等）既不夸大，也不轻视 SOA 的复杂性，而是正视它，并对其进行管理，使之能为业务的终端服务。
我们在本专栏中已经几次讨论过这一主题：请参阅“观点与展望”专栏的前几期文章，了解更多关于 SOA 关键原则的信息。请先阅读“什么是 IT 管理，为什么应该对其加以注意？”（本专栏的第 5 期）和“定义 SOA 的组成部分”（第 9 期）；此外还可以查看“SOA 治理简介 ”（developerWorks，2006 年 6 月）一文中 IBM 对 SOA 治理的官方定义。
体系结构
任何一位架构师，无论是否是软件从业人员，他的目标都是为混乱的状态提供一种秩序，用具体、完整、易于理解、可沟通的术语定义复杂的系统，以使其他人能构建和维护这些系统。因此，在这种情况下，通过定义，SOA 将不再复杂——如果我们运用得当的话。无疑，SOA 中最重要的一个字母就是“A”（体系结构），如果您认真对待作为一名 IT 架构师的工作，您将不会让您的计划复杂化。是的，系统本身可能会很复杂，但是您的计划对该系统进行了定义，任何人看了这个计划之后都会说：“我明白了。我知道该做什么了。“
总之，问题并不在于 SOA 太过复杂。相反，如果架构师没有把他的工作做好，SOA 的开发工作不是显得太复杂，就是显得过于简单。现在回过头来看看我的孩子们，他们也有同样的问题。当然，在大学学习的确很复杂。我想，我下回见到他们时，会鼓励他们勇敢地面对挑战，对于复杂性，应有客观的认识，既不高估，也不低估，并设计一套方法，帮助他们对这种复杂性进行管理。对于每个设计和实现 SOA 的架构师而言，他们都面临着相同的挑战。
关于专家
Jorge Diaz
Jorge Diaz 是 IBM Software Services for WebSphere® 的一位解决方案架构师。他的工作重点是提供中间件和分布式系统集成领域的策略体系结构，负责欧美地区的相关工作。Jorge 与各个大客户密切合作，帮助他们使用各种技术（包括 Web 服务）来引入面向服务的体系结构。
Andras Robert Szakal
Andras Robert Szakal 是 IBM Federal Software Group 的首席架构师，同时也是杰出工程师和高级认证 IT 架构师。他还是 The Open Group 理事会成员。
Bobby Woolf
Bobby Woolf 是一名 IBM Software Services for WebSphere 咨询师，负责帮助客户使用 WebSphere 实现成功。他与人合著了
Enterprise Integration Patterns
和
The Design Patterns Smalltalk Companion
。请参阅 developerWorks 上 Bobby 的 Blog，以了解更多信息。
参考资料 学习
获得产品和技术
- 使用 IBM 试用软件构建您的下一个开发项目，这些软件可以从 developerWorks 直接下载。
讨论
关于作者 | 
| | Paul Dreyfus 是 developerWorks 团队的一名编辑。他以前曾在 Apple Computer、Netscape 和 Rational Software 撰写和编辑面向软件开发人员的技术材料。本文中的观点是他的个人看法，并不反映 IBM 官方对所涉及主题的态度。如有任何看法或问题，可以通过 pdreyfus@us.ibm.com 与 Paul 联系。 |
对本文的评价
| 
