The Rational Edge

ソフト開発の変革というWebサービスの可能性
−変革をもたらすための7つの原則−

Jason Bloomberg
Senior Technologist
Ashton Services
2002/5/2

---

　ドット・コム・バブルの崩壊以来、「Webサービス」はソフトウェア業界で群を抜く熱い話題となっている。しかし、その何がこれほどまで騒がれているのか、いまだ見えにくいと感じている読者も多いのではないだろうか。

　SOAP（Simple Object Access Protocol）やWSDL（Web Services Description Language）といった「Webサービス」技術には、取りあえずは統合プロセスの簡略化が期待できる。特に基幹業務レベルでのシステム統合に簡略化が求められていることは絶対に間違いなく、この分野への適用が期待できる。何しろ、大規模ソフトウェアプロジェクトでは新旧システムの統合だけで経費の最大75％もが費やされるケースが多々あるのだ。

　EAI（Enterprise Application Integration）プロジェクトの最前線にいた方なら、ラッパ（異種システム間の通信を可能にする専用のコード）の構築がいかに大変かをご存知だろう。しかし、「Webサービス」はそれを簡略化する可能性をもっている。ラッパコードをXMLベースの標準インターフェイスにまとめることができるからだ。そうなれば、すべてのラッパコードが同じ標準に準拠して統合が簡単になり、それに伴ってコストも低下するようになる。

　最終的には統合コストを削減するだけにすぎなくても、「Webサービス」にはその苦労に見合う価値が確実にある。しかし、もし期待できるものがこれだけならば、これはソフトウェアエンジニアリングの分野においては比較的小さい進化の過程の1つにすぎない。だが心配は無用だ。Rational Edgeの「Web Services：Opening Soon for Business」をお読みいただければ、まだまだ初期のレベルにある「Webサービス」には今よりもはるかに明るい未来が待っていると筆者が確信していることはお分かりいただけると思う。

　読者には、次のことを念頭に置いて本稿をお読みいただきたい。今日の新しい「Webサービス」対応開発ツールは（これまでのツールと比較して明確に成熟し、洗練されてはいるものの）パワフルな「Webサービス」アプリケーションを構築できるまでには完成されてはいない、ということだ。しかし、これはツールに落ち度があるわけではなく、むしろ現在のソフトウェア開発そのものが抱える制約によるものなのだ。

サービス指向開発の7原則

　ソフトウェアの開発は、初期の手続き型プログラミングの時代から大きな発展を遂げてきた。オブジェクト指向の分析やデザインが分散オブジェクトフレームワークへとつながり、これが次には今日の分散コンポーネントフレームワークへとつながった。「サービス」指向の開発様式はこの発展の過程として必然なのだ。しかし、デベロッパがオブジェクト指向テクニックの完全な習得のために手続き型プログラミングを「捨てる」必要に迫られたように、「Webサービス」が要求するであろう新しいサービス指向の開発原則を導入するためには、やはり同じことが必要となる。

　過去の考え方から脱却するため、ソフトウェアのプロは新しいツールの機能を理解するとともに、これによって構築可能なものの全体像を把握する必要がある。以下に説明するサービス指向の開発原則（新旧の考え方の変化として説明していこう）は、事実上、理解度を一段引き上げるためのガイドラインだ。

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

　コンポーネントベースのソフトウェア開発では、コンポーネントの構築と統合に焦点を当てて開発が行われる。開発者がコンポーネントを構築するときは、システム全体の仕様を理解し、さまざまなコードの部品を組み合わせる。そして、ソフトウェアが仕様どおりの動作をすれば、開発者の役割は果たされたことになる。

　だが、「Webサービス」の場合は、開発者は、従来と同様に仕様どおりのサービスを構築するだけでは役割を果たせない。なぜなら、図1に示されるように、「Webサービス」はその機能を動的記述によって定義するからだ。動的仕様はWSDLで記述されている。「Webサービス」を利用するソフトウェアは、WSDLファイルだけで機能仕様を知ることができる。

