Файл: Понятие прикладных протоколов и серверы приложений.pdf

URL определяется как компактное представление местоположения и метода доступа к ресурсу, доступному через Интернет - (RFC1738, 1808) [2, с. 171].

Ресурс может быть файлом любого типа или, как правило, документом HTML. URL - это просто имя и адрес этого ресурса. Кроме того, URL также показывает протокол, используемый для доступа к ресурсу.

URL имеет следующий формат:

протокол: адрес

На этом уровне существует много разных протоколов: FTP, TELNET и HTTP являются хорошо известными примерами. Схема URL-адреса HTTP имеет следующий формат:

http: // хост: порт / путь / файл

Порт HTTP по умолчанию - 80, но отличается для других протоколов. Значения по умолчанию почти всегда опускаются в URL.

HTTP является основным протоколом всемирной паутины. HTTP - это протокол клиент-сервер, способный передавать различные типы данных: графику, аудио и видео. Это также облегчает возможность получения одной веб-страницы из нескольких мест. HTTP использует TCP, но каждая страница передается независимо: новое TCP-соединение устанавливается для каждого запроса, который клиент отправляет на сервер [2, с. 88].

Вот два термина, связанные с HTTP, с которыми нужно ознакомиться:

Прокси : Прокси - это промежуточная система между клиентом и сервером: он действует как сервер для клиента и как клиент для сервера. Прокси-сервер часто используется при настройке брандмауэра: он действует как сервер, пропуская только достоверную информацию. Из-за множества доступных версий HTTP, между клиентом и сервером может быть установлен прокси, и каждая отдельная версия протокола направляется на соответствующий сервер [4, с. 62].

Шлюз: действует от имени сервера и может использоваться для обеспечения безопасности. Шлюз действует как промежуточное устройство, которое может преобразовывать не HTTP-протоколы. Например, запрос сделан на FTP-сайт. Шлюз выступает в качестве промежуточной системы и выполняет запрос от имени клиента на соответствующий сервер. Затем шлюз преобразует FTP в формат HTTP, который отправляется клиенту [5, с. 235].

И шлюзы, и прокси полезны при защите сетей и создании брандмауэров.

2)FTP (File Transfer Protocol) используется, когда два компьютера передают файлы между собой. Ваш браузер поддерживает этот протокол, как и все FTP-клиенты.

3)SMTP (Simple Mail Transfer Protocol) используется для отправки электронной почты и передачи почтовых сообщений между почтовыми серверами.SMTP-сообщения в наборе символов ASCII (набор ISO 646). Это означает, что в письме можно использовать только 255 различных символов. SMTP также регистрирует маршрут, пройденный любым конкретным почтовым сообщением. Необходимо рассмотреть три основных области: отправитель, протокол и получатель [14, с. 88].

Отправитель.

Если сообщение отправляется нескольким пользователям на одном хосте, то на хост нужно отправить только одну копию этого сообщения.

Он отправляет сообщение повторно, если оно изначально было неудачным при отправке. Повторная постановка в очередь не должна быть неопределенным процессом и должна прекратиться после истечения срока действия электронной почты [5, с. 74].

Информирует пользователя, если он предоставил неверный адрес.

Протокол.

Протокол используется для передачи сообщения от отправителя к получателю по TCP-соединению. Он не предоставляет уведомления о доставке, хотя SMTP в целом надежен.

Получатель.

Получатель принимает входящую почту и распределяет ее по нужным почтовым ящикам [13, с. 53].

Каждое сообщение имеет заголовок, определенный в RFC 822, и обычно соответствует следующему формату:

Дата: понедельник, 14 марта 2005 г. 09:26:34 (GMT + 2)

От: «Администратор сети CS» <admin@cs.uct.ac.za>

Тема: Использование компьютерных лабораторий

To: jsmith@cs.uct.ac.za

CC: tadams@cs.uct.ac.za

