面向服务架构SOA

面向服务架构SOA（共9篇）

面向服务架构SOA 篇1

0、引言

随着社会的快速发展, 一个企业、单位、部门需要不断组建新业务, 企业间的合并、企业内部部门的重组, 国家政策的变化也可引发企业原有业务的变化。通过手持移动设备、ATM机、计算机网络、客户呼叫中心、公司员工等多个渠道为客户提供同质服务对现代业务提出了新的要求。另一方面企业现有业务运作的传统IT系统, 积累了大量数据财富, 但由于开发技术不同, 开发团队相异, 采用的数据格不统一, 已成为企业进一步开发新业务的障碍。

一个企业的IT战略是其发展的信息基础, 其IT架构的构建, 需要企业决策者、各级业务管理部门、IT设计人员共同参与;在此过程中企业业务人员与IT设计人员之间的快速有效沟通成为关键要素。传统的沟通方法是双方在市场调研、需求分析、功能设计阶段进行反复磋商, 根据业务和IT技术的要求, 由IT人员落实。这一过程比较长, 甚至出现了IT系统还没有完成, 原先的需求就发生了变化。因此只有在更高层次的业务建模、业务流程、流程管理的概念框架下进行沟通才能尽快地将业务变化落实到IT架构中, 适应敏捷业务的要求。

基于以上所述, 传统的软件设计方法已无法适应现代企业业务敏捷化的要求, 已无法考虑到复杂多变的业务需求, 社会迫切需要一种新的软件设计方法。另一方面, 面向对象的程序设计技术, CORBA、DCOM、JAVA Bean等分布式组件技术的发展, 为新的软件设计方法积累了一批经验, 提供了技术保证。在这一背景下, 促成了面向服务的架构SOA的诞生和发展。

1、SOA的发展过程

具备SOA形式的系统出现得比较早, 但概念最初由世界著名的咨询公司Gartner于1996年提出7。其基本思想是将企业应用程序构建为一系列可执行业务功能的服务, IT资源通过服务的形式重用;业务模式在动态业务环境中重新组合, 以此满足企业业务敏捷性的要求。另外, 从社会的角度看, 企业愿意将自己的服务通过无偿或有偿的方式提供出来供别人使用。

SOA的发展, 其实质就是SOA标准规范的发展, 根据Steve.Jones的观点1, 经历了中间件和Web服务两个阶段。上世纪80年代初TCP/IP技术的发展, 催生了中间件技术, 如CORBA的I-IOP, 后为解决中间件的紧耦合问题产生了SOAP、WSDL、UDDI等Web服务技术。

Gartner预言, 至少有60%的企业将采用SOA做为其IT架构2。在国内, 许多高校、科研机构和企业举办各种关于SOA的研讨会。如普元信息技术有限公司2007年在成都、广州、上海、北京举办了四次关于SOA在中国如何发展的研讨;共有1600人次以上的CIO、IT信息主管和技术精英参加3。可以肯定的说, SOA已成为计算机领域内近年来最热门的研究领域之一, 是企业IT战略架构的必然模式。

2、SOA概述

2.1 SOA的概念及相关错误观点

SOA是Service-oriented Architecture的缩写, 称为面向服务的体系架构, 是一种软件架构方法、原则。有译为"以服务为中心的体系结构"2。它是Internet环境下信息系统集成的一种体系架构。在这种体系结构中, 以高度抽象的具有独立功能的服务为基本单位构造各种松耦合的应用系统, 以最大的灵活性和重用性提高应用系统的开发效率。

目前, 对SOA的认识存在三种误区, 表现为以下三个方面:

(1) SOA就是Web服务

Web服务是SOA最重要的实现手段, 但不是唯一形式。服务组件架构SCA (Service Component Architecture) 和面向服务的数据对象SDO (Service Data Object) 构建的系统是SOA的一种形式;eb XML规范构建的电子商务系统又是SOA的另一种形式;CORBA、DCOM、JAVA Beans等中间件技术也可构建SOA形式的系统。

(2) SOA是一种新的技术

把SOA与面向过程、面向对象的程序设计等同起来, 认为是一种全新的技术。其实, SOA的服务仍然靠传统软件技术去实现, 只是在具体的程序实现基础上抽象出了一层描述层, 将具体的实现与描述隔离开来, 使业务人员和部分设计人员能够在该层进行高度抽象的设计。

(3) SOA是各种规范、标准的集合

SOA是实现异构系统互操作的最佳体系架构, 各种标准、规范是其理论基础。但实现SOA还需要各种具体的软件技术和开发平台, 各种平台在支持基本标准的基础上, 对各种扩展标准有不同支持。

2.2 实现SOA的主要技术

基于开放标准, 具有粗粒度、松耦合服务的技术均可构建SOA。实现SOA的技术有许多种, 主要有Web服务技术, SCA、SDO技术, 分布式对象技术, Web Sphere MQ技术, B2B Platform技术等。

2.2.1 Web服务技术

Web服务是实现SOA的最有效手段, 其SOAP、WSDL、UD-DI、WS-Security、WS-Transaction、WS-Policy、WS-Reliability、WS-addressing标准和规范丰富了SOA的思想, 其描述的服务在业务层抽象, 独立实现, 构造的系统具有松耦合性, 服务能够重用, 有明确的接口定义, 较粗的粒度, 无状态等特点, 这些是SOA的典型特征。目前已有大量的Web服务平台供开发者选择, 如IBM的Web Sphere application server6, 微软的.NET Framework等。

2.2.2 SCA、SDO技术

服务组件架构直接采用Web服务和XML开发服务, 程序员在底层技术上考虑各种异构环境的具体实现细节, 通过组件的实现提供服务, 用接口公开其功能, 并使用其它服务。SDO定义和规范了服务的数据, 使SCA独立于数据源和具体数据访问技术, 实现服务间的数据交换, 通过对组件的组装构建应用系统。

2.2.3 分布式对象技术

分布对象技术包括CORBA、J2EE、DCOM等, CORBA是一个开放标准, 支持RPC (Remote Procedure Call) 调用, 多种编程语言, 可把CORBA对象作为Web服务发布, CORBA IDL可作为服务定义语言, 实现高层次抽象, 用其构建的SOA系统效率较Web服务的高, 但CORBA要求服务请求者和服务提供者都用CORBA实现。J2EE除具有开放标准, 支持远程调用外, 本身支持XML和SOAP进行通信, J2EE EJB也可将其对象直接发布为Web服务。

2.2.4 B2B Platform

Eb XML、Rosetta Net也是理想的构建SOA的Web服务平台, 它们都有开放标准, 基于XML和业务文档异步交换, 为服务注册、服务安全、服务监控与管理、业务流程管理、补偿事务及可靠消息传递提供了集成机制。

2.3 SOA的标准规范体系

SOA是基于许多开放标准的, 这些标准实现了异构系统之间的互操作。主要有eb XML系列标准 (eb XML Registry、eb XML BP、eb XML msg、UBL) , Web服务系列标准 (SOAP、WSDL、UDDI、BPEL、WSDM、WS-Security、WS-Reliability、WS-Transaction、WS-CDL) , SOA本身标准 (SOA IM、SOA CS) 等。

2.3.1 SOA运行时的架构1 (如图1)

2.3.2 主要标准

SOAP (Simple Object Access Protocol) 称为简单对象访问协议, Web服务的基本标准。Web服务用作其所有信文的规范, 基于XML, 在分布式环境下交换结构化、有类型的数据。

WSDL (Web Service Description Language) 称为服务描述的语言。用于在抽象层描述服务传递消息的类型、服务的操作、服务的地址、服务的接口、服务名称、服务与SOAP的绑定等;完成服务的描述与服务实现的隔离。现为Web服务的基本规范。

UDDI (Universal Description and Discovery Integration) 称为通用描述、发现与集成标准, 虽然发布早, 由于支持的厂商少, 仍不能算作Web的基本规范。它主要实现服务的注册、服务的分类、服务的查找。一般有发布和修改、发现和获取两类操作。

Web服务事务模型与规范, WSCoordination和WSTransaction (简称WS-C、WS-T) 。其中WS-T包括WSAtomic Transaction和WS-Business Activity。是Web服务的补充规范。

Web服务的安全协议, Web Service Security (WSS) , 主要是解决用户令牌的传递、SOAP消息的完整性和保密性。是Web服务的补充规范。

只有基本标准和规范还无法提供满足企事业要求的服务质量, 有了补充规范后才能建立企业级的SOA, 即对安全、可靠、事务提供支持。

3、SOA的实现

3.1 SOA的设计模式

SOA的设计模式有服务注册表 (Service Registry) 模式, 企业服务总线 (Enterprise Service Bus, ESB) 模式, 服务编排 (choreography) 模式三种。

3.1.1 服务注册表 (Service Registry) 模式

服务注册表模式是基于SOAP、WSDL、UDDI标准的模式, 在这种模式下由服务请求者、服务提供者、服务注册表三种角色组成, 其架构如图2。实现过程4如图3。根据注册表服务的对象又分为有公有注册表、私有注册表、专有注册表三种。

