XOE Developers Guide v1.0: A guide to application development within the XOE framework | ||
---|---|---|
Prev | Architectural Overview | Next |
XOE is not meant to be used for huge monolithic applications. It was designed based on the idea that applications or services are installed on demand, and are kept small by means of sharing as much infrastructure components as possible. This fine grained modularity of the system comes at a price. Dependencies between modules have to be tracked. The underlying module structure and processing (names, versions, query mechanism, install procedures etc.) has to be transparent for the end-user. This is achieved by means of the XOE package management subsystem.
XOE packages are physically stored as standard jar archives, containing XML and XHTML resources, Java classes, and a XML package meta data document (package.xml), holding information about dependencies, collisions, provided features, and their corresponding install methods.
Since package meta data is described in XML, and retrieved via (symbolic) XPath queries, the system is less vulnerable against the "fragile package format" problem shown by other package management systems.
The XOE package management includes a client part (package requirement detection and query), a server-side query system implemented as a SOAP service (to determine sets of required packages), and a server-side package repository (which holds the actual packages).
The install process is initiated by the client, e.g. by automatically detecting that it has no registered service for a certain protocol or content type. This leads to a request for the missing feature, which is sent as a SOAP message to the query server. The server identifies potential packages providing the requested feature, determines their dependencies and collisions, and sends back the response message listing all required packages. The client in turn checks this list against its installed packages, and starts to retrieve the missing ones (via HTTP).
Once all required packages have been downloaded to the client, the package management determines the required order of installation, and processes the packages by means of calling feature-specific installers (Java class, native library, files etc.). Installer classes can be configured, which makes the package management system extensible by means of itself. Since installer actions are defined in Java, and are executed inside of the XOE process, they can be used for complex operations like initializing and registering Java objects. By means of JNI (Java Native Interface), it is also possible for specialized installers to use platform specific functions like directly instantiating shared native libraries, without having to store (i.e. duplicate) them in the filesystem.
The installation is performed as a transaction, i.e. it either completely succeeds for all required packages, or it is completely reverted.
Even thought this process can be explicitly triggered by the user (e.g. requesting a certain application), it can also be automated up to a level where the only user interactions are to handle choices and to confirm the package installation.