«

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

On Sun, 25 Jul 2004 12:53:38 GMT, John Curley wrote:

> 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.. ]

--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology

"John Curley" <> wrote in message
news:m3OMc.59201$ om...
> 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

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

RMI is really not an option

Benoit

"Alex Molochnikov" <> wrote in message
news:m2_Mc.109848$Mr4.25791@pd7tw1no...
> "John Curley" <> wrote in message
> news:m3OMc.59201$ om...
> > 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
>
>

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

/franz

"Benoit" <> schrieb im Newsbeitrag
news:4119d97f$0$205$...
> use Java Web Start and communicate with the server through servlet (with
for
> instance Tomcat)
>
> RMI is really not an option
>
> Benoit
>
> "Alex Molochnikov" <> wrote in message
> news:m2_Mc.109848$Mr4.25791@pd7tw1no...
> > "John Curley" <> wrote in message
> > news:m3OMc.59201$ om...
> > > 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
> >
> >
>
>

[vinocit]

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