リモート呼び出しを行うための SOAP クライアントが必要なだけですが、私は少し Groovy 初心者です。Groovy のドキュメントによると、標準の Groovy SOAP ライブラリは非推奨です。代わりに、ドキュメントは新しいライブラリGroovyWSを示しています。
残念ながら、GroovyWS には、プロジェクトが休止中であるという警告が表示され、Groovy WSLiteが表示されます。
Groovy WSLite は実際にはまだ開発が活発に行われているようですが、以前の 2 つのライブラリに比べて「Groovy っぽい」というわけではありません。みんなが使っているのはwsliteですか？
GroovyWSとgroovy-wslite (およびHTTP Builder ) の両方がプロジェクトで Groovy SOAP クライアント ライブラリとして使用されていることがわかると思います。決定はおそらく、どちらが機能し、どちらがユーザーが好む API/アプローチを持っているかでした (その中で注文）。
私のアドバイスは、 GroovyWS が提供する API と WSDL ドキュメントをプロキシする機能が気に入った場合は、 GroovyWSを試してみて、対話する必要があるサービスで機能するかどうかを確認することです。SOAP の世界では状況があまり変わっていないので、最近更新されたかどうかについてあまり心配する必要はありません。それが機能する場合は完了です。ヘルプがすぐに見つからない問題が発生した場合は、別の方法を試してみます.
groovy-wslite (免責事項: 私は作成者です) は、軽量 (依存関係の観点から) の代替手段を提供することを目的としています。この代替手段は、WSDL の構文解析/プロキシーの利便性と引き換えに、掘り下げずに結果の SOAP 呼び出しをより簡単に制御できるようにするものです。 CXF のようないくつかの基盤となる Java フレームワークの内部を深く掘り下げます。このようなフレームワークの上に構築されたライブラリの追加機能を好む人もいれば、他のアプローチの単純さを好む人もいます。
Groovy が優れている点は、Java との統合がいかに簡単かということです。したがって、他の人がすでに指摘しているように、Spring WS、CXF、JAX-WS などの Java Web サービス クライアントと簡単に統合できます。
私はgroovywsを避けたいと思います。いろいろ調べた結果、Spring Web サービスとコントラクト駆動の Web サービスを使用するソリューションを最終的に選択しました。
クライアントは、soap 要求 XML を生成する toXml() メソッドを使用してコマンド オブジェクトをインスタンス化します。次に、WebServiceTemplate を使用して sendToEndpoint を実行します。
サーバーには、Spring Web サービス エンドポイントを使用します。着信 xml の解析は子供の遊びです。XML をオブジェクトにマーシャリングする必要はありません。XmlSlurper から生成される GPathResult は完全に管理可能です。私たちのサーバーは grails 上で実行されるため、springws grails プラグインを利用して、エンドポイントの作成をさらに簡単にしました。
ただし、注意点が 1 つあります。grails の springws プラグインは古くなっています。Spring Web サービスは現在バージョン 2.x で、springws プラグインには 1.4.xi が付属しています。しかし、プラグインなしでも非常に使いやすく、プラグインを新しいAPIにアップグレードすることは難しくないと思います。
また、MTOM を実行したい場合は、メッセージ処理を深く掘り下げる必要があるため、springws はもう少し複雑になります。Spring Web サービスを使用してかなり高度な ws-security を実行できましたが、問題ありませんでした。
それ以外の場合は、jax-ws などに固執したい場合は、cxf (MTOM を適切に処理) を使用します。すべてのプロキシと pojo が動的に生成されるため、オーバーヘッドはおそらく高くなります。また、契約に基づくものではないことも、私たちにとって大きなプラスです。
あなたは宿題を自分でやったようです！Groovy WS Lite は現在動作しているようです。Groovy を使用して spring-ws の動作を確認したい場合は、github で作成したテスト スイートプロジェクトをご覧ください。