WebサービスとSOAに関する議論

はじめまして，てんちょ と申します。

自分が提供したい/することをどうサービスとしてどうまとめるかということが「サービス志向」のネックだと思っています。しかし，サービスをしっかり作るのはいいのですが，一度サービスを定義し，公開してしまえば修正/変更は困難っていうのはすごく窮屈な気がします。

私の個人的な考えですが，どうせサービス提供者が作って提供しているものなのだから，サービスの修正/変更方法に関しても定義できて，かつ(修正/変更可能な場合)自動修正/変更の枠組みを作ってみたいなぁと思っています。サービス利用者(すでにシステムの一部として動作していると思いますが)は自然とサービスの修正/変更を受け入れるというような感じができればなぁと思っています。

全然話の流れが違うようになってしまってすみません。

TrackBackいただいた「カフェ日誌」「NeonsWiredSymphony」「chika watanabe」の皆さん、そしてコメントいただいたyamさん、Masayoshi Yasudaさん、Thorさん、Psychsさん、吉松さん、そしてTrackBack先と行ったり来たりでコメントいただいたchikaさん、ありがとうございました。

このあたりの話題は、やはりエキサイティングですね。皆さんのコメントを見ていると、色々な発見があります。また、それぞれが自分の主張を強く持っていることに、心強さを感じました。

このテーマに関しては、まだ拙速な着地点を見つけられなくてもいいと思っています。それぞれの信念をそれぞれに実践し、学んだことをぶつけ合えるといいですね。

また別のネタがあれば取り上げてみますので、そのときにもまた是非よろしくお願いしますね。

あと先ほどエントリしましたが、オフラインミーティングもやりますのでご都合のつく方はぜひご参加ください。

トラックバック先に長文コメントいただきありがとうございました。

ちょっとすれ違ってるかなぁ、という感じがしたところもありましたが、概略わかりました。

なお、IBMのweb fountainはセマンテックウェブの話じゃないの？なんでこの文脈で出てくるの？というご質問を頂きましたが、web fountainはセマンテックウェブ的「意味空間」の解析をwebサービスインターフェースで提供するもの。
「webサービスという「技術」だけでは、将来的にはあんまり儲からないかもね、だからコンテンツつきで売るね」
ということだと思います。
（もちろん、IBMにとっては、SOA時代到来への一手段でしょう。IBMのOn Demand Groupの今後の予算は確かどこかで100億ドルと聞いた気が。web fountain開発費用はその100分の1に過ぎません）

とここまで書いて思ったんですが、もしかして江島さんの主張は
「webサービスの技術だけ売っていても商売にならない」
ということですか？だったら、全くもって納得です。

全然関係ないですが、ちょっと前"semantic web"とGoogleで検索したら、Googleの求人広告が出ました。やっぱりねーって感じですけど;-)

SOAを成功させる鍵は、Web Servicesといったインタフェース「技術」だけに依存する訳ではなく、セマンティックの統合であり、high-latency and low-fidelity (Gartnerのいうcoarse-grainedと近いと思います)なサービスの実現である点、合意します。大規模、複雑、スパゲッティ、部門断絶な状況に置かれている現状のエンタープライズ・システムにおいて(とりわけ実質的なCIOの存在しない日本において)、このような課題をどのようにアーキテクトしていくかが大事だと思っています。

吉松です。本題とあっているのかどうかすら怪しいですが、私の記事が取り上げられているようなので、コメントをば。

現在の私の理解によると、「サービスを意識したコンピュータシステム（の作り方）」において重要なフレーズを1つだけ挙げるとするならば、それは

Services assume high-latency, and low-fidelity connectivity.

だと思います。これはSOAPという機械的なものにも当てはまるし、標準化団体や企業間／部署間／担当者間に代表される人間的なことにも当てはまります。これを疎結合と言うならそうかもしれませんし、密結合と呼んでも正しいのかもしれません（だからcouplingという言葉では議論しづらい）。リンクいただいたオピニオン記事で私が書いた「アウトソース先を取り替えられる」という文章には、UDDI＋WSDLによる自動処理という意味はないです。宅配業者というのがある種、統一的インターフェイスを持つ枯れた業界であるために誤解を招きやすかったかもしれませんが、HTTP/XML/SOAPは、シンタックスにコストをかける必要がなくなったこと*だけ*を意味していて、現実のビジネスを動かすコントラクトとポリシー（セマンティクスと言い換えられるか？）の開発・運用コストが下がるということは意味しません。その意味では、巨大パッケージソフトを持ちさえすれば、コンピューティングを意識せずにビジネスの要件だけに集中できるとする発想と、実は大して変わらない、とも言えるのでしょう。

一時期、Webサービスによってシンタックスだけではなく、コントラクトとポリシーの「標準化・抽象化」が可能になり、それがWSDL／UDDIによって運用されるという物語が語られたことがありました。Webサービス懐疑派の中には、そのようなナイーブな議論を非現実的と切り捨てて、そこからWebサービス全体を「バズ」とする結論を導く方も少なくないようです。しかし、「サービスを意識したコンピュータシステム（の作り方）」を現在推進しようとしている面々も、それがナイーブであるという点についてはすでに同意済みです。一方で、シンタックスに関する技術はほとんど「Done」であり、そのスペックをあれこれ議論する必要がもはや薄れていることも明らかになりつつあります。すでにプロトコル層はできた、アプリケーション層に注力していこう、という態度の1つの表れが、先日MSグループとIBMグループから別々に発表された「イベント」に関するスペックであると理解できます。

サービスが自律ドメインで運用される（そうでないのが巨大パッケージ）以上、コントラクトとポリシーはサービスごとに異なるものになります。それが異なるということ自体はこれまでと変わりません。これまでの考え方と、「サービスを意識したコンピュータシステム（の作り方）」の考え方との違いは、サービスごとにそれが異なるにもかかわらず、コントラクトとポリシーをすりあわせるための活動が「high-latency, and low-fidelity」に行われること（行われないこと？）です。それが「high-latency, and low-fidelity」である以上、過度の抽象化は高コストを招くことになります。WSDLのportTypeをJavaやC#のinterfaceにマップできたって何の意味もないのです。抽象化はコストを下げるために行われるものでしたが、今は人が行っているビジネス上のサービスを機械で実行するとなると、そのような巨大な粒度での抽象化は無意味なまでにあいまいにしかなりません。

サービスをエージェントと同一視するのも、私には疑問です。エージェントという言葉には「私のために働いてくれるあなた」というニオイがしますが、WebサービスとかSOAのSとかで語られるサービスという言葉は、それぞれ自分のために独立して働いている私たちという意味しか感じません。自分と他の自律ドメインとの境界を強硬に主張するためには、抽象化は不要です。しかし、それでも少なくとも袖を振り合う程度につながるために、なんらかのコントラクトとポリシーが必要です。

抽象化されておらず、しかも暗黙の前提条件を確立するための時間はあまり取れず（high-latency）、なおかつ前提条件が守られる保証がほとんどない（low-fidelity）という状態で、それでも接続して利用価値のあるサービスであるためには、システムのインターフェイスはどうあるべきなのか？そのインターフェイスをどう作るべきなのか？それを考えるのが「サービスを意識したコンピュータシステムの作り方を考える」アーキテクトの仕事だと思います。そしてそれがビジネス戦略に沿っているかどうかを考えるのが情報担当の役員たちの仕事でしょう。となると、この種の「アーキテクチャ」の構築というのは、それぞれのビジネスにおいて異なるはずであり、MSやIBMがちょいと考えたものを単に鵜呑みにできるはずがありません。アーキテクチャをプラットフォーム・ベンダーに語らせると、技術とビジネスの境界があいまいになってしまう、その典型がWebサービスにまつわる肯定と否定なのではないでしょうか。プラットフォーム・ベンダーがうっかり「サービス指向」とか言っちゃっている今こそ、実際のサービス企業たちが彼らから主導権を奪うチャンスとも、私は考えています。

P.S.
上記は2004/1/30時点での私の思い込みであり、私が将来にわたってこう思い込むとは限らないことをご了承ください。

すみません、お名前の表記を一部間違えました。
あと表現がおかしなところなど直して私のblogにも載せておきました。

http://www.webmagiccentral.com/mt_webmagician/jp/

吉松史彰さん(New Amazon Web Service Evangelist!)の記事、読みました。非常に正しくSOAにおける「サービス」の定義を把握されていますね。残念ながら江島さんの「サービス」は私に言わせれば、まだ「オブジェクト」と同義レベルのものです。

