风景区基础数据平台与企业数字化应用平台技术建议书.docx

风景区基础数据平台与企业数字化应用平台技术建议书.docx

《风景区基础数据平台与企业数字化应用平台技术建议书.docx》由会员分享，可在线阅读，更多相关《风景区基础数据平台与企业数字化应用平台技术建议书.docx（49页珍藏版）》请在冰豆网上搜索。

风景区基础数据平台与企业数字化应用平台技术建议书

风景区基础数据平台及企业数字化应用平台

技术建议书

1前言3

2项目概述3

2.1项目简介3

2.2建设目标3

3总体方案设计4

3.1设计原则4

3.2技术路线4

3.3系统架构4

3.4系统网络结构4

4软件方案设计4

4.1设计思路4

4.2软件功能设计4

4.2.1数据存储子系统4

4.2.2数据应用子系统4

4.2.3集成统一平台4

4.2.4企业信息门户5

4.2.5营销决策支持子系统5

4.2.6运行维护系统5

4.3接口方案设计5

4.4支撑软件选择建议5

5现有应用系统改造方案5

5.1GPS车辆调度系统改造5

5.2酒店管理系统改造5

5.3财务系统改造5

5.4OA系统改造5

6硬件方案设计5

6.1总体部署方案5

6.2主机选择及配置建议5

6.3网络设计5

6.46

7系统安全设计6

8工程实施方案6

8.1项目组织6

8.2工程进度6

8.3质量管理6

8.4风险管理6

8.5培训6

8.6验收6

9技术支持与服务6

1前言

随着信息技术的高速发展，数字化技术已经渗透到工作和生活各个领域。

2002年，建设部启动了“国家重点风景名胜区监管信息系统”建设工作，由此，数字化被提上了景区建设的议事日程，引领着景区的建设和管理工作向着更科学、高效、便捷的方向发展。

峨眉山风景区位于中国四川省峨眉山市境内，是著名的旅游胜地和佛教名山,是一个集自然风光和佛教文化为一体的中国国家级山岳型风景名胜。

1996年12月6日列入《世界文化与自然遗产名录》。

峨眉山管理委员会为相对独立的、享有县级政府职能的权威机构，依法行使对峨眉山风景区的统一管理。

峨眉山管理委员会重视峨眉山景区信息化，是全国启动信息化建设较早的风景区之一。

已建成并使用的系统有网上办公系统、财务管理系统、电子沙盘、某旅游网、酒店管理系统、数字监控系统、GPS车辆管理系统、规划管理系统等多个信息，涵盖了行政、规划管理、安全保障、经营管理等多个方面。

2006年3月，完成了《“数字化峨眉山”总体规划》的编写，并通过了建设部专家的评审。

从而开启新一轮数字化某建设的序幕。

目前，覆盖全山的基础光纤通讯平台线路敷设工作已经完成，光纤网络集成招标已经结束，即将开始施工。

2项目概述

2.1项目简介

“数字化峨眉山”是以峨眉山基础光纤通讯网络、地理信息系统GIS平台及基础数据库为基础，以高度的应用集成平台为连接点，通过整合各种旅游资源，建立统一的景区管理平台，将网络技术与现有管理体系相结合，而形成的一套完整的数字化营销宣传、环境保护、管理服务、决策系统。

通过确立标准统一的未来软件开发或集成的技术架构，建立高水平的应用系统体系，使各个应用子系统在一个统一的平台下实现数据交流和业务协作。

同时，新的应用系统只要遵循这一标准技术架构，就能顺利实现与现有系统的数据交流。

现有系统建设存在的主要问题有：

1、各个应用系统彼此独立，无法进行数据的汇聚和资源的整合。

如各酒店的酒店管理系统彼此独立，不能进行数据交流和数据共享，成为各个独立的“信息孤岛”。

2、缺少与具体管理工作密切相关的管理系统，缺少一个统一的景区管理、指挥、调度平台。

2.2建设目标

建立以数字智能指挥中心为核心的管理服务、营销、保护三大体系，将峨眉山传统的管理模式转变为数字化的管理模式，实现管理和营销新的突破，树立中国第一、世界领先的管理和科技品牌。

