基于soa办公自动化管理系统设计与实现

基于soa办公自动化管理系统设计与实现内容摘要：

门 部门 部 于 05 年推出了一套全国高考网上 公文审核 系统，因为 审计部门 部门 部的网上 公文审核 系统要照顾到全国各省、市、地区的 公文审核 工作，而各个省、市、地区的 公文审核 政策、实际情况又不太相同， 故 审计部门 部门 部的网上 公文审核 系统虽然功能多，但操作起来复杂，使用起来不方便，而且维护起来也比较困难，没有在全国范围内得到广泛应用。 现在国内有很多高校使用了网上 公文审核 系统，但是也需要 审计部门进行现场确认 公文审核 资格和 办理 公文审核 材料 ； 从 公文审核 流程来看，此类的公文审核 方式主要是采用网上 公文审核 和现场确认相结合的方式，没有完全利用第一章 绪论 3 现有的技术实现网络化操作 ，而在国外，这种类型的系统则相对成熟，可以通过网络完成所有 公文审核 业务。 研究内容和目标 SOA 的 本质上 是一种建立管理 IT 系统和业务流程的方法 ， 它是 为软件集成服务的，实现了技术和架构的完全分离， 同时 消除了软件服务集成的所有障碍。 因此 ， SOA 使得软件集成不必受任何标准的限制， 也就是说 SOA 可以集成任何标准的软件服务。 由于个人对 审计部门 部门 工作和业务流程非常熟悉，结合攻读硕士期间所学到的先进 IT 技术和知识，因此我 参加 了 公文审核公文审核 系统的研发工作。 在系统的开发过程中， 我 参与系统的 总体 分析和设计 ，并 主要 负责 网上 公文审核 模块 的开发。 结合实际 情况 ， 本文 主要在以下几个方面做了 研究 工作 ： （ l） 对 SOA 架构 思想 、 Web 服务 以 及 面向服务的 相关理论 SOUP（面向服务的 统一过程）和 SOAD（面向服务的分析和设计） 进行 较为深入的 分析研究。 （ 2） 基于 SOA 理论 ，结合 某 审计部门 部门 审计部门 部门 网上 公文审核 系统的需求，分析了 该 系统的业务需求 和业务流程 ， 结合 SOUP 过程方法，以面向服务的设计原理，采用 UML 统一建模语言从服务用例的角度对系统进行 分析和 建模。 （ 3） 基于 SOA 的设计 原则和 目标， 采用自顶向下的方式 分析了 系统的 业务流程， 以网上 公文审核 模块为例子进行详细设计。 系统的开发过程中 结合 SOAD理论 探讨了面向服务架构中服务粒度的设计及 通过 对服务进行组合调用 来 建立业务流程的步骤， 从 提高系统业务流程的可重组性和适用性方面进行了探索。 （ 4）综合运用 Web 缓存技术、同步令牌机制 Token、数据库连接池等 技术提高系统整体性能。 本论文主要创新点 近年来，各省级 审计部门 部门 部门陆续开发了适用于本省的 审计部门 部门公文审核 系统，也有个别具有 审计部门 部门 资格的 审计部门 部门 投入使用了 公文审核 系统，如北京林业大学 、复旦大学等 ；还有一些 省市 在高考 公文审核 系统开发应用中引入了 SOA 思想。 从功能上来说，这些系统都是对 公文审核 信息的采集，如果要顺利完成 公文审核 工作，还需要 审计部门 工作人员 到现场进行图像 采集、办理 公文审核 材料 等一系列手续，直至最后的 公文审核 信息进行确认。 一些研究硕士学位论文 者应用 SOA 理论对中信息孤岛的问题进行了应用系统集成的初步研究，而对于SOA 理论应用于 公文审核 系统并与其他服务系统之间组合服务的研究则异常罕见。 随着 审计部门 部门 的规模化和规范化，研究和设计基于 SOA 理论的 公文审核系统，实现 工作人员 报到、 身份 注册等各系统之间服务共享，可大大提高工作效率和信息化水平；基于 SOA 理论 进行设计和开发该系统 ，可以提高系统复用，降低今后的开发和维护成本，有很大的实用价值。 本 文 的研究旨在为各 审计部门 部门 的 公文审核 流程全部 实现信息化和网络化 （ 无需现场 公文审核 即可完成全部 公文审核 流程）、 以及 从 审计部门 公文审核 到 工作人员 报到、 身份 注册 等环节的 服务 共享化、流程化、简便化 进行了 初步探索。 论文组织 全文共分为 七 个 章 节，每个章节的主要内容 概 述如下： 第 1 章，讨论了课题的研究背景、课题来源、研究内容和目标 ，并指出了本课题的 创新 点，最后介绍了论文的组织。 第 2 章，首先描述了面向服务架构的核心概念，介绍了 SOA 的关键理论， 接着对本课题所依赖的技术理论基础 Web 服务 做了比较全面的介绍。 第 3 章， 本文的工作重点之一， 用 SOUP 的 方法对 某 审计部门 部门 公文审核系统进行了 分析，分析了系统的业务需求 、 功能性 及 非功能性需求， 较详细的介绍了本系统开发选用的软硬件平台及技术架构。 第 4 章，基于面向服务的分析， 使用统一建模语言 UML 对系统 从服务的角度进行 总体分析。 第 5 章， 基于 SOA 的思想体系，对 公文审核公文审核 系统进行了整体的设计。 选 取了具有 代表性的 公文 网上 公文审核 流程 模块，对 公文审核 业务流程进行详细的分析与设计， 并详细介绍了为提高系统性能所采用的关键技术。 第 6 章，介绍了 系统测试。 基于 SOA 和 web 服务技术 架构的 系统测试的 特点，分析了测试类型 ，介绍了测试工具和测试方法，并对 系统测试 结果进行了简单分析。 第 7 章，对本文研究内容总结，指出了存在的不足及今后的努力方向。 第二章 面向服务的相关技术概述 5 第二章 SOA 的 相关 技术 概述 软件开发方法经历了面向过程、面向对象、面向组件和面向集成的发展过程，每个过程都是前一个过程的创新和发展，使这些方法越来越方便的服务于人类社会 [3]。 如今，面向服务的架构（ SOA）以更加先进的理念 成为占有绝对优势的 软件工程实践方法。 SOA 架构的定义 许多组织或 个人从不同角度和不同侧面对 SOA 进行了描述， 但是迄今为止，对于 SOA 还没有一个公认的 定义。 我们 可以 这样来 理解 SOA： 首先 SOA 是一种体系结构 ， 这种体系架构 是 可以构建 松散耦合的 服务的 框架。 其次， 在 SOA 体系框架 中， 所有的 功能 部分是 由底层 的 业务事务被构建成 的 互相独立的 服务 ， 服务也是被封装成的用于业务流程的可重用组件， 而服务的具体实现方式是外部不可见的 [4]。 外部组件 若想使用服务，那么 只能通过服务描述来获知 此 服务所提供的功能， 然后通过接口 调用 该服务。 由此可见，服务是 SOA 的关键概念之一。 就目前的实际应用来看， 服务的实现可能包括在一个企业内部 的不同计算机上或者许多业务合作伙伴拥有的计算机上执行的 很多步骤，因此 服务 并不等同于组件， 可能是一个组件也可能不是一个组件。 SOA 的 基本特征和要素 松散耦合是指 构造的服务、接口、协议等 之间不能 相互 依赖，包含三个方面的内涵：服务 与服务 之间的松散耦合、接口和实现之间的松散耦合、业务组件和传输协议之间的松散耦合。 粗粒度是指 SOA 中服务的接口应该比面向对象的编程的 API 要大一些，需要接近用户的实际操作。 硕士学位论文 位置的透明指 的是 不 管 业务组件 的 URL如何变化而 客户端的调用程序的 URL都不需要改变。 而传输协议的透明是指 不管服务组件的传输协议如何变化 而 客户端的调用程序的传输协议都不需要改变。 通常 SOA 通过服务总线对组件的接口进行进一步的封装以 保证服务的位置和传输协议的透明 [4]。 诸如 COM、 CORBA 等 传统的组件模型采用了 从服务器端 到 客户端 传递 二进制编码对象 然后在 客户端 调用这个对象的 模式 来完成某些 信息的传递，以完成某些功能。 这种消息模式传递的是二进制编码。 在 Inter 中，由于存在大量的系统，它们是来自 不同语言 ，由 不同平台 实现的，因此 对数据甚至是一些基本数据类型定义都 会 不同， 这样给不同的服务之 间传递对象带来了极大的 困难 ，采用采用传递二进制编码对象的方式显然不满足当前的技术应用了 [5]。 恰好 由于基于文本的消息本身不包含任何处理逻辑和数据类型， 服务间传 递 的仅仅是 文本 消息 ， 这样 就不必 考虑 兼容 的问题 了。 因此 这也决定了基于 SOA 搭建的 系统必须采用基于文本的消息传递方式。 SOA 的基本结构 面向服务的架构体系 SOA 本质上 是 一种 设计和构建松散耦合的 企业级软件 解决方案，它能够以程序化的可访问的软件服务的形式公开业务功能，以使其他应用程序可以通过已发布的和可发现的接口来使用这些服务 [3]。 SOA 中， 服务提 供者、服务请求者和服务 注册库 （ UDDI）三 个主要组成部分分别承担了不同的任务，每一组成部分 又 分布 有三个操作：发布、查找 和调用 [3]。 SOA 对三者之间的关系进行了很好的描述。 图 21 说明了面向服务结构中协作支持发布、查找和调用的关系图。 图21 服务描述 服务描述 服务 调用 发布 查找 服务注册库 服务 请求者 服务 提供者 第二章 面向服务的相关技术概述 7 面向服务的 体系结构模型图 SOA 的目标 SOA 通过应用组件和传输协议的松散耦合（即服务传输协议的透明化）、服务的即时绑定（即服务位置的透明化）从而实现业务组件的虚拟化，造就一个虚拟的集成架构或者集成平 台服务总线，这样使得服务集成不受任何限制，可以同时集成 .NET 和 J2EE 组件，以及集成其他遗留系统的各种应用，同时也可以随时更换这些服务组件，最终达到敏捷的、不受限制的服务集成目标，从而使 IT 能够随着业务需求的变化而自由调整，最终达到“随需而变”。 由本章的介绍可知，构件技术的总体情况是基本应用普遍，同时其发展被赋予了新的内涵，这包括了众多关于构件的各种创新思维，力求促使构件成为一个整体的逻辑单元而且支持自动装配，具有强大的自我描述功能，变得更加“智能”，同时努力使不同标准之间的构件能够共同工作。 但实际上 这些高级的特性还没有在实际应用中被使用，大多处于实验室阶段，这就涉及到这样一个现实的问题，即在实际开发信息系统时如何有效地应用构件。 这也是构件技术的当前的重要的研究课题之一。 软件是人开发而出来了，不可能是完美，在软件开发的当中，一定需要预测，来保证其功能的正常进行。 软件预测可以在软件开发过程中，对软件质量的加以控制，使得软件质量达到预定的效果，保障功能的完善性，准确性。 软件测试是在软件投入运行前 ,对软件需求分析、设计规格说明和编码的最终复审 ,是软件质量保证的关键步骤。 软件测试是为了发现错误而执行程序的过程 ，因此软件测试的目的就是尽可能多地发现并改正软件中的错误，提高软件的质量。 曾说： “程序测试只能表明错误的存在 ,而不能表明错误不存在。 ”可见 ,测试是为了使软件中蕴涵的缺陷低于某一特定值，使产出、投入比达到最大。 软件测试的工作内容 编写软件测试计划，设计软件测试脚本和用例，搭建软件测试环境 执行软件项目测试，包括功能测试、性能测试、易用性测试等 整理、分析、报告并追踪软件缺陷，并确认软件测试问题得以解决 撰写软件测试结果分析报告，预先评估项目的风险，编写其它相关文档 结合研发软件产品项目情况，制定相应的软件、项目版本控制制度 软件可靠性预计中存在的问题有以下 3 方面： 由于没有模型应用的先验知识 ,导致盲目的选取模型。 硕士学位论文 模型预计中存在很多的不一致性。 有时选择一个或多个模型进行预计 ,预计质量都很低。 针对上面提出的问题可采用下面的一些方法来解决上述问题： 在选择模型或模型组前进行可靠性趋势分析 ； 无论选择何种模型都要进行预计质量分析 ； 预计质量不好时应用改进技术改进预计质量 . 目前 ,风险评估在许多方面 ,最具代表性的包括 ： 敏感性分析、灰色系统分析、模 糊综合评价法、层次分析法、蒙特卡罗模拟和人工神经网络。 敏感性分析法 通过测定灵敏度分析是一项或多项不确定的因素致使决策评价指标的变化改变的知识范围的各种因素的变化 ,达到预期目标的影响程度。 因此 ,当外部环境发生了变化，评价对象的风险承受能力的判断。 如果一个因素的微小变化的决策评价指标的影响幅度较大 ,说明该因素是灵敏度因子 ； 反之 ,如果某一因素的变化 ,不影响决策评价指标结果或更少 ,则需考虑的因素是不敏感因素。 灰色系统分析 在 1982 年《灰色系统控制问题》的发表标志着灰色系统理论的诞生，有些现象是不明确 和不确定性与数学中的应用。 传统的系统理论，该信息系统中最更充分。 相对较差对信息系统的一些。 采用黑盒的方法，也取得了较为成功的经验。 然而，一些不确定信息的内部零件，有些信息并不知道该系统，但研究是很不够的空白区域成为灰色系统理论的诞生地。 在客观世界中，不是白色系统（信息完全清楚）的东西也不是黑系统（完整的信息不明确），而是灰色。 因此，一个灰色系统理论中存在很多这样的灰色系统研究的进一步发展。 该理论认为，任何在一定幅度随机过程是限制和某些灰颜色的改变时区数量和随机过程为灰色过程。 灰数、灰色元、灰色关系是灰色系统 的主要。