0

私の環境の前提:すべての SOAP 要件を処理するために spring-ws を使用して Spring 3 で実行しています。これについては、さまざまなベンダーと複数の統合を行ってきましたが、問題はありません。

問題:この最近の統合には、非常に古いものを実行しているベンダーがいて、その WSDL は rpc バインド スタイルを使用しています。言うまでもなく、JAXWS は rpc を完全にはサポートしていません (相互運用のアンチテーゼであるため、当然のことです)。

考えられる解決策 #1: Axis 1 を使用して WSDL でスタブを生成することを試みることができます。実際、既にこれを行っていますが、Axis 依存関係を pom に導入することに非常に消極的です。現在非常に安定している環境を台無しにする可能性のある膨大な量のライブラリの競合が発生することは間違いありません。

考えられる解決策 #2: WSDL を、JAXWS が解析できるドキュメント/リテラル​​に書き直すことができます。WSDL を実際に書き換える際にいくつかの問題が発生します (「メッセージ部分 "xxx" のスキーマ記述子 {xxx}xxx を取得することは定義されておらず、Java にバインドできませんでした」)。その上、エンドポイントが特に rpc をチェックする場合、とにかく私はうんざりしています。

考えられる解決策 #3: Axis とこのサービス クライアントを実行するまったく新しいボックスをデプロイできます。つまり、メイン プロジェクトはこのボックスに対して REST 呼び出しを行い、SOAP 要求を作成して応答を解析します。それを行うのは非常にばかげた方法のようです（そして、単純であるべき何かのためのばかげた量の作業）。

私が逃した解決策はありますか？また、私はこれについてグーグルをトロールしてきました.一部の人々は＃1で成功していますが、その後のフォールアウトについては誰も実際に話していません. (つまり、Axis の従来の依存関係を処理したり、Spring 3 で Axis をうまく機能させようとしたりなど)

4

1 に答える 1

0

#1

#1 をより安定させる 1 つの方法は、Axis jar の独自のコピーを作成するために使用する Axis ソースのローカル コピーを取得することです。しかし、全体のパッケージを変更します。たとえば、org.apache.axis の代わりに com.mycompany.org.apache.axis になり、翻訳はかなり機械的になります。

次に、Axis1 のすべての依存関係 (古いバージョンの commons-beanutils など) も同じように扱われます。瓶をロードします。独自のカスタム パッケージで jar を構築します。(Maven でビルドすると、依存関係の特定がいくらか容易になります。)

これを行うと、元の Axis コードに更新と修正を組み込む機能がいくらか犠牲になります。リリースされた更新は、すべての .java ファイルにpackageおよびimports行が変更されているローカル コピーに組み込む方法を理解する必要がある一連の変更になります。

#2

＃2についてはわかりません。それはサイコロのロールですね。

#3

#3 で行っていることは、ESB が本当に得意とすることです。3 番目は、独自のミニ翻訳者を作成する場所です。私はそれをしました、そしてそれはうまくいきます。

ただし、実際には同じボックスでステップ 3 を構築できます。別のボックスは必要ありません。小さな翻訳アプリを、メイン ポートで実行される別のアプリケーションとしてデプロイします。アプリケーションを別のポートにデプロイするか、別の URL/パスとしてデプロイします。翻訳アプリは Axis1 を使用して受信メッセージを翻訳し、それを渡し、応答を翻訳して戻します。

このソリューションの優れた点の 1 つは、1 つのアプリケーションがあるかのように負荷分散を処理できることです。翻訳アプリとメイン アプリの負荷が高くなり、CPU サイクルの共有バケットが使い果たされます。さらに必要な場合は、まったく同じようにセットアップされたサーバーを追加します。

于 2013-04-04T18:17:46.433 に答える