On 10/8/06, Martin Drautzburg <Martin.Drautzburg at web.de> wrote:
> We are currently in the situation where we need to support a larger user base
> of apx. 500 users. Our current application includes a fat client, a J2EE
> business logic layer and a databse backend.  There are two main problems:

Ouch! Using J2EE! It's like a punishment ;) (I've been working with
j2ee for more than two years... so know how horrible is to maintain
and develop)

Some alternatives that comes to my mind:
1. Use Smalltalk ;)
St is more comfortable for "rpc", because you can do things like
dynamic proxies or "become" that are very difficult or impossible in
Java.
For commercial projects, GemStone it's a very powerful solution (but a
little expensive). With GS you get a distributed object oriented
database that solves: remote object execution and persistence at the
same time.
There are other solutions in Squeak, VW, Dolphin and VAST... but I
only have experience  in VAST and GemStone...
For example at Mercap we are developing an application with VAST and
GS  that runs unchanged in a local image or using remote objects (we
only have to "hide" the small dialect differences between VAST and GS
and the transaction handling).

The good: A really cool language ;), a 95% transparent "rpc", the
other 5% is because you have to take care of the performance and
transactions.

The bad: May be your development team doesn't know anything about
smalltalk and your current application is developed in Java :(
I think that a transparent "rpc" framework it's not suitable for a
non-reliable, slow network like a WAN

2. Use a web client instead of a fat client
You can use web pages with a lot of JavaScript to make a more dynamic client.
If the software is going to be used in a intranet you can use
Mozilla's XUL to make a more "rich" user interface.

The good: Zero installation on the client. Works good on a WAN.
The bad: JavaScript is difficult to maintain, and HTTP is stateless,
so is more difficult to program the application logic (unless you use
Smalltalk and Seaside ;) )

3. Use ULC (http://www.revasoft.com/)
I don't know if it's a good option (I've tried only the ULC goodie in
VAST that it's not supported and contains some bugs), but I think that
maybe the Java version is more polished.

Good and Bad... I can't tell you anything about the Java version of
ULC. The VAST version (a Smalltalk server with a Java UI), it is not
appropriate for a slow network.

I didn't mention WebServices because I think that they aren't a good
alternative for this kind of client (fat clients that made a lot of
remote calls to the server).
In my experience WebServices are slow,  and suffers of the same
problem as CORBA: it's a "generic"  specification (multi-language,
multi-platform) hence it's really complex (it's good for interop, but
working with them it's a pain in the ass).

I hope it helps. Regards,
Diego.-