Problems and Workarounds During the Implementation

After modeling these data structures, code was created. In this process, a WSDL document which was attached to [OPCXMLDA] was used to generate OPC specific typecodes as discussed above. Moreover, the classes, as depicted in figure 61 were coded. However, there were numerous bugs and missing features in the ZSI, such as:

Attribute handling:

XML attributes were handled as strings by ZSI, regardless of the data type declaration in the WSDL document.

Missing data types:

ZSI does not implement all data types, especially the date/time-based data types are not fully implemented¹³² and the fixed-decimal type is entirely missing.

Missing Documentation:

The Documentation provided by ZSI is quite outdated, moreover, some newer topics are entirely missing. This made the usage of ZSI quite complicated, as some information had to be gathered from the source code itself¹³³.

Various bugs:

There were bugs concerning the handling of the ``QName'' and ``anyType'' data types, problems in the script that generates the typecodes and some other minor shortcomings.

Fortunately, the ZSI developers were very helpful in solving most of these problems, and it was possible to fix some of these bugs in the source code of the framework or to find workarounds for some of the shortcomings.

Nevertheless the code tended to be very unstable. For this reason, unit tests for all methods were set up that verify the serialization and parsing of all available OPC SOAP messages as follows:

1. Fill Internal Data Structure:

The internal Python objects representing the SOAP message are completely filled with test data. This way, all available elements/attributes should be present in the serialized SOAP message.

2. Serialize SOAP Message:

The appropriate ``fill'' method of the data object is then used for creating the associated typecode, which is used for serializing the data into a SOAP Message.

3. Check for Attributes/Elements:

The XML code in the SOAP message is examined if the specified data is actually present in XML attributes/elements.

4. Parse SOAP Message into Internal Data Structure:

The previously serialized message is parsed back into a suitable typecode and the ``read'' method of the associated data object is then used to fill the Python data structure.

5. Compare Original and Parsed Data:

The last step is to compare the original data structure with the parsed data from the previous step.

These unit tests can then automatically be run to guarantee the proper functionality of these code segments. This way, code changes or updates of the ZSI framework that lead to faulty behavior can easily be tracked and fixed. More information about unit testing can be found in [HUN03]¹³⁴.