6

ここに画像の説明を入力してください

上の写真に示すように、EJB-3 Enterpriseアプリケーション（EARファイル）があります。これはポータルとして機能し、同じデータストアと通信およびトランザクションする3つのWebアプリケーション（WARファイル）を保持します。これらの3つのWebアプリはポートレットの実装ではありませんが、エンタープライズアプリの永続層を介してデータストアと対話する通常のWebアプリです。これらのWebアプリは独立して開発されているため、一部はEnterprise AppのWebサービスを使用し、一部はEJBクライアントを使用します。

また、以下に示すように、これらのWebアプリ（Web App1、Web App2、およびWeb App3）を置き換え、独立したEnterpriseAppsを使用してデータベースと通信およびトランザクションする他のオプションがあります。

ここに画像の説明を入力してください

さて、私の質問は次のとおりです。

1）上記の2つのオプションの中で最良のオプションは何ですか？

2）エンタープライズアプリのクライアントとして機能するWebアプリを独立したエンタープライズアプリ（EARファイル）として置き換えると、どのように影響しますか？

3）トランザクション処理、SSO機能、スケーラビリティ、およびその他の要素のより良いモデルは何ですか？

4）他にもっと良いモデルはありますか？

編集：

1）最初のモデルでは、EARファイルと対話するための好ましい方法はどれですか？webservicesまたはejb-client jarファイル/ライブラリ（インターフェースとユーティリティクラス）？

2）両方のモデルのメモリ使用量（サーバーRAM）とパフォーマンスはどのように異なりますか。かなりの違いはありますか？

4

3 に答える 3

3

あなたはとても抽象的なので、私もそれをします。「ポータル」、「エンタープライズアプリ」など、すべてのあいまいな単語を削除すると...最後に3つのWebアプリと共通のライブラリまたはフレームワーク（エンタープライズアプリ）があります。

そのアプリを可能な限りシンプルに見る。3つのWebアプリを開発する必要がある3人の開発者がいます。アプリの構築に役立つ一般的なコードをいくつか提供します。使用するモデルは、提供するコードの種類によって異なります。

1.-一部のユーティリティと一般的なビジネスコードのみを提供します。あなたのニーズに合った古典的なライブラリかもしれません。（Java EE環境では、単一のデータストアに対してSession Factoryを共有する永続性キャッシュレベル2の利点をどのように活用できるかを考慮する必要があります）

2.-永続性、キャッシュ、セキュリティ、監査などの共有サービスを提供します...最初のオプションとしてサービスレイヤーが必要になります。共有状態になるため、必要なインスタンスは1つだけです。

3.-より一般的なケースは、一般的なサービスにビジネスAPIとサービスレイヤーの両方を提供することです。

シナリオに対してより複雑なソリューションを使用することを強制する要件を示しているわけではありません。

編集：

rmi（ejb-client）またはwebservicesのどちらが優先されるかについて。私は常にrmiを使用して、地理的に近いアプリケーションを通信します。使用は簡単で、プロトコルはWebサービスよりもはるかに高速です（Googleでrmi Webサービスのパフォーマンスを検索するこのトピックに関する多くの比較を読むことができます）。
一方、rmiはネットワーク遅延に対してより敏感であり、特別なファイアウォール構成を必要とし、Webサービスよりも結合されています。したがって、サードパーティにサービスを提供したり、地理的にまばらなサーバーに接続したりするふりをする場合は、WebサービスまたはRESTを優先します。

最後の質問については、最初は同じサーバーに1つまたは10のアプリケーションをデプロイすることに違いはありません。デプロイ料金は、アプリケーションの使用のオーバーヘッドに対してわずかです。もちろん、これを一般的な仮定としてとらえる必要があります。明らかに、アプリケーションのサイズとデプロイ方法は、メモリ消費量などに影響を与えます。

この決定は、必要に応じて簡単に変更できることを考慮に入れる必要があります。先ほど申し上げたように、簡単な解決策から始めることができ、アプリケーションのデプロイで問題が発生した場合は、耳を簡単に再構築できます。

于 2012-05-01T21:50:58.320 に答える
0

私はFedoxに同意する傾向があります。あるソリューションを他のソリューションよりも選択する理由（ビジネス上の理由、技術的な理由など）がない場合は、抵抗が最も少ないパスを選択することをお勧めします。私の考えでは、それが最初の解決策になるでしょう。

一般的に、単純なものから始めて、必要に応じて複雑さを追加します。あなたの解決策は文脈なしでは意味がありません。銀行のアプリは、ブログとは異なる考慮事項が必要です。

お役に立てれば

于 2012-05-02T12:42:34.900 に答える
0

VitriaのBusinessWareと呼ばれる新しいプラットフォームがあります。これは非常に成功したプロジェクトであり、数百万の価値があります。
次に、それがどのように機能し、理論的に同じことができるように何をするかを見てみましょう。
プロジェクトをデータベースと相互接続し、WebサービスをEJBと相互接続します。それらの概念から、次のことを学ぶことができます。

  1. メインのEJBステートレスBean（API）を作成します。その役割は、次のメッセージを渡すことです。

    • 他のWebサービスへのWebサービス
    • WebアプリへのWebサービス
    • 他のWebサービスへのWebアプリケーション

  2. これの目的は、EJB最初にメインデータベースで検証を行い、次に呼び出しを他のモジュールに渡すことです。

  3. このEJBのみがDBにアクセスして、接続をより安全にします
  4. これによりEJB、送信するモジュールが自由に受け入れられるようになるまでメッセージがキューに入れられます。
  5. これEJBにより、DB内のすべてのプロセスが制御されます
  6. これによりEJB、メッセージの送信先が決まります
于 2012-05-04T10:11:32.373 に答える