exam13 6

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

Лазарева Карина

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

В переводе с английского сервис service — это просто услуга, предоставление услуги или обслуживание клиента.

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

сервис, служба и услуга зачастую являются синонимами

2. Веб-сервис

Веб-служба, веб-сервис (англ. web-service) — это сетевая технология, обеспечивающая межпрограммное взаимодействие на основе веб-стандартов.

Веб-стандарты [11] - стандарты являются рекомендациями для разработчиков программного обеспечения и для веб-мастеров. Служат веб-стандарты для того, чтобы, с одной стороны, пользователи ПО без проблем и неудобств могли пользоваться сетью интернет, а с другой стороны, для того, чтобы разработчики программного обеспечения или веб-мастера были уверены в работоспособности своих продуктов [2].

Веб сервис обладает интерфейсом, описанным в WSDL формате. Другие системы, взаимодействуют с веб сервисом через SOAP-сообщения, которые обычно передаются с помощью HTTP с XML сериализацией в связке с другими веб-стандартами. Веб - сервис - идентифицируемая веб – адресом (строка URI) программа. Программный интерфейс, представленный в машинно-обрабатываемом формате WSDL. Другие системы взаимодействуют с этим веб-сервисом путем обмена сообщениями протокола SOAP.

В веб-сервисах всегда есть клиент и сервер. Сервер – это и есть веб-сервис и иногда его называют endpoint (конечная точка, куда доходят SOAP сообщения от клиента). Примером веб-сервиса может стать компания Amazon. Организация имеет сеть онлайн-магазинов и систем доставок. Она предоставляет веб-сервис, который запрашивает цены на продукты, продаваемые онлайн через [3].

РЕЗЮМЕ Cлужба (service): Приложение, которое предоставляет клиентам услуги управления, предоставляя доступ к Веб-службам, определенным в данном документе[4]. Основным компонентом веб-сервисов в интернете являются данные, которые передаются между клиентом и сервером. Веб-сервис – это система, доступная в интернет-пространстве и работающая на основе специальной программы, идентификация которой выполняется с помощью URL-строки. Поиск осуществляется другими ресурсами, основной задачей является взаимодействие программных систем на разных платформах, для чего используются открытые протоколы. К системам веб-сервис относят поисковики, хостинги, электронную почту, облачные хранилища, календари и прочие сервисы. Ключевая особенность системы – отсутствие зависимости от характеристик и состояния какого-либо конкретного компьютера, браузера или провайдера, поэтому доступ к таким сервисам поддерживается в любом государстве. Единственное условие для пользования системой – наличие подключения к интернету.

3. Сервис-ориентированная и микросервисная архитектура

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

• Сервис-ориентированная архитектура (service oriented architecture, SOA) - архитектурный стиль, который поддерживает ориентированность на службы и является парадигмой для бизнеса и ИТ. Данный архитектурный стиль предназначен для разработки систем с точки зрения служб, доступных через интерфейс, и результатов действий этих служб. Служба - логическое представление ряда действий, который имеет определенные результаты, является автономным, может быть составлен из других служб и является "черным ящиком" для потребителей службы. Использование архитектурного стиля SOA может помочь ИС гибко и быстро реагировать на постоянно меняющиеся потребности бизнеса [5].

Пример. Представим классический интернет-магазин. Стандартные модули: UI, бизнес-логика и дата-слой. Возможны способы взаимодействия с сервисом: API REST [12] и веб-интерфейс. При построении монолита все эти вещи будут управляться внутри одного и того же модуля.

• Микросервисная архитектура (Micro Service Architecture, MSA) – принципиальная организация системы на основе микросервисов и их взаимодействия друг с другом и со средой по сети. Микросервисы — это шаблон сервис-ориентированной архитектуры, в котором приложения создаются как совокупность различных наименьших независимых сервисных единиц. Это программный подход, который фокусируется на разложении приложения на однофункциональные модули с четко определенными интерфейсами.

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

Одно из важнейших свойств микросервиса это его независимость от других компонентов приложения. Суть микросервиса по отношению к большому приложению (монолиту) изображена на рис.1.

Рис.1 Микросервисы по отношению к монолиту

