2. Distributed Object Computing Architecture

Corporate Intranets, which use Internet standards and protocols as a means of communication, are being rapidly developed as a cost-effective method of sharing data resources and distributing reusable software components¹⁶. Pharmaceutical companies are investing heavily in data-intensive technologies, such as those associated with high- throughput screening (HTS) and combinatorial libraries¹⁷, and there is a growing requirement that Intranets should support multiple views into such stored information by making use of data objects, which contain the same core information but allow different users to view different attributes of the object depending upon their requirements. There are, therefore, a number of reasons for extending VChemLab beyond the simple client- server structure described above and developing an application which would enable users to remotely interrogate a fully integrated chemistry database, containing entries for 3D structures, spectra, and physicochemical and biological data.

Scalability- While the current structure would probably extend to 100's of molecule entries for the downloaded JavaScript arrays, browsers are not designed for large-scale data handling applications. Hence, we need a design which would allow users to submit searches on a full database remotely to a server, before downloading a manageable subset to the browser.
Searchability- A properly constructed database would allow users to conduct chemical substructure searching and store associations between different chemical and biological data types, such as those derived from HTS.
Security - We would like the ability to restrict access in certain project areas and also allow remote update of the database by designated users.

[!]

[!]

[!]

We have therefore begun to develop VChemLab for a Distributed Object Computing environment, whereby a client process operating on a local computer can have access over a Network to the methods and data handling procedures of remote objects running on a different machines. In principle, these objects would be platform, operating system and programming language independent, although this requires adherence to a heterogeneous communications interface standard such as that defined by the Common Object Request Broker Architecture (CORBA)¹⁸. Java is an object-oriented programming language which has become increasingly popular with WWW users in the last few years, with Java-based applets allowing complete client-side browser applications to be downloaded from a remote server. With the release of the latest Java Development Kit (JDK 1.1)¹⁹, it has become possible to develop a homogenous object-based distributed computing architecture, written entirely in Java, known as Remote Method Invocation (RMI)^20,21. This allows a persistent network connection to be maintained between the client-based application, such as an applet, and the remote server-based object, such as a database interface (Fig.10). In this, a Java client running on one virtual machine can request the services of the remote object, running on a separate virtual machine, by making a request to the RMI registry on the same host as the remote object. The RMI registry runs as a background application on the remote host and contains references to the active remote objects, which bind to the registry using specified service names. When the registry accepts the clients request, it returns a reference to the remote object back to the client in the form of a stub. The actual exchange of parameters between client and server is controlled by the remote object's stub and skeleton, which are client- and server-side proxies of the remote object²⁰.