?? soapdoc2.html
字號:
<b>struct</b> soap soap; <br />
... <br />
soap_init(&soap); // initialize runtime environment <br />
... <br />
soap_call_ns__method1(&soap, ...); // make a remote call <br />
... <br />
soap_call_ns__method2(&soap, ...); // make another remote call <br />
... <br />
soap_end(&soap); // clean up <br />
... <br />
}
</td></tr></table><br></i>
The runtime environment can also be heap allocated:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#B0D0B0"><tr><td><i>
<b>int</b> main() <br />
{ <br />
<b>struct</b> soap *soap; <br />
... <br />
soap = soap_new(); // allocate and initialize runtime environment <br />
<b>if</b> (!soap) // couldn't allocate: stop <br />
... <br />
soap_call_ns__method1(soap, ...); // make a remote call <br />
... <br />
soap_call_ns__method2(soap, ...); // make another remote call <br />
... <br />
soap_end(soap); // clean up <br />
... <br />
free(soap); // deallocate runtime environment <br />
}
</td></tr></table><br></i>
A service need to allocate and initialize an environment before calling <i>soap_serve</i>:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#B0D0B0"><tr><td><i>
<b>int</b> main() <br />
{ <br />
<b>struct</b> soap soap; <br />
soap_init(&soap); <br />
soap_serve(&soap); <br />
}
</td></tr></table><br></i>
Or alternatively:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#B0D0B0"><tr><td><i>
<b>int</b> main() <br />
{ <br />
soap_serve(soap_new()); <br />
}
</td></tr></table><br></i>
A service can use multi-threading to handle requests while running some other code that invokes remote methods:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#B0D0B0"><tr><td><i>
<b>int</b> main() <br />
{ <br />
<b>struct</b> soap soap1, soap2; <br />
pthread_t tid; <br />
... <br />
soap_init(&soap1); <br />
<b>if</b> (soap_bind(&soap1, host, port, backlog) < 0) exit(-1); <br />
<b>if</b> (soap_accept(&soap1) < 0) exit(-1); <br />
pthread_create(&tid, NULL, (<b>void</b>*(*)(<b>void</b>*))soap_serve, (<b>void</b>*)&soap1]); <br />
... <br />
soap_init(&soap2); <br />
soap_call_ns__method(&soap2, ...); // make a remote call <br />
... <br />
soap_end(&soap2); <br />
... <br />
pthread_join(tid); // wait for thread to terminate <br />
soap_end(&soap1); // release its data <br />
}
</td></tr></table><br></i>
In the example above, two runtime environments are required.
In comparison, gSOAP 1.X statically allocates the runtime environment, which prohibits multi-threading (only one thread can invoke
remote methods and/or accept requests due to the single runtime environment).
<p>Section <a href="#sec:mt">5.2.3</a> presents a multi-threaded stand-alone Web Service that handles multiple SOAP requests by spawning a thread for each request.
<p> <h2><a name="tth_sEc4">4</a> <font color="#0000FF">Interoperability</font></h2>
<p>gSOAP interoperability has been verified with the following SOAP implementations and toolkits:
<dl compact="compact"> <dt><b>Apache 2.2</b></dt> <dd></dd> <dt><b>Apache Axis</b></dt> <dd></dd> <dt><b>ASP.NET</b></dt> <dd></dd> <dt><b>Cape Connect</b></dt> <dd></dd> <dt><b>Delphi</b></dt> <dd></dd> <dt><b>easySOAP++</b></dt> <dd></dd> <dt><b>eSOAP</b></dt> <dd></dd> <dt><b>Frontier</b></dt> <dd></dd> <dt><b>GLUE</b></dt> <dd></dd> <dt><b>Iona XMLBus</b></dt> <dd></dd> <dt><b>kSOAP</b></dt> <dd></dd> <dt><b>MS SOAP</b></dt> <dd></dd> <dt><b>Phalanx</b></dt> <dd></dd> <dt><b>SIM</b></dt> <dd></dd> <dt><b>SOAP::Lite</b></dt> <dd></dd> <dt><b>SOAP4R</b></dt> <dd></dd> <dt><b>Spray</b></dt> <dd></dd> <dt><b>SQLData</b></dt> <dd></dd> <dt><b>Wasp Adv.</b></dt> <dd></dd> <dt><b>Wasp C++</b></dt> <dd></dd> <dt><b>White Mesa</b></dt> <dd></dd> <dt><b>xSOAP</b></dt> <dd></dd> <dt><b>ZSI</b></dt> <dd></dd> <dt><b>4S4C</b></dt> <dd></dd></dl>
<p> <h2><a name="tth_sEc5">5</a> <font color="#0000FF">Quick User Guide</font></h2>
<p>This user guide offers a quick way to get started with gSOAP. This section requires a basic understanding of the SOAP 1.1
protocol and some familiarity with C and/or C++. In principle, SOAP clients and SOAP Web services can be developed in C and C++
with the gSOAP stub and skeleton compiler without a detailed understanding of the SOAP protocol when the applications
are build as an ensamble and only communicate within this group (i.e. meaning that you don't have to worry about
interoperability with other SOAP implementations). This section is intended to illustrate the implementation of SOAP C/C++ Web
services and clients that connect to other existing SOAP implementations such as Apache SOAP and SOAP::Lite for which some
details of the SOAP protocol need to be understood.
<p> <h3><a name="tth_sEc5.1">5.1</a> <font color="#0000FF">How to Use the gSOAP Stub and Skeleton Compiler to Build SOAP Clients</font></h3><a name="sec:client"></a>
<p>In general, the implementation of a SOAP client application requires a <b>stub</b> routine for each remote method that the client
application needs to invoke. The primary stub's responsibility is to marshall the input data, send the request to the designated
SOAP service over the wire, to wait for the response, and to demarshall the output data when it arrives. The client application
invokes the stub routine for a remote method as if it would invoke a local method. To write a stub routine in C or C++ by hand is
a tedious task, especially if the input and/or output data structures of a remote method are complex data types such as records,
arrays, and graphs.
<p>The generation of stub routines for a SOAP client is fully automated with gSOAP. The gSOAP stub and skeleton compiler is a <b>
preprocessor</b> that generates the necessary C++ sources to build SOAP C++ clients. The input to the gSOAP stub and skeleton
compiler consists of a standard C/C++ <b>header file</b>. The header file can be generated from a WSDL (Web Service
Description Language) documentation of a service with the gSOAP WSDL importer, see <a href="#sec:wsdlin">5.2.7</a>. The SOAP remote methods are specified in this header file as <b>function prototypes</b>. Stub routines in
C/C++ source form are automatically generated by the gSOAP compiler for these function prototypes of remote methods. The
resulting stub routines allow C and C++ client applications to seamlessly interact with existing SOAP Web services.
<p>The gSOAP stub and skeleton compiler also generates <b>skeleton</b> routines for each of the remote methods specified in the header
file. The skeleton routines can be readily used to implement one or more of the remote methods in a new SOAP Web service. These
skeleton routines are not used for building SOAP clients in C++, although they can be used to build mixed SOAP client/server
applications (peer applications).
<p>The input and output parameters of a SOAP remote method may be simple data types or complex data types. The necessary <b>type
declarations</b> of C/C++ user-defined data structures such as structs, classes, enumerations, arrays, and pointer-based data
structures (graphs) are to be provided in the header file. The gSOAP stub and skeleton compiler automatically generates <b>
serializers</b> and <b>deserializers</b> for the data types to enable the generated stub routines to encode and decode the contents of
the parameters of the remote methods.
<p>The remote method name and its parameterization can be found with a SOAP Web service description, typically in the form of an XML
schema. There is an almost one-to-one correspondence between the XML schema description of a SOAP remote method and the C++ type
declarations required to build a client application for the Web service. The schemas are typically part of the WSDL specification of a SOAP Web service. The gSOAP WSDL importer converts WSDL service descriptions into header files.
<p> <h4><a name="tth_sEc5.1.1">5.1.1</a> <font color="#0000FF">Example</font></h4><a name="sec:example1"></a>
<p>The <i>getQuote</i> remote method of XMethods Delayed Stock Quote service provides a delayed stock quote for a given ticker name,
see <a href="http://xmethods.com/detail.html?id=2"><tt>http://xmethods.com/detail.html?id=2</tt></a> for details. The WSDL description of the Delayed Stock Quote service provides the
following details:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#D0D0D0"><tr><td><span class="roman">
<table><tr><td>Endpoint URL: </td><td><tt>http://services.xmethods.net:80/soap</tt> </td></tr><tr><td>SOAP action: </td><td>"" (2 quotes) </td></tr><tr><td>Remote method namespace: </td><td><tt>urn:xmethods-delayed-quotes</tt> </td></tr><tr><td>Remote method name: </td><td><tt>getQuote</tt> </td></tr><tr><td> Input parameter: </td><td><tt>symbol</tt> of type <tt>xsd:string</tt> </td></tr><tr><td> Output parameter: </td><td><tt>Result</tt> of type <tt>xsd:float</tt>
</td></tr></table>
</td></tr></table><br></span>
The following <i>getQuote.h</i> <b>header file</b> is created from the WSDL description with the WSDL importer:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#B0D0B0"><tr><td><i>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -