IONA 是是业界领先的中间件平台供应商，为企业提供基于开放标准和组件结构的分布式计算技术。IONA 的软件产品支持对电子商务应用的开发、部署和管理，同时应用于其它各种大规模的分布式应用系统。IONA 的软件产品使各种异构系统间交换信息成为可能。其全球客户超过 4500 家，其中包括全球500 强中的大部分企业，以及在航空、金融、ISV、制造业、零售业和电信行业中的领先者。IONA Orbix E2A 电子业务平台－包括 Orbix E2A Web Services集成平台和 Orbix E2A 应用程序服务器平台，它能够实现信息流在各种异类系统和应用程序中的交互。这些平台协同工作为用户提供了一个单一的解决方案，该解决方案可以开发可靠的、可缩放的和安全的电子商务系统。

IONA (NASDAQ：IONA) 建立于 1991 年，总部设于爱尔兰都柏林、，美国总部设于麻萨诸塞州的沃尔瑟姆。公司有超过 850 名员工分布在全球 30 办公室。<0}有关 IONA 的详细信息，请访问我们的网站 http://www.iona.com

2   IONA Orbix E2A平台

E2A 是“ End 2 Anywhere™”的缩写。IONA坚信今天的开放系统必须对“Anywhere”开放，具有以任何形式和任何系统交互和协作的能力 。IONA 的核心能力是使用基于开放式标准的技术对不兼容软件系统进行完整业务集成。在过去的 10 多年中，IONA 以其基于标准的CORBA 和 J2EE 解决方案和产品环绕，建立了它的整个业务。利用 Orbix E2A，IONA 正将广泛的专门技术扩展到基于 Web Services标准的解决方案中。IONA 技术已在全球超过 4，500 家公司（诸如，Boeing、AT&T、Credit Suisse 和 NTT）中运行了大型关键任务系统。

Orbix E2A 是唯一能够解决所有级别的应用集成的解决方案。IONA的Orbix E2A，它包含基于标准的具有企业级QOS特性的应用以及Web Services所需的开发和部署工具。Orbix E2A 的核心包含两个主要产品：Orbix E2A 应用程序服务器平台和Orbix E2A Web Services集成平台。它们可以一起使用或者单独使用。

Orbix E2A 应用程序服务器平台是全球部署最为广泛的开发平台，用于要求最为苛刻的分布式应用程序，它结合了 CORBA 的可缩放性和 J2EE 高生产力。“应用服务器平台”是一个开发平台，它用于高度集成用 Java/J2EE、C++/CORBA、COBOL 或者 Visual Basic 开发的应用程序服务。他包含了世界上最强大的 CORBA 基础结构，最高效的 J2EE 服务器，和 Web Services标准，这些这些标准带有用于最流行的应用程序和技术的集成适配程序。Orbix E2A 应用程序服务器平台为可靠的、具有缩放性的和安全性的应用程序提供了所需的管理服务。

Orbix E2A应用程序服务器平台有三个版本：

²       Enterprise Edition（企业版）为开发者所设计，这些开发者需要一个单一企业部署平台用于面向服务的应用程序集成CORBA、J2EE、Microsoft NET 和主机环境，这些开发者也还须满足最苛刻的集成要求和分布式交互要求。

²       Standard Edition（标准版本）在一个集成的产品中，将 CORBA 企业应用程序的互操作性与 J2EE开发人员的可观生产力结合在了一起。其中包涵了潜在的 Web Services支持。Standard Edition（标准版本）是为构建和部署复杂的分布式系统的开发者设计，这些系统将现有 IT 投资与新的应用程序逻辑集成在一起。

²       J2EE Edition 是任何 J2EE 应用程序服务器中拥有最低成本的产品。除了灵活的许可条款，J2EE Edition 通过拥有一套完善的应用程序集成功能，以及将 EJB 暴露为 Web Services的内置支持，降低了开发和部署 J2EE 和 EJB 应用程序的成本。 