在管理上要符合景区实际，达到情况明、指挥灵；服务上以方便游客为宗旨，提供个性化的服务；营销上要建立数字化、网络化的营销体系，打破地域界限，缩短全球的营销距离，为峨眉山带来更多的游客。

总集成项目的建设目标主要包括以下几个方面：

1、数据中心建设

2、集成统一平台建设

3、集成管理平台与企业信息门户建设

4、应用系统建设和改造

5、基础数据管理

6、管理服务体系、数字营销体系和生态保护体系三大体系建设

2.3项目单位

2.4名词解释

●EAI：

Enterprise ApplicationIntegration，即企业应用集成。

EAI是将基于各种不同平台、用不同方案建立的异构应用集成的一种方法和技术。

EAI通过建立底层结构，来联系横贯整个企业的异构系统、应用、数据源等，完成在企业内部的ERP、CRM、SCM、数据库、数据仓库，以及其他重要的内部系统之间无缝地共享和交换数据的需要。

有了EAI，企业就可以将企业核心应用和新的Internet解决方案结合在一起。

EAI是目前解决企业数据孤岛最有效，最可行的方案。

●ODS：

OperationalDataStore，即运营数据仓储。

ODS是操作型系统中的集成,用于当前，历史以及其它细节查询（业务系统的一部分），为决策支持提供当前细节数据（数据仓库的一部分）。

●WebService：

WebService是一种应用程序，使用标准的互联网协议，将功能纲领性地体现在互联网和企业内部网上，WebService是一个通用型的接口，接口支持比较广泛，适用于不同架构系统间的通讯和集成。

3总体方案设计

3.1设计原则

1）构件式系统

系统由一系列独立部署的构件组成，构件的设计应该满足以下要求：

Ø构件多实例运行：

应该尽量满足对每一个构件都可以同时运行多个构件实例的需求，以保证系统的高可靠性与可伸缩性。

Ø构件接口定义稳定：

应充分考虑构件间接口稳定性，使用XML或者类似的结构，以保证接口传输参数与内容的可扩展性。

Ø构件粒度合理确定：

应综合考虑系统性能、扩展性等方面的因素，同时兼顾系统在部署、维护和管理等方面的要求，合理确定构件粒度。

2）分布式、面向接口访问

每个构件均可以承担服务提供者和服务使用者两种角色，服务使用者通过访问服务提供者的接口获取相应的服务。

系统必须实现构件的分布透明机制。

组成系统的构件实例可以部署在一台或多台主机上。

构件提供的服务访问对分布地点、位置透明，服务使用者通过构件的逻辑名称即可获取服务而与构件所在主机的物理位置无关。

3）松耦合、高内聚原则

系统设计须遵循松耦合、高内聚原则。

构件之间保持松耦合状态，服务的具体实现方式对服务使用者透明。

在构件内部所实现的功能与结构保持高度逻辑相关性的同时，保证构件间的相互独立性。

4）共享信息服务

系统必须提供独立于业务的共享信息服务。

共享信息服务遵循企业的数据模型规范，外部系统通过企业集成与接口平台，访问系统的共享信息，以实现系统间的集成与互操作。

5）业务过程与构件实现分离

应综合考虑业务过程与构件实现的分离的原则，利用流程管理、策略管理和界面集成技术，动态地定义系统的行为以实现系统功能。

应用此种技术在获得灵活性与可扩展性的同时，也应当充分预见其对系统性能带来的影响。

3.2技术路线

3.2.1应用整合平台

应用整合平台是以EAI技术为基础，将不同地应用系统无缝地整合为一个完整的应用系统的基础架构，是企业级应用综合调度和运行、管理的基础平台。

应用整合平台是各个子系统进行通讯的纽带，它不受具体业务的限制。

应用整合平台主要由业务流程管理引擎、公共信息总线、公共数据服务，以及公用的数据转换服务、注册服务、安全服务、交易控制服务、日志服务和适配器开发框架工具型组件等组成。

业务流程管理引擎通过对流程的定义、执行、管理和监控，提供了一个快速开发、部署和管理业务流程的软件平台；公共信息总线将所有的业务系统以相同的方式连结在一个用来相互通信的结构性部件上，实现不同系统间的互联互通；系统中最基本、最重要的数据模型构成了共享的核心数据，这些数据在应用整合平台中被集中存储、统一维护，通过公共数据服务向外部开发。

