如何使我的 Java Swing 应用程序成为客户端-服务器应用程序?

发布于 2024-08-31 10:06:39 字数 271 浏览 4 评论 0原文

我制作了一个 Java Swing 应用程序。现在我想让它成为一个客户端-服务器应用程序。当服务器上的数据发生更改时,所有客户端都应该收到通知,因此我不是在寻找 Web 服务。客户端-服务器应用程序将在单个 LAN 上运行,它是一个业务应用程序。服务器将包含一个数据库 JavaDB。

什么技术和库最容易入手?我应该使用 Sockets 从头开始​​实现它,还是应该使用 Java RMI,或者 JMS?或者还有其他更容易开始的替代方案吗?

我应该使用什么服务器库吗? Jetty 是替代方案吗?

I have made a Java Swing application. Now I would like to make it a Client-Server application. All clients should be notified when data on the server is changed, so I'm not looking for a Web Service. The Client-Server application will be run on a single LAN, it's a business application. The Server will contain a database, JavaDB.

What technology and library is easiest to start with? Should I implement it from scratch using Sockets, or should I use Java RMI, or maybe JMS? Or are there other alternatives that are easier to start with?

And is there any server library that I should use? Is Jetty an alternative?

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

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

发布评论

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

评论(5

_畞蕅 2024-09-07 10:06:39

鉴于您已经拥有应用程序,也许最简单的事情就是确定客户端和服务器之间所需的接口,并且首先重构您的应用程序以使用该接口在后端/前端之间进行通信。 在同一进程内结束

然后你就可以开始把它分开了。一个简单的解决方案是使用 RMI 将其分开(因为您正在谈论 Java 对象并具有 Java 方法调用)。 Spring 包含有用的工具来简化/自动化接口的 RMI 公开。

对于通知要求,简单的 UDP 多播(或广播)就足够了。

请注意,一旦您拆分应用程序,就会遇到问题。维护一致的数据视图、管理及时更新、处理服务器停机时的情况、拥有大量客户端时可能出现的加载问题等。从某种意义上说,将应用程序拆分为客户端和服务器只是新架构的开始过程。

Given that you have the application already, perhaps the simplest thing to do is to identify the interface that you require between the client and server, and first of all to refactor your application to use that interface to talk between the back-end/front-end within the same process.

Then you can start to split this apart. A simple solution would be to split this apart using RMI (since you're talking Java objects and have Java method calls). Spring contains useful tools to simplify/automate the RMI exposure of interfaces.

For the notification requirement, a simple UDP multicast (or broadcast) would suffice.

Note that as soon as you split your application up, you have issues re. maintaining consistent views of data, managing timely updates, handling cases when the server is down, possible loading issues when you get lots of clients etc. In a sense, splitting the application up into a client and server is just the start of a new architecture process.

桜花祭 2024-09-07 10:06:39

Mina 是一个很好的选择,作为一个网络应用程序框架,用于为此目的构建一个简单的服务器 - 它是一个比使用原始套接字更好的选择。

http://mina.apache.org/

如果您确实需要应用程序服务器,那么您可以看看JBoss。它还提供了一个远程组件(作为 Mina 之类的替代组件):

http://www.jboss.org/ jbossremoting

不过,您可能不太需要Enterprise Java Beans。在大多数情况下,一个简单的基于 POJO 的框架就足够了 - 您可以将其与依赖注入框架(例如 Guice)结合起来:

http://code.google.com/p/google-guice/

Spring。保持简单,除非确实需要,否则不要使用 J2EE 服务器。希望有帮助。

Mina is a good choice as a network application framework for building a simple server for this purpose - it's a much better option than using raw sockets.

http://mina.apache.org/

If you really need an application server then you could take look at JBoss. It also provides a remoting component (as an alternative to something like Mina):

http://www.jboss.org/jbossremoting

You probably won't have much need for Enterprise Java Beans though. In most cases a simple POJO based framework is more than sufficient - you could tie this altogether with a dependency injection framework such as Guice:

http://code.google.com/p/google-guice/

or Spring. Keep it simple, don't use a J2EE server unless you really need to. Hope that helps.

留一抹残留的笑 2024-09-07 10:06:39

这就是 J2EE 所做的大部分工作,但这是一个全新的学习曲线,因为它们已经预先解决了您将遇到的许多问题以及许多您可能不会遇到的问题,因此添加了许多新技术。

但从最基本的角度来看,J2EE 正好回答了这个问题。

This is much of what J2EE does, but it's a whole new learning curve because they have pre-solved many of the problems you will run into and many you may not and therefore add on a lot of new technologies.

But at it's most basic, J2EE answers just that question.

何其悲哀 2024-09-07 10:06:39

我曾参与过这样的项目。我们使用 J2EE 实现了客户端 Swing 和服务器端。我们使用了 EJB、无状态 bean 和消息驱动 Bean。我还参与了一个设备跟踪、管理项目。我们的客户是卡车+Swing 用户,我们使用Servets+TCP/UDP、Apache Mina 框架来处理和保持连接。

I worked in a project like this. We implemented Client-Side Swing and Server side with J2EE. We used EJB,Stateless beans and Message Driven Beans.Also I have been in a device tracking, management project. Our clients were trucks+Swing users and We have used Servets+TCP/UDP,Apache Mina framework to handle and keep connections.

失去的东西太少 2024-09-07 10:06:39

我从事 Java Swing 客户端/服务器应用程序已近 3 年了。我建议您选择 RMI/EJB。我们开发的最初应用程序是使用 RMI/EJB 进行客户端-服务器通信,WebLogic 作为服务器。

但我们后来发现应用程序中包含很多“类似浏览器”的功能,例如会话超时等,因此,我们使用了 BrightSide 通过 HTTP 包装 RMI 调用的框架。我们所做的另一项增强是用开源 JBoss 服务器取代了 Weblogic。

使用 HTTP 包装调用将变得非常方便,并且可以使您的 swing 应用程序变得非常丰富。稍后,当情况要求您严格使用网站时,您可以使用 jnlp

希望这有帮助。

I have been working in Java Swing Client/Server applications for almost 3 years. I would suggest you to go for RMI/EJBs. The initial application that we developed was doing this using RMI/EJB for client-server communication with WebLogic being the server.

But we later found out that there are lot of "browser-like" features to be included to the application such as session-timeout etc., So, we used the BrightSide Framework which wraps the RMI calls through HTTP. One more enhancment we made is that we replaced Weblogic with the open source JBoss server.

The wrapping of calls with HTTP will become very handy and you can make your swing applications really rich. Later, when the situation demands for you to use a website strictly, you can deploy your swing using jnlp.

Hope this helped.

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