soap チュートリアル => 石鹸を使い始める

備考

このセクションでは、soapの概要、および開発者がそれを使用する理由を概説します。

それはまた、石鹸内の大きな科目を言及し、関連するトピックにリンクする必要があります。 soapのドキュメンテーションは新しいので、これらの関連トピックの初期バージョンを作成する必要があります。

バージョン

バージョン	発売日
1.1	2000-05-08
1.2	2003-06-24

一般情報

SOAPは、リモートプロシージャコール（RPC）を介して他のSOAPサービスまたはクライアントとデータを交換するために使用されるプロトコルを定義するSimple Object Access Protocolの略語です。それは2つのバージョンで利用可能です：

SOAP 1.1 [ IETF ]
SOAP 1.2 [ IETF ]

SOAP 1.2はSOAP 1.1を廃止しており、可能であればSOAP 1.2を使用することが推奨されています。

HTTP / Sの上に構築され、SMTPやFTPではまれに構築されますが、プロトコルに応じてサポートされます。基本的なトランスポートプロトコルとしてHTTPがよく使用されますが、SOAPは限られたサブセットしか使用しません。リクエストを送信するためには、HTTPのPOST操作にほぼ完全に依存します。文書はURIパラメータとして渡されなければならないが、ほとんどのフレームワークでは拒否される約3000文字の境界を超える可能性があるが、 GET呼び出しは理論的には1.2以降可能である。また、セキュリティ関連の設定は通常、特別なSOAPヘッダー内で定義されます。

SOAPとRESTはWebサービスと呼ばれますが、本質的に非常に異なります。いくつかのフレームワークは、WS（SOAPベースのサービスの場合）とRS（RESTベースのサービスの場合）を区別します。

次の表は、両方のWebサービスタイプの違いの概要を示しています。

アスペクト	石鹸	残り
標準	SOAP 、 WSDL	標準はなく、単なる建築様式
リソースアドレッシング	SOAP操作による間接	固有のリソース識別子（URI）
エラー処理	SOAP障害メッセージ	HTTPエラー応答コードとオプションで応答本体
データ表現	XML	HTTPで利用可能なすべてのエンコーディング
HTTPの使用	トランスポートプロトコル	HTTPメソッド（GET、POST、PUT、DELETE、...）にマップされたリソースに対するアクション（CRUD）
トランザクションサポート	SOAPヘッダー経由	トランザクションをリソースとしてモデリングする
状態	ステートフル（SOAPアクションはアプリケーションの一部です）	ステートレス（自己完結型のリクエスト）
サービス発見	UDDI / WSDL	実際にはありません。 APIのStart-URIはサブAPIのリストを返します
方法	SOAP本体の内部	HTTPメソッド
メソッドの引数	WSDLのXMLスキーマによって定義される	HTTPヘッダーまたはURI内のPath / QueryまたはMatrixパラメーター経由で
状態遷移	データに直接基づいていないと判断しにくい	次のURI呼び出し
キャッシングサポート	しばしば望ましくないキャッシングは、	HTTPで定義されたシンプル

石鹸

SOAPリクエストは、body要素を含む必要があり、オプションのヘッダ要素を含むことができるSOAPエンベロープで構成されます。 WS-Securityは、メッセージが暗号化されていると定義されているか、またはWS-Coordination / WS-Transactionがメッセージをトランザクション内で実行する必要があると定義するように、特定の構成をサービスに渡すために使用されます。

2つの値を追加するHTTP経由の単純なSOAP 1.2要求は次のようになります。

POST /calculator HTTP/1.1
Host: http://example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 224

<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
 <env:Body>
  <m:AddValues xmlns:m="http://example.org/calculator">
   <m:FirstValue>1</m:FirstValue>
   <m:SecondValue>2</m:SecondValue>
  </m:AddValues>
 </env:Body>
</env:Envelope>

上記のサンプルリクエストに対する応答は次のようになります

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 329

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
               soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
 <soap:Body xmlns:m="http://www.example.org/calculator">
  <m:AddValuesResponse>
   <m:Result>3</m:Result>
  </m:AddValuesResponse>
 </soap:Body>
</soap:Envelope>

上記の例では、 FirstValueが1 、 SecondValueが2設定された2つの引数を持つAddValuesメソッドを呼び出す要求を定義しています。このリクエストはリモートSOAPサーバー上でこのメソッドを実行しました。結果として値3が結果として返されました。別のレスポンス要素にカプセル化されています。これは通常は呼び出されたメソッド名と後続のResponse文字列です。応答を調べると、これが以前のAddValueメソッド呼び出しの応答であると判断できます。

SOAP 1.1と1.2の違い

SOAP 1.2では、バインディングフレームワークがプロトコルでサポートされている限り、HTTP以外のトランスポートプロトコルを使用できます。

SOAP 1.1はXML 1.0をベースにしていますが、1.2はXML Infosetに基づいており、SOAP 1.1で使用されているデフォルトのXML 1.0シリアライザ以外のシリアライザでSOAPメッセージをシリアライズできます。これにより、メッセージをバイナリメッセージとしてシリアライズすることが可能になり、メッセージのXMLのオーバーヘッドを防ぐことができます。それに加えて、使用される基礎となるプロトコルのシリアル化メカニズムは、データバインディングを介して決定することができる。

相互運用性の側面は、SOAP 1.2では、より具体的な処理モデルを定義し、その先行モデルを定義することによって促進され、解釈の可能性を排除しました。 SOAP 1.1および1.2メッセージで動作することを可能にするAttachment API（SAAJ）付きSOAPは、多くのフレームワーク実装者がメッセージを処理して作成するのに役立ちました。

W3Cは、SOAP 1.1と1.2の主な変更点について簡単な概要を発表しました

Webサービスの相互運用性

Webサービス相互運用性（WS-Iとも呼ばれます）は、IBM、Microsoft、Oracle、HPなどの有名な企業によって管理される相互運用性のガイドラインです。これらのガイドラインは、SOAPが本体内に複数の要素を含むことを許可していても、SOAP本体内で単一のルート要素を使用することを推奨しています。

WS-Iは

WS-I基本プロファイル（WSI-BP）
WS-I基本セキュリティプロファイル
単純な石鹸の結合プロファイル

WSI-BPは、4つの異なるバージョンv1.0（2004）、 v1.1（2006）、 v1.2（2010）、 v2.0（2010）で利用可能であり、SOAP、WSDLなどのコアWebサービス仕様の相互運用性ガイドラインおよびUDDI。 SOAPサービスは、WSDL（Web Services Description Language）を使用して、サポートされている操作とメソッドを他のエンドポイントにまとまって記述することができます。 WSI-BPはWSDLを使用してより狭いセットを定義し、完全なWSDLまたはSOAPスキーマによって定義されるので、仕様自体の中のあいまいさの一部が排除され、エンドポイント間の相互運用性が向上します。

WSDL

使用可能なSOAP操作、そのパラメータ、およびクライアントに呼び出すそれぞれのエンドポイントを宣伝するために、 Web Services Description Language （WSDL）と呼ばれるXMLベースの文書が使用されていWeb Services Description Language 。

WSDLは、サービスエンドポイント、SOAPメッセージの操作へのバインディング、操作のインターフェース、およびそのタイプをクライアントに説明します。 WSDLは、SOAPと同様に、クライアントとほぼ同じセマンティクスを表現しますが、構文が少し異なる2つのバージョンで使用できます。

WSDL 1.1

WSDL 1.1記述には、 service 、 binding 、 portType 、およびmessageセクションが含まれていportType 。上記の電卓のサンプルに対応するサンプルWSDLファイルからわかるように、WSDLファイル内のスキーマをさらにインポートまたは定義できます。

