接口服务（精选10篇）
接口服务 篇1
本文重点介绍面向服务的接口的详细过程, 在开发服务之前, 我们需要定义良好的服务接口。对设计Web服务而言, 这是对通常所接受“WSDL优先”方法的支持。也是我们这章要描述的服务设计过程的基础。对创建高度标准化的面向服务架构而言, 在开发前先定义服务接口十分重要, 并且也是我们所识别的当代SOA的诸多特征所要求的。
特别是, 在服务逻辑之前先创建服务契约会带来下列好处:
· 能够将服务设计成能精确表达服务候选的语境和功能。
· 服务的操作名称使用约定, 将使端点定义标准化。
· 可将操作粒度建模成提供一致性和可预知的接口设计。
· 要求底层应用遵照服务设计来表示。
· 业务分析师能进行业务服务的设计。
本文以Student服务的设计步骤, 初步的要求是能够执行一个查询以获得他的学籍基本信息和宿舍信息, 通过赋予以下两个操作候选来表达这两个功能:GetStudentDetailInfo。
GetStudentDormInfo
1 第一步:审查现存服务并定义实体Schema
设计新服务的第一步是确认它是否是必须的, 如果其他服务存在, 它们也许已经提供了在操作候选中识别出的部分或者全部功能;或者它们已经建立了适当的语境, 通过它能够实现这些新操作。
SOAP消息在其封装的Body部分携带了有效负载数据。需要对该数据进行组织和分类, 我们依靠XSD schema可以完成这一操作。实际上一个单独的schema可以嵌入到type结构中, 在那里可以定义每个表示SOAP消息体的数据元素。
对于该Student服务从需要识别的数据着手, 这些类别的数据将履行“学籍基本信息”的处理需求。以定义两个复杂类型结束:一个包含Student服务接收的请求消息所要求的搜索准则, 另一个包括服务返回的查询结果。有意识的命名类型, 使类型与各自的消息相关联。这两个类型组成了新的StudentInfo.xsd.schema文件。如下:
但是我们发现从StudentInfo.xsd.文件中派生出的schema并不包括宿舍信息, 该信息是不在学生信息采集系统中的, 而是在宿舍管理系统中, 于是我们使用不同的targetNamespace来识别截然不同的起源, 命名为StudentDorm的schema。
为了提高可复用性, 并且允许单独维护WSDL的每个schema文件, 将 XSD schema语句 import 用于把两个 schemas的内容放到Student服务 的WSDL文件的 types 结构中。
2 第二步:派生抽象接口
接下来, 我们将分析服务的候选操作, 并且遵照下列步骤来定义初始的服务接口。
(1) 确认每个操作候选是恰当的, 并且通过合理的逻辑封装粒度来保证重用。
(2) 在WSDL文件中创建portTpye域, 并用候选操作的operation结构来展开它。
(3) 列出每个操作的逻辑处理所需要的输入和输出值。这可以通过引用子集part 元素中的XSD Schema 类型, 定义合适的message结构来完成。
决定使用GetStudentDetailInfo () 和GetStudentDormInfo () 两个操作。
随后进入抽象定义的剩余部分, 以下就是定义了message和portTpye结构后的结果:
3 第三步:应用面向服务原则
根据本文前面分析的对于Web Service没有提供的4条面向服务的原则来进行分析:
服务可复用性;
服务自治;
服务无状态;
服务可发现性。
可复用性会在第四步进一步推广, 第四步可将设计扩展到更容易的需求。
由于以实体为中心的服务经常要求组合成服务层, 而且他们依赖应用服务层来执行某些业务逻辑, 所以他们的即时自治通常都定义的良好。
同样, 无状态也是相对可管理的, 以实体为核心的服务一般并不拥有大量的工作流逻辑, 并且那些要通过调用多个应用来执行操作的情况, 首选的是延期状态管理。
可发现性是以实体为核心的服务设计和后续部署需要利用的重要部分, 正如第一步中所述, 我们必须确保设计的服务并不是重复已存在的逻辑, 发现机制会使这个决定更加简单。同样, 我们可以采用documentation元素的元数据细节来使其更容易被发现。
在审查了初始的抽象服务接口后, 可以确定结合少量修改就能够更好地支持基本的面向服务、。特别是, 将元消息增加到WSDL定义中, 这样能更好地描述两个操作及其相关消息的目的与功能。
以下是用额外的元数据文件来补充服务接口的结果:
4 第四步:标准化和简化服务接口及其扩展服务设计
调整抽象服务接口, 特别是将命名约定结合到标准化的操作名称中去, 使用命名标准对内在互操作性提供了本地支持, 这是当代SOA的关键特性。
以下是具有新的标准化名称的两个operation结构:
本步骤包含执行一个推理分析, 在它预定义的功能语境中应该为这个服务提供哪些其他类型的特性。实现新功能一般有两种方法:填加新操作和在现存操作中填加新参数, 虽然后一种方法可能更有效的简化服务接口, 但它可能会违背直觉, 因为太多的参数与操作相关, 可能要求服务请求者了解房屋的众多内容以便有效利用它。所以填加操作是提供与实体相关的明显功能最直接的方式, 以实体为核心的服务的一组经典操作是:
GetSomething
UpdateSomethng
AddSomething
DeletSomething
标准操作在业务服务层构建了一致的互操作水平, 促进了可复用性, 但是不要为了潜在的可复用性使操作过度复杂化。
为此对于本服务我们分析能够增加到Student服务的几类操作如下:
GetDetailInfo
GetDormInfo
UpdateDormInfo
下面示例显示了portType结构如何扩展补充操作的。
5 小结
本文给出了一个具有指导意义的服务的设计步骤与过程, 并在设计过程中应用设计服务的指导原则, 比如使用命名标准, 注重于可扩展性, 识别当前和未来的服务请求者, 使用模块化WSDL, 以及使用原数据说明服务。通过本章的分析, 我们可以看到, 把以实体为核心的业务服务设计为精确表示现存业务的实体, 而保存业务的处理不可知。这其中可能需要一些推理分析, 以便用所需范围的通用操作适当地以配备以实体为核心的业务服务。
参考文献
[1]朱振杰.SOA的关键技术的研究与应用实现[J].电子科技大学硕士文, 2006.
[2]Mark Endrei, Jenny Ang, Ali Arsanjani, et a1.Patterns:Service Oriented Architecture and Web Services.IBMIn.temational Technical Support Organization, April 2004.
[3]Mark colan.Service-Oriented Architecture expands the visionof Web Service http://www-128.ibm.com/developer-works/webservices/library/ws-soaintro.html, 2004.
[4] (美) 伊尔著, 王满红, 陈荣华, 译.SOA概念、技术与设计[M].北京:机械工业出版, 社2007-1.
接口服务 篇2
车站客运服务信息系统包括客票系统、旅客服务信息系统、行包信息系统、门禁系统、综合布线等系统，其中旅客服务信息系统包括车站级集成管理平台、客运广播系统、综合显示系统、视频监控系统、时钟系统、旅客携带物品安全检查设备、信息查询系统、入侵报警系统、求助系统及客运作业管理系统等。
2.2系统设置简况
(1)客票系统
客票系统主要采用中心、区域、车站三级架构。铁路总公司客票中心主要负责全路票务管理、售票交易、电子支付、列车服务及营销决策等服务，地区客票中心主要负责客票核心数据处理、交易、共享、管理、客运营销辅助决策、系统监控、自动售检票等服务，车站主要负责售票的实时交易服务。通过全国快速便捷的超大型售票网络，目前全国日均售票量达400余万，峰值售票量已达800万。下面主要介绍下车站客票系统。
车站客票系统主要包括应急服务器、管理终端、窗口售票设备、自动售票机、自动取票机、自动检票机、补票机、实名制验证/复位和客票安全等设备。通过这些设备可以为旅客提供从购票、取票、进站、检票到出站的全过程、多元化的出行服务，方便旅客的同时也提升了车站运营管理能力。如下图所示：
(2)旅客服务信息系统
旅客服务信息系统可采用中心、区域、车站三级架构，或采用中心、车站两级架构，也可采用车站单级架构。现代高速铁路多采用中心、区域、车站三级架构。车站旅客服务信息系统包括车站级集成管理平台、客运广播、综合显示、视频监控、时钟、旅客携带物品安全检查设备、信息查询、入侵报警、求助及客运作业管理等系统。各子系统覆盖了旅客购票、进站、候车、上车、下车、出站、接站等一系列服务。如下图所示：
手势识别接口 篇3
斯庞特在以色列特拉维夫的PrimeSense公司花了五年时间来研发这一系统，微软出资扶持了这一技术并将其用在自己的Xbox360游戏机的Kinect控制器上。玩家可以用它控制克隆小人来直接表达自己的身体姿态——无需手柄、摇杆、手套或前代手势接口用来探知使用者运动的彩色连接标签。
淘汰掉这些游戏道具的关键是让电脑能以三维立体的方式观察世界，而不仅仅是两个以普通方式工作的相机。感知空间的深度让计算机易于分辨从背景中伸出的一只手臂，并跟踪手臂的移动。
斯庞特回忆起当他开始启动这个研发项目时，只有少数几种办法感知环境深度——主要是靠“飞行时间”(从传感器发出光线或声音，侦测其遇到物体返回所需的时间，以此计算距离)与“结构光”(向物体上投射有图案的光线分析图案如何被物体表面所改变)。尽管有大量的学术研究，也有一些公司建立了原型，但“没有任何真正成熟的东西”能够批量生产的，斯庞特说。相反的，他建起了自己的系统，把上述两种技术结合在一起，同时也运用立体观测——从两个不同的视角对同一个图景中的图像进行比较。
Kinect仅仅是一个开始，斯庞特相信接下来会有一场手势识别接口的革命。PrimeSense公司鼓励骇客们改造Kinect，将其用在其他的终端上。路易斯安那州立大学的研究者们已经用Kinect组件与一台上市销售的3D电视，完成了一个无需头盔与手套的虚拟实景装置。在澳大利亚，一个物流软件公司行动迅速地将手势识别控制器用于了空中交通监视。很容易想到会有更多现实世界的手势接口的应用出现。斯庞特说，视线跟踪的头戴式控制器可用于自动驾驶，非接触式接口显示屏则可用于商场和机场。
现在，斯庞特在与电脑制造商华硕合作，为今日愈加复杂且愈加网络化的电视制作手势控制系统一本质上来说，是将电视变成一个巨大的iPad，你可以坐在沙发上操作它，却不用遥控器。
接口服务 篇4
1 主要做法
1.1确定方案, 确保接口服务管理工作有序开展。制定《涪陵区市级统筹接口服务选择实施方案》, 统一思想, 切实加强接口管理的组织领导, 明确具体实施步骤。运用市场规则, 降低辖区内接口服务运行成本, 建立正确组织全区定点机构选择市级统筹接口服务的框架。以掌握网络信息系统信息数据的主动权为原则, 加强对接口服务商服务数量、质量和服务态度的监控, 突显“网络信息系统正常运行”的主题。
1.2掌握主动, 建立市级统筹统一接口服务商进入和退出机制。居民医保实行市级统筹后, 和职工医保使用统一接口, 实现“一台前置机、一套接口系统和一条医保专线”分别结算。鉴于全区绝大多数定点机构专业技术人员缺乏, 与接口商单独谈判处于弱势, 接口服务商费用收取随意性大的现状, 区医保中心作为联系定点机构和接口服务商的桥梁, 勇于承担责任, 拟订接口服务商进入、竞争竞价和退出的机制, 强化接口服务商服务数量、质量和服务态度的监管, 确保辖区内定点机构医保接口系统正常运行。
1.3精确测算, 多次集中约谈, 协商拟定接口服务费收取标准。为平衡商业运作关系, 形成相互制约机制, 运用市场规则, 降低辖区内定点机构医保接口运行成本, 以市统一接口服务收费指导价为指导, 测算服务费用, 对比周边区县收费情况, 在掌握多家接口服务商情况的基础上, 多次集中约谈东软、万达、银海三家接口服务商, 协商全区接口服务费收取标准。在自愿的前提下, 三家接口服务商均在市指导价以下, 重新拟定了适合全区的收费标准。
1.4透明公开, 公平竞争, 自由竞价, 自主签约选择接口服务商。采取的主要措施, 一是及时在网上公布与接口服务商集中约谈协商的最新进展情况, 让定点机构吃下定心丸;二是召开定点机构选择接口服务商工作会, 首先由三家公司分别介绍自己接口软件的优势和服务特色, 公开收费价格和服务承诺, 然后由定点机构根据自身情况与接口服务商面商价格, 自主选择接口服务商, 并于会后及时签订服务协议。据统计, 最终选择情况为东软公司274家 (定点医疗机构72家、定点药店202家) , 万达公司398家 (定点医疗机构23家、村卫生室375家) , 银海公司50家 (全为定点药店) 。
1.5强化考核, 提升统一接口服务质量。为加强对统一接口服务商网络信息系统服务质量的考核, 提升统一接口服务质量, 坚持实事求是、客观公正、定性与定量相结合, 医保经办机构、两定机构和服务商共同参与, 在全市率先制定《医保统一接口维护协议》和《医保统一接口服务考核实施办法》, 建立《医保接口监督投诉台账》, 公布投诉电话, 确保全区两定机构医保实时结算业务的正常开展, 保障参保人员及时有效享受医保待遇。
1.6加强评议, 考核支付接口服务费用。根据定点机构推荐情况, 成立由公立、民营医院和零售药店代表组成的接口服务监督考评工作组, 全程参与集中约谈、服务协议审定、接口安装实施、接口服务监督考评等环节, 认真听取各界人士意见, 并制定对接口服务商的监督考核办法。费用支付方式采取在区医保中心设置过渡账户, 汇集全区定点机构接口服务费, 在年初支付80%给接口服务商, 20%在年底时由监督考评工作组组织考核并根据年度考核结果再统一支付给接口服务商。
2 初步效果
通过以上措施, 涪陵区医保统一接口服务工作得到有效规范, 形成了协商式、透明化、考核制的工作机制, 实现了服务收费标准透明公开化, 接口商竞争公平公正化, 定点机构签约选择自主面商化, 服务质量监督考评客观公正化;服务费在市最高限价的基础上大幅降低, 全区2013年服务费总额由测算的100万元左右降至57万元, 总降幅达43%, 定点机构得到了实惠;掌握了主动, 在保证接口服务商和定点机构平等签约的同时, 改变了过去由医保中心包揽的作法, 实现了医保中心得社会效益、定点机构得服务效益、接口服务商得经济效益、老百姓得就医实惠的共赢局面;医保接口服务质量和效率得到体制保障, 考评小组的成立既体现了医保中心在接口服务中的监管和桥梁作用, 又调动了定点机构的积极性, 保障了其切身利益。
摘要：涪陵区医保中心为做好医保市级统一接口服务工作, 在重庆市首推协商式、透明化、考核制的管理机制, 通过精确测算、集中约谈、公开竞争、自由竞价、监督评议、考核付费等方式, 积极组织辖区定点机构合理选择医保统一接口服务商, 实现供、需、管三方共赢。
关键词：医疗保险,定点机构,接口服务
参考文献
[1]重庆市人力资源社会保障局.关于做好社会保险定点医疗机构和药店统一接口实施工作的通知 (渝人社发[2012]238号) [Z].2012.
[2]重庆市人力资源社会保障局.关于做好金保工程二期业务外网建设工作的通知 (渝人社发[2012]229号) [Z].2012.
接口服务 篇5
王晖
摘要关键词简单介绍USB接口的特点和Philips公司的USB接口芯片ISP1581;详细介绍USB接口的硬件原理设计、固件开发流程及USB设备的调试。
USB
ISP158
1固件
枚举
微控制器接口
DMA 引
言
通用串行总线USB(Universal Serial Bu s是近年来应用在PC领域的新型接口技术;是一些大PC厂商,如Microsoft、Int el等,为了解决日益增加的PC外设与有限的主板插槽和端口之间的矛盾,而制定的一种串行通信的标准。USB以其高速、易于安装配置、使用灵活和可靠性高而日益受到人们的欢迎。现在已广泛使用于计算机和周边设备的连接,如键盘、鼠标、打印机、存储设备等。
USB控制器一般有两种类型:一种是MCU集成在芯片里面;另一种是纯粹的USB接口芯片,仅处理 USB 通信。前者由于开发时需要单独的开发系统,因此开发成本较高;后者只是一个芯片与MCU接口,实现USB 通信功能,因此成本较低、可靠性较高。本文主要介绍Philips公司的ISP1581器件的使用方法,它属于后者。1硬件设计
1.1I S P1581芯片特点
ISP1581 是一个高速USB 器件控制器。它实现了USB 2.0/1.1 物理层和数据协议
层的任务,并且实现了
连同端点EP0(设置用于 访问设置缓冲器在内的 16 个USB 端点的共同协 作;用于基于微控制器 的系统,与微控制器/微 处理器的通信是通过一 个高速的通用并行接口 实现的,接口速度可达 12.5M字节/s或12.5 M字/s;支持DMA传输, 可很好地实现与大容量
存储设备的接口;通过ATA/A TAPI接口,可以直接与ATA/A TAPI设备相连。ISP1581能适应大多数设备类规范的设计,非常适合做很多外围设备,如打印机、扫描仪、外部大容量存储器和数码相机等的外部接口。(注: ATA/A TAPI,Advanced Technology Attachmen t/Advanced Technology Attachment Peripheral Int erface。中文名称为高级技术附加装置/高级技术附加装置外围接口。ATA是一种硬盘接口标准,ATA标准的接口类型其实就是IDE 接口类型。
1.2I S P1581内部模块功能描述
ISP1581内集成了多个模块,各自完成不同功能,如图1所示。
① USB2.0收发器。模拟收发器通过集成的终端电阻直接与USB电缆相连。
② Philips串行接口引擎(SIE,Serial Interface Engine。完成所有USB协议层的功能,主要完成以下的功能:同步方式的识别、并行/串行的转换,位填充/解除填充、CRC校验/产生、包标识(PID校验/产生、地址识别和握手评估/产生。考虑到速度,它是全硬件的,不需要
DREQ,DACK CS0,CS1, [16:0] DS/WR 图
1ISP1581内部结构方框图
固件介入。
③ 存储器管理单元(M M U和集成RA M。MMU 和集成RAM 实现了USB 总线和微控制器管理器或DMA 管理器之间的速度转换。
④ 微控制器/处理器接口和微控制器/处理器的管理器。可以直接与大部分微控制器相连。
⑤ DMA 接口和DMA 管理器。DM A 管理器接收到DMA 命令后,可直接把数据从内部RAM 传送到外部DM A 设备或从外部DM A 设备传送给内部RAM。
2硬件连接
ISP1581 有一个快速通用接口,利用它可以实现与大
部分类型的微控制器/处理器的通信。上电时,由引脚BUS_CONF、MODE1 和MODE0 共同设置。由于MMC2107的外部地址、数据总线是分开的,因此在本开发平台上ISP1581只能工作在通用处理器工作模式下,设置方式如表1所列。
ISP1581提供微控制器接口与微控制器进行数据传输,也支持DMA 传输。在微控制器速度较高时,两者的读写访问速度均可达12.5M b/s ,采用DMA 方式会增加电路设计的复杂度。经过综合比较,采取微控制器接口方式。USB 模块硬件连接原理如图2所示。
注:①ISP1581提供两种复位方式:a.ISP1581集成有上电复位电路(POR, RESET 引脚接电源,实现上电复位功能。b.RESET 引脚接MMC2107的一个数字I/O 引脚，将该引脚置低800μs 后置高,实现复位。②ISP1581 的供电电压为3.3V 或5.0V ,I/O 引脚最大能承受5.0V 的电压。根据I/O 口的电压,从3.3V 和5.0V 中选择一个作为供电电压。
3I S P 1581固件(F I R E W A R E 程序设计 由于所有的通信都是由主机发起,设备只能响应来
自主机的命令。在这种结构下,ISP1581的固件采取中断驱动。这样一方面保证了快速的数据传输和较好的软
件结构,另一方面简化了编程和测试。
固件程序由5部分组成,如图3所示。(1主循环流程
上电后,初始化MMC2107和ISP1581。然后,主循环程序轮询检查事件标志,进入相应的子程序进行进一步的处理。图4是主循环的流程。
表
1设置工作方式
注:这里使用16位总线,AD[0]必须与ISP1581的地端相连。图
3固件结构和数据流向 图
4USB主循环程序
图
2MMC2107与ISP1581硬件连接原理
(2中断服务程序(ISR流程
图5所示的中断服务流程,用来处理由ISP1581产生的中断。通过访问ISP1581的中断寄存器,建立正确的事件标志,以通知主循环程序进行处理。(3USB 标准请求处理
进行应用通信以前,主机必须枚举设备。该过程是通过给端点0发送包含标准设备请求(CHA P_9的控制传
输实现的。USB 标准请求流程(见图6译码设备请求类型,转到相应的处理子流程。枚举过程如下: ①主机使用默认地址(地址0读取设备描述符G etDeviceDescriptor;② SetAddress;③ 连续3次G etDev iceDescriptor ,读取全部设备描述符;④ G etConfigDescriptor;
⑤ G etStringDescriptor(可能没有;⑥ 读取全部ConfigDescriptor 后,主机将找到新设备,提示安装驱动程序。⑦ 在设备能通信前,主机给出SetConfiguration 请求,设备收到后调整有关信息,使设备能被客户软件利用。(4厂商请求处理(VENDOR 厂商请求和USB 标准请求一样,都根据控制传输的内容进行相应处理。本开发平台的固件程序中定义了两个厂商请求,分别为取得固件版本和将批量数据写入设备或从设备中读出数据。
取得固件版本流程如图7所示。主机发送批量数据读写请求时,在控制传输的数据阶段,主机给出需要传输的数据字节数、数据传输方向、页索引和数据定位。控制传输结束后,主机和设备就可以根据双
方约定,启动批量传输。批量传输流程如图8所示。调
试 4.1 调试步骤
USB 的调试可分为以下几个步骤: ① 若USB 芯片正常工作,可实现软连接,将设备插 入主机后,主机上出现“未知设备类型”的USB 设备;② 提供描述符,提供正确的VID 和PID 后,主机能够识别设备,但要求提供设备的驱动程序;③ 安装驱动程序后,调试各端点,使其均可传输数据,用主机端的测试程序对其进行测试,验证硬件及固件的正确性。
中断服务程序
图
5中断服务程序流程 图6
USB标准设备请求流程 取得固件版本
图7
取得固件版本流程 图8
批量传送流程
4.2调试工具
因为每一次USB的传输过程,都有时效要求,等待时间过长,通信过程也就中止了,因此不适合用硬件仿真器来设断点调试。可采用串口辅助调试过程,即在固件代码中加入类似于Printf的语句,向串口输出一些信息。借此,可以知道程序是否运行到此处,以及运行到此处时相应的变量或寄存器值。
设备完成配置后,在Bus Hou nd中可看到该设备(bus Hound是一种应用软件。选择该设备,就可以对主机与此设备间的通信数据进行分析和监视。Bus Hound 工作在主机端,串口工作在微控制器端。将串口调试和Bus Hound两种手段配合使用,可以使USB通讯过程的调试更加容易。
在调试USB设备时,还可使用UsbView程序。在该程序中可以查看设备描述符、配置描述符和端点描述符是否正确。
接口服务 篇6
关键词：百度地图API,JavaScript接口,人社自助服务一体机
百度地图API的开放, 各网站、APP可以将百度地图嵌入自己的系统中, 与自身应用功能相结合, 提供更加丰富的人机交互形式, 并提升用户的体验度。主要介绍如何利用百度地图的Java Script接口嵌入自助服务一体机网站, 以实现自助机地图分布与定位功能。
1 数据库以及接口的建立
1.1 建立自助服务一体机的布点 GPS 数据库这里以 Oracle11G 数据库为基础进行建表:
1.2 生成百度地图 Java Script 需要的 JSON 格式数据包
这里使用PHP来进行代码编写, 首先建立一个数据库类Db.php, 内容如下 :
1.3 编写一个将布点与坐标数据转换成 Json 数据格式的程序Get Json.php
代码如下:
执行结果如下:
2 关键实现代码
2.1 将坐标点信息标注到地图的代码
以上的代码主要基于百度地图的Java Script接口的来实现将数据库中的坐标标注在地图中, 并实现点击相应的标点显示点上具体信息, 如图1所示。
2.2 自动定位并显示对话窗口
用户点击左侧布点列表时自动定位到地图中的相应位置,并显示对话窗口。下面的代码将左侧列表中的<a>标签进行了点击事件的绑定, 用于实现点击列表项定位到地图中相应标注点的功能。
其中list_item是列表所在的DIV的ID名称。
3 运行效果
运行效果如图2所示。
4 结语
接口服务 篇7
随着移动通信技术和网络应用的迅猛发展,以短消息为核心的增值业务因其广阔的市场前景和巨大的商业价值而备受人们的青睐[1]。应用提供商可以用OSA (Open Service Access)提供的API对网络资源进行控制和利用,从而达到生成新业务的目的[2]。目前,短信网关方式是应用提供商和手机用户信息互动最流行的途径,即通过Web浏览器,应用提供商连接到服务提供商SP(Service Provider)短信息网关,SP短信息网关连接到短信息中心,然后由短信业务中心最终将短信息发送给手机用户[3]。B/S结构的Web应用由于其先进的开发技术、优越的可管理性和易维护性、可扩展性,以及简单方便的应用模式而成为目前最流行的应用方式,因此基于Web服务器的B/S服务机制成为短信服务器开发的热点[4]。
作为短信息交互频繁的短信服务器接口,系统和信息的安全性必须得到足够的重视[5]。对于传输短信息数据的接口而言,其安全性是指系统资源不受外部非法的侵入、盗用、欺骗;信息资源不受非系统授权的伪造、篡改、泄露等。采用B/S结构的短信服务器接口充分发挥了服务器的强大作用,但是由于B/S结构的Web浏览器传输的是HTML文本文件,信息安全性受影响,短信息面临易丢失、被篡改或被盗取等,极大影响了短信息的交互[6]。
在这种背景下,本文设计了基于JSP技术B/S架构的短信服务器接口,并且采用MD5数字签名技术,保证了短信息的完整性;采用防重放攻击技术,保证系统免受外界攻击;采用IP验证技术,确保短信息来源的可靠性。
1 短信服务器接口介绍
短信服务器接口主要实现OTA(Over The Air)应用下载服务器和短消息网关之间短信息数据的交互,它由一个接收进程接收短消息,主要完成网关之间的数据接收;由另一个发送进程负责发送短消息,主要完成网关之间数据发送。短信息上行时,SP调用其发送进程,通过应用提供商提供的接收短信息接口,将用户上行的短信息发送给应用提供商,应用提供商接收短信息页面做一系列的安全验证处理,对于通过安全验证的短信息数据则存储到应用提供商的数据库中。应用提供商根据用户的需求,从业务数据库中提取对应的业务内容,调用发送进程,通过SP提供的接收短信息接口将下行的短信息传送到SP服务提供商的服务器,SP最终将短信发送给手机用户。短信服务器接口框图如图1所示。
2 短信服务器接口安全性设计
2.1 短信服务器接口开发环境
本接口采用目前商业上广泛应用的JSP技术作为短信服务器接口开发语言。JSP是基于Java Servlet以及整个Java体系的Web开发技术,所有的页面都被编译成为Java Servlet。因此,JSP页面拥有Java技术的所有优点,包括健壮的存储管理和良好的安全性,并且拥有Java编程语言“一次编写,到处运行”的优点。相对于其他Web编程语言,如PHP、ASP,它的编译操作仅在JSP页面的第一次请求时发生,因此执行效率比PHP和ASP高。另外,相对于其他脚本语言,JSP的技术结构具有这样的优势:它可以通过JavaBean技术实现内容的产生和显示相分离,并且JSP可以使用JavaBean或者EJB (Enterprise JavaBean)来执行应用程序所要求的更为复杂的处理,进而完成大型的分布式应用。
本接口采用B/S体系结构,采用出色的开放源代码的Tomcat服务器作为Web服务器,SQL Server 2000作为后台数据库,利用JDBC访问机制对后台数据库进行访问,使用JSP+JavaBean技术进行Web应用程序的开发,充分利用了Java技术的优势,使得系统高效、稳定。
2.2 短信息接收进程的安全性设计
短信息接收发生在两个阶段,用户上行短信息时,应用提供商从SP接口中获取数据;应用提供商下行短信息给手机用户时,SP从应用提供商接口中接收短信息数据。正确、完整的短信息是应用提供商和手机用户交互的重要依据。因此,在接收短信息进程中,采用了一系列措施来加强短信息在交互传输中的安全性。图2是接收短信息模块的流程图。
接收的短信息经过安全验证后,验证通过则直接存储到数据库中,并将处理的结果打印在页面上;对于安全验证不通过的短信息则只给发送方返回出错状态以便其在数据库中对短信息做相应的处理。其中安全验证包括数字签名验证、防重放攻击验证、IP验证。
2.2.1 短信息数字签名验证
MD5(信息一摘要算法)是一种应用广泛的提取数字指纹的算法。它的作用是让大容量信息在用数字签名软件签署私人密钥前被“压缩”成一种保密的格式,即把一个任意长度的字节串转换成长度一定的整数。
MD5的典型应用是对一段信息产生信息摘要,以防止信息被篡改。MD5将传入的信息通过其不可逆的字符串变换算法,产生惟一的MD5信息摘要。在本接口中传递短信息之前,对短信息通过MD5运算,得到一个惟一的摘要。这种做法可以防止短信息内容在传输过程中被恶意篡改,保证信息传输的安全性。
在JDK中,类java.security.MessageDigest中已经定义了MD5数字签名算法,所以只需要简单地调用即可得到MD5的128位整数,然后将此128位转换成16进制表示即可。
短信息上行时,SP短信息网关利用MD5算法对ID+Phone_number+Up_message+Md5_key(以下简称Up_message)的组合进行数字签名,即MD5(Up_message),其中ID是指业务的编号;Phone_number是用户手机号码;Up_message是指用户上行的短信内容,Md5_key是签名密钥。将得到的结果放到接口的签名参数Sign_result中传送。应用提供商根据对方接口中传输的参数值,同样对Up_message进行MD5运算,如果得到的摘要与SP短信网关传送的Sign_result结果一致,则表明短信息在传输过程中没有被修改,签名正确,否则将给SP短信网关返回“签名错误”标记。
2.2.2 防重放攻击验证
重放攻击也称为新鲜性攻击,即攻击者通过重放消息或消息片段达到对主体进行欺骗的攻击行为,主要目的在于破坏认证的正确性。重放攻击是攻击行为中危害较为严重的一种。在许多情况下,攻击者不需要篡改任何信息,他只需要发送一个目的主机已接收过的包,通过占用接收系统的资源,致使系统消耗资源,可用性受到极大的损害,甚至无法正常通信。
作为短信服务器的接口,短信息交互频繁,短信息网关的IP极易受到重放攻击的威胁。缺乏新鲜性检查机制是导致重放攻击最常见的原因之一。通常新鲜性检查机制就是时间戳,用短信息附带的时间戳标明该短信息上行的具体时间,短信息接收方只接收时间戳与当前系统时间的差值在设定范围之内的消息。本文用System.currentTimeMillis ()来获得当前系统的时间戳。在JDK中,currentTimeMillis ()是java.lang.System类提供的方法,用于返回以毫秒为单位的当前时间。
但是时间戳机制并不能保证消息的确定性和惟一性,因此在时间戳后面另加一个计数值来确保短信息数据的惟一性,计数值由SP接收到用户上行的短信息后由计数器累加计数产生。将时间戳和计数值的结合作为重放的标记,将此标记放到接口中一起传送给应用提供商,应用提供商下行数据给用户时,将对应上行短信的事务编号的ID参数值传给SP。重放标记ID只存在于一个上行短信到下行短信的流程,将收到的ID值与之前保存的ID值判断是否重复,如果有重复,则认为是重放攻击,丢弃短信息。
2.2.3 IP验证
为防止未授权用户或恶意用户的访问,本系统中采用了IP验证技术。JSP中的内置对象request是javax.servlet.HttpServletRequest子类的对象,当客户端请求一个JSP页面时,JSP容器会将客户端的请求信息包装在这个request对象中,请求信息的内容包括请求的头信息(Header)、系统信息(如编码方式)、请求的方式(如GET或POST)、请求的参数名称和参数值等信息。javax.servlet.HttpServletRequest提供了getRemoteAddr()方法,用来取得来访者的IP地址。应用服务商将短信息存储到数据库之前,将request.getRemoteAddr()得到的IP地址与预定的IP值进行比较,如果确认是SP服务商的IP,才对短信息进行相应的处理。
2.3 短信息发送进程的安全性设计
应用提供商调用发送进程将短信息数据传输给SP短信网关,发送流程如图3所示。应用提供商从数据库提取相应的数据,采用MD5算法对短信息内容进行加密,即将记录中的ID+Phone_number+Number+Down_message_n+Md5_key (以下简称Down_message_key)组合后调用MD5函数运算,计算方法:MD5(Down_message_key)。本接口支持“一条短信上行,多条短信下行”的机制,这里的Number是指下行短信的数目,Downmessage_n是指下行给用户的第n条短信内容。同样将经MD5运算得到的信息摘要放到Sign_result和其他参数如电话号码、短信内容等一起传送给SP短信网关,然后从SP短信服务商获取发送状态,如果数据已成功下发,则删除相应的数据,并生成发送报告。发送页面实现效果如图4所示。
2.4 安全验证的短信服务器接口应用
利用安全认证的短信服务器接口进行通讯,需要SP和应用提供商的服务器都提供一个URL,通过调用URL相互交换数据。此接口应用模型已应用于桂林某公司BOSS(业务运营支撑系统)平台的通讯管理接口,具有较好的应用效果。在该公司的通讯接口平台中,需要调用SP提供的URL接口将下行的数据发送到SP服务器中。在设计中要求将所有已处理的短信息都存储到数据库,短信数据库设计包括短信发送数据表和短信接收数据表。数据表的字段一般包括ID、Phone_number、Message、Sign_result,在该公司的发送进程,将ID、Phone_number、Message以及Md5_key进行MD5签名认证后得到签名结果Sign_result,调用SP的URL接口:
http://***.***.***/***/***.jsp?ID=*********&Phone_number=***********&Message=*8*******&Sign_result=******传送到SP接收接口,此时,SP首先进行IP认证,读取来访者IP地址,如果IP正确,则进行重放攻击认证,此时将检测对方传递过来的ID与数据表中已用的ID是否有重复,若没有重复,则利用相同的签名算法对原始信息进行MD5签名,将得到的签名结果与传递过来的Sign_result进行比较,若正确则存入对应的数据表中,否则返回相应的错误信息。在该公司的发送数据处理过程中,也同时接收SP返回的状态结果,按照状态结果的类型进行相应的后续操作。
3 结论
本文利用JSP技术实现了短信息服务器接口,采用MD5信息签名技术、防重放攻击技术、IP验证技术等加强了短信息接口传输的安全性与可靠性。本文设计的接口可以高效地完成应用提供商与SP之间短信息数据交互。实践证明,随着短信息业务的推广,安全、可靠的短信息服务器接口将极大地提高短信息增值业务的效率。
摘要：研究短信服务器接口实现方式,提出了基于JSP技术的B/S结构的设计思路。针对B/S结构在安全性上存在的不足,利用MD5数字签名、防重放攻击、IP验证等技术加强了短信息接口传输的安全性与可靠性。该方案设计简单、安全性高,具有较广阔的应用前景。
关键词：JSP,短信服务器,MD5,重放攻击
参考文献
[1]蔡长安,张益华.基于VC++的短信和邮件互发系统的设计[J].计算机应用与软件,2008,25(8):165-167.
[2]周书民,汤彬,孙亚民.基于CMPP协议的移动短信增值服务平台[J].计算机工程,2006,32(10):260-263.
[3]霍利锋,白凤娥.基于多线程的移动短信平台设计[C].AECC专题学术研讨会论文集,2007.
[4]刘蕾,刘厚泉.基于工作流的B/S模式OA系统设计与实现[J].微计算机信息,2008,24(6):233-235.
[5]杨燕,谭成翔.安全短信息系统的研究和实现[J].计算机工程, 2008,36(4):124-126.
接口服务 篇8
内容管理系统是一个软件系统, 它提供给最终用户编辑、发布及修改内容的功能。当前, 内容的概念非常广泛, 它可以是一个网站的新闻、评论或博客, 也可以是图片、视频, 当然还可以是一些金融数据。当内容存储于内容管理系统中后, 有一个需要面对的问题就是如何使用这些内容。
以前, 内容管理系统相对独立和封闭, 不需要和其它系统进行信息交互, 内容在该系统中采集、管理并被使用。 随着网络技术的发展, 内容管理系统中的内容不再局限于自身使用, 它所管理的内容被越来越多的外部应用程序使用。这些外部应用程序的种类非常丰富, 可以是一般的PC客户端应用, 也可以是互联网站的应用, 甚至是手机移动端的应用。
为了避免外部应用程序接触内容管理系统的数据层, 减少应用程序之间的耦合, 内容管理系统就需要提供一套数据服务接口供外部应用程序使用。外部应用程序在使用内容时只需要访问数据服务接口, 而不需要和应用程序的数据层进行交互。通过数据服务接口访问内容管理系统有两大好处:
(1) 减少系统间的耦合。当内容管理系统底层数据结构发生变化时, 外部应用程序不需要改变, 因为外部应用程序只是和它的数据服务接口进行交互。
(2) 性能提升。由于数据服务接口独立于内容管理系统, 是无状态的, 所以它可以单独布署到不同的机器上, 提供分布式数据服务, 同时也可以单独对数据服务接口提供缓存服务。
作为数据服务接口的实现方式, 最为普遍的是使用SOA面向服务的体系结构。基于SOA的体系结构设计可以方便地在不同的系统之间集成, 各系统之间不需要了解其它系统的技术实现方案, 参与集成的系统只要能提供对外业务所需要的数据服务接口即可。百度百科http:// baike.baidu.com/subview/21305/5033544.htm?fromId =21305&from=rdtself有关于SOA的介绍。
大多数SOA的体系结构设计都是基于Web Service技术的, 包括RMI、SOAP、CORBA和EJB等。虽然它们可以构建一个SOA系统, 但是在技术上都存在不足:
(1) 开发、维护复杂。基于以上技术构建的Web Service接口, 有些技术需要了解复杂的开发协议和规范; 有些需要学习新的开发环境, 这些都会导致开发和维护成本的上升。
(2) 客户端便用不方便。由于以上技术大都有自己的协议和规范, 这使得客户端需要了解服务器端所使用的协议和规范;同时, 当基于客户端存根类访问服务时, 服务升级变得不方便, 需要所有使用该Web Service的客户端完成存根类的升级。
(3) 浏览器富客户端难于应用。随着互联网应用的发展, 前端浏览器的应用越来越强调用户的交互体验, 互联网应用也就变得越来越富客户端, 很多时候都需要在浏览器端直接调用Web Service接口。而采用以上技术的客户端调用要么是只限定在服务器上, 要么是向浏览器传递的信息量过多, 不利于互联网传输。
而基于REST规范设计的Web Service接口, 很好地弥补了以上技术的不足:
(1) 基于HTTP协议。基于REST的Web Service接口采用HTTP协议, 使用起来非常简单, 因为所有的服务器接口都是一个URI资源, 开发起来相当方便, 维护成本也相当的低。
(2) 客户端使用方便。由于是基于HTTP协议, 所以客户端只要象访问一个互联网资源一样访问一个基于REST规范的Web Service接口, 不需要了解任何其它复杂协议和规范, 也不需要通过存根类去访问它们。
(3) 适应于富浏览器应用。AJAX即“Asynchronous JavaScript and XML” (异步JavaScript和XML) , 是一种创建交互式网页应用的网页开发技术。基于富浏览器的应用都是使用AJAX来调用后台Web Service服务的。而基于REST规范的Web Service接口可以返回一种全新的数据格式:JSON。JSON (JavaScript Object Notation) 是一种轻量级的数据交换格式, 是JavaScript的对象和数组。所以客户端通过AJAX调用基于REST的Web Service接口, 不需要做任何数据解析便可以在应用中直接使用返回的JSON数据。
1 REST服务规范
REST (Representation State Transfer, 表述性状态转移) 指的是一组架构约束条件和原则, 满足这些约束条件和原则的应用程序或设计就是RESTful。REST规范主要涉及以下内容:
(1) 资源。互联网上所有的内容都可以看作一个资源, 每个资源都可以为它们定义唯一一个ID, 即资源标识符URI (Uniform Resource Identifier) , 比如某电子商务网站上的一份订单, 可能会拥有以下形式的资源标识符:ht- tp://www.example*.com/orders/1234234, 该订单的资源标识符将会在整个互联网上唯一。
(2) 超媒体。超媒体被当作应用状态引擎 (Hyperme- dia as the engine of application state) , 也就是链接的思想。 任何情况下, 使用链接指引被标识的资源。比如上面订单的例子中, 订单资源的输出内容包括顾客的信息, 该顾客实际上是一种资源, 那么在订单的输出中就需要包含该顾客资源的链接。当客户端获得某一个订单资源时, 也能方便地获得该订单的顾客资源。
(3) 资源操作。在对资源进行操作时最常见的是增加、删除、修改和查询操作。HTTP协议定义了一系列的方法, 最常见的是GET和POST方法, 还有PUT、DE- LETE等方法。REST规范规定POST方法用来增加资源;DELETE方法用来删除资源;PUT方法用于更新资源;GET方法用来查询资源。
(4) 多重表述。资源可以有多重表达形式, 它可以是XML格式, 也可以是JSON格式, 通过设置HTTP头信息, 客户端可以指定某一资源的表达形式。例如下列HTTP头信息指定要获得订单的XML格式:
GET/orders/2013023112342142HTTP/1.1
Host:www.example*.com
Accept:text/xml
如果要获得JSON格式, 只需要将Accept头内容改成text/json
(5) 无状态性。REST规定客户端与服务器之间是无状态的 (Statelessness) 。这种无状态是指服务器端不应当保留客户端的状态, 这样当服务器出现问题, 客户端不需要依赖于这台服务器, 可以直接切换到另一台服务器, 这种设计提高了系统的可伸缩性。当然, 无状态并不是说系统不能保留状态信息, 状态信息可以保留在客户端及资源本身。
2设计与实现
本节将从技术和业务上说明如何构建基于REST规范的数据服务接口。当前, 支持REST的Java框架有很多, 比较流行的有Restlet、Cetia4、Apache Axis2和Jersey, 而Spring框架在版本3后也开始支持REST了。由于本系统较早支持REST服务接口, 所以选择了Jersey框架, Jersey框架是JAX-RS (JSR 311) 的参考实现。
2.1技术架构
图1是该系统的技术架构。使用该数据服务的客户端可以是浏览器, 也可以是手机或其它服务器端应用程序;客户端在访问数据服务时, 不是直接访问REST数据服务, 而是访问Varnish缓存服务器, Varnish缓存服务器可以很好地平衡用户访问请求, 特别是在多用户、大并发情况下, Varnish缓存服务器可以大大减少后台数据服务器的压力;REST数据服务是真正的数据服务提供者, 它访问CMS内容管理系统数据库, 并向外提供数据服务。 可以认为REST数据服务是内容管理系统的消费者, 而内容管理系统是数据库的生产者, 编辑人员能通过内容管理系统管理文章、新闻, REST数据服务为外面的客户端应用程序提供数据服务。
在构建REST数据服务时, 使用Jersey框架建立面向REST规范的数据服务, 同时使用Spring框架支持整个系统的IOC/AOP, 让整个系统的设计及代码看起来更加简洁, 易于管理;在数据访问层方面, 该设计采用了IBatis框架以达到ORM, 消除Java对象与JDBC数据集之间的数据转换;对于一些不是经常变动的基础元数据访问, 比如作者信息, REST数据服务层采用了ECache缓存框架, 当集成了ECache后, 在需要使用缓存的地方, 只要使用Java标记Annotation就可以了。这里不需要写任何代码就可以对任何一个接口的输出加上缓存支持。
2.2数据服务接口需求分析
内容管理系统是提供编辑人员编辑并发表文章的系统, 主要管理三类内容:编辑人员信息、文章关键字信息及发布的文章。这些内容需要以Web Service的形式向外提供数据接口, 供其它应用程序使用。由于当前系统的数据服务接口主要为外部应用程序提供数据服务, 所以都只提供GET方法。
外部应用程序可能是基于Web的B/S应用, 也可能是一般的C/S应用, 甚至仅仅是一个中间件。各个应用程序在处理不同的数据类型时优势也不同。例如, 如果是基于AJAX调用的B/S应用程序, 处理JSON格式数据将会很方便;而XML格式是几乎所有编程语言都能支持的一种数据格式, 甚至有些中间件或应用程序可能只支持XML数据格式, 所以在设计数据服务器接口时应当至少支持两种格式:JSON和XML。
提供一个稳定的对外数据服务对于内容管理系统来说非常重要, 这种稳定性并不仅仅是指系统的性能及可用性, 还体现在对外接口稳定性上, 也就是说对外接口的访问方式不会经常改动。当然, 这种稳定性是相对的, 在设计对外数据服务接口时需要从超媒体的角度出发, 使得数据访问者能够通过某一入口便能找到相应的资源, 这样即使资源的访问改变时, 外部应用程序也不需要做什么改变, 数据接口的访问形式变化对它来说是透明的。
数据服务接口在满足业务需求的情况下, 需要满足3个设计要求:支持对资源的读操作、支持资源的多重表述、 支持超媒体。而基于REST规范设计的数据服务接口已经提供了实现这3个设计要求的技术支持。
2.3面向REST规范的资源设计
在设计内容管理系统的资源超媒体时, 可以考虑从内容使用的角度出发, 设想一个B/S网站需要使用该内容管理系统的数据, 它有一个应用场景如下:①它的首页需要显示指定时间范围内的文章列表、作者列表及关键字列表;②当用户点击某一文章时, 会进入显示该文章详细内容的网页, 文章的详细内容会显示该文章编辑人员的名字;当点击该编辑人员的名字时, 会进入与该编辑人员相关的介绍网页;③编辑人员介绍网页有一链接, 当点击该链接时, 会显示与该编辑人员相关的文章列表网页。
根据以上场景, 设计出图2的面向REST规范的数据资源服务接口。从该图中可以得出两大信息:一是系统已将资源分为两种类型, 即索引资源和实体资源, 索引资源其实是某一类型资源的列表, 通过索引资源可以访问到系统中的实体资源, 而实体资源是真正的资源, 对应于某一篇实实在在的文章或一名作者;二是整个内容管理系统的资源都是互通的, 没有处于孤岛中的资源, 比如通过任何一篇文档资源都可以访问到相应的关键字资源和作者资源, 通过任何一个索引资源都能访问到所有的文档资源, 这就是对超媒体设计的支持。
在设计实体资源的URI时, 将采用 “http://www. sample*.com/{资源}/{关键字}”的形式, 例如某一特定文档资源的URI是http://www.sample*.com/articles/ 1, 某一作者资源的URI是http://www.sample*.com/ editors/1, 某一关键字的资源是http://www.sample*. com/keywords/1。
图3显示某一篇文章资源输出XML表现形式的内容片段, 从中可以看出它里面已包括了对作者资源及关键字资源的链接。
3使用效果
该设计方案已经成功应用于一家全球性金融企业的内容管理系统, 通过该内容管理系统, 可以看到证券分析人员和信息采编人员发布上市公司的各类信息, 包括新闻、年报等;通过该方案设计的服务接口对外提供数据服务。现在全球已有30多个国家的金融网站通过该接口获得上市公司的信息, 同时有数十种手机客户端应用程序在使用该接口, 为不同的用户群提供信息服务。图4是使用该数据服务器接口的一个网站界面。
由于该数据服务接口是无状态的, 所以在全球设置了不同的数据中心, 以便向不同的站点提供最好的性能服务。该数据服务接口自上线两年多来, 一直处于非常稳定的运行状态, 向外提供了7×24小时连续不间断的可用性服务, 同时没有出现性能压力问题。
4结语
本文提出的基于REST规范面向SOA的服务接口设计非常适合内容管理系统, 特别是基于B/S的互联网应用, 使得客户端使用这些服务变得非常简单, 而且所有的编程语言都可以方便使用, 不需要了解SOAP、EJB、COR- BA等复杂的交互协议。基于REST规范的服务器接口设计面向SEO (Search Engine Optimization) 搜索引擎优化, 有利于网站的推广。
由于内容管理系统的客户端非常多, 对于它提供的数据服务器接口性能及稳定性有很高的要求, 虽然Varnish服务器的建立使得该数据服务的性能有了很大的提升, 但当客户端应用是Web时, 由于Varnish只是位于一个区域的服务器, 当该数据服务被不同的地域浏览器访问时, 仍然会出现性能问题, 所以该方案还需要解决的一个问题是数据服务的反向代理。当客户端访问Varnish之前, 先访问反向代理服务器, 反向代理服务器后面是一系列分布在不同地域的Varnish服务器, 反向代理服务器将根据用户请求的来源决定访问哪一台Varnish服务器, 具体的实现细节还有待进一步研究。
参考文献
[1]PACKT PUBLISHING.RESTful web services cookbook:solutions for improving scalability and simplicity[EB/OL].Yahoo Press, 2010.
[2]ROBERT DAIGNEAU.Service design patterns:fundamental design solutions for SOAP/WSDL and RESTful web services[J].Addison-Wesley Professional, 2011.
[3]MARTIN J FOWLER.Patterns of enterprise application architecture[J].Addison-Wesley Professional, 2002.
[4]BRUCE JACOB, SPENCER NG, DAVID WANG.Building scalable web sites:building, scaling, and optimizing the next generation of web applications[J].O'Reilly Media, 2006.
接口服务 篇9
1 Web Service数据接口
Web service是一个平台独立的, 低耦合的, 自包含的、基于可编程的Web的应用程序, 可使用开放的XML标准来描述、发布、发现、协调和配置这些应用程序, 用于开发分布式的互操作的应用程序。Web Service作为一项新的技术出现在我们面前, 它的出世是用于解决在不同的平台下的应用的协同的。Web Service技术, 能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件, 就可相互交换数据或集成。依据Web Service规范实施的应用之间, 无论它们所使用的语言、平台或内部协议是什么, 都可以相互交换数据。Web Service减少了应用接口的花费, 为整个企业甚至多个组织之间的业务流程的集成提供了一个通用机制。
Web service的一个最基本的目的就是提供在各个不同平台的不同应用系统的协同工作能力。Web service接口方式主要适用于前台交互应用系统, 如县级综合业务平台、气象业务内网、数据共享应用平台等, 检索数据量不宜过大, 除以数组形式返回要素数据外, 也支持与REST服务相同的返回格式和功能。采用Web service接口方式既能保证气象信息服务平台的数据安全, 又能达到其它业务单位从气象信息服务平台中获取数据的目的。
2 气象信息服务平台中Web Service数据接口实现
Web service定义了应用程序如何在Web上实现互操作性。要实现互操作性, Web Service平台必须提供一套标准的类型系统, 用于沟通不同平台、编程语言和组件模型中的不同类型系统。SOAP (Simple Object Access Protocol) 是实现在各个Web Service组件之间传递消息的传输层, 是Web Service之间的基本通信协议。WSDL (Web service Description Language) 定义了Web Service做什么, 怎么做和查询的信息。WSDL是实现协同能力的关键, 它提供了一份契约用于与新老的应用之间交互。这项技术使得各个组织可以将标准的制定集中在Service的外部接口, 而不用考虑各组织的具体实现。简而言之, 它实现了Web service的接口与实现的分离。从而使得标准的制定, 更加容易。
气象信息服务平台Web Service数据接口实现采用的是Axis+eclipse开发Web service的方式, Axis是apache下一个开源的Web service开发组件, 首先在气象信息服务平台服务器上安装eclipse的Java EE、axis2、eclipse的axis2插件等, 然后在eclipse新建Web工程并创建Java类及方法, 根据数据资料的类别定义不同的方法, 使用eclipse的create Webservice功能, 选择axis2生成发布Web service, Web service就会部署到应用中, 生成可以调用的WSDL文件。
在Web客户端, 取得服务端的服务描述文件WSDL, 解析该文件的内容, 了解服务端的服务信息, 以及调用方式。根据需要, 生成恰当的SOAP请求消息 (指定调用的方法, 已经调用的参数, 如时间、气象要素等) , 发往服务端。等待服务端返回的SOAP回应消息, 解析得到返回值。在服务器端, 生成服务描述文件, 以供客户端获取。接收客户端发来的SOAP请求消息, 解析其中的方法调用和参数格式。根据WSDL的描述, 调用相应的对象来完成指定功能, 并把返回值 (如查询结果、统计数据等) 放入SOAP回应消息返回给用户。
3 气象信息服务平台中Web Service数据接口应用
在气象信息服务平台中, 用户可以根据自己的需要选择合适的语言和开发工具调用Web service, 根据WSDL描述文档, 会生成一个SOAP请求消息。Web service都是放在Web服务器后面的, 用户生成的SOAP请求会被嵌入在一个HTTP POST请求中, 发送到Web服务器来。Web服务器再把这些请求转发给Web service请求处理器。
气象信息服务平台的WSDL描述语言中包括Web Service使用的数据结构、参数及方法等。是以XML文件形式来描述Web service的说明书, 有了说明书, 用户才可以知道如何使用或是调用这个服务。以PHP语言为例, 以下是部分调用实例代码:
4 Web Service数据接口应用安全
随着Web Service技术的发展, Web Service的安全问题也逐渐被重视, 利用现有的SSL和HTTPS协议, 可以很容易的获得连接过程中的安全。然而这种安全实现方法有两个弱点。一是它只能保证数据传输的安全, 而不是数据本身的安全, 数据一旦到达某地, 那么就可以被任何人所查看。而在Web Service中, 一份数据可能到达多个地方, 而这份数据却不该被所有的接受者所查看。二是它提供的是要么全有要么全无的保护, 你不能选择哪部分数据要被保护, 而这种可选择性也是在Web Service中所常要用到的。目前Web Service数据接口已有使用XML安全扩展标准、实现数字签名、XML文件的加密技术、某些中间件的保护等保护方式。Web Service技术仍在持续发展中。
参考文献
[1]柴晓路等.Web Services技术、架构和应用[M].北京:电子工业出版社, 2003.
[2]青岛东合信息技术有限公司编.Web Services应用开发[M].北京:电子工业出版社, 2011.
[3]王瑄等.应用Web Services构建多层架构的高效.NET应用[M].北京:科学出版社, 2005.
[4]中国气象局.地面气象观测数据文件和记录簿表格式[M].北京:气象出版社, 2005.
接口服务 篇10
随着异种计算环境的不断增加,各种系统间的互操作性就愈显得必要,要求系统能够无缝地进行通信和共享数据,从而在Internet环境下,消除巨大的信息孤岛,实现信息共享、进行数据交换,达到信息的一致性[1]。Web Service能够使不同的系统之间利用"软件-软件对话"的方式实现相互调用,打破了软件应用、网站和各种设备之间的格格不入的状态,实现"基于Web无缝集成"的目标,所以得到越来越广泛的应用,应用的系统也越来越复杂。这就给应用于Web Service接口的手工测试带来了极大挑战,而基于传统系统的自动化测试方法也显的无能为力。基于此,本文通过深入研究Web Service技术并结合传统系统的自动化测试方法和测试工具,提出了一个“糖葫芦”式的自动化测试策略,并设计与实现了由该策略指导的针对Web Service服务接口的自动化测试平台。
2. Web Service服务接口的自动化测试基本策略和流程
2.1 Web Service服务接口的测试策略原理
自动化测试可以让测试人员从繁琐和重复的测试活动中解脱出来,专心从事有意义的测试设计等活动。自动化测试不仅可提高测试效率和测试的准确性,而且可解决一些用手工测试非常困难问题[2]。Web Service服务的应用越来越广泛,针对它的自动化测试有很高的应用价值。该策略的思路是构造出一个个的糖葫芦,最后用竹签串起来,达到更高程度的自动化测试。通过对Web Service应用的深入研究发现,它的应用有以下特点:
(1)要调用Web Service服务必须建立一个与之对应的Web Service Client端;
(2)Web Service Client端调用服务的参数虽然不同,但是调用模式相同;
(3)调用服务后返回的数据一般是XML结构;
(4)在Web Service Server端调试开发阶段,发布的服务结构变化很大。
上述特点给自动化测试带来了可能和便利,虽然调用服务需要建立与之相应的Client端,但是由于Client调用服务的模式相同,使运用语言的反射机制建立一个万能的Clien成为可能。该万能客户端给外界提供接口,接受外界的数据参数,动态调用Web Service服务,这样在调用服务阶段就能实现自动化调用,需要调用Web Service服务一次就触发万能客户端一次。
调用服务返回的数据格式是XML,这就给测试检查点提供了很大便利。我们可以把XML结构的数据考虑成树形结构,根据XML结构的特点,设计与开发一个针对XML结构的数据检查点的工具,该工具接受外界参数对相应的XML文件进行数据检查。
基于上述的特点4,在建立万能客户端时构造出一个配置文件,也是利用语言的反射机制,根据配置文件的信息动态加载Client端,在单元测试或者集成测试阶段如果发布的服务结构变化,只需要改变配置文件中相应的信息。
最后统计调用服务和数据检查的信息,生成测试报告。
2.2 Web Service服务接口的自动化测试方法和流程
在该策略中起竹签作用的是自动化测试工具QTP,QTP解析测试流程包括:调用万能客户端,调用针对XML格式的检查点工具,调用报告生成工具,生成测试报告。
万能客户端提供的参数有调用的服务名、调用服务需要的数据文件地址、返回数据存储地址、生成测试报告的统计文件地址。
针对XML结构的数据检查工具提供的参数有XML文件路径、检查Key路径(x Path)、预期值、生成测试报告的统计文件地址。
测试报告生成工具提供的参数有统计文件地址、生成测试报告地址。
如下图1为针对Web Service服务接口的自动化测试策略流程图:
3. 基于QTP的自动化测试的设计和实现方法
3.1 QTP介绍及应用原理
Quick Test ProfessionalTM是一款先进的自动化测试解决方案,用于创建功能和回归测试。它自动捕获、验证和重放用户的交互行为。Quick Test Professional是新一代自动化测试解决方案,采用了关键词驱动(Keyword-Driven)测试的理念,能完全简化测试的创建和维护工作。Quick Test关键词驱动方式独特之处在于,测试自动化专家可以通过一个整合的脚本和纠错环境,拥有对基础测试脚本和对象属性的完全访问权限,这些脚本和纠错环境与关键词视图(Keyword View)可以互为同步[3]。
Quick Test Professional同时满足了技术型和非技术型用户的需求,让各个公司有能力部署更高质量的应用,同时部署的速度更快,费用更低,风险也更小。Quick Test Professional和我们新的测试自动化系统Mercury Business Process Testing的紧密结合,可以将非技术型的业务专家(SME,Subject-Matter Experts)引入质量流程,这一引入可以将IT和业务更好地融合,最终建立起更出色的应用[4]。
因为QTP有录制回放的功能,所以在有UI界面的测试中,采用测试案例驱动方式,QTP读取测试案例数据进行回放,达到自动化测试目的。在没有UI界面的基于Web Service服务接口的测试中,自行开发出一个自动化调用Web Service服务接口的可执行程序,由QTP触发该可执行程序并进行测试数据传输完成对服务接口的自动化测试。
3.2 万能客户端设计
通过对Web Service Client进行研究发现以下几个问题:
(1)在Web Service Serve端的开发调试阶段,也就是单元测试阶段,每次发布出来的服务结构变化非常大,这就给这种回归测试带来了很大困扰。服务器每一次发布新修改的服务,自动化测试项目组就要修改测试工具。
(2)在真实的业务系统中服务的调用与具体业务本身逻辑结合非常紧密,比如调用一个服务的前提是需要调用另外一个服务返回的数据,而返回的数据结构非常复杂。
(3)每一个Client端可以提供的服务很多,每一个服务需要的数据类型都不相同。
为了解决以上问题,在设计客户端的时候构造了一个配置文件,该文件包括调用服务句柄、数据类型等信息。在Client调用服务时首先把测试数据构造成树形结构存储,根据配置文件信息构造成调用服务需要的数据类型,利用语言的反射机制调用QTP传输参数的服务接口。回归测试时只需要修改配置文件的信息即可。因为调用服务返回的数据结构非常复杂,如果把返回数据保存成文件,再调用下一个服务时,需要上一次调用服务返回的数据,这样一方面降低了运行效率,另一方面如果在执行流程出现异常则容易产生混乱。为了解决上述第二个问题,在设计Client端时实现了内流程、外流程。
(1)外流程:如果两个服务之间是独立的,一方不需要另一方返回的数据,则按照普通流程走,在QTP上实现流程,一个服务QTP调用Client端一次。
(2)内流程:QTP一次把多个有关系的服务需要的参数传给万能Client端,由万能Client端实现该流程,中间没有QTP干预,所有的中间返回的数据都保存在内存中,调用下一个服务时在内存中构造需要的数据类型,这就很好地解决了上述问题。如图2为万能客户端流程图。
3.3 基于XML结构文件的检查工具模块结构
XML结构文件检查工具模块结构如图3所示,其中功能调度模块为平台的入口,在功能调度模块中根据QTP传输来的数据初始化数据、检查类型、生成报告文件。其中重点是检查类型调度模块。该工具支持二十几种检查类型,包括为空、非空、整数型、小数型、日期格式、运算式、字段值在某一范围、等于、大于、小于等等。
3.4“糖葫芦”式针对Web Service自动化测试策略关键点
(1)模块之间低耦合
在这种自动化测试流程串中模块之间的耦合度非常低,一个模块改变不会影响到另外一个模块。这就给应用带来了极大的便利性。
(2)应用范围广
该策略可以应用在所有的基于Web Service服务接口的系统的自动化测试中。策略对行业和业务依赖非常低。
(3)自动化程度高
达到了很高的自动化执行程度,从生成测试案例后,系统开始运行,到生成测试报告,中间不需要人为干预,大大提高了测试效率,减少了测试人员的工作量。
4. 结论
随着科技的进步和时代的发展,自动化测试是一个发展趋势。由于Web Service服务的应用也越来越广泛,所以针对Web Service服务接口的自动化测试的需求是迫切的[5]。本文基于QTP工具采用“糖葫芦”式等略设计与开发了针对Web Service服务接口的自动化测试平台,该自动化测试平台应用面较广泛,并已经应用于大型的金融机构的核心业务系统测试中,不仅大大提高了测试效率,减少了测试成本,还解决了一些人工几乎不能完成的测试工作,取得了良好应用效果。
参考文献
[1]段智华.浅谈SOAP[EB/OL].IBM DeveloperWorks.
[2]张瑾,杜春晖等.自动化软件测试[M].北京:机械工业出版社,2008.
[3]陈能技.QTP自动化测试实践[M].北京:电子工业出版社,2008.
[4]张瑾,杜春晖等.自动化软件测试[M].北京:机械工业出版社,2008.