面向资源整合的党校教务管理系统的设计与实现

　　摘要：本文提出通过基于SOA的资源整合框架和运用信息模型研究来实现教育资源的整合，从面向服务架构及相关技术出发，深入分析了资源整合的目标，并以该目标出发，分析教务管理的业务逻辑需求；结合并应用SOA的技术特点，分析了为满足业务逻辑需求在SOA框架下实现信息资源整合的可行性，并给出了实现信息整合的框架模式；详细分析并阐述了实现基于SOA的教育资源整合的关键过程；最后完成对原校园内的信息资源的整合。
　　关键词：面向服务架构 Web 教务管理 资源整合
　　中图分类号：TP311.5 文献标识码：B 文章编号：1007-9416（2013）06-0155-03
　　1 研究背景
　　搬迁了新校舍，业务量更大了，各类不同部门使用的校园信息系统，都需要存储和管理大量的数据，使得以下几个问题日益突出：
　　信息海量：信息数量多、容量大，需要高性能的存储、检索和分发管理技术；信息复杂：信息加工在存储、检索、过滤、提取、挖掘、分析等方面，相对结构化数据而言，具备独特的复杂性；信息孤岛：各个部门都有自己的应用系统，每个都有自己的数据库、自己选择的操作系统、自己开发的应用软件和用户界面，完全是独立的体系；个性化：信息个性化增值服务方面存在广泛需求，更是信息化应用的热点。要解决这些难题，最节省人力物力的办法就是，在改造和完善教务信息管理的基础上结合一种通用且有效的架构——面向服务架构[1][2]（SOA），建立一个面向资源整合的党校教务管理平台。该平台以实现学校教务管理信息化为目的，以基于部门协同工作的教务管理工作为核心，采用基于Web的软件系统为工具全面实现信息和资源的整合，达到全面管理的目的。
　　2 关键技术
　　2.1 面向服务的体系结构/面向服务架构（SOA）
　　SOA[3]——Service-Oriented Architecture，面向服务架构[4][5]，它可以被看成一种面向服务的组件模型，是为了在解决在Internet环境下应用业务集成问题的一种软件系统架构。XML Web Services标准的出现，使得SOA成为“现代应用开发领域最重要的课题”。SOA具有以下几个特点：业务驱动；松散耦合；明确定义的接口；遵循开放标准和协议的远程调用。它描述了一套完善的开发模式来帮助客户连接到服务上。因为几乎所有的通信中间件系统都有固定的处理模式。而服务既可以定义为功能，又可对外定义为对象、应用等。这使得面向服务架构（SOA）可适应于任何现有系统，并使得系统在集成时不必刻意遵循任何特殊规则。
　　2.2 Web服务
　　Web[6]服务即Web Service技术，是描述一些操作（利用标准化的XML消息传递机制可以通过网络访问这些操作）的接口。Web服务是用标准的、规范的XML概念描述的，称为Web服务的服务描述。这一描述囊括了与服务交互需要的全部细节，包括消息格式（详细描述操作）、传输协议和位置。该接口隐藏了实现服务的细节，允许独立于实现服务基于的硬件或软件平台和编写服务所用的编程语言使用服务。简单的说，Web服务是一种开发的规范，使得通过网络可以对基于规范开发的各种应用进行调用、整合，从而在互联网上完成更复杂的任务。关于Web 服务的几个底层标准协议业界已经基本达成共识，包括XML、SOAP、WSDL、UDDI等。
　　2.3 J2EE技术
　　J2EE 是基于Java技术的一整套企业应用开发标准和规范以及同硬件无关的运行时环境，能够为开发的系统带来显著的可移植性、重用性、伸缩性、易于维护性，并能简化系统的结构以及提高系统的开发效率[7][8]。它提供了编写一次，随处运行的可移植性，遵循J2EE标准的所有服务器都支持该模型。另外，J2EE还支持异构环境。基于J2EE的应用程序不依赖任何特定操作系统、中间件或硬件，因此设计合理的基本J2EE的程序只需开发一次就部署到各种平台。J2EE平台由一整套服务（Services）、应用程序接口（APIs）和协议构成，它对开发基于Web的多层应用提供了功能支持。
　　3 系统设计与实现
　　教务管理系统主要是为了完成日常教学任务而开发的，其主要目标浊对学生个人信息、师资信息、教学资源信息、课程信息等进行管理及维护，减轻教学工作的压力，提高教学管理工作的效率。
　　3.1 系统基本的功能模块
　　3.2 基于SOA的信息整合框架模式
　　如图2所示，在SOA的应用机制下，为实现对校园的各类信息资源进行整合，整合框架主要由三层组成：业务数据供应层，业务服务处理层和业务应用接口层组成[9-12]。
　　用SOA框架，主要通过构建Web Service方式在原有的应用系统的基础上完成信息整合[13-16]，在这个过程中，根据业务的需要，完成分析所有业务对每个原有的数据库所需抽取的数据信息后，为每个原有的数据库构建一个富含一个或多个具备数据抽取及数据格式转换接口的业务数据适配器，每个数据适配器充当了一个数据库对外提供数据的转换接口；然后根据业务逻辑将进一步构建Web Service实现从这一个或多个业务数据适配器按SOA框架组合成对应的业务逻辑服务；最后通过业务应用实现与用户交互。
　　3.3 构建业务数据转换接口
　　该过程主要是根据业务的需求，经过业务逻辑需求分析后，构建应用系统中不存在，但新业务所需的数据库，并为原有应用系统中的数据库构建业务所需数据的数据转换接口Web Service。构建业务数据转换接口的核心工作是根据原子业务数据设计实体类，系统的实际工作其实是由业务逻辑类执行的，实体类和业务逻辑类的设计工作的基础分别是构建原子业务数据和业务逻辑需求分析。
　　3.4 构建业务逻辑服务
　　构建业务逻辑服务与构建业务数据适配器相类似，前者在设计中主要是设计实体类，后者主要是设计控制类。控制对象负责管理并协调大部分业务操作；控制对象还封装与用户界面问题（边界对象）或数据工程问题（实体对象）没有特殊关系的逻辑。这一逻辑有时也称为应用逻辑或业务逻辑。