X M L D B を用いた位置情報管理システム

(1)

X M L D B を用いた位置情報管理システム

坂本昭彦ぺ得田英寿本ぺ岩波孝比古事 *

L o c a t i o n I n f o r m a t i o n Management System u s i n g XMLDB

Akihiko SAKAMOTO

*，

H i d e h i s a TOKUDA 市ぺ TakahikoIWANAMI*

^常

Abstract

I t

is the one to propose to use XML as a location information in research. XML enables the dealings between flexibility and the enterprise. If this technology is used， it is wide further as the management of the position. Moreover， width within the range of the application is expected to extend to the Web service. The policy does as follows. Management and the acquisition of data can be flexibly done in cooperation with the Web service. Moreover， efficient data management can be done by using the XML document and the data base. We make for trial purposes of architecture， consider， and handle the practicality of the application. This is assumed to be one system， and it has aimed at making of the data spread highly effective finally.

Keywords XML， XMLDB， location information， management， load reduction， Internet

1.はじめに

近年インターネットにおいては多くのサービスが登場し多種の Webアプリケーションが普及している. しかしその一方で，ユーザアクセスの集中やアクセス端末の多様化などによりハード機器やアプリケーション開発ソフトなどのサーバ構築コストは増加傾向にある.また，データ管理においてはリレーショナルデータベースにてデータ管理を行うというのが一般的であるが，組織内あるいは組織聞でデータの交換や登録を行う際にそれらの互換性の欠如が支障となることが多い.

また，情報機器の進歩は著しく，高性能化，

小型化が進んでいる.モパイル向けアプリケーションの技術の標準化団体である WAP

*近畿大学工学部電子情報工学科

*本近畿大学大学院システム工学研究科

45

(Wireless Application Protocol)フォーラムでは記述言語の標準仕様としてXHTMLを採用しており，XML技術を移動通信に利用する動きが加速している.しかしながら， XHTMLコンテンツは XMLコンテンツと比べ，コンテンツサイズが大きくなる傾向にある.次世代携帯電話向けに Webサービスとして注目される位置情報をテーマにしたサービスが登場し，急激な需要増加が見込まれる.このため，今後も情報伝播の効率化を高めることは今非常に重要なことである.

XMLは，企業間でタグをあらかじめ取り決めておくことによって共通のデータ形式を作成することができ，特殊な機材を導入することなく，

Department of Electronic Engineering and Computer Science， School of Engineering， Kinki University Graduate School of Systems Engineering， Kinki University

(2)

46 近畿大学工学部研究報告 No41

インターネットを利用して交換することができる.

XMLを使い，取引先との電子化が実現されれば取引データをさまざまなアプリケーションで扱って加工したり表示・印刷したりすることができるため応用範囲が広がる.電子化された取引データをそのまま伝票の起票に使ったり，社内文書に変換したりといった応用が容易にできるようになる.

企業取引以外にも利用可能な分野として位置情報の管理があると考える.本研究では，位置情報として XMLを利用することを提案するものである.柔軟性，企業間取引も可能になる技術を使えば，位置の管理としてさらに幅が広がりWebサービスにも応用範囲の幅が広がることが期待されると考えるのである.実現方式として， Webサービスと連携しデータの管理や取得を柔軟に行うことができるよう，また， XML

ドキュメント，データベースを使用し効率的なデータ管理を行えるよう，アーキテクチャの試作から考察，アプリケーションの実用性までを手掛ける.これを一つのシステムとして，最終的にデータ伝播の高効率化を目的としている.

2.既存システムの問題点

本研究で扱う問題点2点について述べる.

2.1メタデータの扱いにおける問題点

本研究で使用しているメタデータは位置情報を含んでいるが，詳細な位置情報設定方法については後述する.位置の情報管理を XML形式

として表す際，図 1のような方法がある.

ーくcrossmg>

、direct旧n>4</direction>

<Jusual̲route') ー<branch>

