Package org.xiruss

Top-level classes for the XIRUSS repository HTTP API server.

See:
Description

Class Summary

AllTests
JettyXirussHttpApiRunner	Uses the Jetty HTTP server/app server to serve a XirussRepository over HTTP, returning results per the program-to-program HTTP API for interacting with a XIRUSS repository.
JettyXirussHttpViewerRunner	Sets up the Xiruss HTTP access runner.
JettyXirussRunnerBase
XirussRepositoryServerRunner	Master server runner.
XirussRepositoryTest	Tests the XirusRepository methods.

Package org.xiruss Description

Top-level classes for the XIRUSS repository HTTP API server. The server-side server itself is in org.xiruss.xirussrepository.server.

The runner is an HTTP server that has been extended to serve the XirussRepository via HTTP.

The design decision here is to do something very simple a lightweight that still provides a usuable, Web-accessible respository. The JettyXirussHttpApiRunner uses what is essentially a CGI approach to directly implement the semantics of the XIRUSS-specific URLs. The server provides a simple REST HTTP API for read/write access to a running repository.

In a more robust, production-ready system you would almost certainly want to expose the repository as a set of formal Web services fronted by a proper Web application server. However, for the purposes of this demonstration project, that level of overhead and complexity was not necessary.

The primary purpose of the JettyXirussHttpApiRunner is simply to provide usable access to a repository in order to demonstrate the basic operation and design principles of the XIRUSS repository and to serve as a very simple and easy-to-understand reference implementation of the models. They also provide a basis for easy experimentation as, by not doing do much, they do not limit the way that additional things could be done. They can also serve as a starting point for implementing more robust versions of these classes.

The design principles are about the design of the abstract object models and class-based implementation techniques that reflect those object models, not about clever ways to make the system scale and perform. Scalability and preformance are characteristics that can be added to the core system components as a secondary implementation and engineering activity, but adding them would not change the fundamental data models or public APIs. It would primarily change the implementations of the core SnapCM objects that implement the storage and metadata repository itself.

Thus, these top-level objects make no attempt to provide the sort of performance, scalability, security, or data integrity features that a production-suitable system would have to provide. For example, I've made no effort to ensure the correctness of concurrent access or even to ensure that concurrent access is possible or reliable.

See the individual package and class descriptions for additional details about the design and implementation of the objects.