CapeDwarf — Google App Engine на Java EE

У меня много лошадей Пройдя весь путь от ранних спецификаций Java EE и выполнив «облачную» экскурсию с Java EE 7, мне было любопытно посмотреть, что недавно объявил о проекте CapeDwarf , чтобы представить платформу Google как сервис, предлагающий « Google App Engine », на месте. ,

История до сих пор

Я играл с App Engine. Это было первое настоящее предложение PaaS для меня в те времена. И мне понравилось. Что мне не нравится, так это то, что вы должны проверить, хорошо ли играет GAE с вашим вкусом Java. Несколько дней назад, в конце июня, Google и Red Hat объявили об официальном партнерстве над GAE TCK, которое рано или поздно должно привести App Engine к Wildfly.

Установка и настройка вашей среды

Давайте начнем прямо сейчас. Получить CapeDwarf и поиграть с ним. В ядре есть Wildfly или AS7, так как большинство из нас все еще знают сервер приложений JBoss. CapeDwarf является только модулем расширения и должен быть встроен. Есть два основных способа получить его: Grep последняя сборка со страницы загрузок, которая будет Beta5 (выпущена 2013-07-10), или собрать ее самостоятельно. Сначала я попробовал последний способ, и он поддерживается очень коротким файлом readme на странице проекта github, но я бы не советовал делать это. Это занимает примерно 30 минут (чистое время сборки), потому что вы также должны собрать AS 7.2.0. Если вы получили zip-дистрибутив, все, что вам нужно сделать, это разархивировать его и запустить сервер с поддержкой CapeDwarf через:

Сначала это выглядит как запуск AS 7, за исключением того факта, что он занимает намного больше времени из-за запуска JGroups. По крайней мере, на моей машине. В любом случае, после этого вам необходимо добавить администратора и войти в консоль сервера по адресу http: // localhost: 9090 / и проверить, есть ли расширение, перейдя на вкладку «Расширения». Теперь все готово.

Использование примера приложения Гостевая книга

Теперь осталось только запустить выбранную среду IDE (в моем случае NetBeans) и запустить небольшой демонстрационный проект. Давайте придерживаться примера гостевой книги, который также является частью официального gae-sdk . У вас уже должны быть Maven и Java 7. Пример гостевой книги доступен в качестве официального архетипа, и вы можете просто получить его, используя следующую команду mvn:

Все, что вам нужно с точки зрения зависимостей, находится в центре, поэтому вам даже не нужно настраивать другой репозиторий! Откройте сгенерированный проект прямо сейчас и начните настраивать некоторые вещи. Сначала вам нужно изменить die appengine.target.version в pom.xml на 1.8.3. Затем вам нужно добавить соответствующие индексы хранилища данных. Насколько я понимаю, GAE делает это самостоятельно. CapeDwarf, использующий несколько существующих технологий Red Hat, должен получить указание запустить индексы. Добавьте файл datastore-indexes.xml в папку src / main / webapp / WEB-INF / со следующим содержимым:

Если вы добавите атрибут <finalName> ROOT </ finalName> в раздел <build>, вы готовы к работе. Разверните приложение через консоль управления или поместите его в папку $ JBOSS_HOME / standalone / deployments. Вот и ты. Перейдите по адресу http: // localhost: 8080 / и наблюдайте, как происходит волшебство.

Вы можете отправлять приветствия или даже войти с адресом электронной почты и оставлять персональные комментарии. И все без изменения одной строки кода. Вы даже можете развернуть тот же кусок кода в App Engine. Далее, если вы перейдете по адресу http: // localhost: 8080 / _ah / admin /, вы получите симпатичную небольшую консоль администратора, которая дает вам доступ к базовому хранилищу данных.

