パーソナルツール
現在の場所: ホーム ブログ DB2 9 を利用したメール・アーカイブ・システムの開発 (1)
« 2018January »
Su Mo Tu We Th Fr Sa
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
このBlogについて
 代表の向井田ことMUKAです。当ブログサイトでは、MAGICやDB2に関する技術者向け情報を公開しています。お気軽にお立ち寄り下さい。
最近のエントリ
twitter / 新RT機能を英語モードで・・・ muka 2009年11月19日
twitter / List Widget muka 2009年11月03日
twitter API / Retweet の仕様が・・・ muka 2009年10月30日
twitter API / Lists muka 2009年10月24日
IBM Rational Software Conference 2009 と アジャイル開発 muka 2009年10月08日
twitter API / geoタグ! muka 2009年10月01日
Twitter Developers Meetup in Tokyo muka 2009年09月11日
Club DB2 2009/9/4 muka 2009年09月05日
最近のコメント
Re:Club DB2 2009/8/29 muka 2009年09月01日
Re:Club DB2 2009/8/29 SIM 2009年08月31日
最近のトラックバック
Club DB2 8/29の感想エントリと今後の予定 Unofficial DB2 BLOG 2009年09月01日
カテゴリ
misc (47)
dbMAGIC (47)
DB2 (47)
mail (47)
Web (47)
twitter (47)
 

DB2 9 を利用したメール・アーカイブ・システムの開発 (1)




はじめに


 9月になり、当社も設立1周年を迎えました。
 これもひとえに、皆様のお陰と感謝しております。
 思えばがむしゃらにやってきたこの一年でしたが、二期目は今まで以上に楽しくやっていけたらと思っております。

 さて、この何ヶ月か密かに新製品の開発を行っているのですが、それが「DB2 9を利用したメール・アーカイブ・システム」です。
 現在、10月のリリースに向けて準備中という段階です。そこで、このページを借りて、その紹介などもしていきたいと思っています。
 今まで私がやってたことを知っている人からはよく、「何故、メールアーカイブなの?」と聞かれるんですが、およそ次のような理由です。

  • メールサーバ製品の開発を行っている会社との協業を考えた。
  • とにかく、「DB2 9」で何か作りたかった。
  • 内部統制などのジャンルで、今後需要の増すことが期待されている?
  • 大掛かりなシステムではないので、小さく早く始められる?
いずれにしても、全く開発経験の無いシステムだったんですが、試行錯誤しながらやってきて、ようやく形が見えてきたという感じですね。
 特に、メールレシーバや、メールデータのXML変換プログラム(後述)は、協業している会社の技術協力を頂くことができたのが大きなポイントで、これらの技術協力を頂けなければ、この製品も完成できなかったことと思います。
 また、「DB2 9」は、他のページでもいろいろ紹介させて頂いていますが、今のところ「我が社の開発テーマ」みたいなものになっています。このメールアーカイブでも大活躍します。特に、NSE(テキスト検索用エンジン、「Net Search Extender」の略)という拡張モジュールは、新たなDB2の世界を見せてくれたという感じです。今後、いろいろと他の分野のアプリケーションにも応用できる機能だと思っています。
 当然ながら、MAGICはV10で開発しています。V10になって、「こんなこともできるようになったんだ!」というようなものが幾つもありまして、それらもあわせてこのページで順次紹介できれば良いなと思っております。




