test

Sun Java System Communications Services 6 2005Q4 配備計画ガイド

第 23 章 Instant Messaging アーキテクチャーの開発

この章では、さまざまな Instant Messaging アーキテクチャーについて説明します。インストールする必要のあるコンポーネントは、個々の配備ごとに異なります。たとえば、電子メール通知をサポートする場合は、SMTP サーバーをインストールする必要があります。電子メール通知をサポートしない場合は、SMTP サーバーをインストールしないでください。

Instant Messaging と相互運用するコンポーネントの詳細については、「Instant Messaging の関連コンポーネント」を参照してください。

この章には、次の節があります。

注 –

現在、Solaris プラットフォームではすべての配備オプションが利用できます。Linux および Windows オペレーティングシステムでは一部の配備オプションが利用できません。

Instant Messaging の基本アーキテクチャー

図 23–1 は、Instant Messaging の基本アーキテクチャーを示したものです。

図 23–1 Instant Messaging の基本アーキテクチャー

この図は、Instant Messaging の基本配備におけるコンポーネント間の関係を示しています。

この Instant Messaging 基本アーキテクチャーでは、チャット、ニュースアラート、会議室などの機能が提供されます。この基本機能を利用するには、次のコンポーネントをインストールする必要があります。

この例では、次のようにします。

基本アーキテクチャーにおける認証

図 23–2 は、Instant Messaging の基本アーキテクチャーで行われる認証プロセスで、ソフトウェアコンポーネントがどのように連携するかを示しています。認証要求のフローに注目しています。このプロセスの各段階の説明は、図の後に記載しています。

図 23–2 Instant Messaging の基本アーキテクチャーにおける認証要求のフロー

この図は、LDAP のみの Instant Messaging サーバー構成の認証プロセスにおける認証要求のフローを示しています。

基本アーキテクチャーにおける認証プロセスは、次のように処理されます。

  1. エンドユーザーはブラウザから Instant Messenger アプレット URL にアクセスし、クライアントを呼び出すメソッドを選択します。

  2. ブラウザが Java Web Start または Java プラグインを起動します。

  3. Java Web Start または Java プラグインは、適切な Instant Messenger リソースファイルをダウンロードし、Instant Messenger を起動します。

  4. ログインウィンドウが表示され、エンドユーザーはログイン名とパスワードを入力します。ログインデータはマルチプレクサ経由で Instant Messaging サーバーに送信されます。

  5. Instant Messaging サーバーは LDAP サーバーと通信してエンドユーザーを認証し、連絡先リストやその登録情報などのエンドユーザー情報を要求します。

エンドユーザーの認証が完了すると、Instant Messaging のメインウィンドウが表示され、そのエンドユーザーの連絡先リストが表示されます。これにより、エンドユーザーは他のエンドユーザーとの 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 を示しています。

このアーキテクチャーの認証フローは基本配備と同じです。詳細については、「基本アーキテクチャーにおける認証」を参照してください。

図 23–3 電子メール通知を使用する Instant Messaging アーキテクチャー

この図は、電子メール通知が有効な Instant Messaging の配備におけるコンポーネント間の関係を示しています。

この例では、次のようにします。

図 23–4 カレンダアラートを使用する Instant Messaging アーキテクチャー

この図は、カレンダの予定通知が有効な Instant Messaging の配備におけるコンポーネント間の関係を示しています。

この例では、次のように動作します。

Access Manager または SSO を使用する 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 アーキテクチャーを示しています。

図 23–5 Access Manager ベースのサーバーポリシー管理またはシングルサインオンを使用する Instant Messaging アーキテクチャー

この図は、Access Manager を使用する Instant Messaging 配備におけるコンポーネント間の関係を示しています。

この例では、次のように動作します。

Access Manager のみを使用するアーキテクチャーにおける認証

図 23–6 は、シングルサインオン環境において、コンポーネント Portal Server および Access Manager と連携する Instant Messaging ソフトウェアによって使用される認証プロセスを示したものです。図 23–2 と同様に、この図も認証要求のフローを示しています。このプロセスの各段階の説明は、図の後に記載しています。

図 23–6 Access Manager を伴う構成での認証要求のフロー

この図は、Instant Messaging アーカイブコンポーネントとデータフローを示しています。

シングルサインオン環境において、この配備の Instant Messaging サーバーの認証プロセスは、次のように機能します。

  1. ユーザーは、Web ブラウザに適切な URL を入力し、Access Manager にログインします。

  2. Access Manager ソフトウェアはエンドユーザーを認証し、セッショントークンを返します。

    シングルサインオンが機能するには、セッショントークンが必要です。このトークンはアプレットパラメータとして提供され、認証プロセス全体で使用されます。セッショントークンがある限り、資格の再入力はエンドユーザーに求められません。

  3. エンドユーザーはブラウザから Instant Messenger アプレットにアクセスし、クライアントを呼び出すメソッドを選択します。

  4. ブラウザが Java Web Start または Java プラグインを起動します。

  5. Java Web Start または Java プラグインは、適切な Instant Messenger リソースファイルをダウンロードし、Instant Messenger を起動します。

  6. Instant Messenger は、セッショントークンを使用して Instant Messaging サーバーへの認証を要求します。

  7. Instant Messaging サーバーは、セッショントークンの検証を Access Manager に求めます。セッションが有効であれば、Instant Messenger はエンドユーザーの連絡先リストを表示し、エンドユーザーはチャット、アラート、ポーリングなどの Instant Messenger サービスを利用できるようになります。

  8. Instant Messaging サーバーは、連絡先リストやその登録情報などのエンドユーザー情報を取得または設定するときに、LDAP に直接照会する必要があります。

