北京市应急指挥系统方案样本

北京市应急指挥系统BEA技术建议V1.0BEA系统（中华人民共和国）有限公司-01

目录TOC\o"1-4"\h\z\u1 项目总体规定 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 系统监控，保证SLA 263.7 BEA实现SOA架构优势 273.7.1 全面、统一平台 273.7.2 基于原则开放平台 273.7.3 简朴、高效率实行 294 成功案例 30项目总体规定项目规定见项目需求书，此处略。信息平台技术规定顾客需求服务媒介：互联网顾客需要通过互联网满足对信息浏览、查询、决策、指挥、邮件服务、即时通讯等需求。无线网络顾客需要通过无线服务，满足随时随处浏览信息、查询信息、视频会议等需求。呼喊中心顾客需要通过人工和语音呼喊服务满足信息服务，状况报告等语音服务需求。北京市应急指挥系统BEA技术方案北京市应急指挥系统SOA架构总体设计依照项目需求，该项目应用可以分为几种层面：底层数据层——通过数据库系统存储共享业务数据，共享数据从各自业务数据库中提取，数据源之间进行复制和互换；应用支撑层——通过应用服务器支持程序组件建立和运营；数据服务层——针对不同应用，应用对数据访问需要一种数据服务层，通过数据服务层，应用可以做到透明访问异构和分布数据库和文献系统，应用逻辑和数据源之间是松耦合，通过中间数据服务层提供跨数据库关联和映射；服务总线层——通过服务总线，连接各类可重用服务模块，完毕消息传递，数据转换，服务路由等功能；工作流层——穿接应用模块，按照工作流程构建业务流程，支撑部门内部和跨部门流程建模，执行和管理，并结合门户系统构建流程门户，构建SOA构架应用，工作流平台是必要；门户呈现层——可以针对不同类型顾客提供灵活访问形式，依照不同顾客类型提供个性化服务。北京市应急指挥系统，其逻辑构造可以按照上述六层来构建。其好处在于，从纵向构造上看，应用品有松耦合架构。详细简介如下：在数据层——数据库或文献系统可以进行数据互换；应用支撑层——通过开发基于J2EE应用程序组件实现应用模块功能，组件可以封装为服务，组件构建，运营和管理由本层支撑，应用支持层通过WebLogicServer实现；在数据服务层——数据访问基于统一入口，被访问数据则可以分布在外部有关单位共享数据库和北京市应急指挥系统数据库中，通过数据服务层进行跨数据库关联，数据服务层访问可以通过Java接口或Web服务实现，数据访问层通过AquaLogicDataServicePlatform产品实现；服务总线层——业务应用通过组件方式构建，组件可以以便封装成Web服务，在系统之间被互相调用，服务总线层通过AquaLogicServiceBus实现；在工作流层——工作流层支撑流程建模，执行和管理，灵活流程管理工具使生成和变化工作流程变得简朴；在门户呈现层——通过门户技术，北京市应急指挥系统门户中建立各类应用呈现portlet，信息内容呈现个性化。北京市应急指挥系统基于SOA统一技术架构要实现上述系统层次和功能，需要SOA构架设计和相应BEA产品支持，做到开放、灵活和敏捷。下面分层简介BEA方案和产品技术特点。应用支撑平台应用支撑平台是通过BEAWebLogicServer应用服务器实现。详细技术指标参照附件《北京市应急指挥系统BEA方案-V1-应用服务器技术指标.doc》。数据服务平台BEA可以提供解决方案涉及数据访问平台通过AquaLogicDataServicePlatform实现。数据服务层在北京市应急指挥系统中起着数据访问服务作用，可以在跨系统在分布式数据访问中屏蔽数据源，形成基于XML统一访问接口，数据构造，数据关联，数据目录定义和数据访问控制通过数据服务平台完毕。由于在数据库和应用之间加入了数据服务层，数据库表修改不会影响应用代码，对此后系统升级和改造提供灵活构造。数据服务通过BEAAquaLogicDataServicePlatform来实现。提供一种原则途径来迅速地聚合并呈现来自各种异构数据源数据视图(涉及Webservices，数据库，文献、XML文献、应用及Web站点等)。这种数据视图可以通过JavaAPI，RMI，WebServices等办法被应用，业务流程，门户应用所直接调用。下图是AquaLogicDataServicePlatform逻辑构造。（1）什么是数据服务层？从架构观点看，数据服务层是位于底层数据源集合之上数据抽象层。从SOA原理分析，数据服务层作用是为所有读写操作提供一种访问点，并对“使用者”应用隐藏底层数据物理构造和访问机制。为此，数据服务层提供了一种独立于底层数据源接口，它公开用来读写数据可重用数据服务原则集合。下图描述了数据服务层在架构中角色。数据服务层一种重要优势在于，它遵循了一种重要SOA原理——“松耦合”——将使用数据服务应用与底层数据源提供者依赖性降至最低。这样，应用将看不到数据源使用底层物理构造及有关访问机制。“松耦合”容许数据库架构师在不更改层接口或“使用者”应用状况下，从数据服务层修改、组合、移动甚至删除底层数据源。这样，数据库架构师既能为需要应用提供信息，又能控制数据构造。随着时间推移，这种提高灵活性将简化公司应用维护，并使公司更灵活、更敏捷地适应业务IT需求变化。数据服务层第二个优势在于：它提供了“单个”数据访问位置。诸多公司都试图解决“数据真实性”问题，例如，名为“收入”字段既也许指bookings数据库预订收入，也也许指sales数据库销售收入，在这里，“收入”项真实含义取决于它来源上下文，也取决于使用它上下文。典型数据服务层是访问广泛公司数据源统一访问点机构之因此会遇到“数据真实性”问题，其中一种因素是公司中存在大量数据源。此外，这些数据源分散在不同应用中，使用状况又不尽相似，因而导致混淆。当顾客试图理解一种数据段真实含义时，经常会遇到如下四个问题。对于将使用上下文而言，数据也许来自底层数据源一种错误位置字段名不清晰，数据也许是错误信息数据也许过时（例如，由于数据仓库更新间隔）在读取或上次更新时，也许将某些不对的和（或）不完整数据转换应用到数据上数据服务层解决了上述所有问题，它是公司中单个数据访问点，使公司可以找到数据“单个真实来源”。在实行数据服务层后，可保证从对的数据源获得数据，并将恰当信息连贯地返给所有应用。此外，可在数据服务层对字段实行原则化，保证数据描述清晰可辨，并将使用对的数据源。数据服务层可保证返回数据是最新，来自恰当数据源，并且是实时获取。最后，所有数据转换都被用于数据服务层，以保证整个公司应用和执行连贯性。总之，通过使用数据服务层，机构可获得如下几种明显好处：应用与访问数据复杂性隔离，故应用更易于创立。更改数据源影响范畴普通只限于数据服务层，故应用更易于维护。应用使用共享数据服务、验证逻辑及服务封装其她数据规则，故能获得更一致数据。总之，使用BEAAquaLogicDataServicesPlatform公司敏捷性和反映速度更快，可以适应不断变化市场规定。（2）构建数据服务层老式办法老式上，开发人员在构建数据服务层时，会使用人工编码方式，并将代码嵌入在建应用中。这种办法难以共享和重用数据服务。为此，公司开始寻找ETL（extract，transform，andload，提取、转换和加载）产品来构建服务层。ETL起初用来为业务报表应用创立数据仓库。在用ETL技术构建数据服务层时，将关联和复制各种来源数据，将它们整合到一种数据仓库、数据中心或操作数据库，并将成果库作为数据服务层数据源。对于“只读”或“查询密集”小型公司应用集而言，这种办法非常有效，能支持周期性数据刷新（如分析或数据挖掘应用）。“添加新数据源”等更改普通需要重新设计，并重新加载中心数据库，故ETL办法最适于静态应用（此类应用需求很少更改）使用。过去经验证明，这种办法合用于业务报表应用，这些应用执行记录分析、复杂数据汇聚或时间系列趋势计算，能从长期数据解决（如整夜）中获益。公司逐渐发现，ETL办法需要IT部门建立和管理ETL系统，并经常大规模移动数据，成本高昂。研究显示，由于迁移数据会带来初期和长期硬件和磁盘空间成本，用于开发、支持、升级和监控ETL项目和工作成本也许相称可观。（3）BEAAquaLogicDataServicesPlatform构建数据服务层办法TheBEAAquaLogicDataServicesPlatform从底层设计开始简化为SOA实行开发数据服务任务。该平台基于具备声明性服务定义元数据驱动办法，不需要人工创立工作流或代码，能自动完毕许多数据服务创立和维护工作。此外，声明性办法能自动优化数据访问规划，减轻后台系统承担，提高系统综合性能。BEAAquaLogicDataServicesPlatform中声明性编程：BEAAquaLogicDataServicesPlatform在数据服务声明性定义中使用XQuery语言。声明性编程使数据服务架构师可以定义需要服务及基本数据和服务；然后由BEAAquaLogicDataServicesPlatform来决定提供所需服务最佳算法。该平台可以选取适当数据源访问顺序、编排底层服务调用，在遇到RDBMS数据源时，还能产生一组适当SQL查询语句。它支持各种算法，可以创立高效SQL，将尽量多查询解决委托给底层RDBMS数据源，只检索后解决形式数据；为及时访问Web服务等高延迟资源，它还支持并行、基于超时故障转移工具。因而，BEAAquaLogicDataServicesPlatform提供对底层数据自动访问、转换与关联以及底层数据访问优化。适应应用需求服务：对于任意服务调用，应用也许需要许多数据子集和各种不同成果。例如，对于一种返回客户数据服务，应用也许需要查询按客户标记排序数据（排序）、邮政编码为某特定数字客户（筛选）、只要客户姓（映射）或客户数量（共计）。老式上，上述操作都必要是独立服务调用，这些调用有互相重复数据转换和确认逻辑。普通，以一种通用getCustomer（）服务调用获得上述所有数据是无法接受，由于那会将太多数据带到中间层，产生性能问题。BEAAquaLogicDataServicesPlatform声明性办法使数据服务架构师能定义一种getCustomer()服务调用，而不会产生性能问题。开发人员可以使用应用特有过滤、排序、映射或共计等功能，BEAAquaLogicDataServicesPlatform动态地创立针对各种不同状况而优化查询和更新规划。这消除了针对不同应用需求不断变化数据服务层需要，提高了数据一致性。服务上服务（视图演化）：如下图所示，声明性办法使数据服务架构师能运用既有服务定义新服务，而不必紧张性能下降。BEAAquaLogicDataServicesPlatform引擎可以优化掉服务调用中间层，为服务调用产生效率更高数据访问规划。与此相反，基于工作流（或人工编码）办法在服务调用其她服务时，性能会严重下降。各个服务按照编码执行，而不考虑高层服务需要也许只是一小某些数据；并且每种服务均有自己界限，要跨越界限需要进行多次数据复制和转换。因而，数据服务架构师经常不得不为所需各个数据服务分别编写工作流。一次集成与重用：如下图所示，声明性办法使数据服务架构师可以创立、共享、专用和重用数据服务。实例涉及了提供单一“客户”视图数据服务，或者提供重要业务实体数据服务。在数据服务层，数据服务架构师经常创立许多类似服务调用：getCustomerByID(custID)getCustomersByRating(rating)getTopCustomers()如果客户数据是从各种数据源获取，则执行这些数据服务最有效办法似乎是使用各种SQL查询和服务调用。使用BEAAquaLogicDataServicesPlatform，数据服务架构师可以创立一种通用数据集成服务，例如getCustomerProfile()。在这个重要“单一客户视图”上，可以以便快捷地定义各种专用服务。由于这些服务可以运用在底层服务中已经预先完毕集成工作，因此定义这些高层服务非常容易。此外，BEAAquaLogicDataServicesPlatform声明性办法使其可以优化掉中间层，为在其上构建服务产生更高效访问途径。与此相反，用工作流或人工编码来解决此问题，需要为每个服务分别编写程序。BEAAquaLogicDataServicesPlatform声明性办法，支持视图演化，消除了服务调用其她服务时产生性能瓶颈。采用BEAAquaLogicDataServicesPlatform，通过重用既有服务，定义新服务变得极为简朴。并且由于与数据关于规则在一种地方定义和使用后，可以一致地被所有有关数据服务使用，因而该特性有助于提高数据一致性。此外，由于变化只需在一种地方进行，使得对于这些规则维护十分轻松，提高了一致性。BEAAquaLogicDataServicesPlatform采用独特声明性办法来定义数据服务，支持数据访问逻辑自动化，提供“一次定义，多次重用”体验，极大地简化了数据服务开发和寻常维护。（4）定义数据服务BEAAquaLogicDataServicesPlatform提供了丰富建模环境，能依照业务实体和它们之间关系组织数据服务。使用这一环境，数据服务架构师能在单一地点理解数据服务模式、服务操作和数据服务管理方略。良好数据服务模型为应用开发人员提供了使用数据服务指南，并让她们更有效地维护和重用数据服务。BEAAquaLogicDataServicesPlatform采用如图“分段图（chipdiagram）”，以图形化方式描述每个数据服务功能。分段图以简洁格式概括一种数据服务信息，使数据服务架构师可以看到该服务及有关人工制品。图3演示了该数据服务几种方面信息：数据服务读功能与之有关数据形状，一种XMLSchema提供对有关数据服务访问导航功能一组用来定义它低档数据服务BEAAquaLogicDataServicesPlatform还支持数据模型图创立和维护，该图以图形化方式记录和共享一种数据服务层某些信息。与E-R或UML图表非常类似，每个数据模型图表都显示一组数据服务和它们之间互有关系。BEAAquaLogicDataServicesPlatform中数据服务，按照实际业务实体建模（5）数据转换通过数据服务平台提供数据转换功能，在不同格式数据之间互相转换，将数据格式转化为对方能辨认格式。这样就使得具备不同数据格式服务能具备更广泛兼容性。数据转换是指数据从一种格式向另一种格式映射和转换。例如，非XML格式数据可以转换为XML格式，反之，XML格式数据也可以转换为非XML格式。BEA数据服务平台提供了基于XQuery技术可视化数据转换功能，能通过拖拽手段迅速实现不同格式之间数据转换，还可以对下列任意输入输出数据类型进行数据转换：XML数据、非XML数据、Java原子类型、Java类。在这个过程中，不但可以实现数据格式上变化，还能使用XQuery函数，对数据内容自身做各种运算。此外，通过BEA服务平台实现数据转换功能自身也可以被其她模块复用。可视化数据转换功能服务总线平台不同系统之间和指挥决策系统同北京市各级政府有关系统之间系统调用和信息互换，建议使用Web服务办法。为了建立开放服务调用管理框架，建议使用BEAAquaLogicServiceBus服务总线产品。BEA提供了服务平台，提供了服务管理、服务路由、服务编排、数据转换和消息代理等功能。在BEA提供服务平台中，“服务”代表了业务功能上可被复用应用模块。它不但仅可以是Web服务（WebServices），还可以是使用其她任何开放手段可访问到应用资源，这些开放技术涉及Tuxedo、CORBA、消息机制、适配器、DCOM等。这种服务多样性充分扩展了开放平台资源管理范畴，无论是采用Java、C、C++开发应用系统，还是使用CORBA、Web服务、消息机制实现异构系统，这些资源都可以做为可复用业务资产，通过开放系统架构实现灵活互联互通。服务管理一方面通过集成功能，将客户系统中所包括使用不同实现技术、运营在不同平台应用接入到应用架构中。在完毕集成单独应用后，这些应用模块就成为在开放架构中可以被复用业务模块了。为了进一步增长应用和数据灵活性，来适应业务发展需要，可以将这些接入应用和数据资源交给核心层服务平台进行管理。图：BEA服务平台服务资源管理BEA提供服务平台可以集中管理集成层接入各种应用服务，它可以从注册到其中服务自身描述（WSDL）中得到服务特性，然后对众多基于服务应用资源进行集中管理。通过集中、有效管理可复用应用服务，可以清晰理解在信息平台应用架构中有哪些应用和数据资源；这些资源是由什么应用或数据源提供服务；它们后台实现实分布在哪些系统内部；它们都可以提供什么可重用业务功能；如何才干访问它们等信息；它们提供什么安全保护，从而真正实现了应用服务资产管理。服务路由使用服务路由功能，可觉得信息平台实现更加非常灵活业务调用过程。在BEA提供服务平台中，可以实现基于业务规则服务路由功能。一方面服务使用方通过服务平台访问某个服务入口，当服务平台接受到顾客祈求后，如果在服务调用过程配备了访问路由，那么平台会使用路由配备表进行基于业务规则匹配，然后依照不同匹配成果，将顾客对服务祈求路由到后台不同业务提供者。

