An archived xbook session is called the subxbook of a xbook. During a xbook session, we store all of the user's input parameters and the output that is sent back to the xbook client. The output is referred to as a page and can contain status information about the job it launched, URLs to data, meta-data, etc. A page can also contain another form (e.g., to monitor job status). Therefore, each xbook can emit multiple pages and are stored in sequence in order to be browsable by the xbook client. When we archive a page that contains a html form, we edit the page so that the default input parameters correspond to the the input parameters the user used during the session. A subxbook also contains the xbook handler script and is a executable xbook as well. This allows users to re-execute a xbook with the same or similar parameters.
Each xbook also contains a properties file. This a xml file containing meta-data which will be published into a xbook directory service. It will also contain a mapfile which controls access as to what users can execute the xbook. The mapfile is just a list of user DNs.
The xbook repository is implemented over the file system. Figure 2.3 shows the layout of a sample xbook repository. The repository contains n xbooks labeled xbook-1 to xbook-n. The contents of xbook-1 are a html form which is the starting page that is sent to the user when they request the xbook, the handler script which contains the xbook implementation, the properties file, and the archive which stores xbook sessions. The archive contains m sessions or subxbooks. The first subxbook of xbook-1 is also shown, subxbook-1. It contains everything that xbook-1 did plus the pages collected during the session.
