CN109559258A - 教育资源公共服务系统 - Google Patents

Abstract

本发明公开了教育资源公共服务系统，包括总体设计、框架设计和功能设计，本发明教育资源公共服务系统，平台管理是教育信息化应用平台的核心部分，提供统一的基础平台，实现与现有业务系统的集成和整合，在设计思路上所有业务平台、业务系统、应用系统间不直接对接，而是按照业务模型将基础应用集中规划为内部聚合、相对独立的应用服务。这些服务和对服务的管理形成系统总线，各系统根据业务需要作为服务或数据的制造者或消费者，与总线对接，各系统间并不直接发生交互，从而实现系统间的解耦；而通过系统总线的方式，对服务的使用进行统一的注册管理、安全管理、权限控制、路由、格式交换和监控。

Description

教育资源公共服务系统

技术领域

本发明属于教育资源公共服务系统，具体为教育资源公共服务系统。

背景技术

传统的教育资源公共服务系统采用主教育平台一对多同一服务，主教育平台的服务器负荷大，其服务质量较低，服务细节不够完善，对此需要设计一种高效的教育资源公共服务系统。

发明内容

本发明的目的就在于为了解决上述问题而提供教育资源公共服务系统，解决了现有的教育资源公共服务系统不够完善，服务细节不到位的问题。

为了解决上述问题，本发明提供了一种技术方案：

教育资源公共服务系统，包括总体设计、框架设计和功能设计。

作为优选，所述总体设计包括总体框架设计、技术框架设计和企业服务框架设计；

2.1、总体框架设计包括网络基础设施、信息资源中心、共享交换平台、应用层和展示层；另外安全与管理体系贯穿在整个建设过程中；

2.1.1、展示层：展示层通过建立综合信息集成门户系统为用户提供统一的用户界面，信息和应用通过门户层实现统一的访问入口和集中展现；

2.1.2、应用层：应用层提供多样化的定制应用，以提供满足面向各类用户依据实际需求开展业务的需要需求，如学籍管理、教籍管理、校产管理等；

2.1.3、共享交换平台层：共享交换平台层为数据共享交换平台所在位置，连接各类应用和应用所需的信息资源，组织和整合各类数据、组件和服务，数据共享交换平台层为实现应用层各种应用系统的搭建和运行提供支撑服务，包括目录服务系统、交换服务系统、安全服务系统和平台管理系统等；

2.1.4、信息资源层：信息资源层是数据中心，通过定义数据模型，实现数据组织、存储和管理，为共享交换平台层和应用层提供数据服务；

2.1.5、网络基础设施层：网络基础设施层提供各类系统的承载网络、所需的系统软件和硬件设备及其运行环境；

2.1.6、信息安全防护体系：信息安全保障体系贯穿系统建设各个层次。安全体系建设包括物理安全、网络及系统安全、应用及数据安全和安全管理几个方面，通过建设从物理层到应用层的整体安全防御体系，保障系统稳定、可靠、安全地运行；

2.1.7、管理维护体系：本系统应包括完备的管理和维护体系，它可从系统不同的层面实施管理与维护，为各种应用系统提供统一管理与维护基础服务；

2.2、技术框架设计采用J2EE技术体系，本次建设基于JDK1.6及以上的J2EE 框架为主，同时部分模块也采用了基于FrameWork3.5的.net体系框架建设；

2.3、企业服务架构设计包括企业服务框架和企业服务总线，具体如下；

2.3.1、企业服务框架分步骤为前端框架、服务层框架、业务层框架、持久层框架和通用构件库；

2.3.1.1、企业服务框架的前端框架完全遵照MVC模型设计，利用控制器来分离模型和视图，达到一种层间松散耦合的效果；

2.3.1.2、请求服务层是一个承前启后的层次，它负责连接展现层和业务领域层，并负责转换两个层次间的数据信息、传递数据等工作，请求服务层还提供了纵向集群和业务路由功能2个核心功能；

2.3.1.3、业务领域层主要由流程控制、过滤器、业务代理对象、业务对象、状态保存、资源控制和事务控制模块组成；

2.3.1.4、对于持久层，基础运行框架采用了标准的DAO模式来实现，可以使得持久性存储与业务逻辑完全分开，资源访问层还提供了包括数据库、LDAP、文件系统等多种数据访问层DAO的实现；

2.3.1.5、通用构件库是一个功能组件的集合，这些组件都是基于基础服务框架，为特定类型的业务应用提供管理控制功能；

2.3.2、企业服务总线针对ESB进行系统介绍，其中包括ESB的特点、ESB 的架构优势和产品架构；

2.3.2.1、ESB是一种在松散耦合的服务和应用之间进行集成的标准方式，是在SOA架构中实现服务间智能化集成与管理的中介；

2.3.2.2、ESB把最新的整合技术升华到一个基于标准的、经济易用的软件平台产品。ESB与当前市场上存在的、私有的集成方案相比，具有扩展性和灵活性的优势；

2.3.2.3、企业服务总线采用企业服务总线产品(企业服务框架ESB)实现，主要分为消息总线、安全管理、消息路由、数据服务、服务治理、运行控制六个子系统。

