级别： 初级 Paul Dreyfus, 编辑, IBM
2007 年 5 月 25 日 17 世纪政治理论与计算技术有什么共同之处？通过阅读这篇技术社论，可以了解为何 SOA 是企业 IT 活动的必由之路以及为何治理是 SOA 的核心。
 | |
注意：本月我们将尝试一点不同的东西。developerWorks 编辑 Paul Dreyfus 最近与 developerWorks Live! Technical Briefing 团队合作，在蒙特利尔举行了关于 SOA 治理的会议。通过这次会议，他与客户进行了广泛的接触，并开始考虑 SOA 与 SOA 治理及其在企业 IT 中的地位。在本期的观点与展望 中，他将与我们分享有关此主题的完全不同的看法。
本文中所述观点是作者个人的看法。他并不代表 IBM 或 IBM developerWorks 团队，并无意与 IBM 和 developerWorks 对 SOA 与 IT 治理的官方立场保持一致。如有任何看法或问题，请通过 pdreyfus@us.ibm.com 与作者直接联系。
|
|
引言：SOA 势在必行
您可能已经听到 IBM 和 IT 行业中的其他企业大谈特谈面向服务的体系结构（Service-Oriented Architecture，SOA）：讨论其作为企业软件体系结构样式选项的不可避免性；认为在处理任何与企业软件工程相关的工作而尚未采用 SOA 的情况下，要么必须尽快采用 SOA，要么完全放弃相关工作。您甚至还可能听说过，如果使用 SOA，则还必须进行一些听起来有些模糊的活动（称之为“治理”），否则就会很快发现失去了控制。
很多人之所以这样说，是因为他们想卖点什么东西给你。这样做很正常，毕竟我们生活在商业时代。而您可以决定是否为推销说辞背后的推理所动，并购买与之紧密相关的硬件、软件、工具、服务和咨询。
除了钱之外，SOA 的势在必行以及相关的派生项“治理”背后还有更为深层次的东西。SOA 并不是出色的市场叫卖方式，而是代表了任何规模的企业的企业 IT 的自然发展方向。当然，这些市场卖家完全可能夸大了事实，因此我们此处并不会考虑关于不可避免的 SOA 与治理浪潮，而将讨论让我们处于现在位置的各个因素，并随后讨论如何确保自己舒服地乘浪而行而不是被牵着鼻子走。
控制与创造性
大部分人类活动——包括 IT 开发——都位于控制与创造性之间的连续体上的某个位置。这些活动的产物反映其在此连续体上的位置。例如，汽车、飞机和桥梁是严格受控制的设计和制造过程的产物，此类过程可得到高度可靠的产品。而与另一个极端相近的活动——绘画、音乐和其他艺术形式——反映了思维的自发性和自由，可得到不可预知而经常充满挑战的产品。
其他人类活动及其产物位于这两个极端之间的某个位置。以教育为例。提供教育服务同时需要控制和自发性。如果没有计划（教学大纲），不可能有任何真正的教育，将可能导致一团糟糕。不过，即使遵循最系统、从方法性角度而言非常完善的教学大纲的结果也是不可预测的。彼此非常相似、具有相同的知识或采用相同的方法或从学习过程同等地获益的学生很少。而为人父母也同时需要控制和自发性，其结果也很难预测。在这两种情况下，过多的控制或过多创造性都可能是灾难性的。
在企业 IT 中对两个极端进行均衡
类似地，IT（特别是软件开发）都处于这个极端之间。同样，太多的控制会导致产品对大多数用户都缺乏吸引力。太过强调创造性与自发性，最终会得到很大程度上不可用的系统（无论这个系统本身如何有趣）。
不过，正如您可能已经从所有这些例子认识到的，所有成功的企业都需要在控制与创造性之间求得恰当的平衡。如果汽车的引擎经常熄火或爆炸，则没有人愿意开，而汽车不会爆炸或自动熄火则是采用严格流程的结果。不过，汽车对顾客有吸引力的原因是其体现了设计师和工程师的创造性。
无论如何，不管控制得多么仔细，很多计算机系统都会自动关闭或瘫痪。而这正是这头野兽的本性——对控制（用于获得可靠的软件）和创造性（编写软件所需）进行的均衡目前已导致了无法始终正常工作的产品。而且，此类产品经常难于开发、运行、维护和变更。
这方面有一些非常突出的例外。政府、保健业、银行业及其他行业的 IT 系统均是在绝对强调控制的环境中进行开发的。这些 IT 系统必须高度可靠，开发这些系统的组织投入了大量的资源来确保其可靠性。而此类 IT 系统还有一个颇具讽刺意义的方面：此类系统的开发人员必须在如何完成其工作方面具有极高的创造性。不过他们的生产过程受到高度的控制。
法西斯主义和无政府状态
所有这些人类活动或过程都需要进行监督，以确保过程适合所需的最终结果。从最大的方面而言，这种监督是以政府的形式实现的——监督整个社会和国家如何运转的政治组织。类似地，通过宗教监管，可以规范人们要遵循的活动和各种过程。与此类似的是企业管理团队和培训部门，他们也同样提供规则和指导原则来确保使用对企业目标以及相关人员恰当的方法。
为人类组织提供的监督方式位于另一个连续体上的某个位置——法西斯主义与无政府状态之间。历史上有很多监督（治理）样式的例子。君主政体、邪教和德国纳粹是可以描述为法西斯主义的三个例子，在此类情况下，对参与者极端严格的控制似乎能恰当地确保实现领导人的“宏图大志”。另一个极端则是第一届伍德斯托克音乐节、19 世纪的美国先驱以及小孩的游戏场地等，在这类例外的情况下，至少是在短期内没有规则和秩序可言。（在其中的每种情况下，会很快出现领导者维持秩序；在后面两个例子中，有时候这种“秩序”可能会很快形成法西斯风格的秩序，具体取决于领导者的个性。）
同样，与控制与创造性之间的连续体一样，人类活动通常指示这两种类型的监督之间的平衡。尽管有很多独裁例子，严格控制的组织有的存在长达数十年甚至几个世纪，但法西斯主义的组织违背人类寻求意志自由与独立的天性。任何无政府系统有些像真空，基本上会淹没领导人和任何用于指明方向的规则，尽管如果不对无政府状态的混乱情况进行监视，即使在最受控制的情况下也可能会崩溃。
民主、民治？
在 17 世纪和 18 世纪，哲学家和领导人认识到对治理国家及社会与发达的民主政治系统之间进行均衡的需求。在此类系统中，社会成员认识到了对规则和秩序的需求。他们还认为，如果这些规则和秩序是由社会中的人自己（而不是社会的领导人）决定的，则将最好地满足社会的需求。而且，为了满足控制和自发性/创造性的双重需求，这些组织及其监督规则需要进行更改，以满足社会新成员的需求。
业务和业务的 IT 方面通常也依据这个平衡对自身进行组织。的确如此，大部分企业都采用层次结构，领导者个人可以自己作出影响其属下的很多人员的决策。他们的领导者很喜欢“这不是民主政治”之类的话。但是，通常业务和 IT 监督团队——我们将其称为高层管理——至少会考虑必须执行其决策的人员的需求，因此会采用一种民主的方式。不听取其员工顾虑的问题的管理团队通常会发现，在决策中缺乏此类考虑会导致失败。而且，监督规则和所应用的结构必须灵活，能够满足在不断发展的过程中组织、其文化、业务目标以及市场的需求。
从绿屏到 SOA：发展简史
现在让我们回到 SOA 上（准确地说，是回到 SOA 治理的话题上）。在对此展开大篇幅讨论前，让我们简单地回顾一下过去二十年企业计算发展历史的总体情况，从而了解我们是如何逐步过渡到今天的 SOA 的。
如果回到二十年前，个人计算机当时刚刚在企业中开始普及。如果企业使用计算机，则大部分使用的都是大型的集中系统——如大型机。用户使用“哑”终端（监视器和键盘，具有很少处理能力或没有处理能力）访问数据和应用程序。存在网络，但是主要用于将终端连接到集中式处理资源。没有几个人拥有电子邮件地址，甚至很多人都不知道电子邮件是什么，不过已经在开发和使用广域网 (WAN) 和局域网 (LAN) 系统了。
进入个人计算机时代。突然之间，工作人员有了强大的计算能力，而且有数目不断增加的大量应用程序可用。他们可以按照自己认为合适的方式在自己的计算机上使用、修改、存储和操作数据与应用程序。计算资源开始越来越多地从大型机和其他集中式系统分散。多种平台——不同的操作系统、硬件和体系结构——争夺人们的认可和市场份额。
人们越来越多地开始将所有这些系统连接到网络中。WAN 和 LAN 可用于将从最大的大型机到最小的个人计算机的各种计算机连接起来，以允许用户共享数据、访问文件服务器和进行通信。从很多方面而言，连接性隐藏了技术复杂性，而技术复杂性则由于采用了多种体系结构和硬件及软件系统似乎头绪很乱。这种连接性至少为每个人提供了彼此进行交流的方式（即电子邮件），而越来越多的业务也开始由计算机来完成。
万维网：新体系结构
我们都知道接下来是什么：Internet 的万维网出现了，似乎轻轻一下就将所有这些历史搁在一边了。突然之间所有人都能够方便地进行沟通了。这是一种非常棒的获取信息的方法，而且可以瞬时就获得所需的信息。这同时也是一种极具吸引力的购物方式。能够加入思维方式类似的人们的社区。能够更简单地完成任何事情。
企业现在希望以后将多平台、多体系结构世界的复杂性放在 Web 之后，在这种情况下似乎任何系统都能够与其他系统进行通信。是的，需要编程（正如他们所说，仅仅是编程而已）。但似乎配备了总体计划（称为体系结构）来实现真正的互操作远景，任何应用程序、任何数据集、任何系统都可以使用 Web 访问。
网页模型
似乎看起来很直接，而之所以这样，是得益于网页的简单性。谁又不知道单击蓝色文字或另一个链接来查看图片、更多的信息或其他应用程序（而所有这些都在另一个网页显示）呢？有什么比将代码嵌入网页中以提供对其他功能的访问更简单？
网页连接到服务器，而服务器连接到数据库、其他服务器和其他系统（即使这意味着多个连接与功能层），这看起来很简单的“体系结构”吸引了开发社区和企业。IT 企业必须通过 Web 将所有东西连接起来并提供所需技术，以进一步支持数据、应用程序和系统之间的互连和互操作性——新的与新的之间、新的与旧的之间甚至旧的与旧的之间。
从 IT 体系结构角度而言，Web 似乎承诺能够实现一个长久的远景。多年以来，技术领袖一直在讨论这基于计算机的服务：能够彼此进行通信，能在某个网络上的用户或服务需要时动态地进行组合，并能在需求满足之后断开彼此间的连接。已经提出了多个标准来支持此类方案。现在 Web 似乎成了帮助 IT 实现这个远景的最终交付机制和体系结构，这个远景不仅简化了最终用户的使用，同时也为资源有限的 IT 企业提供易开发性和易维护性。
理论与实践，远景与现实
在企业 IT 世界，似乎没有任何时候比现在更为简单了。IT 人员是否经常提交一组工具、开发环境、体系结构、操作系统、API 或任何东西，声称是“您将需要的最后一个”，最终能通过最少的新代码编写和维护让所有东西协调工作？而很多次所谓的最终全面解决方案之后的远景不过只是远景而已。正如我们常说的，从理论上来说，理论和实践是一样的，但在实践中并非如此。虽然 Web（尽管简单）是整个世界的 IT 困境的唯一解决方案。实际上，“仅仅编程”并不简单。
并非 Web 不能解决很多问题，甚至对企业 IT 也是如此。但通过进一步分析和很多事实，都一再对将 Web 作为基于服务的 IT 世界的支持力量来满足企业需求的远景产生了冲击。具有讽刺意义的是，其中的很多事实都发生在看到 Web 中这样的前景的公司、政府和其他组织身上。一些更为重要的事实如下：
- 以不同方式呈现网页的不同浏览器
- 对访问 Web 具有不同需求的不同设备
- 新技术和标准的大量出现，用以通过 Web 开发和交付信息、应用程序、数据和其他服务，其中一些彼此并不能很好地协作（如果能够工作的话），这包括过去十年左右发展起来的服务器、语言、工具和其他中间件组成部分。
- 身份验证和安全性的严格要求使得很多组织中的用户很难（甚至不可能）使用 Web。
- 对基于 Web 的内容和服务的大量需求会导致不可预测负载和带宽竞争。
- 对很多关键任务的企业应用程序的可靠性和可用性的需求。
- 将遗留应用程序和数据与现代 Web 应用程序集成的需求非常大而且过程极为复杂，同时很多用户从较旧的应用程序迁移到 Internet，因此突然之间互操作性变成了一个大问题，此外，还有带宽、性能和可靠性等问题，在网络成为进行业务的环境时尤其如此。
- 软件资产跨多个服务器分布以及这些资产的组件化可以处理很多此类问题。
- 一个老的工程难题的激化：对软件工程任务的需求以及代码的量似乎在以指数增长，其增长速度随着时间在不断加快（同时，进行这些工作以及编写新代码与维护旧代码所需的工程师的数量以及资金量的增长仅是数学级的，随着时间推移会有稳定的轻微增长）。
互操作性以及缺乏互操作性的老问题并没有消失（尽管 Web 提供了用于进入旧系统的非常不错的机制，但实践表明，创建进入这些旧系统的通路的工作非常困难，而且开销非常大，不值得一试。Web 还提供了另一个很好的机制，用于承载新的基于 Web 的服务。但是，正如前面指出的，其中一些服务彼此并不能很好地协同工作，或者更糟糕，甚至都不能识别彼此。）
现实带来的一种新体系结构样式
另外还有句老话，需要是发明的动力。对于企业和企业 IT，通过 Web 开展业务的需求带来了一个需要。所需要的不仅仅是网页暗示的体系结构简单性。如果要实现基于服务的 Internet，并且可以在其上安全地开展业务，企业则需要相关的标准来确保其计算服务之间的互操作性。为此，IT 世界需要标准来确保解决以下这些当务之急：
- 互操作性。开发团队需要为新服务定义的 API 以及用于“包装”旧服务的代码，以便在新体系结构中对其加以利用。
- 性能和可靠性。需要标准来定义服务如何存储以及如何进行彼此的识别与通信，从而获得可接受的响应时间和保证在正确的时间选择正确的服务。
- 效率。类似地，必须清楚地解决注册与通信问题，以确保在任何时候只会调用和使用需要的服务。
- 代码重用。体系结构需要确保软件服务能够编写一次后多次使用（但同样，只在正确的时间使用），以尽可能提高创建这些服务时所花成本的回报并消除冗余软件。
- 可管理性和可维护性。随着新需求、新用户以及新系统的出现，需要能够有效地修订和维护根据体系结构创建的服务，以便在将来利用这些服务。
- 经济。为了确保 IT 投资不会失去控制。
- 安全性。需要身份验证、加密和总体安全性方案来支持满足业务、政府和其他组织的需求。
- 与业务目标保持一致。最后（但并非最不重要），企业需要知道所有这些工作都能够帮助业务的发展。IT 世界在软件工程方面的投资都会对其所支持的业务造成实际的影响。需要配备流程，用于标识和描述业务需求，从而支持工程师有效地使用新软件服务实现这些需求，以确保新的软件工程工作能对业务造成积极的影响。
而这个标准就是面向服务的体系结构 (SOA)，如果当初没有人定义 SOA，则可能会由其他人以另外一种形式对其加以定义。此类体系结构变成了一种需要。之前定义的体系结构涵盖面不够，不足以满足 IT 的需求。或者过于概略，不够具体，不能为实际的企业提供适用的指导。或者，可能由于其他的原因而使 IT 社区对其的关注不够。SOA 源自 IT 和企业对一种通用方法的需求，以便能够识别和处理性能、带宽、计算容量、可靠性、安全性等等的问题。同时，另一个方面的需求也对其起到了推动作用，即需要让各种数量不断增长的技术和任务通过网络无缝地协同工作。
SOA 是由于现实的需求而产生的。之前的基于组件和基于网络的体系结构代表了具有前瞻意识的 IT 巨头们的远景。每个主要行业提供商和很多不知名的企业和个人都定义了类似于面向服务的体系结构的东西。大部分都声称能带来真正的跨平台互操作性。所提出的所有概念都非常吸引人，但大部分所解决的都是尚未出现的问题。而另一方面，SOA 处理的是行业的难点问题，对企业 IT 和高科技行业中的当务之需作出了回应。的确，IBM 是 SOA 的主要支持者，但从很多方面而言，这个标准源自广大的 IT 世界及其对此类体系结构不断增长的需求。
对 IT 创造性与控制的均衡
从这个方面而言，SOA 代表了 IT 的自然发展之路。很难将其称为革命性的变革，相反，它是一个顶峰，是许多趋势及在 IT 世界存在多年的许多逐渐提出的小问题的答案的积累。让我们回到本文最初的出发点之一，从本质而言，SOA 满足了一个非常广泛的需求：满足所有基本人类活动，在控制和创造性之间求得平衡。
在 IT 领域，SOA 提供所需的控制来确保 IT 开发所进行的工作有用，而同时支持创造性，以确保工作本身及其结果具有吸引力。从最基础的角度而言，SOA 定义了软件组件协同工作的一种方式。控制来自这样的定义：它确保组件执行所需的业务功能，可靠地一起工作，将持续工作一段时间，并能够高效地对其进行修改，以便将来继续有用，能继续工作。这些定义将支持组件级巨大的创造性——只要知道上下文，就可以发现各种需求并以有巨大创造性空间的方式开发代码来满足这些需求。
通过监督维持平衡：治理
维护这个平衡需要什么呢？当然将由 SOA 体系结构模型进行此工作。如果要通过一个正在使用的实际例子来加深印象，可以参考 IBM SOA Foundation 和八个 SOA 场景，其中提供了开发 SOA 的框架和实现此体系结构所需的指导原则。但为了保持这个平衡，需要强调实现 SOA 的机构给予恰当的监督和指导。这个监督称为治理，这个术语可能会被过度使用，但无论如何其本身都是非常恰当的。Merriam-Webster Online 将“治理”定义为“管辖”，并将“管辖”定义为“进行统治的行为；具体来说，就是权威的命令或控制”。更准确地说，治理是 IBM 所定义的八个 SOA 场景之一，它超越了其他功能场景，提醒 SOA 人员其工作需要包括治理，否则就不能实现 SOA 的预期目标。
如果您是工程师（尤其是要接触代码时），术语治理 可能会让您想起铁腕式管理，就是前面所述的监督连续体的法西斯主义端。您可能会用刚刚提供的定义（即“权威的命令或控制”）来支持您的说法。
不过，如果仔细分析一下这个定义，您会发现使用的是权威 而不是独裁。前面我们对监督方式进行过讨论，完全可以说今天企业的行政管理的确同时考虑了必须执行工作的人员（工程方面的执行者）和该工作的用户（客户、最终用户）。的确，企业和 IT 行政管理人员会认为采用的是官僚主义甚至一言堂的作风，但软件工程的本质以及用户的期望要求 IT 和 SOA 治理向民主空间发展，处于法西斯主义与无政府状态间的连续体的中间位置。
也就是说，不仅 SOA 是 IT 近代史上不可避免的，而且治理也是必需的，可能甚至对定义、可视为体系结构的任何 SOA 的组成部分都是如此。如果没有治理，则 SOA 实现可能没有实际价值，构建这些实现的人将会无法谋生甚至更糟糕。而且，如果没有治理机制的监督，SOA 实现还可能缺乏创造性和价值，将永远不会被使用。
在企业 IT 的领域及整个软件行业中，行使治理职责的人员必须放弃对工作本身的一些控制，否则所得到的东西就可能很差，不具有吸引力，而导致没有人使用或者不想使用。开发人员必须愿意进行恰当的组织工作，否则其产品的工作方式将很有限，仅能在很短的时间内适用。从这个角度而言，治理是必须进行 SOA 工作中无法避免的一部分，特别从这个缩写中的“A”（体系结构）而言更是如此。如果没有治理，则不会有真正的面向服务的体系结构。
参考资料 学习
获得产品和技术
- 使用 IBM 试用软件开发您的下一个项目，可直接从 developerWorks 下载这些试用软件。
讨论
关于作者 | 
| | Paul Dreyfus 是 developerWorks 团队的一名编辑。他以前曾在 Apple Computer、Netscape 和 Rational Software 撰写和编辑面向软件开发人员的技术材料。本文中的观点是他的个人看法，并不反映 IBM 官方对所涉及主题的态度。如有任何看法或问题，可以通过 pdreyfus@us.ibm.com 与 Paul 联系。 |
对本文的评价
| 
