XX综合门户管理系统设计方案

综合门户管理系统

设计方案

XX公司

二○一三年七月

目录

1.概述 (3)

2.承担的任务 (3)

3.技术要求 (3)

3.1.功能要求 (3)

3.2.设计要求 (4)

4.软件总体设计 (5)

4.1.功能组成 (5)

4.2.网络拓扑结构 (6)

4.3.运行模式 (6)

5.系统功能设计 (7)

5.1.系统管理 (7)

5.1.1. 部门管理 (7)

5.1.2. 候选用户管理 (7)

5.1.3. 用户管理 (7)

5.1.4. 权限管理 (7)

5.2.集成门户管理 (8)

5.2.1. 统一的企业目录基础 (8)

5.2.2. 强大的数据管理能力 (8)

5.2.3. 团队协作及共享 (8)

5.2.4. 业务系统的单点登录 (8)

5.3.内容发布管理 (8)

5.3.1. 站点管理 (8)

5.3.2. 栏目管理 (8)

5.3.3. 内容发布 (8)

5.4.OA管理 (9)

5.4.1. 发文管理 (9)

5.4.2. 收文管理 (9)

5.4.3. 收文阅办 (9)

5.4.4. 公文查询 (9)

5.5.业务支撑框架 (9)

5.5.1. 企业服务总线 (9)

5.5.2. 服务封装 (13)

5.5.3. 服务管理 (14)

5.5.4. 服务质量监控 (14)

5.5.5. 安全日志管理 (15)

6.系统运行环境要求 (15)

6.1.软件环境要求 (15)

6.1.1. 服务器端 (15)

6.1.2. 客户端 (15)

6.2.硬件环境要求 (15)

6.3.网络环境要求 (15)

1.概述

企业在信息化实践过程中，大量软件系统得到广泛应用。也随之产生新的问题：多个系统间采用非标准的形式紧密耦合，集成困难且阻碍未来发展更新；系统难以灵活应对业务变迁：管理功能限制在多个程序域内，难以实现宏观尺度的监测和调控等等。

本文试图提出采用ESB（Enterprise Services Bus，企业服务总线）的解决方案，通过构建一个松散耦合的综合门户管理系统，实现企业中多个异构业务系统的集成，同时继承企业已有的IT资产，并提供丰富的管理功能和未来良好的发展空间。方案着重关注利用服务封装、编排和管理等关键技术实现企业的数据和业务集成。

2.承担的任务

通过综合门户管理系统的建设，实现企业中各个软件系统的数据和业务的集成，实现信息化资源的整合和提升，提高企业数据的利用效率，降低企业业务集成的成本，提高企业信息化建设的效益。

3.技术要求

技术要求包括功能要求和设计要求。

3.1.功能要求

建立一个完整有效的企业业务门户，可以在一定程度上把分立系统的不同功能有效地组织起来，为用户提供一个统一的应用服务功能入口，整合企业的后台业务系统，减少“信息孤岛”的存在并降低重复投资，为用户提供更加完善的信息服务。

综合门户管理系统应该重点关注各个异构系统的数据和应用集成。为了实现数据及应用层面的集成，该应用接口必须满足以下功能：

（1）异构系统之间的通信功能；

（2）异构系统之间的服务交互功能；

（3）实现异构系统之间的服务聚集的功能；

（4）保证异构系统之间的服务质量；

（5）必须充分考虑异构系统进行集成的安全性；

（6）需要定义服务的级别或优先级；

3.2.设计要求

综合门户管理系统的设计，首先需要满足企业的实用性要求，还必须兼顾可扩展的要求，从基础上贯彻安全性要求。具体包括以下要求。

（1）实用性要求。综合门户管理系统应该切实满足各个异构系统进行数据交换、服务交互的需求，兼顾数据标准的通用性和处理效率。

（2）开放可扩展性要求。任何封闭的系统，不兼容的系统，都不符合信息化建设要求，本平台的建设中，也必须要采用开放性的设计原则，建设过程中注意和其他相关系统的接口以及系统日后的不断扩充和升级，整合系统资源。

为了使应用接口不仅和已有的各个业务系统有效连接，而且在以后能够方便地扩展和连接新的业务系统，升级时底层不出现大的改动，有效地保护前期的投资，必须保证系统的开放性和通用型。因此在应用接口的设计和开发过程中，将广泛采用国际通用的标准和协议，如J2EE（Java2 Enterprise Edition）标准，XML （eXtensible Markup Language，可扩展的标记语言）技术，TCP/IP协议，LDAP （Lightweight Directory Access Protocol简单目录访问协议）协议，SSL（Security Socket Level）安全协议。

