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

Question

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

在大多数情况下，我已经看到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提供了与.NET世界中提供的MTS类似的功能。

几个问题：

1. 为什么在微软对Java的根本区别接近应用服务器？当这些框架被创建时，这一定是架构/设计选择。
2. 每种方法的优缺点是什么？
3. 为什么Microsoft从MTS托管模型（类似于Tomcast servlet托管模型）转移到更常见的当前方法，即将业务对象作为Web服务器的ASP.NET过程的一部分？
4. 如果您想在今天的ASP.NET应用程序中实现MTS类型的方法或Tomcat类型的方法，我假设一个通用模式是在一些IIS进程中托管业务对象（可能位于一些不同的物理层或逻辑层）通过WCF（或标准的asmx网络服务，无论）。这是一个正确的假设吗？

Answer 1

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

真的，WCF并不是一个新的技术堆栈，而是对.NET堆栈现有元素的重组和重新标记。具体来说，WCF承担了.NET Remoting，Web服务和分布式事务的功能。

您引用了“目前比较常见的方法，即将业务对象作为Web服务器ASP.NET过程的一部分。”这仅适用于非分布式应用程序。当所有的对象都驻留在同一台服务器上时，这是一个简单的模型。这遵循微软的“Scale Out”部署模型。除了在服务器之间分离对象层，还可以将除数据库之外的所有内容放在Web服务器上，然后逐渐添加相同的冗余服务器以扩展Web服务器层。

最近，微软一直在努力推行面向服务的体系结构，后者更依赖于WCF和远程调用。这被看作是云战略的关键，它可以让人们将部分或全部应用程序移动到云中的灵活资源（MS想要使用Azure等进行托管）。