将SOA实现的技术与业务方面相结合

在过去几年间，面向服务的体系结构(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 专业人士带来了什么呢?

• 组件体系结构：这提供了用于构建可伸缩和可重用的软件组件的独立于平台和语言的灵活方法。
• 松散耦合：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 Execution Language，BPEL)表示生成的构建;BPEL 是一种 XML 语言，可以导入到 IBM WebSphere Integration Developer 之类的各种工具中。此时可以通过将业务服务(或者更准确地说，其接口)连接到业务流程中的任务，以组成解决方案。流程并不会考虑基础服务的实现或接口的技术细节，只要满足其需求即可。

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

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

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