作为优选，所述框架设计包括J2EE应用结构、工程模块部署以及工程模块规划；

3.1、本系统采用J2EE应用结构，分为以下六层：

3.1.1、表现层：由JSP页面组成；

3.1.2、MVC层：使用SpringMVC框架技术；

3.1.3、业务逻辑层：使用业务逻辑组件构成；

3.1.4、DAO层：使用DAO组件构成；

3.1.5、Hibernate持久层：使用Hibernate框架技术；

3.1.6、数据库层：使用SQLServer2008R2数据库存储数据；

3.2、本系统采用工程模块部署，整个项目由多个JAVA工程构成，每个工程对应一个JAR包，在web主工程中，通过maven依赖，自动加载；

3.3、本系统采用工程模块规划，包括如下步骤：

A、核心工程：作为一个独立的jar包，不依赖于系统其他任何工程，可以被其他工程引用；

B、服务类工程：依赖于核心包，实现数据处理，以及接口服务的一种jar 包，不同的服务类工程之间可以相互依赖，但必须在本项目平台的环境下运行；

C、业务子工程：这种工程通常是针对业务或功能子系统来定义的，实现业务处理流程；

D、Web工程：顾名思义，可以在浏览器下运行的工程，Web工程是由各种业务子系统整合而来的，每个业务子系统在web工程下都是可插拔的。

作为优选，所述功能设计包括程序架构设计，系统模块设计和基础平台；

4.1、程序框架设计分为3层结构：

A、底层为系统的核心层，包括系统的核心功能，数据抽取、转换引擎，数据对象交换引擎等；

B、服务层：是在核心层的基础上，实现本系统的数据逻辑处理，本层次为应用层提供服务接口；

C、应用层：各业务系统、应用系统以模块化插件的形式，注册到平台上，利用平台的数据、权限等资源，实现与平台的耦合运行；

4.2、系统模块设计包括系统管理、分级管理、应用管理和日志管理；

4.3、基础平台：

SSO统一认证采用CAS+Shiro+Spring框架，CAS包含两个部分：CAS Server 和CASClient。

本发明的有益效果是：本发明教育资源公共服务系统，平台管理是教育信息化应用平台的核心部分，提供统一的基础平台，实现与现有业务系统的集成和整合。

通过提供统一认证实现对教育用户的统一认证和统一管理，并实现与市级统一认证平台的对接。

通过数据交换子系统，实现信息化应用各应用系统之间的数据交换，实现与各种基础服务的对接，并统一为其他系统和平台提供服务整合接口。

通过建立教育数据标准，并以该标准为数据结构依据和接口规范构建教育数据中心。

最终在数据中心数据沉淀的基础上，通过对数据分析和挖掘，为领导分析决策提供辅助支持。

同时对各个业务系统提供多种公共基础应用作为服务支撑，并通过应用基础平台进行集中式、一站式管理。

在设计思路上所有业务平台、业务系统、应用系统间不直接对接，而是按照业务模型将基础应用集中规划为内部聚合、相对独立的应用服务。这些服务和对服务的管理形成系统总线，各系统根据业务需要作为服务或数据的制造者或消费者，与总线对接，各系统间并不直接发生交互，从而实现系统间的解耦；而通过系统总线的方式，对服务的使用进行统一的注册管理、安全管理、权限控制、路由、格式交换和监控等。

附图说明：

图1为本发明的系统组成结构示意图；

图2位本发明的CAS协议过程示意图。

具体实施方式：

如图1-2所示，本具体实施方式采用以下技术方案：

1、教育资源公共服务系统，包括总体设计、框架设计和功能设计。

其中：所述总体设计包括总体框架设计、技术框架设计和企业服务框架设计；

2.1、总体设计是根据本项目的业务特点，为使整个信息系统规范化、系统化、整体化，增加应用系统独立性、可扩展性，提高数据资源的利用率，通过采用最新的网络通信技术、软件定制及复用技术、信息安全技术，总体框架设计包括网络基础设施、信息资源中心、共享交换平台、应用层和展示层；另外安全与管理体系贯穿在整个建设过程中；

2.1.1、展示层：展示层通过建立综合信息集成门户系统为用户提供统一的用户界面，信息和应用通过门户层实现统一的访问入口和集中展现；

2.1.2、应用层：应用层提供多样化的定制应用，以提供满足面向各类用户依据实际需求开展业务的需要需求，如学籍管理、教籍管理、校产管理等；

2.1.3、共享交换平台层：共享交换平台层为数据共享交换平台所在位置，连接各类应用和应用所需的信息资源，组织和整合各类数据、组件和服务。数据共享交换平台层为实现应用层各种应用系统的搭建和运行提供支撑服务，包括目录服务系统、交换服务系统、安全服务系统和平台管理系统等；

2.1.4、信息资源层：信息资源层是数据中心，通过定义数据模型，实现数据组织、存储和管理，为共享交换平台层和应用层提供数据服务；

2.1.5、网络基础设施层：网络基础设施层提供各类系统的承载网络、所需的系统软件和硬件设备及其运行环境；

