接口管理的心得体会

接口管理的心得体会（通用7篇）

接口管理的心得体会 篇1

机电接口技术学习心得体会

本学期的课程结束了，本学期我们主要学习了常用的直流稳压器及应用电路的工作原理、设计方法以及常用的抗干扰技术等知识、运算放大器、电压比较器、隔离电路、调节器、滤波器电路在内的机电接口中常用的电路原理及应用、常用功率器件、直流电机、交流电机和步进电机的驱动电路，以及简单的了解了工业机器人通过本次课程我更多的了解到了机电接口技术的理论知识，也培养了我如何用更加全面的眼光看待机电接口技术这个专业需要考虑的问题。在本学期课程过程中，通过老师的耐心讲解，和学校对于网上课程的安排。我理解了机电接口技术重要性，也对本专业有了更深刻的了解

第1章我们学习了常用的直流稳压器及应用电路的工作原理、设计方法以及常用的抗干扰技术等知识。直流稳压器可以为负载提供稳定的直流电源，当交流供电电源的电压或负载电阻变化时，稳压器的直流输出电压都会保持稳定。直流稳压电源的基本功能：工频交流电源经过变压器降压、整流、滤波后成为稳定的直流电。图中其余部分是起电压调节，实现稳压作用的控制部分。电源接上负载后，通过采样电路获得输出电压，将此输出电压和基准电压进行比较。当输出电压小于基准电压，则将误差值经过放大电路放大后送入调节器的输入端，通过调节器调节使输出电压增加，直到和基准值相等；如果输出电压大于基准电压，则通过调节器使输出减小。抗干扰技术主要包括对空间干扰、供电干扰以及过程通道干扰的各种解决方案。使我们对于一个机电产品的环境基础的打造，有了深刻的认识。让我们明白一个机电设备对于电源以及环境有哪些苛刻的要求，让我们明白为了保证一个机电设备的良好运行，需要从哪些方面入手，预防哪些方面的问题。

第2, 3, 4章我们学习了运算放大器、电压比较器、隔离电路、调节器、滤波器电路在内的机电接口中常用的电路原理及应用。在这一章我们需要学会如何使用这些公式，搭建我们想要的运算电路。一个典型的运算电路应该包括三个部分：信号获取、信号放大与处理、信号执行。要完成以上的三个部分，才能称作是一个较为完整的运算电路。就拿运算放大器来说，我们需要了解他的原理，对于它的各个端口有清晰的认识，对于其特性参数要有较深的理解，从而能根据我们的电路要求选择一个合适的运算放大器。我印象最深刻的是理想的运算放大器有两个重要结论“虚短”和“虚断”，我们在老师的引领下，复习了电工电子这门基础课程的相关内容，同时也对反向比例放大器的公式进行了推导。

第5到第8章我们学习了常用功率器件、直流电机、交流电机和步进电机的驱动电路。这几章的特点是应用性强，要求我们掌握基本概念和简单的应用电路，在学习的过程中，注重理解基本概念、基本原理，看懂电路的工作原理。课堂上，老师向我们介绍了电动机的结构，工作原理，以及接线；步进电机的相位，直流步进电机和交流步进电机各自的特点，让我们对一个步进电机的精准控制有了近一步的理解和体会。

再次感谢我们的科任老师杨灵敏，老师严谨细致、一丝不苟的作风，一直是我们学习的榜样，每一难题的解决都离不开老师的细心教导，再次感谢老师的悉心教诲。

接口管理的心得体会 篇2

城市轨道交通建设工程是多专业、多单位参与的综合性工程。各专业、各单位之间相互依从、相互制约、相互联系, 形成了繁杂的接口体系。完整正确的技术接口, 是指导、检查和验证各子系统设计的完整性、安全性、可靠性、合理性和经济性的重要文件, 它不仅是选择土建工程方案, 也是各设备系统确定功能和规模的依据之一,

(注:表格中带*号表示存在接口关系)

2 专业组成和功能

建筑专业是地铁车站内所有专业的龙头专业, 在地铁设计规范称中为车站建筑专业。本专业的功能主要是为乘坐轨道交通的乘客提供安全、舒适、快捷的服务场所及与之配套必须设置的运营所需要的设备和管理用房。其中:站厅层是乘客集散空间和售检票场所, 站台层是乘客候车及下车的场所。本专业的设计应以车站的总体布局符合城市规划、城市交通规划、环境保护、城市景观为要求, 并以站内设备用房布置紧凑、便于管理、公共区乘客乘降设备在正常情况下和非正常情况下能够保证乘客安全、可靠, 快捷的疏导为原则进行设计。

3 专业的主要接口 (表1和表2)

轨道交通设计接口可以分成外部接口与内部接口, 外部接口是指轨道交通工程与城市外部条件的接口关系, 内部接口是指轨道交通内部各专业间的接口关系。

