SOA的应用技术（精选12篇）
SOA的应用技术 篇1
一中间件技术提高了分布式应用的灵活性、互操作性、移植性和可维护性
中间件的出现无疑是分布式计算技术发展史上的一次重大变革, 在早期的分布计算中, 两个分布式应用程序之间的通信, 是在物理网络协议的基础上直接实现。编程人员必须处理物理网络的细节。中间件的出现, 封装了低级通信机制的技术复杂性, 对应用程序开发人员隐藏了通信技术库的细节。
比如以北京英夫美迪公司的S1自动播出系统 (以下简称S1系统) 为例, S1系统也是一种分布式系统, 不同的系列台可以分布在不同的服务器上, 播出库、节目库以及资料库等不同的库也都可以部署在不同的服务器上, 这就是一种分布式应用系统。由于S1系统是传统的播出系统, 没有采用中间件技术, 所以所有的客户端都需要是直接访问服务器, 那么程序员在编程的时候就必须处理所有的准确细节, 比如节目库位于哪台服务器、它所使用的数据是SQL Server还是Oracle等。这种方式的缺点就是可重用性低、可移植性和可维护性低。比如, 对于同样是查询节目这个功能, 必须在播出程序、节目管理程序以及节目查询浏览程序等不同程序中分别编写代码来实现, 显然这样的可重用性低, 而且开发工作量大。还有, 例如由于播出程序功能修改的需要, 系统变更了数据库的一个字段, 则必须通知所有其他模块的开发人员, 让他们修改他们所负责的代码, 以适应数据库的变化, 所以可以维护性低。而且由于这种紧密连接的关系, 想升级数据库时, 比如把Access数据库升级为SQL Server数据库, 或更换为Oracle数据库的时候, 所有的客户端程序都需要重新修改, 系统的可移植性低。
我们再来看看如果采用中间件技术, 是怎样一种情况。这个时候, 客户端不直接访问数据库服务器, 而是访问中间件服务器, 所有对数据访问的细节被中间件封装起来了, 应用程序开发人员不需要了解。比如同样是查询节目库的功能, 该功能被封装在了中间件中, 是中间件提供的一项标准功能。所有客户端的编程人员都不需要在每一个程序中编写相关的实现代码, 只需要在程序中调用中间件服务器提供的对应功能, 这样大大简化了客户端的开发。客户端程序只需要在调用相关功能的时候, 说明它需要查询的信息的参数就可以了:比如要查询“新闻频道”中, 标题中包含“国庆”的所有节目, 就把查询的频道参数设置为“新闻频道”, 标题参数设置为“国庆”就可以了, 剩余的操作由中间件服务器来完成, 并把查询的结果反馈给客户端。客户端不需要知道新闻频率的节目是位于哪台服务器上的, 使用的是何种数据库等细节。这样带来的好处也很明显。首先相关功能代码的重用性好, 比如同样的查询, 播出程序、制作站程序以及审听浏览等不同程序都直接调用中间件服务器中的相关服务, 不需要自己分别实现, 代码的重用性高。而且如果修改了数据库某个字段, 而接口方式没有改变, 则只需修改中间件服务器的相关代码, 而不需要让所有的相关开发人员都去修改客户端程序。如果想要更换数据库或者把数据库服务器的操作系统更换为Linux的时候, 只需要修改中间件服务器的相关代码, 而不必更换所有客户端的程序, 系统的可移植性和可维护性好。
卓越的中间件框架提高了分布式应用程序的灵活性、互操作性、移植性和可维护性, 成为有效实现分布式软件架构的关键。
二XML技术的出现解决了“中间件异质性”问题
虽然中间件技术为单个系统的开发提供了卓越的基础结构, 封装和屏蔽了对后台系统平台的访问细节, 这样可以很容易地使如Linux、Windows等不同的操作系统, 以及ORCAL、SQL等不同的数据库所构成的后台系统整合在一起, 以一个统一的标准, 向前端的工作站服务。
但由于分布式计算概念、标准和产品过多, 产生了“中间件异质性”问题。也就是说, 虽然很多的厂家采用了中间件技术, 但是中间件技术和标准较多, Oracle有Oracle的解决方案, 微软有微软的解决方案, 这些不同厂家的中间件产品彼此不兼容。一个大型广播电视台所使用的业务系统是很多的, 包括播出系统、媒资系统、多媒体新闻系统、广告管理系统等, 这些业务系统不可能完全采用一个厂家的产品, 这样不同厂家的产品虽然可能都采用了中间件技术, 但中间件产品是彼此不兼容, 则这些不同厂家的系统则无法有效地融合在一起, 协调工作。
XML技术的出现很好地解决了这个问题。
XML称为可扩展标记语言 (e Xtensible Markup Language) , 是一种简单的数据存储语言, 使用一系列简单的标记描述数据, 而且这些标记可以用方便的方式建立。
XML的设计宗旨是传输和存储数据, 而非显示数据。这是XML与HTML的最大区别, XML与HTML的设计区别是:XML是用来存储数据的, 重在数据本身。而HTML是用来定义数据的, 重在数据的显示模式。
XML与其他数据表现形式最大的不同是:它极其简单, 是纯文本的。XML的简单使其易于在任何应用程序中读写数据, 这使XML很快成为数据交换的唯一公共语言。
XML是独立于软件和硬件的信息传输工具。XML是一种流行的、独立于中间件的格式, 可以在不同应用程序之间交换数据和文档。XML基本上是IT行业可以达成一致的最小公分母。XML不与特定技术或中间件标准绑定, 经常作为一种特殊格式来处理各个不兼容中间件平台的数据。那就意味着不同的应用系统可以很容易加载XML数据到程序中并使用它, 并以XML格式输出结果。
三Web Service技术实现了不同服务系统之间的集成和互调
1998年, 微软工程师利用SOAP (Simple Object Access Protocol, 简单对象访问协议) 发明了基于XML的Web Service (Web服务) 。
Web Service本质上是要以标准化的方式实现企业内外各个不同服务系统之间的互调或者集成。它的设计目标就是简单性和扩展性, 这有助于大量异构程序和平台之间的互操作性, 从而使存在的应用程序能够被广泛的用户访问。基于XML Web services标准的可互相连接和整合的软件产品和解决方案, 可以给广播电台带来巨大的好处:比如不同厂家的制播系统、媒资系统、多媒体新闻系统、手机广播系统等异构系统间通过Web Service技术实现相互访问和协调运作;电台的信息系统可以更方便地为听众提供更好的服务;电台信息系统可以与电视台、广告代理商等合作伙伴的系统进行更好的相连。
下面我们看看Web Service的定义, Web Service的定义多种多样, 下面就列举几个:
Web Service是一种新的web应用程序分支, 它们是自包含、自描述、模块化的应用, 可以发布、定位、通过web调用。Web Service是基于网络的、分布式的模块化组件, 它执行特定的任务, 遵守具体的技术规范, 这些规范使得Web Service能与其他兼容的组件进行互操作。
Web Service可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后, 其他Web Service应用程序可以发现并调用它部署的服务。
Web Service是一种应用程序, 它可以使用标准的互联网协议, 像超文本传输协议 (HTTP) 和XML, 将功能纲领性地体现在互联网和企业内部网上。可将Web服务视作Web上的组件编程。
下面用一种基本的方法来分析一下各个不同服务系统之间的互调或者集成的实现方法。假如电台的网站系统能够需要从媒资系统获取相关查询服务。我们这里称网站系统为服务A, 媒资系统为服务B, 即服务A要远程调用服务B上的查询服务, 要实现这个目的, 需要下面3个要素:
首先媒资系统 (服务B) 需要向外公布, 它能提供什么样的服务, 即媒资系统必须要以一种标准化的语言让电台的网站系统 (服务A) 知道, 它能提供什么样的服务, 以及如何调用它的服务, 它的服务在哪里等, 这就是Web Service的服务描述, 是What、How和Where部分;
那么媒资系统 (服务B) 对外公布的服务信息放在哪里?这个需要服务提供者把相关信息注册到相应的公共网址 (我们成为服务注册中心) , 这样外部其他系统能很方便地找到这些发布的信息;
那么网站系统 (服务A) 想要媒资系统 (服务B) 的查询服务的时候, 它如何操作?首先它到服务注册中心查找想要的服务, 找到后, 网站系统 (服务A) 得到媒资系统 (服务B) 所提供的服务在哪里、如何调用等信息。然后网站系统 (服务A) 要以一种标准化的通信消息格式告诉媒资系统 (服务B) , 它想用什么服务, 并加入相应的输入参数等。当媒资系统 (服务B) 完成服务后, 会同样以标准化的通信方式告诉网站系统 (服务A) 相应的服务结果, 是Web Service的服务消息的请求 (request) 和响应 (response) 部分。
从上面的可以看出, Web Services包括3种组件:
服务提供者:提供服务, 进行注册以使服务可用, 也就是上面例子中服务B:媒资系统相关服务的提供者;
服务代理:服务交换所, 服务提供者和服务请求者之间的媒体;
服务请求者:向服务代理请求服务, 调用这些服务创建应用程序。也就是上面例子中服务A:网站系统。
同样Web Services包括3种操作:
发布/不发布 (Publish/Unpublish) :服务提供者向服务注册中心 (代理) 发布 (注册) 服务或移去 (不发布) 这些服务的注册;
发现 (Find) :由服务请求者向服务代理执行查询 (find) 操作, 服务请求者描述要找的服务, 服务代理分发匹配的结果;
绑定 (Bind) :服务器请求者得到相关的查询结果后, 根据查找到的结果找到服务器提供者。然后和服务提供者之间进行绑定, 即服务请求者向服务提供者申请调用相关服务。
以上3个要素实际上对应于Web Service的3个组成部分——WSDL、SOAP和UDDI。
WSDL (Web Service Description Language) Web服务器描述语言:主要目的在于Web Service的提供者将自己的Web服务的所有相关内容, 如所提供的服务的传输方式、服务方法接口、接口参数、服务路径等, 生成相应的完全文档, 发布给使用者。WSDL是由Intel、IBM、MS、Ariba等共同提出。是一个基于XML的语言, 用于描述Web Service及其函数、参数和返回值。因为是基于XML的, 所以WSDL既是机器可阅读的, 又是人可阅读的。一些最新的开发工具既能根据你的Web Service生成WSDL文档, 又能导入WSDL文档, 生成调用相应Web Service的代码。
SOAP是Web Service的标准通信协议:是一种标准化XML格式的传输消息, 以便大家都用同一种格式来讲话, 可以相互完全理解, 服务请求者和发布者使用该协议进行沟通。即服务请求者要以标准化的SOAP通信消息格式告诉服务提供者, 它想用什么服务, 并加入相应的输入参数等。当服务提供者完成服务后, 会同样以标准化SOAP通信方式告诉服务请求者相应的服务结果。SOAP采用了已经广泛使用的两个协议:HTTP和XML。HTTP用于实现SOAP的RPC风格的传输, 而XML是它的编码模式。主要有以下优点:第一, SOAP是可扩展的, SOAP无需中断已有的应用程序, SOAP客户端、服务器和协议自身都能发展, 而且SOAP能极好地支持中间介质和层次化的体系结构;第二, SOAP是简单的, 客户端发送一个请求, 调用相应的对象, 然后服务器返回结果, 这些消息是XML格式的, 并且封装成符合HTTP协议的消息, 因此, 它符合任何路由器、防火墙或代理服务器的要求;第三, SOAP完全和厂商无关, SOAP可以相对于平台、操作系统、目标模型和编程语言独立实现。另外, 传输和语言绑定以及数据编码的参数选择都是由具体的实现决定的;第四, SOAP与编程语言无关, SOAP可以使用任何语言来完成, 只要客户端发送正确SOAP请求 (也就是说, 传递一个合适的参数给一个实际的远端服务器) , SOAP没有对象模型, 应用程序可以捆绑在任何对象模型中;第五, SOAP与平台无关。SOAP可以在任何操作系统中无需改动正常运行。
UDDI (Universal Description、Dis-covery andIntegeration) 通用发现、描述和整合, 是一种创建注册服务的规范, 以便大家将自己的Web Service进行注册发布供使用者查找。
图2是Web service的服务过程的示意图。
四SOA实现了Web Service技术更高程度的抽象
虽然Web Service技术实现了服务接口的传输和调用的标准化, 但是还是没有解决广播电台内部不同Web Service平台间的异质性问题, 异质性 (特别是中间件的异质性) 的存在是一个基本事实。
我们无法阻止它, 却可有效地管理它。所以要求现代架构必须支持所有这些技术和概念, 同时必须适应底层分布基础结构的不断变化, 正是这些需求推动了SOA (service-oriented architecture, SOA) 技术的产生。SOA相对于Web Service实现了更高程度上的抽象和平台无关化。
SOA的实质是一个组件模型。它将应用程序的不同功能单元 (成为服务) 通过这些服务之间定义良好的接口和契约联系起来。
SOA整合发布平台将完全无关的平台所提供的各种服务整合起来一起发布给外界, 包括实施安全控制和监控服务状态等, 客户端完全不知道真正的服务发布者是谁。
SOA是一种IT体系结构, 称为面向服务的体系结构。SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚, 轻松应对企业商业服务变化和发展的需要。
SOA是在计算环境下设计、开发、应用、管理分散的逻辑 (服务) 单元的一种规范。这个定义决定了SOA的广泛性。SOA要求开发者从服务集成的角度来设计应用软件, 开发者超越应用软件来思考, 并考虑复用现有的服务, 或者检查如何让服务被重复利用。SOA鼓励使用可替代的技术和方法 (例如消息机制) , 通过把服务联系在一起而非编写新代码来构架应用。经过适当构架后, 这种消息机制的应用允许公司仅通过调整原有服务模式而非被迫进行大规模新的应用代码的开发, 使得在商业环境许可的时间内对变化的市场条件做出快速的响应。
SOA也不仅仅是一种开发的方法论——它还包含管理。例如, 应用SOA后, 管理者可以方便地管理这些搭建在服务平台上的企业应用, 而不是管理单一的应用模块。其原理是, 通过分析服务之间的相互调用, SOA使得公司管理人员方便地拿到什么时候、什么原因、哪些商业逻辑被执行的数据信息, 这样就帮助了企业管理人员或应用架构师迭代地优化他们的企业业务流程、应用系统。
SOA和Web Service都包含“服务”的概念, 并且都能对客户端封装服务的具体实现。但是两者是有本质的差别的, Web Service只是实现SOA的一种主要途径而已。
Web Service服务接口需要绑定具体实现的服务组件来实现服务, 它对具体的服务实现完成了封装, 但是它本身是知道服务是如何实现的, 另外客户端调用Web Service组件时, 需要知道Web Service的具体位置和传输协议。但是SOA架构平台只和服务接口进行绑定, 实现了服务接口的透明化, 服务位置的透明化, 服务传输协议的透明化。SOA本身也不知道服务具体是如何实现的。SOA实现了更高程度的抽象。
五结束语
从上面的描述可以看出, SOA是一种IT体系结构, 是一个组件模型, 是一种开发和应用的规范。当广播电台采用的SOA构架来构建电台内的业务系统以后, 电台的播出系统、制作系统、媒资系统、新媒体业务系统等不同厂商生产的子系统, 都可以方便地实现集成和信息交互, 并可以轻松应对企业服务的变化, 而不论这些系统是使用的是Windows或Linux等不同平台, 采用Oracal、SQL Server等不同的数据库, 甚至可以是PC服务器或小型机等不同类型的服务器。
摘要：随着IT技术的发展, 以及实现传统广播和新媒体业务有效结合、相互支撑的需要, 广播电视的技术系统越来越多地采用了基于SOA构架的方式来建设。SOA, 即以服务为导向的软件开发思想, 是当前技术界最热门的话题, 而且用Web Service (Web服务) 技术作为核心构件去搭建SOA架构逐渐成为主流。本文主要从这两种技术的发展历程出发, 并结合播出系统来说明这两种技术在广播系统中的主要用途及其主要特点。
关键词：中间件技术,XML,Web,Service,SOA
SOA的应用技术 篇2
今天，很多公司都试图采用“服务驱动”的方式来提高敏捷性和响应能力，这不仅表现在与客户和合作伙伴的交互上，也表现在IT基础架构的设计和创建上。“服务驱动”要求IT实施面向服务的架构(SOA)，将企业应用中的分散功能组合成基于标准、可互操作的“服务”，并快速组合和重用这些服务来满足业务需求。SOA的中心是服务，而不是应用。通过实施SOA，公司能提高效率，更快地推出服务，并提高敏捷性，以响应不断变化的业务需求。
为了优化IT基础架构以交付服务，并将SOA从理想转化为现实，IT需要一个“智能化”的基础架构，以促进和简化服务的重用，并在当今典型的IT环境(各种技术、协议和应用并存)中可靠地集成服务。IT正在实施一个抽象层，以简化基础架构，隐藏底层多种不同应用和技术造成的复杂性。在几年前，这意味着提供一个用于定制企业应用的平台。而到了今天，抽象层则基于服务，将企业流程表示为服务(由松耦合的业务逻辑片断组装而成)，供其他服务和最终用户使用。
在简单高效的SOA基础架构的支持下，IT将可以实现“服务驱动”的愿景，快速推出新服务，在几乎不中断IT基础架构的情况下重用有价值的业务功能;使IT与业务需求保持一致，响应业务流程的更改，并为用户提供更卓越的服务。
为使IT架构尽可能快地响应业务需求，需要改变架构自身的角色。面向服务的架构就是提供改变的一种方式。SOA有明确的特征，它与目前大多数大公司定义的架构方式根本不同。这些特征完全能够适应更快的变化，并能加强业务与企业IT之间的协作。因此SOA架构功能需求主要体现在如下方面：
1、基于服务
IT通常为了满足一个特定业务领域的要求而出现或发展，只考虑那个领域的利益。IT通常都根据项目来投资和创建，目的是解决特定要求，故易出现功能重复的情况。由于采用“逐个项目”的开发方式，在代码或组件级别来共享功能的传统方法已经宣告失效。
基于服务的IT方法改变了功能的开发和交付方式。功能被一次性地考虑、分解和部署在企业的所有级别中，这降低了成本，加快了交付，提高了IT适应变化的能力。除要改变IT投资和管理方法外，基于服务的方法还要求在功能的打包和部署方式上做出改变。SOA还考虑使功能转化为服务的可能方式，以及这些服务的管理和监控方法。
2、基于标准
传统IT交付的另一个方面是每个项目通常都选取最有利的方法去满足自身需求。这导致了技术增生。当考虑如何使建立在这些技术上的应用交换信息时，就会显露出问题。以前像CORBA和DCOM等基于标准的组件模型效果不好，因为缺少执行它们的技术，还可能延缓支持标准的开发，或二种情况都有。更新技术(如XML、Web服务及UDDI等)为支持重用的、基于标准的SOA奠定了基础，支持这些标准的技术很容易得到，并真正做到了平台中立。
3、企业焦点
如果在业务部门内按项目来开发IT，实现企业范围的`流程或信息的可视化与管理将变得极其困难。许多机构通过成立企业架构小组或委员会来解决这些问题。这些小组通常只关注技术选择，而没有执行其他建议的权力。除加强管理外，这些小组需要一个机制，从而依据标准方式，按适当粒度和用户社区可视化水平去定义、配置、监控和管理对企业功能的访问。只有一个构建合理的、基于服务的且符合正确管理原理的企业架构，才能提供所需要的部署平台。
4、业务焦点
在大多数企业中，业务用户需要多种应用去完成他们的日常工作，各个独立的应用是为不同的需求组合而创建的，这又是一个传统IT交付的副产品，会造成浪费工作、增加培训费用、过度依赖专业技能、重复记录数据和缺乏对全部业务流程的可视性和控制等诸多弊端。SOA的目的为业务在用户可以想象的级别上提供功能，使其日常使用变得易于理解、说明、测试和操作。
论SOA在系统集成中的应用 篇3
摘 要:系统集成是Web Service和SOA的主要应用领域,集成技术主要用于解决数据库爆炸和信息孤岛问题。集成通过自适应技术来整合IT信息资源,发挥IT的整体作用,集成技术包括了连接、管理、规范和整合企业内外的信息。随着Web Service和SOA的不断成熟,一种基于SOA的集成框架ESB也日趋完善。ESB融合了EAI和B2B的优点,采用ESB可以使系统集成更方便、更经济。
关键词:SOA 系统集成 Web Service ESB
中图分类号:TP303文献标识码:A 文章编号:1673-8454(2009)17-0081-04
一、概念
系统集成泛指连接、管理和组合各种企业内和企业间的系统,使集成后的系统能以统一的方式互联互操作以支持业务过程的自动化技术。将两个或者两个以上的系统进行集成时主要涉及组织、角色、任务和过程的定义和管理。系统集成的主要工作有集成方案的确定,集成功能范围的划分,工作流系统的创建改造,数据格式的规范,组织模型的统一等。
SOA(Service-Oriented Architecture),一般翻译为“面向服务的体系结构”,它是一种良好分布式软件架构模型,它将不同的功能单元(服务)通过单元之间的接口和契约联系起来。接口采用中立的方式进行定义,独立于实现服务的硬件平台、操作系统和编程语言,使得构建的服务可以以一种统一和通用的方式进行交互。所以,SOA是将软件组织在一起的抽象概念。
二、系统集成
系统集成是一种新兴的服务方式,指在企业范围内外,将多个应用系统的过程、软件、标准、数据库和硬件集成在一起,使集成后的系统成为一个无缝运作的系统。系统集成的本质就是最优化的综合统筹设计,对一个大型的综合计算机网络系统,系统集成所要达到的目标——整体性能最优,即所有部件和成分合在一起后不但能工作,而且全系统是低成本的、高效率的、性能匀称的、可扩充的和可维护的系统。一般的系统集成包括业务过程集成、应用集成、数据集成和功能集成。通过集成可以增进与客户的关系,增强供应链间的联系,改善内部流程,减少市场周期等。我们经常把系统集成分为:表示集成、数据集成和功能集成(如图1所示),另外API集成是所有集成的基础。系统集成实现的关键在于解决系统之间的互联和互操作性问题,它是一个多厂商、多协议和面向各种应用的体系结构。这就需要解决各类设备、子系统间的接口、协议、系统平台、应用软件等与子系统、建筑环境、施工配合、组织管理和人员配备相关的一切面向集成的问题。
目前系统集成的领头公司主要有:IBM、EBA、Microsoft、Sybase等,它们都很好地实现自己的系统集成的解决放方案。
三、SOA的关键技术
与SOA相关的技术很多,主要有XML、Web Service、CORBA(DOM、EJB)、ESB、SOAD、BPM(EAI、B2Bi)等。
1.SOA
SOA是目前IT领域的热点,它是具有分布、协作、共享特征软件的首选体系结构。
SOA的关键是“服务”的概念,W3C将服务定义为:“服务提供者完成一组工作,为服务使用者交付所需的最终结果。最终结果通常会使使用者的状态发生变化,但也可能使提供者的状态改变,或者双方都产生变化。”
Service-architecture.com将SOA定义为:“本质上是服务的集合。服务间彼此通信,这种通信可能是简单的数据传送,也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数。”
Looselycoupled.com将SOA定义为:“按需连接资源的系统。在SOA中,资源被作为可通过标准方式访问的独立服务,提供给网络中的其他成员。与传统的系统结构相比,SOA规定了资源间更为灵活的松散耦合关系。” 它是一种架构模型,可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。
Gartner则将SOA描述为:“客户端/服务器的软件设计方法,一项应用由软件服务和软件服务使用者组成……SOA与大多数通用的客户端/服务器模型的不同之处,在于它着重强调软件组件的松散耦合,并使用独立的标准接口。”
SOA支持将业务功能单元作为连接服务或可重复进行集成,在需要时可通过网络访问这些服务或任务。SOA是一种松散耦合和粗粒度的服务结构,它将服务组合成各种应用程序,提高了代码的重用率、方便地复用各种应用资源,使业务更加灵活和便利,增加功能的同时减轻了工作量。SOA原型的一个典型例子就是CORBA(公共对象请求代理体系),随着Web Service技术的成熟,SOA也有了进步,主要体现在以XML为基础的技术上。在Web Service中通过WSDL来描述接口,这样系统的动态性、灵活性、自治性就会有很大的提高。
SOA的主要组件结构如图2所示。SOA是通过http传递的SOAP消息。SOAP(简单对象访问协议)是一种基于XML文本的通信协议,它是一种轻型的分布式计算协议,在分布式环境中交换信息。Http允许SOAP利用Web服务器、代理服务器和防火墙等进行投资,达到简单、可扩展的目的。
2.XML
XML(Extensible Markup Language)可扩展标记语言,是一套定义语义标记的规则,也是元标记语言,用于定义其他与特定领域有关系的、语义的、结构化的标记语言的句法语言。XML具有简明有效、易学易用、开放、国际化、标准高效、可扩展等特点。它是一种简单、灵活的标准格式,为基于Web的应用提供了一个描述数据和交换数据的有效手段。使用XML有以下好处:使搜索更有意义,开发灵活的Web应用软件更简单,可实现不同的数据集成,适用于多种应用环境,方便客户端的数据处理和计算,数据标准满足个性化要求,局部数据可随时更新,与现有的Web发布机兼容,可扩展性高和有良好的压缩性能。
3.Web Service
Web Service是由URI标识的软件应用,其接口和绑定可以用XML来定义和描述并且可以被发现,与其他软件通过基于Internet的协议以XML消息交换方式直接交互。Web Service是实现SOA的具体方式之一,它是架构在XML和Internet之上的分布式计算技术。Web Service是系统集成中用来解决应用程序之间相互通信的技术,同时也是描述一系列操作的接口。在Web Service中需要一系列标准的支持,例如WSDL、UDDI、SOAP等,这些标准在角色、操作和构件三者之间起连接作用,如图3所示。
(1)WSDL(Web Service Description Language)包含文档或面向过程消息的端点操作信息的XML格式网络服务描述,可以绑定描述与SOAP、HTTP GET/POST和MIME技术。
(2)UDDI(Universal Description,Discovery and Integr-ation,统一描述、发现和集成)是一个规范,可以用于以Web Service为基础的信息注册,是一个公用的可接入集合,以登记的形式将信息登记出来以便可以发现这些服务。
(3)SOAP(Simple Object Access Protocol)是一种轻量级的编程,常用于没有控制中心、分布式的环境中交换信息,它以XML为基础,一般由信封、编码规则、远程过程调用和应答规则、捆绑方式组成。
4.CORBA、DOM、EJB
CORBA是Common Object Request Broker Architecture的缩写,简称公共对象请求代理体系,它由国际对象,管理组织OMG指定。在该环境下开发的软件既可面向对象又具有可重用性、可移植性及可操作性等特点。CORBA是一种分布式计算标准,其主要分三层:对象请求代理、公共对象服务和公共设施。CORBA是一种应用于开发和配置分布式应用的服务器端中间件模型规范,包括:抽象构件模型、构件容器结构和构件的配置以及打包规范。
5.ESB
ESB(Enterprise Service Bus)采用SOA原则,在大粒度服务级别通过事件驱动和基于XML的消息引擎,以与实现无关的方式集成企业应用的新型标准。它使用许多可能的传递消息协议来负责适当的控制流甚至还可能是服务之间所有消息的传输,相当于计算机的系统总线。模块(服务)都以松耦合连接到BUS上,以此方式来提高服务效率,ESB主要有智能路由(Routing)、传输(Transformation)和事件(Event)组成,如图4所示。
6.SOAD
SOAD(Service-Oriented Analysis and Design,面向服务的分析与设计),是专门为面向服务的体系结构范型设计的软件建模和开发方法,它建立在早期包括面向对象的分析和设计以及业务过程管理在内的过程开发基础之上。所有的设计方法都提倡信息隐藏、抽象和关注点分离。但是SOAD加入了对服务仓库、服务编排和企业服务总线的设计方法。SOAD是以架构为中心,以用例和业务过程驱动,迭代式开发方法。
四、基于J2EE的系统集成解决方案
不管是C/S还是B/S结构的系统软件,最终的目的只有一个——对各种服务的集成。软件技术发展到今天,EIS的集成出现了两大主流,即SUN的J2EE方案和MS的.NET方案,他们要做的都是将不同的服务进行集成后统一接口暴露给客户端。J2EE并非一个产品,而是一系列的标准。J2EE(Java 2 Enterprise Edition)技术的基础是Java 2平台,它提供了对EJB、Servlet、JSP、XML等技术的全面支持,其最终目标是成为一个支持企业级应用开发的体系结构,简化企业解决方案的开发、部署和管理等复杂问题。事实上,J2EE已经成为企业级开发的工业标准和首选平台。J2EE为搭建具有可伸缩性、灵活性、易维护性的商务系统提供了良好的机制。
J2EE平台通过新的JAX-RPC1.1 API提供完整的Web服务支持,这种API很好地支持基于Servlet和企业Bean的服务端点。JAX-RPC1.1基于WSDL和SOAP协议提供了与Web服务的互操作性。J2EE平台也支持Web Services for J2EE规范(JSR 921),它定义了Web服务部署需求并利用了JAX-RPC编程模型。J2EE1.4平台有以下优点:提供了一个多层应用程序模型,这意味着应用程序的不同部分可以运行在不同的设备上。J2EE结构定义了一个客房机层,一个中间层(由一个或多个子层组成),以及一个EIS层。基于容器的组件管理,J2EE基于组件开发模型的中枢容器(Container)概念,容器提供了组件服务的运行时(Runtime)环境,组件可以期望它们的服务在任何J2EE平台上都有效。所有的EJB容器提供对EJB组件的事务和生命周期管理的自动支持,并支持对EJB的查找或其他的服务。容器还提供对企业信息系统的标准化访问。J2EE1.4平台升级新增加的技术大部分和Web服务相关。在J2EE1.4平台下,开发、部署、发现Web服务变得非常方便。J2EE1.4提供了Web服务总框架,如图5所示,主要包括了:Web Services for J2EE、JAX-RPC、SAAJ、JAXR、Connector Architecture1.5等,其中JAX-RPC是J2EE1.4平台中Web服务的核心技术。除此之外,J2EE还声称支持WS-I Basic Profile1.0。
在J2EE平台下,Web服务器通过两种方式访问J2EE应用程序,一种是携带一组类型参数(最初的Web服务版本)的RPC风格调用(同步和异步),这种类型的服务调用非常类似传统的方法调用,使用在分布式对象和RPC实现中;另外一种则是消息传递风格调用(同步和异步),这种类型的服务调用类似传统的消息系统。客户在访问JAX-RPC API创建的Web服务,JAX-RPC就使用Servlet来实现相应的Web服务。Web服务的客户也可以通过Bean的服务端点接口访问无状态会话Bean。如果不采取消息的同一规范,则Web服务的客户不能访问其他类型企业的Bean。
五、总结
SOA将应用程序不同的功能单元,通过组件(服务)之间接口和契约联系起来,甚至将不同的应用系统整合成一个功能强大、服务性能强的系统。其接口采用中立的方式进行定义,我们一般称之为松耦合。松耦合的系统有很好的灵活性,当整个应用程序的每个组件的内部结构和实现逐个发生改变时,它能继续存在。接口独立于硬件、操作系统和编程语言,使得系统中的服务可以统一和通用的方式进行消息传递和交互。通过使用基于XML的语言WSDL来描述接口,相应的服务已经转到更动态且灵活的接口系统。以SOA为基础的系统集成很好地解决了信息孤岛的问题。
参考文献:
[1]全国计算机技术与软件专业技术资格(水平)考试办公室,2006年下半年试题分析与解答.北京:清华大学出版社,2007.
[2]张友生.系统分析师技术指南[M].北京:清华大学出版社,2007.
[3](美)科拉夫兹格,(美)本克,(美)斯拉姆著,韩宏志译. Enterprise SOA中文版——面向服务架构的最佳实战[M].北京:清华大学出版社,2006.
[4]梁爱虎.SOA思想、技术与系统集成应用详解[M].北京:电子工业出版社,2007.
[5]毛新生.SOA 原理·方法·实践[M].北京:电子工业出版社,2007.
[6]Stephen R.Schach.面向对象与传统软件工程[M].北京:机械工业出版社,2006.
[7]史济民等.软件工程——原理、方法与应用[M].北京:高等教育出版社,2002.
[8]喻坚,韩燕波.面向服务的计算:原理和应用[M].北京:清华大学出版社,2006.
SOA的应用技术 篇4
关键词：SOA,协同商务,服务设计,BPEL4WS
随着企业信息化的不断发展,企业或多或少的都建立了自己的信息化应用平台,这些平台的应用日益增多,对系统的应用要求也越来越大,SOA作为一种新的架构思想和技术为企业信息化平台的整合,带来了许多发展机会[1]。服装行业作为商务的一个重要领域,涉及的上下游企业和中间物流企业,需要更多协同和处理,协同商务的发展为解决基于多方关联和应用提供了广阔空间,大大降低了成本提高了交易效率。本文设计的平台就是基于该行业的应用展开的。
1 基于SOA的协同商务平台设计
1.1 总体结构设计
我们通过引进了中间件技术分表现层,构件管理及业务应用和数据访问层四层对系统平台进行了设计如下:
1)表现层:完成界面和与最终用户交互的功能;
2)构件管理层:在这里利用EOS平台的核心功能构件管理功能对整个构件组合的生命周期进行管理;通过EOS中间件实现将业务构件和应用相结合同时组合得到我们所需的应用系统。
3)业务应用构件层:各种构件库存在内部,供构件组合时所需。
4)数据访问层:提供一定的业务处理逻辑构件和相应的接口供构件管理层和表现层使用;通过数据集成构件,将分布在不同数据库中的各种信息资源整合(集成),使业务逻辑层具有统一的访问接口。
1.2 系统功能设计
功能主要包括三方面:1)在线品牌服装电子商务服务管理功能。2)情景互动,社区服务功能。3)前端用户区管理,提供用户综合产品搜索,分类导航,新品区,品牌区,特卖场,童装,女装,男装,运动装区域。
通过情景互动功能,提供了多个系统门户和入口,能够将企业中的部门、员工和与企业相关的供应商、合作伙伴、经销商、终端客户、银行等机构都放到一个平台上来运作。通过品牌服装电子商务功能的这些模块可以对知识管理、财务管理、资产管理、客户关系管理、流程管理、项目管理和供应链等企业职能,进行全面覆盖,而且各模块之间的关联性很强,形成一个网状信息架构。通过前端用户区,以WEB的方式实现,使得用户使用时既充满趣味,又能作为各类服装企业网上销售的有力工具,同时将服装制造商,品牌商,用户,物流企业很好的集成。打破了物理形态上的地域限制。从而提高服装行业商务服务的水平。
1.3 基于BPEL4WS的服务组合设计
设计了构件库组合以外,很大一部分也涉及到了服务组合,服务组合很好的体现了SOA的架构思想[2]。在SOA的核心技术中,除了服务和数据消息模型外,最重要的就是服务的编排和流程。一个完善的系统,用来将已有的服务组装起来定义真正的业务流程。BPEL(Business Process Execution Language)是服务编排的核心技术,也是具体业务流程的表现[3]。我们依据BPEL4WS来设计服务流程,结合需求分析的情况,将信息管理服务,资金流管理服务,物流管理服务三块设计出符合快速组合的应用系统的要求。
1.3.1 信息流管理服务设计
1)业务过程分析
信息流是系统的核心部分,涵盖了每个数据的流程及业务流通,通过服务的组合和设计,我们可以快速的建立流程管理系统。而且不受流程变化的影响,灵活快捷的紧跟发展步伐。
2)服务提供者类型的定义
模型中4个服务提供者类型,即伙伴的定义如下:
其中4个伙伴分别对应与:平台用户(user)、查询服务(inquire)、商品管理(goods manager)、订单处理(Purchase service)、财务管理(finance Service)。服务链接类型和角色名称描述了每个伙伴。这些信息标识了业务流程和伙伴必须提供以使得该关系获取成功的功能,也就是用户交易流程和伙伴需要实现的Port Type。
3)链接的定义
在流程中定义一个伙伴时,需对此伙伴指定的它要遵循的链接类型及其所承担的角色,下面代码定义了用户交易流程与商家的WEB服务间的链接类型:
4)流程活动的序列描述
BPEL4WS流程定义的核心部分是对流程完成功能的活动进行序列化描述,我们针对信息管理这个活动的序列化描述如下:
5)应用的组合构件包
实现该服务功能我们用到的构件包有计算构件库,业务构件库,应用构件库中的系统管理构件包,报表管理构件包,订单管理构件包,商户管理构件包,查询管理构件包,客户服务管理构件包,平台服务管理构件包,智能构件库中的服务组合,商品管理及信息流管理构件包。通过这些构件的组合完成了整个平台系统的信息管理。
1.3.2 资金流管理服务设计
1)业务过程分析
根据资金情况我们可以分为:电子订购,电子支付、客户支付三个过程管理
2)服务提供者类型的定义
模型中4个服务提供者类型,即伙伴的定义如下:
其中4个伙伴分别对应与:会员服务(club-user)、平台服务(platform-service)、商家活动理(shop-service)、投递服务(Post-service)。
3)链接的定义
4)流程活动的序列描述
5)应用的组合构件包
实现该服务功能我们用到的构件包有计算构件库,业务构件库,应用构件库中的消息管理构件包,会员管理构件包,查询管理,定单管理,积分管理构件包,虚拟货币管理构件包,社区管理构件包,广告管理,EOS系统构件包,资金流管理构件包。完成了对整个电子订购,电子支付,客服支付三个过程的管理功能。
1.3.3 物流管理服务设计
1)商业过程分析
物流管理环节是协同商务的重要环节,这个关系到供应商和客户以及平台的诚信度和今后实际运行的效果。这里我们包括物流系统建设、物流过程及结果管理等。
2)服务提供者类型的定义
其中4个伙伴分别对应与:快递服务(Post-service)、支付服务(Pay-service)、订单查询活动(Order-service)、关联服务(Postservice)。
3)链接的定义
4)流程活动的序列描述
5)应用的组合构件包
实现该服务功能我们用到的构件包有计算构件库,业务构件库,应用构件库中的系统管理构件包,EOS系统构件包,报表管理构件包,商户管理构件包,查询管理构件包,物流管理构件包,后台管理构件包。通过这些构件包的组合完成了整个物流的派送服务功能。
2 结束语
本文从结构,功能,服务三方设计分析了百分协同商务平台,这些都是SOA的核心技术,对中小型服装商务企业快速建立协同平台具有重大指导意义。
参考文献
[1]OliverSims H P.Business Component Factory[M].JohnWiley&Sons.,Inc.,1999.
[2]海红.侯秀萍.赵云峰.构件集成算法的研究[J].计算机技术与发展,2009(5).
SOA面试试题 篇5
2、WSDL的操作类型主要有几种
3、如何定义一个可复用的服务
4、SOA面试题：如何在SOA中实现松耦合
5、SOA的常见陷阱或者误解是什么
6、什么是ESB?请介绍一下ESB?
7、介绍一下你对SOA的认识
8、解释下列WebService名词：WSDL、SOAP、UDDI
9、介绍一下SOA和SOA的基本特征
#拓展知识#
体系结构作用：
我可以用面向服务的体系结构做什么?
对 SOA 的需要来源于需要使业务 IT 系统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现，IT 系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。
SOA驱动政府门户应用整合 篇6
当前，Web2.0和面向服务架构(SOA)给政府门户的发展注入了新的活力。SOA是一种IT体系结构模型，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。SOA帮助我们站在一个新的高度理解政府门户应用架构中的各种组件的开发、部署形式，以迅速、可靠、和更具重用性架构整个政府门户系统。政府门户实施SOA的关键目标是实现政府门户系统各种应用功能的最大化重用。
政府门户应用状况
政府门户应用包含以下系统：
图1
还包括邮件系统，视频点播，博客社区系统，授权阅读，政府图库系统等等。在政府内网门户应用中还有办公自动化系统，网上办事等业务系统。这些应用系统充分满足了政府的信息公开，在线交流和服务，以及行政监督的需要。由于在建设时间、承建厂商、采用标准等方面的不同，这些系统在大多数政府里形成了一个个无法共享的信息孤岛，“整合”便成了一个热门话题，也成了一个难题。这么多系统之间的互相访问和操作，大量的功能需要被重用，包括已经建设系统的重用，未建系统的标准规范，等等，势必需要选择一套先进的技术整合体系。
整合技术
点对点的整合最常见的是用于两、三个系统之间进行数据交换。方法简单，但其最大的问题是缺乏灵活性，每两个系统之间需要进行互访时都要进行开发。两三个系统之间的互访尚可以应付，随着系统的增加，其复杂性和工作量成指数级增加。
图2
建立一个集中的EAI数据交换平台，每个应用系统中安装一个适配器的插件。由适配器负责应用系统的数据接口和统一规范格式的转换。它降低了集成的难度，扩展性好。不足之处在于，集中的数据交换平台和适配器的开发复杂，初期投资高，具有一定的应用门槛，另一方面，由于投资大，用户的期望也非常高，造成很多用户对整合效果并不满意。
图3
SOA通过建立一种统一的架构，使得软件开发人员能快速开发、集成和重用应用。更为重要的是，基于这种框架，系统能在业务发生变化之后，动态响应新的需求，快速重新装配各种服务。从底层通过标准化的接口，实现流程优化和低成本运行，使业务流程变得更具灵活性。
图4
大汉JPORTAL平台实现政府应用整合
大汉JPORTAL产品正是适应SOA这样的构架而发展的，它包含了统一用户管理体系，单点登录系统，门户应用整合平台，统一消息平台。系统采用数据总线的技术，将机构，用户，公共信息资源，待办事项，短信邮件通知等数据进行有效地整合并制定了相应的访问和控制标准，提供低耦合网络访问的标准接口。
整合政府门户应用中已有系统，实现单点登录，用户登录任何一个业务系统之后不必再次登录就可进入其它有权限的系统。各种资源信息根据不同的业务范围和需求在政府内部进行有效的共享。通过和后台系统集成，将信息和业务处理过程在门户系统中进行展示，各种业务过程能够流畅地通过门户系统中进行处理，实现自动化和流水化。系统采用开放、插件式的集成技术，满足不断发展的业务系统与门户的集成。
系统构架图：
图5
特点及性能：
◎轻量级Portal构架，快速部署低成本实施。
◎实现统一用户，统一入口，集成化用户操作环境。
◎系统提供三种方式的单点登录功能，支持B/S、C/S系统的单点登录。
◎面向用户更为人性化的友好界面，支持频道的定义，支持频道和页面的拖拽重组。
◎提供多种信息聚合器，聚合来自因特网和其他应用系统的信息。
◎集成全文检索方便构建知识管理平台。
◎系统内嵌更多资源。
◎统一进行应用授权和资源授权。
◎系统提供更多服务，方便地进行应用和功能的进一步扩展。
目前市场上基于SOA构架的整合成功实施的相对较少。有的往往只提供一系列产品或者一套基于他们产品上的解决方案，而大汉JPORTAL资源整合门户平台，以轻量级Portal构架，通过统一界面、统一用户、统一登录、统一授权的方式，整合并展现组织内部应用系统资源和外部互联网资源，随需应变地满足组织内每一个个体的使用需要。除了提供更为个性化的应用和使用扩展的便捷，在开发效率、轻便灵活、应用维护上都具有一定的优势，远低于传统Portal 的投入。
SOA的应用技术 篇7
传统的EAI往往使用如CORBA和COM等消息中间件进行分布式、跨平台的程序交互,实际上是部件级的重用,难于满足现今企业业务流程动态改变的需要。面向服务架构(ServiceOriented Architecture,SOA)以其松散耦合和动态绑定的优势,通过将所有企业资源封装为Web服务,用统一的业务架构将不同的应用系统整合起来,从而达到了提高工作效率和可靠性,加快市场响应速度的目的。
1 基于SOA的企业应用集成
1.1 SOA的组成和特点
1.1.1 组成
SOA的主要组件包括服务、动态发现和消息[2],它的模型中主要包括3个角色(服务提供者、服务请求者和服务注册代理)和3个动作(提供服务、请求服务和调用服务),其实现的标准或协议有XML、WSDL、UDDI和SOAP。目前基于SOA应用的实现方式大多采用Web服务。
1.1.2 特点
(1)松散耦合:SOA允许独立存在的开发服务的提供者和消费者,而不用考虑各自的技术组成。
(2)请求/响应:服务请求者向服务提供者发送请求信息,服务提供者接到请求后发出响应以提供所请求的服务。
(3)同步:包括服务调用和执行。服务请求者请求服务时,在源和目的两个系统间必须维持一个链接,直到请求者收到响应为止。
1.2 基于SOA的EAI的优点
SOA将不同应用系统的不同功能单元封装为Web服务,通过定义良好的接口将服务联系起来。相比传统的EAI架构,它具有以下优点:(1)统一标准、松散耦合、可扩展的服务架构;(2)定义良好的标准化接口;(3)实现技术和位置透明;(4)简单灵活,实现成本低。
1.3 基于SOA的EAI架构
对于一个复杂的企业应用集成平台来说,良好的体系结构将会使系统开发结构清晰,并能提高系统的可维护性和扩展性。在现有标准和协议的基础上,结合SOA的实现方式,设计的基于SOA的EAI框架结构如图1所示。它由资源层、服务层、业务层和应用层构成,各层的作用和功能是:
(1)资源层。企业内部的各种信息系统,软、硬件资源都属于资源层,它用于支撑整个企业内部的正常运作,包括MIS、PDM和ERP等系统;
(2)服务层。它为业务层提供业务功能,利用开放的标准和协议封装底层企业资源,提供服务契约、服务安全、交换数据标准等功能;
(3)业务层。业务层通常也叫业务流程管理(Business Process Management,BPM)。引入BPM可以减少业务需求与IT系统间的失配,让业务用户对流程建模,然后由IT部门提供执行和控制这些业务流程的基础服务。
(4)应用层。即客户端浏览器和各种企业应用,可以是企业内部资源,也可以是Internet网络上的个人用户、手持设备等。它主要是对数据进行显示和处理,对业务逻辑进行触发和调用。
2 实现的关键技术
2.1 基于XML的数据交换
利用数据交换标准XML实现应用系统之间交互的过程是:首先建立所需数据的元数据XML Schema;然后在不同系统之间通过XML转换语言XSLT实现XML文档的转换解析;最后将转换后的XML数据保存到数据库或者应用程序中,从而完成数据交换过程。如图2所示。
2.2 基于WSDL的Web服务描述
在集成环境下,企业资源(MIS、PDM和ERP等系统)通过WSDL(Web Service Description Language,Web服务描述语言)封装为Web服务,所有资源被定义为一组服务访问点。客户端通过这些服务访问点对包含面向文档信息或者面向过程调用的服务进行访问(类似远程过程调用)。
在WSDL中,对服务的封装数据主要包括两类:消息和端口类型。消息主要是对业务服务操作数据的描述;端口类型主要是对服务对外提供的所有操作接口的描述。
WSDL正是通过types,message,port Type,binding,port,service,operation等7个相互关联的元素,实现了对服务的所有特征的抽象,隐藏了具体的实现细节。
2.3 基于SOAP的Web服务访问
Web服务的访问依赖基于XML的消息传递,当前XML消息传递的行业标准为SOAP(Simple Object Access Protocol,简单对象访问协议)。它是在分散或分布式环境中交换信息的简单协议,基于XML语法,用来说明机器间通信消息的传送格式。
一条SOAP消息包括以下4个部分:
(1)Envelope:定义了消息的整体框架,包括可选或必须的内容、发送者和处理;
(2)编码规则:规定应用程序需要使用的数据类型和实例;
(3)绑定:使用底层协议交换消息;
(4)RPC:定义用来表示远程过程调用和应答的协定。
SOAP消息从发送方到接收方是单向传送,以请求应答的方式实现。其实现过程包含3个步骤:
(1)服务请求者创建一条请求Web服务操作的SOAP消息,并将此消息和服务提供者的网址提交给支持SOAP消息的消息服务器,消息服务器再将此消息通过HTTP协议发送出去;
(2)SOAP消息被路由到服务提供者的消息服务器上后,再直接被路由到服务提供者的Web服务对象;
(3)Web服务处理请求消息并生成一个响应(SOAP消息),响应消息被提交给消息服务器并转送给服务请求者。
2.4 基于UDDI的Web服务注册与发现
在SOA架构下,服务的注册与发现是基于UDDI(Universal Description,Discovery and Integration,统一描述、发现与集成)实现的。它是Web服务注册信息的规范,提供的Web服务信息包括3个部分:
(1)白页信息:包含企业名称、地址、电话号码和企业的其它信息;
(2)黄页信息:提供企业分类信息;
(3)绿页信息:企业提供的有关Web服务的技术信息,可能是一些文件或URL链接,它们是服务的发现和调用的依据。
UDDI[3]的工作原理如图3所示。工作过程如下:
(1)服务提供者向注册中心提供行业或企业规范;
(2)服务提供者注册其提供的业务或服务的描述;
(3)UDDI注册中心给每个注册实体指定一个唯一的通用标识符(Unique Universal Identifier,UUID);
(4)外部搜索引擎、客户机与商业应用程序(例如,基于业务流程聚合起来的Web服务)使用UDDI注册中心来发现它们感兴趣的服务;
(5)其它企业调用这些服务,简便的进行动态集成。
2.5 基于Porlet的门户元件技术
门户元件(Portlet)是Web表现层中最为关键的技术,其目的在于使门户页面内容的聚合变得更加方便和规范。在基于SOA的EAI环境下,为了将企业资源展现在信息门户上,可以采用如图4所示的方法将Portlet与Web服务良好的结合起来。
当Portlet接收到请求去访问远程服务时,Portlet首先会去调用SOAP代理对象,该代理把请求参数序列化为与程序设计语言无关的SOAP请求后,再把该请求发送到远程的Web服务中;远程的Web服务接收到SOAP请求后进行拆包,将请求参数还原,调用服务,完成服务请求后,将服务结果返回。
3 基于SOA的EAI应用实例
在为某企业开发的基于SOA的企业应用集成平台中,实现的核心功能主要包括:业务流程驱动的业务活动建模、业务数据的管理、基础服务的构建与管理、基于消息中间件的数据交换。通过集成平台的构建实现了对企业基础服务的管理,让企业的业务人员能够快速建立企业业务流程,并且将业务流程与企业的IT基础架构映射,使企业的基础服务能够快速的响应企业的需求变化,实现企业信息的统一与共享。集成环境的部署与实施方案如图5所示。
4 结束语
SOA可以实现网络环境下应用的松散耦合和集成,能够使用户方便快捷地集成现有的应用和部署新的应用。作为下一代Web服务的基础架构,SOA尚处于不断发展中,还有许多地方有待完善,随着相关标准和实施技术的不断完善,SOA的应用将更加广泛。
摘要：分析了基于SOA的企业应用集成的优点,设计了基于SOA的企业应用集成体系结构,研究了其实现的关键技术,并结合应用实例验证了该技术的可行性。
关键词：SOA,企业应用集成,Web服务
参考文献
[1]周涛.EAI——企业实现信息化的重要途径[J].中国信息导报,2003(39).
SOA技术在电信系统中的应用 篇8
Web服务作为炙手可热的技术, 如何应用到企业的IT系统和商业流程之中并给企业带来直接的经济效益, 一直备受国内外企业管理者的高度关注和推崇。而在近两年, 出现了一种技术架构被誉为下一代Web服务的基础架构, 它就是SOA (Service-oriented architecture, 面向服务架构) 。1996年, Gartner最早提出SOA。2002年12月, Gartner指出SOA是“现代应用开发领域最重要的课题”, 还预计SOA将成为占有绝对优势的软件工程实践方法。
1 SOA技术简介
SOA是在计算环境下设计、开发、应用、管理分散的逻辑 (服务) 单元的一种规范。SOA要求开发者从服务集成的角度来设计应用软件, 还要求开发者超越应用软件来思考, 并考虑复用现有的服务, 或者检查如何让服务被重复利用。
SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚, 轻松应对企业商业服务变化、发展的需要。企业环境中单个应用程序是无法包容业务用户的 (各种) 需求的, 即使是一个大型的ERP解决方案, 仍然不能满足这个需求在不断膨胀、变化的缺口, 对市场快速做出反应, 商业用户只能通过不断开发新应用、扩展现有应用程序来艰难地支撑其现有的业务需求。通过将注意力放在服务上, 应用程序能够集中起来提供更加丰富、目的性更强的商业流程, 其结果就是, 基于SOA的企业应用系统通常会更加真实地反映出与业务模型的结合。服务是从业务流程的角度来看待技术的——这是从上向下看的。这种角度同一般的从可用技术所驱动的商业视角是相反的。服务的优势很清楚:它们会同业务流程结合在一起, 因此能够更加精确地表示业务模型, 更好地支持业务流程。相反我们可以看到以应用程序为中心的企业应用模型迫使业务用户将其能力局限为应用程序的能力。
2 电信业务中的应用
那么SOA架构又是如何实现的?如何应用到我们电信业务系统?这是接下来要论述的重点。
SOA架构是如何实现的呢, 让我们看一下图1:
从图上我们可以看到, SOA结构中共有3种角色: (1) Service provider:发布自己的服务, 并且对使用自身服务的请求进行响应; (2) Service broker:注册已经发布的Service provider, 对其进行分类, 并提供搜索服务; (3) Service requester:利用Service broker查找所需的服务, 然后使用该服务。
在这些角色之间使用了3种操作: (1) publish操作:使Service provider可以向Service broker注册自己的功能及访问接口; (2) find操作:使Service requester可以通过Service broker查找特定种类的服务; (3) bind操作:使Service requester能够真正使用Service provider。
为支持结构中的3种操作 (publish、find和bind) , SOA需要对服务进行一定的描述, 这种服务描述 (Service Description) 应具有下面几个重要特点:首先, 它要声明Service provider的语义特征。Service broker使用语义特征将Service provider进行分类, 以帮助具体服务的查找。Service requester根据语义特征来匹配那些满足要求的Service provider (因此, 语义特征中重要的一点就是对Service provider的分类) 。其次, 服务描述应该声明接口特征, 以访问特定的服务。最后, 服务描述还应声明各种非功能特征, 如安全要求, 事务要求, 使用Service provider的费用等等。
Web Service是代表了SOA的一种实现。Web Services使用了标准的技术, 包括服务描述 (UDDI, WSDL) 、通讯协议 (HTTP, SOAP) 以及数据格式 (XML) 等。Web Service定义为:通过SOAP在Web上提供的软件服务, 使用WSDL文件进行说明, 并通过UD-DI进行注册, 并以XML为数据格式进行数据通信。Web Service可以让程序以更低的代价、更简单的方式集成在一起, 降低企业实施电子商务的成本, 同时Web Service的松耦合方式也有助于以增量方式开发、部署分布式计算环境。
Tuxedo Service是一种广泛意义上的SOA实现技术。Tuxedo Server是Tuxedo Service的provider、Tuxedo Client是Tuxedo Service的requester、Tuxedo的Bulletin Board是Tuxedo Service的broker, 唯一有可能不符合SOA条件的理由是Tuxedo Service的协议并非一种流行的标准协议。图2是如何把Tuxedo Service发布为Web Service的过程。
这里结合电信网上营业厅查询话费的列子阐述一下Tuxedo Service发布为Web Service的过程。电信企业在Internet上提供话费查询, 而话费数据又放在企业内部的计费帐务数据库中, 基于安全性考虑, 必须在中立区设置一台服务器, 即能够访问计费帐务数据库, 又能被Internet所访问。同时又考虑到已有的投资, Tuxedo Service中间件已经把话费查询的服务封装好了, 只要把该服务发布提供给Internet就可以了。所以需考虑如何把Tuxedo Service封装成Internet可以访问的服务, 这时就用到了Web Service技术。通过Bea Weblogic服务器上开发EJB组件, 并通过WTC (Web Logic Tuxedo Connector) 调用Tuxedo Service, 同时利用BEA's Web Logic Workshop工具把该EJB组件发布为标准的Web Service。这样, 客户端通过访问Web Service就可以访问提供话费查询的Tuxedo Service了。这种Tuxedo Service、Web Service技术的联合应用, 在电信企业应用中起到很好的效果。利用已有的服务, 实现了快速的开发, 节约了应用的开发成本, 简化了应用的集成, 为电信在电子商务领域开展业务提供了技术保障。
3 结束语
对于电信运营商而言, 目前尚存在一系列的问题。首先, 电信运营商自身OSS/BSS系统的建设还处于不断完善的过程中, “信息孤岛”现象依旧存在, 这不利于对自有业务的快速集成与管理;其次, 综合信息服务还包括非传统电信服务的内容, 电信运营商还将融合IT应用等服务系统才能最终满足客户的完整需求, 而将第三方应用系统与自身服务进一步进行捆绑则更是实施的难点。因此, 部署SOA来改造电信运营商的服务管理平台, 是一个行之有效的方法。SOA就像是无处不在的毛细血管, 可以把企业的信息孤岛整合起来, 提高系统的可重用性, 提升效率。相信SOA技术在不久的将来, 会在电信企业的应用系统集成中起到越来越重要的作用, 而电信企业的从CIO到负责规划的系统分析人员在作系统规划的时候, 在基础建设和技术实现方面, 不妨多一些考虑SOA技术。
摘要：论述了SOA架构的概念以及特点和作用, 同时重点介绍了WebService技术和Tuxedo Service中间件技术在电信企业中的集成应用。通过具体应用例子的论述, 阐明了SOA技术架构给电信企业应用系统带来的好处。在做系统规划时, 可多考虑SOA架构。
关键词：SOA,Tuxedo Service,web service,应用集成
参考文献
SOA的应用技术 篇9
随着企业应用集成(EAI)的不断发展,需要有更加有效、灵活的开发和集成模式来适应动态信息系统的要求。面向服务体系结构(SOA)的出现,填补了这一空缺,SOA所具有的松散耦合、面向消息的请求/响应通信方式、关注流程的特点顺应了快速构建柔性集成应用的需要。
面向服务的体系架构(Service-Oriented Archi2tecture,SOA)是一种基于互联网的信息集成体系框架,SOA采用面向服务的软件封装技术,它以服务接口(service interface) 和服务实现(service implementa2tion)的方式呈现,它的3个基本要素是服务描述、服务发现和服务调用。从技术角度讲,它是一个组件模型,XML技术为基础,通过WSDL 协议,使用基于XML格式的Web Service描述语言来描述接口SOA不仅仅是一个软件开发框架而且还是一个业务开发框架,它能够将不同类别、不同平台的服务结合在一起,动态、实时地更新维护一个跨区域的多功能的应用实体。
1 SOA面向服务架构(SOA)
SOA是一种粗粒度、松耦合的服务架构。SOA是服务的集合,服务之间通过标准和精确定义的接口通信。接口是采用中立的方式进行定义的,独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种系统中的服务可以以一种统一和通用的方式进行交互。由此,SOA是一个其所有功能均被定义成精确定义的、可调用的、独立的服务,且能被有序编排构建业务流程的应用架构。
SOA是基于服务的分布式系统设计框架,具备以下几个特点:
① 松散耦合:服务提供者使用标准定义语言定义和公布它的服务接口,接口定义服务消费者和服务提供者之间的调用契约。只要服务接口保持一致,改动调整应用程序的内部功能或结构将对其他部分没有影响;
② 互操作性:基于标准,提供了不同厂商解决方案之间的互操作性,SOA可以使用任何平台之间的功能,而与编程的语言、操作系统和计算机类型等等无关,可以确保各种基于SOA 解决方案之间的集成和互操作性;
③ 位置透明:SOA通过“发布检索”机制提供位置透明性,即服务请求者无需知道服务提供者的实际位置。
SOA体系架构模型为如图1所示。
2 中间件分类
用于EAI的中间件可分为5类:① 远程过程调用类中间件:RPC是基于开发过程集成的分布式应用软件的中间件,它能通过网络调用过程;② 数据库访问中间件:数据库访问中间件能够访问远程数据文件和数据库,它在数据级上集成,并且能通过网络查询或转移数据;③ 面向消息的中间件(MOM):MOM通过使用消息集成不同的应用软件;MOM技术将消息作为集成方式,能够产生、控制、存储和传送消息;MOM对数据一致性和多部处理问题很有效,但是因为消息规范容易更改,因此MOM软件组件集成中的作用不显著;④ 分布式对象技术类中间件(DOT),DOT作为中间件的一种,将面向对象的概念推广到分布式处理中,它能给新的、原有的应用软件提供面向对象的接口,从而实现互相访问;⑤ 事物处理监控器(TPM),它保证事物的完整性,具有如下的功能:回滚、失败后接替、自动重启、错误日志、消除单点失败的复制技术。一个可靠的系统需要集成MOM、DOT和TPM技术,没有一种单一的中间件产品能满足所有企业建立一个可靠的系统的需要,企业必须综合使用中间件以获得高效的EAI解决方案。
3 集成方法和通信模式
集成方法主要有2种:消息传递和接口定义。应用软件集成的设计者必须预先设定消息格式,通过定义的消息格式对消息进行传递,控制系统的业务流程。在接口定义这种方式中,发送器通过接口进行通信,由接口规定应用软件能调用的操作,任何用于处理的数据也都通过接口进行传输。通过这种接口定义,应用软件不会认为调用来自其他应用软件,而将它看成是自身内部的请求,这样,应用软件同其他应用软件的接口调用是透明的。
系统互相作用的方式决定其灵活性,通信模式有2种:同步通信和异步通信。同步通信分为以下几种模式:请求/应答、同步轮询;异步通信分为以下几种模式:消息传送通信、发布/订购通信、广播通信。在同步通信中,请求发送器需要一直等待,直到收到应答才进行下一次发送,这是因为需要应答结果来继续执行。异步通信允许发送器发出请求后继续执行,可能并不需要接收器为请求作应答。
4 基于SOA架构中间件应用集成设计
基于SOA架构的中间件应用集成设计如图2所示,各个功能实体都以服务的形式出现, 在特定的层次上为特定应用程序提供服务。
利用SOA松耦合、面向业务的特点,本文设计了基于SOA的架构,利用WebService 技术实现中间件与业务应用系统的集成,完成二者的松耦合集成。
① 业务应用数据库主要用于存储各个业务应用数据,是各个业务应用的持久化存储的地方;
② 基于SOA架构的系统服务总线,它是整个系统处理的核心,主要由服务总线(SB)、消息传输、数据转换及动态路由等几部分组成,是基础架构服务中的基础核心部分。服务总线是SOA 体系中的基础架构,是在SOA架构中实现服务间智能化集成与管理的中介。各个服务通过总线来互相访问,消息传输、数据转换及动态路由提供服务总线所需的必要服务支持,主要是总线基本服务,如消息分发订阅、队列、数据转换映射服务、动态连接和路由等;通信系统与网络技术
③ 中间件层:采用消息导向的中间件(MOM)和分布式对象技术类中间件(DOT),信息是以消息的形式从一个程序模块传送到另一个或者多个程序模块, 依据各个业务要求,以XML文件格式定义各个传输内容;
④ 服务接口层:服务接口层位于中间件层与应用系统之间。通过业务建模分解业务流程,识别出相关的业务服务,定义消息类型,派生服务接口并实现服务。然后将服务注册到服务库中。服务的请求者可在服务库中查找到该服务。实现服务间的串连以构成企业的关键业务流程。
5 在某地面系统中的应用
利用上述集成方案构建中间件在某应用系统的集成,以实现对集成框架的应用验证。
该系统采用J2EE的架构,消息中间件将系统的业务流程串联起来, 其服务总线由服务总线配置管理服务器、服务总线客户端以及消息中间件3部分组成。其组成如图3所示。
消息配置文件发送功能负责接收服务总线客户端发送的配置信息申请,并返回消息配置信息、服务注册信息,其中消息配置申请包含应用软件标识及消息配置文件版本信息。消息配置信息文件、服务注册信息为服务端生成的xml文件,它来源于数据库中的消息配置信息。
消息配置信息Xml文件为:
< xmlversion="1.0" encoding="gb2312" >
<ConfigFile>
<文件版本号>536</文件版本号>
<消息配置信息>
<消息编号>1</消息编号>
<消息名称>计算服务申请</消息名称>
<业务信息内容>申请信息</业务信息内容>
<消息类型>数据帧</消息类型>
<生命周期>600</生命周期>
<软件发送方>122</软件发送方>
<接收>
<软件接收方>121</软件接收方>
<接收队列>GDJSQQ</接收队列>
<消息中间件消息名称>服务计算消息</消息中间件消息名称>
<IP>10.10.2.90</IP>
<QCU>RWKZFW</QCU>
<端口号>10245</端口号>
</接收>
</消息配置信息>
消息发送、接收功能完成该系统内业务数据的流转以及业务服务的调用。应用软件通过服务总线客户端,调用消息中间件,将业务数据以消息的形式传递到其他的应用软件或服务。当应用软件调用系统中所部署的业务服务时,各应用软件通过服务总线客户端发送服务申请至业务服务,业务服务返回服务结果至应用软件,从而完成服务的调用
6 结束语
SOA为系统应用集成提供了较为理想的集成框架,在应用层通过中间件实现松散的应用集成,能够满足各种信息集成要求,体现了松散耦合、位置透明、协议独立的特点,能够支持随需应变的动态业务需求,较好地解决了传统企业应用系统集成存在的问题。SOA简化了IT的计算环境,其兼容性、互通性以及最终实现的业务系统自主的能力,满足了高度动态的业务系统环境。
摘要：介绍了面向服务架构(SOA)的基本概念和工作原理,以中间件技术为基础,提出了一种基于SOA的中间件应用集成框架,框架采用服务分层模型,具有敏捷性、松耦合、跨平台、分布式的特点,可广泛适应信息系统集成发展的需要,分析了基于SOA的企业应用集成的优点,设计了基于SOA的企业应用集成体系结构,研究了其实现的关键技术,给出了基于SOA架构的中间件应用集成方案,以消息中间件将系统流程集成起来,最后给出了相应的应用案例。
关键词：应用集成,面向服务架构,中间件
参考文献
[1]马华,李建华.基于SOA企业应用集成系统[J].计算技术与自动化,2005(12):87-89.
[2]叶宇风.基于SOA的企业应用集成研究[J].微电子学与计算机,2006(5):211-213.
[3]王建兴,吕晓华.基于WEB SERVICES的面向服务信集成研究[J].计算机时代,2006(2):1-2.
SOA的应用技术 篇10
针对以上问题,本文提出并设计实现一种基于SOA的医院应用集成系统。系统采用了总线型的集成结构,其中的应用提供者作为service provider发布该集成结构的总线上,应用的使用者作为service consumer通过总线来使用这些应用服务。该框架可为医院应用集成和医院间协作提供信息集成、流程集成、信息安全支持和集成服务等功能并形成可重构、可配置、插件化、开放式的医院应用集成平台,以满足医院对现有业务流程整合/分解要求。
1 面向服务体系结构
面向服务体系结构(Service-Oriented Architecture,SOA的思想[2]将企业应用看成是由一些能够跨越企业边界、自我描述、实现某一特殊功能的服务集合所构成。通过标准化的机理,能够将这些服务注册于公共数据库之中,并被感兴趣的请求者发现;通过标准化的方法,服务者和请求者之间能够进行动态绑定和直接交互,实现一定的企业功能逻辑,图1所示为SOA模型。
作为SOA的一种实现手段,Web服务提供了基于可扩展标记语言(eXtensible Markup Language,XML)的标准接口,具有完好的封装性、松散的耦合性、协议规范的标准性以及高度的可集成性等特点,能够良好地满足SOA应用模式的需求。目前已经有一系列基于XML的Web服务标准被业务广泛接受,形成了Web服务的核心技术[3]。服务的提供者可以用Web服务描述语言(Web Services Description Language,WSDL)描述Web服务;用统一描述、发现与集成(Universal Description,Discovery and Integration,UDDI)注册中心发布、注册Web服务;服务的请求者通过UDDI进行查询,发现所需的服务后可以利用简单对象访问协议(Simple Object Access Protocol,SOAP)来绑定、调用这些服务。
2 ESB企业服务总线
企业服务总线(Enterprise Service Bus,ESB)是构建基于面向服务体系结构(SOA)解决方案时所使用基础架构的关键部分,是由中间件技术实现并支持SOA的一组基础架构功能。ESB支持异构环境中的服务、消息,以及基于事件的交互,并且具有适当的服务级别和可管理性。简而言之,ESB提供了连接企业内部及跨企业间新的和现有软件应用程序的功能,以一组丰富的功能启用管理和监控应用程序之间的交互。在SOA分层模型中,ESB用于组件层以及服务层之间,它能够通过多种通信协议连接并集成不同平台上的组件将其映射成服务层的服务。
作为SOA基础架构的关键部分,ESB的功能主要体现在通信、服务交互、应用集成、服务质量、安全性以及管理和监控方面。在通信方面,ESB能够支持消息路由/寻址,支持多种通信技术、通信协议(如JMS、HTTP),支持发布/订阅的通信模式,能够处理请求/响应、同步以及异步的消息传递方式,并且要求以可靠的方式传递消息。服务交互方面,ESB上所发布的服务是以当前标准的Web服务描述语言(Web Service Description Language)来定义Web服务的,并且ESB上通常配备有服务目录和发现机制。ESB的重要功能就是集成不同的系统,必须能够支持多种接入ESB的方式(例如将ESB、WebService、CORBA以及使用Socket等方式访问的遗留系统接入到ESB系统),将接入的系统映射成Web服务。在集成不同系统的同时,必须考虑服务质量方面的问题,如事务性和消息传递的可靠性。对于关键的Web服务,ESB需要以加密的方式进行消息传递,并且必须验证访问者的权限。ESB软件作为SOA基础架构的一个复杂子系统,还必须配有相应的管理和监控功能,用于ESB软件自身的系统管理、日志记录、测量和监控等。
3 SOA和ESB
了解SOA和ESB[4]之间的关系非常重要。SOA代表策略、惯例以及框架。这些因素使用应用程序可以提供各种功能并且可以作为服务集合供其它应用程序使用,如图2所示,服务是一种业务完整的逻辑工作单元,可以通过直接开放的文档接口从独立设计环境以编程方式进行访问。可以调用、发布和发现服务,也可以使用单一的基于标准的接口方式抽象实现。应用程序软件由以松散1对1耦合关系存在的服务和服务消费者(即客户)构成。
SOA是软件行业为应对单一大型应用程序的管理问题产生的解决方案。正如我们想象的那样,应用程序体系结构的这一变化对于怎样才能获得最佳的应用程序集成产生了极大的影响。如图3所示,ESB为服务提供者和服务消费者之间的集成提供了一个平台。在现代平台上开发的新应用程序,其本质都是面向服务的应用。但是,有一些现有的企业应用程序并没有使用SOA的设计理念。在此情况下,ESB应该能够提供将这些应用程序暴露为服务的能力。
如上图所示,采用ESB总线的优点如下:
(1)更智能的端点:ESB启用的体系结构在应用程序与外界的接口点处配置了更多的智能功能。ESB允许每个端点使用各种标准(如WSDL等)以服务的形式呈现自己,因此不需要为每个应用程序编写专用接口。可以在端点(客户机和服务器)创建时将集成智能性部署在这些端点上。可以绕过规范格式而将负载直接转换为目标格式;(2)集中式与分布式ESB采用了轻量级的分布式体系结构。当必须将程序间的每次交互转换为规范格式时,集中式的交换中心才有意义。ESB可以将更多的处理逻辑分配到端点上。这与大型主机和现代的分布式系统体系结构间的区别相似。交换中心与大型主机一样,仍然可以用于某些需要它的体系结构中,但它们只是开发人员的一项选择,而不是供应商指定的要求;(3)无集成堆叠-ESB是一个具有相对少层级的软件,您可以使用开放式标准应用其它处理层。例如,如果某个ESB用户希望部署某个特定的业务流程管理工具,您只需使用行业标准接口(如用于协调这些业务流程的BPEL)就可以很轻松地将该工具集成到ESB中。
ESB方法比传统集成方式的好处是可以灵活的配置服务的提供者,减少了硬件和软件的花费,而且还可以通过因使用灵活的分布式框架而节省下来的人力来实现。除此之外,还可以逐步部署ESB以便减少因影响原系统和迁移造成的费用。
4 基于SOA的医院应用服务总线ESB集成方案
当前,医疗信息系统包括的服务对象主要有:从Internet接入的病人,以医院、药店为代表的医疗机构,以药品、医疗器械等供应商为代表的合作企业,区域性的医疗卫生行政机构。病人是医疗服务对象,医疗机构作为医疗服务提供者,供应商为医院的合作伙伴,而医疗卫生行政机构是医疗信息系统的数据中心与管理中心。医疗卫生行政机构的职能有:医疗信息系统的数据标准、公用服务标准,医疗机构资源的接入,医疗机构资源的动态控制管理,整个医疗行为合法性的监管。
4.1 框架模型
为了满足当前医疗信息系统服务对象的多样化以及为用户提供方便性,克服以集成平台为核心的医疗内部系统集成方案在进行跨医院集成方面的缺陷,提出了采用基于SOA的医院应用服务总线集成方案如图4所示。
其中,ESB服务总线是该框架的核心。部署的ESB服务器则将医院内部的基础应用服务例如组件库、应用组合工具、元数据管理、数据映射工具、监控管理和安全管理封装成服务提供者注册在ESB服务总线上,而各种业务系统例如HIS系统、PACS系统、LIS系统和其它业务系统等则通过ESB节点适配器组件来连接ESB总线,通过各系统与总线的业务流程和数据交换来实现各业务系统之间以及业务系统与基础应用服务的业务和数据交互服务。
当某个业务系统需要集成时,它首先调用适配器组件,将其能够提供的服务用WSDL描述后,用适配器组件以消息形式发布到ESB总线上,等待请求者调用。在调用时,可通过适配器将原系统的消息封装为HL7标准的XML消息。而要调用其它业务系统的功能时,也是通过适配器请求ESB服务总线,ESB服务总线则查找相应的服务,并将该服务请求以消息形式请求相应的业务系统。
4.2 服务调用流程
我们现在以LIS系统通过调用HIS系统病人基本数据服务的情况为例子讲述调用应用服务的过程。假设医院的HIS系统已经将病人基本数据服务注册到ESB服务总线上。调用过程如下:
(1)服务请求者(LIS系统)通过适配器组件用WSDL描述需要访问的服务,用SOAP消息向ESB总线发出查询病人基本数据请求;(2)LIS系统发出的请求经系统认证授权,ESB总线会根据请求查询到总线上注册的病人基本数据服务,并将LIS系统发出的消息转换成HIS系统发布服务所要求的数据格式,并将该服务请求向HIS系统发出相应的SOAP请求消息;(3)经ESB总线发出的请求消息通过适配器组件传递给HIS系统,HIS系统则根据该消息将病人的结果通过适配器组件以HIS系统发布的Web服务转换成符合HL7标准的XML文档,然后封装成SOAP消息;(4)该SOAP消息会传递回ESB总线,ESB总线则将结果转换为LIS系统所能识别的数据格式并以SOAP消息封装传回给LIS系统。
5 总结
针对传统面向接口的集成方式不能方便、低代价地实现异构系统的集成,难以适应现代医院快速的业务变化需求。本文提出了一种基于SOA架构的医院应用服务总线来集成医院内部的各业务系统,解决了传统架构技术无法解决的问题。基于ESB总线的架构提供了一种各业务系统与基础服务之间一种松耦合的服务模式,任何业务系统都可以提供服务,也可以调用服务,在提高系统组件可重用性以及实现业务过程的灵活地改动和再造方面有着不可比拟的技术优势。
参考文献
[1]谢梅源.以面向服务体系结构(SOA)架构社区医疗信息系统.温州职业技术学院学报,2006,5(3).
[2]张明宝,夏安邦.基于面向服务体系架构的敏捷虚拟企业信息系统框架.计算机集成制造系统,2004.10.
[3]刘伯超,马晓轩,葛声.基于Web服务的软件服务体系结构的研究与实现.北京航空航天大学学报,2004.30.
SOA的应用技术 篇11
由于历史的原因,一些信息化不够充分的企业往往建设了不少业务系统,这些业务系统基本上都是C/S应用。在新的SOA技术架构中重用这些业务系统是一个比较重大的工作,需要根据实际情况,设计出复用、集成这些原有系统的方法。需要满足如下原则:
1.着重规划。对于旧有业务系统的复用、集成需要有整体的规划,是合理、有效复用、集成旧有业务系统的前提,也是实施SOA最为基础的一步。有了规划,才能去选择现有条件下最适合的技术和工具,最后用这些技术和工具实现这些业务系统的复用。
2.从局部到整体。SOA让企业可以搭建一个松藕合的平台,但是SOA不可能一蹴而就,在企业内部规划、实施SOA是一个长期的过程。在企业内部实施SOA时总是先从部门级开始,从最关键的业务开始,然后慢慢扩充到其他业务、其他部门,到最后实现整个企业的SOA。设计出来的复用集成方式必须满足这种小步快跑式的SOA实施方式。
3.有破有立。由于已经建设的业务系统比较多,采用不同的技术架构开发,在实施SOA时,需要考虑到复用集成时的各种情况,提供符合条件的复用集成方式。一些太落后的系统可以考虑推倒重来,对于那些还能继续应用的系统,需要提供包装、升级到新的技术架构的解决方案;对于那些太过于封闭的旧有技术架构,要考虑如何用最新的集成手段来将它开放成服务,加入到新的SOA体系中来。
二、重用遗留C/S应用的几种方式
在一个企业内部实施SOA 并是简单的把原来的业务系统全部拆掉后重建,理想的做法是在一个企业目前正在使用的应用、系统和资产中确定可重用的、高价值的业务系统,采用 SOA 的理念、原则、方法和技术来标准化这些任务,使他们可以在企业内部得到重用。重用已有的应用程序和系统是非常明智的决策,可以减少企业在实施SOA时的资金投入,且重用现有业务系统不会对现有业务造成太大的冲击,可以显著降低企业实施SOA时的风险。
这些现有业务都已经经过了长时间的运营,是公司拥有的最宝贵且经过验证和时间考验的资产,重用原有的业务系统还可以大幅度加速 SOA 项目的实施进度。相应的研究结果显示:重用原有业务系统的开销比从头构建这些业务系统需要的费用少五倍。由于这些遗留系统已经过了严格的实践的检验,其维护开销也会减少。根据实施SOA时企业内部IT项目建设的阶段和原有遗留系统的实际状况,我们需要采取不同的策略来集成原有代码:
1.系统服务化。这种方式是指直接将原有系统的源代码通过SOA技术架构发布为服务,在新的体系结构中直接复用。
2.系统架构升级。这种方式是指采用新的体系架构升级原有C/S业务系统,或者是将该系统中需要新增加的功能基于新的体系架构重建,或者在该系统使用寿命达到标准后重新创建该系统。
3.系统集成。这种方式是指通过系统集成的方式使用原有代码,达到业务重用的目标,如实施SOA时直接采用采用EAI、ESB等技术集成那些遗留下来的C/S应用。
4.遗留系统拆分。这种方式是指在SOA实施过程中,直接利用原有C/S应用,达到业务系统重用的目标,只是需要将遗留系统拆分成更小的系统,以满足服务拆分的需要。如在实施SOA过程中直接采用业务系统调用的方式,直接启动原来的C/S应用,让用户使用。
5.其他方式。根据实际情况,我们可能还需要提供其他的重用方案,如直接使用那些还具备使用价值的、比较独立的业务系统,或者是采用以上三种方式的混合形式来达到系统复用集成的目标。
三、代码服务化
采用代码服务化的好处是服务接口由所公开的遗留资产定义,不需要进行分析来设计接口规范。由于新服务可以在与包装的现有资产相同的平台上运行,没有必要添加新基础设施。能省略接口定义和分析,要处理的平台更少,这样部署周期就会更短,风险也更小。采用代码服务化方法时需要重点考虑如下事项:
(1)服务使用者需要与旧有系统的服务定义建立联系,而旧有系统在很多情况下的最初设计都不是按照面向服务的方式来设计的。
(2)这种重用方式假定现有应用程序平台提供了对服务调用的最新技术的支持。
(3)这种实现模式会给系统带来服务消息处理的压力。
四、系统架构升级
采用系统架构升级的方案中,我们在现有应用程序功能和服务之间引入构件层,所有需要被服务化的原有系统,都遵循先被构件化,然后被服务化的过程。构件可以提供服务和实际实现之间的抽象,封装了对原有系统的所有操作,同时提供了更多的灵活性。使用构件有如下好处:
(1)可以在不影响服务使用者的情况下更改现构件的业务逻辑实现。这些构件可以方便地进行扩展,以封装数据和信息构件,为数据或信息服务提供外观层,对于服务使用者来说,这些服务是透明的。
(2)可以在构件层进行系统和功能的组装和编排,构件服务使用者的影响很小或者没有影响。
(3)可以将服务部署在与现有应用程序不同的基础设施上,现有应用程序的基础设施通常针对服务的特定处理要求进行了硬编码。
这种重用模式体系结构有自己的特点。
(1)它允许服务与业务保持紧密一致,但并不一定直接映射到现有应用程序接口的服务接口定义。
(2)可以支持使用 SOA 的原则和最佳实践来以正确的粒度级别设计服务和接口,与此同时,这也会增加服务定义的设计工作。
(3)引入构件层后,设计工作会比直接将应用程序公开为服务更为复杂,可能会涉及到使用适配器或连接器技术来与应用系统进行连接。
五、系统集成
在采用系统集成方式重用原有C/S应用时,原有信息系统本身作为服务提供者而独立存在。它提供的服务被整合到新的技术架构中。系统集成模式的主要优势在于,可以不需要花很多时间为服务定义开发实现构件,由服务提供者直接提供这些服务及其接口,这可以大幅度降低SOA实施时间。服务消费者可以很容易的根据不同的业务场景在服务提供者之间进行切换。整合集成模式体系结构需要重点关注的事项:
(1)必须恰当地定义服务的服务级别协议,确认被整合的应用系统能够提供满足要求的服务。
(2)系统和系统之间通过服务调用完成交互,如果是在非局域网环境下,需要考虑到安全的问题,如增加防火墙等。
六、遗留系统拆分
在遗留的C/S应用中,会存在一些非常独立的系统,他们和其他的系统之间不存在什么联系,甚至也不需要交互,只是需要根据不同的人提供不同的权限或者是更小的调用域,这个时候我们就可以采用遗留系统拆分的方式来直接利用这些C/S应用。遗留系统拆分模式的主要优势在于,可以不需要花很多时间为来处理服务化、接口等内容,而只需要简单的利用遗留的C/S应用,将它拆分成更小的应用即可。这可以大幅度降低SOA实施时间。遗留系统拆分模式体系结构需要重点关注的事项:
(1)系统本身应该是非常独立的,完成相对独立的业务,和其他系统之间不存在太多的交互。
(2)必须恰当地定义拆分的标准,以满足可被重复利用的可能性。
(3)必须考虑如何调用这些遗留的技术路线。
SOA的应用技术 篇12
应用系统的规模和功能复杂性在逐年增加，特别是在企业级应用系统中表现的更加突出，中间件技术在解决企业应用系统不同信息管理系统的自治性，异构性，及其之间的交互性以及对以往遗留信息系统的支持方面作出了很大贡献。然而，随着多种中间件技术的兴起，带来了跨平台计算问题。为了实现不同中间件平台之间的集成和互操作，OMG (Object Management Group) 提出了标准的模型驱动架构MDA (Model Driven Architecture) [1]。MDA主要由三部分组成:平台无关的模型 (PIM) ，模型转换器 (MT) ，特定平台模型 (PSM) ，将系统的功能描叙及其系统具体平台上的实现分离开来，通过模型转换器实现系统模型到应用代码的转换。为了提高对分布式计算和信息系统集成领域的技术支持，OMG提出了功能更加完善的SOA (Service Oriented Architecture) ，服务作为一种平台无关，开放和自治的网络化构件，使分布式应用具有更好的复用性，灵活性和可扩展性等优势。伴随着应用系统的发展变化，为了满足软件工程人员对应用系统高质量的保证，软件测试技术也蓬勃发展起来，软件测试由最初的全手工输入的代码测试，到部分人工参与的半自动化测试及自动化测试 (主要是利用各种测试应用工具) ，以及近年来逐渐兴起的MDT (Model-Driven-Testing) 。随着可视化UML (Unified Modeling-Language) 建模工具描述功能的完善和各种功能测试工具的出现，加速了模型驱动测试方法学在现代软件系统的应用。模型驱动测试极大地减少了软件生命周期中软件测试阶段的人力劳动和测试时间，缩短了软件上市时间，提高了软件质量和开发效率。同时，模型驱动软件开发和测试方法学都是面向领域建模软件思想的应用，极大的提高了系统的复用性和软件开发的生产力。
关于模型驱动测试的研究颇多，其中以AGedis[2]项目研究成果最为突出，文献[3]提出了模型驱动测试开发方法学和产生了用于模型驱动测试开发的开发工具，文献[4]侧重于用于模型驱动测试开发工具体系架构的研究。虽然基于模型驱动测试的具体应用研究很广，但多数都是侧重于模型驱动测试建模的研究，很少有对模型驱动测试开发应用软件的研究。然而到目前为止，专门用于模型驱动测试软件开发的集成开发工具还没有出现，但应用于模型驱动测试各个开发阶段的商业工具却非常多，基于Eclipse架构面向模型架构软件开发和模型驱动测试的开源组件和插件工具的发布，使得模型驱动测试软件开发有了实践的平台。本论文就是利
用基于Eclipse架构的OAW和JUnit组件作为应用工具进行模型驱动单个服务测试的研究。下面将分两大部分来叙述：
2 面向服务架构测试概述
本文是对面向服务架构应用Service的模型驱动测试的研究，所以有必要在这里简单介绍些面向服务架构和服务及其测试的相关内容。众所周知，应用系统的测试过程包括下面三个过程：单元测试，集成测试和系统测试。由于面向服务架构的服务具有动态配置，灵活应用的特征，同时，组成应用系统的服务还可能由第三方服务生产厂方提供，这样使得面向服务应用系统的测试工作难度更大。为了确保应用程序能够按照预期定义的功能正常运行，我们必须首先对组成服务的单个服务独立进行测试 (即单元测试) ，然后对组成业务过程的服务集进行业务处理过程测试 (即集成测试，主要是对不同服务之间通信与协作的测试) ，最后对整个系统的功能进行测试 (即系统测试) 。面向服务是指在应用系统业务处理过程当中，系统的整个业务功能被合理的分解成具有一系列相互独立运行的组件 (即服务) ，所有的各种服务组成一个服务集合。服务是不依赖于计算机硬件平台，操作系统及系统开发程序语言的，同时又是异构的，自治的逻辑单元。而我们常提到的面向服务多数指面向web服务，实质上，这只是其得到广泛应用的一个领域，不能涵盖其所有内容[1]。面向服务架构是一种分布式，松耦合网络架构，在这里我们不对它进行详细全面的介绍，主要介绍其三个最重要标准组件：SOAP (SimpleObjectAccessProtoca-l) ，UDDL (UniversalDescription, Definition, an-dIntegration) ，WSDL (WebServiceDefinition-Lan-guage) 。由于本论文侧重单个服务的测试，我们将详细介绍WSDL内容，并在下面以作为案例的agiotagerServices (货币兑换服务) 进行描述，如下面程序所示。WSDL是一种基于XML的服务描述及服务如何被访问的定义语言，主要包括下面四个部分:端口类型 (portType) ，通信消息 (message) ，类型 (types) ，端口绑定 (bindings) 。在一个服务描述文件中，端口通过端口类型元素定义，端口元素描述了服务提供的操作;通信消息用于定义在服务提供方和服务使用方之间传递的各种消息;类型描述服务使用的数据类型，端口绑定描叙服务使用的通信协议。面向服务架构软件系统的单个服务测试包括下面三个方面的内容：1) 测试单个服务的所有服务端口;2) 测试服务端口上的所有操作;3) 测试所有操作使用的数据元素的正确性。
3 货币交换服务测试
模型驱动测试是指系统分析初期将软件设计需求分析书与测试规格说明书紧密结合起来产生行为模型，利用测试工具进行自动化测试的过程。系统需求分析说明书详细定义了系统的功能和系统中各参与角色业务活动，而测试规格说明书描述了系统测试需求及其定义了的一系列测试用例集。软件测试就是在测试规格说明书的指导下测试应用系统是否满足它在系统需求分析中的功能定义，并按照预期定义的结果进行显示。我们在这里将模型驱动测试过程划分为以下主要三个阶段：设计阶段，代码产生阶段，和运行阶段。在设计阶段生成测试规范抽象模型和转换模板，在代码产生阶段，通过采用代码产生工具 (如TGV, GOTCHA) ，将测试规范模型转换成测试代码。这两个过程是独立于特定平台，与开发应用系统的特定开发技术无关的。在测试运行阶段，则需要利用测试引擎 (如JUnit, Fitnesse) 去测试给定系统，即测试系统 (SUT) 。测试系统不单是指一个功能完整的应用系统，有时也可以指单个的功能模块，或单个的类，甚至类中的一个方法。由于测试系统体系架构，开发语言等的不同直接利用已有的测试引擎去测试各种测试系统是不可能的。这时，我们就需要在选定的测试引擎环境下定义适当的接口类，用于实现测试代码与测试系统之间的映射，即接口适配器。接口适配器对测试代码进行了封装。同时对在软件测试过程中生成的桩类和仿真类提供支持。在本文中，我们选取一个功能非常简单的货币兑换服务 (agiotagerServices) 来进行说明，按照前面描述的模型驱动测试的三个阶段分三个小节来详细说明单个服务的测试过程。该服务只有一个不同种货币进行兑换的方法，详细定义如上所示。
3.1 设计阶段
在这一阶段，我们根据测试系统需求分析说明书对系统测试进行设计，生成测试规范和测试代码产生模板。其中测试规范模型我们采用OMG对UML进行扩展的UTP (UML Testing Profile) 视图来描述模型驱动测试领域概念：测试系统 (SUT) ，测试上下文 (TestContexts) ，测试集 (TestSuit) ，测试用例 (TestCase) 。根据模型驱动测试的需要，在遵守U2TP协议的前提下，我们定义了构造型<
测试用例集中定义的测试用例，在测试运行时通过消息机制依次调用测试系统的相应的功能函数。如在本案例中调用汇率转换器的方法adiotage (100, dollar, yuan, 6.795) ，汇率转换器的一个实例就被创建，它接收传递过来的实际参数，执行后将产生的结果传递到参与断言的实例中，参与断言根据预期设置的值判断该测试是否通过，输出测试结果。
3.2 测试代码产生阶段
测试代码产生阶段是利用前一阶段生成的测试模型和转换模板产生测试代码的过程。然而对于某些测试系统而言，由于产生的测试代码的不完备性，我们需在测试执行阶段定义一些特定数据结构 (如多维数组) ，保留特定的测试数据值和测试返回值数偶，用以对测试系统进行完备性测试。同时，测试系统本身功能复杂性和及其对测试模型和模板转换产生不同格式代码的多功能性，选择一个功能强大的测试生成工具就变得尤其重要。在本论文中，我们是利用OAW工具集来产生测试代码。如下所示。
我们可以看到，产生的测试代码是平台独立的。测试集中每个测试用例对应其中一个测试方法，由@Test符号引导。每个测试用例包括两个部分：定义块和消息块。定义块引用了参与该测试用例顺序图所有类，在需要时创建所需的对象实例。消息块表示测试用例顺序图参与角色之间调用消息及其传递测试结果的断言。
3.3 测试运行阶段
测试运行阶段是模型驱动测试的最后一个环节，可以执行在不同平台上。由于通过测试生成工具产生的测试代码是不能在测试引擎环境中直接对测试系统进行测试，这就需要我们编写相应的接口适配器。在这里我们选择JUnit作为测试引擎，故而我们采用Java语言依照测试代码编写agiotagerServices服务接口适配器文件，部分代码如下所示：
测试适配器文件用于对远程方法调用进行打包，有时也可用于对测试用例初始化进行打包，如数据库初始化代码或者对复杂测试状态判断的预期值的设定。接口适配器在测试阶段的早期，如果测试系统没有被完整的测试，我们还可以通过接口适配器文件中添加测试内容对其进行补充测试。当然，测试代码的缺陷我们主要还是通过修改测试模型和测试模板从整体上来进行改进，这也正是模型驱动测试的优势所在。在软件测试运行过程中，对于复杂的活动图，需要根据测试系统的要求，定义参与活动的服务角色桩模块。在agiotagerServices测试运行过程中，通过在agiotagerServices有目的的修改agiotageTest (float:, enum:, enum:, float:) 方法的参数变量，出错部分都能正确反映输出的断言中。
4 结束语
本论文通过一个简单的货币兑换服务，结合模型驱动测试方法学和面向服务架构，对单个服务如何进行模型驱动测试软件开发过程进行了详细阐述，为模型驱动测试应用系统开发提供了借鉴作用。然而，本论文主要侧重于单个服务的功能测试，而且测试系统简单，没有考虑测试系统内部功能模块及其业务数据结构的复杂性。特别是如何对不同服务组成的业务处理服务集合进行的集成测试，对其的实用性研究还有待后续深入。
参考文献
[1]鲍志云.解析MDA[M].人民邮电出版社, 2004.
[2]http://www.agedis.de.
[3]Alan Hartman, Kenneth Nagin.Model Driven Testing-AGEDIS Architecture Interfaces and Tools.IBM Haifa Research Laboratory.