</branch>

</crossing>

ーくroad>

くdirection>‑5く/dlfectlon>

<distance>39ぐJdistancs::.‑

くIroad>

ーくCr05S1ng>

ー<usualroute>

</U5ual̲route>

ー<blロck>

ぐleft>郵便局<118ft">

<left>市役所</left，

図 1 XML形式とする際の構造

XMLドキュメント内で，ルートの直下は経路 (course)で、あり，その下位に交差点(crossing)と道路(road)のように続けタグでくくっていくのである.

この方法は検索に優れている反面，データ量が多くなると複雑になり，ドキュメン卜を見ただけでは位置関係がイメージしにくい.そこで，

ツリー形式を構成する新たな方法を考えなければならない.本システムとして考案したのは，

距離をタグでくくるのではなく，建物の属性として座標の情報を加えることによって表す方法である.これにより，ひとつの情報単位を表すタグが削減され，後述するツリー構造の問題点の解決にもなる.

2.2水平型負荷分散の問題点

Webサーノ《はXMLDBサーバのIPアドレス，

ポート番号，データベースディレクトリ XML ツリー型などの各種情報を認知しておく必要があるので Webサーバの運用後アップデートが複雑になり XMLDBサーバにデータを渡すのが難しい.特に，位置情報を管理するデータベースでは何階層ものツリー型で構成されるため，

3層システムのファンクション層とデータ届を適した構成にする必要がある.本実験で構成するXMLDBサーバは， IPアドレスに，ポート番号，ツリー構造を効率的に管理できるような

ファンクション層を実現する.

例えば，図2のように，Webサーバと XMLDB を1 1接続するのと，図 3ように 1 3接続するのでは，データベース内に格納される XML 文書のツリー構造が複雑になれば， 1 3接続の方が実行速度が低下するのである.また， IP アドレス，ポート番号の管理も Webサーバが負

192.168.2.1 192.168.2.11

Webサーパ

XMLOB

図2 1 1接続

図3 1 3俵続

(3)

担することになる.

そこで，表 1の構成でplngにより， Webサーノ《からDBへパケット 56byteを200回送り，

両者でWebサーバと X MLDBとの平均レスポンスタイムを調べると次のような結果が得られた.(表 2)

表 1構成

CPU Pentium4 1.7GHz

Celeron 950MHz

os

Windows2000 FedoraCore3

表2平均レスポンスタイム(msec)

1対 1 1対3

035139 0.364685

1対3接続の方が値が大きく，原因としては

① 1対1に比べパケットのデータ部分の比率が少ない

② ラウンドロビン方式をとるプログラムによるオーバヘッド

さらに， XMLDBではツリー方式を処理する DBの構造上送るパケット量が多くなるにつれて遅延の比率も大きくなる傾向にある pingなどの軽いパケットではなく，また， DBの台数を増やすとWebサーバで;DBを管理するのが困難になる.

3. システム概要

本研究で構築した X ML ドキュメン卜のツリー構造とアプリケーションサーバの概要を述べる.

3.1 XMLDB概要

現在，電子商取引や基幹業務を行うためのシステムとして， W W Wや，データベースを連携したシステムが台頭してきている.このようなシステムでは， XML文書が活躍することが期待されている.そこで， W W Wとデータベースについて述べる.

通常， W W Wとデータベースを利用するシステムは，ユーザの操作を処理するブラウザの層，データの問い合わせを処理するなどの業務処理をする層，さらに処理対象となるデータを格納するデータベース層，という 3層から成り立っている.

このようなシステムのことを3層システムという(図 4).

3層システムでは，ユーザの操作を処理する部分をプレゼンテーション層，業務処理をする部分をファンクション層，データベースを処理する部

分をデータ層と呼ぶ.

W W Wを利用した3層システムは，プレゼンテーション層に W W Wブラウザを利用するため，

