Вторая часть обзора посвящена среде Google AppEngine.
В отличии от GWT, который является просто средством разработки, одним из ряда аналогичных, на GAE нужно посмотреть и с другой стороны. GAE это не просто среда (платформа), где выполняются приложения (кстати, совсем не обязательно, написанные на GWT), но и хостинг. И помимо вопроса, насколько GAE отвечает требованиям проекта с точки зрения разработчика и руководителя проекта – об этом пойдет речь ниже, возникает вопрос – насколько выгоден этот хостинг, насколько удобно поддерживать приложение в рабочем состоянии, по сравнению с традиционными подходами. Я не в курсе всех особенностей, связанных в вопросом GAE хостинга, но с точки зрения разработчика могу отметить следующее:
+ возможностей административной консоли (см. ниже) явно не достаточно для сопровождения и мониторинга больших приложений. Эту функциональность все равно придется реализовывать и отнюдь не меньшую ее часть.
+ ограничения на ресурсы, api, хранилище данных и др. делают разработку сложнее, длиннее и дороже, чем для традиционных хостингов.
+ отсутствие необходимости поддерживать работу “железа”, иметь штат системных админов и других вопросов, связанных с оборудованием и софтом – это привлекательное обстоятельство для маленьких компаний.
+ будет ли такое решение дешевле в эксплуатации, зависит в первую очередь от того, какой доход при каком трафике будет приносить приложение. Возможно, что при небольшом трафике, оно вообще не потребует дополнительной оплаты хостинга.
+ текущее состояние проекта GAE – предварительный релиз. Это влечет за собой несколько проблем и вопросов. Во-первых, какие цены на дополнительные услуги и ресурсы установит google после выпуска полноценного релиза и будет ли сохранен бесплатный доступ? Во-вторых, в настоящий момент отсутствует поддержка, кроме как общение с командой разработчиков через форум, ответы которых на вопросы сообщества не являются оперативными.
+ большой проблемой является надежность приложений, развернутых на GAE. В нашей практике были случаи, когда приложение (и не только наше) становилось недоступным на 30 минут, 1 час или даже 12 часов. Через день или 2 на форуме появлялись разъяснения от google, что они в это время проводили обновление ПО или что-то в этом роде. Вопросом предварительного оповещения о таких ситуациях, по крайней мере для предварительного релиза, похоже, в google никто особенно не озабочен. Для коммерческих приложений этот вопрос стоит крайне остро и поэтому в последнее время целый ряд компаний приняли решение мигрировать свои приложения с GAE на традиционный хостинг. Вот ссылка на типичный случай (на английском) — http://www.carlosble.com/?p=719
Итак, мой вывод о GAE хостинге таков. GAE может использоваться небольшими компаниями и индивидуальными предпринимателями для хостинга проектов, которые не требуют серьезного мониторинга, поддержки и надежности. Использование хостинга GAE компаниями, имеющими собственный хостинг и штат нужных специалистов абсолютно неоправданно.
Теперь об особенностях платформы для руководителей проектов и программистов.
+ среда предоставляет разработчику ряд сервисов: сохранение больших объемов данных – до 2Г, работу с картинками (изменение масштаба и т.п.), работу с почтой, выборку данных по http, выполнение фоновых задач и др. Каждый из сервисов навязывает разработчику те или иные ограничения. Поэтому, если планируется использовать такой сервис, обязательно следует ознакомиться с актуальной документацией на предмет этих ограничений. Перечень и API сервисов выглядят более бедными по сравнению с инфраструктурой, предоставляемой J2EE application server-ом и даже J2SE. Так, например, отсутствует какая-либо возможность работы с цветом изображений.
+ GAE накладывает ряд ограничений на использование java классов, поэтому, планируя архитектуру приложения, следует всегда проверять “JRE Class White List” на предмет совместимости.
+ крайне болезненным является вопрос использования на GAE различных framework-ов и библиотек. На сайте http://code.google.com/p/googleappengine/wiki/WillItPlayInJava можно ознакомиться с, как мне показалось, официальным списком поддерживаемых и не поддерживаемых библиотек. Однако, этот список явно не полный и, по-видимости, убедиться, что данный framework или библиотека будут работать в среде GAE можно только загрузив их туда и поработав с ними. Имеется также официально не поддерживаемая google страница http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine. Там следует обратить внимание не на ее содержание, а на messages, размещенные и все еще размещаемые там пользователями и разработчиками. Возможно, среди них удастся найти информацию о библиотеке, отсутствующей в официальном списке. Ну и, конечно, не следует забывать про поиск и конференции.
+ для работы с приложениями, google предоставляет административную консоль с минимальным набором операций. Большая часть ее экранов – это отображение статистической и билинговой информации. Сравнивать ее с традиционными консолями серверов приложений просто бессмысленно. Из наиболее важных функций следует отметить добавление пользователей-администраторов (кто может деплоить приложение и имеет доступ к консоли), управление версиями приложения и фоновыми задачами. Имеется также не слишком удобный просмотровщик хранилища данных.
+ логирование в целом можно признать удовлетворительным. Логи можно смотреть через консоль, либо загрузить при помощи утилиты командной строки на локальный компьютер (что мне, кстати, удавалось не всегда). Логи периодически уничтожаются, так что, если есть подозрение, что они вам могут понадобиться – загружайте их, не откладывая на потом.
+ деплой приложения проводится целиком, даже, если во всем приложении меняется только один файл ресурса. Для деплоя можно использовать специальную утилиту или делать его при помощи плагина Eclipse-а. Можно иметь несколько версий одного и того же приложения. Одна версия будет вызываться по умолчанию, а для других создаются специальные адреса.
+ при деплое google app engine иногда начинает вести себя довольно странно и выводит (или не выводит) сообщения об ошибках. Здесь приходится идти в “поиск” и надеяться, что этот вопрос уже решен сообществом google разработчиков. В моей практике было 2 случая. Первый, когда после “успешного” деплоя, в логе стали появляться сообщения, о том, что тот или иной класс не может быть найден. В этом случае я менял версию приложения, делал повторный деплой, а сбойную версию удалял. Второй, когда деплой стал время от времени завершаться с сообщением об ошибках при парсинге web.xml. При этом, иногда десплой проходил успешно, а иногда – нет. Выяснилось следующее. При создании проекта в eclipse, web.xml создается для сервлета версии 2.3 с соответствующим определением DTD. GAE поддерживает версию 2.5 и поэтому в web.xml я использовал конструкции из 2.5, а заменить DTD на schema для 2.5 – забыл. Ошибка очевидна, однако, почему деплой с таким кривым web.xml чаще проходил, чем заканчивался ошибкой, осталось загадкой.
+ вместо домена, предоставляемого google для созданного вами приложения, можно установить другой домен, владельцем, которого вы являетесь. Однако, при этом, насколько я понял, вы теряете возможность работы по Https.
+ встроенная авторизация пользователей крайне ограниченная. Имеется всего 2 роли – admin (который указывается в админ. консоли) и все остальные, кто имеет т.н. google account (он может быть, а может и не быть адресом вашего почтового ящика на gmail.com). Можно также предоставить доступ только пользователям с адресами из определенного домена, зарегистрированного в Google Apps. Если же требуется более “тонкое” разграничение доступа, придется реализовать его самостоятельно.
+ ключевым элементом большинства приложений является хранилище данных (datastore). Google предоставляет в распоряжение разработчиков свое собственное хранилище. Оно не является ни реляционной, ни объектной базой данный. В частности, там нет понятия foreing key, а перечень сохраняемых типов ограничен. Крайне важно понимать, что данные вашего проекта подходят для этого хранилища. Мое мнение состоит в том, что данные должны быть либо преимущественно “для чтения” и денормализованными, либо независимыми друг от друга. Даже простые зависимости между часто модифицируемыми данными крайне плохо подходят для размещения в GAE datastore и интенсивно расходуют квоту процессорного времени во время операции модификации.
Имеется несколько способов работы с эти хранилищем.
Во-первых, это – низкоуровневое API. К сожалению, вся документация здесь ограничивается кратким javadoc. И хотя, по-видимости, это наиболее эффективный и предсказуемый способ работы, отсутствие документации и высокая трудоемкость реализации операций (например, создания зависимых объектов) делают его использование проблематичным.
Во-вторых, это использование JDO или JPA. Этот способ рекомендуется google, а по JDO есть учебник с примерами. К сожалению, здесь все обстоит крайне неважно. Реализация API для JDO/JPA создана компанией DataNucleus. Для работы с конкретным хранилищем данных эта реализация требует специальный плагин для этого хранилища. Плагин для хранилища google, написанный программистами google, получился не слишком удачным. Там имеется множество ограничений и отклонений от спецификаций JDO/JPA, не описанных ни на сайте google, ни на сайте DataNucleus. Поэтому, если вы выбираете этот способ работы с хранилищем, будьте готовы к сюрпризам и дополнительным временным затратам. Из-за такого двойственного характера этого продукта вам не удастся получить разъяснения ни от одной, ни от другой компании. В интернете есть много сайтов, посвященных этой теме. Например, этот http://datanucleus.blogspot.com/2010/01/gaej-and-jdojpa.html
В-третьих, как альтернатива двум вышеописанным подходам, сейчас активно развивается несколько оригинальных продуктов, являющихся “тонкой” обверткой над низкоуровневым API. Здесь я, к сожалению, не вижу возможности подробно рассмотреть степень их готовности, качество, удобство, уровень документированности и т.п.. Это тема для отдельного поста. Однако, чтобы не быть голословным, приведу ссылки:
+ в заключение насколько допонительных ссылок, описывающих чужой опыт использования GAE, его ограничения и рекомендуемые подходы к проектированию ПО (на английском):
Надеюсь, изложенное здесь и эти ссылки помогут вам принять верное решение об использовании GAE в вашем проекте.
