2011-07-12 34 views
2

私はアプリケーションのWebサービスの作成を検討しています。このアプリケーションでは、「作業単位」はしばしば単一のエンティティではなく、複数の表にまたがる複数のエンティティであるため、トランザクション内のすべてを実行します。 「すべてか何か」がほしいと思う状況があり、トランザクションが完璧な意味を持ちます。私はWebサービスでこれをどうやってやるべきか、私がすべきことは本当にわかりません。Webサービスをトランザクションにする必要がありますか?

Webサービスはステートレスでなければならず、提供されるAPIはエンティティ単位で構築する必要がありますが、1つの部分が失敗すると「ロールバック」が発生する「作業単位」を処理する方法がわかりません。

Webサービスをトランザクションにする必要がありますか?トランザクションをどのように実装しますか?「BEGIN TRANSACTION」を送信し、「END TRANSACTION」で終わる行に沿ったものでしょうか?

ウェブサービスがステートレスである場合、独立していない「作業単位」はどう対処しますか? 私はその話題について読むことができるまったくの明確な文献はありますか?

おかげで、

+0

私は、Webサービス層はトランザクション内のアクターではなく、下のレイヤーでトランザクションを要求し、コミットされたかロールバックされたかに関わらず、結果をクライアントに報告すると考えています。 1つのアプリケーションノード内で起こりうることを超えたトランザクションロジックを求められているなら、それを「デザインの匂い」と呼んでいます。 – wberry

答えて

4

は、Webサービスは、舞台裏のすべてまたはnoneかもしれませんが、あなたがクライアントに公開する内容についての選択肢を持っています。

クライアントにコミット/ロールバックの動作を知らせたい場合は、APIの一部として「補償トランザクション」を提供する必要があります。したがって、1つのユースケースで新しいトランザクションが作成された場合、そのトランザクションを削除し、作成が成功したか失敗したかをユーザーに伝える補完的な方法を提供する必要があります。他のすべてのメソッドと同じです。

私はこれがサービスが何をしているのかをあまりにも明らかにしていると思います。クライアントはあまりにも多くのことを知っている。それはカプセル化が貧弱です。

私は、その知識をサービス内に隠しておく方が良い設計だと思います。成功か失敗かをユーザーに報告しますが、それだけです。

これは、完全な作業単位を網羅するほど粗くなるようにサービスを設計する必要があることを意味します。ユースケースを満たすために、データソースやその他のサービスを調整しましょう。

関連する問題