应用接口采用开放的、基于J2EE标准的设计方案，提供非常强大的服务器端的Java 技术支持，保证了应用系统的跨平台的要求。支持Windows、Unix、Linux等多种操作系统。

（3）安全性要求。为保证应用接口的稳定运行及信息管理的可靠。必须将整个应用接口的安全设计当作一个整体考虑，并设立不同的安全级别和权限控制，并且有先进的防病毒和防止黑客攻击的能力。

为了保障应用接口中传输的重要、敏感信息的安全，应用接口将采用一整套的安全保密技术和策略，建立了一套完整、合理的用户授权管理系统，对访问应用接口的用户进行身份认证，确保身份的真实性。使用多级授权的用户管理体系，对用户访问的权限进行控制。采用日志和审计系统对在各个重要环节进行操作进行记录，并可对这些操作日志进行审计。在敏感信息的传送中采用数字签名和加密技术，保证信息传送过程中的安全。这些为物理层、传输层到应用层提供的多重安全保障措施，保证了集成系统的高度安全。

4.软件总体设计

4.1.功能组成

综合门户管理系统包括：系统管理、集成门户管理、内容发布管理、OA管理和业务支撑架构等模块。如图1所示。

图1综合门户管理系统功能结构

（1）系统管理

包括组织结构管理（部门管理、候选用户管理）、用户管理、角色管理、权限管理、授权管理、操作日志、权限委托和流程管理。

（2）集成门户管理

包括门户定制工具、门户展示引擎的设置。

（3）内容发布管理

包括：站点管理、栏目管理和内容发布。

（4）OA管理

包括：发文管理、收文管理等。

（5）业务支撑架构

包括：企业服务装ESB、服务封装、服务管理、服务质量监控以及安全日志管理。

a．企业服务总线（ESB），主要用于为各个异构系统中的服务建立统一的运行时环境，消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。企业服务总线是所有异构系统交互的基础。

b．服务封装，主要是指各个异构系统，将已有的业务系统封装成为数据服

务或业务服务。通过企业服务总线对业务服务的集成，各个异构系统间通过服务的调用来实现数据或业务的集成。服务封装是所有异构系统集成的前提。

c．服务管理，主要是指对暴露于企业总线上的服务进行管理，包括服务的注册和匹配，状态验证等。各个异构系统中的服务只有通过在企业服务总线上进行注册后才能被其他异构系统所发现。

d．服务质量监控，主要指对服务的提供过程进行记录和统计，从而形成服务质量评价的数据，通过服务质量监控，可以促进改善服务质量，提高服务效率。

e．安全日志管理，主要对服务的调用过程进行记录和统计，用于分析服务调用的合法性和合理性。为管理员进行服务的管理提供相关的依据。

4.2.网络拓扑结构

综合门户管理系统的网络拓扑可以基于已有信息化平台进行扩展，以下是其网络拓扑示意图，如图2所示。

图2 综合门户管理系统网络拓扑

4.3.运行模式

综合门户管理系统将采用B/S架构，各业务系统通过企业服务总线进行服务注册，将自己的数据服务或业务服务“暴露”给其他业务系统；业务系统可以通过企业服务总线对远程的（其他业务系统）服务接口信息进行查询；对于可用的服务接口进行调用，并获取服务调用结果。

企业服务总线将对各业务系统的行为进行记录和统计，作为服务质量和服务

访问安全的依据。其运行模式如图3所示。

图3综合门户管理系统运行模式

5.系统功能设计

5.1.系统管理

5.1.1.部门管理

部门管理主要用于维护系统的组织结构树。

部门的管理操作有：新增、查看、编辑、失效、用户和角色。

5.1.2.候选用户管理

候选用户管理主要用于维护组织结构中用户账号。

用户管理的操作有：查看、编辑、失效和密码重置。

5.1.3.用户管理

用户管理主要用于维护系统用户。

用户管理的操作有：新增、查看、编辑、失效、部门调整、部门设置、角色设置和权限设置。

5.1.4.权限管理

权限管理用于维护系统权限。

权限管理的操作有：角色权限、人员权限和菜单权限。

5.2.集成门户管理

5.2.1.统一的企业目录基础

综合门户管理系统从企业应用中抽象出组织机构、业务分工、业务权限、业务流程、基础资源等作为独立的管理对象，并统一存储于系统之中，为使用不同接入方法的用户通过统一的应用资源目录来访问不同的数据和应用系统奠定了基础。

5.2.2.强大的数据管理能力

综合门户管理系统支持各种结构化和非结构化的数据，并能识别多种关系型和OLAP数据库中的数据。

5.2.3.团队协作及共享

