第五章基于CORBA的分布式软件开发
5.1 分布式技术的基本原理
5.1.1传统的面向对象分析与面向对象设计方法。
常规的OOA和OOD方法可以直接应用于分布式系统的分析和设计，然而传统的OOP环境（例如C＋＋或object pascal）在直接用于分布式应用系统的程序设计时遇到了问题。传统的对象与访问该对象的程序只能存在于同一进程中，并且只有相关程序设计语言的编译器才能创建这些对象并感知这些对象的存在，而外部进程无法了解和访问这些对象。这意味着在常规的分布式客户/服务器应用中，客户进程不可能直接访问异地服务进程中的常规对象。为了解决这个问题，人们提出了分布式对象的概念。
5.1.2分布式对象技术
分布式对象存在于网络的任何地方，可被远程客户应用以方法调用的形式访问。至于分布式对象是使用何种程序设计语言和编译器所创建，对客户对象来说是透明的。客户应用不必知道它所访问的分布式对象在网络中的具体位置以及运行在何种操作系统上，该分布对象与客户应用可能在同一台计算机上，也可能分布在由广域网（如Internet）相连的不同计算机上。分布对象具有动态性，它们可以在网络上到处移动。独立于特定的程序设计语言和应用系统、可重用和自包含的软件成分称为软构件。分布式对象是一种典型的软构件。基于分布对象技术的分布式应用开发就是分布式对象的开发和组装。
分布对象技术采用面向对象的多层客户/服务器计算模型，该模型将分布在网络上的全部资源(无论是系统层还是应用层)都按照对象的概念来组织，每个对象都有定义明晰的访问接口。创建和维护分布对象实体的应用称为服务器，按照接口访问该对象的应用称为客户。服务器中的分布对象不仅能够被访问，而且自身也可能作为其他对象的客户。因此在分布对象技术中，客户与服务器的角色划分是相对的或多层次的。支持客户访问异地分布对象的核心机制称为对象请求代理(Object Request Broker,ORB)。ORB处于分布对象技术的核心位置。
通过重用已有的软构件，使用构件对象模型的软件开发者可以像搭积木一样快速构造应用程序。这样不仅可以节省时间和经费，提高工作效率，而且可以产生更加规范、更加可靠的应用软件。
5.2 分布式软件构件具备以下几个特征
• 自描述构件必须能够识别其属性、存取方法和事件，这些信息可以使开发环境将第三方软件构件无缝地结合起来；
• 可定制--提供一个典型的图形方式环境，软件构件的属性只能通过控制面板来设置；
• 可集成--构件必须可以被编程语言直接控制。构件也可以和脚本语言连接或者与从代码级访问构件的环境连接，这个特性使得软件构件可以在非可视化开发项目中使用；
• 连接机制--构件必须能产生事件或者具有让程序员从语义上实现相互连接的其他机制。这意味着程序员可以很容易地向按钮添加代码，使点中按钮就可以影响其他构件的动作。
构件模型是为开发者定义软件构件而建立的体系结构和API集，使开发者可通过软件构件的动态组合来建立应用系统。构件模型由构件与容器两种主要成份构成。构件是具有可重用特性的基本软件部件。容器用于存放和安排构件，实现构件间的交互。容器也可以作为另一个容器的构件使用。
5.3 分布式对象的服务
分布式对象服务包括支持分布式系统正常工作的各类基本的系统级服务，例如名字管理、事件通告、对象事务管理、对象生命期、时间同步、并发控制等。公共设施包括支持分布式系统高效开发和有效工作的各类面向领域的常规服务和工具，例如GUI服务、数据库服务、电子邮件服务、系统管理服务以及面向电信、仿真和金融等应用领域的领域构架等等。应用对象涉及各种应用软件，它在对象服务和公共设施的帮助下完成相应的应用逻辑；ORB如同一条总线（Bus）把分布式系统中的各类对象和应用连接成相互作用的整体。
5.4 基于CORBA的分布式应用
5.4.1分布式应用程序设计的主要问题
分布式应用程序设计的主要问题是确定建立在对象级上的客户与服务对象的关系。从其最根本的功能来讲，服务对象提供远程接口，客户对象调用远程接口，客户对象不需要了解远程对象的位置以及实现细节，也不需要了解哪个ORB 用于对象之间的交互。按照实现过程，CORBA的实现分为两种方式：命名服务对象引用方式和字符串化对象引用方式。
下面介绍基于CORBA技术，用C++语言在网络中建立分布式应用的具体方法。……..~
5.4.2 Corba中IDL的设计
从技术的角度来讲，把系统设计成n层结构需要解决系统管理上的一些问题，如网络的延时，系统的反应时间，服务的可用性，负载的管理，分布式的缓冲和分布式的垃圾回收等。而且，对于每一个能提高系统效率的新的解决方案，也会随之带来新的问题。但是这些在设计大型的分布式应用系统的技术上的问题，都可以通过使用一些基本的设计方法和技巧来加以解决。
通过使用迭代（Iterator）的设计模式来定义idl语言，从而解决corba程序中诸如性能管理，缓冲，分布式垃圾回收等问题。
一、性能上的问题
虽然corba的体系结构简化了网络的内在的复杂性。但它不能保证一定可以构造一个高
性能，高效率的系统，要实现这个目标，整个系统的设计一定要考虑到网络固有的结构，主要是以下的三个因素。
1．远程调用的数量。
2．数据传输的数量。
3．不同数据类型的转换和包装。
如果在系统设计的开始加以考虑，这些问题将会得到解决。
在基于corba的体统设计中，idl在组件的设计中起了很大的作用，应为它定义了服务端程序相互遵循的接口标准。
二、IDL的设计
一个通常在IDL设计中被忽视的问题是哪一个接口用于服务器端的应用程序，以及暂时的（transient）和持久的（persisent）corba对象。
1．一个服务器端的应用程序是一个用于实现对象方法的，与语言无关的对象。在corba程序的模型中，服务器端的程序通过可移植对象适配器（Portable Object Adaptor,即POA）向系统注册，从而能一直接受用户对它的调用。
2．同服务器端的对象相比，暂时的corba对象并不用POA向系统注册，他们在用户向系统请求的过程中由服务器端的应用程序生成。这些暂时的corba对象的生命周期不会超过所在进程或生成该对象的线程的生命周期，而且他们的对象句柄并不公开。
3．持久性的corba对象同持久性的状态相关联，有着特殊的用途。
以下主要讨论使用暂时的corba对象来管理大量数据的传输。这个方法在处理可能丢失数据的程序时非常有用，如下例所示：
用户要查询大量的数据，在得到了前20个数据后，另一个用户也提出一个查询，可能的情况是前面查询的数据将丢失。在一个单进程的应用程序中，这不是一个问题。但是在分布式编程和设计中。将会占用很多的网络带宽和cpu的处理时间。
基于如上所述，图一提供了一个客户端和服务器端程序的交互相应的示意图。客户端的代理是个远端的代理类，用于处理同远端服务器程序的连接以及把客户端的请求发送到服务器端。客户端向提供所需服务的服务器端付出请求，服务器端返回一组产品的信息，如果这个结果中有n个产品，则N个元素经过参数转换后在返回。初一看，这个设计是可行的，如果不发生前面所说的不可预料的情况的话。
企业级应用程序的设计比较复杂。前期的设计对以后系统的性能会有很大的影响。而在CORBA环境中，IDL的设计就显得尤为重要。好的IDL设计，充分利用JDK的API，如计时器，垃圾回收机制，集合框架能大大的提高系统的性能。从而能构造一个强壮的，高度可用的分布式系统。