Разбиение на независимые компоненты даёт безусловные и неоспоримые преимущества: легкое понимание контекста, гибкость развития, управления и масштабирования. Но что такого плохого в существующих архитектурных решениях, таких как SOA? В отличии от монолитных архитектурных приложений, микросервисы:

1. Улучшает изоляцию сбоя компонентов: большие приложения могут продолжить эффективно работать, даже при неисправности какого-то отдельного модуля.
2. Устраняет приверженность приложения к одному технологическому стеку: если хочешь попробовать новый технологический стек на каком-то сервисе - пожалуйста. Зависимости будут гораздо легче, чем при монолитном, к тому же будет намного проще откатить все вспять. Чем меньше кода в одном приложении, тем легче работать.
3. Упрощает понимание функционального сервиса для новых сотрудников.

Пример. Представим тот же классический интернет-магазин. Здесь отличие от монолита в том, что у каждого модуля (UI, бизнес-логика и дата-слой) есть свой сервис и своя БД. Они слабо связаны и могут взаимодействовать с различными протоколами (например, REST) через свои границы.

[Сравнение архитектур].

РЕЗЮМЕ

Сервис-ориентированная архитектура — это стиль проектирования ПО. Архитектура делится на две части: функциональные аспекты и аспекты качества обслуживания. Миксросервисная архитектура - стиль разработки, который позволяет создавать приложения в виде набора небольших автономных сервисов, разработанных для бизнес-сферы. Микросервисы в значительной степени получили свое название из-за того, что сервисы здесь меньше, чем в монолитной среде. Тем не менее, микро –о бизнес-возможностях, а не о размере.

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

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

4. Поддерживающие протоколы прикладного уровня

Прикладной уровень (APPLICATION). Необходим для взаимодействия между собой сетевых приложений, таких как web, e-mail, skype и тд.

Задачей данного уровня является обеспечение доступа к сетевым службам.

Функции прикладного уровня:

• Решение задач, отправка файлов; управление заданиями и системой;
• Определение пользователей по их логину, e-mail адресу, паролям, электронным подписям;
• Запросы на соединение с иными прикладными процессами;

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

В качестве транспорта для сообщений используется протокол HTTP. Описание веб-сервисов и их API могут быть найдены средствами UDDI. Концептуальная схема технологии приведена на рис.2, а связь между протоколами — на рис.3.

Рис.2 Концепция веб-сервиса

• SOAP (Simple Object Access Protocol) — протокол обмена сообщениями между потребителем и поставщиком веб-сервиса;
• WSDL (Web Services Description Language) — язык описания внешних интерфейсов веб-службы;
• UDDI (Universal Discovery, Description and Integration) — универсальный интерфейс распознавания, описания и интеграции, используемый для формирования каталога веб-сервисов и доступа к нему.

Рис.3 Связь между протоколами

Все спецификации, используемые в технологии, основаны на XML и, соответственно, наследуют его преимущества (структурированность, гибкость и т.д.) и недостатки (громоздкость, медлительность) [7].

Взаимодействие между SOAP, WSDL и UDDI: [8]

Приложение играет роль веб сервисов, которые нужны клиенту для доступа к другому приложению или бизнес логике, расположенной где-то в сети. Клиент делает запрос в UDDI реестр для нахождения сервиса по имени, категории, идентификатору или какой-то другой спецификации. Как только сервис найден, клиент получает информацию о местонахождении WSDL документа из UDDI реестра. WSDL документ содержит информацию о том, как обратиться к веб сервису, и формат запросов в XML схему. Клиент создает SOAP сообщение в соответствии с XML схемой, взятой из WSDL, и посылает запрос хосту (где находится веб сервис).

HTTP (HyperText Transfer Protocol) - протокол уровня приложения, используемый в основном в World Wide Web. HTTP использует клиент-серверную модель, где браузер является клиентом и общается с веб-сервером, который хостит веб-сайт.

SOAP - протокол обмена структурированными сообщениями в распределенной вычислительной среде. Также предоставляет стандарт структуры упаковки данных для транспортировки XML документов с помощью различных интернет-технологий, как: SMTP, HTTP, FTP.

• Так как SOAP обладает стандартным механизмом транспортировки, различные клиенты и серверы могут взаимодействовать, например, с EJB через .NET клиент и наоборот.

