アプリケーション・サーバーがサポートするさまざまなアプリケーション・タイプで使用される 多くの部分を含め、プログラミング・モデルについて学習するため、 『WebSphere アプリケーションについての学習』セクションを開始点として使用します。
図では、単一アプリケーション・サーバーのインストールを示しています。プログラミング・モデルに 関連する部分は、ここで説明されます。他の部分は製品アーキテクチャーを構成し、 プログラミング・モデルで概要が説明されているさまざまなアプリケーション・タイプから 独立しています。製品アーキテクチャー を参照してください。
Web コンテナーは、Web アプリケーション・コンポーネントが実行 されるアプリケーション・サーバーの一部です。Web アプリケーションは、1 つ以上の関連するサーブレット、JavaServer Pages テクノロジー (JSP ファイル)、 Hyper Text Markup Language (HTML) ファイルから構成され、各構成要素をまとめて管理できます。 これらが結合され、ビジネス・ロジック機能が実行されます。
サーブレット は、 動的 Web ページ・コンテンツのサポート、データベース・アクセスの提供、 複数クライアントへの同時サービス提供、およびデータのフィルター処理などのタスクを実行できます。
JSP ファイル により、Web ページにおける ビジネス・ロジックからの HTML コードの分離が可能になります。JSP 仕様の IBM 拡張を使用すると、HTML 作成者は Java プログラミングの専門知識がなくても、Java テクノロジーの 強力な機能を容易に Web ページに追加できます。
HTTP セッション とは、同じブラウザーを使用して、同じユーザーからサーブレットに対して出される一連の要求のことです。 Web コンテナー内で稼働するアプリケーションは、セッションを利用して個々のユーザーを管理します。 例えば、多くの Web アプリケーションでは、 訪問したページでの一連の選択に基づいて、 ユーザーがサイトを移動するときのデータを動的に収集できます。ユーザーの次の移動先、つまり、次に表示されるサイトは、 ユーザーが以前にサイトで選択した内容により決定されます。このデータを保守するために、アプリケーションはこれを「セッション」に保管します。
EJB コンテナーは、エンタープライズ Bean をデプロイおよび管理するために 必要なすべてのランタイム・サービスを提供します。これは、セッション Bean とエンティティー Bean の両方の 要求を処理するサーバー・プロセスです。
Enterprise Bean は、 通常、J2EE アプリケーションのビジネス・ロジックをインプリメントしたり、データにアクセスしたりする Java コンポーネントです。 EJB モジュールにパッケージされ、アプリケーション・サーバーにインストールされているエンタープライズ Bean は、サーバーと直接通信しません。 EJB コンテナーは EJB コンポーネントとアプリケーション・サーバーの間の インターフェースです。コンテナーとサーバーは共に、エンタープライズ Bean ランタイム環境を 提供します。
コンテナーは、多くの下位レベルの サービス (スレッド化、トランザクション・サポートなど) を提供します。 管理的な側面として、EJB コンテナーは 格納されている Bean のデータ・アクセスを処理します。 単一コンテナーは、 複数の EJB Java アーカイブ (JAR) ファイルをホストすることができます。
本製品は、アプリケーション・クライアントを開始するための便利なlaunchClient ツール と、 クライアント・コンテナー・ランタイムを提供します。
技術情報のソースによっては、 クライアント・アプリケーションは、アプリケーション・クライアントとも呼ばれます。 この資料では、2 つの用語は同意語です。
管理クライアントの使用 を参照してください。
製品は、Web サービス・ プロバイダーと要求側の両方として機能します。プロバイダーとしては、クライアントが使用するために公開される Web サービス をホストします。要求側としては、他のロケーションから Web サービスを呼び出すアプリケーション をホストします。図では、Web サービス・プロバイダーまたはゲートウェイに接触する、 この機能の Web サービス・エンジンを示しています。
エンタープライズ・アプリケーションと EIS 間の接続は、EIS 提供のリソース・アダプター (アプリケーション・サーバーに接続する) を使用して行われます。このアーキテクチャーにより、アプリケーション・サーバーと EIS 間の、接続管理、トランザクション管理、 およびセキュリティー契約が指定されます。
アプリケーション・サーバーの 接続マネージャー (表示されていない) が接続をプールして管理します。 JCA 仕様で定義されているリソース・アダプターおよび JDBC 2.0 拡張仕様で定義されているデータ・ソースの両方によって取得される接続を管理することができます。
JDBC リソース (JDBC プロバイダーおよびデータ・ソース) は、データ・アクセスのためアプリケーションによって使用される J2EE リソース の 1 タイプです。データ・アクセスは、JDBC リソースに限らない広範な主題ですが、 この情報では、多くの場合、簡潔化のために J2EE リソースの見出しの下にデータ・アクセスをグループ化します。
JCA リソース・アダプター は、アプリケーションが使用する別のタイプの J2EE リソースです。JCA は、異機種の EIS に J2EE プラットフォームを接続するための標準アーキテクチャーです。これには、Java プログラミング 言語で書き込まれていない ERP、メインフレーム・トランザクション処理、データベ ース・システム、およびレガシー・アプリケーションなどがあります。
JCA リソース・アダプターは、EIS ベンダーまたはその他のサード・パーティー・ベンダーが提供する システム・レベルのソフトウェア・ドライバーです。これは、 J2EE アプリケーション・サーバーまたはクライアントと EIS の間の接続を提供します。リソース・アダプターを 使用するには、リソース・アダプター・コードをインストールし、そのアダプターを使用する構成を作成します。 製品は、定義済みのリレーショナル・リソース・アダプターを提供します。
非 JMS インバウンド要求の場合、メッセージ駆動型 Bean は、 その目的のために作成された Java Connector Architecture (JCA) 1.5 リソース・アダプターを使用します。JMS メッセージングに対応するため、 メッセージ駆動型 Bean では、JCA ベースのメッセージング・プロバイダー (例えば、WebSphere Application Server に搭載されている、 デフォルトのメッセージング・プロバイダー) を使用できます。
EJB 2.1 は、 メッセージ駆動型 Bean を宛先に接続するために ActivationSpec を導入します。バージョン 5 との互換性のため、 現在もリスナー・ポートに対して JMS メッセージ駆動型 Bean (EJB 2.0) を構成 できます。 これらのメッセージ駆動型 Bean に対して、メッセージ・リスナー・サービスは、 1 つ以上の JMS リスナーを制御およびモニターするリスナー・マネージャーを提供します。 JMS リスナーはそれぞれ、デプロイされるメッセージ駆動型 Bean に代わって、JMS 宛先を モニターします。
メッセージング・サポートに対する今後の変更の可能性に ついて確認するには、非推奨のフィーチャーと除去されたフィーチャー を参照してください。
サービス統合バスは、メッセージングおよびサービス指向アプリケーションの 統合された通信インフラストラクチャーを提供します。サービス統合バスは、 高信頼性メッセージ・トランスポートを提供し、仲介論理を使用してメッセージ・フローを ネットワークにインテリジェントに適応させる JMS プロバイダーです。これは、 Web サービスの要求側とプロバイダーの接続をサポートします。この機能は、 セキュリティー、システム管理、モニター、および問題判別サブシステムを含め、 製品アーキテクチャーに完全に統合されています。
JavaMail API は、Java ベースのメール・クライアント・アプリケーションを構築するための、 プラットフォームとプロトコルに依存しないフレームワークを提供します。API が、プロトコル上で 稼働するメール・サーバーと対話する場合は、該当するサービス・プロバイダー (プロトコル・プロバイダー として知られる) が必要になります。
メール・プロバイダーは、 メール送信用の Simple Mail Transfer Protocol (SMTP)、メール受信用の Post Office Protocol (POP)、およびメール受信用の別のオプションとしての Internet Message Access Protocol (IMAP) を含む、 プロトコル・プロバイダーのコレクションをカプセル化します。別のプロトコルを使用する場合、 そのプロトコル用に適切なサービス・プロバイダーをインストールする必要があります。
JavaMail には、 サービス・プロバイダーの他に、Multipurpose Internet Mail Extensions (MIME)、URL ページ、および添付ファイルなどの プレーンではない複素数データ・タイプを扱うための基礎となるフレームワークとして JavaBeans Activation Framework (JAF) が必要です。
URL プロバイダーは、 HTTP などの特定の URL プロトコルの機能性を実装し、 アプリケーションと特定のプロトコルにサービス提供される URL リソース間の通信を可能にします。 デフォルトの URL プロバイダーは、HTTP、 FTP、または File などのサポートされる Java 2 Standard Edition 仕様に基づいたプロトコルを 持つ URL リソースで使用するために組み込まれています。追加プロトコルを実装する独自の URL プロバイダーを プラグインすることもできます。
java:comp/env 環境は、JNDI ネーム・スペース・オブジェクトと ローカル・アプリケーション環境オブジェクトの両方を検索する際に使用する単一メカニズムを 提供します。製品は、デフォルトで、多数のローカル環境エントリーを提供しています。
セキュリティー・インフラストラクチャーおよびメカニズムによって、 エンタープライズ・セキュリティー要件に対応することで、Java 2 Platform Enterprise Edition (J2EE) リソースおよび管理リソースが保護されます。言い換えると、この製品のセキュリティー・インフラストラクチャーは、 複数層のエンタープライズ・コンピューター・フレームワークの既存のセキュリティー・インフラストラクチャーと 連動します。オープン・アーキテクチャーに基づき、製品は、 エンタープライズ・ソフトウェア・コンポーネントと統合するプラグイン・ポイントを多数提供して、 エンドツーエンド・セキュリティーを提供します。
セキュリティー・インフラストラクチャーは、 プログラミング・モデルとアプリケーション・タイプに依存しない製品アーキ テクチャーのエレメントの両方に 関連します。
JNDI は、 ネーミングへのクライアント・サイド・アクセスを提供し、 アプリケーション開発者により使用されるプログラミング・モデルを表します。 CosNaming は、サーバー・サイド・インプリメンテーションを提供し、 ネーム・スペースが実際に保管される場所となります。JNDI は、基本的に、CosNaming に保管されたネーム・スペースのクライアント・サイド・ラッパーを提供し、 クライアントの代わりに CosNaming サーバーと対話します。
アプリケーション・サーバーのクライアントは、 ネーミング・アーキテクチャーを使用し、これらのアプリケーションに関連するオブジェクトへの参照を取得します。 オブジェクトは、多くの場合、ネーム・スペースと呼ばれる階層構造にバインドされます。 これは、名前バインディングのセットから構成されており、それぞれは、特定のコンテキストに関連した名前、 およびその名前にバインドされたオブジェクトになっています。ネーム・スペースは、 ネーム・サーバーを通じてアクセスおよび操作できます。
ORB は、 クライアントがネットワーク内のオブジェクトを探し出して、 そのオブジェクトに対して操作を呼び出すためのフレームワークを提供します。 その場合、リモート・オブジェクトについては、場所を意識する必要がなく、 クライアントと同じ実行プロセス内にあるかのように扱うことができます。
図には示されていませんが、 ORB が機能する 1 つの場所は、クライアント・コンテナーが Java クライアントに代わって EJB コンテナーと接触を行う場所です。
サーバー上で動作するアプリケーションは、トランザクションを使用することにより、リソースへの複数の更新を 1 つの作業単位として 調整できます。その場合、すべての更新が永続的に更新されるか、どの更新も永続的に更新されないかのどちらかになります。 トランザクションは、アプリケーション、またはアプリケーションがデプロイされているコンテナーにより、 開始したり終了したりします。
アプリケーション・サーバーは、 リソース・マネージャーの調整をサポートするトランザクション・マネージャーであり、 その他の準拠トランザクション・マネージャーとともに、 分散グローバル・トランザクションに参加します。
サーバーは、 分散トランザクション・サポートが必要ではない場合、 ローカル・トランザクション・サポートを介して、 データベース、JMS キュー、および JCA コネクターと対話するように構成することができます。
WebSphere プログラミング・モデル拡張機能は、 本製品に付属のプログラミング・モデルの利点です。 アプリケーション機能および性能を拡張し、プログラミングおよびデプロイメントをより迅速かつ生産的にする、 最先端のテクノロジーを提供します。
さまざまな WebSphere プログラミング・モデル拡張機能およびアプリケーション・サーバー実行時にそれを サポートする対応アプリケーション・サービスは、ビジネス・オブジェクト・モデル拡張機能、 ビジネス・プロセス・モデル拡張機能、および次世代アプリケーションを作成するための拡張機能 の 3 つのグループに分類可能です。
ビジネス・オブジェクト・モデルに関連する拡張機能
アプリケーション・プロファイルおよびアクセス・インテントは、ソース・コードに影響を与えることなく、 エンタープライズ Bean のアプリケーション・パフォーマンスを微調整するための柔軟な方法を提供します。各種エンタープライズ Bean、 およびエンタープライズ Bean 内の各メソッドは、リソースにアクセスするための独自のインテントを持つことができます。 アクセス・インテントに基づくコンポーネントのプロファイルにより、 アプリケーション・サーバー・ランタイムのパフォーマンスが向上します。
動的照会により、実行時に、 クライアントが EJB コンポーネント上でカスタム照会を実行できるようになり、Enterprise Bean が改善されます。 これまでは、EJB 検索およびフィールド・マッピングは、開発時にインプリメントされ、 変更するには、さらに開発を行うか、再アセンブリーをする必要がありました。
J2EE アプリケーションは、 読み取り/書き込み率が高く、データの流れにおいて短時間の待ち時間であれば対応可能なので、 動的キャッシュは、サーバー応答時間、スループット、およびスケーラビリティーにおいて非常に有利です。
機能には、 クラスター間のキャッシュ複製、キャッシュ・ディスク・オフロード、Edge Side Include キャッシング、 および外部キャッシング (Web サーバーの機能のような、アプリケーション・サーバー外部からキャッシュを制御する機能) があります。
ビジネス・プロセス・モデルに関連する拡張機能
ActivitySessions は、 複数ローカル・トランザクションのスコープを拡張し、それらをグループ化する機能を提供します。これにより、 デプロイメント基準を基に、または明示的プログラム・ロジックにより、トランザクションをコミットすることができます。
次世代アプリケーション作成のための拡張機能
作業域により、分散アプリケーション間で情報を効果的に共用することができます。例えば、 お客様がアプリケーションにアクセスしたときにプロファイル情報を追加する場合などです。この情報を作業域に置くことにより、 アプリケーション全体でこの情報を使用でき、ソリューションを手動でコーディングしたり、 データベースに対して情報を読み取ったり書き込んだりする必要がなくなります。
拡張機能の学習について詳しくは、 WebSphere プログラミング拡張についての学習 を参照してください。