在过去几年间，面向服务的体系结构(service-oriented architecture，soa)受到了极大的关注，带来了软件开发和业务敏捷性的新时代。不过，仅仅 soa 本身并不能解决世界的 it 问题。我们仍然需要可靠而有效的软件工程实践，因为管理落后的 soa 实现和其他体系结构方法一样会出错(如果不是更糟糕的话)。本文将从实际的角度看待 soa(技术和业务两方面)，并将提供一个实际的案例研究，说明通过成功的 soa 实现带来的好处。
撩开神秘面纱
关于 soa，目前并没有统一的定义，但为了实现灵活性和业务敏捷性的体系结构目标，确定了以下这个得到广泛认可的抽象定义：
定义 soa 的体系结构风格描述一组模式和指导原则，以创建松散耦合的基于标准且与业务相结合的服务，由于描述、实现和绑定之间实现了关注分离，这些服务能够提供更高级别的灵活性，以响应业务威胁和机会。
按照达尔文的优胜劣汰观点，soa 是之前的分布式体系结构风格(如分布式组件对象模型(component object model，dcom)、common object request broker architecture (corba) 和 enterprise javabeans (ejb))的自然进化，但其中又融合了各种标准(特别是基于 xml 的标准)，以提供更好的互操作能力。另外还特别明确地强调业务一致性，而这在之前的体系结构中并没有占到主流地位。soa 通过这一点为业务流程驱动的开发提供了理想的平台，可让业务分析人员完全参与到软件开发生命周期中来，而这就是它的一个重要优势。
不过，直接采用 soa 并不能保证项目成功(esb 并不是企业的尚方宝剑!)，有些项目根本就不应该采用 soa 方法。我们都听到过人们谈论各种不好的体系结构和失败项目，然后说“soa 应该能够解决这个问题”。但是，就像我们很可能会创建笨拙庞大的基于 java™ 2 platform enterprise edition (j2ee) 的体系结构一样，我们也很容易用错 soa。如果 ejb 的早期实现失败了，其原因应是有些架构师并没有真正地了解技术的限制(亲历过由于某种数据库搜索而导致应用程序将数百个在容器管理的持久性 [cmp] 实体 bean 加载到内存中的情况的人应该清楚我所指的是什么)。但就 soa 而言，这并不简单。对服务采用类似的全权委托理论已导致了对每个应用程序功能调用都内部使用 web 服务的应用程序的出现——不再是完全的性能解决方案!
谢天谢地，我们似乎从过去这些沉痛的教训中吸取了经验。例如，创建通过 j2ee 经验总结的模式和关联的反模式过程中获得的知识已经被用于构造有关 soa 的类似最佳实践。ibm® 已经成功地开发了 soa 应用程序方面可重用的模式和蓝图，并制定了行业特定的模型，可帮助进行体系结构决策和提供服务标识方法。
通过使用此类构件，可以对引入 soa 的成本造成极大的影响。对于任何新技术，都会存在相关的启动成本，而 soa 会让人觉得初期投资特别大。对重用和灵活性的强调是有代价的，而这很难在项目级别为 soa 推行提供支持，因为并不一定会给项目带来好处。基于模式的加速器和现成资产能够帮助缩短交货时间，但最终需要对初始 soa 项目进行一定的投资。不过，有证据表明，随着整个企业的后续 soa 项目扩展和重用服务目录中的服务，将会降低开发成本，从而让开始 soa 之旅的组织在中期收回这些成本。
soa 视角
尝试回答问题“什么是 soa 时?”，务必考虑您的目标受众的观点，他们的看法通常可归为两类：it 或业务。根据其出发点不同，他们可能会出于不同的原因而支持采用面向服务的概念，而且所认识的潜在的好处和缺点也不尽相同。
每种观点都会从不同的角度描述方法和对采用此技术进行评价。并没有关于如何开始引入 soa 的非常明确的方法;soa 并不是规定性的东西，所注重的是灵活性，不仅体现在最终结果上，也体现在实现结果的过程中。
下面让我们进一步对这两个方面进行讨论。
it 方面
从 it 角度而言，soa 定义一个软件体系结构，此体系结构由松散耦合的分布式组件组成，而这些组件通过通信通道进行合作，从而形成了组合应用程序。soa 的目标是实现组件重用，而不受实现语言或主机平台的影响，可以将此视为好的软件工程实践的外推法，让我们从类重用上升到服务重用的级别——真正的组件体系结构。
如果服务是基于组件的体系结构的开发的自然发展步骤，用于对其进行链接的企业服务总线(enterprise service bus，esb)则可以视为轮辐式集成样式的发展。esb 消除了轮轴作为单一错误点的角色，带来了可伸缩性、智能路由、安全性和中介，而这些均基于 soap 和 ws* 开放标准。
那么这项新技术给 it 专业人士带来了什么呢?
这些特性可带来直接的技术优势，通常可为引入 soa 思维方式铺平道路，特别是在中小型企业 (smb) 领域中，it 通常推动 soa 的引入。可以在单个项目级别实现此方法(虽然有些 soa 方面可能不会带来短期好处)，单个 soa 项目的成功可能会导致此技术在整个企业内大幅度推广开来。
事实上，通过这种方式采用 soa 不仅为给 it 带来好处，而且会间接地为业务提供帮助。随着部署的 soa 项目越来越多，此方法的好处将变得越来越明显：
这些因素减少了风险和成本，可提高业务敏捷性;不过，这些最终都是 it 带头开展的活动，业务没有控制权。
业务方面
2006 年度 ibm 全球 ceo 调查(全球有超过 750 位 ceo 参与了此项调查)，发现 87% 的 ceo 认为接下来两年所需的最基本更改就是要推动创新。gartner 的著名分析师 roy schulte 捕捉到了这些想法，认为“以前构建应用程序是为了长久使用，现在构建应用程序需要考虑进行变更”。
那么 soa 为业务提供了什么来对此加以管理呢?回头看看本文前面的 soa 定义，可能很难发现如何引起业务部门对其的兴趣;松散耦合、关注分离 和体系结构风格 都是以 it 为中心的术语。不过，从业务角度而言，定义中的关键词是灵活性。
与之前相比，业务必须比以往任何时候都需要能够快速地适应不断变化的业务条件。it 体系结构开始向集成模式发展，要构建跨多个操作系统的业务流程，并将现成产品与遗留系统连接起来。soa 提供了支持该模型的灵活性，特别是提供了理想的平台来采用一项关键性技术：业务流程建模(business process modeling，bpm)。
通过 ibm websphere® business modeler 之类的工具，业务分析人员能以图形方式定义和建模业务流程。但这不仅是文档工作;websphere business modeler 可以使用业务流程执行语言(business process execution language，bpel)表示生成的构建;bpel 是一种 xml 语言，可以导入到 ibm websphere integration developer 之类的各种工具中。此时可以通过将业务服务(或者更准确地说，其接口)连接到业务流程中的任务，以组成解决方案。流程并不会考虑基础服务的实现或接口的技术细节，只要满足其需求即可。
用于构建软件解决方案的此方法可为业务带来明显的好处，这可以通过以下方面得到证实：
最终的结果是，业务分析人员有效地定义与其业务单位的需求一致的软件流程，并以灵活的环境为基础，从而能够专注于更改的影响。业务拥有控制权。
|||行业模型
随着业务流程模型的开发，还出现了一系列对其提供支持的行业标准，以简化互操作性和促进 it 系统与业务合作伙伴间的流程和服务重用。金融、保险和医疗保健部门在这方面都有发展，但本文将讨论一些电信相关的标准，因为这些标准与本文稍后讨论的案例研究密切相关。这些活动(在以下部分中列出了其中一些活动)提供有关行业最佳实践的详细指南(业务和技术级别)，让软件工具与行业模型保持一致。
增强电信运营图
增强电信运营图(enhanced telecom operations map，etom)隶属下一代运营系统和软件(next generation operation systems and software，ngoss)计划，正在迅速成为被电信行业广泛接受的业务流程标准。etom 可作为领域分析参考图，正在逐渐成为电信行业的通用业务语言。
etom 使用层次结构模型，对业务组件进行多次分解，直到能够使用适当级别的细节对其进行表述为止。在最高的概念级别，etom 定义了三个宽泛的功能领域：
通过接下来三次迭代对这些实体进行分解，就可以得到企业的组件图，在其中标识服务提供者所需的基本构建块，最终标识各个流程。在上面的每个功能区域中，etom 都提供了以下三个级别的分解：
此层次结构方法如图 1 中所示，其中给出了运营模型的第 2 级分解，重点突出了客户关系管理 (customer relationship management) 第 1 级实体中的订单处理组件。
图 1. etom 运营第 2 级分解
etom v6.0 第 1 级到第 3 级已经在 websphere business modeler 中完全实现，如图 2 中所示。同样可以在其中看到运营领域的层次结构分解，其重点同样是图 1 中突出显示的客户关系管理第 1 级实体。
图 2. etom 运营第 2 级分解
websphere business modeler 项目层次结构视图显示了四个第 1 级的组件，并将客户关系管理展开，最终显示确定客户订单可行性 (determine customer order feasibility) 第 3 级流程。所建模的每个构建都与一个遵循标准 tmf 命名约定的标识符关联。
由于这些流程在 websphere business modeler 中建模，因此可以对其进行组装，并最终作为 soa 的一部分进行部署。而且，这些流程均已经进行了扩展，包括第 4 级，以便定义满足关联的第 3 级流程的需求所必需的服务接口，如图 2 中突出显示的部分所示。另外，还提供了整个电信运营的框架实现，并提供了快速 soa 开发工作的蓝图。
共享信息/数据
如果说 etom 可帮助进行电信运营内的流程的标准化工作，那么共享信息/数据(shared information/data，sid)模型(也隶属 ngoss 计划)就提供了一个公用术语库，定义了超过 1,000 个行业标准业务实体。这些定义最初是使用统一建模语言(unified modeling language，uml)定义的，后来又改用 xml 模式定义(xml schema definition，xsd)对其进行定义，现在都作为业务项在 ibm soa 工具中提供，以供在流程模型中使用，提供了定义服务接口的基础。
使用 ngoss sid 及其通用信息语言的好处在于，可通过其实现与企业运营的成本、质量、时间和自适应性相关的业务好处，让您的企业将重点放在为其客户创造价值方面。
电信应用图
电信应用图(telecom application map，tam)有效地充当了 ngoss 框架构建块(etom 和 sid)与实际的可部署且能得到的运营系统之间的桥梁，将流程功能和信息分组为得到认可的运营支撑系统(operation support systems，oss)和业务支撑系统(business support systems，bss)应用程序或服务。
虽然此领域可能没有绝对完美的解决方案，但 tam 提供了一个通用参考框架，允许供应商、客户和在此领域进行运营的业务合作伙伴了解彼此的观点。tam 基于对当前固话网络、移动网络和线缆通信领域可用的典型系统的观察，并会随着这些系统的发展而发展。
从集成的角度而言，tam 提供了基础运营系统的规范模型，并为在 etom 中定义的业务功能和流程提供了通用端点。它充当了 facade，将业务服务从与基础运营系统相关的技术实现细节分离出来，从而进一步减少了此领域变更的影响，实现了基于 soa 的解决方案的一个主要目标。
ibm websphere business services fabric
ibm websphere business services fabric 提供了一个端到端 soa 平台，用于建模、组装、部署、管理和治理组合业务服务。它提供了设计时工具、运行时环境、行业参考模型和预构建的 soa 资产，以支持快速开发针对行业的组合业务服务。
websphere business services fabric 还提供了可选的电信软件包，此软件包构建于上述 ngoss 标准和 websphere business modeler 扩展之上，提供了专门针对电信行业定制的、可配置的预构建参考业务服务模板集合。通过这种方式使用预构建资产，可通过重用、标准化和跨 it 资产的一致性支持来帮助减少电信运营服务的维护成本。
|||治理
尽管治理在分布式体系结构的构造和管理中并不是新概念，但从失败到成功实现或遵循治理的经验使其在 soa 中的重要性得到越来越多的重视。
早期一些使用共享库(如 microsoft® windows® 动态链接库)造成的混乱局面就是此领域缺乏治理的结果的一个例子。windows 构建于大量 dll 之上，dll 是系统级别的公用功能库，在运行时供很多使用者动态地访问。桌面应用程序也可以使用这些 dll，而且根据操作系统的当前路径级别等因素，可以在安装应用程序时引入这些系统 dll 的新版本。
您需要仔细分析更新共享 dll 的版本的影响，因为所造成的错误的影响将非常广，而且难于定量。您需要保留接口，弃用所建议的退役 api，向相关受众发布关于功能更改的信息，并在发布前使用新版本测试依赖于库的当前版本的应用程序和 dll。
如果没有进行这些必要的工作，则很容易发现陷入循环依赖关系的网中，发布一个 dll 可能会修复一个问题，但最终会带来两个新问题。
soa 尝试通过将培训与管理技术结合来处理治理共享服务的类似问题，通过 soa 卓越中心(centre of excellence，coe)概念提供流程、模板和最佳实践。coe 提供治理中央机制，控制 soa 生命周期的所有方面，包括以下内容：
这以传统的基于项目的设计权威角色为基础，但将其提升到了企业级别，提倡跨所有 soa 项目的重用、一致性和标准化。
客户案例研究
虽然 soa 肯定可以应用于新项目开发，但可能在再工程领域才是它发挥自己最大效力的地方。下面的案例研究给出了很多现有 ibm 客户面临的一个业务问题，这同时也是迅速发展的组织所经历的典型问题。这通常会导致业务需求通过涉及调配具体系统的战术 it 活动实现，而非战略企业级的计划。soa 的引入提供了在经历了这样的发展之后将 it 与业务相结合的机会。
问题
客户的业务非常依赖于自定义的现成产品来进行电信运营。客户的基础设施中的每个应用程序在彼此独立的情况下都能正常工作，但由于缺乏企业视角而导致这些产品之间集成情况糟糕，从而出现竖井 (silo) 情况极为严重的局面。从 it 角度而言，这并不一定是个大问题;每个系统都正常工作，似乎都在管理着一个业务流程。不过，这些流程实际上只是子流程，均参与到跨多个业务部门的较大事务中。
由于这样，会给用户带来以下影响：
此案例研究的重点在于上面问题中重点涉及的以下三个运营系统间的集成：
每个系统都包含应用程序特定的业务逻辑，这些业务逻辑均以相对独立的方式运行，如图 3 中所示。此逻辑经常与表示信息交织在一起，即体系结构内没有清楚的关注分离，从而进一步限制了灵活性。在系统彼此通信的情况下，由于使用了专用 api，因而存在紧密依赖关系，这种方式不可靠，而且会降低可见性。
图 3. 业务子流程
这些系统的用户群实际上有重叠，有些用户最终需要按顺序访问所有三个系统，以收集必要的信息。这就要求他们进行多次登录，以不同的表示样式进行交互、进行重复任务并手动对每个系统的信息进行协调。
解决方案
引入 soa，以在分层参考体系结构中统一这些异类系统，如图 4 中所示。
图 4. soa 分层体系结构
每个层次提供不同的好处(如下所示)，这些层次一起提供了一个灵活的可自定义的业务驱动体系结构。接下来让我们详细讨论一下这些层次：
服务投资组合
标识服务时，可以使用一系列建模技术，如 ibm 内使用的面向服务的建模与体系结构(service-oriented modeling and architecture，soma)方法，本文对此将不予讨论。但抽象一点来说，所标识的服务归为两大类：
经常还有第三类服务，信息服务，用于提供对数据源(通常为联合数据源)中包含的数据的直接访问。不过，在这种情况下，所有数据访问都是通过相关运营系统执行的。
行业遵从性
使用行业特定的业务流程模板和数据模型不仅可以加速在 websphere business modeler 中进行的开发工作，而且还能够提供对业务本身的结构、确定的差距和重叠区域的验证。不过，可能更为重要的是其带来的前瞻性品质认证，特别是在应用程序集成方面更是如此。
由于其多样化且十分复杂的技术需求，很多电信运营商都非常依赖于现成的系统，将其用于控制从开单到网络的物理运营的各个方面的事务。这些系统必须有效地进行通信才能保证企业的成功，而遵循行业标准是实现此目标的最好方法。
目前需要使用 esb 来执行中介操作，在相关运营系统使用的不同数据表示形式之间进行转换。但随着整个行业对标准遵循的不断增加，这将变得越来越没有必要。采用通用数据术语是此领域的一个关键，可帮助对产品接口进行标准化，提高性能、消除特定的产品依赖性，让我们回到 soa 的主要目标之一，即业务敏捷性。
解决方案堆栈
此解决方案基于以下运行时堆栈和开发环境：
除了每个体系结构层提供的具体功能外，堆栈还带来了一系列非功能优势，包括固有的可伸缩性(通过作为 soa 基础的 ibm websphere application server 提供的功能)和在堆栈所支持的操作平台内一定程度的平台独立性。
尽管我们在此解决方案中使用了一系列 websphere 品牌产品，但此方案最终代表的是一种体系结构范式，并有一定的供应商独立性。ibm 参加了各种标准组织(如 w3c、oasis 及其 tmf、bpel、xml 和 ws* 标准的后续实现工作)，可确保此解决方案不会成为另一个定制解决方案。
总结
本文从技术和业务的角度讨论了如何通过引入 soa 来处理现实的业务问题。bpm 之类的补充技术的出现带来了更多的 soa 好处，支持您的业务积极地参与到软件生命周期中来。
我们还了解了 soa 一个将来的发展方向，说明了 it 模式如何发展为行业模板，从而为整个企业提供技术和流程蓝图。任何 soa 的一个主要目标都是将 it 与业务需求相结合，但 soa 现在有了进一步的发展;通过采用新兴的行业模型，我们可以看到 soa 理念将如何帮助业务保持自身与行业的一致，通过采用标准和最佳实践来提供可靠的互操作性和未来敏捷性。
新闻热点
疑难解答