Orbix E2A Web Services集成平台是第一个可以用于关键业务流程的 Web Services集成平台。Web Services集成平台是在 Web Services标准和面向服务的结构的基础上构建的，因此减少了应用程序集成（防火墙内外）的成本。Web Services集成平台提供了实现可靠的、可缩放的和安全动态数据交换，业务流程自动化和复合应用程序所需的所有工具和管理服务。

Orbix E2A Web Services集成平台具有以下三个版本：

²       Collaborate Edition（协作版）是一个用于进行完整业务集成的单一平台，它为实现企业内外的流程协作提供了一套全面的集成解决方案。这一基于 Web Services的平台能够利用新旧集成标准，从而降低了应用程序的集成成本，并且确保了异类系统之间的完全操作性。

²  Partner Edition（合作伙伴版）提供了轻量级的 Web Services连接器，使客户可与已部署了 Collaborate Edition（协作版）的贸易合作伙伴无缝地协作。致力针对中小型企业，Partner Edition（合作伙伴版）允许贸易伙伴使用最少的开销安全地发送、接收和响应业务通讯。

²  XMLBus Edition 是轻量级的 Web Services集成平台，它是针对那些希望用纯粹的 Web Services方式进行集成的开发人员。这是一个入门级的解决方案，它能够使开发人员轻松地实现、部署、保护、访问、检测、集成并管理基于标准的 Web Services。

3    应用案例：移动BOSS改造工程

3.1      移动BOSS改造工程项目概述

根据对移动BOSS改造工程项目的目标理解和需求分析，系统方案力求使系统能够最大限度地满足用户不断增长和变化的业务需求，也使用户能够在最大限度保护其投资的前提下不断利用迅速发展中的IT技术和产品，同时使数据中心及各业务系统同服务器系统、存贮系统及网络系统方案相结合，实现最优的性能，确保用户的业务顺利实施及发展。

改造BOSS的意义并不是简单的对现有系统进行扩容，而是为企业建立统一的数据规范和信息系统的逻辑框架，对现有的业务系统进行改造和整合，为将来的新增业务与原有的应用系统的结合建立规范和标准，时力科技提供的解决方案是基于以下原则设计的：

² 标准化的技术和业务规范；

² 极高的安全性和可靠性；

² 良好的扩充及扩展能力；

² 优越的开放性；

² 高可管理性和可维护性；

² 高可用性和实用性。

根据移动BOSS改造工程项目的需求和以上的设计原则，该解决方案是以移动数据中心为核心，为移动运营各业务系统提供建设和运行的应用集成平台，实现计费平台、客户管理平台等业务框架平台的有效集成和各移动业务应用系统的有效整合，并具有极强的可扩展能力。

下面是移动BOSS 建设方案的系统功能层次结构图：

由于For-MDC不仅可以最大限度地协调和整合移动运营各项业务系统中的用户数据和业务信息，而且能够将各个业务系统有机地整合成一个综合业务处理系统，实现数据共享和业务信息的统一，因此通过基于For-MDC建立计费平台和客户管理平台可以提高业务支撑系统的可扩展性，可维护性和对新业务需求的可适应性，并可降低运营成本。

通过在For-MDC上建设统一的计费平台，即可实现语音、数据、增值服务等不同运营业务的统一计费、统一管理、与统一结算，可极大的简化计费处理流程。通过统一话单格式、费率管理引擎等技术，可以对不同类型的业务、不同的计费方式、各种优惠策略和话费套餐等提供全面、快速的支持。

由于For-MDC具有强大的客户数据整合和管理能力并使之与各业务系统形成统一的接口，因此，在For-MDC数据中心上建立统一的客户管理平台，可实现移动公司的服务渠道、商业运作过程和客户数据挖掘与管理的高度集中统一与实时处理，真正实现CRM“以客户为中心”的实时高效的服务机制，并使得对用户数据、业务信息的挖掘和分析变得更加深入、简单和有效，使决策支持系统和客户服务系统得到深入的实际应用，为各项移动业务的改进和完善提供最切实的依据。同时，通过采用数据挖掘和商业智能等技术，在For-MDC基础上建立的客户管理平台保证了为未来业务的扩展提供最快的市场预测能力与反应能力，极大地增强移动公司在日益开放的移动通信市场中的竞争优势。

