連載：熱血VBプログラマ応援団

第5回 XML Webサービスに待ち構える暗黒面（前編） ――　VB.NETで軽やかに乗り越えて光を目指せ！　―― 株式会社ピーデー 川俣 晶 2004/05/26

　

− 今回のご相談 −

前回のスマート・クライアントの話題で、XML Webサービスのことを書いていますが、どうもこれが信用できません。XML Webサービスについての話を聞くと、何でも実現できる夢のような技術に思えますが、本当でしょうか？ あまりに景気が良すぎる話に乗って失敗した経験も多いので心配です。 　もし本当にそれが素晴らしいとしても、使いこなすのが難しいようでは、われわれの開発現場には導入できないかもしれません。簡単なWebアプリケーションの開発すら実践できていないのが現状で、それより難しい技術を取り入れるのはかなり困難であるといわざるを得ません。まして、XMLの知識ですら、ほとんどないも同然です。そんな状況で、XML Webサービスが活用できるとは思えません。 　そして、XML Webサービスが使えないとすると、スマート・クライアントも開発できないことになってしまいます。こんな心配をするのは間違っているでしょうか？ 景気の良い新技術はまゆにつばを付けたくなる 逆転のVゴール より

疑いを持つことは健全な証し

　景気の良い新技術が信用できるのか、それが本当に自分たちにも使えるのか、ということを心配するのは、とても健全な考え方だと思います。むしろ、心配することなく、新技術に何でも飛びつくことの方が問題だと思います。

　そもそも、ソフトウェア開発の現場に「銀の弾丸」（万能の解決策の別名）はない、といわれたのはパソコンなど影も形もないメインフレームの時代です。特定の問題を解決するための有力な技術はあっても、あらゆる問題を解決してくれる夢の技術はあり得ません。どんな技術にせよ、それが実現してくれることと、そうではないことを冷静に見極めるためにも、宣伝文句に踊らされずに疑問を持つことは重要です。

　このように書かねばならないのは、時として、あまりに実現不可能であることが明らかな技術が、偽装された「銀の弾丸」のように宣伝されることもあるためです。もちろん、そのようなものは一過性のブームにしかならず、現場に浸透する前に消えていきます。

　そのように考えたときに、いまひとつ普及が進まないXML Webサービスも同じようなものではないか、という疑問を感じるかもしれません。今回は、その点について取り上げてみたいと思います。

　ここでは、まず良い話を1つ。そして、悪い話を1つ。最後に良い話をもう1つ述べて終わりたいと思います。

良い話：XML Webサービスを作成するのは簡単だ

　さて、まずはXML Webサービスについて取り上げてみます。前回はWebサービスと表記しましたが、マイクロソフトは「XML Webサービス」と呼んでいるので、この用語を使ってみましょう。

　余談ですが、「Webサービス」という言葉は、「Webを使って行うサービス一般」と紛らわしく、できれば使いたくない言葉です。その点で、XML Webサービスという用語で区別を明確化しようとしたことは前向きの進歩だと思います。しかし、「XML技術を活用して情報サービスを行うWebアプリケーション」と区別が付きにくい、という問題がないともいえません。このようなネーミングは、（XML）Webサービスが、XMLを使って実現された多くの技術の1事例にすぎない、という状況を覆い隠してしまい、誤解を生じさせる場合もあります。

　さて、この話を別の角度から読み直すと、面白いことが分かります。XML WebサービスはXMLを使って実現された応用事例の1つにすぎない、ということは、裏を返せば、XMLの的確な使い方はXML Webサービスを開発した人がすでに考慮済みということです。XML Webサービスの利用者が、XMLの正しい使い方について、思い悩む必要は必ずしもないのです。もちろん、そういう知識を持つ人が思い悩むのも有意義だと思いますが、XMLの知識がなくてもXML Webサービスは利用できます。

　また、XML Webサービスは、ネットワークを経由して実現されるため、Webアプリケーションを開発する知識が要求されるのか、と思われるかもしれません。しかし、実際には、XML Webサービスを作成するためにWebアプリケーションの知識の大半は必要ありません。

　そのことを確認するために、Visual Basic .NETで簡単なXML Webサービスを書いてみました。これを見ると一目瞭然だと思います。

注　この記事は技術解説ではないので、サンプル・コードはあくまで雰囲気をつかむための参考として掲載しています。これらのサンプル・コードの中には、Visual Studio .NETに入力しただけでは実行できないもの、プロジェクトで参照の追加などを必要とするものがあります。

　

Imports System.Web.Services <System.Web.Services.WebService(Namespace := "http://tempuri.org/SampleWSSvc001/Service1")> _ Public Class Service1   Inherits System.Web.Services.WebService ……Web サービス デザイナで生成されたコード……   <WebMethod()> _   Public Function CalcPrice(ByVal basePrice As Integer) As Integer     Return basePrice * 80 / 100   End Function End Class

　このサンプル・コードでは、CalcPriceというメソッド（Function）を、別のコンピュータから利用可能にしています。そのために必要だった作業は、Visual Studio .NETでXML Webサービスのプロジェクトを作成したことと、自作メソッドの先頭に<WebMethod()>という属性を付け加えたことだけです。

　このような方法で実現するXML Webサービスは、要するにメソッドを別のコンピュータから呼び出し可能にするだけのものなので、基本的には普通のメソッドを記述するスキルがあれば容易に記述できます。

　Webアプリケーションを構築する場合には、HTMLであるとか、ASP.NETのコントロールであるとか、さまざまな知識が要求されますが、XML Webサービスはそれとは異なり、<WebMethod()>という属性さえ覚えれば、すぐに開発に取り組めます。

　このメソッドを呼び出す（XML Webサービスを利用する）方のプログラムも簡単に記述できます。XML Webサービスを呼び出す詳細なコードはVisual Studio .NETが作ってくれるので、以下のように簡単に呼び出すことができます。

Module Module1   Sub Main()     Dim service As New SampleWSCli001.localhost.Service1     Console.WriteLine(service.CalcPrice(100))   End Sub End Module

　このサンプル・コードのCalcPriceメソッドの呼び出し（太字部分）は、別コンピュータ上のCalcPriceメソッドの呼び出しとなります。このように、XML Webサービスを呼び出す場合も、普通のメソッド呼び出しと同じように行うことができ、Webアプリケーションの知識は必要とされません。

　つまり、Windowsアプリケーションに精通したVBプログラマが取り組む技術として、Webアプリケーションよりも、XML Webサービスの方が、はるかにハードルが低いのです。

悪い話：XML Webサービスに待ち構える暗黒面

　さて、良い話の次は悪い話が待っています。現在XML Webサービスには、多くの問題が指摘されています。ここでは、その中の1つとして、オーバーヘッドについて取り上げたいと思います。

　XML Webサービスは呼び出しのオーバーヘッドが大きい、つまり遅いという特徴を持っています。

　どれぐらい遅いのか、簡単な例で見てみましょう。上記のサンプルXML Webサービスを1万回呼び出す時間を計測するサンプル・プログラムを作成してみます（コンソール・アプリケーションとして作成）。

Module Module1   Sub Main()     Dim service As New SampleWSCli002.localhost.Service1     Dim sum As Integer     Dim startTime As DateTime = DateTime.Now     For i As Integer = 0 To 10000       sum += service.CalcPrice(i)     Next     Dim endTime As DateTime = DateTime.Now     Console.WriteLine(sum)     Console.WriteLine(endTime.Subtract(startTime))   End Sub End Module

　これと同じ処理を、XML Webサービスを使わず、1つのプログラム内で処理するプログラムも作成してみました（コンソール・アプリケーションとして作成）。

Module Module1   Public Function CalcPrice(ByVal basePrice As Integer) As Integer     Return basePrice * 80 / 100   End Function   Sub Main()     Dim sum As Integer     Dim startTime As DateTime = DateTime.Now     For i As Integer = 0 To 10000       sum += CalcPrice(i)     Next     Dim endTime As DateTime = DateTime.Now     Console.WriteLine(sum)     Console.WriteLine(endTime.Subtract(startTime))   End Sub End Module

　さて、両者の実行時間には何倍程度の差があると思いますか？

　筆者のパソコンで実行した結果は以下のとおりです。なお、別のコンピュータ上でメソッドを呼び出すことは可能ではありますが、ネットワークの速度による遅れの要素を除外したいので、同じパソコン上でローカル・ホストを通信対象にして実行しています（つまり、すべての処理は1台のパソコンで完結します）。

XML Webサービスを使った版	00：01：39.1144962
1つのプログラム内で完結する版	00：00：00.0100146

　見てのとおり、けた違いどころではありません。XML Webサービスを使った版は1分39秒。1つのプログラム内で完結する版は1秒すらかからず、10ミリ秒ぐらいで終わっています。まさに圧倒的な速度差です。

　これは重要なポイントを示しています。XML Webサービスは、通常のメソッド記述とメソッド呼び出しに、わずかな知識を追加すれば活用できます。しかし、呼び出しのオーバーヘッドが極めて大きいため、通常のメソッドと同じ感覚で使っていると、とてつもなく処理速度が遅いプログラムになってしまう危険性を持っています。

　この遅さを意識せずにプログラムを設計することは、自滅行為とすらいえます。XML Webサービスを使うなら、別のコンピュータの呼び出し回数を減らし、1回の呼び出しでできるだけ多くの処理をさせるように配慮する必要があります。それを行ってすら、まだ遅すぎるというケースもあり得るでしょう。これが、XML Webサービスの暗黒面の1つです。

　では、この遅さの理由はどこにあるのでしょうか。その理由は2つに分けられます。1つは、別のコンピュータと通信するためのメカニズムを経由することによる避けられない速度低下。もう1つは、XML Webサービスという技術が、そもそも重いアーキテクチャであること、といえます。前者は、回避することができませんが、後者は回避することが可能です。

　ところで、どうしてこれほどまでに遅いXML Webサービスが次世代システムの本命としてもてはやされるのでしょうか。その理由は2つあると思います。

　1つは、ファイアウォールを越えて通信できるためです。XML Webサービスの重さの一因は、既存のHTTPなどのプロトコルの上にデータを載せて転送する構造にあります。これは、独自プロトコルを使用すると、ファイアウォールやプロキシ・サーバを通過できないという事情から選択されたものです。

　もう1つは、XML Webサービスという新しい技術を使って製品を売り込みたいという営業的な理由だと思います。しかし、技術的な意味に限れば、この理由についてはまじめに検討する必要はないと思います。

■

　次回は、この暗黒面を克服する方法から話を続けます。

「熱血VBプログラマ応援団」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）