В первой части этой серии мы рассмотрели базовую среду, которую GAE предлагает разработчику. Вы должны быть взволнованы, чтобы заставить себя написать свое первое приложение и увидеть его вживую! Настройка IDE для разработки GAE — довольно простая задача: просто установите плагин GAE в выбранной вами версии Eclipse, и вы можете начать разработку на GAE.
Но прежде чем мы перейдем к API и услугам, которые может предложить GAE, давайте разберемся со структурой и конфигурацией приложения, которые влияют на работу вашего приложения во время выполнения. Это также проведет нас через некоторые интересные аспекты среды и приведет к улучшению дизайна и планирования приложения.
Дескриптор развертывания: web.xml
Описатель развертывания веб-приложения в GAE, как и любое другое веб-приложение, настраивает сопоставления URL-адресов сервлетов и JSP таким же образом, или URL-адреса защищены, а роли задаются так же, как в веб-приложении. Фильтры и обработчики ошибок также могут быть использованы таким же образом. Следует отметить несколько незначительных отличий: EJB / JNDI и т.п. не поддерживаются, это очевидно, поскольку у нас нет контейнера EJB. Загрузка при запуске не загружает сервлет при запуске приложения, но когда веб-сервер получает первый запрос. Некоторые обычные конфигурации, такие как настройка ServletContextListener или параметры загрузки при запуске, могут быть настроены, но помещены в appengine-web.xml.
Конфигурация приложения: appengine-web.xml
Файл appengine-web.xml является обязательным требованием для веб-приложения GAE и, как минимум, содержит идентификатор и версию приложения. При развертывании приложения номер версии используется, чтобы решить, развертывать ли в существующей версии, если совпадение найдено, или развертывать в новой версии, если совпадение не найдено. Это особенно полезно иметь несколько экземпляров приложения для тестирования, не затрагивая живой экземпляр. Обратите внимание, что хранилище данных совместно используется версиями приложения.
<? xml version = "1.0" encoding = "utf-8"?> <appengine-web-app xmlns = "http://appengine.google.com/ns/1.0"> <Приложение> мой-приложение </ приложение> <Версия> 2 </ версия> </ AppEngine-веб-приложение>
В приведенном выше XML-коде приложение my-app версии 2 развертывается.
Обслуживание статического контента
Статический контент может быть помечен тегом <static-files>, чтобы весь статический контент обслуживался отдельным веб-сервером, что является хорошей практикой в веб-приложениях, о чем вы, возможно, знаете. Статический контент не сильно меняется в жизненном цикле приложения, и обслуживание статическим сервером оставляет серверу контейнера / приложения возможность сосредоточиться на динамическом контенте, что лучше всего. Это включает в себя выражение, которое сначала принимается во внимание, и даже если вы не указали значение по умолчанию, которое будет применено, за ним следует применение выражения исключения
В следующем примере все файлы jpg помечаются как статические, за исключением файлов в каталоге классов. Аналогичное выражение может быть определено для файлов ресурсов с тегом </ resource-files>. Параметр expiration внутри тега include устанавливает срок действия кэша для браузеров, например, в приведенном ниже примере установлено значение 36 часов.
<статические-файлы> <include path = "/ **. jpg" expiration = "1d 12h /> <exclude path = "/ classes / **. jpg" /> </ Статические-файлы>
Свойства системы и среды
Свойства уровня системы и среды можно установить с помощью следующих тегов:
<система-свойства> <property name = "my-app.user.timeout" value = "300" /> </ Система-свойства> <ENV-переменные> <env-var name = "ENV_VAR_NAME" value = "ENV_VAR_VALUE" /> </ ENV-переменные>
Настройка входящих сервисов
Существуют определенные входящие службы, такие как почта или XMPP, которые по умолчанию отключены. Если вам нужно включить их, вам нужно добавить их специально в appengine-web.xml, как показано в примере ниже.
<входящие-услуги> <Служба> channel_presence </ услуги> </ Входящие-услуги>
|
Сервисы |
Описание |
|
почта |
Включает входящие электронные письма |
|
channel_presence |
Позволяет клиентам использовать канал и включает уведомления |
|
разогреть |
Используется для прогрева определенных компонентов приложения при запуске |
|
xmpp_presence xmpp_message xmpp_subscribe |
Услуги, связанные с XMPP |
Механизм сессии
GAE предлагает механизм сеанса с использованием интерфейса сеанса сервлета, но по умолчанию отключен, и для его включения необходимо добавить следующее в appengine-web.xml:
<Сессий с поддержкой> True </ сессий с поддержкой>
Данные сеанса хранятся в хранилище данных с объектами типа _ah_SESSION, а также хранятся в MEMCACHE для более быстрого доступа. Вы можете уменьшить задержку, пометив данные сеанса, записанные в хранилище данных, как асинхронные. Запись данных сеанса в хранилище данных выполняется с помощью очереди, если не указано, что это очередь «по умолчанию», но ее можно настроить для других имен.
<async-session-persistence enabled = "true" queue-name = "sessionQueue" />
Конфигурация индекса
Индексы используются для ускорения поиска данных. В GAE индексы могут быть определены разработчиком / пользователем, а также автоматически генерируются сервером разработки.
|
Имя файла |
Детали |
|
WEB-INF / хранилищу-indexes.xml |
Индексы, определенные пользователем / разработчиком |
|
WEB-INF / AppEngine генерируемые / хранилища данных-индексы-auto.xml |
Индексы автоматически генерируются сервером разработки при выполнении запросов к данным |
Давайте посмотрим на структуру типичного datastore-indexes.xml и два ключевых аспекта, которыми он управляет.
<? xml version = "1.0" encoding = "utf-8"?> <Datastore-индексы AutoGenerate = "истинный"> <datastore-index kind = "Employee" ancestor = "false"> <property name = "employeeNumber" direction = "asc" /> </ Датастор-индекс> </ Datastore-индексы>
Сначала посмотрите на дочерний элемент, <datastore-index>. Этот тег определяет вид сущности, для которой вы будете определять индекс. Атрибут ancestor должен иметь значение true, если индекс поддерживает фильтрацию объекта по родительской группе объектов. Тег свойства определяет имя свойства, которое является индексами и направлением, которое может быть «asc» или «dsc».
Второй аспект, который определен в родительском теге файла, то есть внутри <datastore-indexes>, управляет обработкой автоматически сгенерированных индексов.
|
AutoGenerate =»истина» |
— По умолчанию true, если пользовательский индексный файл не существует. — Обновляется, когда сервер разработки выполняет запрос, для которого индекс не определен ни в одном из файлов индекса, и добавляет индекс в datastore-indexes-auto.xml. — Когда вы загружаете приложение в GAE, оба файла индекса используются для построения индексов в GAE. |
|
AutoGenerate =»ложь» |
— Индексы в datastore-indexes-auto.xml игнорируются — Когда приложение выполняет запрос, для которого в datastore-indexes.xml не определен индекс, возникает исключение |
Запланированные задачи: cron.xml
Определить и запланировать крон
Cron — это очень знакомое слово для пользователей UNIX-подобных ОС и мощный инструмент, позволяющий выполнять некоторые задачи через определенные промежутки времени, периодически или только в одноразовых случаях, но запускается системой самостоятельно в указанный промежуток времени / интервал. Кроны GAE просты в использовании и отлично подключаются к вашему веб-приложению. Задание определено в сервлете, и вы настраиваете URL для него в дескрипторе развертывания. URL для задания и расписания — это только два обязательных требования для настройки cron в cron.xml. Если вы не определили цель, она будет использовать экземпляр приложения по умолчанию, но вы можете запустить cron для конкретной версии экземпляра, с которой нужно работать. Файл Cron может иметь до 20 крон, а файл XML находится в каталоге WEB-INF вашего приложения.
Формат расписания почти английский, например «каждые 6 часов» или «1-й вторник января, апреля, июня, 05:00»
<? xml version = "1.0" encoding = "UTF-8"?> <Cronentries> <Хрон> <URL> / DailyReport </ url> <description> Необязательный Desc идет сюда </ description> <расписание> каждый день 11:30 </ расписание> <Часовой пояс> Америка / New_York </ часовой пояс> <Цель> Версия-2 </ цель> </ Хрон> </ Cronentries>
Доступ и защита Cron Jobs
Пока запись в «url» cron доступна в виде URL-адреса веб-приложения, задание cron должно работать нормально. Следующее, о чем вам нужно позаботиться, это не разрешить доступ к cron любому пользователю, кроме system / admin, добавив URL-адрес и соответствующие роли администратора, которые могут получить к нему доступ в дескрипторе развертывания.
Мы уже поняли почти все конфигурации и среду GAE. Мы не рассмотрели конфигурации бэкенда и очереди задач, так как они будут более адекватно объяснены в контексте этих специальных тем. Мы готовы нырнуть сейчас, после демонстрации земли и неба! Так что следите за следующей частью и настройте свою IDE и мозги для некоторых рук!