特別なアプリケーションをクライアントマシンに配布する必要がなく，インターネットの標準の通信プロトコルで、あるTCP/IPを利用したシステムを構築することが可能である.

図4 3層システムの仕組み

3層システムのメリットとしては，クライアン卜マシン上で、ユーザから入力されるデータを受け取るなどの操作処理だけを行い，そのほかの処理はサーバ上で、行うため，クライアント上の処理を減らすことができる点がある.また，各階層が分離されていることによって，システムの変更がしやすいという点もある.画面操作とデータ処理が別々に構築されることによって，画面の部分のみを変更したい場合，簡単にシステムを変更でき

ることが可能である.

XMLはこのW W Wを使った業務システムなどで利用されることが期待されている.例えば，ユーザは W WW ブラウザを用いて，サーバから受信した X MLを表示させることができる.また，

WW Wブラウザが XMLに対応していなくても，

サーノミで、XSLを用いてX ML文書をHTML文書に変換し，ユーザ、にHTML文書のみを送信することもできる.さらに，データベースからデータを取り出したり格納したりする際に， X ML文書を用いることも考えられる.

3.2メタデータについて

あるデータに関する情報をさらに記述するデータのことをメタデータという.X MLはさまざまなデータに関する情報を記述する機能を持たせることができる.

インターネットを介してデータを検索する場合には，このメタデータが活躍する.たとえばメタ

(4)

データとして文書のタイトルや作者名，更新日時などの情報を記述しておきこれを検索の対象とすることで検索の精度をあげることができる.

メタデータを記述するために，XMLにしたがったRDF(ResourceDescription Framework)が標準化されている， RDFは1999年2月にW3Cの勧告となっている仕様である， RDFでは， XML ばかりなく， HTMLなどW W Wに関連した文書のメタデータを記述することができる， RDFに対して検索を行うことで必要なデータにすぐにたどり着く仕組みを構築できることが期待されている.

3，3XMLドキュメントのツリー構造

XMLDBにおける 1 多での XMLドキュメントのツリー構造によるデータ転送効率の問題点について，新たなツリー構造の記述方法を提案する.

クライアントのキーによる検索にも有用なシステムとするため，以下の点に従った.

① 地図をXMLDBで管理し，情報をメタデータとして管理する.

②クライアン卜からのキーワードを検索し，ヒットしたものを位置と建物の説明等を加えてクライアントに返す.

③ 建物の詳細な検索が可能

図5示す地図を図6のツリー構造に置き換えて考えることでDB化する.最上位は mapで分岐があれば，東，北，西の順に roadを子として持つようにする.また次の分岐点までに建物が存在すれば buildingを子として持つようにしてツリー構造を実現している.この構造では従来の構造よりも視覚的にわかりやすく，ひとつの'情報単位のステップ数が少ないので，ツリー構造による転送効率のネックが解消されるのである.

次に， road， buildingにはそれぞれ位置情報を付加したのだが，たとえばroadの場合road(sx， sy， dx， dy)となる.

o ¹⁰⁰⁰ ¹⁰⁵⁰

ぽ民 1000

f

』畑愉，田

l沼 t

1050

~

「

̲ road

口

^b^l^仙

図5 記述方法の対象map

処理の流れを図6に示す.

図6 ツリーの記述方法

<'IX.IIII version=" 1.0" encoding="ShiJl̲JIS" '1>

<road sx=" 10似)"s)'=" 1 000'・dx="IOω"d、="1υ50"namel="五条例〉

く加i1ding sx="IOO()" s)'='1倒見J"dF"IU2U・dy="IU3U・阻mel=公園調 n^{副阻}2="五条公園"da回1="積水"da^阻2="テニスコート">

〈旧me>五長公園<Jn^{卸時〉}

叫ala>噴水^fテニスコートあり<Jdala>

</building>

<road sx=" 1 UC剛"剖="IlKIU" dx="I05U" dv=" 10(則"

R間同1=大門">

<building sx=" 1 U2U・町=IO(K)"dx="1 U5U・dy="95()"

