The true face of WSDL soap action

I recently encounteredSoapSome are empty, some are not empty, and they are confused.

(SoapactionThe URI type value of the Property specifies the value of the soapaction header of this method. Do not use relative URIs in requests, but use absolute Uris. This value is required for HTTP-based soap binding. For soap binding of other protocols,DisableSpecify this value explicitly. Soap: Action elements can be defaulted .)

So they used the RPC format in the WSDL provided by China Telecom last time, but no soapaction was specified. When I changed the sope format to document, the generated client soapaction value was empty, it cannot be run. however, soapaction is required for HTTP requests.

It is said that soapaction header makes a pot of effort for many developers in the soap 1.1 specification. Is it so hard to understand? I think this is because there are two very different ways to use soap, and soapaction is mainly used to support a small number of applications. In my opinion, this method is also very valuable.

Let's first look at how the soap 1.1 Specification defines the HTTP soapaction header:

The soapaction HTTP request header is used to identify the destination of a soap HTTP request. Its value is a URI address. Soap sending does not limit the format, Uri features, or it must be parsed. In this case, when sending an http soap request, its HTTP client must use/to specify the soapaction HTTP request header.

The content of the soapaction header can be used on the server, for example, the firewall filters HTTP-based SOAP request messages. The soapaction header value is an empty string (""), indicating that the SOAP Message destination is identified by the HTTP request URI. If there is no value, it indicates that the Message destination is not specified.

After reading the official definition, I believe everyone is confused. Are you confused about the word "destination? Let's give it an accurate description-"determine the path for executing a certain behavior ".

Let's look at an example of a SOAP message:

<SOAP-ENV: Envelope
Xmlns: SOAP-ENV = "http://schemas.xmlsoap.org/soap/envelope"
SOAP-ENV: encodingstyle = "http://schemas.xmlsoap.org/soap/encoding/">
SOAP-ENV: Body>
<M: getlasttradeprice xmlns: M = "Some-Uri">
<Symbol> xys </symbol>
</M: getlasttradeprice>
SOAP-ENV: Body>
SOAP-ENV: envelope>

Obviously, this message indicates the method of "getlasttradeprice" to be executed on the server. Developers will not doubt this. In this case, the soap action may seem redundant?

However, in another SOAP message sending scenario, soap action is indispensable. In this scenario, the SOAP message does not display the specified service method name to be called, but uses the underlying transmission protocol to send the message (in this case, it is generally ignored by web services ), for example, a SOAP message sent using the http post method.

Take the AWT component container as an example. We know that there are many AWT containers, such as panel, box, and window. In many cases, developers know what objects are under the generic container objects they create. Assume that the java. AWT. container object in the following two sections of code is actually a box:

1.

Comp = new textfield ("test ");
Java. AWT. Container c = Foo. Bar ();
C. Add (COMP );

2.

Comp = new textfield ("test ");
Java. AWT. Container c = Foo. Bar ();
(Java. AWT. Panel) c). Add (COMP );

The above two sections of code generate two different results. The "add ()" method seems to have the same meaning for both, but in Code 2 it is extended to "Add as a panel object ". Obviously, code 2 throws an exception because we know that this object is actually a box, and our Code expects a panel.

The meaning of http post is just like the "add ()" method in this example. http post provides an index on how soapaction is used; the soapaction header value should be used to specify the "extension" Destination -- the name of the processing container expected by the SOAP/HTTP message sender (which can be understood as follows: that is, the corresponding API method ). As in the above AWT example, if this expectation is not met, an error will occur.

Note: In the soap 1.2 specification, the soapaction header attribute is replaced by "action", but its role and working principle remain unchanged.

Interestingly, in tibco's EAI tool BW, the soap action attribute must be specified when a SOAP server activity is used. If the referenced source WSDL does not use this attribute, it must be displayed; therefore, the client must also pay attention to it. You must enter the expected URI for the soap action attribute.