はじめに

メッセージングシステムは、スケーラブルで信頼性がある高性能アプリケーションを作成する場合に使用されます。 メッセージングシステムを使用すると、プログラマは、メッセージのバッファリングや分散、クラッシュ回復、クライアント登録、切断された接続などの複雑な操作を避けることができます。 ただし、今のところメッセージングシステムは独自のもので、アプリケーションコードを移植できないため、別の製品への移行は困難です。 また、共通の概念やAPIはあまり多くないため、メッセージングシステムを短期間で学習できます。

Java Message Service (JMS)は、Sun Microsystemsにより定義されているAPIで、Javaクライアントアプリケーションで企業メッセージングシステムにアクセスする方法を指定します。 JMSは、J2EEでメッセージ駆動型Beanの基礎的な役割を果たします。 ベンダによっては、異なるメッセージメカニズムやメッセージプロトコルを使用するJMSを実装していますが、JMSの仕様では、プログラマは一般的な概念を使用してポータブルコードを作成できます。

このガイドでは、通常のメッセージングミドルウェア、特にJava Message Serviceについて説明します。 ここでは、JMSの詳細、およびメッセージングやjBroker® MQ製品の特別な利点について説明します。 これらの概念についてすでに精通している場合、jBroker MQにより提供されている機能の概念について説明する最後のセクションは読まなくても構いません。 また、Javaプログラミングのを使用してjBroker MQについて詳しく説明するチュートリアルから始めることもできます。

ミドルウェア

インターネットにより、eコマースに関連するビジネスの機会が大きく増えました。 eコマースではより直接的に顧客と対話でき、取引規模の拡大につなげることができますが、このペースが速く活動的な環境に携わる企業は、次のようなコンピュータシステムの問題に直面しています。

新しいハードウェアや特別なソフトウェアによりソリューションを導入することもできますが、ソリューションがビジネスの成長に追い付けないということもしばしばあります。 そのため、インターネットベースアプリケーションの従来の2層クライアント/サーバモデルは、次のような複数層で構成されるアーキテクチャに代わりつつあります。

中間層のシステムにより、次のようなビジネスソリューションやサービスが提供されます。

Javaアプリケーションを作成する開発者のために、企業Java APIは、これらのサービスにアクセスできるように標準化されています。 ミドルウェアは、上位および下位層で実行するアプリケーションと柔軟に連結していて、企業のすべてのコンポーネントにアクセスできます。

柔軟な連結によりミドルウェアを他の層で発生したハードウェアまたはアプリケーションの障害と分離することができるため、高い信頼性を実現できます。 ネットワークを通じて多くのコンピュータで実行されているプロセスをリンクするサービスを提供することで、ミドウェアは既存のソフトウェアおよびハードウェアの機能を利用します。

メッセージ指向ミドルウェア

メッセージ指向ミドルウェア(MOM)は、異種アプリケーションを接続する特殊なミドルウェアです。 MOMアプリケーションの特徴は、次のとおりです。

MOMコンポーネントは、企業環境内でメッセージを非同期に作成、送信、受信するアプリケーションに、信頼できるメカニズを提供します。 メッセージングにより提供される利点をさらに詳しく説明するため、リモートプロシージャコール(RPC)などの従来の同期通信と非同期通信との違いについて説明します。

同期通信

同期通信は、従来のクライアント/サーバモデルにおけるクライアントとサーバの間で行われます。 これらは両方とも参加可能であり、次の要求を処理する前にメッセージの受信を確認する必要があります。 また、トラフィック量が増加すると必要な帯域幅も増加するため、ハードウェアの増設がすぐに必要になります。

同期通信では両者が実行中で、着信要求を処理できる状態にあることが必要なため、ハードウェア、ソフトウェア、およびネットワークの障害による影響を受けやすくなります。 そのような場合における現実的な問題は、障害によりまったく応答できなくなるのではなく、応答速度が遅くなるだけになるように、さまざまなエラー状況に対処できる十分なロジックをアプリケーションに実装する必要があるということです。

非同期通信

サーバとクライアントは対等で、メッセージを自由に送受信できます。 RPCとは異なり、非同期通信では、メッセージをリアルタイムで確認する必要がないため、エージェントは、メッセージの送信後作業を続けることができます。 これは、クライアントとサーバ間に中間層として機能するサービスを置くことで実現されます。

実際の操作では、非同期通信の場合モバイルまたはポータブルPCのスイッチを切ったり、再びログオンするときに最後に接続していた時点から送信されたメッセージを受信したりできます。 また、コンポーネントの障害が発生した場合でも大きな損害にはならず、多少不都合になるだけで済みます。メッセージが遅延する可能性がありますが、失われることはありません。

中間層を使用するもう1つの利点は、メッセージ送信者は、メッセージ受信者と平行して実行する必要がないということです。 たとえば、メッセージ送信者が不定期にメッセージを送信する一方で、受信者は自由なペースで連続的にメッセージを消費できます。 このような場合、メッセージミドルウェアは2つのピア間のバッファのような働きをします。