<wsdl:definitions xmlns:xs="http://www.w3.org/2001/XMLSchema"
                  xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
                  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
                  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                  xmlns:calc="http://example.org/calculator"
                  xmlns:tns="http://example.org/calculatorService"
                  targetNamespace="http://example.org/calculatorService">

    <!--
      Abstract type definitions
    -->

    <wsdl:types>
        <!--
        <xs:schema>
            <xs:import namespace="http://example.org/calculator" schemaLocation="calc/calculator.xsd" />
        </xs:schema>
        -->
        <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
                   xmlns:tns="http://example.org/calculator"
                   targetNamespace="http://example.org/calculator"
                   elementFormDefault="qualified"
                   attributeFormDefault="qualified">

            <xs:element name="AddValuesRequest" type="tns:AddValuesType" />
            <xs:element name="AddValuesResponse" type="tns:AddValuesResponseType" />

            <xs:complexType name="AddValuesType">
                <xs:sequence>
                    <xs:element name="FirstValue" type="xs:int" minOccurs="1" maxOccurs="1" />
                    <xs:element name="SecondValue" type="xs:int" minOccurs="1" maxOccurs="1" />
                </xs:sequence>
            </xs:complexType>

            <xs:complexType name="AddValuesResponseType">
                <xs:sequence minOccurs="1" maxOccurs="1">
                    <xs:element name="Result" type="xs:int" />
                </xs:sequence>
            </xs:complexType>

            <xs:attribute name="Timestamp" type="xs:dateTime" />
            <xs:element name="CalculationFailure">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="ErrorCode" type="xs:int" />
                        <xs:element name="Reason" type="xs:string" />
                    </xs:sequence>
                    <xs:attribute ref="tns:Timestamp" use="required" />
                </xs:complexType>
            </xs:element>

        </xs:schema>
    </wsdl:types>

    <!--
        Abstract message definitions
    -->

    <wsdl:message name="AddValuesRequest">
        <wsdl:part name="in" element="calc:AddValuesRequest" />
    </wsdl:message>
    <wsdl:message name="AddValuesResponse">
        <wsdl:part name="out" element="calc:AddValuesResponse" />
    </wsdl:message>
    <wsdl:message name="CalculationFault">
        <wsdl:part name="fault" element="calc:CalculationFailure" />
    </wsdl:message>

    <!--
        Abstract portType / interface definition
    -->

    <wsdl:portType name="CalculatorEndpoint">
        <wsdl:operation name="AddValues">
            <wsdl:documentation>Adds up passed values and returns the result</wsdl:documentation>
            <wsdl:input message="tns:AddValuesRequest" />
            <wsdl:output message="tns:AddValuesResponse" />
            <wsdl:fault name="CalculationFault" message="tns:CalculationFault" />
        </wsdl:operation>
    </wsdl:portType>

    <!--
      Concrete binding definition
    -->

    <wsdl:binding name="CalculatorBinding" type="tns:CalculatorEndpoint">
        <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
        <wsdl:operation name="AddValues">
            <soap:operation soapAction="http://example.org/calculator/AddValuesMessage" />
            <wsdl:input>
                <soap:body parts="in" use="literal" />
            </wsdl:input>
            <wsdl:output>
                <soap:body parts="out" use="literal" />
            </wsdl:output>
            <wsdl:fault name="CalculationFault">
                <soap:fault name="CalculationFault" use="literal" />
            </wsdl:fault>
        </wsdl:operation>
    </wsdl:binding>

    <!--
        Concrete service definition
    -->

    <wsdl:service name="CalculatorService">
        <wsdl:port name="CalculatorServicePort" binding="tns:CalculatorBinding">
            <soap:address location="http://localhost:8080/services/calculator" />
        </wsdl:port>
    </wsdl:service>

</wsdl:definitions>

serviceセクションでは、サービスが着信要求をリッスンする具体的なエンドポイントを定義します。 bindingセクションは、オペレーションを具体的なスタイルにバインドし、サーバーが期待する、またはクライアントが期待できるメッセージフォーマットを定義します。

抽象セクションは、サービスによって提供される操作と交換されるメッセージを定義するportTypeブロックで構成されportType 。メッセージはonブロックで指定され、引数と戻り値がインスタンスであるスキーマ型にリンクされます。メッセージは、パラメータを宣言outたり、 in 、 outまたはinoutになる値を返すことができます。最初の2つは、後者が参照によって渡された引数の振る舞いを模倣するのは非常に簡単ですが。 pass-by-refは一部の言語ではサポートされていないため、この影響は特定のハンドラを使用してシミュレートされることがよくあります。

WSDL 2.0

同じ電卓は、次のようにWSDL 2.0で記述することができます。

