Java PageBox 
 New PageBox 
 Other products 

New versions of PageBox: simple to use with examples



The PageBox idea is to deploy and update Web Applications from central points called Repositories.

A PageBox agent is a specialized Web Application that process deployment requests coming from Repositories.

A Repository is another specialized Web Application that processes two kinds of requests:

This model only uses proven technologies:

It leverages on the scalable and reliable Application servers available today.


A Repository and the PageBox agents subscribed to this Repository form a PageBox constellation.

In the PageBox documentation we also call PageBox the PageBox agent.



PageBox is a form of caching. Instead of caching HTML pages, PageBox caches the code able to produce these pages. This code can use a local database or local files and can invoke Web services. Because the code cached by PageBox runs closer to the user the response time is better. Because the provider doesn’t have to send the presentation with the data the provider spares resources and the consumer spares bandwidth, a win-win situation.

Caching is commonly used on the Web. For instance proxies keep downloaded pages in cache and call the server only when they don’t have the requested page in cache. Today the Internet infrastructure is over-sized, which means that there is no value reducing the traffic on the Internet backbones. The advent of increasingly fast link between small sites and ISPs (ADSL, WiFi...) has reduced the value of running a Web application locally rather than remotely. This is very true for bandwidth and somewhat less for latency.

Internet is actually a peer-to-peer network. Routers have huge routing tables. There is even a standard, RPSL that helps the autonomous systems that make Internet to keep in sync. The response time is made of:

  1. The time spent between the PC or LAN and the ISP. This time depends on the message size.

  2. The time spent between your ISP and the server. This time primarily depends on the number of routers, which, thank to the routing tables, is almost independent of the distance between the ISP access point and the server.

  3. The server response time.

Some studies have shown that network bandwidth grows faster than processor speed. If these studies are right latency could become the next bottleneck, the routing taking place in CPUs.

Overall the value of PageBox depends on the cost and speed of PC or LAN links to Internet.

To be effective PageBox must be installed:

  1. On the consumer LAN or

  2. Close to the ISP access point

We chose to focus for the moment on the first target: providing a light-weight infrastructure to install components on LAN Web sites, these components being sometime stand-alone (it could be the case for franchised business) and sometime used in portals/WebTops.


The installation and the update of applications are costly for both customers and software publishers.

PageBox automates this process and makes it free. Two scenarios are possible:

  1. The software publisher hosts the Repository. When they buy the application the publisher gives to the customer an account allowing them to subscribe to the Repository. Then the application is automatically deployed on the customer PageBox agent(s). When the publisher updates the application the update is automatically deployed to all subscribers.

  2. The customer hosts the Repository. When they buy the application the customer gives to the software publisher an account allowing them to publish their application to the customer Repository.

Though PageBox is optimized for the deployment of Web application it may actually deploy any kind of application. The java version, which is the most advanced version to date, allows running an installation step where the application can create and populate a database or run an installation class. This facility allows designing dummy applications whose sole purpose is to update a reference database or to run a job. In that case PageBox acts like an RPC facility with the difference that the publisher doesn’t know how many machines will run the procedure and what are these machines.


Web application instances deployed from the same Repository are identical and offer the same services and serve the same requests. Moreover a Web application instance can get the location of its clones. Therefore PageBox is a framework for implementing distributed applications.

This property is used by the PageBox API. An application can use this API to send messages to its clones. An Active Naming feature allows routing a request to the most suitable instance.


In a constellation each machine may have access to a specific data set, to a special device or to a given resource. A PageBox-installed Web application instance can inform its clones on other machines about the data, device or other resource that it controls. Then any of these clones can route requests regarding this data, device or resource to the Web application using Active Naming.

This property can be used to implement data-dependent routing (distributed database) or to implement monitoring applications.


For security PageBox only needs existing and mature technology.

  1. A Repository can be configured to use HTTPS, which implies that it has a certificate. The publisher and the subscriber can check the Repository certificate. Thank to HTTPS data are encrypted.

  2. The Repository checks if the publisher, the subscriber and the Repository administrator are authenticated.

  3. In the same way the subscribed PageBox agent can be configured to use HTTPS. The Repository can check the certificate of the PageBox agent when it deploys a Web application. Thank to HTTPS data are encrypted.

  4. When the Repository deploys a Web application or when the PageBox administrator wants to use the agent’s user interface the PageBox agent checks if the Repository is authenticated.