3.1.2 企业服务总线 (Enterprise Service Bus, ESB) 模式

ESB是一个提供通信、整合、安全、事务支持和服务质量控制等SOA要求性能的基础架构。ESB通过提供一个服务的地址和命名控制点来提供这些性能。服务请求者通过以特定的地址和协议调用服务来访问ESB。ESB有许多端口, 一个端口包含一个协议, 一个或多个地址, 一个特定的方式处理服务交互的特性, 如事务、安全等。具体架构如图4

3.1.3 服务编排 (choreography) 模式

服务编排模式采用基于应用的逻辑封装服务, 从而将组合服务中的服务排序与具体服务分离开来, 以小粒度的服务组合成大粒度的服务, 模式化的实现商业流程并自动执行, 监视商业流程的执行效果, 实现工作流解决方案。具体实现技术有两种:基于BPEL4WS标准的服务编排实现;基于特定工作流或消息流的实现。

3.2 Web服务平台

Web服务是实现SOA的最重要手段, 现在有许多软件工具帮助实现服务的发布、管理、整合、服务请求者与服务提供者之间的数据转换。这些软件统称为Web服务平台。

3.2.1 Web服务平台的关键要素

Web服务平台为服务请求者和服务提供者进行交互提供了与下层实现技术无关的基础设施, 关键要素有服务契约、服务契约库、服务注册与查找、服务层安全、服务层数据管理、服务层通信、多协议和多传输支持、服务层服务质量、服务层管理、对多种编程语言的支持、服务的编程接口。这些要素能够完成服务的定义 (WSDL文档自动生成) 、保证企业级服务质量, 将复杂的服务调用、数据转换自动完成。

3.2.2 Web服务平台的选用原则5

(1) 平台必须是基于标准或规范的, 至少支持SOAP、WSDL。

(2) 根据企业或单位的各种需求, 解决方案考察现有及新兴标准, 并评估这些标准的成熟成度, 有无竞争的标准。这些标准在不同厂商的产品及技术间的互操作性。

(3) 考察企业的独特需求与资产, 充分利用这些已有的投入。

(4) 标准本身由于竞争问题产生互操作障碍, 要考虑WS-I是否有这些标准的Profile。

3.2.3 Web服务的实现过程

Web服务的开发过程可以分为服务的发现、服务的描述或发布、服务的逻辑实现、服务的调用。

3.2.3. 1 服务的发现

在SOA的实现过程中, 服务的发现是指在一定范围内 (通常是企业范围、或若干关键业务流程范围内) 确定可能成为服务的服务候选者。一般采用下述三种方法确定服务候选者。第一种方法是自顶向下分解业务进行分析, 该方法将业务活动从上层分解直至每个业务活动都可以清楚的进行描述为至, 然后再逐级向下分解每个子业务活动, 将最终的子活动做为服务候选者。第二种方法是通过业务目标来分析, 该方法通过对业务目标进行分析, 进一步找到新的服务。第三种是自下而上的对现有系统分析, 找出前两种分析过程遗失的服务。这三种方法共同筛选才能找出所有服务。服务的发现必须在业务、流程、业务流程、业务建模等抽象层进行, 贯彻业务对齐、松耦合、重用的原则。这主要由业务分析师和系统架构师完成。

3.2.3. 2 服务的描述或发布

服务的描述主要是完成服务的WSDL文档的生成, 用来说明服务采用的数据类型、提供的操作、传递的消息、服务与SOAP的绑定、服务的地址和名称、服务的质量等。服务的WSDL可以由服务开发人员书写, 也可以程序包装发布成服务时自动生成。服务的发布就是将具有独立功能, 完成特定业务的程序打包成Web服务, 在服务平台中注册。

3.2.3. 3 服务的逻辑实现

服务的逻辑实现由IT设计人员或程序人员完成, 同样的服务描述可以在不同的操作系统环境下, 用不同的语言完成。由服务平台完成服务描述到服务实现间的映射, 服务请求者不需了解技术细节。

3.2.3. 4 服务的调用

服务请求者必须输入实际参数、根据服务的WSDL编写和解读SOAP, 才能调用相关服务。这些可以由用户编写程序来实现, 也可以由Web服务平台自动生成, 即根据WSDL生成服务代理 (Service Proxy) 与服务框架 (Service Skeleton) 。服务调用者根据服务代理生成的调用代码调用服务, 服务开发者根据服务框架生成实现服务的代码框架。

4、SOA的发展趋势

4.1 We服务标准日臻完善

众多主流IT公司和组织的参与, 使各种基于互操作、安全、系统重构的标准不断完善。每一个标准大致从最初提出要经过Proposal Draft、Working Draft、Nomination Draft、Specification、Standards几个阶段。现在规范标准有:SOAP、WSDL、UDDI, WS-Security、WS-RP、WS-Reliability、SOAP-MTOM。推荐标准有:ASAP、BPEL、WS-Coordination、WS-Policy, WS-Addressing、WS-CAP、WS-Choreography、WSDM、WS-Eventing、WS-Federation、WS-IL、WS-Provisioning、WS-Reliable Messaging、WS-Resource Framework等。总共有30多个, 这些推荐、规范、标准为SOA的发展开辟了广阔的空间和奠定了坚实的基础。

4.2 SOA的开发平台

目前的主要开发平台有Apache SOAP2.3、AXIS1.2 (Apache Extensible Interaction System) 、IBM的Web Sphere application server6、Microsoft Visual Studio.NET、Sun ONE Web等。

在市场上, Web Sphere具有主导地位, Web服务应用平台市场的竞争主要就集中在IBM Web Sphere和Microsoft.NET两家之间6。随着开源运动的发展, 基于JAVA Bean的Sun ONE Web也成为SOA开发人员的重要平台。

4.3 基于SOA的应用开发发展迅速

到目前为止, IBM已经帮助全球4500多家企业成功地实施了基于SOA的整合, 这其中包括很多中国的企业, 如中远集运、北京朝阳区政府、南京玄武区政府、山西移动等。8在国内电力行业开始将原有系统改造成SOA架构, 许多企业开始将原有系统重新整合成SOA架构, 以满足新形势下业务敏捷性要求。许多高校和科研机构积极进行SOA相关的各种研究, 成如火如荼之势。

4.4 目前的研究热点

在SOA的开发中, 将多个独立的服务组合成复合服务, 形成服务流程, 通过服务流程满足企业业务的要求。服务流程的编排成为SOA系统的关键, 一个服务可以被多个流程使用, 一个服务流程也可发布为一个服务供其它服务流程调用。服务的评价是服务编排中必须考虑的问题, 服务的可靠性、响应速度、安全性等成为服务编排时的重要因素。

5、SOA发展中存在的问题

5.1 标准有待进一步完善

标准化不足是制约SOA发展的重要因素。Web服务是实现SOA最好的方式, 但Web服务本身还有很多不成熟的方面。除了SOAP和WSDL相对成熟外, 在可靠消息、安全Web服务、Web事务处理等方面的标准还有待完善。存在着不同组织机构竞争的局面, 如eb XML系列的标准和Web服务标准有重叠, W3C的WS-CDL与OASIS的BPEL同是服务编制领域的规范;Web服务规范中用于表达策略的有三种, 由BEA、IBM、Microsoft及SAP开发的WS-Policy Framework, OASIS的Web Service Policy Language (WSPL) , W3C的WSDL 2.0 feature and properties。这三种规范不统一, 给开发者造成选择的困难。

5.2 服务质量有待提高, 可公开的服务少

服务需要不断的维护, 并使用服务提供者的资源, 现在还没有建立一种有偿使用机制, 各大公司并没有向SOA理想中的那样, 将自己的服务公布出来, 影响了SOA的发展。

5.3 概念体系不够清晰

现在SOA被各种媒体热炒, 出现了各种错误的概念。如把Web服务的软件架构就认为是SOA, 又有人认为SOA是一种新的技术, 把SOA的实现技术ESB当成是SOA。将SOA与前面的软件设计割裂开来, 认为解耦、松耦合、代码重用是SOA的主要特征。

6、SOA实现过程中的问题解决办法

(1) 根据企业级服务质量构建SOA, 选择合适的服务质量规范, 合理的服务平台。

(2) 基于业务对齐的角度分析SOA的服务, 从低耦合、粗粒度、可重用的角度描述服务。

(3) 从局部到全局性逐步实现SOA, 甚至只实现传统部分系统的集成。

(4) 根据服务规约对服务质量进一步完善, 在有偿使用、服务响应时间、服务数据的可靠性、安全性等方面扩大服务的使用率, 推进SOA的发展。

结束语

SOA的发展必将对企业的业务拓展、服务质量的提升、技术成本的降低产生重大影响。对软件设计方法从思想、方法产生革命性的变化。我们现在谈论SOA多在理想的环境下进行, 总是认为所定义的服务恰好适合企业的业务, 不需要任何后续的返工或修改即可重用于多种业务运营;定义的服务已在粒度、耦合度、重用性和技术中立间作了平衡, 而且保持高效的、可伸缩的、安全的和可靠的优势。事实SOA的实现对一个企业来说应是一个长期规划, 经济效益是其根本。

