next up previous contents
Next: Addressing Scheme Up: SOAP Front end Design Previous: The Extended Service Daemon   Contents

Encapsulating the IGUANA Protocol into SOAP Messages

One way to implement a SOAP Web Service in the IGUANA gateway is to encapsulate the ESD protocol into a SOAP message, as depicted in figure 43.

Figure 43: Encapsulating the ESD Protocol in SOAP Messages

Encapsulating ESD may be done in the following ways:

Encapsulate ESD code ``as is'':
The easiest way is to put the ESD code directly into the SOAP body. ESD code consists of simple ASCII encoded strings. Therefore, the most obvious way would be to define an XML element, such as <ESD></ESD>, where the ESD code can be embedded.

However, this raises some problems, as ESD code may contain XML specific data, such as characters like ``<''. This problem may be circumvented by converting these characters to XML entities93. Such XML code is called ``Encoded XML''. Another way would be to use a specific XML element, called ``<[!CDATA[...]]>''94. A sample SOAP message that embeds ESD code is shown in listing 30.

\begin{lstlisting}[caption={ESD Code Embedded in a SOAP Message}
...1:02:03:04:05:06/00:03:05 BINHEX</esd>

This method is easy to implement and already available tools and functions that are based on the ESD syntax may be reused completely this way. Moreover, the good communication abilities of SOAP/HTTP may be used95.

However, these advantages come at a high price: The gateway has to implement an XML parser with considerable hardware requirements. Moreover, the XML parser cannot be used to validate fieldbus data due to the structure of the ESD message format. Therefore the real advantage of XML documents - conveying metadata for validation and processing purposes - is left out.

Moreover, the ESD code depends a lot on whitespace96. Although the XML parser will not alter the whitespace97 and passes it to the applications ``as is'', possible reformatting of the SOAP message by client applications or debug tools could alter whitespace and make the ESD code erroneous. Structuring data with elements is more natural in XML documents and should be preferred over delimiting with whitespace.

Translate ESD code to XML Code:
Handling the ESD code requires in depth knowledge of the underlying protocol. One solution would be to translate the ESD code into another structure that can be described by WSDL, which simplifies client access. This translation may be done in various ways. A simple example is given in listing 31.

\begin{lstlisting}[caption={Translated ESD Code}
0 LON.GA...
...ata encoding=''BINHEX''>91 9F A0 3F 6A</data>

Line 1 depicts the untranslated ESD code. Line 3 to 6 shows a possible translation, where the ESD code is split and embedded in several XML elements. The example in Line 8 to 15 also splits the datapoint address into several elements.

One advantage of this translation is easy data access through the XML parser. No whitespace parsing has to be done, fieldbus data can easily be accessed by addressing XML elements. Another advantage is human readability, which is improved compared to the conventional ESD code.

Translating ESD into XML code may be done in different ways. However, there are various available standards, as shown in chapter 3. If this ``translation process'' is done in a standard compliant way, the interoperability between the Internet/fieldbus gateway and according clients will be vastly improved.

next up previous contents
Next: Addressing Scheme Up: SOAP Front end Design Previous: The Extended Service Daemon   Contents
Hermann Himmelbauer 2006-09-27