Rich Clients - what's on the backend?

[Wardie]

Hi,

I've written a Swing app that is currently standalone and I want to
turn it into a "Rich Client"

I've got servlets running in a Tomcat installation for other apps.

Q) Is the back-end of a Rich Client normally a servlet? I've been
looking at some code that packages up httprequests/responses to get
serialised Java objects sent back to the client - is this the "best
practise" for Rick Client dev?

I launch my current Swing app using WebStart so I am assuming the
answer is "yes".

Is there a definitive example/article/resource for a simple Swing Java
Rich Client (not an Eclipse RC or Spring RC one).

Many thanks,
Chris

 

[Rohit Kumbhar]

Hi,

I've written a Swing app that is currently standalone and I want to
turn it into a "Rich Client"

A "Swing" is a "Rich Client" or "Thick client" by default. What do you
mean by turning it into a rich client?

I've got servlets running in a Tomcat installation for other apps.

Q) Is the back-end of a Rich Client normally a servlet? I've been
looking at some code that packages up httprequests/responses to get
serialised Java objects sent back to the client - is this the "best
practise" for Rick Client dev?

Servlets are good if your client is a browser. You could create and
deploy ejbs [will need you to shift to app server] and your swing app
can do a JNDI lookup for the backend processing.

I launch my current Swing app using WebStart so I am assuming the
answer is "yes".

Is there a definitive example/article/resource for a simple Swing Java
Rich Client (not an Eclipse RC or Spring RC one).

Many thanks,
Chris

Regards
Rohit

 

[Michael Rauscher]

A "Swing" is a "Rich Client" or "Thick client" by default.

Even if you wrote "Swing application" instead of "Swing", I'd say: no.

Bye
Michael

 

[Thomas Weidenfeller]

A "Swing" is a "Rich Client" or "Thick client" by default. What do you
mean by turning it into a rich client?

The distinction if something is a thick or thin client depends on where
the data processing happens. If it happens on some server, it is a thin
client.

Swing has not much to do with data processing. It is a GUI toolkit. Even
a thin client would have to have a GUI system locally, because almost
the only job of a thin client application is to display data which is
processed on some server. Whether Swing is the most smallest and elegant
toolkit for a thin client is another issue.

However, since the terms "thin client", "rich client" and "thick client"
are heavily abused by marketing (or were even invented by marketing) you
will find a lot of bending of definitions.

/Thomas

 

[Wardie]

The distinction if something is a thick or thin client depends on where
the data processing happens. If it happens on some server, it is a thin
client.

Swing has not much to do with data processing. It is a GUI toolkit. Even
a thin client would have to have a GUI system locally, because almost
the only job of a thin client application is to display data which is
processed on some server. Whether Swing is the most smallest and elegant
toolkit for a thin client is another issue.

However, since the terms "thin client", "rich client" and "thick client"
are heavily abused by marketing (or were even invented by marketing) you
will find a lot of bending of definitions.

Thanks everyone for the replies. Let me clarify my position.

Firstly - I don't agree that writing an app in Swing makes it - by
definition - a rich client. That's simply not true. It's only a
"client" if there's some notion of a server on the other end -
otherwise it's just an app. That's what I have currently. It does
everything locally. Sure I launch it from a web page using Web Start,
but the lump of executable code that fires up does all the processing,
JDBC access etc. You could quibble that JDBC means there's a database
server and therefore it's a client - but that would be stretching the
point.

I've used servlets extensively for longer than I care to remember and
am happy with what they do and how they do it. Most of my work until
the recent Swing app has been web/servlet/JSP/TagLib based.

My understanding of a "rich" or "thick" client in this context is
something that has more processing power and a richer GUI toolkit than
the conventional HTML browser-based front ends. That seems to be the
case with all the stuff I've seen under the RC banner.

My motivation for all this is that my standalone Swing app has a
growing user base. Since it mainly paints pretty pictures/formats
reports from large sets of data read from a database. I want to
introduce caching etc of this data on the server side and puke it down
the wire so the Swing app (by now a "client") only needs to render it
and handle the UI events.

Recently I spent a day playing with some code that sends httpRequests
to a servlet on my Tomcat server.

Based on this work :
http://www.javaworld.com/javaworld/javatips/jw-javatip103.html

The servlet then stores a bunch of data in a bean/{POJO and serializes
it via an httpResponse to the client which unpacks it and can use the
data.

I really just want someone to tell me if

(a) I'm doing something consider "bad practice" or
(b) if there's a better way to do it - I'm on Java 5.0 now if that
changes anything


Hope this makes sense.

 

[Mark Space]

Firstly - I don't agree that writing an app in Swing makes it - by
definition - a rich client. That's simply not true.

I think I agree with you. I'm really not sure what the previous posters
were complaining about.

My motivation for all this is that my standalone Swing app has a
growing user base. Since it mainly paints pretty pictures/formats
reports from large sets of data read from a database. I want to
introduce caching etc of this data on the server side and puke it down
the wire so the Swing app (by now a "client") only needs to render it
and handle the UI events.

I think you need GWT. (Think as in sounds like, but this area is so big
it's hard to be sure.)

GWT converts Swing into Ajax so they can be run in a browser rather than
on Java. It's very Web 2.0, and a neat idea. Do your design and
testing in Java, then switch to Ajax.

http://code.google.com/webtoolkit/

Good luck.

 

[Wardie]

I think you need GWT. (Think as in sounds like, but this area is so big
it's hard to be sure.)

GWT converts Swing into Ajax so they can be run in a browser rather than
on Java. It's very Web 2.0, and a neat idea. Do your design and
testing in Java, then switch to Ajax.

http://code.google.com/webtoolkit/

Thanks Mark.

I've read some blurb on GWT but haven't looked at it in any detail. I
guess my reservation is that my Swing app has some home-grown graphing
and charting in it and I can't see how to do that in anything but core
Swing.

I was at a seminar on the Eclipse RC a while back and it looks like
good stuff, but they said any "custom rendering" - such as my graphing
stuff - would mean dropping down into Swing.

I've been distracted by the Spring RC project but have since been told
not to hold my breath on that getting to a release state.

I don't really need the client to be browser based - although I am very
interested in the whole AJAX thing (that's how I came across GWT in the
first place).

I'm really just thinking of pushing the data handling stuff up to the
server so I can do some rudimentary caching etc. I sort of envisage my
Swing app shrinking by about 25% in source code terms because all the
JDBC will be ripped out. It will just send a parameterized request to
the server (current test is as an HttpRequest) and get a lump of data
back (current test is as serialised JavaBean/POJO in an HttpResponse).

Thanks again,
Chris