Sorry, I went back and read your post more closely... If I understand correctly you have an existing JSP/Servlet app that you want to build a Swing client for. I read your post too fast and thought you were asking in general how you could use the web tier to provide some kind of distributed back end capability for a Swing app.
In this case, with an existing web app,
RMI HTTP Tunneling (an appropriate link this time Lasse
) probably isn't what
you should be looking into - mainly this is used to get around issues where a firewall blocks the normal RMI server mechanisms, and a servlet provides a Proxy that wraps the RMI call in HTTP. Since you don't have an existing RMI app, this probably isn't what you want to do.
Web Services may still be a good option...
A lot of this depends on how your existing JSP/Servlet app is built and what it does... does it use Model 2/MVC architecture? If so, it would be much easier to swap out the
JSP frontend and replace it with a Swing frontend. (Basically what you would do is have an alternate controller servlet that passes you serialiazed versions of beans, rather than having it put the beans into request/session/application scope for a JSP to use. ) Is it using EJBs or some other form of back-end storage for data used in the Servlet/JSP app? It might be easier to access the back-end data directly from your Swing app.