2

SE アプリケーションを EE で書き直すプロジェクトに参加しています。現在、サポート対象のアプリケーション サーバーとして JBoss 7.1.3 を使用していますが、移植性のために AS 固有のコードを最小限に抑えようとしていることは明らかです。

私たちのアプリケーションの背景を少し説明します...システム (MDB/Web サービス) からの処理要求を受け入れ、他の多くのシステムとやり取りすることで要求を満たします。システム処理の監査は、データベース主導です。

既存のアプリケーションの現在の機能は、データベース接続が失われた場合にアプリケーションをシャットダウンして、未監査の処理を防ぐことです。そこで、移植可能な方法でこの機能を再作成する標準的な方法があるかどうかを調べてきました。アプリケーション自体からプログラムでアプリケーションを停止する標準的な方法があるかどうか、または同様の機能を提供することについて何か考えがあるかどうか疑問に思っていると思います。

これまでのところ、JMX を介して JBoss に接続し、アプリケーションをアンデプロイするか、MDB の配信を停止する方法があるかもしれないことを見てきましたが、すべて AS 固有であるため、移植性について心配しています。AS 間の移植性だけでなく、異なるバージョンの AS 間の移植性についても懸念しています...これらのアクションのプロセスは、異なる JBoss リリースで変更されているようです。

4

2 に答える 2

1

ASは複数のアプリを実行するように設計されているため、そのような機能が存在する場合、それは実際には脆弱性になると思います. そして、そのような共有サーバーの 1 つで、1 つのアプリケーションが不正になると、残りのアプリケーションが停止します。

それでも、シェルスクリプトを実行してランタイムを取得することでそれを行うことができますが、実際には移植可能なコードにはなりません。

于 2013-04-26T00:37:23.200 に答える
0

アプリを停止すると言うときは、 System.exit(0) を意味しますか? 実行中のアプリがあなただけのものである限り（共有jbossではない）、Jboss / EEコードでもそれを行うことができます

共有されている場合 (社内の他のアプリまたは共有プロバイダーによって)

  1. サービスを提供するクライアントにエラー応答を送信する
  2. ログファイルに書き込み、それが成功した場合はサービスを続行します（ログはデータベースに転送できます-データベースが常に最新である必要がある場合、これは機能しません）
  3. 接続プールを使用してデータベース接続を維持します->それをより良く保つための単なる提案です。メインに到達できない場合は、代替データベースを使用することもできます。繰り返しますが、これはビジネス/あなたの特定の状況によって異なります
  4. 移植性と応答性を高めるには、null/空のセットで応答します。ステータス画面もあります - >アプリやイベントのステータスをクライアント/サポートに伝える方法（dbや他のリソースが時々利用できなかったなど）。実装: 各 API 関数は、共通の方法でこれを処理するために、最初に AOP インターセクトを持つことができます。

アンデプロイする場合は、1 つの抽象クラスの基本設計と、各アプリ サーバー/アプリ サーバー バリアントのバージョンを持つことができます。アプリサーバーを一度使用すると、頻繁に変更または追加することはほとんどないと思います。おそらく、将来のJSR / web / ejbアプリケーションの機能のために、これをオラクルに提案できます

于 2013-04-26T01:02:24.370 に答える