The SOAP standard was initially developed with simplicity in mind. However, over time it became very complicated146. Moreover, SOAP Web services also embrace other technologies, such as XML, XML Schema, WSDL and others.
Due to this high level of complexity, SOAP frameworks tend to have difficulties implementing every aspect of the SOAP specification. This was also observed with ZSI: As denoted above, ZSI does not implement several data types, such as ``Decimal'' and SOAP arrays. However, it seems that these limitations do not apply to ZSI, other frameworks such as .NET also seem to have shortcomings. For instance, the OPC XML-DA specification defines a specific data type for arrays as the underlying frameworks lack support for this data type. Another example is the statement in [OPCXMLDA]:
Time, date and duration are not supported fully by the .NET tools. Time and date are transmitted as dateTime while duration is transmitted as a string. A ValueType Qualifier attribute is included when values of this type are transmitted between client and server.
Such missing functionality complicates the implementation and may lead to interoperability problems. To give an example, let's assume that a SOAP framework supports the ``duration'' data type and automatically serializes it as an XML Schema ``duration''. An OPC peer that is implemented with a framework unaware of this data type would therefore either reject the SOAP message or maybe decode it incorrectly, which could lead to unexpected behavior. It is expected that SOAP frameworks will evolve and provide a better SOAP standard compliance and functionality in the future. In fact, older frameworks had much more incompatibility issues than current implementations.
Another advantage which improves compatibility is the automatic validation of SOAP messages, as depicted in figure 69.
It can be seen that the client validates the SOAP message before it serializes and sends it and the server also validates the message before it hands it to the receiving server function. This validation greatly improves the compatibility of SOAP Web services, as the exchanged messages must follow a previously defined specification. Moreover, validation reduces errors as faulty messages will be rejected by the validator. However, validation comes at a cost: On the one hand, it will increase the CPU load, on the other it will add extra complexity to the SOAP framework.
As a next step, the validation facilities of ZSI were tested. ZSI does not have a dedicated validator but it does nevertheless catch various errors due to type and element checking. The results are depicted in figure 70.
For this test, various erroneous typecodes were built and attempts were made to serialize them. On the other hand, it was tried to parse manually constructed erroneous SOAP messages. It can be seen that validation of advanced features, such as enumeration is not done. Nevertheless, many errors are detected, such as wrong data types in elements/attributes.
The OPC XML-DA standard itself is simple at a first glance but tends to be quite complicated during the implementation. It is also interesting that the specification is not strictly SOAP compliant. [OPCXMLDA] states: OPC XML-DA is being developed in a manner that leverages concepts from Simple Object Access Protocol (SOAP) 1.1.
There are some difficulties and unclear sections in the OPC standard, especially with the subscription architecture. Some of these are as follows147:
Moreover, the specification does not explicitly state whether one or more clients may query a subscription. Moreover, it seems to be allowed that one client may issue concurrent SPR messages to an OPC server. The specification does not state which of these SPR's should receive changed data. This lack of information may also lead to unexpected behavior of OPC servers.