私は、自動的にデバイスを設定するWebアプリケーションを持っています。通信は、HTTPを使用してリクエスト/レスポンス方式で行われます。私は現在、構成手順を管理するためにスレッドを使用していますが、一般的にアプリケーションスレッドがWebサーバーに生成されないようにすることをお勧めします。イベントフレームワークがアプリケーションの状態を維持するために使用されているのですか、または私は間違った方法でそれらについて考えていますか？アプリケーション状態を管理するスレッドまたはステートマシン？
これ以上適用可能なデザインパターンがある場合は、そのことについてお聞きしたいと思います。
ありがとうございます。
あなたの状況を完全に理解しているかどうかはわかりませんが、とにかく私はそれに刺すようにします。
年前私は、自分の国の大規模な通信事業者向けのADSLアクティベーション要求のサービスのためのアプリケーションを設計しました。
アップストリームアプリケーションから「アクティベーションリクエスト」を受信しました。異なるプロトコルで異なるデバイスで実行しなければならなかった一連の設定手順を実行していましたが、失敗したり、顧客が退会した場合に1つまたは複数のステップのキャンセルを実装する）。
ソートの「状態機械」に基づいて解決策を選択しました。各リクエストは、ステータス（「新しい」から「完了」まで、さまざまな中間ステップを含む）と一連の子レコードを要約したヘッダー・レコードとして（Oracle DB内で）表示され、それぞれが必要なNステップの1つを表します設定を完了します。
基本的に適切な操作タイプのレコードを選択し、それぞれを解決しようとしました（これにより、プロトコルに従って操作をグループ化することができました。たとえばsnmpやtelnetなど）。
また、開いているすべての「ヘッダー」レコードを定期的にチェックする「メタバッチ」をスケジュールし、すべてのチェックが完了しているかどうかを確認します接続されたステップレコードは「終了」状態にあり、それに従ってヘッダステータスを更新する。 fの面倒。フルステップまたは部分的な「ロールバック」も簡単でした。各ステップごとに、完了したかどうかを示す具体的な記録があったためです。
今日も同様の問題に取り組まなければならないのなら、私はステートマシンベースのアプローチに賛成です。
あなたが説明したことはまさに私がする必要があるものです。しかし、私は1つのプロトコル、TR-069のみを使用しています。私はアクティベーションリクエストまたは "Inform"を取得し、次に設定を実行する必要があります。ステートマシンベースのアプローチに賛成すると言いますと、あなたが実装したデータベースステートマシンについて話しているのですか？具体的にはそのステートをデータベースに保存していないものですか？ – toc777
ある種の永続性（「伝統的なDB」など）は確かに便利だろうと思いませんか？実際、私のオリジナルデザインは、フラットファイルを使用して状態を保持するプロトタイプとして開始しました。私たちがOracleに切り替えたデバイスは80kに達しました（私が知っていたすべてのトリックを試みましたが、DBに移動する前に、 ..）。とにかく、私はソートの状態マシンに行くので、可能な限り効率的な方法でさまざまなアクションを処理できるようになり、1つのステップが失敗した場合に何が問題になったのかを簡単に理解できます。 –
デバイスのすべてのデータをデータベースに保存していますが、「状態」固有のデータは保存していません。デバイスがサーバーとの新しいセッションを開始するたびに、構成手順が実行されます。あなたが状態のヘッダーをDBに格納するならば、これは例えば、誰かがsshをデバイスに変更して何かを変更し、サーバーがそれを知らないなどの不整合が生じる可能性があることを意味します。状態ヘッダーがまだデバイスに有効かどうかはどうでしたか？ – toc777
@Prashantによると、State-Machineパターンとスレッディングを比較しようとするのはリンゴとオレンジです。現在どのようにスレッドを使ってデバイスを設定していますか？デバイスの状態を追跡するための長期的な要件は何ですか？また、デバイスの状態は時間とともに変化しますか？
つまり、別のスレッドにプッシュオフするのが便利な、ワンショットの設定ですか？ステートマシンのパターンは、特にCPUの場合、比較的長い時間にわたってトランジションを気にするならば、さまざまな状態と可能な遷移をモデル化するのに役立つツールです。
ステートマシンは、さまざまな方法で実装できます。たとえば、イベントを使用して遷移をトリガすることができますが、一部の静的変数は現在の状態を追跡します。あなたはそれの中に大きなswitch文を持つ大きなループを持っている別のスレッドでそれを行うことができます。
私は2つの質問をするでしょう：
1）あなたのデバイスの状態をモデル化してきたどのように？
2）スレッドは、デバイスの設定に特有のものは何ですか？
最初に、コンフィギュレーションスレッドを作成します。このスレッドには、デバイス上で実行するいくつかの異なるコマンドを含むconfigプロシージャが含まれています。各コマンドは、メッセージをデバイスに戻すのを待っているサーブレットに渡すことで、デバイスに送信されます（デバイスは接続を開始します）。デバイスがコマンドを受信すると、デバイスは常にコマンド応答で応答します。サーブレットはこの応答をコンフィグレーションスレッドに渡し、コンフィグレーションスレッドはコンフィグレーションを続行します。私がスレッドを使用している唯一の理由は、構成手順の位置と状態を維持することです。 – toc777
2つのスレッド間でメッセージ全体を渡すと、複数のスレッドを持つすべての複雑さが私にこれを単一のスレッドに単純化したいと思うようになります。 – toc777
ステートマシンは設計パターンですが、スレッドは実装の選択肢です。あなたの質問をもう少し明確にしてもよろしいですか？ – manku
@Prashantデザインパターンは実装の選択肢でもありませんか？これはまさに私の質問です。追加のスレッドを使用するのではなく、アプリケーション構成プロシージャの状態を維持する良い方法はありますか？ – toc777
私はあなたがスレッド内にステートマシンを実装できることを意味しました。私はあなたが尋ねていることは、イベントベースのモデル対スレッドを使うべきかどうかということだと思いますが、それは単なる推測です。申し訳ありませんが、答えはありませんが、質問は私を混乱させる。 – manku