問題：社内サーバーでサービスとして実行されるスタンドアロンのJavaアプリ（以降、「エージェント」と呼びます）があります。一部の中央サーバーのリモートエージェントとして機能します。エージェントがより多くの場所に展開されるにつれて、それらの管理はより複雑になります。具体的には、更新のプッシュはかなり手動のプロセスであるため面倒であり、エージェントが実行されている環境に関するログやその他の情報へのアクセスは問題があり、デバッグが困難になります。議論中のサーバーはヘッドレスで無人です。つまり、これは手動の介入なしに完全に自動化されたプロセスである必要があるため、JavaWebStartは実行可能なソリューションではありません。
提案された解決策：エージェントの電話を定期的に（中央サーバーに）ホームにして、エージェントのステータスを提供し、更新を確認します。
私はこの問題に対する他の提案された解決策を受け入れていますが、この質問が焦点を当てている「ステータスと自己更新」のアイデアの実用的なプロトタイプをすでに持っています。
私が思いついたのは、実際にはエージェントのラッパーとして機能する別のプロジェクトです。ラッパーは、HTTPを介して中央サーバーを定期的に呼び出し、エージェントの更新バージョンを確認します。アップデートが見つかると、新しいバージョンをダウンロードし、実行中のエージェントをシャットダウンして、新しいエージェントを起動します。それが奇妙な解決策または回りくどい解決策のように思われる場合は、注目に値する他のいくつかの考慮事項/制約があります。
- ラッパーが新しいバージョンのエージェントを取得すると、新しいJAR依存関係が存在する可能性があります。これは、クラスパスが変更されることを意味します。つまり、ClassLoaderをいじって永続的な生成メモリリークのリスクを冒すのではなく、別のJavaプロセスを生成したいということです。手作業による介入が必要になります-まさに私が逃げようとしていることです。これが、プロトタイプのエージェントの更新を管理するための別個の「ラッパー」プロセスになってしまった理由です。
- エージェントが展開されている一部のサーバーはリソースが制限されているため、どのソリューションでもCPUとメモリの使用量を少なくする必要があります。そのため、新しいJVMを起動する必要がなく、別個のラッパープロセスを使用することに対するストロークであるソリューションが必要になります。
- エージェントはすでにWindowsサーバーとRHELサーバーの両方にデプロイされているため、ソリューションはクロスプラットフォームである必要がありますが、バッチスクリプトとbashスクリプトで適度な量のプロセスを複製して問題を解決することは問題ありません。
質問：前述のように、自己更新型のJavaアプリを作成する方法を知りたいです。より具体的には、これを支援するフレームワーク/ライブラリはありますか？この分野での経験を持つ誰かが私にいくつかの指針を与えることができますか？