この章では、さまざまな Instant Messaging アーキテクチャーについて説明します。インストールする必要のあるコンポーネントは、個々の配備ごとに異なります。たとえば、電子メール通知をサポートする場合は、SMTP サーバーをインストールする必要があります。電子メール通知をサポートしない場合は、SMTP サーバーをインストールしないでください。
Instant Messaging と相互運用するコンポーネントの詳細については、「Instant Messaging の関連コンポーネント」を参照してください。
この章には、次の節があります。
現在、Solaris プラットフォームではすべての配備オプションが利用できます。Linux および Windows オペレーティングシステムでは一部の配備オプションが利用できません。
図 23–1 は、Instant Messaging の基本アーキテクチャーを示したものです。
この Instant Messaging 基本アーキテクチャーでは、チャット、ニュースアラート、会議室などの機能が提供されます。この基本機能を利用するには、次のコンポーネントをインストールする必要があります。
Instant Messaging サーバーと 1 つ以上の Instant Messaging マルチプレクサ
Instant Messaging リソース
Sun Java System Web Server などの Web サーバー
Sun Java System Directory Server などの LDAP サーバー
この例では、次のようにします。
認証と検索用のユーザーエントリは LDAP サーバーに保持されます。
クライアントは Web サーバーまたは Sun Java System Application Server から Instant Messaging リソースをダウンロードします。
クライアントは常に Instant Messaging マルチプレクサ経由で Instant Messaging サーバーに接続します。
図 23–2 は、Instant Messaging の基本アーキテクチャーで行われる認証プロセスで、ソフトウェアコンポーネントがどのように連携するかを示しています。認証要求のフローに注目しています。このプロセスの各段階の説明は、図の後に記載しています。
基本アーキテクチャーにおける認証プロセスは、次のように処理されます。
エンドユーザーはブラウザから Instant Messenger アプレット URL にアクセスし、クライアントを呼び出すメソッドを選択します。
Java Web Start または Java プラグインは、適切な Instant Messenger リソースファイルをダウンロードし、Instant Messenger を起動します。
ログインウィンドウが表示され、エンドユーザーはログイン名とパスワードを入力します。ログインデータはマルチプレクサ経由で Instant Messaging サーバーに送信されます。
Instant Messaging サーバーは LDAP サーバーと通信してエンドユーザーを認証し、連絡先リストやその登録情報などのエンドユーザー情報を要求します。
エンドユーザーの認証が完了すると、Instant Messaging のメインウィンドウが表示され、そのエンドユーザーの連絡先リストが表示されます。これにより、エンドユーザーは他のエンドユーザーとの Instant Messaging セッションに参加できるようになります。
オフラインユーザーへの電子メール通知とユーザーへのカレンダの予定の Instant Messaging ベース通知をサポートするように、Instant Messaging を配備することができます。
電子メール通知とカレンダアラートをサポートする Instant Messaging アーキテクチャー は、「Instant Messaging の基本アーキテクチャー」と同じ機能を提供します。この機能を提供するには、「Instant Messaging の基本アーキテクチャー」に記載されたコンポーネントを含める必要があります。電子メールアラートをサポートするには、Sun Java System Messaging Server などの SMTP サーバーもインストールする必要があります。カレンダアラートをサポートするには、Sun Java System Calendar Server もインストールする必要があります。
電子メール通知を有効にする場合、Instant Messaging のインストール時に使用する SMTP サーバーの指定が必要となります。SMTP サーバーがインストールされていない場合は、Instant Messaging ソフトウェアのインストール前にインストールを完了する必要があります。図 23–3 は、ネットワーク経由の電子メール通知に対応した Instant Messaging を示しています。
Calendar Server がインストールされていない場合は、Instant Messaging ソフトウェアのインストール前にインストールを完了する必要があります。図 23–4 は、ネットワーク経由のカレンダ通知に対応した Instant Messaging を示しています。
このアーキテクチャーの認証フローは基本配備と同じです。詳細については、「基本アーキテクチャーにおける認証」を参照してください。
この例では、次のようにします。
認証と検索用のユーザーエントリは LDAP サーバーに保持されます。
Instant Messaging サーバーは、オフラインユーザー宛てのメッセージを SMTP サーバーへ転送します。SMTP サーバーは、そのメッセージを電子メールとしてユーザーのメールボックスに送信します。
クライアントは Web サーバー (またはアプリケーションサーバー) から Instant Messaging リソースをダウンロードします。
クライアントは常に Instant Messaging マルチプレクサ経由で Instant Messaging サーバーに接続します。
この例では、次のように動作します。
認証と検索用のユーザーエントリは LDAP サーバーに保持されます。
ENS (Event Notification Server) がカレンダの予定の通知を Instant Messaging サーバーに送信し、そこから適切なエンドユーザーに通知が転送されます。
クライアントは Web サーバー (またはアプリケーションサーバー) から Instant Messaging リソースをダウンロードします。
クライアントは常に Instant Messaging マルチプレクサ経由で Instant Messaging サーバーに接続します。
Access Manager のポリシー機能とシングルサインオン (SSO) を使用するように Instant Messaging を配備することができます。Access Manager を使用する Instant Messaging アーキテクチャーは、「Instant Messaging の基本アーキテクチャー」と同じ機能を提供します。この機能を利用するには、「Instant Messaging の基本アーキテクチャー」に記載されたコンポーネントのほかに、Access Manager もインストールする必要があります。さらに、Instant Messaging サーバーホスト上に Access Manager SDK をインストールする必要があります。
このアーキテクチャーの場合、Instant Messaging はユーザーの検索にディレクトリを使用しますが、ユーザーの認証または承認には使用しません。ユーザーの認証と承認は Access Manager 側で行われます。
Access Manager で SSO を使用する場合、Access Manager と Instant Messaging が同じ Web コンテナを使用するように構成する必要があります。
図 23–5 は、Access Manager を使用する Instant Messaging アーキテクチャーを示しています。
この例では、次のように動作します。
ユーザーエントリは LDAP サーバーに保持されます。
Web サーバー (または Web サーバーが組み込まれたアプリケーションサーバー) は、ブラウザ経由でクライアントに Instant Messaging リソースをダウンロードします。リソースは、基本的にはクライアントです。
クライアントは常にマルチプレクサ経由で接続します。
Access Manager が提供する Instant Messaging 関連サービスには、在席確認サービスとインスタントメッセージングサービスがあります。
Instant Messaging 配備で ID ベースのサービスを管理する Access Manager 管理インタフェースには、Web サーバーを使用してアクセスすることができます。Access Manager の Web サーバーは、Instant Messaging リソースのサーバーと同じであってもかまいません。詳細については、Access Manager のマニュアルを参照してください。
Access Manager SDK は、Instant Messaging サーバーが Access Manager との通信時に使用する API を提供します。
図 23–6 は、シングルサインオン環境において、コンポーネント Portal Server および Access Manager と連携する Instant Messaging ソフトウェアによって使用される認証プロセスを示したものです。図 23–2 と同様に、この図も認証要求のフローを示しています。このプロセスの各段階の説明は、図の後に記載しています。
シングルサインオン環境において、この配備の Instant Messaging サーバーの認証プロセスは、次のように機能します。
ユーザーは、Web ブラウザに適切な URL を入力し、Access Manager にログインします。
Access Manager ソフトウェアはエンドユーザーを認証し、セッショントークンを返します。
シングルサインオンが機能するには、セッショントークンが必要です。このトークンはアプレットパラメータとして提供され、認証プロセス全体で使用されます。セッショントークンがある限り、資格の再入力はエンドユーザーに求められません。
エンドユーザーはブラウザから Instant Messenger アプレットにアクセスし、クライアントを呼び出すメソッドを選択します。
Java Web Start または Java プラグインは、適切な Instant Messenger リソースファイルをダウンロードし、Instant Messenger を起動します。
Instant Messenger は、セッショントークンを使用して Instant Messaging サーバーへの認証を要求します。
Instant Messaging サーバーは、セッショントークンの検証を Access Manager に求めます。セッションが有効であれば、Instant Messenger はエンドユーザーの連絡先リストを表示し、エンドユーザーはチャット、アラート、ポーリングなどの Instant Messenger サービスを利用できるようになります。
Instant Messaging サーバーは、連絡先リストやその登録情報などのエンドユーザー情報を取得または設定するときに、LDAP に直接照会する必要があります。
メッセージアーカイブをサポートするとともに Instant Messaging がセキュリティー保護されたモードで実行されるように、Instant Messaging を配備することができます。この機能を提供する Instant Messaging アーキテクチャーは、「Instant Messaging の基本アーキテクチャー」と同じ機能も提供します。また、Portal Server デスクトップによりエンドユーザーは Instant Messenger クライアントを利用することができます。この機能を利用するには、「Instant Messaging の基本アーキテクチャー」に記載されたコンポーネントのほかに、Portal Server と Access Manager もインストールする必要があります。
このアーキテクチャーでは、Access Manager がアクセスするディレクトリと Web サーバーが使用されます。これらのサーバーの追加インスタンスをインストールする必要はありません。また、Access Manager が必要となるこのアーキテクチャーでは、「Access Manager または SSO を使用する Instant Messaging アーキテクチャー」で説明したすべての機能も利用できます。
図 23–7 は、ポータルベース Instant Messaging アーキテクチャーを示したものです。
この例では、次のようにします。
ユーザーエントリは LDAP サーバーに保持されます。
Web サーバー (または Web サーバーが組み込まれたアプリケーションサーバー) は、ブラウザ経由でクライアントに Instant Messaging リソースをダウンロードします。リソースは、基本的にはクライアントです。
Instant Messaging クライアントは常にマルチプレクサ経由で接続します。
Access Manager が提供する Instant Messaging 関連サービスには、在席確認サービスとインスタントメッセージングサービスがあります。
Instant Messaging 配備で ID ベースのサービスを管理する Access Manager 管理インタフェースには、Web サーバーを使用してアクセスすることができます。Access Manager と Portal Server の両方に対する Web サーバーは、Instant Messaging リソースのサーバーと同じであってもかまいません。詳細については、Sun Java System Access Manager と Sun Java System Portal Server のマニュアルを参照してください。
Access Manager SDK は、Instant Messaging サーバーが Access Manager との通信時に使用する API を提供します。
Portal Server は Instant Messaging チャネルをサポートし、ユーザーは Portal デスクトップから Instant Messenger にアクセスできます。
Portal Server は、この配備で送信されるインスタントメッセージを保存するためのアーカイブ機能を提供します。
図 23–8 は、シングルサインオン環境において、Portal Server および Access Manager と連携する Instant Messaging ソフトウェアによって使用される認証プロセスを示したものです。図 23–2 と同様に、この図も認証要求のフローを示しています。このプロセスの各段階の説明は、図の後に記載しています。
シングルサインオン環境において、この配備の Instant Messaging サーバーの認証プロセスは、次のように機能します。
ユーザーは、Web ブラウザに適切な URL を入力し、Portal Server にログインします。
Access Manager ソフトウェアはエンドユーザーを認証し、セッショントークンを返します。Portal Server によりエンドユーザーはデスクトップをダウンロードすることができます。Portal Server デスクトップは、エンドユーザーのブラウザに表示されます。セッショントークンの説明については、手順 6 を参照してください。
エンドユーザーは、デスクトップの Instant Messaging チャネルで Instant Messenger URL リンクをクリックします。
Java Web Start または Java プラグインは、適切な Instant Messenger リソースファイルをダウンロードし、Instant Messenger を起動します。
Instant Messenger は、セッショントークンを使用して Instant Messaging サーバーへの認証を要求します。
シングルサインオンが機能するには、セッショントークンが必要です。このトークンはアプレットパラメータとして提供され、認証プロセス全体で使用されます。セッショントークンがある限り、資格の再入力はエンドユーザーに求められません。
Instant Messaging サーバーは、セッショントークンの検証を Access Manager に求めます。セッションが有効であれば、Instant Messenger はエンドユーザーの連絡先リストを表示し、エンドユーザーはチャット、アラート、ポーリングなどの Instant Messenger サービスを利用できるようになります。
Instant Messaging サーバーは、連絡先リストやその登録情報などのエンドユーザー情報を取得または設定するときに、LDAP に直接照会する必要があります。
Instant Messaging を配備し、この節で説明してきたすべての機能を有効にするには、次のようにします。
Instant Messaging をインストールする前に次のコンポーネントをインストールします。
Directory Server (Access Manager インストール時)
Web Server (Access Manager インストール時)
Access Manager
Portal Server
Calendar Server
Messaging Server
Instant Messaging リソースを Web Server ホストにインストールします。
Access Manager SDK を Instant Messaging サーバーホストにインストールします。
また、Access Manager ホスト上で Access Manager Instant Messaging サービスを設定する必要もあります。
ここでは、「Instant Messaging の基本アーキテクチャー」で説明した配備シナリオのバリエーションを説明します。たとえば、必要となる各種サーバーおよびコンポーネントを次の物理構成にインストールすることができます。
上記の一部またはすべての組み合わせ
これらのバリエーションは、この章で説明したすべてのアーキテクチャーに適用できます。配備要件に合わせて選択してください。
図 23–9 は、Instant Messaging サーバーとマルチプレクサが同一ホスト上にインストールされる構成を示したものです。Web サーバーは別ホスト上にインストールされます。Web サーバーホストには、Instant Messaging リソースも格納されます。Web サーバーと LDAP サーバーのインスタンスがすでに存在し、これらのホストに他のアプリケーションをインストールしない場合は、この構成を採用します。
図 23–10 は、2 つのマルチプレクサが 2 つの異なるホスト上にインストールされる構成を示したものです。Instant Messaging サーバーは別のホスト上にインストールされます。この構成では、企業のファイアウォールの外にマルチプレクサを置くことができます。複数のホストにマルチプレクサをインストールすると、Instant Messaging サーバーの負荷は複数のシステムに分散されます。
マルチプレクサはリソースを大量に消費する場合があるので、別のホストに置くことでシステム全体のパフォーマンスを向上させることができます。
Windows 環境では、1 つのホストでサポートされるマルチプレクサは 1 つだけです。
図 23–11 は、2 つの Instant Messaging サーバーによる構成を示しています。この構成は、管理ドメインが複数ある場合に採用されます。Instant Messaging サーバーの各ホストでは、一方の Instant Messaging サーバーのエンドユーザーが、もう一方の Instant Messaging サーバーのエンドユーザーと通信できるようにサーバーを設定する必要があります。