在过去几年间，面向服务的体系结构（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 EditionJ2EE)的体系结构一样，我们也很容易用错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专业人士带来了什么呢？

　　·组件体系结构：这提供了用于构建可伸缩和可重用的软件组件的独立于平台和语言的灵活方法。
　　·松散耦合：ESB的使用提供了理想的机制来对服务使用者和提供者进行松散绑定，完全消除了点对点接口。
　　·实用工具服务：通过这些可构建可重用IT服务库，提供电子邮件服务、信用卡服务等等，其通过SOA成为企业资产的一部分。
　　·遗留支持：虽然通常使用SOAP/HTTP，但服务并不一定为Web服务。本机应用程序和遗留系统都完全可以加入到SOA中来，例如，可以使用Java Message Service (JMS)挂钩到IBM iSeries平台上的MQ集群中，从而给遗留RPG应用程序带来新生。
　　·平台独立性：标准的采用已成为了SOA中的关键，从而让之前不兼容的技术跨一系列平台进行协作。

　　这些特性可带来直接的技术优势，通常可为引入SOA思维方式铺平道路，特别是在中小型企业(SMB)领域中，IT通常推动SOA的引入。可以在单个项目级别实现此方法（虽然有些SOA方面可能不会带来短期好处），单个SOA项目的成功可能会导致此技术在整个企业内大幅度推广开来。

　　事实上，通过这种方式采用SOA不仅为给IT带来好处，而且会间接地为业务提供帮助。随着部署的SOA项目越来越多，此方法的好处将变得越来越明显：

　　·组件重用度的提高应该会减少开发工作量，并在IT项目交付方面表现出较大改善。
　　·由于使用了接口分离特定的运营系统，因此应该在业务规划方面具有更大的灵活性。
　　·点对点连接的消除应该可以简化引入新业务系统的工作。

　　这些因素减少了风险和成本，可提高业务敏捷性；不过，这些最终都是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 &#101xecution Language，BPEL）表示生成的构建；BPEL是一种XML语言，可以导入到IBM WebSphere Integration Developer之类的各种工具中。此时可以通过将业务服务（或者更准确地说，其接口）连接到业务流程中的任务，以组成解决方案。流程并不会考虑基础服务的实现或接口的技术细节，只要满足其需求即可。

　　用于构建软件解决方案的此方法可为业务带来明显的好处，这可以通过以下方面得到证实：

　　·业务驱动的开发：业务分析人员为软件开发工作打下基础，但不用考虑技术细节。
　　·企业级解决方案：解决方案明确设计为跨多个业务部门，而不是由特定IT系统的可用性决定。
　　·可重用业务组件：您将最终构建可重用现有业务服务的投资组合（试着询问典型的保险公司的IT部门，他们有多少个创建保单 功能的不同实现）。
　　·绩效指标：尽管本文中没有提到，但通过使用BPEL可在流程中嵌入关键绩效指标（Key Performance Indicator，KPI）。可以将其用于向业务部门提供有关系统状态的智能反馈。
　　·业务敏捷性：IT的重点在提供业务价值和敏捷性。可以通过重新编写业务组件（而非完全更改整个应用程序代码）来最小化和专注于业务需求变化的影响。

　　最终的结果是，业务分析人员有效地定义与其业务单位的需求一致的软件流程，并以灵活的环境为基础，从而能够专注于更改的影响。业务拥有控制权。

　　行业模型

　　随着业务流程模型的开发，还出现了一系列对其提供支持的行业标准，以简化互操作性和促进IT系统与业务合作伙伴间的流程和服务重用。金融、保险和医疗保健部门在这方面都有发展，但本文将讨论一些电信相关的标准，因为这些标准与本文稍后讨论的案例研究密切相关。这些活动（在以下部分中列出了其中一些活动）提供有关行业最佳实践的详细指南（业务和技术级别），让软件工具与行业模型保持一致。

　　增强电信运营图

　　增强电信运营图（enhanced Telecom Operations Map，eTOM）隶属下一代运营系统和软件（Next Generation Operation Systems and Software，NGOSS）计划，正在迅速成为被电信行业广泛接受的业务流程标准。eTOM可作为领域分析参考图，正在逐渐成为电信行业的通用业务语言。

　　eTOM使用层次结构模型，对业务组件进行多次分解，直到能够使用适当级别的细节对其进行表述为止。在最高的概念级别，eTOM定义了三个宽泛的功能领域：

　　·操作
　　·企业管理
　　·战略、基础设施和产品

　　通过接下来三次迭代对这些实体进行分解，就可以得到企业的组件图，在其中标识服务提供者所需的基本构建块，最终标识各个流程。在上面的每个功能区域中，eTOM都提供了以下三个级别的分解：

　　·第1级 将第0级的实体（如运营）细化为更为具体的功能领域，如客户关系管理（Customer Relationship Management，CRM）、服务管理和资源管理。
　　·第2级 提供进一步的分解级别，分解为具体的处理区域，如订单处理或老客户关系巩固。
　　·第3级 开始定义在第2级的实体中可能进行的典型业务活动，如发出客户订单、信用卡授权以及跟踪订单处理等。

　　此层次结构方法如图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及其通用信息语言的好处在于，可通过其实现与企业运营的成本、质量、时间和自适应性相关的业务好处，让您的企业将重点放在为其客户创造价值方面。