IONA iPortal 应用服务器构架

一起学习

(by huihoo.com fat1 , Allen 整理)

总论：以Java 技术为基础的J2EE构架为企业提供了一个快速构造大型，可伸缩的，分布式的电子商务框架。其中应用服务器作为该构架的支撑基础，将一个应用从Web服务器和数据库中分离出来，为处理大量的用户与事务提供了一个更为构架化更为完美的解决方案。目前应用服务器市场异常活跃，出现了很多优秀的产品。

iPortal 应用服务器是世界著名厂商IONA公司推出的J2EE应用服务器，该应用服务器以IONA’s的ART和POA技术为基础，提供了一个伸缩性能非常好的容器。该容器具有部署界面，允许进行热部署和热重配，能够真正实现24x7工作。iPortal 应用服务器的独特构架使得EJB容器和Web容器可以被充分分布到多台机器上，消除了应用的瓶颈。由于它严格遵守规范和标准，保护了用户的投资。而且它具有与Unix 和大型主机系统的充分交互能力。本文从技术的角度对iPortal 应用服务器的构架作了概括性的介绍。

1. 什么是POA?

iPortal 应用服务器基于 orbix 2000 和 orbix 2000 for Java，这两种产品都是 CORBA2.3 的ORBs（对象请求代理），在CORBA2.3中和应用服务器有关系的一个方面是POA（Portable Object Adapter） 即可移植对象适配器。在CORBA规范中，对象适配器是服务器端的组件，它负责创建对象参考（reference）（对象参考是要公布给客户端的）也负责将直接的CORBA调用传到服务器端的合适的对象或服务提供者（在iPortal 应用服务器中，所有的服务提供者都是Java对象）。

POA是在CORBA2.3规范中提出的以取代基本对象适配器BOA（Basic Object Adapter），这是因为BOA在CORBA服务器中不易在ORBs之间移植。尽管CORBA 服务器端的移植性与应用服务器关系不大。POA在应用服务器上的应用的最主要的好处是它提供了很大的灵活性：可以将抽象的CORBA对象映射成JAVA 对象，并且能控制资源的利用和Java对象的生命周期。

每一个CORBA服务器可以有多个POAs，每一个POA可以提供不同的功能或者支持不同的特性。而且每个POA都提供一个独立的对象生存空间，相应有一套POA策略来决定这些寄存的对象如何被激活以及如何建立对象的参考。POA策略是相当复杂的。然而，IONA使用了一种叫做服务定位器（ServantLocator）的策略，这是POA策略中最具有伸缩性的。

2. 什么是ART?

ART（Adaptive Runtime Technology）是IONA的分布式对象构架，它是iPortal应用服务器的基础。ART的设计目标是使客户能够根据要求定制产品。在Orbix 的前一个版本中将所有的功能都放在一个很大的单一的库中。因此客户不可能通过修改来配置不同的需要，这样使得只有IONA才能修改Orbix，但甚至是ION也很难做出修改，因为库中所有的东西都纠缠在一起。

ART的绝大部分功能被设计成插件的形式：例如POAs，传输协议，加密和认证机制，日志和数据库存储。ART的构架和它的插件见图1。 在运行时，ART根据服务器的配置文件装入一些插件。这有点像EJB的声明式编程（Declarative Programing）。一些插件可以在启动时装载，而另外一些在运行时根据应用程序的要求装载。这使得IONA具有很大的灵活性，因为可以根据应用服务器的需要选择特定的功能模块，根据需要配置适当的容器大小，这样使容器既小又高效。

插件是一个代码库，可以在联接或运行时被装载，好象Widows中的DLL。插件可以包含任何类型的代码，但是它包含的对象要通过在运行中的ORB 中注册来增加功能。插件可以直接地与应用程序联接，在启动时装载，也可以在运行时根据应用服务器的要求装载。ART插件的接口在CORBA的接口定义语言（IDL）中定义，因此整个插件的构架独立于编程语言。定制插件的例子包括：在ATM上用GIOP协议取代缺省的IIOP协议，用建立在内部安全系统之上的安全机制代替缺省的安全机制。


图1,ART内部构架

因为ART的特性是配置在应用程序中，而不是和它编译在一起，因此就有可能不需要通过重写或重编译应用程序而改变应用服务器的外观和功能。

ART在启动时要装载哪些插件取决于配置文件。而且这些配置文件的改变也可以在运行时被ART感觉到。这样，新的插件通过适当地改变配置而被装载。这种机制允许不改变和重新编译代码而更新应用服务器。

