SOA的基本特征

SOA的基本特征.
实施SOA的关键目标是实现企业IT资产的最大化重用.要实现这个目标,就要在实施SOA过程中牢记以下特征:
.可从企业外部访问
.随时可用
.粗粒度的服务接口
.分级
.松散耦合
.可重用的服务
.服务接口设计管理
.标准化的服务接口
.支持各种消息模式
.精确定义的服务契约

1.可从企业外部访问
通常被称为业务伙伴的外部用户也能像企业内部用户一样访问相同的服务.业务伙伴采用先进的B2B协议(ebXML或RosettaNet)相互 合作.当业务伙伴基于业务目的交换业务信息时,他们就参与了一次会话.会话是业务伙伴间一系列的一条或多条业务信息的交换.会话类型(会话复杂或简单,长 或短等)取决于业务目的.
除了B2B协议外,外部用户还可以方位以Web服务方式提供的企业服务.

2.随时可用
当有服务使用者请求服务时,SOA要求必须有服务提供者能够响应.大多数SOA都能够为门户应用之类的同步应用和B2B之类的异步应用提供服务.同步应用对于其所使用的服务具有很强的依赖性.
许多同步应用通常部署在前台,其最终用户很容易受到服务提供者短缺的影响.很多情况下,同步应用利用分布式服务提供者,这样可以响应更多的用户请求.但是,随着使用特定服务功能的服务器数量的增长,出现短缺的可能性也呈指数级上升.
相比之下,异步用于要更为稳健,因为其采用队列请求设计,影响可以容许出现服务提供者短缺或迟滞的情况.异步应用大多数情况下部署在后台,用户 通常不会觉察到短暂的短缺.大多数情况下异步应用能够稳健应对短时间短缺,但是长时间短缺则会引发严重问题.在服务短缺解决,队列引擎将罕见的大量工作推 到共享的应用资源中,可能会出现队列溢出或者服务死锁.
服务使用者要求提供同步服务时,通常是基于其自身理解或使用习惯.在多数情况下,采用异步模型可以达到同样的效果,但更能体现SOA的最佳特性.
当然,并不是所有情况下都应当采用异步设计模式.但大多数情况下,异步消息可以确保系统在不同负荷下的伸缩性,在接口响应时间不是很短时尤其如此.

3.粗粒度服务接口
粗粒度服务提供一项特定的业务功能,而细粒度服务代表了技术组件的方法.举例说明---向计费系统中添加一个客户是典型的粗粒度服务,而你可以使用几个细粒度服务实现同一功能,如:将客户名加入计费系统中,添加详细的客户联系方式,添加计算信息等.
采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的往复,一次往复就足够.Internet环境中有保障的TCP/IP会话已不再占据主导,建立连接的成本也过高,因此在该环境中进行应用开发时粗粒度服务接口的优点更为明显.
除去基本的往复效率,事务稳定性问题也很重要.在一个单独事务中包含的多段细粒度请求可能使事务处理时间过长,导致后台服务超时,从而中止.与此相反,从事务的角度来看,向后台服务请求大块数据可能是获取反馈的唯一途径.

 

4. 分级
一个关于粗粒度服务的争论是此类服务比细粒度服务的重用性差 , 因为粗粒度服务倾向于解决专门的业务问题 , 因此通用性 , 重用性设计困难 . 解决该争 论的办法之一就是允许采用不同的粗粒度等级来创建服务 . 这种服务分级包含了粒度较细 , 重用性较高的服务 , 也包含粒度较粗 , 重用性较差的服务 .
在服务分级方面 , 须注意服务层的公开服务通常由后台系统 (BESs) 或 SOA 平台中现有的本地服务组成 . 因此允许在服务层创建私有服务是非常重要的 . 正确的文档 , 配置管理和私有服务的重用对 IT 部门在 SOA 服务层快速开发新的公开服务的能力具有重要影响 .

5. 松散耦合
SOA 具有 " 松散耦合 " 组件服务 , 这一点区别于大多数其他的组件架构 . 该方法旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来 .
服务提供者和服务使用者间松散耦合背后的关键点是服务接口作为与服务实现分类的实体而存在 . 这使得服务实现能够在完全不影响服务使用者的情况下修改 .
大多数松散耦合方法都依靠基于服务接口的消息 . 基于消息的接口能够兼容多种传输方式 ( 如 HTTP,JMS,TCP/IP,MOM 等 ). 基于消息的接口可以采用同步和异步协议实现 ,Web 服务对于 SOA 服务接口来讲是一个重要的标准 .
当使用者调用一个 Web 服务时 , 被调用的对象可以是 CICS(Center for Information and Communication Sciences) 事务 ,DCOM 或 CORBA 对象 ,J2EE EJB 或 TUXEDO 服务等 , 但这与服务调用者无关 . 底层实现并不重要 .
消息类 Web 服务通常是松散耦合和文档驱动的 , 这要优于与服务特定接口的连接 . 当客户调用消息类 Web 服务时 , 客户通常会发送一个完整的文档 ( 如采购订单 ), 而非一组离散的参数 .Web 服务接受整个文档 , 进行处理 , 而后可能或者不会返回结果信息 . 由于客户和 Web 服务间不存在紧密耦合请求响 应 , 消息类 Web 服务在客户和服务器间提供了更为松散的耦合 .

