soap チュートリアル
石鹸を使い始める
サーチ…
備考
このセクションでは、soapの概要、および開発者がそれを使用する理由を概説します。
それはまた、石鹸内の大きな科目を言及し、関連するトピックにリンクする必要があります。 soapのドキュメンテーションは新しいので、これらの関連トピックの初期バージョンを作成する必要があります。
バージョン
バージョン | 発売日 |
---|---|
1.1 | 2000-05-08 |
1.2 | 2003-06-24 |
一般情報
SOAPは、リモートプロシージャコール(RPC)を介して他のSOAPサービスまたはクライアントとデータを交換するために使用されるプロトコルを定義するSimple Object Access Protocolの略語です。それは2つのバージョンで利用可能です:
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ブラウザでURLhttp://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の機能テスト 。