<?xml version="1.0" encoding="utf-8" ?>
<wsdl:description xmlns:xs="http://www.w3.org/2001/XMLSchema"
                  xmlns:wsdl="http://www.w3.org/ns/wsdl"
                  xmlns:soap="http://www.w3.org/ns/wsdl/soap"
                  xmlns:calc="http://example.org/calculator"
                  xmlns:tns="http://example.org/calculatorService"
                  targetNamespace="http://example.org/calculatorService">

    <!--
      Abstract type definitions
    -->

    <wsdl:types>
        <!--
        <xs:schema>
            <xs:import namespace="http://example.org/calculator" schemaLocation="calc/calculator.xsd" />
        </xs:schema>
        -->
        <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
                   xmlns:tns="http://example.org/calculator"
                   targetNamespace="http://example.org/calculator"
                   elementFormDefault="qualified"
                   attributeFormDefault="qualified">

            <xs:element name="AddValuesRequest" type="tns:AddValuesType" />
            <xs:element name="AddValuesResponse" type="tns:AddValuesResponseType" />

            <xs:complexType name="AddValuesType">
                <xs:sequence>
                    <xs:element name="FirstValue" type="xs:int" minOccurs="1" maxOccurs="1" />
                    <xs:element name="SecondValue" type="xs:int" minOccurs="1" maxOccurs="1" />
                </xs:sequence>
            </xs:complexType>

            <xs:complexType name="AddValuesResponseType">
                <xs:sequence minOccurs="1" maxOccurs="1">
                    <xs:element name="Result" type="xs:int" />
                </xs:sequence>
            </xs:complexType>

            <xs:attribute name="Timestamp" type="xs:dateTime" />
            <xs:element name="CalculationFault">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="ErrorCode" type="xs:int" />
                        <xs:element name="Reason" type="xs:string" />
                    </xs:sequence>
                    <xs:attribute ref="tns:Timestamp" use="required" />
                </xs:complexType>
            </xs:element>

        </xs:schema>
    </wsdl:types>

    <!--
        Abstract interface
    -->

    <wsdl:interface name="CalculatorInterface">
        <wsdl:fault name="fault" element="calc:CalculationFault" />
        <wsdl:operation name="AddValues" pattern="http://www.w3.org/ns/wsdl/in-out" style="http://www.w3.org/ns/wsdl/style/iri" wsdl:safe="true">
            <wsdl:documentation>Adds up passed values and returns the result</wsdl:documentation>
            <wsdl:input messageLabel="in" element="calc:AddValuesRequest" />
            <wsdl:output messageLabel="out" element="calc:AddValuesResponse" />
            <wsdl:outfault messageLabel="fault" ref="tns:fault" />
        </wsdl:operation>
    </wsdl:interface>

    <!--
        Concrete binding definition
    -->

    <wsdl:binding name="CalculatorBinding" interface="tns:CalculatorInterface" type="http://www.w3.org/ns/wsdl/soap" soap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">
        <wsdl:operation ref="tns:AddValues" soap:mep="http://www.w3.org/2003/05/soap/mep/soap-response" />
        <wsdl:fault ref="tns:fault" soap:code="soap:Sender" />
    </wsdl:binding>

    <!--
        Concrete service definition
    -->

    <wsdl:service name="CalculatorService" interface="tns:CalculatorInterface">
        <wsdl:endpoint name="CalculatorEndpoint" binding="tns:CalculatorBinding" address="http://localhost:8080/services/calculator" />
    </wsdl:service>

</wsdl:description>

WSDL 1.1と2.0の違い

両方のバージョンの違いに関するグラフィカルな概要は、下の図に示されています。

（ソース）

イメージからわかるように、 messageセクションは削除されました。これは現在、 interfaceセクションに含まれていinterface 。また、要素の名前が変更されたり、構文が異なるものもありますが、一般にWSDLのバージョンはバージョン2.0と基本的に同じですが、1.1と比べると少しオーバーヘッドが必要です。

WSDL 2.0を介してSOAPベースのサービスを定義する際の実装面積が小さくなるだけでなく、新しいバージョンではRESTサービスを定義する機能も提供されますが、WSDL 2.0やWADLはRESTfulサービスには推奨されません。

どのスタイルを好むか

WSDLバインディングセクションでは、サービスがSOAPメッセージングプロトコルにどのようにバインドされているかについて説明します。上記のサンプルはバインディングスタイルとしてdocumentを使用しました。これにより、結果の出力が有効なXMLインスタンスである限り、SOAPボディを必要な方法で構造化することができます。これはデフォルトのバインディングスタイルであり、しばしばMessage-Oriented styleと呼ばれます。

documentスタイルとは対照的に、 RPCスタイルリクエストボディには、操作名とメソッドパラメータのセットの両方が含まれていなければなりません。したがって、XMLインスタンスの構造は事前定義されており、変更することはできません。

バインディング・スタイルに加えて、バインディング・セクションは、 literalまたはencoded名前でSOAPメッセージへのバインディングの変換モデルも定義します。この2つの違いは、 literalモデルはユーザー定義のXSD構造に準拠しなければならず、 encodedモデルはxs:integerやxs:stringなどのXSDデータ型を使用する必要がありますが、要求と応答の検証に使用できることです。そのため、ユーザ定義のスキーマに従わないことになります。しかし、これにより、メッセージ本文の検証やXSLTを介したメッセージの変換が難しくなります。