摘要：本文通过对SOA产生的社会原因、发展过程的分析指出了其出现的必然性;从SOA的概念内函、标准、实现技术说明了SOA的基本组成;从SOA的设计模式、Web服务平台、服务的实现过程介绍了SOA的实现过程。同时分析了SOA的发展趋势、目前存在的问题以及应对办法。

关键词：SOA,Web服务,平台,系统集成,中间件

参考文献

[1].李春旺.SOA标准规范体系研究[J].现代图书情报技术.2007 (5) 。

[2].毛新生.SOA原理.方法.实践[M].北京:电子工业出版社, 2007.7。

[3].新浪科技.2007-11-01.SOA让世界变得更平.[EB/OL].http://tech.sina.com.cn/it/2007-11-01/16331827668.shtmlg

[4].王能斌, 王洌, 王泓.Web数据的管理和交换.北京:科学技术出版社, 2006.5。

[5].Eric Newcomer, Greg Lomow著, 徐涵译.Understanding SOA with WebServices中文版.北京:电子工业出版社, 2006.6。

[6].王瑄, 李燕.应用Web Services存在某些方面构建多层架构的高效.NET应用-XML China论坛开发纪实.北京:科学技术出版社, 2005.6。

[7].王仰富.SOA与企业IT架构[EB/OL].2007-7-21.http://www.cio-times.com/news/2007-7-27/2007727152033.html

面向服务架构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

医疗保险一直是我国社会保险的重要组成部分，医疗保险信息管理系统也是社会保险信息管理系统的重要组成部分。

由于各地的医保待遇政策的差异，各地医保系统的核心算法各不相同，必须通过在各地的服务之间交换数据才能准确地完成异地就医待遇计算。可是各个独立的系统采用的技术不同，采用的接口方式也不相同，所以无法简单地采用网络把这些独立的系统连接起来。为了实现这些独立的系统之间的通信，可以重新制作一个可以适应各地医保待遇算法的统一的程序框架，把各地的医保待遇算法“填充”进去；也可以封装现有的系统，通过统一的接口和互操作协议使原有系统可以互相理解。面对服务的架构才能够适应这种需求。

2 设计

2.1 面向服务架构

总的来说面向服务开发具有以下特点：

（1）重用：创建能够被各种应用重用的服务，提高服务的适应性。

（2）效率：较少改变原有系统，集中精力于数据共享，组合现有服务以达到快速创建新的服务与应用的目的。

（3）低复杂度：较少关心底层实现、执行环境，通过对服务建模和建立接口契约来连接系统。

（4）高操作性：将业务问题和技术问题尽量分离，使业务人员和技术人员通过服务契约进行高效协同。

开发服务与开发对象不同：因为一个服务，是由它与其他服务交换的信息而不是由一个方法的结构来定义的；服务定义所在的抽象层次必须比对象定义所在的抽象层次要高，因为这样可以把一个服务的定义映射到某种面向过程的语言、消息排队系统或面向对象系统上。理解服务定义的粒度也同样重要。一般来说，服务都会定义粗粒度的接口。相对于对象的调用来说，对服务的单次调用会接收更多的数据，消耗更多的计算资源，因为它需要进行执行环境的映射和xml处理等工作，而且对服务的访问通常都是远程的。当然，对象接口也可以是粗粒度的。关键在于，服务是用来解决应用的互操作问题以及用于组合新应用或者应用系统，而不是为应用创建具体业务逻辑。通过进行Web服务的聚合，可以发布封装了多个其他服务的Web服务。这样，可以将一个粗粒度的接口分解为多个细粒度的服务，或者，用多个细粒度的服务组合为一个粗粒度的接口。粗粒度的服务更适合用于发布，而细粒度的服务则更适合作为仅供前者使用的“私有”服务。

结合目前的医保系统，医保中心对医院端提供了许多功能，如门诊和住院登记、交易结算、药品目录下载、对账报表生成等。这些交易中有的在中心端和客户端之间的数据交换量很大，不适合作为实时系统的一部分进行封装。考虑到异地医保业务中，只有属地的医保中心待遇核心算法对异地的医保系统有意义，所以我们只要封装属地的医保中心待遇核心算法部分，作为我们新系统的服务。向异地提供一些如待遇审批、待遇结算等医保待遇核心功能即可，其它不涉及到账户消费的功能就不需要加入实时系统部分。

在努力减小业务中交换的数据量的同时，也要减少每次业务在属地和异地医保系统之间的往来次数。

2.2 结算中心

将各地的系统进行封装之后，还需要建立一个结算中心。其目的有二：

(1)由于医保业务的特殊性，每个业务请求都必须要被处理，所以系统不能采用自动发现服务的方式，需要有一个模块来登记和维护这些已知服务的信息，进行数据的调度。

(2)各地的医保的结算系统是独立结算的，异地之间的业务的结算信息要被记录，然后通过银行系统对这些结算记录进行冲减，这为保证数据一致提供了依据。

为了实现以上这两个目的，结算中心需要至少具备以下几个功能：服务登记、数据转发、保证事务完整性、保存交易记录。通过在已知的服务地址列表中检索某个描述，找到对应的地址作为请求的目的地址。如要进行异地医保垫付给用结算，可根据保存的请求数据记录，通过调用银行提供的接口来完成。

2.3 层次结构

实时系统可以在医院客户端和医保中心端之间加入一个中间层，通过这个中间层来完成对原有医保系统的封装，同时也利用这个中间层来完成对异地医保系统请求的转发。如果发现一个请求的属地信息不是本地，则直接请求转给结算中心。同时还要完成本地医保中心的数据和异地之间传输的xml之间的数据格式转换。

3 实现

3.1 各地医保系统改造

异地就医业务发生时由异地医疗保险系统要多传入一个异地的区域编号，这个编号可以是全国统一编制的，也可以是局部的结算中心可以识别的，然后调用上一级结算中心进行交易。属地医保中心要提供接口给结算中心调用。每一个医保中心都具备异地和属地的双重角色。具体改动如下表：

表1 原系统改动列表

3.2 结算中心功能

结算中心是一个独立的新增模块，要在省级或部级进行开发。结算中心负责连接各地的医保中心，接收并转发各地的异地医保请求，将这些请求保存起来而不保存返回的处理结果。同时还要和银行接口连接，根据保存的请求数据，完成异地医保垫付。

3.3 结算中心接口

结算中心对外接口由Tuxedo编制的服务程序提供。主要完成两个任务：向结算中心数据库内保存请求数据、解析请求串并转发到指定的医保中心服务器。对于数据库操作由Tuxedo自动完成事务控制。使用Tuxedo主要原因是Tuxedo支持C语言编制的服务，执行效率较高；而且Tuxedo的并发性能很好，可以满足大量数据交换的需要。

结算中心提供给各医保系统的是一个jar，无用户界面，要求输入输出必须遵守接口规范。程序文件名：ddb_interface.jar。此接口完成远程服务接口调用，用于医保中心java程序调用jar的相应接口，完成调用Tuxedo服务：将此jar在医保中心WebLogic服务器部署为EJB，完成医保中心处理Tuxedo调用。

在这个jar中一共有5个消息类和2个功能类。5个消息类分别为MessageRequest：与Tuxedo交互过程中使用到的交互消息请求对象；MessageResponse：与Tuxedo交互过程中使用到的交互消息回应对象；MessageBody：交互消息休；MessageRequestHeader：交互消息请求头信息；MessageRequestHeader：交互消息回应头信息。2个功能类为RemoteTusedoServiceClient：远程Tuxedo服务客户端接口，负责调用Tuxedo服务；DDBException：接口异常类。由于目前只是一个原型系统，所以没有异常类的具体实现。

3.4 数据封装

对数据的封装采用xml的格式，在信息头中包括了：数据来源地、数据目的地、请求类型、交易编号、交易响应码、错误措述等几个部分。信息体中又分为参数和数据项，数据项中有多个数据元素。设置数据项是因为WebLogic和Tuxedo进行数据格式转换时，不支持xml的元素属性，所以要把元素属性转化成元素。根据需要，这些xml的内容可以加密后传输，来提高安全性。

针对具体业务，以住院异地结算为例，请求方必须发送包括请求业务类型、住院流水号、个人编号、医疗费总额、符合基本医疗费用总额、自费金额、自付金额、结算日期等项，应答方必须发送包括应答业务类型、执行成功标识、统筹支付金额、个人账户支付、个人现金支付等项。这些数据项都是选取出的待遇计算所必须的重要数据项。

4 测试

4.1 测试环境

测试模拟同一省内两城市医保中心，通过省级办理异地业务，其中属地医保中心为两台Sun V20z，每台机器上安装WebLogic，建立一个Server，2个Server形成Cluster。异地医保中心的系统搭建方式与属地医保中心相同。省级交换中心为两台SumV20z搭建的Tuxedo Cluster。属地医保中心、异地医保中心和省级交换中心分别建立用户，共用一个数据库，数据库服务器机型为Hp4640。

