next up previous contents
Next: Problems and Workarounds During Up: Implementation of an OPC Previous: Choosing an Appropriate SOAP   Contents


Parsing OPC XML-DA Compliant SOAP Messages

The Zolera SOAP Infrastructure (ZSI) framework handles the parsing and serializing of SOAP messages. Before a message can be parsed, a data structure, called ``Typecode'' has to be set up. A Typecode is a Python object and represents a specific type of SOAP message. SOAP messages can be parsed into suitable typecodes, which can then be read/written by custom Python code. On the other hand, typecodes can be serialized, which allows the creation of appropriate SOAP messages. This concept is depicted in figure 60.

Figure 60: Parsing/Serializing SOAP Messages via ZSI Typecodes
\begin{figure}\centering
\includegraphics[scale=0.7]{graphics/devel-typecodes.eps}\end{figure}

These typecodes can either be created by hand or - in case a WSDL document is available - with a tool, called ``wsdl2py''. This tool generates two python files, which can be imported into custom code and used to access these typecodes. Moreover, the structure of these generated typecodes can then be examined through python, using the ``help()'' command. The idea behind this concept is that a user never has to look at the complicated WSDL code itself, instead he can handle everything through the Python language. Listing 33 depicts a creation of a simple OPC typecode129 and Listing 34 shows the output of the ``help()'' command, while listing 35 shows the regarding snippet of the WSDL document.

language=C
\begin{lstlisting}[caption={Creating a Simple OPC Typecode}
,label=ex_typecode]...
...de object
tc.set_attribute_ClientItemHandle('SampleHandle123')
\end{lstlisting}

language=C
\begin{lstlisting}[caption={Available Attributes/Method of the Typecode}
,label...
...tHandle(self, value)
\vert set_attribute_LocaleID(self, value)
\end{lstlisting}

language=XML
\begin{lstlisting}[caption={Associated WSDL Code Snippet}
,label=ex_typecode_ws...
...estHandle'' type=''s:string'' />
</s:complexType>
</s:element>
\end{lstlisting}

Line 5 in Listing 33 depicts how the generated method set_attribute_ClientRequestHandle can be used to fill the associated XML attribute in the SOAP message, as defined in Line 4 in listing 35.

Typecodes may embed other typecodes and hence represent complicated WSDL documents. One huge advantage of this concept is that SOAP-compliant data types are automatically converted to Python-specific data types. For instance, a SOAP ``integer'' will automatically be converted to a Python integer.

The problem with this approach is that complicated WSDL documents generate complicated typecodes, although it may be possible to provide the underlying data in a much simpler form, for instance by creating custom objects, or using specific Python data types, such as dictionaries130. [OPCXMLDA] contains various complicated WSDL structures, which are complex to access. As these structures have to be read/written throughout the whole implementation, a simpler structure would be more appropriate.

After a thorough study of the OPC WSDL document, it was discovered that all request/response documents have one or more OPC Items which transport attributes, such as the Item value, the quality/timestamp and more. OPC Items may contain OPC properties, which contain the name, description and some other attributes of the property. Every request/response is accompanied by general attributes, such as the time when the request was issued, or a deadline until the response must be finished.

Therefore custom and built-in Python objects could be used as follows:

General request/response attributes:
These attributes can be stored in a Python dictionary.
OPC Items:
A specific object, called ``ItemContainer'' was modeled which is able to contain every type of OPC Item found in the OPC XML-DA specification.
OPC Properties:
Another specific object, called ``OPCProperty'' was created that can be used to store OPC Item Property data.

Three basic classes were created that are used for storing SOAP message data into this simpler data structure, as depicted in figure 61131.

Figure 61: Class diagram of the OPC Server's Data Structure
\begin{figure}\centering
\includegraphics[scale=0.7]{graphics/devel-uml1.eps}\end{figure}

These classes have specific ``fill'' and ``read'' methods, which may be used to fill/read suitable ZSI typecodes. These data structures are automatically created by the server, hence the programmer may easily access OPC data of request/response messages and never has to deal with typecodes.



Subsections
next up previous contents
Next: Problems and Workarounds During Up: Implementation of an OPC Previous: Choosing an Appropriate SOAP   Contents
Hermann Himmelbauer 2006-09-27