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

Содержание:

ВВЕДЕНИЕ

Стремительное развитие Интернета вещей привело к появлению множества прикладных протоколов, необходимых для его реализации. Вопросами стандартизации и практического внедрения этих протоколов занимаются международные организации (ITU-T , IEEE , ETSI, OASIS ), неправительственные ассоциации (oneM2M), альянсы производителей и операторов (IERC, ISO/IEC), партнерские проекты (IoT-A). Несмотря на большое число заинтересованных сторон или, наоборот, благодаря этому, предпринимаемые усилия в основном носят локальный, разобщенный характер и направлены на решение достаточно узких задач. Касательно участия российских компаний в этом процессе необходимо отметить, что такая доля мала и не позволяет сделать выводы о ее существенности [5, с. 12].

Стоит упомянуть о существовании Российской ассоциации Интернета вещей, которая относится к кластеру информационных технологий фонда "Сколково", официально участвует в работе международных организаций по стандартизации Интернета вещей (ITU-T) и представляет наши интересы среди мирового экспертного сообщества, поскольку внедрение Интернета вещей на отечественном рынке является очевидной задачей для ведущих телекоммуникационных компаний [7, с. 8].

Анализ существующих публикаций показал, что данной тематике в русскоязычном сегменте посвящено не так много литературы, а находящиеся в открытом доступе источники не раскрывают в полной мере интересующий нас вопрос использования прикладных протоколов Интернета вещей [9, с. 11]. В большинстве случаев внимание уделяется таким технологиям, как ZigBee, Bluetooth Low Energy, NFC, RFID и др. В то же время в зарубежных источниках данный вопрос поднимается все чаще, однако информация также достаточно разобщена и носит ознакомительный характер. Таким образом, очевидна необходимость в обобщении имеющихся материалов и их систематизации [4, с. 19].

Актуальность данной темы обусловлена многообразием существующих протоколов, стандартов Интернета вещей [9, с. 10] и отсутствием устоявшейся терминологии, описывающей концепцию в целом [1, с. 25].

Цель работы – изучить понятие прикладных протоколов и серверы приложений.

Задачи:

– Рассмотреть что такое прикладные протоколы;

– Исследовать что такое серверы приложений.

Методы исследования в работе – сравнительно-аналитические.

Объект работы – прикладные протоколы и серверы приложений.

Предмет – информационные системы и технологии.

Методы исследования в работе – сравнительно-аналитические.

При написании работы была использована литература, написанная: Алиевым В.С. в 2017г., Балдиным К.В. в 2018, Барским А.Б. в 2018, Вдовенко Л.А. в 2016, Вдовиным В.М. в 2017, Вендровым А.М. в 2017, Горелик О.М. в 2016, Есауловой С.П. в 2018, Ивасенко А.Г. в 2015 и 2017.

Также использовались учебники по информационным технологиям, написанные группами авторов в 2015, 2016, 2017 годах.

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

Структурно работа состоит из введения, двух глав и списка литературы.

1. Прикладные протоколы

1.1. Определение и суть прикладных протоколов

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

Протоколы приложений управляют различными процессами, такими как процесс загрузки веб-страницы или отправки электронной почты. Протокол приложения указывает, как выполняются эти процессы [5, с. 63].

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

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

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

Интерфейс определяет совокупный сервис, предоставляемый данным уровнем выше лежащему уровню.

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

Правила взаимодействия двух машин могут быть описаны в виде набора процедур для каждого из уровней. Такие формализованные правила, определяющие последовательность и формат сообщений, которыми обмениваются сетевые компоненты, лежащие на одном уровне, но в разных узлах, называются протоколами [2, с. 124].

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

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

Программные средства, реализующие некоторый протокол, также называют протоколом. При этом соотношение между протоколом - формально определенной процедурой взаимодействия, и протоколом - средством, реализующим эту процедуру, аналогично соотношению между алгоритмом решения некоторой задачи и программой, решающей эту задачу. Понятно, что один и тот же алгоритм может быть запрограммирован с разной степенью эффективности. Точно также и протокол может иметь несколько программных реализаций, например, протокол IPX, реализованный компанией Microsoft для Windows NT в виде программного продукта NWLink, имеет характеристики, отличающиеся от реализации этого же протокола компанией Novell. Именно поэтому, при сравнении протоколов следует учитывать не только логику их работы, но и качество программных решений. Более того, на эффективность взаимодействия устройств в сети влияет качество всей совокупности протоколов, составляющих стек, то есть, насколько рационально распределены функции между протоколами разных уровней и насколько хорошо определены интерфейсы между ними [11, с. 88].

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

При организации взаимодействия могут быть использованы два основных типа протоколов. В протоколах с установлением соединения (connection-oriented network service, CONS) перед обменом данными отправитель и получатель должны сначала установить логическое соединение, то есть договориться о параметрах процедуры обмена, которые будут действовать только в рамках данного соединения. После завершения диалога они должны разорвать это соединение. Когда устанавливается новое соединение, переговорная процедура выполняется заново. Телефон - это пример взаимодействия, основанного на установлении соединения [2, с. 76].

Вторая группа протоколов - протоколы без предварительного установления соединения (connectionless network service, CLNS). Такие протоколы называются также дейтаграммными протоколами. Отправитель просто передает сообщение, когда оно готово. Опускание письма в почтовый ящик - это пример связи без установления соединения [4, с. 120].

Расслоение.

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

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

Прикладной уровень - это уровень в семислойной модели взаимодействия открытых систем (OSI) и в наборе протоколов TCP / IP. Он состоит из протоколов, которые ориентированы на межпроцессное взаимодействие по IP-сети и обеспечивают надежный интерфейс связи и услуги конечного пользователя.

Прикладной уровень является седьмым уровнем модели OSI и единственным, который напрямую взаимодействует с конечным пользователем.

Прикладной уровень предоставляет множество услуг, в том числе:

Простой протокол пересылки почты

Передача файла

веб-серфинг

Веб-чат

Почтовые клиенты

Сетевой обмен данными

Виртуальные терминалы

Различные операции с файлами и данными

Прикладной уровень обеспечивает полный доступ конечного пользователя к множеству общих сетевых сервисов для эффективного потока данных модели OSI. Этот уровень имеет много обязанностей, включая обработку ошибок и восстановление, передачу данных по сети и полный сетевой поток. Он также используется для разработки сетевых приложений [1, с. 89].

На прикладном уровне используется более 15 протоколов, включая протокол передачи файлов, Telnet, простой протокол передачи файлов и простой протокол управления сетью [5, с. 54].

Его основным сетевым устройством или компонентом является шлюз.

Сети строят свои различные протоколы связи друг на друге. Хотя IP позволяет компьютеру обмениваться данными по сети, он пропускает различные функции, которые добавляет TCP. Сам TCP является сетевым протоколом, который использует IP под ним. Прикладное программное обеспечение, которое создает исходные данные, также важно при определении используемого протокола: целевое приложение должно понимать данные, передаваемые ему, и для этого необходим четко определенный протокол связи. Хотя разные классы приложений определяют свой собственный протокол (например, электронную почту, которая по-разному передает данные, скажем, HTTP), каждый из них основан на протоколах более низкого уровня, таких как TCP и IP. Эти "более высокий уровень” [9, с. 37]. На рисунке 1. показано соотношение между различными протоколами.

Рисунок 1. Соотношение между различными протоколам

SMTP, протокол, используемый для отправки электронной почты, является рабочим протоколом, основанным на TCP / IP. Однако SMTP может отправлять только текстовые сообщения. Растущая потребность отправлять больше, чем текст, привела к появлению Mime [5, с. 39].

1.2. Виды прикладных протоколов

Некоторые распространенные протоколы приложений:

1)HTTP (протокол передачи гипертекста) используется для передачи веб-страниц. Возможно, вы заметили, что каждая строка в адресной строке вашего браузера начинается с http: // www . Он сообщает приложению, в данном случае браузеру, какой протокол использовать при связи с приложением на удаленном компьютере [1, с. 131].

Ключевой концепцией HTTP является универсальный локатор ресурсов (URL).

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].

