ISO/IEC 29362:2008 情報技術— Webサービスの相互運用性—WS-I添付ファイルプロファイルバージョン1.0 | ページ 2

この規格 プレビューページの目次

※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。

序文

ISO (国際標準化機構) と IEC (国際電気標準会議) は、世界標準化のための専門システムを形成しています。 ISO または IEC のメンバーである各国団体は、特定の技術活動分野に対処するためにそれぞれの組織によって設立された技術委員会を通じて国際規格の開発に参加しています。 ISO と IEC の技術委員会は、相互に関心のある分野で協力します。政府および非政府の他の国際機関も、ISO および IEC と連携してこの作業に参加しています。情報技術の分野では、ISO と IEC は共同技術委員会 ISO/IEC JTC 1 を設立しました。

国際規格は、ISO/IEC 指令第 2 Part に規定されている規則に従って草案されています。

合同技術委員会の主な任務は、国際規格を作成することです。合同技術委員会によって採択された国際規格草案は、投票のために各国機関に配布されます。国際規格として発行するには、投票を行っている国家機関の少なくとも 75% による承認が必要です。

この文書の要素の一部が特許権の対象となる可能性があることに注意してください。 ISO および IEC は、そのような特許権の一部またはすべてを特定する責任を負わないものとします。

ISO/IEC 29362 は Web サービス相互運用性機構 (WS-I) によって作成され、ISO および IEC の各国機関による承認と並行して、PAS 手順に基づいて合同技術委員会 ISO/IEC JTC 1, 情報技術によって採択されました。 IE

ISO/IEC 29362:2008 のこの修正バージョンには、元のバージョンの 3.1, 3.4, および 4.4 のサンプル コードに欠落していた文字が含まれています。

1 範囲と概要

1.1 範囲

この国際標準は、相互運用性を促進することを目的とした一連の非独自の Web サービス仕様と、それらの仕様の明確化および拡張で構成される WS-I Attachments Profile 1.0 (以下、「プロファイル」) を定義します。このプロファイルは WS-I Basic Profile 1.1 を補完し、SOAP メッセージを使用した相互運用可能な SOAP メッセージと添付ファイルベースの添付ファイルの伝達のサポートを追加します。

添付ファイル付きの SOAP メッセージ (SwA) は、SOAP メッセージに添付ファイルをパッケージ化するための MIME マルチパート/関連構造を定義します。このプロファイルは WS-I Basic Profile 1.1 を補完し、相互運用可能な SwA ベースの添付ファイルを SOAP メッセージで伝達するためのサポートを追加します。

セクション 1 では、プロファイルを紹介し、他のプロファイルとの関係について説明します。

セクション 2「プロファイルの適合性」では、プロファイルに適合するとはどういう意味かを説明します。

後続の各セクションはプロファイルのコンポーネントを扱い、コンポーネントの仕様とその拡張性のポイントを詳述する概要と、その後にコンポーネント仕様の個々の部分を扱うサブセクションの 2 つの部分で構成されます。

1.2 他のプロファイルとの関係

このプロファイルは、添付ファイル付きの SOAP および MIME バインディングのサポートを追加し、Basic Profile 1.1 と組み合わせて使用​​することを目的としています。

1.3 表記規則

この文書内のキーワード「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨」、「してもよい」、および「任意」は次のとおりです。 RFC2119 のように解釈されます。

プロファイル内の要件の規範的な記述 (すなわち、「準拠要件」で概説されているように、準拠に影響を与えるもの) は、次の方法で提示されます。

ここで、「nnnn」はプロファイル内の要件間で一意の番号に置き換えられ、それによって一意の要件識別子が形成されます。

要件識別子は、 XML の名前空間 からの QName と互換性があるように、名前空間で修飾されていると考えることができます。要件の識別子に明示的な名前空間プレフィックスがない場合 (たとえば、「bp10:R9999」ではなく「R9999」)、その識別子は、それが出現するドキュメント セクションの適合 URI によって識別される名前空間内にあるものとして解釈される必要があります。修飾されている場合、プレフィックスは、以下に記載されているように、有効な名前空間マッピングに従って解釈される必要があります。

