3

Manning Publications Co の Craig Walls による「Spring in Action」第 2 版で、Spring-WS を介した SOAP について読み終え​​たところです。彼らは、Spring のドキュメントと同様に、メッセージとメソッドを XML で作成し、Contract First について書いています。次に、それを XSD に変換してから WSDL に変換し、Spring でマーシャリングとサービス パスを配線します。

私は認めざるを得ません、私は確信していません。これが、たとえばサービス インターフェイスを作成し、そのインターフェイスに基づいてサービスを生成するよりも優れているのはなぜでしょうか? これは、Spring3 での REST @Controllers の定義に非常に近いものです。SpringでSOAP Webサービスを作成することで、このような道を進むオプションはありますか?

また、既存の Web サービスを複製したいと考えています。その WSDL があり、その代わりにサービスを配置できます。これはまったくお勧めですか？もしそうなら、推奨されるアプローチは何ですか？

乾杯

Nik
4

2 に答える 2

7

ワイヤーを交差させなければならないと思います。

コントラクトとは、最初に WSDL を定義し、次にこの WSDL をサポートする Java コードを作成することを意味します。

最後にコントラクトとは、Java コードを作成し、後で WSDL を生成することを意味します。

コントラクト ラストの危険性は、WSDL が Java コードから自動的に生成され、Java コードをリファクタリングすると、WSDL が変更されることです。

Spring-WS は最初にコントラクトのみをサポートします

2.3.1. もろさ

前述のように、contract-last 開発スタイルでは、Web サービス コントラクト (WSDL および XSD) が Java コントラクト (通常はインターフェイス) から生成されます。このアプローチを使用している場合、契約が長期間にわたって一定であるという保証はありません。Java コントラクトを変更して再デプロイするたびに、Web サービス コントラクトが変更される可能性があります。

さらに、すべての SOAP スタックが Java コントラクトから同じ Web サービス コントラクトを生成するわけではありません。これは、現在の SOAP スタックを別のものに変更すると (何らかの理由で)、Web サービスの契約も変更される可能性があることを意味します。

Web サービス コントラクトが変更された場合、コントラクトのユーザーは、新しいコントラクトを取得し、コードを変更してコントラクトの変更に対応するように指示する必要があります。

コントラクトが有用であるためには、コントラクトができるだけ長く一定である必要があります。契約が変更された場合は、サービスのすべてのユーザーに連絡し、新しいバージョンの契約を取得するように指示する必要があります。

于 2009-10-15T22:04:48.633 に答える
3

Java インターフェースが脆弱であるという Toolkit の指摘は正しいですが、それ以上のものがあると思います。

オブジェクトとリレーショナルのインピーダンスの不一致があるように、オブジェクトと XML の不一致もあります。Spring Web サービスのドキュメントでは、コレクションなどによって Java または .NET クラスからの XML ドキュメントの生成がどのように問題になるかについて、うまく説明されています。

Spring のアプローチを採用してスキーマから始めると、より良い結果が得られます。より安定し、「ダックタイピング」が可能になります。クライアントは不要な要素を無視できるため、新しい要素を追加することでスキーマに影響を与えずにスキーマを変更できます。

于 2009-10-16T00:51:46.893 に答える