79
Message Encoding
As the service agent framework is designed as a distributed system covering multiple programming
languages, it is necessary that any data being passed around within a report, request or response be se-
rialised into a form suitable for transmission as part of a message. At present the encoded form of the
data uses a subset of XML. That is, it would qualify as being XML, however to make the implemen-
tation easier, the code for decoding such messages will not accept arbitrary XML.
At present the exact form of the XML being used is not revealed as this is being reviewed and will most
likely change. Further, the protocol used between message exchange endpoints is unique to this soft-
ware. It too is being reviewed and will most likely be changed to use some more commonly accept
form of handling message boundaries. Any new mechanism will likely also be designed to be able to
proxy through HTTP servers, thus avoiding issues with closed firewalls.
That the precise details are not being revealed actually makes no difference as it has no bearing in re-
lation to using the software. This is because everything is hidden under a high level API which hides
such details, thus allowing for change in the formats used without requiring changes to applications
using the software. The only instance where changes might have a visible affect is in respect to the
NET-RPC protocol for RPC over HTTP. This would only be an issue if you tried to write your own
client for this protocol.
The one aspect of how data is encoded which will not change is in relation to the means of identifying
different types. Here the XML Schema Datatypes 2001 specification is used as a guide, with Python
types being assigned corresponding types with respect to this specification. Through introduction of
customised encoders and decoders, support for user defined scalar data types may however also be
added.