My workgroup is planning the migration of a successful three-tiered application from a fat-client (VB/ TP-with-c++ objects environment) to a J2EE environment. Our customers are used to having the functionality a fat-client affords (F1 for help, multitude of visual controls like tabs, tab-key to next field, etc.) Does anyone have any advice in weighing the Swing client versus browser for client decision? Any studies regarding projects that chose to use Swing (for usability reasons or ?) or a browser (for configuration and distribution or ?) A list of the things you may need to compensate for if you choose the browser model (and maybe even suggested ways to compensate)? Any other advice? Thanks!

In our application, we weighed this one pretty heavily. It mostly comes down to your customer base and maintainence. We went with Swing in the Java Plug-in (1.3) because we needed a complex UI that just wasn't possible or feasible with html. Our customers though are on an extranet, so we could 'dictate' this and maintain it easier than if it was a public domain type of application. Another option for the Swing app would be to use Java WebStart, which is similiar to the Plugin, but doesn't require a browser. It has the same sandbox type of architecture, and allow auto-updates of the application, much like an applet.

Html front ends are great for a broader audience and can be easier to maintain, the client doesn't have to install anything, other than a browser of course, and can certainly look 'prettier'. Of course you still have to be concerned about cross browser issues, such as JavaScript, CSS, etc.

Robert

The other approach is to retain your fat-client and reengineer it to communicate with your J2EE backend through servlets. This way, your user don't have to relearn the interface and you can keep a large part of your investment on the fat-client.

Benedict Chng

There's no need to use servlets between your client server. You should be able to call to the EJB's directly. HTTP is a poor performing protocol for distributed applications.

Dave Wolf
Internet Applications Division
Sybase

Is there a firewall issue here for client-server communication over the internet without using HTTP protocol?

Furthermore, are there library available for VB/C++ clients to talk to the server using RMI protocol?

The other approach is probably RMI-IIOP but if I'm not wrong, they tunnel over HTTP.

Benedict Chng

Well I can speak on these answers for EAServer.

1) Our InitialContextFactory can use either IIOP or can use IIOP tunneled inside of HTTP. We will automatically tunnel only when needed. Our runtime also supports things like reverse proxy forwarding and network address translation issues you might find. So firewalls shouldnt be much of an issue.

2) EAServer does provide a C++ runtime which can connect to EJB's in EAServer. We use IIOP and have the same firewall features as above.

So in short, yes you can have C++ clients connect directly to the EJB's using IIOP or tunneled IIOP for firewall penetration when using EAServer.

Dave Wolf
Internet Applications Division
Sybase

Thanks everyone! I appreciate all your time and thoughts.

Rick