概念:面向服务的体系结构
在此概念中,通过几方面定义了面向服务的体系结构(SOA)的特征:作为技术基础结构;作为设计的概念框架;作为业务和 IT 之间的桥梁;作为基于组件和 OO 技术的演进。
关系
主要描述

简介

要构建企业规模的软件解决方案,困难来自至少四个主要的挑战来源:

  1. 了解高度复杂的业务领域。
  2. 最有效地使用 IT 资源以满足业务需求。
  3. 在长达数月的项目开发期间,管理分多个阶段且涉及大型工程师开发团队的开发工作。
  4. 将解决方案部署到种类复杂的基础结构技术,这些技术已演进了多年,包括从许多供应商处获得的各种中间件软件,并通过质量参差不齐、记录不全的集成工作组合在一起。

在此环境中开发解决方案,需要一种软件体系结构方法帮助架构设计师灵活地演进他们的解决方案,并在新功能的环境中复用现有的工作,以至于即使目标基础结构本身在演进时也能快速实施业务功能。为了满足这些需求,许多组织都在寻求将信息资源重新组织为非常独立、可复用的功能,以创建本质上可适应的环境。通过使用开放、标准的协议描述这些可复用的功能,组织能创建可独立于基础技术而使用的自描述服务。技术独立性允许服务在多种环境中使用,以实现业务流程、规则和策略的标准化。IT 系统的这种方法称为面向服务的体系结构(SOA),由于能从根本上提高企业和 IT 组织的响应性,现已获得广泛认可。

向 SOA 转变对组织提出了许多挑战。例如,面向服务的概念引入了新的术语和模型,并提倡互操作性和流程集成。此外,集成组成 SOA 的许多基础技术层可以是一项非常复杂的任务。IT 组织经常发现他们需要改变方法、升级技能集、在开发环境中使用新功能以及更改解决方案设计流程。为了合成这些内容,最近出现了 SOA 的概念,其特征还在继续演进。但是,关于什么是 SOA 以及 SOA 在解决构建企业软件解决方案的主要问题中所起到的作用,有几个明确的观点。

SOA 作为技术基础结构

系统由服务的集合组成,这些服务调用通过其服务界面定义的操作。 现在,许多组织都根据服务及其互连来表达它们的解决方案。使用 SOA 的最终目标就是实现业务和 IT 的灵活性。还定义了许多重要的技术来支持 SOA 方法,最值得注意的是跨多台机器分发服务和通过因特网或内部网连接服务。这些 Web service 方法依靠服务内的通信协议(如 SOAP);允许在公共目录中注册并在通用描述、发现和集成(UDDI)存储库中搜索 Web service 界面(用 Web Service 定义语言 - WSDL 表示);共享用 XML 定义和以标准模式描述的文档中的信息。此外,还开发了针对策略、安全性、可靠性、发现等其他领域的标准;这一系列的标准通常称为“WS-* 系列”。

但 SOA 只是一组标准和服务描述,就象面向对象只是一组类层次结构一样。实际上,可以创建不使用 Web service 技术的 SOA,也可以用非面向服务的方法使用 Web service 技术。要了解为什么面向服务的观点为业务增加了价值,以及如何设计、实施、部署和管理面向服务的解决方案,还需要了解很多内容。[另外,SOA 不等于 WS]

SOA 作为设计的概念框架

为 SOA 创建解决方案意味着重新考虑今天构建的系统种类、重新考虑组织中的技能,并重新定义团队成员协作的方法。最重要的是,开发解决方案时采取服务方向需要更广泛地复查其对于如何设计解决方案的影响、从完全不同的服务将它们组合在一起意味着什么,以及如何管理和演进部署的面向服务的解决方案。

此转变中的一个重要更改就是术语“应用程序”,因为我们知道从以应用程序作为所有项目的中心转变为将重点放在业务依靠的服务组合上时,会有问题。在这点上,我们可以将这个从面向应用程序的项目到面向服务的项目的转变当作从设计组成应用程序的一组垂直集成的组件到设计一组水平服务的转变。将来,我们会看到术语应用程序被归类为近似于用户交互服务的一小层特定业务逻辑的描述,该描述将编排提供批量值的业务和基础结构服务集合。

Gartner 指的是服务方向作为面向服务的应用程序开发(SODA)的这个更大的环境。Gartner 认为 SODA 的五个主要原则是组合、自适应流程管理、基于服务的互操作性和集成、发现和描述以及快速应用程序维护。从工具供应商的角度,这些领域与三个领域中提供的技术支持有关:

SOA 生命周期。“发现和描述”和“快速应用程序维护”原则指的是服务的生命周期以及它们是如何被发现、应用、演进和维护的。工具供应商不断地提供越来越多的用于存储、编目、搜索和检索服务的方法。对正在进行的服务演进的支持是其中一个重要方面,它导致服务具有多个版本。

SOA 平台和编程模型。基于服务的互操作性和集成原则指的是在特定的运行时平台中连接、部署和管理服务的方法。主要平台供应商支持面向服务的功能直接作为中间件运行时的一部分,并将其运行时编程模型演进成作为第一类元素的表面服务概念。因此,可从一个基于服务的透视图构思、设计、实施和管理解决方案。

SOA 实践和工具。组合和自适应流程管理原则指的是在解决不断变化的业务需求的环境中如何创建和组合服务。工具供应商支持挖掘现有的应用程序来发现潜在的服务、合并现有的功能以使那些功能可作为服务来访问、创建新服务并通过连接用其界面显现的行为来连接服务。 这样做的基础是以可重复、可预知的方法设计面向服务的解决方案时提供明确的指导信息和最佳实践。

