北京市应急指挥系统方案.doc

北京市应急指挥系统
BEA技术建议

V1.0

BEA系统（中国）有限公司
2023-01

目录

1 项目总体规定 3
2 信息平台技术规定 4
用户需求的服务媒介： 4
互联网 4
呼喊中心 4
3 北京市应急指挥系统BEA技术方案 5
3.1 北京市应急指挥系统SOA架构总体设计 5
3.2 应用支撑平台与集成环境 6
3.3 信息资源共享环境 7
3.3.1 数据服务平台 7
3.4 工作流平台 15
3.5 门户系统方案 17
3.5.1 内容管理 17
3.5.2 搜索功能 18
3.5.3 多渠道访问 19
3.5.4 门户安全管理 20
3.5.5 统一用户档案 22
3.5.6 单点登录 23
3.6 系统部署和管理 24
3.6.1 高性能 24
3.6.2 集群和可靠性 25
3.6.3 系统监控，保证SLA 26
3.7 BEA实现的SOA架构优势 27
3.7.1 全面、统一的平台 27
3.7.2 基于标准的开放平台 27
3.7.3 简朴、高效率实行 29
4 成功案例 30

1 项目总体规定
项目规定见项目需求书，此处略。

2 信息平台技术规定
用户需求的服务媒介：

互联网
用户需要通过互联网满足对信息的浏览、查询、决策、指挥、邮件服务、即时通讯等的需求。

无线网络
用户需要通过无线服务，满足随时随地浏览信息、查询信息、视频会议等的需求。

呼喊中心
用户需要通过人工和语音的呼喊服务满足信息服务，情况报告等语音服务需求。

3 北京市应急指挥系统BEA技术方案
3.1 北京市应急指挥系统SOA架构总体设计
根据项目的需求，该项目的应用可以分为几个层面：
1. 底层的数据层——通过数据库系统存储共享的业务数据，共享数据从各自业务数据库中提取，数据源之间进行复制和互换；
2. 应用支撑层——通过应用服务器支持程序组件的建立和运营；
3. 数据服务层——针对不同的应用，应用对数据的访问需要一个数据服务层，通过数据服务层，应用可以做到透明访问异构的和分布的数据库和文献系统，应用逻辑和数据源之间是松耦合的，通过中间的数据服务层提供跨数据库的关联和映射；
4. 服务总线层——通过服务总线，连接各类可重用服务模块，完毕消息传递，数据转换，服务路由等功能；
5. 工作流层——穿接应用模块，按照工作流程构建业务流程，支撑部门内部和跨部门的流程建模，执行和管理，并结合门户系统构建流程门户，构建SOA构架应用，工作流平台是必须的；
6. 门户展现层——可以针对不同类型的用户提供灵活的访问形式，根据不同用户类型提供个性化服务。

北京市应急指挥系统，其逻辑结构可以按照上述六层来构建。其好处在于，从纵向结构上看，应用品有松耦合架构。具体的介绍如下：
1. 在数据层——数据库或文献系统可以进行数据互换；
2. 应用支撑层——通过开发基于J2EE的应用程序组件实现应用模块功能，组件可以封装为服务，组件的构建，运营和管理由本层支撑，应用支持层通过WebLogic Server实现；
3. 在数据服务层——数据的访问基于统一的入口，被访问数据则可以分布在外部相关单位的共享数据库和北京市应急指挥系统的数据库中，通过数据服务层进行跨数据库的关联，数据服务层的访问可以通过Java接口或Web服务实现，数据访问层通过AquaLogic Data Service Platform产品实现；
4. 服务总线层——业务应用通过组件方式构建，组件可以方便的封装成Web服务，在系统之间被互相调用，服务总线层通过AquaLogic Service Bus实现；
5. 在工作流层——工作流层支撑流程建模，执行和管理，灵活的流程管理工具使生成和改变工作流程变得简朴；
6. 在门户展现层——通过门户技术，北京市应急指挥系统门户中建立的各类应用展现portlet，信息内容的展现个性化。

北京市应急指挥系统基于SOA的统一技术架构

