As we have discussed, it is very natural to use web hardware and software to implement control of metaproblems [16]. Although we only described earlier the dataflow model for this, one can, of course, use these ideas for any application with linked components that have relatively large chunks of computation that dwarf the latency and bandwidth implied by using the Web as a compute engine. In fact, we can include our recently completed RSA130 factoring project [17] in this class. This distributed the sieving operations over a diverse range of clients (from an IBM SP2 at NPAC to a 386 laptop in England) under the control of set of servers. This was implemented as a set of Web server CGI Perl scripts FAFNER [7]. These created daemons to control the computation on each client which returned results to the server that accumulated results for final processing to locate factors.
We can extract two types of computing tasks from our factorization experience [1]. The first is the resource management problem--identifying computer resources on the Web; assigning them suitable work; releasing them to users when needed, etc. A sophisticated Web system ARMS [18] for this is being developed by Lifka at the Cornell Theory Center. Well-known distributed computing systems in this area include LSF, DQS, Codine and Condor (see review in [19]), and this seems a very natural areas for the use of Web systems including linked databases to store job and machine parameters.
The second task is the actual synchronization of computation within a given problem--resource management, on the other hand assigns problems to groups of machines and does not get involved with detailed parallel computing algorithm and synchronization issues. Here, we see two general concepts. One is support of the messaging between individual nodes that creates a virtual (parallel) machine out of the World Wide Web.
This low level support is called WebVM and should implement the functionality of parallel systems, such as MPI in terms of Web technology message systems--either HTTP or direct Java server--server (client) connections. Here, the most elegant model is perhaps based on a mesh of Web Servers [20] although today's most powerful implementations would use like FAFNER, a mesh of Web clients controlled by a few servers [21]. In the spirit of WebWindows, we can expect servers or server equivalent capability to become available on all Web connected machines. Note that the natural Web model is server-server, and not server-client and indeed this supports the traditional NII dream of democracy with everybody capable of either publishing or consuming information.
On top of WebVM, one can build higher level systems, such as the distributed shared memory model (called WebHPL) or more easily an explicit message passing system, such as the dataflow model. WebFlow supports a graphical user interface ([1], [2], [16]) specifying metaproblem component linkage and one can naturally design domain specific problem solving environments in this framework. One would support scripted ``little languages'' (designed for each application) at the top level a) (in classification of Section 4, which would allow for more flexible and dynamic metaproblem component linkage.
Now is, of course, a confusing time for there are as many compute-web implementation strategies as there are major players in emerging Web technology--especially as we evolve from powerful, but rather ad hoc server side CGI scripts to integrated dynamic Java client and server systems. Thus, now is not the time for ``final solutions'' but rather for experimentation and flexibility to examine and influence the key building blocks of future Web computers.
Finally, note that the Web encourages new models for computation with problems publishing their needs and Web compute engines advertising their capabilities and dynamic matching of problems with compute resources.