13

3 層アーキテクチャを持ち、Web サービスを介して通信する、より複雑な CRUD アプリケーションを想像してみてください。クライアントはサーバーとの会話を開始し、ウィザードのようなものを実行します。ウィザードを処理するには、クライアントはサーバーからのフィードバックを必要とします。

このアプローチのステートフルまたはステートレス Web サービスについての議論を開始しました。私は自分の経験と組み合わせていくつかの調査を行いました。

次のプロパティを持つステートレス Web サービス (この場合):

+ high scalability
+ high availability
+ high speed
+ rapid testing
- bloated contract
- implementing more logic on server-side

しかし、最初の 2 つの点を消すことができます。このアプリケーションは、高いスケーラビリティと可用性を必要としません。

それでは、ステートフル Web サービスについて説明します。私はたくさんのブログやフォーラムの投稿を読みましたが、ステートフル Web サービスを実装する最も発明されたポイントは次のとおりです。

+ simplifies contract (protocol)
- bad testing
- runs counter to the basic architecture of http

しかし、ほとんどすべての Web アプリケーションにこれらの欠点があるのではないでしょうか? Web アプリケーションは、Cookie、クエリ文字列、セッション ID、およびすべてのものを使用して、http のステートレス性を回避します。

では、なぜ Web サービスにとってそれほど悪いのでしょうか?

4

3 に答える 3

9

Web サービスで状態を維持することは困難であり、細心の注意を払ったり、経験を積んだりしていないと、遅かれ早かれバグを見つけるのが非常に困難になる可能性があるためです。

于 2010-04-06T21:16:37.500 に答える
2

私は、ステートフルな Web サービスでかなりの幸運に恵まれました。HTTP 上のホール Cookie セッションがそれであるため、少し汚れているように感じます。しかし一方で、彼らはSOAPだったので、その時点で美しさに腹を立てるのはちょっとばかげている.

覚えておくべきことの 1 つは相互運用性です。ステートフルな Web サービスを実行している場合、クライアントは同じ状態の概念 (通常は Cookie) をサポートする必要があります。しかし、再び-私にとってはうまくいきました。

PSセッションを追跡するコンテナにいると思います。

于 2010-04-06T21:18:07.170 に答える
2

状態は、ほとんどのバグが隠れる場所でもあります。

于 2010-04-06T21:18:55.313 に答える