7つの原則は変革をもたらすか？ インフォテリア株式会社 吉松 史彰 2002/05/11

---

　先日、ほかでもない＠ITで興味深い記事が公開された。「ソフト開発の変革というWebサービスの可能性 ― 変革をもたらすための7つの原則 ―」というタイトルのその記事は、「サービス指向開発」というスタイルを掲げて、それが現在のソフトウェア開発をいかに変革するのか、7つの原則という形でまとめている。

　筆者はサービス指向開発というものが現在のWebサービス・ムーブメントの中核にあることは認める。実際この言葉は以前から使われていた用語であり、決してこの記事の筆者であるJason Bloomberg氏の発案した言葉ではない。だが、この記事で挙げられている7つの原則には首を傾げざるを得ない。「以下に説明するサービス指向の開発原則（新旧の考え方の変化として説明していこう）は、事実上、理解度を一段引き上げるためのガイドラインだ」というが、実際にはこの記事は読者をミスリードしてしまう可能性がある。そこで、筆者が考えるサービス指向開発を、その記事の内容にあわせて提起してみたいと思う。

編集部注：「ソフト開発の変革というWebサービスの可能性 ― 変革をもたらすための7つの原則 ―」からの引用部分については、薄赤色の背景で囲んで表記するか、本稿の本文中で一部引用するときには、かぎカッコ（「」または『』）でくくり、太字で表記しています。

「第1の原則：「静的コンポーネント」から「動的サービス」へ」への反論

『「Webサービス」はその機能を動的記述によって定義するからだ。動的仕様はWSDLで記述されている。「Webサービス」を利用するソフトウェアは、WSDLファイルだけで機能仕様を知ることができる』

　サービスの動的仕様とは何だろうか？ サービスの仕様がダイナミックに変化してしまったら、サービスの利用者は困ってしまわないだろうか？

　WSDLに記述されているのは、サービスへのインターフェイスである。WSDLにはそのインターフェイスと実装方式（プロトコル）とのバインディング（<binding>要素）と、実装の公開場所（<services>要素）も記すことができるが、WSDLに記述してある中で最も重要なものはインターフェイス（<portType>要素）である。インターフェイスは文字通りサービスに関する記述（Service Description）である。公開されているインターフェイスを通じて、利用者と開発者はコミュニケーションを行う。

　このインターフェイスは、極論をいえば、いったん公開したら2度と変更できない。もしもインターフェイスが変更されてしまったら、以前のインターフェイスを使っているクライアントがとたんに動作しなくなってしまうからだ。Bloomberg氏がいみじくもいっている通り、『デベロッパにはこの「サービス」が呼び出される方法や、呼び出す側のソフトウェアのユーザーインターフェイスがまったく想像できないことがある』のだから、クライアントがいるかいないかを知ることはサービス側ではできないのだ。

　そこで筆者が考える原則はこうなる。

■第1の原則：「Webサービスは原則的に変更してはならない」

　動的なんてとんでもない、というわけだ。ここで誤解してほしくないのは、記述されたサービスの内容が変わらないということと、そのサービス記述を取得するタイミングとは、何の関係もないということだ。WSDLファイルを実行時に取得してプロキシを生成し、ダイナミックにWebサービスへのバインドを行うことができるということとは次元が異なる議論である。

『第2の原則：「システムの統合」から「サービスの公開とリフレクション」へ』への反論

『今日における統合化へのアプローチはシステムレベルの要件定義から始まる。システムが本来何をすべきかによって、設計者は各種コンポーネントとその統合方法を計画する。「サービス指向開発」では、このトップダウンのアプローチを採用する代わりに、ボトムアップのアプローチを採用する。システムの各コンポーネントは、システムアーキテクチャが整う前にすでに「Webサービス」として公開されているわけだ』

　Bloomberg氏は混乱している。前半で述べているシステムレベルの要件定義云々という部分は、「サービスの開発」にも当然当てはまるのだ。サービスを開発するときの話をしていながら、後半では「サービスがあるからそれは必要ない」。この議論は明らかにかみ合っていない。

　既存のシステムの統合をするうえで、それらシステムを「サービス」に見立ててそのサービスが持つ機能を公開し、個別のシステムがお互いの公開サービスを調査して（これをリフレクションと呼ぶのはどうかと思うが）、必要に応じてバインド（結合）する。その際に、これまでは難しかったインターフェイスの統一が、XMLによって簡単になる。それがWebサービスを既存システムの統合に応用する手法である。筆者はこの「第2の原則」には何の意味も感じない。