POP3 (Post Office Protocol 3) позволяет почтовым клиентам читать почту с почтовых серверов [14, с. 12].

DNS (служба доменных имен) позволяет сетевым компьютерам находить друг друга [7, с. 94].

DHCP (протокол динамической конфигурации хоста) используется для автоматического назначения IP-адресов сетевым компьютерам. Каждому сетевому компьютеру необходим уникальный IP-адрес [6, с. 78].

TCP / IP (Протокол управления передачей / Интернет-протокол) иногда называют «Интернет-протоколом» по той простой причине, что он является наиболее широко используемым протоколом при подключении к Интернету.

Выводы по главе.

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

Протоколы существуют для нескольких различных приложений. Примеры включают в себя проводные сети (например, Ethernet), беспроводные сети (например, 802.11ac) и связь через Интернет (например, IP). Набор протоколов Интернет, который используется для передачи данных через Интернет, содержит десятки протоколов. Эти протоколы могут быть разбиты на четыре категории:

Канальный уровень - PPP , DSL , Wi-Fi и т. Д.

Интернет-уровень - IPv4 , IPv6 и т. Д.

Транспортный уровень - TCP , UDP и т. Д.

Прикладной уровень - HTTP , IMAP , FTP и т. Д.

2. Серверы приложений

2.1. Понятие серверов приложений

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

Сервер приложений обычно используется для сложных приложений на основе транзакций. Для поддержки высокопроизводительных потребностей сервер приложений должен иметь встроенную избыточность, мониторинг высокодоступных, высокопроизводительных распределенных сервисов приложений и поддержку сложного доступа к базе данных [9, с. 127].

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

Первый эшелон, передний конец, веб - браузер на основе графического интерфейса пользователя, как правило, на персональном компьютере или рабочей станции [15, с. 312].

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

Третий эшелон, фоновый , базы данных и сервер транзакций, иногда на ЭВМ или большом сервере [5, с. 59].

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

Во многих случаях сервер приложений объединяется или работает с веб-сервером (протокол передачи гипертекста) и называется сервером веб-приложений [4, с. 115]. Веб-браузер поддерживает простой в создании пользовательский интерфейс на основе HTML. Веб-сервер предоставляет несколько различных способов пересылки запроса на сервер приложений и пересылки измененной или новой веб-страницы пользователю [2, с. 71]. Эти подходы включают Common Gateway Interface (CGI), FastCGI , от Microsoft Active Server Page , и страницу сервера Java . В некоторых случаях серверы веб-приложений также поддерживают посреднические интерфейсы запросов, такие как CORBA Internet Inter-ORB Protocol (IIOP) [13, с. 120].

2.2. Реализации серверов приложений

Основные этапы развития прикладной архитектуры компьютерных систем можно увидеть на рисунке 2.

Рисунок 2. Развитие прикладной архитектуры компьютерных систем

Первая эра - эра эксклюзивного «монолита», когда компьютерные программы, или потом, пакеты программ, выполнялись на одном компьютере. Особого выбора у потенциальных потребителей программных продуктов тогда не было - или сам разрабатывай, или заказывай у опытных людей. Тогдашние операционные системы не баловали богатством возможностей - работает приложение на компьютере - и хорошо. Оно могло работать годами, выполняя раз навсегда закрепленные функции, и все были довольны. Это время часто называют и «эрой мэйнфреймов», хотя именно мэйнфреймы подошли вплотную к «тихой революции». От них появилась возможность приставить к одному серверу несколько «глаз» - терминалов, которые позволили плавно перейти в «клиент-серверную эру». Вот тут то и появляется служака «сервер» [3, с. 138].Сервер работает, служит, выполняя задания его величества клиента. Клиент от простенького «застенчивого» терминала вырастает до важного и значительного повелителя. Нынешний революционный момент характеризуется тем, что серверы не могут, а клиенты не хотят существовать по-старому. Первые не могут справиться с обилием поставленных перед ними требований, а вторые недовольны качеством обслуживания их запросов. Выход - в дальнейшей специализации. То, что пыхтя и отдуваясь, выполняет несчастный сервер, теперь будет распределено на множество серверков - компонентов, каждый из которых успешно выполняет свою функцию. В такой компании клиенты превращаются в равноправные компоненты, чья задача - представительство функциональных сотоварищей (других компонентов) для пользователя, сидящего перед дисплеем [10, с. 98].