6. 可重用的服务及服务接口设计管理
如果完全按照可重用的原则设计服务 ,SOA 将可以使应用变得更为灵活 . 可重用服务采用通用格式提供重要的业务功能 , 为开发人员节约了大量时间 . 设计可重用服务是与数据库设计或通用数据建模类似的最有价值的工作 . 由于服务设计是成功的关键 , 因此 ,SOA 实施者应当寻找一种适当的方法进行服务设计过 程管理 .
服务设计管理根本上讲是服务设计问题 , 服务设计需要在两点间折衷 --- 走捷径的项目战术与企业构建可重用通用服务的长期目标 . 超越短期目标进行服务接口的开发和评估是迈向精确定义服务接口的重要一步 , 同时还需要为接口文档 , 服务实现文档及所有重要的非功能性特征设立标准 .
在大型组织中实现重用的一个先决条件是建立通用 ( 设计阶段 ) 服务库和开发流程 , 以保证重用的正确性和通用性 . 此外 , 对记述服务设计和开发的服务文档进行评估也是成功利用服务库的关键 .
简言之 , 不按规则编写服务讲无法保证可重用的 SOA 的成功实施 . 在执行规则的过程中会产生财务费用 , 需要在制定 SOA 实施计划时加以考虑 .

7. 标准化的接口
近年来出现的两个重要标准 XML 和 Web 服务增加了全新的重要功能 , 将 SOA 推向更高的层面 , 并大大提高了 SOA 的价值 . 尽管以往的 SOA 产品 都是专用的 , 并且要求 IT 部门在其特定的环境中开发所有应用 , 但 XML 和 Web 服务标准化的开发性使企业能够在所部署的所有技术和应用中采用 SOA, 这具 有巨大的意义 .
Web 服务使应用功能得以通过标准化接口 (WSDL) 提供 , 并基于标准化传输方式 (HTTP 和 JMS), 采用标准化协议 (SOAP) 进行调用 . 例如 , 开发人员可以采用最适合门户开发的工具轻松创建一个新的门户应用 , 并可以重用 ERP 系统和定制化 J2EE 应用中的现有服务 , 而完全无需了解这些应用 的内部工作原理 . 采用 XML, 门户开发人员无须了解特定的数据表示格式 , 并能够在这些应用间轻松第交换数据 .
你也可以不采用 Web 服务或 XML 来创建 SOA 应用 , 但是这两种标准的重要性日益增加 , 应用日趋普遍 . 尽管目前只有集中服务使用者支持该标准 , 但为了大多数的服务使用者都会将其作为企业的服务访问方式 .

8. 支持各种消息模式
SOA 中可能存在以下消息模式 . 在一个 SOA 实现中 , 常会出现混合采用不同消息模式的服务 .
. 无状态的消息 . 使用者向提供者发送的每条消息都必须包含提供者处理该消息所需的全部息 . 这一限定使服务提供者无需存储使用者的状态信息 , 从而更易扩展 .
. 有状态的信息 . 使用者与提供者共享使用者的特定环境信息 , 次信息包含在提供者和使用者交换的信息中 . 这一限度使提供者与使用者之间的通信更为 灵活 , 但由于服务提供者必须存储每个使用者的共享环境信息 , 因此整体可扩展性明显减弱 . 该限度增强了服务提供者和使用者的耦合关系 , 提供了交换服务提供者 的服务难度 .
. 等幂消息 . 向软件代理发送多次重复消息的效果和发送单条信息相同 . 这一限度使提供者和使用者能够在出现故障时简单的复制消息 , 从而改进服务可靠性 .

9. 精确定义的服务契约
服务是由提供者和使用者间的契约定义的 . 契约规定了服务使用方法及使用者期望的最终结果 . 此外 , 还可以在其中规定服务质量 . 还须主要的关键点是 , 服务契约必须进行精确定义 .
META 将 SOA 定义为 :" 一种以通用为目的 , 可扩展 , 具有联合协作性的架构 , 所有流程都被定义为服务 , 服务通过基于类封装的服务接口委托为服务提供者 , 服务接口根据可扩展标识苻 , 格式和协议单独描述 ." 该定义的最后部分表明在服务接口和其实现之间有明确的分界 .