Web enabled App architecture question - thin or thick client?

[Adam Lipscombe]

Folks,

I have been tasked with designing and developing a java/web version of an
existing Lotus Notes program.
The existing program has a rich UI with lots of calculations being done on
the fly (i..e when a user tabs between input fields). The target user base
is not particularly IT literate.

I have been considering the possible approaches and 3 occur to me:

1. Thick client - Swing App on client desktop talking to Web services
server.
Pros - Can have rich UI with the calc logic working as in the existing
app - i.e. when user tabs between fields.
Cons - Needs VM on client.
Needs fairly powerful machine to run it.
Not "sexy" - thin client seems to be the big buzzword these
days.

2. Thin client -Web Browser/HTML /Javascript with main processing on server.
Pros - Every machine can run it.
"Standard" UI - users are used to web browsers.
Cons: Must use Javascript to get the "on the fly" calc logic working
(i..e. App will be very clunky if it posts to the server every time users
tab between input fields). Some of the calcs are quite complex and I dont
fancy doing that level of processing with Javascript, not least 'cos the
debuggers are so awful.


3. Half-way house - Thick client running on server rendered in client
browser by Webcream or similar.
Pros - As for thin client, plus you get the rich UI and on the fly
calcs.
Cons: I am not sure about webcream in a production env. Is it reliable?



I am trying to figure out which if the most apporopriate approach. Does
anyone have a view, or done something similar? Any other approaches I have
not considered?


TIA - Adam Lipscombe

 

[Dave Ockwell-Jenner]

Folks,

I have been tasked with designing and developing a java/web version of an
existing Lotus Notes program.
The existing program has a rich UI with lots of calculations being done on
the fly (i..e when a user tabs between input fields). The target user base
is not particularly IT literate.

[snip]

Here are a few suggestions that you may want to consider:-

1. Java Web Start - being able to launch a full-fledged "thick client"
via the web. So, your delivery and distribution of the application is
via the web, but it runs on each workstation. This also has the
advantage that there's nothing for users to install... it's essentially
click'n'run provided they have a relatively recent Sun JVM installed.

2. Macromedia Flash - hear me out Flash is actually a very capable
technology for building so-called "rich" UIs, especially for delivery
over the web. It will easily support form/field validation and
communication to a back-end system.

 

[Adam Lipscombe]

Thanks for your input.

I just been looking at Java ServerFaces - it seems like it might do what I
want.
I have never used it though - does anyone know anything about it?
Will it deliver a genuinely rich UI?
Is it production quality and stable?


TIA - Adam

Folks,

I have been tasked with designing and developing a java/web version of an
existing Lotus Notes program.
The existing program has a rich UI with lots of calculations being done on
the fly (i..e when a user tabs between input fields). The target user base
is not particularly IT literate.

[snip]

Here are a few suggestions that you may want to consider:-

1. Java Web Start - being able to launch a full-fledged "thick client"
via the web. So, your delivery and distribution of the application is
via the web, but it runs on each workstation. This also has the
advantage that there's nothing for users to install... it's essentially
click'n'run provided they have a relatively recent Sun JVM installed.

2. Macromedia Flash - hear me out Flash is actually a very capable
technology for building so-called "rich" UIs, especially for delivery
over the web. It will easily support form/field validation and
communication to a back-end system.

 

[Enrique]

Folks,

I have been tasked with designing and developing a java/web version of an
existing Lotus Notes program.

1. Thick client - Swing App on client desktop talking to Web services
2. Thin client -Web Browser/HTML /Javascript with main processing on server.
3. Half-way house - Thick client running on server rendered in client

What was the Lotes program like? Was it a windows application? Maybe
the end users have grown accustomed to the existing app's behaviour.

If you have the luxury of doing so, perhaps you can try a couple of
prototypes and see how the end users respond to them. Pick your
option based on your feedback.

The concerns for installing JVMs for #1 are valid, but perhaps with
WebStart you can reduce the number of support calls related to
installation. For #2, I cannot comment on whether it would be
practical to convert all of those calculations to Javascript. It
really depends on the practicality of such a conversion. Lots of
round trips to the server does sound like it can be a potential
problem, if the existing application does all of the calculations on
the client.

 

[Enrique]

I have never used it though - does anyone know anything about it?
Will it deliver a genuinely rich UI?

Faces is pretty new. Hasn't been around as long as Swing. If you're
okay with end users installing JVMs to use the application, google it.
You'll find it.

 

[Richard Corfield]

Thanks for your input.

I just been looking at Java ServerFaces - it seems like it might do what I
want.
I have never used it though - does anyone know anything about it?
Will it deliver a genuinely rich UI?
Is it production quality and stable?

It looks a good technology to me. At last! Something that gives an
apparently stateful user interface element model where fields remember
their values for you. I've not seen that since Perl's CGI.pm. You'd still
need Javascript on the client to perform any dynamic updates of fields.
I noticed tags in Java Server Faces for inserting javascript code, for
example on field update. It also seemed to be able to do some translations
on that code for different browsers, but I've not looked in to how
powerful that is. The example I saw was for image swapping on rollover.

If you want to do it in Java, you could have an "Update" button, much like
those online shops where you change the counts of things you're buying
and press update to get the new price. If the fields you're updating are
fields that the user can also enter then changing the way its used may
help. I tried looking up ferry prices last night, and the two interfaces
I tried were terrible. I didn't always enter details in the order the
application designer thought I would, and got very frustrated when it
recalculated things I'd entered earlier, and in one case told me off
for starting in the wrong place.

For point and click development, Sun's new studio pre-release looks
interesting. It was massively resource hungry though, perhaps still beta
code. My old machine at work is only a P400 with 256M RAM.

I'm wondering how easy it is to fit JSF into an existing Struts framework,
rather than having to go full hog and switch to the controller supplied
with JSF. Perhaps I've not been reading the manuals enough.

- Richard