Различия между серверами приложений .NET и серверами приложений Java

Question

Я хотел бы лучше понять причины, по которым модель сервера приложений .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.

Несколько вопросов:

1. Почему принципиальное различие между подходами Microsoft и Java к серверам приложений?Должно быть, это был выбор архитектуры / дизайна при создании этих платформ.
2. Каковы плюсы и минусы каждого подхода?
3. Почему Microsoft отказалась от модели хостинга MTS (котораяаналогична модели хостинга сервлетов Tomcast) более распространенному текущему подходу, который заключается в том, чтобы просто иметь бизнес-объекты как часть процесса ASP.NET веб-сервера?
4. Если вы хотите реализовать подход типа MTS илиПодход Tomcat-типа в приложениях ASP.NET сегодня я предполагаю, что распространенным шаблоном будет размещение бизнес-объектов в каком-либо процессе IIS (возможно, на другом физическом или логическом уровне) и доступ через WCF (или стандартные веб-службы asmx, что угодно).Это правильное предположение?

Answer 1

На мой взгляд, основное отличие заключается в подходе «открытый» по сравнению с подходом «интегрированный стек». Microsoft любит предоставлять все в виде интегрированного стека, который разделяет общий вкус и подход. Java более дружественна к модели «принеси свою собственную x », где вы можете подключить свой любимый сервер приложений, менеджер транзакций и т. Д. Оба технологических стека позволяют выполнять как внутрипроцессный, так и удаленный вызов. с различными уровнями поддержки транзакций.

Действительно, WCF - это не новый стек технологий, а реорганизация и ребрендинг существующих элементов стека .NET. В частности, WCF взял на себя функции .NET Remoting, веб-служб и распределенных транзакций.

Вы ссылаетесь на «более распространенный в настоящее время подход, который заключается в том, чтобы просто включить бизнес-объекты в процесс ASP.NET веб-сервера». Это характерно только для нераспределенных приложений. Это простая модель, которая хорошо работает, когда все ваши объекты будут находиться на одном сервере. Это соответствует модели развертывания Microsoft «Scale Out». Вместо того, чтобы разделять уровни объектов по серверам, разместите все, кроме базы данных, на веб-серверах, а затем постепенно добавляйте идентичные избыточные серверы для масштабирования уровня веб-сервера.

В последнее время Microsoft активно продвигает сервис-ориентированную архитектуру, которая в большей степени зависит от WCF и удаленного вызова. Это рассматривается как ключ к облачной стратегии, которая позволит людям перемещать части или все их приложения на гибкие ресурсы в облаке (которые MS хотела бы разместить с Azure и т. П.).