問題タブ [multi-tier]

私は Java EE アーキテクチャについて読んでいて、Java EE アーキテクチャの第 3 (データ) 層を構成するいわゆるEIS (エンタープライズ情報システム) 層への参照を (少なくとも Oracle ドキュメントで) いくつか見てきました。

3 層システムでは、データベースは通常 3 層目であることを理解しています。レガシー システムも、ビジネス ミドルウェア (第 2 層) と同じデータベースと直接対話し、何らかの理由で他のどこにも属さないため、この層に配置されることもあります。

私の質問は次のとおりです。3 番目の「EIS」層に属するコード(ある場合) は何ですか? Hibernate クラスや DAO などの ORM コード?

第 2 層では、システムとコンパイル済み Java の両方が実行されています。たとえば、作成した一連の WAR を実行する Tomcat サーバーがあるとします。私は、RDBMS と、その RDBMS と対話するためのいくつかのコード (私は推測しますか?!?!) を持っている第 3 層のアナロジーを「取得」していません。

要するに、EIS 層にコードを展開する背後にある標準/ベスト プラクティスとは何か、そしてそれらの展開がどのように見えるのか疑問に思っていると思います。前もって感謝します！

これはJava中心の質問ですが、実際には多層アーキテクチャを利用するすべてのシステムに当てはまります。

3層アーキテクチャでは、通常、次の3つの層があります。

• クライアントコードが存在するクライアント/プレゼンテーション層。と
• ビジネスロジックが存在するミドルウェア層。と
• RDBMSやその他のデータ量の多いシステムが存在するデータ/eis層

Javaランドでは、Webアプリケーションの場合、これは次のようになります。

• GlassFish「Web層」（Webアプリのクライアント層を構成するWAR）と「ビジネス層」（EJB、ミドルウェアなど）の両方を実行するようなアプリケーションサーバー。と
• データ層を具体化するRDBMSサーバー

仮想化/クラスター化された環境では、これらのアプリケーション（GlassFish、OracleやPostgreSQLなどのRBMBSなど）はVM上で実行されます。

私の質問：これらのVM間でこの3層アーキテクチャを割り当て/配布する標準的な方法は何ですか？つまり、次の「戦略」のいずれかが実行可能である可能性がありますが、優先的ではありません。

1. GlassFishとRDBMS（3層すべて）の両方を実行する1つのVM（たとえば、すべてのVMがUbuntuサーバーであるため、コスト/価格は方程式に考慮されません）
2. 2つのVM：GlassFishを実行しているアプリケーションサーバーVMと、PostgreSQLなどを実行しているデータベースサーバーVM
3. 3つのVM：2つのアプリサーバーVMは両方ともGlassFishを実行していますが、1つのGlassFishインスタンスはWAR（Web層）のみを実行していますが、2番目のFlassFishインスタンスはミドルウェア/ビズロジックを実行しています。次に、3番目のDBサーバー

明らかに、すべてのサーバー（すべての層）が同じVMで実行されている場合、ネットワークの遅延に悩まされることはないため、サーバーはより高速またはより効率的に実行される可能性があります。ただし、それらは同じVM上にあるため、それらをサポートするにはメガハードウェアが必要になります。この設定にはセキュリティ上の懸念もあるかもしれません。

それぞれに長所/短所があります。次の目標を最もよく達成する戦略に興味があります。（1）スループット/速度を最大化する、（2）クラスター化/クラウド環境に最適、（3）セキュリティを最大化する。

前もって感謝します！

Java EE アプリケーション (単純な Web GUI、大規模な EJB 3 ビジネス層、JPA) を使用しており、そのほとんどの機能は現在ログオンしているユーザーに依存しています。

このため、EJB には遍在するString userNameパラメーターが蔓延しています。それなしで実行できる重要なメソッドを見つけることはほとんどなく、最も基本的な EJB にまで及びます。場合によっては、ユーザーのロケールなど、他のセッション関連のパラメーターによって補足されます。

その結果、パラメーター リストが大きくなり、コードの明瞭さが損なわれます。これはおそらく一般的な問題ですが、どうすれば回避できますか? より多くのコードを GUI クライアントにプッシュすることは、さらにクレイジーなアイデアに思えます。

ウィキペディアからの次の定義は、多層アプリケーションのデータ アクセス層とは何かを説明しています。

データ アクセス レイヤー (DAL) は、データベースなどのある種の永続ストレージに格納されたデータへの簡単なアクセスを提供するコンピューター プログラムのレイヤーです。

永続ストレージは 1 つ以上のファイルで構成することもできますが、上位層は、ファイル内の情報をどのように編成したかを知りません。app.configまたはのような構成ファイルを使用するアプリケーションがあるとしますweb.config。app.configファイルにはいくつかのパラメーターの値 (キャッシュの最大サイズなど) が含まれている可能性があるため、これらの値はアプリケーションの起動時にロードする必要があります。さらに、アプリケーションが UI を介してこれらのパラメーターの編集を許可している場合は、app.configファイルを更新する必要があります。これらの操作はDALの一部ですか?

別のクラスを表すことを意図したクラスの標準名はありますが、それを区別します。

