市应急指挥系统BEA技术建议策划方案

北京市应急指挥系统BEA技术建议V1.0BEA系统（中国）有限公司2006-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功能专门好的支持政府部门的工作流。下图是申请工作流的示意图。要实现面向服务的核心系统，仅有底层的组件服务的剥离是远远不够的，各种原子服务、分子服务最终应成为应用实现层面上的逻辑，而业务的组装、修改、运行则应与应用实现分离而通过流程治理器来实现。通过可视化界面，对各原子或分子服务进行组装形成新业务。因此，工作流治理器就成为业务支撑系统的核心，将业务系统构造在基于标准的工作流基础上，实现业务逻辑和应用逻辑的剥离，使得业务治理人员能够自行定义和治理数据业务的流程。下图是WebLogicIntegration的BMP的开发视图：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实时在线，并提供中意的响应速度。高性能在BEA的SOA技术架构中，关于不同层次，提供了一系列提高和优化系统性能的技术手段。图：BEA核心架构保证高性能集群和可靠性BEA提供先进集群技术，能够使北京市应急指挥系统SOA架构具备良好的伸缩能力和24x7的系统可用性。集群技术指通过多种方法组合服务器，实现关键业务系统的负载分布，消除个不故障点。集群采纳备份配置，通过对象集群技术，使复制服务器或对象实例能够进行自动故障接替，保持有状态对象的状态。发生硬件或软件故障时，客户机访问透明地切换到运行中的服务器或对象副本。集群是面向客户机的独立“超级”服务器，用一个URL编址。在集群内部，服务器之间通过IP多播进行通信，利用DNS负载平衡、硬件负载平衡器或代理服务器支持访问模型。BEA集群是业内最先进的技术，可为用户关键业务Web应用提供最强大的伸缩能力和可用性。与单个服务器相比，集群具有两大优点：伸缩能力——与单服务器或单机相比，集群的容量不受限制。为了提高容量，可在集群中动态地添加新的服务器。假如需要增加硬件，可在新机器中加装服务器。当单个服务器不足以充分利用现有设备时，也能够在机器中增加服务器。高可用性——集群采纳多服务器备份来幸免客户机的硬件或软件故障。同样的服务能够由集群中的多个服务器来提供。当其中一个服务器发生故障时，另一个服务器能够接替发生故障的服务器接着工作。这种故障服务器的故障接替能力可确保客户机应用的无缝可用性，客户机全然察觉不到曾经发生过问题。BEA应用技术架构通过集群和可靠Web服务（WS-Reliable）等特性保证了平台级不和服务级不的可靠运行。将北京市应急指挥系统应用架构构建在集群结构上，通过BEA提供的故障转移功能，系统的意外宕机可不能造成的服务平台停止业务处理，