4.2 测试软件

监控工具：

操作系统vmstat /mpstat/iostat/netstat/prstat、中间件WebLogic8.1.4Console、数据库Oracle9.2OEM、statspack。

负载生成工具：

模拟负载场景Loadrunner v8.0。

4.3 测试数据及分析

在测试这个场景时，通过处方数量一定（300条处方），逐步增加并发人数；并发人数达到100个用户时，逐步增加处方量进行分别测试。跟踪后台的出错信息，根据这些错误信息分析、定位原因。通过调整中间件配置、应用等，最终达到并发100个用户、每人处方量达到500条的要求。详细数据见表2。

通过观察表2中列出的数据看到，所有的交易请求都能得到响应，说明系统有效。随着并发用户数的增加，交易请求的最小响应时间变化不明显，最大响应时间逐渐增加，说明这个实验环境中，系统的并发处理能力有限，交易请求要在队列中等待，但最后还是可以成功被处理的。每种业务的最小响应时间和最大响应时间都有一定差距，随着并发用户数的增加这种差距明显增加，这种增加也不是线性的，主要由于测试服务器只有一台，没有进行负载均衡，在后台处理时采用随机抢先机制造成的。

5结语

面向服务的架构概念和J2EE、web service、xml、中间件的结合使其更实用有效，通过面向服务的架构来重组现有的医疗保险系统，对原系统改动小，而且技术复杂度低，可以降低开发和维护成本。利用结算中心进行调度，利用交易中间件来进行消息的转发，保证了系统的可靠和效率。实验证明方案切实可行，但在性能优化方面仍有提升空间。

参考文献

[1]Thomas Erl.. PRENTICE HALL PTR，2006.

面向服务架构SOA 篇4

一、我国电子政务的现状与存在的问题

传统的电子政务系统主要针对各部门自身的业务需求来实现, 造成应用系统独立建设, 缺乏统一的标准, 各个部门自成体系, 信息资源分割严重, 信息孤岛大量存在, 资源获取和可用性差, 信息交换共享十分困难。

政务部门在各自的信息系统建设中, 多从自身业务出发来构建信息系统, 业务数据固化于软件实现中, 且信息资源单独管理, 造成了业务与数据的相对自我封闭。对需要跨部门共享的业务信息, 因其描述格式、描述方式均不统一, 标准化程度低, 导致大量事实性信息孤岛出现, 且不同孤岛间的数据获得与使用较为困难。如何建立起电子政务应用的标准化数据体系, 保证数据表达、处理、展现的规范化已经成为电子政务建设中亟待解决的重要问题。SOA的应用为突破信息孤岛、整合信息资源、协同政务应用、缩短开发周期、降低开发成本提供了很好的解决方案。

二、SOA的基本结构

SOA是软件工程方法的重要发展, 也是软件产业形态由产品转向服务的里程碑性技术基础。SOA是一种新的应用架构模型, 它以服务驱动为核心理念, 按需连接系统资源, 通过将原有应用中的零散功能整理包装为具有互操作性的标准服务, 实现服务的快速组合和重用, 保证应用敏捷性与扩展性, 满足政务业务发展需要。SOA结构中共有3种角色:①服务提供者。发布自己的服务, 并且对使用自身服务的请求进行响应。②服务注册中心。注册已经发布的服务提供者, 对其进行分类并提供搜索服务。③服务请求者。利用服务注册中心查找所需的服务, 然后使用该服务。SOA的基础是服务描述和服务发现。服务描述主要提供服务的接口描述信息和服务部署信息等。服务发现是指服务请求者通过查询服务注册中心去定位符合其需求标准的服务。

三、SOA在电子政务中的5种应用模式

SOA技术架构强调统一规划、统一标准、统一平台、统一管理, 以需求为导向, 以业务服务为焦点。所有服务以松散耦合的状态存在于系统之中, 可以随业务需求的变化, 快速组合成跨单位的具有高协作能力、高应急能力的应用系统。采用SOA的技术架构和技术理念, 一方面深度满足用户的业务需求, 另一方面解决了政务系统项目的重复建设问题。SOA在电子政务中的5种应用模式如图1所示。

1.软基础设施应用模式

从软基础设施的角度, SOA的应用可以分为利用信息资源目录梳理业务活动和业务对象的应用模式, 以及建立业务主题库的应用模式两类。利用信息资源目录梳理业务活动和业务对象的应用模式用于梳理业务以支撑基于SOA的应用;建立业务主题库框架的应用模式则主要是阐述如何建立业务领域的主题库, 基于这种应用模式可以建立多层次、分布式应用系统的基础库。

2.资源共享应用模式

资源可以通过服务的模式对外共享, 任何需要这些资源的机构和个人都能拿到所需要的资源。资源的有效共享依赖于3个方面:一是资源本身的描述, 二是资源本身的实际存储方式, 三是资源的提供方式。资源本身的描述和逻辑集中有赖于基于元数据的资源描述, 逻辑集中就是将资源的描述以目录的形式进行统一存储;资源的物理存储方式依赖于应用构建前期对数据的规划, 此层的变动只会影响资源的物理层面特性, 并不影响其服务的特性, 因此原有的对应用层限制最大的数据层, 通过目录的统一服务变得非常灵活而有弹性;最后, 资源的提供方式则是基于前两个方面的服务方案, 资源共享以服务的形式体现。

3.业务协同应用模式

如何实现这些业务的协同是SOA在这种应用模式下的重点。在这种应用模式下, 完成业务协同包括3个步骤:

(1) 业务处理服务。业务处理服务源于对组织内或组织间业务活动的分析, 组织内的业务处理服务可以直接基于业务活动抽象的用例来构造;组织间的业务活动一部分来自于对业务活动的分析, 另一部分来自于资源共享的需求, 进而依据这部分需求建立起共享的服务。

(2) 业务流程服务。业务流程服务源于对组织内各部门间或组织间的业务关系的分析, 通过建立业务的前置关系、后置关系从而形成业务流程, 依据业务活动间的关系建立起对外提供的业务服务。

(3) 服务查询检索。服务查询检索主要是供外部用户明确了解组织提供了哪些服务、具体的服务内容是什么以及如何获取和使用这些服务。

最后通过服务检索查询的功能开发定义明确的交互界面, 用户可以通过交互界面查询定位所需的服务。

4.不同服务渠道的应用模式

原有的系统建设通常不会建立服务层完成系统间的调用, 而是直接调用下层其他应用或者采用数据共享的方式, SOA在应用与业务之间加入一个服务层, 从而避免直接访问下层其他应用。另外, 在大多数机构中, 存在不同的应用和技术共存, 由于这些应用提供的功能都是特定的, 要在应用间共享信息最好的解决方案是转向一种面向服务的架构和Web服务, 即在业务层之上加入一个服务层。

5.基于虚拟数据中心的应用模式

即忽略数据在不同节点的部署而集中提供服务。如果要在单节点上提供虚拟数据中心, 可以建立非分布式目录中心用于提供虚拟中心服务;如果在多节点上建立虚拟数据中心, 即跨节点的虚拟中心, 需要建立分布式目录中心用于提供虚拟中心服务。

总之, 通过SOA应用模式分类体系的研究, 可以更好地帮助用户理解SOA的应用类型, 并结合SOA架构的优势, 确定业务建设下一步的方向。

四、基于SOA的电子政务系统设计优势

SOA的体系结构可以基于现有的系统投资来发展, 而不需要彻底重新创建新系统。如果将开发力量集中在创建服务, 利用现有的技术结合基于组件的方法来开发软件, 将可获得如下几个方面的好处:

(1) 利用现有资源。通过使用适当的SOA框架, 可以将业务服务构造成现有组件的集合。使用这种新的服务只需要知道它的接口名称, 服务的内部细节以及在组成服务的组件之间传送的数据的复杂性都对外界隐藏了。这种匿名性使组织能够利用现有资源, 通过合并运行在不同的操作系统中, 用不同的编程语言开发的组件来创建服务。原有系统提供的功能, 可以通过服务来封装并提供给新的系统或其他系统进行访问。

(2) 商品化基础架构。利用SOA框架, 可以使不同的政务网站应用程序之间, 基础架构的开发和部署变得更加一致。现有的组件、新开发的组件和从厂商购买的组件可以合并在一个定义良好的SOA框架内。这样的组件集合将被作为服务部署在现有的电子政务平台上。

(3) 减少成本。随着业务需求的发展和新的需求的引入, 通过采用SOA框架和服务库, 为现有的和新的应用程序增强和创建新的服务的成本大大减少。

(4) 持续改进业务过程。SOA允许清晰地表示流程流, 这些流程流通过在特定业务服务中使用的组件顺序标志, 这给商业用户提供了监视业务操作的理想环境。业务建模反映在业务服务中, 流程操纵是以一定的模式重组部件 (构成业务服务的组件) 来实现的, 这将进一步允许更改流程流, 而同时监视产生的结果, 促进了业务过程的持续改进。

