Различия между серверами приложений.NET по сравнению с серверами JAVA-приложения
Я хотел бы лучше понять причины модели сервера приложений.NET по сравнению с используемым большинством серверов JAVA-приложения.
В большинстве случаев я видел с веб-приложениями ASP.NET, бизнес-логика размещается в процессах хостов asp.net веб-сервера. Другой общий подход должен иметь физически или логически другой уровень, который размещает Ваши бизнес-объекты и затем выставлен как веб-сервисы или получен доступ с помощью механизмов как WCF. Последний подход обычно, но не всегда, кажется, используется, когда более высокий масштаб требуется. В эпоху COM-объектов я видел Microsoft Transaction Server (MTS), и более поздний хостинг COM + раньше размещал COM-объекты, содержащие бизнес-логику, с MTS (теоретически) управляющим объектным временем жизни, транзакциями, параллелизм yada yada. Эта модель в основном, кажется, исчезла на земле ASP.NET.
В мире Java у Вас мог бы быть Apache с Tomcat как контейнер сервлета и Ваши бизнес-объекты, размещенные в Tomcat. В этом случае Tomcat предоставляет схожую функциональность какой MTS, обеспеченный в мире.NET.
Несколько вопросов:
- Почему принципиальное различие в Microsoft по сравнению с Java приближается к серверам приложений? Это, должно быть, было архитектурой/проектным решением, когда эти платформы были созданы.
- Каковы за и против каждого подхода?
- Почему Microsoft переезжала от размещающей MTS модели (который подобен модели хостинга сервлета Tomcast) к более общему текущему подходу, который должен только иметь бизнес-объекты как часть процесса ASP.NET веб-сервера?
- Если Вы хотели реализовать подход типа MTS или подход типа Tomcat в приложениях ASP.NET сегодня, я предполагаю, что общий шаблон должен был бы разместить бизнес-объекты в некотором процессе IIS (возможно на некотором другом физическом или логическом уровне) и доступ через WCF (или стандарт asmx веб-сервисы, безотносительно). Действительно ли это - корректное предположение?