某市应急指挥系统BEA技术建议方案.docx

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系统监控，保证SLA263.7BEA实现的SOA架构优势273.7.1全面、统一的平台273.7.2基于标准的开放平台273.7.3简单、高效率实施294成功案例301 项目总体要求项目要求见项目需求书，此处略。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 提供内置的内容管理系统模块，同时也可集成第三方的内容管理系统。内容管理系统能够与门户系统无缝集成，支持门户网站统一的目录服务，系统必须通过门户网站管理系统认证后进入，向各类用户提供统一的访问点。内容管理系统应能提供对信息的搜集、组织、筛选、分类、搜索和自定义等一系列功能，实现对非结构化和结构化数据的高效和有序的统一管理和存储。支持用户管理和权限设置，并能让用户根据自身情况快速搭建内容的组织结构。  提供对信息安全性的多级别、多方式的定义，以保证信息的完整、真实和安全。  可预先定义信息的发布形式和页面显