2.1.6、信息安全防护体系：信息安全保障体系贯穿系统建设各个层次。安全体系建设包括物理安全、网络及系统安全、应用及数据安全和安全管理几个方面，通过建设从物理层到应用层的整体安全防御体系，保障系统稳定、可靠、安全地运行；

2.1.7、管理维护体系：本系统应包括完备的管理和维护体系，它可从系统不同的层面实施管理与维护，为各种应用系统提供统一管理与维护基础服务；

2.2、技术框架的设计采用J2EE技术体系，本次建设基于JDK1.6及以上的 J2EE框架为主，同时部分模块也采用了基于FrameWork3.5的.net体系框架建设，所有对外交互部分采用了Web Services协议栈(如：WSDL、WSFL、SOAP等)，人员组织基于LDAP协议进行存储，采用MVC、IoC、AOP设计模式，系统建设框架采用SpringMVC+Hibernate，客户端采用jsp+DWZ；

2.3、企业服务架构包括企业服务框架和企业服务总线，具体如下；

2.3.1、企业服务框架分步骤为前端框架、服务层框架、业务层框架、持久层框架和通用构件库；

2.3.1.1、企业服务框架的表现层框架完全遵照MVC模型设计，利用控制器来分离模型和视图，达到一种层间松散耦合的效果，提高系统灵活性、复用性和可维护性。展现层框架提供了丰富的web组件库，web组件基于ajax技术设计，通过异步模式，提升了用户体验；优化了浏览器和服务器之间的传输，减少不必要的数据往返，减少了带宽占用；ajax引擎在客户端运行，承担了一部分本来由服务器承担的工作，从而减少了大用户量下的服务器负载；

2.3.1.2、请求服务层是一个承前启后的层次，它负责连接展现层和业务领域层，并负责转换两个层次间的数据信息、传递数据等工作，请求服务层还提供了纵向集群和业务路由功能2个核心功能；

2.3.1.3、在业务领域层，我们就是真正实现了让开发者只关注业务逻辑的实现，而不必关注比如事务、资源的生成和释放等等，业务领域层主要由流程控制、过滤器、业务代理对象、业务对象、状态保存、资源控制和事务控制模块组成，对于开发人员而言，他们需要开发的是过滤器和业务对象，也可以选择性的使用业务代理对象，对于资源管理、事务管理和路由控制等与业务逻辑无关的操作，开发人员只需要通过配置文件进行简单的配置，而无需编写任何代码，系统会自动根据开发人员所写的配置文件来自动的对事务、资源等进行管理；

2.3.1.4、对于资源访问层，基础运行框架采用了标准的DAO模式来实现，可以使得持久性存储与业务逻辑完全分开，资源访问层还提供了包括数据库、 LDAP、文件系统等多种数据访问层DAO的实现，使得开发人员在开发的时候只需关注业务逻辑，而无需再考虑数据库、LDAP的结构；

2.3.1.5、通用构件库是一个功能组件的集合，这些组件都是基于基础服务框架，为特定类型的业务应用提供管理控制功能，如缓存管理、定时任务管理、集群管理、线程管理等；

2.3.2、企业服务总线针对ESB进行系统介绍，其中包括ESB的特点、ESB 的架构优势和产品架构；

2.3.2.1、教育部门各级应用呈现业务系统多元化形态：即系统分布多元化，业务功能多元化，部署形态多元化，基础软件产品多元化，而正是这些多元化的特性，要求我们能够从平台层面提供相应解决方案，使得各部门业务系统、各级别业务系统能够联动应用，能够以最小的成本快速的响应业务；

ESB是一种在松散耦合的服务和应用之间进行集成的标准方式，是在SOA架构中实现服务间智能化集成与管理的中介，通过这种标准化的方式，很容易将呈现多元化形态的各个业务系统ESB是逻辑上与SOA所遵循的基本原则保持一致的服务集成基础架构，它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能，同时，其也提供了服务的监控、统计、服务的发现等功能；

ESB系统中将集成的对象统一到服务，消息在应用服务之间传递时格式是标准的，这使得直接面向消息的处理方式成为可能，ESB能够在底层支持现有的各种通信协议，这样使得开发人员对消息的处理就可以完全不必考虑底层的传输协议，可以将所有的注意力都集中到消息内容的处理上来，使得在ESB中，对消息的处理就会成为ESB的核心，因为通过消息处理来集成服务是最简单可行的方式。这也是ESB中企业服务总线功能的体现；

业务和数据的快速集成工作使用ESB来完成，应用ESB，可以完成以下功能：

A、能够迅速的挂接基于不同协议传输，使用不同语言开发的系统；

B、被接入的各个系统都以独立的，松耦合的服务的形式存在，具有良好的扩展性和可延续性；

C、数据在各个系统之间，以一种统一的，灵活的，可配置的方式进行交互；

D、能够以用户友好的方式定义和定制各个系统之间的业务流程，并构建敏捷的业务流程；

E、提供了一套完整的服务治理解决方案，包括服务对象管理、服务生命周期管理、服务的监控及针对服务访问与响应的统计等；

