SOAP (Simple Object Access Protocol) is widely used in distributed applications, such as WebService. When using. Net to develop WebService, you only need to add the WebMethod feature to the corresponding method, and then you can send SOAP messages through the network. In this way, when using Webservice, you may not be very concerned about the structure of the SOAP message. The following describes the structure of the SOAP message and the use of tools to listen to the SOAP message.
This section contains the following contents:
- 1. What is XSD?
- 2. the SOAP-based Data Interaction System is XSD
- 3. SOAPSOAP message structure
- 4. Support for SOAP protocol
- 5. Use SOAPHeader to expand SOAP
- 6. SOAP custom exception
- 7. Listening for SOAP messages
1. What is XSD?
XSD (XML Scheme Definition, XML outline Definition) is used to describe the structure and content of XML. It is also an XML document, through which we can know which nodes are contained in the xml document and what types of values these nodes should be. Common WSDL documents.
2. the SOAP-based Data Interaction System should be XSD
The WebService Data Interaction format is based on SOAP, while SOAP is actually XML data with SOAP format. Based on XML cross-platform features, each system needs to be able to accurately understand what types of parameters, parameters, and returned values WebService requires when calling WebService. XSD is a good choice to describe these problems. So such systems are XSD ..
3. SOAP message structure
First take a look at the following SOAP request message:
It consists of the <SOAP: Envelope> soap Header (<SOAP: Header>) soap message Body (<SOAP: Body>. <Soap: Envelope> is the root node of the SOAP message and a required part of the SOAP message. <soap: Header> is an optional part of the SOAP message. If the SOAP message contains it, therefore, it must be the first element node in soap: Envelope>. <soap: Body> is a required part of SOAP. If the SOAP message does not contain <soap: Header>, <soap: body> must be the first element node in SOAP.
In addition, when WebService returns an exception to the consumer, the <soap: Fault> element node is returned to the consumer, which is included in <soap: Body>. As follows:
<soap:Body><soap:Fault><faultcode xmlns:q0="ns=cnblogs.com/tyb1222">q0:code</faultcode><faultstring>System.Web.Services.Protocols.SoapException: 0x00</faultstring><faultactor/><detail /></soap:Fault></soap:Body>
<Faultcode> is a required element node in <soap: Fault>. It allows consumers to identify errors.
<Faultstring> is a required element node in <soap: Fault> to describe the error text.
<Faultactor/> is not a required element node in <soap: Fault>. It is used to describe the route node on which an error occurs.
<Detail> describes the application assembly error information related to <soap: Body>. If the Body cannot be correctly processed, <detail> is a required element in <soap: Fault>.
4. Support for SOAP protocol
Generally, the accessed WebService is through the Web server. The most common application protocol for accessing Web servers is of course the well-known HTTP protocol. HTTP has become the most common protocol to support SOAP. In fact, it supports any transmission protocol supported by SOAP to implement communication between applications, including TCP and SMTP.
5. Use SOAPHeader to expand SOAP
In. webService is developed on the. Net platform. If the SOAP header is not extended through the SOAPHeader, only the <SOAP: Envelope> and <soap: Body> nodes in the soap message are required. In many cases, the use of SOAPHeader is also a common part of SOAP, such as using SOAPHeader to authenticate the consumer, or using Actor to route SOAP messages to SOAP messages.
With SOAPHeader extension SOAP, you can override the implementation of SOAPHeader In the derived class.Note: When using a derived class to override the SOAPHeader, You need to define a non-parameter constructor for the derived class. Otherwise, the problem of serialization failure due to no parameter constructor is reported during WebService access.
This section briefly introduces the SOAPHeader extension.
public class EaxmHeader : SoapHeader{ public string UserName { get; set; } public string Password { get; set; } public EaxmHeader() { } public EaxmHeader(string userName,string password) { UserName = userName; Password = password; }}
Then, on the specific WebService function interface, set MemberName in SOAPAttribute to add the EaxmHeader object. As follows:
[WebMethod]
[SoapHeader ("header", Direction = SoapHeaderDirection. InOut)]
Public int divide (int x, int y)
6. SOAP custom exception
Transmission exceptions in network communication are inevitable. Sometimes, to ensure service security, expose service information as little as possible and notify consumers of the cause of exceptions during the call process. Generally, you can throw a custom SOAPException. in <soap: fault> Custom <faultcode> error code and <faultstring> prompt text information. For example, throw new SOAPException (...) in catch (...)
7. Listening for SOAP messages
SOAP message listening tools include MSSoapT (Microsoft SOAP ToolKit) and tcpTrace. Let's talk about using them to listen to SOAP messages.
After WebService is published, you can generate a Service proxy class by using the WebService URI address or the WSDL document of WebService (see the previous section ).
After the production of the proxy class is complete, set the port number in the constructor of the proxy class. For example:
public class ExamService : SoapHttpClientProtocol{ private SendOrPostCallback divideOperationCompleted; /// <remarks/> public ExamService() { Url = "http://193.168.11.94:8866/ExamService/WebService1.asmx"; }....}
The above http: // 193.168.11.94: 8866 is the local port number when the tool is used to listen to the SOAP message. Note: If you are using the Asp. Net Development Server in the VS debugging environment, a port number will also be used. The actual listening port number is the port set in the proxy class, which is generally different from it.
7.1 use MSSoapT to listen to SOAP messages
Set the listening port and host information, such:
In this way, MSSoapT listens to SOAP messages during program debugging, for example:
The upper part is the request SOAP message, and the lower part is the return SOAP message. For example:
7.2. Use tcpTrace to listen to SOAP messages.
The following message is received: