aspose file tools*
The moose likes BEA/Weblogic and the fly likes question for author Aaron Mudler Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » BEA/Weblogic
Bookmark "question for author Aaron Mudler" Watch "question for author Aaron Mudler" New topic
Author

question for author Aaron Mudler

Frank Silbermann
Ranch Hand

Joined: Jun 06, 2002
Posts: 1389
I have a question about applet / webserver communication. Here's the situation. The users of my application reside across firewalls, so all communication must be via HTTP. A web application based on servlets and JSPs with declarative security provides most of the functionality, but one piece requires the richer client that can only be provided by an applet. The applet interacts with the user, and based on those interactions, requests data from the server.
The applet sandbox suffices, but because of firewalls the applet must use and HTTPSocket to communicate with the server. The applet can submit a serialized bean via the HTTP Post method, and receive a serialized bean as a binary result.
My question is, can the applet / servlet communication make use of BEA WebLogic's implementation of declarative security, or must the applet and servlet implement their own security protocol? Is there any way for the applet to inform the servlet that its request is part of the same browser session as the JSP that delivered the applet in the first place?
Aaron Mulder
Author
Ranch Hand

Joined: Feb 25, 2003
Posts: 65
You really have a couple issues here.
First of all, you can configure WebLogic to tunnel RMI (or equivalently, T3) connections over HTTP. So your applet could use normal EJB calls and/or normal object parameters without concerning itself with the mechanics of serialization and the HTTP protocol. That should save you a fair bit of work. This is covered in detail in Chapter 20 of the book, but to make a long story short, you can enable it on the server side on the (server)|Connections|Protocols tab in the console, and then use an http:... URL instead of a t3:... URL when creating a new InitialContext in the client.
Next, you can also have clients load all the classes they need from a web app runing in WebLogic, which avoids having to distribute the fairly heinous WebLogic JAR with your applet or soemthing like that. There's also a tool (utils.applet.archiver.AppletArchiver) that can calculate all the classes than an applet uses and packages them for the occasion.
On the security front, I'm not sure there's a good way to incorporate your applet into the web application session. Essentially, the applet would need to provide the cookie used in the browser on every request, and if the browser and applet used the same cookie, they should get the same session. You could also do the same thing with URL rewriting. But I'm pretty sure unsigned applets can't access cookies or URLs in the browser, so this would require some trickery (maybe have the applet make "first contact" and then have it open the web pages in the browser using the URL rewriting it was given?).
However, I'm not sure that's the best approach. Using the RMI over HTTP approach, your applet could communicate directly with EJBs, so the applet and web app could both store common data in a statefull session bean or entity beans (or directly in the database, or whatever). You woudln't be taking advantage of the web app session to the same degree, but this is kind of what stateful session beans are for...
Hope that helps.


<a href="http://www.javaranch.com/bookpromo.jsp" target="_blank" rel="nofollow">WebLogic Book Giveaway</a> 2/25-2/27
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: question for author Aaron Mudler