要实现上述的系统层次和功能，需要SOA的构架设计和相应的BEA产品支持，做到开放、灵活和灵敏。
下面分层介绍BEA的方案和产品技术特点。
3.2 应用支撑平台
应用支撑平台是通过BEA WebLogic Server应用服务器实现。具体的技术指标参照附件《北京市应急指挥系统BEA方案-V1-应用服务器技术指标.doc》。
3.3 数据服务平台
BEA 可以提供的解决方案涉及数据访问平台通过AquaLogic Data Service Platform实现。
数据服务层在北京市应急指挥系统中起着数据访问服务的作用，可以在跨系统在分布式数据访问中屏蔽数据源，形成基于XML的统一访问接口，数据结构，数据关联，数据目录定义和数据访问控制通过数据服务平台完毕。由于在数据库和应用之间加入了数据服务层，数据库表的修改不会影响应用代码，对此后系统的升级和改造提供灵活的结构。
数据服务通过BEA AquaLogic Data Service Platform来实现。提供一种标准途径来快速地聚合并展现来自多种异构数据源的数据视图(涉及 Web services, 数据库, 文献、XML文献、应用及Web站点等) 。这种数据视图可以通过Java API，RMI，Web Services等方法被应用，业务流程，门户应用所直接调用。下图是AquaLogic Data Service Platform的逻辑结构。

（1）什么是数据服务层？
从架构的观点看，数据服务层是位于底层数据源集合之上的数据抽象层。从SOA的原理分析，数据服务层的作用是为所有读写操作提供一个访问点，并对“使用者”应用隐藏底层数据的物理结构和访问机制。为此，数据服务层提供了一个独立于底层数据源的接口，它公开用来读写数据的可重用数据服务的标准集合。下图描述了数据服务层在架构中的角色。

数据服务层的一个重要优势在于，它遵循了一个重要的SOA原理——“松耦合”——将使用数据服务的应用与底层数据源提供者的依赖性降至最低。这样，应用将看不到数据源使用的底层物理结构及相关访问机制。

“松耦合”允许数据库架构师在不更改层的接口或“使用者”应用的情况下，从数据服务层修改、组合、移动甚至删除底层数据源。这样，数据库架构师既能为需要的应用提供信息，又能控制数据结构。随着时间的推移，这种提高的灵活性将简化公司应用的维护，并使公司更灵活、更灵敏地适应业务IT需求的变化。

数据服务层的第二个优势在于：它提供了“单个”数据访问位置。很多公司都试图解决“数据真实性”问题，例如，名为“收入”的字段既也许指bookings数据库的预订收入，也也许指sales数据库的销售收入，在这里，“收入”项的真实含义取决于它的来源上下文，也取决于使用它的上下文。

典型的数据服务层是访问广泛公司数据源的统一访问点

机构之所以会碰到“数据真实性”问题，其中的一个因素是公司中存在大量数据源。此外，这些数据源分散在不同应用中，使用情况又不尽相同，因而导致混淆。当用户试图理解一个数据段的真实含义时，经常会碰到以下四个问题。

² 对于将使用的上下文而言，数据也许来自底层数据源的一个错误位置
² 字段名不清楚，数据也许是错误信息
² 数据也许过时（例如，由于数据仓库更新间隔）
² 在读取或上次更新时，也许将一些不对的和（或）不完整的数据转换应用到数据上

数据服务层解决了上述所有问题，它是公司中的单个数据访问点，使公司可以找到数据的“单个真实来源”。

在实行数据服务层后，可保证从对的数据源获得数据，并将适当信息连贯地返给所有应用。此外，可在数据服务层对字段实行标准化，保证数据的描述清楚可辨，并将使用对的的数据源。数据服务层可保证返回的数据是最新的，来自适当数据源，并且是实时获取的。最后，所有数据转换都被用于数据服务层，以保证整个公司应用和执行的连贯性。

总之，通过使用数据服务层，机构可获得以下几个明显的好处：

² 应用与访问数据的复杂性隔离，故应用更易于创建。
² 更改数据源的影响范围一般只限于数据服务层，故应用更易于维护。
² 应用使用共享的数据服务、验证逻辑及服务封装的其他数据规则，故能获得更一致的数据。

总之，使用BEA AquaLogic Data Services Platform的公司的灵敏性和反映速度更快，可以适应不断变化的市场规定。

（2）构建数据服务层的传统方法
传统上，开发人员在构建数据服务层时，会使用人工编码方式，并将代码嵌入在建应用中。这种方法难以共享和重用数据服务。为此，公司开始寻找ETL（extract, transform, and load，提取、转换和加载）产品来构建服务层。