4 建筑专业接口的主要内容

按照设计输入和设计输出划分, 建筑专业接口管理的主要内容有: (表3和表4)

参考文献

[1]GB 50157-2003地铁设计规范[S].

动车组专业接口管理 篇3

作者： 北雪编辑

来源: 中国铁路网

更新时间： 2009-11-26

1.动车组运用管理。车辆（动车）段运用所按规定的修程、修制，完成动车组的运用检修，确保动车组出所时技术状态达到标准要求。机务段在动车运用所设派班室和待乘室，安排本务司机按计划出乘。

2.动车组车载设备管理。电务段负责列控车载设备和LKJ设备，铁通公司负责CIR设备，车辆段负责车载广播设备的检修。在运用所内设上述设备的检修点，负责相关出入所检测、检查及维护工作。

3.车内设备使用和管理。动车组配电盘、车内空调、照明及旅客信息系统设备由随车机械师操作。自动广播装置的广播内容由客运段负责按规定要求录制，车辆段负责输入自动广播装置。客运乘务员发现设备故障时，通知随车机械师及时处理。运行中发生设备损坏时，随车机械师与列车长共同确认，并填写上部设施破损记录，双方签字。

4.动车组的整备和保洁管理。动车组的客运整备和车内保洁由客运部门负责，动车组外皮清洗和吸污作业由车辆部门负责。

5.动车组看管，由铁路局指定部门负责。

6.动车组作业管理。车载行车安全设备（列控车载设备设备、CIR设备、LKJ设备）的检修、客运整备及保洁作业，须统一纳入动车组运用检修计划，由运用所统一管理。作业前，地勤司机、地勤机械师、客运整备人员、吸污作业人员、看管人员等有关作业人员，应向运用所调度人员报到，接受命令；各专业作业结束后，应到调度人员处进行登记，填写检修竣工单。

7.动车组调车管理。动车组出入所（存放点）的操纵由各铁路局根据具体情况自定；动车组转线及所内（或存放点）调车等作业，根据动车所的安排，地勤司机负责操纵。各铁路局根据具体情况制定详细的调车作业办法。

8.动车组存放点管理。

⑴铁路局设置的动车组存放点须具备动车组存放条件，并报部核准。各局在动车组存放点应设调度人员、地勤机械师及地勤司机，并建立作业登记制度、钥匙交接管理制度、出退乘签到制度。根据铁道部《关于铁路第六次大面积提速调图有关动车组劳动组织职工培训和工资分配问题的意见》铁劳卫[2007]67号文件，动车组存放点所需调度人员、地勤机械师由铁路局内部调整解决。

⑵存放点的作业管理。对不进行检修作业的外属停放动车组，由停放地铁路局指定有关单位负责动车组的吸污、防冻、客运整备、保洁等作业及看管，安排乘务人员待乘休息及接送条件；对不进行检修作业的本属动车组管理比照外属动车组执行。

9.动车组的交接管理。

⑴动车组入运用所或存放点，本务司机与地勤司机办理驾驶设备和行车安全设备的状态交接及主控钥匙、司机室门钥匙及列控车载设备柜钥匙交接，并提交动车组运行状态交接单（附件2）。地勤司机与调度人员办理主控钥匙、司机室门钥匙及列控车载设备柜钥匙交接；并与行车安全设备检修单位人员办理列控车载设备及LKJ、CIR运行技术状态交接（附件2）。动车组入动车所，随车机械师与调度人员办理动车组技术状态交接及车门集控开关钥匙交接，填写交接记录。动车组入存放点，随车机械师与地勤机械师办理动车组技术状态交接及车门集控开关钥匙交接，填写交接记录；随车机械师持交接记录到调度人员处签到；地勤机械师与调度人员办理车门集控开关钥匙交接。

⑵动车组出运用所前，由动车所质检员组织地勤司机、客运人员、随车机械师及列控车载设备、LKJ、CIR检修单位进行出库联检，填写出库联检记录单（附件3）。客运人员负责车厢内服务设施完好状况的检查确认，与质检员办理交接；随车机械师负责动车组技术状态的检查确认，与质检员办理交接；行车安全设备检修单位负责对列控车载设备、LKJ、CIR设备进行出库检查确认后，填写行车安全设备合格证，地勤司机确认行车安全设备技术状态，与检修单位办理合格证交接；本务司机与地勤司机办理行车安全设备合格证和驾驶设备技术状态的交接。

⑶动车组出存放点前，地勤机械师、随车机械师、地勤司机到调度人员处签到。地勤司机向调度人员领取主控钥匙、司机室门钥匙及列控车载设备柜钥匙，负责确认行车安全设备技术状态；地勤司机撤除防溜，本务司机签认防溜撤除记录；双方在操纵端驾驶室办理主控钥匙、司机室门钥匙及列控车载设备柜钥匙交接，本务司机负责驾驶设备技术状态的确认，填写交接记录。地勤机械师向调度人员领取车门集控开关钥匙，与随车机械师办理动车组技术状态及钥匙交接，填写交接记录。地勤司机、地勤机械师将交接记录交调度人员。