ポータルベースまたはアーカイブを使用する Instant Messaging アーキテクチャー

メッセージアーカイブをサポートするとともに 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 アーキテクチャーを示したものです。

図 23–7 ポータルベースのセキュリティー保護されたモードまたはアーカイブを使用する Instant Messaging アーキテクチャー

この図は、Instant Messaging アーカイブコンポーネントとデータフローを示しています。

この例では、次のようにします。

Portal Server アーキテクチャーにおける認証

図 23–8 は、シングルサインオン環境において、Portal Server および Access Manager と連携する Instant Messaging ソフトウェアによって使用される認証プロセスを示したものです。図 23–2 と同様に、この図も認証要求のフローを示しています。このプロセスの各段階の説明は、図の後に記載しています。

図 23–8 Portal Server と Access Manager を伴う構成における認証要求のフロー

この図は、Portal Server を組み合わせた Instant Messaging の配備を示しています。

シングルサインオン環境において、この配備の Instant Messaging サーバーの認証プロセスは、次のように機能します。

  1. ユーザーは、Web ブラウザに適切な URL を入力し、Portal Server にログインします。

  2. Access Manager ソフトウェアはエンドユーザーを認証し、セッショントークンを返します。Portal Server によりエンドユーザーはデスクトップをダウンロードすることができます。Portal Server デスクトップは、エンドユーザーのブラウザに表示されます。セッショントークンの説明については、手順 6 を参照してください。

  3. エンドユーザーは、デスクトップの Instant Messaging チャネルで Instant Messenger URL リンクをクリックします。

  4. ブラウザが Java Web Start または Java プラグインを起動します。

  5. Java Web Start または Java プラグインは、適切な Instant Messenger リソースファイルをダウンロードし、Instant Messenger を起動します。

  6. Instant Messenger は、セッショントークンを使用して Instant Messaging サーバーへの認証を要求します。

    シングルサインオンが機能するには、セッショントークンが必要です。このトークンはアプレットパラメータとして提供され、認証プロセス全体で使用されます。セッショントークンがある限り、資格の再入力はエンドユーザーに求められません。

  7. Instant Messaging サーバーは、セッショントークンの検証を Access Manager に求めます。セッションが有効であれば、Instant Messenger はエンドユーザーの連絡先リストを表示し、エンドユーザーはチャット、アラート、ポーリングなどの Instant Messenger サービスを利用できるようになります。

  8. Instant Messaging サーバーは、連絡先リストやその登録情報などのエンドユーザー情報を取得または設定するときに、LDAP に直接照会する必要があります。

すべての機能が有効な Instant Messaging

Instant Messaging を配備し、この節で説明してきたすべての機能を有効にするには、次のようにします。

また、Access Manager ホスト上で Access Manager Instant Messaging サービスを設定する必要もあります。

Instant Messaging の物理的な配備例

ここでは、「Instant Messaging の基本アーキテクチャー」で説明した配備シナリオのバリエーションを説明します。たとえば、必要となる各種サーバーおよびコンポーネントを次の物理構成にインストールすることができます。

これらのバリエーションは、この章で説明したすべてのアーキテクチャーに適用できます。配備要件に合わせて選択してください。

Instant Messaging の物理的な配備例: Web Server を別ホストにインストール

図 23–9 は、Instant Messaging サーバーとマルチプレクサが同一ホスト上にインストールされる構成を示したものです。Web サーバーは別ホスト上にインストールされます。Web サーバーホストには、Instant Messaging リソースも格納されます。Web サーバーと LDAP サーバーのインスタンスがすでに存在し、これらのホストに他のアプリケーションをインストールしない場合は、この構成を採用します。

図 23–9 Web サーバーと Instant Messaging サーバーを別々のホストにインストール

この図は、Web サーバーと Instant Messenger が異なるホストにインストールされることを示しています。

Instant Messaging の物理的な配備例: マルチプレクサを別ホストにインストール

図 23–10 は、2 つのマルチプレクサが 2 つの異なるホスト上にインストールされる構成を示したものです。Instant Messaging サーバーは別のホスト上にインストールされます。この構成では、企業のファイアウォールの外にマルチプレクサを置くことができます。複数のホストにマルチプレクサをインストールすると、Instant Messaging サーバーの負荷は複数のシステムに分散されます。

注 –

マルチプレクサはリソースを大量に消費する場合があるので、別のホストに置くことでシステム全体のパフォーマンスを向上させることができます。

Windows 環境では、1 つのホストでサポートされるマルチプレクサは 1 つだけです。

図 23–10 Instant Messaging マルチプレクサの別ホストへのインストール

この図は、2 つのマルチプレクサが 2 つの異なるホスト上にインストールされ、Instant Messaging サーバーはさらに別のホスト上にインストールされる、複数サーバーの構成を示したものです。

Instant Messaging の物理的な配備例: 複数の Instant Messaging ホスト

図 23–11 は、2 つの Instant Messaging サーバーによる構成を示しています。この構成は、管理ドメインが複数ある場合に採用されます。Instant Messaging サーバーの各ホストでは、一方の Instant Messaging サーバーのエンドユーザーが、もう一方の Instant Messaging サーバーのエンドユーザーと通信できるようにサーバーを設定する必要があります。

図 23–11 複数の Instant Messaging サーバーホスト

この図は、2 つの管理ドメインが存在する環境を示しています。