F、封装多种协议适配器，使开发人员能够透明的与基于不同通信协议和技术架构的系统进行交互；

G、能够以用户友好的方式，方便的对服务的生命周期进行管理；

H、应用一定的安全策略，保证数据和业务访问的安全性；

I、能以用户友好的方式进行服务的注册以及管理；

J、支持多种服务集成方式，如：Web服务、适配器等；

2.3.2.2、ESB把最新的整合技术升华到一个基于标准的、经济易用的软件平台产品。ESB与当前市场上存在的、私有的集成方案相比，具有以下的优势：

2.3.2.2.1、扩展的、基于标准的互连技术，ESB包含了一个基于标准的消息系统，使企业内部以及外部整个价值链上的系统之间，可以很容易地通过异步或同步交换信息，ESB通过Web服务、J2EE、.NET和其他标准提供更强的系统互连功能。

2.3.2.2.2、灵活的、基于服务的应用组合、基于面向服务的架构(SOA)，ESB 应用模型允许复杂的分布式应用，包括跨越多个应用程序、系统和防火墙的集成解决方案，由事先开发和测试好的服务灵活组合而成，这为系统提供了易扩展性。

2.3.2.2.3、通过提高重用来降低总体拥有成本(TCO)，SOA方式直接提高了重用程度，降低了维护难度，因而降低了系统的总体拥有成本(TCO)。

2.3.2.2.4、所有这些优势都来源于ESB架构中的每个组件对于通信、互连、转换、移植性和安全性标准的强有力支持。

2.3.2.3、企业服务总线采用企业服务总线产品(企业服务框架ESB)实现，主要分为消息总线、安全管理、消息路由、数据服务、服务治理、运行控制六个子系统；

2.3.2.3.1、消息传输器，目前已经建设的系统是基于不同的协议和技术标准的，在整合的过程中，势必需要这些异构系统能够相互通信，同时又要求对原有系统的影响最小，消息传输器即ESB中封装的，用来在各个业务系统间传递消息的功能组件，消息传输器封装了消息传输的细节，使得被集成系统的传输协议和开发语言对于用户来说是透明的，消息通道中封装了与不同类型系统交互的细节，针对不同的系统建立相应的传输通道，同时对外提供统一API，以实现协议和语言无关的特性，这就使得已有的各个系统能够以统一的方式进行通信；

企业服务框架ESB中已支持以下类型消息通道：

Email：包括Smtp&Smtps、Pop3&Pop3s、Imap&Imaps；

File：支持Windows以及Unix文件系统接入到ESB总线中；

FTP：支持直接将FTP服务接入到总线中；

Http：支持将已有的Http或者Https服务接入到总线中；

JDBC：支持将已有的JDBC数据源接入到总线中；

JMS：支持将已有的Java消息系统接入到总线中；

Quartz：支持将已有的定时器服务接入到总线中；

RMI：支持将已有的RMI系统接入到总线中；

SSL：支持将已有的SSL系统接入到总线中，并能够使消息的消费者能够以透明的方式对其进行访问；

TCP&UDP：支持已有的基于UDP或者TCP协议的系统接入到总线中；

WSDL：可以将已有的基于WSDL的服务(如webService)接入到系统中；

BPM：可以将已有的BPM应用接入到总线中；

2.3.2.3.2、路由器，教育业务系统的业务具有一定的灵活性，即会随着形势的变化调整业务规则，这就要求产品能够适应业务变化的灵活性，且能适应这一灵活性，路由器用来寻址服务，并应用消息传输器，将消息正确的发送到服务提供者，消息路由对于客户是透明的，客户只需调用统一的API，系统会自动完成寻址功能；

2.3.2.3.3、消息收发，消息的收发是ESB的主要功能之一，集成到企业服务总线上的各种服务，或者消费消息，或者提供消息，即或者接收消息，或者发送消息，各个业务系统间需交换信息，企业服务总线中提供一套完整的适配器，供开发人员调用，该适配器也是协议无关性用户体验的表现，开发人员只需使用统一的API，即可完成与不同类型系统的通信工作；

2.3.2.3.4、过滤器，消息的通道的路由与建立都需要耗费一定的资源，使用过滤器可以使某些请求在建立消息通道之前即被拦截，节省资源，

用户通过过滤器注册页面注册过滤器，注册完成之后，当进行收发消息操作消息时，过滤器将会被自动应用；

2.3.2.3.4、转换器，转换器是ESB的基础组件之一，其主要用来转换在不同应用系统之间传递的消息中包含的数据的格式，此消息中可能会携带诸如字符串，XML文档或者二进制数组之类的数据，对于这些数据，消息消费者并不一定能够“理解”，因此需要借助于该适配器，将数据转换为消费者能够理解的形式，用户通过转换器注册页面注册转换器，注册完成之后，当用户使用ESB提供的适配器进行消息的收发时，注册的转换器会被自动应用，不需要编写任何代码，

2.3.2.3.5、服务治理平台，服务治理是SOA规范中的一个重要内容，它包括技术、管理、实施等各个方面，ESB作为SOA架构下进行EAI的最佳方式，其也需要具备相关功能；