⑷动车组继乘，由本务司机、随车机械师按规定交接。

⑸列控车载设备柜钥匙交接管理。列控车载设备及LKJ出入所检测时，由设备检测单位与运用所办理钥匙交接。

接口管理的心得体会 篇4

核电工程建设项目的设计往往采取分岛设计的方式进行, 即核岛 (NI) 和常规岛 (CI) 、电站配套设施 (BOP) , 分别由不同的设计责任主体来实施, 各设计方通过分工和协作来完成全厂设计, 以保证全厂性能的完整。分岛设计的方式有利于设计单位发挥优势, 在其擅长领域进行设计, 降低核电站项目的设计费用和风险。然而, 分岛设计也存在不利因素, 它导致了错综复杂的岛间设计接口, 使设计边界处的协调工作量浩大。在分岛设计模式下, 设计接口的管理成为了核电建设项目中一项重点和难点工作。为了有序管理岛间设计接口, 核电业主或总承包单位常常会根据岛间的设计分工和进度计划, 编制一本动态的接口控制手册 (ICM) , 来收纳核电设计接口的所有条目、内容信息和交换的时间进度要求等, 通过手册的形式发布并不断更新完善, 以供各设计方执行设计接口参数的交换和进行状态追踪。运用ICM来进行设计接口的管理, 是中国核电工程项目最常用的接口管理模式, 国内的核电项目如大亚湾、岭澳、三门和海阳等项目均采用了这一模式。

ICM是一本包含所有岛间接口条目的集合体, 其接口数量十分庞大。ICM的管理者须对接口设置的合理性和全面性、交换时间的可行性以及交换内容的准确性等方面对ICM进行把控, 也须对每条接口信息交换的过程和状态进行动态跟踪。对于特定的某一接口, 从打开到关闭, 其间的交换次数预先难以确定, 许多接口需交换多次才能最后关闭。同时, 管理者还需对ICM的执行情况, 定期进行统计分析并发布状态报告。由此可见, 对ICM本身的管理也是一项非常繁杂的工作。因此, 有必要对ICM管理工作的流程、要点和方式方法等进行深入的研究, 以提高管理效率和实现对设计接口的有序控制。

1 ICM介绍

ICM, 全称是Interface Control Manual, 即接口控制手册, 它是管理核岛和常规岛、BOP设计接口数据交换的工具, 该手册明确列出了各个设计供方应提交的接口数据清单。ICM包含了数以千计的接口条目, 其每一个接口条目均包括接口编码、所属专业和系统、接口类别、内容描述、参考文件、接口资料的交换方、接口的交换时间、接口的目前状态、是否经过变更等相关信息。ICM中的设计接口条目, 覆盖了机械、电气、仪控、土建等专业领域, 包含了各种功能和实体接口信息, 如各种参数值、流程图、设备资料、布置图、化学性能要求、管线和电缆的走向和边界处接口、控制要求、仪控输入/输出控制点资料、模拟机提资等内容。ICM是一份处于不断完善中的动态文件, 包含项目本阶段中存在的所有核岛、常规岛以及BOP设计方之间设计接口和状态, 它为工程进展提供指引。

ICM通常在核岛浇注第一罐混凝土前18个月, 由业主或核电总承包单位牵头组织中外方咨询专家、设计院、各合同商和业主内部设计人员编制。经汇总后的接口清单由业主或总承包单位通过ICM发布并定期更新, 供设计方交换设计资料时使用。ICM所规定的接口交换时间和内容已经按照工程设计的逻辑顺序进行了设置, 满足设计二级进度和三级进度的要求, 并在编制后经过了各方的审查和认可[1], 各方均承诺按照ICM规定的时间来提交接口资料。如任何一方要求对ICM的内容或时间进行更改, 都应经过规定的程序[2]。

2 ICM的管理

2.1 管理的目标和内涵

如前说述, ICM是一份包含项目本阶段中存在的所有岛间 (核岛、常规岛和BOP) 设计接口的动态文件。管理ICM, 其本质是对岛间设计接口进行管理。设计接口管理的目标是实现设计接口交换的时间和内容满足不同设计方的设计进度和质量要求。在ICM模式下进行设计接口管理, 是从各系统、设备、构筑物的技术参数出发, 为了确保建成后的核电厂按额定参数运行, 要求各岛的设计单位按照协调的技术参数进行设计, 在相互的接口处根据ICM规定的时间和内容要求, 提出对方所需要的设计资料, 满足全厂设备运行的功能要求[3]。

2.2 接口关系流程

设计接口的管理是核电建设项目中一项重点和难点工作, 业主或核电总承包单位的设计管理部门会成立专门的设计接口协调机构来进行设计接口的管理。设计接口协调机构、NI设计方和CI/BOP设计方三者之间的接口关系流程图如图1所示。其中, 设计接口协调机构承担着NI设计方和CI/BOP设计方之间的接口数据交换协调者和ICM管理者的职能。

2.3 管理工作要点

设计接口协调机构在ICM模式下开展的NI和CI/BOP之间设计接口协调和管理工作, 其工作要点包括:制定接口传递渠道和模式, 协调、管理NI和CI/BOP之间的设计接口数据传递;审查和跟踪ICM的状态, 对过期条目及时提醒和敦促有关责任方完成, 并责成ICM编制方定期升版ICM;定期邀请各设计方召开ICM会议, 梳理ICM的状态, 解决NI和CI/BOP在接口资料交换过程中遇到的热点问题等工作;编制ICM相关报告, 反映接口交换情况, 使设计接口信息的交换及时、有序, 满足项目的进度要求与质量要求。

2.4 ICM审查流程

设计接口协调机构应定期对接口控制手册 (ICM) 进行审查, 审查的内容包括:a) 提资的时间是否满足进度要求;b) 审查是否有过期或即将过期的条目, 催促责任方及时提交资料;c) 接口条目的完成状态是否正确;d) 接口条目所对应的接口信息交换单是否登记完整;e) 是否应该新增接口条目或删除不必要的接口条目;f) 已经增加或删除的接口条目是否在ICM中更新。

以上的审查内容可以分为状态审查和过期审查两方面的内容。设计接口协调机构应定期审查ICM的状态是否根据项目进展情况及时地进行了更新, 并将意见递交ICM编制方, 定期要求ICM编制方对ICM进行升版。同时, 对于ICM中的过期条目, 进行重点的关注和控制。发现过期条目后, 及时催促责任方提交接口资料, 并审查其提交的资料是否准确和完整, 确认无误后再将资料传递给接受方。接受方收到资料后会将确认收讫的信息和审查意见, 再反馈给资料提供方。提供方如需进一步提供资料则进入下一轮的提资流程。

2.5 ICM会议

由于各设计方根据不同的合同关系制定了各自三级进度, 导致部分接口提资时间无法达成一致, 同时, 接口交换双方也可能对接口资料的提交范围和深度存在分歧。定期协调各设计方召开ICM会议是一种有效的管理途径。通过会议, 可以协调各方来整体考虑核电工程项目进展的要求, 探求解决问题或分歧的方案和促成一致意见。通过定期ICM会议, 还可以逐条确认各个条目状态, 根据工程进展要求, 逐渐关闭其中的开口项, 并为过期条目制定后续行动项。

3 运用信息化手段管理ICM

ICM包含了数以千计的设计接口条目, 管理和跟踪的工作量很大。目前, 国内大多数核电项目的ICM管理是基于EXCEL表格的形式, 接口交换的状态控制和跟踪必须通过人为方式、手动地去干预和统计, 费时费力。因此, 有必要研发专门的ICM数据库系统, 运用信息化的手段, 实现设计接口参数的高效管理和控制。

ICM数据库整体功能结构图如图2所示, 主要包括ICM清单、ICM查询、ICM统计三大模块, 该数据库可以在各设计方、ICM编制方和接口管理方之间共享。ICM数据库具备设计接口参数清单信息的录入、修改、显示, 以及接口数据的批量导入和导出等数据库通用功能。同时, 该数据库还能根据各个接口条目的提交状态, 统计各个专业、各种状态 (如过期、关闭、开口、已提交未确认等状态) 下的接口条目清单, 实现对过期参数的报警、即将到期数据的预警功能, 并生成各种报表, 以便于对接口参数进行控制和跟踪。

值得一提的是, ICM数据库还能自动生成ICM的各种状态统计图, 如图3, 系统根据电气专业接口条目的状态信息, 自动统计生成了电气最终数据提交状态饼图, 包含了关闭条目、过期条目、开口条目等数量和百分比信息。又如图4, 系统根据各个月份初步数据计划和实际完成的条目数, 自动生成了计划与实际完成情况对比图 (月份间隔取5个月) 。

各种统计图表的即时和快速生成, 能使核电项目建设者对设计接口交换的进展和状态一目了然, 以便于采取后续的跟进行动。

4 结语

运用ICM来进行设计接口的管理, 是中国核电项目最常用的设计接口管理模式。对ICM进行管理, 也就是要跟踪和协调各设计方严格按照ICM规定的时间、内容和质量要求提交和确认设计接口信息。另一方面, 接口条目的更新、接口交换的状态也要及时反映至ICM中, 以维持ICM的有效和受控。本文研究了ICM的管理的目标、内涵、工作流程和工作要点, 对于加深对核电项目接口管理工作的理解, 提升接口管理水平具有普遍的借鉴意义。同时, 本文亦探讨了ICM管理工作的信息化, 对于改变传统的手工统计方式, 实现设计接口的高效管理提供了思路。

摘要：核电工程建设项目设计接口错综复杂, 通常会使用接口控制手册 (ICM) 来进行管理和控制。对核电项目ICM的编制、格式和内容等进行了介绍, 并研究了ICM管理的目标、内涵、要点和流程等。最后, 分析和探讨了运用信息化手段来进行ICM的管理, 为高效管理设计接口提供了参考。

关键词：设计接口,接口控制手册,管理,信息化

参考文献

[1]程东平, 孙汉虹.核电工程项目管理[M].北京:中国电力出版社, 2006.

[2]林诚格.非能动安全先进核电厂AP1000[M].北京:原子能出版社, 2008.

接口管理的心得体会 篇5

随着海洋水文多要素立体观测技术的进步, 波浪、潮汐测量仪器正朝着测量原理多样化、装备体积小型化和观测智能化的方向发展, 其测量精度也不断提高, 进行测试检定的难度不断加大[1]。

目前, 加速度式波浪浮标或传感器检定工作主要由JBY-1波浪浮标检定装置[2]承担, 其利用双环桁架式结构, 将被检浮标安装在一个绕水平轴旋转的刚性臂上, 由电机带动其高速旋转实现波浪模拟, 可模拟最大波高1~6 m (以0.5 m为间隔) , 最大载重量180 Kg, 可检浮标直径0.5~1.0 m;声学、压力和浮子式验潮仪检定工作主要由水塔式潮汐/水位检定装置[3]承担, 其利用水泵改变水位的变化实现潮汐环境模拟, 可模拟最大潮差0~8 m, 水位测量分辨率0.1 mm。由上可知, 由于可检量程的限制, 它们难以实现大量程测波/验潮仪器的满量程检定;由于载荷限制, 它们难以实现大尺寸、大质量测波仪器的整机检定;由于结构限制, 波浪浮标检定装置难以加入波向检定子系统实现波向、波高和波周期的同时检定;由于功能限制, 难以实现同时具有测波/验潮功能的波/潮测量仪器检定。

针对以上分析, 为更好地保证测波、验潮仪器在实际使用中所得数据的有效性、可靠性和准确性, 研究新型波、潮测试检定系统WTTVS (Wave/Tide Testing and Verifying System) 是十分必要的。

为提高WTTVS的自动化程度和工作效率, 本文研究WT-TVS监控管理系统。目前, 许多监控管理系统采用组态软件进行开发设计, 虽然开发难度降低、开发周期短, 但往往软件架构设计不够清晰, 不易扩展, 通用性和灵活性差, 后期维护费用高[4], 难以较好地应对需求的变化, 而本文提及的基于接口多层架构模型充分运用传统三层架构的思想和接口的概念, 所谓接口, 实际上是一个纯虚类, 是从数据访问层抽象出来的公共方法签名, 有效降低了方法调用和实现之间的耦合关系, 使系统层次清晰, 易于扩展和维护。

1 WTTVS总体概况

WTTVS工作于实验室环境中, 利用垂直升降平台模拟海洋波浪或潮汐运行规律, 营造波浪和潮汐要素的测试检定环境。该系统由实时监控管理系统、波浪/潮汐环境模拟装置构成, 后者由测控终端和垂直升降模拟平台组成, 如图1所示。

实时监控管理系统通过RS-485向测控终端发送控制指令并同时获取监测信息, 其功能和软件架构的设计将直接影响到WTTVS的性能、自动化程度和研究过程中的功能扩展, 是本文讨论的重点。垂直升降模拟平台由曳引电机、承载平台、旋转编码器和绝对值编码器等构成。其中, 承载平台又分为水上和水下部分, 可同时承载多台被检仪器在垂直方向做受控运动, 对多种类型的验潮仪或测波仪实施测试检定。测控终端主要由PLC、变频器和继电器等构成, 主要完成对承载平台升降速度的控制、承载平台位置监测、实验环境监测、运行故障监测和紧急情况处理等任务。

2 WTTVS实时监控管理系统

2.1 主要功能设计

结合面向对象程序设计方法和分层架构思想, 依据WTTVS的结构特征和控制需求设计实时监控管理系统各个功能单一的功能模块, 为它们设置不同的登录权限, 如图2所示, 管理员可操作所有模块, 检定员和审计员只能操作箭头指向的模块。

