Java Enterprise

Java сама по себе - язык. Java EE (ранее J2EE) или Java Enterprise это стек технологий, включающий стандарты на сервер приложений, шины сообщений, механизмы авторизации и другие необходимые на предприятии вещи. Прикол в том, что если большинство ваших приложений не живет в Java Enterprise окружении, если у вас всё на Windows или на LAMP, то Java для вас это огромный тяжелый пласт знаний как в эксплуатации так и в разработке.

Например, Вы знаете что такое сервер приложений (Application Server)? Я когда был Windows администратором и даже ИТ шефом в компании, где не было сервера приложений не знал что это, не понимал зачем это надо, и когда коллеги, внедрявшие Oracle что-то там, говорили про это, я понимал их отображая в своем сознании Application Server на IIS.

На самом деле прямого аналога Application Server в .NET нету, хотя условным аналогом можно считать IIS, но не совсем. Application Server предоставляет более стандартизованную среду для запуска приложений. IIS позволяет запускать и PHP приложения и CGI/FastCGI приложения на любых языках и это натурально веб-сервер. Tomcat, GlassFish, Oracle Containers for Java, JBoss и так далее, позволяют запускать только Java приложения, они сами реализованы на Java, и глубина стандартизации Java EE приложений с т.з. зрения использования сервисов Application Server-а выше. Т.е. Application Server это такая богатая обвязка для Java приложения, а не универсальный веб-сервер.

Приложение, реализованное на основе стандарта Java Enterprise Bean может быть запущено как на ферме серверов приложений, так и на единственном Application Server-е, само того не зная. И наоборот, множество приложений может быть запущено на одном сервере. При этом, администраторы могут выбирать Application Server-а, которые им удобны с т.з. управления, а Java приложения будут работать на любом из них. Так же, если приложению нужен сервер очереди сообщений, администратор может (тут я не уверен, но разработчик точно может) выбирать из списка вариантов. То же касается любых других сервисов, которых десяток и т.д.

Это, казалось бы, закладывает грандиозную масштабируемость и управляемость. С другой стороны это сложность понимания для тех, кто ещё не в этом.

А теперь давайте посмотрим, используется ли эта инфраструктура в таком виде на практике? Обычно вендоры ПО, описывают "рекомендованные" конфигурации и админы от них не отступают. От греха.. Более того, инсталляции ПО зачастую происходят вместе с сервером приложений. Вы же не хотите много развертывать руками? Конечно нет! А для какого сервера приложений разработчик должен дать Вам инсталлятор? Вариант "для любого" не устраивает в свою очередь разработчиков. Поэтому, ПО на Java, когда Вы ставите его через yum, отнюдь не тянет через зависимости какой-нибудь Tomcat, а чаще включает его в себя. Поэтому, демо версия Naumen, включает в себя Tomcat. Поэтому, Queue Metrics поставляется с Tomcat и т.д. Поэтому обычно, обыкновенные админы не ставят на один Application Server несколько Java приложений.. Сравните это с повсеместной практикой развертывания многих приложений на одной инсталляции Apache (httpd) или IIS, и Вы поймете, что Java не экономна.

Вторая вещь, касается возможностей распределения выполнения. Программисты (некоторые) смотрят на крутые вещи таким образом, что раз можно, значит это нужно использовать и всё остальное проблема сервера(ов). И это может сказываться на том, как работает приложение. Некоторые, используя СУБД Oracle, перегружают её обширной реализацией бизнес-логики на уровне хранимых процедур (это выясняется, когда становится ясно, что мы не можем масштабироваться дальше, т.к. СУБД стало узким местом). Другие всюду используют Enterprise Java Beans, хотя при тесных взаимодействиях совсем не всё равно на одном сервере или на разных выполняется этот код. Но все они уверены, что Oracle и Java это круто.

На самом деле, Java это круто. Если всё сделано правильно и если это облегчает жизнь, а не добавляет сред бедным LAMP или Windows администраторам.

LAMP

Linux+ Apache+ MySQL+ PHP = дешевая и вкусная среда для разработки небольших приложений.

Во-первых, админы спокойно разворачивают десяток таких приложений на одном сервере. Ресурсов почти не надо, настройки почти ноль. Перенос куда-либо не сопряжен ни с какими сложностями. Хостинг найти не просто не проблема, а просто вообще не проблема и стоит он как ... я из кофе-машины за месяц пью на такую же сумму.

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