ETL起初用来为业务报表应用创建数据仓库。在用ETL技术构建数据服务层时，将关联和复制多个来源的数据，将它们整合到一个数据仓库、数据中心或操作数据库，并将结果库作为数据服务层的数据源。对于“只读”或“查询密集”的小型公司应用集而言，这种方法非常有效，能支持周期性数据刷新（如分析或数据挖掘应用）。“添加新数据源”等更改一般需要重新设计，并重新加载中心数据库，故ETL方法最适于静态应用（此类应用的需求很少更改）使用。过去的经验证明，这种方法合用于业务报表应用，这些应用执行记录分析、复杂数据汇聚或时间系列趋势计算，能从长期数据解决（如整夜）中获益。

公司逐渐发现，ETL方法需要IT部门建立和管理ETL系统，并经常大规模移动数据，成本高昂。研究显示，由于迁移数据会带来初期和长期的硬件和磁盘空间成本，用于开发、支持、升级和监控ETL项目和工作的成本也许相称可观。

（3）BEA AquaLogic Data Services Platform构建数据服务层的方法
The BEA AquaLogic Data Services Platform 从底层设计开始简化为SOA实行开发数据服务的任务。该平台基于具有声明性服务定义的元数据驱动方法，不需要人工创建工作流或代码，能自动完毕许多数据服务创建和维护的工作。此外，声明性的方法能自动优化数据访问规划，减轻后台系统承担，提高系统综合性能。

BEA AquaLogic Data Services Platform中的声明性编程：BEA AquaLogic Data Services Platform在数据服务的声明性定义中使用XQuery语言。声明性编程使数据服务架构师可以定义需要的服务及基础数据和服务；然后由BEA AquaLogic Data Services Platform来决定提供所需服务的最佳算法。该平台可以选择合适的数据源访问顺序、编排底层服务调用，在碰到RDBMS数据源时，还能产生一组合适的SQL查询语句。它支持各种算法，可以创建高效SQL，将尽量多的查询解决委托给底层RDBMS数据源，只检索后解决形式的数据；为及时访问Web服务等高延迟资源，它还支持并行的、基于超时的故障转移工具。因此，BEA AquaLogic Data Services Platform提供对底层数据的自动访问、转换与关联以及底层数据访问优化。

适应应用需求的服务：对于任意服务调用，应用也许需要许多数据子集和各种不同的结果。比如，对于一个返回客户数据的服务，应用也许需要查询按客户标记排序的数据（排序）、邮政编码为某特定数字的客户（筛选）、只要客户的姓（映射）或客户数量（合计）。传统上，上述操作都必须是独立的服务调用，这些调用有互相反复的数据转换和确认逻辑。通常，以一个通用的getCustomer（）服务调用获得上述所有数据是无法接受的，由于那会将太多的数据带到中间层，产生性能问题。

BEA AquaLogic Data Services Platform的声明性方法使数据服务架构师能定义一个getCustomer( )服务调用，而不会产生性能问题。开发人员可以使用应用特有的过滤、排序、映射或合计等功能，BEA AquaLogic Data Services Platform动态地创建针对各种不同情况而优化的查询和更新规划。这消除了针对不同应用需求不断改变数据服务层的需要，提高了数据一致性。

服务上的服务（视图演化）：如下图所示，声明性方法使数据服务架构师能运用现有服务定义新服务，而不必紧张性能下降。BEA AquaLogic Data Services Platform引擎可以优化掉服务调用的中间层，为服务调用产生效率更高的数据访问规划。

与此相反，基于工作流（或人工编码）的方法在服务调用其他服务时，性能会严重下降。各个服务按照编码执行，而不考虑高层服务需要的也许只是一小部分数据；并且每种服务都有自己的界线，要跨越界线需要进行多次数据复制和转换。因此，数据服务架构师经常不得不为所需的各个数据服务分别编写工作流。

一次集成与重用：如下图所示，声明性方法使数据服务架构师可以创建、共享、专用和重用数据服务。实例涉及了提供单一“客户”视图的数据服务，或者提供重要业务实体的数据服务。在数据服务层，数据服务架构师经常创建许多类似的服务调用：

Ÿ getCustomerByID(custID)
Ÿ getCustomersByRating(rating)
Ÿ getTopCustomers( )

