 |
≫ |
|
|
|
|
|
聞き手 |
先ほどWebサービスの話が出ましたが、SOAはWebサービスと同じものなのですか？ |
|
|
西村 |
先ほどは話を簡単にするために厳密な言い方をしなかったのですが、実はSOAとWebサービスはまったく異なります。何が異なるのかというと、言葉の位置づけが異なるのです。
まず基本的な考え方として“サービス指向”というものがあります。この考え方に基づいたアーキテクチャがSOAです。Webサービスはサービス指向を実現するためのひとつの技術です。SOAとWebサービスはいずれも“サービス指向”というコンセプトに基づいていますが、SOAはそれを具現化するための手法全体を意味し、Webサービスはその手法を支える技術を意味しているのです。 |
|
|
|
|
|
| ● サービス指向 (Service Orientation) |
・・・ |
基本的な考え方、コンセプト |
|
| ● SOA (Service Oriented Architecture) |
・・・ |
アーキテクチャ、技法、工法 |
|
| ● Webサービス (Web Services) |
・・・ |
技術 |
|
| ● SOAP (Simple Object Access Protocol) |
・・・ |
プロトコル |
|
|
|
|
|
|
聞き手 |
SOAPという言葉もありますね。 |
|
|
西村 |
SOAPはSimple Object Access Protocolの略で、これはプロトコルを意味します。WebサービスはSOAを支える技術基盤ですが、SOAPはさらに下の、Webサービスを構成するひとつの要素です。 |
|
|
|
|
聞き手 |
なるほど、これらの言葉は混同して使ってしまいがちですが、明確に意識して使い分けなければいけませんね。 |
|
|
西村 |
そのとおりです。「Webサービスを使っているからSOAだ」という議論を見かけることも少なくありませんが、Webサービスを使っているからといってSOAが実現されているとは限りません。「そもそもサービス指向とは何なのか」を理解しておかないと、SOA導入もうまくいかないのです。 |
|
|
|
|
聞き手 |
先ほど「SOAはレゴブロックのようなもの」というお話が出ましたが、その大本のコンセプトである“サービス指向”とは、どのような考え方なのですか？ |
|
|
西村 |
これも従来型のシステム開発と比較するとわかりやすくなります。従来型の開発では「いかに良いソフトウェアを合理的に作るか」に軸足が置かれていました。プログラムの構造化やオブジェクト指向といった取り組みは、この“合理的に作る”という発想から生まれたものです。
これに対してサービス指向の開発では「いかに他人の作ったソフトウェアを合理的に使うか」「いかに他人に使われやすいソフトウェアを作るか」に軸足を置きます。いくらすばらしいソフトウェアを作っても、それが他の人に使われなければ意味がないのです。 |
|
|
|
|
|
「いかに他人の作ったソフトウェアを合理的に使うか」 |
|
|
「いかに他人に使われやすいソフトウェアを作るか」 |
|
|
|
|
|
聞き手 |
製品と商品の関係に似ていますね。従来のアプローチでは良い“製品”を作ることを目標としていたのに対し、サービス指向では良い製品であるだけではダメで、他の人に喜んで買ってもらえる“良い商品”にしなければならないというわけですね。 |
|
|
西村 |
それは面白いたとえですね。確かにその通りです。サービス指向ではソフトウェアそのものの優秀さ以上に、他人にとっての使い勝手の良さが重要になるわけですからね。 |
|
|
|
|
聞き手 |
それでは使われやすいソフトウェアとは、どのようなものなのですか？ |
|
|
西村 |
大まかにいって、5つのポイントがあります。
まず第1に、独立性が高いこと。他のサービスと連携できることはもちろん必要なのですが、その連携の形が“密”ではなく“疎”である必要があります。いわゆる“疎結合”ですね。例えばあるサービス機能を利用する時に、その機能を使う側がサービス機能と同じコンピュータ上になければならない、といった制約がある場合には疎結合とはいえません。
第2は外部仕様が明確化されていること。外部仕様とはそのサービスの“使い方”の定義ですが、これがはっきりしなければ使いようがありません。
第3は見つけやすいこと。いくら素晴らしい機能を提供するサービスでも、それがどこにあるのかわからなければ、やはり使いようがありませんからね。
第4は内部構造が隠蔽され、カプセル化されていること。これは言い方を変えれば、中身がわからなくても使えるということです。自動車の運転をするのに、エンジンの中身まで知る必要はありません。これと同じことです。実は内部構造の隠蔽は、外部仕様の明確化と表裏一体の関係にあります。
そして第5がハードウェアなどの動作環境もセットで用意されていることです。ソフトウェアだけ用意するのでは不十分なんです。そもそもサービスとは“機能を提供するもの”です。ソフトウェアだけ用意しても、それを動かすハードウェアがなければ、機能を提供することはできません。 |
|
|
|
|
|
| ● 他とは疎に連携して独立性が高い |
|
| ● 外部仕様が明確化されている |
|
| ● 見つけやすい |
|
| ● 内部構造が隠蔽され、カプセル化されている |
|
|
|
|
|
|
聞き手 |
なかなかハードルが高そうですね。 |
|
|
西村 |
でもこのうちいくつかのポイントは、Webサービスを利用することで実現できるんです。Webサービスは、SOAP、WDSL、UDDIといった要素で構成されていますが、疎結合はSOAPで実現できますし、外部仕様の明確化はWSDLで実現できます。また見つけやすさはUDDIで可能になります。
実はSOA導入の本当の難しさがあるのは、技術的な部分ではありません。むしろ導入する組織や人の考え方やアプローチにこそ、SOA導入の成否を分ける鍵があります。 |
|
|
|
|
聞き手 |
それはどういうことでしょうか。 |
|
|
西村 |
SOAを導入することは手段であり、目的ではありません。当然ながらその技術に過ぎないWebサービスを導入することも、目的ではないのです。しかしシステムから発想してしまうと、Webサービスの導入やESB（Enterprise Service Bus）やBPM（Business Process Management）の導入が目的になってしまうことが珍しくありません。目的はあくまでも、ITとビジネスのスピードをシンクロさせ、ビジネスの成長を加速させることです。SOAはそのための手段に過ぎないということを、はっきりと意識すべきです。 |
|
|
|
印刷用画面へ
