6. Use SOAP in HTTP
This section describes how to work with HTTP with HTTP under the premise of using or without using HTTP Extension Framework. Bind SOAP to HTTP can utilize HTTP rich feature sets, and provide advantages to use SOAP form methods and distribution adaptability. Transfer SOAP on HTTP does not consider SOAP to completely transcend HTTP semantics, and more appropriate description should be Semantic in SOAP and naturally become the semantics of HTTP.
SOAP naturally utilizes HTTP's request / response message model, place the parameters of the SOAP request in the HTTP request, and place the parameters of the SOAP response in the HTTP response. Note that in any case, SOAP intermediate and HTTP intermediates are different. That is, the HTTP intermediates addressing the HTTP Connection header field generally cannot process the SOAP entity in the HTTP request.
When you need to include the SOAP message in the HTTP message, the HTTP application must use the media type "Text / XML" in accordance with RFC2376 [3].
6.1 SOAP HTTP Request
Although SOAP can be used in conjunction with a variety of HTTP request methods, the bindings here only define how SOAP is transmitted in the HTTP POST request. (See Section 7 Learn how to use SOAP in RPC, and how section 6.3 how to use HTTP EXTENSION FRAMEWORK
6.1.1 SoapAction fields in HTTP header
The SOAPACTION HTTP Request First Field (Header Field) can be used to indicate the purpose of the SOAP HTTP request. Its value is a URI that identifies the purpose. SOAP has no strict restrictions on the format, and there is no strict limit on the URI's description and whether it is parsing. When a SOAP HTTP request is issued, the HTTP customer must use the header field.
SOAPACTION = "soapaction" ":": "> <"> URI-REFERENCE <">] URI-Reference =
The existence of the soapaction header field and its content can be used by a server such as a firewall to filter SOAP request messages in HTTP. When the value of this field is an empty string (""), it means that the purpose of the SOAP message is provided by the HTTP Request-URI. And if there is no value, it indicates that the purpose of the message is not indicated.
E.g:
EXAMPLE 42
SOAPACTION: "http://electroctrocommerce.org/abc#mymessage"
SOAPACTION: "MyApp.sdl"
SOAPACTION: ""
SOAPACTION:
Examples of values for soapaction
6.2 SOAP HTTP Response
SOAP complies with HTTP complies with the semantics of the HTTP status code that represents the communication state in HTTP. For example, the 2xx status code indicates that this is a request for successful reception, understanding, and acceptance of the client contains SOAP components.
When the SOAP error occurs when the request is processed, the SOAP HTTP server must issue an HTTP 500 "InterNal Server Error" in response to the SOAP message contained in the response, indicating that SOAP processing is indicated by SOAP processing. mistake.
6.3 HTTP Extension Framework
SOAP messages can be used with HTTP Extension Framework [6] to identify the appearance and intentions of the SOAP HTTP request.
Is it a policy and capabilities that use EXTENSION FRAMEWORK or using simple HTTP for communication. The client can enforce HTTP Extension Framwork with a "M-" HTTP method prefix by a forced extension declaration. The server side can force the HTTP Extension Framework by using the 510 "Not Extended" HTTP status code. That is, through an additional row tour, each of each of the messages can detect other call parties and therefore actions. The extended identifier used to use the Extension Framework identifies SOAP is:
http://www.w3.org/2001/06/soap-ENvelope
6.4 SOAP HTTP example
EXAMPLE 43
POST / stockquote http / 1.1
Content-type: text / xml; charSet = "UTF-8"
Content-Length: nnnn
SOAPACTION: "http://electroctrocommerce.org/abc#mymessage"
.
SOAP HTTP Request Using POST
EXAMPLE 44
HTTP / 1.1 200 ok
Content-type: text / xml; charSet = "UTF-8"
Content-Length: nnnn
.
SOAP HTTP RESPONSE to EXAMPLE 43
EXAMPLE 45
M-post / stockquote http / 1.1
"Http://www.w3.org/2001/06/soap-envelope"; ns = nnnn
Content-type: text / xml; charSet = "UTF-8"
Content-Length: nnnn
Nnnn-soapaction: "http://electroctrocommerce.org/abc#mymessage"
.
SOAP HTTP Request Using The Experimental HTTP Extension Framework
EXAMPLE 46
HTTP / 1.1 200 ok
EXT:
Content-type: text / xml; charSet = "UTF-8"
Content-Length: nnnn
.
SOAP HTTP RESPONSE to EXAMPLE 45
7. Use SOAP in RPC
One design goal of SOAP is to package and exchange RPC calls with XML scalability and scalability. This section defines a unified remote procedure call and response.
In fact, we can also expect that in the RPC environment is probably a combination of coding styles defined in other representations. The SOAP ENCODINGSTYLE attribute (see section 4.3.2) can be used to indicate the coding style of the method calling / responding in this section. The use of SOAP with SOAP protocol (see section 6) is basically orthogonal to the SOAP protocol (see section 6). In the case of using HTTP as a SOAP protocol binding medium, an RPC call can be mapped to an HTTP request, while the RPC response can be mapped to the HTTP response. In any case, the RPC using the SOAP mode is not limited to the HTTP protocol binding.
To implement a method call, you need the following information:
Target SOAP node URI method name optional method or process feature or process parameter optional header data
SOAP relies on protocol binding to provide a mechanism for transmitting URIs. For example, for HTTP, request URI indicates a resource corresponding to the call. In addition to the requirements of this URI, SOAP does not limit the address (see [4] to get more information of the URI).
7.1 RPC and SOAP BODY
RPC calls and responses are transmitted in the SOAP body element (see section 4.3), using the following manipulation:
A method call is built into a structural Struct. This method call is displayed as a simple structure structure, contains access identity of each [IN] or [IN / OUT] parameter. The name and type of this structure can be identified using the name of the process or method. Each [IN] or [IN / OUT] parameter is represented as an access identifier, the name and type of the access identity correspond to the names and types of the corresponding parameters. Their order is also the order in the original RPC. A method response is built into a structural struct. This method response is shown as a simple structure Struct, contains access identity of each [OUT] or [IN / OUT] parameter. The first access identifier is a return value, and then it is followed by the original order. Each [OUT] or [IN / OUT] parameter is represented as an access identifier, the name and type of the access identifier correspond to the name and type of the corresponding parameters. There is not much semantic to the access identification name of the return value. The same, the name of the structure is not much semantic. Of course, in any case, after adding the "response" string, there is an agreement to name it. Method calling error should be encoded using the SOAP FAULT element (Catering Section 4.4). If a binding protocol has additional rules for errors, these rules should be observed.
As previously expressed, the structure and response structure can be encoded using rules defined in Section 5, or other encodings described in the EncodingStyle attribute (see section 4.1.1).
Applications can handle missing parameters, but you can also return an error.
Because if "Result" is included in the response, it indicates that "fail" indicates failure, so if the method response contains "Result" and "Fault", it is wrong.
7.2 RPC and SOAP HEADER
For those formal call data parts, it is not a method, but the method requests some additional information related to the encoding, or it can be represented in the RPC encoding. If so, it must be described as a child element of the SOAP Header element.
An example of using the Header element is to transmit a transaction ID in the message. The transaction ID is not a call in the parameter table, which is generally to be handled by the lower member rather than just an application ID, and there is no direct method to transfer this need in the call. By adding an entry on the head and imparts a fixed name, the receiver's transaction manager can extract the transaction ID, and it can be used without affecting the code called by the remote process.
8. Considering the safety mechanism
A description of the method of integrity and privacy protection is not included in this document. These issues will be described in detail in later versions of this document.
9. References
9.1. NORMATIVE REFERENCES
[2] IETF "RFC 2119: Key Words for use in rfcs to indeicate requirement level", S. Bradner, march 1997. available at http://www.ietf.org/rfc/rfc2119.txt[3] IETF "RFC" 2376: XML Media Types, E. Whitehead, M. Murata, July 1998. Available At http://www.ietf.org/rfc/rfc2376.txt
[4] IETF "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter, August 1998. Available At http://www.ietf.org/rfc/ Rfc2396.txt
[5] IETF "RFC 2616: Hypertext Transfer Protocol - HTTP / 1.1", R. Fielding, J. GetTys, JC Mogul, H. Frystyk, T. Berners-Lee, January 1997. Available At http: // www. Ietf.org/rfc/rfc2616.txt
[6] Ietf "RFC 2774: An HTTP Extension Framework", H. Nielsen, P. Leach, S. Lawrence, February 2000. Available At http://www.ietf.org/rfc/rfc2774.txt
[7] W3C Recommendation "EXTENSIBLE MARKUP LANGUAGE (XML) 1.0 (Second Edition", Tim Bray, Jean Paoli, CM Sperberg-McQueen, Eve Maler, 6 October 2000. Available At http://www.w3.org/tr / 2000 / REC-XML-20001006
[8] W3C Recommendation "Namespaces in XML", TIM BRAY, DAVE HOLLANDER, ANDREW LAYMAN, 14 January 1999. Available At http://www.w3.org/TR/1999/Rec-xml-names-19990114/
[9] W3c proposed Recommendation "XML LINKING LANGUAGE (XLINK) Version 1.0", Steve Derose, Eve Maler, David Orchard, 20 December 2000. Available At http://www.w3.org/tr/2000/pr-xlink- 20001220 /
[10] W3C Recommendation "XML Schema Part 1: Structure", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 May 2001. Available At http://www.w3.org/tr/2001/rec- XMLSChema-1-20010502 /
[11] W3C Recommendation "XML Schema Part 2: Datatypes", Paul V. Biron, Ashok Malhotra, 2 May 2001. Available At http://www.w3.org/tr/2001/rec-xmlschema-2-20010502/ 9.2. Informative References
[12] Transfer Syntax NDR, IN Open Group Technical Standard "DCE 1.1: Remote Procedure Call", August 1997. Available At http://www.opengroup.org/public/pubs/catalog/c706.htm
[13] IETF "RFC2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format Of Internet Message Bodies", N. FREED, N. Borenstein, November 1996. Available At http://www.ietf.org/rfc/rfc2045 .TXT
A. SOAP Envelope Examples
A.1 Sample Encoding of Call Requests
EXAMPLE 47
POST / stockquote http / 1.1
Host: www.stockquoteserver.com
Content-type: text / xml; charSet = "UTF-8"
Content-Length: nnnn
SOAPACTION: "http://example.org/2001/06/quotes"
XMLns: env = "http://www.w3.org/2001/06/soap-ENvelop"> XMLns: t = "http://example.org/2001/06/tx" Env: encodingstyle = "http://www.w3.org/2001/06/soap-encoding" Env: Mustunderstand = "1"> 5 Env: encodingstyle = "http://www.w3.org/2001/06/soap-encoding" XMLns: m = "http://example.org/2001/06/quotes"> Similar to Example 1 But with a Mandatory Header EXAMPLE 48 POST / stockquote http / 1.1 Host: www.stockquoteserver.com Content-type: text / xml; charSet = "UTF-8" Content-Length: nnnn SOAPACTION: "http://example.org/2001/06/quotes" Env: encodingstyle = "http://www.w3.org/2001/06/soap-encoding" XMLns: m = "http://example.org/2001/06/quotes"> Similar to Example 1 But With Multiple Request Parameters A.2 Sample ENCODING OF RESPONSE EXAMPLE 49 HTTP / 1.1 200 ok Content-type: text / xml; charSet = "UTF-8" Content-Length: nnnn XMLns: xsi = "http://www.w3.org/2001/xmlschema-instance" XMLns: XS = "http://www.w3.org/2001/xmlschema" XSI: Type = "xs: int" Env: encodingstyle = "http://www.w3.org/2001/06/soap-encoding" Env: Mustunderstand = "1"> 5 Env: encodingstyle = "http://www.w3.org/2001/06/soap-encoding" XMLns: m = "http://example.org/2001/06/quotes"> Similar to Example 2 But with a Mandatory Header EXAMPLE 50 HTTP / 1.1 200 ok Content-type: text / xml; charSet = "UTF-8" Content-Length: nnnn Env: EncodingStyle = "http://www.w3.org/2001/06/soap-encoding" XMLns: m = "http://example.org/2001/06/quotes"> Similar to Example 2 but with a structure EXAMPLE 51 HTTP / 1.1 500 INTERNAL Server Error Content-type: text / xml; charSet = "UTF-8" Content-Length: nnnn Similar to Example 2 But Failing to Honor Mandatory Header EXAMPLE 52 HTTP / 1.1 500 INTERNAL Server Error Content-type: text / xml; charSet = "UTF-8" Content-Length: nnnn Similar to Example 2 But Failing to Handle Body B. Acknowledgements This Document is The Work of The W3C XML Protocol Working GROUP. Members of the Working Group are (at the time of writing, and by alphabetical order): Yasser al Safadi (Philips Research), Vidur Apparao (Netscape), Don Box (DevelopMentor), David Burdett (Commerce One), Charles Campbell (Informix Software), Alex Ceponkus (Bowstreet), Michael Champion (Software AG), David Clay (Oracle), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Ron Daniel (Interwoven), Glen Daniels (Allaire), Doug Davis ( IBM), Ray Denenberg (Library of Congress), Paul Denning (MITRE Corporation), Frank DeRose (TIBCO Software, Inc.), Brian Eisenberg (Data Channel), David Ezell (Hewlett-Packard), James Falek (TIBCO Software, Inc .), David Fallside (IBM), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dan Frantz (BEA Systems), Dietmar Gaertner (Software AG), Scott Golubock (Epicentric), Rich Greenfield (Library of Congress), Martin Gudgin (Develop Mentor), HUGO Haas (W3C), Marc Hadley (Sun Microsystems), Mark Hale (Interwoven), Randy Hall (Intel), Gerd Hoelzing SAP AG), Oisin Hurley (Iona Technologies), Yin-Leng Husband (Compaq), John Ibbotson (IBM), Ryuji INOUE (Matshita Electric Industrial Co., Ltd.), Scott Isaacson (Novell, Inc.), Kazunori IWASA ( fujitsu Software Corporation), Murali Janakiraman (Rogue Wave), Mario Jeckle (Daimler-Chrysler Research and Technology), Eric Jenkins (Engenia Software), Mark Jones (AT & T), Jay Kasi (Commerce One), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Jacek Kopecky (IDOOX SRO), ALAN KropP (Epicentric), Yves Lafon (W3C), Tony Lee (Vitria Technology Inc.), Michah Lerner (AT & AT & T), Richard Martin (Active Data Exchange), Noah Mendelsohn (Lotus Development), Nilo Mitra (Ericsson Research Canada), Jean-Jacques Moreau (Canon), Masahiko Narita (Fujitsu Software Corporation), Mark Needleman (Data Research Associates), Eric Newcomer (IONA Technologies), Henrik Frystyk Nielsen (Microsoft Corporation), Mark Nottingham (Akamai Technologies), David Orchard (JamCracker), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Andreas Riegg (Daimler-Chrysler Research and Technology ), Hervé Ruellan (Canon), Marwan Sabbouh (MITRE Corporation), Shane Sesta (Active Data Exchange), Miroslav Simek (IDOOX sro), Simeon Simeonov (Allaire), Nick Smilonich (Unisys), Soumitro Tagore (Informix Software), James Tauber (Bowstreet), Lynne Thompson (Unisys), Patrick Thompson (Rogue Wave), Randy Waldrop (WebMethods), Ray Whitmer (Netscape), Volker Wiechers (SAP AG), Stuart Williams (Hewlett-Packard), Amr Yassin (Philips Research ) And Dick Brooks (Group 8760). Previous Members WERE: Eric Fedok (Active Data Exchange) Susan Yee (Active Data Exchange) Alex Milowski (Lexica), Bill Anderson (Xerox), Ed Mooney (Sun Microsystems), Mary Holstege (Calico Commerce), Rekha Nagarajan (Calico Commerce), John Evdemon ( XML Solutions), Kevin Mitchell (XML Solutions), Yan Xu (DataChannel) Mike Dierken (DataChannel) Julian Kumar (Epicentric) Miles Chaston (Epicentric) Bjoern Heckel (Epicentric) Dean Moses (Epicentric) Michael Freeman (Engenia Software) Jim Hughes ( fujitsu Software Corporation) Francisco Cubera (IBM), Murray Maloney (Commerce One), Krishna Sankar (Cisco), Steve Hole (MessagingDirect Ltd.) John-Paul Sicotte (MessagingDirect Ltd.) Vilhelm Rosenqvist (NCR) Lew Shannon (NCR) Henry Lowe (OMG) Jim Trezzo (Oracle) Peter Lecuyer (Progress Software) Andrew Eisenberg (Progress Software) David Cleary (Progress Software) George Scott (Tradia Inc.) Erin Hoffman (Tradia Inc.) Conleth O'Connell (Vignette) Waqar Sadiq (Vitria Technology Inc.) Tom Breuel (Xerox) David Webber (XMLGLO bal Technologies) Matthew MacKenzie (XMLGlobal Technologies) and Mark Baker (Sun Microsystems) .This document is based on the SOAP / 1.1 specification whose authors were: Don Box (Develop Mentor), David Ehnebuske (IBM), Gopal Kakivaya (Microsoft Corp. Andrew layman (Microsoft Corp.) Noah Mendelsohn (Lotus Development Corp.), Henrik Frystyk Nielsen (Microsoft Corp.), Satish Thatte (Microsoft Corp.) and Dave Winer (Userland Software, Inc.). WE Also Wish to Thank All The People Who Have Contributed to Discussions on XML-DIST-APP@w3.org. C. Version Transition from SOAP / 1.1 To SOAP VERSION 1.2 EdNote:.. The scope of the mechanism provided in this section is for transition between SOAP / 1.1 and SOAP version 1.2 The Working Group is considering providing a more general transition mechanism that can apply to any version Such a general mechanism may or may not be The Mechanism Provided Here Depending On WHETHER IT ITEMED Applicable.The SOAP / 1.1 Specification Says The Following On Version In Section 4.1.2: "SOAP does not define a traditional versioning model based on major and minor version numbers. A SOAP message MUST have an Envelope element associated with the" http://schemas.xmlsoap.org/soap/envelope/ "namespace. If a message is received by a SOAP application in which the SOAP Envelope element is associated with a different namespace, the application MUST treat this as a version error and discard the message. If the message is received through a request / response protocol such as HTTP, the application MUST Respond with a soap versionMismatch Faultcode Message (See Section 4.4) Using the soap "http://schemas.xmlsoap.org/soap/envelope/" namespace. " That is, rather than a versioning model based on shortnames (typically version numbers), SOAP uses a declarative extension model which allows a sender to include the desired features within the SOAP envelope construct. SOAP says nothing about the granularity of extensions nor how extensions may OR May Not Affect The Basic SOAP Processing Model. It is entire Up to Extension Designers Be It Either in a Central OR A Decentralized Manner To Determine Which Features Become SOAP EXTENSIONS. The Soap ExtensIlity Model Is Based on The Following Four Basic Assumptions: SOAP versioning is directed only at the SOAP envelope. It explicitly does not address versioning of blocks, encodings, protocol bindings, or otherwise. A SOAP node must determine whether it supports the version of a SOAP message on a per message basis. In the following , "support" means understanding the semantics of the envelope version identified by the QName of the Envelope element: A SOAP node receiving an envelope that it does not support must not attempt to process the message according to any other processing rules regardless of other up -. or downstream SOAP nodes A SOAP node may provide support for multiple envelope versions However, when processing a message a SOAP node must use the semantics defined by the version of that message It is essential that the envelope remains stable over time and that.. New features area mechanism. Changing the envelope inherently affects interoperability, add comple line - all of which directly conflicts with the SOAP requirements No versioning model or extensibility model can prevent buggy implementations Even though significant work has been going into clarifying the SOAP processing model, there is no guarantee that a SOAP 1.2 implementation will behave correctly... ONLY EXTENSIVE TESTINING THE SOAP Community and Design SIMPLICITY THE CAN HELP Prevent / Catch Bugs. The rules for dealing with the Possible SOAP / 1.1 and SOAP VERSION 1.2 Interactions Are As Follows: Because of the SOAP / 1.1 rules, a compliant SOAP / 1.1 node receiving a SOAP Version 1.2 message will generate a VersionMismatch SOAP fault using an envelope qualified by the "http://schemas.xmlsoap.org/soap/envelope/" namespace identifier . A SOAP Version 1.2 node receiving a SOAP / 1.1 message may either process the message as SOAP / 1.1 or generate a SOAP VersionMismatch fault using the "http://schemas.xmlsoap.org/soap/envelope/" namespace identifier. As part of the SOAP VersionMismatch fault, a SOAP Version 1.2 node should include the list of envelope versions that it supports using the SOAP upgrade extension identified by the "http://www.w3.org/2001/06/soap-upgrade" identifier. The upgrade extension contains an ordered list of namespace identifiers of SOAP envelopes that the SOAP node supports in the order most to least preferred Following is an example of a VersionMismatch fault generated by a SOAP Version 1.2 node including the SOAP upgrade extension.: EXAMPLE 53 VersionMismatch Fault generated by a soap version 1.2 node, and incruDing a soap upgrade extension NODES ARE NOT LIKELY TO INDICATE for NOTLOPE.D. Change Log D.1 SOAP Specification Changes DateAuthorDescription20010629MJGAmended description of routing and intermediaries in Section 2.120010629JJMChanged "latest version" URI to end with soap12 20010629JJMRemove "previous version" URI20010629JJMRemoved "Editor copy" in