Раз уж ввели строительный термин - монолит, то приведем строительно-архитектурную параллель. Первая - монолитная эра, эра дольменов и кромлехов, отдельных решений, автоматизирующих конкретные производственные задачи заказчика. Опыта еще мало - каждое сооружение в некотором смысле произведение искусства. Вторая эра - однотипные поселения, каждое их которых характеризуется замком (сервером) и постройками попроще вокруг (клиентами) [15, с. 212].И если простые постройки не представляют большой архитектурной ценности, то замки - решения штучные и дорогостоящие. А переходим мы в эру массовой застройки, когда «строительство» программных приложений поставлено на поток. И сколько бы мы ни ругали такую застройку, именно этот способ позволяет обеспечить жильем - программными приложениями, всех желающих за разумную цену и в реальные сроки [4, с. 118].

Типовые современные дома обычно строятся из блоков или панелей. Так и современные программные приложения строятся или, скорее, будут строиться из компонентов. (Компонент - самостоятельный программный продукт, поддерживающий объектную парадигму, реализующий отдельную область бизнес-логики и умеющий взаимодействовать с другими компонентами с помощью открытых интерфейсов.) Такая технология позволит ответить на самые острые проблемы компьютерного мира - сокращение времени разработки программного приложения, облегчение процесса внедрения и поддержка гибкости внедренного решения [5, с. 125]. На рис. 3 изображены этапы жизненного цикла программного приложения.

Рисунок 3. Жизненный цикл информационных систем

Внешние интерфейсы компонентов должны быть описаны в едином стиле - на одном и том же языке. Поэтому два известных на сегодняшний день стандарта, CORBA и COM+ создали свои варианты IDL — Языка Описания Интерфейсов. CORBA, COM+ и технология Java, которая, естественно, использует для описания интерфейсов язык Java, предлагают близкие подходы к методу взаимодействия компонентов. На основе описания внешних интерфейсов создаются прокси (заместители) для клиента и сервера, которые позволяют им связываться друг с другом в реальном времени. Прокси для клиента принято называть стабом, а прокси для сервера – скелетоном [10, с. 160].

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

Рисунок 4. Стандарты в программных приложениях

В технологии CORBA это:

ССМ (CORBA Component Model)- компонентная объектная модель, компонентное развитие модели бизнеса ВОМ - Business Object Model;

BOCA (Business Object Component Architecture) - принципы архитектуры компонентных систем, развитие OMA (Object Management Architecture) на вышележащий уровень стандартизации; [10, с. 121].

CDL (Component Definition Language)- язык определения компонентов, развитие IDL [1, с. 167].

Разработка этих стандартов продвигается, правда, не так быстро, как хотелось бы всем заинтересованным сторонам. Но признанным героем на поле стандартизации компонентов стала технология компании Sun - Enterprise Java Beans (EJB). Возможно причина ее успеха в том, что в «семейном кругу» одного языка программирования намного проще решить вопросы взаимодействия [14, с. 120]. Тем более языка молодого и резвого, который многие проблемы, такие как вызов удаленных методов (RMI - Remote Method Invocation), умеет решать сам. Не исключено, что универсальные цели консорциума OMG, развивающего технологию CORBA, - объединить компоненты, написанные на разных языках программирования, функционирующие на разных системах и разных компьютерах в разных точках земного шара, являются в данном случае некоторым тормозом. В дальнейшем мы увидим как две технологии, сомкнувшись, отбросив амбиции, дают замечательный результат на радость всем заинтересованным сторонам [11, с. 150].