JMSの代わりにScalaアクターを使用する場合の違いは何ですか？
たとえば、パフォーマンスとスケーラビリティの観点から、ScalaアクターモデルはJMSと比較して何を追加しますか？どの場合、JMSではなくアクターを使用する方が理にかなっていますか？つまり、JMSがカバーできないアクターが対処する問題は何ですか？
回答:
JMSとScalaのアクターは理論的な類似性を共有していますが、必ずしも同じ問題をアーキテクチャ的に解決するとは考えていません。アクターは、レースやデッドロックを誤って作成することが一般的に難しい共有メモリの同時実行に代わる軽量の代替手段となることを目的としています。JMSは、ダイレクトメッセージング、パブリッシュ/サブスクライブ、トランザクション、EJB統合などにまたがることを目的とした高度なAPIです。
アクターに相当する最も近いJMSは、非永続的、非トランザクション的、非pub / subキューによってサポートされるメッセージ駆動型Beanです。これを「単純なJMSBean」と呼びます。
さて、あなたの質問に。
JMSは実装ではなく仕様であるため、パフォーマンスについて話すのは難しいことです。それでも、単純なJMS Beanを使用する場合、パフォーマンスはほぼ同じであり、時間とメモリの点でアクターに少しエッジがあると思います。pub / sub、transactionsなどの機能をJMSに追加すると、パフォーマンスは自然にさらに低下しますが、リンゴとオレンジを比較しようとしています。
スケーラビリティに関しては、単純なJMS Beanは、アクターとほぼ同じ方法でスケーリングする必要があります。トランザクションをJMSミックスに追加すると、トランザクションの範囲に応じて、スケーラビリティが自然に損なわれます。
アクターが何をするのかというより広い質問は、JMSではできません。まあ、組み込みのpub subまたはトランザクションがなければ、アクターはJMSから減算するように見えます-そして広くそれは真実です。しかし、ここに問題があります。アクターは非常に少ないコードを必要とするので、非常にきめ細かい並行性のためにアクターを喜んで使用できます。通常のJavaコードでは、「JMSとその依存関係、または必要なコードなどを台無しにする気がしないので、スレッドを生成し、ロックを使用して、データ構造を共有します」と言うかもしれません。Scalaの俳優の場合、「俳優をかき立てて先に進む」と言う可能性がはるかに高くなります。
デザインには哲学的な違いもあります。アクターには、スーパーバイザー階層の単純な組み込みの概念があります。アクターは通常、「クラッシュさせる」設計で使用されます。アクターが何らかの理由で死亡した場合、別のアクターは、そのアクターを再起動する、多数のアクターを殺してすべてを再開する、または他のアクターができるように多数のアクターとそれ自体を殺すなど、そのアクターをどうするかを決定する責任があります問題に対処します。この種のものはJMSに追加できますが、APIの中核ではなく、何らかの方法で外部で管理する必要があります。
ちなみに、JMSがカバーする領域にさらに移動するScalaアクターライブラリについては、Akkaを参照してください。Akkaはまた、多くの一般的なアクター階層戦略に宣言型アプローチをもたらします。