移动BOSS建设方案是按满足移动业务发展到601万用户时处理能力和业务量的需求而设计的，同时还具有很强的扩充能力。该系统的设计采用了国际上最先进的系统结构和应用模式；具有计算机信息技术发展和移动通信业务发展双重的前瞻性，完全适应今后移动通信业务发展的需要。

移动BOSS的各业务系统是基于统一的应用集成平台建设的，业务系统包括计费、营业、帐务、决策支持、客户服务等业务系统，应用集成平台采用了基于B/S处理方式的三层应用处理模型，并在业务平台之上采用业务组件的构造方式来开发和集成各业务系统。应用处理模型三层结构的划分，简化了业务处理逻辑；这种方式能更好地控制业务处理，极大地简化了应用业务变更的实现，同时也使应用系统扩充变得非常容易，避免了传统的应用系统结构的弊病----对某个业务或功能的调整会影响到其它的业务或功能。因此这种应用处理模型能够适应将来的快速变化的业务调整和新业务的推出。 

移动BOSS的建设方案完全遵循中国移动通信集团公司制订的《中国移动业务运营支撑系统（BOSS）业务规范1.0版》和《中国移动业务运营支撑系统（BOSS）技术规范1.0版》等全部技术及业务规范，业务的应用逻辑结构按照三层结构进行设计，包括：数据核心层、业务逻辑层和接入层。下图是基于For-MDC的移动业务系统框架图：

3.2  For-MDC (Mobile Data Center) 移动应用集成平台概述

3.2.1 系统概述

移动经过多年的努力，已分期建设了营业、计费、帐务管理、银行代收费、高额监测、信用度管理、客户服务、BMCC门户网站、移动网管、办公自动化等多个业务系统。这些系统对支撑移动业务的正常运营，起到了巨大的作用。

随着移动业务的飞速发展，技术的不断进步，市场竞争的不断加剧，迫切需要将这些分期建设的业务系统有效地整合起来，达到用户、数据、系统资源共享，以实现提高服务水平、管理水平和经营决策水平，为客户提供及时、准确和高质量的服务。为此，时力科技总结了多年在移动行业的开发经验，采用当前国际上通信和IT行业的最新技术，以业界领先的Orbix E2A 应用服务器平台为基础，构建了For-MDC (Mobile Data Center) 移动应用集成平台。

For-MDC通过Orbix E2A 的CORBA软件总线和统一的数据服务接口提供可扩展的应用集成平台，并提供全面的系统管理，将计算资源整合到一个集中管理，综合控制的环境中，实现安全、高效率、低成本的运营。For-MDC为各业务系统提供建设和运行的平台。

For-MDC采用了以Orbix E2A 的CORBA/J2EE组件为基础的中间件产品，是专为分布式应用提出的一个解决方案。一个分布式计算系统由运行在多种计算机平台上的多种软件组件构成，它们表现得如同一个单一的功能强大的大型系统。通过该种办法，可以充分利用所有平台的长处，并继承了基于网络的系统的弹性。

在分布式对象计算环境中，为了能使不同来源的对象能够协调合作，必须遵守共同的CORBA规范。CORBA全称是公共对象请求代理结构（Common Object Request Broker Architecture）。它是由对象管理组织（OMG）定义的，这个组织由代表了整个计算机工业的600多家公司组成。

定义于TCP/IP 之上的IIOP（Internet Inter-ORB（对象请求代理）协议）是保证对象间互操作的必要的通信协议。其中的一个关键核心是ORB（Object Request Broker）。ORB是对象总线，它可以保证对象之间的通信，无论这些对象是位于同一台机器上，还是位于通过网络连接起来的不同的机器上。目前市场上有许多商用的ORB，在For-MDC解决方案中，我们选用了IONA公司的Orbix E2A 作为我们的CORBA平台，Orbix是目前世界上最成熟和市场份额最大的CORBA平台。

