soap协议精选(九篇)
前言：一篇好文章的诞生，需要你不断地搜集资料、整理思路，本站小编为你收集了丰富的soap协议主题范文，仅供参考，欢迎阅读并收藏。
第1篇：soap协议范文
AMBA 3 高级扩展界面(AXI)协议由于大幅度扩展了AMBA 2.0片上总线的性能和灵活性,因而具备了更多的优势,同时也增加了设计的复杂度。DesignWare IP为AMBA 3 AXI协议的解决方案让设计者能快速、简便地集成此高速协议,同时降低了风险,加快了设计周期。为AMBA 3 AXI协议的DesignWare IP解决方案提供了存取三种主要需求元件的权限,包括综合实现IP、验证IP和使用Synopsys的CoreAssembler工具实现子系统自动集成。在基于AMBA 3 AXI协议的下一代高速设计中,这三部分的组合使得设计人员能充分降低设计和验证时间。
技术背景――AMBA 3 AXI协议为了正确领会面向基于AMBA 3 AXI协议的工程设计挑战的复杂性,我们必须理解AMBA 3 AXI协议自身的技术特点。AMBA 3 AXI协议是专门为实现下一代IC设计,由包括Synopsys在内的30多家公司合作开发的。AMBA 3 AXI协议定义了一种单向通道的架构,它能有效使用寄存器片断实现管道的高速连接。它支持多重突发事务、完成无序处理事务,和高效使用读、写和地址/控制操作的通道的联系,能使系统具有较高的性能和效率。这种性能只受设备能力的限制。
AMBA 3 AXI协议:通道的作用AMBA 3 AXI协议的架构和以前的AMBA协议有很大不同,因为它引入了通道。五个独立通道均由一组信息信号组成,使用一种双向“VALID”和“READY”的握手机制。当通道具有有效数据或者控制信息时,信息源使用“VALID”信号。目标则使用“READY”信号表示可以接收数据。读数据和写数据的通道均包含“LAST”信号来表示最终的数据传输。读和写处理都有各自的地址通道。地址通道包含了某种事务处理所需要的所有地址和控制信息。读数据的通道传输由从模块到主模块的读数据和读响应信息。读数据的通道包含了8、16、32、64、128、256、512或1024位的数据总线,以及用来表示读处理过程完成状态的读响应信息。写数据的通道传输由主模块到从模块的写数据和写响应信息。数据的通道包含了8、16、32、64、128、256、512或1024位的数据总线,同时对每8个数据位使用一个字节用来表示数据总线中哪个字节是有效的。支持非对齐的传输能更有效地使用总线以获得更高的性能,更低的存取时间和更高带宽。
AMBA 3 AXI的DesignWare IP解决方案随着AMBA 3 AXI协议的复杂化,基于此协议的子系统的设计和验证成为一关键问题,它需要大量的专门技术。DesignWare IP的解决方案专门为简化设计任务,给工程师提供存取通用设计和验证IP模块,以加快从模块到子系统级别的实现和验证过程。另外,coreAssember工具可自动集成子系统和测试实例。 设计人员使用为AMBA 3 AXI的DesignWare IP的解决方案可以快速集成,综合和验证基于AMBA 3 AXI的设计。
为AMBA 3 AXI的DesignWare综合IPDesignWare综合IP是解决方案三部分的第一部分,它可以快速实现高带宽,低存取时间和高性能的基于AMBA 3 AXI的设计。综合IP包含三个关键元素:互连总线制造,AXI到AHB的桥,主模块和从模块的通用接口。这些是新建任何片上系统的基本构建模块,它们使设计人员易于实现基于AMBA 3 AXI的架构。这些IP元件也能帮助已有IP和专门应用模块转化为基于AMBA 3 AXI,从而保证了产品的高重用性。
为AMBA 3 AXI的DesignWare Interconnect Fabric(DW_axi)具有的特点使其目前为止是基于AMBA 3 AXI协议设计的标准互连制造的最佳方案。DW_axi灵活的配置为工程师提供了一系列特色来匹配他们的具有优先顺序的设计需求。DW_axi是AMBA 3 AXI协议的RTL级互连实现,它可以同时实现不同主从模块之间的传输。它能配置支持最多16对支持所有协议中指定的地址和数据宽度的主模块和从模块。DW_axi是基于多重地址、多重数据总线架构的,它有选项内置于系统译码器。每个处理过程在地址通道包含有地址和控制信息,它们描述了所要传输的数据的自然状态。数据在主模块到从模块之间传输时,从模块使用写数据通道,主模块使用读数据通道。在写处理过程中,所有数据均从主模块流向从模块,AMBA 3 AXI协议具有一个额外的写响应通道来允许从模块给主模块发出信号表示写过程的完成。这种多层互连架构允许在所有5个AMBA 3 AXI的通道的不同主/从模块对之间进行并行传输。因此其系统带宽并不受DW_axi限制,而是受外部主从模块的限制。
除了提供组合式地址和数据通道的控制以外,DW_axi提供了内部和外部流水线操作,称为寄存器分割(register slicing)。它能使设计人员可以得到尽可能高的工作频率、带宽和性能。可配置的内部和外部寄存器分割能应用于单个的通道,无论是全路径还是向前控制路径,以提供时间和制造优化性能的最大灵活性。为优化SW_axi以获得最佳性能和最小面积,它包含了一个从属的可见特征,当不是所有的从模块对所有的主模块是可见的情况下可以使用该特征。它定制主模块的可见性用于对于正常和boot模式的从模块的存取,结果使得任何逻辑的复杂度降低。这样能以最少的逻辑得到优化的性能。
AMBA 3 AXI协议的一个关键目标是能互用已有的AMBA 2.0技术。为达到互用的目标,DesignWare IP解决方案包含了一个AMBA 3 AXI的桥梁,连接AMBA 2.0 AHB,称为DW_axi_x2h。DW_axi_x2h支持和完整的基于AMBA 2.0的子系统之间的联系,可以提供已有的基于AHB的子系统的复用。在lite模式中,单独的受控元件可以直接连接至基于AMBA 3 AXI协议的总线。这种互用的一个明显的优点在于设计人员已经拥有了大量的经DesignWare验证的AMBA 2.0 AHB和APB的综合IP和验证IP。它能提高复用的选择,增加了设计人员用于有差异的设计的时间,而不用于通用子系统的创建和验证。DesignWare综合IP解决方案包括了另外一些基于模块的通用AMBA 2.0的设计,比如AHB总线制造,DW_ahb,APB桥和制造,DW_apb,和一些设备,例如DMA、内存控制器、I2C、SSI、GPTI、RTC,定时器和中断控制器等。
还有一些可复用的基础元件也易于实现基于AMBA 3 AXI协议设计,它们就是DesignWare的为主模块和从模块的通用接口模块,称为DW_axi_gm/gs。DW_axi_gm/gs采用了一种通用的接口,减少了从定制的IP或者专用应用模块转为基于AMBA 3 AXI协议的总线的时间。当定制的应用或者IP连接至基于AMBA 3 AXI的总线时,设计人员不用担心协议的细节,因为DW_axi/gs模块能处理大部分AMBA 3 AXI接口的细节。当使用通用的接口时,一旦设计和AMBA 3 AXI的总线相连时,设计人员可以有更多的时间专注于验证和检查。
本文为全文原貌 未安装PDF浏览器用户请先下载安装 原版全文
为AMBA 3 AXI的DesignWare Verification IPDesignWare IP的解决方案的第二部分是为AMBA 3 AXI的Synopsys的DesignWare验证IP(VIP)。通过引入更多产品验证的高级技术,这些验证IP提供了一种快速有效的方法来验证基于AMBA 3 AXI的片上系统。AMBA 3 AXI的DesignWare的验证IP包含以下元件:主模块、从模块、监视器和验证互连。每个元件均支持所有的AMBA 3 AXI的地址和数据宽度,以及所有协议传输和响应的字节。VIP的主模块和从模块用于产生和响应处理事务。验证互连能产生一个具有完整互连功能的子系统,以帮助在模块级对多重模块相互作用的集成过程中的测试。验证IP包含完整的命令集,它可以完成定向事务处理,基于level命令的测试。验证IP将迅速修正互连错误,功能错误,通过特殊例子的测试。
验证IP已经获得AMBA3所确认的认证标志。这个标志表示DesignWare验证IP已被证明能正确实现于AMBA 3 AXI的规范系统,此系统是由来自ARM公司的规则集合所组成的基于断言的AXI测试系统。当验证IP被应用于模块级,对于工程师,这些模块的接口可以保证和AMBA 3 AXI协议规范一致。 由于这些模块均已证明在AMBA 3 AXI上的正确性,因此设计人员能轻易在模块级集成最终的子系统。DesignWare的验证IP除了能用于创建现实的应用系统外,还能被用于在子系统级进行完全测试主模块和从模块之间作用。使用这些IP可以确定符合AMBA 3 AXI协议规范。
DesignWare验证IP和参考验证方法DesignWare验证IP采用重用分层的、覆盖驱动的、随机约束的验证方法,它可用于快速产生上千种传输过程。
带约束的随机验证的生成是通过Synopsys的参考验证方法(RVM)定义的。RVM是在验证方法手册中目前可以获取的最好的实践方法。它为自动产生处理事务来强调协议组合的最大数目制定了一种强大的方法。随机约束、覆盖驱动的方法相比于传统的定向测试方法,可以为大而复杂的设计提供更好的产品和质量的验证。在定向测试的方法下,工程师通过写单个的测试来验证特殊的设计特点。此方法耗时巨大,尤其对于拥有大量相互作用的复杂设备更是可观。慢慢地,设计往往在达到验证质量目标前就流片,因而加大了提高成本的可能。
通过一种随机约束、覆盖驱动的方法,工程师可以为设计写出描述实际输入情形的高级的约束。先进的验证工具和验证IP将使用这些约束自动产生成千种测试校验实例而不用工程师去设计。功能覆盖用于指导验证和测量过程。它可以使验证质量目标可以在流片之前较容易达到,即使对于更复杂的设计也是如此。参考验证方法建于一种能重用的架构之上,用于实现带约束的随机验证环境,它能使模块级的测试重用于模块级、子系统级和多重项目之间。RVM驱动的验证IP意味着设计人员只需写最少的代码,即可按顺序产生成千上万的测试,通过实际的总线流量足以强调模块或子系统。基于Synopsys的RVM的环境提供了对于所有的验证元件一种统一的接口,它极易理解,而且能加快地在其他的项目之间重用。
为加快一个基于AMBA 3 AXI协议系统的验证,DesignWare验证IP应被用来依次验证单个的元件接口,子系统,最终是完整的系统。在模块级,验证IP可产生有效准确的激励以测试AMBA 3 AXI接口的应用。如果测试是根据RVM指南生成的,此级别的测试可以在子系统级再次运行。由于DesignWare为AMBA 3 AXI的验证IP均以通过AMBA3认证,设计人员可以对于验证过程的质量足够放心。
一个原始的基于AMBA 3 AXI的子系统的有效验证可以用许多松散连接的IP和DesignWare验证IP的设计模块来实现。这样可使互连、处理事务和特征能很快被验证,同时很快创建一套高覆盖率的测试。DesignWare验证IP的主模块和从模块被用于替代元件,这样主模块的VIP即可用于创建定向和约束的随机验证事务。这种方法允许快速地创建子系统的激励和响应,可以快速解决任何设计互连的问题。DesignWare验证IP的监视器被用于检查是否适应AMBA的需求以及提供和基于测试标准的得分板(scoreboard)的直接接口。
得分板实质是测试程序的一个模块,可提供一种自动智能的方法跟踪事务、覆盖和数据流。对于数据,它可设置为跟踪源标准数据并比较目标数据来为所测试的数据路径产生一个通过或失败的标准。得分板和DesignWare验证IP的监视器直接相连,以使所有的事务和覆盖数据被提取,捕获和验证。使用DesignWare验证IP监视器的优点在于当主模块和从模块的验证IP被删除或者被系统级别测试的真实RTL替代时,相同的基于得分板的验证环境可以继续使用。当监视器为无源元件时,它们可以用于整个验证周期。
为了进一步加快验证过程,在模块和子系统级的环境中应该加入断言IP从而能使用formal和hybrid formal的验证工具,例如Synopsys的magllan工具。验证环境应包括验证IP和断言IP。验证IP监视器提供了高级模拟特征,例如:cross-port的覆盖和得分板通告。由于ARM提供定义了断言的IP作为可执行规范,所以它可以作为参考的标准结果。所有的DesignWare的验证IP元件已经通过ARM提供的作为AMBA3确认认证过程的一部分的断言IP的验证。此外,DesignWare验证IP的监视器可以帮忙确定何时验证完成,通过跟踪和记录每个事务,提供覆盖信息,给出违反规范的错误和警告。
验证的最后一阶段就是完整系统级别的验证。在此阶段,必须包括对于松散连接应用的元件的RTL和IP。外部接口必须经过验证,其他的DesignWare验证IP此时可以用来减少系统级测试的负担。设计人员能广泛使用DesignWare Verificaion IP,它是作为VCS Verification Library的一部分,DesignWare Library产品包括PCI Express?、串行IO、I2C、以太网、USB、USB-OTG以及成千上万种基于存储器的模型。DesignWare Verification IP中为ABMA 3 AXI的主模块仍应用于产生激励因为原始子系统的测试能立即重用。另外的DesignWare Verification IP 还可以直接和得分板一起提供完整的智能验证平台。
验证工程师也希望尽可能快地模拟验证设计、标准测试、验证IP和断言IP。Synopsys VCS?模拟器可得到很高的模拟性能。VCS把完整的设计环境、设计、标准测试、验证IP和断言IP优化成单个统一的内核。这单个编译的内核能消除传统模拟环境中经常出现的通信和同步的问题。此方法具有5倍或者更多的模拟性能提高。对于验证工程,这意味着以前需5天运行的测试现在可以在1天以内完成。工程师能有更多的时间确保覆盖数目,提高最终设计的信心。
集成一体:DesignWare IP和Synopsys的coreAssembler工具DesignWare IP的解决方案的第三部分,是Synopsys的coreAssembler工具。当DesignWare Library IP和coreAssembler工具一起使用时,设计人员可在更少的时间内自动集成模拟和综合基于AMBA的子系统。coreAssembler工具能使子系统自动生成设计和AMBA 3 AXI和AMBA 2.0 AHB/APB元件的模块集成。coreAsembler工具可减少含有DesignWare IP的专用子系统的生成时间。这再次让设计人员可以专注于产品的其他测试或者差异性设计。coreAssembler工具完全支持“在工具流程内专为封装、集成和重用IP的结构”,SPIRIT,格式,适合SPIRIT的第三部分和定制IP模块能轻而易举地封装到装配子系统。
本文为全文原貌 未安装PDF浏览器用户请先下载安装 原版全文
在打包DesignWare的可综合IP和验证IP时使用了“装配导向技术”。这是内置的专门协议技术,能使coreAssembler自动完成IP模块的相互连接。Synopsys集成的专门技术是从AMBA IP和基于AMBA子系统的创建中多年形成的。它支持任何AMBA 3 AXI或者AMBA 2.0或者多层子系统的配置,另外还支持AMBALITE的配置。例如,设计人员具有AMBA 3 AXI互连的制造和AMBA 3 AXI到AMBA 2 AHB的桥元件,coreAssebler内置的集成系统可以自动将两个AMBA 3 AXI接口连接集成。这种自动构造方法可以消除印制产生线的错误。所有的DesignWare Library 综合IP元件和这种设计技术一起捆绑,还有一套缺省的参数。因此,产生一个子系统的初始设计就简单到只需点几下鼠标,选择几个下拉菜单以及配置一些子系统参数即可完成。
coreAssembler通过设计参数和系统级别参数的交叉传播以支持层次式设计的方法,可以避免多重IP的错误配置。这些参数,例如地址和数据宽度,可以在顶层被锁住,然后传播至低层次的IP模块,可确保避免IP模块的错误配置。这种内置的自动化的参数检查消除了IP配置错误的出现几率,能大大减少子系统调试的时间。工程师能越快地完成第一个子系统的模拟和运行时间,验证工程师就有越多的时间来验证子系统需求功能的实现。
为得到最优化的综合结果,coreAssembler能自动运行Synopsys的综合工具,包括PhysicalCompiler?和Design Compiler?。设计人员可以从多种综合方法中选择,例如面积-时延、时延-面积、ACS和低功耗优化等等流程。coreAssembler 也可以将用户定义的流程集成到其自动化的流程中。
为减少第一次模拟的时间,coreAssembler自动创建一个验证的基础架构,其包括DesignWare Verification IP专门达到集成子系统的目标。另外产生这个架构的同时,工具也产生DesignWare Verification IP用来测试子系统的激励。目前,这些还是简单的基础测试,例如写入一个IP元件的寄存器,再读出来保证写入的内容的正确性。虽然这些看似容易,但其确是很多子系统设计的第一个里程碑,在传统的子系统开发过程中,通常需要几周的时间。使用DesignWare Library IP和coreAssembler流程,子系统的基础测试可在几个小时之内完成。
自动化的流程也使设计新手变得很容易上手。比如,子系统以前是以32位数据线设计,而设计师在最后一分钟决定需要使用64位数据总线以达到性能的要求。在传统的设计流程中,工程师需要重新配置和修改很多RTL文件,它需要花费自己很多的时间,也许还会出现许多错误。而使用coreAssembler流程中,只需要通过一个在顶层一个参数的简单修改就可以完成,这个修改可以自动地传递到所有低层次的模块中。新的RTL代码会重新自动产生,同时也生成新的测试架构的文件。
总结
第2篇：soap协议范文
WebServices的基本元素是可扩展标记语言（ExtensibleMarkupLanguage，XML）、SOAP、Web服务描述语言（WebServicesDescriptionLanguage，WSDL）。XML用来编解码数据，SOAP用来传输数据，WSDL用来描述WebServices及如何访问WebServices。XML与超文本标记语言（HypertextMarkupLanguage，HTML）一样，都是标准通用标记语言（StandardGeneralizedMarkupLanguage，SGML）。XML是Internet环境中跨平台的依赖于内容的技术，是当前处理结构化文档信息的有力工具。SOAP是一种简单的基于XML的协议，使应用程序通过超文本传送协议（hypertexttransportprotocol，HTTP）交换信息。WSDL是基于XML的用来描述WebServices及如何访问WebServices的一种语言。WSDL可描述WebServices，用于WebServices的消息格式和协议的细节。使用WebServices技术作为接口技术的基础有以下优点。1）数据交换。WebServices使数据交换更方便，实现跨防火墙的通信，以一种最简单的方式实现异构系统间的互通信和数据交换，且能跨平台。2）数据封装。WebServices使用XML对数据封装，使用者能且仅能看到该对象提供的功能列表。3）应用程序集成。不同编程语言编写的应用程序通常都有一定的应用环境，集成起来会有很多技术壁垒，需要花费较多资源才能实现。通过WebServices，应用程序可用标准的方法把功能和数据“暴露”出来，供其他应用程序使用，简单方便。4）低成本。在实际项目中的开发成本最低，无论从软件开发人员的培训和WebServices产品的购买都较廉价。
2接口的技术方案
2.1采用基于中间数据库视图方式
根据需要对外发送的数据，组织SQL语句，把结果以数据库视图的方式建立。其他系统的接口程序通过分配具有一定权限的账户，访问中间数据库视图获取数据。该方式的优点：程序可自由访问数据库，访问的内容和访问的组合方式均可由应用程序自定义，并且可自定义SQL语句组织查询结果。缺点：数据库安全性差，非系统内部程序可直接接触到数据库层面，对信息保密有隐患。
2.2采用基于REST风格服务方式
表述性状态转移（RepresentationalStateTrans-fer，REST）代表了分布式超媒体系统的体系结构风格，是一种针对网络应用的设计和开发方式，可降低开发的复杂性，提高系统的可伸缩性。REST提出一些设计概念和准则：①网络上的所有事物都被抽象为资源；②每个资源对应一个唯一的资源标识；③通过通用的连接器接口对资源进行操作；④对资源的各种操作不会改变资源标识；⑤所有操作都是无状态的。该方式的优点：可利用缓存提高相应速度。通信本身的无状态性能使不同的服务器处理一系列请求中的不同请求，提高服务器可扩展性。浏览器可作为客户端，简化软件需求。缺点：安全性比SOAP低。对HTTP的依赖性高，需要通过HTTP的返回码区分返回结果。
2.3用基于SOAP协议的WebServices调用方式
SOAP可以和现存的多种因特网协议和格式结合使用，包括HTTP，简单邮件传输协议（SimpleMailTransferProtocol，SMTP），多用途网际邮件扩充协议（MultipurposeInternetMailExtensions，MIME）。还支持从消息系统到远程过程调用协议（RemoteProcedureCallProtocol，RPC）等大量的应用程序。该方式具备以下优点。1）具有可扩展性。SOAP客户端、服务器和协议自身均能吸纳新技术不断发展，而且升级更新时也不必中断已有的应用程序。2）SOAP调用简单。客户端只需发送一个请求，服务器获取请求后调用相应的对象，然后把调用的结果返回给客户端，完成一次调用交互。3）SOAP完全和厂商无关，与编程语言、平台无关。缺点：较复杂，对于大量并发应用，效率不高。根据以上方案的比较，结合智能电网通信管理系统对接口方面的要求，综合利弊，采用基于SOAP的WebServices方式实现接口功能。
3接口的设计与解析
3.1功能结构
智能电网通信管理系统接口软件（以下简称接口）采用接口调用方主动发起数据请求，接口提供方返回相应请求数据的应答模式。接互示意如图1所示。
3.2技术约定
为保证不同厂家开发的接口服务端和客户端软件能顺利实现接口调用，对WebServices具体接口实现过程作出如下规范及版本约定：1）整个接口消息基于XML语言，必须符合XMLV1.0（及更高版本）规范和XMLSchema（及更高版本）规范；2）接口实现必须使用SOAP协议，接口描述必须使用WSDL语言；3）接口实现方必须向接口调用方提供本端服务的WSDL文件，建议使用WebURL方式实时提供；4）接口实现必须符合SOAPV1.1版本规范，高版本SOAP协议必须保证与1.1版本的兼容性；5）接口实现必须至少支持SOAP在HTTPV1.0协议上的传输；6）接口实现必须符合WSDLV1.1版本规范，高版本WSDL语言必须保证与1.1版本的兼容性；7）接口描述必须至少支持WSDL在SOAPV1.1协议上的绑定；8）接口实现必须支持WS-IBasicProfileV1.0（及更高版本）互联互通协议。
4结语
第3篇：soap协议范文
1系统概述
企业服务总线的核心是由消息监听器、适配器、协议转换器、消息路由器和服务调度器五部分组成.协议转换作为企业服务总线的核心功能之一,可以为注册到企业服务总线上的服务提供者和服务请求者提供可靠的交互服务.ESB系统总体框架图如图1所示.企业服务总线的主要功能包括如下部分:1.消息监听功能:监听基于不同协议的消息.2.服务请求者与服务提供者之间的应用协议的转换:如果服务请求消息基于的协议与服务提供者所注册的协议不同或者服务提供者所提供的服务消息是服务请求者无法解析,则需要对该协议进行转换.3.服务之间的消息转发(路由):把请求消息转发到目标的服务地址.4.服务定位:查找服务的目标地址.5.服务安全:对请求消息进行认证授权.在企业服务总线中,协议转换器主要功能就是如果请求消息基于的协议与服务者所采用的协议不同,则需要对该协议进行转换.
2协议转换器的需求分析
各个系统在需要与其他系统交互的时候,要通过调用ESB来访问目标系统提供的服务接口获取数据,完成业务操作.各应用系统作为服务消费方在调用ESB的时候,需要明确每个参数代表的含义,按照参数书写格式要求来发送参数,然后ESB会自动调用消费方服务.但连接到ESB上的服务请求者和服务提供者可能采用不同的应用协议,针对不同的应用协议,ESB的监听器接收到的请求消息有不同的协议格式.如果ESB能够支持现有的各种通信协议,那么对消息的处理就完全不考虑传输细节,而直接通过消息请求和获取服务.如果没有将一种协议转换为另一种协议的工具,则服务请求者很难与给定的服务提供者进行通信.与此需求相关的需求是使用者的数据格式可能与服务提供者使用的数据格式不同.因此,需要一种能够提供此转换的工具.
关键技术
1基本定义
SOAP即简单对象访问协议,是一个轻量级的、简单的、基于XML进行信息交换的通信协议.它可以和现存的许多因特网协议进行结合使用,包括HTTP,SMTP.JMS是实现JAVA领域远程通信的一种手段和方法,是个远程通信协议,在其他的语言体系中也存在着类似JMS的东西,可以统一的将这类机制称为消息机制.XML(ExtensibleMarkupLanguage)即可扩展标记语言,它是万维网协会的XML工作小组所定义的可扩展标记语言,是一组规则与准则的集合.XML作为通用的、自解释的数据交换格式,已成为大多数应用程序所采用,XML技术可以有效地解决不同协议下的数据之间的共享与交互.
XML现在已经成为一种通用的数据交换格式,它的平台无关性,语言无关性,系统无关性,给数据集成与交互带来了极大的方便.XML是从标准通用标记语言(SGML)中简化修改出来的.XML将SGML的灵活性和强大功能与已经被广泛采用的HTML结合起来,简化了计算机对文档和数据交换的处理,使得现有的协议和软件更为协调,从而简化了数据的处理和传输.使用XML标记语言可以做到数据或数据结构在任何编程语言环境下的共享.XML最大的优势在于它能对各种编程语言编写的数据进行管理,使得在任何平台下都能通过解析器来读取XML数据.XML标记语言的语法非常简单,可以通过解析器在任何机器上解读.并可以在各种计算机平台上使用.逐渐成为一种数据交换的语言.
2协议转换思想
ESB支持广泛使用的协议(HTTP,JMS,SOAP等等).目前,我们设计的ESB系统支持的协议有:HTTP、SOAP和JMS协议,以后还将对其进行扩展.协议转换模型用于当服务的请求者与服务提供者基于不同协议时的消息转换.消息监听部分监听到消息后,对其进行适配,然后将其传递给协议转换部分,协议转换器主要负责将采用不同协议的消息转换成内部标准消息,经由消息路由器路由后将其封装成目标方要求的协议形式的消息传递到目标方.在进行协议转换时,标准消息的内容主要由以下几部分组成:用户名、角色类型、IP地址、端口号、消息的状态、消息的寻址信息和业务数据.
网络上传输的消息的内容常常分为消息头和消息体,如应用层的HTTP、SOAP、JMS消息.业务相关内容存入消息体中,消息头中包含与业务无关的管理信息,比如消息的优先级、序列号、地址信息等.因此,对消息进行解析时,可以对其消息头和消息体分别进行解析.譬如SOAP消息都使用XML形式编码.处理接收到的SOAP消息应该有两个步骤,首先,识别应用程序需要的SOAP消息的头部分;其次,识别应用程序需要的SOAP消息体部分;最后,检验该SOAP消息是否满足要求,即消息的目的地址、参数信息等是否和目标地址名称、参数等相对应.
协议转换模型设计与实现
1并行XML解析
XML在不同的语言里解析方式通常都是一样的.基本的解析方式有两种:SAX和DOM.利用SAX解析XML文档,牵涉到两个部分:解析器和事件处理器.解析器负责读取XML文档,并向事件处理器发生事件,如元素开始和元素结束事件;而事件处理器则负责对事件做出响应,对传递的XML数据进行处理.DOM是基于XML文档树结构的解析,DOM在分析XML文档时,将组成XML文档的各个部分映射为一个对象,在内存中,这些节点形成一棵文档树,整棵树是一个节点,树中的每一个节点也是一棵树,通过访问树中的节点来存取XML文档的内容.为了提高系统的效率,在这个协议解析器中,我们将采用一种并行的XML解析方式.并行XML解析可以充分利用多核计算机的优势来提高系统的性能.具体实现方式为:首先对XML文件进行预解析,根据预解析的结果将XML文件划分为多个小的XML文件,并将这些XML文件分配到不同的线程上,从而这些划分后的XML文件就可以并行地进行解析.
2协议转换模型
在不同系统或不同系统的组成部分之间传输数据时,必须考虑接口参数差异问题.不同格式的数据是难以在系统内部或者系统间传输的,因此协议转换器要解决这种异构的问题.鉴于业务相关内容通常存入消息体中,消息头中包含与业务无关的管理信息,协议转换器以分层方式进行转换,主要包括2个部分:消息头转换和消息体的转换.在进行协议转换时,要对ESB系统支持的各个协议建立模型,每当需要某种协议解析时,都要读取对应的协议模型信息.协议转换可能会出现解析失败的情况,这就要求将失败信息记录到日志文件中,方便系统查阅并进行处理.
为进行协议转换,消息或服务必须要先进行适配,在初次连接或者其协议发生变化时,要填写其协议的格式,在此设计一个表格存储在注册库中.这一表格包括字段序号(SQ),消息名称,消息序号,消息类型,字段名称,起始位,长度,字段类型,字段描述.其中,消息类型是指消息所使用的协议.协议转换示意图如图2所示。协议转换器要把收到的不同协议格式的消息转换为内部统一的消息格式即XML的格式,以方便内部消息路由器对消息的路由;消息路由器对消息路由后,由系统内向服务提供方或者服务请求方发送数据时,协议转换器实现读取XML文件,按照数据库中对应的注册的协议的要求,形成指定的消息类型,并发送到目的地.而这里的转换是需要服务请求方和服务提供方提前注册他们支持的协议的详细信息,我们将这些信息分别都保存在不同的表格里,并存入注册库.
因此,协议转换器有两个功能要实现.一个是将接收到的消息转换为内部数据格式即XML文件.另一个功能是将内部表示的XML文件转换为注册库中查找到的目标协议格式,在这一过程中,需要使用并行XML解析方式对XML文件进行解析,从而能够快速地实现协议转换.在这个转换的过程中,ESB系统首先要建立所支持的JMS、HTTP和SOAP协议的模型,从而为协议转换提供相关的信息.协议转换器过程图如图3所示,在这里以JMS和SOAP协议转换为例.若获取到对方的JMS或者SOAP消息,则在存入数据库的同时,要首先根据之前注册的JMS或者SOAP模型将JMS或者SOAP消息转换为XML的格式,统一消息格式,方便系统对数据的处理.当传输数据时,若传输的是其他形式的消息,则其消息格式 为消息描述指定的格式,协议转换器就利用消息描述表中对消息的内容的描述进行转换,将XML格式的消息转换为JMS或者SOAP消息.实质上,在协议转换器中,消息的转换包括两个层次上的协议转换:服务请求方的数据到系统内部的协议转换,系统内部的消息到服务提供方的协议转换;服务提供方的消息到系统内部的协议转换,以及系统内部的消息到服务提供方的协议转换.
3协议转换器的可扩展性
设计模式使人们可以更加简单方便地复用成功的设计和体系结构.为了实现协议转换器的可扩展性,协议转换器的实现中应用了工厂模式和适配器模式.协议转换器的类图如图4所示:在协议转换器的实现中,AbstractTransformer是所有协议转换的一个基类,并且是一个抽象类,实现了接口Transformer和Amnotatedobject.其它的转换类都实现了AbstractTransformer.
结语
第4篇：soap协议范文
关键词： Android； Web Service； 智能家居； 嵌入式网关； 视频监控
中图分类号：TP311 文献标志码：A 文章编号：1006-8228（2017）03-44-04
Abstract： For the smart home system controlled by PC has disadvantages in price， mobility and operation， a new design and implantation scheme of smart home system based Web Service is proposed. The embedded Web Service server and ONVIF video monitoring server are built by transplanting gSOAP， the client end is realized by using KSOAP2 development kit. Users can control and monitor the remote smart home devices via Android phone and tablet. The system has advantage of simple， low cost， portable and practical， and it is worth to be promoted.
Key words： Android； Web Service； smart home； embedded gateway； video monitor
0 引言
智能家居（smart home）系统通过将家居设备进行组网，将计算机技术和自动化技术进行整合，实现居家环境监测、视频监控、家电控制，以及危险预警系统等诸多服务，提高了人们的生活水平，现在正在慢慢走进人们的生活[1]。目前，大多数的智能家居系统采用PC机进行控制，这种控制系统造价高，不能移动，不方便操作。采用手机或者平板电脑远程连接家庭网络，可以方便快捷的实施监控[2-5]。但是，目前采用这种手机或平板控制的智能家居系统比较少，而且大部分的功能比较单一，界面设计简单，无法提供良好的用户体验。
本文提出了一种采用Web Service技术的智能家居系统实现方案。用户可以通过运行Android系统的智能手机或者平板，连接家庭网关，对家用电器进行远程控制，对居家环境进行远程视频监控。
1 系统硬件平台
智能家居网络总体框架如图1所示。家庭中各个网传感节点和Zigbee协调器组成星型通信网络。各个传感器节点和家居设备以Zigbee方式和协调器通信，协调器通过串口连接网关。本系统的网关采用基于ARM1176JZF-S内核，主频533MHz的高性能嵌入式芯片S3C6410。网关上组建嵌入式Web服务器和视频服务器，提供Web Service服务。运行在手机或平板上的智能家居控制系统客户端通过调用Web Service服务实现以下功能。
⑴ 通过获取温度传感器、湿度传感器、光照度传感器、红外传感器的数据，实现对居室环境数据进行持续的采集。
⑵ 对智能家电、智能窗帘和智能灯具等设备的控制。
⑶ 调用摄像机实现远程视频监控。
2 软件框架
2.1 程序架构
本系统采用目前流行的Web Service技术，实现安卓客户端和网关服务器之间的通信。Web Service是一种跨平台的分布式Web应用程序。Web Service服务由服务器提供，客户端可以在网络上的任何一个位置调用此服务。Web Service三个重要的组成部分是SOAP、WSDL（Web Services Description Language）和UDDI（Universal Description Discovery and Integration） [6]。SOAP是一个基于XML的轻量型分布式计算协议，定义了调用Web Service服务的标准方法；WSDL用于描述访问具体的接口的方式；UDDI用来管理、分发和查询Web Service。
软件框架如图2所示。客户端和服务器之间通过HTTP协议进行SOAP消息的传递。网关服务器运行Linux操作系统，提供基于SOCKET的HTTP协议通信协议。然后再移植开源Web Service工具gSOAP来提供Web Service服务所需要的XML解析器和SOAP处理器。
2.2 服掌鞫顺绦蛏杓
服务器端程序设计步骤：首先生成C/C++头文件；然后使用SOAP编译器编译后生成RPC服务框架和序列化的数据类型代码；最后将这些代码链接到服务应用程序中，就成为可供客户端调用的Web Service。gSOAP编译器同时会生成一个WSDL文档用于描述这些服务。
在本设计中，客户端的请求分为POST和GET两种方法。GET方法用来处理静态网页，进而为描述接口的WSDL文件提供支持。POST方法用来实现SOAP消息的传输，将接收到的HTTP数据包保存在内存缓冲区，然后再进行进一步的处理。网关服务器对SOAP消息的处理过程如图3所示。服务器在接受到客户端的HTTP请求以后，调用相关模块解析SOAP消息，然后根据解析结果提供相应的服务。最后将执行结果封装成SOAP响应信息返回给客户端。
2.3 视频服务器程序设计
采用建立在Web Service的SOAP通信框架基础之上的ONVIF通信标准，进行视频服务器设计。ONVIF通过定义网络视频设备之间信息交换的通用标准，以实现不同厂家的视频产品之间的互通性。ONVIF也是使用WSDL定义服务，使用XML语言描述数据，采用SOAP通信协议传输信息。ONVIF标准包括设备发现和设备管理两大功能模块，前者通过基于IP组播技术实现，后者通过传递SOAP消息进行通信。SOAP通信框架按照以下步骤生成[7]。
⑴ 登录ONVIF网下载WSDL文件，该文件描述了与媒体服务相关的Web服务消息格式、操作、数据类型、协议绑定和服务地址。
⑵ 从网上下载gSOAP 2.8.21工具，解压后得到的wsdl2h和soapcpp2文件。
⑶ 使用wsdl2h工具将WSDL文件转换成C/C++风格的头文件。
⑷ 使用soapcpp2工具将上一步产生的头文件生成服务器端提供SOAP服务的框架（Skeleton）代码。
3 安卓客户端程序设计
3.1 客户端与服务器之间的通信
在Android客户端平台上，调用服务器端的Web Service必须使用开发包KSOAP2，以实现SOAP协议的处理。KSOAP2是一个用于资源受限制的Java环境如Applets或J2ME应用程序的第三方类库。
安卓客户端通过调用服务器端的Web Service服务，通过对远程数据库的查询、控制和管理操作，从而实现对家居设备进行控制和监视。本设计采用的KSOAP2软件工具可以封装用户请求，以SOAP格式来调用Web Service，然后将返回的SOAP格式的数据信息解析为SOAP Objecet对象。KSOAP2调用Web Service步骤如下。
⑴ 下载Ksoap2-Android工具，并导入工程。
⑵ 指定Web Service的命名空间和调用Web Service方法的名称。
⑶ 借助Soap Object对象传递参数。
⑷ 生成调用Web Service方法的SOAP请求信息，并指定SOAP的版本。
⑸ 调用Web Service，根据返回的数据，解析出结果。
3.2 客户端设计
客户端连接服务器的第一步是登录，进行身份验证，其流程如图4所示。首先输入服务器的用户名和密码。如果服务器验证通过，就可以建立客户端与服务器之间的交互通道，在主界面中接收服务器响应数据帧，同时更新所有家居设备的状态信息。用户登录成功后，可以执行如下相应的动作。
⑴ 如果要控制设备或者查询设备状态信息，则通过Get方法发送控制帧或者查询帧。
⑵ 如果要执行视频监控则通过POST方法发送视频控制命令。
⑶ 如果用户需要更改密码，就要输入旧、新两种密码，如果密码匹配，则服务器返回响应码“201”，表示密码更改成功；否则可以向服务器发送控制或者查询请求，服务器收到后，先返回一个响应，然后执行相应的动作。
3.3 视频监控客户端设计
3.3.1 设备发现和管理
设备发现的主要目的就是获取ONVIF设备的服务功能和服务地址，为后面的视频数据接收和播放提供基础。ONVIF协议的设备发现模块可以让客户端发现服务器的RPC的入口，本设计采用WS-Discovery发现协议实现该功能。WS-Discovery [8]协议采用SOAP和UDP组播协议，客户端使用239.255.255.250：3702地址发送组播消息自动搜索ONVIF设备。服务器端的ONVIF设备收到组播消息后进行响应，客户端根据收到响应数据包来获取相应的设备信息，统计搜索到的设备个数。
3.3.2 流媒体数据接收及分片打包
网关服务器摄像头自带视频采集、视频压缩编码功能，输H.264格式编码的标准数据流。客户端通过RTSP会话接收服务器端的流媒体数据，一次完整的会话过程如下。
⑴ 连接服务器，同时发送一个RTSP DESCRIBE命令。服务器返回一个描述媒体类型、流数量等信息SDP。
⑵ 分析收到的SDP，为会话中的流发送一个SETUP命令建立RTSP。客户端通过此命令将自己的端口号告诉服务器。
⑶ 流媒体连接过程建立成功以后，客户端发送PLAY命令和TERADOWN来开始和结束视频的播放，还可以发送快进、快进和暂停命令。在播放过程中，服务器使用UDP发送流媒体RTP包给客户端。
本系统需要多个ONVIF IPC设备通信，为了提高数据传输速率和数据处理的效率，课题组采用Select网络模型完成标准的RTSP会话过程。
3.3.3 流媒体解码及显示
为了能显示视频，客户端需要首先移植FFMPGE。使用FFMPGE对接收到的RTSP流媒体文件进行解码，再将解码后的信息转换成为YUNV420P格式，然后再转换为RGB24格式。最后再转换成可在安卓设备上播放的ARGB_8888格式。转换完毕之后，就可以将每一帧显示在屏幕上。
4 结论
本文结合嵌入式系统和安卓平台优势， 采用目前流行的Web Service技术，设计和实现了智能家居系统的服务器端和安卓客户端程序。服务器端通过移植gSOAP和ONVIF协议来组建嵌入式Web服务器，提供Web Service服务。安卓客户端程序给予KSOAP2开发包进行设计，实现了服务器端的Web Service服务的调用。系统主要采用JAVA语言进行开发，具有结构简单，开发难度低的优点。系统操作简单、成本低、使用方便，可以实现家居设备的远程控制和居家环境的远程视频监视，给人们生活带来极大的便利，具有较高的使用价值和推广价值。
参考文献（References）：
[1] Lin H T. Implementing smart homes with open sourcesolutions[J]. International Journal of Smart Home，2013.7.
[2] 周恩，李文军，郑永军等.Android平台的智能家居控制系统设计[J].中国计量学院学报，2013.24（3）：261-265
[3] Z阳静，邹念育，雷冬鸣等.基于Android和WIFI通信的智能家居系统设计[J].大连工业大学学报，2016.1：67-71
[4] 黄成云，卢选民，李戈.基于Android的智能家居控制软件设计与实现[J].计算机与现代化，2014.11：102-105
[5] Kumar S. Ubiquitous Smart Home System Using AndroidApplication[J]. Computer Science，2014.6（1）.
[6] 龚瑞琴，毕利.基于Web Service的Android技术应用研究[J].电子技术应用，2014.40（1）：134-136
第5篇：soap协议范文
关键词:Web服务;端到端安全;SSL;ESSL
中图分类号:TP309文献标识码:A文章编号:1009-3044(2009)13-3383-02
1 引言
Web 服务是一个崭新的分布式计算模型,是Web上数据和信息集成的有效机制[3]。Web服务的新型构架,Web服务的高效执行方式,Web服务与其他成熟技术的有机结合以及Web服务的集成是解决现实应用问题的重要技术。但是,Web 服务的安全问题也日益的突出,并逐渐成为Web 服务向前发展的一个瓶颈。当然国内外,Web 服务安全的研究有也不少的成果。但是还是不能够完全满足Web服务的端到端的安全需求。本文讨论了SSL在保障Web服务安全方面不足,并在此基础上提出扩展的SSL,用以满足Web 服务端到端的安全需求,在最后对扩展的协议进行分析,说明了它的优势以及应用的意义。
2 SSL在Web 服务安全机制中的应用分析
2.1 Web 服务安全需求分析
作为典型的分布式应用,Web 服务的安全要求包括:数据的机密性、数据的完整性、不可否认性、身份认证、访问控制、审计和安全管理等多个方面,同时还具有自身的特点[1]。对于Web 服务来说,保障其安全需要end-to-end的安全。当然这并不是说point-to-point的安全机制以及其他的传统的安全不可以应用到Web 服务,恰恰相反,由于目前大多数哦Web 服务使用http作为其传输层,因此在依赖于http原来的安全机制都可以在Web services中使用[1],例如防墙、SSL等。Web 服务在实施的过程中也许需要point-to-point 和end-to-end其中的一种或两种的安全机制,这取决于受到的威胁的所处层次[1]。如果对于安全性要求不高或者威胁的层次比较低的话,像SSL、防火墙等都可以发挥很好的作用[1]。
2.2 SSL协议概述
SSL 协议(Secure Socket Layer)是Netscape 推出的一种安全通信协议,它提供Internet上保密通信的安全协议。SSL的Client和Server在正式交换应用数据之前,需要建立会话密钥以及有选择地进行身份验证。会话和连接是SSL的两个重要的贯穿始终的概念。连接建立在会话的基础上,每个连接与一个会话关联。Cipher Spec和master secret组成一个会话的主要加密参数,可被多个连接共享。每个连接有独立的会话密钥。
SSL的安全服务位于TCP和应用层之间,对应用层是透明的[2,5],可为应用层如:HTTP、FTP、SMTP等提供安全业务,服务对象主要是Web 应用,即客户浏览器和服务器。
SSL有三种验证模式[5]:
1) Client和Server都被验证;
2) 只验证Server、不验证Client;
3) 完全匿名。
SSL协议提供的服务可以归纳为如下三个方面[5]:
1) 连接是保密的,对称加密用于加密数据;
2) 实体的身份通过公钥加密得到验证;
3) 连接是可靠的,带密钥的MAC用于保证信息的完整性。
2.3 和SSL在Web服务中的应用分析
尽管SSL在Web 服务中能够提供一定的安全保障,但是它只能够提供点对点的安全,如图1所示,而无法保障端到端的安全,如图2所示,在高要求或者威胁层次较高的时候,它就无法满足要求。在Web 服务的典型应用中,SOAP消息往往不仅仅只是在两个节点间传输,更多的情况下是要经过很多的中间节点[6-7],而且每个中间节点都可能会对SOAP消息进行处理。虽然SSL可以确保SOAP消息在两个相邻的节点之间的安全,但是由于在节点内部SOAP消息是以明文出现的,所以,一旦其中一个节点受到了攻击或者恶意的修改SOAP消息,都会造成SOAP消息的泄漏或异常。因此,SSL对于SOAP消息的端到端的安全性是不够的[4],必须有一种更高级级别的安全机制作为保障。
3 扩展的ESSL
为了解决上面我们提到SSL协议在保障Web服务安全中的不足,对SLL进行扩展,称之为扩展的SSL协议(Extended SSL,简称ESSL),这个改进保留了SSL原有的安全特性,又可以满足Web服务的end-to-end的安全需求。(ESSL术语只在本文中适用)
3.1 相关标记
为了准确表达,我们使用下面标记:
Ii:第i个节点,其中I1是消息的原始发送者(Requester/Provider),In是消息最终收到的消息的(Requester/Provider),0
info:原始的信息
infoi:经过Ii修改后的信息,由Ii加密后发送给Ii+1
Ceri:Ii的证书
h():使用安全的hash函数进行对消息的摘要
ski:Ii的私钥
pki:Ii的公钥
sgni:Ii数字的签名
Sign(ski,m):Ii用自己的私钥对消息m进行数字签名
Rec(pki,s):用Ii的公钥对签名s进行验证
E(pki,m):用Ii的公钥加密消息m
D(ski,s):Ii用自己的私钥解密加密的消息s
ki:Ii随机生成的对称密钥
E(ki,m):用ki进行加密
D(ki,s):用ki进行解密
3.2 协议的流程的详细描述
首先要说明的是,两个相互通信的节点,在进行消息的传递之前要进行握手,在握手的过程主要是交换相互的数字证书以及协商相关的加密算法等。
协议的流程如下:
1) I1:生成签名:sgn1=Sign(sk1,h(info)),加密信息:E(k1,info),生成数字信封:E(pk2,k1),I1把(sgn1,E(k1,info),E(k1,info),E(pk2,k1),(sgn1,Cer1))发送给下一个通信节点。
2) 中间节点Ii(1
3) In:收到消息(sgnn-1,E (kn-1,infon-1), E (kn-1,info),E(pkn,kn-1),(sgn1,Cer1,)),In首先解开数字信封D(skn,E(pkn,kn-1)),获得对称密钥kn-1,然后获取信息info=D(kn-1,E(kn-1,info))和infon-1= D(kn-1,E(kn-1,infon-1)),验证In-1的签名Rec (pkn-1,sgnn-1)=h(D(kn-1,E(kn-1,infon-1)))?,然后在验证I1的签名和原始信息的完整性Rec (pk1,sgn1)=h(D(kn-1,E(kn-1,info)))?。如果验证通过就进行下一步的操作,如果没有就终止通信。
协议中对消息的解密以及验证的流程如图3所示。
协议中对消息加密处理的流程图如图4所示。
说明:当i=1的时候,虚线框中的处理过程就不需要了,因为info1=info
4 ESSL协议的分析
4.1 安全性分析
从ESSL的流程可以看出,SSL原有的安全机制都被包含,同时由于在消息中加入原始信息发送者对原始信息的签名以及它的数字证书,另外在原始信息和修改后的信息都被发送到最终接收者In那里,这样最终的接收者In不仅能够看出来中间节点对原始信息的修改,同时还可以验证原始的信息及其签名和消息的完整性。另外,协议使用原来的数字信封以及对称加密,使得消息的机密性也有了保障。(下转第3397页)
(上接第3384页)
综上所述,使用ESSL可以保证Web服务端到端的安全。
4.2 速度分析
为了能够达到端到端的安全需求,ESSL多发送了很多“冗余”的信息并且做了附加的加密和验证,这样对于传送的速度以及验证速度势必有所影响。但是,为了信息的安全或者特殊的安全需要,可以用性能换取高安全。
5 结束语
该文分析了Web服务的安全需求,指出了现有的SSL在保障Web服务安全中存在的不足,并在SSL协议的基础上做出了改进,提出了ESSL,使其达到Web服务端到端的安全需求,从而能够保障Web 服务的端到端的安全。另外,在其它要求端到端安全的环境中,ESSL也有着广泛的用途。
参考文献:
[1] Web Services Architecture[EB/OL].(2004-02)./2002/ws/.
[2] 宋志敏,王卫京,南相浩.SSL V3.0及其安全性分析[J].计算机工程与应用2000(10):145-147.
[3] 岳昆,王晓玲,周傲.Web 服务核心支撑技术:研究综述[J].软件学报,2004,15(3):428-442.
[4] IBM Corporation.Web Service Conceptual Architecture (WSCA1.0) [EB/OL]./developerworks/cn/views/webservices/libraryview.jsp.
[5] 范红,冯登国.安全协议理论与方法[M].北京:科学出版社,2003.
[6] 钱权,严家德.Web Service的安全机制[J].计算机工程,2007,33(22):190-192.
[7] 石伟鹏,杨小虎.基于SOAP协议的Web Service安全基础规范(WS-Security)[J].计算机应用研究,2003(2):100-102.
第6篇：soap协议范文
Web service是一个平立的，松耦合的，自包含的、基于可编程的web的应用程序，可使用开放的XML标准来描述、、发现、协调和配置这些应用程序，用于开发分布式的互操作的应用程序。
集成化物流管理控制系统(iWMS) 是自动化立体库中的灵魂和中枢。是一个基于UNIX/Windows操作系统、在网络环境下实现客户机/服务器模式的软件系统。其目的是集成地管理、协调和调度物流有关的有关物流活动，并及时与ERP（企业资源管理系统）等系统交换信息。执行ERP系统所下达的采购计划和物料需求计划等，并将执行结果及时反馈。
关键字：Web Service
集成化物流管理控制系统
企业资源管理系统
中图分类号：C29 文献标识码：A 文章编号：
第一部分 引言
Web Service是一项新技术， 能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件， 就可相互交换数据或集成。依据Web Service规范实施的应用之间， 无论它们所使用的语言、 平台或内部协议是什么， 都可以相互交换数据。Web Service是自描述、 自包含的可用网络模块， 可以执行具体的业务功能。Web Service也很容易部署， 因为它们基于一些常规的产业标准以及已有的一些技术，诸如XML和HTTP。Web Service减少了应用接口的花费。Web Service为整个企业甚至多个组织之间的业务流程的集成提供了一个通用机制。
第二部分 介绍Web Service
简单来说，Web Service是一种跨编程语言和跨操作系统平台的远程调用技术。
其实可以从多个角度来理解Web Service，从表面上看，Web Service就是一个应用程序向外界暴露出一个能通过Web进行调用的API，也就是说能用编程的方法通过Web来调用这个应用程序。我们把调用这个Web Service的应用程序叫做客户端，而把提供这个Web Service的应用程序叫做服务端。从深层次看，Web Service是建立可互操作的分布式应用程序的新平台，是一个平台，是一套标准。它定义了应用程序如何在Web上实现互操作性，你可以用任何你喜欢的语言，在任何你喜欢的平台上写Web service ，只要我们可以通过Web service标准对这些服务进行查询和访问。
Web Service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性，Web Service平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。Web Service平台必须提供一种标准来描述Web Service，让客户可以得到足够的信息来调用这个Web Service。最后，我们还必须有一种方法来对这个Web Service进行远程调用,这种方法实际是一种远程过程调用协议(RPC)。为了达到互操作性，这种RPC协议还必须与平台和编程语言无关。
第一 Web Service的优势
平台无关。不管你使用什么平台，都可以使用Web service。
编程语言无关。只要遵守相关协议，就可以使用任意编程语言，向其他网站要求Web service。这大大增加了web service的适用性，降低了对程序员的要求。
对于Web service提供者来说，部署、升级和维护Web service都非常单纯，不需要考虑客户端兼容问题，而且一次性就能完成。
对于Web service使用者来说，可以轻易实现多种数据、多种服务的聚合（mashup），因此能够做出一些以前根本无法想像的事情。
第二 Web Service的发展趋势
在使用方式上，RPC和soap的使用在减少，Restful架构占到了主导地位。
在数据格式上，XML格式的使用在减少，json等轻量级格式的使用在增多。
在设计架构上，越来越多的第三方软件让用户在客户端（即浏览器），直接与云端对话，不再使用第三方的服务器进行中转或处理数据。
第三 Web Service平台技术
XML+XSD,SOAP和WSDL就是构成Web Service平台的三大技术。
XML+XSD：
Web Service采用HTTP协议传输数据，采用XML格式封装数据（即XML中说明调用远程服务对象的哪个方法，传递的参数是什么，以及服务对象的返回结果是什么）。XML是Web Service平台中表示数据的格式。除了易于建立和易于分析外，XML主要的优点在于它既是平台无关的，又是厂商无关的。无关性是比技术优越性更重要的：软件厂商是不会选择一个由竞争对手所发明的技术的。
XML解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。例如，整形数到底代表什么？16位，32位，64位？这些细节对实现互操作性很重要。XML Schema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。Web Service平台就是用XSD来作为其数据类型系统的。当你用某种语言(如或C#)来构造一个Web service时，为了符合Web Service标准，所有你使用的数据类型都必须被转换为XSD类型。你用的工具可能已经自动帮你完成了这个转换，但你很可能会根据你的需要修改一下转换过程。
SOAP：
Web Service通过HTTP协议发送请求和接收结果时，发送的请求内容和结果内容都采用XML格式封装，并增加了一些特定的HTTP消息头，以说明HTTP消息的内容格式，这些特定的HTTP消息头和XML内容格式就是SOAP协议。SOAP提供了标准的RPC方法来调用Web Service。
SOAP协议 = HTTP协议 + XML数据格式
SOAP协议定义了SOAP消息的格式，SOAP协议是基于HTTP协议的，SOAP也是基于XML和XSD的，XML是SOAP的数据编码方式。打个比喻：HTTP就是普通公路，XML就是中间的绿色隔离带和两边的防护栏，SOAP就是普通公路经过加隔离带和防护栏改造过的高速公路。
WSDL：
好比我们去商店买东西，首先要知道商店里有什么东西可买，然后再来购买，商家的做法就是张贴广告海报。 Web Service也一样，Web Service客户端要调用一个Web Service服务，首先要有知道这个服务的地址在哪，以及这个服务里有什么方法可以调用，所以，Web Service务器端首先要通过一个WSDL文件来说明自己家里有啥服务可以对外调用，服务是什么（服务中有哪些方法，方法接受的参数是什么，返回值是什么），服务的网络地址用哪个url地址表示，服务通过什么方式来调用。
WSDL(Web Services Description Language)就是这样一个基于XML的语言，用于描述Web Service及其函数、参数和返回值。它是Web Service客户端和服务器端都能理解的标准格式。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具既能根据你的Web service生成WSDL文档，又能导入WSDL文档，生成调用相应Web Service的类代码。
WSDL文件保存在Web服务器上，通过一个url地址就可以访问到它。客户端要调用一个Web Service服务之前，要知道该服务的WSDL文件的地址。Web Service服务提供商可以通过两种方式来暴露它的WSDL文件地址：1.注册到UDDI服务器，以便被人查找；2.直接告诉给客户端调用者。
第三部分 Web Service在物流管理控制系统和企业资源管理系统接口中的应用
集成化物流管理控制系统(iWMS) 是自动化立体库中的灵魂和中枢。是一个基于UNIX/Windows操作系统、在网络环境下实现客户机/服务器模式的软件系统。其目的是集成地管理、协调和调度物流有关的有关物流活动，并及时与ERP（企业资源管理系统）等系统交换信息。执行ERP系统所下达的采购计划和物料需求计划等，并将执行结果及时反馈。
一般企业再建造自动化立体库前，自己的ERP系统（企业资源管理系统）已经上线，而建造完自动化立体库后，将集成化物流管理信息系统与ERP系统有机结合在一起，成为摆在企业信息化管理者面前的重要项目之一。有可能两个系统服务器，操作系统，网络等各种配套平全不同，在各种接口里，挑选出Web Service当接口模式是有原因的。就像上面提到的，Web Service是一种跨编程语言和跨操作系统平台的远程调用技术。不论什么操作系统、什么语言，Web Service都能很好地支持。下面就以用友ERP与IWMS做一个Web Service接口模块的介绍：
第一 入库下载物料编码、供应商信息、入库单据信息
用友ERP系统采用UNIX操作系统，Oracle数据库；集成化物流管理控制系统(iWMS)采用WINDOWS操作系统，SQL SERVER数据库。
当物料入库前，先从ERP系统下载物料编码、供应商信息等基础信息。通过物料编码接口和供应商信息接口两个Web Service接口，IWMS系统从ERP系统中得到了基础信息数据，这样就可以开始接受入库单据的信息了。
入库单据信息包含入库单据号、物料编码、批号、批次、供应商代码、计划入库数量、实际入库数量、规格等信息。
根据接受到ERP入库的单据信息进行相应的转换生成IWMS的入库单据。
第二 入库完成后回传入库单据实际数量
调用入库单据，对物料清点码盘后进行组盘入库，等该单据所有的物料全部入库完毕后，将入库单据的实际入库数量回传给ERP系统。
根据接口协议，回传的入库单据和ERP的原单据其他数据项一致，只有实际入库数量不一样。
第三 出库下载客户信息、出库单据信息
客户来提货前，先从ERP系统填写销售出库单据，出库单再传给IWMS系统。
出库单出库前，客户等基础信息要通过客户信息接口这个Web Service接口传递给IWMS系统，然后才可以接受出库单的信息了。
出库单据信息包含出库单据号、物料编码、批号、批次、客户代码、计划出库数量、实际出库数量、规格等信息。
根据接受到ERP出库的单据信息进行相应的转换生成IWMS的出库单据。
第四 出库完成后回传出库单据实际数量
调用出库单据，配货清点完毕，等该单据所有的物料全部出库装车后，将出库单据的实际出库数量回传给ERP系统。
根据接口协议，回传的出库单据和ERP的原单据其他数据项一致，只有实际出库数量不一样。
第四部分 结语
本文介绍了Web Service在物流管理控制系统与企业资源管理系统接口中的应用。
第7篇：soap协议范文
关键词:SOA;企业应用集成
中图分类号:TP311.133.1文献标识码:A
SOA&Enterprise Application Integration Design
Li Shu
(Sichuan Leshan Vocational&Technical College,Leshan614000,China)
Abstract:This paper describes enterprise application integration, and then analyzes the key technology of SOA and Web services,proposed SOA-based enterprise application integration solutions,this program flexible,loosely coupled nature,step by step integration,easily extensible.
Keywords:SOA;Enterprise application integration
一、企业应用集成
(一)企业应用集成的提出
企业应用集成(EAI)是指企业中和企业之间的任何相连的应用间无限制地共享数据和业务处理,从而使企业的整个业务、管理、资源等各个环节,达到协调运转,效率优化。从企业应用集成的具体应用范围来看,企业应用集成包括两方面:企业内部应用系统集成和企业之间的应用系统集成。EAI的模型如图1所示:
(二)企业应用集成的内容
企业应用集成的内容涉及到以下几个层面:
1.业务过程集成:当对业务过程进行集成的时候,企业必须在各种业务系统中定义、授权和管理各种业务信息的交换,以便改进操作、减少成本、提高响应速度。
2.应用集成:为两个应用中的数据和函数提供接近实时的集成。
3.数据集成:在集成之前,必须首先对数据进行标识并编成目录,另外还要确定元数据模型。这三步完成以后,数据才能在数据库系统中分布和共享。
4.集成的标准:集成的标准化促成了信息和业务数据的共享和分布,包括COM+/DCOM、CORBA、EDI、JavaRMI和XML。
5.平台集成:要实现系统的集成,底层的结构、软件、硬件以及异构网络的特殊需求都必须得到集成。
二、面向服务的体系结构
(一)SOA协作
面向服务的体系结构(service-oriented architecture SOA)是一个组件模型。面向服务的体系结构将应用程序中的不同功能单元称为服务,并通过对这些服务之间定义良好的接口而将其联系起来。接口是采用中立的方式进行定义的,也就是说它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。结构模型如图2所示。
三个角色是:
1.服务提供者:提供并自己的服务,并且对使用自身服务的请求进行响应;
2.服务注册中心:用来存储服务描述信息的信息库;
3.服务请求者:指查找和调用服务的客户端应用程序,利用服务(UDDI)查找所需的服务,然后使用该服务(绑定)。
(二)SOA的特点和优势
1.松散耦合
服务实现者可以更改服务中的接口、数据或者消息版本,而不对服务使用者造成影响。
2.基于行业标准
消除了使用特定标准而限制于服务使用者的需要。并且使用基于标准的技术可打破行业或技术平台的垄断并促进所有服务的最优组合。
3.可重用的服务
服务重用避免了重复开发之烦琐,同时提高了实现中的一致性。服务的重用比起组件或者类的重用更容易实现。
4.同步服务调用(RPC方式)
同步服务对于要求实时响应的应用程序来说是至关重要的,例如Portal 或者Query。
5.异步服务调用
在异步服务调用中,调用方向消息收发服务发送一个包含完全上下文的消息,收发服务将该消息传递给接收者。
三、基于SOA的企业应用集成(EAI)
(一)服务访问流程
通过基于SOA的企业应用集成框架实现的服务访问流程描述如下:
1.企业门户将用户对某个服务的请求传到后端支持服务总线的应用服务器,如IBM的WebSphere;
2.应用服务器通过UDDI查询Web Service公共目录或者经验证后访问Web Service私有目录,用得到的WSDL描述生成SOAP请求消息绑定服务提供者;
3.SOAP请求被传递到对应的SOAP路由器,由SOAP路由器将该请求传递到对应该服务的适配器;
4.适配器激活相关应用系统;
5.应用处理结果返回适配器,经适配器打包为包含处理结果的SOAP消息,返回给SOAP路由器,直至返回用户处。
(二)主要组成部分功能描述
1.企业内部Service Provider
企业内部Service Provider中包含已有应用或新开发的Web Service应用,它们均被封装为标准的Web Service组件,成为系统中的一个集成点。
对已有系统集成的关键在于对系统的封装和包裹,可以先利用WSDL生成器生成该服务对应的WSDL文件,然后生成服务器端基于SOAP的框架代码,在框架代码的基础上开发Web服务适配器,通过该服务适配器,将XML格式的请求转换为已有系统能解析的格式,同时,将已有系统处理后的结果转换为XML格式。服务适配器还具备与后端服务器建立通信连接,验证数据有效性等功能。
2.服务总线Service Bus
服务总线通过一个处于中间层的集中式服务器,为业务流程控制、服务路由、协议转换和安全扮演着中央控制点的角色。以下对服务总线上的几个关键功能作简要介绍:
(1)工作流控制:定义工作流程,并协调服务间的交互,己出现一些推荐的标准,如WSFL(Web Service Flow Language)等;
(2)事务管理:由于分布的,松耦合的应用环境不适于使用传统的事务技术,对此,IBM,微软和BEA联合提出WS-Transaction;
(3)安全映射:对所有参与服务进行统一管理,把安全性考虑隔离在单一构件上,简化开发和管理;
(4)服务监控:监控流程的执行,利用记录的数据来分析服务质量和指导服务改进;
(5)SOAP路由器:用以实现SOAP消息的传递,路由器通过分析,找出对应的Web Service适配器的位置,将SOAP请求传递到所请求的适配器;
(三)服务网关Service Gateway
对于企业外部集成,使用服务网关,一方面可以安全地对外公开Web服务,另一方面,防火墙之外的客户也能调用这些服务。它包括一个服务管理模型和过滤器。服务网关能够将客户端支持的服务协议转换为提供方支持的服务协议,如:客户的请求可能是HTTP上的SOAP,但在内部可以使用JMS协议上的SOAP。
(四)企业门户Enterprise Portal
终端用户界面集成特定用户访问的全部应用程序和服务来提供可用、高效、一致的界面。组合式Portal将Web服务通过Portal即插即用,使EAI更加灵活。
四、结束语
SOA为企业应用集成(EAI)提供了理想的集成框架,它是实现EAI的有力工具。基于SOA和消息中间件技术,可以在不改变应用系统原有底层架构的基础上实现灵活的、面向服务的应用集成,未来相信面向服务的EAI会在企业信息化的进程中得到更广泛的应用。
参考文献
[1]宋善德,王雪飞.基于Web服务的企业应用集成方案.计算机应用研究,2003,6,127-129.
[2]宋波,李妙妍.面向Web服务的BPEL的研究与实现.计算机工程与设计,2007,28(9).212-214.
[3]叶宇风.基于SOA的企业应用集成研究.微电子学与计算机,2006,23,(5).211-213.
[4]胡继东,刘广钟.基于Web Services的软件集成方法的研究与实现.计算机系统应用,2002,11,33-35
第8篇：soap协议范文
随着Web Services由技术概念到实践应用的不断发展，种种迹象表明，Web Services将是未来应用架构的一个极为重要的模式。
安全中间件是中间件的一种，为我们提供了CA认证、数字证书、数字签名等安全相关的通用编程抽象。应用程序人员不必拥有专业的安全知识，即可通过调用安全中间件的相关API方便地使用所需的安全功能，从而使开发人员能够专注于业务逻辑的开发。
目前，传统的基于PKI(Public Key Infrastructure)的安全中间件已经可以满足我们大部分的安全要求，但是这仍然是不够的，因为传统安全中间件基本上都是采用调用API的方式，从而直接导致了应用程序与安全中间件的紧耦合性、平台相关性与编程语言相关性。
基于Web Services的安全中间件的优势
具有松耦合性与跨平台跨编程语言正是Web Services技术的最大特性，下面将讨论传统安全中间件与基于Web Services的安全中间件的各自运作模式及他们的不同，并总结出基于Web Services的安全中间件的优势。
传统安全中间件产品一般以PKI为基础，建立在X.509等安全标准之上，为开发人员提供了加密、认证、授权、验证等安全接口。下面是传统安全中间件与基于Web Services的安全中间件的运作模式对比图：
由图1左边可以看出，应用程序是采用API调用方式使用安全中间件的，即传统安全中间件是作为函数库与应用程序部署在一起的，这些都使得应用程序与安全中间件之间产生了紧耦合，导致整个系统过于复杂而不好维护，丧失了灵活性。另外，安全算法是需要大规模计算的，对于计算资源宝贵的移动设备来说，以上并不是一个理想的解决方案。
采用Web Services技术的安全中间件，通过SOAP协议实现应用程序与安全中间件之间的通讯。如图1右边所示，在本设计中，应用程序与安全中间件之间的通讯采用了Web Services技术，通过SOAP协议进行通讯。同时，为了保证应用程序与安全中间件之间网络通讯的安全，本系统中采用SSL用于保证传输层上的点对点完整性和机密性，在应用层面上则是采用WS-Security规范保证SOAP消息的安全性。
在以上的对比分析中我们可以得知，在基于Web Services的安全中间件中，不管是J2EE或.Net编程技术，都可以通过标准的SOAP协议与安全中间件进行通信，实现了编程语言无关性。再者，由于Web Services技术是基于网络HTTP协议通过网络进行通信，从而去掉了应用程序与安全中间件需要部署在同一操作系统、服务器上的限制，进而实现了平台无关性。最后，假设日后安全中间件内部模块进行了更新升级，也不会影响到应用程序，无需再编译、再部署，从而实现了应用程序层与安全中间件层之间的松耦合性。
由此可得出基于Web Services的安全中间件的优势有：编程语言无关性，平台无关性与松耦合性。
基于Web Services的安全中间件的总体设计
本文将设计与实现一个基于Web Services的安全中间件，该安全中间件从理论上讲，能够实现传统安全中间件的所有功能，并且是基于SOAP通讯的，实现了松耦合及跨平台跨编程语言性。
本中间件的功能主要分成两大块――证书模块与密码模块。
证书模块：证书申请，即个人通过安全中间件向CA申请证书；查询证书，应用程序可以通过该功能查询自己或已收到的他人证书状态；获取证书，应用程序可通过安全中间件获取自己或他人的证书；撤销证书，在个人丢失私钥时，可以申请撤销证书；验证证书，可用于验证他人证书的有效性。
密码模块：加密解密消息，使用各种算法对消息进行加解密操作；生成会话密钥，为通信的双方生成会话密钥；数字签名，对消息进行数字签名；签名验证，可对已进行数字签名的消息进行验证其完整性和发送方身份。
总体框架：
基于Web Services的安全中间件的设计目标，是为了让所有类型的应用程序都能通过由WS-Security保护的SOAP协议来获取安全服务。本中间件总体框架如下图所示：
如图2所示，本系统采用分层的设计结构。最上层为服务接口，以Web Services的形式给应用程序，而不是传统的采用API或RPC远程调用接口，消除了应用程序层与安全服务层之间的耦合性，也使得应用程序与安全中间件无需部署在一起，大大提高了企业信息系统的整体灵活性。
安全中间件在接收到请求后对其进行解析，然后进行相应的操作并返回。在应用程序接口下面，是两个主要模块接口――证书服务与密码服务接口，设计这两个接口的目的是为了日后系统的扩展。
在两个接口的下面，是两个模块的具体实现，这里的具体实现有两种方式，一是使用各种成熟的组件直接实现服务，如Sun提供的JCE、JAAS及JSSE，微软的CryptAPI或Intel的CDSA等；二是通过统一的PKI接口调用现成的PKI设施，其好处是可以随以后需求的变更而灵活使用不同的PKI产品。PKI统一接口的下方PKI Provider xx是针对某一PKI产品所设计的专用转换接口，实现从特定PKI产品自身接口到本系统PKI统一接口的转换。
实现细节：
下面是本系统的服务接口设计，这里的服务接口是指本安全中间件开发给应用程序的服务接口。本系统的Web Service的实现采用AXIS2开源框架。下面将使用AXIS2的services.xml说明服务接口的设计，并结合使用SOAP消息格式进行详细说明。
如services.xml文件中申请证书的xml配置如下：
urn:applyCert
本文就传统安全中间件与基于Web Services的安全中间件进行探讨比较，进而总结出基于Web Services的安全中间件的优势之处在于松耦合、跨平台与跨编程语言。接着，提出基于Web Services的安全中间件的设计方案，并实现了上述三点优势。当然，本系统目前还存在一些不足之处，在完整性方面，目前仅实现了基本的安全服务功能；在标准性方面，目前采用的Web Services安全规范仍处于草案阶段而不是公认的标准；最后是实用性，本系统目前仍处于测试阶段，最终能否胜任安全强度的要求仍需进一步的考验。
参考文献
[1] JP Morgenthal. Web Services for Enterprise Application Integration. [A] Journal, 2002,2(5 ): 14 ~16
[2] 张志擦. 中间件技术. 北京:中国石化出版社，2002. 122~123
[3] 荆继武. PKI系统研究：[博士学位论文]. 北京:中国科学院研究生院，2002
[4] 张振兴. Web服务安全性的研究与实现：[D]. 华北电力大学硕士论文，2004
[5] 肖军模，刘军. 网络信息安全. 北京:机械工业出版社，2003. 23~24
[6] Markham T. Security at the network edge. Information Survivability Conference, 2001,11. 279~286
第9篇：soap协议范文
关键词： 区域医疗； 数据交互； 异构系统； 信息化建设
中图分类号： TN911?34 文献标识码： A 文章编号： 1004?373X（2014）02?0051?02
随着信息技术的飞速发展，各种管理信息系统已在医疗行业中得到广泛应用。同时，在新医改的推动下，建立数字化“医疗联合体”和“区域医疗平台”成为医疗信息化发展的必然趋势。但由于各个医疗部门的软硬件条件各异，部门、单位特点不同，势必造成多种关系数据库共存的局面。多种异构数据库的存在严重限制了数据共享和交互的范围。因此如何在保留原有成熟医院信息系统（Hospital Information System，HIS）的基础上，实现异构数据库间透明信息存取是首要解决的问题。
1 医疗信息系统现状
我国从20世纪90年代初逐步开始医疗信息化建设。目前各种医疗信息化系统已经开始部署到地方各级医疗机构，典型的系统包括：医院信息系统（Hospital Information System，HIS）、电子病历系统（Electronic Medical Records，EMR）、医学影像存档与通信系统（Picture Archiving and Communication System，PACS）、检验信息系统（Laboratory Information System，LIS）和超声信息系统（Ultrasound Information System，UIS）等。
为落实国家“十二五”深化医药卫生体制改革规划、物联网发展规划和电子政务发展规划，需要对卫生信息化建设及其应用提出新的要求。国家已从战略层面指出：根据当前医改对信息化发展形势的要求，“十二五”期间卫生信息化工作要在以区域卫生信息化建设为重点的互联互通和资源共享方面有所作为[1]。区域卫生信息化建设发展的一个必然阶段便是区域卫生信息化中的数据交互建设，这是区域卫生信息化建设中最重要的课题。数据交互的实现，能够满足政府更高效、更灵活、协同性更好的实现对医疗卫生的管理，帮助医疗卫生单位实现大量信息快速、有效、准确地获取、管理和传递，改进工作流程，提高工作效率。
由于国内医疗信息化建设水平参差不齐，且无统一的标准。不同的信息系统开发商在设计、实现过程中所采用的系统架构、技术方法、开发平台千差万别，势必出现不同医疗机构间相同业务类型的数据存储定义、语义表达方式不同。这些不同，形成了无数个孤立的信息系统，导致患者就诊时医生无法在第一时间内准确了解疾病史、药物治疗史、过敏史和前期检查结果等，降低诊疗效率和诊疗质量，增多患者重复检查的次数，提高诊疗成本，加重患者经济负担。 构建异构医疗数据交互平台是实现区域卫生信息化的核心环节。通过外挂中间件的方式，对医院已有的HIS不做改动的前提下，在系统间高效、安全的传输和处理基于相关医疗信息标准的医疗信息。
2 系统设计
为了异构医疗数据间的交互，首先必须建立稳定可靠的系统架构。如图1所示，该系统架构在保留原HIS和数据库的基础上通过外挂中间件的方式交互数据。当某医院有申请数据的需要时，通过HTTP请求以XML格式表示的有效数据。发送方通过数据访问模块从源数据库中提取数据，然后基于HL7的医疗信息标准进行数据转换，以WS?Security的安全机制实现SOAP消息的安全传递，保证医疗数据标准、安全、有效的传输给数据申请方。
3 关键技术
在整个异构医疗数据交互系统架构中，数据的转换、表现形式以及数据的传输安全是最核心的技术。
（1） 基于HL7的数据转换模型。医疗信息传输与交换技术标准（Healthy Level Seven，HL7）是医学信息系统应用和执行的标准，是基于消息实现数据传递的标准规范[2]，多个HIS之间进行数据的交互都是以HL7为标准的。在HL7标准中，若干个字段构成一个消息段，有一定顺序和逻辑关系的消息段构成一条消息，当某事件发生时将消息按照一定的网络传输协议传送到接收方，接收方在消息的接收、解析之后将其送往应用程序。相比于之前版本，HL7 v3版一个显著的特点就是支持可扩展标记语言，运用XML技术来加强和改善医疗系统之间的数据交换能力。
（2） 可扩展标记语言XML。XML（eXtensible Markup Language）是针对包含结构化信息的文档而设计的一种标记语言。在本系统的研发中通过以XML格式表示和传输以HL7标准建立的共享数据信息。考虑到HIS数据的复杂性，它需要在数据类型、主外键值、数据完整性约束等方面的定义，使用XML schema定义XML文档数据交换格式的标准[3]。
（3） 基于WebService和SOAP协议的异构数据源交互模型。SOAP 调用的数据和方法的表达方式是基于 XML 的、可以使数据的型和值在表达上分离， 有利于应用程序之间透明交换信息， 同时可以解决网络传输安全性问题[4]。本研究采用WebService和SOAP协议建立异构数据源交互模型，如图2所示。该模型采用XML作为数据描述语言，转换时首先通过数据交换中间件把各种异构的输入/输出数据按照描述逻辑转换为统一规则的XML文件，然后通过SOAP传输协议在各异构系统之间的Internet网络之间进行传输，最后再通过数据交换中间件完成数据转换。
（4） 异构系统安全策略。采用基于WS?Security的安全机制实现SOAP消息的安全传递，其中对XML元素加密算法由WS?Security规范提供，这种加密算法满足了消息级安全的需要[5]。同时，采用基于X.509证书的PKI技术实现对SOAP消息进行加密、解密和签名、认证，最终实现安全的SOAP消息调用。
4 结 语
本文结合HL7 V3版本的特点和XML技术的优势，提出在保留原HIS和数据库的基础上，采用外挂中间件的方式实现异构医疗数据交互的策略，构建了数据交互的系统架构，并阐述了关键技术解决方案，对实现区域卫生信息化建设环境下的医疗数据交互提供了一个切实可行的方案。
参考文献
[1] 佚名.攻坚医改难题勇担发展重任：2012年医疗卫生信息化发展与未来展望[J].中国信息界，2012（12）：40?45.
[2] Anon. HL7 version 2： health informatics [M]. [S.l.]： [s.n.]， 2010： 107?128.
[3] AHMED K Z，UMRYSH C E.用J2EE和UML开发企业级应用程序[M].康博，译，北京：清华大学出版社，2002.
[4] 徐汉川，胡润波，刘国忠.基于XML/SOAP数据交换中间件的设计[J].哈尔滨商业大学学报：自然科学版，2004，20（6）：665?670.
[5] 蔡小芳，张永胜.在Web服务安全中XML加密与签名的应用[J].计算机安全，2006（7）：20?23.