バインディングスタイルと使用モデルの組み合わせにより、実際には4つの異なるメッセージ結果が得られます。一般的に使用されるリストに5番目のエントリが追加されます（実際には標準の一部ではありません）。

RPC / encoded
RPC /リテラル
ドキュメント/コード化
ドキュメント/リテラル
ドキュメント/リテラル（ラップ）

メッセージングの文書/リテラルスタイルでは、wrapped-document / literalと呼ばれるパターンが存在します。これは単なるパターンであり、WSDL仕様の一部ではありません。このパターンは、JSR 224（JAX-WS：XMLベースのWebサービス用のJava API）に言及しています。（ソース）

以下のセクションでは、WSDLまたはスキーマ宣言の違いと、バインディングスタイルまたは使用モデル定義の変更時のSOAPメッセージフォーマットへの影響についての概要を示します。

RPC / encoded

WSDL：

...
<wsdl:message name="AddValues">
  <wsdl:part name="FirstValue" type="xsd:int" />
  <wsdl:part name="SecondValue" type="xsd:int" />
</wsdl:message>
<wsdl:message name="AddValuesResponse">
  <wsdl:part name="Result" type="xsd:int" />
</wsdl:message>

<wsdl:portType name="CalculatorEndpoint">
  <wsdl:operation="AddValues">
    <wsdl:input message="AddValues" />
    <wsdl:output message="AddValuesResponse" />
  </wsdl:operation>
</wsdl:portType>

<!-- binding style set to 'RPC' and use to 'encoded' -->
...

SOAPリクエスト

<soap:envelope>
  <soap:body>
    <AddValues>
      <FirstValue xsi:type="xsd:int">1</FirstValue>
      <SecondValue xsi:type="xsd:int">2</SecondValue>
    </AddValues>
  </soap:body>
</soap:envelope>

SOAPレスポンス

<soap:envelope>
  <soap:body>
    <AddValuesResponse>
      <Result xsi:type="xsd:int">3</Result>
    </AddValuesResponse>
  </soap:body>
</soap:envelope>

長所

単純なWSDL
要求と応答で利用可能な操作と要素の名前

短所

明示的なXSI型の宣言
検証が難しい
WS-I準拠ではない

RPC /リテラル

WSDL：

...
<wsdl:message name="AddValues">
  <wsdl:part name="FirstValue" type="xsd:int" />
  <wsdl:part name="SecondValue" type="xsd:int" />
</wsdl:message>
<wsdl:message name="AddValuesResponse">
  <wsdl:part name="Result" type="xsd:int" />
</wsdl:message>

<wsdl:portType name="CalculatorEndpoint">
  <wsdl:operation="AddValues">
    <wsdl:input message="AddValues" />
    <wsdl:output message="AddValuesResponse" />
  </wsdl:operation>
</wsdl:portType>

<!-- binding style set to 'RPC' and use to 'literal' -->
...

SOAPリクエスト

<soap:envelope>
  <soap:body>
    <AddValues>
      <FirstValue>1</FirstValue>
      <SecondValue>2</SecondValue>
    </AddValues>
  </soap:body>
</soap:envelope>

SOAPレスポンス

<soap:envelope>
  <soap:body>
    <AddValuesResult>
      <Result>3</Result>
    </AddValuesResult>
  </soap:body>
</soap:envelope>

長所

単純なWSDL
要求と応答で利用可能な操作と要素の名前
XSIタイプ指定が不要
WS-I準拠

短所

検証が難しい

ドキュメント/コード化

意味がないので省略する。

ドキュメント/リテラル

WSDL：

...
<types>
  <schema>
    <element name="FirstValueElement" type="xsd:int" />
    <element name="SecondValueElement" type="xsd:int" />
    <element name="ResultValueElement" type="xsd:int" />
  </schema>
</types>

<wsdl:message name="AddValues">
  <wsdl:part name="FirstValue" element="FirstValueElement" />
  <wsdl:part name="SecondValue" element="SecondValueElement" />
</wsdl:message>
<wsdl:message name="AddValuesResponse">
  <wsdl:part name="Result" element="ResultValueElement" />
</wsdl:message>

<wsdl:portType name="CalculatorEndpoint">
  <wsdl:operation="AddValues">
    <wsdl:input message="AddValues" />
    <wsdl:output message="AddValuesResponse" />
  </wsdl:operation>