图：BEA服务平台服务路由配备功能BEA实现基于应用信息服务路由功能可以通过可视化路由配备界面实现，这样可以在应用系统在运营时候，更加灵活、以便适应业务动态变化需要。可用用来做为判断路由准则数据可以涉及：传递进来业务信息，与顾客有关环境信息（applicationcontext），通过接口可以访问到外部信息等内容。服务路由规则可以通过服务平台可视化编排界面实现既可。如果路由规则比较复杂，建议使用规则服务提供更加灵活实现。服务在路由过程中，可以结合核心层负载均衡，并能动态判断后台服务系统连通状况，实现智能路由功能。顾客祈求可以通过负载均衡转到负载较小服务器上，这样可以对外提供更好QoS保障。服务编排服务路由功能实际是服务编排其中一某些。BEA服务平台能提供更多强大服务编排功能。其中除了服务路由提供了较为重要功能外，其她重要功能还涉及：图：BEA服务平台中丰富、灵活服务编排功能Skip（跳转）——跳转到服务编排中指定解决节点位置上。Reply（回应）——终结服务编排调用，向调用者返回服务编排成果。IfThen（判断）——服务流程判断构造。PublishTable（分支）——服务流程分支构造。WebServiceCallout（Web服务外调）——调用指定Web服务。Validate（校验）——使用XML，校验数据格式或数据内容。Insert（添加）——添加新环境变量内容。Replace（替代）——替代环境变量内容。Delete（删除）——删除环境变量内容。Rename（更改名称）——更改环境变量名称。RaiseError（错误解决）——定义错误解决方式。Log（日记）——定义记录日记记录信息。

图：图形化服务编排功能通过上面这些灵活服务编排功能和可视化编排实现，BEA服务平台可以实现非常灵活地组合可被重用业务服务来适应不断变化业务需求。工作流平台指挥决策业务过程中，会有一系列工作流过程，为了构建灵活业务应用，需要工作流工具支持。BEAWebLogicIntegration中BPM功能较好支持政府部门工作流。下图是申请工作流示意图。要实现面向服务核心系统，仅有底层组件服务剥离是远远不够，各种原子服务、分子服务最后应成为应用实现层面上逻辑，而业务组装、修改、运营则应与应用实现分离而通过流程管理器来实现。通过可视化界面，对各原子或分子服务进行组装形成新业务。因而，工作流管理器就成为业务支撑系统核心，将业务系统构造在基于原则工作流基本上，实现业务逻辑和应用逻辑剥离，使得业务管理人员可以自行定义和管理数据业务流程。下图是WebLogicIntegrationBMP开发视图：WebLogicIntegration业务流程管理工具BPM基于原则BPEL。业务流程执行语言（BPEL）容许指定业务流程以及它们和Web服务关系。其中指定了业务流程是如何使用Web服务来达到它目，还指定了由业务流程提供Web服务。用BPEL指定业务流程是完全可执行，且在符合BPEL环境间是可移植。无论实现BPEL业务流程伙伴Web服务与否基于BPEL，BPEL业务流程都能和这些Web服务互操作。最后，BPEL支持单位之间业务合同规范和复杂内部业务流程视图。工作流实现功能内外部之间指挥决策业务流转实现 对于指挥决策系统中复杂指挥决策流程，BEAWeblogicIntegration支持各种跨不同地区部门、跨不同平台流程。中心中心平台业务流程引擎工作列表流程管理外部平台业务流程引擎工作列表审

批

调

用

接

口审

批

调

用

接

口发起流程图：跨不同指挥决策平台指挥决策流程实现如上图所示，发起指挥决策流程是运营在指挥决策平台上。当指挥决策业务需要外部平台审批时候，业务流程引擎可以调度审批流程。所有和指挥决策有关材料也通过调用接口传到外部平台。如果外部平台完毕审批，系统还可以把成果返回给指挥决策平台。使用BEAWeblogicIntegration，可以有各种办法实现调用分布服务接口。基于J2EE消息机制接口调用流程将所有必要信息通过JMS发送到BEAWeblogicIntegration消息代理中。而被调用通过监听订阅消息通道中特定消息，当有发给它自己指挥决策调用时候，异地指挥决策平台启动指挥决策流程。Web服务通过Web服务技术将业务流程封装，Web服务会将指挥决策流程启动功能放在接口中。调用流程通过调用布置在异地Web服务来启动一种远程指挥决策流程。工作流平台实现核心BEAWelogicIntegration业务流成管理功能（BPM）为指挥决策系统服务功能提供了一种易用、可靠、开放、可管理平台，是指挥决策功能实现核心。它重要特点是：以集成框架为基本，完全包括集成平台中基于接口功能系统间信息将不但仅是用于共享，这些信息将被有效管理起来集成平台要包括工作流管理器功能和工具集成平台中扩展重要功能涉及：工作流定义、信息自动路游，自动判断。BEAWelogicIntegration业务流程管理功能重要涉及了：可视化流程定义工具BEAWeblogicInegration通过可视化集成开发工具BEAWeblogicWorkshop来定义流程业务。业务流程引擎保存了可视化创立业务流程能力，因而具备灵活性，使顾客得以集中精力专注于应用逻辑，而不必关怀实行细节。事实上，顾客构建是业务流程图形化表达。图：可视化业务流程定义在运用BEAWebLogicWorkshop中图形化工具(设计视图)设计业务流程过程中，BEAWebLogicWorkshop用定义业务流程XML，为JPD(Java流程定义)文献作注释。当需要编写Java代码时，单击访问（源代码视图）就可使用它。BEAWebLogicIntegration业务流程管理功能，使公司开发人员具备了开发、运营、维护复杂业务流程能力。业务流程将公司既有系统、整个公司各种应用以及决策人员集成在一起。业务流程引擎业务流程引擎是指挥决策系统指挥决策平台核心实现核心，它将业务系统构造在基于原则工作流基本上，实现业务逻辑和应用逻辑剥离，使得管理人员可以自行定义和管理数据业务流程，实现业务管理闭环构造。业务流程引擎能解释、运营定义流程。一方面流程引擎会创立指挥决策流程实例，每个流程实例是一种独立指挥决策业务。可以通过各种方式启动一种指挥决策流程：顾客积极调用，时间定期运营，接受到订阅消息道指定消息。一旦指挥决策流程开始，流程引擎会调度、监控各项流程中活动，例如指挥决策业务需要自动获得农产品记录数据，流程引擎就会自动通过应用程序接口调用计算记录模块，并把所得成果返回工作流中。当指挥决策流程需要人为参加指挥决策时候，系统会按照定义，为目的指挥决策顾客建立“指挥决策任务”，与此同步流程引擎实时监控顾客任务列表执行状况，一旦顾客解决完指定给她任务后，流程会自动往下执行。图：BEAWeblogicIntegration业务流程实现机制BEAWeblogicIntegration提供业务流程引擎是基于开发原则BPEL（流程执行语言BusinessProcessExecutionLanguage）基本上。BPEL是一种流程定义语言，用于指定包括Web服务业务流程。BPEL合用于支持业务流程逻辑"宏观定义"。这些业务流程均是完整而独立应用，它们将Web服务作为实现其业务功能"活动"。在BEAWeblogicIntegration定义业务流程中可以调用各种各样系统资源。涉及通过JDBC读写数据库，通过J2CA应用适配器来调用系统遗留应用，通过Web服务接口调用布置在异地应用，通过JMS触发消息机制。通过EJB接口调用应用逻辑。BEAWebLogicIntegration使用J2EE兼容型技术，涉及Java基本、JSP和EJB互操作性、用于流程元素间数据传送XML以及用于业务流程组件间消息传送JMS。这些开放原则意味着在IT人员技能合用于不同项目，并且IT人员可以协同完毕同一项目不同某些。因而，使用原则技术（XML）和开放编程API意味着解决方案可以扩展，为将来发展留有余地。业务流程工作列表BEAWeblogicIntegation提供了业务流程工作列表（Worklist）功能。它表反映出每个参加指挥决策人员当前和哪些指挥决策工作有关，例如待办指挥决策事务，未办指挥决策事务，有关指挥决策事务，跟踪任务状态等。它使人们能在业务流程内协作，完整工作流涉及各种操作，例如接受、批准、修改和路由文档业务人员通过访问自己工作列表可以懂得和自己岗位有关工作内容，并迅速解决。BEAWeblogicIntegation工作列表还容许业务员人员将分派给她指挥决策任务做其她操作，例如：回绝接受，转分派给其她业务人员等。业务流程监控与管理业务流程是随着外部顾客更高规定、内部部门职能变化等因素不断发上变化，这就需要业务流程能灵活适应这种变化，从而为广大顾客提供不断完善业务功能。BEAWeblogicIntegation业务流程管理功能提供了强大业务流程监控，记录，管理功能。通过这些详细监控手段，业务管理人员可以全面掌握流程运营状况，分析流程流程安排合理性，为优化各种业务流程提供了详细数据根据。流程监控功能能为监控每个运营在流程引擎中业务流程实例各种信息，涉及流程实例启动者、开始时间，完毕时间，总共运营时间，运营节点位置，当前流程运营状态。已经指挥决策完每个节点信息涉及：开始时间、指挥决策历时、结束时间、指挥决策人等。并且这些信息都是通过下面可视化管理界面来实现。 图：业务流程管理监控可视化界面Portal技术概念Portal一词本来是"门户网站"意思，例如雅虎、新浪等这样网站。但是对于政府和公司公司信息化平台建设而言，Portal所扮演角色则有所不同。本来业界对Portal定义有诸各种分类，例如把Portal定义为信息门户、协作门户、专业门户、知识门户等等。但不论分类如何划分，Portal对底层规定和其基本架构有明显一致性，并且随着时间推移，业界、新闻界以及分析家都对Portal定义看法逐渐趋于一致。简朴说，门户是一种重要Web站点并且是一种联合社区，它提供内容汇集、搜索服务、协作工具、应用程序访问和集成，所有这些功能存在于与最后顾客进行个性化交互中。通过个性化"我主页（MyHomePages）"来满足每个最后顾客需要并将个性化嵌入门户服务和应用程序各个角落，咱们可以对门户加以区别。另一方面，门户与Web站点不同，由于它用几乎相似办法将个性化与选取内容、协作功能程序以及应用程序服务结合在一起。对最后顾客而言，门户就是一种到所有计算资源单独访问点。门户（Portal）是Web应用程序简朴统一访问点,不但如此还提供了许多有价值附加功能，例如安全性、搜索、协作和工作流。门户网站提供了集成内容和应用，以及统一协作工作环境。事实上，门户网站就是下一代桌面，可以在Web上向各种客户机设备提供大量电子商务应用。BEAWeblogicPortal完整门户网站解决方案可以让顾客随时随处、安全、以便地访问完毕她们任务所需所有东西。门户网站是延伸与顾客体验（Reachanduserexperience）核心。也就是说，门户网站提供工具和顾客界面，用于访问信息和应用程序，个性化管理和选取内容。 集中完毕应用认证和授权管理。门户服务将承担顾客对各种信息和应用资源统一访问服务，对顾客身份进行验证，并控制顾客对各类资源访问权限。 构建、连接和管理应用程序。为公司应用整合提供基本支撑，通过Portal服务，公司可以将各种分散应用服务功能整合在门户服务平台上，以便顾客对各种应用资源访问，使各种独立应用系统通过门户服务平台形成一种完整应用。 业务流程集成和自动化。通过门户服务平台提供功能化服务组件，如：工作流服务组件，公司可以实行大量以业务为导向业务流程集成和自动化解决。为各种顾客提供个性化访问功能。通过门户服务咱们可以有效定义和控制各种不同顾客可以获得和访问信息内容。在大型信息化门户平台中，需要对不同业务资源进行整合，有组织地对顾客进行展示。通过下面办法，在WebLogicPortal中，将整个公司资源充分运用并有机组合，以灵活和有序方式进行展示。Portlet：Portlet是门户中某些应用或应用视图，可以被当作不同内容版块。依照开发方式不同，BEAWebLogicPortal可以支持不同类型Portlet（JSP/HTML、Web服务、Pageflow或Java），开发人员可以使用Portlet来集成公司系统中位于不同位置数据和访问不同性质应用，并以统一方式进行展示。Web集成：通过WebLogicPortal，不但可以用Portlet直接透视公司数据。同样，如果这些数据已经通过Web方式进行了展示，或者需要在Portal中集成其她Web页面信息，Portal提供了Web内容集成功能，将其她Web页面内容嵌入公司Portal，使Portal成为所有资源统一入口。WebServices：公司门户中某些数据也许是通过访问WebServices应用得到。WebLogicWorkshop中可以使用简朴可视化开发工具，简化对WebServices访问，以便将对WebServices访问迅速地集成到公司门户中。页面流Pageflow：公司级应用往往建立在MVC技术基本上实现，在WebLogicPortal中，实现了以Struts为核心流程控制管理功能，页面逻辑、后台服务（由EJB等实现），数据效验和流程控制在统一图形化界面中完毕。可以使应用开发进行合理分工，同步保证了整个系统灵活性，同一种后台服务可以同步为不同界面逻辑服务。只要系统管理员将应用进行相应配备就可以实现。内容管理内容管理系统是门户重要功能之一。管理人员通过内容管理完毕网站信息采集、编辑、审核、发布。BEAWebLogicPortal提供内置内容管理系统模块，同步也可集成第三方内容管理系统。内容管理系统可以与门户系统无缝集成，支持门户网站统一目录服务，系统必要通过门户网站管理系统认证后进入，向各类顾客提供统一访问点。内容管理系统应能提供对信息收集、组织、筛选、分类、搜索和自定义等一系列功能，实现对非构造化和构造化数据高效和有序统一管理和存储。支持顾客管理和权限设立，并能让顾客依照自身状况迅速搭建内容组织构造。

提供对信息安全性多级别、多方式定义，以保证信息完整、真实和安全。

可预先定义信息发布形式和页面显示格式。

内部和外部顾客可以通过浏览器、智能搜索、个性化工具等迅速获得信息。支持本网站全文检索。支持多语种。支持模板管理。支持系统集成。提供二次开发接口。搜索功能BEAWebLogicPortal内置搜索引擎支持各种后台数据源，这种灵活性容许依照门户顾客业务需求，从各种数据库中搜索非构造化、半构造化和构造化信息：JDBC，ODBC数据源：支持任何可以访问到JDBC和ODBC数据源，对数据库中数据库进行搜索。文献系统数据源：涉及HTML文献、文本文献、PDF文献、Office文献等外部HTTP数据源：支持顾客指定HTTP地址，系统会自动分析该网站内所有内容，并将分析成果保存检索库中。BEAWebLogicPortal内置搜索引擎支持了各种搜索方式和功能：联合搜索：支持在查找内容之间设立联合逻辑功能。自然语言搜索：支持搜索成果匹配度：支持按照匹配限度，对搜索成果排序功能。所搜成果排序内容有关性分级BEAWebLogicPortal搜索功能拥有全文检索能力。它使用了成熟模式匹配技术，无论英文还是中文，都能将原文中内容通过提取环节，放到更适合高速查询索引文献中。顾客发出所有内容查询，都是通过索引库迅速定位到指定信息上。BEAWebLogicPortal对于国际化语言有较好支持。由于BEAWebLogicPortal搜索功能是通过开放接口来实现，因而对于不同语言种类，可以通过开发针对不同语言语法分析器，来而实现国际化科技信息检索和搜索。当前BEAWebLogicPortal支持语言种类有：英文和所有单字节语种双字节语种：中文，日文，韩文，泰文等由于国家科技基本条件平台上可以被搜索科技信息和数据非常众多，必要要考虑顾客在访问这些数据和信息安全性。平台安全体系除了可以保证集成到平台应用安全性，还应当保证顾客对搜索成果安全访问。不同级别、分组和角色顾客对科技数据访问范畴是不同，某个范畴顾客应当只可以搜索到安全控制机制中所规定资源范畴。对于没有授权顾客访问数据信息，此顾客是不可以通过搜索工具查找该信息。此外，门户搜索内容和安全访问设立需要通过统一安全平台，统一管理界面进行灵活，迅速配备。BEAWebLogicPortal搜索功能也是基于开放架构来实现。不但在生成内容索引时候，可以通过开放接口，实现不同语言语法分析器，还能通过实现统一一致搜索引擎接口，可以以便快捷集成进第三方搜索引擎。多渠道访问在可北京市应急指挥系统将来系统接入前端必然会以各种方式存在，例如手机访问、PDA访问、笔记本无线访问、文字终端等。为了系统可以适应将来应用趋势发展，需要各种前端设备统一接入解决方案。BEA平台与其她产品最大不同在于不是以网关位置来判断接入设备而是以访问合同来判断，而是依照每种类型接入设备发出不同祈求格式来判断它们。通过该技术可以最精确最简便判断出当前接入设备类型。依托内置内容翻译器可以对所提供内容按合同及方略进行转化以适应当前接入设备。内容翻译器可以按照不同访问终端类型，将门户显示内容自动翻译成适合它们浏览格式。这样北京市应急指挥系统需要实现一套门户系统，就可以满足各种不同终端访问了，而不必针对每种终端设备单独实现一种门户。