『第3の原則：「再利用性を念頭に置いたコーディング」から「幅広い応用範囲を念頭に置いたコーディング」へ』への反論

　再利用できるコードを書くのは難しい。それは同意する。XP（eXtreme Programming）の掛け声の中でも非常にキャッチーなものの1つに「YAGNI（You Aren't Gonna Need It）」というものがある。将来の備えに書いておくようなコードは、将来実際に使うことはないのだから、書くだけ無駄だということだ。この点ではBloomberg氏の主張に同意する。だが、同意できるのはここまでだ。

『Webサービスの場合「サービス」の記述は動的なので、そのサービスがどのように利用されるのかをデベロッパは知ることができないし、知る必要もない。では、デベロッパがサービス指向のメリットを最大限に活かした開発を行うにはどうすればよいのだろうか？ そのためには、サービス指向開発というアーキテクチャの原則と、アジャルな開発というエンジニアリングの原則とを組み合わせればよい』

（アジャル：agile、「機敏な」という意味。「アジャイル」とも発音される）

　Webサービスの記述は動的ではありえないことはすでに述べた。大体、ここでのデベロッパとはだれのことだろうか？ サービスの開発者か利用者か？ 組み合わせろといっている、サービス指向開発とアジャルな開発という2つの原則の姿がここまでまったく見えないのだ。

『「Webサービス」の開発は、ユーザーの意見を積極的に取り込む継続的かつ反復的プロセスであるべきだ』

　ユーザーの意見の取り込みは重要だ。Googleが行っているWebサービスAPIのベータ・テストなどは、意見を取り込むための効果的な手段といってよいだろう。だが、いったん正式公開したら、そのあとに提供できるのは新しいバージョンであって修正版ではないことに注意すべきだ。

「そしてサービス自体は、複雑ではなく利用しやすいシンプルなかたちで構築すべきである。そのためには、デベロッパはリファクタリングによってコードをできるだけ幅広く応用できるように努める必要がある。」

　「複雑ではなく利用しやすいシンプルな形で構築すべき」なのは、サービスそのものではなくサービスのインターフェイスである。リファクタリングはコードに対する作業なので、サービスのインターフェイスとは直接関係しない。コードをリファクタリングした結果がサービスのインターフェイスに影響してしまうようなら、それはインターフェイスの定義（あるいはコードの書き方）を最初から見直さなくてはならない。繰り返すが、「インターフェイスのリファクタリング」はしてはいけないのだ。

　そこで筆者の第2番目の原則はこうなる。

■第2の原則：「Webサービスはアジャルに開発してはならない。」

　利用者のユーザービリティ、本来提供したいサービスがすべて提供されていること、サービスに余計な穴がないこと。これらを綿密に調査したうえで仕様化し、ユーザーに掲示する接続仕様書としてまとめなければならない。そのために必要なのは、流行のアジャル開発ではなく、まずはウォーターフォール方式のような綿密な仕様固めなのだ。仕様が固まったあとで、それを実装するときにアジャルな手法を導入するのは一向に構わない。繰り返すが、インターフェイスは変えられないのだから、決して反復的に設計してはならないのだ。

『第4の原則：「分裂的なアップグレード」から「臨機応変なアップグレード」へ』への反論

　Webサービスのアップグレードで勘違いしてはならないのは、Webサービスのバージョン管理問題は、Windowsの世界で言えば「DLL地獄」、Javaで言えば「Jar地獄」のような問題とは異なるということである。Bloomberg氏は、まず次のような主張を展開している。

「カプセル化を意識してデザインされたインターフェイスを無視し、外部のモジュールと接続する仕掛けがシステム内部にあることも珍しくない。さらに、APIの中に意味的にあいまいな部分がある場合もある。例えば、古いコンポーネントのgetQuantity()メソッドではボックスの数を返すのに、新しいコンポーネントではパレットの数を返すという場合がある。そしてもちろん、代用として新たに搭載されたAPIが古いものと異なることも多々あり、その場合は相当量の再統合作業が必要になってくる」

　しかし何のことはない、これは単に開発者と利用者の双方がインターフェイスを守っていない（そもそもインターフェイスが定義されていないので直接実装にアクセスしている）という例にすぎない。つまり、これはDLL地獄やJar地獄についての説明なのだ。これは統合作業の複雑さなどと大上段に構えるような問題ではないのだ。

