Основы проектирования интернет-приложений 1.1.Основные понятия интернет-приложений
В данной главе рассмотрены основные определения, связанные с интернет-приложениями.
1.1.1.Интернет и его особенности
Интернет – Interconnected Networks – объединенные сети, глобальная телекоммуникационная сеть информационных и вычислительных ресурсов. В разгар холодной войны, 4 октября 1957 года, СССР запустил первый искусственный спутник Земли, тем самым получив преимущество в космосе. В США решили, что деньги, отпущенные Пентагоном на научные исследования, тратятся впустую, поэтому было принято решение создать единую научную организацию под покровительством Министерства обороны – ARPA (Advanced Research Projects Agency). Один из разрабатываемых передовых проектов – это распределенная децентрализованная вычислительная сеть, способная пережить даже ядерную войну. Существующие в то время телефонные сети не обеспечивали достаточной надежности: выход из строя одного крупного узла мог разделить сеть на изолированные участки. В декабре 1969 года была создана экспериментальная сеть, построенная на принципах цифровой коммутации пакетов и соединяющая 4 узла:
калифорнийский университет в Лос-Анджелесе;
калифорнийский университет в Санта-Барбаре;
исследовательский университет Стенфорда;
университет штата Юта.
Это событие считается рождением современного интернета.
Особенности интернета:
интернет не имеет собственника, является достоянием всего человечества;
интернет нельзя выключить целиком;
интернет может связать каждый компьютер с любым другим;
чтобы из множества подключенных к интернету устройств выбрать нужный, существуют две составляющих части: это адреса и имена участников сети.
1.1.1.1.Адрес в интернете
Для идентификации компьютера в интернете используются адреса. В настоящее время работают одновременно две версии адресации:
IP v4, представляющая собой четырехбайтное число (32 бита). Для удобства работы цифры адреса разделяют между собой точкой. Например, адрес локальной машины – это 127.0.0.1.
IP v6, 128 бит. Восемь групп по 4 шестнадцатеричных цифры, разделенных двоеточием. Пример адреса:
2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d
Нули могут заменяться двумя двоеточиями. Тот же адрес локальной машины можно написать как ::1. Используется одновременно с IP v4 за счет так называемого «отображения адресов» ::FFFF:xx.xx.xx.xx дает IP v4 адрес, то есть младшие 32 бита при этом равны ip v4 адресу. Такой подход дает возможность с сетей IP v6 обращаться к тем хостам, которые поддерживают только IP v4.
В обоих стандартах существуют особые группы адресов. Сюда относятся так называемые не маршрутизируемые адреса, предназначенные для организации локальных сетей и служебного взаимодействия самих маршрутизаторов между собой внутри сетей провайдера – это мультикастовые адреса, предназначенные для широковещательных сообщений, когда одно сообщение передается одновременно нескольким получателям (но не одному и не всем участникам сети); адреса, уникальные только в пределах одного компьютера (локальные адреса).
1.1.1.2.Имя в интернете
Другой важной составляющей интернета является служба имен (DNS, Domain Name System), которая предназначена для представления адресов компьютеров в более человеческой универсальной форме. Служба DNS преобразует полученное имя хоста (строку) в IP-адрес устройства. Ключевым элементом отсчета является точка («.» так и называется – домен точка, или корневой домен, или домен нулевого уровня). Домен точка разделен на зоны (.com., .org., .net., .ru. и так далее). В связи с тем, что домен точка присутствует в адресе всегда, он опускается в записи адреса (последняя точка не указывается, вместо urfu.ru. пишут urfu.ru).
Существует несколько утилит, позволяющих вручную провести распознавание адреса. Направлены эти утилиты прежде всего на то, чтобы диагностировать работоспособность службы DNS на данном участке сети. В частности, можно отметить команды host и nslookup:
sally ~ # host urfu.ru
urfu.ru has address 93.88.190.5
urfu.ru mail is handled by 100 relay1.urfu.ru.
urfu.ru mail is handled by 200 relay2.urfu.ru.
У DNS существует как прямое направление распознавания (по имени найти IP-адрес), так и обратное (по адресу найти имя). В общем случае полученные значения могут не совпадать между собой, потому что один физический IP-адрес может иметь несколько имен. В приведенном выше примере адрес urfu.ru и его IP-адрес не совпадают между собой в прямом и обратном направлении:
sally ~ # host 93.88.190.5
5.190.88.93.in-addr.arpa domain name pointer ustu.ru.
Для идентификации ресурса в интернете существуют определенные стандарты. Чтобы получить конкретный ресурс (документ, изображение, почтовое сообщение, вызываемую процедуру и так далее), кроме собственно адреса хоста, на котором этот ресурс расположен, нужно указать еще ряд параметров. В общем случае строка идентификации ресурса согласно спецификации URL (Uniform Resource Locator) выглядит следующим образом:
имя_службы://имя_хоста.имя_домена.зона:порт/имя_ресурса
Кроме того, указанная строка при необходимости может быть дополнена именем входа/паролем, а также дополнительными произвольными параметрами, передаваемыми в запросе ресурса (например, параметрами для вызова RPC-процедуры).
Вот как выглядит адрес ресурса, предоставляющего сведения о погоде в Екатеринбурге:
http://www.gismeteo.ru/city/hourly/4517/#wdaily1
Забегая вперед, отметим, что довольно часто при разработке интернет-приложений появляется необходимость обмана службы DNS с путем присвоения некоторым соседним компьютерам фиктивных имен, на самом деле DNS не распознаваемых. Либо второй вариант – присвоить одному компьютеру несколько имен. Делается это при помощи файла hosts. В MS Windows файл hosts расположен в каталоге c:\Windows\System32\drivers\etc\, в *nix системах – в каталоге /etc.
Например, мы хотим одновременно разрабатывать на одном компьютере два web-приложения. Одно из них представляет собой библиотеку книг с указанием автора и краткой аннотацией и называется library. Другое из них посвящено учету персональных финансов и называется purse. Когда приложения будут готовы, в файлы DNS будут внесены соответствующие изменения, и имена станут доступны всем пользователям интернета, но на этапе разработки это не обязательно. Достаточно внести следующую строчку в упомянутый файл hosts:
127.0.0.1 localhost purse library
Компьютер, за клавиатурой которого непосредственно производится разработка обоих указанных приложений (то есть «локальный» компьютер) будет откликаться на два этих имени.
Такой подход (обман) не позволит подключиться любому пользователю интернета к вашим приложениям. Но он дает возможность организовать на одном компьютере два независимых виртуальных хоста и обращаться к ним из строки браузера, набирая в ней (на локальном компьютере): http://purse или http://library и получая ответ от разрабатываемых приложений.
1.1.1.3.Службы (сервисы)
Службы (сервисы) – это информационные системы, разработанные для предоставления конкретных информационных услуг в сети интернет. Они включают в себя наборы программ и протоколов прикладного уровня, обеспечивающих пользователей сети возможностью выполнять работу с распределенными информационными ресурсами. Каждый сервис базируется на своем протоколе (или семействе протоколов), который позволяет клиентам и сервисам общаться между собой. Можно привести несколько примеров сервисов, базирующихся на соответствующих протоколах:
служба DNS (BIND, 53 порт). Базис интернета. Неработоспособность службы DNS приведет к неработоспособности всех остальных служб, поэтому существует ряд технических и организационных решений, направленных на обеспечение круглосуточной и бесперебойной работы этой службы в сети;
служба электронной почты (SMTP, POP-3, IMAP);
обмен моментальными сообщениями (ICQ, IRC, Skype);
передача файлов между компьютерами (FTP, SFTP);
управление удаленными серверами, выполнение на них команд удаленным способом, копирование файлов (SSH, RSH, FISH);
управление сетью (SNMP);
служба доступа к каталогам справочной информации (LDAP).
Наиболее известным сервисом в интернете является web-сервис (WWW, World Wide Web, «Всемирная паутина»), предоставляющий пользователям доступ к документам с использованием протокола HTTP. Очень часто между понятиями интернет и web ошибочно ставят знак равенства. Между тем, протокол HTTP, лежащий в основе службы web, безусловно, самый распространенный, но все же один из многих протоколов передачи данных, объединенных между собой названием интернет.
1.1.1.4.Сокета
Сокета представляет собой абстракцию, программный объект внутри операционной системы, с помощью которого происходит соединение клиентской и серверной части. При этом клиент и сервер могут находиться как внутри одного и того же компьютера, так и быть на разных компьютерах.
Представим себе такую ситуацию: вам звонят по телефону. При этом и вы, и звонящий вам абонент берете в руки телефонные трубки. Вас не интересуют подробности работы телефонной сети. Вы не знаете, какими базовыми станциями обслуживается ваш разговор, по каким каналам связи идет сигнал, где и какое сработало коммутационное оборудование и так далее. Зато вы знаете, что если набрать номер, через какое-то время установится соединение и можно будет говорить. Причем делать это нужно по очереди. То есть для общения вы должны соблюдать некоторый протокол, последовательно обращаясь к некоторым функциям трубки (набрать номер, дождаться ответа абонента, говорить). Можно сказать, что телефонная сеть для вас представлена трубкой. То же самое справедливо и для сокеты: сразу за ней начинается сеть, но подробности работы самой этой сети приложению знать не обязательно, достаточно вызывать некоторые функции объекта сокеты в определенном порядке (то есть с соблюдением протокола).
Сокета – объект универсальный, единый по своей сути для клиентской и серверной стороны. После ее создания при помощи вызова соответствующих методов сокета может стать как клиентской, так и серверной. Если воспользоваться аллегорией, то серверная сокета – это электрическая розетка в стене. У этой розетки есть замечательное свойство: она всегда является свободной. Как только к ней подключается клиент (вилка), сервер сразу же порождает новый процесс, обслуживающий данное соединение. Розетка с включенной в нее вилкой отходит в сторону, где происходит непосредственно обмен данным между конкретным клиентом и сервером. А исходная розетка по-прежнему остается свободной, доступной для следующих соединений. Каждый подключившийся клиент занимает определенные ресурсы операционной системы, поэтому при создании серверной сокеты указывается максимально допустимое число клиентских соединений.
Для работы с созданной сокетой точно так же, как и с любым другим устройством операционная система использует дескриптор – беззнаковое целое число, идентифицирующее ресурс внутри операционной системы. После получения дескриптора в сокету можно писать данные, читать из нее, назначать на нее некие обработчики событий (сигналов) и так далее. Существует великое множество библиотек для работы с сокетами, которые предоставляют реализацию функций либо вообще готовых классов клиентской и серверной сокеты. Эти библиотеки представляют собой переход на более высокий уровень работы, предназначены для облегчения труда программистов. Действительно, особого смысла каждый раз реализовывать одни и те же низкоуровневые процедуры нет. Однако на нижнем уровне обращение с сокетой в любой из библиотек все равно происходит с использованием именно дескриптора.
Сокета как программный объект характеризуется тремя параметрами: доменом (областью, семейством протоколов, которые могут быть использованы для данной сокеты), типом и портом.
Наиболее распространенными являются следующие домены:
AF_UNIX (AF_LOCAL) – для организации обмена в рамках одного и того же компьютера;
AF_INET, AF_INET6 – по протоколу IP v4 / IP v6 соответственно;
AF_NETLINK – для взаимодействия между пространством пользовательских программ и ядром операционной системы.
Среди типов сокет наиболее распространены три:
SOCK_STREAM – создаваемая сокета, предназначена для организации последовательного потока. При этом между клиентом и сервером устанавливается виртуальное соединение, ошибки в работе которого также обрабатываются сокетой. Соответственно, если мы создадим сокету с доменом AF_INET и типом SOCK_STREAM, такая сокета будет обрабатывать TCP/IP соединение.
SOCK_DGRAM – сокета, предназначена для передачи дейтаграмм. Дейтаграммы (датаграммы, datagram) – это пакеты информации, которые передаются по сети без установления соединения. Они имеют адрес отправителя и получателя, но факт их доставки не гарантируется. Точно так же не гарантируется и порядок прихода дейтаграмм: далеко не факт, что получатель примет сообщения в том же самом порядке, в каком они были переданы. Основной особенностью работы с дейтаграммами является отсутствие временных задержек, вызванных скоростью работы сети. Являются основой протокола UDP (User Datagram Protocol).
SOCK_RAW – так называемая сырая сокета. Данный тип сокеты используется для низкоуровневого программирования, а также при необходимости дополнения существующих протоколов (например, добавления в сообщение собственных заголовков).
Порт сокеты – это беззнаковое целое двухбайтное число, которое определяет службу сервера. Сочетание порт – протокол является уникальным на данном компьютере в том смысле, что если данный порт и данный протокол уже прослушиваются каким-либо процессом, другой процесс не сможет повторно создать такую же сокету. Тот же порт, но с другим протоколом при этом захватить можно. Порты диапазона 0–1023 являются привилегированными, то есть для создания сокеты, прослушивающей данный порт, необходимы особые привилегии. Теоретически любой порт свыше 1024 может быть захвачен первым запросившим его процессом. На самом деле число официально зарегистрированных портов гораздо больше, чем 1024. В качестве примера можно назвать сочетание 3306/tcp, которое используется сервером MySQL по умолчанию. Общепринятые присвоения портов не являются официальным стандартом, и любой созданный пользователем процесс имеет полное право захватить порт 3306/tcp. И иногда программисты намеренно этим пользуются с целью ввести в заблуждение возможных злоумышленников. Однако, если у вас нет на то каких-то особых причин, не стоит использовать в своих программах зарегистрированные пары порт – служба.
После создания сокеты (иными словами, получения от операционной системы дескриптора сокеты) на нее могут быть установлены модификаторы – такие же, как и для любого символьного устройства в операционной системе. Например, сокету можно сделать неблокирующей. При этом, если из сокеты на данный момент нечего читать, то оператор чтения сокеты вернет нулевое количество прочитанных байт (а не приостановит работу программы, как это произойдет в случае с блокирующей сокетой).
1.1.1.5.Протокол HTTP. Виды запросов
HTTP – Hyper Text Transfer Protocol – протокол передачи гипертекста, то есть такого текста, когда вместе с содержимым передается информация по его отображению. Изначально HTTP предназначался для передачи HTML-содержимого. Однако в настоящее время протокол HTTP используется для передачи любой информации произвольного содержания, оставаясь при этом текстовым. Термин текстовый означает, что в ходе работы могут передаваться только отображаемые на экране символы. Например, в принимаемой и передаваемой информации не может быть символа «0». Разумеется, что понятие любая информация подразумевает, что каждый передаваемый байт может принимать все допустимые значения, то есть 0–255 включительно. Такая информация еще называется бинарной. Передача бинарной информации с помощью текстового протокола осуществляется за счет специального кодирования, когда исходная информация на момент передачи видоизменяется таким образом, что содержит только текстовые символы. На клиенте после получения сообщения осуществляется обратное преобразование. С помощью такого механизма посредством HTTP могут передаваться, например, двумерные или трехмерные изображения.
Кроме того, HTTP широко используется как транспортный протокол для передачи между разными программами объектов (экземпляров классов). Информация о структуре объекта (именах полей, их модификаторах, значениях и т. д.) преобразуется в текстовый вид (например, в XML или JSON). В текстовом виде передается по сети и на клиенте осуществляется обратное преобразование из текста в программный объект. Одним из существенных преимуществ подобного метода передачи является то обстоятельство, что клиент и сервер могут быть написаны на разных языках программирования, выполняться на различных архитектурах и т. д. Таким образом, с помощью протокола HTTP связываются между собой гетерогенные приложения в логически единое целое (рис. 1.1).
Рис. 1.1. Пример общения клиента и сервера по HTTP-протоколу
Основой HTTP является технология клиент-сервер, то есть всегда выделяются два участника обмена: клиент, который делает запрос (HTTP Request), и сервер, который отвечает клиенту на данный запрос (передавая по сети пакет HTTP Response). На этом один шаг протокола заканчивается, и данный цикл может повторяться сколь угодно большое число раз. Особенностью HTTP является тот факт, что сам по себе протокол не поддерживает информацию о сессии, не обязан что-либо знать об истории. Иными словами, протокол не предусматривает сохранения состояния. Есть запрос, и есть ответ на него. Причем, как правило, сразу после ответа сервер разорвет TCP-соединение с клиентом с целью более рачительного использования собственных ресурсов. При необходимости клиенты, использующие HTTP, могут самостоятельно сохранять информацию об истории данного сеанса. Для этих целей существуют два механизма:
куки – cookies – небольшие пакеты данных, хранящиеся на стороне клиента и передающиеся вместе с запросом. Как правило, cookie имеет два атрибута, определяющие его сохранение клиентом, то есть возможность сохранения информации на диске. В случае, если cookie разрешается хранить информацию у клиента на диске, указывается время жизни данного cookie на клиентской стороне, после чего он будет считаться устаревшим, не актуальным. В частности, в качестве cookie может выступать уникальный идентификатор сессии на стороне сервера;
сессии – HttpSessions – на стороне сервера. Сессия представляет собой программно-доступный объект, который формируется сервером и содержит в себе информацию о работе с данным клиентом. Объект сессии уникален для сеанса работы с каждым клиентом. Обычно сессия имеет идентификатор, который сохраняется в cookies на клиенте. Механизм сессий скрывает подробности реализации, разработчику нет необходимости отслеживать, что из информации запоминается на клиентской части, а что – на серверной. Достаточно просто получить объект сессии и думать о нем, что он однозначно определяет сеанс данного клиента.
Реализация сервера может хранить информацию о заголовках последних запросов, поступивших с данного IP-адреса. Сам протокол не осведомлен о предыдущих запросах и ответах, внутренняя поддержка состояния в нем не предусмотрена. Текущей версией протокола HTTP/1.1 предусмотрен режим постоянного соединения, то есть установленное tcp/ip соединение может оставаться открытым и после отправки ответа на поступивший запрос. Ключевое слово здесь – может, при разработке собственных интернет-приложений правильнее будет полагать, что HTTP работает как одна-единственная изолированная от контекста пара запрос-ответ.
Вне зависимости от вида запрос это или ответ пакеты в HTTP имеют одинаковую структуру и состоят из следующих параметров:
стартовой строки или строки запроса/ответа. Содержание стартовой строки однозначно идентифицирует тип сообщения (тип пакета). Содержание стартовой строки отличается для запросов и ответов;
заголовков сообщения. Разделенные двоеточием пары имя : значение. Характеризуют тело сообщения (какой сервер используется; когда последний раз менялся объект; что конкретно будет передаваться; в какой форме кодироваться и так далее). Существование заголовков в том числе позволяет передавать с помощью HTTP бинарную (двоичную, то есть любую, не обязательно текстовую) информацию, хотя сам протокол является текстовым. На использовании заголовков базируются и расширения HTTP: разработчик серверного программного обеспечения вправе добавить свои собственные заголовки. При этом сохраняется совместимость с существующими клиентами, которые будут просто игнорировать незнакомые заголовки.
тела сообщения. Тела сообщения может и не быть в запросе в том случае, если стартовая строка и заголовки однозначно идентифицируют запрашиваемый ресурс.
Заголовки от тела отделяются пустой строкой. То есть такой строкой, которая не содержит других символов, кроме возврата каретки и перевода строки, , "\r\n", коды символов – 13 и 10 в десятичной системе. Довольно часто встречаются решения, ограничивающее данное правило только до одного символа – возврата каретки ("\r").
1.1.1.5.1.Структура запроса (Request)
Стартовая строка запроса выглядит следующим образом:
Метод URI HTTP/Версия
Метод – это название запроса, одно слово заглавными буквами. Наибольшее распространение имеют следующие методы:
GET – запросить содержимое указанного ресурса. Клиент может передавать параметры указанному ресурсу, перечисляя их после символа "?". Пример стартовой строки метода GET с передачей параметров на сервер:
GET /some_resource?param1=value¶m2=value2 HTTP/1.1
Метод GET является идемпотентным, то есть многократный запрос GET с одними и теми же параметрами должен приводить к одним и тем же результатам.
HEAD – то же самое, что и GET, но само содержимое ресурса при этом сервером не передается, передаются только заголовки. Метод позволяет узнать, существует ли запрашиваемый ресурс на сервере. Если имеется – не менялось ли его содержимое со времени последнего запроса.
POST – применяется для передачи пользовательских данных (параметров) указанному ресурсу. При этом сами передаваемые параметры включаются в тело запроса. При помощи метода POST можно создать ресурс (например, загрузить файл на сервер). В этом случае сервер выдаст ответ 210 (Created) и в заголовке Location будет указан URI созданного ресурса. Метод POST идемпотентным не является, то есть многократное повторение POST с теми же параметрами может приводить к разным результатам.
PUT – загрузка содержимого запроса на указанный ресурс.
DELETE – удалить указанный ресурс.
URI (Uniform Resource Identifier) – путь к запрашиваемому ресурсу (документ, изображение, файл, службу, ящик электронной почты и т. д.).
Версия – пара разделенной точкой цифр.
1.1.1.5.2.Структура ответа (Response)
Стартовая строка ответа сервера имеет следующий формат:
HTTP/Версия КодСостояния Пояснение
Версия – две цифры, разделенные точкой.
КодСостояния – три цифры, значение которых определяет результат выполнения запроса и дальнейшее поведение клиента. Первая цифра кода состояния определяет его класс, группу, к которой принадлежит данный код состояния. В настоящее время выделяют следующие группы:
1xx – информационное сообщение;
2xx – успешно выполненный сервером запрос;
3xx – перенаправление. Сообщает клиенту, что нужно сделать еще один запрос, как правило, по другому URI. Адрес, по которому клиент должен сделать запрос, как правило, указывается в заголовке Location;
4xx – были допущены ошибки со стороны клиента;
5xx – возникли ошибки на сервере.
При возникновении ошибок, как правило, тело сообщения содержит гипертекстовую информацию, поясняющую возникшую ошибку.
Пояснение – текстовое короткое пояснение к коду ответа. Ни на что не влияет и не является обязательным. Большая часть библиотек работы с HTTP имеет собственные средства определения «пояснения» по полученному коду, в том числе и локализованного пояснения.
Пример HTTPresponse:
HTTP/1.1 200 OK
Date: Wed, 11 Feb 2013 11:20:59 GMT
Server: Apache
X-Powered-By: PHP/5.2.4-2ubuntu5wm1
Last-Modified: Wed, 11 Feb 2013 11:20:59 GMT
Content-Language: ru
Content-Type: text/html; charset=utf-8
Content-Length: 1234
Connection: close
(пустаястрока)
(далее следует запрошенная страница в HTML)
1.1.2.Интернет-приложения
Стоит отметить, что термины интернет-приложения и web-приложения не являются синонимами. Как уже говорилось выше, интернет-приложение не обязано базироваться именно на Web-службе и использовать для межкомпонентного обмена протокол HTTP. Однако, поскольку большую часть интернет-приложений составляют именно такие приложения, разница между терминами практически сходит на нет.
1.1.2.1.Web-приложения
Web-приложение построено, как минимум, по двухуровневой архитектуре (то есть по архитектуре клиент-сервер). При этом в качестве клиентской программы используется web-браузер, а обмен с серверной частью происходит с использованием протоколов HTTP/HTTPS.
Рис. 1.2. Общая схема взаимодействия пользователя с Web-приложением
Как видно из рис. 1.2, web-сервер (блок, реализующий обмен с клиентом по протоколу HTTP) не является единственной составляющей приложения. Он транслирует методы и их параметры в некую среду, которая программным путем формирует HTML-страницу. Такие страницы называются динамическими, потому что их содержание меняется во времени, может зависеть от параметров, от предыдущих шагов клиента в рамках данной сессии. Среда выполнения может быть различной, более подробно вопрос о способах формирования динамических страниц будет рассмотрен ниже.
Основные причины широкого распространения именно web-приложений обусловлены их достоинствами, а именно:
доступностью, пользователю не нужно что-либо ставить на компьютер в качестве клиентского программного обеспечения, достаточно просто набрать нужный адрес в браузере;
отсутствием версионности, если разработчик изменил код приложения, клиентам не нужно сообщать, доступна ли новая версия программы. Следующий после изменения кода запрос даст пользователю уже новое содержание.
1.1.2.2.Web-сервисы
Web-приложение направлено на работу с пользователем и имеет пользовательский интерфейс. В противоположность этому, web-сервис работает либо с другими web-сервисами, либо с web-приложениями. Обмен при этом происходит точно так же, как и в случае с приложениями, то есть по схеме запрос-ответ. В качестве клиента может выступать любая программа, которая правильно сформирует HTTP-запрос и расшифрует полученный HTTP-ответ. Однако для общения стандартной версии HTML может оказаться недостаточно, поэтому используются его расширения: JSON, XML-RPC, SOAP, REST и так далее. Общая схема работы web-сервиса представлена на рис. 1.3.
Рис. 1.3 Общая схема взаимодействия пользователя с web-сервисом
Для описания сервиса существует специальный язык, называемый WSDL (Web Service Definition Language). При помощи WSDL можно запросить у web-сервиса сведения о существующих методах и необходимых параметрах, то есть получить полную описательную информацию о предоставляемом сервисе. Кроме собственно информативной составляющей, WSDL несет и другую нагрузку: на его основе строятся различные средства автоматизированного проектирования web-сервисов – программные средства, позволяющие из WSDL файла создавать скелеты классов и наоборот.
В современном интернете существует множество web-сервисов. В качестве примера можно указать Яндекс.XML. Существует всем известная поисковая система Яндекс. Однако для ее использования не обязательно заходить на http://yandex.ru. Вы можете использовать ее в любом созданном приложении (и не обязательно web-ориентированном). Сервис Яндекс.XML позволяет обратиться с запросом к самой поисковой системе, получить результат выполнения этого запроса в виде XML и использовать полученный результат в своем приложении. Разумеется, при этом существует вопрос лицензионности: придется пройти ряд предписанных Яндексом шагов и обязательно указать в своем приложении ссылку, на основе чего сформирован данный ответ. Но суть остается прежней: предлагается некий сервис, данные из которого могут использоваться по своему усмотрению.
1.1.2.3.Особенности проектирования
Интернет-приложения, как правило, доступны всем участникам сети интернет, даже если целью является разработка простой узкоспециализированной информационной системы. Предположим, разрабатывается информационная система предприятия. Одной из поставленных задач будет задача разделения прав пользователей: кто и что сможет видеть внутри этой системы. Независимо от того, что будет происходить в клиентской части, серверная часть, точка входа в разрабатываемую систему, будет расположена в интернете, соответственно, доступна всей многомиллиардной аудитории. В отличие от классических пользовательских программ большую часть интернет-приложений не нужно устанавливать, никто не спросит разрешения на попытку поработать с системой.
Соответственно, при проектировании интернет-приложений приходится уделять повышенное внимание вопросам безопасности работы. При разработке системы безопасности основным принципом является разумная достаточность предпринимаемых мер. Нет никакого смысла проводить сканирование сетчатки глаза, снимать отпечатки пальцев, делать голосовой анализ, вытаскивать из процессора его серийный номер и из сетевой карты ее mac-адрес – и все это только для того, чтобы отобразить пользователю на экране сегодняшние новости.
Другой не менее важной особенностью является непрогнозируемая нагрузка. Сегодня приложение имеет 10 одновременно работающих клиентов в максимуме, а завтра их станет миллион. Соответственно, при разработке приложения ориентируетесь на 10 клиентов, это расчетная нагрузка. Нет никакого смысла сразу же делать приложение из расчета на миллион, потому что нагрузочная способность – это, в конечном счете, деньги и время, что и будет успешно потрачено, а вот миллион клиентов у приложения может и не появиться в силу целого ряда причин. Однако необходимо предусмотреть возможность масштабирования системы таким образом, чтобы удержать лавинообразно нарастающую нагрузку.
Третья рассматриваемая особенность – это круглосуточная работоспособность приложения. Если мы говорим о локальной сети предприятия, то существует нерабочее время для сотрудников этого предприятия, выходные, праздники. Иными словами, у администраторов всегда есть возможность что-то менять, не нарушая работоспособности системы: переставить программное обеспечение, провести сервисные процедуры с базой данных и даже целиком поменять сервер на более мощный. При должной подготовке даже серьезные изменения в системе не скажутся на пользователях, поскольку к началу следующего рабочего дня их будет ждать полностью способная выполнять свои функции система. Совсем другая картина получается с интернет-приложениями, пользователи которых находятся в разных часовых поясах и имеют полное право затребовать функции разработанного сервиса в любое время любого дня. А между тем задачи администрирования и сервисного обслуживания никуда не исчезли, их по-прежнему необходимо выполнять. И одно из возможных решений – это правильная архитектура разрабатываемого приложения, допускающая временную неработоспособность одной или нескольких компонент без нарушения функционала системы в целом. Это возможно.
1.1.2.4.Особенности пользовательского интерфейса
Пользовательский интерфейс web-приложений тоже имеет свои особенности, обусловленные большой (возможной) аудиторией. Web-приложения должны быть простыми, насколько это вообще возможно, то есть интуитивно понятными для большинства пользователей. Предположим, разрабатывается интерфейс приложения, предназначенного для работы в рамках некоторого предприятия. При этом всегда есть возможность устроить для будущих пользователей системы обучающие курсы, рассказать им, что есть на экране и что разработчики хотели этим сказать. В случае с web-приложением такой возможности не будет. Пользователь либо догадается сам, что разработчики имели в виду, либо просто уйдет.
Поскольку у пользователя есть варианты его поведения внутри созданного web-приложения (варианты пути пользователя), нужно выделять желаемый вариант поведения пользователя: цветом, размером, шрифтом. Если довести ситуацию до шутливого абсурда, то получим «идеальный web-интерфейс» – это белый экран и на нем огромная красная кнопка «Оплатить».
Обычно разработчики приложений придерживаются неких правил хорошего тона. Эти правила не являются уникальными именно для интернета, они обусловлены общечеловеческой этикой. На сайт в первый раз попал человек. Возможно, случайно, возможно, по рекомендации своих знакомых. Ситуация точно такая же по сути, но без привязки к сетям и сайтам: вы устроили грандиозный прием (или небольшую вечеринку) и зашел случайный гость. Как вы себя поведете в таком случае, учитывая, что в госте вы – заинтересованы? Это же ваш посетитель и вам крайне важно, чтобы у него осталось хорошее впечатление, и он пришел сюда еще раз. А лучше бы – еще и друзей с собой привел. Если посмотреть на ведущие web-приложения мира, то все они ведут себя в данной ситуации одинаково. Наверное, так же, как вы бы себя повели в жизненной ситуации с вечеринкой.
Человека нужно встретить. Причем встретить прямо на пороге, чтобы он не смог уйти из-за того, что просто постеснялся войти внутрь. Объяснить ему, что вы ему очень рады, что он не будет здесь лишним. Попросить его чувствовать себя как дома и так далее.
Его нужно познакомить с обстановкой и остальными гостями. Вкратце обрисовать ему, куда он попал, что здесь происходит. То есть, возвращаясь к ситуации с интернетом, коротенько пояснить суть приложения.
Человеку нужно создать благоприятную обстановку – следует сделать так, чтобы в рамках приложения пользователю стало хорошо и он не пожалел, что сюда зашел, почувствовав свою прямую выгоду.
Заинтересовать человека бонусами. Пришедшему пользователю нужно дать понять, что если он приведет сюда друзей, то ему станет еще лучше, выгода будет еще больше.
Другой особенностью является отсутствие стандартов на оформление визуальных элементов интерфейса. Если мы возьмем элемент кнопка, или поле ввода, или меню, или любой другой визуальный элемент, то в рамках операционной системы этот элемент выглядит одинаково и ведет себя одинаково в любой программе. Соответственно, пользователь привыкает к расположению, внешнему виду и поведению визуальных элементов данной операционной системы. Меню в любой программе расположены вверху окна (Windows) или в специальной строке меню (MacOsX). Кнопка всегда имеет цвет, определенный текущей палитрой пользователя. Внешний вид кнопки одинаков в разных программах. И так далее.
Описанное выше не является справедливым для web-приложений в полной мере. Стандартами языка HTML предусмотрены визуальные элементы кнопка, поле ввода и так далее. Однако как в силу сравнительной бедности этих элементов, так и в силу имеющихся развитых программных средств для их модификации каждый разработчик раскрашивает элементы и изменяет их поведение по своему усмотрению.
Можно попытаться сформулировать некоторое правило хорошего тона для разработки интерфейса web-приложения: не стоит чрезмерно модифицировать внешний вид и поведение визуальных элементов по сравнению с наиболее распространенным, имеющимся на уже существующих широко известных сайтах. Есть смысл сначала посмотреть, как та же самая функция реализована наиболее значимыми, распространенными web-приложениями. В противном случае имеется существенный риск дезориентировать пользователя. Если нарисовать круглую кнопку, пользователи могут просто не найти ее на экране, потому что ранее сформировавшаяся привычка заставляет искать глазами кнопку в форме квадрата. Конечно, вышесказанное – это только правило, а вовсе не закон, ведь вполне возможно, что нестандартный интерфейс как раз и является фишкой разрабатываемого сайта.
Приведенный перечень особенностей не является исчерпывающим, но является достаточным для демонстрации специфичности интернет-приложений, их непохожести на задачи классического прикладного программирования.
|
