基于SOA和Web Service的监狱信息整合平台的设计与实现

发布时间：2015-01-19 11:26

 

【摘要】 随着信息技术的发展，企事业单位的各部门根据自身的业务需求逐步建成了功能各不相同的信息管理系统，各系统之间的“信息孤岛”、重复建设等问题也日益突显出来，如何整合异构的数据资源，建立一个松耦合、可扩展的信息整合平台成为研究的热点之一。本文首先结合我省监狱业务软件的建设现状，分析了对监狱信息进行整合的必要性和意义；其次，在对信息系统整合的相关技术深入研究的基础上，提出了采用SOA的体系结构来构建平台；再次，对信息整合平台的需求进行分析，提出了基于SOA的整合平台的解决方案，对整合平台的总体架构、服务处理、数据处理和交换、门户等方面分别进行了设计，并使用UML对设计进行了描述；最后，利用Liferay、Mule、Yale CAS等开源程序包搭建整合平台，实现了服务封装和发布、数据在ESB传输、门户定制、单点登陆等模块的功能。基于SOA的监狱信息整合平台的建立，使不同时期建设的应用系统能有机的结合为一个整体，消除“信息孤岛”，简化业务操作，提高工作效率，对促进监狱信息化的发展具有现实意义。 

第一章 绪论

1.1 监狱业务软件建设情况
2007 年，司法部在发布的《全国监狱信息化建设规划》中指出，监狱信息化建设的总体目标是：构建覆盖全国监狱系统的网络互联互通、信息资源共享、标准规范统一、应用功能完备的信息化体系，明显提高监狱信息资源综合开发利用水平，形成全员应用、资源共享的信息化工作格局，显著提高监狱执法、安全防范、罪犯改造等工作的信息技术应用能力，为推进司法行政系统信息化建设奠定基础。监狱信息化建设主要任务为：建设一个平台、一个标准体系、三个信息资源库、十个应用系统。所谓“一个平台”，即网络和硬件平台；“一个标准体系”，即监狱信息化标准体系；“三个信息资源库”，即监狱管理信息库、罪犯信息库、警察信息库；“十个应用系统”，即监狱安全防范和应急指挥系统、监管及执法管理系统、教育改造系统、生活保障及医疗卫生系统、警察管理系统、生产管理与劳动改造系统、监狱建设与保障系统、狱务公开系统、办公自动化和决策支持系统。
近年来，随着司法部《全国监狱信息化建设规划》的实施和广东政法信息网的建设，我省监狱系统的信息化建设取得了长足的发展。目前，我省监狱系统统一使用的主要业务软件包括：办公自动化（OA）系统、监管改造信息系统、狱情排查系统、罪犯考核管理系统、减刑假释管理系统、罪犯零花钱管理系统、教育改造系统、心理矫治系统等。此外，一系列的业务软件正在开发推广中，如生产管理系统，刑罚执行系统，罪犯健康管理系统、一人一策改造罪犯工作平台、人事管理应用系统、廉政档案管理系统等。各监狱单位也根据不同的业务需求自行开发了专门的专业软件，如：内部工作网站、智能排班系统、警察考核测评系统、罪犯劳动报酬管理系统等等。这些业务软件为监狱各业务线的工作发挥着重要作用[1]。
.............................

1.2 监狱信息系统整合的必要性
目前，在各监狱单位运行及试运行的业务系统多达十多个，一系列的业务软件正在开发推广中，随着系统的不断增加，系统之间的问题也日益突显。
立足于需求，这些系统是根据本业务部门的特定需求一个项目一个项目地完成的，往往缺少跨部门的横向考虑，从而导致了“信息孤岛”，数据很难共享。同一个字段在不同的系统中可能会出现偏差，造成“一数多源”的现象。
从技术上分析，这些系统的建设年代差异较大，由多个承建商开发，采用的开发环境、接口标准、系统架构、编程语言、运行环境、数据库等也不尽相同，应用系统之间缺乏统一的规划，联系比较散乱。为了实现共享，早期应用间的连接使用了点对点的方式，导致应用间的耦合度比较高，管理维护都比较困难。当一个应用发生故障时，相关联的应用都会发生不可预计的问题；当一个应用对外接口发生改变时，相关联的应用必须随之修改；应用之间的关联缺少统一的维护，无法对应用间的调用进行统一的管理。
对于基层警察来说，其管教工作涵盖服刑人员的狱政管理、刑罚执行、教育改造、心理矫治、生活卫生、劳动改造等多方面，这些业务数据分别存储于各系统中，由于系统间缺少整合，使用者只能分别登陆到各个系统中工作，一些基础数据必须重复地录入和处理。
因此，将不同时期建设的应用系统有机地结合为一个整体，建成一个符合监狱管理工作实际需要、整合各业务系统的平台，成为迫切的需求。通过实现“身份认证”的整合（单点登录），数据存储层面的“基础数据集中”，传输层面的“通用数据交换”、应用层面的“业务流程整合”及用户界面的“通用门户”，为管理决策提供全面、准确、及时的信息，最终达到执法信息网上录入、执法流程网上管理、执法活动网上监督、执法质量网上考核和全程网上监控的效果。
....................................

