BEA方案的实施架构有七层，其中应用的应用逻辑和功能的开发占两层，分别是应用功能服务层和应用数据存访层，它们对应于传统的多层Web应用构架中的功能逻辑层和数据存访层。而多层Web应用构架中的Web展现层则被展开成跨系统整合的五层结构，分别称为用户界面集成层，业务流程集成层，逻辑功能梳理层，核心信息共享层，和应用外接界面层。在EAI平台上的有业务流程集成层、逻辑功能梳理层、核心信息共享层和应用外接界面集成层。

 
　　OSS在BEA集成平台上分七层剖面图

　　用户界面集成层（展现层）

　　一个典型的EAI问题是，各个应用系统都要开发自己的用户界面，而且每个用户界面使用的终端设备有限，结果新的跨系统的业务流程如业务开通的业务员，不得不同时使用不同的用户界面，并受到终端设备可及性限制，大大降低了使用者的工作效率。客户的WEB用户界面也是如此，结果自主在线服务利用率和满意度都大大折扣。

　　BEA方案将用户界面集成摆在最上层，目的是通过集成多种业务系统的用户界面，建立一个跨应用，设备，和企业的统一，集成的互动用户界面，让用户有着适用，实用，灵活，即时，性格，和牢靠的舒适体验。客户可以通过任何设备从任何地方获取所需信息。

　　BEA在用户界面集成层对应的产品是WebLogic Portal。

　　业务流程集成层（业务集成层）

　　所谓的业务流程，是指为了在一定时期内达到特定的商业目标，而按照各种商务规则连接起来的业务功能集。这些业务功能是抽象定义的：业务功能的具体实现受限于业务功能运行所必须的可用资源，包括业务人员，IT业务应用系统，客户，和商务交往及贸易伙伴等。业务功能的构成由目标决定，其中的任何操作、活动、任务都是为实现该目标而设。在业务流程中，商务规则或者表现为条件和限制，或者表现为实施并发、串行等流程中的行为（Activity）节点。

　　在没有实现业务流程集成的企业系统中，业务流程的实现分布在应用的代码中，并需要跨部门的手工合作来做业务操作，这样进行快速流程变更的灵活性极小。采用以业务流程驱动的企业架构后，将业务流程的逻辑从应用中释放了出来，集中到业务流程管理器，形成了一个新的层，可以称之为”业务流程集成层”。旨在帮助企业从战略上，管理和提高动态业务流程效率。这正是”业务管理”的本质所在。

　　业务流程集成层由下列技术成分组成：

　　业务流程引擎：BEA业务流程引擎是流程的执行分配、激活和执行引擎。它是一个关键组成成分，其目的是完成业务流程，并按照逻辑的流程定义来实时地管理业务功能的启动和终止。而BEA业务流程管理器完全建立在WebLogic Server服务器上，是由WebLogic Server服务器管理的EJB组件集成。

　　资源管理工具：无论是通过机械的、电子的、软件或者人工方式来完成业务功能所需要的资源，均由资源管理工具进行统一管理。当某一业务功能启动时，该功能相关的资源必须保持可用，而当业务功能完成时，该资源必须能够释放，并随时提供使用。资源管理工具还必须能够提供均衡负载，适时资源调配以保证业务功能正常进行。

　　调度工具：对于给定任务、负载均衡、代理控制等，必须考虑能力和权限。业务流程和事务通常带有外在的时间限制。因此业务功能的调度是非常复杂的技术问题。如果没有调度工具，那么将无法保证执行的效率。

　　审计管理工具：BEA WebLogic Integration的事务存档功能自动记录所有流程活动，能够对业务流程进行审计是。审计管理工具能够跟踪业务的执行、决策以及在什么时间，由什么角色或什么人，使用什么资源完成。

　　错误管理工具：尽管很多错误能够被预先估计并可采用一定的业务流程进行处理，但是经常出现意想不到的错误。错误管理工具必须能够使用统一的、可跟踪的方式进行处理。