所有这三个方面对于成功开发面向服务的解决方案都很重要。它们必须全部解决才能满足组织有效创建更灵活、更符合业务目标的解决方案的需求。

SOA 作为跨接业务和 IT 的解决方案的整体方法

在开发企业规模解决方案时要应对的一个主要挑战是用 IT 组织设计的特定于技术的解决方案连接业务分析员表达的特定于领域的需求。通常,这两个完全不同的领域之间不会连接良好。这两个团体有不同的技能,使用不同的建模概念和表示法(如果有的话),并很少理解那些概念之间的映射。使用面向服务的方法旨在帮助跨接业务分析员和业务线专家与 IT 专家(如架构设计师、系统分析员、集成人员、设计人员和开发人员)之间的间隔。特别是,围绕核心服务集合集成流程、资产和可交付件旨在以清楚、明确的方法连接系统这两个不同的方面。

SOA 提供了侧重服务的视图来帮助应对这些挑战:

桥接业务与 IT 的间隔。使活动和流程的业务视图符合用于实现部分这些活动的技术是最基本的。这种符合性包括业务模型驱动下游开发的能力以及将业务模型和 IT 解决方案结合演进的能力。该服务概念对于这种符合性是至关重要的。服务和基于服务的考虑形成了将业务分析员、IT 架构设计师、集成人员和开发人员联系在一起的共同基础。服务的特性、详细程度级别以及它们提倡的封装级别使它们更加符合驱动业务的业务流程模型。共同的设计实践对此是很重要的,它能确保概念、工作产品和任务在这些不同的角度保持同步。最后,具有能有效地将代表业务目的的模型转换为有效的实施的工具,这对于跨接业务与 IT 之间的间隔也是很重要的。

支持在 IT 组织中更改角色。向服务考虑的转变更改了组织中的技能和团队组合。开发的重点在于用突出服务级别协议(SLA)和服务间协议的体系结构描述来发现、定义、管理和组合服务。传统的将工具功能分解为今天的产品线的做法对于此方法是不合适的。IT 组织中的不同成员将需要不同的功能组合。例如,诸如软件设计人员之类的现有角色所需的技能正转变为更重视跨不同的服务提供者集合来组合和管理服务。类似地,诸如集成专家之类的新角色正在涌现,其重点在于组合基于服务的价值链,以支持组织的主要业务目标。

侧重于资产和复用。将服务看作系统设计中的主要资产改变了组织对复用这些服务的价值的看法。我们前面讨论了从垂直开发一组应用程序组件转变为水平集成组件。其中一个有价值的方面就是服务本身的可复用性提高了。事实上,它们组合为新的功能和新的服务是驱动变更的基本因素。在许多企业中,SOA 的高可复用性证明了对设计和开发服务组合进行投资是有意义的。因此,管理资产的技术和捕获组合资产的模式的可重复方法变得异常重要。在基于资产的开发方法中,这些资产对于组织而言有重要价值,必须认真进行管理。管理资产的团队基础结构在该方法中起到了关键作用。

在专业角色内部和专业角色之间提高协作级别。企业应用程序开发一直发现软件开发需要人们密切合作并注重管理共享资产的生命周期、工作产品可跟踪性以及共享的实践和流程。随着组织的地理分布范围更广、团队中个人之间的实时通信增加,以及软件被嵌套为更大的系统开发启动规划的一部分,进行软件开发更需要进行协作。软件开发基础结构的角色将越来越被看作是促进跨团队共享和复用服务的软件专业人员的协作开发环境。

SOA 作为基于组件和面向对象技术的演进

在软件工程的任何新的开发行为中,很容易假设:可以应用在先前的项目中起过作用的相同技巧和工具。 这种用旧解决方案解决新问题的倾向并不新奇。 类似地,当开发人员开始创建基于组件的应用程序时,他们尝试用自己的面向对象开发的经验来解决问题。 有了更多的经验,就可以理解,面向对象技术和语言是实施组件的极佳方法,虽然我们必须知道通过决策和实施所作出的权衡。 权衡涉及到实施多形态行为的继承和聚集或者重新设计类库,以便可使用各组组件,而不是作为单一 C++ 应用程序的基础。

类似地,我们将组件视为实施服务的最佳方法,虽然必须知道,基于组件的示范应用程序不一定能用作示范的 SOA。 我们一旦了解服务在应用程序体系结构中扮演的角色,就可以充分利用贵公司的组件开发人员和现有组件。 作出这一转变的关键,就是要意识到面向服务方法意味着另一个应用程序体系结构层。 下面的图说明,当作为解决方案的消费者时,可如何将技术层应用于应用程序体系结构来提供详细程度更低的实施。用来指代这一部分系统的术语是“应用程序边缘”,该术语反映了服务是展示系统外部视图的好方法这一事实,以及使用传统组件设计来进行内部复用和组合。 查看对象、组件和服务之间差异的一种方法是将它们与其实施耦合;一个对象与其编程语言紧密耦合,组件与一些运行时或平台(COM、CORBA 和 J2EE 等)耦合,而服务确实只与用于描述其规范的标准集耦合。

文本内容中所述的图。

一般情况下,从面向对象的思维方式转变为基于组件的思维方式要花费 6 到 18 个月时间,在这段时间里开发人员可了解这一新技术及其要求。 理想的情况是,转变为面向服务的解决方案能够更快地完成。 为此,开发人员就必须了解开发和复用组件以支持面向服务的解决方案所涉及的难题、权衡和设计决策。