WebLogic Server および WebLogic Express の紹介
|
 |
 |
|
以下の節では、WebLogic Server の e-コマース プラットフォームについて概説します。
今日のビジネス環境では、新市場への参入を促進し、顧客の確保を手助けし、また新製品や新サービスをいち早く紹介することを可能にする Web および e-コマース アプリケーションが求められています。こうした新しいソリューションを構築してデプロイするためには、あらゆるタイプのユーザを接続して利用できるようにすると同時に、企業データ、メインフレーム アプリケーション、およびその他の企業アプリケーションを統合して強力でフレキシブルなエンド ツー エンドの e-コマース ソリューションを構築できる、実績があり信頼性の高い e-コマース プラットフォームが必要です。さらに、重要度の高い企業規模のコンピューティングを処理するためには、パフォーマンス、スケーラビリティ、および高可用性を提供しなくてはなりません。
産業界をリードする e-コマース トランザクション プラットフォームである WebLogic Server は、信頼性が高く、セキュリティが確保され、スケーラブルでかつ管理の容易なアプリケーションの開発とデプロイメントを可能にします。システム レベルでの詳細は WebLogic Server で管理するため、ユーザはビジネス ロジックとプレゼンテーションに集中することができます。
WebLogic Server は、Java 2 Platform, Enterprise Edition (J2EE) バージョン 1.3 の技術 (http://java.sun.com/j2ee/sdk_1.3/index.html) を実装しています。J2EE は、Java プログラミング言語に基づいた多層エンタープライズ アプリケーションを開発するための標準プラットフォームです。J2EE を構成する技術は、BEA Systems をはじめとするソフトウェア ベンダと Sun Microsystems によって共同開発されました。
J2EE アプリケーションは、標準化され、モジュール化されたコンポーネントに基づいています。WebLogic Server では、これらのコンポーネント用にあらゆるサービスが用意され、細かなアプリケーションの動作を、プログラミングを必要とせずに自動的に処理します。
注意 : J2EE には下位互換性があるため、WebLogic Server のこのバージョン上で引き続き J2EE 1.2 を実行できます。
WebLogic Server は、分散異種コンピューティング環境にまたがる、ミッション クリティカルな e-コマース アプリケーションを開発しデプロイする上で欠くことのできない機能を提供します。以下のような機能が含まれています。
WebLogic Server は、XML ベースの仕様である Web Services Description Language (WSDL) 1.1 を使用して Web サービスを記述しています。WebLogic Web サービスは、メッセージ フォーマットとしての SOAP (Simple Object Access Protocol) 1.1 および 1.2 と、接続プロトコルとしての HTTP をサポートします。
注意 : WebLogic Web サービスでは、SOAP 1.1 および 1.2 の両方の受信リクエストを受け付けますが、SOAP 1.1 の送信応答しか作成しません。
BEA WebLogic ExpressTM は、Web および無線アプリケーションに動的コンテンツとデータを提供する、スケーラブルなプラットフォームです。WebLogic Express は、プレゼンテーション サービス、および WebLogic Server からのデータ ベース アクセス サービスを備えており、これにより開発者は対話型のアプリケーションやトランザクション対応の e-ビジネス アプリケーションを迅速に開発したり、既存のアプリケーションにプレゼンテーション サービスを提供したりできます。
WebLogic Express には、WebLogic JDBC 機能、JavaServer Pages (JSP)、Remote Method Invocation (RMI)、および Web サーバ機能といった、WebLogic Server で使用できるサービスや API が多く用意されています。
WebLogic Express は、WebLogic Server とは異なり、エンタープライズ JavaBeans (EJB)、Java Message Services (JMS)、またはトランザクション用の 2 フェーズ コミット プロトコルは提供していません。
WebLogic Express の詳細については、WebLogic Express のマニュアルを参照してください。
WebLogic Server はアプリケーション サーバです。アプリケーション サーバは、分散型の多層エンタープライズ アプリケーションを開発およびデプロイするためのプラットフォームです。WebLogic Server は、Web サーバ機能、ビジネス コンポーネント、バックエンドのエンタープライズ システムへのアクセスなどのアプリケーション サービスを統合します。 キャッシングや接続プーリングなどの技術を使用して、リソースを有効に利用し、アプリケーションの性能を改善します。また、WebLogic Server は、エンタープライズ レベルのセキュリティ、および強力な管理機能を備えています。
WebLogic Server は、多層 (または n-層) アーキテクチャの中間層で動作します。多層アーキテクチャとは、コンピューティング システムを構成するソフトウェア コンポーネントが、相互に、かつハードウェア、ネットワーク、およびユーザに関連して動作する場所を決定するものです。各ソフトウェア コンポーネントの最適な位置を選択すると、アプリケーションをより速く開発でき、デプロイメントや管理が容易になります。また、パフォーマンス、使用率、セキュリティ、スケーラビリティ、および信頼性をより自在に制御することができます。
WebLogic Server は、Java Enterprise 標準である J2EE を実装しています。 Java は、ネットワークと相性のよいオブジェクト指向プログラミング言語であり、J2EE には、分散オブジェクトを開発するためのコンポーネント技術が含まれています。この機能により、WebLogic Server のアプリケーション アーキテクチャに、アプリケーション ロジックのレイヤリングという第 2 の次元が追加され、各レイヤは WebLogic Server の J2EE 技術の中に選択的にデプロイされます。
以降の 2 つの節では、WebLogic Server のアーキテクチャを表す 2 つの概念、ソフトウェアの層とアプリケーション ロジックのレイヤについて説明します。
多層アーキテクチャのソフトウェア コンポーネントは、以下の 3 層で構成されています。
クライアント アプリケーションは直接 WebLogic Server にアクセスするか、別の Web サーバまたはプロキシ サーバを経由してアクセスします。一般には、WebLogic Server がクライアントの代わりにバックエンド サービスと接続します。 しかし、クライアントが多層 JDBC ドライバを使用して、バックエンド サービスに直接アクセスしてもかまいません。
図 1-1 は、WebLogic Server アーキテクチャの 3 つの層を示しています。
WebLogic Server のクライアントは、標準のインタフェースを使用して WebLogic Server のサービスにアクセスします。WebLogic Server は Web サーバ機能を完全装備しているため、Web ブラウザは、Web の標準 HTTP プロトコルを使用して、WebLogic Server のページを要求できます。WebLogic Server サーブレットと JavaServer Pages (JSP) は、高度な e-コマース Web アプリケーションで求められる、動的でパーソナライズされた Web ページを生成します。
Java で記述するクライアント プログラムには、Java Swing クラスを使用して構築される高度な対話型のグラフィカル ユーザ インタフェースを備えることができます。標準の J2EE API を使用して WebLogic Server のサービスにアクセスすることもできます。
WebLogic Server にサーブレットや JSP ページをデプロイすることにより、Web ブラウザ クライアントではこれらのサービスをすべて利用できます。
このバージョンの WebLogic Server は真の J2EE アプリケーション クライアントをサポートします。以前のバージョンでは、WebLogic クライアントがクラスタ化、セキュリティ、トランザクション、および JMS などの WLS 機能を十分に活用するには、クライアントのマシン上に完全な WebLogic JAR があることが必要でした。
J2EE アプリケーション クライアントはクライアント マシン上で実行され、マークアップ言語で得られるよりも豊富なユーザ インタフェースを提供できます。アプリケーション クライアントはビジネス層で実行されている EJB に直接アクセスし、適宜 HTTP を介して Web 層で実行されているサーブレットと通信できます。一般に、アプリケーション クライアントはサーバからダウンロードされますが、クライアント マシン上にインストールすることもできます。
J2EE アプリケーション クライアントは Java アプリケーションですが、J2EE コンポーネントであるため、スタンドアロンの Java アプリケーション クライアントとは異なります。したがって、他の J2EE 準拠のサーバへ移植できるという利点があり、J2EE サービスにアクセスできます。
中間層には、WebLogic Server、その他の Web サーバ、ファイアウォール、およびプロキシ サーバが含まれます。プロキシ サーバとはクライアントと WebLogic Server の間のトラフィックを仲介するものです。BEA のモバイル コマース ソリューションの一部である Nokia WAP サーバは、無線デバイスと WebLogic Server との間の接続を提供する中間層サーバの一例です。
多層アーキテクチャに基づいたアプリケーションでは、中間層で、信頼性、スケーラビリティ、および高いパフォーマンスが要求されます。そのため、中間層に選択するアプリケーション サーバは、システムの成功にとってきわめて重要です。
WebLogic Server クラスタを使用すると、連携している複数の WebLogic Server に、クライアントのリクエストやバックエンド サービスを分散できます。クライアント層のプログラムは、単一の WebLogic Server のようにクラスタにアクセスします。負荷が大きくなる場合は、WebLogic Server をクラスタに追加して、処理を共有させることができます。クラスタは、選択可能なロードバランシング アルゴリズムを使用して、そのリクエストを処理できる WebLogic Server をクラスタ内で選択します。
リクエストが失敗すると、リクエストされたサービスを提供する別の WebLogic Server で引き継ぐことができます。フェイルオーバは可能な限り透過的であり、障害から回復するために記述しなければならないコードの量を最小限に抑えます。たとえば、WebLogic Server でリクエスト処理が失敗した場合、クライアントのセッションがセカンダリ サーバ上でその処理を再開できるように、サーブレット セッション ステートをセカンダリ WebLogic Server にレプリケートしておくことができます。WebLogic EJB、JMS、JDBC、および RMI サービスは、すべて、クラスタ化機能を使用して実装されます。
バックエンド層には、クライアントから WebLogic Server を介してのみアクセスできるサービスが含まれます。バックエンド層のアプリケーションは、多くの場合、最も重要でミッション クリティカルなエンタープライズ リソースです。WebLogic Server では、エンド ユーザによる直接的なアクセスを制限することによって、これらのリソースを保護します。接続プールやキャッシングなどの技術によって、WebLogic Server は、バックエンドのリソースを効率的に使用し、アプリケーションの応答を向上させます。
バックエンド サービスには、データベース、エンタープライズ リソース プランニング (ERP) システム、メインフレーム アプリケーション、レガシー エンタープライズ アプリケーション、およびトランザクション モニタが含まれます。Sun Microsystems の Java コネクタ アーキテクチャ仕様を使用して、既存のエンタープライズ アプリケーションをバックエンド層に統合できます。WebLogic Server では、統合されたバックエンド アプリケーションに Web インタフェースを簡単に追加できます。
データベース管理システムは、ほとんどすべての WebLogic Server アプリケーションが必要とする、最も代表的なバックエンド サービスです。WebLogic EJB および WebLogic JMS は、通常、永続的なデータをバックエンド層のデータベースに格納します。
WebLogic Server で定義される JDBC 接続プールは、あらかじめ指定された数のデータベース接続を開きます。データベース接続は、一度開かれると、データベースへのアクセスが必要なすべての WebLogic Server アプリケーションによって共有されます。接続の確立に関連する負荷の大きなオーバーヘッドは、クライアントのリクエストごとに 1 回ではなく、プールの各接続ごとに 1 回だけ発生します。WebLogic Server は、データベース接続を監視し、必要に応じて接続をリフレッシュし、アプリケーションに対して信頼できるデータベース サービスを確保します。
BEA WebLogic EnterpriseTM システムへのアクセスを提供している WebLogic Enterprise Connectivity および BEA Tuxedo® システムへのアクセスを提供している Jolt® for WebLogic Server でも、システムのパフォーマンスを強化するために接続プールを使用しています。
WebLogic Server は、J2EE のコンポーネント技術およびサービスを実装しています。J2EE コンポーネント技術には、サーブレット、JSP ページ、およびエンタープライズ JavaBeans (EJB) が含まれます。J2EE サービスには、標準のネットワーク プロトコル、データベース システム、およびメッセージング システムへのアクセスが含まれます。WebLogic Server アプリケーションを構築するには、必要に応じてこれらのサービス API を使用して、コンポーネントを作成し組み立てる必要があります。
コンポーネントは、WebLogic Server の Web コンテナまたは EJB コンテナ内で実行されます。コンテナでは、J2EE 仕様で定義されたライフサイクルのサポートやサービスを提供しているため、構築するコンポーネントでは、下層部の詳細を扱う必要はありません。
Web コンポーネントは、ブラウザ ベースの J2EE アプリケーションに対してプレゼンテーション ロジックを提供します。EJB コンポーネントは、ビジネスのオブジェクトやプロセスをカプセル化します。Web アプリケーションと EJB は、JDBC、JMS (Java Messaging Service)、および JTA (Java Transaction API) などの J2EE アプリケーション サービスの上に構築されています。
図 1-2 は、WebLogic Server のコンポーネント コンテナおよびアプリケーション サービスを示したものです。
以下の節では、プレゼンテーション ロジック、ビジネス ロジック、およびアプリケーション サービスの各レイヤについて説明します。
プレゼンテーション レイヤには、アプリケーションのユーザ インタフェースや表示ロジックが含まれます。ほとんどの J2EE アプリケーションは、クライアント マシン上の Web ブラウザを使用します。クライアント プログラムをすべてのユーザのコンピュータにデプロイするよりも容易なためです。この場合、プレゼンテーション ロジックは WebLogic Server の Web コンテナです。ただし、どのプログラミング言語で記述されたクライアント プログラムでも、HTML を表示するためのロジックまたは独自のプレゼンテーション ロジックを保持している必要があります。Web サービスにアクセスするクライアントは、呼び出そうとしている Web サービスを示す SOAP メッセージをアセンブルし、その本文の中に、必要なデータを含める必要があります。
標準の Web 技術を使って構築される Web ベースのアプリケーションは、アクセスや保守が容易で、ポータブルです。Web ブラウザ クライアントは、e-コマース アプリケーションのための標準仕様です。
Web ベースのアプリケーションでは、HTML ドキュメント、JavaServer Pages (JSP)、およびサーブレットによってユーザ インタフェースが表現されます。Web ブラウザには、HTML の記述から Web ページをユーザのコンピュータに表示するためのロジックが含まれています。
JavaServer Pages (JSP) とサーブレットは、密接に関連しています。どちらも、呼び出されるたびに、WebLogic Server 上で Java コードを実行して、動的な Web コンテンツを作成します。2 つの相違点は、JSP が拡張 HTML で記述されるのに対し、サーブレットは Java プログラミング言語を使用して記述される点です。
HTML の知識があり HTML エディタまたはデザイナを使用して作業することに慣れている Web デザイナにとって、JSP は便利です。サーブレットはすべて Java で記述されるため、Web デザイナよりも Java プログラマに適しています。サーブレットを記述するには、HTTP プロトコルおよび Java プログラミングに関する知識が多少必要になります。サーブレットは、リクエスト オブジェクト内の HTTP リクエストを受け取って、通常はその応答オブジェクトに HTML または XML を記述します。
JSP ページは、WebLogic Server 上で実行される前に、サーブレットに変換されます。つまり JSP ページとサーブレットでは、同じものに対する表現方法が異なっています。JSP ページは、HTML がデプロイされる場合と同じ方法で WebLogic Server にデプロイされます。.jsp ファイルは、WebLogic Server が提供するディレクトリにコピーされます。クライアントが .jsp ファイルを要求すると、WebLogic Server は、そのページがコンパイル済みかどうか、また最後にコンパイルされてから変更されているかどうかを確認します。必要に応じて、.jsp ファイルから Java サーブレット コードを生成する WebLogic JSP コンパイラを呼び出して、Java コードを Java クラス ファイルにコンパイルします。
Web ブラウザでないクライアント プログラムでは、ユーザ インタフェースを表示するために独自のコードを用意する必要があります。非ブラウザ クライアントには、通常、独自のプレゼンテーション ロジックと表示ロジックが含まれていて、ビジネス ロジックとバック エンド サービスへのアクセスに関してのみ、WebLogic Server に依存します。このため非ブラウザ クライアントは、ブラウザ ベースのクライアントよりも開発やデプロイが難しく、インターネットベースの e-コマース アプリケーションに対して適合しにくくなります。
Java のプログラムでは、Java Swing クラスを使用して、強力で移植性の高いユーザ インタフェースを作成することができます。Java で記述されたクライアント プログラムは Java RMI (Remote Method Invocation) を介して任意の WebLogic Server サービスを使用できます。それにより、クライアントではそのクライアント内のローカル オブジェクトと同じように、WebLogic Server オブジェクトを操作できます。RMI はネットワーク経由の呼び出しの詳細を隠蔽するため、J2EE クライアント コードとサーバ サイド コードはよく似ています。
RMI を介して WebLogic Server を活用するには、WebLogic Server のクラスがクライアント上で利用可能であることが必要です。 WebLogic Server 8.1 は、ここではシン クライアントと呼ばれる真の J2EE アプリケーション クライアントをサポートしています。小規模な標準 jar および JMS jar (各約 400 KB) が提供されています。WebLogic Server クライアントは InitialContext、UserTransaction、EJB などの標準 J2EE アーティファクトを活用できます。iiop、iiops、http、https、t3、および t3s がサポートされています。それぞれ、InitialContext で異なる URL を使用して選択できます。
WebLogic RMI-IIOP を使うと、CORBA 対応のプログラムは、WebLogic Server エンタープライズ Bean および RMI クラスを CORBA オブジェクトとして実行できます。WebLogic Server の RMI および EJB コンパイラは RMI クラスおよびエンタープライズ Bean 用の IDL (インタフェース定義言語) を生成することができます。こうして生成された IDL がコンパイルされて、ORB (Object Request Broker) 用のスケルトンとクライアント プログラム用のスタブが作成されます。WebLogic Server は、受信した IIOP リクエストを解析して、RMI 実行時システムにディスパッチします。
WebLogic Web サービスを呼び出すクライアント アプリケーションは、Java、Microsoft .NET Toolkit などの任意のテクノロジを使用して記述できます。クライアント アプリケーションは、呼び出す Web サービスに関する SOAP (Simple Object Access Protocol) メッセージをアセンブルして必要なすべてのデータを SOAP メッセージの本文に含めます。次にクライアントは SOAP メッセージを HTTP/HTTPS を介して WebLogic Server に送信します。そこで Web サービスが実行され、SOAP メッセージが HTTP/HTTPS を介してクライアントに送り返されます。
Java ベースの Web サービス クライアントの場合、WebLogic Server はオプションの Java クライアント JAR ファイルも提供します。JAR ファイルには、WebLogic Web サービス クライアント API や WebLogic FastParser など、クライアント アプリケーションが WebLogic Web サービスを呼び出すために必要なものがすべて含まれています。他の Java WebLogic Server クライアントとは異なり、Web サービス クライアントには weblogic.jar ファイルを含める必要がないため、シン クライアント アプリケーションを作成できます。
エンタープライズ JavaBeans は、J2EE アプリケーションのビジネス ロジック コンポーネントです。WebLogic Server の EJB コンテナは、エンタープライズ Bean のホストになり、ライフサイクル管理、およびキャッシング、永続性、トランザクション管理といったサービスを提供します。
エンタープライズ Bean には、エンティティ Bean、セッション Bean、およびメッセージ駆動型 Bean の 3 種類があります。次の節では、それぞれの種類について詳しく説明します。
エンティティ Bean は、顧客、口座、または倉庫のアイテムといったデータを含むオブジェクトを表します。エンティティ Bean には、データ値およびそれらの値に対して呼び出されるメソッドが含まれます。これらの値は、(JDBC を使用して) データベース、または、何らかのデータ ストアに保存されます。エンティティ Bean は、他のエンタープライズ Bean が関連するトランザクションやトランザクション対応のサービスに参加できます。
エンティティ Bean は、たいていデータベース内のオブジェクトにマップされます。エンティティ Bean は、テーブル内の 1 行、行内の 1 カラム、または、テーブル全体やクエリ結果を表すことができます。各エンティティ Bean には、Bean の検索、取得、および保存に使用されるユニークな主キーが関連付けられています。
コンテナ管理による永続性を使用すると、WebLogic EJB コンパイラで JDBC サポート クラスを生成して、エンティティ Bean をデータベース内の行にマップできます。コンテナ管理による永続性では、その他のメカニズムも利用できます。たとえば、Oracle Corporation の TopLink for WebLogic Foundation Library は、オブジェクト リレーショナル データベースに対し永続性を提供します。
エンティティ Bean は、多くのクライアントおよびアプリケーションで共有できます。エンティティ Bean のインスタンスは、任意のクライアントのリクエストで作成されますが、そのクライアントの接続が解除されても消滅しません。エンティティ Bean のインスタンスは、クライアントがアクティブに使用している限り生存します。EJB コンテナは、使用されなくなった Bean に対してパッシベーションを行う場合があります。つまり、生存しているインスタンスであっても、サーバから削除される可能性があります。
セッション Bean は、1 つのクライアントを提供する、一時的な EJB インスタンスです。セッション Bean は、データよりもアクションを具体化するため、手続き的なロジックを実装する傾向があります。
EJB コンテナは、クライアントからのリクエストを受けて、セッション Bean を作成します。 そして、そのクライアントがその Bean との接続を維持している間のみ、その Bean を維持します。セッション Bean は永続的ではありませんが、必要に応じて、永続ストレージにデータを保存できます。
セッション Bean は、ステートレスにもステートフルにもなります。ステートレス セッション Bean は、呼び出しの間クライアント固有の状態を維持しないため、どのクライアントでも使用できます。ドキュメントをプリンタに送信したり、読み込み専用のデータをアプリケーション内に取得したりといった、セッションのコンテキストに依存しないサービスへのアクセスを提供できます。
ステートフル セッション Bean は、特定のクライアントの代わりに状態を維持します。 ステートフル セッション Bean を使うと、ワークフロー プロセスにおける順序の組み立てやドキュメントのルーティングといった、プロセスの管理ができます。クライアントとの複数の対話の間、状態を蓄積して維持することができるため、セッション Bean は、アプリケーション内の制御オブジェクトとしてよく使用されます。セッション Bean は永続的ではないため、単一のセッション内で処理を完了し、JDBC、JMS、またはエンティティ Bean を使用してその処理を永久に記録しておく必要があります。
EJB 2.0 仕様で導入されたメッセージ駆動型 Bean は、JMS メッセージ キューから受け取った非同期メッセージを処理するエンタープライズ Bean です。JMS からメッセージが転送されると、メッセージ駆動型 Bean は、プールからインスタンスを選択してメッセージを処理します。
メッセージ駆動型 Bean は、WebLogic Server の EJB コンテナで管理されます。メッセージ駆動型 Bean は、ユーザ駆動型アプリケーションから直接呼び出されることはありません。そのため、EJB ホームを使用してアプリケーションからメッセージ駆動型 Bean にアクセスすることはできません。ただし、ユーザ駆動型アプリケーションでも、その Bean の JMS キューにメッセージを送信することにより、メッセージ駆動型 Bean を間接的にインスタンス化できます。
WebLogic Server では、コンポーネントが低レベルな実装の詳細に関わることなくビジネス ロジックに集中できるようにする、基盤となるサービスを提供します。WebLogic Server は、ネットワーク、認証、認可、永続性、および EJB やサーブレット用のリモート オブジェクトへのアクセスを扱います。標準 Java API は、データベースやメッセージング サービスといった、アプリケーションが使用できるその他のサービスへの移植性の高いアクセスを提供します。
WebLogic Server では、WebLogic Server に適用可能な Extensible Markup Language (XML) テクノロジと、WebLogic Server に基づく XML アプリケーションが統合されています。Standard Generalized Markup Language (SGML) の簡略化されたバージョンである XML は、文書内のデータの内容と構造を記述するものであり、インターネット上でコンテンツを配信する際の業界標準となっています。通常、XML は J2EE アプリケーションとクライアント アプリケーション間、または J2EE アプリケーションのコンポーネント間におけるデータ交換フォーマットとして使用されます。WebLogic Server XML サブシステムでは、XML ファイルを処理および変換するために、標準パーサ、WebLogic FastParser、WebLogic PullParser、XSLT トランスフォーマ、DTD、および XML スキーマの使用をサポートしています。
クライアント アプリケーションは、TCP/IP に基づいた標準のネットワーキング プロトコルを使用して、WebLogic Server に接続します。WebLogic Server は、Uniform Resource Identifier (URI) の一部として指定できるネットワーク アドレスで、接続リクエストをリスンします。
URI は、標準化された文字列で、インターネットを含むネットワーク上のリソースを指定します。URI には、プロトコルを指定する方式、サーバのネットワーク アドレス、要求されたリソース名、およびパラメータ (省略可能) が含まれます。Web ブラウザに入力する URL、たとえば http://www.bea.com/index.html は、最も一般的な URI 形式です。
Web ベースのクライアントは、HTTP プロトコルを使用して WebLogic Server と通信します。Java クライアントは、Java RMI (Remote Method Invocation) を使用して接続します。Java RMI を使用すると、Java クライアントは WebLogic Server のオブジェクトを実行できます。 CORBA 対応クライアントは、RMI-IIOP を使用して WebLogic Server の RMI オブジェクトにアクセスします。RMI-IIOP を使用すると、CORBA 対応クライアントは、標準の CORBA プロトコルを使用して WebLogic Server のオブジェクトを実行できます。
以下の表のように、URI の方式は、クライアントと WebLogic Server がネットワーク経由でやりとりするためのプロトコルを決定します。
World Wide Web の標準プロトコルである HTTP は、リクエスト応答プロトコルです。クライアントは URI が含まれたリクエストを発行します。URI は、http:// で始まり、WebLogic Server のアドレス、次に HTML ページ、サーブレット、または JSP ページといった WebLogic Server 上のリソースの名前が続きます。リソース名が省略された場合、WebLogic Server はデフォルトの Web ページ (通常は index.html) を返します。HTTP リクエストのヘッダには、コマンド (通常は GET または POST) が含まれます。HTTP リクエストには、データ パラメータおよびメッセージ コンテンツを含めることができます。
WebLogic Server は、クライアントに結果を返すサーブレットを実行することにより、HTTP リクエストに常に応答します。HTTP サーブレットは、ネットワーク上で受け取った HTTP リクエストのコンテンツにアクセスして、HTTP 準拠の結果をクライアントに返すことができる Java クラスです。
WebLogic Server は、HTML ページに対するリクエストを、組み込みの File サーブレットに転送します。File サーブレットは、WebLogic Server のファイル システムのドキュメント ディレクトリ内で HTML ファイルを探します。カスタム コード化されたサーブレットへのリクエストが、WebLogic Server 上の対応する Java クラスに対して実行されます。JSP ページへのリクエストが発生すると、WebLogic Server はその JSP ページがまだコンパイルされていない場合はコンパイルして、サーブレットを実行します。サーブレットは結果をクライアントに返します。
T3 は最適化されたプロトコルで、WebLogic Server と他の Java プログラムとの間のデータ転送に使用されます。これには、クライアントとそれ以外の WebLogic Server 間のデータ転送も含まれます。WebLogic Server は、接続された個々の Java 仮想マシン (JVM) を追跡して、JVM に対するすべてのトラフィックを実行できる単一の T3 接続を作成します。
たとえば、Java クライアントが WebLogic Server 上のエンタープライズ Bean および JDBC 接続プールにアクセスすると、1 つのネットワーク接続が WebLogic Server の JVM とクライアントの JVM との間に確立されます。T3 プロトコルは 1 つの接続上のパケットを見えない形で多重化するため、EJB および JDBC のサービスでは、専用のネットワーク接続を単独で使用しているかのように記述することができます。
T3 は不要なネットワーク接続イベントを回避し、OS のリソースをほとんど使用しないため、Java-to-Java アプリケーションにとって効率的なプロトコルです。また、このプロトコルにはパケット サイズを最小限に抑える内部の機能があります。
Remote Method Invocation (RMI) は、分散アプリケーションのための標準的な Java 機能です。RMI を使うと、「サーバ」と呼ばれる Java プログラムが Java オブジェクトをパブリッシュし、「クライアント」と呼ばれるもう 1 つの Java プログラムがそのオブジェクトを実行できます。ほとんどのアプリケーションでは、WebLogic Server が RMI サーバで、Java クライアント アプリケーションがクライアントになります。ただし、RMI では任意の Java プログラムがサーバの役割を果たせるため、この役割を逆にすることもできます。
RMI アーキテクチャは、CORBA アーキテクチャと似ています。リモート オブジェクトを作成するには、リモート クライアントが実行するメソッドを定義した Java クラス用のインタフェースをプログラマが記述します。WebLogic Server の RMI コンパイラ rmic を使用してこのインタフェースを処理し、RMI スタブおよびスケルトン クラスを生成します。リモート クラス、スタブ、およびスケルトンが WebLogic Server にインストールされます。
Java クライアントは、この節で後述する Java Naming and Directory Interface (JNDI) を使用して、WebLogic Server のリモート オブジェクトをルックアップします。JNDI は、WebLogic Server への接続を確立し、リモート クラスをルックアップして、スタブをクライアントへ返します。
クライアントは、リモート クラス上で直接メソッドを実行しているように、スタブ メソッドを実行します。スタブ メソッドは呼び出しを用意し、それをネットワーク経由で WebLogic Server 内のスケルトン クラスに転送します。
WebLogic Server では、スケルトン クラスがリクエストを復元し、サーバ サイド オブジェクト上でメソッドを実行します。スケルトン クラスは、その結果をパッケージ化してクライアント サイドのスタブに返します。
WebLogic EJB および Java クライアントから利用できるその他のサービスが RMI 上に構築されます。EJB はビジネス オブジェクトをよりよく抽象化できるため、ほとんどのアプリケーションでは、RMI を直接使用するよりも、EJB を使用するほうがよいでしょう。さらに、WebLogic Server の EJB コンテナには、キャッシング、永続性、ライフサイクル管理といった、リモートクラスでは自動的に利用できない拡張機能があります。
Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) は、CORBA クライアント プログラムでエンタープライズ Bean を含む WebLogic RMI のオブジェクトを実行できるようにするプロトコルです。RMI-IIOP は、Object Management Group (http://www.omg.com) が策定した 2 つの仕様に基づいています。
Java-to-IDL 仕様は、Interface Definition Language (IDL) が Java インタフェースからどのように派生するかについて定義しています。WebLogic Server の RMI および EJB コンパイラでは、RMI および EJB オブジェクトをコンパイルする際に IDL を生成するオプションがあります。IDL API のコンパイラを使用して IDL をコンパイルすると、CORBA クライアントが要求するスタブを生成できます。
Objects-by-Value 仕様は、Java と CORBA の間で複合データ型をどのようにマップするかを定義します。Objects-by-Value を使用するには、CORBA クライアントは、CORBA 2.3 でサポートされている Object Request Broker (ORB) を使用する必要があります。CORBA 2.3 仕様の ORB がない場合は、CORBA クライアントは、Java プリミティブ データ型のみ使用できます。
HTTP および T3 プロトコルとの間で交換されるデータは、セキュア ソケット レイヤ (SSL) プロトコルを使用して暗号化できます。SSL を使用することで、認証されたサーバに接続されたこと、およびネットワーク経由で転送されるデータが非公開であることを、クライアントに対し約束します。
SSL では公開鍵暗号化を使用しています。公開鍵暗号化を行うには、WebLogic Server デプロイメントの ID および信頼を生成する必要があります。ID はデジタル証明書および関連のプライベート キーという形式を取ります。信頼は、WebLogic Server の ID を検証する認証局 (Entrust、Versign など) によって確立されます。クライアントが WebLogic Server の SSL ポートに接続すると、サーバとクライアントはプロトコルを実行します。ここで、サーバの Server ID の認証、信頼の検証、暗号化アルゴリズムとセッション パラメータのネゴシエーションが行われます。クライアントに対して証明書の提示を要求するように、WebLogic Server をコンフィグレーションすることもできます。これを、相互認証と呼びます。
SOAP (Simple Object Access Protocol) は、分散型環境で情報を交換するために使用する軽量 XML ベースのプロトコルです。このプロトコルは、SOAP メッセージを記述するエンベロープ、エンコーディング ルール、およびリモート プロシージャ呼び出しと応答を表す規則で構成されます。
すべての情報は、HTTP またはその他の Web プロトコル上で転送可能な Multipurpose Internet Mail Extensions (MIME) エンコード パッケージ内に埋め込まれています。MIME は、非 ASCII メッセージをインターネット上で送信できるようにフォーマットするための仕様です。
WebLogic Server は、アプリケーションおよびコンポーネントにデータ サービスとアクセス サービスを提供する、標準の J2EE 技術を実装しています。これらのサービスには、以下の API が含まれています。
Java Naming and Directory Interface (JNDI) は、アプリケーションでオブジェクトを名前からルックアップできるようにする、標準 Java API です。WebLogic Server またはユーザ アプリケーションは、提供する Java オブジェクトをネーミング ツリー内の名前にバインドします。WebLogic Server から JNDI コンテキストを取得し、オブジェクトの名前で JNDI のルックアップ メソッドを呼び出すことにより、RMI オブジェクト、エンタープライズ JavaBeans、JMS キューおよびトピックといったオブジェクトや JDBC データソースをアプリケーションでルックアップできます。ルックアップは、WebLogic Server オブジェクトへの参照を返します。
WebLogic JNDI は、WebLogic Server クラスタのロード バランシングやフェイルオーバ機能をサポートします。クラスタ内の各 WebLogic Server は、レプリケートされたクラスタワイドのネーミング ツリー内で提供するオブジェクトをパブリッシュします。アプリケーションは、クラスタ内の任意の WebLogic Server から JNDI の初期コンテキストを取得したり、ルックアップを実行したり、そのオブジェクトを提供するクラスタ内の任意の WebLogic Server からオブジェクト参照を受け取ったりできます。コンフィグレーション可能なロード バランシング アルゴリズムが、クラスタ内のサーバ間での負荷を分散するために使用されています。
Java Database Connectivity (JDBC) は、バックエンドのデータベース リソースへのアクセスを提供します。Java アプリケーションは、JDBC ドライバを使用して JDBC にアクセスします。JDBC ドライバは、データベース ベンダ固有の、データベース サーバ用インタフェースです。すべての Java アプリケーションでは、ベンダの JDBC ドライバをロードしたり、データベースに接続したり、データベース操作を実行したりできますが、WebLogic Server では、JDBC 接続プールを使用することにより、性能上の大きなメリットを提供します。
JDBC 接続プールとは、WebLogic Server で管理される JDBC 接続のグループに名前を付けたものです。WebLogic Server は、起動時に JDBC 接続を開いて、それらをプールに追加します。JDBC 接続が必要になると、アプリケーションはプールから接続を取得し、使用してから、他のアプリケーションが使用できるようにプールに返します。データベース接続を確立する処理は、多くの場合時間がかかり、リソースを大量に消費するため、接続プールでは、接続処理の数を制限することでパフォーマンスを改善します。
WebLogic Server はまた、単一サーバ コンフィグレーションにおけるデータベース接続でロード バランシングまたは高可用性の機能を実現するための JDBC マルチプールを提供します。マルチプールとは「プールのプール」で、特定のリクエストに対してどの接続を提供するかを選択するためのコンフィグレーション可能なアルゴリズムを備えています。現在、WebLogic Server はデータベース接続用に高可用性またはロード バランシングのどちらかをサポートするアルゴリズムを提供しています。
接続プールを JNDI ネーミング ツリーに登録するには、そのための DataSource オブジェクトを定義します。Java クライアント アプリケーションは、DataSource 名で JNDI ルックアップを行うことにより、プールから接続を取得できます。
サーバサイド Java クラスでは、WebLogic JDBC プール ドライバを使用します。これは、ベンダ固有の JDBC ドライバを呼び出す汎用 JDBC ドライバです。このメカニズムにより、アプリケーション コードの移植性を高めることができ、バックエンド層で使用するデータベースのブランドを変更するような場合にも対応できます。
クライアントサイドの JDBC ドライバは、WebLogic JDBC/RMI ドライバです。これは、プール ドライバへの RMI インタフェースです。このドライバは、標準 JDBC ドライバを使う場合と同様に使用できます。JDBC/RMI ドライバを使うと、Java プログラムは、他の WebLogic Server の分散オブジェクトと同じように JDBC にアクセスでき、また中間層のデータベースのデータ構造を維持できます。
WebLogic EJB および WebLogic JMS では、永続的なオブジェクトをロードおよび保存するために、JDBC 接続プールから取得した接続を使用します。EJB および JMS を使用すると、アプリケーションで直接 JDBC を使用するよりも便利な抽象化が提供されます。たとえば、エンタープライズ Bean を使用してデータの多いオブジェクトを表現すると、JDBC コードを修正せずに、後から基底のストアを変更することができます。JDBC を使用してデータベース操作をコーディングする代わりに、永続的な JMS メッセージを使用すると、サードパーティ製のメッセージング システムにアプリケーションを後から適応させることが簡単になります。
Java Transaction API (JTA) は、Java アプリケーションでトランザクションを管理するための、標準インタフェースです。トランザクションを使用して、データベース内のデータの整合性を保護し、並列アプリケーションまたは並列アプリケーション インスタンスによってそのデータへのアクセスを管理することができます。一度トランザクションを開始したら、トランザクション処理のすべてが正常にコミットされるか、あるいはそのすべてがロールバックされるかの、どちらかの状態になる必要があります。
WebLogic Server では、EJB、JMS、JCA、および JDBC 処理を含むトランザクションをサポートしています。2 フェーズ コミットにより調整される分散トランザクションは、BEA WebLogic jDriver for Oracle/XA のような XA 準拠の JDBC ドライバを使用してアクセスされる複数のデータベースにまたがることができます。
EJB 仕様では、Bean 管理によるトランザクションおよびコンテナ管理によるトランザクションが定義されています。エンタープライズ Bean がコンテナ管理のトランザクションと共にデプロイされると、WebLogic Server は自動的にトランザクションを調整します。エンタープライズ Bean が Bean 管理によるトランザクションと共にデプロイされる場合は、EJB プログラマはトランザクション コードを用意する必要があります。
JMS または JDBC API に基づいたアプリケーション コードを使用すると、トランザクションを開始したり、それ以前に開始されたトランザクションに参加したりできます。アプリケーションを実行する WebLogic Server スレッドには、1 つのトランザクション コンテキストが関連付けられています。スレッド上で実行されるすべてのトランザクション処理は現在のトランザクションに参加します。
J2EE コネクタ アーキテクチャは、エンタープライズ情報システム (EIS) を簡単に J2EE プラットフォームに統合します。数多くのアプリケーション サーバと EIS との間を接続するという問題を Java により解決します。コネクタ アーキテクチャを使用することで、EIS ベンダはアプリケーション サーバごとに自社製品をカスタマイズする必要がなくなります。J2EE コネクタ アーキテクチャに準拠することで、BEA WebLogic Server ではカスタム コードを追加しなくても、新しい EIS への接続機能を追加できるようになります。
J2EE コネクタ アーキテクチャは、WebLogic Server および EIS 固有のリソース アダプタのどちらでも実装されます。リソース アダプタとは EIS に固有のシステム ライブラリのことで、EIS への接続を提供するものです。リソース アダプタは JDBC ドライバと同様の機能を持っています。リソース アダプタと EIS 間のインタフェースは基底となる EIS に固有なので、ネイティブ インタフェースの場合もあります。
J2EE コネクタ アーキテクチャには、WebLogic Server と特定のリソース アダプタの間のシステムレベル規約、クライアントがアダプタにアクセスするための共通のインタフェース、およびリソース アダプタを J2EE アプリケーションに対してパッケージ化およびデプロイするためのインタフェースで構成されています。詳細については、『WebLogic J2EE コネクタ アーキテクチャ』を参照してください。
WebLogic Server では、WebLogic Server に適用可能な Extensible Markup Language (XML) テクノロジと、WebLogic Server に基づく XML アプリケーションが統合されています。詳細については、「XML 実装」を参照してください。
J2EE のメッセージング技術は、WebLogic Server のアプリケーション同士の通信や非 WebLogic Server アプリケーションとの通信に使用できる、標準 API を提供します。メッセージング サービスには、以下の API が含まれています。
Java Messaging Service (JMS) を使用すると、メッセージを交換してアプリケーション同士で通信できます。メッセージとは、異なるアプリケーション間の通信を調整するために必要な情報が含まれている、リクエスト、レポート、およびイベントです。メッセージで提供される抽象化のレベルにより、送り先システムについての詳細情報をアプリケーション コードから切り離すことができます。
WebLogic JMS は、ポイント ツー ポイント (PTP) およびパブリッシュ/サブスクライブ (pub/sub) という 2 つのメッセージング モデルを実装しています。PTP モデルでは、任意の数の送信者がキューにメッセージを送信できます。 キューの中の各メッセージは、1 つのリーダーに送信されます。pub/sub モデルでは、任意の数の送信者がトピックにメッセージを送信できます。トピック上の各メッセージは、そのトピックに対するサブスクリプションを持つすべてのリーダーに送信されます。メッセージは、同期的または非同期的に、リーダーに配信できます。特定のメッセージング モードは、Administration Console を使用するか、または JMS でメッセージ送信に使用されるメソッドによって制御できます。
JMS メッセージは永続的にも非永続的にもできます。永続的なメッセージはデータベースに保存され、WebLogic Server を再起動しても失われません。非永続的なメッセージは WebLogic Server を再起動すると失われます。 トピックに送信される永続的なメッセージは、そのメッセージに関心のあるすべてのサブスクライバが受信するまで保持できます。
JMS では、異なるタイプのアプリケーションに役立つ複数のメッセージ タイプをサポートしています。メッセージ本体には、任意のテキスト、バイト ストリーム、Java プリミティブ データ型、名前と値の組み合わせ、シリアライズ可能な Java オブジェクト、または XML コンテンツを含めることができます。
WebLogic Server には、Sun の JavaMail 参照実装が含まれています。 JavaMail を使用すると、アプリケーションで電子メール メッセージを作成して、ネットワーク上の SMTP サーバ経由で送信できます。
最も一般的な WebLogic Server のユーザには、以下のタイプがあります。
WebLogic Server 製品の評価およびレビューを担当する製品評価担当者の場合、製品とその重要な機能の概要を報告する上流工程のタスクが関心の対象となるでしょう。評価担当者は、以下のタスクについての関連ドキュメントを参照することをお勧めします。 これらのドキュメントは BEA の Web サイトから入手できます。BEA のホーム ページで [製品のドキュメント｜WebLogic Server <現在のバージョン> オンライン ドキュメント] をクリックしてください。
WebLogic Server 環境のインストールとセットアップを担当するユーザの場合、完全に機能するシステムを実現するためのタスクが関心の対象となるでしょう。 インストール担当者は、以下のタスクについての関連ドキュメントを参照することをお勧めします。これらのドキュメントは BEA の Web サイトから入手できます。BEA のホーム ページで [製品のドキュメント｜WebLogic Server <現在のバージョン> オンライン ドキュメント] をクリックしてください。
|
|
WebLogic Server 環境の管理を担当するユーザの場合、完全に機能するシステムを維持するためのタスクが関心の対象となるでしょう。システム管理者は、以下のタスクについての関連ドキュメントを参照することをお勧めします。これらのドキュメントは BEA の Web サイトから入手できます。BEA のホーム ページで [製品のドキュメント｜WebLogic Server <現在のバージョン> オンライン ドキュメント] をクリックしてください。
|
|
|
WebLogic Server アプリケーションまたはコンポーネントの開発を担当するユーザの場合、以下のタスクについての関連ドキュメントを参照することをお勧めします。これらのドキュメントは BEA の Web サイトから入手できます。BEA のホーム ページで [製品のドキュメント｜WebLogic Server <現在のバージョン> オンライン ドキュメント] をクリックしてください。
|
|
|
