\chapter{WSDL/XMLSchema python code generation}

Handling XML Schema (see \citetitle[http://www.w3.org/XML/Schema]{XML Schema specification}) 
is one of the more difficult aspects of using WSDL (see
\citetitle[http://www.w3.org/TR/wsdl]{The Web Services Description Language}.  
Using wsdl2py generates a module with stub code for the client interface,
and a "types" module that contains typecode representations of the XML Schema types and elements.  The generated typecodes are registered in a global schema instance, and once the "types" module is imported by an application all the global elements declarations and type definitions are available everywhere (see section ??).  

\section{wsdl2py}

\subsection{Command Line Flags}

\subsubsection{General Flags}
\begin{description}
\item[-h, ---help] Display the help message and available command line
flags that can be passed to wsdl2py.
\item[-f FILE, ---file=FILE] Create bindings for the WSDL which is located at
the local file path.
\item[-u URL, ---url=URL] Create bindings for the remote WSDL which is located
at the provided URL.
\item[-x, ---schema] Just process a schema (xsd) file and generate the types
mapping file.
\item[-d, ---debug] Output verbose debugging messages during code generation.
\item[-o OUTPUT_DIR, ---output-dir=OUTPUT_DIR] Write generated files to OUTPUT_DIR.
\end{description}

\subsubsection{Typecode Extensions (Stable) }
\begin{description}
\item[-b, ---complexType (more in subsection~\label{subsubsection:complexType})]
Generate convenience functions for complexTypes.  This includes getters,
setters, factory methods, and properties.  ** Do NOT use with --simple-naming **
\end{description}

\subsubsection{Development Extensions (Unstable) }
\begin{description}
\item[-a, ---address] WS-Addressing support.  The WS-Addressing schema must be
included in the corresponding WSDL.
\item[-w, ---twisted] Generate a twisted.web client.  Dependencies: 
python\verb!>=!2.4, Twisted\verb!>=!2.0.0, TwistedWeb\verb!>=!0.5.0
\end{description}

\subsubsection{Customizations (Unstable) }
\begin{description}
\item[-e, ---extended] Do extended code generation.
\item[-z ANAME, ---aname=ANAME] Use a custom function, ANAME, for attribute name
creation.
\item[-t TYPES, ---types=TYPES] Dump the generated type mappings to a file
named, ``TYPES.py''.
\item[-s, ---simple-naming] Simplify the generated naming.
\item[-c CLIENTCLASSSUFFIX, ---clientClassSuffix=CLIENTCLASSSUFFIX] The suffic
to use for service client class. (default ``SOAP'')
\item[-m PYCLASSMAPMODULE, ---pyclassMapModule=PYCLASSMAPMODULE] Use the
existing existing type mapping file to determine the ``pyclass'' objects to be
used.  The module should contain an attribute, ``mapping'', which is a
dictionary of form, {schemaTypeName: (moduleName.py, className)}.
\end{description}

\subsection{Basics of Code Generation}
\label{subsection:Basics of Code Generation}

\subsubsection{client stub module}
Using only the {\it General Flags} options one can generate a 
{\bfseries client stub module} from a WSDL description, consisting of
representations of the WSDL information items {\it service}, {\it binding}, 
{\it portType}, and {\it message}.


These four items are represented by three abstractions, consisting of a
{\it \bfseries Locator} class, {\it \bfseries PortType} class, and several 
{\it \bfseries Message} classes. The {\it \bfseries Locator} will have two methods for each {\it service port} declared in
the WSDL definition.  One method returns the address specified in the {\it binding}, and the other is a factory method for returning a {\it \bfseries PortType}
instance.  Each {\it \bfseries Message} class represents the aspects of the {\it binding}
at the operation level and below, and any type information specified by {\it message part} items.

\subsubsection{types module}
The {\bfseries types module} is generated with the {\bfseries client module} but
it can be created independently.  This is especially useful for dealing with
schema definitions that aren't specified inside of a WSDL document.  

The module level class defintions each represent a unique namespace, they are
simply wrappers for the contents of individual namespaces.  The inner classes
are the typecode representations of global {\it type definitions} (suffix {\it \bfseries _Def}), 
and {\it element declarations} (suffix {\it \bfseries _Dec}).

\subsubsection{understanding the generated typecodes}
The generated inner typecode classes come in two flavors, as mentioned above. 
{\it element declarations} can be serialized into XML, generally {\it type
definitions} cannot. In very simple terms, the {\it name} attribute of an {\it element declaration} is serialized into an XML tag, but {\it type
definitions} lack this information so they cannot be directly serialized into an
XML instance.  Most {\it element declaration}s declare a {\it type} attribute,
this must reference a {\it type definition}.  Considering the above scenario, a
generated {\it TypeCode} class representing an {\it element declaration} will
subclass the generated {\it TypeCode} class representing the {\it type 
definition}.

\paragraph{pyclass}
All instances of generated {\it TypeCode} classes will have a {\it pyclass}
attribute, instances of the {\it pyclass} can be created to store the data
representing an {\it element declaration}.  The {\it pyclass} itself has a {\it
typecode} attribute, which is a reference to the {\it
TypeCode} instance describing the data, thus making {\it pyclass} instances 
self-describing. 
When parsing an XML instance the data will be marshalled into a {\it pyclass}
instance.

\paragraph{aname}
The {\it aname} is a {\it TypeCode} instance attribute, its value is a string representing the
attribute name used to reference data representing an element declaration. The set 
of {\it XMLSchema} element names is {\it NCName}, this is a superset of ordinary
 identifiers in {\it python}.

\citetitle[http://www.w3.org/TR/REC-xml-names/]{Namespaces in XML}

\begin{verbatim}
From Namespaces in XML
	NCName	 ::=	(Letter | '_') (NCNameChar)*
	NCNameChar	 ::=	Letter | Digit | '.' | '-' | '_' | CombiningChar | Extender

From Python Reference Manual (2.3 Identifiers and keywords)
	identifier	::=	(letter|"_") (letter | digit | "_")*

Default set of anames
	ANAME	::=	("_") (letter | digit | "_")*
\end{verbatim}

\paragraph{transform} {\it NCName} into an {\it ANAME}
\begin{enumerate}
\item preprend "_"
\item character not in set (letter \verb!|! digit \verb!|! "_") change to "_"
\end{enumerate}

\paragraph{Attribute Declarations: attrs_aname}
The {\it attrs_aname} is a {\it TypeCode} instance attribute, its value is a string representing the
attribute name used to reference a dictionary, containing data representing
attribute declarations.  The keys of this dictionary are the
\verb!(namespace,name)! tuples, the value of each key represents the value of
the attribute.


\paragraph{Mixed Text Content: mixed_aname}

\subsection{Typecode Extensions}

\subsubsection{--complexType}
\label{subsubsection:complexType}
The {\it complexType} flag provides many conveniences to the programmer. This 
option is tested and reliable, and highly recommended by the authors.  

\paragraph{low-level description}
When enabled the \verb!__metaclass__! attribute will be set on all generated 
{\it pyclass}es.  The metaclass will introspect the {\it typecode} attribute of 
{\it pyclass}, and create a set of helper methods for each element
and attribute declared in the {\it complexType} definition.  This option simply
adds wrappers for dealing with content, it doesn't modify the generation scheme.

\begin{description}
\item[Getters/Setters] A getter and setter function is defined for each element
of a complex type.  The functions are named \verb!get_element_ANAME! and
\verb!set_element_ANAME! respectively.  In this example, variable \var{wsreq}
has functions named \verb!get_element__Options! and \verb!set_element__Options!.
 In addition to elements, getters and setters are generated for the attributes
 of a complex type.  For attributes, just the name of the attribute is used in
 determining the method names, so get_attribute_NAME and set_attribute_NAME are
 created.

\item[Factory Methods] If an element of a complex type is a complex type itself,
then a conveniece factory method is created to get an instance of that types
holder class.  The factory method is named, \verb!newANAME!, so \var{wsreq} has
a factory method, \verb!new_Options!.

\item[Properties]
\citetitle[http://www.python.org/download/releases/2.2/descrintro/#property]{Python class properties}
are created for each element of the complex type.  They are mapped to the
corresponding getter and setter for that element.  To avoid name collisions the
properties are named, \verb!PNAME!, where the first letter of the type's pname
attribute is capitalized.  In our running example, \var{wsreq} has class
property, \verb!Options!, which calls functions \verb!get_element__Options! and
\verb!set_element__Options! under the hood.

\end{description}

\begin{verbatim}
<xsd:complexType name='WolframSearchOptions'>
  <xsd:sequence>
    <xsd:element name='Query' minOccurs='0' maxOccurs='1' type='xsd:string'/>
    <xsd:element name='Limit' minOccurs='0' maxOccurs='1' type='xsd:int'/>
  </xsd:sequence>
  <xsd:attribute name='timeout' type='xsd:double' />
</xsd:complexType>
<xsd:element name='WolframSearch'>
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element name='Options' minOccurs='0' maxOccurs='1' type='ns1:WolframSearchOptions'/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>
\end{verbatim}

\begin{verbatim}
# Create a request object to operation WolframSearch
#   to be used as an example below
from WolframSearchService_services import *

port = WolframSearchServiceLocator().getWolframSearchmyPortType()
wsreq = WolframSearchRequest()
\end{verbatim}



\begin{verbatim}
# sample usage of the generated code

# get an instance of a Options holder class using factory method
opts = wsreq.new_Options()
wsreq.Options = opts

# assign values using the properties or methods
opts.Query = 'Newton'
opts.set_element__Limit(10)

# don't forget the attribute
opts.set_attribute_timeout(1.0)

# At this point the serialized wsreq object would resemble this:
# <WolframSearch>
#   <Options timeout="1.0" xsi:type="tns:WolframSearchOptions">
#     <Query xsi:type="xsd:string">Newton</Query>
#     <Limit xsi:type="xsd:double">10.0</Limit>
#   </Options>
# </WolframSearch>

# ready call the remote operation
wsresp = port.WolframSearch(wsreq)

# returned WolframSearchResponse type holder also has conveniences
print 'SearchTime:', wsresp.Result.SearchTime
\end{verbatim}

\section{Code Generation from WSDL and XML Schema}

This section covers wsdl2py, the second way ZSI provides to access WSDL
services.  Given the path to a WSDL service, two files are generated, a 
'service' file and a 'types' file, that one can then use to access the
service.  As an example, we will use the search service provided by Wolfram
Research Inc.\copyright{}, \url{http://webservices.wolfram.com/wolframsearch/}, 
which provides a service for searching the popular MathWorld site, 
\url{http://mathworld.wolfram.com/}, among others.

\begin{verbatim}
wsdl2py --complexType --url=http://webservices.wolfram.com/services/SearchServices/WolframSearch2.wsdl
\end{verbatim}

Run the above command to generate the service and type files.  wsdl2py uses
the {\it name} attribute of the {\it wsdl:service} element to name the resulting files.
In this example, the service name is {\it WolframSearchService}.  Therefore the files
{\it WolframSearchService_services.py} and {\it WolframSearchService_services_types.py}
should be generated.

The 'service' file contains locator, portType, and message classes.  
A locator instance is used to get an instance of a portType class, 
which is a remote proxy object. Message instances are sent and received 
through the methods of the portType instance.

The 'types' file contains class representations of the definitions and
declarations defined by all schema instances imported by the WSDL definition.
XML Schema attributes, wildcards, and derived types are not fully
handled.

\subsection{Example Use of Generated Code}

The following shows how to call a proxy method for {\it WolframSearch}.  It
assumes wsdl2py has already been run as shown in the section above.  The example
will be explained in greater detail below.

\begin{verbatim}
# import the generated class stubs
from WolframSearchService_services import *

# get a port proxy instance
loc = WolframSearchServiceLocator()
port = loc.getWolframSearchmyPortType()

# create a new request
req = WolframSearchRequest()
req.Options = req.new_Options()
req.Options.Query = 'newton'

# call the remote method
resp = port.WolframSearch(req)

# print results
print 'Search Time:', resp.Result.SearchTime
print 'Total Matches:', resp.Result.TotalMatches
for hit in resp.Result.Matches.Item:
    print '--', hit.Title
\end{verbatim}

Now each section of the code above will be explained.

\begin{verbatim}
from WolframSearchService_services import *
\end{verbatim}

We are primarily interested in the service locator that is imported.  The 
binding proxy and classes for all the messages are additionally imported.
Look at the {\it WolframSearchService_services.py} file for more information.

\begin{verbatim}
loc = WolframSearchServiceLocator()
port = loc.getWolframSearchmyPortType()
\end{verbatim}

Using an instance of the locator, we fetch an instance of the port proxy
which is used for invoking the remote methods provided by the service.  In
this case the default {\it location} specified in the {\it wsdlsoap:address}
element is used.  You can optionally pass a url to the port getter method to
specify an alternate location to be used.  The {\it portType} - {\it name} 
attribute is used to determine the method name to fetch a port proxy instance.
In this example, the port name is {\it WolframSearchmyPortType}, hence the 
method of the locator for fetching the proxy is {\it getWolframSearchmyPortType}.

The first step in calling {\it WolframSearch} is to create a request object
corresponding to the input message of the method.  In this case, the name of
the message is {\it WolframSearchRequest}.  A class representing this message
was imported from the service module.

\begin{verbatim}
req = WolframSearchRequest()
req.Options = req.new_Options()
req.Options.Query = 'newton'
\end{verbatim}

Once a request object is created we need to populate the instance with the
information we want to use in our request.  This is where the {\tt --complexType}
option we passed to wsdl2py will come in handy.  This caused the creation of 
functions for getting and setting elements and attributes of the type, class 
properties for each element, and convenience functions for creating new instances
of elements of complex types.  This functionality is explained in detail in 
subsection~\ref{subsubsection:complexType}.

Once the request instance is populated, calling the remote service is easy.  Using
the port proxy we call the method we are interested in.  An instance of the python
class representing the return type is returned by this call.  The \var{resp} object
can be used to introspect the result of the remote call.

\begin{verbatim}
resp = port.WolframSearch(req)
\end{verbatim}

Here we see that the response message, \var{resp}, represents type {\it WolframSearchReturn}.
This object has one element, {\it Result} which contains the search results for our
search of the keyword, {\tt newton}.

\begin{verbatim}
print 'Search Time:', resp.Result.SearchTime
...
\end{verbatim}

Refer to the wsdl for {\it WolframSearchService} for more details on the returned information.


\section{Advanced Usage Patterns}
Not done.


