2.4 Models of Components on the Web

Our first model of behaviour on the Web is going to follow reasonably closely the simple example of the previous section. The components we will model will be clients and servers. A Web server is going to be modelled as a component which is a source of pages which can be requested over a unique channel. The Server is defined as follows

Server(db, s) = s?(p, c) . c!db[p] . Server(db, s)

The server listens on channel s for a communication of the form (p,c), which is a request for page p to be transmitted on channel c. We assume db is a database of pages and that db[p] looks up the page named p and returns it (or some default page, perhaps with an error message in it). This page is then returned as requested on channel c and the behaviour repeats itself.

Consider how a client will identify a resource on the Web. It needs to know the channel to the server and the resource name (page name) on that server. So, the client knows a pair (s,p) and uses this to send a message to the server of the form s!(p,c) which is a request for page p to be returned on channel c, exactly as the server is expecting. We can think of (s,p) as being a URL.

Suppose now we model the client as having a set of bookmarks, all of which are such URLs. For example the client's bookmarks might be the set

$$bm1 = \{ (s1, p1), (s1, p2), (s2, p1) \}$$

where the client knows of two servers and of one or two pages on each. The behaviour of a suitable client might be

$$Client(bm,c) = \sum (s,p):bm~ .~ (s!(p,c)~ .~ c?q~ .~ Client(bm, c))$$

Now if db1 and db2 are the databases served by the servers on channels s1 and s2 respectively then the following process exhibits a typical browsing behaviour.

Client(bm1,c1) | Server(db1, s1) | Server(db2, s2)

The client arbitrarily asks for one of the pages it knows of from either server. This it receives back on its private channel. The model doesn't describe what then happens to the received page q. Effectively it is discarded.

This model is unsatisfactory in many ways which we will proceed to fix. Firstly, the client can only browse pages it knows of at the outset. To overcome this we assume that when a page q is returned it may contain other URLs which the client can then select. Suppose the function $\hbox{{\it URLs}}(q)$ returns a set of URLs obtained from the page q. For example, we might have

Now we can modify the client to behave as follows

$$Client(bm,c) = \sum (s,p):bm~.~(s!(p,c)~.~c?q~.~Client(bm \cup \hbox{{\it URLs}}(q),~c))$$

where the client collects all the URLs from each page it visits and adds them to its set of bookmarks (it's now a kind of Web crawler).

Readers should be able to convince themselves that if the client starts in the state $Client(\{(s1,p1)\},c1)$ then it will eventually be able to collect all the URLs on the pages on each of the servers which is running.

Each of the processes Client(bm,c) and Server(db,s) can be seen as components from which we can build various configurations of client-server systems. In practice, much more elaborate processes than these will be required to model realistic systems. But, for this short paper, our objective is to show how the pi-calculus can model dynamic systems, which are reconfigured as they are executing. To this end let us elaborate the client just one more time, this time to download a new application.

Suppose that we have a predicate isAppl(q) which can determine if a resource q is a simple page or an executable (client-side) application. If isAppl(q) returns $\hbox{{\it false}}$ then q is a simple page. If it returns true then q is an application and compile(q) is the loadable process which the client can execute.

We modify the client to behave as follows

Now the client can continue to browse but a new application is running locally which presumably provides some useful service.