図1　動的記述とコンポーネントによって示される動的Webサービス

　この原則から派生する最も重大な問題の1つが、「Webサービス」を利用するシステムの中ではビジネスロジックと表示のロジックを分離させなければならないというものだ。「Webサービス」を構築する場合、デベロッパにはこの「サービス」が呼び出される方法や、呼び出す側のソフトウェアのユーザーインターフェイスがまったく想像できないことがある。多階層システムはユーザーインターフェイス層、ビジネスロジック層、そして接続層とに分離されているものだが、多階層化の必然性のないシステムの場合でも、扱いやすさや再利用のメリットを基準にして、システムが分離されることがある。従って、再利用性や扱いやすさを失う以上のメリットがあれば、設計者は各層の機能をある程度混合させる場合もある。しかし、「Webサービス」ではそれが許されない。

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

　今日における統合化へのアプローチはシステムレベルの要件定義から始まる。システムが本来何をすべきかによって、設計者は各種コンポーネントとその統合方法を計画する。「サービス指向開発」では、このトップダウンのアプローチを採用する代わりに、ボトムアップのアプローチを採用する。システムの各コンポーネントは、システムアーキテクチャが整う前にすでに「Webサービス」として公開されているわけだ。そして、各サービスはリフレクションを使用し、カプセル化されたサービス内のデータや機能にアクセスすべく必要な情報を外部システムに提供する（呼び出す側のソフトウェアが、インターフェイスに関する情報を「サービス」に対して問い合わせられるようにすることを「リフレクション」という）。

図2　サービス指向による開発は、従来の密なシステム統合とは違い、「サービスの公開」によってサービスが構成される

　サービス指向の開発手法を用いてシステムを構築する場合、設計者は図2で示されるようにシステム要件から着手してサービスの組み立て工程へと進む。サービスの組み立てとは、そのシステムに適したコンポーネントを特定することに該当するが、「Webサービス」環境では設計者がサービスの動的仕様を利用できる点が異なる（「第1の原則」参照）。動的サービス仕様が特定されていれば、個々のコンポーネントとそのインターフェイスが完全に記述されておらず、記述が実行時までずれ込んでも、設計者はシステムの構造を決めることができる。

　第2の原則には重要な特徴が2つある。第1に、それぞれのデータソースや業務オブジェクトがWebサービスとして公開されれば、デベロッパはシステムがその「サービス」にどのようにアクセスしたり利用したりするのかを知っておく必要がない。第2に、システム設計者がシステムを計画する場合、これらのコンポーネント（アプリケーションやプラットフォームなど）が持つ本来の性質は意味を持たなくなってしまう。

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

　再利用性を念頭に置いたコーディングは、オブジェクト指向プログラミングの柱の1つだ。一度書いたコードを何度も利用することは、費用と時間の両方の節約になる。だが実際には、再利用可能なコードを書くことは一度しか使わないアプリケーションのコードを書くよりはるかに難しい。再利用可能なコードを書こうとすると大きな問題が3つある。

1. 単発のコードを書くよりはるかに多くの時間がかかる
   
2. コードが実際に再利用可能になる保証がまったくない
   
3. デベロッパが作り出したものがカスタマの要求に合致しない場合がある。それは、多くの場合、デベロッパにはコーディングを終了するタイミングさえも分からないほどだ

　このような理由から、XP（eXtreme Programming）などのアジャル（機敏）なソフトウェア方法論では、コードの再利用を避けている。XPでは、デベロッパはカスタマが実際に必要とするものだけをコーディングし、カスタマは積極的に開発チームに参加してユーザーテストを実施したりして方向性を示す。そして意図しない機能が組み込まれそうになった場合は、デベロッパがコードのリファクタリング（可能な限りシンプルになるまでコードを書き直すこと）を行うことになる。

　リファクタリングによって、それまでコードが重複していたすべてのケースを処理できる汎用性を持たせるまでコードを合理化する。本質的に、リファクタリングはある種の再利用に向けた開発作業だといえる。しかし、リファクタリングは柔軟かつ広範囲に適用できるコードの作成を目的としており、再利用に向けた従来のコーディング作業とは異なる。

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