For-MDC特点

For-MDC具有以下特点：

1、全面支持移动的各种运营业务

¨         话音业务

²       GSM

²       神州行

²       3G

²       其它

¨         数据业务

²       移动互联网业务

²       手机上网（含WAP上网）、 固定用户上网、专线用户上网， IP电话、虚拟专用网（VPN/VPDN）、GPRS、VoIP

²       移动梦网

2．支持建设所有的移动业务系统

²       数据采集

²       计费

²       业务管理

²       客户服务

²       综合帐务

²       结算

²       决策支持

²       其它

3、完全符合中国移动的BOSS规范

符合中国移动通信集团公司对BOSS的体系结构、网络结构、应用软件结构、系统软硬件、外部接口及安全管理等的基本技术要求，业务系统的建设遵循三层结构的原则。

4、全面采用国际技术标准

²       CORBA规范

²       J2EE标准

²       Web Services标准

²       ANSI /ISO SQL数据处理技术

   ²  TCP/IP网络协议

3.2.2  For-MDC结构及功能

 For-MDC结构图

根据中国移动通信集团公司《中国移动业务运营支撑系统（BOSS）业务规范》的要求，以及时力科技对移动业务的理解，考虑到目前的业务规模和今后的业务发展，并考察和研究了当今移动通信和IT行业的主流的、最先进的技术，提出基于FOR-MDC的移动应用解决方案，如图所示：

3.2.3  For-MDC结构说明

前端用户对各种业务系统的访问、操作是通过浏览器来实现的，这样，用户不但可以用运行于PC机上的浏览器来完成对各种业务的操作，今后也可以通过PDA、WAP手机以及其他上网设备来实现相同的工作，实现Anytime、Anywhere的移动式办公（M-Business）。

用户前端通过浏览器调用JSP页面，将相应的用户请求信息发送给Web服务器，Web服务器主要将用户的请求信息转发给Orbix E2A J2EE用服务器中的Java Servlet或者EJB建构的CORBA客户程序。另外，Web服务器还把应用服务器运行这些程序获得的结果（包括各种异常的处理信息），生成动态的HTML回传给用户。

在应用服务器内体现出当今先进的J2EE技术和CORBA 技术的结合。每一业务应用被当成是一个CORBA对象来看待，各个业务应用的操作被抽象成一些特定的CORBA对象的操作（Operation）、服务（如Naming Service，Trading Service，Event Service，Factory Service等），通过这些功能，CORBA的各个对象之间可以实现互访、资源共享，实现负载均衡，这样，CORBA 还可以使业务系统利用同一种规范，使分散的各个业务部分统一起来，提高了代码的重用性、扩展性，使业务系统的更新和添加，即插即用（Plug & Play），只需依照一定OMG的规范编写对CORBA-ORB的适配（Adapter）程序即可实现对各个系统的访问，整个系统如同有一个由CORBA统一起来的软件总线。因此，对各个业务系统的操作、访问，由应用服务器上的Servlet Java Corba Client程序将请求发到CORBA软件总线上，并由相应的业务应用适配器，获得运行于相应业务服务器上的业务逻辑的运行结果。同时，CORBA技术的开放式的设计为将来新的业务的接入提供了无限的扩展性。各种Internet技术的高速发展，使得Web服务器从简单的HTTP服务器到Web应用服务器的进化成为必然。通过Web应用服务器，应用CORBA技术，可以让任何客户通过权限确认后，访问存放在各种系统中的各种类型的信息，并通过已有的，应用的适配器 (Adapters)和Java运行环境，可以实现各个应用方便连接。

3.2.4  基于CORBA的软件总线

软件总线是指系统定义了一组接口规范，任何应用程序、软件系统或工具只要具有与该接口规范相符合的接口定义，就能方便地集成到系统中，而这个接口规范独立于任何实现语言和环境。应用软件或构件能够在“软件总线”（Software Bus）之上实现“即插即用”（Plug & Play）。