应用整合平台中还包括一些公用的工具型服务组件。

数据转换服务为不同应用系统间的数据分析、格式映射、格式转换提供通用的工具。

注册服务负责维护所有服务组件的集中目录，供其他组件注册和查询。

安全服务为应用系统提供统一的消息传输加密解密服务、应用访问权限控制等。

交易控制服务负责对应用系统间的联机交易事务进行监控、管理，保证交易的一致性和持久性。

日志服务为应用程序组件提供统一的日志记录服务，使得所有的应用系统间的交易有统一的日志记录以便监控和查询。

适配器框架是应用整合平台向应用系统提供的适配器开发框架，使得我们可以快速地为应用系统开发出联接到EAI平台上的适配器。

目前EAI的主流技术以应用服务器（如J2EE应用服务器）为基础，采用开放的XML、WebService、BPEL等多种标准和技术实现。

●从技术上看，基于成熟应用服务器的EAI可以为企业提供以下好处：

✓可靠性：

提供一个坚固的系统运行环境，具有强大的故障恢复能力、系统重新启动和恢复能力、数据可靠传输能力等。

✓可扩展性：

提供动态部署能力，涉及交易方式、应用程序配置、对象服务嵌入等。

✓可管理性：

系统要实现有效的管理，管理内容包括应用服务器、操作系统进程和线程、数据库连接，以及网络会话等。

✓数据一致性：

交易完整性保障。

✓应用安全性：

包括最终用户身份认证、节点连接的安全认证、应用程序的安全认证、管理界面的访问权限控制、数据加密／解密功能、安全事件报警等。

●从业务上看，EAI可以为企业提供以下好处：

✓EAI可以通过使企业提高业务流程效率、快速响应客户需求、改善客户服务、增加对客户的了解、强化客户忠诚度来改善客户关系、增加市场份额，从而增加收入。

✓EAI可以通过使企业增加管理层对业务的可视性和全面监控、减少IT开销、降低运营成本和重复性消耗、降低销售和售后服务成本来起到降低各种成本的作用。

3.2.2多层架构

系统采用分层结构开发和设计，将界面、业务逻辑和数据分离，实现系统内部松耦合，以灵活、快速地响应业务变化对系统的需求。

系统层次结构划分为数据层、信息服务层、业务逻辑层和控制层，通过各层次系统构件间服务的承载关系，实现系统功能。

各层的应用构件利用系统服务框架所提供的基础服务实现系统公共设计、运行与管理机制。

其中业务逻辑层及信息服务层中的构件必须遵守同样的设计规则并在一个统一的构件运行环境中运行。

集成接口服务是系统开放给外部系统的接口服务。

下图描述了系统的分层次的技术架构，方框外的公共支撑框架及企业应用集成平台不属于本工程的范围。

以下将分别对这些系统内部层次进行说明。

3.2.2.1数据层

数据层负责系统的数据存储及维护数据的完整性与一致性。

数据可以根据需要存储在数据库管理系统、文件、外部存储设备中。

数据层数据的组织按照企业业务概念模型在应用软件上优化实现的要求形成各个主题域。

3.2.2.2信息服务层

信息服务层实现系统的共享信息服务。

该层的构件实现对数据的封装，并把封装后的数据转换成有价值的业务与系统信息，通过合约接口，向其上的业务逻辑层和其他相关外部系统提供一致的与业务逻辑无关的信息服务。

信息服务层按照系统域方式进行组织。

系统域是一组与某一特定管理领域或概念紧密相关的高内聚的系统实体集合。

系统域的划分以数据层的企业数据模型主题域为划分依据，并根据信息服务的要求进行细化。

如下图所示，信息服务层主要实现数据分布与处理和信息服务两个层次的功能。

3.2.2.2.1数据分布和处理功能

数据分布和处理功能对数据库、操作系统文件或其他形式存储的数据进行操作。

保证数据的完整性和一致性，屏蔽数据分布、数据模型和数据格式方面的差别，提供统一的数据逻辑视图。

