计算机网络期刊论文范文
所属栏目:计算机网络论文
发布时间:2014-01-09 16:30:05 更新时间:2014-01-09 16:01:04
在大学的各项工作中,教务管理应该说是极为重要的一项。它涉及到教学资源、学生学籍、成绩、教学计划的安排与执行、考务、教材等方面的大量信息[1]。当前,大学普遍采用的教务网络管理信息系统存在着难以满足广大师生员工日益多样的需求和移动等多样化终端设备接入的需求的弊病[2]。而基于开放平台思想对其进行重构则是化解这种有限的自身能力与不断变化的用户需求之间的矛盾、构建有效服务型管理系统的有效途径。
摘要:基于开放平台思想,重构大学教务管理系统,可以更充分地利用高校的人才优势,促成教务管理系统应用的定制与微定制、创新与微创新,全面提升整个系统适应变化的能力,更好地服务于广大师生员工。
关键词:开放平台思想,大学教务管理系统,重构,RESTful,授权
1开放平台基本思想简述
开放平台肇始于2007年。当年Facebook开放了应用平台,2008年Google发布开放平台战略。之后,互联网业者普遍接受了开放平台。
开放平台的基本思想,就是软件系统通过公开其应用程序编程接口供外部其它程序调用,以使用其资源,或籍此增加其功能,而其自身源代码却不必改动。
以开放平台思想重构大学教务管理系统,能实现以开放、活跃的管理系统替代封闭、僵化的管理系统,变单向低效的线性信息流系统为多向活跃的网状信息流平台。
2重构大学教务管理系统的基本思路
以开放平台思想重构大学教务管理系统,其基本思路是,统筹规划其原有服务功能和开放性平台相关的功能,分层设计并实现相应的持久层、业务层、表现层及开放API层。
大学教务管理系统的重构是传统业务与开放平台的统一,是开放平台对传统业务功能的提升,而不是开放平台对传统功能的简单否定。其中,对于新构建的开放性平台部分要注意其强健性。为此,可采用组件化体系,形成一个清晰的分层模型,各层依次支撑,相互协作,形成一个有机整体,完成强健的开放平台的构建。
3重构大学教务管理系统的基本策略
3.1重构大学教务管理系统的技术架构选型策略
大学教务管理系统开放平台的构建涉及多方面的技术。从开放API(OpenAPI)的架构风格而言,主要包括RPC(RemoteProcessCall)和REST(RepresentationalStateTransfer)[3]两种技术架构。
RPC即远程过程调用。它总的来说是一个Client/Server模式。提供服务的一方称为Server,消费服务的一方称为Client。首先,Client调用进程发送一个有进程参数的调用信息到服务进程,然后等待应答信息。在Server端,进程保持睡眠状态直到调用信息到达。调用信息到达后,Server获得进程参数,计算结果,发送答复信息,然后等待下一个调用信息。最后,Client调用进程接收答复信息,获得进程结果,然后调用执行继续进行。而REST是一种轻量级的Web服务架构风格,对资源只提供Create、Retrieve、Update和Delete4个原子操作,开发者通过它们构造复杂的操作过程。
这里重点提一下REST。REST的核心是资源。REST风格应用可以实现交互,并天然地具有服务器无状态的特征。在状态迁移的过程中,服务器不需要记录任何Session,所有的状态都通过URI的形式记录在了客户端。与有状态服务设计相比,无状态服务容易实现系统性能的横向扩展。通过增加硬件,部署多个无状态服务,并进行LoadBalance而不会受到制约;至于有状态服务模式,Session的存储、共享都会带来性能瓶颈,且无法通过增加硬件消除。
REST实际上是Web的最佳体验,一个URI代表某种资源,使用HTTP谓词GET,POST,PUT,DELETE来代表对资源的不同处理方式,这统一了接口,便于大家遵循,也便于构造RESTAPI的请求,最终利于构建分布式应用或者跨平台应用。Google,Facebook之类的开放API,都是RESTful的。
3.2重构大学教务管理系统的开放内容选择策略
以开放平台思想重构大学教务管理系统的目的之一,就是将相应的教务管理数据、服务封装并以应用程序编程接口的形式公开,供广大师生员工依自身工作、学习等方面的特定需求进行二次开发,并在许可包围内为其他师生员工提供服务功能。
根据大学教务管理的业务内容,重构大学教务管理系统的开放内容主要有:教务数据开放、教务业务开放和教务账号开放。
教务数据开放上,主要开放人员方面信息(学生信息、教师信息、班级信息)、教学方面信息(课程信息、教学计划、课表安排、网上评教)、考试方面信息(考试安排、考试成绩)、公告通知等与师生们关系紧密的数据。教务业务开放上,主要开放教务管理业务活动,如教学研究、学术活动、实践教学等。最后,教务账号开放方面,大学教务管理系统有其独特的优势。因为相对于校内其它的信息系统,大学教务管理系统的账号数据涵盖面应是最广的。通过开放教务账号数据,一方面保证校内定制应用对开放平台性教务管理系统的安全访问,另一方面也可作为校内统一登录账号,实现校内单点登录。
3.3重构大学教务管理系统的开放授权策略
为平台及其数据安全考虑,开放平台性大学教务管理系统必须实施开放授权。使输出类功能(查询信息等)和输入类功能(添加、更新、删除等)能安全地调用,并同时保证平台相应信息的准确、及时和完整。
授权的实现是采用访问控制的形式。访问控制的内容包括认证、控制策略实现和安全审计几方面。主要的访问控制有3种模式:自主访问控制、强制访问控制和基于角色的访问控制。自主访问控制是应用最广泛的访问控制策略。用户有权对自身所创建的文件、数据等访问对象进行访问,并可将其访问权授予其他用户或收回其访问权限。自主访问控制所提供的安全性可能被非法绕过,授权用户在获得某资源的访问权限后,可能传送给其他用户。所以其安全性相对较低,无法对系统资源提供严格的保护。
强制访问控制是由系统对用户所创建的对象依既定规则对用户权限进行控制。每个用户和文件都被赋予一定的安全级别,且只有系统管理员才可确定用户和组的访问权限,用户不能改变自身或任何客体的安全级别。系统通过比较用户和文件的安全级别,决定用户是否可以访问该文件。强制访问控制常用于专用或简单系统,对通用或大型系统不太有效。
基于角色访问控制(Role-BasedAccessControl,RBAC)的基本原理是:在用户与权限之间引入角色的概念,权限赋予角色,角色赋予用户,从而实现了用户与权限的逻辑分离,降低了授权管理的复杂性、成本和错误授权的可能性。
RBAC支持三个著名的安全原则:最小权限原则、责任分离原则和数据抽象原则。最小权限原则要求将角色配置成完成任务所需要的最小权限集;责任分离原则要求通过调用相互独立且互斥的角色共同完成特殊任务;数据抽象原则要求通过权限的抽象控制一些操作,而不使用典型的操作系统提供的读、写和执行权限。
在开放平台性大学教务管理系统的开放授权上,可从师生员工等使用者和开放API两个维度考虑。可考虑采用基于角色的授权模式,进行细粒度的访问控制。
对于教务账号开放,其授权方式的具体实现应遵循开放授权协议。开放授权协议,即oAuth,它为用户资源的授权提供了一个安全的、开放而又简易的标准,是一种无须透露用户认证信息而访问用户的受保护资源的安全访问方式[4]。目前它已逐渐成为开放资源授权的标准。对于开放平台性大学教务管理系统而言,它可以在保证安全性的前提下,让师生员工使用教务管理系统的验证授权功能。oAuth协议与其它授权方式不同之处是,oAuth的授权不会使第三方触及到师生员工的帐号信息(如用户名与密码),即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权,就此而言,oAuth是安全的,即使截到数据包,也无法还原出用户的登录信息。这既是oAuth最大的优点,也是它得以逐渐成为通用授权标准的原因。业界提供了oAuth的多种实现,如PHP、JavaScript、Java等各种语言开发包,节约了师生员工的开发时间,提高了开发效率。这些也便于重构大学教务管理系统时实现平台自身的oAuth认证服务。
4关于大学教务管理系统重构的安全问题
大学教务管理系统重构的安全问题主要涉及校内第三方应用的漏洞及潜在攻击性带来的安全隐患预防、师生员工信息资料
的安全以及其它敏感数据的保护等几个方面。在构建教务管理系统开放平台时,需要采取多种措施保证教务管理系统开放平台的安全运行。
其基本思路和主要做法是,在选择成熟技术保证开放平台运行稳定的基础上,通过采用访问所需的最小授权方式保护信息资料和敏感数据的安全,并采用加密、数字签名等措施予以加强;通过实时监控第三方应用调用API的情况,并配合人工线下审核等方式[5]最大限度地和更早地预防、发现、消除校内定制应用引发的安全隐患。只要设计周全、实施得力,开放平台性大学教务管理系统的运行安全及资源安全是完全有保障的。
5结束语
基于开放平台思想,重构大学教务管理系统,以大学教务管理系统开放平台统摄其传统业务,在保证原有服务质量的基础上,逐步形成以开放平台为中心系统,以院系部门所开发系统为内层卫星系统,以师生员工所开发系统为外围卫星系统的富有生机的生态性大系统,并最终达成多方位、多层次、大覆盖的有效服务型大学教务管理系统。
参考文献:
[1]董羽冲.基于网络的协作式教务管理平台的研究与设计[J].海南师范大学学报(自然科学版),2009(3):93.
[2]王文海.基于WCF数据服务的大学教务管理系统开放平台的构建[J].电脑知识与技术,2012(30):7164.
[3]Representationalstatetransfer[EB/OL].[2012-10-06].http://en.wikipedia.org/wiki/Representational_State_Transfer.
[4]OAuth2.0[EB/OL].[2012-10-07].http://oauth.net/2/.
[5]朱蔚恒,周伟,龙舜.开放平台解决方案及其安全策略研究[J].计算机工程,2012(6):267.