BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース トップダウン対ボトムアップなSOAの論争が再燃

トップダウン対ボトムアップなSOAの論争が再燃

ブックマーク

原文(投稿日:2010/07/19)へのリンク

SOAコミュニティで長い間静かだった、SOAへのトップダウン対ボトムアップのアプローチについての議論が、最近再び始まった。それは、オープンソースのESB開発会社であるMuleSoftが 管理コンソールのリリースを公表した 際に、SOAの管理哲学にボトムアップなアプローチをサポートする、と言ってから始まった。

SearchSOAのRob Barry氏は、トップダウン対ボトムアップのアプローチについて、いくつか意見を集めた :

SOAを作り上げる時、ボトムアップな管理アプローチは、即座に組み立てられる、個々のESBに関わるサービスを統合することに焦点が集まる。このアプローチは、後で過度のアップデートとリワークが必要になる、と批判されてきた。一方、反対の「トップダウン」な管理アプローチは、広範囲な計画と厳しいポリシーの強制が必要である。このアプローチは、結果を出すまでに、ずっと時間がかかるので、失敗してきた。

投稿に集まった意見が一致している点は:ボトムアップは、基本的に主たる目的が統合することであるなら、始めるには良いアプローチである。トップダウン アプローチは、もっとずっとビジネスを巻き込む必要がある、ということでも皆一致している。彼らの結論は、どちらの戦略を使うか決めるのは、ビジネスとITの関係による、ということである。

Barry氏の投稿を基に、ebizQで 質問を行った ら少ないが面白い回答があった。 ebizQの質問に答えて、 Avi Rosenthal氏は、何を作るかによって、両方のアプローチを区別している:

SOAは、アーキテクチャ上のスタイルであり、アーキテクチャを作るには、トップダウンで、ボトムアップなどない。webサービスは、時々間違ってSOAだと定義されるが、技術的なことである。webサービスは、ボトムアップで作られる。SOAをボトムアップで作るのは、間違ったアプローチで、時々 ABOS (A Bunch Of Services、山のようなサービス)と呼ばれる。もしSOAをボトムアップで作ったら、おそらく、ものすごく冗長なものができ、アーキテクチャなどないだろう。しかし、SOAをトップダウンだけで作ったら、知覚的なアーキテクチャとなり、動く成果物とはならないだろう。なのでSOAの工程の一部は、ボトムアップであるべきである。まとめると:SOAの始めは、トップダウン アプローチだが、実践的なアプローチは、トップダウンとボトムアップが混じったアプローチなる。

この質問への別の回答で、 Michael Poulin氏は、SOAのコンシューマ中心の性質がトップダウンのアプローチを強制する、と言っている:

もしサービスの構築を、今持っているものから始める-ボトムアップ-と結局、持っているもので終り、コンシューマが必要とするものを作らないで終わってしまう、リスクが非常に高い。SOAは、コンシューマ中心、ビジネス指向のアーキテクチャである。コンシューマのニーズから始めれば、トップダウンを避ける可能性など無い。いつも、これが出発点だ。しかし、次の段階では、自分の能力を評価すべきである、すなわち、開発基盤を形成しているリソースの観点から、コンシューマのニーズを見るべきである。

この議論は、新しいものではない。2005年に遡って、John Crupi 氏は、投稿で、SOAは、 ビジネス駆動なアーキテクチャ スタイルであり、そうであるなら、成功するには、トップダウンでなけばならない、と言っていた:

そしてトップダウン、の意味するのは、アーキテクチャとソリューションの問題に取り組む、ということである。今持っているものから開発して、自分たちにできる新しい技術で、それを覆い隠す、ことではない。このボトムアップなアプローチは、極めて自然で、簡単だが、SOAが失敗するための完璧なレシピである。

その頃の他の意見には、Bill de hOra氏のそれに対する投稿 は、「トップダウンか失敗の原則か」の考えに反対している:

トップダウンだけのアプローチが難しいのは、トップがないことである。実際には、SOAシステムは、分散化する傾向がある - アーキテクチャ上の力や統治の中心点は無い。「10分で決めたり、次のは無料だ」と言って、実行できる人は、一人もいない。

この論争は、何年もされてきた。結局、あるツールベンダーは、ボトムアップ戦略を選んだようだ。

この記事に星をつける

おすすめ度
スタイル

BT