Webサービス更新メッセージ（DTO）でオプションの属性を使用する方法は？

Question

背景

は図書館で本を管理し、BookService、あなたは（SOAP）、Webサービスがあるとします。情報モデルでBookエンティティは以下の属性を持っていることを前提としています。データを操作するために

• id
• author
• publisher
• title
• shelfId

4ウェブサービスオペライオンが定義される：

• AddBook
• GetBook
• UpdateBook
• DeleteBook

要求および応答メッセージは、各操作のために定義されています。しかし、更新メッセージXMLスキーマの設計はより複雑です。

• R1：属性の以前の値をリセット/削除する可能性があります。など。あなたはその本を図書館に保管することはもうなくなり、その特定の本の属性shelfIdの属性値をリセット/空にして削除したいとします。
• R2：ウェブサービスの不快感を避ける。anti-pattern Chatty Servicesを参照してください。
• R3：並行性制御とオプティミスティック・ロックに関する将来の要件を準備します。古い情報に基づいて更新が行われるリスクを最小限に抑える（または削除する）ことをお勧めします。

設計案

私は更新メッセージ（複数可）を設計するために、1は、いくつかのサブオプションを持っている3つの市長の選択肢を、以下を参照してください。

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

考察

Altキー3を理解することは簡単であるという利点があるが、欠点はBookエンティティ内の複数のフィールドを更新する必要がある場合には、消費者が複数の操作を呼び出す必要があるだろうということです。これにより、サービスは "chatty"になり（上記のR3を参照）、パフォーマンスが低下します。

はアルト2はアルト1よりも複雑であるが、オプティミスティック並行性制御に関するアルト2のいくつかの利点がある：各々のタイムスタンプ/バージョンの状況について

• は楽観的ロックフィールドがデータベースに格納されている（例：authorVersion）=>Alt 2は、authorとpublisherのように、複数のユーザーが異なる部分を同時に変更する方法を提供します。これは、同じBook障害が発生する危険性が少なくなります。全体Bookための1つのタイムスタンプ/バージョンのオプティミスティック・ロックをアルト2 1アルト上のデータベース=>本当の利点に格納されている状況で
• 。更新で1つのフィールドのみが変更されても、要求のバージョン番号が古すぎると障害が発生します。状況では
• なし同時実行制御や楽観/悲観的ロックが使用されている=>Altキー2は、古いデータを上書きするのAltキー1より少ないリスクを与えるが、それでも他の一貫性のない変更が問題を与えることがあります。

でアルト2（及びアルト3）さらに別の状況があるがアルト1上の利点を与えます。コンシューマは、Bookエンティティに関するすべてのデータを保存することはできません。例えば、棚の情報を更新するときに、著者が棚の情報を追跡（キャッシュ）する必要がなければ、棚から書籍を選ぶロボットをより効果的にプログラミングすることができる。

消費者がバージョン番号またはタイムスタンプの代わりに以前のバージョンのコピー全体を提出するAlt 2.3のアプローチの利点は、バージョン番号またはタイムスタンプにデータベース内の専用の列が必要ないということです。

これをまとめて言えば、Alt 2.2は、ほとんどの場合、最も魅力的なように見えます。ここでの課題は、XMLをデシリアライズするフレームワークが、明示的にNULLに設定された要素（例えば、要素）と左上の要素を区別できる必要があることです。 <shelfId xsi:nil="true"/>。 See a post on this topic here.

あなたがのために行くだろう選択肢のQUESTION

？あなたは他のより良い選択肢を見ますか？ディスカッションについてどう思いますか？

Answer 1

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

etagは、楽観的なロックに使用される1つの標準になります。私はあなたがロック機構の意味を既に広く議論してきたと思います。それはあなたが描写するように機能するはずです。

Alt 1は、トラフィックが問題ではなく、オブジェクト全体のオプティミスティックロックで十分です（ほとんどの場合imho）。これもうまくいく可能性があります。

ビジネスプロセスによっては、異なる属性の変更が相互に依存しているため、別の属性のみの変更が間違っている可能性があるため、属性の個別のバージョン管理を行うことは意味がありません変更の時代遅れだった。

これが原因である可能性がある場合は、代替1のもう1つの理由です。