其中, 历史数据查询模块细分为以送检单位和检定人员等多种查询条件的多个子模块, 以不同类型被检仪器所记录的数据和分析方法, 进行显示、处理和报表生成等操作;系统检定项目模块根据被检仪器原理的不同划分为三个子模块, 分别是加速度式测波仪检定子模块、声学式波/潮仪检定子模块、光学式或压力式波/潮仪检定子模块, 依据各自的被检仪器原理和检定要求进行严格的检定流程控制;系统测试项目模块的划分与测试检定项目模块基本相同, 主要用于波/潮测量仪器的动态性能测试;通信系统设置模块包括本装置通信设置和被检仪器通信设置两个子模块, 前者通过设置通信参数保证主控制机 (PC机) 与测控终端 (PLC) 正常通信;后者根据不同被检仪器的通信方式和通信协议, 设置通信接口和参数保证主控制机 (PC机) 与被检仪器的正常通信;系统管理模块包括备份和恢复数据库子模块, 集成了资源管理器功能, 使操作更为直观方便;报警信息管理模块主要是对系统中出现的报警信息进行查询和管理。

2.2 系统架构设计

考虑到WTTVS实时监控管理系统融合了波、潮仪器的测试检定任务, 其功能和任务较为复杂, 随着装置的硬件结构和控制系统研究的不断深入, 要求实时监控管理系统软件也必须同步更新。当人机交互的界面发生变动时, 若逻辑操作和功能实现代码与界面膠连在一起, 则难以保证代码修改的一致性, 甚至导致重写代码;当系统报表或视图中的信息发生变化时, 数据库结构将随之扩充或修改, 导致访问数据库的代码随之改变, 当数据库访问代码较为分散时, 势必会增大修改的难度。基于Winform的应用程序具有编码方便和调试部署容易的特点, 可在较短开发周期内应用于波/潮测试检定系统的实验调试, 而基于Web的网页应用程序更为适宜未来可能存在的对远程数据共享需求, 若软件架构较为随意, 将很难实现Winform向Web的转换。

本文运用面向对象程序设计和在其基础上发展起来的多层架构思想解决上述问题, 可以得到通用性好、易扩展、稳定且可靠的实时监控管理系统, 在需求发生变化时, 仅需较少地修改代码[5,6]。

基于接口的多层架构模型是在三层架构的基础上, 从数据访问层抽象出接口, 由不同数据库的数据访问层继承, 实现数据访问。业务逻辑层通过接口调用数据访问层, 进一步降低了业务逻辑层与数据访问层的耦合度。该模型按各子系统只能与同层及其下层子系统通信的原则划分层次结构, 有效限制了子系统间的依赖关系, 使系统以更松散的方式耦合, 较好地达到易于维护和扩展的目标[7,8]。

基于接口的多层架构模型如图3所示, 实体箭头表示层与层之间的引用关系, 箭头所指方向为引用层, 反方向为被引用层。其中, 数据访问层根据具体数据库管理系统的不同拥有不同的实现, 若需更改数据库, 只需编写相应的数据访问层代码, 修改抽象工厂层部分代码和配置文件中有关数据库类型的字段, 即可实现数据库的迁移。

该分层架构具有大量优点的同时也存在一些不足, 如采用多层架构模型后, 必须通过中间层来完成数据访问工作, 而不是很多业务直接访问数据库, 降低了系统的性能;导致级联修改, 尤其体现在自上而下的方向上, 例如当表示层需增加一个功能时, 为保证满足多层架构模型要求, 需要向下多层增加相应的代码, 即增加了代码量和程序员工作量[9]。

3 基于接口的多层架构实现

3.1 实现策略

WTTVS实时监控管理系统利用C#、Sql Server 2005和NI Measurement Studio 2005共同实现编码, 其中, C#开发环境Visual Studio 2005与Sql Server 2005无缝集成, 不但可以对数据库进行管理, 而且还具有较强的项目管理和组件开发能力, 为开发结构框架清晰且更易于维护和扩展的软件系统提供了保障[10]。在VS2005项目管理方案中, 为多层架构中的每一层均建立相互独立的7个项目, 即表现层 (WTTVS) 、业务逻辑层 (WTTVS-BLL) 、数据访问层 (WTTVSDAL) 、抽象工厂层 (WTTVSDALFactory) 、公共异常层 (WTTVSException) 、数据访问接口层 (WTTV-SIDAL) 和数据模型层 (WTTVSModel) 。

3.2 各层实现方法

表现层与业务逻辑层之间采用紧耦合方式, 用于采集操作人员的输入信息和请求, 展示特定的业务数据。该层利用C#良好的界面设计能力和丰富的控件库, 结合NI Measure Studio2005中的Lab View工程控件, 可以进一步优化界面设计, 提供美观、简洁的交互界面, 为减少操作人员的误操作, 该层利用界面逻辑展现被检仪器测试检定流程, 如波浪浮标检定前需完成的工作有录入波浪浮标基础信息和技术参数、外观检查及初始化系统等。

