Почему Java-приложениям нужен сервер приложений и .Net только веб-сервер IIS?

Ответ 1

Существует несколько причин.

Сервер приложений Java EE - это монитор транзакций для распределенных компонентов. Он обеспечивает множество абстракций (например, именование, объединение, жизненный цикл компонента, постоянство, обмен сообщениями и т.д.), Чтобы помочь в этом.

Многие из этих сервисов являются частью операционной системы Windows. Java EE нуждается в абстракции, поскольку она не зависит от операционной системы.

Следует также сказать, что полная спецификация Java EE не требуется для разработки веб-приложений. JDBC, часть Java, которая занимается реляционными базами данных, является частью Java SE. Java EE добавляет в сервлеты, которые являются HTTP-слушателями, и Java Server Pages, который является языком разметки для создания сервлетов. Вы можете создавать полнофункциональные веб-приложения, используя только эти технологии и Java SE. Tomcat и Jetty - это два сервлета/JSP-движка, которые могут работать для полноценных серверов приложений Java EE.

Если вы обратите внимание на то, что .NET имеет HTTP-прослушиватели, встроенные в модуль System.Net, вы понимаете, что он, как если бы .NET взял страницу из Java и сместил функциональность javax.servlet в фреймворк.

Если вы добавите Spring и такие функции обмена сообщениями, как ActiveMQ или RabbitMQ, вы можете писать полные приложения, не прибегая к WebLogic, WebSphere, JBoss или Glassfish. Вам не нужны EJB или полная спецификация Java EE.

ОБНОВЛЕНИЕ:

Spring Boot предлагает возможность разработки и запуска полнофункциональных Java-приложений в качестве исполняемого JAR файла. Нет необходимости в каком-либо сервере приложений Java EE, просто JDK 8 или выше.

Ответ 2

Это потому, что у Sun и Microsoft были разные цели с их программным обеспечением и способы достижения этой цели.

Сант-мантра для Java была с самого начала "Пишите один раз, бегите везде", и это привело к тому, что было сделано много усилий для создания _API_s, которые определяют, как должна выглядеть среда, чтобы позволить минималистичную часть код выполняет свою работу.

API для "обработки веб-запроса и возврата веб-ответа" был назван Servlets и был чрезвычайно успешным из-за того, что он заполнял пустоту и был четко определен. Все основные веб-серверы на основе Java, о которых я знаю, позволяют запускать сервлеты. Ранняя реализация полного сервлет-совместимого веб-сервера составляет всего 1500 строк. Впоследствии это было расширено, чтобы включить JSP для обеспечения HTML-кода на стороне сервера (например, PHP).

Для любого действительно масштабируемого решения, включая веб-решения, это означает, что в конечном итоге загрузка настолько высока, что один компьютер недостаточно мощный, чтобы запускать его самостоятельно. Масштабируемое решение ДОЛЖНО быть способным распространяться по нескольким компьютерам, знакомым друг с другом, и это единственное требование приносит много других вещей в таблицу:

• Код должен иметь возможность запускать код, запущенный на другом компьютере (EJB).
• Данные должны быть доступны для всех компьютеров согласованным способом (база данных).
• Доступ к указанной базе данных должен быть эффективным (пул соединений с базой данных). ... и многое другое

Затем Sun создал API для всех функций, которые они нашли, для этого, и назвал его "Java Enterprise Edition" (в те дни слово "Предприятие" использовалось для многих вещей) и создала систему реализуя все эти API, которые люди могли покупать и использовать.

Разница между Microsoft и Sun теперь входит в игру. Здесь Microsoft просто сделает IIS общедоступной и скажет "использовать эти API" в клиентах, но на самом деле не хочет, чтобы кто-то создавал другой сервер, предоставляющий эти API. Потому что они хотят продать Windows, чтобы запустить его!

Sun хотела, чтобы люди использовали язык вместо этого, поэтому они позволили ANYONE реализовать спецификацию Java EE, но им пришлось передать строгий набор тестов от Sun (и платить), чтобы иметь возможность использовать бренд Java EE, Это привело к тому, что большое количество серверов Java EE было доступно там, где вы обычно можете повторно использовать основную бизнес-логику, но должны настроить сервер Java EE для предоставления ресурсов, необходимых для приложения.

См. http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition#Certified_application_servers для состояния серверов сегодня. Как коммерческий, так и открытый источник доступны на основе ваших потребностей - выберите тот, который вам подходит.

Итак, причина в том, что Java EE - это набор хорошо определенных API, которые любой может реализовать, и они имеют.

Ответ 3

Во-первых, вы можете запустить .NET-код с Apache с помощью mod_mono, поэтому он не ограничен IIS. Также есть несколько других веб-серверов (Cassini и XPS), которые также будут запускать ASP.NET.

Для запуска динамического веб-приложения вам нужен как веб-сервер, так и сервер приложений. Иногда они так хорошо интегрируются, что они кажутся одними и теми же, иногда нет.

В отношении Java - он всегда поддерживал больше платформ, чем .NET, и был более открытым, поэтому был интегрирован в большее количество веб-серверов (в стек Linux).

Как и .NET, так и IIS - это технологии, которые были получены от Microsoft, ASP.NET и аспектов сервера приложений (aspnet_isapi.dll) в комплекте с IIS, а другие установщики .NET интегрированы с IIS. Конечно, Microsoft только реализовала его на своей ОС и на своем веб-сервере.

Ответ 4

Apache очень похож на IIS и не имеет большого отношения к Java.

Серверы приложений в Java предоставляют дополнительные услуги, которые .NET предоставляет различными способами, с различными продуктами или операционной системой Windows.

Apache обычно используется в развертываниях Java в качестве прокси-сервера для сервера приложений позади него и потенциально обслуживает статический контент или обрабатывает SSL и аналогичные проблемы. Это совершенно необязательно, хотя есть веские причины для его использования.

Tomcat и Jetty - это в основном веб-серверы Java, которые предоставляют определенную инфраструктуру (среди прочего, Servlets) для создания динамических веб-сайтов с Java-кодом. Они часто являются компонентами более крупного сервера приложений или могут быть развернуты отдельно.

JBoss - пример сервера приложений (Glassfish и Weblogic - две очень распространенные другие), которая предоставляет полную спецификацию J2EE. Идея спецификации J2EE заключается в том, чтобы разрешить определенный способ создания сервера приложений, чтобы приложение можно было переключать между различными серверами приложений от разных поставщиков, соответствующих спецификации. Спецификация касается взаимодействия с определенными службами, которые полезны для серверной программы.

Ответ 5

Потому что Java EE - это спецификация, а не сам продукт. Помните, что Java намного более открыта, чем .NET(в смысле спецификации).

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

Ответ 6

Одна из причин заключается в том, что писать сервлет так же просто, как реализовать интерфейс javax.servlet.Servlet в конкретном классе. Таким образом, контейнеры сервлетов должны поддерживать довольно простой API, чтобы называть себя веб-серверами. Это делает установку для создания контейнера сервлетов чрезвычайно простой из-за этого ограниченного контракта функциональности.

Ответ 7

Отключение инструментов - одно из преимуществ и недостатков Java, посмотрите на доступные Java Web Developement Frameworks, вы можете бесконечно их оценивать, чтобы решить. в .Net это в значительной степени MVC. С серверами это относительно просто. Большинство отправляются в Tomcat, если им нужен веб-сервер и JBoss, если им нужен бесплатный сервер приложений. Причины этого уже были сказаны, J2EE - это спецификация.