</wsdl:portType>

<!-- binding style set to 'Document' and use to 'literal' -->
...

SOAPリクエスト

<soap:envelope>
  <soap:body>
    <FirstValueElement>1</FirstValueElement>
    <SecondValueElement>2</SecondValueElement>
  </soap:body>
</soap:envelope>

SOAPレスポンス

<soap:envelope>
  <soap:body>
    <ResultElement>3</ResultElement>
  </soap:body>
</soap:envelope>

長所

XSIタイプのエンコーディングはありません
ボディの検証が可能
制限付きWS-I準拠

短所

WSDLは、追加のXSD定義のためにさらに複雑です
操作名が失われました
WS-Iでは、SOAPボディ内の1人の子のみが許可されます

ドキュメント/リテラル（ラップ）

WSDL：

...
<types>
  <schema>
    <element name="AddValues">
      <complexType>
        <sequence>
          <element name="FirstValue" type="xsd:int" />
          <element name="SecondValue" type="xsd:int" />
        </sequence>
      </complexType>
    </element>
    <element name="AddValuesResponse">
      <complexType>
        <sequence>
          <element name="ResultValue" type="xsd:int" />
        </sequence>
      </complexType>
    </element>
  </schema>
</types>

<wsdl:message name="AddValues">
  <wsdl:part name="in" element="AddValues" />
</wsdl:message>
<wsdl:message name="AddValuesResponse">
  <wsdl:part name="out" element="AddValuesResponse" />
</wsdl:message>

<wsdl:portType name="CalculatorEndpoint">
  <wsdl:operation="AddValues">
    <wsdl:input message="AddValues" />
    <wsdl:output message="AddValuesResponse" />
  </wsdl:operation>
</wsdl:portType>

<!-- binding style set to 'Document' and use to 'literal' -->
...

SOAPリクエスト

<soap:envelope>
  <soap:body>
    <AddValues>
      <FirstValue>1</FirstValue>
      <SecondValue>2</SecondValue>
    </AddValues>
  </soap:body>
</soap:envelope>

SOAPレスポンス

<soap:envelope>
  <soap:body>
    <AddValuesResponse>
      <Result>3</Result>
    </AddValuesResponse>
  </soap:body>
</soap:envelope>

長所

XSIタイプのエンコーディングはありません
ボディの検証が可能
要求と応答で利用可能な操作と要素の名前
WS-I準拠

短所

WSDLは、追加のXSD定義のためにさらに複雑です

UDDI

Universal Description, Discovery and Integration (UDDI)は、特定のタスクを解決するサービスを見つけるのに役立つWebサービス用のXMLベースのイエローページレジストリとして機能する、2000年に作成されたオープン業界イニシアティブです。適切なサービスを見つけるには、まずUDDIなどのWebサービスレジストリにサービスを登録する必要があります。

UDDIはSOAPメッセージ交換で動作し、実際のWebサービスを呼び出すために使用できるWSDLドキュメントへのアクセスを提供します。

UDDIは以下のようなルックアップ基準を提供します。

ビジネス識別子
商号
事業所
ビジネスカテゴリ
名前によるサービスタイプ
発見URL

ただし、現在のUDDIの大きな欠点は、検索ステートメント内で単一の基準のみを使用できることです。したがって、特定の実装者は、UDDIの実装をモジュール化して、複数のUDDIを同時に生成するクエリを可能にし、返された結果を集約しました。

しかし実際には、UDDIはそれほど頻繁に使用されていません。 IBM、Microsoft、SAP が2005年にUDDIサービスを停止して以来、UDDIが死んでいるとも言われています。

さらにメモ：

SOAP / WSDLは幅広いツーリング・サポートを提供し、メッセージのタイプや交換されるデータが埋め込み型またはリンクされたXSDスキーマを通じて明確に定義されるため、クライアントとサーバーの両方でスタブ・クラスを動的に生成することもできます。

WSDL 2.0ではWebサービスを定義するオーバーヘッドが少なくなりますが、まだいくつかの言語ではまだ新しい標準を採用していません。 wsimport （Oracle / Sun）やwsdl2java （Apache CXF）などのJavaの一般的なツールでは、WSDL 2.0の記述を適切に処理できません。したがって、互換性の理由から、WSDL 1.1を使用することをお勧めします。 JavaでWSDL 2.0ベースのSOAPサービスを開発する必要がある場合は、 Apache Axis2プロジェクトからwsdl2javaを見てください。

