To provide a comprehensive set of tools that will be highly used and developed on, we will be providing a Java interface to every Daylight toolkit call. This interface is essential if at all we are to provide a set of Daylight tools that we wish to be highly used and developed on. The Java toolkit will provide this via an object model that is not necessarily the same as the object model used in the toolkit. Several choices are available at this stage for the development of such a model. Primary and most important are those involving communication between a Java applet and the toolserver. Some of the choices available here are

• Java applets talk directly to the toolserver via sockets. Besides having messy network code that talks between a C server and a Java applet, this will also mean that there will be no possibility to distribute functionality between the server and the client.
• Java applet talks to remote toolkit on client. This would require the remote toolkit to be installed on every client running the Java applet, an option that is not always possible or desirable. This would also require a local runtime library on the client to facilitate communication between Java and the C-toolkit.
• Java applet talks to a remote Java servlet that talks to the Daylight toolkit. The advantages of this model outweigh its disadvantages. The servlet can, in addition to authentication functions, also have remote caching functionality. The servlet could be resident on any machine, even the local client. The applet and servlet can communicate via RMI or any other model. The servlet can be extended by a customer if desired to even include their favorite protocol such as CORBA.. The servlet will have to include a local library for the Java-to-C communication and will, to that extent be platform specific. Also the servlet communication will not be as efficient as doing the same via straight sockets.