数据分布和处理功能应当提供中介（Mediation）和适配（Adaptation）功能。

当底层数据模型或格式发生变化时，这两种功能可以对信息服务的使用者尽可能屏蔽此种变化。

3.2.2.2.2信息服务功能

信息服务功能将原始数据经处理和组合，形成具有业务意义或系统意义的操作实体。

这些处理可能包括数据的挖掘和过滤。

这一层次也可能采用适配或中介的方式，将企业范围的数据模型转换为操作所必须的业务概念。

3.2.2.2.3信息结构实施原则

系统信息的层次结构保证了系统在信息处理和系统结构的灵活性和对不同来源数据的适应性。

在数据和信息处理方面，必须保证：

Ø能够根据业务处理的需要，完成数据模型的适配和数据格式的转换。

Ø能够通过不同的技术手段，使用不同形式的存放的数据，例如，数据库、操作系统文件、其他系统的接口数据等。

Ø能够实现分布透明机制。

信息服务的使用者通过接口访问系统数据时，无需清楚数据的物理存储位置及存储格式。

3.2.2.3业务逻辑层

业务逻辑层实现系统业务逻辑相关的处理功能，它包括业务构件子层和展现构件子层，分别实现人机界面无关的业务逻辑构件与人机界面相关的界面展示构件。

业务逻辑层的构件以服务的形式提供与业务逻辑紧密相关的系统功能。

业务逻辑层构件的功能和关系的描述如图3-3所示。

图：

构件的作用和关系

业务逻辑构件使用信息服务构件提供的服务，实现并提供业务逻辑处理服务；界面展示构件组成界面展示的基本元素，它向控制层提供界面展示服务。

通过它们与信息服务层构件服务的集成关系可以实现独立的业务功能。

3.2.2.3.1业务逻辑构件

业务逻辑构件响应来自界面展示构件或外部系统的消息和请求，完成系统的各种业务逻辑处理，并通过调用系统信息构件提供的服务，操作和使用系统信息。

业务逻辑构件以高内聚、松耦合等系统分析设计原则聚合那些内聚性很强的操作和逻辑，提供适当粒度的业务处理服务。

3.2.2.3.2界面展示构件

界面展示构件由一组基本并紧密相关的界面展示单元组成，并通过这些基本的界面单元调用与之有较强内聚性的业务逻辑构件的服务实现一个独立的、带人机交互界面的业务功能。

界面展示构件向控制层提供界面展示服务，通过控制层对不同界面展示服务或业务功能服务的集成，实现完整的业务功能。

3.2.2.4控制层

控制层对系统行为以及其它资源进行关联和控制。

关联控制主要包括：

Ø对构件所提供的服务和系统资源的配置和控制。

Ø对业务流程的关联和控制。

Ø对人机交互界面的关联和控制。

控制层的关联和控制功能可以与构件分离以动态方式实现，也可以包含在构件功能内部以硬编码的静态方式实现。

以静态方式实现的控制层，其关联和控制逻辑分布在各个构件内部，此时控制层只是一个逻辑的存在。

为了能够迅速适应业务需求的变化和发展，应尽可能将业务构件提供的功能和对功能的控制相分离，利用系统服务框架所提供的策略管理、流程管理等技术实现动态的控制层。

界面集成是对不同界面展示服务之间的集成，它是控制层的一个重要功能。

界面集成是比业务功能集成更高层次的集成。

在界面构件的合理规划和设计下，通过界面集成可以提高开发部署效率、提高构件的重用性、有利于系统的健壮性和稳定性。

界面集成可以重用已有的企业内外资源，迅速满足客户和业务的需求。

界面集成也可以有两种方式：

Ø静态方式的界面集成，设计人员以编程的方式集成各类界面展示服务，提供人机操作界面，实现系统的业务功能。

Ø动态方式的界面集成，一定的界面集成工具，在策略管理和流程管理的控制下，通过配置来定义各个界面服务之间的关联关系，在系统运行过程中动态地决定界面的外观和行为。

动态控制层利用流程管理技术实现业务流程的动态定义和控制，利用策略管理及界面集成等技术实现界面外观和行为的动态控制。

动态控制层的实现有利于提升系统的配置能力、可扩展性和健壮性，保证系统迅速适应业务需求的变化和发展。