　「Webサービス」の開発は、ユーザーの意見を積極的に取り込む継続的かつ反復的プロセスであるべきだ。そしてサービス自体は、複雑ではなく利用しやすいシンプルなかたちで構築すべきである。そのためには、デベロッパはリファクタリングによってコードをできるだけ幅広く応用できるように努める必要がある。

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

　モジュール性は再利用性とともに、オブジェクト指向プログラミング、そしてコンポーネントアーキテクチャ一般にとっての基本原理だ。システムにモジュール性があれば、システムを構成する個々のコンポーネントは、そのシステムのほかの部分に影響を与えることなくアップグレードもしくは交換できることになる。モジュール性は、技術知識のほとんどないビジネスユーザーでさえも理解できるほど理にかなっていることは絶対に間違いない。だが残念ながら、今日のエンタープライズコンポーネントアーキテクチャにおいてはモジュールをあまり目にすることができないのが現状だ。

　問題なのは、複雑なシステム中のコンポーネントの交換もしくはアップグレードが決して人々が期待するほど簡単でも低コストでもないことだ。多くの場合、システムコンポーネントは完全にはカプセル化されていない。設計者が慎重に設計したにもかかわらず、カプセル化を意識してデザインされたインターフェイスを無視し、外部のモジュールと接続する仕掛けがシステム内部にあることも珍しくない。さらに、APIの中に意味的にあいまいな部分がある場合もある。例えば、古いコンポーネントのgetQuantity()メソッドではボックスの数を返すのに、新しいコンポーネントではパレットの数を返すという場合がある。そしてもちろん、代用として新たに搭載されたAPIが古いものと異なることも多々あり、その場合は相当量の再統合作業が必要になってくる。

　モジュール問題の泥沼を解決することは、サービス指向開発の主な目的の1つだ。単純にAPIを公開するのではなく、「Webサービス」にラップされたコンポーネントが動的サービス記述を公開するのである。基盤のAPIが変更されても、WSDLによるサービスの記述が自動的に調整され、システムのほかのコンポーネントは実行時にこの変更に合わせることができる。現在では異なるロジック層の分離が推奨ではなく要求されているため、「Webサービス」のカプセル化を破壊するような仕掛けはかなり減っている（もちろん、デベロッパはいままでどおりルールを破って粗悪なコードを書くこともできるが、サービス指向開発の原則に従うことでこのような仕掛けは不要になっていくだろう）。

　状況が落ち着き、サービス指向開発が意図されたように機能し始めれば、大企業はコンポーネントベースアーキテクチャによって作られたシステムのアップグレードが、臨機応変に実施できることに気付くようになる。膨大な期間とコスト、そして数時間から数日のダウンタイムが要求される今日の古いアップグレードプロジェクトと異なり、Webサービスとして公開されたコンポーネントのアップグレードは日常のメンテナンス作業の範囲内に収まるリスクの低い作業になっていく。ビジネスの観点から見ると、大企業のアーキテクチャはこれで最新の状態を維持し、必要に応じて自らをスムーズにアップグレードできるようになる。

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

　トラフィックが突如急増するeビジネスシステムの拡張を依頼された設計者ならだれでも、スケーラビリティの確保が複雑な作業であることは十分に承知している。結局のところ、現時点ではスケーラビリティは十分な時間的余裕を持って慎重に計画しなくてはならないものなのだ。設計者はまず予想使用率パターン（平均およびピークの両方）を考慮し、これらの予想値を使ってロードバランスとフェイルオーバーを計画する。ただし、システムのボトルネックには特に注意する必要がある。1000ページ規模のWebサイトでは、数カ月間スムーズに動作しても、ある1ページがニュースで紹介されると、それによって生じるトラフィックの急増がサイト全体をダウンさせてしまう場合があるからだ。