2.3.2.3.6、服务注册，应用ESB，可以通过简单的可配置的方式，将注册后的服务数据保存到关系数据库，LDAP或者UDDI中，同时通过简单的配置，即可将数据存储到已有的UDDI注册表中，即使该UDDI注册表由另外不同的系统进行维护(如各种主流的商用注册表，JBOSS ESB维护的UDDI注册表等)；

2.3.2.3.7、服务的发现及查找，服务消费者在请求相应的服务之前，需发现已经注册到企业服务总线中的服务，才能进行相应的调用，服务的发现及查找是调用的前提，企业服务总线中注册的服务可能存储在不同的实体中，发现和查找模块需要能够方便的发现存储于不同实体中的服务，提供基于不同条件的查找以及发现策略，如根据服务类型、服务所有者名称、注册时间、服务状态等条件进行查找；

2.3.2.3.8、服务的生命周期管理，在SOA技术体系中，服务一直都处于不同的生命周期中，处于不同生命周期的服务对请求的响应不同，如处于活动状态的服务可以响应服务消费者的请求，而处于计划状态的服务，却不能响应服务消费者的请求；

2.3.2.3.9、服务统计及监控，为确保系统挂接到总线上的各个系统稳定、安全的运行，需建立统一的服务资源监控以及统计系统，实现系统之间分布、跨系统的服务监控与访问、响应统计，以保证服务稳定安全的运行，包括服务状态的实时在线监控，服务响应情况统计，服务历史状态查询，越权访问等，服务的状态不是一成不变的，服务的运行状况也可能随着时间的推移、运行环境的变化而变化，为确保服务能够正确的、迅速的、高效的响应客户请求，需要对服务进行监控，如监控其平均响应时间，负载是否均衡，是否存在停机情况等，企业服务框架ESB提供了友好的用户界面，针对于以上几种情况进行监控，并将结果以图形化的形式展现出来，并在产生重大影响之前发出警告，并预测使用率会变的更高的服务，以为期提高更大的容量；

2.3.2.3.9、安全与权限管理，在网络和信息化建设高速发展的今天，安全成为越来越重要的话题。经过多年的发展，安全领域形成了一系列的解决方案，这些方案包括基于用户名密码的身份权限认证，基于数字证书的身份权限认证以及基于WS-*的服务安全认证，ESB提供了一套独立于应用系统的服务权限认证模型，对服务消费者身份进行验证，该服务权限认证模型独立于任何的应用系统，正是基于该点，ESB可以方便的与任何应用系统的权限进行整合，而不会对原有系统进行任何变动，ESB真正实现了与应用系统的解耦合，企业服务框架ESB 实现了WS-*标准，保证了消息在传输的过程中的安全性，并且降低离线攻击的风险，同时企业服务框架ESB为使用数字证书提供了接口，当应用系统使用数字证书时，也可以很方便的与企业服务框架ESB进行整合，而不需要对原有系统进行任何改动，企业服务框架ESB还提供对数据交换时数据加密功能，包括XML 数据加密功能，XML数据签名功能；

2.3.2.3.10、运行控制，业务系统接入到总线以后，需要能够对服务监控，如监控服务的状态，服务的访问量、被访问量，响应时间、内存占用率、CPU使用情况、是否出现异常情况等，企业服务框架ESB提供了图形化的用户界面对以上信息进行监控，主要功能是集中配置和管理ESB网络中及分布在整个网络上不同的服务器；监控ESB网络上各种事件，日志，以及各个服务器的性能，系统信息和已经部署的服务；对计算机设备运行活动的完全记录和描述；对日志数据进行采集、汇聚、存储、归档、分析和报警、监控、自动化的手段；监视系统状态、追踪系统问题；可以根据监控数据对服务进行调整，对硬件环境进行调整，对服务流程进行优化等等；统计分析在运行控制中扮演了非常重要的角色，统计分析工作主要是对系统运行过程中产生的一些数据进行统计，并以一定的方式展现给用户，供用户决策使用，使用企业服务框架ESB，用户可以手动配置要对哪些运行过程中产生的数据进行统计，并以图形化界面方式展示给用户。

其中，本系统应是高度组件化的系统，具备对行业方案的自适应性，也就是说，首先应该是一组可重用的组件以及将这些组件组合成一个产品的规则；其次才是一个可运行的软件版本，本系统应该提供一系列关于监控业务的原语级的抽象，这些抽象构成软件业务功能层，在业务功能层之上才是对用户的呈现，它必须遵循业务和呈现严格分离的原则，实现高内聚低耦合，本系统应是一个高度可扩展的系统，他需要具备与任意系统的对接能力和方便的扩展能力，在系统的部署上要将基本功能(基本不变)和行业功能(不断变化)在物理上隔离，本系统应是一个容易理解的系统，作为一个软件产品，特别是作为一个行业试点型的产品，可维护性是第一位的，可维护的必要条件就是容易理解，进一步容易开发，最终容易维护。我们无法回避复杂，因为软件所要解决的问题本身就是复杂的，但是我们可以拒绝繁琐，力求简洁、明晰，本系统应是一个可实现快速功能开发的框架，只有快速的响应用户需求才能更大的体现软件的价值；