OMA参考模型从总体上抽象地描述了OMG组织推出的面向对象技术所包含的内容，以及模型中各组成部分之间的关系。OMA参考模型如下图所示：

OMA体系结构由五部分组成：

²       对象请求代理ORB（Object Request Broker）

负责对象在分布环境中透明地收发请求和响应，它是构建分布对象应用、在异构或同构环境下实现应用间互操作的基础。

²       对象服务（Object Services）

是为使用和实现对象而提供的基本服务集合。在构建任何分布应用时，经常会用到这些服务，而且这些服务独立于应用领域。例如生命周期服务定义了对象的创建、删除、拷贝和移动的方法，但是它并不指明在应用中如何实现这些对象。

针对对象服务，OMG组织制订了CORBA服务（CORBA Services： Common Object Services Specification）规范，简称为COSS规范。COSS规范由一组接口（Interface）和服务行为描述构成，其接口一般使用OMG IDL语言描述。目前的COSS规范主要包括以下内容：名录服务（Naming Service）、事件服务（Event Service）、永久对象服务（Persistent Object Service）、生命周期服务（Life Cycle Service）、并行控制服务（Concurrency Control Service）、外部化服务（Externalization Service）、关系服务（Relationship Service）、事务服务（Transaction Service）、查询服务（Query Service）、许可证服务（Licensing Service）、特征服务（Property Service）、时间服务（Time Service）、交易服务（Trading Service）、和安全服务（Security Service）。由此可见，COSS规范几乎包含了分布系统和面向对象系统的各个方面，它的每个组成部分也都非常复杂和全面。

²       公共设施（Common Facilities）

是向终端用户应用提供的一组共享服务接口，但这组服务不像对象服务那样基本。例如系统管理、组合文档和电子邮件服务就可以归入公共设施中。

²       应用接口（Application Interfaces）

是由销售商提供的、可控制其接口的产品，它相应于传统的应用表示。因此OMG组织不对它们做标准化工作。应用接口处于参考模型的最高层。

²       领域接口（Domain Interfaces）

是为应用领域服务而提供的接口。例如，现在OMG组织为PDM（Product Data Management，产品数据管理）应用制订了规范，在该规范中定义了8个使能器，描述了12个功能模块及其接口，明确了PDM系统内部以及PDM系统与其应用系统之间交互的方式。

CORBA规范是针对OMA参考模型中的对象请求代理ORB而制订的。CORBA规范定义了IDL语言（Interface Definition Language， 接口定义语言）及映射、单个ORB和ORB间互操作机制。随着CORBA规范版本的升级，其内容也不断丰富。单个ORB的体系结构如图所示。

在该体系结构中，描述了以下主要的内容：

IDL语言通过说明对象的接口来定义对象。一个接口包括一组命名的操作和相应于这些操作的参数。注意，虽然IDL语言提供了用于描述被ORB操纵的对象的概念框架，但是ORB在运行时并不需要IDL源代码。只要在例程或者运行状态下接口库中的等价信息是可用的，ORB就能通过特定的方式正确地完成其功能。IDL语言实质上提供了一种手段，通过它，特定的对象实现就能告诉客户哪些操作是可用的，并且应该如何激活这些操作。IDL语言是一种描述性语言，客户要能真正使用IDL源文件中所定义的对象，必须把这些对象映射到指定的程序设计语言实现的对象。这部分工作由IDL编译器完成。OMG IDL语言的语法类似于C++。CORBA规范中定义了OMG IDL语言到具体编程语言的映射，包括OMG IDL语言到C、C++、Small Talk、Java和COBOL等语言的映射。

ORB核心提供了客户一对象实现之间实现透明通信的方法，它可以屏蔽对象实现位置、实现方式、状态和通信机制等细节以及不同实现间可能存在的差异。

对象适配器位于ORB核心和对象实现之间，它负责服务对象的注册、对象引用的创建和解释、对象实现的服务进程的激活和去活、对象实现的激活和去活以及客户请求的分发。

