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

МИНИСТЕРСТВО ОБРАЗОВАНИЯ РЕСПУБЛИКИ ПРУССИЯ

ПРУССКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

 

Факультет Ядерных Проблем

 

 

Кафедра интеллектуальных систем

 

 

 

 

РАЗРАБОТКА  СЕРВЕРНОЙ ЧАСТИ МНОГОПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРАКТИВНОГО ПРИЛОЖЕНИЯ

 

Курсовая работа студента 3 курса

МАРКЕЛЛОВА Егора

 

Руководитель: канд. физ.-мат. наук, доцент

БЕЛЕГ Иван

 

 

 

 

 

 

 

 

Прусск, 2012

СОДЕРЖАНИЕ

Перечень сокращений условных обозначений, символов, единиц и терминов 3

Введение 5

1. Разработка много пользовательских интерактивных приложений 6

1.1. Общая структура 6

1.2. Клиентская часть 9

1.3. Серверная часть 11

2. Серверная часть с технологией Java Enterprise Edition 14

2.1. Веб-сервисы 14

2.2. Servlets/JSP 15

3. Реализация JEE приложения на платформе Google App Engine 16

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

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

3.3. Скрипт обработки 20

Заключение 21

Список использованных источников 22

Приложение А 23

Приложение Б 26

Приложение В 27

 

 

ПЕРЕЧЕНЬ СОКРАЩЕНИЙ УСЛОВНЫХ ОБОЗНАЧЕНИЙ, СИМВОЛОВ, ЕДИНИЦ И ТЕРМИНОВ

БД – база данных

СВЧ – сверхвысокая частота

СУБД - Система управления базами данных

API - Application programming interface

CRUD - Create Read Update Delete

DOS - Disk Operating System

GAE – Google App Engine

HTTP - HyperText Transfer Prоtocоl

HTTPS - Hypertext Transfer Protocol Secure

HTML – Hypertext Markup Language

IPC - Interprocess Communication

IoC – Injection of Control

JAX-RPC - Java API for XML-based RPC

JAX-WS - Java API for XML Web Services

JAXB - Java Architecture for XML Binding

JAX-RS - Java API for RESTful Web Services

JEE – Java Enterprise Edition

JSON - JavaScript Object Notation

JDO - Java Data Objects

JPA- Java Persistence API

JVM - Java Virtual Machine

JSP – Java Server Pages

MVC – Model View Controller

PHP - Hypertext Preprocessor

REST - Representational State Transfer

SOA - Service Oriented Architecture

SOAP  - Simple Object Access Protocol

SAAJ - SOAP with Attachments API for Java

SDK – Software development kit

TCP - Transmission Control Protocol

UDDI - Universal Description Discovery and Integration

UDP - User Datagram Protocol

URL - Uniform Resource Locator

WSDL - Web Service Definition Language

WWW – World Wide Web

WAR - Web application Archive

XML - eXtensible Markup Language

XML-RPC - XML Remote Procedure Call

 

ВВЕДЕНИЕ

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

С развитием  web-технологий не стоят на месте и средства коммуникации. Растет скорость доступа в интернет, меняется принцип подключения. Если около десяти лет назад пользователь имел низкоскоростной dial-up доступ в интернет, то сейчас можно подключиться к интернету почти повсеместно, как со стационарного компьютера, используя ADSL, Ethernet, так и с мобильных устройств, используя Wi-Fi, 3G или WiMAX технологии.

Поэтому будущее  ведет к наличию статического окна браузера, как двери в динамический мир, на широком спектре устройств, будь то компьютер, панель холодильника или витрина магазина.

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

В этой работе мы рассмотрим современные варианты решения серверных частей, произведем сравнение и выбор лучшей платформы.

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

 

1. РАЗРАБОТКА  МНОГОПОЛЬЗОВАТЕЛЬСКИХ ИНТЕРАКТИВНЫХ  ПРИЛОЖЕНИЙ

1. Общая структура

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

Один из вариантов  определения:

Вычислительная модель клиент-сервер - разделение приложения на отдельные задачи, размещаемые на различных платформах для большей эффективности. Как правило, это означает, что программа представления данных находится на машине пользователя (на клиенте), а программа управления данными и сами данные — на сервере. В зависимости от приложения и используемого программного обеспечения вся обработка данных может осуществляться на клиентской машине или распределяться между клиентом и сервером. Сервер соединяется со своими клиентами по сети. Серверное программное обеспечение принимает запросы от клиентского программного обеспечения и возвращает ему результаты.

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

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

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

Это некоторый  прием инкапсуляции функционала  модулей, т.е. имея готовую структуру  приложения, не составит большого труда  поменять, например, сервер БД и т.п. Данный тип представлен на рисунке 1.

Рисунок 1. Трехуровневая система "клиент-сервер"

Главной задачей интернета всегда оставалось объединить мировое сообщество в некоторый динамический ресурс способный быстро и правильно обмениваться нужной информацией или данными. Но сам Интернет — разнороден, т. е. различные приложения на различных узлах сети функционируют на разных аппаратно-программных платформах, и используют различные технологии и языки. Чтобы связать все это и предоставить возможность одним приложениям обмениваться данными с другими, были придуманы веб-сервисы.

Прежде всего, веб-сервисы (или веб-службы) — это  технология. И, как и любая другая технология, они имеют довольно четко очерченную среду применения.

Если посмотреть на веб-сервисы в разрезе стека сетевых протоколов, мы увидим, что это, в классическом случае, не что иное, как еще одна надстройка поверх протокола HTTP.