3.1、本系统采用J2EE应用结构，分为以下六层：

3.1.1、表现层：由JSP页面组成；

3.1.2、MVC层：使用SpringMVC框架技术；

3.1.3、业务逻辑层：使用业务逻辑组件构成；

3.1.4、DAO层：使用DAO组件构成；

3.1.5、Hibernate持久层：使用Hibernate框架技术；

3.1.6、数据库层：使用SQLServer2008R2数据库存储数据；

3.2、按工程模块部署，整个项目由多个JAVA工程构成，每个工程对应一个 JAR包，在web主工程中，通过maven依赖，自动加载；

3.3、工程模块规划，包括如下步骤：

A、核心工程：作为一个独立的jar包，不依赖于系统其他任何工程，可以被其他工程引用，包含所有全局常量、变量，通用方法，统一基类实体，类型定义，缓存处理，日志处理，异常拦截，字典池，数据源获取，模块菜单定义等。与本项目平台的环境无关。

B、服务类工程：依赖于核心包，实现数据处理，以及接口服务的一种jar 包，不同的服务类工程之间可以相互依赖，但必须在本项目平台的环境下运行；

C、业务子工程：这种工程通常是针对业务或功能子系统来定义的，实现业务处理流程，每个业务子系统根据需要，可以细分定义自己的服务类工程，为外部系统共享接口服务，可以在不同子工程之间是不允许相互依赖引用，同时也必须在本项目平台下运行；

D、Web工程：顾名思义，可以在浏览器下运行的工程，Web工程是由各种业务子系统整合而来的，每个业务子系统在web工程下都是可插拔的。

其中，所述功能设计包括程序架构设计，系统模块设计和基础平台：

4.1、程序框架设计分为3层结构：

A、底层为系统的核心层，包括系统的核心功能(数据访问，接口定义，通用方法定义等)，数据抽取、转换引擎，数据对象交换引擎等，标签库类，这一层次与本系统平台无关，可以作为一种公共模块，引用到各种项目里；

B、服务层：是在核心层的基础上，实现本系统的数据逻辑处理，本层次为应用层提供服务接口；

C、应用层：各业务系统、应用系统以模块化插件的形式，注册到平台上，利用平台的数据、权限等资源，实现与平台的耦合运行；

4.2、系统模块设计

4.3、基础平台：

4.3.1、SSO统一认证采用CAS+Shiro+Spring框架，CAS包含两个部分：CAS Server和CAS Client，CAS Server需要独立部署，主要负责对用户的认证工作；CAS Client负责处理对客户端受保护资源的访问请求，需要登录时，重定向到CAS Server，图2是CAS最基本的协议过程。

CAS Client与受保护的客户端应用部署在一起，以Filter方式保护受保护的资源，对于访问受保护资源的每个Web请求，CAS Client会分析该请求的 Http请求中是否包含Service Ticket，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的CAS Server登录地址，并传递Service(也就是要访问的目的资源地址)，以便登录成功过后转回该地址，用户在第3步中输入认证信息，如果登录成功，CAS Server随机产生一个相当长度、唯一、不可伪造的Service Ticket，并缓存以待将来验证，之后系统自动重定向到Service 所在地址，并为客户端浏览器设置一个Ticket Granted Cookie(TGC)，CASClient在拿到Service和新产生的Ticket过后，在第5，6步中与CAS Server进行身份合适，以确保Service Ticket的合法性，实现统一认证功能，分为两部分：一是，为应用系统认证提供一套API，通过API访问CAS服务器；二是，实现CAS认证服务器，为应用系统获取，并验证票据。

4.3.2、CAS接口

获取TGT票据，发送POST请求到/v1/tickets POST/v1/tickets HTTP/1.0

，参数：username＝登录名password＝密码，使用得到的TGT票据获取ST 票据POST/cas/v1/tickets/{TGT id}HTTP/1.0，参数service＝{form encoded parameter forthe service url}，参数为:service＝encoded地址，根据ST 票据获取用户信息，GET/proxyValidate，返回xml格式用户信息；

4.3.3、Shiro Security

Subject是安全领域术语，除了代表人，它还可以是应用，在单应用中，可将其视为User的同义词；

Principal是Subject的标识，一般情况下是唯一标识，比如用户名；

Role和Permission分别代表了不同粒度的权限，从上图中可以看出Role 的粒度更大些，Permission代表了系统的原子权限，比如数据的修改、删除权限。对于简单的权限应用，可以不需要Permission；

Realm是一个执行者，负责真正的认证和鉴权；

实现应用的安全模块的关键在于：定义合适的role和permission，这就需要遵循如下原则：

role没有实质内容，只是代表一组permission，目的是为了管理的方便，一般都是动态定义；permission一般都是预先定义好的，不允许动态改变，除非源代码改动，它才会变化，它是整个安全模块的基础；要使permission也能动态定义，并非不可能，但是这将使鉴权非常复杂，甚至可能导致鉴权语句遍布整个程序，得不偿失；