メールアーカイブって?


 そもそも、メールアーカイブって何でしょうか?
 そうですね、簡単に言えば「送受信したメールデータを全てアーカイブ(書庫化)するシステム」のことです。
 送受信したメールというのは、SMTPサーバ(MTA)を経由した送信/受信メールの全てが該当データになります。
 また、書庫化するということは、インデックスが付けられて即座に検索することが可能になるということです。
 このジャンルの製品は最近沢山出ているようです。
 注目されることになったのが、システムセキュリティや内部統制の観点からです。個人情報漏洩の抑止効果も期待されていますし、当然ながらメールデータの保存・検索に便利ですので、単に問題発生時の検索用途だけでなく、データ共有的な機能をつけている製品もあるようです。
 というわけで、メールアーカイブも百花繚乱。製品価格もピンからキリまでいろんな製品があります。
 さて、そんな中で、当メールアーカイブは果たして生きていけるのか・・・。(それは私も良く分かりません。(^^;)
 まぁ、こんなものを作ったんだけど・・・というノリで、順を追って、概要や特長について説明していきたいと思います。



当メールアーカイブの概要



 それでは、順に当メールアーカイブの概要について説明していきましょう。

メールの受信機能

 まず、メールの受信部分についてです。
 この部分は、MTAから転送されたメールを受信して、保存するためのサービスプログラムをバックグランドで実行させることで実現しています。
 この部分を担当しているのが、「KSearch.exe」というモジュールです。その設定画面を示します。

ma_001.jpg

KSARSサービスは任意のポートからメールを受信して格納することが可能です。


 タイムアウト時間や、保存単位、受信フォルダ、サービス監視ポートなどを設定することが可能です。

 ところでレシーバにメールを転送するにはどうすれば良いでしょうか?
 MTA(SMTPサーバ)は、転送機能のあるものであれば、Windows系に限らず任意のものを利用することが可能です。
 下記は、とあるメールサーバ(現e-postメールサーバの前身版)での複写転送と配送先を設定している例です。


ma_002.jpg

ダミーのアドレスを転送先アドレスとして設定します。


ma_003.jpg

ダミーで設定したドメインに対して、配送先サーバとポート番号を指定します。

ただ、上記のような場合は、受信したメールのエンベロープ情報には送信先として常にダミーのメールアドレスが入ってしまいます。(ヘッダ情報の「To」等は問題ありません。)
 これを解決するためには、「Q-Send Server」というe-post製品を使用することで解決が可能です。(いつかの機会にご紹介したいと思います。)

メール書庫化機能

 次に、メールの書庫化についてです。
 メールデータは、1件=1ファイルのXMLデータに変換されます。変換されたXMLデータは、DB2の表に格納されます。
 下の画面は、Mail2XMLという変換プログラムを起動したものです。ダイアログにより対話的に処理を指示することも可能です。が、本システムでは変換とインポート処理をバックグランドで自動的に実行しますので、この画面が表示されることはありません。


ma_004.jpg

メールのXML変換プログラムは単独で起動も可能です。


 メールデータをXMLデータにする利点には、次のようなものがあります。

  • XMLデータベースに格納して、利用が可能になる。
  • メールのエンコードの文字種別(JIS, EUC,UTF-8)によらず、全て同じコード(UTF-8)でアクセスできるようになる。
  • エンベロープ、ヘッダ、ボディ(本文)、添付ファイル(テキスト情報)などの個別の情報について、1つのXMLスキーマを利用してアクセスが可能になる。
  • XMLデータであることによる他の副次的な利点を享受できる(システム連携のデータとして利用する等)

 一番大きいのは、なんと言っても「XMLデータベースに格納できる」ということです。他の利点は付随的なものとすらいえます。
 統一的に文字コードはUTF-8に変換されますが、中にはどうしても文字化け等の理由によりXMLデータでは扱えない文字コードが混入してしまうことがあります。(DB2は結構チェックが厳しいので、そういうデータはインポート時にはじかれてしまいます。)

 下図は、DB2の管理ツールコントロールセンターで表を開いたところです。「MAIL_DATA」というカラムがXMLタイプのカラムです。これ以外にも、いくつかの属性を同じ表のカラムに格納することができるわけです。DB2 9がハイブリッドデータベースと言われる由縁ですね。


ma_005.jpg

XMLタイプのカラムがテーブルに作成されていることが分かります。



 XMLカラムの右脇のボタンをクリックすると、文書ビューアーという画面で、XMLデータの内容を確認することが可能です。
 このXMLカラムを使用することにより、送信者、宛先、件名、本文、その他任意のヘッダ項目を使用したメールの検索を行うことが可能になります。


ma_006.jpg

XMLスキーマの階層構造に従って、メールメッセージデータが格納されます。


 
 メールメッセージデータとしての殆どの属性は、このXMLという形式のカラムにテキストデータとして格納されることになるわけです。
 XMLカラムがあれば、他の従来形式のカラムは必要ないのでは?という疑問が湧き起こるかもしれませんが、リレーショナルデータベースとXMLデータベースの双方の良いところを使えるというのがハイブリッドDBの利点です。
 特に当システムでは、次のような考え方に基づき、このメール・データの定義を行っています。

  • メールデータはRFC822の仕様に基づき、極力原型に近い形態でXMLスキーマを定義する
  • XMLカラムにメールデータを格納し、メールデータの検索ができるようにする
  • ヘッダの情報のうちのいくつか(Message-Id、In-Reply-To等)は、他のカラムに展開し、またインデックスを作成するなどして、データ検索の高速化を実現する
  • ヘッダの情報の日付(Date)については、GSTに変換して、他のカラムに展開
  • XMLデータにない属性(メールサイズ、添付ファイルの数、その他)は他のカラムに展開

 関連するメールを検索する際に、ヘッダの「Message-Id」と「In-Reply-To」の関連を調べるわけですが、当初はXMLの検索機能を使って行っていたんです。でもすぐに、これは従来のリレーショナルデータベースの持つインデックス検索には及ばないことが分かりました。

 なお、検索用の表以外に、メールの実データを格納する表が別途あります。
 ER図的に描くと次のようになります。

ma_007.jpg

メールデータは、1対1に関連付けられた2つの表で構成されます。


 メールデータは、MAIL_EMLというテーブルのEML_BLOBというBLOB形式のカラムにバイナリデータとして格納されます。(暗号化したものが格納されます。)
 例えば、メールクライアント上から誤って削除してしまっても、このテーブルを利用して復元することが可能です。