The ULC link that I wrote in the previous mail is outdated... a Google
search gave me this one: http://www.canoo.com/ulc/index.html

(I don't know if it's exactly the same framework, but the name and the
intention it's the same and the homepage it's up-to-date)

On 10/9/06, Diego Fernandez <diegof79 at gmail.com> wrote:
> 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.-
>