假如客户数据是从多个数据源获取的，则执行这些数据服务的最有效的办法似乎是使用多个SQL查询和服务调用。使用BEA AquaLogic Data Services Platform，数据服务架构师可以创建一个通用的数据集成服务，比如getCustomerProfile( )。在这个重要的“单一客户视图”上，可以方便快捷地定义多个专用服务。由于这些服务可以运用在底层服务中已经预先完毕的集成工作，所以定义这些高层服务非常容易。此外，BEA AquaLogic Data Services Platform的声明性方法使其可以优化掉中间层，为在其上构建的服务产生更高效的访问途径。与此相反，用工作流或人工编码来解决此问题，需要为每个服务分别编写程序。

BEA AquaLogic Data Services Platform的声明性方法，支持视图演化，消除了服务调用其他服务时产生的性能瓶颈。

采用BEA AquaLogic Data Services Platform，通过重用现有服务，定义新服务变得极为简朴。并且由于与数据有关的规则在一个地方定义和使用后，可以一致地被所有相关的数据服务使用，因此该特性有助于提高数据的一致性。此外，由于改变只需在一个地方进行，使得对于这些规则的维护十分轻松，提高了一致性。

BEA AquaLogic Data Services Platform采用独特的声明性方法来定义数据服务，支持数据访问逻辑的自动化，提供“一次定义，多次重用”的体验，极大地简化了数据服务的开发和平常维护。

（4）定义数据服务
BEA AquaLogic Data Services Platform提供了丰富的建模环境，能根据业务实体和它们之间的关系组织数据服务。使用这一环境，数据服务架构师能在单一地点了解数据服务模式、服务操作和数据服务管理策略。良好的数据服务模型为应用开发人员提供了使用数据服务的指南，并让他们更有效地维护和重用数据服务。

BEA AquaLogic Data Services Platform采用如图的“分段图（chip diagram）”，以图形化方式描述每个数据服务的功能。分段图以简洁的格式概括一个数据服务的信息，使数据服务架构师可以看到该服务及相关人工制品。图3演示了该数据服务的几个方面的信息：

² 数据服务的读功能
² 与之相关的数据形状，一种XML Schema
² 提供对相关数据服务访问的导航功能
² 一组用来定义它的低档数据服务
BEA AquaLogic Data Services Platform还支持数据模型图的创建和维护，该图以图形化方式记录和共享一个数据服务层的部分信息。与E-R或UML图表非常类似，每个数据模型图表都显示一组数据服务和它们之间的互相关系。

BEA AquaLogic Data Services Platform中的数据服务，按照实际业务实体建模

（5）数据转换
通过数据服务平台提供的数据转换功能，在不同格式的数据之间互相转换，将数据格式转化为对方能辨认的格式。这样就使得具有不同数据格式的服务能具有更广泛的兼容性。
数据转换是指数据从一种格式向另一种格式的映射和转换。例如，非 XML 格式的数据可以转换为 XML 格式，反之，XML 格式的数据也可以转换为非 XML 格式。BEA的数据服务平台提供了基于XQuery技术的可视化的数据转换功能，能通过拖拽的手段快速实现不同格式之间的数据转换, 还可以对下列任意输入输出数据类型进行数据转换：XML 数据、非 XML 数据、Java 原子类型、Java 类。在这个过程中，不仅可以实现数据格式上的变化，还能使用XQuery的函数，对数据内容自身做各种运算。此外，通过BEA服务平台实现的数据转换功能自身也可以被其他模块复用。

可视化数据转换功能

3.4 服务总线平台
不同系统之间和指挥决策系统同北京市各级政府的相关系统之间的系统调用和信息互换，建议使用Web服务方法。为了建立开放的服务调用管理框架，建议使用BEA AquaLogic Service Bus服务总线产品。

