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!
- Posted by: Rick Wagner
- Posted on: December 06 2000 08:38 EST
- Swing vs. Browser client design decision by Robert McIntosh on December 06 2000 09:06 EST
- Swing vs. Browser client design decision by Benedict Chng on December 06 2000 13:00 EST
- Swing vs. Browser client design decision by Dave Wolf on December 06 2000 13:14 EST
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.
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.
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.
Internet Applications Division
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.
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.
Internet Applications Division
Thanks everyone! I appreciate all your time and thoughts.