　そしてBloomberg氏はこうも主張する。

『モジュール問題の泥沼を解決することは、サービス指向開発の主な目的の1つだ。単純にAPIを公開するのではなく、「Webサービス」にラップされたコンポーネントが動的サービス記述を公開するのである。基盤のAPIが変更されても、WSDLによるサービスの記述が自動的に調整され、システムのほかのコンポーネントは実行時にこの変更に合わせることができる』

　とんでもない！ 「WSDLによるサービス記述が自動的に調整」されてしまったら、今動いているクライアントはもう1度テスト・フェイズからやり直しだ！ そんなことがサービス側に許されるはずはないのだ。

　Webサービスのバージョン問題は、今非常にホットなトピックの1つだ。筆者の第1の原則は、主張を明確にするためにいささか極論にしたのだが、ここまで筆者が主張してきたように、本当にWebサービスがまったく変更できないなら、ときがたつにつれて有用でなくなってしまうに違いない。Webサービスのインターフェイスを変えるということは、インプットとして受け取る情報やアウトプットして提供する情報の構造を変えるということだ。既存のデータ構造に何らかの構造が追加された場合と削除された場合に関しては、「Webブラウザ方式」で解決できるだろう。つまり、追加した情報がクライアントから送られてこない場合はデフォルトを適用し、不要な情報が送られてきた場合はそれを無視するということだ。情報の意味を変更するのは絶対にやめた方がよい。インターフェイスの変更はデータ構造の変更にとどめ、データの意味は変えるべきではない。

　Webサービスのインターフェイスにおいて、インプットとアウトプットのデータ構造はXML Schemaで定義する。XML Schemaには構造を拡張する機能があるので、それを用いれば、各種のツールが変更点を検出して新しいクライアント・プログラムの開発を支援してくれるだろう。もちろんテストが完了するまでは古いインターフェイスでサービスを利用し続けられる。

　筆者の第3の原則はこうだ。

■第3の原則：「Webサービスのインターフェイスにおけるデータ構造は変更できるが、慎重に行わなくてはならない」

　インターフェイスのデータ構造を変更するとは、すなわちインターフェイスを変更することにほかならない。だが、XML Schemaを使えば業界標準の形式で変更を定義できる。インターフェイスの変更はご法度だが、XML Schemaで定義できる範囲での変更なら許容できる場合もあるだろう。データ構造の変更可能性は、ひとえに最初のインターフェイスをどう定義したかに左右される。ここからも、インターフェイスの決定を慎重に行わなければならない理由が分かるだろう。

『第5の原則：「トップダウンのスケーラビリティ」から「ボトムアップのスケーラビリティ」へ』への反論

『「Webサービス」対応環境のスケーラビリティは、現在の誤りを犯しがちなトップダウンのアプローチではなく、ボトムアップの形式で処理される。UDDI（Universal Description, Discovery, and Integration）レジストリは単純にスケーラビリティとフェイルオーバーだけの目的で、現在のWebサービスのバックアップを見つけられるようセットアップすることができる。そして、予期せぬトラフィックが発生している場合は、システムが自動的にUDDIレジストリからバックアップサービスを見つけ出し、そのWSDLによるサービス記述（これもレジストリに保管されている）を入手して、瞬時にバインドすることができる』

　いったい何年前の話をしているのか？ このような動的なサービスのバインドが実際には困難であることはすでに業界の常識だ。いつもの取引先がたまたま仕事が忙しく、こちらの納期までに部品を用意できそうにないとき、急にほかの部品工場に必要な部品を発注することなどできないのだ。たとえ社内のほかの部門で以前にその工場と取引したことがあったとしても、それだけで「バックアップ」サービスと見なすのは非常に困難だ。

　UDDIから提供される先にあるWebサービスなら、品質や内容、利用条件にまったく差がないのか？ そんなはずはない。UDDIにスケーラビリティを求めるのは無理な相談だ。「バックアップ」サービスとしてUDDIから返されたものが、実はダイヤルアップで運用されているサービスだったらどうなるのだろうか？ UDDIに登録されている情報の更新はだれが責任を持つのだろうか？

　そこで筆者の第4の原則はこうなる。

■第4の原則：「Webサービスの提供者と利用者は、サービス・レベルについて合意（SLA）しなければならない」

