SCAの前にJBIを振り返る
JBIに興味のない方や、JBIをご存じの方は3ページ目の「Tuscanyとは何か」から読んでいただいても構いません。
SCAが公開される前に、SOAの仕様とされていたのがJBI（Java Business Integration）です。JBI自体は普及しないまま終息すると思われましたが、JavaコミュニティではJava EE 6にJBIを盛り込もうとする動きもあり、その行方は予測できません。執筆時点（2009年7月）では、2009年秋リリース予定とされているJava EE 6にJBIが盛り込まれる気配はありませんが、非常に興味深く、見守りたいところです。
長い歴史を経て
「ビジネス統合」という考え方は、SOAが出る前から存在し、実現するための試みが行われてきました。RPC、CORBA、DCOM、RMI、Webサービスなど数多い例が存在します。RPCは同一言語間のリモート関数呼び出し、CORBAは異なる言語間のリモート関数呼び出しを基礎としており、DCOM、RMIはオブジェクト自身がシステム間で受け渡されることを基礎としたシステム結合の基礎技術です（厳密にはオブジェクトのスタブがクライアントに配置される技術です）。Webサービスは当初、RPCベースのSOAPで始まり、その後ドキュメントベースも加わりました。どちらもXMLの出現があって実現した技術です。執筆時点のWebサービスにはRESTfulなWebサービスも加わり、目的に合った使い方ができるようになりました。
以上の技術はすべてプログラム間の通信の規約ですが、それは自ずと「ビジネス統合」の技術として採用されてきたわけです。筆者自体はCORBA、RMI、Webサービスの経験がありますが、CORBAは仕様の難解さ、実装の難しさのため逃げ出したくなったほどです。RMIは、Javaの世界に閉じられていることとクライアント側でのリソースのアクセスが非常に難しいことで最近ではすすんで使用することはありません。従って、今ではWebサービスしか筆者は使用していないのが現状です。皆さんはいかがでしょうか？
このような流れの後、SOAという考え方が現れてきたのです。当初、SOAは定義も標準もなくSOA製品ベンダーの解釈で作成されました。結果、ユーザーはどのベンダーの言っていることが本物のSOAなのか分からなくなってしまったのです。SOAにはまだ標準すらないのだという疑念が拭い去れず、使えるという判断を下すことができなかったため、普及しなかったのです。
混沌としているSOAの世界に突如救世主として現れた、と流れ上言いたいところですが、JBI自体は2003年5月にJCPに提案されたことを考えると、混沌とする以前にJBIのおおよその骨格ができあがっていたのです。これは正直驚きました。SOA製品ベンダー同士が「これでは共倒れするので結集しよう」と呼びかけられて始まったとばかり思っていたためです。
JBI誕生
上述のとおり、JBIは2003年に提案されています。ただし、2005年8月にFinal Releaseになっていることを考えるとそんなに古い技術ではないわけです。JBI製品であるServiceMixやOpenESBは十分使える製品だと考えています。
JBIの特徴
1）プロトコル中立
SCAの魅力でも挙げましたが、JBIもプロトコル中立です。仕組み自体はいたってシンプルなもので、プレイヤーはSE（Service Engine）、BC（Binding Component）、NMR（Normalised Message Router）の3つです。
まずはJBI内部でのプレイヤーの役割を見ていきましょう。SEはサービスを提供するコンポーネント（以降、提供者）とサービスを消費するコンポーネント（以降、消費者）に分かれます。消費者が提供者にサービスを要求する場合、お互い直接やりとりするわけではありません。消費者はNMRに対し要求を渡し、NMRは消費者の要求をJBI内部の共通フォーマットのメッセージに変換します。提供者はNMRに対し要求が来ていないか確認します。要求があった場合、NMRは共通フォーマットのメッセージから提供者が分かるメッセージに変換します。提供者としてはXSLTエンジンであったり、BPELエンジンであったりします。消費者としては開発したJavaシステムなどを考えてもらうと分かりやすいと思います。ただし、すべてのコンポーネントはJavaに限られています（注1）。
厳密に言うと、SEやBCは直接NMRとやり取りするわけではなく、DC（delivery channel）を介します。
今挙げた仕組みはJBI内部に当てはまるものでJBI外部との通信にはBCがその役割を受け持ちます。JBI外部からJBI内部の提供者に要求が来た場合、BCがプロトコル変換をします。BCは要求を提供者ではなく、NMRに伝えます。それ以降の流れはJBI内部と同じです。JBI外部からは多様なプロトコルで要求が来ますが、提供者はそれを意識しないという意味でプロトコル中立と言えます。JBI外部のサービスを利用したい場合、この逆の流れになります。後の回で説明しますが、SCAのプロトコル中立とは異なります。
2）コンポーネントのコンポジット
コンポーネントを組み合わせてコンポジットを作るには、SEが使用されます。プロトコル中立で説明したようにコンポーネント間は直接通信せず、ルータを介して通信します。従って、JBIのコンポジットはSEがメッセージの流れをコントロールすることにより実現しています。SCAのコンポジットとも概念が異なります。この仕組みは少しエレガントさに欠けると感じています。SCAのコンポジットの方法は、開発者から見ると非常に簡単であるかのように実現されています。
SCA誕生
実はSCAは、JBIが実現できていないものを補うために生まれてきたわけではありません。JBIがJava EEにSOAを組み込み拡張するという目的で誕生したという経緯があります。つまり、SOAをJavaに組み込みたい、Javaの世界にSOAを実現したいというのが目的です。SCAは新規か既存かの区別なくアプリケーションやシステムをサービスとして公開するのが目的です。従って、ビジネスロジックはJavaである必要はありません。JBIがJavaのSOAを外部のJava以外のSOAと連携するための仕組みであるのに対し、SCAは言語を特定せずSOAの世界を実現する仕組みであると言えます。JBIをJava EE 6に組み込めるかという議論が最近まで活発であったことを考えると、Javaの世界から見たJBIはそれ自体意味を持っているわけです。当連載では、JBIとSCAのどちらが優れているという議論はしません。コンテクストによりその価値が違うためです。
ただし、Javaの世界で閉じてしまうことに問題がないわけではありません。Javaで閉じたSOAができると自ずと.NETで閉じたSOAの出現も考えられます。マイクロソフトのWCF（Windows Communication Foundation）がそれに該当すると思われます。言語に依存したSOAの島がいくつできても、それらを連携する仕組みを確立することは可能です。ただし、これは非常に困った状況を生み出してしまうのです。JBIやWCFそのものはSCAの外部のシステムとしてSCAとの連携はできますが、JBIやWCFで作られたコンポーネントは、JBIやWCF固有のコードを埋め込むため、それ以外の環境に簡単に組み込むことができないのです。SCAのコンポーネントはSCA特有のコードを記述する必要がないため、いつでも他のフレームワークのコンポーネントとして組み込むことが可能なのです。この点が、SCAとJBIやWCFとの大きな違いとなります。
また、JBIとSCAはその思想自体が異なります。JBIがESB（Enterprise Service Bus）を核とした仕様であるのに対し、SCAが「非常に簡単」にマシンの境界さえ超えたコンポーネントの組み合わせや解体を可能とすることに重点を置いている点です。つまり「Assembly」を核とした仕様なのです。
冒頭にクラウドとSOAは対立するものではないと言いましたが、対立どころかクラウドが力を発揮するにはSOAの力が必要なのです。クラウド上に乗っていない、あるいはクラウド上に乗せたくないシステムとクラウドのシステムを連携するにはSOAが必要となってきます。特にプロトコル中立のSCAの考え方は、既にこれを実現できる力を持っています。このようなSCA準拠のSOAの出現はクラウドにとっても追い風となるはずです。
クラウドをSOA化するのではなく、「クラウドへの移行にはSOAとBPMが不可欠」と主張する記事があります。なるほどと考えさせられます。興味のある方は参照ください。
少し紹介が遅れましたが、SCAの仕様自体はIBMとBEAにより開発されたものです。その後、OSOA（Open SOA）という団体を経て、今はOSAISにより標準化されています。2007年にversion 1.0として公開されました。Tuscanyもversion 1.0に準拠して実装されています。
