Różnice między serwerami aplikacji .NET a serwerami aplikacji Java

Question

Chciałbym lepiej zrozumieć przyczyny modelu serwera aplikacji .NET w porównaniu do przyczyn używanych przez większość serwerów aplikacji Java.

W większości przypadków, które widziałem w aplikacjach internetowych ASP.NET, logika biznesowa jest hostowana w procesach hosta asp.net serwera WWW. Innym powszechnym podejściem jest posiadanie fizycznie lub logicznie innego poziomu, który obsługuje obiekty biznesowe, a następnie są one prezentowane jako usługi sieciowe lub dostępne za pośrednictwem mechanizmów takich jak WCF. To ostatnie podejście zazwyczaj, ale nie zawsze, wydaje się być stosowane, gdy wymagana jest wyższa skala. W czasach obiektów COM widziałem Microsoft Transaction Server (MTS) i późniejszy hosting COM + używany do hostowania obiektów COM zawierających logikę biznesową, z MTS (teoretycznie) zarządzającym czasem życia obiektu, transakcjami, współbieżnością yada yada. Wydaje się, że model ten w zasadzie zniknął na ziemi ASP.NET.

W świecie Java możesz mieć Apache z Tomcat jako kontener serwletu i obiekty biznesowe hostowane w Tomcat. W tym przypadku Tomcat zapewnia podobną funkcjonalność do tego, co zapewnia MTS w świecie .NET.

Kilka pytań:

1. Dlaczego zasadnicza różnica w porównaniu Java Microsoft podchodzi do serwerów aplikacyjnych? Musiał to być wybór architektury/projektu, gdy stworzono te ramy.
2. Jakie są plusy i minusy każdego podejścia?
3. Dlaczego firma Microsoft odstąpiła od modelu hostingu MTS (który jest podobny do modelu hostowania serwletów Tomcast) do bardziej powszechnego obecnego podejścia, które polega tylko na tym, aby obiekty biznesowe były częścią procesu ASP.NET serwera WWW?
4. Jeśli chciałbyś zaimplementować podejście typu MTS lub podejście typu Tomcat w aplikacjach ASP.NET dzisiaj, zakładam, że powszechnym wzorcem byłoby hostowanie obiektów biznesowych w pewnym procesie IIS (prawdopodobnie na innej warstwie fizycznej lub logicznej) i dostęp za pośrednictwem WCF (lub standardowych usług sieciowych ASMX, cokolwiek). Czy to jest prawidłowe założenie?

Answer 1

Według mojego sposobu myślenia, zasadniczą różnicą jest podejście "otwarte" a podejście "zintegrowany stos". Microsoft lubi dostarczać wszystko jako zintegrowany stos, który ma wspólny smak i podejście. Java jest bardziej przyjazna dla "przynieść swój własny model x", gdzie możesz chcieć podłączyć swój ulubiony serwer aplikacji, menedżer transakcji itp. Oba stosy technologii umożliwiają in-process wywoływanie, jak również zdalne wywoływanie z różnymi poziomami obsługa transakcji.

Naprawdę, WCF nie jest nowym stosem technologii, ale reorganizacją i rebrandingiem istniejących elementów stosu .NET. W szczególności WCF przyjął funkcje .NET Remoting, Web Services i transakcji rozproszonych.

Użytkownik odwołuje się do "bardziej powszechnego bieżącego podejścia, które polega jedynie na posiadaniu obiektów biznesowych w ramach procesu ASP.NET serwera WWW." Jest to powszechne tylko w przypadku aplikacji nie dystrybuowanych. Jest to prosty model, który działa dobrze, gdy wszystkie twoje obiekty będą rezydować na tym samym serwerze. Jest to zgodne z modelem wdrożenia "Scale Out" firmy Microsoft. Zamiast segregować warstwy obiektów na serwerach, połącz wszystkie elementy poza bazą danych na serwerach WWW, a następnie stopniowo dodawaj identyczne, nadmiarowe serwery, aby skalować warstwę serwera WWW.

Firma Microsoft ostatnio mocno naciska na architekturę zorientowaną na usługi, która polega w większym stopniu na WCF i zdalnym wywoływaniu. Jest to postrzegane jako klucz do strategii w chmurze, która pozwoliłaby ludziom przesuwać części lub wszystkie ich aplikacje do elastycznych zasobów w chmurze (które MS chciałoby hostować z Azure i tym podobne).