概説JBI

JBIとは何か？

　まず最初に、JBIがどのような背景の中で生まれ、どのような方向を目指しているのかを見ておきましょう。

JSR 208

　JBIは、Java Business Integrationの略で、その名前のとおりJavaのプラットフォーム上で、ビジネス統合を図ろうとするものです。2003年の5月にJSR 208としてJCPに提案され、昨年6月には、2年間の議論をまとめたJBI 1.0仕様のProposed Final Draft 2が出されてそのアーキテクチャの全体像が明らかになりました。JSR 208には、米国サン・マイクロシステムズ、オラクル、ソニック ソフトウェア、ティブコソフトウェア、独国SAPなど多数のベンダーが参加しています。おととし、米国IBMとBEAシステムズが脱退して、その代わりに、アパッチ・ソフトウェア・ファウンデーションとJBossが参入したことでも話題になりました。

「Java EEをビジネス統合SPIで拡張する」

　JSR 208は、その目的を、「J2EEをビジネス統合SPIで拡張する」こととうたっています。JBIは、Java EEの拡張として構想され、その次々期バージョンであるJava EE 6の中核技術と目されています。ただ注意してほしいのは、JBIは、現在話題になっているJava EE 5のEJB 3.0やJSF（JavaServer Faces）などを拡張したものではありません。従来のJ2EEの中にJBIに発展する要素を見つけようとすれば、J2EE 1.4で導入されたSOAP対応のStateless Session Beanに行き当たるかもしれません。あるいは、EJB層ではなく、Web層のサーブレットがその先祖となるのかもしれません。

　JBIは、ビジネス統合という課題にこたえるべく、Java EEとWebサービスの統合をさらに推し進めようとするものです。JBIで拡張されたJava EEは、現在のアーキテクチャとは大きく異なるものになるだろうと筆者は考えています。

　「J2EEをビジネス統合SPIで拡張する」という命題では、SPI（Service Provider Interface：サービス提供インタフェース）という言葉にも注意が必要です。JBIは、アプリケーションが直接利用するAPI（Application Programming Interface）を提供するだけではなく、何よりも複数のサービス提供者を想定し、それとのインタフェースであるSPI群を提供することで、J2EEを拡張しようとしています。

ビジネス統合問題

　JBIが登場してきた背景には、いわゆる「ビジネス統合問題」があります。

　エンタープライズの現場では、基幹部分にメインフレームがあり、部門ごとにはUNIX/Linuxサーバがあり、社員の大多数はWindowsマシンを利用するという異機種混合環境は珍しいものではありません。むしろ、それが常態と言ってよいと思います。

　「ヘテロ」な環境自体が問題なわけではありません。問題は、こうした環境が、ビジネスのニーズに即応した統合されたシステムとして有効に機能し、かつ、そのシステムが適切なコストで維持／管理／運用されているかどうかというところにあります。

　IT技術の変化は激しく、またビジネス自体も変化を続ける中で、部分的なものであれシステムの更新は避けられません。企業システムには、絶えず変化しようという傾向が内在しています。企業システムは、問題が起きる度に繰り返される更新、あるいは業務上のニーズの変化に基づく拡大の中で、「統合」どころか、現実にはますますつぎはぎだらけの複雑なものになっていきます。デビット・チャペル氏は、こうした企業システムのアーキテクチャを、皮肉を込めて「Accidental Architecture」と名付けました。企業のITシステムを見れば、その企業がどのようなトラブルに遭遇してきたかがわかるというわけです。

　システムの複雑さは、対処すべき問題とシステムの維持コストを増大させます。IT技術の進歩と経済環境の変化による一層の経営合理化への圧力の下で、企業内のアプリケーション統合であるEAI（Enterprise Application Integration）や、企業間連携（B2B）に対する要求は、ますます強いものになっています。システムを統合することで大幅なコスト削減が可能となるからです。

　統合について、技術的には、これまでもいろいろな試みがなかったわけではありません。しかし、これまでのやり方では、自社の内部だけで独自の「統合」を行うか、あるいは、特定ベンダーの「統合」技術に「ロックイン」するしか方法はありませんでした。ビジネス統合の問題は、将来のビジネスの世界全体にかかわる大きな問題です。それは、1つの会社の内部に閉じるものではないし、特定の会社の技術に依存するものでもないはずです。

JBIのアプローチ――サービスはメッセージの交換

　JBIは、Java EEをSOAで拡張してビジネス統合問題を解決しようとする試みだと考えることができます。ここでは、サービスを提供するコンポーネントを単位として構成されたアーキテクチャをSOA（サービス指向アーキテクチャ）と呼んでいます。JBIは、次のようなアプローチでビジネス統合問題に答えようとします。

●ビジネスをサービスで構成されたものととらえる

　まず、企業のシステムを、サービスを提供するコンポーネントの集まりとして再構成します。ビジネス統合の現場である現実のビジネスの世界では、それぞれの部門を固有のサービスの担い手として把握するのは難しいことではありません。粗い粒度では、SOAシステムのサービス概念と現実のサービス概念とが近づいて、わかりやすくなるのがSOAの良いところの1つです。社長に企業システムのアーキテクチャを説明するのなら、オブジェクトの集まりとしてシステムを説明するより、サービスの集まりとしてシステムを説明するほうが、はるかに簡単なはずです。

　粒度の細かいコンポーネントを考える段階では、プログラムとは「サービスを提供するものである」と、その働きをとらえなおせばよいのです。もっと正確に言うと、「サービスとはメッセージの交換にほかならない」という視点に立てば、企業システムを、サービスを提供するコンポーネントの集まりとして再構成するのは容易となります。

●SPIの標準化

　次いで、JBIは、コンポーネント化されたサービスの提供インタフェースであるSPIを、オープンな標準技術で定義することで共通化しようとします。ここが、JBIのアイデアの中心的な部分です。「サービスとはメッセージの交換にほかならない」のですから、サービスのインタフェースの標準化とは、メッセージ交換のインタフェースの標準化であるということになります。

　もちろん、サポートすべきアプリケーションやプロトコルは多数あるでしょう。ただ、メッセージ交換のインタフェース部分にだけ着目するなら、そのSPIを標準化するのは難しいことではありません。

●メッセージの経路の標準化

　こうした準備、すなわちメッセージ交換のインタフェースの標準化ができれば、サービスの提供者としてのコンポーネントを、この標準化されたSPIを通じてシステムに自由にプラグインすることが可能になります。JBIでは、サービスを提供するコンポーネントを自由にプラグインできるJavaの環境を構成することで、ビジネス統合を実現することを目標としているのです（図1）。JBIは、共通化されたインタフェースで、プラグインされたコンポーネントからのメッセージを標準的なフォーマットのメッセージに変換するとともに、そうしたメッセージが内部の標準的なバスを通じて流通するようにします。

図1：JBI環境には、コンポーネントのプラグインが可能

　メッセージの標準的なインタフェース、メッセージの標準的なフォーマット、メッセージの標準的な内部バス。これが、JBIにおける、ビジネス統合を支える道具となります。