(5) 以流程为中心的体系结构。现在的体系结构模型和实践往往是以程序为中心。通常, 流程信息在组件之间传播, 应用程序很像一个黑匣子, 没有粒度可用于外部, 重用需要复制代码、合并共享库或继承对象。在以流程为中心的体系结构中, 应用程序是为过程开发的, 流程可以分解成一系列步骤, 每一个步骤表示一个业务服务。实际上, 每个过程服务或组件功能都相当于一个子应用程序, 将这些子应用程序连接在一起可以创建能够满足业务需求的流程流。这种粒度允许利用和重用整个组织中的子应用程序。

五、结 语

综上所述, SOA的技术属性和电子政务的宗旨十分吻合, 使用SOA架构实现电子政务将达到事半功倍的效果。当然这并不等于采用了SOA架构, 就可以解决在电子政务中存在的所有问题。SOA和电子政务都在飞速地发展, 处于不断完善的阶段, 一些理论和实践的问题还处在探索阶段, 但是无论如何改变, SOA可以完善和解决传统电子政务中存在的诸多弊端, SOA可以在电子政务建设中发挥出巨大的优势。

摘要：针对我国电子政务系统存在的可扩展性差、容易形成信息孤岛等问题, 本文提出SOA能较好地实现电子政务系统中的业务协同与信息共享。在介绍SOA的基本结构, 分析我国电子政务的现状与问题的基础上, 探讨SOA在电子政务中的5种应用模式及基于SOA的电子政务系统设计的优势。

关键词：面向服务架构,电子政务,应用模式

参考文献

[1]赵育梅.中国电子政务发展中出现的问题及对策研究[J].北京邮电大学学报:社会科学版, 2004 (2) :68-72.

[2]Eric Newcomer, Greg Lomow.Understanding SOA with Web Services[M].中文版.徐涵, 译.北京:电于工业出版社, 2006:162-177.

[3]Andy Lin, Som Sengupta.使用应用程序平台跨越SOA障碍[J].bea dev 2 dev专刊, 2004, 4 (8) :26-30.

[4]姜国华, 李晓林, 等.基于SOA的框架模型研究[J].电脑与信息技术, 2007, 15 (6) :37-39.

[5]Olaf Zimmermann, Pal Krogdahl, Clive Gee.面向服务的分析与设计原理[EB/OL].http://www.ibm.com/developer works/cn/webser-vices/ws-soad1/, 2004-06-01.

面向服务架构SOA 篇5

1.1 模型驱动体系结构(Agent)与面向服务体系结构(SOA)

模型驱动体系结构是软件开发方法上的革新,它源于解决重用和需求变化的问题。比较成熟的重用有二进制代码级(这里将Java字节码及.NET的中间代码都认为是二进制代码一级),源代码级两种层次,其中二进制代码级含主要是系统函数库和应用函数库[1]。随着应用的发展,又出现了粒度较大的类库以及粒度更大的组件库。二进制代码的重用粒度不断变大的趋势实际上反映了IT技术不断向应用需求靠拢的趋势。从源代码级来说,开源软件的发展使其有了更强的生命力。但是,从实践中看来,开源软件的源代码级重用比二进制级的重用需要耗费更大的工作量。此时,重用并没有摆脱物理形式的束缚,从逻辑上将更有价值的设计面重用起来,而设计往往才是高层次软件重用的关键。

设计层的重用一直以来受到限制的原因之一是没有通用的设计表达方式,各种软件设计采用不同的表达符号体系是导致重用困难的原因之一。正是因为没有统一的符号体系,所以也很难发展出通用的辅助设计工具。自从UML出现以后,这个问题在很大程度上得到了缓解。模型的表达有了广为接受的方式,大部分的常用设计元素都可以用UML的元素来表达,这是UML最为成功之处。随着UML推广,各种自动化工具也相应产生,其中最为著名的是IBM的RationalRose,它实现了UML图形表示到多种语言的自动映射功能。

但是UML也面临特定领域的优化和扩展问题,比如用于嵌入式实时领域的实时U侧比,就需要扩展更多的关键元素。为了解决设计重用的问题,也为了解决中间件之间的互联互通问题,OMG提出了一个元层解决方案,即模型驱动体系结构。MDA的核心在于其“元”层的思想,有了元层,整个体系就具有了无限可扩展性,这是MDA不同于其它技术的地方。基于MDA的软件开发生命周期如图1所示,其中把平台独立模型PIM转换成一个或多个平台相关模型PSM是MDA开发过程中最复杂的一步。

MDA是模型驱动体系结构,而SOA是面向服务体系结构,那么,两者之间的联系究竟是什么,为了解决这个问题,SLN.公司从企业计算的角度作了一个从应用出发的专题研究[2]。而从开放系统中间件的角度来看,SOA是为了解决更大粒度的重用所提出的概念,只不过,所采用的技术变为服务,而结构采用了三方模型而已。

传统的组件和对象级重用较为强调重用粒度和互通互操作性,而作为企业计算来说,更加强调敏捷性和跨企业互通性。这就需要更大粒度的重用。此时,组件己经不能满足需要,服务作为更大粒度的组件被提了出来,而且其使用方式上十分强调三方模型。

所以,MDA和SOA都是为了解决重用问题而出现的,而MDA强调模型重用和自动开发过程,SOA强调大粒度重用和跨域协作。它们都反映了敏捷性,敏捷性实际上与IBM按需计算是一个思想。即软件可以按照需求的不同而快速变化重组[3]。从而避免需求的变化导致软件的大规模重写。总结一句,可以将重用、动态、敏捷、模型的关系概括如下:动态必须有重用的支持,而敏捷则必须以动态为基础,模型则是设计层的重用。

1.2 服务组合中的模型方法

服务组合作为服务计算中的重要元素,其有效运行是服务计算动态性和敏捷性得以实现的保证。对服务组合建立模型是学术界和工业界一直共同努力的方向。其中有借鉴原有成果如UML为组件建模的,或者新辟描述语言如WSBPEL和WSCDL的,还有结合UML与WSBpEUWseDL的,都取得了一定的成果。

但是,服务组合必须用严格的形式化方法加以验证,才能保证服务组合的正确性和可验证性。

模型有形式化模型和非形式化模型以及半形式化模型的区别,如:U L就是一种半形式化模型,它定义了符号系统,但是没有定义推理规则;而诸如进程代数和Petri网等就是典型的形式化系统。

2 基于Pi演算的驱动服务组合设计框架

2.1 UESTC-PLATFORM:一个服务计算可视化平台

UESTC-PLATFORM是一个可视化的服务计算平台,它支持服务设计、服务组合、服务仿真、服务部署等功能。其系统体系结构如图2所示。

平台提供了一套良好的访问和管理系统的组件,以便用户程序可以采用B/S方式和C/S两种方式调用系统平台。系统平台采用了SOA架构进行设计,支持BPEL4WS1.1规范,从而保证系统能够向企业级应用提供良好的松散藕合性,满足企业业务的决速变化,并且支持在应用平台中居于主流地位的国际规范。

UESTC-PLATFORM系统将服务划分为两大类:内部服务和外部服务。内部服务指的是与应用程序运行在同一个虚拟机下并被WSDL包装成服务的JAVA组件;而外部服务即Web services,它和应用程序运行在不同的虚拟机,不同的进程、甚至是不同的网络环境下。内部服务适用于企业内同构环境下的组件调用,外部服务适用于企业间异构环境下的组件调用。为了提高服务的调用效率,对内部服务的调用方式是直接解析服务并调用相应组件。

图2中虚线框部分是属于UESTC-PLATFORM的部分。其中具有可移植性、高效率、高性能的内核管理组件是系统的核心部分(点划线虚框所示),它对外提供了监视系统资源和运行状态的接口,对内管理系统的各个组件和服务。此外,内核组件还具有一定的灵活性,可插拔、替换(采用foci技术)其他的实现技术。在本系统平台中,采用基于IOC的技术来实现具体组件,并用Megaserver管理系统内的组件模块,其下挂接了5个系统组成模块:

BPEL工作流引擎:它是平台的重要组成部分,符合业界BPEL4WSvl.1标准。使得基于本平台的企业级应用能够全面实现SOA架构和企业商业、办公过程自动化。

内部服务:实现企业内部业务组件服务化。

规则引擎:按照业界标准实现业务规则的随需应变。

相关资源:包括了排队队列、流程连接池、工作队列、系统平台参量、服务参数等。各种组件:指构成本系统的组件,包括服务管(Serviceman age)、日志、事务、持久化等。

2.2 基于Pi演算的形式化框架PIFF

1)PIFF:一个基于Pi演算的形式化框架

PIFF是一个基于Pi演算的形式化框架。它包括三个部分:第一个部分表明了WSCDL-WSBPEL的关键元素和Pi演算之间的关系;第二部分表示了如何将高级结构——进程模式——建模为Pi演算的agent表达式;第三部分是一些指导和辅助验证的工具。PIFF的结构如图3所示。

2)WSCDL,WSBPEL和Pi演算元素的对应关系

Pi演算可以描述各种数据结构和控制结构。无论WSCDL还是WSBPEL,其组合描述都可以分为两个逻辑部分,一是静态信息描述;二是流控描述。映射关系描述在表1中。

