Разработка серверной части многопользовательского интерактивного приложения

Другим типом  сетевого сервера может являться фоновый web-сервер. В этом случае, он размещается за прокси-сервером и выполняет ряд функций, в то время как прокси-сервер распределяет заявки по нескольким web-серверам и осуществляет кэширования части содержимого.

Кэширующие серверы – специальные фоновые службы, предназначенные для оптимизации работы с данными. Представителем кэширующих серверов является memcached, который позволяет приложению хранить объекты в распределенном кэше, расположенном в оперативной памяти. Кэширующие серверы так же могут работать посредством стека протоколов TCP/IP, но часто реализуются через Unix IPC. Данные службы решают следующую задачу: в некоторых случаях «достать» объект из БД значительно сложнее, чем сделать то же самое из локальной оперативной памяти, зная его имя или идентификатор. С помощью кэширующих серверов создается кэш объектов с устареванием и вытеснением данных в оперативной памяти, который используется для ускорения операций с объектами. В данном случае приложение, прежде чем запросить объекты у СУБД, запрашивает их у кэша. В случае промаха, происходит запрос к СУБД.

Службы отложенного и периодического выполнения заданий – данные службы применяются наиболее часто. Их цель – выполнить некоторое действие с определенной периодичностью или в определенный момент времени. Часто данные сервисы реализуются посредством запуска сценариев при помощи сервиса CRON. Типичный пример использования данного типа служб – проверка пользовательских квот и блокировка при превышении. Данная операция эффективно выполняется при помощи периодических проверок. С точки зрения реализации кода, который будет выполнять функции, возможно предложить 2 варианта:

1. отдельный сценарий, который содержит в себе всю необходимую бизнес-логику;
2. запуск web-страницы, при помощи специального средства, например, wget.

Оба средства имеют определенные преимущества и  недостатки, которые и определяют тот или иной вариант использования.

Службы предварительной подготовки данных применяются в тех случаях, когда выборка данных из источника ресурсоемка и требует большого времени. В данном случае используются службы периодического выполнения заданий, с помощью которых данные в СУБД подготавливаются таким образом, чтобы приложение могло сделать это эффективно. Например, если имеется общая таблица статей или почтовых сообщений большого размера за весь период работы сервиса, то служба предварительной подготовки данных может создавать усеченные версии данной таблицы по датам. Аналогично, данные службы могут заранее подготавливать некоторые агрегированные данные, чтобы упростить запросы к СУБД и уменьшить время реакции приложения. Основной недостаток данных служб – запаздывание. Это означает, что всегда некоторые данные находятся в неактуальном состоянии - хотя бы на несколько секунд.

Прокси-серверы применяются часто в тех случаях, когда требуется кэшировать и распределять информацию между несколькими web-серверами. Однако, существует интересный способ использования прокси-сервера для удаленного общения с web-сервисом, например, eBay. В данном случае мы имеем возможность ограничить количество соединений с web-сервисом и одновременно обеспечить кэширование его ответов, чтобы уменьшить количество запросов и время реакции.

В современных web-приложениях практически всегда присутствует фоновая часть. На этапе  проектирования следует выделить фоновые службы, проанализировать планируемый размер БД и, основываясь на этих данных, спроектировать приложение.

Больших успехов в разработке современных web-приложений и добилась команда компании Google. Современные серверные системы характеризуются способностью распределять нагрузку и автоматически переключать пользователя на другой сервер при отказе текущего, пользователь при этом даже не замечает разницы.

Стоит также упомянуть  об одном из принципов организации Web 2.0 приложений – mush up, перемешивание. Использование комплекса услуг сторонних сервисов. Так, например, использование сервиса Google Maps при создании сайтов аренды недвижимости будет обеспечивать пользователя наглядной и удобной формой предоставления информации.

 

2. СЕРВЕРНАЯ ЧАСТЬ С ТЕХНОЛОГИЕЙ JAVA ENTERPRISE EDITION

1. Веб-сервисы

Технология  Java предоставляет надежную, широко распространенную, независимую от операционной системы платформу, позволяющую быстро создавать и запускать сетевые сервисы. Основой Web-сервисов является воплощенное в платформе J2EE, открытое, часто используемое решение, которое согласуется с существующими системами и предоставляет новые динамичные сервисы с ключевыми технологиями, такими как Enterprise JavaBeans^TM, JavaServer Pages^TM, сервлеты, поддержка XML.

Преимущества  технологии Java:

1. Надежная высокоразвитая открытая платформа для создания и установки Web сервисов.
2. Возможность легкой адаптации к новым стандартам.
3. Улучшенные возможности разработки и внедрения новых сервисов.
4. Внутренняя низкоуровневая защита. По мере персонализации сетевых сервисов возрастают требования к безопасности и аутентификации.
5. Единая платформа для целого ряда устройств.
6. Сквозная архитектура для разработки, внедрения, поддержки и обслуживания Web сервисов.

Java технология обладает  поддержкой ИТ-индустрии и программистов.  Она широко распространена на  настольных компьютерах, серверах, мобильных устройствах, а также  может быть быстро перенесена  на цифровые телевизоры, автомобили, бытовую технику. Ни одна другая  технология не обладает столь  широкой областью применения  и такой поддержкой разработчиков.

Java обладает следующими спецификациями для разработки и развертывания веб-сервисов:

1. SAAJ
2. JAX-RPC
3. JAX-WS
4. JAXB
5. JAX-RS

В данной работе мы не будем  сильно заострять внимание на разработке сервиса при помощи платформы JEE.

2. Servlets/JSP

Другой вариант  реализации «общения» с сервером это Servlets/JSP. Для этого необходимо создать сервлет, который будет обрабатывать GET и POST запросы от клиента, и выдавать соответствующие ответы, как в виде html-страниц, так и набора параметров для обработки на клиенте. В частности остановимся на втором.

Передачу  данных можно реализовать многими  способами. Выделим два самых популярных:

1. передача параметров по принципу «ключ-значение» с помощью GET или POST
2. передача JSON объекта в виде текстовой строки с помощью POST

Второй вариант удобнее  использовать совместно с JavaScript, ActionScript, одним из примеров такого принципа работы является почта Google Mail.

В практической части моей работы выбран именно этот вариант  из соображений более удобной  работы с ActionScript клиентом.

В Приложении А представлен JSON файл авторизации на сервере.

 

3. РЕАЛИЗАЦИЯ JEE ПРИЛОЖЕНИЯ НА ПЛАТФОРМЕ GOOGLE APP ENGINE

1. Платформа Google App Engine

С помощью App Engine можно создавать веб-приложения на базе стандартных технологий Java и выполнять их в масштабируемой инфраструктуре Google. Среда Java предоставляет виртуальную машину Java 6, интерфейс сервлетов Java, а также поддержку стандартных интерфейсов для масштабируемого хранилища данных и служб App Engine, таких как JDO, JPA, JavaMail и JCache. Стандартные средства поддержки упрощают разработку приложений, делают среду привычной и позволяют перемещать приложения непосредственно между средой разработки и собственной средой сервлетов.

App Engine выполняет приложения Java с использованием виртуальной машины Java 6 (JVM). Пакет SDK для службы App Engine поддерживает Java 5 и более новые версии, а виртуальная машина Java 6 может использовать классы, скомпилированные любой версией компилятора Java вплоть до версии Java 6.

Служба App Engine использует в веб-приложениях стандарт сервлетов Java. Классы сервлетов приложений, страницы JSP, статические поля и файлы данных, а также дескриптор развертывания (файл web.xml) и прочие файлы конфигурации развертываются в виде стандартной структуры каталогов WAR. App Engine обслуживает запросы, вызывая сервлеты согласно дескриптору развертывания.

JVM выполняется в защищенной тестовой среде, изолирующей приложения в целях обслуживания и безопасности. Эта тестовая среда гарантирует, что приложения выполняют только те действия, которые не угрожают производительности и возможностям масштабирования прочих приложений. Например, приложение не может создавать потоки, записывать данные в локальную файловую систему или создавать произвольные сетевые подключения. Приложение также не может использовать JNI или иной встроенный код. JVM может выполнять любой байтовый код Java, работающий в условиях ограничений тестовой среды.

App Engine предоставляет масштабируемые службы, которые могут использоваться приложениями для хранения постоянных данных, доступа к ресурсам по сети и выполнения прочих задач, таких как обработка данных изображений. По возможности интерфейсы Java соответствуют принятым стандартным API, что позволяет перемещать приложения в службу App Engine и из нее. Каждая служба также предоставляет полнофункциональный низкоуровневый интерфейс для реализации новых интерфейсных адаптеров и прямого доступа.

Приложения могут использовать хранилище данных App Engine для надежного и масштабируемого хранения данных. Хранилище данных поддерживает два интерфейса Java: JDO 2.3 и JPA 1.0. Эти интерфейсы реализованы с помощью платформы доступа DataNucleus – реализации этих стандартов на основе открытого кода.

Служба Memcache App Engine обеспечивает быстрое распределенное временное хранение данных для кэширования результатов вычислений и запросов к хранилищу данных. Интерфейс Java реализует JCache.

Для доступа к сетевым  ресурсам и обмена данными с другими  узлами по протоколам HTTP и HTTPS приложения используют службу получения данных по URL. Для доступа к этой службе приложения Java могут просто использовать класс java.net.URLConnection и связанные с ним классы стандартной библиотеки Java.

Для отправки сообщений электронной  почты от имени администратора приложения или текущего пользователя приложение может использовать службу Mail. При отправке сообщений электронной почты используется интерфейс JavaMail.

Служба изображений позволяет  приложениям преобразовывать и  обрабатывать данные изображений в  нескольких форматах, выполняя обрезку, поворот, изменение размера и  улучшение цветов. Служба способна выполнять ресурсоемкие задачи обработки  изображений, оставляя большую часть  ресурсов App Engine для обработки веб-запросов

Для аутентификации приложение может использовать службу Аккаунтов Google. Служба Аккаунтов Google выполняет операции по созданию аккаунтов и входу пользователей, а пользователи, уже имеющие аккаунты Google, могут использовать их в приложении. Приложение определяет, когда текущий пользователь выполняет вход, и обращается к адресу электронной почты этого пользователя. Приложения Java могут использовать ограничения безопасности, заданные в дескрипторе развертывания, для управления доступом с помощью Аккаунтов Google и в случае входа пользователя получать его адрес электронной почты. Для создания URL входа и выхода приложение может использовать низкоуровневый API Аккаунтов Google и получать объект данных о пользователе для его хранения в хранилище данных.

В приложении можно настроить  запланированные задачи для вызова URL приложения с заданной периодичностью.

Пакет Java SDK для службы App Engine содержит средства тестирования приложений, добавления файлов приложений и загрузки данных журналов. Пакет SDK также содержит компонент для Apache Ant, упрощающий выполнение стандартных задач в службе App Engine. Подключаемый модуль Google для Eclipse добавляет в среду Eclipse функции для разработки, тестирования и развертывания приложений App Engine и включает полный пакет SDK для App Engine. Подключаемый модуль Eclipse также упрощает разработку приложений Google Web Toolkit и их выполнение в службе App Engine. На рисунке 2 представлена консоль администрирования приложения.

Рисунок 2. Консоль администрирования GAE

В процессе разработки и тестирования сервер разработки выполняет приложения на локальном компьютере. Сервер эмулирует  хранилище данных, службы и ограничения  тестовой среды App Engine. Сервер разработки также может создавать конфигурацию для индексов хранилища данных на основе запросов, выполняемых приложением в ходе тестирования.

Многоцелевое средство AppCfg обрабатывает взаимодействие из командной строки с приложением, выполняющимся на сервере App Engine. Средство AppCfg способно как добавлять приложения на сервер App Engine, так и просто обновлять индекс хранилища данных, что позволяет создавать новые индексы до обновления кода. Оно также может загружать данные журнала приложения для анализа его работы с помощью собственных средств.

2. Панель администрирования

Любое серверное приложение содержит панель администрирования  для непосредственного доступа  к БД, контроля действий пользователей, настройки приложения и выявления  неполадок путем изучения системных  логов.

В данной приложении для создания панели администрирования задействован популярный, зарекомендовавший себя, MVC фреймворк Struts 1.3.10.

В обычном Java EE веб-приложении клиент, как правило, отправляет информацию на сервер из формы. Введённые данные передаются сервлету, который обрабатывает её, при необходимости взаимодействуя с БД, и формирует HTML ответ. Для больших проектов , например, для портала с сотнями страниц, такой подход является неадекватным, так как объединяет бизнес логику и логику отображения, что делает поддержку чрезвычайно сложной.

Struts был создан для того, чтобы чётко разделить модель, бизнес-логику, представление, HTML-страницы, и контроллер, отвечающий за передачу данных от модели к представлению и обратно. Struts предоставляет стандартный контроллер — сервлет под именем ActionServlet и различные средства для создания страниц представления. Разработчик веб-приложения отвечает за написание кода модели и создание конфигурационного файла struts-config.xml, который связывает воедино модель, представление и контроллер.