XML＆Webサービス開発事例研究（1）
Webサービスで運用するRFID制御システム
〜IC Serverが実現する無線ICタグ・ソリューション〜
| XMLとWebサービスを用いたシステム開発の事例を紹介していく本シリーズの第1回は、RFID（無線ICタグ）とWebサービスを組み合わせた次世代商品管理システム・ソリューションを取り上げる。（編集局） |
トッパン・フォームズ（株）
玉木 栄三郎
2003/11/1
■なぜWebサービスとRFIDなのか
Webサービスのビジネス利用はどこまで進んでいるのか？ WebサービスをSOAPプロトコルに限定すれば、ミドルウェア製品やWebアプリケーション開発ですでにSOAPの実装は始まっている。多くの開発者にとって、SOAPはファイアウォールを超えられる便利なRPC（Remote Procedure Call）として認識され始めているのだ。Webサービスでビジネスチャンスをつかもうと考えている開発者がいま最も関心を抱いているのは、この便利なプロトコルを使ってどんなアイデアをビジネスに結び付けるか、になるだろう。本稿では、市場拡大が確実視されているRFIDとWebサービスを結び付けた"アイデア"を紹介する。
RFIDとは何か？
RFIDという言葉をご存じだろうか？ 無線ICタグという表現の方がなじみがあるかもしれない。RFIDとは、Radio Frequency Identificationの略で電波を利用した認証技術の総称であるが、最近では事実上ICチップを使用した非接触認証技術を意味するものとなっている。RFIDはほかにも無線ICタグ、無線ラベル、非接触IC、RFタグなどさまざまな呼ばれ方をしているが、ここではひとまずRFID（RFタグ）で統一することにする。
RFIDは、無線ICタグといった別名が示すように、記憶媒体としてのICチップをタグやラベルに封入し、認識対象物に付与することで、それを非接触で認証（認識）しようとする技術である。身近なところでは、JR東日本のSuicaやビットワレットが運営する電子マネー、Edyなどに採用されている技術として有名である。SuicaやEdyはカード型で、人が所持して利用する運用方式であるが、RFIDは一般的な傾向としてヒトの認証でなく、モノの認証に利用する技術として発展している。
RFIDが非接触認証を実現する仕組み
RFIDと一言で表現してきたが、実際はいくつかの要素により構成されている。何から何までがRFIDであるという明確な基準があるわけではないが、RFIDと表現される場合、少なくとも認識対象となるICチップを含んだRFタグと、そのRFタグに対して情報の読み書きを行うリーダ・ライタという機器の2つの要素を含んでいる。
認識対象となるRFタグは、実際に情報の読み書きが行われるメモリとして機能するICチップ（部）と、情報通信およびICチップの読み書きに必要となる電力を発生させるためのアンテナ部により構成されている。リーダ・ライタから発せられる電磁波がこのアンテナを通過することにより発生する起電力によって駆動する。そのため、RFタグ自体に電源は必要なく、理論上は半永久的に使用できる。
図2 RFタグの構造 |
RFタグは、利用用途に応じてさまざまなタイプや形状のものが製造・販売されている。
図3 目的に応じてさまざまなタイプのRFタグが存在する |
RFタグに対して読み書き処理を行うリーダ・ライタはアンテナ部分と送受信データを処理するコントロール部により構成されている。
図4 リーダ・ライタの構造 |
リーダ・ライタも利用用途に応じて、さまざまな規格や形状のもの（ハンディターミナル型、PDA型（CFカード）、設置型など）が製造・販売されている。
RFIDの分類
RFIDは物理的特性や通信規格、通信に使用する電波帯域などにより、いくつかの種類に分類できる。ここでは、RFIDの性質を理解するためにも通信に使用する電波の周波数帯によりRFIDを分類する。RFIDに利用される周波数帯は、長波帯（125〜135kHz）、短波帯（13.56MHz）、マイクロ波帯（2.45GHz）を利用する3タイプに分類することができる。周波数帯といわれてもピンとこないかもしれないが、長波帯はAMラジオに近い帯域（kHz）、短波帯はFMラジオやテレビに近い帯域（MHz）、マイクロ波は無線LANやBluetoothに利用されている帯域（GHz）といわれれば、少しは身近に感じていただけるかもしれない。
複数の周波数帯域の製品が存在するには理由がある。通信に使用される電波の帯域によってRFIDの性質が異なるためである。RFIDの特性を理解するために、各帯域の特性について確認してみよう。
ビーコンの周波数は何ですか
マイクロ波帯（2.45GHz）
法的な制限や実際の利用環境に影響されるため、一概にはいえないが、一般的に周波数が高くなるほど（波長が短くなるほど）、通信距離が長く、通信が高速で、直進性が高い傾向にある。「ならば、マイクロ波帯だけを使えばいいじゃないか」と思われるかもしれないが、実はそういうわけにもいかない。2.45GHz帯を利用したRFID製品は比較的通信距離も長く、通信も高速であることで知られている。しかし、水による吸収が大きく、水がある環境では通信距離や認識率が著しく低下する。実際、水や氷が多く存在するスキー場のリフトチケットなどでは長波帯のRFIDが利用されている。また、直進性が高いため、障害物の影響を受けやすいという欠点もある。
長波帯（125〜135kHz）
「じゃあ、長波帯を使えばいいじゃないか」というと、そうでもない。長波帯は水の影響こそ少ないが、蛍光灯などから発生するノイズに弱く、オフィスなど、電子機器が多く存在する環境では通信エラーが発生しやすい。また、通信速度が遅いため、高速な読み書きが必要となるような用途には向かない。
短波帯（13.56MHz）
「じゃあ、短波帯はどうだ」というと、帯域の特性は、RFID用途に向いており、実運用という観点からもバランスの取れた帯域といえる。しかし、この帯域の多くは日本ではラジオ、テレビ、携帯電話の帯域として使用されているため、自由に利用することができないのである。不幸中の幸いとでもいうべきか、海外においてもRFIDで使用されている13.56MHz帯は日本においても自由に使用することができるため、日本で利用されているRFIDの多くがこの帯域を利用している。SuicaやEdyもこの帯域を利用している。しかし、帯域としては利用できるものの、電波の出力などは電波法の制限を受けるため、RFID普及において重要な要素となる通信距離は最長で1m程度に制限されたものとなる。「では、日本のRFIDの未来は八方ふさがりか？」というと� �うでもない。電波法の管轄省庁である総務省がRFIDに適した帯域とされるUHF帯（超短波帯）を開放する検討に入っており、近々に開放される可能性も出てきている。UHF帯を利用すれば通信距離を3〜5m程度は確保できるとされており、RFIDの普及に拍車が掛かるものと期待されている。
| ||||||||||||||||||||||||||||||||||||||||||||||
| 図7 帯域別の体表的なチップ |
RFIDアプリケーション開発の現状
散布図とどのように描画する
何かとICチップの大きさ（小ささ）や性能ばかりが話題になるRFIDだが、忘れてはならないのはシステム面の対応だ。
ICチップの容量は大きくなったとはいえ、せいぜい数千bytes程度である（ほとんどのものは数十bytes程度）。そのため、実際の利用時にICチップに記憶されるデータは商品コードと数種類のフラグデータ程度だと考えられており、商品名、価格、原価、仕入先、物流履歴などはICチップ自身は保持せず、必要に応じてリモートサーバを参照する仕組みが主流になると想定されている。そういう意味では、RFIDはシステムの一部を構成するパーツにすぎない。
ICチップに商品コードしか保持されていなくても、そのほかの情報が必要になった場合には、RFタグから取得したコードをキーに、データベースにクエリを投げるだけである。しかし、現在のRFIDシステム開発現場では、こうした一般システムの開発現場において日常的に行われているような簡単な行為もままならない状況がしばしば発生する。その理由はさまざまであるが、その背景にはユビキタスコンピューティングあるいはリアルタイムコンピューティング時代を迎えるに当たっての、既存アーキテクチャの限界を垣間見ることができる。
ここで、いま現在におけるRFIDシステムの開発環境を見てみよう。もしあなたがエンジニアならば、RFIDシステムを開発するに当たって最も気になるトピックはRFタグあるいはそこに搭載されたICチップに対する情報の読み書き方法だろう。RFIDの仕組みでも説明したとおり、RFタグとPC（あるいはサーバ）は直接やりとりできないため、実際の情報のやりとりはリーダ・ライタを介して行うことになる。となれば、気になるのはリーダ・ライタの制御方法である。物理的インターフェイスは何か、通信プロトコルはどのようなものか、ドライバやライブラリはどのように供給されるのか、それらが動作するプラットフォームは何かなど、エンジニアならずとも気になるところだ。
結論からいってしまえば、物理的インターフェイスはRS-232C（シリアルポート）、通信プロトコルはメーカー独自プロトコル、ドライバやライブラリは供給されず、シリアル通信によるコマンドで直接制御を行うといった環境である（シリアル通信さえできればプラットフォームに依存せず利用できるともいえる…）。リーダ・ライタは組み込み用のモジュールとして供給されるタイプも多くあるので、それらを利用するエンジニアのスキルを考慮すれば、このような開発環境でも十分に高水準といえるのかもしれない。誤解を避けるために補足するが、もちろん、USBやRJ-45インターフェースを持った製品も存在するし、DLLが供給されるものもある。ただ、つなげればすぐに使えるというものではないことは明らかである。こうした、イ� ��ターフェイスの高水準化の遅れも、RFID普及の妨げになっていると筆者は考えている。
問題はインターフェイスだけかというとそうではない。お気付きの方もいるかもしれないが、インターフェイスがRS-232CやUSBということは、1リーダ・ライタにつき最低1PCが必要ということになる。このような構成の場合、まず問題になるのはコストである。しかし、最近ではPCの低価格化が進んだことに加え、LinuxなどのオープンソースOSの登場により、PCそのものの価格はシステム全体のコストを考えた場合、そう大きな問題ではなくなってきている。このような構成でむしろ問題となるのは、それぞれのPCに接続されたリーダ・ライタをどう制御するかという技術的な問題と、それに掛かるコストの問題である。
例えば、物流センターなど、比較的大規模な施設で在庫管理などにRFIDを利用したいとすれば、そこには少なくても数十台のリーダ・ライタとそれを制御するPCが存在するということになる。それぞれのリーダ・ライタに対して、「君はAのデータを読み、必要であれば上位データベースを参照する」「君はBのデータを書き込むだけ」といったような制御をどのように行えばよいのだろうか。それぞれのリーダ・ライタに別のロジックを作動させインテリジェントに制御することは至難の業であるとともにコストもかかる。また、RFタグへの情報の読み書きということも重要であるが、そもそも、正しくリーダ・ライタが動作しているかどうかの確認や、動作していない場合のリカバリや障害回避はどのように行えばよいのだろうか。数台 のリーダ・ライタが正しく動作せず、在庫数が正しく得られないために、過剰発注が行われてしまう危険性はないのだろうか。これは、ICチップの性能が上がっても、リーダ・ライタのインターフェイスが改善されたとしても付きまとう問題であり、包括的な解決手法が必要とされる。
RFタグやリーダ・ライタの性能が向上したとしても、システム全体でそれを生かせなければ何の意味もない。RFIDを本当に使える技術にするためには、IT業界に蓄積された新旧さまざまな技術が活用できるはずであり、そこには大きなビジネスチャンスが眠っている。
■Webサービスのビジネス展開
適切に飲料水を保存する方法
RFIDの話題はひとまず置いておくこととし、Webサービスに話題を切り替えよう。Webサービスという言葉を耳にするようになってから久しいが、実際に「Webサービスを利用している」「具体的なサービスを知っている」というエンジニアはまだまだ少ないというのが実情のようだ。（第9回 読者調査結果発表「XMLとWebサービスの活用状況は？」も参照）。職業柄、さまざまな分野のエンジニアに会う機会が多いので、事あるごとに「Webサービスってどうですか？」と尋ねるように心掛けている。エンジニアの立場やスキルにより回答はまちまちであるが、多くの場合、「なんだか難しそう」「まだ先の技術でしょ」「何に使っていいのか分からない」という回答が得られる。
しかし、われわれの認知の度合いには関係なく、Webサービスは日々進化を遂げ、確実に身近でかつ重要な技術になりつつある。
Webサービスとは、その名が示すとおり、Webで使用されている"枯れた"技術を用いて、ネットワーク上に散在する異なったプラットフォーム間のシステムを連動させるための基本技術である。マイクロソフトの表現を借りるなら"XML Webサービス"となり、XMLという接頭語が示すとおり、その互換性や拡張性の根源はXMLによってもたらされる。
実際にはWebサービスという1つの技術が存在するのではなく、SOAP、WSDL、UDDIなど、複数の異なった目的のための基本技術の組み合わせにより実現される。
勘のよい人はお気付きかもしれないが、先に挙げたRFIDシステム開発の諸問題を、Webサービスを使って解決してしまおうというのが、本稿の真意である。
Excelを使ってWebサービスを体験しよう
ここでは、Webサービスの技術的話題には触れず、身近なツールを利用してWebサービスを体験してみることにする。Webサービスをまだ体験していないという方はぜひ挑戦していただきたい。
Webの閲覧に、HTMLを解釈することができるクライアント（ブラウザ）が必要であるのと同様にWebサービスにおいても、それを利用するためのクライアントが必要である。Webサービスのクライアントと聞くと、すぐに思いつかないかもしれないが、われわれが日常的に使用しているExcelやAccessもWebサービスクライアントとして利用できることをご存じだろうか。Office XP以降（単体では2002シリーズ以降）のOfficeツールであれば、マイクロソフトから無料で提供されているOffice XP Web Services Toolkitをインストールすることで、Webサービスクライアントとして機能する。
ここでは、WebサービスをExcel 2003から利用する方法を紹介する。なお、Excel 2002においてもまったく同じ手法でWebサービスを利用することが可能であるため、ぜひチャレンジしてほしい。なお、Webサービス側はこちらで用意したので、必要なものはクライアントとなるExcelだけである。
テストに必要なもの
Webサービス（サーバ側）の仕様
Webサービスを利用する
- Excelを起動する。Office XP Web Services Toolkit 2.0はインストール済みとする。なお、Office 2003用のWeb Services Toolkitはリリースされていないが、XPのものがそのまま利用できるようだ
- 【ツール】 → 【マクロ】 → 【Visual Basic Editor】を起動する
- 【ツール】 → 【Web Service Reference】を選択する。このメニューはWeb Service Toolkitのインストールにより追加される
- ウィザードが起動する。Webサービス URLに先述のWSDLファイルのURLを入力し、検索する。検索の結果、WSTestメソッドが見つかるので、チェックボックスをチェックし、追加する（下図）
- 自動的にWebサービスを利用するためのメソッド（プロキシ）が生成される（下図）
- 標準モジュールを追加する（下図）
- helloメソッドを実装する。ここでは、選択したセル（ActiveCell）に戻り値が挿入されるようにする
【コード】 Sub hello()
'Webサービスのインスタンスを生成
Dim obj As New clsws_WSTest
'選択したセルに戻り値を表示
ActiveCell.Value = obj.wsm_WSHello
End Sub - 【ツール】 → 【マクロ】を選択し、マクロ(hello)を実行する
- Hello Web Serviceが表示される（下図）
数行のコーディングは必要となるものの、日常的に使用しているExcelからローカル関数あるははコンポーネントを呼び出すようにリモートサービスを呼び出せるのがご理解いただけたかと思う。利用に際しては、XMLはおろか、SOAP、WSDL、UDDIなどの知識など全く必要ない。強いていうならば、Webサービスを指定するという過程で、WSDLのURLを必要とするので、WebサービスはWSDLのURLで指定するという概念があればよい程度である。
WebサービスとRFIDを組み合わせると何を実現できるか
ここまで、RFIDとWebサービスという、一見何ら関係のない2つの技術を紹介してきた。事実、RFIDとWebサービスは直接的に何の関係もない。しかし、RFIDの普及にはWebサービスは不可欠な技術だと筆者は考えている。
RFIDシステムの開発が簡単ではないことはすでに説明したが、その難しさの本質は次の項目に起因している。実は、このすべてをWebサービスは解決してくれるのである。
- リーダ・ライタの制御APIが低水準過ぎる
- リーダ・ライタをネットワーク経由で制御する方法が確立されていない
- 分散したリーダ・ライタを管理（監視）する方法が確立されていない
Excelで簡単にWebサービスを利用できるのはご理解いただけたかと思う。先ほど利用したWSHello()やWSAdd()メソッドは、テスト用の簡単な命令であるが、リーダ・ライタの制御コマンドが、このようなWebサービスとして実装されているとしたらどのようなことが可能だろうか。遠隔地に存在しているリーダ・ライタが認識しているRFタグのユニークコードや、認識対象物数（在庫数）をExcelから呼び出せるということになる。
事実、各メーカーから提供されているリーダ・ライタドライバをWebサービスでラッピングすることにより、RFIDシステム開発において発生する多くの問題を解決することができる。Webサービス自体、分散オブジェクト技術の流れを受けているものなので、Webサービスでインターフェイスを実装した時点で、高水準APIと呼べるものとなっている。体験していただいたとおり、ウィザードに従っていくだけでプログラムの基礎部分は完成するという、最新のIDE環境で利用される一般的な手法により、リーダ・ライタ制御メソッドを呼び出すことが可能となる。
リーダ・ライタが接続されているPCにインストールされているAPIを既存技術の範囲でいくら高水準化しても、ネットワークでリーダ・ライタを制御するという問題は引き続き残る。しかし、Webサービスでインターフェイスを実装した場合、ネットワーク経由でダイレクトにリーダ・ライタをコントロールすることが可能となるため、ネットワーク経由での制御問題も解決される。
また、意外と重要なことは、ネットワークに分散したリーダ・ライタをいかに管理するかという問題だ。リーダ・ライタの故障に気付かないまま、RFIDシステムを運用すると、在庫数などが実際の数字より少なく表示されたり、過剰発注の原因にもなりかねない。Webサービスの場合は、このような問題も解決できる。なぜなら、Webサービス自体はWebサーバ上で稼働するものであり、現在、Webサーバの動作チェックを行うツールは数多くあるからだ。これらのツールをそのままリーダ・ライタ管理に応用することが可能になる。いくら素晴らしい性能のリーダ・ライタが単体で存在していても、管理に独自ツールを用意しなければならないのであれば、実用的にはほとんど価値がない。
こうしたリーダ・ライタの管理だけでなく、Webサービスを利用するメリットはほかにも存在する。例えば、通信内容を暗号化することやアクセス制限などのセキュリティ対策を行うことも非常に簡単だ。Webサービスならば、SSLを使うことで簡単に通信内容の暗号化ができるし、ファイアウォールを使ったIPアドレス認証もできる。独自に暗号処理やアクセスコントロール機構を実装する必要はない。また、アクセスが集中した場合の、負荷分散処理、時間帯別のトランザクション（アクセス）分析なども、既存ソフト、ハードを使用し簡単に実現することができる。さらに、忘れてはならないのが、あらゆるプラットフォームからアクセス可能だということだ。いままでは常識であった、Visual Basic版、Java版、Windows版、Linux版など、プラットフォームごとのドライバなどを用意することなく、1サービスですべてのプラットフォームからのリクエストを処理可能である。
このように、WebサービスはRFIDシステム開発時に発生する、従来の技術では解決が難しかった問題を解決してくれるだけでなく、開発効率の向上、コストの削減などに大きく寄与するポテンシャルを秘めている。
次ページでは、Webサービス対応ミドルウェアを使った開発例、およびRFIDとWebサービスの可能性について述べてみたい。（続く）
| イベント情報 RFIDやWebサービスは体験しなければ理解が得られない技術である。本稿で紹介したオンラインリアルタイム在庫管理システムは、2003年11月5日から7日まで東京ビッグサイトにて開催される「計測展2003 TOKYO」および、2003年11月11日〜14日まで開催される「システムコントロールフェア2003」で、マイクロソフト社ブースにて展示、デモが行われる予定なので、興味のある方は、足を運んでいただきたい。 |
■関連記事
・標準化が進むICタグ、2005年には100万社が採用？
・ICタグはSCMで使えるか、NTTコムなどが実証実験
・実用化は5年後？ 坂村健教授が示したRFIDの課題
■連載
1. Webサービスで運用するRFID制御システム
2. リレーショナルDBへの挑戦
3. BIソリューションを支えるXML／Webサービス
TechTargetジャパン
XML & SOA フォーラム 新着記事
0 件のコメント:
コメントを投稿