Download TEXAS Evaluate, elect and implement a platform independent test

5.5. COMMUNICATIONCHAPTER 5. DESIGN & IMPLEMENTATION
and then forwarded to TEATIME if that message is of interest to TEATIME
(based on the agreement in the communication protocol described in appendix 9). If the event is of no use for TEATIME (i.e events that the GUI
is interested in), the event is simply discarded. Refer to appendix 7 for a
complete users guide.
5.5
Communication
As mentioned before, all communication between the different parts in the
TEXAS system is made possible through the TCP/IP protocol. The decision
to go with TCP/IP came natural in order to support remote execution of
tests and also because it is a well-used, easy to implement and a reliable
protocol.
A number of message formats were investigated before deciding which format
that would work well for the data transmission. For example; Bencode, XMLRPC and Java Object Notation (JSON) were analyzed.
Together with the TEATIME project, it was decided that JSON was best
suited.
5.5.1
JSON in TEXAS
The protocol used for communication between the different parts of the system make use of the simple but powerful protocol of JSON.
One of the main reason for choosing JSON to serve as communication protocol was because of the fact that it is widely adopted and suites well for
network communication. Another reason was that the system needed an easy
protocol that allowed for interaction with other applications in a non-complex
way.
In TEXAS, all communication between TEXAS Daemon, TEXAS Manager
and TEXAS C# Wrapper is done by JSON interchangeable messages. For
example, the TEXAS manager without GUI uses JSON to communicate with
the TEATIME system. The message protocol used in TEXAS is the same
as in TEATIME but with some extensions.
The message syntax used in TEXAS is represented in the simplest way, using
(key,value) pairs. As mentioned, JSON can be compiled into more advanced
messages representing arrays and complete objects. However, in TEXAS,
35