n副lcl=電気屋・name=位情電気・da阻1=・家電・伽岨1=本">

図7 XMLドキュメントの記述(一部抜粋) これらを考慮し，試作した XMLドキュメン卜の一部を図 7に示す.次に、 XMLファイルをXMLDB (Xindice:ジンディーチェ)としてサーノくに格納する.

記述されたドキュメントを DBに保存したコレクション名，ドキュメント名および，その位置は，

コレクションdbの中にコレクションmapdbを作りその中にドキュメント mapdb1となっている.

3.4アプリケーションサーバ

WebサーバとXMLDBサーバとの聞にアプリケーションサーバを設け(図8)，の IPアドレス，ポート番号を管理するプログラムにより，

Webサーバの負荷を抑えた.

図8 負荷軽減ネットワーク

また，クライアントからの問い合わせを DB

(5)

に渡し，結果を返すようなフ。ログラムMap.java を作成した.次のような働きをする.

①クライアントから得たキーワードをデータベース検索 (XPath)する.

②クライアントに位置，建物の説明等を返す.

・位置:要素road，buildingの属性sx，sy， dx， dy

・建物の説明:roadの子の要素name，data .索対象はbuildingの属性name1，name2，

. ，datal..

③ 最後に検索に該当した建物の位置を画面に表示する.

. sx， sy， dx， dyから位置を特定 4.評価

4.1 Map.javaによる XPathでの値受け渡しの評価

アプリケーションサーバの Map.javaが正常に動作しているかを検証する.

クライアント側とアプリケーションサーバ内の二点で XPathが有効に働いていればいい.プロンプトに対しここではfunnsuiをキーワードとする.XPathで検索するので//*[@合='funnsui']

と入力すると図9ように表示された.

sx :1000 sy: 1000 dx: 1000 dy: 1000 name:五条公園

図9 サーバ上で、の実行結果

対象となる建物は原点から， sx，sy，dx，dyで，全て距離 1000の位置に配置し，検索に該当するのはこの一つだけという設定のもとであったので，

sx，sy，dx，dy，ともに正しく受け渡していることがわかる.また，該当する名称は「五条公園Jと設定してあったことにより， nameも正しく受け渡

していることが確認できた.

4.2 Map.javaによるXPathでの値受け渡しの評価

クライアント側からキーワードを打ち込み，位置の表示結果が妥当であるかを検討する.

図 10のように funnsuiを含む情報を持つ建物を調べる.黒い実線は道路である roadを表している.north，south，east，westは方角であり，クリ

ックすることによりその方向に画面が移るようになっている.keywordは入力ボックスを二つ設けand検索が可能とした.

検索手順は，右のウインドウから keywordに

funnsuiと入力し OKを押す.すると，図 11に示すような結果になった.赤く表示されているのは検索に該当した建物である.

ここでは三点表示されているのがわかる. ドキュメント内でもfunnsuiにちなんだ建物は3個あり，位置が正確に表示されていることが確認できた.

w

・・

^t

k..，.綱同

nol1l1

品四i判￨

図10 クライアント上での実行前

‑

国脚嶋岡岡>tIh

4周辺

図11 クライアント上での実行後 4.3 Webサーバ.XMLDB問レスポンスタイム

の評価

最後にplngにより，Webサーバから DBへパケット 56byteを200回送り，両者でWebサーバとXMLDBとの平均レスポンスタイムを調べ

ると表3，図 12のような結果が得られた.

平均を見るとわずかにレスポンスタイムが短くなり向上しているが，横軸試行回数，縦軸時間とする分布図(図 12)で示されるようにばらつきが多く見られることがわかった.

表3平均レスポンスタイム(msec) 1対 3

I

1対3(改良) 0.364685 0.35936

