DCT Cross-platform Messaging and XML Data Format Design

Brokered Messaging System

 Description

The cross-platform message broker employed by DCT is “ActiveMQ,” an open-source JMS- compliant application supplied by the Apache Software Foundation. A detailed description of ActiveMQ and JMS is outside the scope of this document but a brief description is warranted.

In this implementation, ActiveMQ lies between the DCT and LIG systems, which do not directly communicate with each other. Each system publishes its own data to the broker and subscribes to the other system’s data via the broker. Messages are organized using “topics,” which are string identifiers defined by each publisher. Subscribers need to specify the desired topic but do not define it. An arbitrary number of subscribers may exist for any published topic, with each one receiving a copy of each message. Only the broker is aware of which systems are publishing and subscribing to data. ActiveMQ decouples publishers and receivers and is stateless.

DCT will publish to a topic but won’t “know” that LIG components are subscribed to that topic; LIG components will likewise publish to a topic and won’t “know” that DCT is subscribed. The DCT, Broker and LIG applications are operating-system independent and can reside on one or more machines. 

Implementation

ActiveMQ Installation

The installation of ActiveMQ is simple as it does not require extensive configuration. Installation instructions and system requirements are specified at the ActiveMQ web site (see referenced documents). The main configuration file is "activemq.xml" and it is advisable to keep a copy from the previous version for reference when upgrading the application.

Java and ActiveMQ

ActiveMQ implements the native Java messaging system (ActiveMQ is written in Java); Java and ActiveMQ can communicate directly.

LabVIEW, ActiveMQ and CMS

LabVIEW does not have a native implementation of JMS. To overcome this incompatibility, the CMS library supplied by the Apache Software Foundation will be utilized. CMS is written in C++ and will be compiled into a Windows DLL that LabVIEW can use. CMS will generate and receive the JMS-compatible messages on behalf of the DCT LabVIEW application layer. CMS will notify LabVIEW of incoming messages by generating a LabVIEW event. LabVIEW will send configuration parameters and messages by passing them to the CMS library. 

Data Format

The messages will contain XML representations of software objects. The format (not the content) of XML data is defined in paragraph 4.1. The XML implemented is not the full W3C standard but uses the style of that standard.

XML Representation

1. The atomic unit of data transmission is the JMS message. Each message contains only one object (the “top-level” object), which may encapsulate child objects.
2. Top-level objects are defined in the TCS external interface document (see referenced documents).
3. Objects are represented using XML elements.
4. Each XML element is composed of one or more child elements or (inclusively) a value.
5. All values are represented in ASCII.
6. The type of a value is not represented and must be interpreted appropriately by the XML consumer.
7. uninitialized or valueless objects may be represented using the shorthand of a single tag terminated with a slash, i.e. the following two lines are equivalent:

<thing></thing>

 <thing/>

Whitespace

The following whitespace pattern is recommended but not required to maintain human readability:

• Top-level element tags are not indented.

• Child objects are indented using one space doublet (ASCII 0x20 0x20) added to the number of doublets used by the parent object. Peers share the same indent.

• If an object contains one or more objects, its start and end tags are terminated with a windows EOL (ASCII 0x0D 0x0A) sequence.

• If an object contains only a value, the start tag, value, and end tag are on one line terminated by a CRLF sequence.

These recommendations are for cosmetic purposes only. The actual whitespace used is irrelevant; End-Of-Lines can be of any type desired and arbitrary spaces and tabs (or none at all) can be used.

Examples

Figure 2 is the UML definition of a GuideTargetPosition object, which is composed of an XPosition and a YPosition object (GuideTargetPosition contains the XPosition and YPosition objects). The XPosition and YPosition position objects are peers; each contains a single value. 

<GuideTargetPosition>
  <XPosition_mm>
    <xPosition_mm>10</xPosition_mm>
  </XPosition_mm>
  <YPosition_mm>
    <yPosition_mm>2.2</yPosition_mm>
  </YPosition_mm>
</GuideTargetPosition>

<GuideTargetPosition>
  <Numeric>2.34</Numeric>
  <XPosition_mm> 
    <xPosition_mm>10</xPosition_mm>
  </XPosition_mm>
  <YPosition_mm> 
    <yPosition_mm>2.2</yPosition_mm>
  </YPosition_mm> 
</GuideTargetPosition>