In the java version, which is the most advanced version to date, the administrator can:

  1. Define from which Repository and from publisher a Web application can be deployed

  2. Define if the Web archive is allowed to run an installation step that can create a database and populate a database or run a installation class

  3. Run the Web application in a Java 2 sandbox with a controlled access to sensitive resources like disk or serial interface


Both the Repository and the PageBox agent implement logging and Web pages displaying the log records. The PageBox agent implements an API allowing deployed applications to log on the agent log.

The java version allows a publisher connected to the Repository to display a non-sensitive, Web application dependent subset of the agent log for troubleshooting.

The new version

The new version of PageBox has been designed to be:


We provide three flavours of the new version:

Primarily because these technologies were then terra incogita for us, we implemented first the new version in PHP and .NET. The new version reuses extensively the most effective mechanisms introduced in the first Java version, especially the publish and subscribe model. However the design is more modular. The Repository has more functions and is server-only. There is a clean separation between

  1. The distribution process

  2. The monitoring system responsible to retry deployments

  3. The installation process

  4. The API designed to be called by deployed Web applications

Though it uses the same modular design as PageBox for PHP and PageBox for .NET, PageBox for Java introduces new functions:

  1. A more scalable deployment model described in the Grid API V2. You can find details about this model in the Deployment with relays section.

  2. A delta deployment. Only the difference between the current version and the installed version is sent to the target PageBox.

  3. An installation API allowing fully automated deployments and updates.

  4. A better security model. In PageBox for Java the PageBox administrator grants installation rights to repository and publishers. The PageBox subscriber and the publisher are checked everywhere.

  5. A token API. Deployment with relays allows creating constellations of thousand and more PageBox agents. If all these PageBoxes called each other with Web services it would generate a huge number of messages. PageBox for Java implements a Token ring to address this issue. A subset of the PageBox API, the Token API allows Web application instances to broadcast or send messages to other Web application instances. These messages are stacked locally up to the reception of a token frame. Then these messages are added to the frame and the frame is sent to the next PageBox on the ring. This token ring architecture minimizes the number of messages.

  6. An improved Active Naming leveraging on the Token API. This Active Naming allows imperative matching and weighted load balancing based on application-defined criteria and on the available resources (CPU, memory and network latency).


We identified four kinds of components:


PageBox for PHP

PageBox for PHP was the first implementation of the new version.

It shows that we can implement a PageBox with a script language.

PageBox for PHP has been tested with PHP 4.0.6 and 4.1.0.

We checked that it works in combination with Apache and BadBlue.

BadBlue is a very small Web server. The idea with the BadBlue support is to show that PageBox can have a very small memory and disk requirement. The combination BadBlue + PHP + PageBox requires less memory than an office application like Word. An end user could easily run such a personal Web server and get its Web applications using PageBox.

PageBox for .NET

PageBox for .NET designed is based on the PageBox for PHP design.

It is written in C# and uses extensively features introduced in ASP.NET such as Web Forms.

Its monitoring system is implemented as a Windows (NT) service.

PageBox for Java

PageBox for Java design is based on the PageBox for .NET. Like PageBox for .NET PageBox for Java can use SOAP Web services but it implements a plug-able network layer: beside SOAP you can use raw HTTP or implement your own protocol. The reference version of PageBox for Java runs on Java Web Services Developer pack (WSDP) and on Tomcat with Axis.

PageBox for Java can be easily ported to other Application servers that support:



Reservation was developed as an example of application distributed with PageBox for .NET. It is:


GoogleControl is a PageBox control that implements a user interface to the Google API and allows setting

GoogleControl is an example tested with PageBox for .NET.


Pandora is an example of distributed application tested with PageBox for Java.

Pandora uses three Web applications:

Though Pandora is only an example it illustrates an e-commerce scenario: many portals sell some articles. The commands are processed by remote servers, which subcontract the payment processing and the article delivery to third parties.

Pandora implements two functions of interest:


Epimetheus is an example that illustrates the use of resources and extensions in PageBox.

A resource is a servlet container resource made available to the Web application through the PageBox API according to a setting defined by the PageBox administrator.

An extension is a component, typically calling native code, made available to the Web application through the PageBox API according to a setting defined by the PageBox administrator.


EuroLCC is an example allowing finding routes covered by Low Cost Carriers. Initially this list only contained European LCCs, hence the name. EuroLCC illustrates the use of the generic installation class. This installation class creates a database and tables where it stores the airport codes, the airport names and the routes.


Prometheus is a simple chat application that illustrates the use of the token API and of the Active Naming.

Reservation Controls Java controls
Polaris Grid Coordinator Grid V2
Distribution Installation NWS
2001-2004 Alexis Grandemange   Last modified