High Level Architecture

The design of Xero is intended to be many small components (like plugins) that are combined together in various ways to produce a running system. These components communicate directly, as well as indirectly via meta-data about each other. The plugins are created as a variety of different types of objects - they can be icons/images, facelet pages or fragments, JNDI objects, Seam objects or other types of components. This document is an attempt to look at the connections and responsibilities of some of the major components and how they interact at a fairly high level. The components and collaboration is shown below:

The intent of designing Xero like this is several fold:

• Small plugins allow extending the functionality or modifying the appearance of the system without major re-work, at least some of the time depending on the required functionality extension.
• Small plugins can each be tested individually, either using mock objects, or having some test data underlying the plugins and perhaps calling alternative constructors.
• A site should be able to modify the appearance of the system by adding some (simple) plugins, or add simple additional functionality by writing simple plugins (the problem here is that some "simple" functionality requires many different changes, and some "complex" functionality just requires a small number of changes - this is a fundamental problem in software).
• A 3rd party should be able to contribute to Xero development by writing one or more plugins that extend the system functionality and capabilities. This is intended to be the primary method of collaboration - a series of plugins each developed and tested separately (in the context of a full, running system), and then combined to produce a full system. It is expected that this will be combined with some number of, hopefully, smaller changes to the core functionality as required in order to expose the required functionality and allow the appropriate changes to be plugged in.

Some of the plugins will be in specific verticals - for example, the study list area, while others will be used in horizontals - eg for the help system or for buttons or controls, and yet others will be used in several areas to provide specific functionality.

The overall packaging/grouping of the plugins is shown below:

In the above diagram, the packages are under org.dcm4chee.xero, and are somewhat simplified, with some dependencies and naming conventions not fully described. As well, the packages are assumed in most cases to include both a GUI component and an EJB component. It is expected that most 3rd party extensions will be GUI extensions or additions of commands. The core framework is intended to support this, and will be extended as needed to support these 3rd party extensions.

Interaction with Dcm4che

The following diagram shows how the interaction of Xero with a PACS, in this case represented as Dcm4che is performed.

Major Groups

There are three major groups within the overall design - the Java packages provide information ("model") for the view, as well as providing local context and control ("controller"). The view components on the other hand are XML files that define what the appearance of the system is. These also contain some amount of controller, as some of the links are direct, rather than going through a controller. The view consists of XML facelet files primarily that are used to generate XSL to transform the current state and the model information into the displayed view. There is also an external component, the WADO server that provides model data in the form of JPEG images and HTML report views. This component may become a primary component of the overall design depending on how many changes are needed to this component.

Model Components

The model consists of the search, search.study and WADO packages. These provide ways to access the DICOM information. As well, the cycle package contains information on the currently selected studies of interest to the user. This is related to the search pages, but is handled as a shorter lifetime, per-user list of data.

Controller Components

The controller components are relatively weakly defined at the moment. The cycle and study areas contain some controllers that define what to display next, but most of the navigation is actually defined in the views. This probably needs to be changed and moved into a stronger separation between control and view, in order to allow better definition over different themes such as mobile, frameless HTML, pure HTML and extended HTML with Javascript and possibly SVG. Ideally, the same components should define the flow of control for each of these regardless if the flow is initiated by an HTML link or a Javascript action.

View Components

The view components are mostly organized very similarly. There is a base XML document that contains the view specific model information (such as which study is being viewed, CINE status etc). This XML document is formatted with an XSLT document that consists of multiple parts, each part used to define part of the view such as the search results table, or alternatively, part of the view such as a specific toolbar button like the navigate next/previous buttons.