3)将高级结构映射到Pi演算

WS将高级结构映射到pi演算

CDL的核心信息交换部分包括在"Interaction"、"exchange"子元素,"exchange"有"send"和"receive"元素中。子元素。iteration有因为WSCDL描述服务之间的交互规则,交互模式可以总结为三种模式之一:单向(one-way),同步发送/接收和异步发送/接收。这些模式可以映射为相应的Pi演算,如表2所示。

WSBPEL交互模式比起WSCDL来说更加复杂一些,因为它可以用来描述组织内的业务流程。根据Alisati:Barros和Frar Puhimann的研究工作,Pi演算可以表达任何的工作流模式。通过分析和比较,该文选择出一些核心模式,作为PIFF支持的内容。表3展示了这些模式。

4)PIFF框架的验证方法

如前所述,PIFF不仅提供了用Pi演算表示WSCDL和WSBPEL的方法,也涉及如何验证关键属性的方法。在服务组合的过程中开发者必须保证服务组合的结果能满足系统用户的需求。系统设计者从全局观点设计系统,但是开发者从本地的内部流程视角来看待服务组合[4]。因此,必须保证每个参与者产生与全局协议一致的交互方式。作为一种编排语言,WSCDL指定了交互行为的全局特征,也表示了全部参与者必须满足的交互规则。怎样形式化地验证wscDL与WSBPEL的一致性是一个重要的问题。在PIFF的辅助下,可以保证这种一致性[5]。

当系统设计者提出一个WSCDL的服务组合描述时,全局设计可以映射为Pi演算表达式,此时,表达式就描述了系统需求,该表达式被称为服务组合需求模型serum(service。composition irementmodel)。为了达到Serum的目标,一些本地流程必须创建出来,本地流程可表达为WSBPEL,设有N个本地服务被创建出来完成组合。

3 使用PIFF框架的实例

在此组合中,有五个参与者。Client Proxy是客户代理。TravelAgentis负责联系宾馆、接受客户请求。Balk负责支付服务。Elmer是Hotel的内部通道,检查是否有空余房间。

1)根据PIFF,一个SCRM可以构建如下:

(缩写:CP-Client Proxy,TA-Travel Agent,BK-Bank,HT-Hotel,CK-HT内对外不可见的内部动作)

SCRM=CPTA.TAHT.(HTTA.TACP+HTBK).BKCP.CPBK.BKHT.HTTA.TACP).SCRM

每个发送操作都有相应的接收动作。SCRM可以解释为:

CP发送请求(req)到TA;

TA接收到req,并且发送预定请求到HT;

HT检查空余房间(通过发送que到CK,通过内部通道Inner进行)。如果CK的回答是有(ok),HT发送支付请求(Pay)给BK,否则(nok)HT发送拒绝信息(rer)给TA,然后TA发送拒绝信息(dec)给CP;如果HT发送pay,BK发送请求给要求cP支付,CP支付(fee);BK发送已支付信息(pok)给HT,HT再发送预定成功信息(suc给TA,TA则发送确认信息(efhi)给CP。

2)根据PIFF,一个essC RM模型可以创建如下:

3)根据PIFF,为了检查是否escort与scrim一致,每个cascara中的服务都必须验证其一致性。在该例中,把Travel Agent作为样例来说明如何验证单个服务一致性。

4 结论

该文的研究工作实现了初步的融合,即可以通过UESTC PLATFORM调用MWP平台工具。这里实现了两个工作,一是将Pi演算描述的流程映射为WS-BPEL的框架;二是将WSBPEL的流程描述逆向转出(建模)为Pi演算的流程描述。这个研究工作仍在进行中,现在所定义的两个映射器(正向映射和逆向映射)是进一步改进的重要基础,也是以后实现对WSCDL支持的重要参考。

摘要：论文从服务计算试图用自动分解需求,全网搜索小粒度服务,组装出符合需求的应用逻辑的方式来完成以前的软件开发任务。在这个框架中,研究的基本点是如何描述服务、如何发现服务、如何组装服务、如何测试和验证服务。具有形式化模型的服务组合能够更好地保证组合正确性以及其它的相关特性。

关键词：Agent,SOA,引擎设计方法,PI-演算,Web服务

参考文献

[1]徐伟,金蓓弘,李京,等.一种基于移动Agent的复合认服务容错模型[J].计算机学报,2005,28(4):558-567.

[2]吴建,吴朝晖,李莹,等.基于本体论和词汇语义相似度的Web服务发现[J].计算机学报,2005,28(4):595-602.

[3]李曼,王珊.基于领域本体的Web服务动态组合[J].计算机学报,2005,28(4):644-650.

[4]刘必欣,王玉峰,贾焰,吴泉源.一种基于角色的分布式动态服务组合方法[J].软件学报,2005,16(11):1859-1867.

面向服务架构SOA 篇6

关键词：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 篇7

关键词：SOA架构,图书馆,数据集成,资源整合

近年来, 随着图书馆中数字资源的不断增加, 读者的信息需求在一定程度上能够满足, 但面临着这样一种困境:这些资源分别有自己的检索系统, 具有各自的信息组织、处理方式, 为用户提供不同的查询方式和服务种类, 不同的权限保护和收费策略, 这样众多的数字化资源之间缺乏必要的联系, 形成了信息孤岛。此外, 高校学科建设的快速发展, 教学和科研对信息的获取提出了更高的要求。图书馆作为信息资源的源泉宝库, 如何将馆藏资源更方便、高效的提供给全校师生获取。从而促进与配合学科建设, 更好的为读者服务。图书馆界不断探索, 利用计算机技术结合读者使用图书馆数据资源存在的问题, 提出了数据资源整合、参考咨询、文献传递等方便读者资料获取的先进理念。

1 SOA技术介绍

1.1 SOA技术

SOA (Service Oriented Architecture, 面向服务的体系结构) 是一种通过封装能够完成特定任务的程序单元来实现系统间相互操作的一种软件体系结构[1]。SOA是一种构件模型, 它对不同级别的程序功能单元 (即服务) 进行封装, 并为这些功能单元提供外部接口, 以利于不同系统间的相互调用。

服务并非仅指Web服务, 比如:EJB、JMS、JavaBean、CORBA等很多种类构件的封装都可以称为服务, 而Web服务确是服务中最典型、最常用的一种, 图书馆绝大多数据库资源是以B/S的架构的web服务提供给用户使用的。如何将这些应用服务整合起来提供给按照学科资源划分提供给用户使用, 我们引入重要的Web Service模型、角色与操作等基本概念。

Web Service是解决应用程序之间相互通信的一项技术。Web Service是描述一系列操作的接口, 它使用标准的、规范的XML描述接口。包括与服务进行交互所需要的全部细节, 消息格式、传输协议和服务位置。而在对外的接口中隐藏了服务实现的细节, 仅提供一系列可执行的操作, 这些操作独立于软、硬件平台和编写服务所用的编程语言。Web Service模型解决方案中共有3个工作角色, 其中服务提供者 (数字图书馆) 和服务请求者 (读者) 是必须的, 服务代理中心是一个可选的角色。它们之间的交互和操作构成了Web Service的体系结构。服务提供者定义并实现Web Service, 然后将服务描述发布到服务请求者或服务代理中心, 服务请求者使用查找操作从本地或服务代理中心检索服务描述, 然后使用服务描述与服务提供者进行绑定并调用Web Service, 如图1所示。

以服务为核心, SOA可看成是形成与组织服务的一组策略、框架和实现。通过SOA的设施, 各种服务可以被远程的动态注册、发现与调用;还可被动态地组装与编配在一起, 实现相对较为复杂的功能。同时SOA设计还要能确保服务合约中规定的服务质量。

1.2 SOA技术的优点

SOA不需要关心低水平的集成问题, 能够让人们专注于业务流程和应用的开发。SOA通过良好定义的接口平台支持相互通信且收集可用的网络服务, 采用分布式应用程序将功能作为服务交付给终端用户, 也可以用来构建其他的服务。面向服务架构具有很多优点[3]。

(1) 松散耦合消除了对系统两端进行紧密控制的需要。就系统的性能、可伸缩性以及高可用性而言, 每个系统都可以实现独立管理, 实现的改变被隐藏了起来。松散耦合给服务提供者和服务请求者提供了独立性, 但要求基于标准的接口和中间件来积极地管理和代理终端系统之间的请求。

(2) 服务重用避免了重复开发的弊端, 同时提高了实现中的一致性。服务的重用比起组件或者类的重用更容易实现。

(3) 由于粗粒度消息和消息收发服务的使用, 可以对服务请求进行排队并以最合适的系统速度处理它们, 具有高度可伸缩性。

(4) 使用共享的基础架构服务可提供一致性, 并允许单点管理。 其他的共享服务 (例如与安全相关的服务) 可以通过直接提供现有产品的服务创建。

(5) 隐藏数据源的复杂性, 同时加强跨数据源的一致性、完整性以及安全性。

2 系统总体方案设计