WSDL (Web Service Description Language) - XML технология, которая описывает интерфейс веб сервиса в стандартизированном виде. WSDL указывает стандарт, как веб сервис должен представлять входные и выходные параметры при вызове извне, как должна выглядеть структура функции, природа вызова и как осуществлять связывание протокола сервера.

• WSDL позволяет различным клиентам автоматически распознавать, как взаимодействовать с веб сервисом

UDDI (Universal Description, Discovery, and Integration) - предоставляет всемирный реестр веб сервисов для рекламы, поиска и хранения. *UDDI предоставляет структуру для представления деловых отношений, веб сервисов, технических метаданных и точек доступа к веб сервисам.

REST (REpresentational State Transfer) - это стиль архитектуры программного обеспечения для распределенных систем, использующий веб протоколы и веб технологии. REST архитектура включает в себя клиентское и серверное взаимодействие, построенное вокруг передачи ресурсов.

• Самая большая реализация REST - World Wide Web, которая, как правило, используется для построения веб-служб.
• Системы, которые построены согласно REST принципам, называются RESTful.
• REST может быть использован для сбора данных вебсайта через XML файлы веб страницы.
• Пользователи могут обращаться к веб страницам через URL сайта, взаимодействовать с XML файлами через браузер и использовать данные как угодно.

Лирическое отступление: прикладные протоколы в стеке TCP/IP

В модели TCP/IP прикладной уровень это единственный уровень, который находится выше транспортного. А в модели взаимодействия открытых систем (OSI) есть еще 2 уровня: уровень представления и сеансовый. Протоколы прикладного уровня TCP/IP определяют форматы и управляют данными, необходимыми для многих распространённых функций обмена данными через Интернет. Наиболее известные протоколы прикладного уровня на рис.4-5.

Рис.4 Протоколы стека TCP/IP

Почему существуют два транспортных протокола TCP и UDP, а не один из них? Дело в том, что они предоставляют разные услуги прикладным процессам. [9].

Рис.5 Протоколы стека TCP/IP прикладного уровня

Самый верхний уровень в иерархии протоколов Интернет занимают следующие протоколы прикладного уровня [10]:

• DNS - распределенная система доменных имен, которая по запросу, содержащему доменное имя хоста сообщает IP адрес;
• DHCP - протокол динамического конфигурирования узлов;
• HTTP - протокол передачи гипертекста в Интернет;
• HTTPS - расширение протокола HTTP, поддерживающее шифрование;
• FTP - протокол, предназначенный для передачи файлов в компьютерных сетях;
• Telnet - сетевой протокол для реализации текстового интерфейса по сети;
• SSH - протокол прикладного уровня, позволяющий производить удаленное управление операционной системой и передачу файлов. В отличие от Telnet шифрует весь трафик;
• POP3 – протокол почтового клиента, который используется почтовым клиентом для получения сообщений электронной почты с сервера;
• IMAP - протокол доступа к электронной почте в Интернет;
• SMTP – протокол, который используется для отправки почты от пользователей к серверам и между серверами для дальнейшей пересылки к получателю;
• LDAP - протокол для доступа к службе каталогов X.500, является широко используемым стандартом доступа к службам каталогов;
• XMPP - основанный на XML расширяемый протокол для мгновенного обмена сообщениями в почти реальном времени;
• SNMP - базовый протокол управления сети Internet.

[Более подробно некоторые из этих протоколов].

РЕЗЮМЕ

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

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

ИСПОЛЬЗУЕМЫЕ ИСТОЧНИКИ

1. Служба Windows
2. Веб-стандарты
3. Пример веб-сервиса Amazon
4. ГОСТ Р ИСО/МЭК 17963-2016 Спецификация веб-служб для управления (WS-management)
5. ГОСТ Р ИСО/МЭК 18384-1-2017 Информационные технологии (ИТ). Эталонная архитектура для сервис-ориентированной архитектуры (SOA RA)
6. Монолитная vs Микросервисная архитектура
7. Веб-сервисы как средство интеграции приложений в WWW
8. Веб-сервисы
9. Протоколы прикладного уровня
10. Протоколы Интернет прикладного уровня
11. Обзор стандартов W3C по обеспечению доступности веб-контента
12. Что такое REST API?