J2EE值对象模式在分布式结构中的分析及应用.doc

值对象模式在分布式结构中的分析及应用 引言 在与远程对象通信时，需要权衡的因素： 远程调用（那些必须跨越网络的调用）速度缓慢。虽然许多远程调用框架可以隐藏进行远程调用的复杂性RMI），但是它们不能消除发生通信所需的步骤。例如，必须先找到远程对象位置，而且建立与远程计算机的连接，然后才能将数据串行化为字节流，然后可能进行加密，最后才能将其传输到远程计算机。 在考虑网络性能时，必须同时考虑滞后时间和吞吐量。简单地说，"滞后时间"描述了数据的首字节到达目的地之前所经过的时间。"吞吐量"描述了在某个时间段（例如 1 秒）内通过网络发送的数据字节数。在基于 IP 路由的现代网络（例如 Internet）中，滞后时间可以是比吞吐量更大的因素。这意味着，传输 10 字节数据所用的时间可能几乎等于传输 1,000 字节数据所用的时间。在使用无连接协议（如 HTTP）时，此效果尤其明显。通常，网络速度越快可以使吞吐量得以增加，但是，要减少滞后时间则会更加困难。 在设计对象接口时，好的做法是将大量信息隐藏在对象内，并提供一组细粒度方法来访问和操作该信息。"细粒度"意味着每个方法都应该负责单个的、相当小的和基本的功能单位。此方法简化了编程，并提供了对对象内部的更佳抽象，从而增加了重用的可能性。必须根据以下事实对此进行平衡取舍：使用较细粒度的方法意味着需要调用更多的方法才能执行高级别的任务。通常，在同一进程内调用方法时，这些额外函数调用的开销是可接受的；但是，在跨进程和网络边界调用这些方法时，开销可能变得难以接受。 避免远程调用中固有的滞后时间问题的最佳方法是进行更少的调用，并让每个调用传递更多的数据。做到这一点的一种方法是，使用长参数列表来声明远程方法。这样，客户端就可以在单个调用中将更多的信息传递给远程组件。但是，这样做会使针对此接口的编程容易出错，因为程序很可能仅按调用语句中的位置来调用外部方法的参数。例如，如果远程方法接受 10 个字符串参数，则开发人员很容易按错误顺序传递参数。编译器将无法检测到这样的错误。 长参数列表无助于从远程调用向客户端返回更多的信息，因为大多数的编程语言将方法调用的返回类型限制为单个参数。而巧合的是，在传输大多数数据时通常需要返回较多信息。例如，许多用户接口传输少量的信息，却希望返回大量结果数据。 RMI的工作原理 概述 Java RMI （Remote Method Invocation 远程方法调用）是用Java在JDK1.1中实现的，它大大增强了Java开发分布式应用的能力。Java作为一种风靡一时的网络开发语言，其巨大的威力就体现在它强大的开发分布式网络应用的能力上，而RMI就是开发百分之百纯Java的网络分布式应用系统的核心解决方案之一。其实它可以被看作是RPC的Java版本。但是传统RPC并不能很好地应用于分布式对象系统。而Java RMI 则支持存储于不同地址空间的程序级对象之间彼此进行通信，实现远程对象之间的无缝远程调用。RMI目前使用Java远程消息交换协议JRMP（Java Remote Messaging Protocol）进行通信。JRMP是专为Java的远程对象制定的协议。因此，Java RMI具有Java的"Write Once,Run Anywhere"的优点，是分布式应用系统的百分之百纯Java解决方案。用Java RMI开发的应用系统可以部署在任何支持JRE（Java Run Environment Java，运行环境）的平台上。但由于JRMP是专为Java对象制定的，因此，RMI对于用非Java语言开发的应用系统的支持不足。不能与用非Java语言书写的对象进行通信。本文拟从程序的角度举例介绍怎样利用RMI实现Java分布式应用。 工作机制 在与远程对象的通信过程中，RMI使用标准机制：stub和skeleton。远程对象的stub担当远程对象的客户本地代表或代理人角色。调用程序将调用本地stub的方法，而本地stub将负责执行对远程对象的方法调用。在RMI中，远程对象的stub与该远程对象所实现的远程接口集相同。调用stub的方法时将执行下列操作： (1) 初始化与包含远程对象的远程虚拟机的连接； (2) 对远程虚拟机的参数进行编组（写入并传输）； (3) 等待方法调用结果； (4) 解编（读取）返回值或返回的异常； (5) 将值返回给调用程序。为了向调用程序展示比较简单的调用机制，stub将参数的序列化和网络级通信等细节隐藏了起来。 在远程虚拟机中，每个远程对象都可以有相应的skeleton（在JDK1.2环境中无需使用skeleton）。Skeleton负责将调用分配给实际的远程对象实现。它在接收方法调用时执行下列操作： (1) 解编（读取）远程方法的参数；