JAVAWebアプリに接続する必要のあるC++アプリがありますが、これに適したオープンソースのSOAPパッケージはありますか、それとも自分で作成する方が簡単ですか?
6 に答える
gSoapも私の推奨事項になるので、darkhelmet に投票します。私たちは主に Java ショップですが、いくつかの C++ ビットと gSoap が私たちの優先する SOAP 統合方法です。確かに、典型的な Java スタックよりも多くの作業が必要ですが、しっかりしているように見えます。
C++ プロジェクトを構築するためだけに JRE と Axis の両方に依存することを避けるために、Axis ではなく gSOAP を使用しました。gSOAP コードは恐ろしく、バグを修正するのが非常に難しいので、これは良いことです。
ただし、gSOAP リンクに関する警告: 1 つのリンク オブジェクト (実行可能オブジェクト、dll、共有オブジェクト) で複数の WSDL を使用することはできません。これは、生成された WSDL 固有の関数の一部に一般的な名前 (soap_getfault() など) があるためです。
さらに悪いことに、Unix ELF リンクでは、これらの名前が共有オブジェクト間の相互リンクを引き起こすため、FooService 障害が BarService の soap_getfault() によって処理され、障害の詳細構造が異なる場合にメモリが破損する可能性があります。
その回避策は、gSOAP 関連がリンク先の SO の外部に公開されないようにすることです。これは、gSOAP ライブラリ自体をリンクするときとコードをリンクするときに、gcc にこれらの定義 _both を与えることで解決できます。
#define SOAP_FMAC2 __attribute__ ((visibility ("hidden")))
#define SOAP_FMAC4 __attribute__ ((visibility ("hidden")))
#define SOAP_FMAC6 __attribute__ ((visibility ("hidden")))
#define SOAP_NMAC __attribute__ ((visibility ("hidden")))
それらをヘッダーファイルに入れ、gccにそれを他の何よりも先に含めるよう強制することで解決しました-include fixsoaplink.h
.
努力できるなら、デフォルトの ELF 可視性を非表示に変更し、必要なシンボルのみをエクスポートすることをお勧めします (VC の dllimport/dllexport など)。
簡単な Google がこれをツールキットとして取り上げました。使ったことはありませんが、かなり人気がありしっかりしているようです。正確にはパッケージではなく、実際に独自に展開するわけではありませんが、中間のようなものです。
これは、難しい方法で発見した gSOAP の別の問題です。すべてのポーリングに select() を使用するため、1024 個のファイル記述子 (Windows では 64 個?) を開くと、スタックが破棄されます。その結果、メッセージを送信できない偽のエラーが発生し、アプリケーションが完全にクラッシュします。
回避策は、gSOAP 自体にパッチを適用する準備ができていない場合、独自のネットワーク コードを作成し、soap->fconnect、->fsend、->frecv などでフックすることです。
Apache のAxisプロジェクトを見てください。これは C++ (および Java) で十分にサポートされており、幸運にもターゲット サービス用の適切な WSDL から始めることができれば、問題はありません。
gSOAP から生成されたコードを見たとき、心臓発作を起こしそうになりました。
ユーザーがオブジェクトごとにすべてのメモリ管理を行う必要があるという事実は、私を驚かせました。それで、私は座って、長期的にはおそらくばかげているかもしれませんが、短期的にはかなり満足できることをしました...
私は gSOAP コードを独自の CPP クラスでラップするプログラムを作成しました。これにより、インターフェイスがより自分の好みに見えるようになります。
各サービス メソッド内で Scoped Guard を使用してメモリを保持しました。あらゆる種類の異なるタイプを扱っているため、それを行うために を使用しstd::list<boost::any>
ました。必要な各オブジェクト タイプを作成する関数があり、それらは実際のメモリを my.xml に入れますlist<any>
。いくつかの問題がありました - ほとんどは構成の変更だけです。現在、何千ものクラスを生成しており、何十もの Web サービスと対話しています。
同じ道を他の人に勧めるかどうかはわかりません...おそらく、gSOAPの出力に依存する独自のツールを維持するのではなく、弾丸をかじってgSOAPに貢献しようとする必要があります...