Toolkit Structure

Toolkit Structure

Table of Contents

• The big three
  • WAR file
  • External Cache
  • Properties file
• Environment
• Test Session
• Tests vs Tools
• Test Client vs Simulator
• Inspector and Simulator Log Viewer

XDS Toolkit has a lot of moving parts. This page attempts to define the bigger pieces.

The big three

Toolkit has three major components.

WAR file

All the operation software is packaged as a single WAR file which in deployed in Tomcat.

External Cache

This is a single directory on the machine running the Toolkit WAR that Toolkit uses as its cache. The contents of the WAR are not updated while Toolkit runs. All working files, logs, detailed configurations are maintained in this cache.

Properties file

Within the WAR there is a single properties file that contains the base configuration of Toolkit and links the WAR to the External Cache. This file is found at WEB-INF/toolkit.properties. While it can be edited by hand it is usually changed through the Toolkit Configuration tool in Toolkit.

Probably the most import property is the location of the External Cache.

This structure allows for the updating of the Toolkit WAR without loosing local data in the External Cache. In new installations the External Cache is created manually (a writable directory) and initialized automatically by Toolkit when it starts up and notices a clean External Cache. Of course, the property pointing to External Cache must be correct.

Environment

An environment defines the, well, testing environment. This includes clinical code management, TLS certificates, locally written tests, and frequently used Patients. An installation can have multiple environments defined. Why have a second (or third) environment? You need a second environment if you have: multiple code sets or certificates from multiple CAs.

Test Session

A Test Session is a type of light weight user definition. A real user can own multiple Test Sessions. They are somewhat tied to authentication. A user wants multiple Test Sessions if he is testing multiple devices and wants to keep the test results separate.

A Test Session is always tied to a single Environment.

Tests vs Tools

Toolkit is bundle of cooperating tools. Most of the tools are single purpose appliances. A good example is the Find Documents tool. It allows the user to send a Find Documents Stored Query, fully parameterized, to a Document Registry or Gateway.

There is one special tool that conducts conformance testing called the Conformance Tool. The Conformance Tool has its own extendable architecture and is configured to test any number of IHE Actor/Transaction types.

Test Client vs Simulator

Toolkit takes the approach that the System Under Test (SUT) is one of two types: a client - it starts its operation by sending a transaction (message) or a server - it starts it operation by accepting a transaction. The test client is used to start a test by sending a transaction to a server SUT. A simulator starts its work by accepting a message from a client SUT. Of course a real SUT is frequently both a client and a server - it has multiple relationships.

The Conformance Tool builds an environment where messages are sent (by a test client) and received (by a simulator). Of course it is the System Under Test (SUT) that is in the middle. One way to think about the Conformance Tool is as a test conductor (yes, think symphonic orchestra) - directing test clients and simulators towards the goal of testing a SUT. The term Orchestration will come up in the discussion on the Conformance Tool.

Inspector and Simulator Log Viewer

Two specific tools deserve discussion at this high level, the Inspector and Simulator Log Viewer. These tools allow the review of message logs from the point of view of the Test Client (Inspector) and Simulators (Simulator Log Viewer).