Insider's Eye 短期集中企画（１）： Sun、IBM、マイクロソフトのWebサービス戦略 Webサービスへの主要3社の取り組み 渡邉利和 2001/11/07

---

　次世代のインターネットを支える主要テクノロジと注目されながらも、Webサービスの実像はなかなか見えてこない。本稿では、Webサービスの普及を推進するIBM、Sun Microsystems、マイクロソフトの主要3社について、それぞれWebサービスを戦略上どのように位置付け、これによって何を達成しようとしているのかを探る。まず1回目の今回は、各社の基本的な立場とWebサービスへの取り組みについて俯瞰し、「共通のインターフェイス規格に基づく3つの異なる利用方法が存在する」という前提を確認する。そして次回からは、Webサービス推進のために各社が用意する開発環境やサービス・システムなど、さらに一歩踏み込んで解説していく予定だ。

単純なインターフェイスとしてのWebサービス

　Webサービスとは何か、という点に関しては、すでにさまざまな解説が行われていることでもあり、ここで改めて繰り返すことはしない。ただ、本稿で「Webサービス」と呼ぶのは、XML、SOAP、UDDI、WSDLといった技術を核とした「リモート・サービスの呼び出し機構」のことであることは明らかにしておきたい。このWebサービスは、「Web上で提供されているサービス一般」を指す言葉と誤解される場合があるようで、最近では単純な「Webサービス」という用語を避ける傾向が出てきている。例えば、マイクロソフトでは“XML Web Service”というふうに、“XML”を追加して明確化を試みているようだ。先ごろロサンゼルスで開催されたPDC（Professional Developers Conference）ではさらに、いくつかの拡張仕様からなる「Global XML Webサービス・アーキテクチャ」を発表している。同様に、Sun MicrosystemsもWebサービスという用語を避け、“Service on Demand”というより広い概念の用語を導入し、この中にWebサービスも含むようになってきている。用語としての「Webサービス」は今後あまり使われなくなる可能性も考えられる。とはいえ、本稿では基本的に「Webサービス」という用語で統一しておくことにしたい。

　さて、Webサービスは基本的には「リモートで実行されるロジックを呼び出すためのインターフェイス」であると言える。LANの世界では標準的に「RPC（Remote Procedure Call）」というメカニズムが利用されてきたが、Webサービスは「インターネット時代のRPC」と表現できるかもしれない。Webサービスは単なるインターフェイスであり、それを使って何が実現できるかは、実のところWebサービス自体の定義の中には含まれないことになる。

　Webサービス自体に関しても、現時点で問題視されている点がいくつかある。例えば、互換性が確実に確保できるか、という点もその1つである。ただし、Webサービスが本質的に相互運用性を実現するためのインターフェイス規格である以上、実はこの点に関してはあまり深刻に心配しなくてもよいのではないだろうか。もちろん、現時点ですぐにWebサービスの実装に取り組む、という場合には目の前の重大問題ということになるが、実のところ互換性問題は時間とともに解決されることが期待される。規格自体の分裂につながるような重大な相違が生じるならともかく、常識的に考えれば「ほかとの相互運用性のない独自のWebサービス・バリエーション」を推進したいと考える人はあまりいないだろう。

　しかし、一方でWebサービスに関してはその推進役としてIBM、マイクロソフト、Sun Microsystemsの3社の名前が挙がることが多く、それぞれの思惑の違いがことさらに取り上げられ、あたかも「3種類のWebサービス」に分裂するかのような懸念が語られることさえあるようだ。

アプリケーション統合の手段としてのWebサービス ―― IBM

　Webサービスが実現する未来像としてよく紹介されるのが、「Web上で提供されているサービスをダイナミックに発見し、連携させる」というイメージだが、実のところこれは言うほど簡単なことではないはずだ。現実には、「プログラマが利用可能なサービスが、あたかもライブラリのようにUDDIに登録され、参照できる」というあたりがせいぜいではないかと思われる。しかし、これに関しても問題はある。技術的には互換性問題があるが、それ以外に、「サービスの質」にかかわる問題も大きい。Webサービスの機能によって、サービス間のインターフェイスは確保できるとしても、リモートで提供されているサービスが「利用に値するサービスか否か」という判断を行う手がかりが必要である。サービスとは、つまるところ「誰が、何を、いくらでやるのか」という話であり、単にロジック間のインターフェイスが取れるだけでは使えることにならない。サービス提供者が怪しげな悪徳業者ではないのか、利用料金はリーズナブルなものか、サービスが確実に提供される保証はあるのか、といった疑問に答える手段がなくては、ユーザーとしてもサービスを利用するかどうかの判断ができないことになる。つまり、インターネットの完全にオープンな環境でのダイナミックなサービス連携は、将来的に実現する可能性は否定しないまでも、すぐに実現可能とは言い難いのは間違いないだろう。少なくとも、サービスの質に関するサービス・プロバイダと利用者の間での何らかの合意が形成される必要がある。

　一方、ある程度クローズドな環境でのサービス間連携は、実現可能性という意味では格段に現実的な話となる。少なくとも、現時点においても、インターフェイスにWebサービスを利用したサービス間連携はすでに実装可能な技術だと言ってよい。ただし、注意すべきなのは、クローズドな環境でのサービス間連携は、必ずしもWebサービスを使わなくても実装可能である。現に、専用のソリューションという形でこうしたシステムが提供されている。例えば、EAI（Enterprise Application Integration）などがその例となる。こうしたシステムで問題となるのは、いわゆる「レガシー・アプリケーション」である。メインフレームなどに実装された基幹系システムと呼ばれるものは、企業の中核的なデータを扱う基本的なロジック層を含む。こうしたシステムをインターネット環境に対応させるために、過去の資産を捨てて新しいシステムにリプレースしてしまうのは確かに簡単で奇麗なシステム構築が可能となるが、これができる企業は限られているだろう。

　例えばWebを利用したコマース・システムを構築する際に、本来なら従来利用している業務システムと統合すべきなのだが、これがレガシー・システムであったりすると、単純にインターネット対応とするのも容易ではない。かといって、まったく別個のシステムとして作ってしまっては無駄な作業が増えることになる。そこで、インターネット上のコマース・システムと業務系のレガシー・システムを統合する、というニーズが出てくるわけだ。

　このときに、確かに他の実装手段もなくはないが、Webサービスもまた有力な解となる。今後標準として確立されることが見込まれるWebサービスをインターフェイスとして利用すれば、将来的な拡張性が確保されることが期待できる。さらに、企業内から一歩踏みだし、グループ企業間や主要取引先とのシステム統合を視野に入れれば、Webサービスは特定の専用インターフェイスを使うよりも安全で低コストなソリューションとなるはずだ。

　この利用法では、インターネット環境のオープンなサービス連携の際に問題となった「サービスの質」に関して、システム側では気にしなくてよくなる、というメリットもある。つまり、自社内に構築したシステム間やグループ企業間、あるいは主要取引先といったところが提供するサービスに関しては、その品質について合意を形成することも容易である。むしろ、従来から相互に利用しているサービスをWebサービス化する、という流れで考えれば、サービスの品質に関してはすでに実績に基づく合意ができている場合が大半だろう。

　この形でのWebサービスの利用は、共通インターフェイスを利用するメリットをストレートに享受でき、かつ障害も少ないと思われるため、筆者としてはまず最初に普及することになると予想している。インターネットの前にまずイントラネットでの普及を想定しているわけだ。そして、この分野に熱心に取り組んでいるのがIBMではないだろうか。レガシー・システムをサポートし、そのインターネット対応を推進するのはIBMにとっても大きな関心事のはずだ。IBMは、一方でJavaにも熱心に取り組んでいる。将来的にはJavaでロジックを記述し、Webサービスで連携させる、という形になると思われるが、レガシー・システムの既存ロジックに関しては、JavaでラッピングしてWebサービス対応を実現する、というシナリオが現実的な移行パスとして想定されているようだ。IBMはWebサービスに関してさまざまな分野で積極的な取り組みを行っているが、最も目立つのがアプリケーション・サーバであるWebSphereでの対応だという点も、業務ロジックの統合のためにWebサービスを利用したい、という意図の反映だと思われる。

