XXX智慧校园建设项目技术方案.doc

目录 1. 用户的现状及需求 1 2. 产品的设计理念 3 实用性 3 先进性 3 开放性与标准化原则 3 扩展性 3 安全性 3 可靠性 3 可管理性和可维护性 3 3. 技术线路 3 4. 智慧校园平台台产品方案 4 4.1 系统架构 4 4.2 系统交互图 5 4.3 技术架构 5 编程语言 5 面向对象的组件技术 5 应用程序的开发与运行结构 5 动态网页生成技术 5 基于SOA的应用设计与集成 6 平台接口 7 开发平台 7 4.4 系统功能 7 4.4.1 校园综合信息门户 7 4.4.2 身份识别与访问控制平台 16 4.4.3 共享数据服务平台（FutureEDU Share DB） 20 4.4.4 监控运维平台 23 5. 运行环境 24 5.1 软件环境 24 5.2 硬件支持环境 24 5.3 客户端运行环境 24 用户的现状及需求 近十年，高校间的竞争与整合正在加剧、组织变革速度加快。面对优质师生资源激烈争夺、提升教学与科研能力、打造学科专业的影响力等几个关键问题摆在各大高校面前，因此，校园信息化正在逐步走向以“消除学校信息孤岛”、“为决策者提供准确治校信息”、“由管理向服务模式转化”为建设目标的学校业务整合进程。 围绕“消除学校信息孤岛”的需求带动下，以及SOA方法论及技术架构的成熟，近几年，国内多数高校已经建设了基于SOA松耦合架构的数字校园平台，即统一信息门户、统一身份认证及授权、公共数据库三大平台。 数字校园平台在一定程度上，确实解决了学校一部分信息孤岛问题。然而，随着学校信息化应用的普及，以及业务的进一步扩大，原有的数字校园平台，在诸多方面已经不满足学校的需求。 统一门户平台 最初，统一门户起到集成器作用，通过其可以直接登入到学校现有业务系统、查看各部门的公告信息、并整合公共数据库之上的查询、报表应用而设计。所以大多设计成管理型门户，因而易用性和用户体验较差； 另外，统一门户一般被设计成内、外网分离模式，有些学校内部子网站多达300个，占用硬件设备及房产资源，且每年面临国家的信息安全等级认证高额检查费用，作为信息集成容器的统一门户，一般不能够提供子机构和个人用户建设门户工具，这在一定程度上增加了管理开销； 门户中的应用规划设计，其实用性问题也凸显出来。受客户体验、一站式服务、校园社区等需求影响，校园门户平台需要为更多的校园用户，如师生、企业、校友、专家、办学联盟以及政府等特定人群，提供更为有好的主动、便利服务，而统一门户平台已经比较难以适应； Portalet 168标准具有良好的组件动态装配特性，也正因如此，一直以来，这种组装引擎使得系统运行速度受到限制和挑战；另外，这种限制也是的平台的组件不能被更多师生共享式开发，其组装问题非常困难；另外，这种封装技术，在当时没有考虑到对平板电脑和IPhone等便捷移动设备的访问，使得移动应用开发需要另立门户。 统一身份认证与授权平台 统一身份认证和授权平台困扰的问题之一就是安全性，经常有些管理员会私自建账号，配置可以访问其他系统，这可能导致学生成绩被篡改的事故发生。有些用户甚至采用实体真实授权模式，希望能通过二级授权避免这个问题，但是，新的问题又来了，需要将第三方应用进行深度的权限整合与同步，在校园里实施这样的事情，是个非常大的挑战。 统一身份认证能够实现各系统基于LDAP协议的访问，能够统一认证身份。但是，实际上，除了电子邮件系统有此类协议，业内很多如教务、科研、OA等系统都需要对此进行专门的改造，甚至，很多学校使用了基于数据库的账号、密码认证，LDAP反而有些不实用，实际上是没有发挥其优势。 往往出现一个账户登入到门户后，显示可以访问某子系统，但是，点击后却被告知无法登陆。比如，邮件系统管理员在邮件系统中里面建立一个账号、但是，这是否有必要关联到一卡通系统、教务系统、图书馆系统不清楚，同步的是几个相对固定的应用，这是因为，统一身份认证采用多协议同步机制，并不支持账户全生命周期管理和自动化流程账户关联。 很多考生用户、外网应聘教师，希望自注册账号，以便访问学校门户给其带来的报考系统或应聘等系统，然而，基于现有的平台技术和业务融合去实现就非常困难。 一个教务处教师，本身又是攻读学校的研究生或博士学位，就需要将教务系统两种不同角色分配给这个教师。事实上，类似单账号多角色的情况是比较常见的。但是，因为不支持账户移动性和多角色管理功能，统一授权系统对这类情况处理就显得非常的困难，一般都采用交叉权限即禁止的方案，或者给用户创建多个账户登录访问，给账户管理和账户移动性带来不便。 在统一授权应用中，挂在资源树上的权限节点有几千个，资源及角色也很多，管理起来和授权都非常复杂，甚至有安全问题，因此，如何快速、简单的实现用户授权、合理规避授权中的存在的矛盾，就需要采