这是一系列文章第一部分，这一系列文章旨在帮助您更好的理解面向服务的体系结构（SOA）的价值，制订出一个实际的计划来评估您现在的基础架构，并把它转变成一个真正的面向服务的体系结构。其目的在于，当您读完本文时，您将理解为什么声称 SOA 是把现有资产带到未来的最好的平台，同时也使得迅速而正确地开发未来的程序成为可能。另外，您将对在计划这样一次迁移的过程中主要考虑的事项有更好的理解。
开发面向服务的体系结构的情况
在过去的40年里，软件体系结构试图处理日益增长的软件复杂性。但是，复杂性仍在继续增加，传统的体系结构好像已经达到了它们处理此类问题的极限。同时，IT 组织的传统需要仍然继续存在；比如，需要对新的业务需求进行快速的反应，需要不断地减少业务中 IT 的成本，以及吸收、集成新的业务伙伴和新的客户群。作为一个产业，我们经历了能够提供完全的分布式处理的多种计算体系结构和能够运行在任何平台上的编程语言，从而大大缩短了实现的时间表，我们还经历了无数的连接性产品，这些产品能够更快更好地集成应用程序。然而，我们还是没有找到完全的解决方案。现在，业界提出面向服务的体系结构（SOA）作为软件体系结构中下一个发展的阶段来帮助 IT 组织满足他们面临的越来越多的复杂性的挑战。可是，这种体系结构现实吗？即使它可以被概括和描述出来，它也能真的被实现吗？本文的论点就是断定 SOA 是现实的；在所有天花乱坠的宣传尘埃落定之后，所有夸大的期望又回到了现实之中，您将发现至少现在 SOA 是 IT 组织可以将其现有的资产带到未来同时又构建新的应用程序系统最好的基础。这是一系列文章的第一部分，它旨在帮助您更好地理解面向服务的体系结构（SOA）的价值，并且制订出一个切实可行的计划来评估您现有的基础架构，然后将其迁移到一个真正的面向服务的体系结构。
曾几何时，现有的 Web 服务技术刺激了关于面向服务的体系结构（SOA）的讨论。这个讨论并不新鲜；从 CORBA 扩展到在完全不同的异类平台上应用程序一直到现在，这个概念已经发展10多年了。集成这样的应用程序的问题不断出现，通常是因为有那么多不同的（非 CORBA 兼容的）对象模型流行起来；因而，很多架构师和工程师都陷入了解决此类问题的泥淖中，开发一种更健壮的体系结构来实现简单、快速和安全的系统和应用程序集成的承诺并没有兑现。然而，问题却在继续增加，并且日益复杂。基本的业务需求，诸如降低成本、减少开发周期、跨企业集成、企业到企业（B2B）和企业到顾客（B2C）集成、更大的投资回报率（ROI）、创建自适应的和自响应的业务模型等等，使我们不停地寻找更好的解决方案；但是，我们越来越觉得“点解决方案（point solutions）”不能解决这样的基本问题。在很多情况下，问题在于缺乏一个一致的体系结构框架，在这种体系结构中，可以快速地开发、集成和重用应用程序。更重要的是，我们需要一个这样的体系结构框架，它能够装配组件和服务，以便快速甚至动态地交付应用程序。为什么像 Web 服务这样的某种技术是好的，但是我们真正需要的是一种不受技术约束的体系结构，有很多文章对此进行了讨论。让我们首先考虑一些基本的问题，这些问题是我们寻求更好的基础的依据，如何解决这些问题将决定我们工作的成败。
首要问题 - 复杂性
一些事情总是相同的，特别是 IT 组织所面对的业务问题。公司管理层总是努力争取更好地利用 IT、获取更大的投资回报率（ROI）、集成历史上分离的系统和更快地实现新系统；但是时至今日，事情发生了些许变化。现在，您遇到的是更复杂的环境。必须重用而不是替换遗留系统，因为考虑到更有限的预算，替换的成本是高昂的。您将发现费用低廉、无处不在的 Internet 访问使得建立一个全新的业务模型成为可能。公司至少需要评估这个模型，因为竞争使然。合并和收购的增长已经成为家常便饭，因此必须将整个 IT 组织、应用程序和基础架构集成和融合在一起。在这样复杂的环境，点解决方案只会使问题进一步恶化，而决不会引导我们走出重林。必须在一个以异构为基础的环境中开发系统，因为它们必须容纳种类繁多的硬件、操作系统、中间件、语言和数据存储。长达数十年的发展和演化积累起来的影响导致了严重的复杂性。面对所有这些对 IT 业务的挑战，很多 CIO 将应用程序集成作为首要任务也就不是令人惊讶的事情了，如 图1所示。
考虑一个银行有一些分离的“地窖”——在银行内不为其他系统所知的自包含应用程序系统。这些应用程序系统中的第一个可能是优秀的设计，同样，第二个、第三个等等可能都是。但是每一个都是针对银行中不同业务的，是单独投资的孤立项目。因而，例如 获取账户余额的功能在 ATM 系统、分行出纳员交付系统、信用卡计分系统都是重复的，即便它们存取相同数据库中的相同会计数据数据。现在，假设该银行必须为客户开发 Internet 服务、在线银行或在线贷款发放系统以保持竞争力，结果会怎么样。新系统只会给已经存在的冗余编程问题雪上加霜，除非通过某种方式使得现有的代码可以重用。
真正的集成难题 - 接口多样性
同样考虑 n（n-1）集成问题。任何组织都会碰到某些类型的集成问题；或许是因为一次公司的合并、一个新的商业联盟或者仅仅是需要互连现有的系统。如果 n 个应用程序系统必须直接互连，那么将会产生 n(n-1) 个连接或接口。在 图2中，每个箭头表示一个接口。
因此，如果另一个应用程序系统 A（第 n+1 个）必须集成进来，将需要产生、文档化、测试和维护 2n 个新的接口。虽然在上图中，5个应用程序组成的集合需要20个直接接口，但是添加第6个应用程序将需要10个新接口！而更糟的是，必须修改每个已有的应用程序中的代码以包括进新的接口，因而将发生大量的测试费用。您可以立即为 n 个应用程序找到产生最小接口数目（n）的最优解决方案，只为每个附加的系统添加一个新的接口，但是，通过直接连接是做不到的。
将来会怎样呢？
在过去的40多年来，软件开发的实践经历了几个不同的编程模型。而进行的每一次转变在某种程度上都是为了处理更高级别的软件复杂性，并且使得可以通过部件、组件或服务来装配应用程序。近来，Java 技术促成了平台中立的编程，而 XML 促成了自描述，因而也促成了平台中立的数据。现在，Web 服务通过允许应用程序以对象模型中立的方式实现互连，从而克服了另一个障碍。使用简单的基于 XML 的消息传递 Scheme，Java 应用程序能够调用基于 DCOM、遵循 CORBA 甚至是 COBOL 的应用程序。在新加坡的一台大型机上的 CICS 或 IMS 事务能够被一台在慕尼黑的 Domino 服务器上运行的 Lotus 脚本驱动的基于 COM 的应用程序调用。最好的情况是，调用程序很有可能根本不知道该事务在哪里运行、它是由哪种语言编写的以及消息的传输路径。只需提出服务请求，然后就会得到答案。
与其任何一个前身相比，Web 服务更有可能成为提供提供有效的、可靠的和可扩展的机器到机器交互的标准，这是几个技术和文化上必须具备的先决条件适时结合的产物。这些先决条件包括：
- 无处不在的、开放标准的、低成本的网络基础架构和技术。它有助于一个分布式环境的形成，这个环境更有利于采用 Web 服务，而不是 CORBA 和 DCE
- 在一个以网络为中心的领域内达到的接受程度和技术成熟水平。它要求互操作性以实现关键的业务目标（比如，分布式协作）
- 一致同意基于 Internet 的开放标准和相关技术是实现低成本互操作性的最好方法。
- 基于网络的技术（比如 TCP/IP）、工具集（IDE、UML等等）、平台（比如 J2EE 平台）和相关的方法（比如 OO、服务等等）的成熟水平。它们提供了简化松散耦合的、可互操作的、机器到机器的交互（一种比 CORBA 用户体验到的高级得多的状态）所需的基础架构。
面向服务的体系结构允许设计这样的软件系统，它通过发布的可发现的接口为其他的应用程序提供服务，而其中的服务可以通过网络进行调用。当您用 Web 服务技术来实现面向服务的体系结构时，您是在一个更强大、更灵活的编程模型中创建一种新的构建应用程序的方式，从而降低开发成本、持有成本以及实现风险。SOA 既是体系结构模型，又是编程模型，是一种考虑构建软件的方式。
然而，还有更重要的机会刚刚出现。其中第一个就是网格计算，网格计算不仅是使用拥有大量 MIPS 的应用程序来进行计算的解决方案，而且还将提供一个框架，通过此框架可以动态地定位、重定位、平衡和管理大量的服务，这样，无论系统上的负载如何，总可以保证安全地获取所需的应用程序。而这又明显地需要按需计算的概念（on-demand computing），按需计算可能是在任何配置下实现的，从简单的服务器集群到有1024个节点的 SP2 网络。用户需要解决问题和适当的用于解决问题的计算资源——不多也不少——并且为实际使用的资源付费。
这些新功能的有效使用将需要重新构造许多现有的应用程序。现有的单一应用程序能够在这些环境中运行，但没有以最优的方式来使用可用的资源。这个问题和先前讨论过的问题一起可以产生如下结论：必须作出根本的改变——迁移到面向服务的体系结构。
面向服务的体系结构的需求
根据上面讨论的问题，可以很明显地看出，应该开发一种体系结构来满足所有的需求，这些需求包括：
- 首要的一点就是利用现有的资产。现有系统很少可以抛弃，它们通常都包含对于企业很有价值的东西。从战略上讲，目标是构造一个新的体系结构来创造所有想要的价值，但是，从战术上讲，必须集成现有系统，以便随着时间的推移，可以在可管理、渐进式项目中分化或取代它们。
- 支持所有必需的集成类型或“样式”。这包括：
- 用户交互——能够提供单一的、交互式的用户体验
- 应用程序连接性——通信层构成了所有体系结构的基础
- 流程集成——编排应用程序和服务
- 信息集成——联合和移动企业数据
- 依集成需求而构建——构建和部署新的应用程序和服务。
- 允许渐进式实现和资产迁移——这将支持开发这种体系结构的一个最关键的方面：获得更大的投资回报率（ROI）的能力。数不清的集成项目由于它们的复杂性、成本和不切实际的实现进度安排而失败。
- 包括一个以标准的组件框架为基础构建的开发环境，促进更好地重用模块和系统，允许将遗留资产转移到这个框架中，并且考虑到新技术的及时实现。
- 允许实现新的计算模型；特别是，新的基于 Portal 的客户端模型、网格计算和按需计算（on-demand computing）。
面向服务的体系结构——不只是 Web 服务
Web 服务的出现产生了根本的改变，因为很多 Web 服务项目的成功显示这种技术事实上确实存在，借此您可以实现真正的面向服务的体系结构。它使您又往回走了一步，不仅分析您的应用程序的体系结构，而且还要分析您正设法解决的基本业务问题。从业务的角度来看，它不再是一个技术问题，而是要开发一种应用程序体系结构和框架，可以在其中定义业务问题，还可以以一致的可重复的方式来实现解决方案。
不过，首先必须理解 Web 服务并不等同于 面向服务的体系结构。Web 服务是包括 XML，SOAP，WSDL 和 UDDI 在内的技术的集合，它使您能够针对特定的消息传递和应用程序集成问题构建编程解决方案。随着时间的推移，您有理由相信这些技术将逐渐成熟并最终为更好、更有效、更健壮的技术所取代，但是，就目前的情况而言，它们可以发挥作用。至少，它们是 SOAs 能够最终实现这种观念的证明。那么，面向服务的体系结构实际上是由什么组成的呢？
SOA 只不过是一种体系结构。它不是任何诸如 Web 服务这样的特定技术的集合；而是超越它们的，在理想的情况下，是完全独立于它们的。在业务环境中，SOA 的纯粹的体系结构定义可能会是这样的“一种应用程序体系结构，在这种体系结构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，可以以定义好的顺序调用这些服务来形成业务流程”。请注意这里的表述：
- 所有功能都定义为服务。这仅仅包括业务功能、由底层功能组成的业务事务和系统服务功能。这将会产生粒度问题，后面我们将对此进行讨论。
- 所有的服务都是独立的。它们就像“黑匣子”一样运行：外部组件既不知道也不关心它们如何执行它们的功能，而仅仅关心它们是否返回期望的结果。
- 在其最一般的意义上来说，接口是可调用的；也就是说，在体系结构的层面上，它们究竟是本地的（在本系统内）还是远程的（在直接系统外）、是用什么互连 Scheme 或协议来调用或需要什么样的基础架构组件来连接，都是无关紧要的。服务可能是在相同的应用程序中，也可能是在公司内部网内完全不同的系统上的不对称多处理器的不同地址空间中，还有可能是在用于 B2B 配置的合作伙伴的系统上的应用程序中。
在所有这些表述中，接口是最关键的，同时也是调用应用程序关注的焦点。它定义了必需的参数和结果的类型；因而，它定义了服务的类型，而不是实现服务的技术。系统的责任是实现和管理服务的调用，而不是调用应用程序。这使得可以认识到两个关键的特征：其一，服务是真正独立的；其二，它们是可以管理的。管理包括许多功能，其中有：
- 安全性——请求的授权、加密和解密（在需要时）、确认等等
- 部署——出于性能、可用性冗余或其他方面的原因，允许服务在网络内重新部署（移动）
- 日志——用于审核、测量等等
- 动态重新路由——用于故障排除（fail over）或负载平衡
- 维护——管理服务的新版本
总结
在第一部分中，您已经简要地分析了一些导致需要考虑 SOA 的问题，这些需求寄希望于新的体系结构。而在第二部分中，我们将研究服务的类型，构造一个基于服务的组件的应用程序框架和一些将来的计算环境，这些环境将使得 SOA 的开发更加势在必行。