オープンな標準としてのWebサービス ―― Sun Microsystems

　インターネットを分散アプリケーションのためのインフラとして捉える見方は、別段目新しいものではない。過去にはOMG（Object Management Group）によるCORBAがあったし、Enterprise JavaBeansなどを使っても同様の機能は実現できる。“Network Is The Computer”というメッセージを掲げたSun Microsystemsにとっては、従来から一貫して取り組んでいる課題の1つということになるだろう。同社の持つ技術、あるいは同社のビル・ジョイ（Bill Joy）氏の関心領域と言い換えることも可能かと思われるが、そこにはネットワーク環境での分散アプリケーションの実現を意図したものが多い。プラットフォームに依存せずネットワーク環境で可搬コードを実現する言語であるJavaもそうだし、中でもサーバサイドでの利用を企図したJ2EEやEJB、そしてJavaをベースに動的な発見／検索メカニズムとダイナミックなコード配布メカニズムを体系化したJiniなど、さまざまな取り組みを行っている。

　Webサービスは、Sunにとっては従来から取り組んでいるテーマに対する異なる実装手段であり、その目指すところは同じだが、特にWebサービスという実装方法自体にはこだわりはない、というところではないだろうか。

　Sunは、Sun ONE（Sun Open Net Environment）というアーキテクチャを発表しており、着々と強化を図っている（Sun MicrosystemsのSun ONEのホームページ）。Sun ONEに関しては「SunのWebサービス戦略」と理解されることも多かったが、基本的には「Service on Demandを実現するための体系」であり、Webサービスは“Service on Demand”を実現するための実装手段の1つ、という位置付けになるだろう。このテーマに長らく取り組んできたSunとしては、すでに利用可能な他の実装手段も持っているため、最終目的さえ実現できるなら実装手段に関してはどれでも好きなものを適切に選んで組み合わせてくれればよい、という感じではないだろうか。

Services On Demand

Sunの言う“Service on Demand”は、単純なWebサービスの置き換えではなく、ユーザーが必要なときに適切なサービスを提供する、というコンセプトである。実装の手法としてはさまざま考えられ、各種のサービス・プロバイダ（SP）もそうだし、SOAP／UDDIベースのいわゆるWebサービスもその1つである。

　Sunにとって重要だと思われるのは、サードパーティの開発者の支援を得ることである。サービスカンパニーであるIBMにとっては、サービスの実装は自社の仕事であると言うことが可能だ。IBMには、自社の方針に従ってサービスを提供する部隊がすでにある。一方、マイクロソフトはMS-DOSやWindowsの時代から培ってきた開発者の豊富な層が味方となる。SunはIBMほどの強力なサービス部隊は持っていない一方、サードパーティの開発者の人数はWindowsに及ばない。Sunがいくらサーバを販売しても、その上でロジックを組み立て、アプリケーションを作成する開発者がいなくては話にならない。

　Sunがサードパーティの開発者を獲得するための最大の武器はJavaである。言語自体の魅力と、プラットフォーム非依存という特徴により、Javaの開発者は着実に増加している。開発言語にJavaを利用するのであれば、システムは用途に応じて適切なものを任意に選択できるため、Sunのサーバが選択される可能性も高まる、という構図だ。従って、Sunの主要な関心は、Javaの適用範囲を拡大し、開発者にとって魅力的な環境であり続けるよう強化を続けることだろう。この点で、Webサービスが開発者の注目を集めるのであれば、JavaでWebサービスを作れるようにしないわけにはいかない。従って、Sun ONEの取り組みとはまた別に、JavaにWebサービス実装のための機能を付加することが当面の重要課題であるはずだ。

　さらに、Webサービスの利用環境として、Sunは特にディレクトリ・サーバに注力しているようだ。Solaris 8の最新版（10/01）では、iPlanet Directory Serverとの連携を強化することが発表されている。このディレクトリ・サーバは、Webサービスの文脈でいうUDDIと同じと考えてよいだろう。実際にサービスを“on Demand”で提供するためには、ユーザーとサービスそれぞれに関する詳細な情報が必要となり、つまりはそれを格納する「データベース」が必要となる、というわけだ。単にソフトウェアとしてのディレクトリ・サーバがありさえすればよい、というほど単純なものではなく、そこにどのような情報を格納するかが重要な問題になるわけだが、まずは何かなくては先に進まない、という意味では、まずディレクトリ・サーバを確実におさえるという戦略も理解できなくはない。

Sun ONEのロードマップ

Sun ONEは将来の話ではなく、現時点で実装可能である、というのがSunの主張ではあるが、Webサービスに限定すれば、必要とされるサーバすべてに必要な機能の実装が終わっているわけではない。主としてiPlanetのサーバ製品を中心に、来年いっぱいくらいで必要な機能が実装されていく予定である。 略語の意味 iAS: iPlanet Application Server／iWS: iPlanet Web Server／iIS: iPlanet Integration Server／iPM: iPlanet Portal Server／iDS: iPlanet Directory Server

新サービスのための基盤としてのWebサービス ―― マイクロソフト

　マイクロソフトは、Webサービスに関しては最も明確な将来像を提示していると言ってよいだろう。マイクロソフトにとって重要なのは共通インターフェイスとしてのWebサービスではなく、.NETアーキテクチャであるのは間違いないのだが、.NETに関してはここでは詳細に立ち入ることは避ける。Insider .NETフォーラムの関連記事をご参照いただきたい。ここでは、マイクロソフトの認証サービス“Passport”と、Webサービスの実装例である“.NET My Services（コードネームHailStorm）”を中心に、マイクロソフトが構想していると思われるインターネットの新しい利用モデルとWebサービスとの関連について考えてみたい。

マイクロソフトのプロダクツ構成

Windowsやサーバ製品群に並び、Passportおよび.NET My Servicesのサービスが今後マイクロソフトの収入源の一角となることをこの図は示している。もちろんこれらのコアとなるのは.NETアーキテクチャだ（PDC2001におけるビル・ゲイツ氏のキーノートでのスライドより抜粋）。

　マイクロソフトの戦略の中でも特に重要なのが、Passportと.NET My Servicesだと思われる。もちろん、.NETアーキテクチャは、全体として従来のWindows環境でのアプリケーション作成に慣れた開発者が、無理なくインターネット環境での分散アプリケーション開発に移行できるように考えられたものであり、マイクロソフトの最大の強みである、多数の開発者達を従来どおり味方につけておくための重要な戦略なのだが、この点に関しては置いておこう。

　.NET My Servicesでは、Webサービスとして利用できるさまざまなサービスが提供される。ここには、カレンダー・サービスやアドレス帳など、基本的なサービスが含まれるため、サービス・プロバイダにとってはかなり厳しい競争を強いられることになるのだが、うまく協調していくことを考えるのであれば、基本的なサービスに関してはマイクロソフトに任せ、得意分野に特化したサービスだけを実装すればよい、ということにもなる。つまり、サービスにおける「基本ライブラリ」として利用可能というわけだ。.NET My Servicesは、ユーザーやサービス・プロバイダに対して有償で提供されるサービスとなる予定だ。そして、認証メカニズムとしてはPassportが利用される。

　現時点では詳細が明らかでないので想像になるが、これはある意味iモードの公式サイトのモデルとよく似ているように思う。つまり、マイクロソフトはPassportを通じてユーザーのサービス利用状況を把握し、課金し、利益を分配することが可能になると考えられる。Passportおよび.NET My Servicesと協調するサービスを提供するサービス・プロバイダは、自社が提供するサービスの利用料金の徴収をマイクロソフトに委託することができるのではないだろうか。このモデルが実際に機能すると、Webサービスで実装されたサービスは、基本的にはマイクロソフトのサービスを介してアクセスされることになる。これは、現在のインターネットがサービスの有料化に苦慮している現状を考えると画期的とも言える。マイクロペイメント問題もあり、少額のサービス利用料をユーザーに課金するには現状では適切な手段が見あたらないが、マイクロソフトが一括課金してサービス・プロバイダに分配するのであれば、クレジットカードを利用した課金でも十分に対応可能だろう。

