图二：分布式对象

显然，EJB的客户（调用EJB的对象）可以是任何对象，包括EJB和一般的Java类甚至是用任何 语言写的corba客户端。

从EJB的客户视角来看的话，我们只能看到一个home接口、一 个remote接口（对于实体bean的话，还可以看见一个主键类，而bean类对客户是不可见的） 。但我们从上面的论述，我们可以知道，对于remote接口中地方法调用，实际上是多态地调 用XXX_Stub类。即XXX_Stub对象对客户具有可见性（但这种可见性是透明的，即客户不知道 这种可见性的存在）。由于，XXX_Stub对象和Object Server实现了相同的接口，并且Object server真正实现了业务逻辑。所以，当在客户端调用XXX_Stub对象的方法时候，XXX_Stub对 象通过socket通信机制将方法签名传给XXX_Skeleton对象，XXX_Skeleton对象在去委托 Object Server完成业务处理逻辑。因此，Object Server本身发生了改变。我们称XXX_Stub 对象是Object Server对象的远程引用，并认为当分布式对象作为参数传递的时候，是通过引 用传递的（会产生副作用�D�D即改变参数对象），只不过这种引用是远程引 用。可以参见本文的示范代码，了解远程引用。

在J2EE中实现Observer模式(3)

在J2EE中实现Observer模式的典型错误

为了说明问题，我们从一个简单例子开始着手：假设一个或多个位于web tier层的、可以 序列化(serilizable)的Java类，想要从位于EJB tier层的一个或多个实体bean中获取数据（ 它们可能是分布在不同EJB SERVER中）。可以把web tier层的Java类看成是一个分布式异构 数据源的联合视图。显然，它们之间存在着依赖关系，而且这两个方面要相互独立（位于不 同的tier），并且当一个对象改变的同时，不知道具体又多少个对象有待改变。因此，我们 决定用OBSERVER模式来实现这个问题。把bean作为observer，把Entity Bean作为Subject。 参照图三Observer设计模式

图三：Observer设计模式

这样，就会使起observer作用的Java类对起subject作用的entity bean中具有参数可见性 ，而且由于它们可以位于不同的机器上，所有我们要为Java类实现serilizable接口，从而使 它可以在网络上传递。看上去似乎非常完美，但不幸的是：在运行的时候，我们发现客户端 并不能自动更新。究其原因，我们发现，原来Java类是通过值传递的，即entity bean中有一 个Java类的拷贝，它对拷贝进行修改，但不会影响原来的Java类。

但如果我们在另外一种情况下，把entity bean作为observer，而使Java类作为subject， 由于Java类拥有entity bean的远程引用，当subject产生事件的时候，会通知entity bean的 远程引用作相应的改动。此时与Java类位于不同tier的entity bean的发生了真正的改动，从 而实现了事件通知范型的observer模式。另外，为了使observer可以观察多个subject， entity bean要拥有observer对象，而这些observer对象（Java类）通过值传递被序列化到 entity bean中，而且这种序列化是深度序列化。由于observer只是准备从subject中提取数 据，而不是改变subject的数据，所有这时候的值传递是可行的。但是，由于EJB规

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!