How to make my Java Swing application a Client-Server application?

Question

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?

Crosby

Answer 1

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.

Mendacity

Answer 2

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.

Imamate

Answer 3

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.

Empery

I see, I've never used J2EE before. But I think it's time to do it now then ;) Thanks. If there isn't any lightweight-solution. – Crosby

There are lots of lightweight solutions, but you will run into and solve many problems that J2EE has already run into and solved. I recommend at least reading about a free J2EE framework enough to know about all the features--that way you may notice potential problems that you will run into that they may have already solved. If you really still feel safe, use RMI. J2EE provides (pretty much for free) redundant servers and failover with guaranteed message delivery and other stuff that can be really hard to get if you decide you want it later. – Empery

The problem with Java EE is that in addition to solving the problems you have, it also solves a ton of problems you don't have, yet subjects you to them. – Mymya

@Mymya Seems like if you are using up-to-date tools that shouldn't be an issue. I assume most of the problems you are talking about are configuration issues which should be mostly easy with new tools and not too much mix & match. Lots of the other problems have gone away in recent version (Beans are much easier to work with, etc), but if you have different experiences I'm actually curious as to where you've encounterd problems. – Empery

@BillK Basically there is just a lot to learn and it generally ends up overkill. You really need to understand how Java EE works to use it, but it is complicated because of the great power and flexibility. It does stuff you might not care about like clustering. It is difficult to decide what you need when you don't even know what your choices are - so you end up sorting through (and trying) a few of the Java EE technologies before you can decide which ones to use. Then there are a bunch of competing technologies which claim to be superior so then you end up investigating them too. – Mymya

I understand what you mean. I guess my thought was that once you reach the point that Jonas has it is probably worth starting to bite that bullet, otherwise you keep finding "One more technology" you need to add to your stack and you end up with a mess. – Empery

Answer 4

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.

Mucilaginous

Answer 5

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.

Nasho

But using HTTP, I can't Push out the notifications!? – Crosby