北京市应急指挥系统BEA方案-V1.docx
《北京市应急指挥系统BEA方案-V1.docx》由会员分享,可在线阅读,更多相关《北京市应急指挥系统BEA方案-V1.docx(41页珍藏版)》请在三一办公上搜索。
1、BEA技术建议 北京市应急指挥系统BEA技术建议V1.0BEA系统(中国)有限公司2006-01 目录1项目总体要求32信息平台技术要求4用户需求的服务媒介:4互联网4呼叫中心43北京市应急指挥系统BEA技术方案53.1北京市应急指挥系统SOA架构总体设计53.2应用支撑平台与集成环境63.3信息资源共享环境73.3.1数据服务平台73.4工作流平台153.5门户系统方案173.5.1内容管理173.5.2搜索功能183.5.3多渠道访问193.5.4门户安全管理203.5.5统一用户档案223.5.6单点登录233.6系统部署和管理243.6.1高性能243.6.2集群和可靠性253.6.3
2、系统监控,保证SLA263.7BEA实现的SOA架构优势273.7.1全面、统一的平台273.7.2基于标准的开放平台273.7.3简单、高效率实施294成功案例301 项目总体要求项目要求见项目需求书,此处略。2 信息平台技术要求用户需求的服务媒介:互联网用户需要通过互联网满足对信息的浏览、查询、决策、指挥、邮件服务、即时通讯等的需求。无线网络用户需要通过无线服务,满足随时随地浏览信息、查询信息、视频会议等的需求。呼叫中心用户需要通过人工和语音的呼叫服务满足信息服务,情况报告等语音服务需求。3 北京市应急指挥系统BEA技术方案3.1 北京市应急指挥系统SOA架构总体设计根据项目的需求,该项目
3、的应用可以分为几个层面:1. 底层的数据层通过数据库系统存储共享的业务数据,共享数据从各自业务数据库中提取,数据源之间进行复制和交换;2. 应用支撑层通过应用服务器支持程序组件的建立和运行;3. 数据服务层针对不同的应用,应用对数据的访问需要一个数据服务层,通过数据服务层,应用能够做到透明访问异构的和分布的数据库和文件系统,应用逻辑和数据源之间是松耦合的,通过中间的数据服务层提供跨数据库的关联和映射;4. 服务总线层通过服务总线,连接各类可重用服务模块,完成消息传递,数据转换,服务路由等功能;5. 工作流层穿接应用模块,按照工作流程构建业务流程,支撑部门内部和跨部门的流程建模,执行和管理,并结
4、合门户系统构建流程门户,构建SOA构架应用,工作流平台是必须的;6. 门户展现层可以针对不同类型的用户提供灵活的访问形式,根据不同用户类型提供个性化服务。北京市应急指挥系统,其逻辑结构可以按照上述六层来构建。其好处在于,从纵向结构上看,应用具有松耦合架构。具体的介绍如下:1. 在数据层数据库或文件系统可以进行数据交换;2. 应用支撑层通过开发基于J2EE的应用程序组件实现应用模块功能,组件可以封装为服务,组件的构建,运行和管理由本层支撑,应用支持层通过WebLogic Server实现;3. 在数据服务层数据的访问基于统一的入口,被访问数据则可以分布在外部相关单位的共享数据库和北京市应急指挥系
5、统的数据库中,通过数据服务层进行跨数据库的关联,数据服务层的访问可以通过Java接口或Web服务实现,数据访问层通过AquaLogic Data Service Platform产品实现;4. 服务总线层业务应用通过组件方式构建,组件可以方便的封装成Web服务,在系统之间被相互调用,服务总线层通过AquaLogic Service Bus实现;5. 在工作流层工作流层支撑流程建模,执行和管理,灵活的流程管理工具使生成和改变工作流程变得简单;6. 在门户展现层通过门户技术,北京市应急指挥系统门户中建立的各类应用展现portlet,信息内容的展现个性化。北京市应急指挥系统基于SOA的统一技术架构要
6、实现上述的系统层次和功能,需要SOA的构架设计和相应的BEA产品支持,做到开放、灵活和敏捷。下面分层介绍BEA的方案和产品技术特点。3.2 应用支撑平台应用支撑平台是通过BEA WebLogic Server应用服务器实现。具体的技术指标参照附件北京市应急指挥系统BEA方案-V1-应用服务器技术指标.doc。3.3 数据服务平台BEA 可以提供的解决方案包括数据访问平台通过AquaLogic Data Service Platform实现。数据服务层在北京市应急指挥系统中起着数据访问服务的作用,可以在跨系统在分布式数据访问中屏蔽数据源,形成基于XML的统一访问接口,数据结构,数据关联,数据目录
7、定义和数据访问控制通过数据服务平台完成。由于在数据库和应用之间加入了数据服务层,数据库表的修改不会影响应用代码,对今后系统的升级和改造提供灵活的结构。数据服务通过BEA AquaLogic Data Service Platform来实现。提供一种标准途径来快速地聚合并展现来自多种异构数据源的数据视图(包括 Web services, 数据库, 文件、XML文件、应用及Web站点等) 。这种数据视图可以通过Java API,RMI,Web Services等方法被应用,业务流程,门户应用所直接调用。下图是AquaLogic Data Service Platform的逻辑结构。(1)什么是数据
8、服务层?从架构的观点看,数据服务层是位于底层数据源集合之上的数据抽象层。从SOA的原理分析,数据服务层的作用是为所有读写操作提供一个访问点,并对“使用者”应用隐藏底层数据的物理结构和访问机制。为此,数据服务层提供了一个独立于底层数据源的接口,它公开用来读写数据的可重用数据服务的标准集合。下图描述了数据服务层在架构中的角色。数据服务层的一个重要优势在于,它遵循了一个重要的SOA原理“松耦合”将使用数据服务的应用与底层数据源提供者的依赖性降至最低。这样,应用将看不到数据源使用的底层物理结构及相关访问机制。“松耦合”允许数据库架构师在不更改层的接口或“使用者”应用的情况下,从数据服务层修改、组合、移
9、动甚至删除底层数据源。这样,数据库架构师既能为需要的应用提供信息,又能控制数据结构。随着时间的推移,这种提高的灵活性将简化企业应用的维护,并使企业更灵活、更敏捷地适应业务IT需求的变化。数据服务层的第二个优势在于:它提供了“单个”数据访问位置。很多企业都试图解决“数据真实性”问题,例如,名为“收入”的字段既可能指bookings数据库的预订收入,也可能指sales数据库的销售收入,在这里,“收入”项的真实含义取决于它的来源上下文,也取决于使用它的上下文。典型的数据服务层是访问广泛企业数据源的统一访问点机构之所以会遇到“数据真实性”问题,其中的一个原因是企业中存在大量数据源。另外,这些数据源分散
10、在不同应用中,使用情况又不尽相同,因而导致混淆。当用户试图理解一个数据段的真实含义时,经常会遇到以下四个问题。 对于将使用的上下文而言,数据可能来自底层数据源的一个错误位置 字段名不清晰,数据可能是错误信息 数据可能过时(例如,由于数据仓库更新间隔) 在读取或上次更新时,可能将一些不正确和(或)不完整的数据转换应用到数据上数据服务层解决了上述所有问题,它是企业中的单个数据访问点,使企业能够找到数据的“单个真实来源”。在实施数据服务层后,可确保从正确数据源获得数据,并将适当信息连贯地返给所有应用。另外,可在数据服务层对字段实施标准化,确保数据的描述清晰可辨,并将使用正确的数据源。数据服务层可确保
11、返回的数据是最新的,来自适当数据源,并且是实时获取的。最后,所有数据转换都被用于数据服务层,以确保整个企业应用和执行的连贯性。总之,通过使用数据服务层,机构可获得以下几个明显的好处: 应用与访问数据的复杂性隔离,故应用更易于创建。 更改数据源的影响范围一般只限于数据服务层,故应用更易于维护。 应用使用共享的数据服务、验证逻辑及服务封装的其他数据规则,故能获得更一致的数据。总之,使用BEA AquaLogic Data Services Platform的企业的敏捷性和反应速度更快,能够适应不断变化的市场要求。(2)构建数据服务层的传统方法传统上,开发人员在构建数据服务层时,会使用人工编码方式,
12、并将代码嵌入在建应用中。这种方法难以共享和重用数据服务。为此,企业开始寻找ETL(extract, transform, and load,提取、转换和加载)产品来构建服务层。ETL起初用来为业务报表应用创建数据仓库。在用ETL技术构建数据服务层时,将关联和复制多个来源的数据,将它们整合到一个数据仓库、数据中心或操作数据库,并将结果库作为数据服务层的数据源。对于“只读”或“查询密集”的小型企业应用集而言,这种方法非常有效,能支持周期性数据刷新(如分析或数据挖掘应用)。“添加新数据源”等更改一般需要重新设计,并重新加载中心数据库,故ETL方法最适于静态应用(此类应用的需求极少更改)使用。过去的经
13、验证明,这种方法适用于业务报表应用,这些应用执行统计分析、复杂数据汇聚或时间系列趋势计算,能从长期数据处理(如整夜)中获益。企业逐渐发现,ETL方法需要IT部门建立和管理ETL系统,并经常大规模移动数据,成本高昂。研究显示,由于迁移数据会带来初期和长久的硬件和磁盘空间成本,用于开发、支持、升级和监控ETL项目和工作的成本可能相当可观。(3)BEA AquaLogic Data Services Platform构建数据服务层的方法The BEA AquaLogic Data Services Platform 从底层设计开始简化为SOA实施开发数据服务的任务。该平台基于具有声明性服务定义的元数
14、据驱动方法,不需要人工创建工作流或代码,能自动完成许多数据服务创建和维护的工作。此外,声明性的方法能自动优化数据访问规划,减轻后台系统负担,提高系统综合性能。BEA AquaLogic Data Services Platform中的声明性编程:BEA AquaLogic Data Services Platform在数据服务的声明性定义中使用XQuery语言。声明性编程使数据服务架构师可以定义需要的服务及基础数据和服务;然后由BEA AquaLogic Data Services Platform来决定提供所需服务的最佳算法。该平台能够选择合适的数据源访问顺序、编排底层服务调用,在遇到RDB
15、MS数据源时,还能产生一组合适的SQL查询语句。它支持各种算法,可以创建高效SQL,将尽量多的查询处理委托给底层RDBMS数据源,只检索后处理形式的数据;为及时访问Web服务等高延迟资源,它还支持并行的、基于超时的故障转移工具。因此,BEA AquaLogic Data Services Platform提供对底层数据的自动访问、转换与关联以及底层数据访问优化。适应应用需求的服务:对于任意服务调用,应用可能需要许多数据子集和各种不同的结果。比如,对于一个返回客户数据的服务,应用可能需要查询按客户标识排序的数据(排序)、邮政编码为某特定数字的客户(筛选)、只要客户的姓(映射)或客户数量(合计)。
16、传统上,上述操作都必须是独立的服务调用,这些调用有相互重复的数据转换和确认逻辑。通常,以一个通用的getCustomer()服务调用获得上述所有数据是无法接受的,因为那会将太多的数据带到中间层,产生性能问题。BEA AquaLogic Data Services Platform的声明性方法使数据服务架构师能定义一个getCustomer( )服务调用,而不会产生性能问题。开发人员可以使用应用特有的过滤、排序、映射或合计等功能,BEA AquaLogic Data Services Platform动态地创建针对各种不同情况而优化的查询和更新规划。这消除了针对不同应用需求不断改变数据服务层的需
17、要,提高了数据一致性。服务上的服务(视图演化):如下图所示,声明性方法使数据服务架构师能利用现有服务定义新服务,而不必担心性能下降。BEA AquaLogic Data Services Platform引擎可以优化掉服务调用的中间层,为服务调用产生效率更高的数据访问规划。与此相反,基于工作流(或人工编码)的方法在服务调用其他服务时,性能会严重下降。各个服务按照编码执行,而不考虑高层服务需要的可能只是一小部分数据;而且每种服务都有自己的界限,要跨越界限需要进行多次数据复制和转换。因此,数据服务架构师经常不得不为所需的各个数据服务分别编写工作流。一次集成与重用:如下图所示,声明性方法使数据服务架
18、构师能够创建、共享、专用和重用数据服务。实例包括了提供单一“客户”视图的数据服务,或者提供重要业务实体的数据服务。在数据服务层,数据服务架构师经常创建许多类似的服务调用: getCustomerByID(custID) getCustomersByRating(rating) getTopCustomers( )如果客户数据是从多个数据源获取的,则执行这些数据服务的最有效的办法似乎是使用多个SQL查询和服务调用。使用BEA AquaLogic Data Services Platform,数据服务架构师可以创建一个通用的数据集成服务,比如getCustomerProfile( )。在这个主要的
19、“单一客户视图”上,可以方便快捷地定义多个专用服务。由于这些服务可以利用在底层服务中已经预先完成的集成工作,所以定义这些高层服务非常容易。此外,BEA AquaLogic Data Services Platform的声明性方法使其可以优化掉中间层,为在其上构建的服务产生更高效的访问途径。与此相反,用工作流或人工编码来处理此问题,需要为每个服务分别编写程序。BEA AquaLogic Data Services Platform的声明性方法,支持视图演化,消除了服务调用其他服务时产生的性能瓶颈。采用BEA AquaLogic Data Services Platform,通过重用现有服务,定义
20、新服务变得极为简单。而且由于与数据有关的规则在一个地方定义和使用后,可以一致地被所有相关的数据服务使用,因此该特性有助于提高数据的一致性。此外,由于改变只需在一个地方进行,使得对于这些规则的维护十分轻松,提高了一致性。BEA AquaLogic Data Services Platform采用独特的声明性方法来定义数据服务,支持数据访问逻辑的自动化,提供“一次定义,多次重用”的体验,极大地简化了数据服务的开发和日常维护。(4)定义数据服务BEA AquaLogic Data Services Platform提供了丰富的建模环境,能根据业务实体和它们之间的关系组织数据服务。使用这一环境,数据服
21、务架构师能在单一地点了解数据服务模式、服务操作和数据服务管理策略。良好的数据服务模型为应用开发人员提供了使用数据服务的指南,并让他们更有效地维护和重用数据服务。BEA AquaLogic Data Services Platform采用如图的“分段图(chip diagram)”,以图形化方式描述每个数据服务的功能。分段图以简洁的格式概括一个数据服务的信息,使数据服务架构师能够看到该服务及相关人工制品。图3演示了该数据服务的几个方面的信息: 数据服务的读功能 与之相关的数据形状,一种XML Schema 提供对相关数据服务访问的导航功能 一组用来定义它的低级数据服务BEA AquaLogic
22、Data Services Platform还支持数据模型图的创建和维护,该图以图形化方式记录和共享一个数据服务层的部分信息。与E-R或UML图表非常类似,每个数据模型图表都显示一组数据服务和它们之间的相互关系。BEA AquaLogic Data Services Platform中的数据服务,按照实际业务实体建模(5)数据转换通过数据服务平台提供的数据转换功能,在不同格式的数据之间相互转换,将数据格式转化为对方能识别的格式。这样就使得具有不同数据格式的服务能具备更广泛的兼容性。数据转换是指数据从一种格式向另一种格式的映射和转换。例如,非 XML 格式的数据可以转换为 XML 格式,反之,X
23、ML 格式的数据也可以转换为非 XML 格式。BEA的数据服务平台提供了基于XQuery技术的可视化的数据转换功能,能通过拖拽的手段快速实现不同格式之间的数据转换, 还可以对下列任意输入输出数据类型进行数据转换:XML 数据、非 XML 数据、Java 原子类型、Java 类。在这个过程中,不但能够实现数据格式上的变化,还能使用XQuery的函数,对数据内容本身做各种运算。此外,通过BEA服务平台实现的数据转换功能本身也可以被其他模块复用。可视化数据转换功能3.4 服务总线平台不同系统之间和指挥决策系统同北京市各级政府的相关系统之间的系统调用和信息交换,建议使用Web服务方法。为了建立开放的服
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 北京市 应急 指挥系统 BEA 方案 V1

链接地址:https://www.31ppt.com/p-1705232.html