许多分布式对象系统中一个关键的资源瓶颈是TCP/IP socket连接。ART提供了一个动态连接管理，使用“最近最少使用”算法回收空闲的socket连接，分配给其它进程使用。如果回收的连接又要求使用，它可以被自动地，透明地重新建立起来。ART还使用了一种复杂的内存管理技术包括“轻量级（Flyweight）”模式来避免重复的公共对象参考组件。每个单一的地址信息只在内存中存放一次，而由所有用到的对象参考共享。

3. 使用ART和POA构建iPortal 应用服务器

5.1 EJB容器

iPortal 应用服务器中的每个EJB服务器都是一个CORBA服务器进程，一台主机可以有多个CORBA服务器。所有的EJB服务器都存在于一个域中并由一个定位器守护线程管理。每个系统中只有一个定位器守护线程，它可以感知到所在域的所有容器，即使这些容器在不同的主机上。守护线程可以被复制以防止单点失败。

iPortal 应用服务器中的容器是通过POAs的层次构架建立的。一个CORBA服务器可以包含多个根POA，每个根POA可以有多个子POAs，如图2所示。

iPortal 应用服务器中的POA表示容器，一个EJB服务器中可以有多个容器。容器中的子POA表示EJB的bean类型。如图3所示。因为CORBA服务器中可以有多个根POAs，相应地每个EJB服务器可以有多个EJB容器。下面的问题是POA怎样采取不同的策略来决定客户的请求被映射到相应的服务提供者。此外，一个特定的POA可以有多个子POAs。所有这些特点都用在iPortal 应用服务器中的容器设计中。容器中的每个子POAs表示一个EJB类型。事实上，有两种POAs分别表示Home 对象和Remote对象。例如在一个容器中我们可以有20个货车beans，30个订单beans。在这种情况下，容器中只需要4个POAs，每种bean有两个（分别表示Home 对象和Remote对象）。


图2 在CORBA2.3中的根POAs 和子POAs


图3 EJB服务器中的容器和bean类型

在iPortal 应用服务器中，容器和应用程序之间是一对一的关系，但是在安装时需要建立另外一个新的容器来装载应用程序。

3.1.1服务定位器

EJB中，客户端不能直接访问beans。而是通过和home对象及remote对象的通讯来访问，这两种对象由容器创建，代表系统中的bean。图4表示了这种机制，根据EJB1.1规范，客户端通常得到一个bean的参考。


图4 EJB 中Home, Remote接口和bean之间的关系

如前所述，iPortal 应用服务器使用“POA服务定位器”策略。POA为客户端的请求选择一个服务。这样我们在内存中就看不到EJBObjects对象。它们的位置被POA取代。

大多数应用服务器中有一张表来存放主健和对象实例的映射。这样，当一个请求到达时，容器根据健值来查找该表以获得bean实例。当beans数量很多时。这样的操作要花费昂贵的代价。iPortal 应用服务器通过将对象的ID 编码进对象句柄取代了这种方式。这样，当一个请求到达时，POA利用对象ID来识别对象，把请求传递给Bean实例。

3.1.2 iPortal 应用服务器消除了CORBA的骨架和编译生成的容器代码

使用iPortal 应用服务器开发的用户将会注意到他们不必要生成容器代码，也就不需要编译并将其包含在jar包中（该jar包要被部署在容器中），jar文件中只需要包括bean实例的Java类，home接口，remote接口，ejb-jar.xml 部署描述符。这是因为iPortal 应用服务器消除了骨架和生成的容器代码（这些文件通常要包含在jar包中）。骨架代码负责传输协议（例如IIOP），实现容器提供的服务，例如事务，持久性和安全。取代CORBA骨架的是Java映射，它负责从IIOP流中识别参数而不必使用特定的对象骨架。取代容器代码的是ART的“侦听链”，它负责实现事务，安全，和容器的环境设置。所有这些都被抽取出来放在一个单独的插件中。侦听链在ART运行时装载来处理正确的事务，安全和方法调用的环境。例如，事务侦听器检查目标bean的部署文件的事务属性。如果需要，一个事务上下文就加入到消息中，或者开始一个新的事务。

这种构架的一个优点是：因为侦听器以插件的形式存在，你可以定制一个而用它取代由IONA提供的缺省的插件。而且，这一切还可以在应用程序运行时进行。

3.1.3 分布和对象定位

应用程序服务器有不同的对象分布机制其中RMI/JRMP和RMI/IIOP是最常用的两种，每一种机制都提供了一种客户端访问服务器中对象的方式。 有些机制，例如RMI/JRMP将IP地址和目标服务器的端口一起编码到对象参考中。如果对象保留在同一个位置这没什么问题，但是如果我们想升级到一个更高性能的服务器上怎么不办？因为服务器的IP地址发生了变化，所有客户端的对象参考失效客户端必须重新通过JNDI刷新对象参考。这显然不是理想的方式。