BEA提供了服务平台，提供了服务管理、服务路由、服务编排、数据转换和消息代理等功能。在BEA提供的服务平台中，“服务”代表了业务功能上可被复用的应用模块。它不仅仅可以是Web服务（WebServices），还可以是使用其他任何开放手段可访问到的应用资源，这些开放技术涉及Tuxedo、CORBA、消息机制、适配器、DCOM等。这种服务的多样性充足扩展了开放平台的资源管理范围，无论是采用Java、C、C++开发的应用系统，还是使用CORBA、Web服务、消息机制实现的异构系统，这些资源都可以做为可复用的业务资产，通过开放的系统架构实现灵活的互联互通。
3.4.1.1 服务管理
一方面通过集成功能，将客户系统中所包含的使用不同实现技术、运营在不同平台的应用接入到应用架构中。在完毕集成单独应用后，这些应用模块就成为在开放架构中可以被复用的业务模块了。为了进一步增长应用和数据的灵活性，来适应业务发展的需要，可以将这些接入的应用和数据资源交给核心层的服务平台进行管理。

图：BEA服务平台的服务资源管理
BEA提供的服务平台可以集中管理集成层接入的各种应用服务，它可以从注册到其中的服务自身描述（WSDL）中得到服务的特性，然后对众多基于服务的应用资源进行集中管理。通过集中、有效的管理可复用的应用服务，可以清楚的了解在信息平台应用架构中有哪些应用和数据资源；这些资源是由什么应用或数据源提供服务的；它们后台实现实分布在哪些系统内部；它们都可以提供什么可重用业务功能；如何才干访问它们等信息；它们提供什么安全保护，从而真正实现了应用服务资产管理。
3.4.1.2 服务路由
使用服务的路由功能，可认为信息平台实现更加非常灵活的业务调用过程。
在BEA提供的服务平台中，可以实现基于业务规则的服务路由功能。一方面服务使用方通过服务平台访问某个服务的入口，当服务平台接受到用户请求后，假如在服务调用过程配置了访问路由，那么平台会使用路由配置表进行基于业务规则的匹配，然后根据不同的匹配结果，将用户对服务的请求路由到后台不同的业务提供者。

图：BEA服务平台的服务路由配置功能
BEA实现的基于应用信息的服务路由功能可以通过可视化的路由配置界面实现，这样可以在应用系统在运营的时候，更加灵活、方便的适应业务动态变化的需要。可用用来做为判断路由准则的数据可以涉及：传递进来的业务信息，与用户相关的环境信息（application context），通过接口可以访问到的外部信息等内容。服务的路由规则可以通过服务平台的可视化编排界面实现既可。假如路由规则比较复杂，建议使用规则服务提供更加灵活的实现。
服务在路由过程中，可以结合核心层的负载均衡，并能动态判断后台服务系统的连通情况，实现智能路由的功能。用户的请求可以通过负载均衡转到负载较小的服务器上，这样可以对外提供更好的QoS保障。
3.4.1.3 服务编排
服务路由功能实际是服务编排其中一部分。BEA的服务平台能提供更多强大的服务编排功能。其中除了服务路由提供了较为重要的功能外，其他重要功能还涉及：

图：BEA服务平台中丰富、灵活的服务编排功能
1. Skip（跳转）——跳转到服务编排中的指定的解决节点位置上。
2. Reply（回应）——终结服务编排调用，向调用者返回服务编排结果。
3. If Then（判断）——服务流程判断结构。
4. Publish Table（分支）——服务流程的分支结构。
5. Web Service Callout（Web服务外调）——调用指定的Web服务。
6. Validate（校验）——使用XML，校验数据格式或数据内容。
7. Insert（添加）——添加新的环境变量内容。
8. Replace（替换）——替换环境变量的内容。
9. Delete（删除）——删除环境变量的内容。
10. Rename（更改名称）——更改环境变量的名称。
11. Raise Error（错误解决）——定义错误解决方式。
12. Log（日记）——定义记录日记记录信息。

图：图形化的服务编排功能

通过上面这些灵活的服务编排功能和可视化的编排实现，BEA的服务平台可以实现非常灵活地组合可被重用的业务服务来适应不断变化的业务需求。
3.5 工作流平台
指挥决策的业务过程中，会有一系列的工作流过程，为了构建灵活的业务应用，需要工作流工具支持。BEA WebLogic Integration中BPM功能很好的支持政府部门的工作流。下图是申请工作流的示意图。

要实现面向服务的核心系统，仅有底层的组件服务的剥离是远远不够的，各种原子服务、分子服务最终应成为应用实现层面上的逻辑，而业务的组装、修改、运营则应与应用实现分离而通过流程管理器来实现。通过可视化界面，对各原子或分子服务进行组装形成新业务。
因此，工作流管理器就成为业务支撑系统的核心，将业务系统构造在基于标准的工作流基础上，实现业务逻辑和应用逻辑的剥离，使得业务管理人员可以自行定义和管理数据业务的流程。
下图是WebLogic Integration的BMP的开发视图：