　ただし、このモデルが成立してしまうと、インターネットが完全にマイクロソフトのサービス・ネットワーク化してしまう危険がある。さすがに、いきなりこうした構図が実現するとは考えにくいが、Passportの登録ユーザーが順調に増え、対応サービスを提供するサービス・プロバイダが増加する可能性はある。実際問題、他に適当な代替手段がないのであればマイクロソフトのサービスを利用することになるだろう。そこで、遅ればせながら対抗案を提示したのがSun Microsystemsを中心に結成されたLiberty Project Allianceということになる。Passportと.NET My Servicesをユーザーのインターネット・サービス利用の入り口に置く、というモデルはサービス・プロバイダにとって魅力的なものになる一方で、ユーザーを入り口で完全に捕捉する強力な関門となりうるため、ユーザーにとっての選択肢を確保する意味でもこの部分で競争が起こることは重要だと考えられる。

　マイクロソフトは、開発環境を整備することで、開発者の支援を行う一方で、まず具体的なサービスを提供する、という形でWebサービスに取り組んでいると言える。これは、IBMやSunとはまた違った方向性である。しかも、Passport／.NET My Service経由でのサービス利用にユーザーを誘導できれば、例えばOfficeアプリケーションの機能の一部をWebサービスとして提供する、といった形で、ローカルアプリケーションとWebサービスの組み合わせを実現することも可能となるはずだ。これは、クライアントPC上のアプリケーション市場で大きなシェアを持つマイクロソフトにとっては、「サブスクリプション・モデル」へのスムーズな移行という面からも魅力的な方向だと考えられる。こう考えると、マイクロソフトにとって重要なのは、共通インターフェイスとしてのWebサービスそのものではなく、インターネットを有料サービス・ネットワーク化することにあると思われる。

共通基盤となるWebサービス

　Webサービスは、さまざまな可能性を持つ。ここでは、よく名前が挙がる3社に関して、それぞれが重視していると思われる3つの利用方法を採り上げることで各社が目指す方向性の違いと、今後の発展方向を考えてみたつもりだ。

　もちろん、ビジネスとしてIBM、マイクロソフト、Sun Microsystemsの3社が競争しているのは間違いないが、だからといってWebサービスをそれぞれ独占することを狙っているとか、互換性問題が生じる、と考える理由はないように思う。どの方向性を採るにしても、互換性を失うことがメリットになることは考えられないと思うからだ。むしろ、共通インターフェイスは確固たる共通基盤として確立させておき、その上にそれぞれの得意な分野のマーケットを育てることを狙っているのだと考えてよいのではないだろうか。

　さらに考えておくべきことは、現時点ではいずれも完成したものではないということだ。アプリケーション・サーバ、ディレクトリ・サーバ、そして.NET My Servicesなど、さまざまな分野でWebサービスのための環境整備が進められているが、これは裏を返せば、このいずれもまだ完成の域に達してはおらず、まだまだ作業が必要な段階にあることを意味している。低コストで簡単にWebサービスを実装し、利用できる段階に達するにはもう少し時間がかかるだろう。この段階でいち早く実装に取り組んでパイオニアとしてノウハウを蓄積するか、あるいは環境ができあがるのを待つか、それぞれの状況に応じて冷静に判断する必要があるだろう。Webサービスは、今後の重要な技術動向として決して無視できるものではないが、現時点ですぐにバラ色の環境を実現できるものでもない。PDCの開催に合わせて、各社一斉にWebサービス関連の発表を行い、やや情報過多の感もあるが、あわてることなく冷静に確実に取り組むべきではないだろうか。

Insider's Eye

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