图：BEA访问层对提供多渠道支持门户安全管理在北京市应急指挥系统系统中涉及众多被集成应用系统和规模庞大数据信息。BEA提供应用技术架构能通过统一安全架构，将所有已有顾客管理、权限控制等安全功能集成到记录架构中，因而能有效实现北京市应急指挥系统平台统一安全管理和维护。BEA安全架构中提供了顾客身份认证、权限管理，安全审计、角色管理、统一顾客档案管理等丰富安全性功能。更为重要是所有安全功能模块，都是基于开发式架构实现，既它提供了即插即用实现方式。容许无缝插入顾客定制或第三方安全性解决方案，提供了安全性服务扩展功能。身份认证身份认证授权审计

Module(s)角色MappingModule(s)身份映射顾客档案安全性框架重要管理员认证人员审计人员角色定义证书人员顾客图：BEA提供开放可插拔式安全架构可插式安全性框架——支持与第三方安全性解决方案集成，容许充分运用市场上“最佳”安全性解决方案所提供所有功能。此外也能将顾客定制化安全实现集成到统一安全架构中。身份验证——借助顾客名与口令组合或数字证书，拟定顾客身份。所谓顾客是指个人、自动进程或其她应用，同步回绝有害入侵者访问。授权——规定应当提供应每个通过身份验证顾客应用功能、服务和数据资源。加密——保证客户端和服务器端之间数据能在保密状况下进行通信和网络数据传播。审计——提供记录所有与安全性有关活动功能，例如顾客登录、资源访问规定。顾客和顾客组定义——提供定义应用顾客或组合授权顾客所需功能，在顾客组内，所有成员都共享相似权限来访问各种应用功能和服务，这样可以统一、以便地管理不同顾客。安全数据存储——保存角色、简档和权限数据。BEAWeblogicServer内置有符合LDAPV3原则高度优化LDAP目录服务。由于拥有完全开放安全架构，因而还可以集成第三方LDAP服务器，当前系统支持目录服务器有：NovellNDSOpenLDAPSuniPlanetMicrosoftActiveDirectory其她所有和LDAPV3原则兼容目录服务器安全性方略定义——提供配备和维护基于规则、动态安全性访问原则框架和GUI工具，以便让特定角色与/或顾客组可以安全地访问资源。权限规则基本可以是一系列可扩展操作和参数，例如时间、身份、顾客简档和调用参数值，它们可以在运营时动态计算和确认。SecureSocketsLayer——还可采用SecureSocketsLayer（SSL）、数字签名以及其他基于原则安全办法。当这些安全办法共同使用时，它们可追踪谁访问了哪种服务。Web服务安全——安全框架为内置Web服务基本构造提供高度安全性，让客户可以创立安全分布式应。Web服务安全保护普通是通过：控制顾客访问权限、通过SSL对Web服务进行数字签名，保护Web服务调用、加密Web服务传播内容这三种方式实现。运用BEA提供统一安全架构，北京市应急指挥系统可以管理各种应用和系统资源安全属性，涉及：应用程序资源 COM资源 J2CA资源EJB资源 JDBC资源JMS资源JNDI资源服务器资源URL资源Web服务资源统一顾客档案除了基于构成员资格授权和个性化外，BEAWebLogicPortal也能依照顾客档案值动态个性化。动态设立对门户资源访问允许。顾客档案存储各种与顾客有关信息，如地址、联系方式以及应用指定属性。BEAWebLogicPortal缺省将顾客档案基于RDBMS存储。在诸多状况下，顾客档案需要与各种外部数据仓库涉及定制顾客数据库、LDAP联合使用。统一顾客档案为在不同资源之间实现单一客户档案视图提供了基本构造。统一顾客档案采用无状态会话EJB实现，该EJB是各种负责存取各自顾客数据无状态会话EJB联合接口。从门户方面看，统一顾客档案属性可以通过管理工具以及API或JSP标记库编程访问。为了将已有系统顾客档案映射到统一顾客档案，开发人员需要实现访问资源系统、存取指定特性接口，并在WebLogicPortal注册。统一顾客档案在从各种资源映射属性时具备很强伸缩性。如一完整顾客档案也许由存于LDAP属性子集、存于缺省RDBMS顾客属性子集、存于定制数据库子集三某些构成。BEAWebLogicPortal区别了为认证身份对顾客信息目录进行访问与对顾客档案属性进行存取。前面已经讲过，认证是通过WebLogicServer安全域进行，而顾客档案属性是经由统一顾客档案存取。这样就可以采用各种LDAP存储，一种用于认证，另一种用于顾客档案数据。BEAWebLogicPortal会自动地为安全域内没有档案记录顾客创立新顾客档案记录。这个功能在顾客安全信息不是由WebLogicPortal创立和维护状况下特别有用，如，处在LDAP或第三方安全产品环境下。BEAWebLogicPortal实用程序可以同步存储在顾客档案和安全域内顾客记录。单点登录这些第三方解决方案涉及身份验证解决方案、Web访问管理解决方案、审计解决方案，等等。Web层单点登录在Web层，浏览器使用者被提示进行应用程序验证（声明她们身份）。这个身份被传到应用服务器上以用于验证顾客。成功登录成果是生成一种cookie，它作用范畴是应用服务器驻留DNS域。然后cookie返回到给向应用程序服务器发送祈求浏览器。默认状况下，当顾客退出应用程序或关闭浏览器时，cookie生命周期结束。除了J2EE指定机制外，通过它安全基本构造和关联安全服务提供者，BEAWebLogicServer通过配备可以支持使用身份验证。如果想把基本顾客名/密码这种身份验证办法改为更强身份验证办法，例如标记(token)，只需要简朴地为新身份验证办法实现安全服务提供者(SecurityServiceProvider)。系统布置和管理北京市应急指挥系统应用架构除了需要有功能强大异构系统集成能力和灵活服务管理能力外，面对业务发展压力，还必要需要拥有卓越运营和管理能力，来保证整个应用架构能提供稳定可靠平台。北京市应急指挥系统服务器布置建议如下图所示，其中软件应用访问控制访问器功能在Portal中已经实现，因此没有单独画出。北京市应急指挥系统布置图高性能在完整北京市应急指挥系统SOA应用技术架构中，服务层和集成层需要承担着大量代理人和浏览器顾客并发访问。那么架构运运营性能和系统可靠性是保证北京市应急指挥系统应用服务水平（SLA）有力保证。BEA平台支持无限可扩展性。随着顾客业务量增长，系统可以通过集群和负载均衡方式动态添加服务器。并通过涉及动态负载分担、多路复用技术、线程池、对象池、连接池、群集负载分担等先进技术，虽然在峰值巨大压力下，保证顾客业务系统7×24×365实时在线，并提供满意响应速度。高性能在BEASOA技术架构中，对于不同层次，提供了一系列提高和优化系统性能技术手段。图：BEA核心架构保证高性能集群和可靠性BEA提供先进集群技术，可以使北京市应急指挥系统SOA架构具备良好伸缩能力和24x7系统可用性。集群技术指通过各种办法组合服务器，实现核心业务系统负载分布，消除个别故障点。集群采用备份配备，通过对象集群技术，使复制服务器或对象实例可以进行自动故障接替，保持有状态对象状态。发生硬件或软件故障时，客户机访问透明地切换到运营中服务器或对象副本。集群是面向客户机独立“超级”服务器，用一种URL编址。在集群内部，服务器之间通过IP多播进行通信，运用DNS负载平衡、硬件负载平衡器或代理服务器支持访问模型。BEA集群是业内最先进技术，可为顾客核心业务Web应用提供最强大伸缩能力和可用性。与单个服务器相比，集群具备两大长处：伸缩能力——与单服务器或单机相比，集群容量不受限制。为了提高容量，可在集群中动态地添加新服务器。如果需要增长硬件，可在新机器中加装服务器。当单个服务器局限性以充分运用既有设备时，也可以在机器中增长服务器。高可用性——集群采用多服务器备份来避免客户机硬件或软件故障。同样服务可以由集群中各种服务器来提供。当其中一种服务器发生故障时，另一种服务器可以接替发生故障服务器继续工作。这种故障服务器故障接替能力可保证客户机应用无缝可用性，客户机主线察觉不到曾经发生过问题。BEA应用技术架构通过集群和可靠Web服务（WS-Reliable）等特性保证了平台级别和服务级别可靠运营。将北京市应急指挥系统应用架构构建在集群构造上，通过BEA提供故障转移功能，系统意外宕机不会导致服务平台停止业务解决，BEA集群支持。可靠Web服务能可以保证服务调用可靠被执行。它可以自动将系统解决但是来大规模并发解决祈求暂时保存到存储机制中，待到系统资源充分时候再调用。这样就可以有效地应对瞬时大并发顾客祈求了。系统监控，保证SLA通过BEA提供应用技术架构，不但可以保证北京市应急指挥系统拥有灵活、可扩展开放业务架构，还能最大