另一个常用的方式是“集中器”来管理服务器的访问。图5示例了一个使用集中器的应用服务器构架，在这个构架里，每个调用都要通过集中器，这种间接方式降低了响应速度。


图5，集中器构架

IONA’s的ART，克服了上述两种构架的缺陷：只有第一次的调用通过定位器。之后就在客户端和容器之间建立了连接，以后的客户端调用就可以通过这个连接和容器直接联系。如图6所示。


图6,ART定位器

其次，定位器被设计成支持复杂的“位置透明”，位置透明意味者客户端不需要知道服务器的位置。IONA的定位器允许客户端独立于服务器位置的移动。这一点是通过避免将IP地址和目标服务器的端口一起编码到对象参考中做到的。取而代之的是IONA将定位器的IP地址和对象所在的容器的名称包含在对象参考中，定位器能够根据名称来确定容器的地址。如果容器在服务器端进行了移动，定位器会得到这个信息。相应的流程如下：

客户端的第一次调用请求通过定位器，定位器从对象参考中抽取目标容器的名称，进而找出目标容器的地址，并且建立了一条从客户端到容器的直接连接。以后客户端和容器的通讯都通过该连接。如果服务器的位置发生了移动，定位器得到这个信息。如果客户端的下次调用请求仍然通过原来的连接将会失败，客户端于是再次发送请求，这次的请求将通过定位器，由于定位器已经知道并且更新了容器名称和新的容器位置的映射，于是就会重新建立起一条从客户端到容器的直接连接。通过这种方式，服务器和客户都不需要其它的命名服务或JNDI。该流程如图7所示。


图7 定位器使得应用程序移植透明

5.1 Web容器和“超级servlets”

Web容器和EJB容器都是J2EE构架的主要组成部分，web容器包括JSP 引擎，Servlet引擎和一个web服务器。传统的做法是将这几部分包装在一起放在一个JVM（Java虚拟机）里。Servlet和JSPs与web服务器在一个进程空间中执行，因此工作不能被分布到多台机器上去。造成了web应用的瓶颈。

一个更具有伸缩性的web容器构架是将JSP引擎和Servlet引擎从web主机上移走，根据需要分布在别的地方。利用这种方法，一个请求如果是要求特定的JSP程序处理，它将被web服务器传递到远端的JSP引擎去处理（也许该JSP还要调用EJB），在JSP执行时，web服务器还可以处理下一个客户请求（该请求有可能被传到另外一个JSP引擎去处理），等等。从效果上看，web服务器和JSP引擎在并行执行，充分利用了多台机器的能力。如果web服务器和JSP引擎在同一个进程空间，这种情况不可能发生，即使利用多线程也不行。


图8 Web容器中的超级servlets 构架

4. 动态容器构架

4.1作为Bean-Managed 的实体Beans的容器

iPortal 应用服务器的容器基于POA 的层次构架，根POA表示容器，子POA表示不同的bean类型和它们的Home接口及Remote接口。每个容器包含一个Bean-Managed 的实体Bean，该实体Bean的接口声明为公有的，接口对应的方法允许用户执行以下功能：

l 不需要停止服务器就可安装应用程序。
l 不需要停止服务器就可配置应用程序。
l 不需要停止服务器和应用程序就可对应用程序进行配置。
l 应用程序一旦执行，即可接收客户调用请求。
l 不需要停止服务器就可移走应用程序。
l 可以停止应用程序而保留它的配置以便再次执行。

4.1.1动态配置

由于接口是公有的，因此可以被任何可用的客户端调用，例如Java应用程序。共有3种典型的部署方式

l 命令行方式
l 图形界面，包含向导
l 自己写一个部署用的Java程序。

5. 应用服务器的构架和拓朴构架

5.1 构架A （见图9）


图9 构架A－所有EJBs在单个进程空间运行

这是web服务器和应用服务器的传统构架，所有构成应用程序的beans在一个Java虚拟机里运行，这种类型的容器易于构建，因为应用程序提供者不必考虑bean的分布，也不必建立一个可靠的通讯协议来支持分布。

也有可能一些应用程序在另外的Java虚拟机里，但是事务的处理在一个进程空间。因为EJB规范要求beans间的通讯是事务性的，该构架不允许应用程序在不同的Java虚拟机和主机上分布。

建立一个分布式的事务协议不是件很容易的事情，这就是为什么一些应用服务器提供商避免的原因。如果所有的东西都放在一个单一的Java虚拟机里来运行，不但限制了伸缩性，而且也限制了它所能支持的客户端连接的数量。这是因为在Java中每个连接都要求启动一个新的线程，这个代价是昂贵的。