业务逻辑层是系统核心部分, 主要包括交换数据的单位变换与合法性检验、业务规则的制定和业务流程的实现等内容, 所有的业务流程均封装于业务逻辑层, 对表现层是透明的, 在数据交换中起到了承上启下的作用。该层中, 若存在业务操作的多样化或今后可能的变化, 可利用抽象类或接口的方法, 脱离对具体业务的依赖。

数据访问层继承于数据访问接口层, 实现其方法签名, 是直接与数据操作相关联的一层, 用于将数据存入数据库或反馈给业务逻辑层。它通过模型库建立与数据表之间的映射关系, 以调用数据库存储过程的方式实现对数据表的Select, Insert, Update和Delete操作。由于数据库访问层依赖于抽象接口, 对于业务逻辑层是完全透明的, 在进行业务逻辑层编码时, 可以不考虑数据库的具体结构及其操作, 从而极大地提高开发和维护效率。

数据访问接口层是针对不同数据库管理系统的访问代码存在差异而抽象出来的方法接口, 向业务逻辑层提供一致性操作, 可与抽象工厂层协同, 脱离了与具体数据库的依赖, 达到不同数据库之间迁移的目的。

抽象工厂层利用抽象工厂模式[11,12,13], 运用.NET库中的Configuration Manager读取配置文件App.Config中的数据库类型键值对, 根据返回的value值创建不同数据库管理系统的数据访问服务, 使系统能更加灵活地支持多数据库操作。键值对格式如下:

抽象工厂在WTTVS中的应用举例如图4所示。抽象类和方法用斜体字表示。抽象工厂类Abstract Factory中定义了创建数据库访问服务对象的抽象方法, 由实际工厂Sql Factory和Oracle Factory继承并实现。在业务逻辑层中, 调用抽象工厂类中的静态函数Choose Factory () , 创建与其相符的实际工厂对象, 再由实际工厂对象创建相应的数据库访问服务对象Sql GWMIService或Oracle GWMIService和Sql TUService或Oracle TUService, 达到对不同数据库管理系统操作的目的。

公共异常层是自定义异常类, 继承于Application Exception, 用于在业务逻辑层数据校验和业务工作流发生异常时, 通知表现层进行相应的处理。数据模型层负责系统中数据的封装和传递, 是数据库中数据表或视图的映射, 也称实体类, 其可以模拟一个或多个数据表, 也可反映一个或多个数据库中的字段, 消除了关系数据和对象之间的差异, 为关系数据库和对象之间架起一座桥梁。图5用UML序列图描述了层与层之间数据流, 展现了数据调用关系以及实体类在数据访问过程中所起的作用。

综上, 基于接口的多层架构模型, 通过结合抽象工厂模式, 利用.NET的配置文件, 有效降低数据访问层与业务逻辑层的耦合度, 保证了系统的通用性、标准化和数据库的可移植性。

4 WTTVS中应用的主要技术

分层架构思想使软件系统结构层次清晰, 易于维护、扩展, 能更好地适应将来系统需求的变化。基于接口多层架构是在传统三层架构的基础上发展而来, 将它们对比总结如表1所示。

WTTVS还充分结合.NET组件化编程的思想, 将系统多处重用的控件, 设计为自定义组件, 添加、删除或修改自定义组件中的代码后, 重新编译, 即可实现新定义的功能, 保证了代码修改的一致性, 有效提高了代码的复用性和系统的开发效率。同时, 将各子模块也设计为自定义组件, 在主窗体中, 利用Panel容器控件动态添加或删除自定义组件。这种设计方式使软件系统的开发类似于堆积木, 便于将来更换功能模块, 符合程序的组件化设计思想。

在系统项目管理方案中, 为各层建立独立的项目, 即保证类分别实现于不同的命名空间中, 使系统分层架构层次更加清晰化, 进一步提高了系统的可维护性和可扩展性, 有效避免了命名冲突的问题, 使系统安全性得到了保障。

在数据访问层与表现层之间交换数据时, 由于涉及不同的数据类型, 需传递的变量包括模型层中的实体类、字符串数组等。鉴于此, 利用C#提供的泛型结构, 运行时自动解释为本地代码, 提高了系统运行效率和代码质量, 保证了数据类型的安全。使用泛型结构方式, 首先进行实例化, 其语法格式如下:

Public List<数据类型>变量名=new List<数据类型> () ;

这时可通过“变量名”的Add方法添加多个已实例化的“数据类型”对象, 便于传递。该泛型结构还可与Data View、List View等控件直接绑定显示泛型结构中的集合元素。

上述技术在WTTVS实时监控管理系统中得到了充分应用, 降低了代码之间耦合度, 使软件系统具有较好的可伸缩性、可扩充性和可维护性, 有效提高了系统的开发效率和代码的健壮性。

5 结语

接口管理的心得体会 篇6

