ここでは、XMPPサービスを開始する際に用意しなければいけないデータの設計について解説していきます。
まず、データベースの種類を大きく二つにわけることが出来ます。一つは、既にWebサービスなどで利用するために運用されているユーザーデータの管理するテーブルや、ユーザー同士の関係性を管理するテーブルです。
次に、XMPPサービスを開始するにあたり、新たに用意しなければならないテーブルがあります。コネクション管理のテーブルや、プレゼンス管理のテーブルなどがそれにあたります。
ユーザーに関するマスタテーブルです。
ユーザー間の関係性を表すテーブルです。
類似したデータベースを既に持っているようなWebサービスと連携させることを前提としています。
次に、XMPPサービスをこれから始めるにあたって、新たに用意しなければならないデータベースについて説明します。
データベースを用意する前に決めておかなければならない事があります。
まずユーザーのJIDをどのように扱うかをあらかじめ決めておきます。例を見てみましょう
taro@xmpp.example.com/12df8e3c90deaab9f87b
まず、上の例でxmpp.example.comになっているドメインパートはコンフィグで指定したdomainの値を使うことになります。詳しくはコンフィギュレーション [ サーバーセクション ]を参照して下さい。
上の例で12df8e3c90deaab9f87bになっているのはリソースです。リソースについてはプロトコルガイド - クライアント/サーバー間のやりとり [ JID ]や、プロトコルガイド - ログインからログアウトまでのケーススタディ [ リソースバインディング ]を参照するとよいでしょう。
Oceanでは、セッションIDとしてランダムな文字列をリソースとして利用するという方針になっています。ハンドラドキュメントの実装例なども参照するとよいでしょう。
あとは、上のJIDの例でtaroになっている部分。JIDのローカルパートです。この値をどうするかを決定しなければなりません。
Webサービス側のユーザー管理テーブルで、上の例に挙げたtaroのような、サービス内でユニークな文字列を利用している場合は、それを利用できます。しかしアルファベット文字列でユーザーを管理していない場合も考えられます。一例として、ユニークな数値IDと、重複可能なニックネームを利用しているケースが考えられます。ユーザー名が重複可能なニックネームで表現されているサービスでは、特定のユーザーを識別することができなくなってしまうので、ローカルパートにその名前を使うことが出来ません。なので次のように数値IDをローカルパートに利用することになるでしょう。
123456789@xmpp.example.com/12df8e3c90deaab9f87b
人間の目から見ると、わかりにくいIDになってしまったように見えます。しかし、クライアント/サーバー間のやりとり [ JID ] で説明した通り、クライアントアプリケーションはロスター内で指定された名前や、vCardを利用して取得したニックネーム(とプロフィール画像)を利用して、ユーザーのプレゼンス表示を行うのが一般的であり、JIDがセマンティックである必要はありません。
vCard拡張について詳しくは、拡張ガイド [ vCard ] を参照して下さい。
vCard拡張で紹介したような画像データのBase64や、sha1ハッシュをどのように提供するかを考えなくてはなりません
vCard拡張について詳しくは、プロトコルガイド - 拡張 [ vCard ]を参照して下さい。
これらのデータベースは、XMPPサービス起動中のみ、永続性が保証される必要があります。つまり、XMPPサービスを再起動するときなどは、一度データベース自体作り直してしまってもよいわけです。ただし、XMPPサービス起動中は揮発してはならないので、キャッシュサーバーのような揮発性のあるストレージを、この目的のために利用してはいけません。ただし、image_storeに関しては、元の画像バイナリの永続性が保証されていれば、Base64やsha1ハッシュに関してはキャッシュサーバーを利用してもよいでしょう。