events - イベントベースのメッセージング システム (zeromq、OpenDDS、..)

Question

次のように機能するイベントベースのメッセージングシステムを設計しようとしています:

店舗に複数の商品があり、それらの価格は毎日変動するとします。クライアントはアプリケーションにログインし、特定の日付 (ログイン日から 1 か月など) の特定の製品の価格を (SMS 経由で) 知るように要求できます。

zeromq を使用する場合、イベントの概念 (上記のように) を導入するにはどうすればよいですか? OpenDDS はそのようなシナリオにより適していますか?

Answer 1

ユースケースを読むと、モデル化されたオブジェクト (この場合は製品) の「状態」(この場合は潜在的な過去の価格) へのアクセスを分散することよりも、「イベント」についてのほうが少ないかもしれません。

オープン スタンダード テクノロジとしての DDS は、pub/sub メッセージングとリレーショナル データ モデリングのスマートな組み合わせを使用して、共有データへの分散アクセスを提供することで、これを直接サポートします。また、データの生産者/消費者とデータ「自体」の両方に関連付けることができるサービス品質 (QoS) ポリシーの膨大なセットを標準化し、サポートします。あなたのユースケースでは、DDSインフラストラクチャがデータオブジェクトの一意に識別された「インスタンス」（DDS用語ではトピックと呼ばれる）ごとに履歴データを維持できるようにするデータの「耐久性」QoSです。

DDSアプローチで重要なことは、特定のユースケースに適した「データモデル」を決定することです.あなたの場合、それは非常に簡単です.つまり、一意の製品コードを持つ製品（「. RDBMS のように、DDS では「キー属性」)、おそらく説明と価格です。価格が変更されるたびに、そのデータ型の新しい「インスタンス」が公開され、その QoS ポリシーが PERSISTENT として定義されるため、ミドルウェアによって維持されます (通常は、 DDS 実装の一部)

DDS のアプリケーションは、これらのトピックへのサブスクリプションを取得し、製品トピックの履歴データが自動的に提供されます。一部の DDS 実装では、コンテンツ、時間、および/またはボリューム (量) の組み合わせに基づいて、履歴データの配信の改良を指定できます。あなたのユースケースでは、「適切な製品」(ID または名前による) と時間の選択になります。

最後に、システムが「Web 対応」であると仮定します。つまり、インターネット規模で動作し、おそらく PC やモバイル デバイスなどでの分散アクセスのためにデータのクラウドベースの永続的なストレージをサポートする必要があります。ボルテックス (www.prismtech.com/vortex) で。Vortex OpenSplice 製品のオープンソース バージョンも利用できることに注意してください (www.prismtech.com/dds-community)。

幸運を ！

Answer 2

ソリューションには、3 つまたは 4 つの異なるテクノロジを組み合わせる必要があるようです。

(1) 長期的な情報を保持し、カスタム クエリをサポートするための、データベースなどのストレージ テクノロジ。基本的に「静止データ」を保持します。従来の RDBMS が適している場合があります。

(2) 状態を更新し、状態変化の通知を取得し、シグナルを送信し、異なるアプリケーションやプロセス間を統合するためのメッセージング テクノロジ。これには、DDS/RTPS、ZeroMQ、JMS/AMQP などのメッセージング ミドルウェア テクノロジが最適と思われます。

(3) Web クライアントおよびサーバー技術。クライアント側と Node.js またはその他の HTTP/REST バックエンド用の Java Script のようなもの。

(4) プロトコル調停・統合技術。さまざまなプロトコルとテクノロジーを統合できるようにするもの。たとえば、メッセージを取得してリモートでデータベースの変更を検出したり、HTTP/REST サービス、メッセージング テクノロジ、およびデータベースを統合したり、SMS とバックエンドを統合したりします。Apache Camel および Enterprise Service バスが提供する種類のもの。

私は、メッセージング プラットフォームとしての DDS を中心としたシステムの構築に精通しています。DDS を選択した場合、さまざまな DDS ベンダーがこれらのビルディング ブロックをすでに多数提供しています。たとえば、Web で検索すると、Apache Camel Integration および Node.js との統合が見つかりました。Hans はすでに PrismTech の Vortex について言及しています。RTI はリレーショナル データベース ( https://www.rti.com/products/dds/database-integration.html ) との統合を準備しているため、データベースで行われた変更はメッセージ バスに反映され、その逆も同様です。 Web/HTTP/REST ( http://www.slideshare.net/GerardoPardo/london-connext-dds-conference-web-enabled-dds ) との統合、および前述の Web テクノロジの他のいくつかとの統合。

別のアプローチとして、ESB を中心にアプローチを開発し、ESB が提供するアダプターをさまざまなテクノロジーに使用することもできます。これはおそらく最も単純なアプローチの 1 つですが、すべてが ESB によって仲介されるという欠点があります。これらのトレードオフのいくつかについて説明した、私が書いた次の記事をご覧になることをお勧めします。

ジェラルド