Diferencias entre los servidores de aplicaciones .NET frente a los servidores de aplicaciones Java

Question

Me gustaría comprender mejor las razones del modelo de servidor de aplicaciones de .NET en comparación con el utilizado por la mayoría de los servidores de aplicaciones Java.

En la mayoría de los casos que he visto con aplicaciones web ASP.NET, la lógica de negocios se aloja en los procesos de host asp.net del servidor web. Otro enfoque común es tener un nivel físico o lógicamente diferente que aloja sus objetos comerciales y luego se exponen como servicios web o se accede a través de mecanismos como WCF. El último enfoque, por lo general, pero no siempre parece usarse cuando se requiere una escala mayor. En los días de los objetos COM, he visto Microsoft Transaction Server (MTS) y posterior COM + hosting utilizado para alojar objetos COM que contienen lógica de negocios, con MTS (teóricamente) administrando la duración del objeto, transacciones, concurrencia yada yada. Este modelo parece haber desaparecido en gran medida en ASP.NET land.

En el mundo de Java, es posible que tenga Apache con Tomcat como contenedor de servlets y sus objetos comerciales alojados en Tomcat. En este caso, Tomcat proporciona una funcionalidad similar a lo que proporciona MTS en el mundo .NET.

varias preguntas:

1. Por qué la diferencia fundamental en el Microsoft contra Java se acerca a los servidores de aplicaciones? Esto debe haber sido una elección de arquitectura/diseño cuando se crearon estos marcos.
2. ¿Cuáles son los pros y los contras de cada enfoque?
3. ¿Por qué Microsoft se alejó del modelo de alojamiento MTS (que es similar al modelo de alojamiento de servlets de Tomcast) al enfoque actual más común que es simplemente tener objetos comerciales como parte del proceso ASP.NET del servidor web?
4. Si desea implementar el enfoque tipo MTS o el enfoque de tipo Tomcat en aplicaciones ASP.NET hoy, supongo que un patrón común sería alojar objetos comerciales en algún proceso IIS (posiblemente en otro nivel físico o lógico diferente) y acceder a través de WCF (o servicios web estándar de asmx, lo que sea). ¿Es esta una suposición correcta?

Answer 1

A mi modo de ver, la principal diferencia está en el enfoque "abierto" frente al enfoque de "pila integrada". A Microsoft le gusta ofrecer todo como una pila integrada que comparte un sabor y enfoque común. Java es más amigable con el modelo "traiga su propio x", donde es posible que desee conectar su servidor de aplicaciones favorito, administrador de transacciones, etc. Ambas pilas de tecnología permiten la invocación en proceso así como la invocación remota con niveles variables de soporte de transacción.

Realmente, WCF no es una nueva pila de tecnología, sino una reorganización y cambio de marca de los elementos existentes de la pila .NET. Específicamente, WCF asumió las funciones de .NET Remoting, servicios web y transacciones distribuidas.

Hace referencia al "enfoque actual más común que es solo tener objetos comerciales como parte del proceso ASP.NET del servidor web". Eso solo es común para aplicaciones no distribuidas. Es un modelo simple que funciona bien cuando todos sus objetos residen en el mismo servidor. Esto sigue el modelo de implementación de "escalabilidad" de Microsoft. En lugar de segmentar los niveles de objetos en todos los servidores, coloque todo, excepto la base de datos, en los servidores web y luego incremente los servidores idénticos y redundantes para escalar la capa del servidor web.

Microsoft ha estado presionando mucho últimamente en la arquitectura orientada a servicios, que se basa más en WCF y la invocación remota. Esto se considera una clave de la estrategia en la nube que haría que las personas movieran partes o todas sus aplicaciones a recursos flexibles en la nube (que a MS le gustaría alojar con Azure y similares).