The technology choices are driven by a number of criteria:

• Must interoperate well with DCM4CHE, being able to use the database and existing DCM4CHE services. 
• Must provide a light-weight browser based interface, with versions available from mobile device browsers up to full, modern browsers using AJAX for smooth, fast interactions.
• Must allow for development piece-meal with different parts of the interface and design being contributed by different groups (although driven from a single location/overall design.)
• Must be licenses under an appropriate choice of license.  Thus, MPL or LGPL is required for all libraries that are used.
• Should be stable, well tested and known technologies.

Given these criteria, some basic choices have been made:

• Java for the server components
• EJB3 for model and controller components.
• Simple RESTful services for all data available from the server and for saving/storing of data (post XML to a service), with well defined XML.
• JSF and Facelets for View components, server side (although mostly only Facelets is used - JSF is mostly ignored and is only used as a container to provide variables and parsing to components.)
• Default browser view
  • Javascript to manipulate the local view with low-flicker/no page redraw most of the time.
  • XML for the raw data (search results etc)
  • XSLT to transform the raw data into a viewable component. The Facelets generates the XSLT documents, not the raw data.
  • CSS for styling and control over layout. Facelets may generate the CSS as well at some point.
  • Frames and (and perhaps IFrames) for sub-components and to manage nested relationships.
  • JPEG for images
  • PNG for icons
• Javascript free version (for security conscious users)
  • Uses same server model as regular version, but posts cursor positions and actions and redraws entire page as required.
• Mobile browser view/low-end browser
  • Mobile profile, extending the Javascript Free version
  • Should re-use the XML data models, but perform server side XSLT
  • Avoid using frames, but change pages as required.
  • Mobile CSS profile, extending the default browser views as applicable.
• In general, the application will only be configured to run under JBoss. That isn't to say it can't run under other environments, and in fact it should be able to, just that no installation or configuration will be provided for other platforms.

External Components to be Used

Component Management: EJB3 and Seam

Using EJB3 to create and manage components is a given based on what other parts of dcm4che are doing, and seam extends this management by allow easier lookups and control. The basic technologies being used here are registration of components, creation of components, lifecycle management etc. As well, seam provides some very useful lifecycle management for POJOs as well as for EJB3s that associates components with specific conversations with a browser, and manages expiring of that data as appropriate.

Logging: SLF4J logger

This allows better interaction with the JBoss default logging setup, and is also the logging used with Dcm4che2. It easily allows replacement of the logger with the Java default logger just be replacing a jar file (no recompiling required), in case the user wants to deploy to a server that uses the Java default logging. Internally, SLF4J in the default configuration for Xero uses Log4j. It could have allowed the default to be the Java logger, but that causes ERROR lines all over the place in the logs for JBoss.

XSLT Access

The Sarissa library provides browser independent access to XSLT transformations from Javascript, as well as standardized XMLHTTPRequest calls. This will be extended with some standard methods to interact with the controller components via standard actions, as well as standard actions to update local copies of XML data.
Sarissa maybe extended for Konqueror to support the Google XSLT library, if Konqueror support becomes important at some point. This would require improving the Google XSLT library as well to support the document() method.

Browser History: RSH - Really Simple History

RSH is a Javascript library that allows browser-version independent manipulation of the browser history, so that things like the "current" page and the last set of pages can be updated without having to refresh the page. Understanding how this interacts with choice of UIDs etc will be critical, as the "current" can't be changed before a # sign if the browser doesn't redirect to the new page.

Image Reading and Generation from DICOM: DCM4CHE WADO Component

The DCM4CHE WADO components will be used for Xero, but they are currently insufficient for Xero requirements in terms of general functionality as well as in terms of performance for certain types of displays. Thus, they will be re-written using a custom filter-chain framework that allows new operations to be plugged in, and has efficient caching of image data, to allow real time image manipulation to be done.

Patient, Study, Series and Image Searching: DCM4CHE2 NET Components

The initial implementation will use this design, but subsequent implementations may choose to use other designs such as a direct database component using Hibernate or XDS-I registry queries etc. Keeping it to use regular C-Finds via the DCM4CHE2 components has the advantage that another server can be used to find data, however, efficiency for certain types of search may dictate direct database queries. So far this has not been required, and the performance of C-Finds appears to be quite good, especially using the private SOP classes to return all available data.