next up previous contents
Next: Interoperability between Different OPC Up: Compatibility and Interoperability of Previous: Compatibility and Interoperability of   Contents

Compatibility Issues Found During the Implementation

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.

Figure 69: Validation of a SOAP Request Message in the Client and Server
\begin{figure}\centering
\includegraphics[scale=0.7]{graphics/devel-validate.eps}\end{figure}

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.

Figure 70: Validation Facilities of ZSI
\begin{figure}\centering
\includegraphics[scale=0.7]{graphics/devel-validate-zsi.eps}\end{figure}

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:

OPC Faults may be not SOAP compliant:
The SOAP 1.1 specification states the following: The faultcode values defined in this section MUST be used in the faultcode element when describing faults defined by this specification. The namespace identifier for these faultcode values is ... Use of this space is recommended (but not required) in the specification of methods defined outside of the present specification. The set of faultcode values defined in this document is: ``VersionMismatch'', ``MustUnderstand'', ``Client'', ``Server''.. [LIV02] interpretes this section thus: Currently there are only four types of faults that can e defined by SOAP. On the other hand, the OPC XML-DA specification introduces custom faultcodes by using a custom namespace. It is unclear whether this violates the SOAP specification or not. This is once again an example where the SOAP specification is unclear and may be implemented in a different manner by different SOAP frameworks.

Complicated subscription:
Implementing the subscription is quite complicated, especially with the advanced subscription architecture with wait/hold times. Some important information is found in comments, such as The first SPR148 after the Subscribe must return only Items with changed values if the Subscribe returned the values (ReturnValuesOnReply = true). The first SPR after the Subscribe must return all items if the Subscribe did not return the values (ReturnValuesOnReply = false). Such comments may easily be overlooked, which may lead to incompatible implementations.

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.

Omitting return values vs. empty strings:
In case of ``void'' return values, the specification is sometimes unclear whether an empty attribute/element should be returned or the element/attribute should be omitted.

Return items in write operations:
The specification does not state if in case of a successful write operation, an empty item should be returned.

Notification of buffer overflows:
In case of buffer overflows, an item attribute should be set with a specific code, denoting the overflow. However it is not specified if only one or more items should contain this flag.


next up previous contents
Next: Interoperability between Different OPC Up: Compatibility and Interoperability of Previous: Compatibility and Interoperability of   Contents
Hermann Himmelbauer 2006-09-27