ネストされたマップ (バイナリ データ ストリームから生成) から SOAP クライアントへの汎用ゲートウェイを構築したいと考えています。
背景: SOAP サービスを呼び出す必要がある非 Java アプリケーションは、json または SOAP/XML を生成できませんが、カスタム プロトコルを簡単に生成できます (これは私たちの管理下にあります)。
そのため、プロキシが必要です。そのプロキシは、WSDL の変更や次の Web サービスのロールアウトのたびに書き直すべきではありません。
私の計画は次のとおりです。
URL、ポート、およびサービス名 (url:port/service-name) をそのプロキシの「厳密な」定義パラメータとして持つには、
SOAP アクションを「厳密な」定義済みパラメーターとして持つ
url:port/service-name?wsdl の wsdl を要求 (おそらくキャッシュ) し、スタブ呼び出しを動的 (キャッシュ) に開始します。
ネストされたマップに存在する値をそのスタブに入力します
SOAP サービスを呼び出す
答えをそのバイナリプロトコルに変換します。
必要な値が欠落している場合は、SOAP エラーと同等のものを送信する必要があります。
もちろん、短い (手頃な) レイテンシー、高い安定性、最小限のデプロイ ダウンタイム (更新のため)、およびかなりの負荷を伴います。
いくつかの可能性があります。
a) WSO2ESB のような ESB を使用する。そこで、ストリーム形式を特別な入力形式アダプターとして実装し、それを内部 XMLStream に変換し (少なくとも json アダプターはそのように機能するようです)、メディエーターに送信します。そのメディエーターは、 http://today.java.net/pub/a/today/2006/12/13/invoking-web-services-using-apache-axis2.html「動的クライアントの作成」のようなことを試み 、呼び出しますSOAP サービスを直接。
b) Camel で ApacheMQ のような MOM ミドルウェアを使用する
c）Apache KarafやCXFのようなものに減らします
私はこれらすべての可能性の間で少し迷っており、それらはそれぞれの種類の多かれ少なかれ恣意的なサンプルです。
a) への考え:
マイナス: メディエーターが指定された SOAP リクエストを直接呼び出すため、ESB ターゲットがないのは少し奇妙に感じます。
マイナス：内部で XML-Stream に変換するのに余計な時間とリソースがかからないのだろうか
マイナス: コードを変更するには、WSO2ESB を再起動する必要があります。
さらに、url、port、service-name の代わりに、ESB を使用して解決されるシンボリック名を定義できますが、余分なミリ秒はかかりません。
b) については、これらのフォーマット変換が Camel でどれほど簡単か、および SOAP-Service-Requests がメッセージ送信とキューイングに適合するかどうかをまだ確認していません。
私はすでにそのトピックをいくつか検索しましたが、まったく異なる製品の範囲が重複しているため、本当に混乱しています. 私はそれが標準的な問題だと思っていましたが、明らかな解決策はないようです-少なくとも私はそれらを見つけられませんでした.
これらのソリューションのどれが問題や多くの作業につながる可能性があるか (そしてどれが簡単に成功するか) の手がかりを得たいと思っています。また、私のアプローチに何らかの理由があることを願っています.
資格のあるコメントをありがとう！
マルコ