LAMP это гигантская экономия ресурсов по всему миру!

Например, у меня среда в которой мы с разработчиками и админы (из соседнего отдела) ведем учет наших задач, регистрируем работы, загружаем исходники работает на PHP (www.streber-pm.org). Я подправил кое-что походу и удовлетворен. Заодно там Wiki. Ошибки в котором я тоже исправил. Мне не нужен домен для входа в эту систему, зато я могу завести там учетки внешним исполнителям. Это стиль применения LAMP-овых приложений.

Да, эти приложения не заточены на хорошую интеграцию в среду .NET или Java Enterprise. Зато ваш код скачают, исправят и проинсталлируют гораздо больше интересующихся людей самого разного уровня подготовки.

.NET

По области применения очень похож на Java Enterprise. Разница только в текущем окружении. На самом деле ИТ шеф должен решить какая технология Java или .NET предпочтительна в компании, это вопрос ИТ стратегии. Чем-то на LAMP можно закрыть дыру. Когда вопрос стоит о том, каким решением закрыть прикладную область стоимостью от ...$, на деле выбор стоит между .NET и Java.

Да .NET в чем-то попроще чем Java EE. Общее количество разных решений на .NET меньше. Но зато, некоторые решения, если можно так выразиться, стандартизованы самим MS.

Во-первых IIS безальтернативен. Поэтому, что делает админ? Берет .msi или setup.exe, запускает на сервере и он читает (если он инструкций до этого не читает) "Требуется IIS 7, требуется .NET 4, требуется ..." и сразу ясно, что дальше делать.. он ставит эти стандартные и единственные компоненты Windows. А ещё лучше, если этот .msi ставит их сам. Next -> next -> next.. и это работает в 95% случаев. Админы SQL Server -а, который ставится кнопкой "далее", удивляются, когда узнают, что для установки Oracle Database нужно скачать Oracle Universal Installer.. хотя для продвинутого администрирования SQL Server недостаточно жать "далее", разумеется.

У MS очень много продуктов которые безальтернативны, но хорошо позиционированы с т.з. применения. Поэтому, при всей сложности изучать MS легче, и устанавливать тоже легче чем продукты из мира Java и Linux. Это сказывается на интеллектуальном уровне некоторых администраторов, но это говорит так же о силе продуктов.

Возьмем, например, портальные решения. Какие Вы знаете портальные решения для .NET/IIS... ну? Кроме Sharepoint? А с другой стороны.. зачем они нужны? Sharepoint дешево? Да. Сколько инсталляций?? Ого-го.

Вы знаете, у нас на предприятии нет решений, которые бы соответствовали по уровню отказоустойчивости службе каталогов (Active Directory), кроме тех, которые написаны под Windows. Знаете как может быть задублирована Active Directory? Представим ПК и приложение на нем. ПК может получить сетевую конфигурацию от более чем одного DHCP сервера. В сетевой конфигурации ПК может быть более чем один DNS. О контроллерах AD ПК узнает от этих DNS и может войти через любой из доступных. Если упадет любое звено, ПК подымется и приложение запустится. Если админ все сделал правильно.. но тут это чаще по умолчанию. А как реализуется поддержка AD в LAMP и Java приложениях? Обычно это ограничивается "авторизацией через LDAP", где один конкретный адрес сервера LDAP прописывается. В Linux и Java вообще много где чего "прописывается" и поэтому иногда "next" работает лучше. Я только радуюсь великолепным руководствам от Red Hat и Oracle, но реальные админы могут сделать одно и то же 50 разных местах.

Поэтому, .NET это так же круто как Java Enterprise. Кроме того, это проще. Выбор стоит между простотой последующей эксплуатации и богатством альтернатив при разработке. А если вдуматься, то он обычно не стоит, а предопределен компетенциями ИТ службы и разработчиков. А они в свою очередь предопределены профилем организации, т.к. этот профиль зачастую влияет на ландшафт продуктов. Если в вашей предметной области много прикладных решений на Java, пилите на ней.

Ключевое

Если Вы новичок-разработчик, колеблющийся в выборе технологии, для начала нужно примкнуть к любому лагерю и найти заказчика.. дальше действительно неважно какая технология лучше. ;-)