EJB中的代理对象
我正在阅读 Enterprise JavaBeans 3.1 这本书，我想知道我是否正确理解了 EJB 代理对象的概念。我现在知道它遵循代理模式，并且我已经阅读了一些相关内容。
当我们为 bean 创建接口时，我们这样做是因为我们希望实现代理模式。这对我们很有帮助，因为客户只关心我们能做什么，而不是直接绑定到一个类，而是一个可以充当真实对象的接口。
那么，容器可能会实例化实现相应接口的代理对象，并在为我们调用真实的 EJB 之前添加一些魔术代码（网络代码），因为代理对象是自动生成的，对吧？
我误解了这个概念吗？如果是这样的话，有人可以告诉我出了什么问题吗？
I am reading the Enterprise JavaBeans 3.1 book and I wonder if I have understood the concept of EJB proxy object correctly. I now know that it follows the proxy pattern and I have read some about it.
When we make the interfaces for the beans, we are doing it because we want to have the proxy pattern implemented. This helps us because the clients are only concerned about what we can do and not tied to directly to a class but rather a interface that can act as if it where the real object.
So, the container probably instantiate the proxy objects implementing the corresponding interface and add some magic code (networking code) before invoking upon the real EJB for us, because the proxy object is automatically made right?
Have I misunderstood the concept? If thats the case could someone tell me whats wrong?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正确的。如果您的应用程序仅限于本地 JVM，那么您为 Bean 编写的接口就足够了。在这种情况下，不需要代理，因为可以实例化并直接提供实现类。
EJB 的客户端无法处理其实现类，因为它们的类路径中没有这些类。 EJB 是位置透明的，您可以通过网络或从位于同一服务器上的另一个应用程序调用它们，但由不同的类加载器隔离。在这种情况下，您需要使用代理对象来编组、通过网络发送以及解编您提供给 EJB 调用的参数以及您收到的这些调用的结果。在客户端，您需要一个虚拟 EJB 接口实现，它将您的调用转发到安装此 EJB 的服务器。
代理还处理其他功能，例如围绕 EJB 方法调用启动/结束事务。
编辑：如果您好奇此类代理到底能做什么，请查看 Java 和 AOP（AspectJ 或 Spring）中的 RMI 概述。它会让您了解可以通过这种方式实施哪些类型的任务。
Correct. The interfaces you're writing for your beans would have been sufficient if your application was confined to a local JVM. In this case no proxy would be needed, as the implementing class could be instantiated and supplied directly.
Clients of EJBs cannot work on their implementing classes, as they don't have them in their classpath. EJBs are location-transparent, you can call them across the network, or from another application located on the same server, but isolated out by different class loaders. In such cases, you need to have proxy objects to marshal, send over the network, and unmarshal the parameters you supply to EJB calls and results of these calls that you receive. And on the client side, you need a dummy EJB interface implementation, that forwards your calls to the server where this EJB is installed.
Proxies also handle other functions, such as starting/ending transactions around EJB method calls.
EDIT: if you're curious what EXACTLY such proxies could do, take a look at overviews of RMI in Java and AOP (either in AspectJ or Spring). It will give you the idea what kinds of tasks can be implemented this way.
您指的是无状态（和有状态）会话 Bean 和消息驱动 Bean 的代理接口吗？
如果是这样，我认为你的理解是正确的。您似乎唯一错过的是无状态 bean 实例池的概念。容器不会根据请求实例化这些，而是在需要时提供实现。
此外，使用代理允许容器管理的事情发生：事务管理、异步线程管理等。
Are you referring to the proxy interfaces to stateless (and stateful) session beans and message driven beans?
If so, I think your understanding is correct. The only thing you seemed to have missed is the concept of instance pools for stateless beans. The container does not instanciate these per request, but instead provides an implementation when needed.
Also, using proxies allows the container managed things to take place: transaction management, asynchronous thread management etc.