　あらかじめService Level Agreement（SLA）を交わした相手とだけサービスを提供すべきだし、利用すべきだ。他社のサービスを使っていて何らかの不具合が発生したときに、その責任がどこにあるのかをはっきりできなければ、企業レベルのシステムは構築できない。UDDIに「バックアップ」サービスの所在が書いてあるかどうかなど、企業システム構築という観点からは問題ではないのだ。

『第6の原則：「プラットフォームへの依存」から「プラットフォームからの独立」へ』への反論

　Bloomberg氏はサービスの開発とサービスの利用を混同している。MicrosoftやIBMが主張しているのは、サービスの開発プラットフォームとして自社の製品や技術が最適であるということだ。

「サービス指向の開発がプラットフォームの問題全体を完全に無意味なものにしてくれるであろうことを考えると、いま始まろうとしている戦いは何とも皮肉なものである」

　この主張はまったく的を射ていない。開発プラットフォームと実行プラットフォームの選択という問題と、サービスへアクセスするうえで必要となる前提は分けて考える、というのがWebサービスのメッセージであり、この点に異論のあるベンダはないはずだ。これまで問題だったのは、サービスの開発者側が選んだプラットフォームは、自動的に利用者側のプラットフォームを強制してしまうということだ。Microsoftを攻撃するときに使われる「抱え込み」というフレーズはまさにこの状況を指している。Webサービスはその抱え込みを不可能にした。サービスが開発されたのが何であれ、利用者は好きな開発環境からそのサービスにアクセスできるのだ。それがWebサービスの利点だし、そのことはBloomberg氏自身何度も主張しているにもかかわらず、このような原則を掲げたり、皮肉顔をしたりするのは筆者にはまったく理解できない。

　Webサービスを名乗る限り、利用者にプラットフォームを強制できないのだから、ここには何の原則もない。Webサービス万歳！ とでもいっておこう。

『第7の原則：「独裁制ソフトウェアモデル」から「連邦制ソフトウェアモデル」へ』への反論

　この原則の内容は、ここまでの6つの原則をいいなおしているだけだ。中身は何もない。インターフェイスにのっとった通信をする限り、サービスはサービスで、それを利用するクライアントはクライアントで、独立して開発できるということがBloomberg氏のいう連邦制であり、それがWebサービスによって実現できることには、筆者も異論はない。

今後の展望

『筆者が明確にしたこれら7つの原則は、このようなシナリオの輪郭を効果的に描いている。これらが力を合わせれば、ソフトウェアアーキテクチャと開発の将来に関するインテリジェントな予想に必要な状況を実現することができるだろう』

　読者の皆さんは、Bloomberg氏の原則を「明確」に理解できただろうか？ 筆者は正直にいって余計にもやもやしてしまった。

　筆者の今後の展望は、Bloomberg氏のそれよりももっと明確だ。

■Webサービスはまず企業内の既存システムを統合するために使われる。

　企業はまず、自社内という実験場でWebサービスによるシステムの統合の可能性を試すはずだ。企業はこの「実験」を通じて、インターフェイスを効果的に定義する方法、実装に最適なプラットフォームなどのノウハウを得るだろう。

■多数の無償WebサイトがWebサービスのインターフェイスも「併せて」提供するようになる。

　GoogleやAmazonがよい例だが、問題になるのは広告収入だ。サービスにはUIがないので、広告を見てもらうことができない。広告収入は多くの無償サイトにおいて第1の収入源だ。広告モデルの限界は以前から指摘されているので、これに代わる新しいビジネス・モデルを考えなければならないだろう。例えばAmazonは、より多くのアプリケーションで自社サイトの商品を宣伝してもらうためにXMLのインターフェイスを公開している（アソシエイト・プログラムという）。この場合は、自社サービスへのインターフェイスを無償で提供しても十分ペイするだろう。Googleの場合はもっと複雑だ。Googleは、そのWebサービスAPIに定義されている「ライセンス・キー」を使う方法を模索しているに違いない。

　現状で筆者が考えられるのはこの2点だ。その先のリアル・ビジネスへの適用にはまだまだ課題が多い。今の時点で何かを予想しても鬼に笑われるだけだろう。

---

吉松 史彰（よしまつ ふみあき）
　インフォテリアにおいて、.NET FrameworkやXMLを活用したシステムの開発とコンサルティングを行っている。また、個人でも執筆や講演活動を通して.NET Frameworkの啓蒙活動をマイクロソフトに黙って勝手に行っている。

「Insider.NET - Opinion」

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