Webサービスというと皆さんは何を思い浮かべるだろう? 分散処理の次世代標準技術,EDI(Electronic Data Interchange[用語解説] )の基盤技術,なんてところだろうか。こうした見方は正しいが,惜しむらくは話が大き過ぎる。

 話が大きくなればなるほど,ソフト開発者の多くは「分散処理?そんな難解なシステム作らないもん」「EDI? CIO(Corporate Information Officer,情報戦略統括役員)さんにでも考えてもらえば?」と,様子見に流れるのではなかろうか。

 UDDI(Universal Description, Discovery and Integration[用語解説] )レジストリを使って役に立つWebサービスを見付け出し,それを利用してソフト開発を楽にする,というシナリオには無理があると思う。そのWebサービスは今日は使えるかもしれない。でも1カ月後に同じように使えるかどうか,だれに分かるというんだろう? 他人の作ったWebサービスをあてにしてソフトを作るんだろうか?

 こんな風に書くと「Webサービスってダメじゃん」とか「Webサービスの利用には越えなければならないハードルがある」と話が進むと思うかもしれない。そうではない。Webサービスは今日の時点ですでに,安価で,簡単で,有用な実装手法だ。

 先ほど触れた「他人の作ったWebサービスの継続性」という問題は,自分のWebサービス・サーバーに自分で作ったWebサービスを置き,それを自分で作ったWebサービス・クライアントで利用すれば問題にならない。Webサービスは分散処理だが,多くの開発者は分散処理そのものが目的ではないのだから,分散処理であることを過度に意識する必要はない。

Webサービスを作ってみた

 自分でWebサービス・サーバーを持ってWebサービスを書くなんて現実的じゃない,と思う方もいるだろう。だが,私の意見は「十分に現実的」だ。

 例えば,私の自宅の机には1台のデスクトップ・パソコンがあり,Windows 2000 ProfessionalとVisual Basic .NET Standard(実売価格は1万2800円前後,以下VB .NET Stdと略)が入っている。メルコのルーター(1万5000円前後)を介してADSLでインターネットに接続している。

筆者の作ったWebサービス
郵便番号から住所を検索して(逆も可)入力支援をするExcelのシート。筆者の自宅のWebサービスを呼び出して利用している。ソース・コードや開発の仕方は日経ソフトウエア12月号の特集2に掲載した
 ニフティのダイナミックDNSサービス(200円/月)を使ってサブドメイン名を取得しているので,その名前を使えばインターネット上のどのコンピュータからも自宅のパソコンにアクセスできる。こうして自宅のパソコンは,インターネット上のHTTPサーバー,FTPサーバーとしてだけではなく,Webサービス・サーバーとしても稼働している(写真[拡大表示])。

 VB .NET StdでWebサービスを書くのは難しくない。枠組みは自動生成されるので,その中に関数(Function)を書くだけだ。VBで関数を書いたことがある人なら迷う部分はほとんどない。関数のみでテストができるようになっているのも気がきいている。

 Webサービス・クライアントを書くのも簡単だ。VB .NET Std,Excel 2002,Delphi Studio 7で作ってみたが,関数ライブラリの関数を呼び出す感覚でWebサービスを利用できる。TCP/IPで通信をするプログラムを書くのに比べると,拍子抜けするほどの簡単さだ。

 つまり,一個人でもWebサービスを作って使うことは可能だ。部署レベルのLANでWebサービス・サーバーを立て,特定の数人のユーザーにWebサービスを提供するのも難しいことではないだろう。

小規模Webサービスの利用シナリオ その1:職場にて

 そんな小規模なWebサービス・サーバーに何の意味があるのか? と思われる向きもいらっしゃるかもしれない。私が想像したいくつかのシナリオを聞いていただけるだろうか。

 まずはデータ・ファイル一元化による更新の簡略化だ。私の職場には各人が取材先などの住所を入力するデータベース・クライアント・ソフトがある(私が作ったものだ)。ソフトには郵便番号から住所を引く,または住所から郵便番号を引く機能があり,郵便番号データは各クライアントに入っている。

 ところが,郵便番号データというのは,総務省郵政事業庁によってときどき更新される。その更新を各人のパソコンに反映させるのが,面倒でなかなかやる気にならない。

 いっそのこと,郵便番号を検索するWebサービスを作り,各クライアントからそれを利用した方がデータ更新の手間が省けるのではないだろうか。郵便番号Webサービスを動かせば,ExcelのワークシートにVBA(Visual Basic for Applications)のコードを仕込んでExcel上からそれを利用することもできる。

 ここでは郵便番号という例を挙げたが,これは製品コードでも顧客コードでも部品コードでも同じことだ。ピンと来る方もいるのではないだろうか?

 2番めは実行ファイル配布の簡略化。現在クライアント・ソフトはデータをファイル共有型のデータベース管理システム(DBMS)で共有している。この部分をWebサービス化することも考えられる。

 そうすれば,クライアント・ソフトを動かすのに必要なデータベース接続ソフト(ここでは具体的にはBorland Database Engine=BDE)を各人のパソコンに入れる必要がなくなる。BDEを使っているせいでインストール・プログラムを作らなければならなかったのだが,それを使わないで済むなら,EXEファイルのコピーだけでインストールが可能かもしれない。

小規模Webサービスの利用シナリオ その2:自宅にて

 次は,職場を離れて自宅サーバーと自作ソフトのお話。まずやってみたいのは私が作っているフリー・ソフトを使っているユーザーへのアンケート調査だ。ダウンロード数がどれくらいかはおぼろげながらわかるものの,継続的に使っているのか,どこが気に入っていて,どこが不満なのかということはなかなか分からない。

 ソフトに「アンケート協力」というメニュー項目を追加し,簡単なアンケートに答えてもらい,自由記入欄に感想を書いてもらって,OKボタンを押したら私のWebサービス・サーバーにそのデータが転送され,蓄積されるというのはどうだろう? これなら自宅サーバーが常時稼働している必要もない(クライアント側に再送信機能を持たせておけばよいだろう)。

 シェアウエアを作るならライセンス管理に使えそうだ。入金を確認したら解除キーを発行する。解除キーをソフトに入力すると,ソフトが私の自宅のWebサービス・サーバーに通知するようにしておく。こうすれば,一つの解除キーが頻繁に使われているかどうかを調査できる。ソフトの作り方によっては,ユーザーのコンピュータのIPアドレスやMACアドレスの情報を得て,不正ユーザーをより的確に見付け出すことだって可能なはずだ。

 プログラム更新の省力化も可能だろう。Windowsの「Windows Update」やウイルス対策ソフトの自動アップデート機能はよくできている。私の作るソフトでも,Webサービスを使えば同等のことができるかもしれない。これはユーザーにメリットがあるはずだ。

 ユーザー数が少ないならば,Webサービスを使って,インスタント・メッセージング,掲示板,チャット,オンライン・ゲーム,ファイル交換プログラムを作ることも可能かもしれない。Webサービスなら,TCP/IPのポートを消費することもないし,ファイアウオールにブロックされることもない。これらはWebアプリケーションで作るという手もあるが,Windowsアプリケーションの使い勝手の良さは,やはり捨て難い。

☆     ☆     ☆

 Webサービスは手軽で実効性の高い実装手法であり,その応用はいろいろ考えられる。もちろん,使ってほしい人だけに使ってもらう,通信の内容を他人にのぞき見されないようにする,といったセキュリティ上の配慮は必要だし,その難度を軽視するつもりはない。ただ,それでもやっぱり,Webサービスはソフトを作る人間に新しい地平を開いてくれたのだと思う。

(原田 英生=日経ソフトウエア)