?? soapdoc2.html
字號:
<a href="#tth_sEc8.11.1">8.11.1 <font color="#0000FF">Serializing and Deserializing XML Into Strings</font></a><br /><a href="#tth_sEc9">9 <font color="#0000FF">SOAP Fault Processing</font></a><br /><a href="#tth_sEc10">10 <font color="#0000FF">SOAP Header Processing</font></a><br /><a href="#tth_sEc11">11 <font color="#0000FF">DIME Attachment Processing</font></a><br /><a href="#tth_sEc12">12 <font color="#0000FF">Advanced Features</font></a><br /> <a href="#tth_sEc12.1">12.1 <font color="#0000FF">Internationalization</font></a><br /> <a href="#tth_sEc12.2">12.2 <font color="#0000FF">Customizing the WSDL and Namespace Mapping Table File Contents</font></a><br /> <a href="#tth_sEc12.3">12.3 <font color="#0000FF">Transient Data Types</font></a><br /> <a href="#tth_sEc12.4">12.4 <font color="#0000FF">How to Declare User-Defined Serializers and Deserializers</font></a><br /> <a href="#tth_sEc12.5">12.5 <font color="#0000FF">How to Serialize Data Without XML plus3 <tt>xsi:type</tt> Attributes</font></a><br /> <a href="#tth_sEc12.6">12.6 <font color="#0000FF">Function Callbacks for Customized I/O and HTTP Handling</font></a><br /> <a href="#tth_sEc12.7">12.7 <font color="#0000FF">HTTP 1.0 and 1.1</font></a><br /> <a href="#tth_sEc12.8">12.8 <font color="#0000FF">HTTP Keep-Alive</font></a><br /> <a href="#tth_sEc12.9">12.9 <font color="#0000FF">HTTP Chunked Transfer Encoding</font></a><br /> <a href="#tth_sEc12.10">12.10 <font color="#0000FF">Timeout Management for Non-Blocking Operations</font></a><br /> <a href="#tth_sEc12.11">12.11 <font color="#0000FF">Secure SOAP Clients with HTTPS/SSL</font></a><br /> <a href="#tth_sEc12.12">12.12 <font color="#0000FF">Secure SOAP Web Services with HTTPS/SSL</font></a><br /> <a href="#tth_sEc12.13">12.13 <font color="#0000FF">Client-Side Cookie Support</font></a><br /> <a href="#tth_sEc12.14">12.14 <font color="#0000FF">Server-Side Cookie Support</font></a><br /> <a href="#tth_sEc12.15">12.15 <font color="#0000FF">Connecting Clients Through Proxy Servers</font></a><br /> <a href="#tth_sEc12.16">12.16 <font color="#0000FF">FastCGI Support</font></a><br />
</td></tr></table><br></span>
<i>Copyright (C) Robert A. van Engelen 2000-2002, all rights reserved.</i>
<p> <h2><a name="tth_sEc1">1</a> <font color="#0000FF">Introduction</font></h2>
<p>The gSOAP toolkit provides a unique SOAP-to-C/C++ language binding for the development of SOAP Web Services and clients.
Other SOAP C++ implementations adopt a SOAP-centric view and offer SOAP APIs for C++ that require the use of class libraries for
SOAP-like data structures. This often forces a user to adapt the application logic to these libraries. In contrast, gSOAP
provides a C/C++ transparent SOAP API through the use of compiler technology that hides irrelevant SOAP-specific details from
the user. The gSOAP stub and skeleton compiler automatically maps native and user-defined C and C++ data types to semantically
equivalent SOAP data types and vice-versa. As a result, full SOAP interoperability is achieved with a simple API relieving the
user from the burden of SOAP details and enables him or her to concentrate on the application-essential logic. The compiler
enables the integratation of (legacy) C/C++ and Fortran codes (through a Fortran-to-C interface), embedded systems, and
real-time software in SOAP applications that share computational resources and information with other SOAP applications,
possibly across different platforms, language environments, and disparate organizations located behind firewalls.
<p>gSOAP minimizes application adaptation for building SOAP clients and Web Services. The gSOAP compiler generates SOAP marshalling
routines that (de)serialize application-specific C/C++ data structures. gSOAP includes a WSDL generator to generate Web service
descriptions for your Web services. The gSOAP WSDL importer "closes the circle" in that it enables client development without the need
for users to analyze Web service details to implement a client.
<p>Some of the highlights of gSOAP are:
<ul><p><li>Unique interoperability features: the gSOAP compiler generates SOAP marshalling routines that (de)serialize native and
user-defined C/C++ data structures. gSOAP is also one of the few SOAP toolkits that support the full range of SOAP 1.1 features
including multi-dimensional arrays and polymorphic types. For example, a remote method with a base class parameter may accept
derived class instances from a client. Derived class instances keep their identity through dynamic binding.</li><p><li>
gSOAP includes a WSDL generator for convenient Web Service publishing.</li><p><li>
gSOAP includes a WSDL importer for automated client development.</li><p><li>
Generates source code for stand-alone Web Services and clients.</li><p><li>
Ideal for building web services that are compute-intensive and are therefore best written in C and C++.</li><p><li>
Platform independent: Windows, Unix, Linux, Pocket PC, etc.</li><p><li>
Fast <em>in situ</em> serialization and deserialization with SOAP encoding of arbitrary user-defined and built-in C and C++ data
structures.</li><p><li>
Fully SOAP 1.1 compliant data encoding and decoding. (Also SOAP 1.2 compliant, except for header faults, SOAP actors, SOAP root.)</li><p><li>
DIME compliant attachments.</li><p><li>
The schema-specific XML pull parser is fast and efficient and does not require intermediate data storage for
demarshalling to save space and time.</li><p><li>
Selective input and output buffering is used to increase efficiency, but full message buffering to determine HTTP message length
is not used. Instead, a three-phase serialization method is used to determine message length. As a result, large data sets
such as base64-encoded images can be transmitted with or without DIME attachments by small-memory devices such as PDAs.</li><p><li>
Supports C++ single class inheritance, dynamic binding, overloading, arbitrary pointer structures such as lists, trees, graphs,
cyclic graphs, fixed-size arrays, (multi-dimensional) dynamic arrays, enumerations, built-in XML schema types including
base64Binary encoding, and hexBinary encoding.</li><p><li>
No need to rewrite existing C/C++ applications for Web service deployment. However, parts of an application that use unions,
pointers to sequences of elements in memory, and <i><b>void</b>*</i> need to be modified, but <b>only</b> if the data structures that
adopt them are required to be serialized or deserialized as part of a remote method invocation.</li><p><li>
Three-phase marshalling: 1) analysis of pointers, single-reference, multi-reference, and cyclic data structures, 2) HTTP
message-length determination, and 3) serialization as per SOAP 1.1 encoding style or user-defined encoding styles.</li><p><li>
Two-phase demarshalling: 1) SOAP parsing and decoding, which involves the reconstruction of multi-reference and cyclic data
structures from the payload, and 2) resolution of "forward" pointers (i.e. resolution of the forward <tt>href</tt> attributes in SOAP).</li><p><li>
Full and customizable SOAP Fault processing (client receive and service send).</li><p><li>
Customizable SOAP Header processing (send and receive), which for example enables easy transaction processing for the service to
keep state information.</li></ul>
<p> <h2><a name="tth_sEc2">2</a> <font color="#0000FF">Notational Conventions</font></h2>
<p>The typographical conventions used by this document are:
<dl compact="compact"> <dt><b><span class="roman"><i>Sans serif or italics font</i></b></dt> <dd> Denotes C and C++ source code, file names, and commands.</span></dd> <dt><b><i><b>Bold font</b></i></b></dt> <dd> Denotes C and C++ keywords.</dd> <dt><b><tt>Courier font</tt></b></dt> <dd> Denotes HTTP header content, HTML, XML, and XML schema fragments.</dd> <dt><b><span class="roman"><font size="+1"><span class="roman">[</span></font>Optional<font size="+1"><span class="roman">]</span></font></b></dt> <dd> Denotes an optional construct.</span></dd></dl>
<p>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC-2119.
<p> <h2><a name="tth_sEc3">3</a> <font color="#0000FF">Differences Between gSOAP Versions 1.X and 2.X</font></h2>
<p>gSOAP versions 2.0 and higher are redesigned and thread-safe.
All files in the gSOAP 2.X distribution are renamed to avoid confusion with gSOAP version 1.X files:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#D0D0D0"><tr><td><span class="roman">
<table><tr><td><font color="#FF0000"><b>gSOAP 1.X</b></font> </td><td><font color="#FF0000"><b>gSOAP 2.X</b></font> </td></tr><tr><td>soapcpp </td><td>soapcpp2 </td></tr><tr><td>soapcpp.exe </td><td>soapcpp2.exe </td></tr><tr><td>stdsoap.h </td><td>stdsoap2.h </td></tr><tr><td>stdsoap.c </td><td>stdsoap2.c </td></tr><tr><td>stdsoap.cpp </td><td>stdsoap2.cpp </td></tr></table>
</td></tr></table><br></span>
Changing the version 1.X application codes to accomodate gSOAP 2.X does not require a significant amount of recoding.
The change to gSOAP 2.X affects all functions defined in <i>stdsoap2.c[pp]</i> (the gSOAP runtime environment API) and the functions in the
sources generated by the gSOAP compiler (the gSOAP RPC+marshalling API).
Therefore, clients and services developed with gSOAP 1.X need to be modified to accomodate a change in the calling convention used in 2.X:
In 2.X, <b>all</b> gSOAP functions (including the remote method proxy routines) take an additional parameter which is an instance of the gSOAP runtime
environment that includes file descriptors, tables, buffers, and flags.
This additional parameter is <b>always</b> the first parameter of any gSOAP function.
<p>The gSOAP runtime environment is stored in a <i><b>struct</b> soap</i> type. A <i><b>struct</b></i> was chosen to support application development in
C without the need for a separate gSOAP implementation. An object-oriented approach with a class for the gSOAP runtime environment would have prohibited the implementation of pure C applications.
Before a client can invoke remote methods or before a service can accept requests, a runtime environment need to be allocated and
initialized.
Two new functions are added to gSOAP 2.X:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#D0D0D0"><tr><td><span class="roman">
<table><tr><td><font color="#FF0000"><b>Function</b></font> </td><td><font color="#FF0000"><b>Description</b></font> </td></tr><tr><td><i>soap_init(<b>struct</b> soap *soap)</i> </td><td>Initializes a runtime environment (required only once) </td></tr><tr><td><i><b>struct</b> soap *soap_new()</i> </td><td>Allocates, initializes, and returns a pointer to a runtime environment </td></tr></table>
</td></tr></table><br></span>
An environment can be reused as many times as necessary and does not need to be reinitialized in doing so.
A new environment is only required for each new thread to guarantee exclusive access
to a new runtime environment by each thread.
For example, the following code stack-allocates the runtime environment which is used for multiple remote method calls:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#B0D0B0"><tr><td><i>
<b>int</b> main() <br />
{ <br />
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -