サービス無状態原則

サービスステートレス性は、サービス指向設計パラダイム内で適用される設計原則であり、可能な限りサービスを状態データから分離することでスケーラブルなサービスを設計します。 ^{[1]これにより、実際の状態}データ管理が外部コンポーネントまたはアーキテクチャ拡張に委任されるため、サービスによって消費されるリソースが削減されます。リソース消費を削減することで、サービスはより多くのリクエストを信頼性の高い方法で処理できます。^[2]

2 つのソフトウェア プログラム間の対話では、対話固有のデータを追跡する必要があります。これは、後続の各対話が前の対話の結果に依存する可能性があるためです。これは、クライアントとサーバーが物理的に同じマシン上に存在しない分散アーキテクチャではさらに重要になります。2層アーキテクチャでは、この対話固有のデータを追跡する責任はリッチ クライアントにありますが、各クライアントが個別のコンピューター上に常駐していたため、これは問題ではありませんでした。^[3]ただし、n 層アーキテクチャでは、状態管理の責任はクライアントからアプリケーションまたはWeb サーバーに移行しました。これにより、ミドルウェアの状態管理拡張機能が必要になり、実際のアクティビティ固有の状態データをそのような拡張機能に委ねることで、サーバーが複数の同時クライアント要求を処理できるようになりました (例: ASP .NETアプリケーションでセッション データをデータベースに格納する) 。これにより、メモリ リソースが解放され、サーバーの応答性が向上し、より多くのクライアント要求に対応できるようになります。

サービス構成では、別のサービスが処理を完了するのを待っている間に、サービスがアクティビティ固有のデータをメモリに保存する必要がある場合があります。その結果、サービス指向の場合、サービス再利用に重点が置かれるため、サービス アクティビティ関連データの効率的な管理がより重要になります。サービスは、特定のビジネス プロセスのコンテキストでコンシューマー プログラムと対話した結果として作成される状態データの管理だけでなく、複数のビジネス プロセスの一部である他の種類のコンシューマー プログラムとの対話に関連しても処理する必要があります。再利用性が高まると、状態データ管理のオーバーヘッドも増加します。サービス ステートレス原則は、状態管理のオーバーヘッドをサービスから他の外部アーキテクチャ コンポーネントに移すことによってサービスをステートレスにするためのガイドラインを提供します。これは、サービス指向ソリューションの全体的なスケーラビリティをさらに向上させます。

サービスのステートレス性を正しく適用するには、管理する必要があるさまざまな種類の状態情報を理解する必要があります。

サービス構成内では、特定のサービス アクティビティの実行に固有のデータを追跡する必要がある場合があります。このデータは通常、ワークフローなどのメッセージの調整と、ルールの解釈方法を規定する関連ルールにリンクされています。

これは、顧客レコードなど、現在のサービス アクティビティによって実行される実際のビジネス プロセスに関連するデータです。場合によっては、このタイプのデータは、特にサービス アクティビティ内の次のステージへの入力として機能する場合、一時的に保存する必要があることがあります。

これは、サービス間の接続情報に関係します。たとえば、コンシューマー プログラムとサービスが相互に通信している場合、特定のサービス インスタンスのみが以前のサービス相互作用を認識しているため、後続の要求をそのインスタンスにのみ送信するには、何らかの相関関係が必要になることがあります。

サービス ステートレス原則は、サービスに含まれるソリューション ロジックの種類に応じてさまざまな範囲に適用できます。

タスク サービスには、特定のビジネス プロセスに固有のソリューション ロジックが含まれているため、再利用レベルは低くなります。ただし、これらのサービスには、サービス アクティビティに関するコンテキスト データ (ワークフロー ルール) が含まれており、これはタスク サービスによって管理されているサービス構成のサイズに直接比例します。その結果、状態延期オプションを使用してこのようなサービスを設計すると、メモリ フットプリントが削減され、応答性が向上します。

こうした種類のサービスは、タスクサービスやエンティティサービスにステートレス性を提供するために、ステートフルである必要があるかもしれない。^[4]一方、高度に再利用可能なユーティリティサービス、例えばレガシーシステムのラッパーとして機能するユーティリティサービスは、複数の同時リクエストに対応できるように、適度にステートレスである必要がある。

これらのサービスは、特定のビジネス プロセスから独立しているため、最も再利用可能なサービスと見なされています。もう 1 つの重要な要素は、ビジネス エンティティに関連するデータを処理するため、必要な機能を提供するために保持する必要がある可能性のあるビジネス データを追跡する負担がかからないように、より高いレベルのステートレス性が求められることです。

ステートレス性は、サービス実装境界外に存在するミドルウェア製品などの共有アーキテクチャ拡張に状態管理を委任するか、専用データベースなどのサービス境界内に存在する専用メカニズムに状態管理を委任することで実現できます。^[5]

各サービスに専用の状態延期オプションを提供することは、明らかに追加の投資が必要となるため、必ずしも可能とは限りません。一方、共有状態延期オプションを使用すると、サービスへの依存関係が生じ、サービスの進化を妨げる可能性があります。

状態情報の保存と取得は、最初にデータをストレージ拡張機能のネイティブ形式に変換し、同じ情報を取得する際にはその逆の処理を行う必要があるため、両方のタスクで計算負荷が高くなる可能性があり、サービスの応答時間に意図せず影響を与える可能性があります。

ステートレス サービスの設計には、サービスに状態延期拡張機能とインターフェイスするロジックを含める必要があるため、追加の労力と時間が必要です。これにより、追加のコードとテストが必要になります。

• Michael Poulin.サービス指向の原則の進化: サービスのステートレス性、パート 6[オンライン]。アクセス日: 2010 年 4 月 19 日。
• Mauro 他「サービス指向デバイス統合 - SOA 設計パターンの分析」[オンライン]、pp. 1–10、2010 43rd Hawaii International Conference on System Sciences、2010。アクセス日: 2010 年 4 月 8 日。