WebLogic Integration的业务流程管理工具BPM基于标准BPEL。业务流程执行语言（BPEL）允许指定业务流程以及它们和 Web 服务的关系。其中指定了业务流程是如何使用 Web 服务来达成它的目的，还指定了由业务流程提供的 Web 服务。用 BPEL 指定的业务流程是完全可执行的，且在符合 BPEL 的环境间是可移植的。无论实现 BPEL 业务流程的伙伴的 Web 服务是否基于 BPEL，BPEL 业务流程都能和这些 Web 服务互操作。最后，BPEL 支持单位之间的业务协议规范和复杂内部业务流程的视图。
3.5.1 工作流实现功能
3.5.1.1 内外部之间指挥决策业务流转实现
对于指挥决策系统中复杂的指挥决策流程，BEA Weblogic Integration支持各种跨不同地区的部门、跨不同平台的流程。

中心平台
业务流程引擎
工作列表
流程管理
外部平台
业务流程引擎
工作列表
审
批
调
用
接
口
审
批
调
用
接
口
发起流程

图：跨不同指挥决策平台的指挥决策流程实现
如上图所示，发起指挥决策流程是运营在指挥决策平台上的。当指挥决策业务需要外部平台审批的时候，业务流程引擎可以调度审批流程。所有和指挥决策相关的材料也通过调用接口传到外部平台。假如外部平台完毕审批，系统还可以把结果返回给指挥决策平台。
使用BEA Weblogic Integration，可以有多种方法实现调用分布的服务接口。
1. 基于J2EE的消息机制的接口
调用流程将所有必要的信息通过JMS发送到BEA Weblogic Integration的消息代理中。而被调用通过监听订阅消息通道中特定的消息，当有发给它自己的指挥决策调用时候，异地指挥决策平台启动指挥决策流程。
2. Web服务
通过Web服务技术将业务流程封装，Web服务会将指挥决策流程的启动功能放在接口中。调用流程通过调用部署在异地的Web服务来启动一个远程的指挥决策流程。

3.5.1.2 工作流平台的实现核心
BEA Welogic Integration的业务流成管理功能（BPM）为指挥决策系统的服务功能提供了一个易用、可靠、开放、可管理的平台，是指挥决策功能实现的核心。它的重要特点是：
· 以集成框架为基础，完全包含集成平台中的基于接口的功能
· 系统间的信息将不仅仅是用于共享，这些信息将被有效的管理起来
· 集成平台要包含工作流管理器的功能和工具
· 集成平台中扩展的重要功能涉及：工作流定义、信息的自动路游，自动判断。
BEA Welogic Integration的业务流程管理功能重要涉及了：
1. 可视化流程定义工具
BEA Weblogic Inegration通过可视化的集成开发工具BEA Weblogic Workshop来定义流程业务。业务流程引擎保存了可视化创建业务流程的能力，因而具有灵活性，使用户得以集中精力专注于应用逻辑，而不必关心实行细节。事实上，用户构建的是业务流程的图形化表达。

图：可视化业务流程定义
在运用 BEA WebLogic Workshop 中的图形化工具(设计视图)设计业务流程的过程中， BEA WebLogic Workshop 用定义业务流程的 XML，为 JPD (Java 流程定义)文献作注释。当需要编写 Java 代码时，单击访问（源代码视图）就可使用它。BEA WebLogic Integration 的业务流程管理功能，使公司开发人员具有了开发、运营、维护复杂业务流程的能力。业务流程将公司现有系统、整个公司的各种应用以及决策人员集成在一起。
2. 业务流程引擎
业务流程引擎是指挥决策系统指挥决策平台的关键实现核心，它将业务系统构造在基于标准的工作流基础上，实现业务逻辑和应用逻辑的剥离，使得管理人员可以自行定义和管理数据业务的流程，实现业务管理的闭环结构。
业务流程引擎能解释、运营定义的流程。一方面流程引擎会创建指挥决策流程实例，每个流程实例是一个独立的指挥决策业务。可以通过多种方式启动一个指挥决策流程：用户积极调用，时间定期运营，接受到订阅消息道的指定消息。一旦指挥决策流程开始，流程引擎会调度、监控各项流程中的活动，比如指挥决策业务需要自动获得农产品的记录数据，流程引擎就会自动通过应用程序接口调用计算记录模块，并把所得结果返回工作流中。当指挥决策流程需要人为参与指挥决策的时候，系统会按照定义，为目的指挥决策用户建立“指挥决策任务”，与此同时流程引擎实时监控用户的任务列表执行情况，一旦用户解决完指定给他的任务后，流程会自动往下执行。

