Swing client to App Server

[John Curley]

Hi, All:

I've traditionally only written web applications (.jsp/.html) to app server
software. Now we're asked to write a Swing (thick client) to app server
application.

Any things to look out for? What is the usual way for calling in to the app
server? I'm used to using Struts and HTTP; but now it appears that I need
to use RMI.

Any resources out there on the web? Code examples? I've been searching but
haven't found much yet.

Thanks for your help.
John Curley

 

[Andrew Thompson]

I've traditionally only written web applications (.jsp/.html) to app server
software. Now we're asked to write a Swing (thick client) to app server
application.

Any things to look out for? What is the usual way for calling in to the app
server? I'm used to using Struts and HTTP; but now it appears that I need
to use RMI.

(shrugs) I do not know about usual, scaleable
or extensible, but the *easiest* way for an
application to interact with a server is via
URL's using .jsp/servlet to do the work on the
server side.

[ I use this to send bug reports from apps.,
I simply roll the data in an URL and do a
BrowserLauncher on the URL.. easy peasy,
you would not even need BrowserLauncher.. ]

 

[Alex Molochnikov]

Hi, All:

I've traditionally only written web applications (.jsp/.html) to app server
software. Now we're asked to write a Swing (thick client) to app server
application.

Any things to look out for? What is the usual way for calling in to the app
server? I'm used to using Struts and HTTP; but now it appears that I need
to use RMI.

Too many to mention in one post, but here are the few that came to my mind
immediately:

1. Firewalls - RMI was not designed for communication over the Internet, and
while going through firewalls is possible (I've done it myself), coding may
be somewhat cumbersome.

2. RMI callbacks - avoid them if you can (callbacks aggravate the firewall
problem). Again, they can work, even if both client and server are hidden
behind the firewalls, but is difficult to implement.

3. JRE - the client may have to be distributed with it, to ensure that the
users:
a. have Java installed on their system, and
b. the version of Java is _correct_

4. Multiplatform - testing the client on every possible platform is might
land. In the case of Web-based app, the cross-platform compatiblility of
browsers is the problem for their developers. In the case of the RMI-based
Swing client the headache is entirely yours.

Any resources out there on the web? Code examples? I've been searching but
haven't found much yet.

Sun's Swing and RMU docs and tutorials. Not perfect, but better than
nothing. Also, the Forums have quite a collection of Q&A on both.

HTH

Alex Molochnikov
Gestalt Corporation
www.gestalt.com

 

[Benoit]

use Java Web Start and communicate with the server through servlet (with for
instance Tomcat)

RMI is really not an option

Benoit

 

[Franz Bayer]

Best would be imho to write a browserlike-client.
Thats not that difficult like with RMI.

/franz

 

[vinocit]

Burlap, Hessian, EJB3.0

Try Burlap and Hessian.

Hey this EJB has turned to POJO take a look at EJB3 its much easier now to create scalable Stateless session beans