同期通信と非同期通信の大きな違いは、メッセージ確認部分にあります。 同期要求が正常に返される場合、クライアントはすぐにサーバが要求を実行したことを認識します。 メッセージングでは、送信者は、要求がいつ処理されるかは分かりません。 処理は、メッセージングミドルウェアの信頼性に左右されます。

非同期モデルには、主にパブリッシュ/サブスクライブ(Pub/Sub)およびポイントツーポイント(P2P)の2種類あります。 Pub/Subの場合、メッセージは1つのパブリッシャから複数のサブスクライバにブロードキャストされます。 P2Pの場合、メッセージは1つの送信者から1つの特定の受信者に送信されます。 2つのモデルには共通する箇所はありますが、通常、そのアプリケーションセットは異なります。

従来のMOMシステムは、これらのモデルの一方だけをサポートしていただけでなく、専用かつ複雑で値段も高く、ベンダによる規制も厳しいものでした。 ミドルウェアスペースの標準化は長い間必要とされてきましたが、Javaが中間層の標準言語になり、Java 2 Enterprise Edition (J2EE)プラットフォームで実現されました。

J2EEプラットフォーム

J2EEプラットフォームは、次のような、標準のシステムサービスおよびメカニズムを提供します。

これらのサービスは水平的なサービスで、特定の産業を対象にしていません。 銀行、保険、または電気通信などアプリケーションに関係なく、大規模な分散アプリケーションでは、このようなシステムサービスが必要です。

プラットフォームにおける共通のシステムサービスの機能性により、アプリケーション開発者に一般的なタスクを実行するための標準フレームワークが提供されるだけでなく、低レベルでエラーが起こりやすいコードを記述する必要がなくなります。 J2EEプラットフォームは、次のAPIスイートで構成されます。

EJB (Enterprise Java Beans)

Enterprise Java Beans (EJB)は、Javaサーバ作成用のコンポーネントモデルを提供します。 EJBモデルでは、次のような基礎となるシステムサービスのフレームワークを利用できます。

また、EJBモデルではシステムのさまざまなコンポーネントとの通信が定義され、EJBコンテナ内の処理がサポートされています。 EJBには低レベルな機能がすでに実装されているため、開発者はビジネスソリューションの開発に集中できます。

EJBを他のコンポーネントとともにサーバに配備して、ビジネス機能をカスタマイズできます。 EJBコンポーネントはJavaクラスであるため、任意のEJB準拠サーバ上で実行して他のJava APIと通信できます。 EJBは、次の3種類のビーンを定義します。

セッションBeanは、1つのクライアントに関連付けられ、通常、持続的ではありません。 エンティティBeanは持続的で、通常、データベース操作と関連付けられます。 メッセージ駆動型Bean(MDB)は、EJB 2.0仕様の新しいビーンで、要求を非同期に受信できます。 MDBは、JMSを使用して作成されます。

JNDI (Java Naming and Directory Interface)

JNDI (Java Naming and Directory Interface)は、ネーミングおよびディレクトリ機能をJavaアプリケーションに提供します。 JNDIではさまざまなオブジェクトを保存、ナビゲート、および取り出すことができるファイルシステムに類似した階層構造がサポートされます。 オブジェクトの例として、EJB、JDBCデータソース、JMS宛先などがあります。

JNDIは単なるAPIなので、通常、LDAP、NIS、またはDNSなど既存のネーミングサービスにより支援されます。 また、JNDIを使用して、CORBA CosNamingサービスと通信することもできます。 Javaアプリケーション開発者は、最終的に使用するネーミングサービスのタイプに関係なく、同じJNDI APIを使用してコードを作成できます。

JDBC (Java Database Connectivity)

JDBC (Java Database Connectivity)を使用すると、Javaアプリケーションから広範囲のリレーショナルデータベースにアクセスできます。 データベースには、アプリケーションで使用できるようにデータが効率的に保存されます。 また、データベースを管理して、セキュリティおよびバックアップ機能を提供することもできます。

JDBC APIを使用すると、アプリケーションプログラマは、データベースとのネットワーク接続を簡単に管理できます。 データベースのコマンドはSQL (Simple Query Language)を使用して記述され、Javaプログラムに組み込まれます。これにより、プログラムはさまざまなデータベースベンダ間で利用できます。

JMS (Java Message Service)

Java Message Service (JMS)は、Javaプログラミング言語からメッセージングミドルウェアシステムにアクセスするための標準APIを提供します。 JMSには共通のモデルやボキャブラリが提供されておりメッセージングシステムをより短い期間で学習できるため、JMSは重要なAPIです。

前に説明したとおり、JMSはメッセージ駆動型Beanの基礎となるため、J2EEモデルに不可欠なコンポーネントでもあります。 MDBでは、コンテナによりビーンとJMSの宛先との接続が管理されるので、メッセージングプログラミングをより簡単に行うことができます。 このガイドの次の2つのセクションで、JMSをより詳しく説明します。

トランザクション

JTS (Java Transaction Service)およびJTA (Java Transaction API)は、Javaアプリケーションを分散トランザクションで使用する標準的な方法を提供します。 分散トランザクションでは、いくつかの個々の操作が1つの最小の作業単位にグループ化されます。この作業単位では次のACIDの特性がサポートされています。