Что же такое этот «бин» (bean — боб) и почему, стремительно выскочив как джин из бутылки в компьютерный мир, он уже завоевал такую популярность. Если перевести определение Sun как можно ближе к оригиналу - то «это модель для создания и развертывания серверных компонентов многократного использования, написанных на языке Java.» Продолжим вместе с Sun расплетать косу этого определения, - «компоненты - это заранее разработанные куски программного кода, которые могут быть установлены в работающие прикладные системы» [10, с. 96]. Если классы Java образуют компонентную модель для проектирования приложений в технологии Java, то Java Beans логически развивает эту модель на следующем уровне интеграции создания автоматизированных систем и абстрагирования от процесса программирования - стадии внедрения. По сути, это переход от разработки приложения под заказ из готовых программных компонентов к сборке из готовых EJB действующих компонентов. Если раньше дома складывали из кирпичей, то теперь - из комнат-секций. Слово Enterprise в названии Enterprise Java Beans означает новую ступень технических задач, стоящих перед программными приложениями. Такие задачи привычны для приложений уровня Предприятия: поддержка распределенности, службы именования, транзакций, безопасности, уведомлений-сообщений, долговременного хранения, и т.д. Неудивительно, что этот список напоминает список Служб технологии CORBA [2, с. 100].

С точки зрения разработки, EJB представляют собой Java-классы специального типа вместе с описателем-паспортом бина и параметрами среды функционирования, которые бин умеет обрабатывать. Описатель бина (Deployment Descriptor) в свою очередь представляет собой XML-файл, в котором содержатся правила, связанные с управлением бином, например, права доступа пользователей к бину. Несколько бинов могут объединяться, образуя приложения, Java-апплеты и новые бины [4, с. 86].Это видно на рисунке 5.

Рисунок 5. Контейнер Enterprise Java Beans

По технологии EJB бобы-бины размещаются в стручке - контейнере (рис. 4) На контейнер возложены обязанности по защите бинов и поддержке их взаимоотношений с внешним миром: регистрация-прописка объектов, обеспечение для них внешних интерфейсов, создание и разрушение реализаций этих объектов, охрана безопасности, управление их состояниями и координация транзакций. В технологии не определено, как конкретно должен быть реализован контейнер. Это могут быть как многопоточные процессы на отдельном сервере, в которых выполняются бины, так и законченные программные приложения, которые можно переносить, или распределять между серверами и/или процессами. Клиентские бины обрабатываются внутри виртуальных контейнеров, таких как Web-страницы, формы, составные документы, и т.д. [1, с. 130].

В технологии определены два основных типа бинов. Session Beans - сеансы клиент-серверного взаимодействия отрабатывают действия клиента, например, запись в базу данных, выполнение вычислений, и т.д. Это окна клиента в мир программных приложений [10, с. 119].

Клиентские приложения общаются с бинами через контейнер, который открывает наружу оба интерфейса бина: Home и Remote. С помощью первого открывается сеанс или находится нужный бин, а с помощью второго - осуществляется отработка действий клиента в Session или транзакционная механика обработки Entity [10, с. 160].

2.3. Серверы приложений: плюсы и минусы

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

Самое важное решение - иметь облачную или собственную серверную инфраструктуру. Хотя это может звучать как черно-белое выделение, есть много вещей, которые следует учитывать. Первый фактор - это то, насколько важно время безотказной работы для вашего бизнеса [10, с. 73].Облачные решения, как правило, стоят дороже, чем собственные, но преимущества использования облака могут значительно перевесить затраты для некоторых предприятий. Например, онлайн-бизнес, который зависит от веб-транзакций, будет считать время безотказной работы чрезвычайно важным фактором; следовательно, они, вероятно, будут готовы платить больше за облачное решение, которое может гарантировать определенный уровень безотказной работы. Другие предприятия, не зависящие от времени безотказной работы, могут больше подходить для внутренней организации [14, с. 127].

Вот некоторые плюсы и минусы облачных и внутренних серверов.

Внутренний сервер плюсы:

Нет необходимости в оборудовании или капитальных затратах. Хорошо подходит для небольших компаний, которые могут слишком быстро перерасти хранилище [1, с. 267].

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

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

Резервное копирование данных в облаке может производиться с интервалом 15 минут, что сводит к минимуму потери данных в чрезвычайных ситуациях. Небольшое время восстановления набора данных улучшено [10, с. 191].

Минусы:

Затраты на восстановление данных могут перевесить преимущества для компаний, которые не так зависят от времени безотказной работы и мгновенного восстановления [1, с. 260].

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

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

Полное восстановление данных может оказаться очень трудоемким и эффективным для систем.

Модель гибридного сервера также обеспечивает компаниям большую безопасность данных. Например, с помощью гибридной модели SysGen клиенты могут создавать резервные копии своих данных на локальном сервере, а также в облачном решении. Партнер SysGen по решениям для резервного копирования Datto представляет решения нового поколения для резервного копирования, аварийного восстановления и обеспечения непрерывности бизнеса [4, с. 120].

На рисунке 6 приведен пример гибридной модели SysGen.

Рисунок 6. Пример гибридной модели SysGen

У клиента есть локальный сервер с локальным хранилищем резервных копий. Сотрудники получают доступ к своим рабочим столам, приложениям, файлам, принтерам и электронной почте из офиса, используя локальную сеть [10, с. 91].В то же время данные резервируются для избыточности в облачное решение, а электронная почта полностью размещается в облаке с помощью Hosted Microsoft Exchange [1, с. 360].Облачная конфигурация также предоставляет сотрудникам в любом месте доступ к своим рабочим столам, приложениям, файлам, принтерам и электронной почте [13, с. 136].

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

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

3. Реализация проблем прикладных протоколов и серверов приложений на практике

3.1. Анализ ситуации на сегодняшний день

В современном интернет пространстве могут возникнуть проблемы на прикладном уровне, но большинство проблем, с которыми сталкиваются люди, возникают на других уровнях. Однако некоторые проблемы на прикладном уровне или на других уровнях (в зависимости от того, как на них посмотреть) включают такие элементы, как следующие:

–Программные ошибки, такие как приложение, которое вылетает при слишком быстрой отправке данных. Когда происходят подобные вещи, все, что вы можете сделать, это диагностировать проблему, связаться с производителем программного обеспечения, уменьшить возникновение проблем, изменив другие элементы конфигурации, или перейти на эквивалентное приложение, если оно доступно [8, с. 64].

–Неверные настройки, такие как имена хостов или адреса, которые могли измениться и не были задокументированы. Узнайте, какими должны быть правильные настройки, даже если это означает двойную проверку конфигурации клиента и сервера [7, с. 160].

–Службы связаны с неверным портом, например с запущенными службами протокола удаленного рабочего стола (RDP) или службами HTTP на нестандартных портах. Например, вы можете получить доступ к удаленному хосту, но если вы попытаетесь подключиться не к тому порту, вы не сможете подключиться [12, с. 100].

–Нередко на серверах внутреннего использования установлено несколько веб-сайтов, на которых разрешено запускать только один из них через стандартный порт HTTP, равный 80. Кроме того, некоторые ИТ-администраторы предпочитают запускать службу RDP на нестандартном порту, чтобы неавторизованные пользователи не пытались подключиться к службе RDP.

–Используемые клиентские или серверные компоненты не соответствуют опубликованным стандартам протокола. Иногда пользовательский написанный код не соблюдает опубликованные протоколы и может привести к длительным упражнениям по устранению неполадок. В одном случае проблема была выявлена ​​только путем чтения опубликованных стандартов и захвата сетевого трафика с помощью инструмента захвата сети Wireshark [10, с. 101].

3.2. Прогнозы и перспективы развития

Обслуживание старых монолитных приложений становится все более дорогим и сложным. При таком сценарии необходимо перейти к современной архитектуре на основе микросервисов, которая решит многие из вышеупомянутых проблем [4, с. 121].Некоторые из ключевых преимуществ перехода на архитектуру на основе микросервисов включают в себя:

Лучшая изоляция неисправностей; если один микросервис выходит из строя, остальные продолжат работать

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

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

Легко масштабируемые отдельные компоненты.

Упрощенный процесс DevOps благодаря использованию контейнерных технологий, таких как Dockers, Kubernetes, Istio и т. д. [15, с. 260].

Архитектура на основе микросервисов может привести к:

–Более быстрому времени выхода на рынок;

–Снижению стоимости инфраструктуры;

–Более быстрому внедрению или улучшению бизнес-функций.

