79
Message Encoding
As the service agentf rameworkis designed as a distributed system covering multiple programming
languages, it is necessary that any data being passed around withina repor t,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.
Atprese nt the exact form of the XML being used is not revealed as this is being reviewed and will mos t
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 us e 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 avoidingissues with closed firewalls.
That the precisedetails are not being revealed actually makes no difference as it has no bearingin re-
lation to using the software. This is because everything is hidden under a high level API which hides
such details, thus allowing forcha ngein the formats used without requiring changes to applications
using the software. The only instance where changes might have a visibleaffect is in respect to the
NET-RPC protocol for RPCover HTTP. This would only bean 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 typeswith respect to this specification. Through introduction of
customised encoders and decoders, support for user defined scalar data types may however also be
added.