随着社会的进步, 经济的不断发展, 大规模的企业也不断增加, 而在企业财务方面, 工作量及复杂度也不断增加。比如信贷业务中定期贷款的偿还等, 都可以通过企业系统与指定银行系统连接, 来进行相关业务操作, 自动完成款项的代发/代扣。

二、银行接口

1. 协议

为了建立数据源与系统之间通用的数据接口, 实现实时地数据传输, 必须定义通信协议, 以传送接口数据。

通讯协议为TCP/IP协议, 使用Socket进行通信, 采用短连接方式。

Socket通常也称作“套接字”, 用于描述IP地址和端口, 是一个通信链的句柄。应用程序通常通过“套接字”向网络发出请求或者应答网络请求。

服务器:使用ServerSocket监听指定的端口, 端口可以随意指定 (由于1024以下的端口通常属于保留端口, 在一些操作系统中不可以随意使用, 所以建议使用大于1024的端口) , 等待客户连接请求, 客户连接后, 会话产生;在完成会话后, 关闭连接。

客户端, 使用Socket对网络上某一个服务器的某一个端口发出连接请求, 一旦连接成功, 打开会话;会话完成后, 关闭Socket。客户端不需要指定打开的端口, 通常临时的、动态的分配一个1024以上的端口。

双方数据传输遵循数据交互的通信格式及发送和接收的顺序。传输数据通过RSA加密解密算法。它易于理解和操作, 也很流行。算法的名字以发明者的名字命名:Ron Rivest, Adi Shamir和Leonard Adleman。但RSA的安全性一直未能得到理论上的证明。它经历了各种攻击, 至今未被完全攻破。主要通过公钥和密钥:公钥可以对外公开, 供其他人加密使用, 而把私钥秘密保存用于解密。RSA的安全性依赖于大数分解, 但是否等同于大数分解一直未能得到理论上的证明, 因为没有证明破解RSA就一定需要作大数分解。假设存在一种无须分解大数的算法, 那它肯定可以修改成为大数分解算法。

目前, RSA的一些变种算法已被证明等价于大数分解。不管怎样, 分解n是最显然的攻击方法。现在, 人们已能分解多个十进制位的大素数。因此, 模数n必须选大一些, 因具体适用情况而定。银行外联系统会统一对外公布一个TCP/IP服务端口号, 用于接收企业方发起的交易。

2. 通讯报文结构

数据交互的通信格式包括报文长度+HEAD报文头+BODY报文体+EXT扩展报文, 具体的XML报文体由单独交易说明。

3. 通讯描述

短连接采取每传输一次数据都进行一次“连接-传输-断开”的过程。

数据发送XML报文体采用XML数据格式, 由下面描述:

(1) 请求方的发送接收顺序:建立TCP连接—发送信息通信报文—接收响应报文—断开连接—。

(2) 接收方的发送接收顺序:建立TCP连接—接收信息通信报文—发送响应结果报文—断开连接。

4. 加密处理

在交易中对报文体按照双方约定的加密方式进行加解密处理。本交易中提供了一个企业设置密钥的交易, 企业可以通过此交易重置交易密钥。

三、接口系统功能流程

四、结束语

此系统是全自动定时执行, 无人值守, 可以根据用户设定时间 (可以设多个时间点) 。所有的报文传输数据都通过加密, 并给出了该系统的具体实现环节。实验结果表明, 该系统能够挖掘一些有益的信息, 从而为管理人员提供有益的参考。

摘要：主要讲述如何实现企业系统与银行系统进行对接, 完成企业贷款的代发/代扣业务。如何实现企业级系统与银行系统进行通讯、数据传输。通讯方式主要是通过Socket (TCP/IP) 来实现, 传输报文通过RSA算法加密。实验结果表明, 该系统能够挖掘一些有益的信息, 从而为管理人员提供有益的参考。

关键词：银行贷款,企业,代发/代扣接口系统,通讯,管理

参考文献

[1]Michael E.Whitman/Herbert J.Mattord齐立博.信息安全原理 (第2版) [M].北京:清华大学出版社, 2006.3:75-80.

[2]胡道元闵京华邹忠岿:网络安全 (第2版) [M].清华大学出版社.2008.9:19-73

接口管理的心得体会 篇7

内容管理系统是一个软件系统, 它提供给最终用户编辑、发布及修改内容的功能。当前, 内容的概念非常广泛, 它可以是一个网站的新闻、评论或博客, 也可以是图片、视频, 当然还可以是一些金融数据。当内容存储于内容管理系统中后, 有一个需要面对的问题就是如何使用这些内容。

以前, 内容管理系统相对独立和封闭, 不需要和其它系统进行信息交互, 内容在该系统中采集、管理并被使用。 随着网络技术的发展, 内容管理系统中的内容不再局限于自身使用, 它所管理的内容被越来越多的外部应用程序使用。这些外部应用程序的种类非常丰富, 可以是一般的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.