基于SOA架构的数字校园解决方案与实现

基于SOA架构的数字校园解决方案与实现朱震 姚奇富（浙江工商职业技术学院网络中心，宁波 ）摘要：本文分析了传统数字校园解决方案和建设模式存在的问题，在深入探讨面向服务的框架模型原理的基础上, 提出了基于面向服务架构的数字校园解决方案，给出了一个面向服务的校园网络应用框架。并结合实践项目,详细阐述了基于SOA的校园应用系统集成的方法和步骤，充分论证了基于SOA的数字校园解决方案的可行性及优越性。关键词：面向服务框架；数字校园；Web服务Research and realization of digital campus based on SOAZHU Zhen, YAO Qi-fu(Network Center, Zhejiang Business Technology Institute, Ningbo )Abstract: This paper analyzed the deficiency of traditional digital campus solution and put forward a new solution of digital campus system based on SOA. After analyzing the principle of Service-Oriented Architecture(SOA), a service oriented digital campus frame was proposed. This paper expatiated the methods and steps of integration based on SOA in detail and has fully proved the feasibility and superiority developed in digital campus system integration based on SOA.Key words: Service-Oriented Architecture(SOA); digital campus; Web Services、数字校园的概念与特点数字校园是以网络为基础，利用先进的信息化手段和工具，实现从环境（包括设备、办公空间、研究空间、教学空间等）、资源（如图书资料及专业数据库、教师讲义和课件、全球网上专业资讯）到活动（包括教、学、科研、管理、服务、办公等）的全部数字化。在传统校园的基础上构建一个既对应又有本质不同的数字空间, 拓展现实校园的时间和空间维度，从而提升传统校园的效率，扩展传统校园的功能，最终实现电子校务（信息发布平台、办公自动化、数据中心、集成的信息系统）、教育资源（网上教学、数字图书馆等）、虚拟社区（后勤服务、校园一卡通等）、网络服务与网络安全为一体的数字化教育环境。数字校园由网络基础设施、网络基础服务、应用系统、信息服务系统、门户平台5大系统构成。网络基础设施（数字传输载体、交换设备、服务器群、存储（NAS）设备，入侵检测（IDS）、防病毒（AntiVirus）、SAN备份系统、计算机终端等）门户平台（身份认证、统一访问接口、个性化用户界面）信息服务系统（信息发布、信息查询与交换、站群（主页集中）管理、搜索引擎）应用系统(办公系统、数字图书馆、管理信息系统、网络教学系统、一卡通系统、后勤服务系统)网络基础服务（电子邮件、BBS服务、文件传输、视频会议、目录服务、公共数据库、虚拟主机、代理服务）图数字校园构成图数字校园建设的特点主要表现在：（）需要集成的业务系统数量众多，包括教学平台、教务管理系统、学工管理系统、办公自动化系统等，覆盖了学校日常教学、科研、管理等一系列工作。（）由于校园内的应用系统是在很长一段时间内逐步建立起来的，系统结构复杂，构建各类应用系统所采用的技术差别大、标准不统一、架构复杂，为数字校园统一平台的建设带来了巨大的困难。（）校园应用系统的服务对象包括教师、学生、校外人员等，受众面大。一方面，经常由于业务逻辑或业务流程变化等原因导致应用系统本身的变化和修改；另一方面，经常有新的应用系统需要被集成。这些造成了系统结构的不稳定，需要数字校园具备对业务系统变化的快速适应和协调能力。、基于SOA架构的数字校园解决方案的可行性.传统数字校园解决方案数字校园是企业应用集成（Enterprise Application Integration, EAI）的典型案例。传统数字校园的建设模式主要有以下几类：（）接口集成模式数字校园需要解决的问题是独立应用系统之间的连接，传统的应用系统之间常见的连接方式包括：CORBA、SOCKET通讯、RMI、RPC、EJB、COM/COM+、HTTP和FTP等，数据库系统之间常见的连接规范包括：ODBC、JDBC。上述这些规范在企业应用系统或数据库系统之间传统的点对点的连接中得以广泛应用。但是由于这些系统之间的连接是通过上述连接接口实现的，缺乏一定的规范和标准，使得在今后新系统的加入和旧系统的移植过程中，会产生接口兼容性问题。而且，随着应用系统的逐渐增加，体系结构变得越来越庞大，系统复杂程度将呈几何级增长。（）应用集成模式应用集成模式通过适配器技术将原有数据库系统、应用系统和原有网络服务组件封装起来，实现系统之间的互通互联。集成厂商为了解决系统之间的连接而开发的可重用的、统一的适配器，通过该适配器每一个应用系统仅需要与业务整合平台相连，而不需要与每个与之交互的应用系统相连。从数据集成的角度来看，该模式的主要问题在于缺乏一种对数据格式的统一描述方法，导致信息载体所采用的数据封装形式有所不同，无法保证经过转换后的目标数据能够完全准确地表达源数据的信息，容易造成信息的丢失；此外，缺少一个全局的语义完整性控制，在应用整合层面上解决由于各局部数据库的异构性而引起的数据对象的命名、数据的格式以及数据结构等方面的不一致问题，无法为全局用户提供全局数据信息的集成和统一的表示。另一方面，这类集成住住由厂商主导完成，这些厂商使用的都是各自专有的集成引擎, 使用专有的适配器来连接各个应用，使用专有的技术来集成系统，因此缺乏清晰的体系结构，无法重用另外厂商的集成，使得数字校园的扩展性受到限制，在集成的同时又面临更大的集成问题，造成为集成而集成的状况。（）界面集成模式界面集成模式是应用系统与用户实现人机交互在表示层面上的扩展，通过使用一个统一的界面（典型的是基于浏览器的界面）代替所有系统的界面来访问原有的系统。该模式更多的是一种系统用户数据或展示内容的集成，如Portal、单点登陆（Single Sign On）、用户统一管理、用户认证授权管理等。界面集成模式的问题在于浏览器的应用存在使用界面不友好，无法离线操作等缺点，且对非B/S结构的应用系统无能为力，往往需要对应用系统进行二次开发来满足界面展示和门户应用的需要，建设成本过高。在数字校园的实际构建过程中，既有采用一种模式实现集成，也有采用混合模式来实现的。但是，由于传统数字校园建设固有模式和方法的局限，无法将所有的应用系统和数据真正实现统一集成，目前所采用的多是重构业务系统或部分系统集成的方式。.面向服务的体系架构面向服务的体系结构SOA（Service-Oriented Architecture, SOA）是一个组件模型, 它将应用程序的不同功能单元通过服务之间定义良好的接口和契约联系起来。接口采用中立的方式进行定义，独立于实现服务的硬件平台、操作系统和编程语言，使得构建在各种系统中的服务可以以一种统一和通用的方式进行交互。SOA包括一套构架的原则和模式，由三部分组成：服务提供者、服务消费者和注册中心。基于SOA的EAI将原有系统的功能封装成服务，通过调用服务完成不同系统间的信息共享，达到应用整合的目的。这是一种较高层次的整合，使得应用集成不再关注于底层的实现细节，应用系统成为真正的“黑箱”。目前，实现SOA架构主要使用的技术是Web服务，Web服务是架构在XML技术上，基于标准体系的组件化松散耦合技术，采用的核心技术包括SOAP、WSDL、UDDI 等标准协议，其目标是实现不同系统间跨平台、跨编程语言的可互操作性，实现在当前环境下最高的可集成性，如图所示。图基于Web服务技术的SOA架构图SOA使得数字校园的实现成为了可能。通过采用SOA框架，可以最大程度地减少系统间的耦合，提高重用性。主要表现在以下几个方面：（）SOA体系架构通过在应用系统的对外接口上采用统一的对象模型进行封装，使原有的应用系统无需更改即可兼容不同的平台、语言和对象模型。应用系统在集成时无须提供多种接口来进行集成双方的对接，避免了资源的重复部署。而且，即使业务系统发生变化，也无须在后期对集成框架进行更改。（）SOA提供了一种松散耦合的机制。通过使用HTTTP、XML、SOAP等标准协议，应用系统只需理解一种通用的对象接口就可以集成并调用其它的网络服务，而无需考虑服务的内部实现机制、操作平台、开发语言等细节。而且，当Web服务产生了接口或功能上的更改，调用方也可以通过Web服务的描述性文档（WSDL），及时地发现并自动适应这样的更改。（）UDDI注册中心以Web服务的方式存放所有应用实体的信息和交互参数，系统可以通过自发的无人参与的方式，发现并且集成新的应用系统及其提供的新服务。只要Web服务的提供者在UDDI注册中心登记了自己所提供的Web服务描述信息，就可以被任何其它Web服务的请求者发现并利用。SOA将传统数字校园的数据集成模式转变为应用系统之间基于标准协议对话的模式，使应用系统可以通过校园网进行数据、信息及服务的交换。通过采用Web服务技术，服务的内部实现细节被封装在通过SOAP/WSDL传递的信息流之中，解决了异构应用系统之间的信息交换和集成的问题。克服了传统数字校园建设模式集成困难、结构复杂、兼容性差、厂商依赖性大、成本过高等缺陷。、基于SOA架构数字校园的设计图是基于SOA的数字校园平台架构图，系统分为四层，自底向上分别为：应用系统层、服务提供层、公共数据层、用户表示层。图基于SOA的数字校园平台架构图（）应用系统层提高重用性是SOA架构的一个重要目标，为了使原有的应用系统能以一种松散耦合的方式集成，可以将系统封装成Web服务，用统一的方式暴露接口（如一个或多个WSDL），将应用系统原来以各种API形式暴露的接口用WSDL重新描述，并使用HTTP+SOAP的消息传输方式作为与外界交互的桥梁。用Web服务封装应用系统可以屏蔽原有系统的实现细节，消除不同技术之间集成的困难。当系统的业务逻辑或实现技术需要更改时，只要Web服务的WSDL接口不变，服务调用方就不需要作任何改动。（）服务提供层服务提供层是应用系统单个功能和任务的抽象和封装，通过调整服务提供层中不同服务的组合方式，能够摆脱下层应用系统细粒度服务的限制，实现许多全新的业务功能和逻辑，向上为公共数据层提供不同的数据源和数据形式，向下为应用系统层提供数据转换、数据过滤、消息传递等服务。服务提供层功能的实现主要依赖于公共服务总线（Public Service Bus，PSB）和服务引擎（Service Engine）。PSB从应用层提取SOAP消息并提交给Web服务，并把响应信息格式化为SOAP消息发回给服务请求者。PSB采用标准的SOAP协议作为数据传输协议来实现应用系统间的互操作，为Web服务提供适配与接口标准，并通过内部软件模块与元数据来完成管理与控制。服务引擎代表了粗粒度服务的实现，它通过将原应用的API重新组合成具有更粗粒度的服务来代表抽象服务的实体，满足应用的平台无关性、高可用性、扩展性的要求。（）公共数据层相对于传统企业应用系统集成方案来说，数字校园原有应用系统的业务功能本质上是相对独立的，需要实现的功能主要是满足用户表示层数据定制的需求以及系统间数据的共享。因此，公共数据层是构建数字校园最重要的方法和手段，它通过搭建一个数据平台来实现校园内各类应用系统的互通互连和数据共享，并且通过用户表示层的形式将这些应用系统提供的数据和服务集成在一起，供用户访问、利用。公共数据层是一个面向服务、规范统一、灵活可扩的系统，服务于学校的教学、科研、管理和生活等各个方面，通过门户服务、系统集成、数据集中等方式满足学校老师、学生、管理人员等用户的访问和应用需求。（）用户表示层用户表示层是数字校园暴露给最终用户使用的服务，它同样是以Web服务的形式提供。表示层的服务应该比在服务层中的服务具有更粗的粒度，它是应用系统业务流程的入口。在数字校园环境中，用户表示层中提供的服务包括门户服务、统一身份认证服务等，为用户提供单点登陆、界面定制、应用访问、数据展现等功能。在基于SOA的数字校园平台设计中，应用系统层中各个应用的功能被封装为基于统一标准来描述和供访问的服务，借助于PSB的连接能力，不同应用的服务不需要关心对方的位置和实现技术，以松散耦合的方式来完成集成，只要服务的接口描述不变，服务的使用者和提供者双方可以自由发生变化而互不影响。当用户表示层或公共数据层需求发生变化的时候，可以通过调整服务提供层中服务组合的方式来满足这种变化。这种通过重用粗粒度服务而不是在底层编程来开发新应用或新接口以满足业务新需求的方法，使得学校能够以更少的投入、更快的速度、更好的质量来开发、管理和维护应用系统。、基于SOA架构数字校园的实现.服务封装 数字校园的实现很少是从全新的项目开始的，数字校园环境的创建几乎总需要涉及到原有遗留系统的集成问题。在基于SOA架构数字校园的体系结构中，集成的方法是将它们分解成服务、操作、业务流程和业务规则，并根据原有系统提供的功能把它分解成多个Web服务，每个服务都用Web Service技术进行封装。换句话说，从服务使用者的视角去看，只能看到与一个Web服务进行交互，而Web服务背后是使用什么样的技术细节是无需知道的，这样可以屏蔽系统的实现技术，以标准方式将它们集成在一起。如图所示：图服务封装 绑定代理（Binding Proxy）把应用系统的API用WSDL重新描述，使系统具备Web服务的功能，它用HTTP和SOAP作为与外界通讯的消息协议。通过使用绑定代理摆脱了系统具体实现技术的影响，而且，只要绑定代理不变，提供服务的应用可以根据需要进行更改。绑定代理除了方便其它程序调用外，它还提供了系统使用外部Web服务的功能。绑定代理可以将外部Web服务转变成特定语言的API，使得系统使用外部Web服务如同本地程序一样。绑定代理可以与应用系统运行在同一环境下，甚至可以运行在同一台硬件设备上。.PSB数字校园应用系统之间的交互、对话和连接功能主要通过PSB来实现，它主要由部分组成：消息路由器和一系列的Web服务静态客户桩（Stub）程序。如图所示：图PSB结构图（）交互流程 如图所示，消息路由器用于接收应用系统的请求消息，当系统需要使用服务层中的服务时就发送请求消息到消息路由器中，消息路由器根据消息的内容和接收者的信息转发到相应的服务引擎，并将服务的操作结果返回给应用系统，整个过程的消息传递都使用SOAP协议和HTTP协议。当应用系统需要与其它系统交互时不能直接与之通讯，必须通过消息路由器将消息转发给Stub，并激发服务运行，服务是应用系统功能的抽象，激发服务也就是调用应用系统的某个功能，通过这种方式达到系统之间的相互通讯。图交互流程（）消息路由器消息路由器是对所有外界进入服务总线或从服务总线到外界的SOAP消息进行处理和转发，它从发送来的SOAP消息中检查发送者的QName和接收者的QName，然后重新构造一个ServiceMessage对象转发。由于SOAP是基于HTTP协议的，所以可以选用Servlet作为消息路由器。图服务消息Content：消息的内容，是SOAP消息的封装，它使用了javax.xml.soap.SOAPMessage，接收者收到消息后会提取content的内容并加以处理；Sender：消息发送者，也就是发送消息的组件本身，它使用space.QName作为它的唯一名字；Receiver：消息的接收者，也就是消息的目的地址，也使用QName作为它的唯一名字；Role：发送者的角色，用于权限控制（）Stub根据应用系统的WSDL描述，每个Web Service对应着一个Stub，一个Stub可能被多个服务使用。Stub的实现不需要开发人员自己编写，目前，有很多工具可以根据Web服务的描述文档自动生成静态的Stub程序代码。.服务引擎 应用系统提供的通常是细粒度的API接口，这与SOA思想中服务单元粗粒度原则相矛盾，同时难以满足数字校园高可用性、扩展性、灵活性的需求。因此，必须通过服务引擎重新组合使应用系统暴露具有一定粒度的服务接口。服务接口实现如图所示：图服务接口 ServiceEngine类是服务端点的标识接口，所有服务引擎都必须实现该接口。服务在运行时有两种状态：正在运行（Running）、停止运行（Stopped）。start()、stop()、shutdown()和init()方法是对服务进行生命周期管理的需要而设计的由服务管理类回调的方法。Init()是在服务初始化被读入内存时的回调方法，这时服务的状态变为Stopped；服务从运行到暂停运行状态需要回调stop()方法；从暂停运行到运行需要回调start()方法；需要从内存中清除服务时要回调shtdown()方法。销毁服务必须首先把服务的状态修改为Stopped，不能直接从Running到Shutdown。 ServiceContext类是Service初始化时的参数，它的作用是使服务引擎能获取该服务的部署信息； getServiceName()获取服务的名字，返回是XML名字空间形式的Qname； getRole()获取服务角色，说明能说明该服务的角色； getDecription()获取服务的描述信息； getOperations()获取服务中的操作，每个操作用一个QName表示； getServiceDescription()获取服务描述文档WSDL，以XML文档(org.w3c.dom.Dcoument)方式返回； getParameter()根据在部署文件中设定的参数名取其值，在部署文件中可以配置name-value形式的参数值，服务运行时可以根据不同的值来改变初始化的内容。、结束语目前，基于SOA架构的数字校园解决方案已经在浙江工商职业技术学院数字校园建设中得到了初步的应用。在实际应用过程中，该架构主要表现出以下一些优点：（）在数字校园的建设过程中摆脱了面向技术的解决方案的束缚，朝着面向服务的方向发展，使其与其它架构相比更具弹性，能够更快地响应校园应用和需求的变化，不仅能够确保当前业务的灵活性, 而且还可以满足未来学校的业务发展需求。（）较好地集成了原有应用。在数字校园的建设过程中不需要重构原有系统，只需要将原有应用系统封装成标准的服务组件，通过这些服务的接口和名称就可以访问或合并构建在不同的机器上、运行在不同操作系统中的遗留系统，有效地保护了原有投资。（）服务设计松散、位置透明，服务协议是独立的，不必与特定的系统或网络相连接，服务间的通信框架使得服务重用成为可能。SOA架构的松耦合性允许服务使用者自动发现和连接可用的服务，使得服务的集成和组合变得更加容易，从而提供了良好的应用开发和服务管理能力。（）统一了业务架构，可扩展性大大增强。在数字校园的基础架构之上，不同应用系统之间的开发和部署将变得更加一致。现有组件、新开发组件和从厂商购买的组件可以合并在一个框架内。这样的组件集合作为服务部署在现有的基础架构中，增强了可扩展性。（）通过采用基于SOA的数字校园体系结构，建设人员可以把精力集中于服务流程的构建和数据标准的制定，而先不去关注有关集成或应用程序的底层实现问题,使学校摆脱了对具体厂商和具体技术的依赖，加快了系统集成和开发的速度，降低了数字校园的建设成本。在未来的