通过容器会话管理在 Java 中使用 POJO RPC 比 JBoss 更简单

发布于 2024-07-11 02:00:21 字数 585 浏览 9 评论 0原文

目前,我只知道一种在 Java 中为 POJO 进行 RPC 的方法,并且使用非常复杂的 EJB/JBoss 解决方案。

是否有更好的方法可以使用 RMI 或可以通过网络序列化和发送完整对象的方法,通过更薄的层(在 Java EE 容器内或没有 Java EE 容器内)提供类似的功能?

顺便说一句,我目前对 HTTP/JSON 序列化不感兴趣。

编辑:澄清一下:我正在尝试用更易于在容器级别管理的解决方案替换旧的 EJB 2.1/JBoss 4 解决方案。 我需要对数据库有完全的控制(计划使用 iBATIS,这将允许我非常轻松地使用相当复杂的 SQL),但我想要通过网络保留的唯一内容是:

  • 调用查找/数据修改方法(自动序列化到这里)。
  • 透明的会话控制(身份验证/授权)。 我仍然需要看看如何实现这一目标。

当然,这两个项目必须作为一个整体发挥作用。 不应向没有凭据的用户授予访问权限。

因为我不太喜欢编写 Web 应用程序,所以我计划构建一个 GUI(Swing 或 SWT),它仅管理 POJO、执行一些报告并从容器调用方法。 我希望序列化尽可能简单。

Currently, I only know a way of doing RPC for POJOs in Java, and is with the very complex EJB/JBoss solution.

Is there any better way of providing a similar functionality with a thiner layer (within or without a Java EE container), using RMI or something that can serialize and send full blown objects over the wire?

I'm not currently interested in HTTP/JSON serialization BTW.

EDIT: For clarification: I'm trying to replace an old EJB 2.1/JBoss 4 solution with something more easy to manage at the container level. I need to have entire control over the database(planning to use iBATIS which would allow me to use fairly complex SQL very easily), but the only things I want to keep over the wire are:

  • Invocation of lookup/data modification methods (automagic serialization goes here).
  • Transparent session control (authentication/authorization). I still have to see how to accomplish this.

Both items have to work as a whole, of course. No access should be granted to users without credentials.

Because I'm not very fond of writing webapps, I plan to build a GUI (Swing or SWT) that would only manage POJOs, do some reporting and invoke methods from the container. I want the serialization to be as easy as possible.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

南街女流氓 2024-07-18 02:00:21

几乎总是如此,Spring 来救援。 从参考文档中,您将需要阅读第 17 章. 使用 Spring 进行远程处理和 Web 服务

有多种方法可供选择。 Spring 的美妙之处在于您的所有接口和实现都是普通的 POJO。 连接到 RMI 或其他由 Spring 处理的内容。 您可以:

  1. 使用 RMI 导出服务
    可能是最简单的方法;
  2. 使用 HTTP 调用程序:如果是远程的访问是一个问题,这对于防火墙等来说可能比纯 RMI 更好; 或
  3. 使用网络服务 ,在这种情况下,我更喜欢 JAX-WS 而不是 JAX-RPC

Spring 还有一个额外的好处,它可以轻松、透明地为服务器和客户端进行连接。

我个人会选择(2)或(3)。 HTTP 是网络友好的。 在 Web 容器中部署很容易。 Jetty 的长期连接使您可以选择通过 HTTP(有效)进行服务器推送。

所有这些方法都允许通过网络发送复杂的对象,但它们在这方面略有不同。 您需要考虑您的服务器和客户端是否要单独分发,以及如果更改需要重新分发类文件的接口是否会出现问题。 或者您可以使用定制的序列化解决方案(甚至 XML)来避免这种情况。 但这也有问题。

使用 Web 容器可以让您轻松插入 Spring Security,它可以一开始会有点令人畏惧,因为有太多选择。 此外,HttpSession 可用于提供请求之间的状态信息。

As is nearly always the case, Spring comes to the rescue. From the reference documentation, you will want to read Chapter 17. Remoting and web services using Spring.

There are several methods to choose from. The beauty of Spring is that all your interfaces and implementations are vanilla POJOs. The wiring into RMI or whatever is handled by Spring. You can:

  1. Export services using RMI:
    probably the simplest approach;
  2. Use HTTP invoker: if remote access is an issue, this might be better for firewalls, etc than pure RMI; or
  3. Use Web Services, in which case I would favour JAX-WS over JAX-RPC.

Spring has the additional benefit in that it can do the wiring for both the server and the client, easily and transparently.

Personally I would choose either (2) or (3). HTTP is network friendly. It's easy to deploy in a Web container. Jetty's long-lived connections give you the option over server push (effectively) over HTTP.

All of these methods allow complex objects to be sent across the wire but they are subtly different in this regard. You need to consider if your server and client are going to be distributed separately and whether it's an issue if you change the interface that you need to redistribute the class files. Or you can use a customized serialization solution (even XML) to avoid this. But that has issues as well.

Using a Web container will allow you to easily plug-in Spring Security, which can be a bit daunting at first just because there are so many options. Also, HttpSession can be used to provide state information between requests.

小糖芽 2024-07-18 02:00:21

简单 RPC 正是 RMI 的构建目的。 如果您创建可序列化的接口,则可以从一个应用程序调用另一个应用程序上的方法。

Simple RPC is exactly what RMI was built for. If you make a serializable interface, you can call methods on one app from another app.

小兔几 2024-07-18 02:00:21

如果您只需要值对象,那么只需确保 POJO 实现可序列化并跨套接字写入对象(使用 ObjectOutputStream)。 在接收端使用 ObjectInputStream 读取对象。 接收端必须具有兼容版本的 POJO(请参阅serialVersionUID)。
Hessian/Burlap '协议对此: http://hessian.caucho.com/http://www.caucho.com/resin-3.0/protocols/burlap.xtp

If you only need value objects then just ensure the POJOs implement Serializable and write the objects across sockets (using ObjectOutputStream). On the receiving end read the objects using ObjectInputStream. The receiving end has to have a compatible version of the POJO (see serialVersionUID).
Hessian/Burlap 'protocol-ize this: http://hessian.caucho.com/ and http://www.caucho.com/resin-3.0/protocols/burlap.xtp

七色彩虹 2024-07-18 02:00:21

您可以通过 REST 尝试 XStream (http://x-stream.github.io/)。 易于应用于现有的一组 pojo。

由于您对 rest/json 不感兴趣,您能否提供一些有关您想要实现的目标的进一步信息?

You could try XStream (http://x-stream.github.io/) over REST. Easy to apply on e pre-existing set of pojos.

Can you give some further information as to what you're trying to achieve, since you're not interested in rest/json ?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文