By writing your initialization code in the applet’s init() method or applet’s constructor.
We can use the java.net.URLConnection and java.net.URL classes to open a standard HTTP connection and "tunnel" to a Web server. The server then passes this information to the servlet. Basically, the applet pretends to be a Web browser, and the servlet doesn’t know the difference. As far as the servlet is concerned, the applet is just another HTTP client. Applets can communicate with servlets using GET or POST methods. The parameters can be passed between the applet and the servlet as name value pairs. Objects can also be passed between applet and servlet using object serialization. Objects are serialized to and from the inputstream and outputstream of the connection respectively.
A signed Applet is a trusted Applet. By default, and for security reasons, Java applets are contained within a "sandbox". This means that the applets can’t do anything, which might be construed as threatening to the user’s machine (e.g. reading, writing or deleting local files, putting up message windows, or querying various system parameters). Early browsers had no provisions for Java applets to reach outside of the sandbox. Recent browsers, however (Internet Explorer 4 on Windows etc), have provisions to give "trusted" applets the ability to work outside the sandbox. For this power to be granted to one of your applets, the applet’s code must be digitally signed with your unforgeable digital ID, and then the user must state that he trusts applets signed with your ID. The untrusted applet can request to have privileges outside the sandbox but will have to request the user for privileges every time it executes. But with the trusted applet the user can choose to remember their answer to the request, which means they won’t be asked again.