综合门户管理系统提供了全面的团队协作支持，包括团队和组织机构管理、信息共享和沟通、业务分工和权限管理以及业务协作支持，实现了业务系统与群件（OA）系统的一体化。支持业务协作中的信息共享；支持信息发布、通知、广播、讨论；支持组织内外、局域和广域的邮件收发。

5.2.4.业务系统的单点登录

综合门户管理系统为各种应用系统的统一构建提供了强大的支撑平台，并为不同应用系统的访问提供了统一的业务门户，用户只需一次登录便可以轻松访问所有应用系统。

5.3.内容发布管理

5.3.1.站点管理

用于对站点进行维护，包括：增加和删除站点。该功能适用于系统管理员用户。

5.3.2.栏目管理

用于对栏目进行维护，包括：增加、编辑和删除栏目。该功能适用于系统管理员用户。

5.3.3.内容发布

用于用户发布具体的内容，例如：公告、通知、新闻等内容。该功能适用于被授予内容发布的用户。

5.4.O A管理

5.4.1.发文管理

指发送所级或部门级别公文的流转管理。包括：拟稿、审核、领导签批或签发、套红、盖章等。

5.4.2.收文管理

指接收外部公文或文件的流转管理。

5.4.3.收文阅办

指在公文发文流程中，需要通知相关人员进行公文的阅览。

5.4.4.公文查询

用户通过选择查询条件来对所发公文或所收公文进行综合查询。

查询条件包括：公文类型、文件标题、发文文号、来文字号、密级、来文单位、主办部门、状态和时间。

5.5.业务支撑框架

5.5.1.企业服务总线

企业服务总线(Enterprise Service Bus，ESB)是构建基于面向服务体系结构(SOA)解决方案时所使用基础架构的关键部分，是由中间件技术实现并支持SOA 的一组基础架构功能。

ESB可以将企业的所有业务流程和应用程序进行协调与协作，包括收集企业的数据和流程信息，以及对它们的管理从而使企业的应用程序和用户可以方便快速的实现其业务目标。

面向服务的架构(SOA)从根本上改变了对企业应用的设计、开发和集成的方式。它倡导企业应用的模块化服务、增量开发、便捷集成和重用。然而SOA也带来一系列的技术挑战，如可靠的消息传递、服务的虚拟化、服务的发现和调用、策略管理等等。使用SOA架构来搭建IT系统是一个复杂的过程，ESB的使用则可以简化这一过程。SOA 的服务组件暴露的是一种粗粒度的接口，其目的是使应用之间能够异步地共享数据。而使用ESB可以将应用程序和分离的集成组件拉在一起，以产生服务装配组合从而形成复合的业务流程，进而自动化一个实时企业中的业务功能。

1．ESB基础功能

（1）通信

?路由

?寻址

?通信技术、协议和标准（例如MQ、HTTP 和 HTTPS）

?发布/订阅

?响应/请求

?Fire-and-Forget，事件

?同步和异步消息传递

（2）服务交互

?服务接口定义（例如，Web 服务描述语言（Web Services Description

Language，WSDL））

?支持替代服务实现

?通信和集成所需的服务消息传递模型（例如 SOAP 或企业应用程序集成

(EAI) 中间件模型）

?服务目录和发现

（3）集成

?数据库

?服务聚合

?遗留系统和应用程序适配器

?EAI 中间件的连接性

?服务映射

?协议转换

?应用程序服务器环境（例如 J2EE 和 .NET）

?服务调用的语言接口（例如 Java 和 C/C++/C#）

（4）服务质量

?事务（原子事务、补偿、Web 服务事务（WS-Transaction））

?各种确定的传递范例（例如Web 服务可靠消息传递

（WS-ReliableMessaging）或对 EAI 中间件的支持）

（5）安全性

?身份验证

?授权

?不可抵赖性

?机密性

?安全标准（例如 Kerberos 和 Web 服务安全性（WS-Security））（6）服务级别

?性能

?吞吐量

?可用性

?其他可以构成契约或协定的持久评估方法

（7）消息处理

?编码的逻辑

?基于内容的逻辑

?消息和数据转换

?有效性

?中介

?对象标识映射

?数据压缩

（8）管理和自治

?服务预置和注册

?记录、测量和监控

?发现

?系统管理和管理工具的集成

?自监控和自管理

（9）建模

?对象建模

?通用业务对象建模

?数据格式库

?集成的公共与私有模型

（10）基础架构智能

?业务规则

?策略驱动的行为，特别是对于服务级别、服务功能的安全和质量（例如

Web 服务策略（WS-Policy））

?模式识别

2．ESB业务集成方案

针对目前所内各种异构系统使用情况，拟采用以下4类方式针对以前的接口进行集成。

（1）方式1

