Partially supported by: DARPA/Rome Laboratory, NSF, Intel, Microsoft

An Infrastructure for • Network Computing with Java Applets • Arash Baratloo, Mehmet Karaul, Holger Karl, and Zvi M. Kedem • Department of Computer ScienceCourant Institute of Mathematical SciencesNew York University • http://www.cs.nyu.edu/milan Partially supported by: DARPA/Rome Laboratory, NSF, Intel, Microsoft

Goals • Java programming language + Java-capable Web browsers are a great “one-two punch,” but… • The challenge is to fully utilize this potential given the limitations imposed by browsers. • In the context of Web-based parallel programming environments and collaborative applications, identify a set of problems, and ... • Provide a set of unified solutions

Typical Web-basedCollaborative session • Composed of • A single Java applications process • Multiple partner applets • Applets down-loaded from the application host • Applets communicate only with the application host • This is the context of our work • Examples are TANGO, JavaParty, Java Collaborator Toolset, etc

Charlotte (PDCS’96) in a Nutshell • Parallel programming model and system that provides • Predictable virtual machine to the programmer • Realizes the virtual machine on the unpredictable Web • End-user starts the execution of the manager process • Volunteers join the computation by a click of a mouse • Worker (applets) code and data is downloaded • One-click computing! • Other examples are Javelin, Bayanihan, etc.

Issues to Address • In the context of Web-based collaborative and parallel applications, … • How do end-users find a service? • E.g., how do volunteers find computations? • E.g., how do users find multi-player games? • Are users free to execute the application on any host? • Not all accessible machines run HTTP servers • How do collaborative applets communicate with each other? • Centralized forwarding agent? • Untrusted native code?

Roadmap • Goals and Motivations • Architecture • Directory Service • Class Server • Direct Inter-applet communication • Security Issues • Summary

KnittingFactory Architecture • Infrastructure (middle-ware) to support both • High-level systems, e.g, parallel programming, collaborative environments, etc. • Web-based applications • Integrated services for • Directory service • Class server • Inter-applet communication

KnittingFactory Directory Service • For highly dynamic (sometimes short lived) services that frequently register and unregister. • Considerations… • Distributed -- a necessity for the Web • Directory-server processes should not do all the work (unlike LDAP) -- scalability • Caching servers (and replication) require invalidation -- costly • Must support Web browsers -- simple language • Goal: Move most the computation and the search away form directory-server process and onto the Web browser.

Directory Service Comprises of... • Existing HTTP servers act as directory-server processes • A single HTML file contains all the necessary information • Other servers, e.g., <name,URL> • Registered services, e.g., <name,URL> • Program code, i.e., Java Script • CGI scripts to register/unregister services • Forms a directed graph

Registration & Successful lookup • Register/Unregister • Service provider sends an HTML Post message <name,URL> • Directory server executes one of the CGI scripts • Results in adding/removing an entry in the HTML file • Successful lookup • Client requests the HTML file containing data + Java Script code • The program searches the file it came from for the appropriate entry

Unsuccessful lookup • The program picks the next server (referral) to visit, assembles a new URL, and redirects the Web-browser • Browser loads a new HTML file which wipes out the program state! • The newly loaded Java script program starts executing and… • Reads the state information passed as a URL tag (#)! • Search is performed by the clients! • Implemented BFS

Issues... • Java application process requires an HTTP server running on the same host, but… • Users might not have access to hosts running HTTP servers • HTTP servers machines will become overloaded when hosting many applications • HTTP servers are too “heavy-weight” for a simple… • Coupling class servers with an application can...

KnittingFactory Class Server • Embedded Java class (applet code) server to… • … flexibly execute the application program on any host • … provide a convenient gateway for browsers to communicate with applications • That simple!

Inter-Applet communication • Browsers enforce the “host-of-origin” policy as a security measure: an applet is not allowed to: • Listen for network connections • Initiate a connection to any host other than the one it came from • Typical solutions • Use a centralized forwarding agent to route messages (e.g, Javelin, Java Collaborator Toolset) • Use untrusted code as in plug-ins and native code (e.g, TANGO, ATLAS) • But forwarding agent can become... • A bottle-neck and a single point of failure • And with native code… • Unsafe, not portable and heterogeneous anymore

Inter-Applet communication (continue) • Signed applets (JDK1.1) and fine-grain access control (JDK1.2) is too rigid for every-day users • Developers have to obtain a certificate and a digital ID from Certifying Authority (CA) • Users/administrators have to decide who to trust and how much • Wouldn’t it be nice to have direct applet-to-applet communication? • KnittingFactory Applets Can! • Implemented using Java RMI, • JDK1.1.3 and tested with appletviewer and HotJava 1.1 • Security issues will be discussed later

KnittingFactory Applet • In a nutshell • Each applet passes a Remote Reference of itself to the session manager • Manager propagates the reference to other session members • After that point, applets can communicate directly • Applets form a collaborative session simply by inheriting KF_Applet • Simplifies collaborative applications development

Security Issues • It is apparent that KnittingFactory Applets violate the host-of-origin policy, and… • It might be used to break Java security guarantees • Many thanks to Java’98 PC, referees, and many others for bringing this to our attention • The benefits of direct inter-applet communication is obvious, and… • Just as a forwarding agent can forward messages, It might be possible to forward trust (references) in a safe and efficient manner.

Summary of services... • Distributed directory service • Designed for services that frequently register/unregister • Designed for Web browsers to act as clients • Search is performed by the browsers • As much as possible, does not introduce new processes/daemons • Class Server • Simple, but execution flexibility • Convenient gateway to the application • Inter-applet communication • Simplifies collaborative application development • Removes single point of failure • Does not require native code • Open question: can we guarantee safety while maintaining flexibility of inter-applet communication?

Partially supported by: DARPA/Rome Laboratory, NSF, Intel, Microsoft