ビジネストランザクションメッセージング基盤は、可能な限り既存のオープンソースを組み合わせて実現したいところです。不必要な開発・維持コストをかけたくはありません。
しかし現状のオープンソースにおいて、以下の点が問題としてあげることができます。
 
      1. エンタープライズレベルのトランザクションログ
      2. データベースの内部利用が前提となっているJMSプロバイダ
      3. FTPなどのトランザクショナルファイルシステムへの対応
      4. 統合的な運用管理との連携方法、プラクティス
      5. 高度な常駐並行処理への対応
 
1. エンタープライズレベルのトランザクションログ
 

トランザクション処理システムの設計において「ログは全てを知っている」と言われます。

ここでいう「ログ」とは、log4jのような処理ログやデバッグ情報のことではなく、トランザクション処理（コミットされたものもアボートされたものも含めて）にかかわった全ての処理データを履歴的に記録している「トランザクションログ」をさします。

トランザクションログは、未確定状態トランザクションの解決やリカバリ処理、あるいは、オンラインレプリケートなどに用いられ、トランザクション処理の中核となる情報を保持します。ですから出力したトランザクションログの物理的にディスクへの書込みが遅延したり、書込み最中の異常終了によりデータの一貫性が壊れたために再起動できなくなったり、単一障害によりデータを失ってしまったりするようでは、実用的なトランザクション処理は成り立ちません。

つまりエンタープライズレベルの信頼性を備えたトランザクションシステムとするためには、トランザクションログの機能性・信頼性がとても重要となります。既存のオープンソースでもトランザクションログ機能を実現しているものは存在します。が、しかし、

        ● 信頼（入念）書込（標準形式を備えたページ単位でのピンポン書込）

        ● ログ多重化（並列実行性の高い多重ログ書込）、

        ● アーカイブ（オンラインで効率的なバックアップ、アーカイブ）

        ● 回復処理のための各種ユーティリティ

などにおいて十分な実装を行っているオープンソースは非常にすくないのが現状です。

オープンソースの中では、リレーショナルデータベースがこのようなトランザクションログを実装しているぐらいですが、リレーショナルデータベースのトランザクションログは、最適化などの目的のために密結合となっており、トランザクションログ機能を切り出して他のリソースマネージャ（メッセージキューなど）やトランザクションサーバのために再利用することは困難となっています。
このような状況では、ビジネストランザクションメッセージング基盤を構築するためには、たとえ非常に高いコストがかかるとしても、信頼・実績のある（プロプライエタリ）製品を用いるしかありません。

2.データベースの内部利用が前提となっているJMSプロバイダ

今後SOA（サービス指向アーキテクチャ）などの普及に従い、ビジネストランザクションメッセージングの標準的なインターフェースと考えられるもののひとつがJMS（Java Message Service）です。

JMSの典型的な実装であるメッセージキューイングサービスは、リレーショナルデータベースのような柔軟なデータ操作機能を持っているわけではありませんが、その分、シンプルで高速なトランザクション処理を実現できます。JMSが本当に一般的で標準的なインターフェースとして普及するかどうかは依然不明（使用経験のあるプログラマであれば寄せ集め的でプロバイダ依存の多い仕様に「うんざり」していることでしょう）ですが、しかし、疎結合による柔軟かつ高信頼でのシステム間連携を実現するためには、メッセージキューイングサービスは欠かせない要素のひとつといえるのではないでしょうか。

しかし、既存のオープンソースJMSプロバイダは、（内部的に）リレーショナルデータベースを利用しているものがほとんどです。これでは、リレーショナルデータベースにJMSのインターフェースを付加しているに過ぎないため、データベースと比べて、通常稼働時のスループットにおいても、交換データの履歴的な管理についても、障害後のリカバリータイムにおいても、何の優位性もありません。つまりはメッセージ交換用に専用のリーレーショナルデータベースを配置しているだけですから、何のために（多くのプログラマが慣れ親しんでいる）SQLやJDBCではなく、JMSというマイナーなインターフェースをわざわざ用いなければならないのかが分からなくなってしまいます。

3.FTPなどのトランザクショナルファイルシステムへの対応

最近では、トランザクションファイルシステム（ジャーナルファイルシステムではなく、トランザクション処理としてファイル操作を実行可能なファイルシステム）が少しずつ登場してきています。

