WCF を使用して非 .NET クライアントに SOAP インターフェイスを公開する場合の問題を知っている人はいますか?

Question

WCF を使用して非 .NET クライアントに SOAP インターフェイスを公開する場合の問題を知っている人はいますか?たとえば、他の SOAP ライブラリとの非互換性はありますか?

これは、サードパーティが当社のソフトウェアと統合できるように SOAP インターフェイスを公開できるようにするためです。

Answer 1

WCF で私が遭遇した問題領域のいくつかは次のとおりです。

• 複数のURLに分割されるWSDLを生成します。つまり、スキーマの一部は1つのURLにあり、別の部分は異なるURLなどです。「メイン」wsdl url（サービス名の後に「？wsdl」があります） xsd:import要素。多くの SOAP クライアント (.NET Delphi 以前など) は、このイディオムに非常に困難を抱えています。したがって、実際に相互運用性を実現するには、WSDL を「フラット化」する必要があります。解決策が 1 つ与えられます ここ.
• WCFは、ASMX Webサービスと同じようにXMLネームスペースを生成しません。WCFは、サービスまたはデータ契約を独自の選択の名前空間に配置する傾向があります。繰り返しになりますが、一部の SOAP クライアントではこれが困難です。ServiceContract 属性と DataContract 属性に明示的な名前空間を追加することで、相互運用性レベルを高めることができます。
• 多くのSOAPクライアントは、WCFクライアントほどうまく障害を処理しません。たとえば、プロキシ生成コードは、WSDLで宣言された障害のクライアント側オブジェクトを作成しません。もちろん、障害はまだクライアントに送信されますが、クライアントは、それがどんな障害であるかを把握するために、より多くの仕事をしなければなりません。

Answer 2

WS-* 標準スタックのバージョンも相互運用性の問題になる可能性があります。たとえば、一部の Java 実装でサポートされている WS-Addressing (2003) のバージョン (Oracle BPEL など) は、WCF ではサポートされていません。WCF は、それ以降のドラフトと 1.0 バージョンをサポートしますが、 2003年初頭のもの

Answer 3

通常、すべてが正常に動作します。それは明らかに、使用しているクライアントに依存します。誰もが SOAP を適切に実装しているわけではありません。

追伸より具体的な回答をご希望の場合は、質問を言い換えていただけますか?