一部の要件は、参照される仕様を明確にしますが、実装に追加の制約を課しません。便宜上、説明には次の方法で注釈が付けられています。 C

一部の要件は、参照仕様に関する進行中の標準化作業から派生しています。便宜上、そのような前方派生ステートメントには次の方法で注釈が付けられます: xxxここで、「xxxx」は仕様の識別子です (たとえば、WSDL バージョン 2.0 の場合は「WSDL20」)このドキュメントが発行された時点ではそのような作業は完了していなかったので、要件の元となった仕様は変更される可能性があることに注意してください。この情報は、実装者の便宜のためにのみ含まれています。

基礎となる仕様の拡張性ポイント (「適合範囲」を参照) は、同様の方法で示されます。

ここで、「nnnn」は、プロファイル内の拡張ポイント間で一意の番号に置き換えられます。要件ステートメントと同様に、拡張性ステートメントは名前空間で修飾されていると見なすことができます。

この仕様では、全体を通じて多数の名前空間プレフィックスを使用します。それらに関連付けられた URI を以下に示します。名前空間プレフィックスの選択は任意であり、意味的に重要ではないことに注意してください。

  • • 石鹸 - 「 http://schemas.xmlsoap.org/soap/envelope/ 」
  • • xsi - 「 http://www.w3.org/2001/XMLSchema-instance 」
  • • xsd - 「 http://www.w3.org/2001/XMLSchema 」
  • • soapenc - 「 http://schemas.xmlsoap.org/soap/encoding/ 」
  • • wsdl - 「 http://schemas.xmlsoap.org/wsdl/ 」
  • • soapbind - 「 http://schemas.xmlsoap.org/wsdl/soap/ 」
  • • mime - 「 http://schemas.xmlsoap.org/wsdl/mime/ 」
  • • uddi -「urn:uddi-org:api_v2」
  • • wsi - 「 http://www.ws-i.org/schemas/conformanceClaim 」
  • • 参照 - 「 http://ws-i.org/profiles/basic/1.1/xsd 」

1.4 プロファイルの識別とバージョン管理

このドキュメントは、名前 (この場合は添付ファイル プロファイル) とバージョン番号 (ここでは 1.0) によって識別されます。これらを組み合わせることで、特定のプロファイル インスタンスが識別されます。

バージョン番号は、「メジャー.マイナー」の形式で、メジャー部分とマイナー部分で構成されます。これらは、プロファイル インスタンスの優先順位を決定するために使用できます。バージョン番号が大きいほど (メジャー コンポーネントとマイナー コンポーネントの両方を考慮して) インスタンスが新しいことを示し、したがって以前のインスタンスよりも優先されます。

同じ名前のプロファイルのインスタンス (例: 「サンプル プロファイル 1.1」と「サンプル プロファイル 5.0」) は、同じ一般的なスコープで相互運用性の問題に対処します (ただし、開発によっては、インスタンス間でプロファイルの正確なスコープを変更する必要がある場合があります)

この情報を使用して、プロファイルの 2 つのインスタンスに下位互換性があるかどうかを判断することもできます。つまり、以前のプロファイル インスタンスへの適合が後のプロファイル インスタンスへの適合を意味すると仮定できるかどうかです。同じ名前とメジャー バージョン番号を持つプロファイル インスタンス (例: 「サンプル プロファイル 1.0」と「サンプル プロファイル 1.1」) は、互換性があるとみなされてもよい(MAY)これは、他の方向の互換性については何も意味しないことに注意してください。つまり、後のプロファイル インスタンスへの適合が、以前のプロファイル インスタンスへの適合を意味すると仮定することはできません。

Foreword

ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized 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 committees 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.

International 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. 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 all such patent rights.

ISO/IEC 29362 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.

This corrected version of ISO/IEC 29362:2008 includes characters which were missing from the sample code in 3.1, 3.4 and 4.4 of the original version.

1 Scope and introduction

1.1 Scope