图：BEA Weblogic Integration业务流程实现机制
BEA Weblogic Integration提供的业务流程引擎是基于开发标准BPEL（流程执行语言Business Process Execution Language）基础上的。BPEL是一种流程定义语言，用于指定包含Web服务的业务流程。BPEL合用于支持业务流程逻辑的"宏观定义"。这些业务流程均是完整而独立的应用，它们将Web服务作为实现其业务功能的"活动"。
在BEA Weblogic Integration定义的的业务流程中可以调用各种各样的系统资源。涉及通过JDBC读写数据库，通过J2CA应用适配器来调用系统遗留应用，通过Web服务接口调用部署在异地的应用，通过JMS触发消息机制。通过EJB接口调用应用逻辑。
BEA WebLogic Integration使用J2EE兼容型技术，涉及Java基础、JSP和EJB互操作性、用于流程元素间数据传送的XML以及用于业务流程组件间消息传送的JMS。这些开放标准意味着在IT人员的技能合用于不同的项目，并且IT人员可以协同完毕同一项目的不同部分。因此，使用标准技术（XML）和开放编程API意味着解决方案可以扩展，为未来发展留有余地。
3. 业务流程工作列表
BEA Weblogic Integation 提供了业务流程工作列表（Worklist）功能。它表反映出每个参与指挥决策人员当前和哪些指挥决策工作相关，例如待办指挥决策事务，未办指挥决策事务，相关指挥决策事务，跟踪任务状态等。它使人们能在业务流程内协作，完整的工作流涉及各种操作，例如接受、批准、修改和路由文档
业务人员通过访问自己的工作列表可以知道和自己岗位相关的工作内容，并迅速解决。BEA Weblogic Integation 的工作列表还允许业务员人员将分派给他的指挥决策任务做其他操作，例如：拒绝接受，转分派给其他业务人员等。
4. 业务流程监控与管理
业务流程是随着外部用户的更高规定、内部部门的职能变化等因素不断发上变化的，这就需要业务流程能灵活的适应这种变化，从而为广大的用户提供不断完善业务功能。
BEA Weblogic Integation的业务流程管理功能提供了强大的业务流程监控，记录，管理功能。通过这些具体的监控手段，业务管理人员可以全面的掌握流程的运营情况，分析流程流程安排的合理性，为优化各种业务流程提供了具体的数据依据。
流程监控功能能为监控每个运营在流程引擎中的业务流程实例的各种信息，涉及流程的实例的启动者、开始时间，完毕时间，总共运营时间，运营节点位置，当前流程运营状态。已经指挥决策完的每个节点的信息涉及：开始时间、指挥决策历时、结束时间、指挥决策人等。并且这些信息都是通过下面的可视化的管理界面来实现的。

图：业务流程管理监控可视化界面