IDL桩为客户提供了静态调用方式，IDL构架为客户提供了静态实现方式。IDL编译器编译描述服务对象接口的IDL文件，生成对应于具体编程语言的IDL 桩和IDL构架程序。IDL桩负责把用户的请求进行编码，发送到对象实现端，并对接收到的处理结果进行解释，把结果或异常信息返回给用户；IDL构架对用户请求进行解码，定位所请求对象的方法，执行该方法，并把执行结果或异常信息编码后发送回客户。

动态调用接口DII（Dynamic Invocation Interface）和动态构架接口DSI（Dynamic Skeleton Interface）提供了动态调用方式和动态实现方式。某些情况下客户预先不知道服务对象的接口信息，需要通过查询或者采用其他的手段获得服务对象的接口描述信息，然后使用DII动态调用ORB核心接口的方法来构造客户请求并发送到对象实现。在对象实现方可以使用DSI动态分发用户请求的机制，以便动态地处理客户方的请求。

客户和对象实现所采用的方式并不一定要一一对应，也就是说，客户方支持的静态和动态两种调用方式，对象实现方支持的静态和动态两种实现方式，经过组合后得到的四种方式都可能出现。例如，客户方可能使用静态调用方式，而对象实现方使用动态构架接口，反之亦然。

在动态方式下，需要查询相应的服务对象的接口描述信息（在静态方式下，这些信息由IDL文件来描述），这些信息由接口库提供。接口库通常以IDL描述文件为其输入，将接口描述信息进行处理后存放在文件、数据库或者其他形式的存储机制中，并提供一组标准的调用接口供客户查询使用。服务对象实现的描述信息也由接口库提供。

CORBA规范还为不同厂商ORB系统之间实现互操作制订了规范。它定义了GIOP（General Inter-ORB Protocol，通用ORB间通信协议），对数据编码的格式、消息格式和对传输协议的要求都做出了详细的规定。由于GIOP是一个抽象的协议，安必须映射到具体的传输协议和传输机制中去，CORBA支持GIOP到TCP / IP协议（Internet Inter-ORB Protocol，简称IIOP）的映射。

CORBA的技术特点：

引入了代理（Broker）的概念。一个代理至少可以有三个方面的作用：完成对客户方提出的抽象服务请求的映射；自动发现和寻找服务器；自动设定路由，实现到服务器方的执行。这样，用户在编制客户方程序时就可以避免了解过多的细节，而只要完整地定义和说明客户需要完成的任务和目标。

用代理来处理客户/服务器模式环境下应用或者应用系统之间交互的信息，称为请求（Requests）和响应（Response）。代理根据客户方的请求，选择一个或若干个服务器进行处理，使客户方无需考虑服务器方的处理细节，只需最后把服务器处理的结果作为对客户方请求的响应通知客户。客户方和服务器方相互独立无关，使得软件易于修改、移植和维护。

所实现的客户方程序与服务器方程序的完全分离。这与以面向过程调用机制为基础的客户/服务器模式存在着很大的不同。客户将不再同服务器发生直接的联系，而仅仅需要同代理进行交互。客户与服务器之间就可以有更加灵活的关系存在。在调用方式保持不变的前提下，服务器可以自由地修改或者升级，客户方程序也可以自由地按照要求进行更改，而无需通知对方。

将分布计算同面向对象的概念相互结合。这样，可以提高软件重用率、控制冗余度等，由此带来诸多好处。

提供了软件总线的机制。所谓软件总线是指CORBA系统定义了一组接口规范，任何应用程序、软件系统或工具只要具有与该接口规范相符合的接口定义，就能方便地集成到CORBA系统中，而这个接口规范独立于任何实现语言和环境。也就是说，CORBA规范支持服务对象的位置透明性、实现透明性、执行状态透明性和通信机制透明性，只要按照OMG IDL接口描述语言对服务对象所提供的服务进行描述，客户应用和服务对象之间就可以透明地交互运行。应用软件或构件能够在“软件总线”（Software Bus）之上实现“即插即通”（Plug & Play）。