This International Standard defines the WS-I Attachments Profile 1.0 (hereafter,"Profile"), consisting of a set of non-proprietary Web services specifications, along with clarifications to and amplifications of those specifications that are intended to promote interoperability. This profile complements the WS-I Basic Profile 1.1 to add support for conveying interoperable SOAP Messages with Attachments-based attachments with SOAP messages.

SOAP Messages with Attachments (SwA) defines a MIME multipart/related structure for packaging attachments with SOAP messages. This profile complements the WS-I Basic Profile 1.1 to add support for conveying interoperable SwA-based attachments with SOAP messages.

Section 1 introduces the Profile, and explains its relationships to other profiles.

Section 2,"Profile Conformance," explains what it 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.

1.2 Relationship to other Profiles

This Profile adds support for SOAP with Attachments and MIME bindings, and is intended to be used in combination with the Basic Profile 1.1.

1.3 Notational Conventions

The keywords"MUST","MUST NOT","REQUIRED","SHALL","SHALL NOT","SHOULD","SHOULD NOT","RECOMMENDED","MAY", and"OPTIONAL" in this document are to be interpreted as in RFC2119 .

Normative statements of requirements in the Profile (i.e., those impacting conformance, as outlined in"Conformance Requirements") are presented in the following manner:

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 compatible with QNames from Namespaces in XML . If there is no explicit namespace prefix on a requirement's 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.

Some requirements clarify the referenced specification(s), but do not place additional constraints upon implementations. For convenience, clarifications are annotated in the following manner: C

Some requirements are derived from ongoing standardization work on the referenced specification(s). For convenience, such forward-derived statements are annotated in the following manner: xxxx, where"xxxx" is an identifier for the specification (e.g.,"WSDL20" for WSDL Version 2.0). Note that because such work was not complete when this document was published, the specification that the requirement is derived from may change; this information is included only as a convenience to implementers.

Extensibility points in underlying specifications (see"Conformance Scope") are presented in a similar manner:

where"nnnn" is replaced by a number that is unique among the extensibility points in the Profile. As with requirement statements, extensibility statements can be considered namespace-qualified.

This specification uses a number of namespace prefixes throughout; their associated URIs are listed below. Note that the choice of any namespace prefix is arbitrary and not semantically significant.

  • • soap -" http://schemas.xmlsoap.org/soap/envelope/ "
  • • xsi -" http://www.w3.org/2001/XMLSchema-instance "
  • • xsd -" http://www.w3.org/2001/XMLSchema "
  • • soapenc -" http://schemas.xmlsoap.org/soap/encoding/ "
  • • wsdl -" http://schemas.xmlsoap.org/wsdl/ "
  • • soapbind -" http://schemas.xmlsoap.org/wsdl/soap/ "
  • • mime -" http://schemas.xmlsoap.org/wsdl/mime/ "
  • • uddi -"urn:uddi-org:api_v2"
  • • wsi -" http://www.ws-i.org/schemas/conformanceClaim "
  • • ref -" http://ws-i.org/profiles/basic/1.1/xsd "

1.4 Profile Identification and Versioning

This document is identified by a name (in this case, Attachments Profile) and a version number (here, 1.0). Together, they identify a particular profile instance.

Version numbers are composed of a major and minor portion, in the form"major.minor". They can be used to determine the precedence of a profile instance; a higher version number (considering both the major and minor components) indicates that an instance is more recent, and therefore supersedes earlier instances.

Instances of profiles with the same name (e.g.,"Example Profile 1.1" and"Example Profile 5.0") address interoperability problems in the same general scope (although some developments may require the exact scope of a profile to change between instances).

One can also use this information to determine whether two instances of a profile are backwards-compatible; that is, whether one can assume that conformance to an earlier profile instance implies conformance to a later one. Profile instances with the same name and major version number (e.g.,"Example Profile 1.0" and"Example Profile 1.1") MAY be considered compatible. Note that this does not imply anything about compatibility in the other direction; that is, one cannot assume that conformance with a later profile instance implies conformance to an earlier one.