Web enabled App architecture question - thin or thick client?

Discussion in 'Java' started by Adam Lipscombe, Apr 22, 2004.

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

    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
    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
    Adam Lipscombe, Apr 22, 2004
    1. Advertisements

  2. [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.
    Dave Ockwell-Jenner, Apr 22, 2004
    1. Advertisements

  3. Thanks for your input.

    I just been looking at Java ServerFaces - it seems like it might do what I
    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

    Adam Lipscombe, Apr 22, 2004
  4. Adam Lipscombe

    Enrique Guest

    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, Apr 22, 2004
  5. Adam Lipscombe

    Enrique Guest

    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.
    Enrique, Apr 23, 2004
  6. 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
    Richard Corfield, Apr 24, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.