这种构架也会造成web容器的缺陷，由于JSP和Servlet 引擎同在web服务器的进程空间运行，它们不能利用多个机器的并行执行能力，就象前面提到的一样，造成了web应用的瓶颈。

5.2 构架B （见图10）

构架B是构架A的变化或扩展，构架B试图通过群集技术（也称为簇）来改变构架A中对伸缩性的限制。群集技术提高了系统承载工作负荷的能力，它是通过将beans复制到不同主机上的进程空间（这些bean和原来的是相同的），以便分担负荷。有很多算法用来决定哪些beans服务哪些客户请求，这种方式提高了系统所能承受的负荷。

问题在于有些应用程序服务器没有给你决定复制哪些beans的选择，而实际上是整个应用程序和组成它的beans都被复制。该构架只是对构架A的改善，实际上是试图填补构架A的漏洞，而不是对于伸缩性的最适合的设计方案。


图10 构架B－单个进程空间和群集技术的应用

群集技术最大的问题是很难缓冲数据。对于web服务器来说，由于绝大多数数据是只读的，群集技术可以很容易地缓冲大量的数据。而应用服务器是一个事务性的系统，经常要求更新数据。当应用程序通过群集技术分散在不同的主机上时，就有可能对后台的同一数据竞争访问。系统不能缓冲这些数据因为另一个群集服务器可能在另一个子事务中访问这些数据。所有如果没有一致的基于群集技术的分布式缓冲策略，EJB就不能利用数据缓冲的优点。

此外，这种构架还会遇到和构架A相同的问题：由于JSP和Servlet 引擎同在web服务器的进程空间运行，造成了web应用的瓶颈。

5.3 构架C （见图11）


图11 构架C－在各个进程空间中的集中器和Beans

这种构架从TPM（事务处理监视器）演变而来，使用了集中器。集中器用来将客户端来的调用请求传到后台的服务器端。 构架C有3个主要的缺点：

(1) TPM 已经存在了很长的一段时间，这也是它可靠和健壮的原因之一。但是这一点却使得它不能利用一些最新的技术例如多线程。所有TPM是典型的单线程，不能支持多线程容器，甚至不能支持一个进程里的多个bean。多个bean必须寄存于独立的Java虚拟机里。很明显，这方式不能扩展到有大量bean的应用中，而且bean内部的通讯必须放在内部处理，这要被进程间的通讯慢得多。

(2) 第二个缺点是由于所有的客户请求都要通过集中器，增加了额外的代价。

(3) 该构架对于web服务器来说具有和构架A与构架B同样的问题。

(1) 构架D （见图12）
图12 构架D－分布的EJB容器和单个进程空间的Web容器

这种构架是最常用的一种构架。到目前为止我们所看到的构架要么在web服务器上要么在ejb服务器上都存在这样那样的漏洞。构架C在克服EJB容器的缺陷方面迈出了一步。现在没有了单个进程的限制。可以把EJB服务器分布到多个主机上。它们之间的通讯要么是RMI/JRMP要么是RMI/IIOP。EJB服务器可以被群集也可以不用群集。然而该构架还是有同样的web容器设计的问题：由于JSP和Servlet 引擎同在web服务器的进程空间运行，造成了web应用的瓶颈。

7.1 构架E （见图8）

该构架是iPortal 应用服务器的构架，它比上面提到的任何一种构架都要先进。该构架克服了构架A和构架B所面临的问题：它们没有能力分布于网络，bean被限制在单个进程空间里。相反，iPortal 应用服务器允许应用程序分布在多个主机上，甚至可以被广域网（WAN）分开。这样应用程序可以跨网络分布充分利用多台机器的优势。

这种构架也克服了由于servlet和jsp同在web服务器上运行带来的web应用的瓶颈问题。iPortal 应用服务器支持将多个JSP和Servlet引擎跨网络分布的能力。也可以将JSP和Servlet引擎分别配置在web服务器（如果它们与后台的通讯不是很多的话）或EJB服务器上。

6. 使用IIOP为EJB和CORBA提供互操作能力

EJB和J2EE在计算机发展史上来说是很新的技术。到目前为止，很多大的公司仍在很多不同的平台上使用不同的编程语言来运作他们的商业事务。特别地，很多公司使用OS/390，AS/400和其它的一些大型机系统存储数据和管理事务。由于这些大型机系统已经很好地运行了很多年，所有公司不愿意完全放弃。因此他们面临的问题就是怎样把现有的系统集成进互联网和电子商务。

很多应用程序提供商不考虑这一点，他们的产品也没有提供把现有的系统集成到新产品中的机制。IONA拥有针对不同需要的产品，允许iPortal 应用服务器充分利用现存的系统。