4.4、组织机构管理

实现组织机构对组织机构的基本信息进行维护，对组织机构之间的关系进行管理，包括上下级关系、虚拟片区关系等等；

模块入口：

平台管理→系统管理→组织机构；

4.5、机构体系管理，组织机构关系默认存在一套以人事行政职能作为参考的关系，在系统运行中，根据业务需要，或者处于管理方便考虑，可以根据实际的指导管辖来进行重新划分组织机构上下级关系，也就是说，一个组织可能有几个上级组织；

模块入口：

平台管理→系统管理→机构体系管理

4.6、字典管理

字典表和字典项修改页面的入口，都是从字典表信息的列表上面链接进入，显示的页面分为上下两部分，上面显示的是本字典表的信息，同时，有一个添加字典项的按钮，下面显示的是本字典表具体字典内容记录列表，列表包含修改和删除字典项的操作；

模块入口：

平台管理→系统管理→字典管理

4.7、用户管理，实现对非系统人员获取系统操作，成为用户的操作方式管理，包含填写注册信息，提交注册申请，注册审过、注册查询等功能；

模块入口：

分级管理→系统管理→注册用户管理

状态管理

实现对系统用户的状态进行统一管理，根据不同业务需求，可对系统用户状态进行修改；

模块入口：

分级管理→系统管理→用户管理

密码管理

实现系统用户密码的统一管理，根据不同需求，可对系统用户密码进行重置、修改；

模块入口：

分级管理→系统管理→用户管理

分配权限

通过对用户分配不同的角色和岗位，赋予用户相应的系统操作权限，可针对实际业务变化，对系统用户的权限进行修改；

模块入口：

分级管理→系统管理→用户管理

权限管理

根据系统操作需要，及实际业务要求，设定相应的角色，并赋予角色对应的操作权限，角色为拥有相同业务权限的一类用户，通过角色管理，实现对不同用户群权限进行管理；

模块入口：

分级管理→权限管理→角色管理

岗位管理

根据系统操作需要，及实际业务要求，设定相应的岗位，并赋予岗位对应的操作权限，岗位为拥有相同业务岗位的一类用户，通过岗位管理，实现对不同用户群权限进行管理；

模块入口：

分级管理→权限管理→岗位管理

分组管理

分级管理，可对不同组的级别进行定义，通过制定不同组的授权管理员，实现对权限管理的下放，分解任务的同时，也减轻了权限设置人员的工作量；

模块入口：

分级管理→权限管理→分组管理

分级功能管理

对权限下放管理组的权限进行分配，划分权限范围，并分配人员，通过所选定人员，完成对下级权限管理要求；

模块入口：

分级管理→权限管理→分级功能管理

本发明的使用状态为：本发明教育资源公共服务系统，平台管理是教育信息化应用平台的核心部分，提供统一的基础平台，实现与现有业务系统的集成和整合。

通过提供统一认证实现对教育用户的统一认证和统一管理，并实现与市级统一认证平台的对接。

通过数据交换子系统，实现信息化应用各应用系统之间的数据交换，实现与各种基础服务的对接，并统一为其他系统和平台提供服务整合接口。

通过建立教育数据标准，并以该标准为数据结构依据和接口规范构建教育数据中心。

最终在数据中心数据沉淀的基础上，通过对数据分析和挖掘，为领导分析决策提供辅助支持。

同时对各个业务系统提供多种公共基础应用作为服务支撑，并通过应用基础平台进行集中式、一站式管理。

在设计思路上所有业务平台、业务系统、应用系统间不直接对接，而是按照业务模型将基础应用集中规划为内部聚合、相对独立的应用服务，这些服务和对服务的管理形成系统总线，各系统根据业务需要作为服务或数据的制造者或消费者，与总线对接，各系统间并不直接发生交互，从而实现系统间的解耦；而通过系统总线的方式，对服务的使用进行统一的注册管理、安全管理、权限控制、路由、格式交换和监控等。

以上显示和描述了本发明的基本原理和主要特征和本发明的优点，本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内，本发明要求保护范围由所附的权利要求书及其等效物界定。

Claims (4)

1.教育资源公共服务系统，其特征在于，包括总体设计、框架设计和功能设计；所述总体设计包括总体框架设计、技术框架设计和企业服务框架设计；所述框架设计包括J2EE应用结构、工程模块部署以及工程模块规划；所述功能设计包括程序架构设计，系统模块设计和基础平台。

2.根据权利要求1所述的教育资源公共服务系统，其特征在于：

2.1、总体框架设计包括网络基础设施、信息资源中心、共享交换平台、应用层和展示层；另外安全与管理体系贯穿在整个建设过程中；

2.1.1、展示层：展示层通过建立综合信息集成门户系统为用户提供统一的用户界面，信息和应用通过门户层实现统一的访问入口和集中展现；

2.1.2、应用层：应用层提供多样化的定制应用，以提供满足面向各类用户依据实际需求开展业务的需要需求，如学籍管理、教籍管理、校产管理等；

