1、 Reference number ISO/IEC 29361:2008(E) ISO/IEC 2008INTERNATIONAL STANDARD ISO/IEC 29361 First edition 2008-06-15 Information technology Web Services Interoperability WS-I Basic Profile Version 1.1 Technologies de linformation Interoprabilit des services du Web Profil de base WS-I, version 1.1 ISO/I
2、EC 29361:2008(E) PDF disclaimer This PDF file may contain embedded typefaces. In accordance with Adobes licensing policy, this file may be printed or viewed but shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downlo
3、ading this file, parties accept therein the responsibility of not infringing Adobes licensing policy. The ISO Central Secretariat accepts no liability in this area. Adobe is a trademark of Adobe Systems Incorporated. Details of the software products used to create this PDF file can be found in the G
4、eneral Info relative to the file; the PDF-creation parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address gi
5、ven below. COPYRIGHT PROTECTED DOCUMENT ISO/IEC 2008 All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO a
6、t the address below or ISOs member body in the country of the requester. ISO copyright office Case postale 56 CH-1211 Geneva 20 Tel. + 41 22 749 01 11 Fax + 41 22 749 09 47 E-mail copyrightiso.org Web www.iso.org Published in Switzerland ii ISO/IEC 2008 All rights reservedISO/IEC 29361:2008(E) ISO/I
7、EC 2008 All rights reserved iiiContents Foreword .viii 1 Scope and introduction1 1.1 Scope.1 1.2 Relationships to Other Profiles.1 1.3 Changes from Basic Profile Version 1.0.2 1.4 Guiding Principles 2 1.5 Notational Conventions3 1.6 Profile Identification and Versioning.4 2 Profile Conformance5 2.1
8、Conformance Requirements 5 2.2 Conformance Targets 6 2.3 Conformance Scope 6 2.4 Claiming Conformance.7 3 Messaging .7 3.1 SOAP Envelopes .8 3.1.1 SOAP Envelope Structure.8 3.1.2 SOAP Envelope Namespace 9 3.1.3 SOAP Body Namespace Qualification.9 3.1.4 Disallowed Constructs.9 3.1.5 SOAP Trailers9 3.
9、1.6 SOAP encodingStyle Attribute.10 3.1.7 SOAP mustUnderstand Attribute.10 3.1.8 xsi:type Attributes 10 3.1.9 SOAP1.1 attributes on SOAP1.1 elements .11 ISO/IEC 29361:2008(E) iv ISO/IEC 2008 All rights reserved3.2 SOAP Processing Model11 3.2.1 Mandatory Headers .11 3.2.2 Generating mustUnderstand Fa
10、ults.11 3.2.3 SOAP Fault Processing.11 3.3 SOAP Faults 12 3.3.1 Identifying SOAP Faults.12 3.3.2 SOAP Fault Structure 12 3.3.3 SOAP Fault Namespace Qualification.13 3.3.4 SOAP Fault Extensibility14 3.3.5 SOAP Fault Language.14 3.3.6 SOAP Custom Fault Codes.14 3.4 Use of SOAP in HTTP15 3.4.1 HTTP Pro
11、tocol Binding 16 3.4.2 HTTP Methods and Extensions.16 3.4.3 SOAPAction HTTP Header16 3.4.4 HTTP Success Status Codes 17 3.4.5 HTTP Redirect Status Codes 17 3.4.6 HTTP Client Error Status Codes18 3.4.7 HTTP Server Error Status Codes 18 3.4.8 HTTP Cookies .18 4 Service Description19 4.1 Required Descr
12、iption20 4.2 Document Structure .20 4.2.1 WSDL Schema Definitions 20 ISO/IEC 29361:2008(E) ISO/IEC 2008 All rights reserved v4.2.2 WSDL and Schema Import21 4.2.3 WSDL Import location Attribute Structure22 4.2.4 WSDL Import location Attribute Semantics22 4.2.5 Placement of WSDL import Elements .23 4.
13、2.6 XML Version Requirements.24 4.2.7 XML Namespace declarations.24 4.2.8 WSDL and the Unicode BOM24 4.2.9 Acceptable WSDL Character Encodings.24 4.2.10 Namespace Coercion24 4.2.11 WSDL documentation Element25 4.2.12 WSDL Extensions25 4.3 Types .26 4.3.1 QName References.26 4.3.2 Schema targetNamesp
14、ace Structure.26 4.3.3 soapenc:Array .26 4.3.4 WSDL and Schema Definition Target Namespaces28 4.4 Messages.28 4.4.1 Bindings and Parts 29 4.4.2 Bindings and Faults.30 4.4.3 Declaration of part Elements .31 4.5 Port Types31 4.5.1 Ordering of part Elements .31 4.5.2 Allowed Operations .32 4.5.3 Distin
15、ctive Operations32 4.5.4 parameterOrder Attribute Construction32 4.5.5 Exclusivity of type and element Attributes .32 ISO/IEC 29361:2008(E) vi ISO/IEC 2008 All rights reserved4.6 Bindings .33 4.6.1 Use of SOAP Binding 33 4.7 SOAP Binding 33 4.7.1 Specifying the transport Attribute.33 4.7.2 HTTP Tran
16、sport.33 4.7.3 Consistency of style Attribute 34 4.7.4 Encodings and the use Attribute34 4.7.5 Multiple Bindings for portType Elements .34 4.7.6 Operation Signatures.34 4.7.7 Multiple Ports on an Endpoint35 4.7.8 Child Element for Document-Literal Bindings 35 4.7.9 One-Way Operations.35 4.7.10 Names
17、paces for soapbind Elements .36 4.7.11 Consistency of portType and binding Elements.36 4.7.12 Describing headerfault Elements.36 4.7.13 Enumeration of Faults37 4.7.14 Type and Name of SOAP Binding Elements .37 4.7.15 name Attribute on Faults38 4.7.16 Omission of the use Attribute.38 4.7.17 Default f
18、or use Attribute.38 4.7.18 Consistency of Envelopes with Descriptions .38 4.7.19 Response Wrappers39 4.7.20 Part Accessors 39 4.7.21 Namespaces for Children of Part Accessors .39 ISO/IEC 29361:2008(E) ISO/IEC 2008 All rights reserved vii4.7.22 Required Headers .41 4.7.23 Allowing Undescribed Headers
19、41 4.7.24 Ordering Headers41 4.7.25 Describing SOAPAction.42 4.7.26 SOAP Binding Extensions .43 4.8 Use of XML Schema 43 5 Service Publication and Discovery 44 5.1 bindingTemplates.44 5.2 tModels 45 6 Security46 6.1 Use of HTTPS47 Appendix A: Referenced Specifications.49 Appendix B: Extensibility Po
20、ints 50 Appendix C: Normative References 52 Appendix D: Defined Terms.53 Appendix E: Acknowledgements .55 ISO/IEC 29361:2008(E) viii ISO/IEC 2008 All rights reservedForeword ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the spec
21、ialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical c
22、ommittees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. Internat
23、ional Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. The main task of the joint technical committee is to prepare International Standards. Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting.
24、 Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or a
25、ll such patent rights. ISO/IEC 29361 was prepared by the Web Services Interoperability Organization (WS-I) and was adopted, under the PAS procedure, by Joint Technical Committee ISO/IEC JTC 1, Information technology, in parallel with its approval by national bodies of ISO and IEC. INTERNATIONAL STAN
26、DARD ISO/IEC 29361:2008(E) ISO/IEC 2008 All rights reserved 1Information technology Web Services Interoperability WS-I Basic Profile Version 1.1 1 Scope and introduction 1.1 Scope This International Standard defines the WS-I Basic Profile 1.1 (hereafter, “Profile“), consisting of a set of non-propri
27、etary Web services specifications, along with clarifications, refinements, interpretations and amplifications of those specifications which promote interoperability. Section 1 introduces the Profile, and explains its relationships to other profiles. Section 2, “Profile Conformance“, explains what it
28、 means to be conformant to the Profile. Each subsequent section addresses a component of the Profile, and consists of two parts: an overview detailing the component specifications and their extensibility points, followed by subsections that address individual parts of the component specifications. N
29、ote that there is no relationship between the section numbers in this International Standard and those in the referenced specifications. 1.2 Relationships to Other Profiles This Profile is derived from the Basic Profile 1.0 by incorporating any errata to date and separating out those requirements re
30、lated to the serialization of envelopes and their representation in messages. Such requirements are now part of the Simple SOAP Binding Profile 1.0, identified with a separate conformance claim. This separation is made to facilitate composability of Basic Profile 1.1 with any profile that specifies
31、envelope serialization, including the Simple SOAP Binding Profile 1.0 and the Attachments Profile 1.0. A combined claim of conformance to both the Basic Profile 1.1 and the Simple SOAP Binding Profile 1.0 is roughly equivalent to a claim of conformance to the Basic Profile 1.0 plus published errata.
32、 This Profile, composed with the Simple SOAP Binding Profile 1.0 supercedes the Basic Profile 1.0. The Attachments Profile 1.0 adds support for SOAP with Attachments, and is intended to be used in combination with this Profile. ISO/IEC 29361:2008(E) 2 ISO/IEC 2008 All rights reserved1.3 Changes from
33、 Basic Profile Version 1.0 This specification is derived from the Basic Profile Version 1.0, and incorporates published errata against that specification. The most notable changes are: MESSAGE conformance target - Some requirements that had a MESSAGE conformance target in BP1.0 now use a new target,
34、 ENVELOPE. This facilitates alternate serialisations of the message, such as that described in the Attachments Profile. SOAP Binding - Requirements relating to the SOAP bindings serialization of the message have been moved to the Simple SOAP Binding Profile to facilitate other serializations. 1.4 Gu
35、iding Principles The Profile was developed according to a set of principles that, together, form the philosophy of the Profile, as it relates to bringing about interoperability. This section documents these guidelines. No guarantee of interoperability It is impossible to completely guarantee the int
36、eroperability of a particular service. However, the Profile does address the most common problems that implementation experience has revealed to date. Application semantics Although communication of application semantics can be facilitated by the technologies that comprise the Profile, assuring the
37、common understanding of those semantics is not addressed by it. Testability When possible, the Profile makes statements that are testable. However, such testability is not required. Preferably, testing is achieved in a non- intrusive manner (e.g., examining artifacts “on the wire“). Strength of requ
38、irements The Profile makes strong requirements (e.g., MUST, MUST NOT) wherever feasible; if there are legitimate cases where such a requirement cannot be met, conditional requirements (e.g., SHOULD, SHOULD NOT) are used. Optional and conditional requirements introduce ambiguity and mismatches betwee
39、n implementations. Restriction vs. relaxation When amplifying the requirements of referenced specifications, the Profile may restrict them, but does not relax them (e.g., change a MUST to a MAY). Multiple mechanisms If a referenced specification allows multiple mechanisms to be used interchangeably,
40、 the Profile selects those that are well-understood, widely implemented and useful. Extraneous or underspecified mechanisms and extensions introduce complexity and therefore reduce interoperability. Future compatibility When possible, the Profile aligns its requirements with in-progress revisions to
41、 the specifications it references. This aids implementers by enabling a ISO/IEC 29361:2008(E) ISO/IEC 2008 All rights reserved 3graceful transition, and assures that WS-I does not fork from these efforts. When the Profile cannot address an issue in a specification it references, this information is
42、communicated to the appropriate body to assure its consideration. Compatibility with deployed services Backwards compatibility with deployed Web services is not a goal for the Profile, but due consideration is given to it; the Profile does not introduce a change to the requirements of a referenced s
43、pecification unless doing so addresses specific interoperability issues. Focus on interoperability Although there are potentially a number of inconsistencies and design flaws in the referenced specifications, the Profile only addresses those that affect interoperability. Conformance targets Where po
44、ssible, the Profile places requirements on artifacts (e.g., WSDL descriptions, SOAP messages) rather than the producing or consuming softwares behaviors or roles. Artifacts are concrete, making them easier to verify and therefore making conformance easier to understand and less error-prone. Lower-la
45、yer interoperability The Profile speaks to interoperability at the application layer; it assumes that interoperability of lower-layer protocols (e.g., TCP, IP, Ethernet) is adequate and well-understood. Similarly, statements about application-layer substrate protocols (e.g., SSL/TLS, HTTP) are only
46、made when there is an issue affecting Web services specifically; WS-I does not attempt to assure the interoperability of these protocols as a whole. This assures that WS-Is expertise in and focus on Web services standards is used effectively. 1.5 Notational Conventions The keywords “MUST“, “MUST NOT
47、“, “REQUIRED“, “SHALL“, “SHALL NOT“, “SHOULD“, “SHOULD NOT“, “RECOMMENDED“, “MAY“, and “OPTIONAL“ in this document are to be interpreted as described in RFC2119. Normative statements of requirements in the Profile (i.e., those impacting conformance, as outlined in “Conformance Requirements“) are pre
48、sented in the following manner: RnnnnStatement text here. where “nnnn“ is replaced by a number that is unique among the requirements in the Profile , thereby forming a unique requirement identifier. Requirement identifiers can be considered to be namespace qualified, in such a way as to be compatibl
49、e with QNames from Namespaces in XML. If there is no explicit namespace prefix on a requirements identifier (e.g., “R9999“ as opposed to “bp10:R9999“), it should be interpreted as being in the namespace identified by the conformance URI of the document section it occurs in. If it is qualified, the prefix should be interpreted according to the namespace mappings in effect, as documented below. ISO/IEC 29361:2008(E) 4 ISO/IEC 2008 All rights reservedSome requirements clarify the referenced specification(s), but do not