アプリケーションサーバを設置したほうが平均レスポンスタイムが短くなっているが，この環境ではアプリケーションサーバの内部処理の性能に依存するため，プログラム面に安定的に処理できない，または，アーキテクチャの特性によるものであると考える.このように， Web サーノくと DBを接続した環境よりも転送速度は上がるが，安定性はやや劣る結果になった.

(6)

0.33 0.32

;

一良一一

改一

¥

一1︐ququ一一対対対一

‑4E︐4E︐4

︐ ︐ ‑

一・・

‑ 一

0.31

0 50 100 150 200 250

図12 平均レスポンスタイムの分布

5.おわりに

本実験の結果，まとめると以下のようになる.

(1)アプリケーションサーバの Javaプログラムをサーバ側で、検証した結果，正確に距離情報と名称をXMLDBから取得しているこ

とがわかった.

(2)同様にアプリケーションサーバの Javaプログラムをクライアント側の GUI環境で検証した結果，正確に位置として画面に表示していることがわかった.

(3)新たに提案した XML記述形式について，

従来の XML記述形式よりも簡素な記述で位置情報のデータベースとして作用してい

ることがわかった.

(4)アプリケーションサーバ増設により，レスポンスタイムを検証した結果，効率的に作用していることがわかった.

(1)， (2)より，位置情報システムはXML記述方式の点，アーキテクチャの点からも従来の XMLDBよりも柔軟でかつ効率的に作用しているといえる.実験を通して XMLはJavaとも相性がよく，インターネットを介した Webサービスには最適であり，次世代の Webサービスには必要不可欠である.

(3)， (4)より， XMLを単に受発注のDBとして管理するのではなく，地図のデータベースとして管理することが可能である.筆者はXMLを使用したが，位置情報表示システムとしては Relational databaseを利用しているのもある.

しかしながら，単に位置情報としての DBにとどまることなく，電子商取引などあらゆる分野に利用可能である点，セキュリティ，プライバシーの点などを考慮しでも XMLを使うということは有効である.

本研究で提案する位置情報を XMLドキュメン

トで管理した際における管理の有効性を示すことができた.この実験で、はサーバ側に Javaでサービスプログラムを新たに設置し，クライアント側ではJavaを用いたGUIを使用しての地図の検索システムを試作した.クライアントからキーを受け取り， DBに渡す.その結果をクライアン卜に返すという点では大きく評価できる.Webサーバの負担を軽減し，ファンクション層としての役割を果たしている.

アーキテクチャを改良することによって， 1:多である Webサーバと XMLDBとのレスポンスタイムの短縮が確認できた.ただし，アーキテクチャを改良した後ではデータの転送速度にかなりのばらつきが見られた.既存のシステムとの違いは Webサーバ側で、はなくファンクション層側でラウンドロビン方式でDBを選択している点である.選択方式を改め，より安定した転送が図れるようにしていく必要がある.

本実験では機材の関係上 1:多を 1: 3としたが 3よりも多い状況でこそタイムの短縮が期待できる.ファンクション層で IPアドレス，ポート番号を管理しているので， DBサーバの多さに関係はなく，システム全体が複雑にならないと言える.

参考文献

[1] 渡遺正弘 blogの機能を利用した位置情報コミュニケーションシステム"電子情報通信学会通信技報 ITS2003‑141，pp.25・30， 2004.

[2]小池竜也，加藤誠巳 "VMUXMLを用いた歩行者ナビゲーション用略地図生成システム " 電子情報通信学会通信技報，ITS2000・23，pp.7‑12， 2000.

[3]伏木匠，熊谷正俊，横田孝義，権守直彦，佐野豊， "XMLを利用した Web方交通情報提供システム"電子情報通信学会通信技報 ITS2003‑110， pp.1‑5， 2004.

[4] 上野英俊，鈴木偉元，石川憲洋，加藤剛志， XMLコンテンツの差分生成法とプッシュ型配信への応用"電子情報通信学会通信技報 NW2001・261，pp.107・114，2002.

X M L D B を用いた位置情報管理システム