the right way to do rich clients

[Guest]

Hello,

For years my basic architecture has been a Swing Applet for the client,
an application on the server, rmi to connect the two, and straight jdbc
for persistence (recently changed to Hibernate) at the server side.
POJOs all the way.

In a desire to drop rmi and use a more web-friendly comm scheme, I
started reading about all the technologies that I've bee woefully
ignorant of, including: JBoss, servlets, SOA-SOAP, jsf, jsp, ...
possibly others. Everything I've seen seems to use form-based html for
the UI. Ick. The apps I'm involved with simply require a Swing-like
UI.

So, my question is: In the years I've been under my rock, what
technologies have come along that I should use to do rich clients in a
web-like way? Also, I've seen disparaging remarks about using Applets
for "real" projects -- what is the preferred technology (I suppose
WebStart?)?

All comments very welcome.

 

[Andrew Thompson]

(e-mail address removed) wrote:
....

...Also, I've seen disparaging remarks about using Applets
for "real" projects -- what is the preferred technology (I suppose
WebStart?)?

Yep. It gives an applet (or web-started application,
preferably) so much more than what an applet alone
can do for the end user, as well as neatly side-stepping
(most of*) the applet/browser/VM interaction problems.

* To replace them with the single hurdle of getting
a browser to handle JNLP files correctly.

What is it about your application, that cannot be
done in pure HTML?

Andrew T.

 

[Daniel Pitts]

Hello,

For years my basic architecture has been a Swing Applet for the client,
an application on the server, rmi to connect the two, and straight jdbc
for persistence (recently changed to Hibernate) at the server side.
POJOs all the way.

In a desire to drop rmi and use a more web-friendly comm scheme, I
started reading about all the technologies that I've bee woefully
ignorant of, including: JBoss, servlets, SOA-SOAP, jsf, jsp, ...
possibly others. Everything I've seen seems to use form-based html for
the UI. Ick. The apps I'm involved with simply require a Swing-like
UI.

So, my question is: In the years I've been under my rock, what
technologies have come along that I should use to do rich clients in a
web-like way? Also, I've seen disparaging remarks about using Applets
for "real" projects -- what is the preferred technology (I suppose
WebStart?)?

All comments very welcome.

Ajax seems to be a buzz-word. Certainly killed my buzz though j/k

 

[Guest]

What is it about your application, that cannot be done in pure HTML?

Well, I don't think *most* applications can be done in html...at least
not very gracefully. Code PhotoShop, or the Swing demo as html.
Anything that involves visual real-time manipulation of data seems
ill-suited for either the html presentation capabilities or the
submit-respond roundtrip for updates.

Ajax seems to be a buzz-word. Certainly killed my buzz though j/k-

Yea, not so interested in that myself. Seems very much the hack.
Plus, aren't you still stuck w/ html presentation? (you just get a
better update methodology?)


So, put another way: (How) can a Swing-based client application use
port 80 to ship messages and get data?

thanks much.

 

[Chris]

So, put another way: (How) can a Swing-based client application use

port 80 to ship messages and get data?

Use web services. There are two main ways to do it:

Have an app server return SOAP messages. Use Axis or the like. Soap has
lots of overhead and complexity, though.

Have an app server return XML in response to an http fetch. Simple,
easy, clean. In your app server all you have to do is create a JSP page
that accepts the appropriate params and returns the appropriate page
formatted as XML. You don't even need to dig into servlet programming
unless you need to get fancy.

 

[Mark Rafn]

For years my basic architecture has been a Swing Applet for the client,
an application on the server, rmi to connect the two, and straight jdbc
for persistence (recently changed to Hibernate) at the server side.
POJOs all the way.

Sounds reasonable.

In a desire to drop rmi and use a more web-friendly comm scheme,

What's the driver for this? How is some other transport more web-friendly, if
you're still using a Swing app for the client?

I started reading about all the technologies that I've bee woefully
ignorant of, including: JBoss, servlets, SOA-SOAP, jsf, jsp, ...
possibly others.

Again, what specific problems are you trying to solve? Picking a technology
without having requirements isn't likely to lead to happiness.

Everything I've seen seems to use form-based html for the UI. Ick. The
apps I'm involved with simply require a Swing-like UI.

Examples are likely to all be form-based. It's easy and works
near-universally. That doesn't mean you have to do it that way.

So, my question is: In the years I've been under my rock, what
technologies have come along that I should use to do rich clients in a
web-like way?

What do you mean by web-like? You just said you needed something swing-like.
Please describe more specifically what you're looking for.

AJAX is the hot new buzzword for getting more responsive apps in a webbrowser.
It's basically writing your UI in html and javascript, and using javascript
to make calls to the server to get data and display it without a complete
page reload.

For use inside a company, I'd far rather use Swing - it's so much easier to
write and debug, and you get a lot more control over what actually happens.
For public use, the compromizes that AJAX brings are worth it, as it's just
incredibly valuable to have no plugins, no installation (except a
semi-modern browser), and somewhat application-like in behavoir.

Also, I've seen disparaging remarks about using Applets
for "real" projects -- what is the preferred technology (I suppose
WebStart?)?

I like WebStart for Swing clients. It seems to have fewer difficulties for
users with plugin management than applets. I also like "download, unzip, and
run" methodology, or actually writing an installer, depending on requirements.

 

[Guest]

What's the driver for this? How is some other transport more web-friendly, if you're still using a Swing app for the client?

The driver is to largely to eliminate hassles w/ internet (as opposed
to intranet) use -- not bieng so concerned about firewalls and all
that. Your question to me is, in fact, my original question.

Picking a technology without having requirements isn't likely to lead to happiness.

fair enough. Another strong driver for all of this is my desire to
pull myself out from under my rock and learn something new. Hence the
shotgun listing.

Examples are likely to all be form-based. It's easy and works near-universally. That doesn't mean you have to do it that way.

Interesting. It always seemed to be html/form-based by necessity. How
can one do it differently?


thanks much.

 

[Andrew Thompson]

Well, I don't think *most* applications can be done in html...at least
not very gracefully.

Note that I was not asking about 'most applications',
the question was why does *your* application require it?

...Code PhotoShop, or the Swing demo as html.
Anything that involves visual real-time manipulation of data seems
ill-suited for either the html presentation capabilities or the
submit-respond roundtrip for updates.

JavaScript can do most of what is required, for the
two stated applications, without any round-trip to
the server.

Andrew T.