过去几年里，IONA把ORB技术引入到大型机平台。IONA目前有好几个版本的产品可以在OS/390上使用，其中提供了针对IMS，CICS，和TFP的适配器。支持用COBOL，C 和PL/1编程。这些适配器使CORBA客户端不需任何修改就可直接访问大型机系统。这对很多公司是非常有用的，因为他们中的一些可能大型机系统的源代码都没有!

OrbixWeb是AS/400上可用的ORB。这使得CORBA客户可以访问很多运行在AS/400上的事务系统。IONA是唯一一家提供将CORBA客户端与OS/390和AS/400连接产品的厂商。

这种连通性不是CORBA客户端独有的。iPortal 应用服务器也提供了对其它客户端访问的技术。iPortal 应用服务器建立在IONA公司最新的ART技术基础上。使用IIOP作为传输协议。此外IONA 在很多产品上使用公用的事务技术，该技术基于OrbixOTS。这种结合意味着： 企业级beans可用使用IIOP和CORBA应用程序（例如：UNIX上的C 或OS/390上的IMS及CICS）进行事务性的通讯。从效果上看，对EJB开发者来说，CORBA服务器充当了企业级beans的角色。

CORBA可以通过IIOP和EJB应用程序通讯，事务上下文可以在两者之间传递。

(1) 从EJB到CORBA

从EJB到CORBA的互操作性也就是企业beans和CORBA服务器进行通讯。典型地，CORBA是现存的旧系统但也有可能是新的例如用C 写的应用程序。如果应用程序中的某些bean负责和CORBA通讯，那么这些bean将作为EJB扮演CORBA应用程序的角色。

然而，通过IIOP与CORBA进行简单的通讯是不值得一提的，很多应用程序服务器都支持。只要将CORBA的桩包含在bean里，将对CORBA的调用请求交给桩，该调用请求将会通过网络到达CORBA应用程序，该bean也会接受到相应的返回值。这种互操作性对用户来说没有很大的价值。

真正的与CORBA系统的集成意味着在beans与现存的老系统之间提供可靠而健壮的通讯。这要求将事务能够从EJB传播到CORBA，而且能够保存安全上下文，IIOP是所有IONA 的CORBA产品和它的应用程序服务器的传输协议。这两种情况都使用OrbixOTS作为事务提供者，它是OribxOTM（IONA的Orbix对象事务监视器）的一部分。它允许事务上下文在EJB和CORBA之间传递。 这就意味者事务可以在EJB和CORBA之间双向传递。IONA的针对EJB和CORBA的安全技术基于SSL，这意味者通过IIOP传输的调用请求是加密了的。

此外，EJB到CORBA的通讯是独立于它所使用的CORBA版本的。iPortal 应用服务器使用的版本是CORBA2.3，IIOP2.0。如果后台的CORBA应用程序用的是CORBA2.0以后的版本，它至少支持IIOP1.0，能够接受基于IIOP1.2的调用请求。这是因为IIOP1.2可以与IIOP1.1或IIOP1.0通讯。

(2) 从CORBA到EJB

从CORBA到EJB的互操作性指的是CORBA客户端，例如用C 或Visual Basic写的来激活企业bean的方法。开发者可能不使用Java来写CORBA客户端，因为可以很容易地使用IONA的RMI桩通过RM/IIOP来和bean直接通讯。

和EJB到CORBA的互操作性不同，CORBA到EJB的互操作性在规范的不同版本之间有明显的不同。CORBA客户端只能激活IDL（接口定义语言）接口，因此，我们需要把用Java写的bean接口通过Java到IDL的映射器转换成IDL，Java到IDL的映射器是CORBA里的一个特色，称为“由值决定对象”这个特色是在CORBA2.3里加的，所有CORBA2.3的客户可以很容易地利用它来激活bean。Bean接收到的IIOP消息和RMI/IIOP消息一样。 但在CORBA2.3以前版本的客户，不能同样的方式，因为他们不支持“由值决定对象”特色，在这种情况下，需要建立一个桥。可以有两种类型的桥：

(1) 一个CORBA服务器接收CORBA2.3以前版本的IIOP调用，而利用RMI/IIOP和EJB应用程序通讯。
(2) 一个CORBA服务器接收CORBA2.3以前版本的IIOP调用，而利用CORBA2.3的IIOP和EJB应用程序通讯。

其中第一种桥是更直接，更常用的方式。

7. 负载均衡

随着internet的持续增长，商业站点会有成百上千的并发用户，应用服务器必须要能够处理很高的负载。为了达到这一点，应用服务器首先要有一个高度伸缩性的构架。iPortal 应用服务器是建立在层次的分布式的构架基础之上的。其次，应用服务器还需要支持某种类型的负载均衡以便把负载分布到多个主机上。负载均衡和容错是紧密联系在一起的。