　「Webサービス」対応環境のスケーラビリティは、現在の誤りを犯しがちなトップダウンのアプローチではなく、ボトムアップの形式で処理される。UDDI（Universal Description, Discovery, and Integration）レジストリは単純にスケーラビリティとフェイルオーバーだけの目的で、現在のWebサービスのバックアップを見つけられるようセットアップすることができる。そして、予期せぬトラフィックが発生している場合は、システムが自動的にUDDIレジストリからバックアップサービスを見つけ出し、そのWSDLによるサービス記述（これもレジストリに保管されている）を入手して、瞬時にバインドすることができる。さらに、このバックアップ用の「Webサービス」へのアクセスを提供するUDDIレジストリは、システムがバックアップ「Webサービス」に関してレジストリに問い合わせ、そのレジストリには適切なサービスに関する情報を持っていなくても、ほかの同種のUDDIレジストリに探しにいくように、再帰的なコンフィグレーションにすることも可能だ。これにより、情報を必要としているシステムは必要な追加「Webサービス」が見つかるまでレジストリを次々にジャンプしていくことができる。

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

　CORBAやWindows DNAなどのかつてのサービス指向アーキテクチャは、プラットフォームの独立性に関しては何も実現してこなかった。当然ながら、Windows DNAは潔くWindows専用のアーキテクチャとしているし、理論的にはプラットフォームに中立のCORBAも、実際には主に単一プラットフォームのインプリメンテーションでのみ高い費用対効果を達成することができる。

　大企業レベルでは、EAI（Enterprise Application Integration）がクロスプラットフォームソリューション構築のための有力なアプローチとなっている。各EAIソリューションは通常、一方でユーザーインターフェイスをサポートし、もう一方でバックエンドにある古いデータソースやさまざまな業務コンポーネントをサポートする各種コンポーネントとアプリケーションサーバとの間に位置する「バス」からなっている。各EAIバスは同期および非同期の両通信をサポートすることができ、多くの場合これらのバスには洗練されたトランザクション処理機能も用意されている。しかし、EAIが大企業によるクロスプラットフォームアーキテクチャの構築を可能にしてくれる一方で、アーキテクチャはどれもコストが非常に高く、EAIソフトウェアだけでも数十万ドルに達するが、EAIのインプリメンテーションに関連する統合コストはこの比ではない。問題は、EAIのインプリメンテーションプロジェクト関連の実質的な作業（つまりコスト）が各種コンポーネントシステムとEAIバスとのインターフェイスを可能にするラッパの構築であることだ。従って、結局のところはEAI関連の大半の作業が実際にはプラットフォームに依存した開発作業となっている。

　「Webサービス」が注目を集めた理由としては、これらがEAIの費用をうまく回避する方法を提供してくれるという部分が大きい。今日、「Webサービス」の世界で最も論争を巻き起こしている問題がプラットフォームへの依存であるのはかなり皮肉である。米マイクロソフトの.NET構想もやはり潔くWindowsベースのアプローチを採用しているのだ。今回IBMが先頭に立つJava／J2EE陣営は全面的な防戦態勢を整え、ワシントン州レッドモンドに展開する敵との大規模なプラットフォーム戦争に備えている。サービス指向の開発がプラットフォームの問題全体を完全に無意味なものにしてくれるであろうことを考えると、いま始まろうとしている戦いは何とも皮肉なものである。

　自分のインターフェイスを使って自分の機能を公開するプラットフォーム上に、コンポーネントを構築するのがコンポーネントベースの考え方だ。そして、コンポーネントはそれぞれのインターフェイスにアクセスすることで相互に連動する。基本的に、コンポーネントはボールをけり合うサッカー選手であり、プラットフォームがサッカー場となっている。従って、別々の競技場にいる2人のプレーヤが競うことが難しいのはいうまでもない。

図3　「サービス」指向の開発がプラットフォームの独立性につながる

