Caltixとの組み合わせ
Celtixとその他のオープンソース
Celtixは単独で動作するだけではなく、J2EE／Servlet／JBIをコンテナとして統合し、コンテナ上のアプリケーションの互換性を保証します。
またCeltix自身はSOAP／HTTPのスタックを提供しますが、JMSのトランスポートはActiveMQを利用します。その他にも、JAX-WS／JAXB／SAAJ／Spring／Derby／ロギングなどを利用します。このように様々なオープンソース（JDKの機能も含む）と組み合わせることで効率的な開発を実現しています。
コンテナとのインテグレーションを行う場合、J2EEとしてはGeronimoをサポートしますが、Geronimoとのインテグレーションのサンプルを作成したときよりも、Geronimoの開発が進んでしまったために現在手順を更新中です。また、Tomcatとのインテグレーションもサンプルの中で扱っています。
CeltixはJBI環境もサポートします。JBI（Java Business Integration）はJSR 208でバージョン1.0のAPIが仕様化されています。先日、国産ベンダーがJBIベースのESBを発表しましたが、オープンソースの世界でもJBIを中心として、ESBを構築する例があります。Celtixを理解する上で他のオープンソースESBと対比することは有効です。
JBIとオープンソースESB
CeltixとJBIのインテグレーションは、次の2つの方式が考えられます。
- CeltixがJBIコンテナ上でコンポーネントとして動作します
- CeltixがJBIコンテナのインターフェースをサポートすることでJBIコンテナ上のコンポーネントをCeltix上に搭載します（まだ、実装されていません）
表1：CeltixとJBIのインテグレーションの方法
インテグレーションの方法を解説する前にJBI自身について解説しましょう。JBIの構成要素は、NMR（Normalized Message Router）、SE（Service Engine）、BC（Binding Component）からなります。これらが1つのJVMの上で動作します。
図1：JBIアーキテクチャ
出典：Java Business Integration(JBI) 1.0 Final Release August 17,2005
図1のようにNMRがSEやBC間のメッセージングの基盤となっていますが、NMR自身がESBとなるわけではなく、SEやBCを伴ってESBとなります。
SEは図1にあるように、例えばActiveBPELのようなBPELエンジンでもいいですし、Celtixでもサービスを提供できるエンドポイントを構築できればいいわけです。BCはJBIの外部の機能との連携を実現しますから、アダプタのような役目にもなります。Celtixが外部のサービス利用者からのメッセージを受けてNMRへ流せばBCの位置づけとなります。
サン・マイクロシステムズのjava.netでは、JBIのリファレンス・インプリメンテーションのOpen ESBが進められています。また、JBI自身はAPIの定義であり、NMRを中心として、SEやBCといったコンポーネントの登録、ライフサイクルの管理、システムの管理といったことに、もっとも重要なNMRでのメッセージングのAPIを規定しています。
https://open-esb.dev.java.net/
※対象ページ閉鎖
NMRでのコンポーネント間のメッセージは、WSDL 2.0をベースとして正規化したXMLドキュメントとバイナリデータのメッセージ本体も格納するアタッチメント、さらにセキュリティと各種プロパティを格納するメタ情報がセットで転送されます。
したがって、従来のEAIツールのハブで一律中間のデータフォーマットに変換していたようなオーバヘッドを避けることができます。さらに、NMRではコンポーネント間のメッセージ交換パターン（MEP）を次の4つのパターンで規定しています。
- In-Only
- 一方向のメッセージであり、サービス利用者（NMRでのProvider）からサービス提供者（NMRでのConsumer）へ要求が送信されるだけです。
- Robust In-Only
- 一方向のメッセージですが、サービス利用者からサービス提供者への要求の結果がNGの場合はフォルトメッセージを通知します。
- In-Out
- リクエスト/レスポンスの形式でサービス利用者からサービス提供者への要求の実行結果を応答し、NGの場合はフォルトメッセージを通知します。
- In Optional-Out
- サービス利用者が送った要求の結果をフォルトメッセージも含めて通知するのはIn-Outと同様で、さらにサービス利用者側で発生した問題でメッセージの転送が失敗した場合は、サービス利用者からフォルトメッセージを通知します。
表2：NMRでのメッセージ交換パターン
またJBIのモデルでは、SEやBCの先の外部のシステムがサービスを提供し、複数のJBI同士をBC経由で連携して、全体でESBとして拡張します。この連携をクラスタと呼んでいます。
JBIをベースにしたオープンソースESBはServiceMixやCeltixと同じObejctWebのPEtALSがあります。前述のOpenESBはJBIのリファレンス・インプリメンテーションです。またMuleは、エンタープライズ・サービス・バス（ESB）メッセージング・フレームワークと称しているメッセージングのインフラになります。
http://servicemix.org/site/home.html
PEtALS
http://petals.objectweb.org/
Mule
http://mule.codehaus.org/
CeltixがWSDLを中心にしたサービス提供者とサービス利用者を生成するモデルですが、MuleはUMO（Universal Message Object）で定義されたサービスに対するメッセージ・ブローカの位置づけになります。
そして、CeltixもMuleもServiceMixが提供するJBIコンテナ上でJBIのコンポーネントとしてインテグレーションが可能です。また、構造的にはCeltixがWrapperとするとServiceMixとMuleはデザインパターンのFacadeのような位置づけになります。
さらに、Apache Software FoundationではESBという言葉は使っていませんが、Synapseでは、Apacheの次世代のWebサービスの基盤であるAxis2をベースにした分散サービス・メディエーション・フレームワークと称してESBのメディエーション機能を中心に開発が進んでいます。
オープンソースESBの構築に様々なアプローチがあるのは商用のESBが、その成り立ちによって様々な形態をとっていることに似ていますが、オープンソースではコンポーネントを利用しあうだけでなくプロジェクト間の合併も起こります。
CeltixはObjectWeからApache Software Foundationへコミュニティを変更しました。その際にSOAPのフレームワークであるXFireと合併することが決まっています。ただし、合併したCeltiXfireプロジェクトが、まだ、Apache側で立ち上がっていませんので、詳細は、お知らせできません。
http://mule.codehaus.org/XFire
※対象ページ閉鎖
なおJBIについては、アイオナのSteve Vinoskiが次のような記事を書いていますので参考にしてみてください。
http://www.iona.com/hyplan/vinoski/pdfs/IEEE-Java_Business_Integration.pdf
※対象ページ閉鎖
それぞれのオープンソースESBについて詳しく説明することはできませんが、Celtixの位置づけは多少ご理解いただけるのではないかと思います。
