- - PR -
リモートコールされるEJBのエラーメッセージの管理について
1
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2004-04-16 12:26
いつも勉強させていただいています。
下記のようなことで悩んでいますが経験のある方の意見をお願いします。 状況: ・StrutsとEJBを利用する複数のアプリケーションがあります。 ・各アプリケーションはEJBのリモートコールでお互いの機能を使ってます。 ・既存の各アプリケーションごとのエラーメッセージの管理は個々のアプリケーション内に存在するapprication.propertiesファイルで行っています。 課題: ・リモートコールでエクセプションが発生した場合、エラーメッセージをユーザ画面に表示する事になるがそのエラーメッセージの管理方法は? 考慮点: @リモートコールの場合、エラーメッセージを呼ばれる側で設定して返すべきか? A各アプリケーションでリモートコールから返ってくるエラーメッセージのキーとその値を自分のプロパーティファイル内に持つべきか? @を選択した場合、エラーメッセージハンドリングの方法が変わる事になるので各アプリケーションへの修正が発生し、これは避けたいと思います。 Aの場合は、共有されるメッセージの配布と管理が手間になります。 他にいい案とか回避策はないでしょうか? | ||||
|
投稿日時: 2004-04-16 13:23
単純に複数のアプリケーションからメッセージを一元管理したいと 言う事であれば、共有できるDB上にメッセージを管理するマスタテーブル を構築する方法もあるのではないかと思います。 もう少し掘り下げて考えると、個々のEJBがどのレベルの機能(サービス)を 提供しているのかにもよるような気がします。 1.EJBが低レベル(細かい単位)の機能を提供していて、 クライアントであるアプリケーション側でその機能を組み合わせることで 一つの大きなサービスを構成している場合 恐らく各EJBがスローする例外のメッセージは、エンドユーザに見せる には適切でないもの...むしろ開発・保守担当者に対して問題の根本原因を 通知するものになると思います。 この場合は、その例外を受けてエンドユーザに見せる為のより抽象化された メッセージを表示させる必要があり、メッセージ管理は個々のアプリケーションの 責務になると思います。 2.EJBが高レベルのサービスを提供していて(要はFacadeになっていて) クライアントであるアプリケーションはそのサービスを呼び出すだけ の場合 各EJBがスローする例外はエンドユーザに見せることができる ような高レベルなものになっていると思います。 この場合は、メッセージ管理はEJB側の責務になると思います。 | ||||
|
投稿日時: 2004-04-16 13:40
私のケースはまさに上記の通りです。 で、エラーメッセージのハンドリングがEJBの責務になった場合はEJBからエラーメッセージのキーではなく完全なるエラーメッセージを返す必要がありますね。その場合、常にメッセージのキーだけをEJB内部で設定し、実際のメッセージの取得はStrutsの機能に任せている既存の作りではアプリケーションの修正が発生しますけどそれだけはどうしても避けたいと思っています。 取り合えず、上記の方法が一般的であると言う認識で宜しいでしょうか? | ||||
|
投稿日時: 2004-04-17 00:32
一般的かどうかは私もわかりませんが、個人的には先のレスに書いたような 考え方が自然ではないかと思っています。 Strutsの機能でメッセージ取得する部分は変更したくないと言う事ですので、 それはそれでポリシーとして統一されていれば良いとは思います。 メッセージリソースのメンテナンスについては、確かに問題ですが 不特定多数のクライアントに配布するのではなく、限られた数の アプリケーションに含めるだけですからメンテナンスについても 許容範囲ではないでしょうか。(妥協しちゃってますが...) | ||||
|
投稿日時: 2004-04-17 08:57
ユーザーに表示するメッセージはプレゼンテーションですから、Strutsが管理するべきだという考え方もあります。EJBで決定すると国際化や、複数画面で同一機能を利用した時にメッセージを変えたいという要望があった場合に対応できません。
逆にEJBで管理するとメッセージの修正をクライアントに通知する必要がなく保守性が向上します。 | ||||
1