为了满足数字资源整合服务和学科资源推送、参考咨询等服务等主要功能, 采取的主要技术路线是面向服务 (SOA) 的portal门户技术与Web Service技术。以“构建学科资源整合信息服务推送”的理念, 致力于解决在信息化数字图书馆建设过程中面临的数字资源利用率低、信息孤岛等问题。它可以整合分散的资源, 构建个性化的用户站点, 使用户能够快速的获取与接收其所关注的信息。

2.1 设计理念

构建学科资源服务门户站点, 实现对分散资源的整合, 向读者提供专业性的学科资源推送, 快捷方便的参考咨询服务, 主要完成以下三个关键点。

(1) 整合图书馆电子资源:

实现统一的检索、下载、阅读门户站点, 呈现读者所关注的信息、整合利用各种类型的图书馆电子资源数据库。读者在门户站点中能够在快速的获取有价值的信息。

(2) 整合多种学科服务、实现学科资源推送:

学科馆员能够利用平台来进行异构资源库的检索、收割, 并将收割的资源筛选后向读者自动或者手动信息推送服务, 建立灵活的学科服务体系。

(3) 方便快捷的在线参考咨询服务:

解决读者在门户站点无法获取到所需的资源信息, 实现专业学科参考咨询。学科馆员与读者一对一在线服务, 实现文献传递、分散资源采集等功能。

2.2 总体架构设计

根据上述设计理念, 结合图书馆与用户的需求, 参考国内外先进经验提出如图2的总体服务架构。

从图2中可见, 我们整个系统打的层次划分为四层门户系统、服务管理子系统、运行支持子系统和资源池四个部分。

(1) 资源池:

现有数据库资源, 如, CNKI期刊书库、超星电子图书等不同的异构数据库资源平台。通过对比数据库字段, 对检索字段进行一一对应, 将资源有机整合在一起。

(2) 运行支持管理系统:

IaaS资源的管理平台, 以及运行维护人员使用的技术运维系统。监控学科服务平台的后台资源情况。调配管理IaaS资源, 对用户的特殊Iaas服务需求提供定制化服务。

(3) 服务管理子系统:

进行资源配置, 发布至门户网站, 对已发布的数据资源进行管理等。

(4) 门户子系统:

读者访问及使用学科服务平台的门户网站。也是对管理员、学科馆员、读者等不同类型用户提供的统一登录与使用门户。各级用户可在平台上进行相关的业务操作。

3 系统建设主要技术路线

3.1 IaaS资源整合

资源整合模块将分布式和异构数据库资源整合, 形成一个共享系统。一旦形成了一个共享资源池, 便在调度引擎层中配置一套特定场所的共享策略, 确保应用程序接收到所要求的资源。IaaS的顶层提供用户和应用程序的接口并支持资源统一检索服务的生命周期。同时IaaS拥有一套应用程序编程接口 (API) , 可以根据应用程序、中间件和负载管理器的要求请求和返回用户检索资源。可以为简单和复杂的数据库资源平台或应用程序配置模版, 实现资源配置自动化。IaaS允许启动多级应用程序的各个部分, 添加、删除资源、监控、系统故障恢复等。

3.2 SaaS服务实现学科资源传递与参考咨询

SaaS服务包含各级用户权限管理、文献传递、学科资源仓储、参考咨询等功能的实现, SaaS服务的接入与运营需要给予平台的统一接口, 服务支撑层面向应用程序提供了基于Web service的统一认证接口。

3.3 Portal控制用户权限与访问机制

portal用来提供管理员、学科馆员、读者不同级别用户个性化权限管理, 实现单点登录。定制不同用户的使用权限与呈现给用户各个信息源的内容。

4 结束语

目前关于SOA的思想理论和方法研究受到广泛关注, 正在迅速应用到各种信息系统中。本论述提出了基于SOA架构的图书馆学科服务体系架构, 可以满足高校数字图书馆相关管理信息系统中的数据集成要求, 能够较好地解决信息系统中异构应用之间、松散耦合环境下的数据互操作、集成和协作问题。

参考文献

[1]郑伟, 徐宝祥, 徐波.面向服务架构研究综述[J].情报科学, 2009, 27 (8) :1269-1274.

[2]王卫星, 王晨光.基于SOA的企业信息系统集成框架[J].计算机工程, 2010 (9) :9-31.

面向服务架构SOA 篇8

SOA提出的是一种软件架构概念,通过提高服务处理的性能,满足软件用户的需求[1]。在SOA环境中,服务网络的终端,将自己可提供的服务,以“独立服务的形式”开放给网络的其他终端,其他终端按一定的协议或是统一的接口,调用服务或资源。这种服务处理过程,为架构平台的过程中,实现资源整合与共享提供了技术支撑。相比于传统的点对点方式架构,SOA是由松耦合、服务之间可相互协作的应用服务构成[2]。在设计家电产业设计服务平台的模型中,任何业务处理功能模块被可以作为一个可提供的服务单元,这样产品的设计研发过程,就可以当作服务处理的过程。

提出的基于SOA数字家电设计服务平台,从全产业链的研发设计服务模块角度切入,规划了从用户和市场需求研究开始到产品营销的各个支持模块:用户研究、产品企划、外观设计、高精模型、新工艺开发、色彩与新材料开发、产品界面交互设计、品牌开发等主要的技术集成模块。平台的搭建将会提高研究设计的流程、关键技术的提高以及增强现有设备的可重用性,形成一个对内可以处理各种服务请求,对外可以提供信息展示窗口的综合应用平台。

1 SOA架构-概要

面向服务的架构模型,包含3大核心部件:ESB(Enterprise Service Bus)企业服务总线、BPM(Business Process Management)业务流程管理以及Portal门户。

ESB是传统中间件技术与XML、Web服务等技术结合的产物[3]。ESB的主要功能是提供事件驱动和文档导向的处理模式,此外ESB还支持基于内容的路由和过滤,具备了复杂数据的传输能力,并可以为其他服务提供一系列的标准接口[4]。

BPM的存在可以使系统更具有稳健性,通过BPM组件,基于SOA架构的平台可以更好地监控其他连接的系统或终端。Portal是一个基于Web的应用程序,是一种低成本的集成技术。随着科技发展,现在企业都有很多信息系统,而Portal就是将这些系统集成到一起,封装成统一界面并提供给用户。

2 SOA架构-服务

数字家电产业设计服务平台是三层体系结构的应用模型,其核心模块:服务层中的服务(Service)管理器。关于平台的服务模块,具体又分为:应用服务(原子服务)、组合服务、业务服务(编排服务)等[6]。家电产业设计服务平台应用基于SOA的架构,实现了企业应用的逐步集成,以及业务的快速迭代。家电设计开发人员需求某些功能时,只要调用具体的业务服务逻辑服务模块即可,比如高精模型的开发,色彩与新材料的开发等模块[4]。服务的管理调度则交给服务平台去处理。在设计服务平台的体系结构中,业务服务逻辑包括两大核心模块(它们之间是相互独立的):业务逻辑模块和表示逻辑模块。表示逻辑模块采用Web页面来实现,由页面流(Page Flow)进行统一管理;业务逻辑采用服务来实现(Java),由服务管理器进行管理。

SOA架构的推出与应用,改变了家电产业信息化平台以及其他企业领域搭建信息化统一管理平台的方式,为企业的众多服务和资源的有效集成提供了架构基础:有效地将用户研究、产品企划、外观设计、高精模型、新工艺开发、色彩与新材料开发、产品界面交互设计、品牌开发等服务打包成一个更粗粒度的服务。SOA架构关于服务的组件模型如图1所示。

3 数字家电设计服务平台

3.1 服务请求过程

对于一个相关设计人员的页面请求来说,其请求操作流转实现比其传统的JSP/Servlet/EJB方法更为简单,流转过程如下:

(1)设计人员在相应的客户终端提交服务请求数据。

(2)平台服务器收到提交的服务请求后,将服务请求事件分发给相应的处理终端与处理单元模块,如:用户研究处理模块、企业策划模块、外观设计和高精模型模块等新。

(3)服务处理终端将平台分发的服务请求,按照请求数据封装的处理标准进行处理,并返回平台的相应的处理结果,随后平台将结果返回给服务请求终端。

3.2 页面流

数字家电设计服务平台Web层分3个组成部分:Service Access Agent层、Web Front Controller层以及Page Flow Engine层。

(1)Web Front Controller:对HTTP发出的请求进行处理,根据Page Flow Engine返回的URL传输到最终页面导航

(2)Page Flow Engine:处理Web层的绝大多数业务,如:数据格式转换处理,消息包的封装以及对服务请求事件进行分发等业务。

(3)Service Access Agent:主要负责对服务层访问的通用接口和消息的响应机制。

3.3 服务管理器

服务管理器是数字家电设计服务平台服务层的核心。平台的搭建可以为设计机构、研究院所和设计院校提供开放性的交流协作服务,此外通过平台可以促进各单位之间的沟通与协作,共享设计资源,共同推动数字家电产业的发展。服务的管理和服务的运行是服务管理器提供的两大核心功能。其中,服务的管理指的是服务实现的加载、初始化以及摧毁以及服务配置描述符的管理等。服务的运行是指服务同步/异步调度、服务请求拦截、服务并发控制、服务访问安全控制、服务实现的动态选择、服务负载均衡等功能。