分层的设计原则和实现方式。CORBA规范仅定义了ORB中需要用到的基本对象，封装了相应的属性和方法。而面向应用的对象定义则可以在OMA的应用对象、领域对象或应用开发环境中逐步分层定义和实现，使CORBA系统核心始终是一个精炼的实体，而各种复杂功能和应用可以由核心扩展和延伸。

CORBA规范充分利用了现今各种技术发展的最新成果，将面向对象的概念应用到分布计算中，定义了一组与实现无关的接口方式，引入代理机制分离客户和服务器，使得CORBA规范成为开放的、基于客户/服务器模式的、面向对象的分布计算的工业标准。

3.3 应用软件的实现

3.3.1 功能划分

基于CORBA总线的移动BOSS的总体实现抽象结构如图所示。

最上层是移动的业务子系统，包括计费结算模块、客户服务模块、业务模块、帐务模块和数据管理模块，分别由不同的业务组件构成，完成移动BOSS的具体功能。第二层是业务组件层，包括采集组件、计费组件、接口组件、漫游结算组件、网间结算组件、帐务处理模块、系统管理模块、帐务管理组件、业务管理组件、客户服务组件、数据管理组件、系统运行监控组件和统计报表组件，它们实现移动业务的普遍功能，是时力公司移动应用集成平台For-MDC的组件构成，对它们进行不同的参数化将实现不同的应用子系统功能。它们与移动应用子系统的对应关系如表所示。在组件层下面是应用服务对象和中间件层，它们提供业务组件在CORBA总线上的具体实现机制。每个业务组件由若干个CORBA对象组成，向其他组件提供CORBA服务。

移动BOSS的总体实现抽象结构：

3.3.2  IONA Orbix E2A 平台的应用：

整个系统的配置如图所示：

1．计费结算模块：

主要实现帐务计算功能，部署采用IONA Orbix E2A  标准版，通过CORBA调用和其他业务系统相联系。 

2．中间件层：

包括三部分：

a)中间件层-业务组件系统：运行主要的业务组件。采用IONA Orbix E2A  企业版，系统基于CORBA。

系统由两部分组成：

业务逻辑部分：由多个基于POA的CORBA业务逻辑对象构成，封装了所有的业务逻辑和数据库访问逻辑，采用C++编程语言。多个POA组成服务器群集，从而提供负载均衡和容错支持。数据库访问逻辑采用Pro*C，JDBC等。 

基础服务部分：提供基本的CORBA服务，包括Locator，Naming，CFR服务。CFR服务提供了全局所有CORBA应用程序的配置信息。Naming提供了全局所有CORBA对象的命名服务。Locator提供了全局所有持久CORBA对象的定位服务。这些服务均为关键服务，所以必须提供容错措施，通过建立Replia Domain（复制域）的方式进行服务的复制，将基本的CORBA服务的副本运行在另一台物理服务器上，复制的服务之间通过Master/Slaver方式同步数据，从而消除了系统的单点失败，并且提高了系统性能。 

b)中间件层-银行系统：实现和银行接口业务的接口。根据系统需求，采用IONA Orbix E2A  企业版（如果需要负载均衡和容错功能）和IONA Orbix E2A  标准版。系统基于CORBA，可以将不同协议（如TCP/TP，MQ，IIOP）的银行接口程序用CORBA进行封装，通过CORBA调用和业务系统相连。 

c)中间件层-客户服务接口：用户通过前台营业厅浏览器界面查询客户信息。

采用IONA Orbix E2A  标准版和IONA Orbix E2A J2EE版。Servlet或EJB程序作为客户程序从ORB软件总线获取数据，并将数据组织成标准的XML格式交给XML解释器，同时指定XSL模板文件，XML解释器将解释后的数据（HTML格式）交回给Servlet程序，Servlet将其打印输出到IE浏览器。或者Servlet程序从浏览器处采集用户输入数据，加工后交给ORB软件总线处理。

IONA Orbix E2A  标准版和IONA Orbix E2A J2EE版所包含的J2EE服务器和XMLBus接口提供基于xml的服务，XMLBus接口提供了将CORBA IDL 接口封装成Web Service的能力，从而提供了对各系统Web Service访问的最直接方案。

3.3.3  性能和可扩展性方面的要求

考虑系统的用户容量，系统需要很强的可扩展性。Orbix E2A CORBA服务器具有良好的性能扩展能力，主要体现在如下的方面：

1．对容纳大量的客户机和服务器的可扩展性

在许多 CORBA 系统中，主要的资源瓶颈是可供进程使用的 TCP/IP 套接字连接数量有限。Orbix E2A CORBA 提供了活动连接管理，从而能够收回空闲的连接并将它们重新分配供当前使用。如果重新需要回收的连接，将自动并透明的重新建立该连接，这种管理完全是基于配置的，可以灵活修改，与程序编码无关。

2．对大量对象的可扩展性

可移植对象适配器 (POA) 为包含大量对象的服务器提供了很高的可缩放性。POA的不同设计模式能够实现复杂的对象缓存，或只使用一个已装入内存的对象来代表数据库中的众多 CORBA 对象。Orbix E2A CORBA 使用复杂的内存管理技术，其中包括“flyweight”设计模式以避免复制对象引用中的相同部分，节省了内存，从而更适合大规模的对象引用数目。

3．对多线程应用程序的支持

Orbix E2A CORBA服务器为多线程应用程序提供了出色的支持。Orbix E2A CORBA服务器 库是多线程的，并且具有线程安全性。Orbix E2A CORBA服务器 提供标准的 POA 策略来启用服务器中的多线程操作。ORB 创建了一个线程池，它会根据所需的负载进行缩放。无需任何编码就可以通过配置的设置控制线程池大小、增长和请求队列。

Orbix E2A CORBA服务器 包括了一个面向对象的线程同步可移植库，它允许用户编写可移植多线程代码。这个库只是每个平台上本地线程接口之上的一个层，所以不存在与直接使用本地接口的其它可移植库或应用程序的冲突。

4．通过服务器群集来均衡负载

Orbix E2A 企业版CORBA服务器最为强大功能之一是它的服务器群集结构服，通过服务器群集平衡负载，透明的将客户定位到不同的服务器上。服务器群集结构使Orbix E2A 企业版CORBA服务器具有无穷的可扩展性，可以通过在中间件层-营收系统中增加Server的数目来提供线性增长的性能提升。

而且Orbix E2A 企业版CORBA服务器的服务器群集结构完全基于POA，配置简单，可以根据系统的要求建立多个逻辑上的群集，可以自由的在运行时动态改动群集的结构而不影响系统的连续运行。

总之，在单服务器级别上，Orbix E2A CORBA服务器 通过开发时设计良好的POA对象服务程序模式，运行时合理的配置连接管理和线索管理参数来提供高性能。而在多服务器级别，Orbix E2A CORBA服务器通过服务器群集结构实现负载均衡和性能扩展。有了这些高级的特性，Orbix E2A CORBA服务器完全能够胜任任何对性能的要求。

3.3.4  高可用性方面的要求

Orbix E2A 企业版CORBA服务器通过服务器群集提供了高可用性保障，极大地提高了系统的可靠性。

建立可靠系统的关键是确保没有单一故障点，即不会发生单一资源的故障导致整个系统崩溃的情况。服务器群集允许用户使用多台服务器为应用程序提供服务，所以它消除了单一故障点。

对于应用程序，服务器群集能够动态地监控群集中各服务器的状态，当一个服务器应用程序发生故障时，系统透明将请求定位到群集中的另一个服务器。

对于核心的系统服务，Locator，Naming，CFR服务，采用复制的方式建立群集，消除了单一故障点。

总之，Orbix E2A 企业版CORBA服务器通过基于POA的应用对象群集和对系统服务的基础群集两种方式保证了系统的高可用性，并且使群集系统的配置简单而灵活，可以在运行时进行动态的调整。