しかし、最近では、HTTPベースのAPIサービス（人間が理解できるきれいなURIとHTTP操作呼び出しを混在させている）と、プロトコルをカスタマイズすることで、実際の推奨事項を完全に満たすRESTベースのサービス、またはOFTP2などの独自のバイトレベルプロトコルを使用します。

HTTP / RESTの基本サービスのようなリソースにタスクを直接マッピングすることができない場合、実行するタスクが自然にアクションを表したり、特定のトランザクションのセマンティクスを定義したりする必要があるため、SOAPは現在でも有用です。独自のプロトコルを定義または実装するためのリソースがない場合は、おそらくSOAPを使用する方がよいでしょう。 SOAPは、UDDIと組み合わせてWSDL記述を動的に組み合わせることができるため、オーケストレーションに対処する必要がある場合に特に便利です。

気象サービス用Javaクライアントhttp://www.webserviceX.NETで公開されているWebサービスを使用可能

  package com.test.ws.example;

 import javax.xml.soap.MessageFactory;
 import javax.xml.soap.MimeHeaders;
 import javax.xml.soap.SOAPBody;
 import javax.xml.soap.SOAPConnection;
 import javax.xml.soap.SOAPConnectionFactory;
 import javax.xml.soap.SOAPElement;
 import javax.xml.soap.SOAPEnvelope;
 import javax.xml.soap.SOAPMessage;
 import javax.xml.soap.SOAPPart;
 import javax.xml.transform.Source;
 import javax.xml.transform.Transformer;
 import javax.xml.transform.TransformerFactory;
 import javax.xml.transform.stream.StreamResult;

 /*
  * WSDL url :  http://www.webservicex.com/globalweather.asmx?WSDL
  * Endpoint URL: http://www.webservicex.com/globalweather.asmx   */

    public class WSClient {

   public static void main(String args[]) {

    try {
        SOAPConnectionFactory soapConnectionFactory = SOAPConnectionFactory.newInstance();
        SOAPConnection soapConnection = soapConnectionFactory.createConnection();

        // Generate SOAP request XML

        MessageFactory messageFactory = MessageFactory.newInstance();
        SOAPMessage soapMessage = messageFactory.createMessage();
        MimeHeaders header = soapMessage.getMimeHeaders();
        header.setHeader("SOAPAction", "http://www.webserviceX.NET/GetCitiesByCountry");
        SOAPPart soapPart = soapMessage.getSOAPPart();
        SOAPEnvelope envelope = soapPart.getEnvelope();
        envelope.addNamespaceDeclaration("web", "http://www.webserviceX.NET");
        SOAPBody soapBody = envelope.getBody();
        SOAPElement soapBodyElem = soapBody.addChildElement("GetCitiesByCountry", "web");
        SOAPElement soapBodyElem1 = soapBodyElem.addChildElement("CountryName", "web");
        soapBodyElem1.addTextNode("INDIA");
        soapMessage.saveChanges();
        soapMessage.writeTo(System.out);
        
                    
        // Call webservice endpint
        String url = "http://www.webservicex.com/globalweather.asmx";
        SOAPMessage soapResponse = soapConnection.call(soapMessage, url);
        Source sourceContent = soapResponse.getSOAPPart().getContent();

        // Print SOAP response
        TransformerFactory transformerFactory = TransformerFactory.newInstance();
        Transformer transformer = transformerFactory.newTransformer();
        System.out.println("Response SOAP Message \n");
        StreamResult result = new StreamResult(System.out);
        transformer.transform(sourceContent, result);
        soapConnection.close();

    } catch (Exception e) {

        e.printStackTrace();
    }
}

}

JAX-WS（ドキュメント/リテラル）を使用した単純なWebサービスとクライアントの作成

これはプロジェクトディレクトリです。

サービスエンドポイントインターフェイス

まず、サービスエンドポイントインターフェイスを作成します。 javax.jws.WebService @WebServiceアノテーションは、クラスをWebサービスのエンドポイントとして定義します。


import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;
import javax.jws.soap.SOAPBinding.Use;

// Service Interface with customize targetNamespace
@WebService(targetNamespace = "http://hello-soap/ws")
@SOAPBinding(style = Style.DOCUMENT, use=Use.LITERAL) //optional
public interface HelloSoap {

    @WebMethod String getHelloSoap(String name);

}

サービスエンドポイント実装（SEI）

