《SaaS平台框架在大学资源计划URP建设中的应用实现.doc》由会员分享，可在线阅读，更多相关《SaaS平台框架在大学资源计划URP建设中的应用实现.doc（8页珍藏版）》请在三一文库上搜索。
1、SaaS平台框架在大学资源计划URP建设中的应用实现前言 SaaS服务模式是基于B/S架构获得广泛认可和推广的情况下发展起来的。可以在减少软、硬件设备，节省资源的情况下，将高校分散的应用和资源进行聚合，实现应用关联和信息共享；同时也提供统一身份认证、数据分析、个性化服务。 一、SaaS介绍 SaaS是soft as a service(软件即服务)的简称，是一种通过In-temet提供软件的模式，厂商将应用软件统一部署在自己的服务器上，客户可以根据自己实际需求，通过互联网向厂商定购所需的应用软件服务，按定购的服务多少和时间长短向厂商支付费用，并通过互联网获得厂商提供的服务和技术支持。其本质就是
2、通过在线租赁的方式替代信息化建设投资，并享有信息化技术的便利、效率和专业的信息化服务。 二、SAAS在校园信息中实现框架 (一)SAAS在多十学校中的系耽结构 在传统的高校信息化建设中，其业务包括了信息门户、人力资源管理系统、学工系统、教务系统、各类申报系统、招聘系统、研究生管理系统、科研系统等等，实现的方式是各个学校通过建立各自的信息平台，利用统一的身份认证、共享数据等技术来实现信息化的建设。这种方式在目前的大部分学校里得到了广泛的应用，但要一个学校建立起所有的系统，其缺点是成本高，建设周期漫长，维护成本高，信息只局限与本校的资源共享，不能所有学校共享，各学校信息化建设水平也参差不齐。 鉴于
3、上述原因，本文提出一个能降低学校成本、没有建设周期、不需要维护、所以资源共享、信息化建设统一的框架即服务学校的平台框架，如图1所示。 左边是各个学校的应用，右边是提供服务的提供商，学校的应用是通过SOAP的请求来实现的。对多个学校可以选择使用服务提供商提供的一个或多个软件服务，但每个Web Service Server服务在一个服务上运行，数据库可以是同一个数据库，但数据库的实例是不通过的，这样就保证了每个学校的呈现结果不同； 每个学校通过自己操作的数据库进行同一身份认证、使用申请的业务服务，在物理上虽然在一起，但逻辑上进行分离，这样既保证了必要数据的共享，也保证了每个学校的数据安全； 应用服
4、务层提供Web Service Server服务，处理由Portal Server传过来的业务请求，在程序控制方面进行了业务逻辑的封装，也保证了各个学校的需求差异； 共享数据库层是统一学校各系统的数据标准，整合各应用系统的共享数据信息，给应用服务层综合应用提供一致准确的数据来源和积累。 (二)平台框架的实现 上面提到的只是这个SaaS跟学校的一个关系，这里来分析SaaS的具体平台实现。本平台框架理论依据与参考是利用布式层次结构的思想、企业IT服务规范和 IBM 软件解决方案，采用了SUN Directory Server和SUN IdenfiW Server为整个门户平台提供一个统一身份认证核
5、心底层平台。认证接口作为这个平台的中间件，负责对外提供集成API。各个集成应用通过认证接口显示统一身份认证、单点登陆(SSO)等功能。Web控制台通过LDAP协议访问Directory Server，用于人员数据的管理(User Management)。Web容器层主要是采用了IBM的Websphere Portal Server来搭建web层，提供portal服务3。应用服务层是由IBM的Websphere提供Web服务，并为整个框架提供业务支持。平台框架可分成用户层、学校信息门户层、业务管理层、系统平台服务层、业务应用层、数据库层、系统安全平台。其中系统安全平台跨越业务管理层、系统平台服务
6、层、业务应用层，是整个系统的安全管理中心。 用户层提供对多种终端统一接入的支持。用户可以通过计算机、PDA、手机、Kiosk机等各种终端的Web浏览器统一访问系统的资源和服务。对于采用标准LDAP方式存放学校用户数据的应用系统，门户服务器可以和他们进行单一的用户存储，达到统一身份认证的集成程度； web容器层提供Portal Server服务(学校信息门户层)，负责终端设备的接口的定义、接人、及界面定制，学校信息门户的统一管理： 业务管理层负责业务应用服务管理，包括学校、客户、合作伙伴、组织机构、用户角色、权限及计费等的统一管理： 系统平台服务层：负责系统资源、数据管理及平台所提供的服务，是系
7、统的核心。 业务应用层：平台所提供的业务应用模块。 数据库层：数据的访问链接及控制。具体的实现在下面分析。 系统安全平台：负责系统的安全保障，包括安全基础设施、业务应用系统安全、安全管理保障体系等，是系统的核心。 (三)本平台数据的设计模型 在设计SaaS系统的数据模型时出于服务客户及减低开发成本等考虑。在数据的共享和隔离之间求得一定的平衡是必须考虑的一个重要因素。一般而言，SaaS系统的数据模型有如下三种形式： 独立数据库 将每个客户的数据单独存放在一个独立数据库是实现数据隔离的一种最为简便的解决方案。 共享数据库单独模式 第二种方式则是所有客户使用同一数据库，但各自拥有一套不同的数据表组合
8、存在于其单独的模式之内。 共享数据库共享模式 第三种方式是用一个数据库和一套数据表来存放所有客户的数据。在这种模式下一个数据表内可以包含了多个客户的记录，由一个客户ID字段来确认哪条记录是属于哪个客户的。 由于为学校提供的服务比较多，而且要服务的学校比较多，对于第三种肯定是不适应的，但对第一种方式从成本和维护等因素考虑都不适合，在本平台下采用了第二种模式：共享数据库单独模式。 在这种数据模型下，当客户尝试第一次使用该SaaS系统时，系统在创建用户环境时会创建一整套默认的表结构，同时将其关联到该客户的独立模式。此时一般使用SOL CREATE命令来创建模式，同时授权一个用户帐号来访问该模式。举例
9、来说，在SOLServer 2005中可以使用如下命令： CREATE SCHEMA ContosoSehema AUTHORIZATION Contoso 接下来，系统可以使用SchemaName，TableName来访问该客 户的模式： GREATE TABLE ContosoSch，ema，Resumes(EmployeelD int i-dentity primary key，Resume nvarchar(MAX) 一旦模式创建完毕，它将成为该客户所属用户帐号访问的的默认模式 ALTER USER Contoso WITH DEFAULT SCHEMA=Con，tosoSehema
10、一旦默认模式设置完毕，在使用该客户的用户帐号进行SOL语句操作时就不要再使用SehemaName，TableName来指定特定的数据表，而是只需要指明表名即可。因此在系统代码内一句简单的SQL语句就可以应用于所有客户，而且每个客户仅访问到自己的模式内的数据： SELECT*FROM Resumes 这种客户独立模式的方式相对比较容易被实现，而且从数据扩展性而言，这种解决方案和独立数据库一样，客户可以相对自由的对其中的数据结构进行新增和修改。一般在最初创建该客户的模式时，系统会预先创建一整套默认的数据结构，但在那之后，客户可以对其做个性化的修改来符合其实际业务需求 这种客户独立模式的方式在数据共
11、享和隔离之间获得了一定的平衡，它既借由数据库共享使得一台服务器就可以支持更多的客户，又在物理上实现了一定程度的数据隔离以确保数据安全。 数据集成构件是实现共享数据和交换数据的中心，它通过标准的Web服务接口进行交互，并以XML格式的数据进行数据传输和交换。共享数据库的各种数据以XML格式传输给数据集成构件；数据集成构件再以XML格式把数据发布到信息门户平台。数据集成构件采用Web服务技术对数据进行包装，把门户的数据展示和需求都看成是一种服务。通过服务的请求和调研实现共享数据库的数据交换和共享。 三、结束语 本文提出了一个服务提供商的SAAS对高校的框架、数据库安全、统一身份认证的高校信息的基本应用框架，描述了高校平台的原理和数据库的设计和实现。基于SaaS服务的高校信息门户通过Portlet化、XML标准化、统一身份认证平台实现了对已有应用和数据的资源整合，为学生、教师、行政人员等学校用户访问公共技术平台的资源提供了统一的登陆的入口，提高了门户系统的安全性、效率和可扩展性，为信息共享、人才储备、成果分享等得到充分的利用进行里叙述。