Даже Datanucleus прекрасно играет в этой игре, и вы можете запустить примеры, изменив javax.jdo.PersistenceManagerFactoryClass в jdoconfig.xml на org.datanucleus.api.jdo.JDOPersistenceManagerFactory. Если вы теперь правильно поняли версии зависимостей (jdo-api: 3.0.1, datanucleus-core: 3.1.5) и используете правильный плагин maven datanucleus:

С тобой тоже все в порядке. Попробуйте. Это действительно легко.

Вещи, чтобы улучшить сейчас

В настоящее время реализация ограничена. Кажется, что команда проекта сосредотачивается на официальном GAE-TCK. Большинство API завершено, и только девять из 26 сервисов не поддерживаются в соответствии с домашней страницей CapeDwarf . Учитывая, что я ожидал увидеть немного больше документации. Пока это в основном сводится к официальной документации Google. Если вы столкнетесь с чем-то особенным, вы сами по себе. Если у вас есть вопросы относительно TCK, недавно созданная группа Google отвечает на них. Хорошая новость: руководитель проекта Алеш Джастин отзывчив и полезен, так как я до сих пор знаком с парнями из Red Hat Java. Если вы ищете примеры, в проекте CapeDwarf есть широкий охват тестов на основе Arquillian. Так что это хорошее место, чтобы начать сейчас.

Google App Engine — альтернатива Java EE 8?

Какой итог? Я бы назвал инфраструктуру GAE зрелой. Будучи запущенным в апреле 2008 года и обнародованным в конце 2011 года, у него было пять лет, чтобы соответствовать потребностям клиентов. Грустно смотреть на определения из облачной темы в ранних спецификациях Java EE 7 и сравнивать их с тем, что уже достигнуто GAE. В то время как EE имеет весьма приличный технический разрез по уровням приложений, GAE по крайней мере частично разбивает это на сервис-ориентированный способ. Несмотря на то, что в SE / EE такие вещи, как безопасность, распространены почти повсеместно (JAAS, JASPIC, отдельные спецификации), GAE просто предоставляет API пользователей для управления пользователями и API AppIdentity для интеграции с другими системами. Помимо этого, он также предоставляет API и абстракции для функций, которые Java EE просто не предлагает в готовом виде. Я имею в виду Multitenancy API или что-то вроде API Capabilities . Если кто-то хотел вначале облегчить работу с PaaS от Google и попытался сделать более позднюю миграцию на Java EE на основе аппаратного обеспечения, он должен был тщательно подумать о картографировании технологий и покупке специфических для Google сервисов. На сегодняшний день CapeDwarf уже существенно изменил правила и снизил риск блокировки поставщиков.

Если вы посмотрите на спецификацию, у нее есть свои недостатки. Google отвечает. Исключительно. На данный момент я не вижу ни одного консультативного совета или подобной вещи на месте. Так что, если Google решит отступить (например, Reader катастрофы), многие люди застрянут. С другой стороны, открытый TCK, по крайней мере, делает спецификацию бесплатной для всех (ASL2.0). И это то, что в основном позволило CapeDwarf и AppScale . Пока что это не лучшая Java EE, по крайней мере, для меня. Но с учетом того факта, что мы снова смотрим в облачное будущее с Java EE 8, это может стать основой для новых спецификаций, которые необходимо сделать, а также может стать хорошим ориентиром для того, что я бы назвал «тематически-ориентированными API». Забота о потребностях бизнеса и не только о технологических проблемах. Это будет интересное движение в ближайшие несколько лет, и мне любопытно, рано или поздно кто-нибудь из продавцов запрыгнет на этот поезд. И грустно видеть, что Google вытащил себя из JCP и активной разработки внутри органа по стандартизации.

Дальнейшие ссылки и чтения

• Блог руководителя проекта: http://in.relation.to/Bloggers/Ales
• CapeDwarf на Github: https://github.com/capedwarf/
• Загрузки CapeDwarf: http://www.jboss.org/capedwarf/downloads
• TCK App Engine: https://github.com/GoogleCloudPlatform/appengine-tck