С другой стороны, если гипотетически разделить Интернет на несколько слоев, мы сможем выделить, как минимум, два концептуальных типа приложений — вычислительные узлы, которые реализуют нетривиальные  функции и прикладные веб-ресурсы. При этом вторые, зачастую заинтересованы в услугах первых.

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

Именно с  появлением веб-сервисов развилась  идея SOA — сервис-ориентированной архитектуры веб-приложений.

На сегодняшний  день наибольшее распространение получили следующие протоколы реализации веб-сервисов:

1. SOAP — по сути это тройка стандартов SOAP/WSDL/UDDI
2. REST
3. XML-RPC

На самом  деле, SOAP произошел от XML-RPC и является следующей ступенью его развития. В то время как REST — это концепция, в основе которой лежит скорее архитектурный стиль, нежели новая технология, основанный на теории манипуляции объектами CRUD в контексте концепций WWW.

Безусловно, существуют и иные протоколы, но, поскольку  они не получили широкого распространения, мы остановимся в этом кратком  обзоре на двух основных — SOAP и REST. XML-RPC ввиду того, что является несколько «устаревшим», мы рассматривать подробно не будем.

Как правило, поставщики веб-сервисов поставляют пакеты с функциями API и документацией, посему вопрос построения клиентов к существующим веб-службам менее интересен с точки зрения автора.

SOAP более применим в сложных архитектурах, где взаимодействие с объектами выходит за рамки теории CRUD, а вот в тех приложениях, которые не покидают рамки данной теории, вполне применимым может оказаться именно REST ввиду своей простоты и прозрачности. Действительно, если любым объектам вашего сервиса не нужны более сложные взаимоотношения, кроме: «Создать», «Прочитать», «Изменить», «Удалить» (как правило — в 99% случаев этого достаточно), возможно, именно REST станет правильным выбором. Кроме того, REST по сравнению с SOAP, может оказаться и более производительным, так как не требует затрат на разбор сложных XML команд на сервере (выполняются обычные HTTP запросы — PUT, GET, POST, DELETE). Хотя SOAP, в свою очередь, более надежен и безопасен.

 

2. Клиентская  часть

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

Затронем  два типа клиентских приложений:

1. приложения выполняемые в браузере устройства
2. непосредственно отдельные приложения операционной системы

Первый тип  зачастую не требует инсталлирования, каких либо дополнительных модулей для запуска на клиентской машине, обладает высокой степенью интерактивности и удобности. Зачастую это легковесные клиенты игр либо вспомогательные «облачные» редакторы, выполненные на Flash, Java или ActionScript.

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

Второй тип делится на два крайних решения: некоторый легковесный клиент, выполняющий задачу создания окна диалога «пользователь-сервер», выполненный на любом из поддерживаемых операционной системой языках. Либо приложение, обладающее широким спектром функциональности обрабатываемой клиентской машиной и дальнейшей отправкой на сервер, в отличие от первого типа требует больших ресурсов.

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

Большой спектр современных клиентских приложений представлен платформой Android и растущим количеством смартфонов. Поэтому разработка данных приложений сейчас пользуется большим интересом в связи с хорошими перспективами и простотой разработки.

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

 

3. Серверная часть

Работу сервера  можно разделить по принципу обработки  запроса на два типа: веб сервисы  и сервера работающие с данными  по простому принципу передачи «ключ-значение».

Сейчас разработчик  стоит перед широким выбором  языков и фреймворков для разработки серверной части. Каждый из них имеет свои преимущества в зависимости от решаемой задачи.

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

С++ обычно используется для создания сильно нагружаемых систем с быстрым временем отклика, почти всегда приходится писать «с нуля», что требует много времени и большого опыта в подобной разработке.

Разработка  на Java делает проекты масштабируемыми, кроссплатформенными, с высокой степенью безопасности и отказоустойчивости. Данный вариант обойдется заказчику дороже, чем PHP или т.п.

Также прекрасно  в этой области зарекомендовали  себя такие языки и платформы  как Python ,.NET, Ruby и Erlang.

Иногда нельзя решить задачу в пределах одного серверного приложения без помощи некой фоновой  службы, выполняющей определенный спектр отдельных задач для главного приложения. Рассмотрим виды фоновых служб.

Все фоновые  службы могут быть разделены на следующие  классы:

1. сетевые серверы (в том числе web-серверы);
2. кэширующие серверы;
3. службы отложенного и периодического выполнения заданий;
4. службы предварительной подготовки данных;
5. прокси-серверы;

Данные классы выделены по функциональному назначению и принципу выполнения служб в  приложении.

Сетевые серверы – фоновые серверы, работающие по сетевым протоколам TCP/UDP и вышестоящим (например, HTTP). Данные серверы недоступны извне и предназначены для обслуживания собственных нужд приложения. Основное назначение данных служб – оптимизированное обслуживание запросов web-приложения. Данный подход может применяться в тех случаях, когда единая служба, выполняющая запросы от web-приложения может действовать более эффективно, чем реализация той же бизнес-логики в рамках приложения. Например, требуется запросить данные удаленно от некоторого web-сервиса из высоко нагруженного приложения. В том случае, если мы реализуем запрос данных у web-сервиса в рамках web-приложения, то в лучшем случае получим DOS, а в худшем web-сервис может перестать функционировать. Для решения данной проблемы может использоваться TCP-сервер с пулом соединений, асинхронно открывающий соединения на web-сервис. Данное решение широко используется нами при работе с eBay API.