次に、サービスエンドポイントの実装を作成します。実装クラスの@WebServiceアノテーションにendpointInterface要素を追加することにより、明示的なインタフェースを作成します。 28.1.1 JAX-WSエンドポイントが従わなければならないJAX-WSエンドポイントの要件。 getHelloSoapメソッドは、名前を渡してクライアントに挨拶を返します。


import javax.jws.WebService;

// Customized Service Implementation (portName,serviceName,targetNamespace are optional)

@WebService(portName = "HelloSoapPort", serviceName = "HelloSoapService",
endpointInterface = "com.wonderland.hellosoap.HelloSoap", targetNamespace = "http://hello-soap/ws")
public class HelloSoapImpl implements HelloSoap {

    @Override
    public String getHelloSoap(String name) {
        return "[JAX-WS] Hello : " + name;
    }

}

Webサービスエンドポイントパブリッシャ


import javax.xml.ws.Endpoint;

public class HelloSoapPublisher {

    public static void main(String[] args) {
        // creating web service endpoint publisher
        Endpoint.publish("http://localhost:9000/ws/hello-soap", new HelloSoapImpl());
    }

}

次のステップでは、 HelloSoapPublisher.javaをJavaアプリケーションとして実行します。次に、WebブラウザでURL http://localhost:9000/ws/hello-soap?wsdlを要求して、WSDLファイルを表示します。

http：// localhost：9000 / ws / hello-soap？wsdl

XMLデータ形式がWebブラウザに表示されている場合は、次のステップに進む準備が整いました。

注意：
何らかのエラーメッセージが表示される場合は、 wsgenツールを使用して必要なJAX-WSポータブルアーティファクトを生成する必要があります。ここではwsgenツールについては扱っていません。

Webサービスクライアント

最後に、公開されたサービスにアクセスするクライアントを作成します。


import java.net.URL;

import javax.xml.namespace.QName;
import javax.xml.ws.Service;

public class HelloSoapClient {

    public static void main(String[] args) throws Exception {

        // create wsdl url
        URL wsdlDocumentUrl = new URL("http://localhost:8000/ws/hello-soap?wsdl");
        QName helloSoapService = new QName("http://hello-soap/ws", "HelloSoapService");
        // create web service
        Service service = Service.create(wsdlDocumentUrl, helloSoapService);
        // get object of pointed service port
        HelloSoap helloSoap = service.getPort(HelloSoap.class);
        // testing request
        System.out.println(helloSoap.getHelloSoap("Soap "));

    }

}

出力： [JAX-WS] Hello : Soap

注： Webサービスクライアントでポート番号が8000に変更されました。その理由は、Eclipse IDEを使用して、 TCP/IP monitorツールをビルドしてメッセージをトレースします（詳細情報： Eclipse IDEでSOAPメッセージをトレースする方法）。機能テスト目的のために、 SoapUIを試してみてください。 SOAPおよびREST APIの機能テスト。

Modified text is an extract of the original Stack Overflow Documentation

ライセンスを受けた CC BY-SA 3.0

所属していない Stack Overflow

soap チュートリアル
石鹸を使い始める

サーチ…

備考

バージョン

一般情報

石鹸

SOAP 1.1と1.2の違い

Webサービスの相互運用性

WSDL

WSDL 1.1

WSDL 2.0

WSDL 1.1と2.0の違い

どのスタイルを好むか

RPC / encoded

RPC /リテラル

ドキュメント/コード化

ドキュメント/リテラル

ドキュメント/リテラル（ラップ）

UDDI

さらにメモ：

気象サービス用Javaクライアントhttp://www.webserviceX.NETで公開されているWebサービスを使用可能

JAX-WS（ドキュメント/リテラル）を使用した単純なWebサービスとクライアントの作成

備考

バージョン

一般情報

石鹸

SOAP 1.1と1.2の違い

Webサービスの相互運用性

WSDL

WSDL 1.1

WSDL 2.0

WSDL 1.1と2.0の違い

どのスタイルを好むか

RPC / encoded

RPC /リテラル

ドキュメント/コード化

ドキュメント/リテラル

ドキュメント/リテラル​​（ラップ）

UDDI

さらにメモ：

気象サービス用Javaクライアントhttp://www.webserviceX.NETで公開されているWebサービスを使用可能

JAX-WS（ドキュメント/リテラル​​）を使用した単純なWebサービスとクライアントの作成

ドキュメント/リテラル（ラップ）

JAX-WS（ドキュメント/リテラル）を使用した単純なWebサービスとクライアントの作成