How to Specify Default Values for Omitted Data

The gSOAP compiler generates soap default functions for all data types. The default values of the primitive types can be easily changed by defining any of the following macros in thestdsoap2.h file:

#define SOAP DEFAULT bool #define SOAP DEFAULT byte #define SOAP DEFAULT double #define SOAP DEFAULT float #define SOAP DEFAULT int #define SOAP DEFAULT long #define SOAP DEFAULT LONG64 #define SOAP DEFAULT short #define SOAP DEFAULT string #define SOAP DEFAULT time

#define SOAP DEFAULT unsignedByte #define SOAP DEFAULT unsignedInt #define SOAP DEFAULT unsignedLong #define SOAP DEFAULT unsignedLONG64 #define SOAP DEFAULT unsignedShort #define SOAP DEFAULT wstring

Instead of adding these to stdsoap2.h, you can also compile with option -DWITH SOAPDEFS H and include your definitions in fileuserdefs.h. The absence of a data value in a receiving SOAP message will result in the assignment of a default value to a primitive type upon deserialization.

Default values can also be assigned to individual struct and class fields of primitive type. For example,

struct MyRecord {

char *name = ”Unknown”; int value = 9999;

enum Status{ active, passive } status = passive; }

Default values are assigned to the fields on receiving a SOAP/XML message in which the data values are absent.

Because method requests and responses are essentially structs, default values can also be assigned to method parameters. The default parameter values do not control the parameterization of C/C++ function calls, i.e. all actual parameters must be present when calling a function. The default parameter values are used in case an inbound request or response message lacks the XML ele- ments with parameter values. For example, a Web service can use default values to fill-in absent parameters in a SOAP/XML request:

int ns login(char *uid = ”anonymous”, char *pwd = ”guest”, bool granted);

When the request message lacks uid and pwd parameters, e.g.:

<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns="http://tempuri.org"> <SOAP-ENV:Body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <ns:login> </ns:login> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

then the service uses the default values. In addition, the default values will show up in the SOAP/XML request and response message examples generated by the gSOAP compiler.

9

Using the gSOAP Stub and Skeleton Compiler

The gSOAP stub and skeleton compiler is invoked from the command line and optionally takes the name of a header file as an argument or, when the file name is absent, parses the standard input:

soapcpp2[aheaderfile.h]

whereaheaderfile.his a standard C++ header file. The compiler acts as a preprocessor and produces C++ source files that can be used to build SOAP client and Web service applications in C++. The files generated by the compiler are:

File Name

Description

soapStub.h A modified and annotated header file produced from the input header file soapH.h Main header file to be included by all client and service sources

soapC.cpp Serializers and deserializers for the specified data structures soapClient.cpp Client stub routines for remote operations

soapServer.cpp Service skeleton routines

soapClientLib.cpp Client stubs combined with local static (de)serializers soapServerLib.cpp Service skeletons combined with local static (de)serializers soapXYZProxy.h A C++ proxy object (can be used instead of soapClient.cpp) soapXYZProxy.cpp Implementation of C++ proxy object

soapXYZObject.h A C++ server object (can be used instead of soapServer.cpp) soapXYZObject.cpp Implementation of C++ server object

.xsd An ns.xsd file is generated with an XML schema for each namespace prefix ns used by a data structure in the header file input to the compiler, see Section 8.2.8 .wsdl A ns.wsdl file is generated with an WSDL description for each namespace prefix ns

used by a remote method in the header file input to the compiler, see Section 8.2.8 .xml Several SOAP/XML request and response files are generated. These are exam- ple message files are valid provided that sufficient schema namespace directives are added to the header file or the generated .nsmap namespace table for the client/service is not modified by hand

.nsmap A ns.nsmap file is generated for each namespace prefix ns used by a remote method in the header file input to the compiler, see Section 8.2.8. The file contains a namespace mapping table that can be used in the client/service sources

Both client and service applications are developed from a header file that specifies the remote methods. If client and service applications are developed with the same header file, the applications are guaranteed to be compatible because the stub and skeleton routines use the same serializers and deserializers to encode and decode the parameters. Note that when client and service applications are developed together, an application developer does not need to know the details of the internal SOAP encoding used by the client and service.

ThesoapClientLib.cppandsoapServerLib.cppcan be used to build (dynamic) client and server libraries. The serialization routines are local (static) to avoid link symbol conflicts. You must create a separate library for SOAP Header and Fault handling, as described in Section 17.32.

The following files are part of the gSOAP package and are required to build client and service applications:

File Name Description

stdsoap2.h Header file of stdsoap2.cpp runtime library

stdsoap2.c Runtime C library with XML parser and run-time support routines stdsoap2.cpp Runtime C++ library identical to stdsoap2.c

9.1 Compiler Options

Option Description

-1 Use SOAP 1.1 namespaces and encodings (default) -2 Use SOAP 1.2 namespaces and encodings

-h Print a brief usage message

-c Save files using extension .c instead of .cpp and produce pure C -w Do not generate WSDL and schema files

-m Generate Matlabtm _{code for MEX compiler}

-I <path> Use <path> (and current dir) for #import -d <path> Save sources in directory specified by <path>

-p <name> Save sources with file name prefix <name> instead of “soap” -n When used with -p, enables multi-client and multi-server builds:

Sets compiler option WITH NONAMESPACES, see Section 9.11

Saves the namespace mapping table with name <name> namespaces instead of namespaces Renames soap serve() into <name> serve() and soap destroy() into <name> destroy() -t Generates code to send typed messages (with the xsi:type attribute)

For example

soapcpp2 -cd ’../projects’ -pmy file.h

Saves the sources:

../projects/myH.h ../projects/myC.c ../projects/myClient.c ../projects/myServer.c ../projects/myStub.h

MS Windows users can use the usual “/” for options, for example:

soapcpp2 /cd ’..\projects’ /pmy file.h

Compiler optionsc, i, n, l, w can be set in the gSOAP header file using the//gsoapoptdirective. For example,

// Generate pure C and do not produce WSDL output: //gsoapopt cw

int ns myMethod(char*,char**); // takes a string and returns a string