6

ほとんどのJavaアプリケーションサーバーで使用されているものと比較して、.NETのアプリケーションサーバーモデルの理由をよりよく理解したいと思います。

ASP.NET Webアプリケーションで見たほとんどの場合、ビジネスロジックはWebサーバーのasp.netホストプロセスでホストされます。もう1つの一般的なアプローチは、ビジネスオブジェクトをホストし、Webサービスとして公開するか、WCFなどのメカニズムを介してアクセスする物理的または論理的に異なる層を用意することです。後者のアプローチは、通常、常にではありませんが、より高いスケールが必要な場合に使用されるようです。COMオブジェクトの時代には、Microsoft Transaction Server（MTS）以降のCOM +ホスティングが、ビジネスロジックを含むCOMオブジェクトをホストするために使用され、MTSが（理論的には）オブジェクトの存続期間、トランザクション、同時実行性を管理していました。このモデルは、ASP.NETランドではほとんど姿を消したようです。

Javaの世界では、サーブレットコンテナとしてTomcatを使用するApacheと、Tomcatでホストされるビジネスオブジェクトがある場合があります。この場合、Tomcatは、MTSが.NETの世界で提供したものと同様の機能を提供します。

いくつかの質問：

  1. アプリケーションサーバーに対するMicrosoftとJavaのアプローチの根本的な違いはなぜですか？これらのフレームワークが作成されたとき、これはアーキテクチャ/設計の選択であったに違いありません。
  2. 各アプローチの長所と短所は何ですか？
  3. MicrosoftがMTSホスティングモデル（Tomcastサーブレットホスティングモデルに類似）から、WebサーバーのASP.NETプロセスの一部としてビジネスオブジェクトを使用するという、より一般的な現在のアプローチに移行したのはなぜですか？
  4. 今日ASP.NETアプリケーションにMTSタイプのアプローチまたはTomcatタイプのアプローチを実装したい場合、一般的なパターンは、IISプロセス（おそらくいくつかの異なる物理層または論理層）でビジネスオブジェクトをホストし、WCF（または標準のasmxWebサービスなど）。これは正しい仮定ですか？
4

1 に答える 1

2

私の考えでは、主な違いは「オープン」アプローチと「統合スタック」アプローチにあります。Microsoftは、すべてが共通のフレーバーとアプローチを共有する統合スタックとして提供することを好みます。Javaは、お気に入りのアプリケーションサーバーやトランザクションマネージャーなどをプラグインできる「独自のxを持参する」モデルに適しています。どちらのテクノロジースタックでも、さまざまなレベルのトランザクションサポートを備えたインプロセス呼び出しとリモート呼び出しが可能です。 。

実際、WCFは新しいテクノロジスタックではなく、.NETスタックの既存の要素の再編成とブランド変更です。具体的には、WCFは.NET Remoting、Webサービス、および分散トランザクションの機能を引き受けました。

「WebサーバーのASP.NETプロセスの一部としてビジネスオブジェクトを使用するという、より一般的な現在のアプローチ」を参照します。これは、非配布アプリでのみ一般的です。これは、すべてのオブジェクトが同じサーバー上にある場合にうまく機能する単純なモデルです。これは、Microsoftの「スケールアウト」展開モデルに従います。サーバー間でオブジェクト層を分離するのではなく、データベース以外のすべてをWebサーバーにまとめてから、同一の冗長サーバーを段階的に追加して、Webサーバー層をスケールアウトします。

Microsoftは最近、WCFとリモート呼び出しに大きく依存するサービス指向アーキテクチャを強く求めています。これは、アプリケーションの一部またはすべてをクラウド内の柔軟なリソース（MSがAzureなどでホストしたい）に移動させるクラウド戦略の鍵と見なされています。

于 2010-08-11T18:24:12.007 に答える