对于已经使用Web Service方式的或者服务提供方与消费方都能够支持web service的，可以直接把现有的web service服务注册到ESB上，或者消费方发布web service，调用者从ESB上进行调用。该方式要求服务提供方修改调用地址，消费方不需要做改动。ESB上的流程如图4所示：

图4 使用Web Service进行业务集成流程

（2）方式2

如果服务提供方能够调用web service，消费方不能够发布web service，将在ESB上自行发布web service，流程上模拟存储过程或Job调用，该方式要求服务提供方修改服务提供方式。ESB上的流程如图5所示：

图5 使用模拟存储过程进行业务集成流程

（3）方式3

如果服务提供方不能够调用web service，消费方能够发布web service的，如果服务提供方能够支持JMS、文件（包括本地文件系统或FTP）、Http、TCP等协议（服务提供方能够发送JMS消息、生成本地文件、将文件上传到FTP、调用Http协议、通过TCP发送消息），那么，将在ESB上根据服务提供方支持的协议发布流程，中间环节使用SOAP Request。如图6所示：

图6 使用SOAP Request进行业务集成流程

（4）方式4

如果服务提供方不能调用web service，消费方不能发布web service，如果服务提供方能够支持JMS、文件（包括本地文件系统或FTP）、Http、TCP等协议（服务提供方能够发送JMS消息、生成本地文件、将文件上传到FTP、调用Http 协议、通过TCP发送消息），那么，将在ESB上根据服务提供方支持的协议发布流程，中间环节使用Database节点。该方式要求服务提供方修改服务提供方式。以文件节点为例，流程如图7所示：

图7 使用数据库节点进行业务集成流程

5.5.2.服务封装

各个业务系统（异构系统）将其需要参与数据或业务集成的资源或业务处理过程封装成为服务。服务的表现形式可以是多种，例如：SOAP服务、HTTP服务，但无论何种服务形式，其数据内容都必须采用双方所遵循的交换标准，如：

XML、JSON等。

Web服务主要使用两种技术：

（1）XML，XML是在web上传送结构化数据的方式，Web services要以一种可靠的自动的方式操作数据，HTML不会满足要求，而XML可以使web services十分方便的处理数据，它的内容与表示的分离十分理想。

（2）SOAP，SOAP使用XML消息调用远程方法，这样web services可以通过HTTP协议的post和get方法与远程机器交互，而且，SOAP更加健壮和灵活易用。

5.5.3.服务管理

服务管理主要包括服务注册和服务信息查询。

ESB注册功能主要用于查看ESB服务端点、本地应用服务端点和远程应用服务端点；并将本地应用服务端点通过ESB注册为其他应用程序服务器可见的远程应用服务端点。如图8所示。

图8 ESB注册界面

业务系统中通过“ping”链接来判断某服务端点是否可用。

业务系统中点击“注册”按钮可以将本地应用服务端点注册为其他应用服务可见的“远程应用服务端点”。

5.5.4.服务质量监控

服务品质（QoS，quality of services）将是衡量一个综合门户管理系统的稳定性的主要标准。对于各个业务系统而言，服务质量是各业务系统之间进行无缝交互的基础。

在异构系统集成系统中，服务消费者和服务提供者之间会有几种不同的文档在进行交换。具有诸如“仅且仅仅传送一次”，“最多传送一次”，“重复消息过滤”，“保证消息传送”等特性消息的发送和确认，在关键任务系统中变得十分重要。WS-Reliability 和 WS-ReliableMessaging是两个用来解决此类问题的标准。

软件可以通过就服务的调用记录（调用时间、IP、用户信息）、服务是否可用（可用/不可用）、调用状态（成果或失败）等指标来进行服务质量的初步分析。

5.5.5.安全日志管理

Web服务安全规范用来保证消息的安全性。该规范主要包括认证交换，消息完整性和消息保密。该规范吸引人的地方在于它借助现有的安全标准，例如，SAML （as Security Assertion Markup Language）来实现web服务消息的安全。

软件可以通过记录服务的调用记录（调用时间、IP、用户信息）、口令错误频率、调用频率等指标来进行服务调用安全的初步分析。

6.系统运行环境要求

6.1.软件环境要求

6.1.1.服务器端

操作系统：Windows Server 2003及以上版本，建议为Windows Server 2008 sp1。

JDK：建议为J2SE 1.6版本。

应用程序服务器：Tomcat 6.0版本、Web Logic 10版本

数据库系统：Oracle 10g R2

6.1.2.客户端

浏览器：IE 8.0版本

6.2.硬件环境要求

数据库服务器内存不得小于8GB。

应用程序服务器内存不得小于4GB，至少2CPU。

6.3.网络环境要求

要求安装TCP/IP协议，网速不低于100Mbps。