2.1.3、共享交换平台层：共享交换平台层为数据共享交换平台所在位置，连接各类应用和应用所需的信息资源，组织和整合各类数据、组件和服务，数据共享交换平台层为实现应用层各种应用系统的搭建和运行提供支撑服务，包括目录服务系统、交换服务系统、安全服务系统和平台管理系统等；

2.1.4、信息资源层：信息资源层是数据中心，通过定义数据模型，实现数据组织、存储和管理，为共享交换平台层和应用层提供数据服务；

2.1.5、网络基础设施层：网络基础设施层提供各类系统的承载网络、所需的系统软件和硬件设备及其运行环境；

2.1.6、信息安全防护体系：信息安全保障体系贯穿系统建设各个层次。安全体系建设包括物理安全、网络及系统安全、应用及数据安全和安全管理几个方面，通过建设从物理层到应用层的整体安全防御体系，保障系统稳定、可靠、安全地运行；

2.1.7、管理维护体系：本系统应包括完备的管理和维护体系，它可从系统不同的层面实施管理与维护，为各种应用系统提供统一管理与维护基础服务；

2.2、技术框架设计采用J2EE技术体系，本次建设基于JDK1.6及以上的J2EE框架为主，同时部分模块也采用了基于FrameWork3.5的.net体系框架建设；

2.3、企业服务架构设计包括企业服务框架和企业服务总线，具体如下；

2.3.1、企业服务框架分步骤为前端框架、服务层框架、业务层框架、持久层框架和通用构件库；

2.3.1.1、企业服务框架的前端框架完全遵照MVC模型设计，利用控制器来分离模型和视图，达到一种层间松散耦合的效果；

2.3.1.2、请求服务层是一个承前启后的层次，它负责连接展现层和业务领域层，并负责转换两个层次间的数据信息、传递数据等工作，请求服务层还提供了纵向集群和业务路由功能2个核心功能；

2.3.1.3、业务领域层主要由流程控制、过滤器、业务代理对象、业务对象、状态保存、资源控制和事务控制模块组成；

2.3.1.4、对于持久层，基础运行框架采用了标准的DAO模式来实现，可以使得持久性存储与业务逻辑完全分开，资源访问层还提供了包括数据库、LDAP、文件系统等多种数据访问层DAO的实现；

2.3.1.5、通用构件库是一个功能组件的集合，这些组件都是基于基础服务框架，为特定类型的业务应用提供管理控制功能；

2.3.2、企业服务总线针对ESB进行系统介绍，其中包括ESB的特点、ESB的架构优势和产品架构；

2.3.2.1、ESB是一种在松散耦合的服务和应用之间进行集成的标准方式，是在SOA架构中实现服务间智能化集成与管理的中介；

2.3.2.2、ESB把最新的整合技术升华到一个基于标准的、经济易用的软件平台产品。ESB与当前市场上存在的、私有的集成方案相比，具有扩展性和灵活性的优势；

2.3.2.3、企业服务总线采用企业服务总线产品(企业服务框架ESB)实现，主要分为消息总线、安全管理、消息路由、数据服务、服务治理、运行控制六个子系统。

3.根据权利要求1所述的教育资源公共服务系统，其特征在于：

3.1、本系统采用J2EE应用结构，分为以下六层：

3.1.1、表现层：由JSP页面组成；

3.1.2、MVC层：使用SpringMVC框架技术；

3.1.3、业务逻辑层：使用业务逻辑组件构成；

3.1.4、DAO层：使用DAO组件构成；

3.1.5、Hibernate持久层：使用Hibernate框架技术；

3.1.6、数据库层：使用SQLServer2008R2数据库存储数据；

3.2、本系统采用工程模块部署，整个项目由多个JAVA工程构成，每个工程对应一个JAR包，在web主工程中，通过maven依赖，自动加载；

3.3、本系统采用工程模块规划，包括如下步骤：

A、核心工程：作为一个独立的jar包，不依赖于系统其他任何工程，可以被其他工程引用；

B、服务类工程：依赖于核心包，实现数据处理，以及接口服务的一种jar包，不同的服务类工程之间可以相互依赖，但必须在本项目平台的环境下运行；

C、业务子工程：这种工程通常是针对业务或功能子系统来定义的，实现业务处理流程；

D、Web工程：顾名思义，可以在浏览器下运行的工程，Web工程是由各种业务子系统整合而来的，每个业务子系统在web工程下都是可插拔的。

4.根据权利要求1所述的教育资源公共服务系统，其特征在于：

4.1、程序框架设计分为3层结构：

A、底层为系统的核心层，包括系统的核心功能，数据抽取、转换引擎，数据对象交换引擎等；

B、服务层：是在核心层的基础上，实现本系统的数据逻辑处理，本层次为应用层提供服务接口；

C、应用层：各业务系统、应用系统以模块化插件的形式，注册到平台上，利用平台的数据、权限等资源，实现与平台的耦合运行；

4.2、系统模块设计包括系统管理、分级管理、应用管理和日志管理；

4.3、基础平台：

SSO统一认证采用CAS+Shiro+Spring框架，CAS包含两个部分：CAS Server和CASClient。