4

私は、OSGi サービスに基づく、カスタムメイドのテクノロジのより大きなセットに基づく主要なソフトウェア システムを移行するプロジェクトの最中です。このためには、OSGi サービスとうまく連携するある種のメッセージ バスが必要になるでしょう。

  • 同期および非同期配信
  • ポイントツーポイントのみ
  • 保証された配信 - ファイルを介した永続性が望ましい
  • 同じクライアント (非同期モード) から注文された厳密なメッセージですが、異なるクライアントから注文する必要があります
  • プロセス間およびノー​​ド間のサポートは適切ですが、厳密には必須ではありません

オープン ソース ソリューションが優先されますが、必須ではありません。

私はイベントバスを見てきました（https://stackoverflow.com/a/1953453/796559で推奨されているように）が、うまく機能していないようです。

問題は、どのテクノロジーが上記に一致するかということです。

4

5 に答える 5

5

トニー、

非常によく似た成功したプロジェクトから来たばかりなので、時間と会社のお金を節約するために、私の経験をあなたと共有させてください. 何よりもまず、ESB は 8 年前に提案されたとき、本当に良いアイデアでした。そして、彼らは重要な問題を解決しました。ビジネス上の問題を厄介なコーダーが理解できるように定義するにはどうすればよいでしょうか? 目標は、ビジネスパーソンがソフトウェアソリューションを作成できるようにするシステムを開発することでした.開発者との面倒なやり取りはほとんど、またはまったく必要ありません.

これに答えるために、多くの組織の善良な人々は、ビジネスの人々が「デジタル化」したいビジネス プロセスをモデル化できるようにする JBI、BPMN、およびその他の多くのソリューションを考え出しました。しかし実際には、それらはすべて非常に重大なレベルで欠陥がありました。ビジネス上の問題には対処していましたが、統合の問題には対処していませんでした。そのため、これらの実装の多くは、高価なコンサルタントによって行われない限り成功せず、その場合でも見込みはありませんでした.

同時に、1990 年代後半に非常に頭の良い人たちが「Enterprise Integration Patterns」という本を出版し、一般的な統合の問題を解決するために使用される 60 を超える設計パターンを特定しました。ESB の作業を行っている人々の多くは、自分たちの問題がビジネス モデリングの問題ではないことに気付きました。むしろ問題は、既存のアプリケーションを統合する方法でした。この問題を解決するために、Michael Strachan と何人かの非常に頭の良い人たちが Apache Software Foundation Project "Camel" を開始しました。Camel は、エンタープライズ統合パターンの厳密な実装であり、あなたや私のような人々が何かを結び付けられるように設計された膨大な数のコンポーネントに加えて.

したがって、ビジネス プロセスを、あるアプリケーションから別のアプリケーションにデータを送信し、その間で適切なデータ変換を行う必要があると考えている場合は、Camel が最適です。では、データベース内の構成可能な一連のルールに基づいて「ルート」(データを送信する指定された一連のアプリケーション エンドポイント) を作成したい場合はどうすればよいでしょうか? まあ、キャメルもそれを行うことができます! そのためのエンドポイントがあります！とにかく、古くて壊れた伝統的な ESB をやらないでください。そして絶対にラクダのことをしてください。

これが役立つかどうか教えてください。

于 2012-02-03T04:48:28.643 に答える
4

OSGi 仕様では、軽量の pub-sub イベント サブシステムであるコンポーネント「Event Admin」が定義されています。RFC0157 から:

Event Admin は、イベント ソースがイベントをイベント リスナーに送信する手段を指定します。イベント ソースは、トピックとプロパティを使用してイベントを作成し、イベント管理者に特定のイベント トピックやプロパティ値への関心を宣言したイベント リスナーにイベントを配信するように要求できます。イベント ソースは、同期 (順序なし) 配信または非同期 (順序あり) 配信を要求できます。

要件と比較すると、スコアは次のようになります。

  • 同期および非同期配信:チェック
  • ポイントツーポイントのみ:いいえ。Pub-Sub
  • 保証された配信 - ファイルを介した永続性が望ましい:いいえ
  • 同じクライアントから注文された厳密なメッセージ (非同期モード):はい
  • プロセス間サポート: if (process == OSGi service) -> Yes
  • ノード間のサポート:まだ. Distributed OSGi の担当者はこれに取り組んできましたが、具体的なものは何も見ていません。

私は Camel のコンセプトが気に入っていますが、要件が限られているため、最近 (より軽い) Event Admin を使用することにしました。キャメルの動機でマイクに+1。私はそれを調べてから、決定する前にオプションを比較します。

于 2012-02-14T11:42:48.653 に答える
1

ESBをお探しですか？ServiceMixは次のとおりです。

Apache ActiveMQ、Camel、CXF、ODE、Karafの特徴と機能を、独自の統合ソリューションの構築に使用できる強力なランタイム プラットフォームに統合する、柔軟なオープンソースの統合コンテナです。これは、OSGi のみを利用した完全なエンタープライズ対応の ESB を提供します。

于 2012-01-29T20:19:22.617 に答える
1

iPOJO イベント管理ハンドラーは、@maasg が言及したイベント管理サービスにアクセスするための使いやすい方法です。

于 2012-04-12T12:34:15.937 に答える