Изучив основные требования к современным КИС, перейдем к платформе Java EE, поскольку она имеет прямое отношение к корпоративным системам и это основная тема моего блога.
Java EE и J2EE используются очень широко, особенно в крупных компаниях. Одно из их преимуществ заключается в том, что платформа состоит из стандартов, гарантирующих обратную совместимость с ранними версиями. Даже старые приложения J2EE в дальнейшем будут гарантированно функционировать. Это всегда было весомым аргументом для компаний, строящих долгосрочные планы. Приложения, разработанные на базе Java EE API, способны работать на всех серверах приложений Java EE. Независимые от производителя приложения позволяют компаниям создавать перспективное ПО, не ограниченное рамками какого-либо конкретного продукта. Это оказалось разумным решением и в итоге привело к появлению индустриальной культуры, в которой стандарты улучшают ситуацию в целом.
По сравнению с миром J2EE в Java EE многое изменилось. Здесь совершенно иная модель программирования — более компактная и продуктивная. Радикальные изменения произошли вместе со сменой названия с J2EE на Java EE 5 и особенно на EE 6. Позже мы рассмотрим современный способ разработки приложений на Java. Узнаем, какие архитектурные подходы и программные модели используются, и увидим, что благодаря платформе разработка становится гораздо эффективнее, чем прежде. Тогда вы поймете, почему Java EE является современным решением для разработки корпоративных приложений.
Сейчас донести эту информацию до отрасли — в сущности, скорее маркетинговая и политическая, чем техническая задача. Множество разработчиков и архитекторов все еще считают Java EE громоздким, тяжеловесным корпоративным решением эпохи J2EE, требующим много времени, усилий и XML. За Enterprise JavaBeans (EJB) и серверами приложений сохраняется очень плохая репутация. Именно этим вызвано предубеждение многих инженеров против этой технологии. По сравнению с другими корпоративными решениями у Java EE было довольно мало маркетинговых решений для разработчиков.
Далее в моем блоге мы увидим, почему современная Java EE является одним из самых простых корпоративных решений. Вы узнаете, за счет чего она столь удобна и почему сейчас более актуальна, чем когда-либо, особенно в современных облачных и контейнерных средах. Влияние ИТ-индустрии на конкретную технологию очень важно для достижения ею успеха.
Компании выбирают Java EE в основном из-за надежности и обратной совместимости. Я предпочитаю Java EE из-за ее производительности и простоты использования. В своем блоге я хотел бы доказать читателям, что Java EE — решение, хорошо удовлетворяющее потребности современных предприятий. Я также представлю вам технологии и стандарты — не углубляясь в подробности. Скорее расскажу, как они связаны между собой. Считаю, что, сосредоточившись на этой связи, мы лучше поймем, как эффективно строить промышленные приложения.
Обновление и перспектива развития Java EE 8
Сейчас мы кратко рассмотрим, что появилось в Java EE версии 8. Цель создания этой версии — сделать продукт еще удобнее для разработчика, оптимизировать работу API и привести Java EE в соответствие с новыми требованиями, предъявляемыми облачными средами. Платформа располагает двумя полностью новыми JSR — JSON-B (Java API для JSON Binding) и Security. Кроме того, усовершенствованы существующие стандарты. В частности, внедрение JSON-B упрощает независимую от поставщика интеграцию интерфейсов JSON HTTP API.
Назначение Java EE — улучшить разработку корпоративных приложений в соответствии с современными средами и условиями. Оказывается, современные среды не просто совместимы с Java EE — они поддерживают подходы, которые уже много лет являются частью платформы, например отделение API от реализации или мониторинг сервера приложений.
В долгосрочной перспективе предполагается оптимизировать поддержку современных методов мониторинга, проверки работоспособности и устойчивости. Сегодня для реализации каждой из этих возможностей приходится слегка дополнять код. Предполагается, что в дальнейшем такая интеграция упростится. Java EE организована так, чтобы разработчик мог сосредоточиться на своих прямых задачах — заняться реализацией бизнес-логики.
Java Community Process
Уникальность платформы Java EE — в процедуре ее определения. Стандарты Java EE разрабатываются как часть Java Community Process (JCP). JCP — яркий пример отрасли, где активно поощряется участие всех, кто интересуется данной технологией. Платформа включает в себя стандарты в виде запросов на спецификацию Java Specification Requests (JSR). Запросы JSR применимы не только в Java и Java EE, но и в отношении основанных на них технологий, таких как среда разработки Spring. В результате практический мировой опыт разработки этих технологий помогает формировать новые JSR.
При разработке приложений, особенно при возникновении потенциальных проблем, письменные спецификации, сформированные на основе JSR, оказываются чрезвычайно полезными. Поставщики, поддерживающие корпоративную платформу, обязаны обеспечить реализацию так, как указано в стандартах. Таким образом, в спецификационных документах содержится информация и для поставщиков, и для разработчиков о том, как будет работать технология. Если какие-либо функции не работают, поставщики должны исправлять эти проблемы в своих реализациях. Это также означает, что разработчикам теоретически остается только изучать и знать сами эти технологии, а не детали, зависящие от поставщика.
Любой разработчик может участвовать в Java Community Process, чтобы помочь сформировать будущие версии Java и Java EE. Экспертные группы (expert groups), работающие над конкретными стандартами, приветствуют конструктивную обратную связь от любого, кто интересуется этой темой, даже если он не состоит в JCP. Более того, можно ознакомиться со следующими версиями стандартов еще до их выпуска. Все это привлекает разработчиков архитектуры и компаний: они не только понимают направление развития, но и имеют возможность повлиять на него и внести свой вклад в процесс.
Именно по этим соображениям я сам специализируюсь на Java EE. У меня есть опыт разработки корпоративных систем в среде Spring. Кроме того, что обе технологии очень похожи с точки зрения модели программирования, я особенно ценю эффективность стандарта CDI, а также возможность легко использовать все технологии платформы. Я изучал конкретные JSR, которые являются частью корпоративной платформы, участвовал в разработке инструментов, которые были стандартизированы в то время. Кроме того, я являюсь членом двух экспертных групп — по JAX-RS 2.1 и JSON-P 1.1. Участвуя в определении этих стандартов, я значительно пополнил свои знания в области корпоративных систем. Конечно, придется глубоко изучать конкретную технологию, если вы захотите помогать ее стандартизировать. Но, согласитесь, приятно осознавать, что принимаешь участие в разработке стандарта ИТ-индустрии.