asp.net - .NET 应用程序服务器与 Java 应用程序服务器之间的区别

Question

与大多数 Java 应用程序服务器使用的模型相比，我想更好地理解 .NET 的应用程序服务器模型的原因。

在我所见的 ASP.NET Web 应用程序的大多数情况下，业务逻辑托管在 Web 服务器的 asp.net 主机进程中。另一种常见的方法是拥有一个物理上或逻辑上不同的层来托管您的业务对象，然后作为 Web 服务公开或通过 WCF 等机制访问。当需要更高的规模时，通常但似乎并不总是使用后一种方法。在 COM 对象时代，我看到 Microsoft Transaction Server (MTS) 和后来的 COM+ 托管用于托管包含业务逻辑的 COM 对象，MTS(理论上)管理对象生命周期、事务、并发性 yada yada。这种模型在很大程度上似乎已经在 ASP.NET 领域消失了。

在 Java 世界中，您可能拥有 Apache 和 Tomcat 作为 servlet 容器，并且您的业务对象托管在 Tomcat 中。在这种情况下，Tomcat 提供了与 MTS 在 .NET 世界中提供的功能类似的功能。

几个问题:

1. 为什么 Microsoft 与 Java 的应用服务器方法存在根本差异？这一定是创建这些框架时的架构/设计选择。
2. 每种方法的优缺点是什么？
3. 为什么 Microsoft 放弃 MTS 托管模型(类似于 Tomcast servlet 托管模型)而采用更常见的当前方法，即仅将业务对象作为 Web 服务器的 ASP.NET 进程的一部分？
4. 如果您想在今天的 ASP.NET 应用程序中实现 MTS 类型方法或 Tomcat 类型方法，我假设一个常见的模式是在某些 IIS 进程中托管业务对象(可能在某些不同的物理或逻辑层上)并访问通过 WCF(或标准的 asmx 网络服务，等等)。这是一个正确的假设吗？

Answer 1

在我看来，主要区别在于“开放”方法与“集成堆栈”方法。微软喜欢将所有东西作为一个集成堆栈提供，所有这些都有共同的风格和方法。 Java 对“bring your own x”模型更友好，您可能希望在其中插入您最喜欢的应用程序服务器、事务管理器等。这两种技术堆栈都允许进程内调用以及远程调用具有不同级别事务支持的调用。

实际上，WCF 并不是一个新的技术堆栈，而是对 .NET 堆栈现有元素的重组和品牌 reshape 。具体来说，WCF 承担了.NET Remoting、Web Services 和分布式事务的功能。

您引用了“当前更常见的方法，即仅将业务对象作为 Web 服务器的 ASP.NET 进程的一部分。”这仅适用于非分布式应用程序。这是一个简单的模型，当您的所有对象都驻留在同一台服务器上时效果很好。这遵循 Microsoft 的“横向扩展”部署模型。与其在服务器之间分离对象层，不如将除数据库之外的所有内容都放在网络服务器上，然后逐步添加相同的冗余服务器以横向扩展网络服务器层。

Microsoft 最近一直在大力插入面向服务的体系结构，该体系结构更多地依赖于 WCF 和远程调用。这被视为云战略的关键，该战略将使人们将部分或全部应用程序移动到云中的灵活资源(微软希望通过 Azure 等托管这些资源)。