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.

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.

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.

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.

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.