2

バックグラウンド

（SOAP）WebサービスがありBookService、図書館の本を管理していると仮定します。Book情報モデルでは、エンティティに次の属性があると想定しています。

  • id
  • author
  • publisher
  • title
  • shelfId

データを操作するために、4つのWebサービス操作が定義されています。

  • AddBook
  • GetBook
  • UpdateBook
  • DeleteBook

要求メッセージと応答メッセージは、操作ごとに定義されています。ただし、更新メッセージXMLスキーマの設計はより複雑です。私たちは以下の資質を達成したいと考えています。

  • R1：属性の以前の値をリセット/削除する可能性。たとえば、本をライブラリに保持しなくなったshelfIdため、その特定の本の属性の属性値をリセット/空にする/削除したいとします。
  • R2：Webサービスでのおしゃべりを避けてください。アンチパターンのChattyServicesを参照してください。
  • R3：同時実行制御とオプティミスティックロックに関する将来の要件に備えます。古い情報に基づいて更新が行われるリスクを最小限に抑える（または削除する）ことができます。

代替案の設計

更新メッセージを設計するための3つの市長の選択肢があり、そのうちの1つにはいくつかのサブオプションがあります。

  1. ビジネスドキュメント全体を送信します。省略された要素（minOccurs="0"スキーマ内にある）または明示的にnullに設定された要素、つまり<shelfId xsi:nil="true"/>、は、前の値の削除として解釈されます。
  2. 変更を強調表示するか、差分のみを送信します。
    1. ビジネスドキュメント全体を送信しますが、この目的に固有の属性を使用して、変更された要素にマークを付けます。例：<author dirty="true">Hemingway<author/>。次に、サービスのプロバイダーは、ダーティとしてマークされた要素のみを更新し、他の要素を無視します。
    2. メッセージスキーマで、識別子を除くすべての要素をに設定しidますminOccurs="0"。コンシューマーは、変更される要素のみを送信します。省略された要素は、意味的に削除として解釈されてはなりません。値を削除するには、明示的なXMLNULL値を使用する必要があります。例：<shelfId xsi:nil="true"/>。
    3. ビジネスドキュメント全体を送信するだけでなく、以前に読んだドキュメントのコピーも送信します。次に、プロバイダーは2つのドキュメントを比較し、新しいドキュメントと以前のドキュメントが異なる属性のみを更新できます。
  3. 複数の操作を定義します。1つの操作だけを使用するのではなく、更新UpdateBookする必要があると思われる要素に基づいて複数の操作を定義します。これらのそれぞれには必須の要素のみがあり、要素を削除するには、XMLの明示的なNULLを使用します。UpdateBookAuthorUpdateBookPublisher<shelfId xsi:nil="true"/>

討論

Alt 3Bookには、理解しやすいという利点がありますが、エンティティ内の複数のフィールドを更新する必要がある場合に、コンシューマーが複数の操作を呼び出す必要があるという欠点があります。これにより、サービスが「おしゃべり」になり（上記のR3を参照）、パフォーマンスが低下します。

Alt2はAlt1よりも複雑ですが、楽観的同時実行制御に関連するAlt2にはいくつかの利点があります。

  • 各フィールドのタイムスタンプ/バージョンを使用した楽観的ロックがデータベースに保存されている場合（例authorVersion）=> Alt 2は、複数のユーザーが同じのとなどの異なる部分を同時に変更できるようにするとauthor同時に、障害が発生するリスクを減らす方法を提供します。publisherBook
  • 全体に対して単一のタイムスタンプ/バージョンを使用した楽観的ロックがBookデータベースに保存されている状況の場合=> Alt1に対するAlt2の実際の利点はありません。更新によって1つのフィールドのみが変更された場合でも、リクエストのバージョン番号が古すぎると障害が発生します。
  • 同時実行制御または楽観的/悲観的ロックが使用されていない状況の場合=> Alt2は、 Alt 1よりも古いデータで上書きするリスクが少なくなりますが、他の一貫性のない変更によって問題が発生する可能性があります。

Alt 2（およびAlt 3）がAlt1よりも有利であるさらに別の状況があります。消費者は、エンティティに関するすべてのデータを保存できない場合があります。たとえば、棚の情報を更新するときに、著者の情報を追跡（キャッシュ）する必要がなく、棚だけを追跡する必要がある場合、棚から本を選ぶロボットをより効果的にプログラムできます。Book

コンシューマーがバージョン番号やタイムスタンプの代わりに以前のバージョンのコピー全体を送信するAlt2.3のアプローチの利点は、バージョン番号やタイムスタンプにデータベース内の専用の列が必要ないことです。

要約すると、 Alt2.2はほとんどの場合最も魅力的なもののように見えます。ここでの課題は、XMLを逆シリアル化するフレームワークが、除外された要素と明示的にNULLに設定された要素を区別できなければならないこと<shelfId xsi:nil="true"/>です。このトピックに関する投稿はこちらをご覧ください。

質問

どちらの選択肢を選びますか？他のより良い選択肢がありますか？議論についてどう思いますか？

4

1 に答える 1

1

すでに説明したように、alt 2.2 はかなり実現可能のようです。ただし、minoccurs=0 と nil の区別はフレームワークによって無視されることが多く、多くのユーザー (このインターフェースの可能性がある) にとって理解しにくいものでもあります。したがって、1 つの変更メッセージで、すべての属性を無効にしたいときに明示的にマークするバリエーションを使用します。

etag は、楽観的ロックに使用される標準の 1 つです。ロック メカニズムの影響については、既に広範囲にわたって議論されていると思います。あなたが説明した方法で動作するはずです。

Alt 1 は、メッセージの設計と使用/実装の両方ではるかに単純であり、トラフィックが問題ではなく、オブジェクト全体の楽観的ロックで十分な場合 (ほとんどの場合、私見です)、それもうまく機能する可能性があります。

また、一部のビジネス プロセスでは、異なる属性の変更が相互に依存しているため、属性を個別にバージョン管理する意味がないことも考慮する必要があります。変化の時。

これが当てはまる場合、それは alt 1 のもう 1 つの理由です。

于 2014-07-11T13:01:05.497 に答える