浅谈基于SOA架构的服务集成技术研究

日期: 2012-04-24 来源:TechTarget中国 英文

  在近几年软件行业的发展中,面向服务架构(SOA, service-oriented architecture)成为了当下的热门话题。很多人对SOA感兴趣,实际上SOA是一种体系架构,它将应用程序的不同功能单元定义为服务,服务之间通过定义良好的接口和契约进行联系,接口是采用中立的方式进行定义的,独立于实现服务的平台,从而使得构建在各种各样的系统中的服务能够用统一和通用的方式进行交互。这样一方面能够将遗留系统整合到新的应用,新开发系统采用符合规范的接口设计后也能够很好地整合到应用当中。这些系统松散耦合,最终形成一个可扩展的新系统。

  1 SOA架构

  SOA是一种粗粒度、松耦合的服务结构,是服务的集合,服务是最核心的抽象手段,业务被划分(组件化)为一系列粗粒度的业务服务和业务流程。服务通过基于标准、精确定义的接口通信,通信可能涉及简单数据传递、两个或更多的在一个活动中协作的服务。由此,SOA是一个其所有功能均被定义成精确定义的、可调用的、独立的服务,且能被有序编排、构建业务流程的应用架构。

  SOA通过应用组件和传输协议的松散耦合,服务的即时绑定,从而实现业务组件的虚拟化,造就一个虚拟的集成架构或者集成平台服务总线,这样使得服务集成不受任何限制,可以同时集成.NET组件和J2EE组件,以及集成其他遗留系统的各种应用,同时也可以随时更换这些服务组件。最终达到敏捷的、不受限制的服务集成目标,从而使IT能够随着业务需求的变化而自由调整,达到所谓的“随需而变”的最高境界。

  SOA是目前EAI领域最先进的体系结构,并得到了IBM、BEA等众多IT厂商的支持,并推出自己的解决方案和相关产品,已日益成为行业应用集成标准。SOA很适合于应用在像数字化校园这种分布式、松耦合、异构平台的场合,它可以彻底解决“信息孤岛”问题。并且充分利用已有的软件资源。所以,采用SOA框架信息化企业或构建数字校园是实现信息资源整合的最佳选择。

  2 SOA相关技术

  实现SOA架构的常用技术有Web Services,JMS和BPEL等。

  (1)ESB技术。企业服务总线(Enterprise ServiceBus,ESB)是构建基于SOA解决方案时所使用基础架构的关键部分,是由中间件技术实现并支持SOA的一组基础架构功能。它是一种为进行连接服务提供的标准化的通信基础结构。基于开放的标准,为应用提供了一个可靠的、可度量的和高度安全的环境,并可帮助企业对业务流程进行设计和模拟。对每个业务流程实施控制和跟踪、分析并改进流程和性能。目前各大IT公司都推出了基于自己的平台工具的ESB产品,如IBM的WebSphere ESB、BEA的AqusLogic Service Bus等。除此之外,也出现了众多的开源ESB产品,如Mule、ServiceMix和Apache Synapse等。

  (2)web Services技术。Web Services主要是为了使原来各孤立的站点之间的信息能够相互通信、共享而提出的一种接口。该接口隐藏了服务实现的细节,允许通过独立于服务实现、独立于硬件或软件平台、独立于编写服务所使用的编程语言的方式使用该服务。Web Services可以通过HTTP、SOAP(XML)、SMTP等协议的组合被访问,利用标准网络协议和XML数据进行通信,具有良好的普适性和灵活性,这使得基于web Services的应用程序具备松散耦合、面向组件和跨技术实现的特点例5。Web Services技术的主要目标是在各种异构平台的基础之上构建一个同样的、与平台与语言无关的技术层,各种应用都可以靠这个技术层来实施彼此的连接和集成。

  (3)JMS技术。Java消息服务(Java Message Ser.vice,JMS)是访问企业消息系统的标准API,是Sun公司提出的Java消息服务规范,是用于访问消息系统的不依赖于某个具体厂商的API,它提供给应用程序创建、发送、接受和渎取消息的接口,具体实现可以不同。JMS技术采用异步通信模式,发送消息者将需要变更的数据消息提交到消息平台后,就完成了自己的任务,就可以进行其他的操作。不需要等待服务器端的消息处理结果。这时即使网络出现故障甚至服务器崩溃也不会造成数据的丢失或不一致,消息会保存在消息队列中直到被最终接收。

  3 基于SOA的服务集成

  基于SOA的实现主要是在全局统一的服务接口规划后,充分利用服务接口设计原则,在SOA的理论架构的辅导下实现服务接口的开发工作。

  3.1基于Web Services和ESB的实现

  对于新建的web应用系统与可以改造的Web应用系统可以通过web服务的方式提供web Services接口,并注册到企业服务总线上(ESB),然后由ESB发布服务接口,为服务请求者提供服务,从而实现数据和信息的共享与交互。

  Web Services描述了一组可以在网络上通过标准化的XML消息传递访问的操作。它使用基于XML语言的协i义来描述要执行的操作或者要与另一个web服务交换的数据。Web Services在遵守由一个协议集组成的特殊的技术格式下进行对象组件之间的远程互连交互,包括数据怎么表示,数据怎么传输,Web服务怎么描述,信息怎样获取。在web服务中,四个方面组成了整个Web服务架构:XML是数据的格式,SOAP是调用web Services的协议,WSDL是描述Web服务的格式,对各种语言实现的服务进行定义,把服务操作和消息以一种抽象的方式进行描述,然后将具体的网络协议和消息格式绑定来定义一个服务访问点,相关的服务实现者将与这个抽象的服务访问点联系起来。UDDI是web服务登记、查找和利用的组合。

  Web Services除了标准化、界面与实现分离、实现中立的优势外,它的一个重要用途就体现在Web Services能很好地解决各个旧有系统之间存在的信息孤岛的问题,基于Web Services的中间件的集成将改变目前的开发模式和应用部署的费用规模,加速电子商务的进程。

  利用Web Services技术实现信息服务接口技术。首先,利用先进的集成开发环境(IDE),从现有代码(如Java)中创建Web服务。并调用向导来生成WSDL文件,发布到ESB总线上提供给其它应用Web服务调用,或者开发人员将首先使用WSDL和XML模式(XML Schenaa,XSD)构造定义Web服务接口,然后为服务生成框架实现代码。接下来,开发人员将完成框架服务部署到ESB总线上。

  先要将Web Services部署到ESB服务器上,确保Web Services可以正常运行。Web senrices正确配置并正常运行之后,再对这些web Services进行测试。测试通过后,就可以发布给其它Web系统调用。

  在华南师范大学数字校园中就是利用此技术实现人事管理系统、一卡通系统等系统之间的服务通讯。

  3.2基于SCA的实现

  SCA定义了一个“简单”的面向服务的架构模型,它进一步分离了技术与业务。使得开发人员可以集中精力编写业务逻辑,而不必将大量的时间花费在更为底层的技术实现上,并以此创建、组装、发布服务,很好地解决了服务连接的问题[8j。SCA通过声明的方式实现服务策略来达到服务质量(Qos)的要求,包括:可靠性、安全、事务等。此外,SCA编程模型是高度可扩展并且是与语言无关的,支持新的接口类型、实现类型和绑定类型。

  一个ScA系统通常都是由若干个模块组成,模块之间进行信息交互以获得自己所需要的数据,最后通过整合形成一个大的应用。在SCA里面,模块所提供的功能都被抽象成服务对外发布,被其他模块或外面的系统调用。宏观上看,一个由若干个组件构成的分布式应用模型如图2所示。其中,每一个组件都有一定的业务功能,或者对外提供服务,或者调用外部组件的服务。这些组件通过“连线”(wire)或者绑定(Bind—ing)也即在模块配置文件中描述关联进行连接。组件被部署到具体的运行时里面,这些运行时可以属于一个域,也可以分属不同的域。至于组件的提供的接口可以是web Services,JMS,BPEL等,开发者自行选择所擅长的语言和开发平台进行开发。

  基于SOA去实现SOA,第一步是要建模应用的结构。确定需要哪些业务功能并用sCA的组件和服务进行描述,接着确定组件间的依赖关系,给每个组件提供合适的SCA引用。对于需要从外部读取数据以配置组件行为的组件,则引入SCA属性对其进行描述。模块内部的引用和服务通过“连线”来描述它们间的关系,模块层次的引用和服务则用绑定来描述。

  第二步是实现组件的业务功能。业务功能的实现可以是一个全新开发的实现。也可以只是简单包装已有的应用逻辑来实现。SCA支持多种形式的实现,开发者可以根据喜好进行选择。

  对于对QoS有要求的组件,则需要在组件部署文件中使用安全策略加以描述。

  3.3BPEL与SCA.SDO组合的实现方式

  SOA架构需要一种基于开放的,与后端数据源无关的,能够清晰表达业务数据的数据模型。SDO很好地解决了这一问题。它基于中立的XML Schema,定义了统一的方法来访问和操作来自异构数据源的数据。系统可以采用离线的方式对其进行访问和更新。SDO把业务数据封装为数据对象,使得业务数据能够以统一的方式在系统组件之间传递。而SCA标准则解决了服务的封装和调用问题,它实现了服务的组件化,每一个服务都被封装为服务组件,组件之间以松耦合的方式调用。

  BPEL和SDO均支持可操作XML定义的元素或数据类型变量,因此可以直接将SDO定义作为BPEL流程的变量进行操作。同时,BPEL以Web服务为服务的包装标准,其服务提供和服务调用均由WSDL文件来描述。BPEL可以直接引入SCA组件的WSDL描述而对SCA组件进行调用。另外SCA组件支持BPEL流程实现方式,使得BPEL流程能够像其他ScA组件一样对外提供服务。图3描述了BPEL与SDO和SCA相结合提供流程服务的情形。

  四个SCA组件均对外暴露接口及引用。其中SCA组件A提供了BPEL的流程实现,将对SC.A组件B,C,D按照一定的顺序进行调用。这时,SCA组件A暴露的接口将是BPEL流程的入口所定义的接口,而它暴露的引用恰恰是BPEL进行服务调用时的伙伴链接所引用的接口。由于BPEL和SCA的接口描述都基于WSDL标准,因此它们可以直接被SCA组件暴露。图中的实线表示,只要通过配置文件的属性设置,就可以将合适的SCA组件与BPEL流程所在的组件进行“连线”。BPEL和SCA的结合,使得BPEL的服务调用具有很好的“插拔”性。只要SCA组件的接口和BPEL所暴露出的引用相匹配,就可以随意替换SCA组件,这样既做到了流程逻辑的可重用,又获得了被调用服务的可重用。

  由于BPEL支持将XML Schema定义的数据类型直接定义为流程变量,因此BPEL和业务对象可以共享相同的SDO定义。虚线表示了业务对象在BPEL流程中使用的情形。BPEL流程服务调用SCA组件A将业务对象BO1传入,业务对象BO1被BPEL流程接收,并启动新的BPEL流程实例。BPEL流程根据所调用的SCA接口定义,生成1302,t303和B04,并用它们分别传递给SCA组件B,C和D,从而实现这些SCA组件按照预定的次序执行。可以看到业务对象在SCA中以及BPEI。流程中始终采用一致的定义模型,并不需要进行任何转换。

  因此,BPEL与SDO的很好结合使得BPEL在数据层面上融入了SOA,而BPEL与SCA的很好结合使得BPEL在服务层面上融入了SOA体系结构。

  4 结束语

  企业信息化过程中存在着多个相互“孤立”的系统,这些系统之间无法交互,信息一致性无法导致。为了保护既有系统同时满足未来发展的要求,SOA架构应运而生,它通过将应用功能定义为服务,通过服务调用的方式解决了信息交互的问题。分析了构建SOA架构的实现技术,提出了三种实现服务集成的技术。其中,基于BPEL与SCA,SDO组合的实现方式是目前研究的热点,也是未来SOA架构实现的发展方向。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

相关推荐

  • 总线技术究竟该不该用?

    曾几何时企业服务总线(ESB)被视为企业IT的核心。今天,不仅ESB受到了比被废弃还要糟糕的攻击,若干开发趋势似乎对更简单的消息总线也发起了质疑。

  • 从ESB到微服务:如何演变?

    从web开发人员的角度看,大量的微服务部署到轻量级的Karaf 容器中,这就符合了ESB的定义。

  • API管理工具能否弥补REST与Web服务之间的鸿沟?

    随着企业学习如何通过RESTful利用现有服务,API管理工具正在引起轰动。API管理工具能否弥补REST与Web服务之间的鸿沟?

  • 支付宝分布式事务测试方案

    基于SOA架构,整个支付宝系统会拆分成一系列独立开发、自包含、自主运行的业务服务,并将这些服务通过各种机制灵活地组装成最终用户所需要的产品与解决方案。