例は説明に役立つはずです。たとえば、私のビジネスレイヤーが、システムで実行されているプロセスに関する多くの情報を含む.NETのSystem.Diagnostics.Processなどのクラスのオブジェクトにアクセスできるとします。システムリソースプロジェクトなどの別のプロジェクトでは、これらの情報をすべて使用することはできないため、ビジネスレイヤーでは、重要と見なされる属性のみを含むクラスProcessInfoを実装します。

そのような中間の代表的なクラスの名前はありますか？

私の知る限り、GAEでは、さまざまなJavaアプリ（WAR）をさまざまなインスタンスにアップロードして、それらすべてを同じ「GAEアプリ」の一部にすることはできません。

ただし、モジュール化されたアーキテクチャがあればいいのですが、メインのWebアプリには、メインのWebアプリがその仕事をするのに役立つ他の複数のアプリがあります。たとえば、メインアプリで重大なことが発生した場合にメールアラートを送信する監視アプリ。メインアプリだけでなく、将来的には他のアプリでも使用できる、一般的な入力検証およびエンコードサービスを備えたセキュリティアプリ。

重要なのは、デプロイされたGAEアプリのアーキテクチャ全体を用意することですが、エンドユーザーが対話する「メインアプリ」はそのうちの1つだけです。また、GAEを「詐欺」しようとはしていません。これは、1つのモノロシックアプリ内にすべてが散らかっていても、すべてが小さなアプリに分離されていても、着信/発信帯域幅は同じになるためです。彼らは私にすべて同じように請求するようになります。

問題は、GAEがこの種の使用を思いとどまらせる（あるいは禁止する）場所を読んだことを覚えていることです。利用規約を読んだだけで、この種の制限はどこにも見つかりませんでしたが、許可されていない場合は、分離されたアーキテクチャの構築にコミットしたくありません。

私がこの種のセットアップを行うことができるかどうか、そしてここで開発者にどのような制限/制約（もしあれば）が課されているかを誰かが知っていますか？前もって感謝します！

3 つの層 (または層? 違いは?) を持つ多層プロジェクトを作成したい

では、各レイヤー (層) にどのように名前を付ける必要がありますか?

ウィキペディアでこの説明を見ました：

しかし、層を単純に「プレゼンテーション層」、「ロジック層」、「データ層」と名付けることはできませんか?

それは名前空間では適切ではありません。

ネーミングのアイデアは？

大規模な多層アプリケーションを開始したいと考えています。サーバー側アプリケーションは、同時に 1000 人を超えるユーザーに応答する必要があります。サーバーアプリは64ビットコンパイラで、クライアントサイドは32ビットで作りたいです。この場合、DataSnap がすべてのクライアントに問題なく応答できるかどうかわかりません。この場合、サーバー コンピュータは非常に強力 (マルチプロセッサと 16GB 以上の RAM) で、データベース管理システムは FireBird 2.5 です。

クライアント/サーバー アプリケーションで SSL 証明書を使用しています。クライアントとサーバーの両方が、間もなく期限切れになる 2 つの証明書を使用しています。通常、証明書を新しいものに置き換えるだけですが、膨大な数のクライアントがあるため、これを一度に行うことはできません。そのため、サーバーと一部のクライアントのみが更新されると、残りのクライアントは認証できなくなります。

手っ取り早い解決策は、証明書の有効期限を単純に無視するバージョンにバイナリを置き換えることです。クライアントの更新は、証明書の有効期限が切れる前に終了する限り、順次実行できます。

私が考えた長期的な解決策：

1. Puppet を使用してクライアントに新しい証明書をプッシュする

   • 残念ながら、すべてのクライアントが Puppet を介して管理されている、または管理されるわけではないため、実行可能ではありません

2. 2 番目の証明書セットを使用する

   • 最初のセットが期限切れの場合は、2 番目のセットを使用します
   • このように、サーバーには新しい証明書があり、一部のクライアントには新しい証明書があり、残りのクライアントには古い証明書がありますが、すべてが機能します

3. 現在の証明書の有効期限が切れている場合、クライアントはサーバーに新しい証明書を要求します。

他の解決策はありますか？

私はこの問題への答えを探し回っていましたが、以前に尋ねられたものはすべてこれの複雑なバリエーションのようであり、質問に答えていないので、私はただ尋ねるべきだと思いました。

私は次の3層アプリケーションを開発しています.....

• DAL-EntityFrameworkを使用したデータアクセス層
• BLL-ビジネスロジックレイヤー
• Webアプリ-MVCWebアプリケーション

Entity Frameworkモデル、リポジトリクラスを作成しました。接続文字列は、DALApp.Configファイルにあります。これで、BLLに最初のクラスが作成され、DALが参照されます。次の非常に基本的な方法をテストしようとすると、BLLに接続文字列がないことに関連するエラーが発生します。

BLLが接続文字列を探すのはなぜですか？私はここで本当に明白な何かを逃していますか？

複数のレイヤーにまたがる接続文字列を含める必要があり、n層構造の目的が損なわれる場合、これを行うための最良の方法はどのようになりますか？誰かが私のためにこれにいくつかの光を当てることができますか？