软考系统架构师论文-二论就rest服务的web应用系统设计

二论就rest服务的web应用系统设计

摘要

• 2011年上半年,我在上海中软资源软件有限公司,作为项目组长参与了公司人事管理(HR)系统开发,在系统开发前,公司再信息化建设汇总,也采用了请假流程,薪资管理,招聘等系统,虽然较为成熟,但是批次之间互相独立,业务数据无法共享,且公司各个分公司间,对HR系统使用情况也截然不同,有的分公司由于各种原因,仍然采用手工管理本应信息系统化的业务流程,公司是以软件外包业务为主,所以人力资源管理系统在公司信息化建设中的地位至关重要,这次开发的HR系统,江整合现有的业务系统,在整个公司内部推行使用,以解决信息孤岛带来的效率低下问题,为了以后的扩展需要,保证在业务和空间尽可能大的扩展性,因此,经过研讨,决定采用REST web服务方式实现系统应用层,本文将就HR系统开发过程,描述一下对REST服务的使用
  和认识的体会.

正文

• 上海中软HR系统整体此阿勇基于B/S的三层架构设计 我作为项目组长参与系统需求分析至测试和部署的整个过程,直接向IT部门总监汇报,负责沟通需求,建立
  项目组,确定系统架构风格和技术实现方案,预定开发周期为120天,系统部署后有两个月的试运行期,项目组人数在2到10人变动,由于项目开发资源(比如时间)紧张,公司HR系统业务逻辑复杂,旧系统改进个新需求交织,项目组对业务并不熟悉.
  难以在一开始预估江所有业务移植到新系统的时间,因此在开发模型选择上,采用螺旋式增量开发,首先不必追求大而全,在开发完系统基本框架基础上,有限移植最期待改进的业务,经于领导和HR部门沟通研究,递交了系统准备实现的功能列表,按不同实现优先级排列,标记为p1的功能优先级最高,必须实现,标记为p2/p3/p4的功能优先级依次减少,必要时根据资源情况需求进行裁剪,
• 在开发技术的选择上,由于本公司业务已微软外包为主,公司的开发人员大都熟悉一项或多项微软开发技术,作为微软公司合作伙伴可以低成本获取软件开发和管理工具,方便的获取技术支持,所以决定该系统采用微软技术:表示层基ASP.NET4.0,中间业务层采用rest服务实现,基于wcf数据访问层,基于微软orm构件-arf,在构件的选择上,尽可能降低开发工作量,提高效率,力求避免吧主要精力放在通用的技术细节,而是放在业务逻辑的研究和实现上.
• 系统部署共有三台服务器,灵台web服务器Windows server 2008 + IIS7.5分别运行系统网站和REST服务,一台数据库服务器Windows Server2008+Sqlserver2008,经过试运行于7月份投入使用,目前系统状况良好,经运行评估,实现了全部必须功能,性能,安全性等质量都达到了原定设计要求目前系统正在根据业务需要,由后续项目组做二次开发.
• 采用REST服务方式实现系统业务逻辑层,完全符合项目开发时考虑的两个因素,简单和灵活,传统的Internet web服务一般基于SOAP协议,构造soap情况xml虽然目前.net framework已经实现了较好的封装,但不便非.net语言调用,如果客户端
  页面中采用大量的ajax技术,使用JavaScript构造soap请求非常困难,在调用服务的web页面开发完成前,为了调试和测试服务,必须写单独的测试程序,十分不便.相比之下,而REST服务具有非常出色的灵活性,既能被服务器端面对对象语言调用,又可以直接被客户端的脚本语言调用,也很方便用浏览器和Fiddler工具进行测试,我们在项目中,并没有将REST服务单纯视为一串地址的响应,但是基于HTTP协议,可以最大的利用HTTP协议的语义特性,入数据的增删改查操作对应不同Http Method.
  用户可以用相同访问服务节点,根据需要,通过在请求头中设置不同的acept-Type,获取不同形式的数据结果,如JSON或XML.
• 更好的性能和缓存支持,由于不需要构造Soap消息,请求Rest服务显然开销更小,REST类Web服务可以利用高速缓存控制头,从而减少带宽的
  需求,从而REST可以改善响应时间和改进用户体验 可扩展性和无状态性,每个请求都是独立的,一旦被调用,服务器不保留任何会话,这样就可以更具响应性,
  通过减少时间后通讯状态的维护工作,提高了服务器的可扩展性.
• 在为系统开发REST服务的时候也遇到了一些问题.
  • 一.安全性方案,并不是指REST服务安全性不足,其本身没有内置的安全支持,但是所有HTTP支持安全模式和框架几乎都可以用于REST服务,真正潜在风险存在于REST灵活的使用方式山,既可以被服务器调用又能被客户端调用,所以一开始就要明确区分用户访问权限和系统访问权限,区分Web页面权限和REST服务权限,但是
    有时在开发中经常混为一谈,所以加强设计阶段这方面的文档和评估工作
  • 二.服务接口规范性,REST服务基于URI地址访问,有非常强的语义性,服务接口的每个操作都基于一个URI模板,在实际业务中,功能类似的操作被做成多个重载,随着重载的增多,URO模板如何约定,如何扩展就成为了一个规范性的问题,开始时,没有对这个予以足够重视,在多人开发服务,以至于一些服务操作予以产生了混乱,影响了理解和正确使用,后来又额外花费时间资源统一了规定了操作URI的格式,这方面
    业界没有明确的标准,更重要的是,应该从设计时就考虑将来如果需要重载空能的扩展,URI模板的语义扩展方式,还有一些其他的规范问题,诸如一些操作包括增删改查中一种以上的数据操作,HttpMrthod如何定义,也要一并考虑.
  • 三.WCF REST自身现在,WCF从3.0到4.0,已经是较为成熟,而WCF的REST构件则是全新的计算,WCF作为.net平台web service的代替者,无论在开发还是管理上,都有极大的灵活性,而WCF REST灵活体现在开发和使用事故那在管理维护情况下,WCF REST服务接口操作没有提供入WCF一样的灵活的配置功能,URI模板等元素必须在代码中设置 消息格式虽然可以根据客户端情况输出,但是不能子啊配置文件中设置.
  • 总的来说,虽然REST仍在发展中,经验和技术还有很大的进步空间,但是毫无疑问,基于REST服务的WEB应用程序拥有很多优势,未来在WEB系统,将有更光明的应用前景