峨嵋山风景区数字化应用平台技术方案建议书.doc

峨嵋山风景区基础数据平台及企业数字化应用平台技术建议书四川银海软件有限责任公司2006年11月峨嵋山风景区基础数据平台及企业数字化应用平台技术建议书1前言32项目概述32.1项目简介32.2建设目标33总体方案设计43.1设计原则43.2技术路线43.3系统架构43.4系统网络结构44软件方案设计44.1设计思路44.2软件功能设计44.2.1数据存储子系统44.2.2数据应用子系统44.2.3集成统一平台44.2.4企业信息门户54.2.5营销决策支持子系统54.2.6运行维护系统54.3接口方案设计54.4支撑软件选择建议55现有应用系统改造方案55.1GPS车辆调度系统改造55.2酒店管理系统改造55.3财务系统改造55.4OA系统改造56硬件方案设计56.1总体部署方案56.2主机选择及配置建议56.3网络设计56.467系统安全设计68工程实施方案68.1项目组织68.2工程进度68.3质量管理68.4风险管理68.5培训68.6验收69技术支持与服务61 前言随着信息技术的高速发展，数字化技术已经渗透到工作和生活各个领域。 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 名词解释l EAI：EnterpriseApplication Integration，即企业应用集成。EAI是将基于各种不同平台、用不同方案建立的异构应用集成的一种方法和技术。EAI通过建立底层结构，来联系横贯整个企业的异构系统、应用、数据源等，完成在企业内部的 ERP、CRM、SCM、数据库、数据仓库，以及其他重要的内部系统之间无缝地共享和交换数据的需要。有了 EAI，企业就可以将企业核心应用和新的Internet解决方案结合在一起。EAI是目前解决企业数据孤岛最有效，最可行的方案。l ODS：Operational Data Store，即运营数据仓储。ODS是操作型系统中的集成,用于当前，历史以及其它细节查询(业务系统的一部分)，为决策支持提供当前细节数据(数据仓库的一部分)。l Web Service： Web Service是一种应用程序，使用标准的互联网协议，将功能纲领性地体现在互联网和企业内部网上，Web Service是一个通用型的接口，接口支持比较广泛，适用于不同架构系统间的通讯和集成。3 总体方案设计3.1 设计原则1) 构件式系统系统由一系列独立部署的构件组成，构件的设计应该满足以下要求： 构件多实例运行：应该尽量满足对每一个构件都可以同时运行多个构件实例的需求，以保证系统的高可靠性与可伸缩性。 构件接口定义稳定：应充分考虑构件间接口稳定性，使用XML或者类似的结构，以保证接口传输参数与内容的可扩展性。 构件粒度合理确定：应综合考虑系统性能、扩展性等方面的因素，同时兼顾系统在部署、维护和管理等方面的要求，合理确定构件粒度。2) 分布式、面向接口访问每个构件均可以承担服务提供者和服务使用者两种角色，服务使用者通过访问服务提供者的接口获取相应的服务。系统必须实现构件的分布透明机制。组成系统的构件实例可以部署在一台或多台主机上。构件提供的服务访问对分布地点、位置透明，服务使用者通过构件的逻辑名称即可获取服务而与构件所在主机的物理位置无关。3) 松耦合、高内聚原则系统设计须遵循松耦合、高内聚原则。构件之间保持松耦合状态，服务的具体实现方式对服务使用者透明。在构件内部所实现的功能与结构保持高度逻辑相关性的同时，保证构件间的相互独立性。4) 共享信息服务系统必须提供独立于业务的共享信息服务。共享信息服务遵循企业的数据模型规范，外部系统通过企业集成与接口平台，访问系统的共享信息，以实现系统间的集成与互操作。5) 业务过程与构件实现分离应综合考虑业务过程与构件实现的分离的原则，利用流程管理、策略管理和界面集成技术，动态地定义系统的行为以实现系统功能。应用此种技术在获得灵活性与可扩展性的同时，也应当充分预见其对系统性能带来的影响。3.2 技术路线3.2.1 应用整合平台应用整合平台是以EAI技术为基础，将不同地应用系统无缝地整合为一个完整的应用系统的基础架构，是企业级应用综合调度和运行、管理的基础平台。应用整合平台是各个子系统进行通讯的纽带，它不受具体业务的限制。应用整合平台主要由业务流程管理引擎、公共信息总线、公共数据服务，以及公用的数据转换服务、注册服务、安全服务、交易控制服务、日志服务和适配器开发框架工具型组件等组成。业务流程管理引擎通过对流程的定义、执行、管理和监控，提供了一个快速开发、部署和管理业务流程的软件平台；公共信息总线将所有的业务系统以相同的方式连结在一个用来相互通信的结构性部件上，实现不同系统间的互联互通；系统中最基本、最重要的数据模型构成了共享的核心数据，这些数据在应用整合平台中被集中存储、统一维护，通过公共数据服务向外部开发。应用整合平台中还包括一些公用的工具型服务组件。数据转换服务为不同应用系统间的数据分析、格式映射、格式转换提供通用的工具。注册服务负责维护所有服务组件的集中目录，供其他组件注册和查询。安全服务为应用系统提供统一的消息传输加密解密服务、应用访问权限控制等。交易控制服务负责对应用系统间的联机交易事务进行监控、管理，保证交易的一致性和持久性。日志服务为应用程序组件提供统一的日志记录服务，使得所有的应用系统间的交易有统一的日志记录以便监控和查询。适配器框架是应用整合平台向应用系统提供的适配器开发框架，使得我们可以快速地为应用系统开发出联接到EAI平台上的适配器。目前EAI的主流技术以应用服务器（如J2EE应用服务器）为基础，采用开放的XML、Web Service、BPEL等多种标准和技术实现。l 从技术上看，基于成熟应用服务器的EAI可以为企业提供以下好处： 可靠性：提供一个坚固的系统运行环境，具有强大的故障恢复能力、系统重新启动和恢复能力、数据可靠传输能力等。 可扩展性：提供动态部署能力，涉及交易方式、应用程序配置、对象服务嵌入等。 可管理性：系统要实现有效的管理，管理内容包括应用服务器、操作系统进程和线程、数据库连接，以及网络会话等。 数据一致性：交易完整性保障。 应用安全性：包括最终用户身份认证、节点连接的安全认证、应用程序的安全认证、管理界面的访问权限控制、数据加密解密功能、安全事件报警等。l 从业务上看，EAI可以为企业提供以下好处： EAI可以通过使企业提高业务流程效率、快速响应客户需求、改善客户服务、增加对客户的了解、强化客户忠诚度来改善客户关系、增加市场份额，从而增加收入。 EAI可以通过使企业增加管理层对业务的可视性和全面监控、减少IT开销、降低运营成本和重复性消耗、降低销售和售后服务成本来起到降低各种成本的作用。3.2.2 多层架构系统采用分层结构开发和设计，将界面、业务逻辑和数据分离，实现系统内部松耦合，以灵活、快速地响应业务变化对系统的需求。系统层次结构划分为数据层、信息服务层、业务逻辑层和控制层，通过各层次系统构件间服务的承载关系，实现系统功能。各层的应用构件利用系统服务框架所提供的基础服务实现系统公共设计、运行与管理机制。其中业务逻辑层及信息服务层中的构件必须遵守同样的设计规则并在一个统一的构件运行环境中运行。集成接口服务是系统开放给外部系统的接口服务。下图描述了系统的分层次的技术架构，方框外的公共支撑框架及企业应用集成平台不属于本工程的范围。以下将分别对这些系统内部层次进行说明。 数据层数据层负责系统的数据存储及维护数据的完整性与一致性。数据可以根据需要存储在数据库管理系统、文件、外部存储设备中。数据层数据的组织按照企业业务概念模型在应用软件上优化实现的要求形成各个主题域。 信息服务层信息服务层实现系统的共享信息服务。该层的构件实现对数据的封装，并把封装后的数据转换成有价值的业务与系统信息，通过合约接口，向其上的业务逻辑层和其他相关外部系统提供一致的与业务逻辑无关的信息服务。信息服务层按照系统域方式进行组织。系统域是一组与某一特定管理领域或概念紧密相关的高内聚的系统实体集合。系统域的划分以数据层的企业数据模型主题域为划分依据，并根据信息服务的要求进行细化。如下图所示，信息服务层主要实现数据分布与处理和信息服务两个层次的功能。.1 数据分布和处理功能数据分布和处理功能对数据库、操作系统文件或其他形式存储的数据进行操作。保证数据的完整性和一致性，屏蔽数据分布、数据模型和数据格式方面的差别，提供统一的数据逻辑视图。数据分布和处理功能应当提供中介（Mediation）和适配（Adaptation）功能。当底层数据模型或格式发生变化时，这两种功能可以对信息服务的使用者尽可能屏蔽此种变化。.2 信息服务功能信息服务功能将原始数据经处理和组合，形成具有业务意义或系统意义的操作实体。这些处理可能包括数据的挖掘和过滤。这一层次也可能采用适配或中介的方式，将企业范围的数据模型转换为操作所必须的业务概念。.3 信息结构实施原则系统信息的层次结构保证了系统在信息处理和系统结构的灵活性和对不同来源数据的适应性。在数据和信息处理方面，必须保证： 能够根据业务处理的需要，完成数据模型的适配和数据格式的转换。 能够通过不同的技术手段，使用不同形式的存放的数据，例如，数据库、操作系统文件、其他系统的接口数据等。 能够实现分布透明机制。信息服务的使用者通过接口访问系统数据时，无需清楚数据的物理存储位置及存储格式。 业务逻辑层业务逻辑层实现系统业务逻辑相关的处理功能，它包括业务构件子层和展现构件子层，分别实现人机界面无关的业务逻辑构件与人机界面相关的界面展示构件。业务逻辑层的构件以服务的形式提供与业务逻辑紧密相关的系统功能。业务逻辑层构件的功能和关系的描述如图3-3 所示。图：构件的作用和关系业务逻辑构件使用信息服务构件提供的服务，实现并提供业务逻辑处理服务；界面展示构件组成界面展示的基本元素，它向控制层提供界面展示服务。通过它们与信息服务层构件服务的集成关系可以实现独立的业务功能。.1 业务逻辑构件业务逻辑构件响应来自界面展示构件或外部系统的消息和请求，完成系统的各种业务逻辑处理，并通过调用系统信息构件提供的服务，操作和使用系统信息。业务逻辑构件以高内聚、松耦合等系统分析设计原则聚合那些内聚性很强的操作和逻辑，提供适当粒度的业务处理服务。.2 界面展示构件界面展示构件由一组基本并紧密相关的界面展示单元组成，并通过这些基本的界面单元调用与之有较强内聚性的业务逻辑构件的服务实现一个独立的、带人机交互界面的业务功能。界面展示构件向控制层提供界面展示服务，通过控制层对不同界面展示服务或业务功能服务的集成，实现完整的业务功能。 控制层控制层对系统行为以及其它资源进行关联和控制。关联控制主要包括： 对构件所提供的服务和系统资源的配置和控制。 对业务流程的关联和控制。 对人机交互界面的关联和控制。控制层的关联和控制功能可以与构件分离以动态方式实现，也可以包含在构件功能内部以硬编码的静态方式实现。以静态方式实现的控制层，其关联和控制逻辑分布在各个构件内部，此时控制层只是一个逻辑的存在。为了能够迅速适应业务需求的变化和发展，应尽可能将业务构件提供的功能和对功能的控制相分离，利用系统服务框架所提供的策略管理、流程管理等技术实现动态的控制层。界面集成是对不同界面展示服务之间的集成，它是控制层的一个重要功能。界面集成是比业务功能集成更高层次的集成。在界面构件的合理规划和设计下，通过界面集成可以提高开发部署效率、提高构件的重用性、有利于系统的健壮性和稳定性。界面集成可以重用已有的企业内外资源，迅速满足客户和业务的需求。界面集成也可以有两种方式： 静态方式的界面集成，设计人员以编程的方式集成各类界面展示服务，提供人机操作界面，实现系统的业务功能。 动态方式的界面集成，一定的界面集成工具，在策略管理和流程管理的控制下，通过配置来定义各个界面服务之间的关联关系，在系统运行过程中动态地决定界面的外观和行为。动态控制层利用流程管理技术实现业务流程的动态定义和控制，利用策略管理及界面集成等技术实现界面外观和行为的动态控制。动态控制层的实现有利于提升系统的配置能力、可扩展性和健壮性，保证系统迅速适应业务需求的变化和发展。系统建设时应尽可能实现动态控制层，若各方面条件不具备，传统的静态控制层的实现也是可以选择的方案。 系统服务框架系统服务框架规定了系统运行的公共机制并实现系统内部的公共服务。使用这些服务与机制可以简化系统构件的开发、部署和各种运行信息的管理。保证系统运行的一致性和各构件的高度集成。各应用系统可以建立私有的系统服务框架也可以共用同一个框架所实现的系统服务。以下对各公共服务做一个简要的描述。1) 日志服务日志服务记录并管理应用系统在某一时刻的运行状态，以对系统的运行过程与性能进行跟踪、分析与调测。2) 系统监控服务系统监控服务实现对应用系统和运行环境的监控，分为监视与报警两部分功能。监视功能可以主动地查询应用系统和运行环境的状态，也可以被动地接收并管理二者的告警信息。报警功能根据一定的策略，以多种方式向维护人员和其它相关监控系统提交系统状态报告和告警。3) 配置管理服务配置管理服务提供一种通用机制与工具管理系统的系统运行参数、业务功能参数与合约。4) 认证鉴权服务认证鉴权服务统一管理系统相关的组织、操作员、角色、功能权限及数据权限。支持对系统用户的认证、鉴权及授权功能。如果企业已建立企业信息门户（EIP）系统，则认证鉴权服务必须支持EIP 对认证鉴权服务的要求，实现系统单点登录等功能。要求系统能够同时提供两种认证鉴权方式：本系统的认证鉴权和支持公共的认证鉴权服务。5) 异常处理服务异常处理服务发现并俘获系统发生的异常，并集中管理因异常而失败且必须恢复处理的业务事件的处理状态。当系统发生异常时，集中的异常处理服务系统能够以统一的方式处理异常及管理失败的业务事件，保证应用系统运行的可靠性和业务处理的连续性。6) 流程管理服务企业端到端业务流程的实现往往会涉及多个系统的多个功能模块。为了降低系统间耦合程度，提高流程管理的灵活性，应该实现分层次的流程管理机制，即各系统内部实现自己的工作流管理，实现流程建模、流程配置、流程执行和流程监控等功能。3.2.3 规则引擎与流程管理框架的集成大多数业务流程包含多个决策点。在这些决策点处，将对某个条件进行评估。业务流程根据这些标准或业务规则更改它们的行为。实际上，这些业务规则对业务流程起到了推动作用。这些规则通常嵌入到业务流程本身或自定义 Java 代码的内部，这将导致在将来的某个时候出现若干问题： l 业务规则比业务本身更改得更频繁，而更改和管理嵌入的业务规则是一个复杂问题，并超出了大多数分析员的能力范围。因此，随着业务规则的更改，程序员通常要消耗大量时间来执行该任务。 l 大多数企业都缺少中央规则信息库。因此，策略中任何涉及到组织范围的更改都无法运用到所有业务流程中。 l 业务流程无法重用规则。因此，IT 人员最终要为每个流程设计规则，这通常导致不一致性或冗余。 使用规则引擎将业务流程与业务规则分离：避免这些问题的最佳方法是使用规则引擎将业务流程与业务规则分离。在该方法中，规则公开为服务，而 BPEL （Business Process Execution Language）流程在到达决策点时通过查询该引擎来利用这些服务。该方法更为灵活，可以通过图形方式操作规则，而不是在编程语言中或在流程内部对规则进行编码。业务用户可以使用工具自行编写规则，并且无需 IT 人员的协助即可进行部署后的规则更改。由于大多数更新和功能增强是由业务用户执行的，因此可以显著减少维护成本。 规则引擎和 BPEL 是两种互补技术。流程管理器可以提供高级工具来显示、设计和管理 BPEL 流程，而第三方规则引擎（如ILOG的JRules）使复杂的业务逻辑可以用类似英语的语法表示，并由非程序员领域专家对其进行编辑。规则引擎与流程管理框架的集成：为实现业务策略、业务流程并支持业务逻辑，以便设计人员在设计系统功能时知道应在何处应用每个相关技术BPEL、业务规则、Java/Web 服务。必须将规则与流程分离，将规则引擎集成到流程管理框架中。如下图 所示，业务逻辑被分布到三个不同的 IT 基础架构层中：业务流程层、Web 服务层和规则层。业务流程层：该层负责管理业务流程的总体执行。这些使用 BPEL 实现的业务流程可以是长期运行的业务流程、事务业务流程以及持久业务流程。流程逻辑支持分布到 Web 服务/EJB 调用中的高级事务（“sagas”）以及嵌套的子流程事务。BPEL 引擎支持对工作流进行审计和检测，因此比较适合于： l 将不易变化的工作流步骤与易变的业务规则分开l 实现行业流程 l 实现需要补偿的流程l 支持流程的大型实例化l 设计需要审计的流程l 协调异构技术，如连接器、Web 服务和支持 Web 服务调用框架 (WSIF) 的逻辑Web 服务层：Web 服务层将现有的应用程序层功能公开为服务。这样，多个业务流程便可以重用这些服务，从而满足面向服务体系结构 (SOA)。 Web 服务实现功能逻辑和域逻辑。功能方法通常是无状态和中等粒度的。例如，Web 服务可能包含系统数据的实用程序方法、实体操作和查询方法。可以使用多种技术实现 Web 服务并隐藏实现平台之间的差别。因此，该层比较适合于： l 为特定实体/域领域实现中等粒度的方法 l 集成原有的代码/第三方工具 l 封装应用程序层中的逻辑、自定义代码和实现 规则层：规则引擎通常是复杂逻辑（涉及实体之间的一些相互依赖性以及与顺序相关的逻辑计算）的发源地。从业务流程中以单独实体的形式提取业务规则可更好地对系统进行分离，从而提高可维护性。 规则引擎可以对规则集进行并行和按顺序的评估。此外，规则能够对输入数据和中间数据的值进行评估并确定是否应引发规则。与传统的 Java 过程代码相比，该模块设计提供了一个更简单、可维护性更高的解决方案。 此外，正如我在前面指出的，规则具备声明特性，并使业务分析员能够进行高级 GUI 编辑。现代规则引擎的执行速度非常快，并提供了内置的审计记录。规则层的典型特性包括：l 包含耦合和复杂的逻辑 l 支持使用并行执行进行高效的业务逻辑评估 l 包含基于多个业务规则评估构建的复杂返回结构 l 允许将域逻辑转换为简单规则 l 实现高度易变的业务策略 由于规则在 Web 服务层中公开为服务，因此可以在所有企业间应用程序中重用，从而简化了新应用程序和集成的开发。3.2.4 EAI集成模式EAI技术的确对企业系统的多种应用集成提供了快速有效的系统实现工具。EAI的最大优势在于利用中间件产品将应用模块之间点对点的网状接口改为星型的或总线型结构，简化的接口（或称为适配器）数量。但是EAI也有不同的实现方式，其技术也是在不断演进的，下面我们对于传统的EAI和目前先进的EAI方式进行比较，并提出我们对基础数据应用平台系统集成模式的建议。 传统的EAI模式图1. 传统EAI模式如果单单利用EAI的中间件工具，包括统一的消息总线和数据格式等，实际只解决了应用模块间语法（即数据格式）的接口简化，利用所有应用模块都将自己的格式转换为XML。但是在应用系统设计和集成的过程中，往往最复杂和最容易出问题的是业务逻辑，即语义。如果没有统一的语义，应用模块之间还是需要点对点的网状接口，还需要设计n X n个适配器。 我们建议的EAI模式图2. 我们建议的EAI模式上图是我们建议的应用集成方式，可以看到显著的不同在与三个部分：1、共享数据信息（Shared Information/Data）2、流程与数据分离（Externalized Process Control）3、以契约定义的接口（Contract Defined Interface）共享数据信息是建立统一的数据核心实体规范，主要是语义的规范。其实现方式可以采用集中数据库，或分布式数据库存储都可以。流程和数据的分离是解决应用模块之间业务逻辑或流程依赖的、实现系统灵活性的重要手段。以契约定义的接口（Contract-Defined-Interface）实现了系统模块之间动态操作的统一。以上三点是系统建设的核心思想，我们的综合服务提供平台是完全遵循以上思想设计的，其重点在与定义统一的数据实体和接口规范。3.2.5 共享数据存储由上面小节可知，统一的共享数据模型是新一代运营支撑系统的关键。而ODS是实现我们EAI模型的SID概念的一个重要实现。本节给出了ODS建设的技术架构。首先我们对IT系统中的数据进行分类，按照数据的量和重要性进行分类，得出四类数据，如下图：图3. 基础数据应用平台（ODS）建议数据分类l 核心主数据定义Master Data核心，非交易型数据，数据量相对较小，变化频度较低，应当在整个企业保持一致性，仅由渠道一个创建和修改，由所有业务实体所共享，统一维护以增强可靠性、数据一致性；提高企业运营效率，例如：用户信息，资源信息。l 主数据定义 Reference data 引用和参数数据 Reference Data，是一类主数据 Master Data，用于对其他数据进行分类，通常是代码表和引用列表，通常只有两列：主键和描述。例如：一些字典表，属性编码等。l 交易数据定义交易数据 Transactional Data，是各个业务参与者之间进行业务交互的记录，数据量较大，变化频率高，对性能和存储要求高 。例如：酒店客房订单，财务清单等。l 私有数据定义私有数据，是运营和操作的详细记录，数据量大，变化频率高，对性能和存储要求高，例如：操作日志，系统日志和应用系统临时数据。根据上面分类原则，我们将系统数据库分为两大类：应用数据库（ADB Application DB）和操作共享数据库（ODS）。下图展示了两类数据得区别与关系：图4. ODS与应用数据库私有数据每个子系统都有自己的应用数据库（ADB），ADB包括三类数据：核心主数据、交易数据以及私有数据。而ODS中主要包括两类数据：核心主数据和交易数据。考虑得系统的性能和稳定性，ADB中核心数据通过实时的EAI消息总线同步到ODS中，同步的方式可以是同步的或者是异步的，视具体数据的有关业务需求而定。而交易数据则通过ETL批处理的方式同步到ODS中。ODS中核心主数据由于实时性较高，主要用于各个子系统间的数据交互。也就是说当某个子系统需要访问其他子系统所拥有的核心子系统时，可以通过共享数据服务从ODS中直接获得，而无需访问其他子系统的ADB。其益处在于：一是减少对其他系统的性能冲击；二是如果其他系统是非标准组件，从ODS获取数据可以免去适配器的转换环节，从而大大提高子系统间交互的效率与性能。ODS的交易数据主要用于非实时性的统计分析和查询，以及作为数据仓库的中转库（staging area）。3.3 系统架构本节根据前面的系统设计原则和技术路线，结合客户的需求，给出了系统的总体架构建议。峨嵋山风景区基础数据平台及企业数字化应用平台系统采用管理服务系统，营销系统层，生态保护平台层等多级架构，每层又拥有不同的子系统，如下图所示：如上图，峨眉山风景区企业数字化应用平台包含三个体系：生态保护体系、管理服务体系和营销体系。整个系统建立在统一的共享数据中心平台上，有效的实现数据共享的要求。 由于本系统中各个子系统众多，关联频繁，为了明确在建设过程中各个承建商之间的工作范围，对整个系统的软件功能做了如下图的功能划分。其中智能控制中心门户、EAI接口、运营管理门户及其下属功能、经营分析门户及其下属功能、数据中心归总集成商负责，其他功能由各个子系统承建商负责，具体的划分图如下：从系统基本功能看，各层的子系统于基础平台系统保持一致，但各自承担不同的职责，共同构筑基础数据平台、企业应用平台的多级架构，满足各部门的不同需求。从系统功能上划分为客户门户、接口平台两大部分：3.3.1 客户门户 客户门户是系统重要组成部分，包括安全管理，系统资源管理，信息浏览/发布，后台管理等功能。l 安全管理：包括认证、授权和用户管理。用户认证：即用户登录，统一平台系统使用SSO（单点登录）技术，实现用户只需要作一次身份认证，随后就可以对所有被授权的网络资源进行无缝的访问，而不需要多次输入自己的认证信息。用户授权：使用角色，用户，组进行管理。角色，用于确定拥有哪些特殊的功能和可以访问的资源。用户，即系统使用者，一个用户拥有一个或多个角色且可以属于一个或多个组。组，类似于一个部门，包含了一个或多个用户的用户集合，系统可以为组定义组管理员（对应部门即部门经理），组管理员可以访问进行有特殊要求的操作（如察看组内其他用户的操作，工作情况）。用户登录后只可以看到自身角色被授权可以访问的资源，对没有被授权访问的资源不能进行访问。l 系统资源管理：管理系统可访问和不可访问的资源。包括添加资源、删除、修改资源，定义、修改资源的访问属性和方法。配置系统一级访问菜单。资源管理系统所管理的资源可以是基础数据应用平台自身的资源，也可以是接入统一平台的外部子系统。资源管理系统管理资源的属性，如访问方式和URL等。资源管理系统可和安全管理系统通信，设置资源的可访问、操作角色。l 信息发布：用于发布基础数据应用平台系统的各种信息，包括新闻，宣传资料，友情连接，广告等。信息发布、管理系统按模块进行划分，将信息发布到指定的模块里。信息发布系统可以对不同模块的信息发布进行不同的审批流程配置，审批成功后的信息及可以立即反映的系统上。l 后台管理：包括数据备份与恢复，参数管理，数据字典管理，系统监控，系统基本信息统计查询等功能。3.3.2 接口平台接口平台负责实现基础数据应用平台系统与外部系统的交互。该平台的主要功能是将外部系统的数据或调用格式转换为本系统内部EAI消息总线或数据文件标准格式，再与各功能子系统进行交互。基础数据平台及企业数字化应用平台以EAI为基础进行设计，系统本身并不具备任何的业务逻辑处理能力，它的主要工作是针对不同的系统定义不同的接口标准和规范，并把任意满足平台定义的接口标准和规范的系统接入到平台里面，并发布接入系统注册的服务为平台自身或其他系统使用。接口平台可以提供web页面集成也可以提供服务、数据集成。因此接口平台是系统最关键也是最重要的部分。l 接入标准：外部系统接入基础数据应用平台的关键是定义统一的接入标准和规范并提供必要的接口。接口平台针对不同的系统定义统一的接入标准和规范，并为接入平台的外系统注册服务。只有符合接入规范、标准的外系统才能进行接入和服务注册。接入方式可以为页面集成，服务接入等。n 页面集成，如外系统为可独立运行的web应用系统则将外部系统的页面直接连接到基础数据平台，通过预定义的外部系统ID和双方约定的加密算法和加密key进行互联。n 服务接入，如需要接入到基础数据应用平台的原系统为非WEB应用程序或只需要提供服务为其他系统所使用，则进行服务接入。标准为格式化的XML，接口方式可灵活多样，WebService，HTTP，JCOM，Socket等均可。如需要用户界面的支持可开发独立的用户界面(web应用系统)，再将开发的界面进行接入。l 用户映射：如接入平台的系统已经存在用户、角色管理则需要将外系统的用户、角色和平台系统的用户、角色进行映射，接口平台拥有用户、角色映射表，用于将接入的系统的用户、角色和平台系统的用户、角色进行一对一映射，方便用户验证、授权、管理等，实现单点登录。l 数据映射：当存在多个同样功能的外部系统(酒店管理系统，财务管理系统等)需要接入平台时，由于多个系统设计的理念或命名规范的不统一，为了不大规模的修改原外部系统，需要进行外部系统数据进行统一映射，规范到基础数据应用平台。将各个外系统的不同的核心数据和平台核心数据进行映射，外部系统需要提供数据操作接口，以达到数据同步。l 服务注册、管理：为了使接入平台后的系统的服务能为其他系统服务，需要将其提供的服务在平台系统进行注册，即定义标准接口契约。注册信息包括服务名，服务描述，服务提供、访问方式(WebService, Socket等)，服务输入，输出等。注册的服务以XML的形式存储在服务管理系统里。注册以后的服务可以供平台系统和其他接入平台后的系统进行调用。如一个外部接入系统需要调用另一个外部接入系统提供的服务时，它不会需要直接调用外部系统提供的服务，而是调用服务管理系统，由服务管理系统找到需要调用的服务，再通过标准契约接口进行调用。4 现有应用系统改造方案4.1 GPS车辆调度系统改造GPS车辆定位子系统能够在GIS电子地图上实时显示所定位的车辆，有利于快速反应，并可进一步加强勤务管理。改造方案:现行GPS系统需要向基础数据应用平台系统提供数据操作接口和应用服务接口，允许授权用户访问。首先将指挥调度系统集成进统一平台内，将现行GPS提供的服务在基础数据应用平台注册和发布服务, 并再为指挥调度系统增加GPS操作界面和功能，指挥调度系统就可以通过基础数据应用平台的接口平台使用GPS系统提供的数据服务和应用服务，实现GPS车辆无法与指挥调度系统互联。4.2 酒店管理系统改造数字峨眉山酒店管理系统的改造方案：l 数据库整合 峨眉山现有的酒店管理系统是独立运行的，每个酒店、宾馆都拥有自己的信息管理系统，相互之间无法进行数据共享。酒店管理系统改造的任务之一就是整合这些酒店的数据，使它们集中到一个统一的数据库中，为实现酒管信息的共享奠定数据基础。由于酒店管理系统不同，各系统的数据表差异可能会较大，为了避免因为数据结构变化所带了的程序的大规范修改，我们在基础数据应用平台建立规范的酒店交易数据表和酒店数据映射表，将各酒店独立的数据和基础数据应用平台数据进行映射，即建立和酒店的用户映射和业务数据映射，以实现数据的整合。l 资源共享 在数据库整合的基础上，实现各酒店、宾馆的资源共享。整合方案：整合部分操作界面，开发基于web的部分操作界面，包括异地查看客房状况、异地提供订房服务以及对酒店宾馆经营状况的综合查询统计等功能，这些功能将访问整合后的数据库或原系统注册在基础应用平台的服务，实现资源共享。l 集成接口 向基础数据应用平台提供数据和应用服务访问接口，允许授权用户访问。将各酒店管理系统的服务进行统一标准、接口整合，各酒店系统需要实现整合平台所要求的接口规范和要求，以实现数据共享和同步。如原系统不能提供服务的，需要基础数据平台提供方法来进行操作。接口实现方式可以是任意的，WebService, JCOM，Socket均可，但必须符合平台规范。4.3 财务系统改造数字峨眉山财务系统的改造方案：l 数据库整合将现有的单机版财务数据库整合到管委会或股份公司的财务数据库中。因为单机版应用程序的数据库没有数据服务器，数据结构不能简单、清楚的抽取出来，因此需要要求原财务软件开发商提供支持，抽取出现有的财务数据并提供他们的数据表结构即各字段含义，然后在统一数据平台建立基础财务表再将各财务软件和统一平台进行数据映射。l 集成接口向基础数据应用平台提供数据和应用接口，允许授权用户访问。将各财务管理系统的服务进行统一标准、接口整合，各财务系统需要实现基础数据应用平台所要求的接口规范和要求，以实现数据、服务共享和同步。如原系统不能提供服务的，需要基础数据应用平台提供方法来进行数据操作。接口实现方式可以是任意的，WebService, JCOM，Socket均可，但必须符合平台规范。4.4 OA系统改造OA系统的改造方案：l 数据库整合 峨眉山现有的OA系统是独立运行的，相互之间无法进行数据共享。OA系统改造的任务之一就是整合这些OA的数据，使它们集中到一个统一的数据库中，为实现OA信息的共享奠定数据基础。由于OA系统不同，各系统的数据表差异可能会较大，为了避免因为数据结构变化所带了的程序的大规范修改，我们在基础应用平台建立规范的OA交易数据表和OA系统数据映射表，将各OA的数据和基础数据应用平台数据进行映射，即建立和OA的用户映射和业务数据映射，以实现数据的整合。l 集成接口 向基础数据应用平台提供数据和应用接口，允许授权用户访问。将各OA系统的服务进行统一标准、接口整合，各OA系统需要实现整合平台所要求的接口规范和要求，以实现数据共享和同步。如原系统不能提供服务的，需要基础数据应用平台提供方法来进行操作。接口实现方式可以是任意的，WebService, JCOM，Socket均可，但必须符合平台规范。5 硬件及支撑软件系统方案设计5.1 总体部署方案本系统采用多层混合架构设计，物理分层部署，通过将数据库服务器、应用服务器、WEB服务器等主机分开部署，有效的满足系统各项性能指标；整个系统各部分均采用冗余设计，充分保障系统7X24无间断运行。具体设计如下图所示：5.2 数据中心数据中心的建设是整个系统的基础，所有的应用层面的功能实现都是在数据中心建立的基础上来设计的。由于本系统的数据种类总多，按照标书中要求按主题来组织数据的需求，我们对本系统的数据分成五大部分，包括生态数据库、空间数据库、运营数据库、影像数据库、外部信息数据库。其组织结构图如下：生态数据库用来存储各种生态监控设备记录下来的生态数据。空间数据库存储的是GIS系统使用的地图信息以及各种监控设备安置的位置信息。影像数据库用来存储各种数字监控设备产生的影像数据。统计数据库用来存储营销分析系统产生的各种统计分析数据。运营数据库存储的是本系统运行过程中产生的各种信息以及本系统的系统数据和基础数据。系统数据包括员工信息、组织机构信息、权限信息、各种系统参数以及日志信息等；基础数据包括各种基础设备定义信息和各种应用参数；运行数据包含各个子系统产生的日常业务信息，比如各景点门禁系统产生的游客进出信息，索道系统产生的运行信息，车辆管理系统产生的各种出车信息，酒店系统记录的游客入住信息，数字监控系统的日常运行信息以及无线景管通送回的日常运行信息等。外部信息数据库用来存储本系统以外得到的信息，包括各种法律法规、市场信息和竞争对手的信息等等。5.3 主机及存储系统配置建议在进行主机系统的设计时，我们主要从三个方面来考虑主机系统的性能指标要求：CPU性能：主要以服务器的TPM值作为相对选型参考值，但必须考虑到厂家公布服务器的TPM值一般是采用该服务器最大的硬件配置、接近100%的使用率所得到的TPM值，而实际的配置往往小得多，所以实际系统性能不会有公布值那么高，在设计服务器处理能力时，需要将一些实际经验值和TPM值一起综合考虑，在本方案设计中，主机的处理能力应该能够满足所有业务应用和一定用户规模的需求，而且需考虑全部系统的开销及应用切换时性能余量，再考虑30%的性能冗余。内存的大小：内存是所有程序运行的环境，在CPU和相关系统软件处理能力的范围内，内存空间越大服务器的事务处理性能越好，但不同的应用对内存的要求不同，所以在基础数据应用平台系统服务器内存设计中，需要从应用要求的角度来考虑，寻找最佳的配置。在基础数据应用平台系统，主要是数据库和应用服务器的计算，按我公司以往的大型数据库应用经验来看：Sybase数据库对内存较敏感，ORACLE和DB2其次，Informix内存要求最小，但Informix对CPU要求更多；应用服务器对于主机资源的占用约为数据库服务器的两倍左右。磁盘I/O性能：在CPU处理能力一定的情况下，磁盘的I/O速度，可使服务器的整体性能相差几倍到几十倍，所以在设计中要特别注意磁盘I/O的选型，磁盘I/O选择尽量大，同时考虑到单个磁盘的I/O速度是一定的，需要靠多磁盘的并行读取来提高磁盘I/O速度，在容量和性价比容许的情况下，尽量选择容量小而数量多的磁盘，能大大提高磁盘的I/O吞吐性能。5.3.1 主机选择及配置建议l 数据库主机配置建议：我们建议的数据库服务器为HP公司的rx8640。配置8颗Inter的itanium2双核1.6GHz的CUP，16G DDR2 内存，两块146GB 10Krpm SCSI硬盘。具体参数如下：设备技术参数CUP64位RISC芯片架构，支持SMP；最大可支持到32个CPU数量，主频1.6GHz，itanium2 CPU，三级缓存18MB；性能超过IBM 1.9GHz CPU内存每颗CPU配2GB内存，最大支持256GB单机当前性能当前配置8个CPU,TPCC值400000tpmc单机满配性能满配32个CPU时达到1600000tmpc动态逻辑分区最大支持640个动态逻辑分区，分区之间可灵活的动态计算资源硬盘当前配置2块146GB 10Krpm SCSI硬盘,，可以扩展到18块以上内置硬盘网络接口1000Base-SX光口全双工以太网卡2块光纤通道阵列卡2GB光纤通道阵列卡(HBA卡)3块高可用性支持I/O设备热插拔、CPU动态隔离与恢复、内存动态隔离与恢复、内存芯片双重备用、热插拔和冗余电源风扇等双机集群软件配置HP双机集群软件操作系统配置最新版本的UNIX操作系统, HP-UX 11i v2其他设备提供投标设备能正常运行所需的光驱、磁带机、特别支架、接口、插座、电缆、显示器、KVM等附件。若遗漏，中标商无偿自行补齐。投标时包括至少一套42U高度的19”标准机柜服务承诺提供原厂的三年7*24小时用户现场服务。提供原厂商对设备的服务承诺l WEB和应用服务器配置建议：我们建议的WEB和应用PC服务器为HP公司的HP DL580G04 X7120M。配置2颗Intel 双核Xeon 7120 3.0GHz处理器 (4MB三级缓存)，4GB REG PC2-3200 2x2GB ALL内存，2块72GB SAS 10K SFF热插拔硬盘 (2.5)。具体参数如下：设备技术参数CUP英特尔 至强 7120M 双核处理器 3.0GHz/800MHz集成 4MB 三级高速缓存内存双路交叉存取 PC2-3200 DDR2 registered SDRAM，运行速度为 400MHz，具有高级 ECC 功能，最大支持64GB硬盘2块72GB SAS 10K SFF热插拔硬盘 (2.5),转速10000rpm，支持RAID0,0+1,5网络接口集成双端口的千兆以太网卡其他设备支持2GB双FC卡、热插拔双电源冗余、热插拔双风扇冗余、机架上架套件以及基于硬件的远程控制端口服务承诺3年保修，3年人工，3年现场服务，7244惠普金牌服务5.3.2 存储选择及配置建议我们建议存储选择HP公司的EVA8000：设备