6

IPCライブラリを使用する場合、APIのバージョンが異なっていても、クライアントとサーバーの両方が通信できる可能性を提供することが重要です。クライアント/サーバーアプリケーションにSOAPを使用することを検討しているので、SOAP/WSDLソリューションがAPIの変更をうまく処理できるかどうか疑問に思います。

例えば：

  • 既存の関数へのパラメーターの追加
  • 既存の関数で使用されている既存の構造体に変数を追加する
  • 機能の削除
  • 既存の関数からのパラメーターの削除
  • 既存の関数で使用されている既存の構造体から変数を削除する
  • 既存の関数で使用されているパラメーターのタイプを変更する
  • 既存の関数のパラメーターの順序を変更する
  • 既存の構造体の複合パーツの順序を変更する
  • 既存の関数の名前を変更する
  • パラメータの名前を変更する

注：「構造体」とは、複合型を意味します

4

2 に答える 2

3

そうではありません。なんとかして手動で管理する必要があります。通常、主要な/重大な変更を導入するときに新しいインターフェイスを作成します。

より一般的に言えば、これは技術的な問題ではなく、アーキテクチャ上の問題です。インターフェイスが公開されたら、変更を処理する方法を本当に考える必要があります。

于 2010-01-29T11:33:24.583 に答える
3

私の知る限り、SOAP/WSDL標準のようなものはありません。しかし、そのような問題に対処するためのツールが存在します。たとえば、Glassfishでは、XSLスタイルシートを指定してWebサービスの要求/応答を変換できます。Oracle SOAスイートなどの他のソリューションは、Webサービスのバージョン管理とコンポーネントの統合を管理するためのはるかに精巧なツールを提供します。メッセージは、異なるバージョンのWebサービスに自動的にルーティングされたり、変換されたりする可能性があります。ターゲットインフラストラクチャが提供するものを確認する必要があります。

編集：

XMLとXSDは、オブジェクト指向言語での型やシリアル化よりも、スキーマの進化に関してより柔軟です。一部のものは、オプションとして宣言するだけで下位互換性を持たせることができます。

  • 既存の関数へのパラメーターの追加-パラメーターがオプションのnull場合、クライアントがパラメーターを送信しない場合は値を取得します
  • 既存の関数で使用されている既存の構造体に変数を追加する-値がオプションのnull場合、クライアントがそれを提供しない場合に取得します
  • 関数の削除-ここには魔法はありません
  • 既存の関数からのパラメーターの削除-クライアントによって送信されたパラメーターは、新しい定義に従って不要になり、省略されます
  • 既存の関数で使用されている既存の構造から変数を削除する-この場合はわかりません
  • 既存の関数で使用されているパラメーターのタイプを変更します。これは変更によって異なります。単純なタイプの場合、シリアル化/逆シリアル化は引き続き機能する可能性があります（例：Stringからint）。

私はリストを100％確信していないことに注意してください。しかし、いくつかのテストで、何が機能し、何が機能しないかを示すことができます。重要なのは、XMLはネットワーク経由で送信されるため、ある程度の柔軟性が得られるということです。

于 2010-01-29T11:41:18.887 に答える