Чтобы узнать больше о микросервисах, ознакомимся с методом IBM Cloud Garage.

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

Отойдите от большой единой структуры команды к более децентрализованной структуре небольших групп [11, с. 146].

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

Представьте культуру DevOps, которая способствует более тесному сотрудничеству между разработчиками, операциями и всеми остальными, кто вовлечен в поставку программного обеспечения [15, с. 294].

Эталонное монолитное приложение представляет собой простое приложение для магазина. Как и многие другие, созданные впервые дни движения Web 2.0, пользователи напрямую взаимодействуют с интерфейсом на основе браузера и управляют своей корзиной для отправки заказов. Как показано ниже, это приложение построено с использованием традиционной модели 3-уровневой архитектуры, состоящей из HTTP-сервера, сервера приложений и вспомогательной базы данных [1, с. 331].

В приложении для покупок есть товары, сгруппированные по разным категориям; пользователь может осуществлять поиск по веб-сайту, добавлять товары в корзину, а затем отправлять заказ. Приложение использует две базы данных для хранения данных приложения - данные инвентаризации продукта и данные заказа клиента. Вы можете найти более подробную информацию об архитектуре и компонентах приложения в ibm-cloud-Architecture / refarch-jee-customerorder на GitHub.

Чтобы модернизировать существующее приложение Websphere в архитектуру на основе микросервисов, нам необходимо проанализировать приложение и оценить, можно ли модернизировать приложение и оправданы ли усилия. Иногда проще и дешевле воссоздать приложение с нуля. Однако в большинстве случаев, учитывая природу приложений JavaEE, гораздо проще преобразовать его в архитектуру на основе микросервисов, чем начинать заново [2, с. 160].

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

1.Микросервисы должны быть достаточно маленькими, чтобы ими могла владеть гибкая команда разработчиков (так называемое «правило 2 пиццерий»).

2.Каждый микросервис должен отвечать за свои данные. Оценивая приложение, оцените также базу данных, чтобы проверить зависимость данных между модулями.

3.Микросервисы должны быть без гражданства. Приложение без состояния обрабатывает каждый запрос с информацией, содержащейся только в нем.

4.Микросервисы должны быть предназначены только для одной цели, но делать это правильно.

Лучшее понимание приложения, как с точки зрения функциональности, так и с технической точки зрения позволяет нам лучше реорганизовать приложение в микросервисы с минимальными изменениями кода, сохраняя при этом функциональность приложения. В зависимости от характера приложения мы можем применить любой из стандартных шаблонов, таких как Backend for Frontend (BFF), Service Pattern, Adapter Pattern и т. д. [7, с. 80].

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

В то время как одностраничное приложение хорошо работает с одноканальным пользовательским интерфейсом, этот шаблон обеспечивает плохие результаты для пользователей по различным каналам, иногда перегружая браузер, управляя взаимодействием со многими асинхронными сервисами поддержки на основе REST [10, с. 167].

Был разработан паттерн Backend for Frontend (BFF), в котором бэкэнд-агрегаторная служба уменьшает общее количество вызовов из браузера и, в свою очередь, обрабатывает большую часть обмена данными между внешними сервисами поддержки, наконец, возвращая более легко управляемый одиночный запрос в браузер. Шаблон позволяет внешним командам разрабатывать и развертывать собственную службу агрегатора бэкэнда (BFF) для обработки всего количества вызовов внешних служб, необходимых для их конкретного взаимодействия с пользователем - часто созданного для определенного браузера, мобильной платформы или устройства IoT. Одна и та же команда создает как пользовательский интерфейс, так и BFF, часто на одном языке, что приводит как к повышению общей производительности приложений, так и к их доставке. При создании приложения на основе микросервисов наши клиенты придерживаются стандартного подхода:

Современные многоканальные интерфейсы должны быть реализованы в виде одностраничных приложений (SPA) с HTML / CSS / JavaScript [7, с. 148].

Эти пользовательские интерфейсы загружаются со статического веб-сервера (либо реализованного с использованием NGINX, либо просто с помощью простого веб-сервера Node.js.) [11, с. 160].

