Differenze tra server applicazioni .NET e server applicazioni Java

Question

Vorrei capire meglio i motivi del modello di server delle applicazioni di .NET rispetto a quello utilizzato dalla maggior parte dei server delle applicazioni Java.

Nella maggior parte dei casi che ho visto con applicazioni Web ASP.NET, la logica di business è ospitata nei processi degli host di asp.net del server web. Un altro approccio comune è quello di avere un livello fisicamente o logicamente diverso che ospita i tuoi oggetti di business e quindi sono esposti come servizi web o accessibili tramite meccanismi come WCF. Quest'ultimo approccio in genere, ma non sempre sembra essere utilizzato quando è richiesta una scala più elevata. Nei giorni degli oggetti COM ho visto Microsoft Transaction Server (MTS) e in seguito l'hosting COM + utilizzato per ospitare oggetti COM contenenti business logic, con MTS (teoricamente) che gestisce la durata dell'oggetto, le transazioni, la concorrenza yada yada. Questo modello sembra essere scomparso in ASP.NET.

Nel mondo Java è possibile avere Apache con Tomcat come contenitore servlet e oggetti business ospitati in Tomcat. In questo caso, Tomcat offre funzionalità simili a quelle fornite da MTS nel mondo .NET.

alcune domande:

1. Perché la differenza fondamentale della Microsoft contro Java si avvicina ai server di applicazioni? Questa deve essere stata una scelta di architettura/design quando questi framework sono stati creati.
2. Quali sono i pro e i contro di ciascun approccio?
3. Perché Microsoft si è allontanato dal modello di hosting MTS (che è simile al modello di hosting di servlet Tomcast) all'approccio corrente più comune che è solo per disporre di oggetti business come parte del processo ASP.NET del server Web?
4. Se si desidera implementare l'approccio di tipo MTS o l'approccio di tipo Tomcat nelle applicazioni ASP.NET oggi, suppongo che uno schema comune sia l'hosting di oggetti di business in alcuni processi IIS (eventualmente su un diverso livello fisico o logico) e l'accesso via WCF (o servizi web standard asmx, qualunque cosa). Questa è una supposizione corretta?

Answer 1

Secondo il mio modo di pensare, la differenza principale è nell'approccio "aperto" rispetto all'approccio "stack integrato". Microsoft ama fornire tutto come uno stack integrato che condivide tutti un sapore e un approccio comuni. Java è più amichevole con il modello "porta il tuo modello x", dove potresti voler collegare il tuo server applicazioni, il gestore delle transazioni, ecc. Preferiti. Entrambi gli stack tecnologici consentono invocazioni in-process e invocazioni remote con vari livelli di supporto alle transazioni.

In realtà, WCF non è un nuovo stack tecnologico, ma una riorganizzazione e rebranding di elementi esistenti dello stack .NET. Nello specifico, WCF ha assunto le funzioni di .NET Remoting, Web Services e transazioni distribuite.

Si fa riferimento a "l'approccio corrente più comune che è solo quello di disporre di oggetti business come parte del processo ASP.NET del server Web." Questo è comune solo per le app non distribuite. È un modello semplice che funziona bene quando tutti gli oggetti risiedono sullo stesso server. Questo segue il modello di distribuzione di Microsoft "Scale Out". Anziché separare i livelli oggetto tra i server, mettere tutto tranne il database insieme sui server Web e quindi aggiungere in modo incrementale server identici e ridondanti per ridimensionare il livello del server Web.

Negli ultimi tempi Microsoft ha dato molto peso all'architettura orientata ai servizi, che si basa molto su WCF e invocazione remota. Questo è visto come una chiave per la strategia del cloud che avrebbe le persone che spostano le parti o tutte le loro applicazioni su risorse flessibili nel cloud (che MS vorrebbe ospitare con Azure e simili).