系统建设时应尽可能实现动态控制层，若各方面条件不具备，传统的静态控制层的实现也是可以选择的方案。

3.2.2.5系统服务框架

系统服务框架规定了系统运行的公共机制并实现系统内部的公共服务。

使用这些服务与机制可以简化系统构件的开发、部署和各种运行信息的管理。

保证系统运行的一致性和各构件的高度集成。

各应用系统可以建立私有的系统服务框架也可以共用同一个框架所实现的系统服务。

以下对各公共服务做一个简要的描述。

1）日志服务

日志服务记录并管理应用系统在某一时刻的运行状态，以对系统的运行过程与性能进行跟踪、分析与调测。

2）系统监控服务

系统监控服务实现对应用系统和运行环境的监控，分为监视与报警两部分功能。

监视功能可以主动地查询应用系统和运行环境的状态，也可以被动地接收并管理二者的告警信息。

报警功能根据一定的策略，以多种方式向维护人员和其它相关监控系统提交系统状态报告和告警。

3）配置管理服务

配置管理服务提供一种通用机制与工具管理系统的系统运行参数、业务功能参数与合约。

4）认证鉴权服务

认证鉴权服务统一管理系统相关的组织、操作员、角色、功能权限及数据权限。

支持对系统用户的认证、鉴权及授权功能。

如果企业已建立企业信息门户（EIP）系统，则认证鉴权服务必须支持EIP对认证鉴权服务的要求，实现系统单点登录等功能。

要求系统能够同时提供两种认证鉴权方式：

本系统的认证鉴权和支持公共的认证鉴权服务。

5）异常处理服务

异常处理服务发现并俘获系统发生的异常，并集中管理因异常而失败且必须恢复处理的业务事件的处理状态。

当系统发生异常时，集中的异常处理服务系统能够以统一的方式处理异常及管理失败的业务事件，保证应用系统运行的可靠性和业务处理的连续性。

6）流程管理服务

企业端到端业务流程的实现往往会涉及多个系统的多个功能模块。

为了降低系统间耦合程度，提高流程管理的灵活性，应该实现分层次的流程管理机制，即各系统内部实现自己的工作流管理，实现流程建模、流程配置、流程执行和流程监控等功能。

3.2.3规则引擎与流程管理框架的集成

大多数业务流程包含多个决策点。

在这些决策点处，将对某个条件进行评估。

业务流程根据这些标准或业务规则更改它们的行为。

实际上，这些业务规则对业务流程起到了推动作用。

这些规则通常嵌入到业务流程本身或自定义Java代码的内部，这将导致在将来的某个时候出现若干问题：

●业务规则比业务本身更改得更频繁，而更改和管理嵌入的业务规则是一个复杂问题，并超出了大多数分析员的能力范围。

因此，随着业务规则的更改，程序员通常要消耗大量时间来执行该任务。

●大多数企业都缺少中央规则信息库。

因此，策略中任何涉及到组织范围的更改都无法运用到所有业务流程中。

●业务流程无法重用规则。

因此，IT人员最终要为每个流程设计规则，这通常导致不一致性或冗余。

使用规则引擎将业务流程与业务规则分离：

避免这些问题的最佳方法是使用规则引擎将业务流程与业务规则分离。

在该方法中，规则公开为服务，而BPEL（BusinessProcessExecutionLanguage）流程在到达决策点时通过查询该引擎来利用这些服务。

该方法更为灵活，可以通过图形方式操作规则，而不是在编程语言中或在流程内部对规则进行编码。

业务用户可以使用工具自行编写规则，并且无需IT人员的协助即可进行部署后的规则更改。

由于大多数更新和功能增强是由业务用户执行的，因此可以显著减少维护成本。

规则引擎和BPEL是两种互补技术。

流程管理器可以提供高级工具来显示、设计和管理BPEL流程，而第三方规则引擎（如ILOG的JRules）使复杂的业务逻辑可以用类似英语的语法表示，并由非程序员领域专家对其进行编辑。

规则引擎与流程管理框架的集成：

为实现业务策略、业务流程并支持业务逻辑，以便设计人员在设计系统功能时知道应在何处应用每个相关技术——BPEL、业务规则、Java/Web服务。

