私たちは、サイズ、範囲、寿命が異なる多くの Java Web ベース アプリケーション (同じ会社用) を開発および保守する必要があります。それらのいくつかは巨大で、他のものは数か月 (または数日) しか存在しない単純なページであり、いくつかは既に実装されており、リファクタリングが必要です。
ただし、共通点が 1 つあります。それは、(ほぼ) 同じ情報にアクセスする必要があるということです。
問題
同社が扱うデータは複雑であるため、多くの異なる情報源に対処する必要があり、その中には古代から受け継がれたものもあります。私たちのドメイン オブジェクトは、これらのソースの多くにマッピングされる可能性があります。例として、コントラクト ドメイン オブジェクトはメイン データベースにマッピングされますが、関連する (物理) ファイルはドキュメント サーバーに保存され、それに関連するアクティビティは NoSQL データベースに保存されます。したがって、これらのオブジェクトの追加、削除、検索には、多くの内部操作が含まれます。
私たちのデータソースは次のとおりです（ただし、任意の可能性があります）。
- AS400 (DB2 をデータベースとして使用)
- Documentum ドキュメント マネージャー
- モンゴDB
- 外部 Web サービス
- その他のレガシー ソース
通常、Glassfish をアプリケーション サーバーとして使用し、maven をビルド ツールとして使用します。
ゴール
私たちの目標は、すべてのアプリケーションがアクセスできるビジネス レイヤーまたはライブラリを作成することです。
- コンパクト
- 一貫した
- 使いやすい
- メンテナンスが容易
- 多くの異なるクライアントからアクセス可能
これまでに発見したこと
私たちは何週間も苦労してきましたが、まだ完全に満足できるものを見つけることができません. いくつかの解決策:
すべてのビジネス ロジックを 1 つまたは複数の jar にパックする: 共有は非常に簡単ですが、すべてのアプリケーションにすべての jar 依存関係と構成ファイルを含め、セキュリティ、キャッシュ、およびその他の処理を行う必要があります。維持するのが難しい (変更がある場合、プロジェクトごとに jar を更新する必要があります)。
すべてのロジックを含む EJB プロジェクトを作成し、リモートでアクセスします。メンテナンスが容易で、セキュリティ、キャッシング、および構成が一度だけ実装されます。リモート通話のペナルティが心配です。調査で気づいたように、これは悪い習慣のようです (私たちは ejb の経験があまりありません)。
内部にすべてを含む Ear プロジェクトを作成し、ローカル アクセスを使用します。これは、リモート バージョンよりも高速ですが、維持するのが大変です。
OSGI を選択: これは EJB ほど人気がなく、真剣に使用したことがないため、少し心配です。
この種の問題の一般的な方法はありますか?
どうもありがとう！