SOA 企业架构移植策略
本文包括开发成功的 SOA 移植策略所需行为的工作细化结构范例,最终生成符合 IBM 客户合约中 SOA 原则的实际应用程序……
学习如何为企业开发面向服务的体系结构(Service Oriented Architecture,SOA)移植策略,该企业的 IT 基础架构包括业务筒仓(silo)的单独业务线,并拥有许多集成的遗留应用程序来支持业务目标。
SOA 介绍
自从 Gartner Group提出面向服务的体系结构(Service Oriented Architecture,SOA)和企业服务总线(Enterprise Service Bus,ESB)以来,这些术语已经用了好几年了。然而,应用 SOA 解决方案的实际细节仅仅是最近才出现的。
那么,准确地说面向服务的体系结构是什么呢?“SOA 是一种组件模型,它通过应用程序功能单元(称为服务)之间定义完善的接口和契约,来联系应用程序中的不同服务。”。通过以上的定义,当提取应用程序作为服务时,SOA 是在应用程序之间构建企业级集成层的模式集。SOA 解决方案提倡使用开放标准,然而当集成应用程序时,在某些地方还是需要使用专有技术。
SOA 依赖于将应用程序功能发布为服务,这些服务可被外部各方调用。通常,对 SOA 服务定义的一致观点是:
- 服务通过明确的、与实现无关的接口来定义。
- 服务被松散绑定,并且可以通过强调位置透明性和互操作性的通信协议进行调用。
- 服务封装了可重用的业务功能。
服务可存在于不同的级别上,并提供不同的粒度。通常认为有以下服务级别:
- 技术功能(例如,日志记录)
- 业务功能(例如,getCustomerInfo)
- 业务事务(例如,openAccount)
- 业务流程(例如,processOrder)
每一个粒度级别可能都需要一些合成度。在每个粒度级别上,服务定义以可复用的方式封装其功能是很重要的。
将应用程序功能发布成服务使应用程序可以高效解耦,这是 SOA 的一种需求。通过接口将功能发布成服务,该接口将针对这项功能创建会话虚包(faÇade)。可以通过直接修改应用程序或者通过创建适配器(将请求转换成特定于应用程序的调用)来创建这样的接口。
当应用程序功能作为服务公开时,创建服务消费者和提供者之间路由消息的机制是很重要的。SOA 解决方案通过使用企业服务总线(Enterprise Services Bus,ESB)来满足此需求。企业服务总线是为各种服务请求者和服务提供者提供连接层的一种消息代理,它确保二者之间合适的消息路由。服务请求者是组件,它调用由服务提供者发布的服务来实现内部逻辑。
虽然 ESB 最重要的任务是提供连接框架,但它也提供现代 IT 所需要的合适的服务级别和可管理性。实质上,ESB 允许在基于 SOA 的架构中集成服务,并提供“服务请求者和服务提供者之间使用分布式中介功能的单一管理点”。
ESB 在服务请求者和提供者之间提供松耦合,允许用一个服务实现来替换另一个,而且不会对该服务的消费者造成影响。
在 ESB 提供了服务之间连接性的同时,其他 SOA 组件也提供了对发布、发现和调用服务的支持。这些组件包括业务服务目录、业务服务编排和 ESB 网关。然而,这些组件的部署需要根据实际的业务需求来决定。举个例子,许多较小的企业可能发现他们实际上并不需要 ESB 网关,因此,将不必建立这些网关,导致架构过于复杂。
业务服务目录提供 ESB 所依赖的服务路由信息,同时支持服务请求者和提供者之间的通信。然而,业务服务目录的主要任务是提供服务细节,这些服务细节可用于执行基础架构所支持的业务功能。实质上,业务服务目录是服务消费者寻找支持他们操作的服务的地方。
在业务服务目录提供关于现有服务的信息的同时,业务服务编排组件允许通过现有的低级服务组成新的服务。例如,可以通过定义包含几个较低级别业务功能的工作流来创建新的业务事务。这样的工作流成为新的服务,并发布在业务服务目录中。
- 本文关键词:

