レベル: 初級 Bobby Woolf, WebSphere J2EE Consultant, IBM Software Services for WebSphere
2007年 8月 17日
2007年 9月 27日 更新 この記事で取り上げるのは、エンタープライズ・サービス・バス (ESB) の構築を中心に構成されたプロジェクトです。サービス指向アーキテクチャー (SOA) を目標としないプロジェクトは得策と言えない理由、そして代わりにどうすれば SOA を適切に導入できるかを説明します。
編集者からの注記: この記事は掲載されて以来(訳注: 日本語版は今回が初掲載です)非常に関心を持たれており、活発な議論が行われていて、とても感謝しております。その一方で残念なことに、この記事は、一部の読者に IBM® ではもはや ESB を重要視していないという印象を与えてしまいました。しかし、そのような印象は事実とはまるで懸け離れているのでご安心ください。この件に関する釈明については、以下に記載した Greg Flurry と Kyle Brown による囲み記事を参照してください。
はじめに
全体として SOA を使用する代わりに、エンタープライズ・サービス・バス (ESB) アーキテクチャーだけを実装してプロジェクトを完成させたいというクライアントからの要望が次第によく聞かれるようになってきています。このような ESB 指向のアーキテクチャーを思い描くのは簡単ですが、それが成功したかどうかを測るのは難しいことです。この類の要求をしてくるクライアントは、ESB 指向アーキテクチャーがビジネスの価値を生み出すことはないということを理解していません。プロジェクトが上手くビジネス価値をもたらすようにするためには、ESB 指向アーキテクチャーをベースとしたプロジェクトを SOA ベースのプロジェクトに変える必要があります。
ESB アーキテクチャーだけを使用した場合
SOA がベースとするのはビジネス要件です。SOA は IT と ビジネスを連携させ、IT システムがビジネスと同じように機能して確実にビジネス価値を生み出せるようにします。詳細については、IBM ホワイト・ペーパー「IBM SOA Foundation: An architectural introduction and overview」を参照してください (「参考文献」セクションにリンクを記載)。
 | | Bobby Woolf はこの記事で、SOA の中核となるサービスを特定して組み立てる計画が伴わなければ、ESB を採用するのは得策でないと主張しています。これは ESB という具体的な例で一般的な IT 問題を論じたものであり、この問題に関する記事は数多く書かれています。つまり、技術を採用する前には、その技術がもたらす価値を検討しなければならないということです。したがって、この記事で ESB という言葉を他の知名度の高いあらゆるソフトウェア製品や用語に置き換えたとしても、その内容に変わりはありません。残念なことに、この記事はブロゴスフィアの一部の読者に、IBM では ESB を重要視しなくなっているという印象を与えてしまいましたが、それは真実とはまったく異なります。この記事が実際に提案しているのは (そして IBM の見解は)、ESB は有用であり、必要な技術基盤ではあるものの、SOA 導入の一環として採用すべきだということです。これらの話題についての詳細は、記事「Exploring the Enterprise Service Bus, Part 2: Learn why the ESB is a fundamental part of SOA」(developerWorks、2007年9月) を参照してください。 |
|
SOA の第一の目標は、ビジネスと IT がより効果的に機能するように、この両方の世界を連携させることです。
IBM の製品とサービスを利用して IT システムを構築する IT 部門は、ビジネス要件について十分に理解していない可能性があります。システムの動作を緻密に計画することに慣れている技術者の目には、ビジネスが機能する仕組みは無計画で成り行き任せのように映ります。説明には一貫性がなく、実行は不可能なように思われ、ビジネス・ユーザーのニーズは非現実的で絶えず変化しているように感じられます。ビジネス要件はやがて、組織の内部に存在していると噂される都市伝説になりますが、精査という光を当てるとどこかに消え去ってしまいます。
このような見方をすると、IT とビジネスの連携には現実性がないように思われ、ビジネスはそれ自体が何を必要としているのかを把握していないという感があります。ビジネスのプロセスはそのあり方自体が自動化を拒むため、プロセスを自動化しようと取り組んでみてもストレスが溜まるだけの無意味な努力となります。
技術者が理解しているのは技術です。技術には非現実的な希望の要件リストは必要なく、技術が必要とするのはコードだけです。コードは技術が使いにくいと不満を言うこともありませんし、コンパイラーは本当に必要なものは何であるかについて日替わりで考えが変わることもありません。コードは動作するかしないかのいずれかです。今日動作するならば、明日も動作します。
技術者にとっては技術のほうが把握しやすく、より大きな満足感も与えてくれます。さらに、ほとんどのエンタープライズ・ソフトウェア会社では技術を主要な商品としています。ESB は技術であり、他の技術を結合する手段です。
SOA が複雑であるのとは対照的に、ESB は簡単に理解することができます。ESB には厄介なビジネス要件は一切必要なく、必要なのは技術要件だけです。ESB は明確であり、データ・フォーマット、ワイヤー・プロトコル、XML、IP、HTTP、SOAP、JMS、JAX-RPC、JAX-WS などの標準をベースとしています。SOA は永遠に分析不可能な状態に陥る可能性がありますが、ESB を構築するための取り組みでは実際の作業を片付けることができます。
これはよく、connect everything to everything (すべてを結び付ける) プロジェクトと呼ばれます。クライアントは、アプリケーション、コンピューター・システム、データ・センター、部門、子会社、出先機関、パートナー、カスタマーなどさまざまな部分から構成されますが、各部分間でのやりとりはありません。つまり、ある部分は他の部分が何をしているのかをまるで知らないということです。しかしある部分に別の部分が必要とするデータがあるとしたら、この 2 つの部分は協力し合わなければなりません。すべての部分が連携できるようになるのは、すべての部分が結び付けられた場合のみです。ビジネスの要件が何であるかを理解しようという無駄な努力とは異なり、すべてを結び付けるという課題は解決することができます。なぜなら、そのソリューションは技術だからです。IT 部門がハンマーだとすれば、ESB は SOA の釘であると言えます。
たいていの場合、考え方は「他に何が必要なのかわからないから、とりあえず ESB を構築することにする」というものです。しかし、この考え方は「君はコードの作成に取り掛かってくれ。その間に相手が何を必要としているかを調べてくるから」という取り組み方と何ら変わりないと思いませんか?
ESB 版フィールド・オブ・ドリームスを採用した場合
読者は、すべてを結び付けたいという願望を、ひとつの語句つまりエンタープライズ・サービス・バスに要約しがちです。では、クライアントはどういった意味で ESB が必要だと言うのでしょうか。そもそも ESB とはどういう意味で使われているのか、そして ESB と呼ぶ必要はあるのかどうかを考えてみてください。
クライアントが ESB の最初の E が表す言葉、Enterprise (企業) の代わりに、法人、省庁、官庁などといった別の組織単位にしたいと思うことはよくありますし、場合によっては ESB を適用する対象 (プロキュアメントやペイロールなど) や送信内容 (製品や注文書など) にすることもあります。クライアントが Corporate Product Procurement Service Bus (法人向け製品調達サービス・バス) を望んだとしても、Service Bus の前に来る言葉に惑わされないでください。クライアントに必要なのは、ESB だからです。「ESB、ただし～」のように記述されている場合さえあります。
クライアントが実際に重点を置くのは最後に来る言葉、バスです。バスが組み込まれた技術的な接続形態では、すべてのものがバスに接続し、それによってバスを使用するその他すべてのものに接続します。つまり、バスは各部分を結ぶ主要な通信手段であるということです。アプリケーション間、さらにはネットワーク上のコンピューター間の通信でも、通常はメッセージング (一連の個々のパケットからなる情報) が使用されます。これについての概要をわかりやすく説明している資料の 1 つに、『Enterprise Integration Patterns』(「参考文献」のリンクを参照) という本があります。この本では、このような接続性をメッセージ・バスと呼んでいます。
たいていの場合、クライアントは ESB のサービスの部分についてあまり深く考えません。エンタープライズであろうと何だろうと、何らかのサービス・バス (xSB) はサービスを呼び出すためのものです。そうでなければ、単なるメッセージ・バスに過ぎません。サービス呼び出しとは、あるアプリケーションが別のアプリケーションに実行内容を指示することで、指示されたアプリケーションはその内容を実行して通常は結果を報告するために応答を返します。
では、クライアントが構築したいものが xSB だとしたら、どんなサービスのことなのでしょう。IT スタッフはこう言うかもしれません。「サービスは、必要に応じてどんな形にもなり得る」。プロジェクトは純粋に技術プロジェクトであるというのは、これまでで最も的確な指摘です。しかしサービスが重要でないと示唆することは、バスを使用するアプリケーションも重要ではなく、アプリケーションがバスを使用する方法も重要ではなく、そしてアプリケーション統合の要件 (ましてやビジネス要件) も重要ではないと言っていることと同じです。そうなると、xSB はあらゆるものに機能することになります。SOA を対象に設計する ESB では、最初はこうしたサービス要件の多くを無視してもかまいません。サービス要件は、SOA が肉付けされるに従って明らかになるからです。しかし、SOA を伴わない ESB にはサービスが 1 つもないため、単なるバスにしかなりません。
バスを構築するだけのプロジェクトは、IT 版のフィールド・オブ・ドリームスといったようなものです。この野球を題材にした映画でケビン・コスナーが演じた主人公が「それを作れば、彼らはやって来る」という声を信じたように、IT 部門はバスを構築すれば、そのバスを中心に人々が SOA アプリケーションを構築するだろうという姿勢でいます。このようなフィールド・オブ・ドリームス的な取り組み方の問題は、ハリウッド映画とは違って、ビジネスの世界では期待する人々が現れる保証はないという点です。人々が SOA アプリケーションを構築するとしても、すでに構築されたバスが気に入られなかったら、結局はその大部分を再構築してからでないと、そのバスは使用されません。SOA アプリケーションの作成者が最終的にバスを使って、それに満足したとしても、そこに至るまでには長い時間がかかります。IT 部門は「映画」の最後のクライマックスまで待ち切れないと判断しかねません。
ESB 指向アーキテクチャーの限界を理解する
ESB 版フィールド・オブ・ドリームスのどこがいけないのかと言えば、映画の中盤で妻のアニーが主人公のレイと別れると決心したことを思い出してください (覚えていなければ、誰もがレイをばかにする、物語の中盤全体を通して見る必要があります)。プロジェクトもこのような時期を迎えることになるでしょうが、プロジェクトの発起人は雇用主に見捨てられたくはないはずです。
問題は、ESB だけではビジネス価値が生まれないことです。ESB は目標を達成するための手段であり、目標そのものではありません。ESB は、SOA の電気配線や配管に例えられます。水が出てくるのは配管ではなく流し台の蛇口からです。配線が光を発することもありません。重要なのはスイッチに接続されたライトです。道筋というものは、2 つの地点を結ぶ手段であるという以外に重要ではありません。SOA のない ESB は、誰もいない場所から誰も望まない場所に続く道路のようなものです。最終的にその場所に行きたいという人は現れるかもしれませんが、それまでは、道路には費用がかかるだけで利益はありません。
ESB 指向アーキテクチャーの本質的な欠点は、誰も使う可能性のない接続性を構築するということです。ビジネスが付加価値を得るには、複数のシステムが相互接続して連動するようになるまで待たなければなりません。それまでは、ESB は単なる経費でしかなく、利益をもたらすことはありません。IT 部門は何かを構築したこと自体に満足感を得られるかもしれませんが、それによってビジネスが少しでもよくなるということはないでしょう。ビジネスは ESB がなくては不可能だったことを成し遂げようとしているわけではないからです。IT 部門にとって、ESB は人間で言う盲腸と同じく、デプロイしたアプリケーションの接続形態に含まれる痕跡だけが残った機関となります。
IT 版フィールド・オブ・ドリームスの「それを作れば、彼らはやって来る」という声よりもふさわしいスローガンは、XP (Extreme Programming: エクストリーム・プログラミング) から聞こえてきます。この「それが必要になることはないだろう」というスローガンが表すのは、極めて実際的な原則です。
何かを実装するのは常に、それが実際に必要なときであり、必要になるだろうと見込まれるときであってはなりません。
必要になるまで構築しないというこの原則は、IT 版フィールド・オブ・ドリームスの逆です。誰かが必要とするだろうという期待から構築するのではなく、実際に必要とされていることがわかってから構築するのであれば、いずれは必要となるだろうと考えるものではなく、必要に即したものを構築することができます。また、構築することが利益に直結する段階になるまでは、構築費を発生させてはなりません。この原則はまさに有効なビジネス哲学で、ビジネスのほかの部門と同じく IT 部門にも適用されます。
SOA の使用方法
ここまでをまとめると、どんなソフトウェア開発にも有効な原則としては以下が挙げられます。
- 必要になるまで構築しないこと
- ビジネス価値を生み出すものを構築すること
- IT とビジネスを連携させること
ESB 指向アーキテクチャーではなく SOA に従い、SOA の一部として ESB を構築してください。言い換えれば、「IBM SOA Foundation: An architectural introduction and overview」(「参考文献」にリンクを記載) で説明しているように、SOA を基盤としたアーキテクチャーを具現化したアプリケーションを作成、統合するという手法で SOA を実践するということです。
この手法では、SOA 開発の一環として ESB を開発し、ビジネスのニーズに基づいてサービスを見い出します。それぞれのサービスには、プロバイダーとコンシューマーだけでなく、この 2 つを結び付ける ESB 内のチャネルも必要です。このチャネルがプロバイダーのように (ただしプロキシーとして機能)、サービスのリモート呼び出しを可能にするサービス要求および応答 (プロセス間通信など) のメッセージ・フォーマットを含めたサービス・インターフェースを実装します。コンシューマーとプロバイダーの間でのサービス・インターフェース、メッセージ・フォーマット、スコープ、そしてサービス品質の違いは、メディエーションによって克服および軽減されます。こういったあらゆることが ESB 設計の中核であり、ESB が呼び出すサービスを把握していなければ、何ひとつとして実行できません。そして ESB が呼び出すサービスを把握するには、ESB を使用する SOA 内でのサービスを把握する必要があります。
このような観点から考えると、アプリケーション同士を結び付けるのは難しいことではなく、それよりもはるかに困難なのはアプリケーションのビジネス機能を結び付けることです。このビジネス機能間の結合は、ESB を構築しただけでは実現できません。
まとめ
ESB の構築に伴う技術的な難題には、厄介なビジネス要件が必要とされないという理由から、クライアントが ESB のみの構築を望む場合はよくあります。しかし ESB だけを構築するということは、IT が ESB を構築してから、その ESB を使う SOA の出現を期待するという IT 版フィールド・オブ・ドリームスです。このような ESB 指向アーキテクチャーでは SOA のメリットが失われ、ビジネス価値も生まれません。事実、すぐには利益を生まず、経費を発生させるだけです。また、IT とビジネスを連携させることもありません。ESB 指向アーキテクチャーに代わる優れた手段は、SOA です。ESB は単独で構築するのではなく、SOA の一部として、そしてできれば IBM が推奨する SOA Foundation アーキテクチャーに従って構築してください。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について | 
| | J2EEの設計者兼開発者であるBobby Woolf氏は、J2EEに関する執筆活動や講演活動を行いながら、同僚たちと研鑚を積んでいます。氏は、ノースカロライナ州ローリー在住の独立コンサルタントです。キューやトピック、同期や非同期で送信されるメッセージ、処理されるセッションや処理されないセッションなど、JMSクライアントAPIのほぼすべての部分について精通しています。以前に一時キューの実験も行ったことがありますが、あまり気に入らなかったようです。氏の連絡先はwoolf@acm.org です。 |
記事の評価
| 
