持续对象标识服务: 第 1 部分：客户机接口

欢迎阅读本系列文章中的第一篇文章，该系列文章将逐步指导您开发提供持续对象标识的服务。

许 多分布式对象系统中的一个迫切需求就是能够为持续对象生成唯一全局标识。我们称这些标识为持续对象标识（persistent object ID，POID）。POID 提供了一个生命期较长的对象，它的全局标识的作用域可以跨越空间和时间。可以举出的用例包括创建银行帐户的帐号以及为新客户生成标识。对于我们来说， POID 在对象类型里是唯一的。在为多个分布式客户机提供服务的同时还要以一种健壮、高效的方式实现这种需求，这是非常具有挑战性的。

我 们的解决方案是采用标准的 J2EE 和 Web 技术，包括 Enterprise Java Bean（EJB）和简单对象访问协议（SOAP）。我们将采用 WebSphere_Studio Application Developer V5 和 WebSphere Application Server V5 来构建和测试应用程序。

本文将讨论总体服务需求以及服务的客户机视图。其后续文章将会介绍服务器端组件的开发。

考 虑到本文的练习目的，我们会尽量使这个需求保持简明而不乏实际性。该服务应确保能够生成客户机指定类型的全局唯一标识。该服务的能力将支持 2 到 31 种不同的持续对象类型，其中每种类型支持 2 到 63 个 POID。就其性能来说，平均请求处理时间（不包括网络等待时间）应小于 0.01 毫秒，使用低端单处理器服务器时其最小有效吞吐量为每秒 2000 个请求。该服务必须支持最少 100 个并发客户机，并应该不受任何底层数据存储失败的影响。也就是说，在任何情况下都不能给客户机分配不唯一的 POID。

尽管该设计应该足够灵活，能够轻松地适应其它的通信协议（包括 RMI 和 CORBA），但 Java 客户机最初还是会使用 SOAP 来访问服务。

一个只有两层的简单数据库方案不太可能达到上述性能需求。特别是，想要为每个 POID 请求都提供一个数据库事务是不合理的。即使有些系统可能支持这个事务率，但这也是对宝贵资源不必要的浪费。

解决该问题的一个办法是采用分段 POID 地址空间（请参阅 ）。 在这种情况下，服务实际上会为诸如 AccountFactory 的客户机分配一个标识块。工厂请求一个新的帐户 POID 时，服务会分配给它一组数目为 100 个的 POID。当接下来还需要帐户 POID 时，服务会立即从这个保留的块中予以分配，这样就减少了额外远程数据库事务的需要。

我们想尽可能减小使用我们服务的客户所面对的复杂性。这种复杂性必须从几个方面去控制。客户机不应该看到服务通信或实现的细节，因为这限制了我们的灵活性。而且客户机本身不应负责管理 POID 块。

我 们可以为客户机提供一种易用的进程内（in-process）组件（负责服务定位和通信）以及 POID 块管理。图 1 描述了我们最初的类图表设计。这个组件由名为 PoIdGenerator 的单一类组成，它公开一个简单的 API，并且负责管理 POID 块。还有一个 PoId 类，它是 POID 值的简单包装器，它使 API 与实际的值类型相分离（在这里是最初为 long）。PoIdGenerator 将保持对代理的引用，该代理程序是 PoIdBroker 的实现。PoIdBroker 的实现又负责定位以及同底层服务的通信。PoIdBlock 是一个非公用帮助程序类，PoIdGenerator 用这个类来管理 POID 块。

这篇文章接下来的重点是客户机端组件的开发。

客 户机首先请求一个 PoIdGenerator 实例，然后在实例上调用 getPoId()，并将指定持续对象类型的 String 参数传给它（图 2）。一般来说，这种类型字符串同持续对象的 getClass().getName() 的返回值相符合。很显然，部署该服务时必须建立类型名称空间策略。PoIdGenerator 接下来会向 PoIdBroker 发送一条消息，为该类型保留一个 POID 块。标识符的块被保留的情况对于客户机来说是透明的，但这种情况使得大多数 getPoId() 请求能被当作本地调用来处理。

下面我们将继续讲述客户机端组件设计和实现的详细情况。先建立一个服务接口可以使工作并行进行。在这种情况下，客户机端小组可以和服务器端开发小组并行工作。

下 面我们来更详细地讲述客户机端序列表。显然，我们需要在 PoIdGenerator 中进行一些初始化工作。启动时需要知道应该装入哪个 PoIdBroker 的实现以及服务所在的位置。这个信息可由 PropertyManager 提供，PropertyManager 在初始化序列中被实例化，并装入属性文件。装入代理程序实现类可能会导致异常的出现。如果我们使用 PoIdGenerator 的直接单一模式，可能会出现问题。理想情况下，我们希望客户机在服务组件首次初始化时就能发现可能出现的异常，而不是在接下来对服务进行调用时才不得不去 处理这些异常。

处理这个问题的一种方法是提供一个公共静态 initialize() 方法，初始化失败时该方法将抛出一个检查到的异常。对公用静态 getInstance() 随后的调用提供了对单个实例的访问，但它不抛出检查到的异常。

客 户机请求 POID 时会出现什么情况？对特定的持续对象类型的首次请求要求 PoIdGenerator 调用 PoIdBroker，以便为那种类型保留一个块。为方便起见，我们引入非公用的帮助程序类 PoIdBlock（图 1）。该块保留了下一个有效标识的值，并且会向下一个 PoId 提供 next() 方法。一段时间后，PoIdGenerator 在用类型字符串索引的 HashMap 中高速缓存这些块。请求 PoId 时，客户机需要处理异常情况，因为获取 PoId 可能会导致远程调用。经过改进，我们分别得出了如下面的图 3 和图 4 所示的详细类图表和序列图表。

以 上就是我们关于持续对象标识服务的第一篇文章的内容。到此，我们已经定义了客户机 API，并且完成了支持“可插的”PoidBroker 的客户机组件。下一次，我们将讲述用 WebSphere Studio Application Developer 来创建后端 EJB 的情况，后端 EJB 负责管理与数据库之间进行的 POID 事务，并实现包括 PoidBroker 代理（它使用 SOAP 服务来与后端进行通讯）在内的中间层。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/374079/viewspace-130249/，如需转载，请注明出处，否则将追究法律责任。