服务管理器总体设计结构如图2所示,服务管理器中的模块相互依赖。下层的模块独立于上层的模块,上层的模块依赖下层模块,相同层次之间的模块相互独立[6]。其中,服务管理器核心模块是Container,负责实现服务的消息处理;Status负责管理服务的运行状态。Log一方面提供服务,并实现记录应用的日志,另一方面记录服务执行的日志。Proxy为服务的代理模块。

4 结语

SOA架构,一种面向服务的架构,被普遍认为是下一代Web服务常用的架构技术,正逐渐地成为企业信息化整合战略和公共服务处理的重要技术基础[5]。基于SOA架构的数字家电设计服务平台,为家电设计行业提供了统一处理各种服务管理平台,设计人员通过客户端就可以处理如用户研究、产品企划、外观设计、品牌开发等服务请求。平台的建设极大地促进了数字家电产业自主创新和自身产业结构的升级,提高了数字家电产业设计、生产以及创新能力,也是实现传统家电产业创新型产业转变的重要举措。基于SOA架构的数字家电设计服务平台,在家电产业如何自主提高创新能力方面,做了有力的探索。

参考文献

[1]林祝发.基于SOA的邮政电子商务信息平台的分析与设计[D].北京邮电大学,2010.

[2]徐振伟.基于SOA的烟草物流调度与服务平台的研究[D].浙江理工大学,2012.

[3]田昌鹏,张升平.基于SOA架构的高校数字校园建设模式探讨[J].通信技术.2008(4).

[4]王益祥,薛霄,朱红磊,刘艳慧.基于SOA架构的企业应用集成技术研究[J].微计算机信息,2010,15:64-65+71.

[5]潘运红,张钢,王春茹,何小敏.基于Portal技术的教学资源集成化平台的研究[J].广东工业大学学报(社会科学版),2008,S1:51-52.

面向服务架构SOA 篇9

近年来, 民航局提出全面推进建设民航强国的战略构想, 航空运输业发展十分迅速, 航空气象服务作为民航业中的一个组成部分, 在终端服务平台方面还相对落后:一是, 全国民航气象服务缺乏一套界面友好的、功能齐全的、可扩展的终端用户服务系统。二是, 民航气象的用户终端服务平台大多数依赖于各套系统提供的单一终端, 没有很好的进行系统集成, 在平台选择也通常局限于Windows桌面应用程序。

随着IT业计算机、互联网和移动设备的高速发展, 3G、Wifi等无线网络技术以及平板电脑、智能手机等新设备已经逐渐融入人们的工作和生活中。因此, 为跟上时代和航空运输业高速发展的步伐, 适应航空用户在不同环境下的多元化需求, 建立一个能够跨多个平台的民航气象终端用户服务系统是非常必要的。

1 SOA面向服务分布式系统架构介绍

1.1 SOA面向服务架构

SOA (Service-Oriented Architecture, 面向服务架构) 架构的基本思想是构建一个松耦合的系统[1], SOA允许用户以一定的方式组织分布式应用程序, 使业务逻辑与用户界面可以分别集中处理。在SOA系统中, 服务的具体操作对客户端来说是不可见的, 服务与客户端之间唯一共同拥有的东西, 就是公开的服务操作列表和参数结构定义。客户端只知道用来描述服务函数的名称、输入参数名称和类型, 以及函数返回类型, 除此之外, 与服务端不存在其他依赖性, 不管是客户端还是服务端, 都可以采用不同的开发平台来实现。

1.2 WCF开发技术

WCF是微软公司为实现SOA架构提供的开发平台, 该平台从NET Framework 3.0开始发布, 整合了.NET Framework 3.0之前的ASMX、.Net Remoting、Enterprise Service、WSE等技术, 并使用WSDL标准文档格式来向用户公开服务合约, 因此利用WCF可以满足包括安全、可信赖、互操作、跨平台通信等需求。

合约 (Contract) 是WCF的基本概念, 它是定义服务端和客户端双方沟通的协议, 合约以接口的方式来体现, 包括数据合约、服务合约、操作合约和消息合约。

2 民航气象服务SOA架构设计

在基于SOA架构的多平台民航气象终端服务系统中, 服务层需要包括:民航气象报文服务、飞行气象文件提取服务、机场天气警报服务、天气雷达产品服务、气象卫星云图产品服务、自动观测系统数据服务等五个基本服务。

2.1 民航气象报文服务

服务合约接口名:IReport, 其中包括:

操作合约:List<string>Get Reports (string OBCC, string TT, string ODate, string OTime) ;根据四字代码、报文类型、时间等返回多个报文。

2.2 自动观测系统数据服务

服务合约接口名:IAWOS, 其中包括1个操作合约函数和1个数据合约:

2.2.1 操作合约:

AWOSData Get Newest AWOSData (string CCCC, string RNO) ;根据四字代码和跑道号, 返回一个AWOSData类型的自观数据。

2.2.2 数据合约:

AWOSData, AWOSData数据对象由自动观测系统各气象要素字段组成。

2.3 天气雷达产品服务

服务合约接口名:IRadar Image。其中包括:

2.3.1 操作合约:

Radar Data Get Newest Image (string Sao Miao Lei Xing, string Hui Bo Lei Xing, string Jiao Du, string Fan Wei) ;根据扫描类型、回波类型、仰角、范围返回最新的Radar Data类型的雷达图像产品。

2.3.2数据合约:

Radar Data, Radar Data数据对象中包括了雷达图文件名、扫描类型、范围、仰角以及雷达图产品等字段。

2.4 机场天气警报服务 (天气通报、报警、反馈)

服务合约接口名:IWeather Alert, 其中包括:

2.4.1 操作合约:

List<Weather Alert Data>Get New Weather Alert () ;返回新的天气警报。

2.4.2 数据合约:

Weather Alert Data, Weather Alert Data数据对象中包括发布时间、发布人、有效时间、警报内容等字段。

2.5 飞行气象文件提取服务

服务合约接口:IFlight File, 其中包括:

操作合约:byte[]Get Flight File (Date Time a Time, Date Time d Time, int high) ;根据航班计划起飞时间、降落时间和飞行高度, 用二进制返回pdf格式的飞行气象文件。

3 多平台客户端开发中的服务引用方法

3.1. NET平台客户端软件服务引用方法

由于WCF本身就是.NET开发平台的一部分, 因此在.NET中引用WCF服务十分方便。在Visual Studio中通过“添加服务引用”来自动生成一个服用引用代理对象, 然后在程序中通过该代理对象即可直接调用服务提供的操作合约函数。

在工程中添加了自动观测系统服务 (IAWOS) 的引用, 自动生成了AWOSService Refernce的一个引用代理对象, 在程序中可以很方便的使用服务接口:

AWOSService Reference.AWOSClient rc=new AWOSService Reference.AWOSClient () ;//实例化一个代理对象。

rc.Get Newest AWOSData ("ZPPP", "01") ;//调用服务函数, 获取“ZPPP”的1号跑道的自观数据。

3.2 Andriod和ISO平台客户端软件服务引用方法

3.2.1在Android系统中通过KSOP2开发包访问wsdl, 在工程中加载ksoap2.jar开发包后, 就可以直接通过KSOP2开发包中的Soap Object对象访问wsdl。在开发时需要注意, 由于Android系统默认禁用了Soket, 所以在开始之前需要在Android Manifest.xml文件中添加:<uses-permission android:name="android.permission.INTERNET"/>。

3.2.2在IOS系统中通过第三方提供的工具自动生成SOAP本地代理类, 直接引用到工程中。也可以自己封装WSDL操作实现SOAP服务的引用。常用的服务引用代理类生成工具主要有:WSDL2OBJC和Sudz C。WSDL2OBJC和Sudz C能够根据WSDL将SOAP服务转化成Object接口和数据结构。

4 结束语

通过WCF技术实现的SOA架构民航气象终端服务系统, 使各服务接口之间、服务接口与用户终端程序实现松耦合连接, 系统功能扩展容易。由于服务接口使用了WSDL标准文档格式, 因此可以实现Windows、Andriod、IOS等主流平台与服务接口的通信, 能够满足多元化的航空气象终端用户需求。

摘要：本文使用基于SOA面向服务架构的松耦合应用系统来为用户提供服务, 可满足不同航空用户多样化需求和航空气象信息服务的飞速增长。该文详细介绍了一种基于SOA架构的松耦合、分布式、多平台气象终端用户服务系统的设计与实现方法, 该系统服务层使用WCF技术, 实现将各类航空气象服务产品集成到一个统一管理的服务层中, 并通过使用WSDL标准文档格式来向用户公开服务合约, 使客服端可以利用Windows、Andriod、IOS、Web等多种平台实现跨平台和功能各异的用户界面层。

关键词：面向服务,分布式,松耦合,WPF,WCF

参考文献