next up previous contents
Next: Conclusion and Future Work Up: Analysis of the SOAP Previous: Memory Usage   Contents

Efficiency of the SOAP Protocol in Fieldbus Access

It is also interesting to examine the efficiency of the SOAP protocol in the current design. In this context, a comparison between SOAP and an alternative technology would be most appropriate. One option would be to compare the IGUANA OPC server with the ESD simulation server. Although these two technologies offer similar capabilites, it has to be denoted that the OPC XML-DA SOAP messages transport much more information than the ESD protocol such as:

Server Status:
Most OPC reply messages contain timestamps of the server receive and reply time, moreover, they contain information about the current server state.

Multiple Item Queries:
The OPC SOAP message format allows to request multiple fieldbus items in one message.

Item Properties:
OPC provides additional properties, such as Quality, the item timestamp and others.

Error Descriptions:
In case of errors, OPC may be more descriptive, such as delivering a detailed information about a server failure, while ESD errors contain only an error number and a single string.

However, many of these features are not needed in a connection-oriented protocol, such as ESD: For instance the ``ClientRequestHandle'' that helps to distinguish between SOAP messages makes no sense with the ESD protocol. Also the receive/reply timestamps will make sense for SOAP Web services where messages may be sent through various paths and proxies but are probably useless in a connection-oriented protocol. Moreover, in many situations a very simple fieldbus read suffices, hence many of the extra OPC features are not needed for simple applications. Therefore, from the perspective of a fieldbus client with very basic requirements, a comparison between ESD and OPC XML-DA seems to be possible.

SOAP certainly has various advantages over proprietary fieldbus protocols, such as interoperability, human legibility, firewall passing and documentation with WSDL documents, as already discussed in chapter 2.3. Nevertheless SOAP has some disadvantages, which are as follows:

SOAP is not Simple:
Although the simplicity of SOAP was initially a main goal, the standard became quite complex. Despite supporting frameworks, the construction of SOAP messages is quite complicated, as already shown in chapter 6.2. A simple protocol such as ESD may be easily implemented by hand, while parsing SOAP messages requires a framework.

To give an example, the implementation of the ESD protocol has 615 code lines, while the implementation that reads OPC SOAP messages into custom data types need 1500 lines of code158 and additionally requires a complicated framework.

SOAP has a huge overhead:
The price for the convenience of XML is that the protocol gets bigger and the parsing produces extra server load. Figure 78 depicts the consequences of this overhead.

Figure 78: Comparison Between ESD and OPC

It can be seen that the throughput of the ESD server is approximately 25 times higher than its OPC counterpart. Moreover, the network load will be less due to a far smaller message size159. It can also be observed that the ESD server memory usage is lower as no XML parser and SOAP framework is needed.

The SOAP message size will probably not be a problem to modern networks. It was observed with a network analyzer that 100 OPC Read requests led to a network traffic of 300kB160. A typical OPC XML-DA server that does not handle more than 5 requests per second, would put a load of 15kB/second on the network, which requires a network speed of approximately 128kbit/second.

The biggest problem may be the high memory requirements, as embedded hardware may have limited resources and cannot provide as much memory as the server would need. However, it is very likely that server implementations in the C programming language consume much less memory and would therefore fit on such hardware.

Toolkits support only HTTP:
Theoretically, SOAP messages could be transported via various protocols, however nearly all current SOAP toolkits support HTTP as a transport protocol only. Although HTTP has its strength, it also has weaknesses such as the following:
Compared to a connection-oriented protocol such as ESD, HTTP is relatively slow.

HTTP is stateless, therefore more complicated tasks like transactions are very difficult to perform and cause the requests to contain enough information for the server to provide an ACID161behavior which is needed for many applications162. Call backs or events from the server to the client are not possible. HTTP is strictly a request/response protocol.

Some toolkits also provide support for SMPT, which has additional routing capabilities and enables asynchronous notifications, but SMTP is probably inappropriate for OPC as the routing of the SMTP messages may lead to high latencies.

next up previous contents
Next: Conclusion and Future Work Up: Analysis of the SOAP Previous: Memory Usage   Contents
Hermann Himmelbauer 2006-09-27