ハブ＆スポーク構造
さて、アプリケーションプラットオームの構造を見ていくと、骨格がハブ＆スポーク型に描かれているのがわかると思います。データにしてもアプリケーションにしてもいったんハブに集められ、そこを経由して配信されるイメージである。
今まで提示してきた構造は、まだSOAとかESB（Enterprise Service Bus）という言葉がない時代に筆者が考えたものであるが、そのSOAやESBとどう違うのかという議論がある。ここで厳密に違いを明らかにする意味はあまりないと考えるが、ざっと整理してみる。
システム間連携の歴史を追うと、最初は２つのシステム間の直接のデータのやり取りでした。しかし、これだと同期をとらなくてはならないのでかなり難しい。そこで登場したのがMQ(MessageQueuing)で間接的、非同期のやりとりにより統合がスムーズになったが、１対１ならまだしも１対NとかN対Nのような統合となると複雑になりすぎて現実的ではなくなった。
そこで、考えられたのがハブ＆スポーク型の構造でこれにより複雑さが解消された。EAIである。従って、いままではEAIのアーキテクチャーであるハブ＆スポークは、主としてMQなどのメッセージ伝送用APIによる独自の仮想化のことでした。ところが、いまや多くの異種システムを抱えてきてそれらの連携にはどうしても標準化と分散化というのが避けて通れなくなった。そこにオープン技術で標準化されたSOAやESBという概念が登場したわけです。
ですから、おわかりのようにSOAはハブ＆スポークと同列の話ではないし、ESBもあくまで仮想化の話だから、基本的な構造概念はハブ＆スポーク型でそれがバス的な接続になっているだけと筆者は考える。
それで重要なのは、どういうハブを用意するのかである。SOAだからサービスをつなぐんでしょと言われそうだが、そりゃちょっと粗っぽいわけで、もう少し分類しておく必要がある。
まず、データの連携のためのハブ機能は従来型のEAIであり、またデータウエアハウスもデータハブといえる。「ユーザ目線のBPM」でさんざん議論したように機能のハブはBPMである。前回紹介した「統合レポート管理システム」は言ってみれば帳票のハブでもある。そして忘れてはいけないのは、データ総研の椿さんが言っている、業務アプリケーション（プログラム）のハブ／通信場としてのデータベースの役割です。
ですから、システムの構造を規定しているハブ＆スポークという考え方は幅広い概念といえるのです。
統合化されたプラットフォームイメージを下図に示す。次回から開発技術について論を進めていく。
