SIMPL Messaging

A SIMPL message is contained in a contiguous block of bytes. A SIMPL transaction involves the transportation of this SIMPL message from one SIMPL module to another. The information in that contiguous block of bytes will have both content (actual field values) and format (field layout and field types). The content in a SIMPL message must be packed by the initiator and unpacked by the recipient. The format is subject to a prior design exercise, the result of which must be communicated to both modules involved in a SIMPL transaction.

The SIMPL core library concerns itself with the transport of a SIMPL message from one local SIMPL module to another. The content or structure associated with that contiguous block of bytes is of no concern to the core library. Only the size of the contiguous block of bytes matters to the core library.

There are many ways to structure a contiguous block of bytes into a SIMPL message. In all cases this involves laying out and specifying the various pieces of information and then arranging them in a specific order. In all cases the SIMPL communicator (sender, replier) packs the message and the SIMPL recipient (receiver, blocked sender) unpacks the message.

The structural information embodied in these pack/unpack operations relies on an agreement between the communicating parties as to the message structure. Once a SIMPL message has been created, it is stored and transmitted as a block of shared memory owned by the sender. While not commonly used, SIMPL 'C' programs can manipulate the message directly in the shared area without needing to copy the message to a local buffer. All the other SIMPL-supported languages require that the message be block copied in and out of shared memory and manipulated in a local buffer. This is commonly the way 'C' algorithms operate as well.

SIMPL message designs can be roughly classified into two schemes:

• Binary based messages.
• Text based messages.

As a rough rule of thumb, binary schemes are the most efficient while text based schemes are the most adaptable. SIMPL doesn't impose any particular messaging scheme, but rather the application architecture and deployment environment does.

A binary based message is often very convenient for 'C' programs because the concept of binary structures is readily available within 'C'. However, binary primitives such as integers are affected by host computer architecture (32/64 bit, endians). This alters size and alignment of these primitives within a binary message. While not a problem for local message exchange or network message exchange on homogeneous hardware, it does impose added challenges in heterogeneous networks. Binary messages are not natural fits to the non 'C' languages supported by SIMPL (Python, JAVA, and Tcl/Tk). While 'C' programs can readily pack and unpack binary messages by employing a 'C' structure pointer to access the fields, non 'C' languages must pay closer attention to their packing and unpacking alignment and sizing issues.

Text messages, on the other hand, are not challenged by architecture or byte ordering/alignment issues. The primitive in a text message is typically a single byte which is atomic on all systems. However, text messages are more computationally intensive to pack and unpack than their binary equivalents. To transmit equivalent content, text messages tend to be larger than their binary equivalents.

Within the context of a binary or a text message there are many possible design strategies. One of the most powerful is called tokenized messaging. Tokenized messaging divides the message into a common part of fixed size and a message specific part of variable size. The common part is unpacked and parsed first. This in turn determines the structure of the message specific part. Tokenized messages are powerful because they are so readily extensible. Binary tokenized messages, where the common element is a single atomic primitive, are exceedingly easy to parse, and as such are very popular amongst 'C' SIMPL developers.

For text messages another popular strategy is to utilize punctuation characters to separate fields. The simplest amongst those strategies is called tag: value pairing. These message designs tend to evolve very rigid syntax rules to keep the parsing simpler. XML based messaging is also used to structure text messages. XML messages have flexible syntax rules. While XML is very powerful, it tends to be computationally expensive to unpack and decompose.

For a SIMPL communication to be successful the block of bytes needs to be transmitted along with the structural information about how to interpret those bytes. Most SIMPL applications don't actually transmit this structural information, but rather rely on a prior agreement about that structure and transmit instead maps or indexes into those prior agreements. Such messaging schemes are said to be non-self-describing. XML message structures, on the other hand, can transmit structural information alongside the actual blob of bytes and are said to be self-describing. (In practice, even XML messages rely on prior agreements about how tags are to be interpreted.)

A SIMPL application typically consists of many different SIMPL modules which intercommunicate. Each communication pathway could have a different messaging scheme. However, for ease of documentation and maintenance a single messaging scheme is often chosen to be application wide.

The art of choosing a SIMPL message design strategy is a complex interconnected optimization. The original problem decomposition into SIMPL modules is often iteratively coupled to SIMPL message design. The hardware and network architecture chosen for the solution plays a role. The choice of programming language associated with a given SIMPL module is then coupled to all of the above. Furthermore, which programming languages are chosen are often a matter of expediency and personal taste. For example, it is more expedient to write a GUI in Tcl/Tk or Python/Tk or Java/Swing than in 'C'/X Windows. To complicate the equation even further, the choice of message design affects the overall SIMPL application performance and cost of maintenance and expansion.

Tokenized Binary Messages

A particularly powerful subset of binary messages are known as tokenized binary messages. They are widely used because they are also one of the simplest.

Tokenized text messaging is also possible and confers many of the same advantages as the binary counterpart.

Imagine this collection of bytes is divided into two parts. The first field of bytes which is of fixed length is always present in every message and when taken together, these bytes represent a unique message identifier called a token. In the figure above the token is a single binary word and can take on three values 0x00, 0x01 and 0x02. The token is always unpacked and parsed first. The balance of the message (which can be of variable length) represents the token context-sensitive data. When two processes wish to exchange such messages they simply agree on a token scheme and on the format for each tokenized message they want to exchange. The token represents an index (or map) into that agreed upon message formating scheme. To the SIMPL interprocess message transport layer all this is still just a contiguous collection of bytes. ie. SIMPL transports the messages, the applications compose and interpret them.

Here is a helpful analogy to illustrate tokenized messaging. When the first dedicated wordprocessor machines were introduced they looked something like a modern PC with a CPU box, a keyboard, and a monitor screen. Unlike modern word processor packages, the software on these machines came on and ran from a series of floppy diskettes. Along with each diskette came a set of cardboard templates which could be laid down over the keyboard function keyset. The template had holes where the keys could poke through and relabelled each of the keys in a more friendly way for the particular piece of wordprocessing software that was running.

If the function keys on that old dedicated wordprocessor keyboard are the analogue to bytes in our SIMPL message, tokenized messages are the software analogue of that cardboard template.

If two processes exchanged a fixed structure of data, as in the previous example code, there wouldn't be a need for tokenizing the message. Both processes would agree on the message format which captured that fixed structure. However, it is a rare software problem that can be decomposed into a single data structure (or if attempted this the structure rapidly becomes unwieldy). Furthermore, most software is extended as new features are added. This is where tokenized messaging really shines. Tokenized messaging is a software framework which, when applied to a contiguous block of bytes, promotes code reuse, and code extendability.