IONA Orbix 2000 V2.0技术白皮书 - 4 Orbix 2000 企业版
(by huihoo.com fat1 , Allen 整理)
4 Orbix 2000 企业版
可以使用 C++ 和 Java 进行设计用于各种 NT 和 UNIX 平台，Orbix 2000 企业版是当今最先进的 CORBA 产品。除了 Orbix 2000 标准版的所有功能和益处外，Orbix 2000 企业提供了下面各节中说明的功能。
4.1 服务器群集
Orbix 2000 企业版最为强大功能之一是它的服务器群集结构。通过使用服务器群集，可以将多个服务器（每个都可能运行在不同的计算机上）组合在一起构成一个单一的逻辑服务器。对于使用服务器的客户机，外表是一个单一的服务器进程。实际上，Orbix 2000 基础结构实际将调用分布到了群集中的一组服务器进程中。
服务器群集极大地提高了系统的可靠性。建立可靠系统的关键是确保没有单一故障点，即不会发生单一资源的故障导致整个系统崩溃的情况。因为服务器群集允许用户使用多台服务器为应用程序提供服务，所以它减少了单一故障点。
一台服务器的故障不会造成服务的丢失，总是会有另一台服务器会替代它。因为 Orbix 2000 的服务器群集功能对应用程序是透明的，所以建立具有高可用性的系统是很容易的。如果群集中的一台服务器发生故障，基础结构将监测到该故障，并且自动将客户机路由到另一台正常工作的服务器，而不会丢失服务。只要在服务器发生故障时，没有正在进行的交易，则整个故障转移过程对应用程序而言是不可见的。
服务器群集还可以极大程度地提高系统的整体性能。因为整个群集是作为单一的逻辑服务器起工作的，所以可以将客户机分布到群集中的每一台物理服务器上，这一过程称为负载平衡。这可以保证没有单一的服务器成为系统中的瓶颈，并且能够让用户利用多台计算机的处理能力。
Orbix 2000 提供了多个即时可用的策略，可以将这些策略用于将客户机分布到群集中的不同服务器上，这些策略包括循环、随机分布和能够将新客户机引导到负载最小的服务器的反馈驱动方法。可以以每服务为基础应用这些策略，这样能够让用户将不同的策略运用与不同的应用程序。可以使用“ART 插件开发人员工具包” 来编写定制的负载平衡策略，这样便可以根据应用程序的需要定制负载平衡了。
它究竟是如何起作用的呢？ 如图 7 所示，在 Orbix 2000 服务器启动时，它使用一个称为“服务器定位器”的进程进行自身注册。在应用程序首次调用一个服务器创建的对象引用时，客户机 ORB 将消息透明地发送到请求服务器当间地址的“服务器定位器”。
“定位器”通过咨询负载平衡子系统选择一个群集中运行正常的服务器以响应该消息，然后将客户机重新定位到这台服务器。从这时起，客户机便直接与这台服务器进行通信。
Orbix 2000 的服务器群集实现提供了多种特性，这些特性对于企业级系统是很重要的：
。透明性：查找服务器的整个过程是由客户机 ORB 使用标准 IIOP 消息来处理的。因此，客户机应用程序不需要知道它在与一个群集应用程序协同工作，它们只是简单的调用一个对象，并且它们被透明地定向到其中一台服务器。此外，如果服务器发生故障，客户机将自动地、透明地返回到“定位器”以便被重新定向到群集中另一个正常运行的服务器。这种通明的性质可以使开发利用群集的应用程序更为容易。
。动态环境：因为客户机在运行时找到服务器的位置，所以整个“服务器定位器”系统是高度动态的。可以将新的服务器添加到群集，并且可以将现有的服务器从一个主机移动到另一个主机，而无需关闭系统。这样就可以让用户更新系统来处理不断增长的负载，或利用新硬件的功能，而不必承受服务丢失的损失。
。灵活性：Orbix 2000 不强制用户使用任何特定的模式进行服务器群集，用户可以在每应用程序基础上对群集中的服务器数、服务器位置、将客户机路由到服务器的算法进行定制。另外，Orbix 2000 负载平衡系统是完全可插入的，这意味着使用“插件开发人员工具包”来开发定制的负载平衡算法（例如通过监控应用服务器的负载决定自己的负载平衡算法）是件很容易的事。
。高效：Orbix 2000 的群集结构将直接通信的速度与群集的功能联合在了一起。客户机 ORB 只有在第一次请求服务时会联络“定位器”。只要被分配到了群集中的物理服务器之一，客户机将在随后的调用中直接与服务器进行通信。这可以为用户提供强大的负载平衡和失败转移能力，而不增加应用程序的开销。
。可管理性：Orbix 2000 群集结构被完全地集成到了 Orbix 2000 的管理环境中。可以从管理控制台中查看群集中服务器的状态，这些状态包括它们的当前位置、服务器上的负载量、每台服务器处理的客户机数目等。另外，无论是否无法启动群集中的某台服务器或正在运行的系统发生故障，这些系统故障都会被作为事件报告给管理服务。这使用户能够检查正在运行的系统发现性能瓶颈，对系统进行调整，使其满足应用程序的需要，并处理在生产环境中可能发生的任何关键性问题。
4.2 群集基础结构
除了支持群集应用程序环境外，如图 8 Orbix 2000 基础结构自己使用群集获得高可用性。诸如定位器、命名服务、交换服务和配置库等 Orbix 2000 服务都可以被组合成服务器群集。
群集中的一台服务器被指定为主服务器，其它服务器被指定为备份服务器。主服务器处理对系统的所有更新，并使用内部数据库复制协议将这些更新传送到备份服务器。群集机制对于应用程序是完全透明的。
根据系统的不同配置，可以使用两种方法了处理主服务器的故障：
。备份服务器中的一台将升级成为主服务器，在这种情况下，系统的运行与先前一样。
。备份服务器继续运行，在此情况下，只允许进行读操作。
虽然不允许备份服务器写入主数据库，但是重新启动的备份服务器可以将其数据库与主服务器的数据库进行同步。
4.3 高级的消息发送结构
Orbix 2000 标准版包括了 CORBA 事件服务，Orbix 2000 企业版包括了 CORBA 事件服务和CORBA 通知服务。IONA 对这些服务的实现提供了连接和事件可靠性。
4.3.1 Orbix 2000 通知服务
在默认情况下，CORBA 应用程序使用同步请求和恢复机制。大多数客户机/服务器应用程序原本就是同步的：客户机请求服务器执行某些服务或提供某些数据，并载继续处理其它活动前等待从服务器得到响应。这适合于交易性的或立即需要信息的应用程序。
但是，为将应用程序限定为同步，客户机/服务器类型交互将应用程序的缩放性、性能和可靠性附加了一些限制。客户机和服务器应用程序的紧密偶合，还为应用程序开发人员添加了诸如处理故障场景等许多复杂性。载许多情况下，异步的、非偶合的通信可以为应用程序开发人员提供更高的灵活性。
例如，请考虑载一个应用程序中，在这个应用程序中客户关心是否能够通知他某些状态的更改（例如，监视股票市场的应用程序或监控网络设备状态的应用程序）。不需要客户机不断地对服务器进行轮询以确定是否发生了状态更改，通信范例让客户机能够注册自己对状态更改感兴趣，并且在状态变化时进行异步传输，这种通信范例是一个很大的优势。
与请求/响应通信相反，许多这样的应用程序是通过使用发布和订阅方式更为自然地实现的。除了具有异步的属性外，发布和订阅通信允许消息生成者与消息消费者取消偶合。这允许消息传输层提供诸如高可靠性提交等不同质量的服务，并且让应用程序开发人员免除了是否能够持续连接到过程或应用程序消息消费者的担心。
4.3.2 持续性
Orbix 2000 Notification 支持事件可靠性和连接可靠性，因此能够将通道配置为在进程重新启动后恢复原来的状态，并且提供事件高可靠性传送。Orbix 2000 Notification 具有一个内置的数据库 (Berkeley DB)，它保证了通知消息的持续性。需要有 ODBC。
Orbix 2000 通知支持事件和连接可靠性：
。连接可靠性：指定通道是否要保留关于所有客户机的持续信息，其中包括它们的过滤器和服务质量属性的配置，以便在通道中的进程重新启动时通道能够动态地重新建立它们的状态。
。事件可靠性：指定通道是否应该保存一份事件的持续拷贝，以便即使在通道服务器发生故障时也能够将事件的持续拷贝传送到所有消费者。
4.3.3 多路广播
Orbix 2000 Notification 支持基于“用户数据报协议”(UDP) 的多路广播作为插件传输层的替代，从而包含了 OrbixTalk 的功能。
将在特定的 IP 广播地址上接收消息的一组主机称为多路广播组。多路广播组可以跨多个网络，主机可以随时加入或离开多路广播组。将主机加入多路广播组不会影响网络上发送的消息，只发送单一的消息，而无论多路广播组中的主机数目。采用这种方式，多路广播传送服务减少了网络资源的负载，并且易于实现缩放性。因为多路广播是一个插件，所以单一通道可以支持 IIOP 和多路广播。
4.4 CORBA 对象交易服务
交易是一个重要的程序设计范例，可以用来简化高可靠性、高可用性应用程序（尤其是那些需要并发访问共享数据的应用程序）的构建。交易概念首先是在商业运作应用程序中引入的，在该环境中将其用于保护集中数据库中的数据。最近，交易概念已经被扩展到了一个更宽泛的分布式计算环境。当今，交易作为构建可靠的分布式应用程序的主要内容的概念已经被广泛接受。
CORBA 对象交易服务 (OTS) 是 Orbix 2000 企业版的一部分。IONA 提供两种不同的 OTS，分别支持单个和多个资源。单一资源 OTS 版本支持对只涉及单一资源（例如，单一数据库）的交易使用交易语义。多资源版本支持跨越多个资源的交易，因此需要两阶段提交。
通过提供两个 OTS 版本，Orbix 2000 让客户（其应用程序需要淡季交易资源）能够减小 ORB 记录的大小。如果随后将应用程序扩展为能够处理多交易资源，则可以容易地添加多资源 OTS 版本。
注意可以将 Orbix 2000 OTS 多资源交易协调程序作为单独组件进行部署，或可以与特定进程一起进行共同分布。“共同分布”能够通过降低网络通信量来提供优异的性能优势。
一个经常用来对交易语法必要性进行说明的实例是银行应用程序中的资金转移，4.4.1. 节中详细说明了该实例，该实例涉及了两个操作：一个帐户中的借方和另一个帐户中的贷方（可能在扣除了一定费用后）。要将这些操作合并到单一工作单元中，下面列出了整个流程中必须的属性：
。如果借款操作失败，借款操作也应该失败；反之亦然：即它们应该都成功，或者都失败。
。在操作前和操作后，系统中的总钱数应该相同。
。在处理过程中系统处于一种不一致的状态（在借方和贷方之间）。
。应该从应用程序的其它部分隐含这一不一致的状态。
。毫无疑问，整个过程提交的操纵结果应被永久保存。
这些点说明了交易中所谓的 ACID 属性：
原子型 交易是完整的或者什么也不做，当交易完成时，同时完成或同时终止（回滚）。
一致型 交易是一个工作单位，它将系统从一个一致状态转换到另一个状态。
孤立型 在交易执行时，部分结构被从访问系统的其它实体隐含。
持久型 交易的结果是持续的。
因此，交易是系统上的一个操作，它将系统从一个持续、一致的状态转变为另一个状态。
4.4.1 分布式交易的实例
这里探讨的实例关于两个帐户之间的资金转移。将一笔钱从源帐户（由服务器 A 管理）转移到了目的地帐户（由服务器 B 管理）。这一转移过程发生在单一的、分布式的交易环境中。
图 9 显示了资金在分布式交易环境中被从源帐户转移到了目标帐户。帐户对象显示为带有黑色边框以表示它是交易性对象。
4.4.2 控制数据库交易
一般来说，数据库提供三种不同的方法来支持交易语义（即控制是执行一个交易还是回滚一个交易）：
。嵌入的 SQL
。数据库本地接口
。XA 接口
在它们之中，只有基于标准的分布交易方法是 XA 接口。大多数现代数据库为交易控制提供了 XA 接口（XA 该接口是 X/Open 组织定义的业界标准）。
4.4.3 两阶段实现
如果系统中具有多个数据库，并且有两个或多个参与到交易中，则有必要将它们置于单一的交易管理器的控制下。需要有交易管理器正确地协调具有多个数据库（更为常见是的多项资源）参与的交易。
数据库或资源必须对交易管理器开放 XA 接口。要完成该操作，它将对交易的控制权转让给交易管理器（在此情况下是 Orbix 2000 的 OTS）。交易管理器和数据库之间的所有交互都是通过 XA 接口实现的。
为保障 ACID 属性并防止数据丢失或损坏，将使用两阶段实现协议来完成分布式交易。图 10 的交互图中列出了典型的步骤。在该实例中，注意力集中在了数据库的上，该数据库支持 XA 接口。
图 10 显示了两阶段提交协议中的步骤是如何执行的。参与交易的元素有：CORBA 服务器 App A（直接连接到了数据库 A）和 CORBA 服务器 App B（直接连接到了数据库 B）。OTS 交易管理器在图中显示为独立的实体。在现实中，OTS 是作为插件存在的，它是由 App A 和 App B 按照需要装入的。
在两阶段实现中，交易管理器对所有参与交易的资源调用 prepare()。这使参与的资源由机会将交易的当前状态保存在它们各自的交易日志中。如果在交易完成前，有资源发生故障，则自动故障恢复机制将使用这些交互日志。通过发送回交易结果的选票，资源将对 prepare() 操作做出回复。“投票”响应的替代方法包括：
。如果交易没有更改资源的数据，则返回 VoteReadOnly。例如，如果与数据库的交互只涉及到 SQL SELECT 语句，则情况如此。
。如果资源的数据被交易写入到稳定的存储器，并且正确地准备了资源，则将返回 VoteCommit。响应表明特定的参与资源恰好继续完成了交易。
。如果特定参与资源因为某一原因想要退出交易，则返回 VoteRollback。 在开始两阶段实现的第二阶段之前，交易管理器将等待所有选票的返回。
在两阶段实现的第二阶段中，交易管理器执行的操作取决于参与资源的投票结果。如果参与资源的多数意见是实现，则交易管理器将对所有资源调用 commit() 继续操作。但是，如果如果有一个或多个负结果，例如参与资源投了 VoteRollback 票，则交易管理器将对所有参与资源调用 rollback()。
OTS 在一个伪退出模型中操作。换句话说，如果特定资源没有接收到确认 commit()，则它最终将回滚到交易中（在一定超时后）。
4.5 CORBA 交换对象服务
Orbix 2000 提供了一个 OMG 交换对象服务的有效的、健壮的和完整的实现。交换对象服务是一种机制，通过该机制特定服务类型的实例能够进行自身宣传，通过该机制其它对象可以发现这些服务。通过这种方法，交换对象服务支持动态发现服务，并具有在运行时将这些服务绑定在一起的能力。
交换程序 (trader) 是一个对象，通过该对象其它对象可以宣传自己的能力并将它们的需要与其它对象宣传的服务相匹配。宣传能力或提供服务称为导出。发现一个服务称为导入。在导出时，对象向交换程序提供服务的描述和它的位置信息。导入时，对象向交换程序请求符合特定属性集合的服务。
当对象试图导入服务时，它将需要的服务属性指定给了交易程序。交易程序检查符合特定属性的服务说明。如果没有该服务，交换程序将通知导入者服务接口的位置。然后，导入者将直接与该服务进行交互。
交易服务是一项高级别组件，它提供了大量完善的功能，用户可以快速地将这些功能集成导各种应用程序中。将交换服务添加到开发工具箱中可以完全启用新的设计策略，这些策略能够简化实现并将新的功能添加导您的系统。
从本质上讲，交易服务是对象元数据的一个可搜索数据库。服务器应用程序通过将它们的对象描述给交换程序来填充数据库，客户机应用程序要求交换程序查找符合特定标准的对象。
交换服务的动态属性能够推动系统设计的及时完成，在该系统中客户机将在请求服务时发现服务器。另外，客户机能够充分利用交换服务中的强大搜索能力（通过使用一种表述性的查询语言，它熟悉易用）来选择那些符合特定限制的服务供应者。
交换服务处理对象发布和发现的细节，这样可以让您专注于让该服务应发挥最大的作用。通过提供一个有效的、强壮的和完整的交换服务规范（由 Object Management Group 定义）实现，交换服务可以减少分布式对象系统的开发时间。
4.5.1 改善设计
交换程序数据库中描述每个对象的元数据可以包括一些仲裁属性（称为特性），这些属性可以提高系统的效率。任何分布式系统的目的之一都是减少远程调用的数量。通过提供足够的元数据来描述这些对象，可以使用交换程序来实现这一目标。
例如，请考虑一个人寿保险行业的应用程序，其中不同的报价对象用于根据客户要购买的保险单确定的保险条款特性来生成报价。
如果应用程序能够使用查询语句来搜索交换程序数据库查找报价对象元数据，这些元数据的属性应与客户所请求的数据相匹配，应用程序避免询问每个报价对象是否支持特定的策略类型，或是否具有特定的质量水平，从而减少远程调用的必须数量。交换程序实现了这种效率。
随着系统需求的增长，可以利用交换服务的更为复杂的功能。系统可能需要具有更强动态功能的交互（较先前说明的交互而言）。例如，您可能需要一个与随时间更改的对象相关的属性的值，在这种情况下客户机的查询在每次执行查询时可能遇到不同的值。
使用交换服务实现这类功能是很直接的。您只需要简单地将属性的值分配给其他对象（它将查询数据库中属性的值，并根据某个算法对其进行运算），然后交换程序将在任何需要属性值的时候向对象进行咨询。
4.5.2 分布式负责
交换服务的另一个高级功能是让用户能够运行多个交换服务器实例（例如，在公司的不同部门中），并将它们合并在一起形成一个交换程序联盟，从而构成更为灵活的系统。
例如，假设工具具有三个部门，分别位于旧金山、芝加哥和法兰克福，并且已经在每个部门中单独地部署了交换服务，这样每个交换服务器都具有它们自己的对象元数据独立数据库。
交换服务可以将它们绑定在一起，从而增大了查询时客户机可以使用的对象池。当对象查询旧金山的交换程序服务器时，该查询自动并透明地传播到了芝加哥和法兰克福的服务器，并且发现的任何结果都会包括在返回给客户机的结果中。
交换程序管理员可以建立限制活动的规则以将开销降低到最小程度。例如，管理员决定只有在本地没有发现匹配对象的情况下（例如，在旧金山服务器的数据库中），对旧金山才被传播到旧金山。
以这种方式加入交换程序的能力提供了一些重要的优势。首先，负载可以分布到多台服务器上。第二，可以建立正确的本地和远程查询组合来适应应用程序的需要。最后，可以随着应用程序需要的更改动态地添加和删除交换程序。