[解決済み] JMSの代わりにScalaのActorを使うには、どのような設計上の決定が必要ですか？

質問

JMSの代わりにScalaのActorを使うと、どのような違いがありますか？

例えばパフォーマンスやスケーラビリティの観点から、ScalaのActorモデルはJMSと比較して何が追加されるのでしょうか？どのような場合にJMSではなくActorを使うのがより理にかなっているのか、つまりJMSがカバーできない問題をActorが解決してくれるのか。

どのように解決するのですか？

JMSとScalaのアクターは理論的な類似性を共有していますが、必ずしもアーキテクチャ的に同じ問題を解決しているとは考えないでください。アクターは、レースやデッドロックが一般に偶然に発生しにくい共有メモリ並行処理の軽量な代替品となることを意図しています。 JMS は、ダイレクト メッセージング、パブリッシュ/サブスクライブ、トランザクション、EJB 統合などにまたがることを意図した、洗練された API です。

アクターに最も近いJMSの等価物は、非永続的、非トランザクション的、非パブ/サブキューによってバックアップされるメッセージ駆動型Beanでしょう。 私はそれを単純な JMS Bean と呼ぶことにします。

では、質問にお答えします。

JMSは実装というより仕様なので、パフォーマンスについて話すのは難しいです。 しかし、シンプルな JMS Bean を使用する場合、パフォーマンスはほぼ同じで、時間とメモリでアクターに少し有利であると予想されます。 pub/sub、トランザクションなどの機能をJMSに追加すると、パフォーマンスは当然さらに低下しますが、その場合、リンゴとオレンジを比較しようとしているようなものです。

スケーラビリティに関しては、シンプルな JMS Bean はアクターとほとんど同じようにスケールするはずです。 JMS ミックスにトランザクションを追加すると、トランザクションのスコープに依存する量によって、スケーラビリティが当然損なわれます。

JMSにできないことで、アクターには何ができるのかという、より大きな疑問があります。 組み込みのパブサブやトランザクションがなければ、アクターは JMS から減点されるように見えます。 しかし、アクターは非常に少ないコードしか必要としないので、非常に細かい並行処理に喜んで使用することができます。 普通のJavaコードでは，「JMSとその依存関係や，それが必要とするコードなどをいじくり回すのは気が進まないので，スレッドを生成し，ロックを使い，データ構造を共有することにします」と言うかもしれません．

デザインにおける哲学的な違いもあります。 アクターには、スーパーバイザー階層というシンプルなコンセプトが組み込まれています。 アクターは通常、quot; let it crash" のデザインで使用されます。 あるアクターが何らかの理由で死んだら、別のアクターがそのアクターを再起動させるか、アクターの束を殺して全部を再起動させるか、あるいはアクターの束を殺してそれ自体を他のアクターに任せて問題に対処するか、といった対処を決定する責任を負っています。 そのようなことはJMSに追加できますが、APIの中核ではないので、何らかの方法で外部で管理する必要があります。

ところで、JMSがカバーする領域にもっと踏み込んだScalaのアクターライブラリについては、以下を参照してください。 Akka . Akka はまた、多くの一般的なアクター階層化戦略に対して宣言的なアプローチを提供します。