ACIDプロパティは、2段階コミットプロトコル(2PC)を使用して分散トランザクションを制御することで、実行されます。 2PCプロトコルは、リソースコーディネータ(トランザクションマネージャ)と呼ばれるミドルウェアで制御されます。 リソースコーディネータは、次のアクションを実行することで2段階コミットを制御します。

  1. 最初に、トランザクション内のすべてのリソースの準備が要求されます。 リソースが準備されると、トランザクションの処理を開始し、完了する準備ができたことになります。 いずれかのリソースが準備できないと、トランザクションは中断(ロールバック)します。
  2. 第1段階が成功し、すべてのリソースが準備されると、第2段階が開始されます。 ここでは、すべてのリソースをコミットするよう要求されます。 リソースコーディネータは、すべてのリソースが成功するまでコミットを呼び出します。

J2EE Connectorアーキテクチャ

J2EE (Connector)アーキテクチャは、既存のエンタプライズ情報システム(EIS)をJ2EEに統合する標準フレームワークを提供します。 この標準フレームワークは、サーブレットおよびEJBがこれらのシステムにどのようにアクセスするかを標準化するだけでなく、このようなシステムがJ2EEプラットフォームを利用することでWebに対応できるようになります。

コネクタアーキテクチャを使用して、EISベンダーは、プラグインして、アプリケーションサーバにより制御できる、システムのリソースアダプタを提供します。 このリソースアダプタを使用すると、セキュリティおよびトランザクションコンテキストを正しく伝達できます。また、アプリケーション開発者は、このようなリソースと通信するための特定の低レベルコードを作成する必要がなくなります。

CORBA (Common Object Request Broker Architecture)

CORBA (Common Object Request Broker Architecture)は、分散および異種オブジェクトシステムの完全なプログラミング環境です。オブジェクトシステムには、オブジェクトモデル、ワイヤプロトコル(IIOP)、クライアント/サーバプログラミング言語API、およびネーミング、セキュリティ、トランザクションなどの標準システムサービスが含まれます。

J2EEプラットフォームは、ビームと別のビームとの通信にRMI/IIOPプロトコルを要求することで、CORBAをサポートしています。 クライアントからサーバへのトランザクションおよびセキュリティコンテキストフローを記述する標準ワイヤプロトコルは、異なるベンダーにより提供されるコンテナ内のビーン間で完全な相互運用を実現します。

JSP (Java Server Pages)

JSP (Java Server Pages)テクノロジを使用すると、Javaプログラマは、JavaコードをWebページに直接組み込むことができます。 Javaコードは、特別なタグを使用して、HTMLファイルに組み込まれます。 JSPは、サーブレットテクノロジとは対称的に、表示する前にクライアントでコンパイルする必要があります。

JSPは、より多くの情報を組み込むことでWebページをより洗練されたものにする場合に使用されます。 すべてのJ2EEテクノロジと同様に、主要となる利点は、JSPは、「Write Once, Run AnywhereTM」をサポートすることで、APIをサポートする任意のプラットフォームで実行できるようJavaアプリケーションであるということです。

サーブレット

(サーブレット) APIは、アプリケーション開発者にWebサーバの機能を拡張するためのメカニズムを提供します。 サーブレットは基本的に、クライアントアプリケーションにより発行されたHTTP POSTおよびGETコマンドを実行するJavaプログラムです。 最も一般的なクライアントアプリケーションはブラウザです。

サーブレットは通常、Webページにコンテキスト固有の内容を表示するときに使用されます。 たとえば、サーブレットを使用すると、ユーザに関するさまざまな情報をJDBCから取得することで、Webページをカスタマイズできます。 サーブレットは、アプレットとは異なりサーバで実行するため、ブラウザにダウンロードする必要はありません。

Webサービス

Webサービスは、正式には、J2EEプラットフォームの一部ではありませんが、ベンダによってはEJBおよびWebサービスなどのその他のオブジェクトの公開をサポートしています。 Webサービスは、標準のインターネットプロトコルを使用してアクセスできる1つのビジネス機能を表します。 Webサービスは、サービスが受け取り、生成するメッセージを記述するXMLドキュメントを使用して定義されます。

WebサービスのXMLは、WSDL標準に準拠しています。 Webサービスのインタフェースは、その実装から独立しているので、Webサービスのユーザおよびプロバイダは、Webサービスインタフェースで定義されているメッセージを生成、消費できる任意のプラットフォームおよびプログラミング言語を使用できます。

Webサービスを使用すると、ビジネスアプリケーションは、HTTP、SOAP、およびMIMEを含む、さまざまなWebプロトコルを介して情報を交換できます。 メッセージ交換用のデータフォーマットはXMLなので、本当の異種インターネット規模のB2Bアプリケーションを実現できます。 SOAPやWSDLのほかに、Webサービスは通常、UDDIebXMLなどのインターネットレジストリに関連付けられます。


Copyright © 1998-2003, Novell, Inc. All rights reserved.