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.