soap5.htm

这是一个实现登陆的页面程序

            (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 (XMLGlobal Technologies) Matthew MacKenzie (XMLGlobal 
            Technologies) and Mark Baker (Sun Microsystems).</P>
            <P></P>
            <P>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.).</P>
            <P></P>
            <P>We also wish to thank all the people who have contributed to 
            discussions on [e-mail].</P>
            <P></P>
            <P>C. Version Transition From SOAP/1.1 to SOAP Version 1.2</P>
            <P><BR>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 is deemed 
            applicable.</P>
            <P></P>
            <P>The SOAP/1.1 specification says the following on versioning in 
            section 4.1.2:</P>
            <P></P>
            <P>"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."</P>
            <P><BR>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 entirely up to extension designers be it 
            either in a central or a decentralized manner to determine which 
            features become SOAP extensions.</P>
            <P></P>
            <P>The SOAP extensibility model is based on the following four basic 
            assumptions:</P>
            <P></P>
            <P></P>
            <P>SOAP versioning is directed only at the SOAP envelope. It 
            explicitly does not address versioning of blocks, encodings, 
            protocol bindings, or otherwise. </P>
            <P>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: </P>
            <P></P>
            <P>A SOAP node receiving an envelope that it doesn't support must 
            not attempt to process the message according to any other processing 
            rules regardless of other up- or downstream SOAP nodes. </P>
            <P>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. </P>
            <P><BR>It is essential that the envelope remains stable over time 
            and that new features are added using the SOAP extensibility 
            mechanism. Changing the envelope inherently affects 
            interoperability, adds complexity, and requires central control of 
            extensions -- all of which directly conflicts with the SOAP 
            requirements. </P>
            <P>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 
            testing within the SOAP community and design simplicity at the core 
            can help prevent/catch bugs. </P>
            <P><BR>The rules for dealing with the possible SOAP/1.1 and SOAP 
            Version 1.2 interactions are as follows:</P>
            <P></P>
            <P></P>
            <P>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. 
            </P>
            <P>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. </P>
            <P><BR>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:</P>
            <P></P>
            <P></P>
            <P>Example 53</P>
            <P><BR>&lt;env:Envelope 
            xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"&gt; 
            &lt;env:Header&gt; &lt;V:Upgrade 
            xmlns:V="http://www.w3.org/2001/06/soap-upgrade"&gt; &lt;envelope 
            qname="ns1:Envelope" 
            xmlns:ns1="http://www.w3.org/2001/06/soap-envelope"/&gt; 
            &lt;/V:Upgrade&gt; &lt;/env:Header&gt; &lt;env:Body&gt; 
            &lt;env:Fault&gt; 
            &lt;faultcode&gt;env:VersionMismatch&lt;/faultcode&gt; 
            &lt;faultstring&gt;Version Mismatch&lt;/faultstring&gt; 
            &lt;/env:Fault&gt; &lt;/env:Body&gt;&lt;/env:Envelope&gt; </P>
            <P><BR>VersionMismatch fault generated by a SOAP Version 1.2 node, 
            and including a SOAP upgrade extension</P>
            <P><BR>Note that existing SOAP/1.1 nodes are not likely to indicate 
            which envelope versions they support. If nothing is indicated then 
            this means that SOAP/1.1 is the only supported envelope.</P>
            <P></P>
            <P>D. Change Log</P>
            <P><BR>D.1 SOAP Specification Changes</P>
            <P><BR><BR><BR>Date <BR>Author <BR>Description </P>
            <P><BR>20010629 <BR>MJG <BR>Amended description of routing and 
            intermediaries in Section 2.1 </P>
            <P><BR>20010629 <BR>JJM <BR>Changed "latest version" URI to end with 
            soap12 </P>
            <P><BR>20010629 <BR>JJM <BR>Remove "previous version" URI </P>
            <P><BR>20010629 <BR>JJM <BR>Removed "Editor copy" in &lt;title&gt; 
            </P>
            <P><BR>20010629 <BR>JJM <BR>Removed "Editor copy" in the title. </P>
            <P><BR>20010629 <BR>JJM <BR>Added "Previous version" to either point 
            to SOAP/1.1, or explicitly mention there was no prior draft. </P>
            <P><BR>20010629 <BR>JJM <BR>Pre-filed publication URIs. </P>
            <P><BR>20010629 <BR>JJM <BR>Incorporated David's suggested changes 
            for the examples in section 4.1.1 to 4.4.2 </P>
            <P><BR>20010629 <BR>JJM <BR>Fixed some remaining typos. </P>
            <P><BR>20010629 <BR>MJH <BR>Fixed a couple of typos. </P>
            <P><BR>20010628 <BR>MJG <BR>Made various formatting, spelling and 
            grammatical fixes. </P>
            <P><BR>20010628 <BR>MJG <BR>Moved soap:encodingStyle from 
            soap:Envelope to children of soap:Header/soap:Body in examples 1, 2, 
            47, 48, 49 and 50 </P>
            <P><BR>20010628 <BR>MJG <BR>Changed text in Section 2.1 from 'it is 
            both a SOAP sender or a SOAP receiver' to 'it is both a SOAP sender 
            and a SOAP receiver' </P>
            <P><BR>20010628 <BR>MJG <BR>Fixed caption on Example 24 </P>
            <P><BR>20010628 <BR>MJH <BR>Fixed a couple of capitalisation errors 
            where the letter A appeared as a capital in the middle of a 
            sentence. </P>
            <P><BR>20010628 <BR>MJH <BR>Updated figure 1, removed ednote to do 
            so. </P>
            <P><BR>20010622 <BR>HFN <BR>Removed the introductory text in 
            terminology section 1.4.3 as it talks about model stuff that is 
            covered in section 2. It was left over from original glossary which 
            also explained the SOAP model. </P>
            <P><BR>20010622 <BR>HFN <BR>Moved the definition of block to 
            encapsulation section in terminology </P>
            <P><BR>20010622 <BR>HFN <BR>Removed introductory section in 1.4.1 as 
            this overlaps with the model description in section 2 and doesn't 
            belong in a terminology section </P>
            <P><BR>20010622 <BR>HFN <BR>Removed reference to "Web 
            Characterization Terminology &amp; Definitions Sheet" in terminology 
            section as this is not an active WD </P>
            <P><BR>20010622 <BR>HFN <BR>Added revised glossary </P>
            <P><BR>20010622 <BR>HFN <BR>Added example 0 to section 1.3 and 
            slightly modified text for example 1 and 2 to make it clear that 
            HTTP is used as a protocol binding </P>
            <P><BR>20010622 <BR>MJG <BR>Added http://example.com/... to list of 
            application/context specific URIs in section 1.2 </P>
            <P><BR>20010622 <BR>MJG <BR>Updated examples in section 4.1.1 to be 
            encodingStyle attributes rather than just the values of attributes 
            </P>
            <P><BR>20010622 <BR>MJG <BR>Added table.norm, td.normitem and 
            td.normtext styles to stylesheet. Used said styles for table of 
            fault code values in section 4.4.1 </P>
            <P><BR>20010622 <BR>MJG <BR>In Appendix C, changed upgrade element 
            to Upgrade and env to envelope. Made envelope unqualified. Updated 
            schema document to match. </P>
            <P><BR>20010622 <BR>MJG <BR>Moved MisunderstoodHeader from envelope 
            schema into seperate faults schema. Removed entry in envelope schema 
            change table in Appendix D.2 that refered to additon of said 
            element. Modified example in section 4.4.2 to match. Added reference 
            to schema document to section 4.4.2 </P>
            <P><BR>20010622 <BR>MJH <BR>Added binding as a component of SOAP in 
            introduction. Fixed a couple of typos and updated a couple of 
            example captions. </P>
            <P><BR>20010622 <BR>MJG <BR>Made BNF in section 6.1.1 into a table. 
            </P>
            <P><BR>20010622 <BR>MJG <BR>Made BNFs in section 5.1 clause 8 into 
            tables. Added associated 'bnf' style for table and td elements to 
            stylesheet </P>
            <P><BR>20010622 <BR>MJG <BR>Amended text regarding namespace prefix 
            mappings in section 1.2 </P>
            <P><BR>20010622 <BR>MJG <BR>Added link to schema for the 
            http://www.w3.org/2001/06/soap-upgrade namespace to Appendix C. 
            Updated associated ednote. </P>
            <P><BR>20010622 <BR>MJG <BR>Added reference numbers for XML Schema 
            Recommendation to text prior to schema change tables in Appendix D.2 
            and linked said numbers to local references in this document </P>