Scientific collaboration and, in particular, networked institutes, are dominated by the need for sophisticated computing services. This is often a problem, because different scientists often have different computers, and offering those services across all computing platforms can be difficult. This is very true of any attempt at joining research groups at different universities together into any cohesive institute: there are often pre-existing computing facilities, and local system management teams, and it is difficult to ``fit in'' the extra services the institute needs into that structure without greatly complicating both management and ease-of-use for the local departments. Any major, serious, institute, must provide a central management of these services. Without such management, the institute is nothing more than a title for a a group of researchers, and not an organic, functioning, single but distributed place of research.
It would be nice if every major application could be written in a network-based language like Java, reducing management down to maintaining a single web server for the institute. However, the latter, with any reasonable network speed, and development time, is not very feasible: It takes a long time to download a very large application, often far longer than the data files one would wish to handle with it. On a far nastier point--one certainly does not want to have to rewrite every major piece of software in use by the scientific community! This seems to limit the general use of executable content documents.
Java, and other versions of executable content, do offer a solution, however. It is easy to write software in Java that handles communication over the network with large, central, computing facilities. In particular, in an application like VIN, one can easily create so-called intelligent agents, which are simply programs that sit on the network and provide various services to the users who are using VIN to collaborate.
For instance, a PostScript viewer is a large piece of software: One agent on VIN, called PSTOGIF, automatically translates PostScript to Graphic Interchange Format, when needed, so that a (one-page) PostScript file may be displayed during a collaboration session, with no computer knowledge needed. The PSTOGIF agent uses a large program, running on a central machine, to translate the image, and then stores it where it can be found on the Web. After translation, the URL of the newly converted image is sent back to the collaborators. The translation program is a well-known one, written in the C language, and only the interface to the network (a small program) has been written in Java. Similarly, VIN uses other intelligent agents to convert between other image formats. A special type of agent, called an image broker, decides which agents can handle various requests. The system functions automatically, without the users needing to be aware of it: if somebody tries to display an image that NetScape cannot handle, VIN then asks the image broker to work on the translation. The result is that a large range of image formats can be displayed within VIN, and, on a more important development level, it is very easy to add new translation programs to the system (less than twenty minutes work, often). Of course, many other types of services can be added in this way, from library access, to symbolic (e.g. Maple) calculation services. These services can easily be distributed across the network, and do not all have to sit on one machine.
VIN, Intelligent agents, and other network uses of the Java language make it easy to place powerful already existing tools directly onto the internet with minimal development time, and with easy access from users of many different types of computers. Indeed, the intelligent agent interface described above is much like the Common Gateway Interface standard used by web servers, and already existing web services can be easily modified to provide direct internet services, without the need of the obvious overhead, and restrictions, of web servers. The browsers simply download, from the initial web server, the programs they need to communicate with these other services. This is important because the Web itself represents only a small part of the services that are currently available on the internet, and many users are often confined to that small part, simply because it is easier to use. Java, as a language, is optimized for network communication, and it is very easy to write significantly complicated network services, or interfaces to already existing services, in it. This can also be expected of all of the third-generation web languages. The rest of this paper will discuss some of the potential uses.