　　安全和策略管理工具：业务流程管理可以使用不同的安全和策略，来决定哪一个代理被授权完成一个任务或活动，使用哪一个资源或哪一些资源完成。业务流程管理不能违反这些安全和策略的限制，应该保证安全性，包括访问控制、资源使用和用户管理等。

　　资源库：业务流程集成层资源库中可存储多种数据对象，包括：

　　业务流程定义语言程序（JPD）
　　实例记录（Instance）
　　消息（Message）
　　数据流 (Input)
　　业务度量定义和数据（Attribute）
　　事务定义和数据 (Transaction State)
　　安全和策略定义 (Security Policy)
　　访问记录(Archive)
　　仿真数据(Simulated Testing Data)
　　错误事件和解决方法(Exception Handling)

　　BEA方案中的业务流程集成层，和企业业务系统通过集成处理器间接交流通信，而它直接依赖的是逻辑功能梳理层。这样，它具备了较好的流程设计、测试和设计更改的能力，而且很容易将其他的新旧系统集成进来。业务流程分两类：业务流程自动化和人员介入工作流。业务流程自动化用来实现应用系统业务流程之间的自动调度，而人员介入工作流适用于那些需要人员进行干预的流程，譬如业务审批流程。其实，很多业务流程都会结合这两类功能，即一部分业务流程需要自动化，而其他部分需要人员介入。所以，业务流程集成层也可以通过集成处理器和门户相连，提供人员介入的交互界面。本层在架构上主要提供：

　　通过子流程来实现业务流程共享
　　支持技术和商务标准协议
　　支持快速实施
　　助企业获得全面业务透视能力，从而让企业可以全面掌控业务

　　逻辑功能梳理层（逻辑功能层）

　　BEA方案中的逻辑功能梳理层将业务功能抽象出来，以多种多样的组件方式提供的接口和表达方法。其重要性是它可以让我们将工作中心放在将这些逻辑界面为交流对象的业务流程模型建模上。它有下列特点：

　　用BEA的控件技术，对应用功能的逻辑界面提供了在技术层上的封装，封装成业务功能控件。根据业务功能梳理和重组的合理需要，功能控件可以通过集成处理器，以同步或异步方式和一个或多个应用系统连接。这样我们达到了虚系统的目的，在开发过程中的相互依存度被弱化，有利于变更管理。

　　对于应用的信息访问部分，发挥BEA 聚合信息视图的威力，根据业务需要，提供同步多系统交叉信息查询的逻辑界面, 进一步将所有子系统的聚合以一个整体的虚系统和统一的信息资源呈现给业务流程集成层或用户界面集成层。

　　如果有集成需求，应用功能的逻辑界面可以包含现有信息系统的功能或信息，将有价值的现有信息整合进来，达到重用的目的。因为通常企业的信息和应用系统是逐步建立的，在整合系统时如果能够把原来的应用封装接入到集成处理器上，将大大缩短上线周期，并降低开支。

　　对应用功能的逻辑界面做先期的梳理和重组，有利于辽宁通信对整个工程做整体规划，逻辑界面和实应用系统的衔接便仅是实施的优先次序问题。

　　逻辑功能梳理层由下列技术成分组成：

　　控件：在Weblogic Workshop中建设业务流程模型时，所有的业务行为（Activity）都通过调用控件来定义的。控件以Java接口的形式定义了逻辑业务功能，包括企业应用功能、作业流对话功能，消息收发格式，Web Services协议等。这种抽象在各个开发人员之间成为沟通的手段。

　　聚合信息视图： 有时如门户，业务流程等需要简单直接地进行多系统单步信息联合搜索（Joint Query）、访问、和复制。LiquidData为多种、异构的数据源提供实时的逻辑单一聚合信息视图。如下图 所示的LiquidData聚合信息视图定义工具界面用来定义联合搜索所用的Xquery语句。

　　核心信息共享层（信息转换层）

　　核心信息共享层主要关心的问题是如何为在集成平台上跑的各个功能模块，业务流程模块，用户门户模块等的核心信息共享提供方便，如：

　　· 各系统的信息同步
　　· 共用的信息语言，词汇，和模型
　　· 核心信息共享和高效存访
　　· 信息交换方式和转换格式
　　· 信息交换业界标准

