We are in the process of developing a swing-applet based system that requires regular interaction with multiple databases residing on more than one database server.
The options available before us, as we evaluate are:
a. Use "signed" applets ( as this is going to be essentially an intra-net application) and use JDBC connection to connect to more than one database ( which reside on servers other than the web server).
b. Use applet - servlet communication - basically, the servlet would establish connection to the databases, directly or through EJB, retrieve necessary database information and pass on the objects to the applet - the front end GUI would be controlled by the applet.
c. Use RMI
We would like to have your perspective of the three options, with your experience in this line.
The questions that come to us are:
a. If the system is essentially an intra-net application, is it okay to design with "signed" applet mechanism - how far is this method common in the market and acceptable to the clients? Is it true that the signed applet would be able to establish connection to various "identified servers" that are allowed permissions in the security file?
b. Between applet-servlet and RMI, which is a better method? What should be the factors that need to be considered? Is RMI being widely used or should we be thinking in terms of EJB, eventhough the current project is purely a Java based solution.
Your input is highly appreciated - thanking in advance for any suggestions and inputs that you may provide.
What about option d) use a swing app to make an http connection to a servlet? That would be the way I would do it. If it is an intranet app, then the network delays should be minimal. If that is the case then you probably want maximum wow factor with minimal design and build time.
However if you need to do an applet, then I would still be inclined to go via a servlet to provide a data abstraction layer. This would enable you to keep the client smaller and leaner, plus there are lots of advantages to a http style connection. RMI is going to be an overhead that you woundn't have to worry about in a applet-servlet environment, however, there will still need to be some serialisation at some point in the applet-servlet example, if you are passing complex objects, so maybe there is no benefit in that area.
The problem I encountered trying to use RMI is that RMI uses TCP connections. But your applet will surely work behind a browser; and browsers, for security reasons, don't allow TCP connections on the client side ...
I don't know signed applets. But what I believe is that an applet-servlet communication using HttpConnections would be a solution.
1) IMHO signed applets are not widely used, but you can use
ordinary applets, which are accessing other resources through
redirector servlet on server side - I mean ordinary applets
are prohibited to establish connect to other than it's own server.
So you will be forced to have special servlet on your server,
which have access to other resources on other servers - this is a
way how to avoid applets limitation.
2) RMI is a heavy solution, because all parameters/objects should
be serialized over net and if network connection is unreliable
working with system will be just a nighmare.
3) If you think that your network connection is unreliable, you can use HTTP protocol between client and server instead of RMI. In this case
you will have following benefits:
i) You can still use all of powerness of thick client
ii) Network unreliability will be defeated
iii) Sometime if you would like to port your application to a thin
client it will be done much more easier than in case of RMI
4) If you would like to use thin client your only problem will
be poorness of UI - if you can go with it - go ahead! Otherwise
use thick client with RMI or HTTP depending on quality of network.
hi
1) signed-applets are not widely used due to security reasons
2) use normal applets if you need rich User interface and use jsps if the html forms can satisfy your UI needs, keeping in mind that jsps are easier to develop and maintain ( no need for rmi or servlet-applet communications)
3)RMI is a)heavy b)complex c)java based (normaly cannot use talk to different kind of technology) d)will not pass the firewalls and proxies (TCP problem you mentioned)
my advise is to push for the jsp/servlet/ejb typical solution unless you realll really need rich UI, then go for applet-servlet communication