　一方、図3のように動的に記述され、必要なときに瞬時に探して呼び出せるサービスでソフトウェア環境全体を構成するのがサービス指向の考え方だ。本来の意味でのプラットフォームの代わりに、いまはXML（これはマークアップ言語にすぎないが、拡張性があるため何でもこれに参加できるようになる）がサッカー場となっている。いまのところ、しばらくはプラットフォームがなくなることはないだろう。結局はWebサービスもソフトウェアであり、サービス指向の環境にユーザーインターフェイスを提供するシステムは今後も必要だ。従って、J2EEと.NETはユーザーのいる周辺へと追いやられ、Webサービスのほかに、これらの「サービス」へのアクセスでユーザーが必要とするデスクトップやブラウザなどの各種インターフェイスを書くために必要なインフラを提供することになるだろう。だがこの騒動の中心では、XMLというサッカー場の中で唯一Webサービスだけがボールを追うことになる。

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

　Webサービスが持つ疎結合の特長によって、統合の問題（第2の原則）やモジュール性の問題（第4の原則）など、融通の利かないAPIを持つコンポーネントベースアーキテクチャの密結合が原因となって発生する問題の多くが解決されるだろう。しかし、サービス指向開発が持つ疎結合などの原則は、ソフトウェアの世界にそれ以上に重要な影響を与えるようになるだろう。

　従来のエンタープライズソフトウェア（米シーベルのコアCRM製品など）はデータベースレベルで統合され、相当な密結合によるアプリケーションスイートを実現している。コンポーネント技術が成熟する中で、エンタープライズソフトウェアベンダ各社は自社のソフトウェアをオブジェクト指向の原則に従って構築する傾向が強く、密結合であることに変わりはないものの公開API経由で通信を行うようになった。

　設計者はこれをさらに発展させ、動的に記述されたWebサービスを集めて整理することでエンタープライズソフトウェアを開発できるようになるだろう。それには単にコンポーネントベースのアーキテクチャを利用し、RPC（リモートプロシージャコール）やメッセージングプロトコルとしてSOAPを使うだけにとどまらないだろうが、ここまでが多くの企業にとっての限界だ。

　サービス指向開発の7つすべての原則を理解するソフトウェアベンダは、疎結合でつながった「サービス」（その多くはUDDIレジストリから瞬時に見つけてくるし、社内開発されていないものもある）で構成されるエンタープライズソフトウェアを公開することになるだろう。時がたつにつれ、このようなエンタープライズパッケージを構成するさまざまなWebサービスは、デベロッパが臨機応変にアップグレードを実施する中で日々変化するだろうし、Webサービスを必要に応じて集めることで、実行時にシステムがスケールアップ／ダウンする。基本的に、未来のエンタープライズソフトウェアベンダは今日のベンダ各社とはまったく異なるモデル（アーキテクチャおよびビジネスの両モデル）を採用することになるだろう。

今後の展望

　ここまで述べてきた原則の多くは、確かにまだ導入できていない。もしかすると、あと最高5年はかかるかもしれないが、中には大幅に早く導入されるものもあるだろう。次期製品のリリースを計画しているソフトウェアベンダ各社は、製品を市場に投入するまでに必要な開発期間を考慮し、1年以上先を考える必要がある。1年先を見ることは未来を予言することを本質的には意味するし、これが誤りを犯しがちな試みであることは周知の事実だ。しかし、今後の変化について特定の仮定がある場合は、1つのシナリオ（発生の可能性が高い論理的に組み立てられた予想される一連のイベント）に照らして合わせて作業を進める方が信頼性は高い。

　筆者が明確にしたこれら7つの原則は、このようなシナリオの輪郭を効果的に描いている。これらが力を合わせれば、ソフトウェアアーキテクチャと開発の将来に関するインテリジェントな予想に必要な状況を実現することができるだろう。筆者がここで概要を説明したものはすべて実現するかはまだ分からない。本稿はソフトウェア関連の労力を集中させる場所の判断を支援する議論を喚起するだろうか？ そう願いたいものである。

IT Architect 連載記事一覧

本記事は「The Rational Edge」に掲載された「Web Services and a New Approach to Software Development 」をアットマーク・アイティが翻訳したものです。