3.6 Portal技术概念
Portal一词本来是"门户网站"的意思，例如雅虎、新浪等这样的网站。但是对于政府和公司公司信息化平台建设而言，Portal所扮演的角色则有所不同。
本来业界对Portal的定义有很多种分类，比如把Portal定义为信息门户、协作门户、专业门户、知识门户等等。但不管分类如何划分，Portal对底层的规定和其基础架构有显著的一致性，并且随着时间的推移，业界、新闻界以及分析家都对Portal定义的见解逐渐趋于一致。简朴的说，门户是一个重要的 Web 站点并且是一个联合的社区，它提供内容聚集、搜索服务、协作工具、应用程序访问和集成，所有这些功能存在于与最终用户进行个性化的交互中。通过个性化 "我的主页（My Home Pages）" 来满足每个最终用户的需要并将个性化嵌入门户服务和应用程序各个角落，我们可以对门户加以区分。另一方面，门户与 Web 站点不同，由于它用几乎相同的措施将个性化与选择内容、协作功能程序以及应用程序服务结合在一起。对最终用户而言，门户就是一个到所有计算资源的单独访问点。
门户（Portal）是Web 应用程序的简朴统一的访问点,不仅如此还提供了许多有价值的附加功能，例如安全性、搜索、协作和工作流。门户网站提供了集成的内容和应用，以及统一的协作工作环境。事实上，门户网站就是下一代的桌面，可以在 Web 上向各种客户机设备提供大量的电子商务应用。
BEA Weblogic Portal完整的门户网站解决方案可以让用户随时随地、安全、方便地访问完毕他们任务所需的所有东西。门户网站是延伸与用户体验（Reach and user experience）的关键。也就是说，门户网站提供工具和用户界面，用于访问信息和应用程序，个性化管理和选择内容。
ü 集中完毕应用的认证和授权管理。门户服务将承担用户对各种信息和应用资源的统一访问服务，对用户的身份进行验证，并控制用户对各类资源的访问权限。
ü 构建、连接和管理应用程序。为公司应用整合提供基础支撑，通过Portal服务，公司可以将各种分散的应用服务功能整合在门户服务平台上，方便用户对各种应用资源的访问，使各种独立的应用系统通过门户服务平台形成一个完整的应用。
ü 业务流程的集成和自动化。通过门户服务平台提供的功能化的服务组件，如：工作流服务组件，公司可以实行大量的以业务为导向的业务流程集成和自动化解决。
为各种用户提供个性化访问功能。通过门户服务我们可以有效的定义和控制各种不同的用户可以获得和访问的信息内容。
在大型信息化门户平台中，需要对不同的业务资源进行整合，有组织地对用户进行展示。通过下面的方法，在WebLogic Portal中，将整个公司的资源充足运用并有机组合，以灵活和有序的方式进行展示。
Portlet：Portlet是门户中的一些应用或应用的视图，可以被当作不同的内容版块。根据开发方式的不同，BEA WebLogic Portal可以支持不同类型的Portlet（JSP/HTML、Web服务、Pageflow或Java），开发人员可以使用Portlet来集成公司系统中位于不同位置的数据和访问不同性质的应用，并以统一的方式进行展示。
Web 集成：通过WebLogic Portal, 不仅可以用Portlet直接透视公司的数据。同样，假如这些数据已经通过Web方式进行了展示，或者需要在Portal中集成其他Web页面的信息，Portal提供了Web内容集成功能，将其他Web页面内容嵌入公司的Portal，使Portal成为所有资源的统一入口。
Web Services：公司门户中某些数据也许是通过访问 Web Services应用得到的。WebLogic Workshop中可以使用简朴的可视化开发工具，简化对Web Services的访问，以便将对Web Services的访问快速地集成到公司门户中。
页面流Pageflow：公司级应用往往建立在MVC的技术基础上实现，在WebLogic Portal中，实现了以Struts为核心的流程控制管理功能，页面逻辑、后台服务（由EJB等实现），数据效验和流程控制在统一的图形化界面中完毕。可以使应用开发进行合理分工，同时保证了整个系统的灵活性，同一个后台服务可以同时为不同的界面逻辑服务。只要系统管理员将应用进行相应的配置就可以实现。
3.6.1 内容管理
内容管理系统是门户的重要功能之一。管理人员通过内容管理完毕网站信息的采集、编辑、审核、发布。BEA WebLogic Portal 提供内置的内容管理系统模块，同时也可集成第三方的内容管理系统。
内容管理系统可以与门户系统无缝集成，支持门户网站统一的目录服务，系统必须通过门户网站管理系统认证后进入，向各类用户提供统一的访问点。
内容管理系统应能提供对信息的搜集、组织、筛选、分类、搜索和自定义等一系列功能，实现对非结构化和结构化数据的高效和有序的统一管理和存储。
支持用户管理和权限设立，并能让用户根据自身情况快速搭建内容的组织结构。  
提供对信息安全性的多级别、多方式的定义，以保证信息的完整、真实和安全。  
可预先定义信息的发布形式和页面显示格式。 内部和外部用户可以通过浏览器、智能搜索、个性化工具等快速获得信息。
支持本网站的全文检索。
支持多语种。
支持模板管理。
支持系统集成。