まずはっきりさせておきたいのですが、SOAとWeb Servicesを同義に取り扱うのはやめましょう。Gartnerもいっていますが、SOA的なアプローチは分散オブジェクト・コンピューティングという考え方ができたときからあります。またSOAはIBM MQでもSonic SoftwareでもJava Messaging Servicesでも技術的な実装は可能で実例もあります。Web Servicesを必ず使わないといけない理由はありません。

江島さん一派の方には理解頂けていない(というより理解頂いた上でそれは無理だといいたいと思いますが)、SOAでの「サービス」は以前述べたとおり、ハイ・レベルなビジネス・プロセスです。発注処理、請求処理などの言葉で表されるレベルのものであって、「オブジェクト」というときに表す発注処理をこなすプリミティブな各一ステップの実装のこととは次元が違います。

次にこのビジネス・プロセスという意味での「サービス」は実現できないという議論ですが、BPM(Business Process Modeling)というツールやBPELなどの仕様策定を一度ご確認下さい。BPMでは複数のアプリケーションやワークフローでのロー・レベルな処理を連携していくことで、一つのビジネス・プロセスを実現します。更に一部のBPMツール(例えばMicrosoft BizTalk Server 2004など)はこのようにして実装した複雑なビジネス・プロセスのインプットとアウトプットだけをWeb Services(WSDL)として隠蔽化して公開することが極めて簡単にできます。

サービスの中身の詳細を把握しないといけないので隠蔽かやSOAというのは幻想、自己矛盾というお話ですが、これは一部合意します。やはり、社内システム統合であれB2Bであれ、ビジネス・プロセスを連携する場合には、インターフェース仕様の定義及びそのバックグラウンドにある業務仕様の深い理解は必須になります。なので、SOAが実現されていくのは、まずは社内の異部門間あるいはグループ会社や密接な取引関係にあるEDIやWeb EDI(XML)を導入済みのビジネスプロセスからということになるかと思います。

他方、このような慎重な分析、要件定義を経て一度、ビジネス・プロセスをSOAのサービスとしてしまうと、それ以降複数の会社、部門、システムが利用する場合には、非常に再利用性が高く、結合が楽になります。ここにSOAモデルやloosely couplingの大きな利点があります。

次に話題を変えて、Microsoft, IBMなどITインフラ企業がWeb Servicesの普及の鍵を握る、あるいはどっちが買ってどっちが負けるといった議論ですが、余り生産性のない議論ですね(IBMが負ける可能性は高いと思いますが(笑))。Web Servicesは標準化団体によって定義されている仕様であって、別にどこのベンダーの製品がよく使われようが、それは瑣末な問題です。寧ろ重要なのは、江島さんが軽視されている、Amazon, Google, Weblogコミュニティといった利用者サイドで既に盛んな利用が始まっているという事実です。テクノロジーは所詮道具に過ぎないので、その社会での価値を決めるのは、最終的にはどれだけのユーザー(企業、個人)が利用するかです。視点を、各実業を担う企業の経営戦略、ビジネス・モデルの構築の観点から、SOA的なアプローチによるビジネス・プロセスとITを結びつけるどれだけ有効なのか、という形に切り替える必要があります。Microsoftという独自技術に非常にこだわりを持つ会社が.NET戦略でXML/ Web Servicesを共通フレームワークにせざるを得なかった社会的な背景、影響力の強さを考えてみて下さい。

以上、私見でした。

前回のコメントの後半部分については，曖昧に書いた結果，意味不明になってしまいました．まずは SOAとウェブサービスについて，もう少し率直に意見を述べておきます．

大手ベンダは，SOAという看板を押し立ててはいますが，その途上，ウェブサービスをある程度利用できた時点で SOAに対する興味は半ば失せると，私は考えています．
「これで SOAの活用は達成できた」と．

SOAが説く利点の多くは，ここから先のサービス同士のエージェント的な結びつきにあると思います．しかし，これは江島さんが前回のエントリで論じておられるように，本質的に難しい問題ですから，彼らも難しさを感じて，あきらめることになるかと思います．

その結果として，大手ベンダは SOAの部分的成功に満足する一方で，MSは破壊的イノベーションとしてのウェブサービスをうまく利用し，より本質的な SOAの実現に成功する構図が生まれる可能性があります．

さて，課題の IBMの WebSphereですね．

IBMは WebSphereを，グリッドコンピューティング，オートノミックコンピューティングのプラットフォームと位置づけていると思います．
私は，WebSphereとその開発環境の高価格化，過剰な信頼性，利便性の追求などを見ていると，IBMが自らをハイエンドに追い込んでいるように見えてしまいます．このあたりの表面構造は，Oracle 10gの方向性にとてもよく似ています．

IBMは，Eclipseをオープンソースコミュニティに提供したことは良いことですが，MSのように創業以来，破壊的イノベーションを組織内でも推進できるように組織文化を注意深く育んできたわけではありません．
そういう意味で，次のラウンドも MSの勝利になりそうな気がしています．

　皆さんが高度な議論をなさっているので、十分かと思いますが...　
以前、某所でした議論と関係があり興味深く拝見しています。

　やはり、Webサービス...という概念または定義の曖昧さによる、誤解が多いのかと思います。
http://webservices.xml.com/pub/a/ws/2002/02/12/webservicefaqs.html?page=1
"a Web service is any piece of software that makes itself available over the Internet and uses a standardized XML messaging system."
　以上であるとすると、この場で述べられているXML Webサービスというのは非常に狭義の意味でのWebサービスのようです。W3CによるSOAPの定義も変わりました。

　欧米では議論や解説を始める前にまず言葉の定義をするのが普通ですが、今回は非常に興味深い事なので、読み手を意識して分かりやすく書くとさらに共感を得られる部分も出てくるかと思われます。

　ここでのWebサービスと私のその定義が根本からずれているような気がしたので内容的に私の意見を述べるのは無意味ですが...個人的には以下の発言は少々意外でした。
”今だって、ベンダーが煽るような所謂「独立したサービスが自動的に連携されてひとつのシステムを作り上げる」という大袈裟なバラ色の未来を匂わせる「Webサービス」は全く馬鹿げていると思っている。”
Infoteria社はそのような喧伝をしている日本の頭目的な会社だと思っておりましたから...少々見方を変えなければならないのでしょうかね。

今後も期待しております。負担にならない程度に。
では。

SOAと比較すべきはオブジェクト指向設計であり、Webサービスと比較するのがオブジェクト指向によるソフトウェアコンポーネンではないですか？

まず、江島さん、あんた男だよ。ご自身の考えをきちんと整理して、反論に応えている辺り。立派です。

正直、私の駄文を真摯に取り上げて頂けただけでも感謝しています。しかし、Web Servicesと従来のオブジェクト指向RPCアーキテクチャ(CORBA, COMに代表される)が違うことはご理解下さい。参照文献はこちら。

"WEB SERVICES ARE NOT DISTRIBUTED OBJECTS" by Werner Vogels
http://weblogs.cs.cornell.edu/AllThingsDistributed/archives/000120.html

あと、SOAとWeb Servicesを同一視するのもやめましょう(江島さんは理解されていると思いますが)。GartnerはSOAはアーキテクチャ・デザインの一アプローチ、Web Servicesは実装レベルのインターフェース技術です。

MSの.NET戦略のコアにXML/Web Servicesが位置づけられている点は私も非常に注目しています。MS Office, InfoPath, それから2-3年後のLoghornでのIndigoで、ミドルウェア及びフロントオフィス・アプリへのWeb Servicesの普及はぐっと進むでしょう。

IBMの場合にはGrid Computingと絡めた面白い捉え方をしているようです。

江島さんへの反論及び実証は別の舞台で近いうちにしたいと思っています。今後もCNETでの記事を楽しみにしています。今後ともよろしくです。

メッセージングとしてのWebサービスとオブジェクト指向の最も大きな違いは、拡張に対する受け手側の許容量にあると思います。メッセージがXMLで構成されているため、新しい要素が追加されるなどメッセージが拡張されても古いメッセージの受信者はそのまま動作するはずです。

Webサービスを構築することはまぁけっこう簡単ですが、Webサービスにしたからといって、システム構築費用が
即座に削減されるわけではない。ただし、長期的な将来の拡張に対するメンテナンスコストを考えるとWebサービス
にするメリットは大きいはず。