3 層のアーキテクチャー

WebSphere® Application Server では、3 層のアーキテクチャーでアプリケーション論理層を提供し、クライアント・コンポーネントがデータ・リソースおよびレガシー・アプリケーションと対話できるようにします。

全体として考えると、3 層アーキテクチャーは、アプリケーション機能を 3 つの独立したシステムに配布できるようにするプログラミング・モデルです。 通常、以下のようになります。
  • ローカル・ワークステーション上で実行するクライアント・コンポーネント (層 1)
  • リモート・サーバーで実行するプロセス (層 2)
  • データベース、リソース・マネージャー、およびメインフレーム・アプリケーションの離散的集合 (層 3)

次の図は、3 層レベルの概要を示しています。各層は論理的な層です。同一の物理サーバーでは、これらの層は 稼働しないことがあります。

図 1. 3 層アーキテクチャー3 層アーキテクチャー

第 1 層。 表示およびユーザーとの対話は、第 1 層のコンポーネントが行います。これらのクライアント・コンポーネントによって、ユーザーは、安全で直感的な方法で第 2 層のプロセスと対話することが可能になります。 WebSphere Application Server は複数のクライアント・タイプをサポートしています。クライアントは、第 3 層のサービスには直接アクセスしません。 例えば、クライアント・コンポーネントは、顧客が製品を注文するフォームを提供します。 クライアント・コンポーネントは、この注文を、製品データベースをチェックして、請求書作成発行および出荷に必要なタスクを実行する第 2 層のプロセスへサブミットします。

第 2 層。 第 2 層のプロセスは、一般に、"アプリケーション論理層" と呼ばれています。これらのプロセスは、アプリケーションのビジネス・ロジックを管理し、第 3 層のサービスへのアクセスが許可されています。 ほとんどの処理作業は、このアプリケーション論理層で行われます。 複数のクライアント・コンポーネントが第 2 層のプロセスに同時にアクセス可能なので、このアプリケーション論理層は、独自のトランザクションを管理する必要があります。

前出の例では、何人かの顧客が同じ品目を注文しようとし、そのうちの 1 つしか在庫がない場合、アプリケーション論理層は、その品目に対する権利を持っているのは誰かを判別し、データベースを更新してその品目の購入状況を反映し、 そしてその品目はもう売り切れたことを他の顧客に通知しなければなりません。 アプリケーション論理層がない場合は、クライアント・コンポーネントが直接、製品データベースにアクセスします。 データベースは、独自の接続を管理する必要があり、通常は、アクセスされているレコードをロックアウトします。 品目がショッピング・カートに入れられるとロックが発生し、他の顧客はその品目の購入を検討できないようになります。 第 2 層と第 3 層を分離することにより、第 3 層サービスへの負荷を軽減して、より効果的な接続管理を可能にし、ネットワーク全体のパフォーマンスを向上させることができます。

第 3 層。 第 3 層のサービスは、安全なネットワーク内に存在し、クライアント・コンポーネントによる直接アクセスから保護されています。対話は、第 2 層のプロセスを介して発生する必要があります。

[z/OS]z/OS® の長所は、固有の層システムのセキュリティーおよび論理的長所を保持する一方、第 2 層および第 3 層を 1 つの物理的 z/OS 環境に縮小する機能があることです。

層間の通信。 3 層ではすべて、相互通信を行う必要があります。この通信は、オープンな標準プロトコルおよび公開された API によって単純化されています。 Java™ や C++ などのプログラム言語により、クライアント・コンポーネントを作成できます。これらのクライアントは、アプリケーション論理層と対話することにより、オペレーティング・システム上で稼働します。第 3 層のデータベースは、アプリケーション層による照会および操作が可能なものであれば、どのような設計でもかまいません。 このアーキテクチャーで重要なのは、アプリケーション論理層です。


トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=covr_3-tier
ファイル名:covr_3-tier.html