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:
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:
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.
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.
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.