私は、SOAP、肥大化、XML、およびRESTのような代替メカニズムについてSOについてすでに多くの議論があることを知っています。
これが状況です。新しいチームメンバーは、プロトコルを手動で実装することの難しさに基づいて、SOAPについて実際に話し合っています。彼はgSOAPを推奨しています（プロジェクトはすべてC ++です）。彼は、WSDLが多くの厄介な手書きのC++をクリーンアップするようなことを述べています。
現在、私はXMLベースのテキストメッセージとexpatXMLライブラリを使用してほとんどのネットワークを処理しています。そのため、メッセージ形式の変更やパラメータリストへの追加に関連するプログラミング作業（それほど多くはありません）があります。送信者側で、XML要求をパッケージ化し、それを単純な古いTCPソケットを介して送信します。受信者では、DOMまたはSAXを使用してXMLを解析します。などこれまでは問題なく動作しました。XMLメッセージは非常にコンパクトで、平均して最大で数百文字です。そして、私はそれらのメッセージのすべての項目を理解しています。
PHPを使用してコード化されたWebサイトから製品の一部（サーバー）にアクセスできるようにする必要があります。これは、SOAPインターフェイスがスクリプト作成者にとって「より簡単」になるというこの考えを部分的に推進しています。このプロジェクトの誰もがSOAPが彼らの救いであると信じています。
gSOAPのような新しい大規模なライブラリの導入は、成熟したプロジェクトの勢いを大きく損なうものだと思います。
私が疑問に思っているのは、SOAPが提供するものを実行するための別のよりコンパクトな方法があるかどうかです。そして、gSOAPまたは他のSOAPツールの主張のバランスを取り、ハードリアリティに対して開発作業を容易にする方法。
IE、XMLライブラリを使用してC ++を手動でコーディングするよりも、WSDLの方が優れていて、簡単で、より巧妙であると言われています。C++オブジェクトのセマンティクスをネットワークメッセージの宣言に直接配置すること。重要なのは、私が定義したXMLメッセージの多くは、受信側で1対1を1つの別個のオブジェクトにマップしないということです。
または、何も心配していない可能性があります。
しかし、ここでメッセージをスキャンするときの現実は、私が地元で言われたことと矛盾しているようです。