　　核心信息共享层是应用系统接入集成处理器的粘合层。这是因为我们应设法让集成处理器内信息越中立越好，所以在信息进入集成处理器以前先将它转换成各方都懂的语汇是必要的。本层为信息搜索、访问、复制、转化

 
　　WebLogic Integration 转换图形对话工具和分析提供基础

　　BEA WebLogic Integration的信息集成模块可以很好地管理结构化、半结构化和非结构化的信息，支持XML标准作为交流语言，并且可以通过适配器与其他应用系统共享数据。通用业务词汇作为信息共享的跨系统交流的中介结构总结，将在下以探讨。

　　应用连接层

　　这里的应用连接层包括应用外接界面层和应用功能服务层。

　　应用连接层是指将企业应用通过标准接口界面开放，以共享和使用其内部信息，接受外部指令和信息，为外界提供功能服务。企业资产有效连接到整合处理器后，不同系统中的信息可以在整个企业范围内共享，业务流程也有了原动力，内涵，和生命。换句话说，本来散落在各系统角落的数据便活灵活现地以有价值的信息，呈现在企业内外的业务员，领导，和顾客面前。

　　连接层需要解决的是在应用系统与集成平台之间的互连问题，通常采取的方式是以集成平台为主，由集成平台统筹考虑整体系统的需求，提出互连的方式、通信协议、交互形式等等规范。

　　在连接层要完成的任务：

　　将应用服务层提供的服务通过适配器连接到集成平台上来。在集成平台的开发环境上通过类似与适配器视图的应用可以看到所提供的服务，然后在集成平台上进行流程的整合和服务的调用。

　　对一些特定通信方式和协议开发相应的适配器，如HTTP、Socket、FTP、JCA等。如果EAI平台提供商能够提供相应的适配器则更好。

　　如果应用直接通过Web Services接口协议，连接层只要引入Web Services控件便可。在BEA集成平台上开发的系统功能服务可以自动生成Web Services接口界面。

　　应用功能服务层和应用数据存访层

　　开发部门应以面向服务的架构为指导，在WebLogic APS 上以层次构架来设计应用系统。应用功能服务层要求不但要提供系统内部的功能服务模块，也是定义该系统开放给外部的服务，使应用外接界面层可以方便地调用该系统的服务以获取相应的信息或执行相应的任务，即要求应用系统以应用网关、Web Services甚至是业务代码等多种形式来实现对外的服务开放，使其是可集成的。

　　在应用服务层要完成的任务：

　　· 软件的开发平台应该是符合面向服务思想的架构，提供的服务应该是可以被外部调用的。如Tuxedo Services、J2EE Services

　　· 在业务系统分析的基础上对业务功能服务进行服务分解，哪些服务是为内部使用的，哪些是为其它应用系统提供服务的。

　　· 对那些要被外部应用调用的服务进行包装，使之成为可以被应用集成平台调用的方式，如Tuxedo Services、Web Services等。

　　应用数据存访层

　　应用数据存访层，主要是指待集成系统自己内部的数据模型（Schema），该层次与具体系统负责的功能领域关系密切。但是，从整体的数据整合方面的需求来看，需要对各系统的数据模型以外模式的形式给予定义和规划。这种定义规划主要依据统一数据视图的需求。但是需要指出的是在这个层次上，应用数据模型与统一数据视图的需求是一种松偶合的机制。

　　”三层体系结构，即用户层、应用层和数据库服务器。用户层主要指用户界面，它要求尽可能的简单，使最终用户不需要进行任何培训就能方便地访问信息；第二层就是应用服务器，也就是常说的中间件，所有的应用系统、应用逻辑、控制都在这一层，系统的复杂性也主要体现在应用层；最后的数据库服务器存储大量的数据信息和数据逻辑，所有与数据有关的安全、完整性控制、数据的一致性、并发操作等都是在第三层完成。

　　WebLogic Server提供的数据存访层服务可以访问异构数据库并通过连接池等多种技术保证数据访问的效率和可靠性。