专栏首页python3SOA概览3-SOA的基本特征

SOA概览3-SOA的基本特征

SOA的基本特征

SOA的实施具有几个鲜明的基本特征。实施SOA的关键目标是实现企业IT资产的最大化重用。 1.可从企业外部访问

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

当有服务使用者请求服务时,SOA要求必须有服务提供者能够响应。大多数SOA都能够为门户应用之类的同步应用和B2B之类的异步应用提供服务。同步应用对于其所使用的服务具有很强的依赖性。

许多同步应用通常部署在前台,其最终用户很容易受到服务提供者短缺的影响。很多情况下,同步应用利用分布式服务提供者,这样可以响应更多的用户请求。但是,随着提供特定服务功能的服务器数量的增长,出现短缺的可能性也呈指数级上升。 相比之下,异步应用要更为稳健,因为其采用队列请求设计,因此可以容许出现服务提供者短缺或迟滞的情况。异步应用大多数情况下部署在后台,用户通常不会觉察到短暂的短缺。大部分情况下异步应用能够稳健应对短时间短缺,但是长时间短缺则会引发严重问题。在服务短缺解决、队列引擎将罕见的大量工作推到共享的应用资源中时,可能会出现队列溢出甚至服务死锁。

服务使用者要求提供同步服务时,通常是基于其自身理解或使用习惯。在多数情况下,采用异步模型可以达到同样的效果,但更能够体现SOA的最佳特性。

当然,并不是所有情况下都应当采用异步设计模式。但大多数情况下,异步消息可以确保系统在不同负荷下的伸缩性,在接口响应时间不是很短时尤其如此。 3.粗粒度服务接口

粗粒度服务提供一项特定的业务功能,而细粒度服务代表了技术组件方法。举个例说明最为清楚:向计费系统中添加一个客户是典型的粗粒度服务,而你可以使用几个细粒度服务实现同一功能,如:将客户名加入到计费系统中,添加详细的客户联系方式、添加计费信息等等。

采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的往复,一次往复就足够。Internet环境中有保障的TCP/IP会话已不再占据主导、建立连接的成本也过高,因此在该环境中进行应用开发时粗粒度服务接口的优点更为明显。

除去基本的往复效率,事务稳定性问题也很重要。在一个单独事务中包含的多段细粒度请求可能使事务处理时间过长、导致后台服务超时,从而中止。与此相反,从事务的角度来看,向后台服务请求大块数据可能是获取反馈的唯一途径。 4.分级

一个关于粗粒度服务的争论是此类服务比细粒度服务的重用性差,因为粗粒度服务倾向于解决专门的业务问题,因此通用性差、重用性设计困难。解决该争论的方法之一就是允许采用不同的粗粒度等级来创建服务。这种服务分级包含了粒度较细、重用性较高的服务,也包含粒度较粗、重用性较差的服务。

在服务分级方面,须注意服务层的公开服务通常由后台系统(BES's)或SOA平台中现有的本地服务组成。因此允许在服务层创建私有服务是非常重要的。正确的文档、配置管理和私有服务的重用对于IT部门在SOA服务层快速开发新的公开服务的能力具有重要影响。 5.松散耦合

SOA具有“松散耦合”组件服务,这一点区别于大多数其他的组件架构。该方法旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。

服务提供者和服务使用者间松散耦合背后的关键点是服务接口作为与服务实现分离的实体而存在。这是服务实现能够在完全不影响服务使用者的情况下进行修改。

大多数松散耦合方法都依靠基于服务接口的消息。基于消息的接口能够兼容多种传输方式(如HTTP、JMS、TCP/IP、MOM等)。基于消息的接口可以采用同步和异步协议实现,Web服务对于SOA服务接口来讲是一个重要的标准。

当使用者调用一个Web服务时,被调用的对象可以是CICS事务、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定义为:“一种以通用为目的、可扩展、具有联合协作性的架构,所有流程都被定义为服务,服务通过基于类封装的服务接口委托给服务提供者,服务接口根据可扩展标识符、格式和协议单独描述。”该定义的最后部分表明在服务接口和其实现之间有明确的分界。 (作者:崔晓波)

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 关于Python构建微服务的思考(一)

      微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。 系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。 每个微服务仅关注于完成一件任...

    py3study
  • Django基础——ORM字段和字段参数

    对象关系映射(Object Relational Mapping,简称ORM)模式是一种为了解决面向对象与关系数据库存在的互不匹配的现象(

    py3study
  • python 终级篇 django --

                                       一般操作                                         ...

    py3study
  • 「微服务架构」七种微服务反模式

    流行语经常为进化的概念提供背景,并且需要一个良好的“标签”来促进对话。微服务是一个新的“标签”,它定义了我个人一直在发现和使用的领域。文章和会议描述了一些事情,...

    首席架构师智库
  • 2018微服务年之服务网格Service Mesh

    微服务自2014年3月由Martin Fowler首次提出以来,在Spring Cloud、Dubbo等各类微服务框架的帮助下,以燎原之势席卷了整个IT技术界,...

    哲洛不闹
  • 微服务架构实施原理

    架构师小秘圈
  • 干货下载:谷歌、亚马逊等十大公司微服务案例精选

    Rainbond开源
  • 亚马逊如何变成 SOA(面向服务的架构)?

    上一篇文章,我摘录了《程序员的呐喊》。这本书有趣的内容太多,今天再摘录一段。 1、 亚马逊公司不仅是世界最大的网络书店,还是世界最大的云服务商。它是怎么实现从...

    ruanyf
  • 微服务架构实施原理详解

    基于微服务架构和Docker容器技术的PaaS云平台建设目标是给我们的开发人员提供一套服务快速开发、部署、运维管理、持续开发、持续集成的流程。

    好好学java
  • 《istio实战指南》第1章 服务网格

    yeedomliu

扫码关注云+社区

领取腾讯云代金券