IONA有两种均衡负载的方式。目前应用在iPortal 应用服务器中的均衡负载方式和应用在其它IONA产品中的一样，即使用JNDI命名服务。IONA还开发出了一种更加复杂的基于ART定位器的负载均衡方式。

7.1 使用对象组织的命名服务的负载均衡方式。

7.1.1. CORBA命名服务

IONA的具有互操作性的命名服务实现方式被用在iPortal 应用服务器中，CORBA IOPs被用来查找EJB。在JNDI有一个名称和对象对应的库，一个名称只和一个对象对应。客户传入一个名称，可以得到一个对象参考。命名服务的工作流程如图13所示。


图13 JNDI使用举例

负载均衡要求一个选择机制来决定客户端使用哪一个服务器或对象。考虑选择机制是要考虑的主要的一点是将选择机制放在何处。典型地，它可以放在客户端，或一些中央服务器上，通常在目录服务中。

有一些应用服务器使用客户端选择机制。这会带来很多问题。如果企业有大量的客户端，那么选择标准一改变或者有新的服务器的加入，每个客户端都需要重新安装。这种方式显然伸缩性不好，因为涉及到客户端的改变。客户端越多，问题越严重。

如果将选择算法放在中央位置，我们就会克服这些问题。选择标准的改变或者新服务器的加入对客户端来说是透明的。在EJB或J2EE中JNDI是放置透明的选择机制的理想位置，因为客户端必须通过JNDI来得到bean的参考。

在1998年，IONA加入了对象组织为CORBA系统的负载均衡而实现的命名服务，这是为了满足用户要求集中实现负载均衡而不要将其放置在客户端的要求。这种方式克服了将选择机制放在客户端所带来的问题，因为选择算法的改变不会影响到客户端。

对象组织扩展了JNDI，允许一个名称对应一组对象而非一个对象。对象组的大小可以改变。 例如｛对象1a,，对象1b，对象1c｝,组成了一个对象组，对象组里的每个对象都是某个对象的拷贝。每一个对象组都有一个相应的算法来决定对象的选择。目前CORBA支持两种算法：随机和轮流。图14示例了对象组织的负载均衡算法。 如果三个客户请求要得到“name2”的对象参考，它们将会依次分别得到“name2”所指向的对象组里三个对象的参考。

既然JNDI现在允许在对象组内部的对象参考之间均衡负载，那么它是怎样被应用到iPortal 应用服务器中的呢？

由于对象组对客户是完全透明的，因此客户端不需要改动。

在EJB服务器端，IONA根据在一个名称下注册的多个beans来进行相应的修改，用户可以通过配置来决定是采用随机还是轮流选择机制。

假设有n个EJB应用程序拷贝和M个客户端，使用轮流选择机制，第一个客户得到第一个应用程序的参考，第二个客户得到第二个应用程序的参考等等，第n个客户得到第n个应用程序的参考。然后第（n 1）个客户再得到和第一个客户相同的对象参考等等，最后的结果是每一个应用程序差不多都为M/N个客户提供服务。


图14使用IONA’s命名服务的负载均衡方式

7.1.2. 使用ART定位器的负载均衡方式。

在前面的章节中，我们讨论了ART定位器和它在COBAR及EJB系统中用做分布和定位对象所带来的优点，定位器能够知道系统中容器的位置和活动状态。域典型地包含特定系统中的所有主机。这一点使得定位器是一个合适的放置负载均衡的选择机制的地方。该机制能够跨容器负载均衡。IONA目前在iPortal 应用服务器中使用基于定位器的负载均衡方式，对于基于定位器的负载均衡，选择机制存在于ART插件中，在启动时被装在定位器。当一个客户第一次向EJB发出调用请求，该请求首先通过定位器。象我们看到的那样，被用在iPortal 应用服务器中的IORs不包含目标主机的IP地址。相反它包含目标容器的名称和定位器的IP地址。在正常的操作方式下（没有负载均衡），定位器在客户和目标服务器中建立一条直接的连接，然后把对方法的调用传递给容器。如果负载均衡插件被装载，那么当客户端的调用请求到达时，定位器根据插件中的算法从可用的容器列表中选择一个来提供服务。iPortal 应用服务器可以使用随机或者轮转的插件。

由于负载均衡机制以插件的形式存在，因此可以象ART插件一样被定制。这样，你就可以从中选择它所提供的两个选择机制之一。你也许希望重写一个算法作为装载服务器的选择标准。此外，这种插件可以在运行时被关掉而不需停止定位器。

8. 容错

应用程序服务器不但要被设计成能够处理很高的负载，而且要有高度的可用性来支持容错。在Internet上，宕机是不能容忍的。 IONA采用了两种方式来处理容错。通常容错在最初是和负载均衡相联系的，目前IONA在iPortal 应用服务器中提供了一个基于JNDI的负载均衡机制。IONA还开发了一种更复杂的基于ART服务器的容错方式。下面让我们分别来看一下。

8.1 使用基于名称的负载均衡支持容错

在第七部分里讨论的负载均衡也可以提供一定的容错。让我们首先看一下在EJB 1.1规范中关于客户端在会话bean失败的事件中所采取的办法： “在服务器失败或者指定的配置超时之后，容器可以终止一个会话bean的生命周期。由于这个原因，客户端在失去了它所连接的会话对象时应该准备去创建一个新的。”

（EJB 1.1规范6.1章，第50页） 我们看到如果会话bean失败，客户端必须去准备创建一个新的会话对象。所以，客户端程序应该以一种兼容的方式能够支持这种情况（通过一个重试循环）。工作过程如下。

客户端必须重新使用JNDI来得到一个新的Home对象（该对象用来建立Remote对象）的参考。这就是对象组被引进的原因，当客户端使用和原来相同的名称来请求一个Home参考时，它得不到和原来同样的参考（原来的已经被破坏），而从对象组里面得到一个新的（取决于它所使用得选择机制和对象组里对象得数量，客户端也有可能得到刚刚被破坏得对象参考，如果试图和这个被破坏的对象Home接口连接，很明显要失败，但这可以使客户端得到另外一个参考。如果采用轮转的选择机制就可以保证得到一个新的Home）。然后客户端就可以使用一个新的Home去建立Remote对象并进而重建一个会话。

现在，客户端不需要与新的会话bean重新开始一个会话，iPortal 应用服务器可以使客户端从它断开的地方继续这个会话。这种工作机制是这样的。iPortal 应用服务器阶段性的把状态保存到数据库（你也可以配置应用服务器将其保存到磁盘）。你可以在容器配置文件中定义保存间隔时间。这样当一个会话bean破坏后，它的状态被保存使它仍然可用。当新的会话bean被创建它从数据库中取回保存的状态，从中断处继续执行。

现在让我们来看一下规范中关于实体bean失败的描述： 所有的实体对象都被认为是持久性的对象。实体对象的生命周期不是由它所在的JAVA虚拟机的生命周期来决定。尽管JAVA虚拟机的破坏可以导致当前事务的回滚但它不能破坏前面所创建实体对象，也不能使得客户端对于Remote和Home接口的参考的失效。（EJB1.1规范，8.4章节，第九十二页）

实体bean的情况有很大差异，根据规范说明的，实体bean的参考是持久性的（长期存在的）不能被改变的。这意味着我们不能使用和会话bean同样的方式（在会话bean中我们维护了一个参考值）。此外，维护多个实体bean将会导致冲突，因为每一个在更新数据库时都加了锁。 然而规范也说明了所有实体bean都是事务性的，这就是实体bean恢复能力的由来。服务器的任何失败或者在这些服务器上特定方法的调用会引起事务回滚。由于IONA的OTS（Orbix对象事务服务）是一个对于CORBA的OTS的完全和真正的实现，iPortal 应用服务器支持实体bean所要求的完全的事务能力，因此实体bean具有从失败中恢复的能力。

8.2 使用ART定位器支持容错

在7.2里我们看到了ART插件构架是如何为定位器提供一个负载均衡插件。我们同样也看到了定位器是负载均衡插件的理想放置位置，因为定位器能了解所有的容器。对于容错也一样。 象负载均衡一样，容错算法被包含在ART插件中，在定位器启动时被装载，而且有一个容器池可供选择。任何容器的失败都会通知给定位器（定位器自身也支持复制，因此不会发生单点失败），这时任何容器的失败都会通知给定位器，这时定位器就会从容器池里选择另外一个。而且在客户端和新的容器之间建立一个新的连接。新的应用的状态可以从数据库里取到（有状态的会话bean和实体bean）。对于会话bean，当失败发生时，客户端要求重建一个会话对象并且继续会话任务。对于实体bean，所有的调用都是事务性的，因此当前的事务被滚回。客户端必须在连接重新建立之后开始新的事务。 由于容错机制以插件的形式存在，因此可以象ART插件一样被定制。这样，你就可以从中选择一个。此外，这种插件可以在运行时被关掉而不需停止定位器。

9. iPortal 应用服务器的其它特性

其他的特性包括：

l 容器对分布式事务的支持。
l IONA的会话bean和实体bean的实现。
l 日志，报表和审核。

9.1 分布式事务和JDBC2.0XA

EJB1.1规范要求使用JDBC（Java数据库连接器）2.0技术作为数据库驱动程序。IONA 把Metrant公司的JDBC2.0驱动程集成到iPortal 应用服务器中，你也可以自由得使用别得驱动程序。Metrant驱动程序既支持XA又支持non-XA接口。 和JDBC1.0相比，JDBC2.0有两个主要的优点，使得它在应用服务器中更加有效。

