Вероятно, мы все
это предчувствовали. Вчера было опубликовано официальное плановое обновление
для JavaEE и GlassFish. И начиная с названия, пост целиком был посвящен одному:
привычный нам сервер GlassFish из полноценного продукта превратился во
второстепенный.
Длинный путь от Sun к Oracle
Еще с самого
начала судьба GlassFish вызывала опасения. После слияния понадобилось некоторое
время, чтобы унять настойчивые просьбы к Oracle “положить конец GlassFish”.
Oracle проделала хорошую работу, способствуя развитию сообщества. Стодневные
релизы версий 2.1.2 и 3.0.1 послужили доказательством стремления к
усовершенствованию. Даже спустя некоторое время все пользователи были довольны.
В январе 2013 года я составил список серверов приложений с открытым исходным
кодом с рекомендациями по выбору. Решающим критерием была поддержка
поставщиками. Поэтому из игры вышел WAS CE. Учитывая вчерашнее событие, к нему
бы присоединился и GlassFish. Оставшиеся альтернативы сводятся к JBoss AS7 /
WildFly.
Почему Java EE пострадает от “смерти” GlassFish?
Качество системы
проверки совместимости (Java EE TCK) не внушает доверия. В прошлом многие
использовали GlassFish в качестве наглядного примера неработающего кода.
Вдобавок ко всему, некоторые производственные сценарии и ошибки привели к
разным реализациям и, что не менее важно, спецификациям. Все практические
специальные знания были исключительно в головах разработчиков.
Я не знаю, как Oracle
управляет разработкой WLS внутри компании, но надеюсь, не так как разработкой
GF. Извлечение пограничных случаев спецификации и устранение конкретных частей
продукта из пользовательских сценариев на основе WLS, определенно, будет
сложным и нечастым. Я рассчитываю на то, что спецификация будет меньше зависеть
от Oracle и, в общем, будет менее устоявшейся. Однако, учитывая, что некоторые
светлые умы работают в данной области, их энтузиазма и знаний будет очень не
хватать. И некому поддержать их в трудную минуту.
Без каких составляющих останется GlassFish?
GlassFish
останется эталонной реализацией будущих стандартов Java EE. Oracle нуждается в
нем лишь по одной причине. Поскольку JCP становится все более открытым, не
удивительно, что его участники не спешат присваивать WLS статус эталонной
реализаций.
Что касается
составляющих, которых лишится GlassFish, здесь я могу только строить догадки.
Одно скажу точно - все, что не охвачено спецификацией Java EE, быстро устареет.
Среди таких составляющих может быть кластеризация и, конечно, отдельные функции
администрирования и обеспечения защиты (сфера PAM). Повторюсь: это всего лишь
предположение!
Есть ли позитивные стороны?
Да: Такой шаг
оставляет широкое пространство для усиленной конкуренции. В дальнейшем пользователи
смогут сэкономить на лицензионных платах. GF и WLS лицензируются по-разному и,
используя стандарт WLS, пользователи получат богатые возможности выбора
необходимой лицензии. К тому же, по крайней мере, команда WLS получит поддержку
пользователей, которым больше не придется отвлекаться, работая над разными
продуктами.
Может ли Oracle оправдать рациональность такого поступка?
На данный момент он кажется бессмысленным. Пользователи могут просто сидеть и ждать следующей отладочной версии, которая выходит раз в год. Если до сегодняшнего дня вы жаловались на редкие релизы, готовьтесь, в будущем их будет еще меньше. На самом деле, чтобы пользу от стратегического шага Oracle получили все, компания может предпринять следующее:- Разработать и следовать четкой схеме обновлений. Найти способ поддерживать, по крайней мере, среду разработки, основанную на сверхлегковесном сервере, и развертывать только в полноценный WLS.
- Сделать пользователям GF привлекательное предложение по лицензированию. Не только текущим пользователям, а всем. Еще лучше - предложить лицензирование по условиям OTN, согласно которому некоммерческие организации получают право использовать WLS бесплатно.
- Сделать GF открытым (в соответствии с надлежащей лицензией) и поощрять вклады сообщества. Пока это невозможно из-за особенностей используемой инфраструктуры и сертификата OCA (Oracle Certified Associate). Перенесите код сервера (включая модули) на GitHub, назначьте менеджера изменений, который будет просматривать и извлекать предложенные исправления и изменения. Пусть сообщество принимает решения по релизам.
Отголоски
По сути, такая
новость не вызывает удивления. Нам всем понятен этот шаг. Два сервера вместо
одного - двойная нагрузка. Слиянием с BEA Oracle “убила” собственный сервер
приложений. Пришла очередь GlassFish. Oracle уже пыталась уменьшить усилия,
необходимые для его сопровождения, объединив команды, а также рассматривала
различные варианты слияния WLS и HK2 и расширения использования одних
компонентов для обоих серверов. Некоторые происшествия отодвинули вчерашнее
объявление на пару месяцев, но не предотвратили его. Так что, покойся с миром
GlassFish. Спасибо за службу.
Комментариев нет:
Отправить комментарий