(作者：文枫 本文选自：开放系统世界——赛迪网 2003年01月15日 )
随着Internet与分布对象计算技术的飞速发展，电信、银行、电力、工商、税务等传统企业都希望把原来基于C/S架构的传统业务应用通过Web来展现。
那么如何在企业业务迅猛发展、应用需求不断扩大、市场竞争日趋激烈、业务整合难度不断加大的基础上，采用灵活、先进的设计理念及结合开放式的系统软硬件平台，在确保业务系统安全、高效、可靠的基础上，构建面向Web、集事务调度、系统配置、业务拓展、统计分析等功能于一体的智能化企业应用平台呢？事实上，数字技术发展到今天，软件已不再是需要安装于具体平台的程序，而是演变为一种互动的服务。那么为了有效地利用企业原有的资源，并无缝地实现新形式下企业传统业务的集成，是不是可以设计一个与行业无关的企业应用整合框架（Enterprise Application Integration Frame，EAIF）呢？它将是一个面向Web的、可动态识别和加载新业务、自适应、易扩展的企业应用整合平台。答案应该是肯定的。本文将详细讲述该架构的设计思想，并提出具体的实现方法。这一设计思想已应用在深圳市电信局的“网上电信局”系统和800业务系统中，并取得了很好的实际效果。
EAIF实现的是一站式网上服务平台的理念。对于企业而言，它将逐渐作为一个独立主流的渠道，并成为传统业务面向Web应用的电子商务平台，从而给企业客户提供个性化的网上业务交易、市场拓展与营销、技术支持和产品售后服务等。希望该文能给那些致力于企业应用整合平台的软件分析与设计人员提供一个思路，并期待与大家探讨以使EAIF更加完善。
系统概述
将企业传统业务整合成面向Web的应用，将是一个分步实施的长期过程。为使其具有良好的技术前瞻性和较强的可伸缩性、可扩展性和易移植性，整体规划显得尤为重要。为了实现这一目标，EAIF系统将以J2EE/XML规范作为实现的基础，具体采用当前成熟的表示逻辑（浏览器层）+业务逻辑（应用服务器层）+数据逻辑（数据库和业务系统层）的分布应用多层结构技术。
核心+插件的配置模式
我们构建EAIF的目的，首先是建立一个可以整合某一行业所有业务应用的、面向Web的通用事务处理平台，并在此基础上，将其架构为一个可以屏蔽行业差别、透明业务处理的抽象模型。也就是通过构建统一的、可重用的系统核心控制与管理模块，在面向具体应用时，根据企业需求进行相应的业务定制，即可配置生成该模型在某一行业的应用实例。该模型将主要包括系统核心（框架）和业务功能两大部分插件。
系统核心应包括用户管理、日志管理、事务调度与管理、安全管理、统计分析等功能。业务插件则主要实现不同行业、不同企业、不同应用需求的业务功能定制（即面向Web服务的业务系统代理），具体采用业务代理EJB的实现模式。如在“网上电信局”中，电信原来97系统的业务处理功能通过CORBA接口封装在Agent97 EJB中实现，而原来的170系统的账单查询等功能，则通过Jolt调用Tuxedo Service封装在Agent170 EJB中实现等。
独立、健壮、完整的Web框架
EAIF的Web应用框架并不单纯是某个需求分析或者面向对象建模的结果，而是EAIF的一个基础部分（也就是系统的核心）。Web框架系统的最终目标是成为一个可以适应大多数企业级Web应用需要的基础系统，可以把前台（JSP或页面）开发人员和后台（EJB或业务插件）开发人员的工作完全分离，以保证高效率和低成本的开发。
Web框架系统运行在Web服务器中，而EJB或业务系统代理运行在应用服务器中。
Web框架的主要功能如下：
◆ 完全符合J2EE规范，可以搭建在任何符合J2EE标准的Web服务器中；
◆ 管理基本的数据库连接；
◆ 完善的日志系统，包括系统日志和业务日志；
◆ 管理用户类型，且用户类型可以自定义（提供用户类型开发接口）；
◆ 管理某一用户类型的可用业务；
◆ 管理用户生存期；
◆ 负责业务分发，控制业务并发负载；
◆ 可自定义所需要的初始化插件（提供业务插件开发接口）；
◆ 使用XML完成系统配置和数据交换；
◆ 统一的用户登录门户；
◆ 统一的XML业务数据入口和出口。
它的主要工作流程如下：
◆ 系统初始化流程（如图1）
图1 系统初始化流程图
◆ 业务处理流程（如图2）
图2 业务处理流程图
系统体系结构
系统架构
EAIF采用分布应用的多层结构，其架构如图3所示。
图3 EAIF架构图
技术层次
EAIF的技术实现采用J2EE/XML/CORBA的规范，其技术层次如表1所示。同时它提供完整的二次开发接口。
表1 EAIF的技术层面
系统关键技术
事务调度与管理控制
为了对所有的业务进行统一分派和管理，并为将来可能增加的新业务预留处理接口，将在EAIF的实例中对所有的企业业务进行分类，对每个具体的业务分配相应的BusinessID。如将电信97系统所包含的业务定义为[1000，1999]，将800系统业务定义为[2000，2999]等。通过一个XML文件，对所有具有确定BusinessID的相应业务进行定义和描述，并在系统启动时进行初始化。代码如下：
这样，就定义了BusinessID为1000的业务类型、代理EJB的JNDI名及最大并发数。最大并发数为0表示无限制。
在此基础上，为了实现对EAIF实例中所有业务的统一调度，可以定义事务管理器TransactionManager，它将负责读取XML初始化配置信息文件，然后根据获得的JNDI名初始化所有业务代理EJB的本地接口，并保存到Hash表。它还要分析、解包由浏览器发来的业务请求。根据BusinessID调用相应业务代理EJB远程接口中的商业方法，它还将处理结果发送回浏览器，同时记录系统日志和业务处理日志。具体处理如图4。
图4 Transaction Manager处理图
在EJB中集成CORBA
Java和CORBA具有相当强的互补性，两种技术的紧密结合，使其成为ObjectWeb技术的主要形态，也是当前Web Service分布计算平台的基础。
首先，Java提供了一个概念清晰、结构紧凑的分布计算模型和构件互操作的方法，为组件应用开发提供了相当的灵活性。CORBA是一种集成技术，更是一个非常完善的分布对象平台。CORBA可以扩展Java在网络、编程语言、组件边界、操作系统中的各种应用。
其次，Java不仅是适合与CORBA捆绑的语言，还是一个跨平台的对象系统，允许CORBA对象在大型主机、网络计算机和移动电话等应用上运行。Java优化了大型应用系统中的内存分配，其中内置的多线程和垃圾收集机制使编写可靠的网络对象更为方便。采用CORBA可以将网络对象连接在一起，并与异构环境中的数据库、原有业务系统、其它语言编写的对象和应用相互集成。
CORBA与Java的基础结构也具有互补性。CORBA处理网络透明性，Java则处理实现透明性。CORBA提供了采用Java实现应用环境与对象间连接的便捷通道。
在EAIF中，我们将把业务代理EJB与原有系统之间通过CORBA IDL接口进行集成。同时，把所有涉及IDL接口实现的操作封装在EJB中。具体地说，只在EJB容器中进行CORBA调用，即只在业务代理EJB的ejbCreate方法中实现CORBA的根名字引用和接口对象初始化。这样将CORBA接口对象操作封装在业务代理EJB的生存周期中，从而避免JSP/Servlet无意的直接调用，这将使业务生产系统的接口更为安全。而前台JSP/Servlet则只能访问EJB远程接口的业务申请referApply(String xml)方法，并必须通过预先定义的、一套专有的XML业务数据传输格式与EJB进行通信。这将使业务受理更易于调度，并使系统的开发、维护与升级也更为简单和方便。
XML消息总线
EAIF系统部署采用XML配置文件，系统将有一个核心的管理配置文件Config.xml，另外还有一个Business.xml。Business.xml用于对业务插件（不同业务系统连接的Adapter）进行配置。通过对系统配置XML文件的动态定制与更新，即可实现业务的动态配置、识别与加载，同时通过实时刷新各类用户可操作的业务列表，使企业在需要增加新业务或抛弃旧业务时，不需要Reset服务即可实现业务应用的“热拔插”。显然，这将使企业在激烈的市场较量中更富竞争力。另外，通过定义一套专有的XML业务数据传输格式，作为前台Web页面（JSP/Servlet）编写人员与后台业务代理EJB开发人员之间进行业务申请和受理的专用XML通信通道，从而使前台开发人员的要求大大降低。因为他们不需要了解复杂的后台业务系统和艰深的CORBA技术，即可完成页面开发工作。这样，通过XML使业务处理透明，在大大降低开发成本的同时使系统更灵活健壮，移植部署也更为方便。
连接池技术(ORB/DB)
EAIF系统中，为了提高关键业务的处理效率和吞吐量，必须采用连接池技术。我们需要考虑两种类型的连接池，一为数据库连接池，另一为对象连接池。
◆ 数据库连接池
该技术已非常成熟，并且应用广泛。在许多主流应用服务器中，如BEA WebLogic Server和IBM WebSphere，在它们的控制台中都提供了连接池的配置工具，直接配置即可。如想自己创建，也不会很困难。因为虽然JDBC1.0标准及其扩展中没有定义连接池，但在JDBC 2.0标准的扩展中定义了与连接池相关的接口，实现与接口对应的类即可。图5简略地描述了数据库连接池的运行机制（对象连接池也类似）。
图5 数据库连接池的运行机制
◆ 对象连接池
在调用CORBA服务时，如果频繁地创建和销毁接口引用对象，必然会使性能受到影响，尤其在大规模并发访问中。如果没有连接池，很可能导致CORBA服务器因排队等待的任务过多而超时，或者因为负载过重而直接导致CORBA服务器没有响应。显然，这是不允许的。所以，为了避免这种情况，我们采用对象池技术。实现方式有两种，如果应用服务器提供了配置工具，如WebLogic Server就提供了连接Tuxedo CORBA主域的配置工具WLEC，直接配置其Config XML文件即可。如果没有，则必须自己创建对象池。需要指明的是，具体的ORB管理连接池可能依赖于EAIF所采用的ORB提供厂商，比如BEA的WLE与Inprise Visibroker及IONA Orbix的ORB，它们具体实现都是不同的。
与后台业务系统的接口方式
CORBA IDL接口
EAIF与业务系统接口的调用方式可采用CORBA IDL。业务系统CORBA接口的所有实现方法都封装在业务代理Stateless EJB中，通过该业务处理EJB调用WebLogic Enterprise的、Tuxedo主域提供的CORBA服务。前台JSP通过调用EJB的远程接口referApply方法，实现业务的具体申请和受理。
如何在EAIF的业务插件接口中实现具体业务处理呢？我们可以根据不同的业务类型定义IDL的不同模块，然后在一个模块中定义一类业务的多个操作接口与商业方法。假设要实现某一类业务，如电信的97业务，它可能涉及多个商业方法，如电话新装、验证用户密码、改电话特性、停机/复机、移机/拆机等。
那么如何来实现业务代理EJB呢？我们可以根据某类业务的大小设计N+1个Stateless EJB。其中AgentBusinessBean实现该类业务操作接口与事务管理控制器TranscationManager的通信。它主要根据业务的BusinessID，分发前台的业务申请到另外N个含具体业务处理方法的Stateless EJB中，具体为AgentBusinessBean1、AgentBusinessBean2...AgentBusinessBeanN。其中Stateless EJB处理10个具体的Business业务，它们共有的远程和本地接口分别为AgentBusiness和AgentBusinessHome。如果将来需要在该类业务中增加新的Business方法时，只需要根据该接口格式增加AgentBusinessBeanN+1... AgentBusinessBeanN+M，并在EAIF的config.xml中加入新业务方法及有权操作用户的声明，将business.xml中的BusinessEJBCount改为N+M，即可实现新业务的自动识别和加载，不需要修改前面的任何代码。
同样，如果需要再增加不同类型的业务，我们只需再定义一个不同的module，在IDL中声明相应的接口和方法、在CORBA服务端实现、在EJB中调用即可。当然，也需要将EAIF的config.xml进行相应的更新。但不需要对以前的代码进行任何修改，甚至根本不需要了解以前已实现的业务，只要按照EAIF的新业务开发规范即可完成新业务的开发、配置和部署。
JOLT调用Tuxedo服务
很多企业的业务系统，比如深圳电信的客户服务中心（现在的1000号，原来的112/114/180/189等）就是直接通过Tuxedo服务器直接提供业务受理。在这种情况下，再为此建立CORBA接口，一是开发代价较大，二是根本没有必要，因此完全可以直接通过Java来访问Tuxedo服务。具体实现时，可使用BEA提供的Jolt类包。如果应用服务器采用BEA的WebLogic Server，还可通过配置其中的Jolt Session Pool，实现对Tuxedo Service的业务调用与动态负载均衡。
系统配置
系统功能配置采用XML文件描述，主要涉及以下XML文件：
◆ Web.xml文件
该文件是J2EE标准Web服务器使用的Web配置文件，应该放在Web服务器的WEB-INF目录下，在EAIF的启动控制Servelt中指明系统主要配置XML文件的路径；
◆ config.xml文件
在EAIF的Web框架系统中，负责描述包括数据库、日志、JNDI环境、额外的初始化插件、业务代理EJB、用户类型、用户类型可用业务等多种信息；
◆ business.xml文件 负责描述EAIF与后台业务系统的接口方式及连接池的配置。
系统主要功能
从上面的分析可以看到，设计EAIF系统主要应包含核心框架、事务管理、系统配置、统计分析及业务插件等五个子系统。
1. 核心框架子系统
适应大多数Web应用需要的基础系统，可以把前台（JSP或页面）开发人员和后台（EJB或业务）开发人员的工作完全分离，以保证高效率和低成本的开发，并提供系统开发接口。
2. 事务管理子系统
实现对EAIF的所有业务进行统一调度，负责负载均衡与业务热拔插；
3. 系统配置子系统
提供统一的系统管理与配置窗口，以便帮助运行维护人员完成新业务的配置部署，并提供规范的二次开发接口；
4. 统计分析子系统
反映企业业务的种类、各类业务量的分布，为业务管理部门提供决策支持。
5. 业务插件子系统
实现不同企业的不同业务的网上代理功能。它相对独立于EAIF，按照不同企业的应用需求进行具体的接口分析与商业方法实现。
系统主要特点
1. 业务的动态识别与加载（软件热拔插）
EAIF中的所有业务都由系统核心配置XML文件定义，通过EAIF系统的管理控制台可实现新业务的添加和旧业务的抛弃。系统将通过一个守护进程监听XML文件的变化，并将变化后的新业务列表解析读出，并保存到一个HashSet，在业务相对空闲时进行新业务的动态配置、识别和加载。这并不需要Reset应用服务器，更新可用业务的HashSet即可。其相关XML配置参考如下：
该文件既可由EAIF提供的控制台进行配置，也可由用户手工修改。
◆ 完善的日志管理
EAIF系统将包括：系统日志和业务日志两套日志。系统日志负责记录系统运行信息，保存在文本文件中。业务日志则负责记录业务使用的情况，保存在数据库中。
系统日志和业务日志的级别描述为：
1：debug
2：info
3：warn
4：error
5：fatal_error
选择的级别会把低级别的信息自动屏蔽掉，建议在运行初期设置为1，稳定以后设置为2。日志级别可通过系统XML配置文件的 <log>节点来设定。示例如下：
2. 个性化服务（Portal）
EAIF应提供适合于不同用户需求的个性化服务，通过配置不同的用户类型登录页面，即可实现用户身份认证，完成后进入不同的个性空间。根据用户的级别，提供积分和相应的优惠，并特别为大客户提供“绿色通道”，尽量考虑和满足企业大客户的应用需求。其基本的XML参考配置如下：
3. 插件配置接口
EAIF为实现灵活的配置方案和方便的用户定制，应提供相应的插件配置接口。具体包括用户类型认证器接口、用户角色接口及定制的初始化业务插件接口。
◆ 用户类型认证器接口和用户角色接口提供EAIF系统支持的用户类型开发和定制。用户类型认证器实现该类用户的身份确认，而用户类型角色实现记录该用户类型的某些参数和用户特性。只要实现这两个接口，即可添加任意需要的用户类型。将其加入系统核心配置XML文件，即可完成该类用户的认证，并且可以识别其可操作的业务类型。其参考XML配置如下：
该用户可操作的业务类型定义XML参考配置：
◆ 额外的初始化插件接口提供其它任何需要的插件定义。只要实现该插件接口，就可向EAIF系统中加入任何需要的初始化插件信息。其在系统核心配置XML文件的参考配置如下：
随着Internet与分布对象计算技术的飞速发展，电信、银行、电力、工商、税务等传统企业都希望把原来基于C/S架构的传统业务应用通过Web来展现。
那么如何在企业业务迅猛发展、应用需求不断扩大、市场竞争日趋激烈、业务整合难度不断加大的基础上，采用灵活、先进的设计理念及结合开放式的系统软硬件平台，在确保业务系统安全、高效、可靠的基础上，构建面向Web、集事务调度、系统配置、业务拓展、统计分析等功能于一体的智能化企业应用平台呢？事实上，数字技术发展到今天，软件已不再是需要安装于具体平台的程序，而是演变为一种互动的服务。那么为了有效地利用企业原有的资源，并无缝地实现新形式下企业传统业务的集成，是不是可以设计一个与行业无关的企业应用整合框架（Enterprise Application Integration Frame，EAIF）呢？它将是一个面向Web的、可动态识别和加载新业务、自适应、易扩展的企业应用整合平台。答案应该是肯定的。本文将详细讲述该架构的设计思想，并提出具体的实现方法。这一设计思想已应用在深圳市电信局的“网上电信局”系统和800业务系统中，并取得了很好的实际效果。
EAIF实现的是一站式网上服务平台的理念。对于企业而言，它将逐渐作为一个独立主流的渠道，并成为传统业务面向Web应用的电子商务平台，从而给企业客户提供个性化的网上业务交易、市场拓展与营销、技术支持和产品售后服务等。希望该文能给那些致力于企业应用整合平台的软件分析与设计人员提供一个思路，并期待与大家探讨以使EAIF更加完善。
将企业传统业务整合成面向Web的应用，将是一个分步实施的长期过程。为使其具有良好的技术前瞻性和较强的可伸缩性、可扩展性和易移植性，整体规划显得尤为重要。为了实现这一目标，EAIF系统将以J2EE/XML规范作为实现的基础，具体采用当前成熟的表示逻辑（浏览器层）+业务逻辑（应用服务器层）+数据逻辑（数据库和业务系统层）的分布应用多层结构技术。
核心+插件的配置模式
我们构建EAIF的目的，首先是建立一个可以整合某一行业所有业务应用的、面向Web的通用事务处理平台，并在此基础上，将其架构为一个可以屏蔽行业差别、透明业务处理的抽象模型。也就是通过构建统一的、可重用的系统核心控制与管理模块，在面向具体应用时，根据企业需求进行相应的业务定制，即可配置生成该模型在某一行业的应用实例。该模型将主要包括系统核心（框架）和业务功能两大部分插件。
系统核心应包括用户管理、日志管理、事务调度与管理、安全管理、统计分析等功能。业务插件则主要实现不同行业、不同企业、不同应用需求的业务功能定制（即面向Web服务的业务系统代理），具体采用业务代理EJB的实现模式。如在“网上电信局”中，电信原来97系统的业务处理功能通过CORBA接口封装在Agent97 EJB中实现，而原来的170系统的账单查询等功能，则通过Jolt调用Tuxedo Service封装在Agent170 EJB中实现等。
独立、健壮、完整的Web框架
EAIF的Web应用框架并不单纯是某个需求分析或者面向对象建模的结果，而是EAIF的一个基础部分（也就是系统的核心）。Web框架系统的最终目标是成为一个可以适应大多数企业级Web应用需要的基础系统，可以把前台（JSP或页面）开发人员和后台（EJB或业务插件）开发人员的工作完全分离，以保证高效率和低成本的开发。
Web框架系统运行在Web服务器中，而EJB或业务系统代理运行在应用服务器中。
Web框架的主要功能如下：
◆ 完全符合J2EE规范，可以搭建在任何符合J2EE标准的Web服务器中；
◆ 管理基本的数据库连接；
◆ 完善的日志系统，包括系统日志和业务日志；
◆ 管理用户类型，且用户类型可以自定义（提供用户类型开发接口）；
◆ 管理某一用户类型的可用业务；
◆ 管理用户生存期；
◆ 负责业务分发，控制业务并发负载；
◆ 可自定义所需要的初始化插件（提供业务插件开发接口）；
◆ 使用XML完成系统配置和数据交换；
◆ 统一的用户登录门户；
◆ 统一的XML业务数据入口和出口。
它的主要工作流程如下：
◆ 系统初始化流程（如图1）
◆ 业务处理流程（如图2）
系统架构
EAIF采用分布应用的多层结构，其架构如图3所示。
技术层次
EAIF的技术实现采用J2EE/XML/CORBA的规范，其技术层次如表1所示。同时它提供完整的二次开发接口。
| 4 | EJB/XML/CORBA | J2EE EAIF API | |
| 3 | JSP/Servlet/XML | ||
| 2 | Java Runtime Environment | ||
| 1 | Windows/Unix/Solaris/AIX/Linux | ||
事务调度与管理控制
为了对所有的业务进行统一分派和管理，并为将来可能增加的新业务预留处理接口，将在EAIF的实例中对所有的企业业务进行分类，对每个具体的业务分配相应的BusinessID。如将电信97系统所包含的业务定义为[1000，1999]，将800系统业务定义为[2000，2999]等。通过一个XML文件，对所有具有确定BusinessID的相应业务进行定义和描述，并在系统启动时进行初始化。代码如下：
<AllBusiness>
<BusinessType>
<BusinessID>1000</BusinessID>
<BusinessEJB>Agent97</BusinessEJB>
<BusinessInfo>普通电话新装</BusinessInfo>
<BusinessMax>0</BusinessMax>
</BusinessType>
<AllBusiness> |
这样，就定义了BusinessID为1000的业务类型、代理EJB的JNDI名及最大并发数。最大并发数为0表示无限制。
在此基础上，为了实现对EAIF实例中所有业务的统一调度，可以定义事务管理器TransactionManager，它将负责读取XML初始化配置信息文件，然后根据获得的JNDI名初始化所有业务代理EJB的本地接口，并保存到Hash表。它还要分析、解包由浏览器发来的业务请求。根据BusinessID调用相应业务代理EJB远程接口中的商业方法，它还将处理结果发送回浏览器，同时记录系统日志和业务处理日志。具体处理如图4。
在EJB中集成CORBA
Java和CORBA具有相当强的互补性，两种技术的紧密结合，使其成为ObjectWeb技术的主要形态，也是当前Web Service分布计算平台的基础。
首先，Java提供了一个概念清晰、结构紧凑的分布计算模型和构件互操作的方法，为组件应用开发提供了相当的灵活性。CORBA是一种集成技术，更是一个非常完善的分布对象平台。CORBA可以扩展Java在网络、编程语言、组件边界、操作系统中的各种应用。
其次，Java不仅是适合与CORBA捆绑的语言，还是一个跨平台的对象系统，允许CORBA对象在大型主机、网络计算机和移动电话等应用上运行。Java优化了大型应用系统中的内存分配，其中内置的多线程和垃圾收集机制使编写可靠的网络对象更为方便。采用CORBA可以将网络对象连接在一起，并与异构环境中的数据库、原有业务系统、其它语言编写的对象和应用相互集成。
CORBA与Java的基础结构也具有互补性。CORBA处理网络透明性，Java则处理实现透明性。CORBA提供了采用Java实现应用环境与对象间连接的便捷通道。
在EAIF中，我们将把业务代理EJB与原有系统之间通过CORBA IDL接口进行集成。同时，把所有涉及IDL接口实现的操作封装在EJB中。具体地说，只在EJB容器中进行CORBA调用，即只在业务代理EJB的ejbCreate方法中实现CORBA的根名字引用和接口对象初始化。这样将CORBA接口对象操作封装在业务代理EJB的生存周期中，从而避免JSP/Servlet无意的直接调用，这将使业务生产系统的接口更为安全。而前台JSP/Servlet则只能访问EJB远程接口的业务申请referApply(String xml)方法，并必须通过预先定义的、一套专有的XML业务数据传输格式与EJB进行通信。这将使业务受理更易于调度，并使系统的开发、维护与升级也更为简单和方便。
XML消息总线
EAIF系统部署采用XML配置文件，系统将有一个核心的管理配置文件Config.xml，另外还有一个Business.xml。Business.xml用于对业务插件（不同业务系统连接的Adapter）进行配置。通过对系统配置XML文件的动态定制与更新，即可实现业务的动态配置、识别与加载，同时通过实时刷新各类用户可操作的业务列表，使企业在需要增加新业务或抛弃旧业务时，不需要Reset服务即可实现业务应用的“热拔插”。显然，这将使企业在激烈的市场较量中更富竞争力。另外，通过定义一套专有的XML业务数据传输格式，作为前台Web页面（JSP/Servlet）编写人员与后台业务代理EJB开发人员之间进行业务申请和受理的专用XML通信通道，从而使前台开发人员的要求大大降低。因为他们不需要了解复杂的后台业务系统和艰深的CORBA技术，即可完成页面开发工作。这样，通过XML使业务处理透明，在大大降低开发成本的同时使系统更灵活健壮，移植部署也更为方便。
连接池技术(ORB/DB)
EAIF系统中，为了提高关键业务的处理效率和吞吐量，必须采用连接池技术。我们需要考虑两种类型的连接池，一为数据库连接池，另一为对象连接池。
◆ 数据库连接池
该技术已非常成熟，并且应用广泛。在许多主流应用服务器中，如BEA WebLogic Server和IBM WebSphere，在它们的控制台中都提供了连接池的配置工具，直接配置即可。如想自己创建，也不会很困难。因为虽然JDBC1.0标准及其扩展中没有定义连接池，但在JDBC 2.0标准的扩展中定义了与连接池相关的接口，实现与接口对应的类即可。图5简略地描述了数据库连接池的运行机制（对象连接池也类似）。
◆ 对象连接池
在调用CORBA服务时，如果频繁地创建和销毁接口引用对象，必然会使性能受到影响，尤其在大规模并发访问中。如果没有连接池，很可能导致CORBA服务器因排队等待的任务过多而超时，或者因为负载过重而直接导致CORBA服务器没有响应。显然，这是不允许的。所以，为了避免这种情况，我们采用对象池技术。实现方式有两种，如果应用服务器提供了配置工具，如WebLogic Server就提供了连接Tuxedo CORBA主域的配置工具WLEC，直接配置其Config XML文件即可。如果没有，则必须自己创建对象池。需要指明的是，具体的ORB管理连接池可能依赖于EAIF所采用的ORB提供厂商，比如BEA的WLE与Inprise Visibroker及IONA Orbix的ORB，它们具体实现都是不同的。
CORBA IDL接口
EAIF与业务系统接口的调用方式可采用CORBA IDL。业务系统CORBA接口的所有实现方法都封装在业务代理Stateless EJB中，通过该业务处理EJB调用WebLogic Enterprise的、Tuxedo主域提供的CORBA服务。前台JSP通过调用EJB的远程接口referApply方法，实现业务的具体申请和受理。
如何在EAIF的业务插件接口中实现具体业务处理呢？我们可以根据不同的业务类型定义IDL的不同模块，然后在一个模块中定义一类业务的多个操作接口与商业方法。假设要实现某一类业务，如电信的97业务，它可能涉及多个商业方法，如电话新装、验证用户密码、改电话特性、停机/复机、移机/拆机等。
那么如何来实现业务代理EJB呢？我们可以根据某类业务的大小设计N+1个Stateless EJB。其中AgentBusinessBean实现该类业务操作接口与事务管理控制器TranscationManager的通信。它主要根据业务的BusinessID，分发前台的业务申请到另外N个含具体业务处理方法的Stateless EJB中，具体为AgentBusinessBean1、AgentBusinessBean2...AgentBusinessBeanN。其中Stateless EJB处理10个具体的Business业务，它们共有的远程和本地接口分别为AgentBusiness和AgentBusinessHome。如果将来需要在该类业务中增加新的Business方法时，只需要根据该接口格式增加AgentBusinessBeanN+1... AgentBusinessBeanN+M，并在EAIF的config.xml中加入新业务方法及有权操作用户的声明，将business.xml中的BusinessEJBCount改为N+M，即可实现新业务的自动识别和加载，不需要修改前面的任何代码。
同样，如果需要再增加不同类型的业务，我们只需再定义一个不同的module，在IDL中声明相应的接口和方法、在CORBA服务端实现、在EJB中调用即可。当然，也需要将EAIF的config.xml进行相应的更新。但不需要对以前的代码进行任何修改，甚至根本不需要了解以前已实现的业务，只要按照EAIF的新业务开发规范即可完成新业务的开发、配置和部署。
JOLT调用Tuxedo服务
很多企业的业务系统，比如深圳电信的客户服务中心（现在的1000号，原来的112/114/180/189等）就是直接通过Tuxedo服务器直接提供业务受理。在这种情况下，再为此建立CORBA接口，一是开发代价较大，二是根本没有必要，因此完全可以直接通过Java来访问Tuxedo服务。具体实现时，可使用BEA提供的Jolt类包。如果应用服务器采用BEA的WebLogic Server，还可通过配置其中的Jolt Session Pool，实现对Tuxedo Service的业务调用与动态负载均衡。
系统功能配置采用XML文件描述，主要涉及以下XML文件：
◆ Web.xml文件
该文件是J2EE标准Web服务器使用的Web配置文件，应该放在Web服务器的WEB-INF目录下，在EAIF的启动控制Servelt中指明系统主要配置XML文件的路径；
◆ config.xml文件
在EAIF的Web框架系统中，负责描述包括数据库、日志、JNDI环境、额外的初始化插件、业务代理EJB、用户类型、用户类型可用业务等多种信息；
◆ business.xml文件 负责描述EAIF与后台业务系统的接口方式及连接池的配置。
从上面的分析可以看到，设计EAIF系统主要应包含核心框架、事务管理、系统配置、统计分析及业务插件等五个子系统。
1. 核心框架子系统
适应大多数Web应用需要的基础系统，可以把前台（JSP或页面）开发人员和后台（EJB或业务）开发人员的工作完全分离，以保证高效率和低成本的开发，并提供系统开发接口。
2. 事务管理子系统
实现对EAIF的所有业务进行统一调度，负责负载均衡与业务热拔插；
3. 系统配置子系统
提供统一的系统管理与配置窗口，以便帮助运行维护人员完成新业务的配置部署，并提供规范的二次开发接口；
4. 统计分析子系统
反映企业业务的种类、各类业务量的分布，为业务管理部门提供决策支持。
5. 业务插件子系统
实现不同企业的不同业务的网上代理功能。它相对独立于EAIF，按照不同企业的应用需求进行具体的接口分析与商业方法实现。
1. 业务的动态识别与加载（软件热拔插）
EAIF中的所有业务都由系统核心配置XML文件定义，通过EAIF系统的管理控制台可实现新业务的添加和旧业务的抛弃。系统将通过一个守护进程监听XML文件的变化，并将变化后的新业务列表解析读出，并保存到一个HashSet，在业务相对空闲时进行新业务的动态配置、识别和加载。这并不需要Reset应用服务器，更新可用业务的HashSet即可。其相关XML配置参考如下：
<AllBusiness>
<BusinessType>
<!--
业务编号，业务编号在整个框架系统中是唯一的，必须为正整数，最大值为java.lang.Integer的最大值
-->
<BusinessID>1000</BusinessID>
<!-- 对应的业务EJB的JNDI名 -->
<BusinessEJB>AgentBusiness1</BusinessEJB>
<!-- 业务信息 -->
<BusinessInfo>示范1</BusinessInfo>
<!--
业务支持的最大并发数，等于0则无限制，小于0则不可做该业务操作，大于0则为业务支持的最大并发数
-->
<BusinessMax>0</BusinessMax>
</BusinessType>
<BusinessType>
<BusinessID>2000</BusinessID>
<BusinessEJB>AgentBusiness2</BusinessEJB>
<BusinessInfo>示范2</BusinessInfo>
<BusinessMax>0</BusinessMax>
</BusinessType>
</AllBusiness> |
该文件既可由EAIF提供的控制台进行配置，也可由用户手工修改。
◆ 完善的日志管理
EAIF系统将包括：系统日志和业务日志两套日志。系统日志负责记录系统运行信息，保存在文本文件中。业务日志则负责记录业务使用的情况，保存在数据库中。
系统日志和业务日志的级别描述为：
1：debug
2：info
3：warn
4：error
5：fatal_error
选择的级别会把低级别的信息自动屏蔽掉，建议在运行初期设置为1，稳定以后设置为2。日志级别可通过系统XML配置文件的 <log>节点来设定。示例如下：
<log>
<!-- 从1到5 -->
<log-priority>1</log-priority>
</log> |
2. 个性化服务（Portal）
EAIF应提供适合于不同用户需求的个性化服务，通过配置不同的用户类型登录页面，即可实现用户身份认证，完成后进入不同的个性空间。根据用户的级别，提供积分和相应的优惠，并特别为大客户提供“绿色通道”，尽量考虑和满足企业大客户的应用需求。其基本的XML参考配置如下：
<AllUserType>
<!-- 用户类型信息 -->
<UserType>
<!-- 登录成功的页面 -->
<LoginPage>LoginUserIndex.jsp</LoginPage>
<!-- 登录失败的页面 -->
<ErrorPage>ErrorPage.jsp</ErrorPage>
</UserType>
</AllUserType> |
3. 插件配置接口
EAIF为实现灵活的配置方案和方便的用户定制，应提供相应的插件配置接口。具体包括用户类型认证器接口、用户角色接口及定制的初始化业务插件接口。
◆ 用户类型认证器接口和用户角色接口提供EAIF系统支持的用户类型开发和定制。用户类型认证器实现该类用户的身份确认，而用户类型角色实现记录该用户类型的某些参数和用户特性。只要实现这两个接口，即可添加任意需要的用户类型。将其加入系统核心配置XML文件，即可完成该类用户的认证，并且可以识别其可操作的业务类型。其参考XML配置如下：
<AllUserType>
<UserType>
<!-- 用户类型名 -->
<UserTypeName>LoginUser</UserTypeName>
<!-- 用户类型编号-->
<UserTypeID>1</UserTypeID>
<!-- 用户类型角色 -->
<RoleClass>com.allcom.Webframe.example.user.LoginUser</RoleClass>
<!-- 用户类型登录使用的认证器 -->
<ValidatorClass>com.allcom.Webframe.example.user.
RegisterValidator</ValidatorClass>
</UserType>
</AllUserType> |
该用户可操作的业务类型定义XML参考配置：
<LoginUserBusiness>
<-- 可用的业务ID -->
<BusinessType><BusinessID>1000</BusinessID></BusinessType>
<BusinessType><BusinessID>2000</BusinessID></BusinessType>
</LoginUserBusiness> |
◆ 额外的初始化插件接口提供其它任何需要的插件定义。只要实现该插件接口，就可向EAIF系统中加入任何需要的初始化插件信息。其在系统核心配置XML文件的参考配置如下：
<AllPlugInit>
<PlugInit>
<!-- 额外的初始化插件运行的类 -->
<class>com.allcom.Webframe.example.core.ExampleInit</class>
</PlugInit>
<PlugInit>
<class>com.allcom.Webframe.example.core.ExampleInit2</class>
</PlugInit>
</AllPlugInit> |
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