このようなファイルシステムを用いることで、ファイルベースでのメッセージ交換でも（高頻度、高負荷が想定される場合を除けば）十分にトランザクションメッセージング基盤とすることが可能といえます。

ファイルでのメッセージ交換は、多くのユーザやプログラマにとって分かりやすい（直感的にイメージをつかみやすい）ものであるため、大多数の中小規模システムにとっては、非常に魅力的な選択肢といえるでしょう。

問題は、

         ● FTPなどのツールが対応していないこと

         ● トランザクションファイルシステムに対応したOSが少ないこと

         ● 普及に従いインターフェースなどが断続的に変化するかもしれないこと

などがあげられます。

トランザクション処理に対応したFTPなどのツールを整備するとともに、これらが利用できない環境での代替機能やインターフェースの変化を吸収する方法も合わせて用意しなければ、システム全体の信頼性の向上を図ることができません。

4.統合的な運用管理との連携方法、プラクティス

様々な有用なオープンソースを組み合わせて利用することは、コスト、機能、リスクなどの面から非常に魅力的です。しかし、システムの運用管理から考えれば、決して利点ばかりではありません。

システム運用管理においては、以下のような要件があります。

データの履歴・追跡
統合的で一貫性のある設定・管理
情報の機密性・安全性
統計情報の取得・レポート
 

勿論、エンタープライズユースを想定しているオープンソースでは、運用管理の標準インターフェースであるJMX(Java Management eXtension)などに対応していますが、しかしオープンソースは階層的・集中管理的なプロジェクトではありませんから、オープンソースの組み合わせによりシステムを構築した場合、統合的なシステム運用を実現することには、かなりの困難が想定されます。

統合的な運用管理と利用する各オープンソースとの連携を可能とし、また、必要となるオープンソースとその組み合わせ、および、ベストプラクティスが提供されなければ、普及は難しいものと考えています。

5.高度な常駐並行処理への対応

メッセージキューイングやトランザクションファイルシステム以外にも、有用と考えられる様々なリソースマネージャがあります。例えば、交換されるデータが画像など（サイズが大きいデータ）の場合、毎回データをメッセージに埋め込んで送受信することは効率がよくありません。このような場合、データ参照用のオブジェクトデータベース、あるいは、XMLデータベースなどが必要となることでしょう。またそれ以外にも、必要とされるコンポーネントや製品との連携を実現するアダプタを用意する必要が予測されます。このような場合に問題となるのは、デーモンやサービスとして常駐し、また、並行的に処理を実行するをソフトウエアを設計・実装することが、決して容易ではないことです。

このような問題を軽減するために共通ライブラリやフレームワークといったものが必要となります。

しかしそもそも共通化設計やフレームワーク設計は、アプリケーションのコンテキストや前提により大きく判断が変化する（時には正反対の判断となる）ものですので、本当に共通利用するものとするためには要求・仕様のスコープや複雑さが幾何級数的に増大するため、莫大なコストと時間が必要となってしまいます。

共通フレームワークや共通ライブラリの有用性は、適用可能なドメインの選択と作成のためのコスト・期間との妥協（トレードオフ）をいかにうまく行えるかにかかっているのかもしれません。

ですから「共通化」といわれるものは「絵に描いたもち」になりやすく、そのため過去の苦い経験をお持ちの方も少なくないでしょう。

とはいえ、現在においてこのような共通コンポーネントのコードベースと考えられるのは、DIコンテナでしょう。

既存のDIコンテナのカスタマイズで対応可能であれば一番よいのですが、しかし、既存のDIコンテナはどちらかといえば単独での動作が前提となっており、

        ● セッションレスを前提としていることが多く、状態を必要とする処理の実現が難しい

        ● 部分的な設定のリロード、部分再起動ができないため、連続稼働性の実現が難しい

        ●  （階層関係、依存関係のある）サービス間で同期をとりながら連携する方法が用意されていない

 というような問題が存在しています。

このような問題に対応するために、DI（IoC）コンテナは、モジュールでの再利用だけではなく、ソースレベルでのカスタマイズ、コンポーネントの切り出し、再利用が容易であることも必要となります。また、このようなコンポーネントが実質的に共通のフレームワークに成長していくことができればと考えています。