(1) JDBC2.0支持XA接口。XA接口是一个被X/Open组织标准化了的持久性存储的公共接口，它被当前的主要的数据库所支持，特别是关系数据库。这些数据库存取的公共API，使得跨多个数据库的两阶段分布式提交成为可能。这在JDBC1.0中是不支持的。在EJB里的两阶段提交也需要一个对于OTS（对象事务服务）的适当实现。事务管理非常难于编写，而且需要花费几年去修正。iPortal 应用服务器结合了IONA的OrbixOTS，这个产品已经在市场上四年了。它是基于Transarc’s Enica TP Monitor，该产品已经投放市场十年了。

(2) SA允许事务挂起和重新开始，以及跨连接的事务。跨连接的事务意味着事务的数量不会受到连接的数量的限制，按照JDBC1.0，一个bean和一个连接相联系，存在于一个事务生命周期中，因此同时开始的对于数据库的事务数会受到连接的数量的限制。使用XA，一个bean只需要在调用方法的阶段和一个连接相联系。这意味着JDBC2.0系统能够支持比JDBC1.0更多的对数据库的并发连接。

9.2 会话bean和实体bean

EJB规范要求EJBs在不同的时间被冻结（Passivated）。至于怎样冻结由服务器提供商决定。IONA没有提供一个特殊类型的冻结方式，而是提供了一个插件形式的冻结器。事实上这个冻结器被实现为ART插件（参看5.2）。编写你自己的冻结器只简单地涉及到去实现插件API。 缺省的冻结器保存到数据库。IONA提供了一个可选的冻结器它是用目录去保存beans，每一个bean对应一个文件。而且因为冻结器是插件形式的，你就可以修改它让它冻结到你所希望的持久性介质上去。

有两个超时值和会话bean有关，第一个是冻结超时时间，该值指定了会话bean冻结的间隔值。第二个超时值是会话超时值，它的工作流程如下。一个客户端如果在超时值指定的时间内没有访问它的会话bean，该会话bean就会被删除。它既会从内存中被清除也会从保存介质上被清除，这决定于此时它在哪儿。

除了插件性的冻结器，iPortal 应用服务器还有一个插件性的容器管理持久类（CMP）。有时你可能想把实体bean冻结在别处而非数据库，可能是一个ERP包，例如SAP或者PeopleSoft。而在别的应用服务器中，唯一的选择是写bean管理的持久性（BMP）实体bean，在这种情况下开发者必须通过编程来调用SAP。在iPortal 应用服务器中，代码只要在插件性的CMP类里写一次，然后插入到容器里。这样就使得开发者只致力于事务逻辑，而让容器在SAP中管理持久性。

9.3 日志，报表和审核

iPortal 应用服务器有日志服务，管理者可以用它来得到重要的系统事件的信息，异常情况的警告，错误情况的详细信息。 日志功能可以使你设定要收集的信息的种类，是否将这些信息显示到屏幕上，或者将它输出到一个指定的文件。缺省的设置适合于大多数iPortal 应用服务器的环境，但是可以通过增加或改变在配置域里的日志变量来重载。 iPortal 应用服务器支持四种主要的日志级别：

(1) Information（信息）：信息消息被产生来通知管理员有重要的非错误的事件发生。
(2) Warning(警告)：在iPortal 应用服务器遇到异常情况时产生警告消息，但是可以忽略掉它而继续执行。
(3) Error(错误)：在iPortal 应用服务器遇到错误时产生错误消息，既有可能从错误中恢复，也有可能被强制放弃当前的任务。
(4) Fatal Error(致命错误)：当iPortal 应用服务器遇到不能恢复的错误时，产生该警告信息。

结束语：IONA公司将EJB技术和CORBA技术合理结合构造除了卓越的iPortal 应用服务器，通过利用ART和POA技术，使其具有很好的灵活性和伸缩性。

要想得到iPortal 应用服务器的试用版，请从 下载。要想了解该产品的使用，技巧和相关论文请到IONA’s开发中心：http://www.iona.com/products/iportal/devcenter.htm. 下载本文示例代码


IONA iPortal 应用服务器构架IONA iPortal 应用服务器构架IONA iPortal 应用服务器构架IONA iPortal 应用服务器构架IONA iPortal 应用服务器构架IONA iPortal 应用服务器构架IONA iPortal 应用服务器构架IONA iPortal 应用服务器构架IONA iPortal 应用服务器构架IONA iPortal 应用服务器构架IONA iPortal 应用服务器构架IONA iPortal 应用服务器构架