必须将规则与流程分离，将规则引擎集成到流程管理框架中。

如下图所示，业务逻辑被分布到三个不同的IT基础架构层中：

业务流程层、Web服务层和规则层。

业务流程层：

该层负责管理业务流程的总体执行。

这些使用BPEL实现的业务流程可以是长期运行的业务流程、事务业务流程以及持久业务流程。

流程逻辑支持分布到Web服务/EJB调用中的高级事务（“sagas”）以及嵌套的子流程事务。

BPEL引擎支持对工作流进行审计和检测，因此比较适合于：

●将不易变化的工作流步骤与易变的业务规则分开

●实现行业流程

●实现需要补偿的流程

●支持流程的大型实例化

●设计需要审计的流程

●协调异构技术，如连接器、Web服务和支持Web服务调用框架（WSIF）的逻辑

Web服务层：

Web服务层将现有的应用程序层功能公开为服务。

这样，多个业务流程便可以重用这些服务，从而满足面向服务体系结构（SOA）。

Web服务实现功能逻辑和域逻辑。

功能方法通常是无状态和中等粒度的。

例如，Web服务可能包含系统数据的实用程序方法、实体操作和查询方法。

可以使用多种技术实现Web服务并隐藏实现平台之间的差别。

因此，该层比较适合于：

●为特定实体/域领域实现中等粒度的方法

●集成原有的代码/第三方工具

●封装应用程序层中的逻辑、自定义代码和实现

规则层：

规则引擎通常是复杂逻辑（涉及实体之间的一些相互依赖性以及与顺序相关的逻辑计算）的发源地。

从业务流程中以单独实体的形式提取业务规则可更好地对系统进行分离，从而提高可维护性。

规则引擎可以对规则集进行并行和按顺序的评估。

此外，规则能够对输入数据和中间数据的值进行评估并确定是否应引发规则。

与传统的Java过程代码相比，该模块设计提供了一个更简单、可维护性更高的解决方案。

此外，正如我在前面指出的，规则具备声明特性，并使业务分析员能够进行高级GUI编辑。

现代规则引擎的执行速度非常快，并提供了内置的审计记录。

规则层的典型特性包括：

●包含耦合和复杂的逻辑

●支持使用并行执行进行高效的业务逻辑评估

●包含基于多个业务规则评估构建的复杂返回结构

●允许将域逻辑转换为简单规则

●实现高度易变的业务策略

由于规则在Web服务层中公开为服务，因此可以在所有企业间应用程序中重用，从而简化了新应用程序和集成的开发。

3.2.4EAI集成模式

EAI技术的确对企业系统的多种应用集成提供了快速有效的系统实现工具。

EAI的最大优势在于利用中间件产品将应用模块之间点对点的网状接口改为星型的或总线型结构，简化的接口（或称为适配器）数量。

但是EAI也有不同的实现方式，其技术也是在不断演进的，下面我们对于传统的EAI和目前先进的EAI方式进行比较，并提出我们对基础数据应用平台系统集成模式的建议。

3.2.4.1传统的EAI模式

图1.传统EAI模式

如果单单利用EAI的中间件工具，包括统一的消息总线和数据格式等，实际只解决了应用模块间语法（即数据格式）的接口简化，利用所有应用模块都将自己的格式转换为XML。

但是在应用系统设计和集成的过程中，往往最复杂和最容易出问题的是业务逻辑，即语义。

如果没有统一的语义，应用模块之间还是需要点对点的网状接口，还需要设计nXn个适配器。

3.2.4.2我们建议的EAI模式

图2.我们建议的EAI模式

上图是我们建议的应用集成方式，可以看到显著的不同在与三个部分：

1、共享数据信息（SharedInformation/Data）

2、流程与数据分离（ExternalizedProcessControl）

3、以契约定义的接口（ContractDefinedInterface）

共享数据信息是建立统一的数据核心实体规范，主要是语义的规范。

其实现方式可以采用集中数据库，或分布式数据库存储都可以。

流程和数据的分离是解决应用模块之间业务逻辑或流程依赖的、实现系统灵活性的重要手段。

以契约定义的接口（Contract-