Затем JavaScript в клиенте может выполнять вызовы REST в набор BFF (или напрямую в Business Microservices) для заполнения данных в компонентах SPA (например, заполнение содержимого для пунктов меню GUI или раскрывающихся меню или других элементов GUI). [10, с. 160].

Микросервисы не генерируют элементы GUI в HTML - это полностью делается с помощью JavaScript и статического HTML / CSS. Вместо этого Microservices возвращают бизнес-ориентированные данные JSON только в ответ на запросы REST [7, с. 120].

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

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

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

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

ЗАКЛЮЧЕНИЕ

Исследовав цели и задачи, поставленные в начале работы, было выяснено, что Стандарт STEP разделен на множество прикладных протоколов, принадлежащих к семейству стандартов ISO 10303. Каждый протокол определяет стандарт обмена данными для определенного семейства продуктов на определенной стадии его жизненного цикла. Наиболее популярными прикладными протоколами для САПР являются AP-203, также известный как ISO 10303-203, и AP-214, также известный как ISO 10303-214. Протокол применения STEP-NC имеет номер ISO 10303-238 или AP-238. Другие прикладные протоколы определяют стандарты обмена данными для специализированных продуктов, таких как корабли (AP-216) и печатные платы (AP-210), и для различных этапов жизненного цикла продукта, таких как планирование процесса (AP-240) и контроль координатной измерительной машины (AP-219)

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

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

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

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

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

Сервер приложений - это виртуальная машина Java ™ (JVM), на которой выполняются пользовательские приложения. Сервер приложений взаимодействует с веб-сервером для возврата динамического настраиваемого ответа на запрос клиента. Запрос клиента может состоять из сервлетов, файлов JavaServer Pages (JSP), корпоративных компонентов и их вспомогательных классов.

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1.Алиев В.С. Практикум по бизнес-планированию с использованием программы Project Expert / В.С. Алиев. - М.: Инфра-М, Форум, 2017. - 593 c.

2. Балдин К. В. Информационные системы в экономике / К.В. Балдин. - М.: ИНФРА-М, 2018. - 224 c.

3. Барский А. Б. Логические нейронные сети / А.Б. Барский. - М.: Интернет-университет информационных технологий, Бином. Лаборатория знаний, 2018. - 352 c.

4. Вдовенко Л. А. Информационная система предприятия: Уч. пос./Л.А.Вдовенко-2-е изд., пераб. и доп.-М.:Вузовский уч. / Л.А. Вдовенко. - Москва: Машиностроение, 2016. - 143 c.

5. Вдовин В. М. Информационные технологии в налогообложении. Практикум / В.М. Вдовин, Л.Е. Суркова. - М.: Дашков и Ко, 2017. - 248 c.

6. Вендров А. М. Практикум по проектированию программного обеспечения экономических информационных систем / А.М. Вендров. - М.: Финансы и статистика, 2017. - 192 c.

7. Горелик О. М. Финансовый анализ с использованием ЭВМ / О.М. Горелик, О.А. Филиппова. - М.: КноРус, 2016. - 270 c.

8. Есаулова С.П. Информационные технологии в туристической индустрии / С.П. Есаулова. - М.: Дашков и К°, 2018. - 120 c.

9. Ивасенко А. Г. Информационные технологии в экономике и управлении. Учебное пособие / А.Г. Ивасенко, А.Ю. Гридасов, В.А. Павленко. - М.: КноРус, 2015. - 154 c.

10. Ивасенко А.Г. Информационные технологии в экономике и управлении. Учебное пособие / А.Г. Ивасенко. - М.: КноРус, 2017. - 354 c.

11. Информационные системы в экономике. Практикум. - М.: КноРус, 2017. - 254 c.

12. Информационные технологии в маркетинге. Учебник и практикум. - Москва: Мир, 2016. - 368 c.

13. Информационные технологии в менеджменте. Учебное пособие / В.И. Карпузова и др. - М.: Вузовский учебник, Инфра-М, 2017. - 304 c.

14. Информационные технологии в управлении персоналом. Учебник и практикум / Ю.Д. Романова и др. - М.: Юрайт, 2015. - 291 c.

15. Информационные технологии. Учебник. В 2 томах. Том 1-2 (комплект из 2 книг) / В.В. Трофимов и др. - М.: Юрайт, 2016. - 632 c.