We have a swing front end that we want to convert to applets so we can run in a browser. Does it make sense to use EJBs within applets? Should we call servlets instead? With the latter, we'll have to convert from HttpServletResponse to jave objects in the applet won't we. Isn't that kind of kludgy? For the former, we run into firewall issues and having to plugin j2ee code to the browser, don't we?

We could use web services, but they wouldn't perform as well as the first two options, correct?

Thanks.

Does it make sense to use EJBs within applets?

Session beans yould be ok I guess, but its not usually done.

Should we call servlets instead? With the latter, we'll have to convert from HttpServletResponse to jave objects in the applet won't we. Isn't that kind of kludgy?

Yes its kludgy.

We could use web services...

Not a good idea for an applet.

The main problem with an applet is you are tied to thier runtime in the given browser:(

Can you use java web start?

Have to confirm that with the client. They want to webify things and have restrictions on mobile code. Signed applets are ok. I would assume then that signed jars and web start should be ok too, however, then we start running into single sign on complexities as you would have to authenticate to the swing app and web apps.

Thanks.

Also look at http://www.creamtec.com/webcream/

Hi,
A java web start application would be a more natural choice insetead of a rich applet.
Regarding communication: RMI supports tunnelling through HTTP, so I guess it wouldn't a great problem accesing your EJBs from the client applet/swing app. Here is link that I have found on google: http://www.ftponline.com/javapro/2002_09/online/j2ee_asankaran_09_03_02/. However, they say that RMI tunnelling over HTTP adds a perfromance penalty. I have't tried it and I am curious to know if it is so.
Another solution would be to use a remoting solution with servlets like Hessian: http://caucho.com/hessian/. Spring offers good integration with Hessian that makes the remoting very easy. The Spring/Hessian solution works only with stateless services. However, this is not such a big case because in your case is easier to hold the session state on your client applet/swing app.
Web services ? As long as you don't have any interoperability (with .NET) I wouldn't use them. They add too much overhead with serialization to/from XML. It makes no sense to send over the wire 1KB of XML text instead of 0.1KB of bytes (serialized objects). I don't know much about this subject, but this might be fixed with fast web services where the transport is in a binary format.

Best regards, Mircea

Thanks very much Mircea. Hussian looks very promising.

All J2EE API's (stateful and stateless and JAX-RPC as well) are available on the client side with ~150 KB runtime and no secuirty issues over HTTP.

http://www.jproxy.com

JMS chat with < 150 KB runtime over the Web:

http://www.jproxy.com/thinlet/demo.html

Cheers,
Marat