第二章 相关技术分析

2.1 面向服务的体系结构（SOA）
2.1.1 SOA 概述
SOA（Service Oriented Architecture）的概念在 1996 年由 Gartner 公司首先提出，并于 2002 年底进一步表示：SOA 是“现代应用和开发领域最重要的课题”，预计至 2008 年，SOA 在软件工程实践方法中，占有绝对优势。Gartner认为 SOA 是一项由软件服务和服务使用者组成的应用，使用客户端——服务端的软件设计方式，并强调软件组件必须松耦合，组件接口必须是独立的、标准的。
在目前，对 SOA 的定义还没有统一，在业务上和在技术上对 SOA 的理解不一致，又存在交叉的地方。不同厂家和开发者由于自身需求的不同，对 SOA 的解释也不一样。主要分为两类：狭义上讲，SOA 是一种 IT 架构，，它面向服务，由业务来驱动；广义上说，SOA 包含了一整套业务系统的构造方法，如架构的风格、编程的模型、运行的环境和相关的方法论等等，它涵盖了整个软件系统的生命周期，从分析与建模、设计与编码、整合与部署、测试与验收、运行与维护、升级或报废等等[5]。
就技术领域而言，IBM 对 SOA 的解释最为广泛认同：SOA 将应用程序分割为一个个功能不同的模块称为服务，是一个使服务之间以统一的、通用的接口和契约连接起来的组件模型，其中接口和契约的定义独立于服务，与实现应用程序功能的硬件平台、所使用的操作系统、编程语言无关，具有中立性。[6]
SOA 的基本架构中有三个基本角色：一是服务请求者（Service requester），它可能是一个业务程序或一个软件，也可能是一个需要调用另一个服务的服务,它向服务注册中心发起查询（Find），若存在请求的服务，则绑定(Bind)并调用该服务；二是服务提供者（Service provider），它将自己的服务和接口描述发布（Publish）到服务注册中心，同时对服务请求者的访问加以控制；三是服务代理者（Service broker），也就是服务注册中心，用于连接服务提供者和服务请求者，服务提供者在这发布（Publish）他们的服务，服务请求者在这查找(Find)他们需要的服务，SOA 中可以没有服务注册中心，服务请求者可以通过其他方式或直接从服务提供者获取服务描述。SOA 的三个基本角色之间的三个基本操作即上文所述的发布（Publish）、查找（Find）和绑定（Bind）。SOA 的基本架构如图 2-1 所示。

和以往应用相比，SOA 应用具有①模块化、②服务化、③数据标准化、③易集成、⑤用户体验良好、⑥灵活业务定制等 6 个显著的特点[5]：
基于 SOA 的应用使用模块化划分、构件化的方法开发，即一个软件分为多个模块，每个模块完成不同的功能，这些功能可分布式地进行部署，并且动态更新，使软件更具灵活性（可插拔）和可扩展性；同时，以业务作为导向，将软件模块根据业务流程编排为一个个服务（服务化），快速响应了当前业务发展的需要，使业务定制更为灵活；而服务之间建立的通用的接口标准，使异构数据库之间的访问有了统一的模型，应用之间的集成也更容易；对用户来说，统一的门户减少了学习成本，用户体验也更优。
............................

2.2 企业服务总线（ESB）
在 SOA 架构下，服务提供者和服务请求者通过一个公共的通讯框架来通讯，这个公共的通讯框架也即企业服务总线 ESB（企业服务总线，Enterprise ServiceBus），在计算机里面，有个总线负责连接 RAM、CPU 和 I/O 设备等，ESB 的概念即出自于此，ESB 总线使服务提供者和服务请求者不再直接相连，即进一步解耦[10]。如图 2-7 所示。

应用 ESB 后，SOA 架构模型如图 2-8 所示。具体描述如下：ESB 连接服务提供者和服务请求者，完成中介的功能；服务提供者在服务中心注册、发布的服务各自连接到 ESB 上，ESB 服务管理器对其进行管理；服务请求者向 ESB 的服务管理器发送服务请求，统一由 ESB 向 UDDI 查找服务并返回服务结果。

...............................

