メッセージングプロバイダーは、使用する2種類のWSDLを提供します。
http://my.amazonaws.com:8000/webservice/?wsdl
http://my.amazonaws.com:8000/webservice/?singleWsdl
最初のものはembedded WSDLです。 WSDL2Java
パッケージの生成には使用できません。また、JAX-WSを使用して接続を作成することはできません。
2番目はsingle WSDLです。 CXF 3.0のWSDL2JavaでJavaパッケージを生成でき、JAX-WSを使用して接続を作成できます。非常にうまく機能します。
これら2種類のWSDLの違いを教えてください。
これらのリンクが何を返すのかを知らなくても推測することしかできませんが、ここで役立つ可能性のある詳細をいくつか示します。
Webサービスエンドポイントに?wsdl
を付加すると、WSDLファイルが得られます。 WSDLは、Webサービスのスケルトンコードに基づいて実行時にフレームワークによって生成されるか、URLパラメーターが指定されたときにサーバーが送信する実際の物理ファイルである場合があります。
WSDLには、WSDL自体の内部で、またはWSDLによってインポートされる個別のファイルとして指定できるXMLスキーマが含まれています。そして今、問題が発生します...
一部のWebサービススタブジェネレーターは、スキーマが内部にある完全なWSDLのみを処理できます。 WSDLが他のファイルをインポートする場合、ツールはインポートを解決できず、失敗します。クライアントがWebサービスとやり取りするためのスタブの作成に問題を抱えていたため、これによりWebサービスの消費が困難になりました。サービスプロバイダーは、実際のWSDLを使用して?wsdl
リクエストに応答するか、あらゆる種類のハックとプラグインの作成を開始して、Webサービスが完全なWSDLを生成するようにしました。
しかし、一部のプロバイダーは気にしさえしなかったため、クライアントはWSDLを解析するためにハックを作成するか、すべてのファイルをダウンロードし、手動で1つのファイルにまとめて代わりに使用する必要がありました。
時間が経つにつれて、人々はこれを問題として認識し、フレームワークはインポートを備えたものではなく、完全なWSDLを提供するようになりました。しかし、これにより別の問題が発生しました。 ?wsdl
URLが返すものを変更すると、その周囲に作成されたすべてのハッキングが壊れてインポートの問題が修正される可能性があります。このため、完全なWSDLを返す別の規則が選択されました:?singleWsdl
。
そのため、完全なWSDLを生成するフレームワーク、インポートで生成するもの、実際の物理ファイルを指定できるもの、?singleWsdl
規則をサポートするもの、しないものがあります。この質問には関係ありませんが、完了のためだけに、WSDL 2.0定義を取得する?wsdl2
規則もあります(?wsdl
WSDL 1.1を取得します)。 ?wsdl2
をサポートするフレームワークもあれば、サポートしないフレームワークもあります。
私の推測では、あなたが抱えている問題はスキーマのインポートに起因するものですが、WSDL自体がなければ私にはわかりません。少なくともこれらの詳細が問題の特定に役立つことを願っています。