Representing Fieldbus Data and Services with SOAP

SOAP Web Services installed on Internet/fieldbus gateways have to represent fieldbus operations and transport fieldbus data. Therefore fieldbus data has to be encapsulated in SOAP messages in some way.

A SOAP message consists of the SOAP envelope that contains the SOAP header and the SOAP body, as depicted in figure 11. The SOAP body, where the fieldbus data will be placed, contains XML code which has to comply to the SOAP specification. The SOAP standard constrains this XML code in many ways but leaves the developer many options in choosing suitable XML code for his data. Therefore Fieldbus data may be represented by SOAP messages in various ways.

The format of the SOAP message is specified by a WSDL document, which contains XML Schema code that specifies the format of the SOAP body. In many cases WSDL documents and therefore the whole structure of SOAP messages can be automatically generated by developer frameworks. However, the format of the SOAP message has to be specified in case of standardizing SOAP Web Services, moreover, the format has an impact on the following issues:

Readability:

SOAP messages will normally be parsed and processed by machines. However, human legibility of these messages is a huge advantage for debugging or testing purposes.

Listing 18 shows two SOAP bodies which provide the same functionality. It is obvious that the first body is far less readable than the second.

language=XML

It has to be taken into account that readability comes at a cost - as listing 18 shows, the second SOAP body is a lot larger than the first. Hence there may be cases where a small message size is preferred to readability.

Representation of data types:

Fieldbus data may be transported in many ways. It can, for example, be transported as simple strings, or it may be mapped to SOAP data types. Data hierarchies or structures may be expressed by XML in various ways.

Extensibility:

Requirements to Web Services on Internet/fieldbus gateways may change over time. Therefore it is important to specify SOAP messages so that they can be extended in the future. Listing 19 depicts an example SOAP body that describes a fieldbus sensor that contains two values (Line 3 and Line 7) with three attributes. The client de-serializes the message according to the order of the XML elements. This message is hard to extend, because if an additional attribute is needed and is appended to the other attributes in the structure, clients will not be able to understand the message⁷³.

language=XML

Validation:

SOAP messages are validated by an XML parser according to constraints defined by XML Schemas. The XML structure and the encoding has impact on the validation process which has to be taken into account when designing SOAP messages.

Fieldbus data embedded in SOAP messages may be validated by the XML parser. This is accomplished by constraining data by XML Schema, such as assigning specific data types to elements where fieldbus data is stored, such as <display xsi:type = "xsd:string">Sensor1</display>. The huge advantage of this way is that all validations are done by the XML parser, so it is not necessary to create one's own validation algorithms to check the correctness of fieldbus data.