第三章 基于 SOA 的整合平台的需求分析 .................................17
3.1 系统概述 .............................................17
3.1.1 业务系统使用情况 ................................................17
3.1.2 系统目标及要解决的问题 ........................................18
3.2 系统需求 .........................................19
3.2.1 功能性需求 .......................................19
3.2.2 非功能性需求 ...................................21
第四章 基于 SOA 的监狱信息整合平台的设计..................................23
4.1 设计原则与思路..........................................23
4.1.1 设计原则........................................23
4.1.2 设计思路......................................23
4.2 总体架构设计.................................................24
4.3 服务处理设计..................................................26
4.3.1 服务识别................................................27
4.3.2 服务封装.................................................28
4.3.3 服务注册.................................................29
4.3.4 服务传输.............................................30
4.3.5 服务管理..........................................30
4.4 数据处理设计...........................................31
4.4.1 数据交换模式 .........................................31
4.4.2 数据传输方式 ......................................32
4.4.3 统一数据格式 ....................................33
4.4.4 数据编码规范 ........................................34
4.5 数据交换设计.......................................34
4.5.1 数据同步模型 ..........................................34
4.5.2 数据适配同步设计 ....................................35
4.5.3 数据 ESB 传输 ......................................37
4.6 门户设计 .......................................38
4.6.1 Liferay.........................................38
4.6.2 Yale CAS.............................................40

第五章 基于 SOA 的监狱信息整合平台的实现研究

5.1 整合实现步骤
根据监狱信息业务系统的现状的分析，本文提出了基于 SOA 的监狱信息整合平台的解决方案，采用基于 SOA 的架构，使用 ESB 作为平台架构的基础设施，使用 Web Service 对各业务系统的数据进行封装，并在整合平台注册和发布，供其它系统或服务调用，从而实现监狱信息业务系统之间数据层面松耦合的整合；通过 Liferay Portal 和 CAS 组件建立门户及统一认证，实现表示层面的整合。具体的实现步骤如下：
(1) 整理数据，识别服务。通过业务调研和业务系统的分析，确定需要共享的基础数据和业务数据；并分析数据之间的联系，确定各数据项的准确来源；再建立共享信息库。同时，抽取必要的功能作为平台的服务。
(2) 转换数据，封装服务。抽取共享的数据进行 XML 转换和服务封装；并对业务功能进行封装。
(3) 搭建 SOA 架构。创建满足整合平台需求的 ESB，搭建基于 SOA 的架构，把封装的服务注册到 ESB 上；数据利用 ESB 传输，通过共享信息库共享和同步。
(4) 建立门户。包括单点登陆功能和门户的实现。本文对(2)－(4)项进行了探讨和研究。

5.2 平台的开发工具及运行环境
整合平台使用的开发工具及运行环境如表 5－1 所示。

5.3 服务处理实现
各业务系统提供的功能或数据需要封装为 Web 服务，在整合平台注册。部分业务系统在开发时预留了 API（Application Programming Interface，应用程序编程接口），允许用户根据需要进行扩展，在整合时可以将接口封装为服务。对于没有预留接口、需要共享数据的业务系统，需要编写接口，再将接口封装为服务。
在本文中，以开源的 CXF 服务框架示例实现 Web 服务的封装。CXF 可以方便地实现 java 类和 WSDL 文档之间的相互转化，简化了编程。使用 CXF 需要在系统中导入 CXF 的 jar 包[36]。

..............................

第六章 总结与展望

6.1 工作总结
基于 SOA 的监狱信息整合平台的建立，使不同时期建设的应用系统能有机的结合为一个整体，实现了目前异构业务系统之间资源共享，简化了干警日常的业务处理，提供了“一站式”的服务平台。本文结合监狱信息化建设的现状，提出了基于 SOA 的监狱信息整合平台的解决方案，主要做了以下工作：
(1) 分析目前我省监狱信息化建设，特别是监狱业务软件建设的现状，得出对监狱信息进行整合的必要性和意义。
(2) 对监狱信息整合平台所用的相关技术进行了介绍和梳理,包括面向 SOA的体系结构，Web Service，ESB，Portal，CAS 等。
(3) 通过对监狱信息整合平台的需求进行分析，提出了基于 SOA 的整合平台的解决方案，对整合平台的总体架构、服务处理、数据处理和交换、门户等方面分别进行了设计，并利用 UML 对设计进行描述。
(4) 利用 Liferay、Mule、Yale CAS 等开源程序包建立整合平台，实现了服务封装和发布、数据在 ESB 传输、门户展现、单点登陆等部分功能。
.............................
参考文献:

[1] 邓可.  基于SOA的监狱信息集成研究[J]. 中国管理信息化. 2011(17)
[2] 陈先伟,辜寄蓉,杨海龙.  国家地籍数据网上汇交系统中的消息传递模型与实现[J]. 计算机与数字工程. 2010(03)
[3] 张齐,钟观宝.  基于用户映射的CAS单点登录系统设计与实现[J]. 信息通信技术. 2009(04)
[4] 张月琴,袁新坤.  一种异构数据库同步技术的研究与实现[J]. 微计算机信息. 2008(33)
[5] 杨柳,蔡英蔚.  基于XML格式异构数据同步模型的研究[J]. 中国电力教育. 2008(S1)
[6] 王杰勋,廖文和.  利用JMS、XML技术实现异构数据库的数据同步[J]. 机械制造与自动化. 2007(01)

 

本文编号：11709