corba设计idl.doc

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个元素经过参数转换后在返回。 初一看，这个设计是可行的，如果不发生前面所说的不可预料的情况的话。 下面的代码定义了用来实现客户端和服务器端交互作用的IDL接口和方法。该文件中只定义了一个方法，用来返回一组产品的信息。 Module productcatalog { struct ProductItem { string productName; … }; typedef sequence ProductItemList; Interface ProductCatalog { ProductItemList getProductItems(in string group,in string category,in string status ) Raises {SomeRemoteException}; }; }; 从客户端的角度看，对服务器端程序的一个请求，来检索产品的信息需要如下的几步骤。如图二所示. 代理的对象提供了一个包，绑定到一个特定的服务器端的对象实例上来充当一个中间的对象，用来管理对远程服务器对象的调度了管理。它的主要任务包括： 1． 准备一个请求 2． 把调用请求提交给ORB的桩(stub) 3． 捕捉（trap）远端的异常。（最好把它们映射到用户自己定义的异常中） 4． 准备好用于接受特定对象模型的数据结构。这些数据要被客户端的应用程序使用产品类代理的实现如下面的代码所示： public class ProductServiceProxy { private static ProductServiceProxy instance; private ProductServiceProxy() {} public static ProductServiceClient getInstance() { if(instance=