СЕРВИС-

ОРИЕНТИРОВАННАЯ
АРХИТЕКТУРА (SOA)
От знакомства до применения в качестве компонентов
корпоративных систем
Введение в SOA
Каким образом связаны информационные системы внутри предприятия?
Обычный путь для российской компании средних размеров — начинать
внедрение информационных технологий с автоматизации работы бухгалтерии,
отдела кадров и документооборота.
Другие системы также обмениваются данными. И здесь возникает один из
самых трудных вопросов для руководителя — поиск оптимальной степени
интеграции. Большой соблазн иметь абсолютно интегрированную систему, но
такая интеграция чрезвычайно трудоемка, стоит немалых денег. И лучше даже
не говорить, во что обходится сопровождение такой системы. Поэтому нужно
взвесить потребности в интегрированных системах, поставив их на чашу весов
против трудностей и дороговизны крупномасштабной ИС. Не существует
стандартного уровня интеграции или централизации — каждый руководитель
должен самостоятельно решать эту непростую проблему.
 Традиционная интеграция
• CSV
• JSON
Бухгалтерия Склад Кадровый учет
• XML
• Web-service JSON
• Web-service WSDL
• COM/DCOM/ActiveX
• CORBA IDL
• WebSockets

Логистика Торговля Отчетность • Sockets

• DBLink
Сервис-ориентированная
архитектура
Интеграция разнородных и распределенных данных не в состоянии разрешить все вопросы
управления предприятием. В соответствии с процессным подходом наибольшую ценность
представляют не сами по себе данные, а использование информации в тех или иных бизнес-
процессах компании. В самых современных ИС принято рассматривать за "атомарную" единицу
не данные в "чистом" виде, а некоторый сервис, соответствующий какому-то элементарному
бизнес-процессу. В частности, такой сервис может просто выдавать какие-то данные, являясь
аналогом "атомарной" единицы классических ИС.
В настоящее время при формировании информационной инфраструктуры предприятия, при
проектировании и реализации КИС всё чаще применяется сервис-ориентированная архитектура
(Service-Oriented Architecture — SOA). Это такая архитектура ИС, в которой система строится из
набора гетерогенных слабосвязанных компонентов (сервисов). SOA понимается как парадигма
организации и использования распределенного множества функций, которые могут
контролироваться различными владельцами. Базовыми понятиями в такой архитектуре
являются "информационная услуга" и "композитное приложение".
Информационная услуга (сервис) — это атомарная прикладная функция автоматизированной
системы, пригодная для использования при разработке приложений, реализующих прикладную
логику автоматизируемых процессов как в самой системе, так и для использования в
приложениях других автоматизированных систем.
Сервис-ориентированная
архитектура
Сервис обычно характеризуется следующими свойствами:
• возможность многократного применения;
• услуга может быть определена одним или несколькими технологически независимыми интерфейсами;
• выделенные услуги слабо связаны между собой и каждая из них может быть вызвана посредством
коммуникационных протоколов, обеспечивающих возможность взаимодействия услуг между собой.
Композитное (составное) приложение — программное решение для конкретной прикладной проблемы,
связывающее прикладную логику процесса с источниками данных и информационных услуг, хранящихся
на гетерогенном множестве базовых информационных систем. Обычно композитные приложения
ассоциированы с процессами деятельности и могут объединять различные этапы процессов,
представляя их пользователю через единый интерфейс.
Использование такого подхода при построении архитектуры сложных интегрированных
информационных систем позволяет:
• создать систему корпоративных композитных приложений, основанных на системе корпоративных
Web-сервисов;
• организовать интеграцию приложений на базе автоматизации бизнес-процессов;
• использовать различные транспортные протоколы и стандарты форматирования сообщений, средства
обеспечения безопасности, надежной и своевременной доставки сообщений;
• существенно повысить скорость разработки прикладных приложений и снизить затраты на эти цели.
Сервис-ориентированная
архитектура
Сервис-ориентированная архитектура (service-oriented
architecture, SOA) придумана в конце 1980-х. Она берёт своё
начало в идеях, изложенных в CORBA, DCOM и других
спецификациях. О SOA написано много, есть несколько её
реализаций. Но, по сути, SOA можно свести к нескольким идеям,
причём архитектура не диктует способы их реализации:
• Сочетаемость приложений, ориентированных на пользователей.
• Многократное использование бизнес-сервисов.
• Независимость от набора технологий.
• Автономность (независимые эволюция, масштабируемость и
развёртываемость)
Сервис-ориентированная
архитектура
Возникла потребность в стандартном способе взаимодействия приложений, которые
созданы с использованием разных технологий, исполняются на разных компьютерах и
под разными ОС. Для этого была разработана CORBA. Это один из стандартов
распределённых вычислений, зародившийся в 1980-х и расцветший к 1991 году.
Стандарт CORBA был реализован несколькими вендорами. Он обеспечивает:
• Не зависящие от платформы вызовы удалённых процедур (Remote Procedure Call).
• Транзакции (в том числе удалённые!).
• Безопасность.
• События.
• Независимость от выбора языка программирования.
• Независимость от выбора ОС.
• Независимость от выбора оборудования.
• Независимость от особенностей передачи данных/связи.
• Набор данных через язык описания интерфейсов (Interface Definition Language, IDL).
Сервис-ориентированная
архитектура
SOA также может рассматриваться как стиль архитектуры информационных
систем, который позволяет создавать приложения, построенные путём
комбинации слабосвязанных и взаимодействующих сервисов. Эти сервисы
взаимодействуют на основе какого-либо строго определённого платформенно-
независимого и языково-независимого интерфейса (например, WSDL).
Определение интерфейса скрывает языково-зависимую реализацию сервиса.
Таким образом, системы, основанные на SOA, могут быть независимы от
технологий разработки и платформ (таких как Java, .NET и т. д.). К примеру,
сервисы, написанные на C#, работающие на платформах .Net и сервисы на Java,
работающие на платформах Java EE, могут быть с одинаковым успехом вызваны
общим составным приложением. Приложения, работающие на одних платформах,
могут вызывать сервисы, работающие на других платформах, что облегчает
повторное использование компонентов.
 Принцип работы CORBA
Сначала нам нужно получить брокер объектных запросов (Object Request
Broker, ORB), который соответствует спецификации CORBA. Он
предоставляется вендором и использует языковые преобразователи
(language mappers) для генерирования «заглушек» (stub) и «скелетов»
(skeleton) на языках клиентского кода. С помощью этого ORB и
определений интерфейсов, использующих IDL (аналог WSDL), можно на
основе реальных классов генерировать в клиенте удалённо вызываемые
классы-заглушки (stub classes). А на сервере можно генерировать классы-
скелеты (skeleton classes), обрабатывающие входящие запросы и
вызывающие реальные целевые объекты.
Принцип работы CORBA
Вызывающая программа (caller) вызывает локальную
процедуру, реализованную заглушкой.
1. Заглушка проверяет вызов, создаёт сообщение-запрос
и передаёт его в ORB.
2. Клиентский ORB шлёт сообщение по сети на сервер и
блокирует текущий поток выполнения.
3. Серверный ORB получает сообщение-запрос и создаёт
экземпляр скелета.
4. Скелет исполняет процедуру в вызываемом объекте.
5. Вызываемый объект проводит вычисления и
возвращает результат.
6. Скелет пакует выходные аргументы в сообщение-ответ
и передаёт его в ORB.
7. ORB шлёт сообщение по сети клиенту.
8. Клиентский ORB получает сообщение, распаковывает и
передаёт информацию заглушке.
9. Заглушка передаёт выходные аргументы
вызывающему методу, разблокирует поток
выполнения, и вызывающая программа продолжает
свою работу.
Принцип работы CORBA
Возникла потребность в стандартном способе взаимодействия приложений, которые
созданы с использованием разных технологий, исполняются на разных компьютерах и
под разными ОС. Для этого была разработана CORBA. Это один из стандартов
распределённых вычислений, зародившийся в 1980-х и расцветший к 1991 году.
Стандарт CORBA был реализован несколькими вендорами. Он обеспечивает:
• Не зависящие от платформы вызовы удалённых процедур (Remote Procedure Call).
• Транзакции (в том числе удалённые!).
• Безопасность.
• События.
• Независимость от выбора языка программирования.
• Независимость от выбора ОС.
• Независимость от выбора оборудования.
• Независимость от особенностей передачи данных/связи.
• Набор данных через язык описания интерфейсов (Interface Definition Language, IDL).
Достоинства и недостатки CORBA
Достоинства
• Производительность выше чем у Web-сервисов
• Независимость от выбранных технологий (не считая реализации ORB).
• Независимость от особенностей передачи данных/связи
Недостатки
• Независимость от местоположения: клиентский код не имеет понятия, является ли
вызов локальным или удалённым. Звучит неплохо, но длительность задержки и виды
сбоев могут сильно варьироваться. Если мы не знаем, какой у нас вызов, то
приложение не может выбрать подходящую стратегию обработки вызовов методов, а
значит, и генерировать удалённые вызовы внутри цикла. В результате вся система
работает медленнее
• Заблокированные каналы связи (communication pipes): используются специфические
протоколы поверх TCP/IP, а также специфические порты (или даже случайные порты).
Но правила корпоративной безопасности и файрволы зачастую допускают HTTP-
соединения только через 80-й порт, блокируя обмены данными CORBA
Веб-сервисы
Благодаря сервисам мы перешли в парадигме SOA от
удалённого вызова методов объекта (CORBA) к передаче
сообщений между сервисами.

Но нужно понимать, что в рамках SOA веб-сервисы — не

просто API общего назначения, всего лишь
предоставляющие CRUD-доступ к базе данных через
HTTP. В каких-то случаях эта реализация может быть
полезной, но ради целостности ваших данных
необходимо, чтобы пользователи понимали лежащую в
основе реализации модель и соблюдали бизнес-правила.
SOA подразумевает, что веб-сервисы отделяют
реализацию от решаемых этими сервисами задач.
Достоинства и недостатки Web-
сервисов
Достоинства
• Независимость набора технологий, развёртывания и масштабируемости
сервисов.
• Стандартный, простой и надёжный канал связи (передача текста по HTTP
через порт 80).
• Оптимизированный обмен сообщениями.
• Стабильная спецификация обмена сообщениями.
Недостатки
• Разные веб-сервисы тяжело интегрировать из-за различий в языках
передачи сообщений. Например, два веб-сервиса, использующих разные
JSON-представления одной и той же концепции.
• Синхронный обмен сообщениями может сильно увеличить нагрузку на
системы.
Сервис-ориентированная
архитектура
Становление и развитие SOA происходило на базе практических требований бизнеса, заключавшимхся, прежде
всего, в разумной экономии программных и технологических средств и затрат на реализацию и сопровождение
информационной инфраструктуры:
• обеспечивать преемственность инвестиций в IT, сохранение существующих информационных систем и их
совместное эффективное использование для повышения ROI от IT-вложений;
• обеспечивать реализацию различных типов интеграции:
• пользовательская интеграция (User Integration) — обеспечение взаимодействия информационной системы с
конкретным персонифицированным пользователем;
• интеграция приложений (Application Connectivity) — обеспечение взаимодействия приложений;
• интеграция процессов (Process Integration) — интеграция процессов в соответствии с бизнес-логикой
деятельности предприятия;
• информационная интеграция (Information Integration) — интеграция с целью обеспечения доступности
информации и данных;
• интеграция новых приложений (Build to Integrate) — интеграция новых приложений и сервисов в
существующие информационные системы.
• обеспечивать поэтапность внедрения вновь созданных и миграции существующих информационных систем;
• иметь стандартизованную технологическую обеспеченность реализации и инструментарий разработки,
совокупно предоставляющие наилучшие возможности повторного использования приложений, внедрения
новых и миграции существующих информационных систем;
• позволять реализацию различных моделей построения информационных систем, в особенности таких как
портальные решения, grid-системы и on-demand-системы.
Варианты интеграционных решений
Интеграция — это не просто
механическое объединение
модулей информационной системы.
При разработке плана интеграции
исходят прежде всего из
стратегических целей развития
предприятия, возможного
изменения бизнес-логики, в
соответствии с которой
выстраиваются бизнес-процессы и
осуществляется их
информационное сопровождение.
Интеграция может производиться
на уровне форматов и баз данных,
программно-аппаратных и сетевых
устройств, пользовательских
интерфейсов, форм и шаблонов
документооборота, программных
приложений и т.д. Выгоды от такой
интеграции очевидны.
Обзор терминологии SOA
• ESB (Enterprise Service Bus) — промышленная сервисная шина — программное обеспечение
промежуточного уровня (Middleware), основанное на стандартах, которые предоставляют
базовые сервисы для сложных архитектур, основанных на посылке сообщений через шину.
• Middleware (здесь) — промежуточное (связующее, межплатформенное) программное
обеспечение, состоящее из агентов, являющихся посредниками между различными
компонентами распределенного приложения.
• Web Service — веб-сервис, веб-служба — программная система, идентифицируемая строкой URI,
внешние интерфейсы которой описаны при помощи языка WSDL. Другие программные системы
могут взаимодействовать с веб-службой, благодаря описанию WSDL посредством обмена
сообщений на базе SOAP.
• XML (eXtensible Markup Language) — расширяемый язык разметки. Предназначен для
представления структурированных данных для хранения и обмена информацией между
приложениями (в частности, веб-сервисами).
• SOAP (Simple Object Access Protocol) — простой протокол доступа к объектам. Основан на XML.
Используется для обмена сообщениями и удаленного вызова процедур (Remote Procedure Call,
RPC).
Обзор терминологии SOA
• Сервис-ориентированная архитекту́ра (SOA, англ. service-oriented architecture) — модульный
подход к разработке программного обеспечения, основанный на использовании
распределённых, слабо связанных (англ. loose coupling) заменяемых компонентов, оснащённых
стандартизированными интерфейсами для взаимодействия по стандартизированным
протоколам.
• Удалённый вызов процедур, реже Вызов удалённых процедур (от англ. Remote Procedure Call,
RPC) — класс технологий, позволяющих компьютерным программам вызывать функции или
процедуры в другом адресном пространстве (как правило, на удалённых компьютерах). Обычно
реализация RPC-технологии включает в себя два компонента: сетевой протокол для обмена в
режиме клиент-сервер и язык сериализации объектов (или структур, для необъектных RPC).
• XML-RPC (сокр. от англ. Extensible Markup Language Remote Procedure Call — XML-вызов
удалённых процедур) — стандарт/протокол вызова удалённых процедур, использующий XML
для кодирования своих сообщений и HTTP в качестве транспортного механизма[1]. Является
прародителем SOAP, отличается исключительной простотой в применении. XML-RPC, как и
любой другой интерфейс Remote Procedure Call (RPC), определяет набор стандартных типов
данных и команд, которые программист может использовать для доступа к функциональности
другой программы, находящейся на другом компьютере в сети.
Обзор терминологии SOA
SOAP (от англ. Simple Object Access Protocol —
простой протокол доступа к объектам) —
протокол обмена структурированными
сообщениями в распределённой вычислительной
среде. Первоначально SOAP предназначался в
основном для реализации удалённого вызова
процедур (RPC). Сейчас протокол используется для
обмена произвольными сообщениями в формате
XML, а не только для вызова процедур.
Официальная спецификация последней версии 1.2
протокола никак не расшифровывает название
SOAP. SOAP является расширением протокола
XML-RPC.
Пример SOAP-запроса
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetails xmlns="http://warehouse.example.com/ws">
<productID>12345</productID>
</getProductDetails>
</soap:Body>
</soap:Envelope>
Пример ответа
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetailsResponse xmlns="http://warehouse.example.com/ws">
<getProductDetailsResult>
<productID>12345</productID>
<productName>Стакан граненый</productName>
<description>Стакан граненый. 250 мл.</description>
<price>9.95</price>
<currency>
<code>840</code>
<alpha3>USD</alpha3>
<sign>$</sign>
<name>US dollar</name>
<accuracy>2</accuracy>
</currency>
<inStock>true</inStock>
</getProductDetailsResult>
</getProductDetailsResponse>
</soap:Body>
</soap:Envelope>
Обзор терминологии SOA
WSDL (англ. Web Services Description Language) — язык описания веб-сервисов и доступа к ним,
основанный на языке XML.
Пример WSDL
Обзор терминологии SOA
REST (сокращение от англ. Representational State Transfer — «передача состояния представления»)
— архитектурный стиль взаимодействия компонентов распределённого приложения в сети. REST
представляет собой согласованный набор ограничений, учитываемых при проектировании
распределённой гипермедиа-системы. В определённых случаях (интернет-магазины, поисковые
системы, прочие системы, основанные на данных) это приводит к повышению производительности
и упрощению архитектуры. В широком смысле[уточнить] компоненты в REST взаимодействуют
наподобие взаимодействия клиентов и серверов во Всемирной паутине. REST является
альтернативой RPC[1].
В сети Интернет вызов удалённой процедуры может представлять собой обычный HTTP-запрос
(обычно «GET» или «POST»; такой запрос называют «REST-запрос»), а необходимые данные
передаются в качестве параметров запроса.
Для веб-служб, построенных с учётом REST (то есть не нарушающих накладываемых им
ограничений), применяют термин «RESTful».
В отличие от веб-сервисов (веб-служб) на основе SOAP, не существует «официального» стандарта
для RESTful веб-API. Дело в том, что REST является архитектурным стилем, в то время как SOAP
является протоколом. Несмотря на то, что REST не является стандартом сам по себе, большинство
RESTful-реализаций используют стандарты, такие как HTTP, URL, JSON и XML.
SOA архитектурные особенности
Ряд архитектурных особенностей SOA позволяет уменьшить степень связанности различных
элементов системы. Для взаимодействия компонентов используется сравнительно
небольшой набор простых интерфейсов, которые обладают только самой общей семантикой
и доступны всем провайдерам и потребителям. Через эти интерфейсы передаются
сообщения, ограниченные некоторым словарем. А поскольку даны только общая структура
корпоративной системы и словарь, то вся семантика и бизнес-логика, специфичная для
приложений, описывается непосредственно в этих сообщениях.
Корпоративная информационная система, построенная на основе SOA, состоит из набора
сущностей, доступных через прикладные программные интерфейсы. Встроенный механизм
поиска и обнаружения сервисов в общем реестре позволяет потребителю выйти на
оператора, предлагающего искомую функцию.
Архитектура веб-сервисов также является сервисно-ориентированной. Более того, веб-
сервисы — это суть SOA c двумя дополнительными ограничениями: интерфейсы базируются
на интернет-протоколах (HTTP, FTP, SMTP Simple Mail Transfer Protocol - Простой протокол
передачи почты, TCP), а все сообщения описываются в формате XML.
SOA практические аспекты
Практические аспекты сервисно-ориентированной технологии позволяют решить проблемы
масштабируемости, интегрировать сети передачи данных и голоса, упростить процедуры
проектирования и управления сетями, а также создать другие распределенные приложения,
прозрачно взаимодействующие с ресурсами систем при помощи прикладных программных
интерфейсов и открытых стандартов.
Грамотное и полноценное управление невозможно без целостного понимания тех
компонентов, или столпов, которые поддерживают зрелый SOA-проект. Конечно, SOA-проект
можно строить только на основных механизмах (механизме) поддержки, однако зрелый
проект подразумевает больший уровень поддержки с ростом уровня ответственности,
которая ложится на SOA-проект. Каждая предметная область требует разного подхода к
управлению SOA, что, соответственно, разным образом отражается на «политике».
Следует также отметить, что политика имеет решающее значение для управления SOA,
поскольку оно будет определять SOA-политику предприятия, а также то, кто создает
политики SOA, где эти политики хранятся, как SOA-политика будет обновляться или
изменяться, где ее можно проследить, какие системы/инструменты используются для
осуществления SOA-политики, и какие отделы осуществляют ее вручную.
SOA практические аспекты
Очередь сообщений
У нас есть несколько приложений, которые асинхронно общаются друг с другом с помощью
платформо-независимых сообщений. Очередь сообщений улучшает масштабируемость и
усиливает изолированность приложений. Им не нужно знать, где находятся другие
приложения, сколько их и даже что они собой представляют. Однако все эти приложения
должны использовать один язык обмена сообщениями, т. е. заранее определённый
текстовый формат представления данных.
Очередь сообщений использует в качестве компонента инфраструктуры программный
брокер сообщений (RabbitMQ, Beanstalkd, Kafka и т. д.). Для реализации связи между
приложениями можно по-разному настроить очередь:
Запрос/Ответ
• Клиент шлёт в очередь сообщение, включая ссылку на «разговор» («conversation»
reference). Сообщение приходит на специальный узел, который отвечает отправителю
другим сообщением, где содержится ссылка на тот же разговор, так что получатель знает,
на какой разговор ссылается сообщение, и может продолжать действовать. Это очень
полезно для бизнес-процессов средней и большой продолжительности (цепочек событий,
sagas).
SOA практические аспекты
Очередь сообщений
У нас есть несколько приложений, которые асинхронно общаются друг с другом с помощью
платформо-независимых сообщений. Очередь сообщений улучшает масштабируемость и
усиливает изолированность приложений. Им не нужно знать, где находятся другие приложения,
сколько их и даже что они собой представляют. Однако все эти приложения должны использовать
один язык обмена сообщениями, т. е. заранее определённый текстовый формат представления
данных.
Очередь сообщений использует в качестве компонента инфраструктуры программный брокер
сообщений (RabbitMQ, Beanstalkd, Kafka и т. д.). Для реализации связи между приложениями
можно по-разному настроить очередь:
Публикация/Подписка
• По спискам
 Очередь поддерживает списки опубликованных тем подписок (topics) и их подписчиков. Когда очередь
получает сообщение для какой-то темы, то помещает его в соответствующий список. Сообщение
сопоставляется с темой по типу сообщения или по заранее определённому набору критериев, включая и
содержимое сообщения.
• На основе вещания
 Когда очередь получает сообщение, она транслирует его всем узлам, прослушивающим очередь. Узлы
должны сами фильтровать данные и обрабатывать только интересующие сообщения.
SOA практические аспекты
Все эти паттерны можно отнести к либо к pull-
(polling), либо к push-подходу:
• В pull-сценарии клиент опрашивает очередь с
определённой частотой. Клиент управляет своей
нагрузкой, но при этом может возникнуть
задержка: сообщение уже лежит в очереди, а
клиент его ещё не обрабатывает, потому что не
пришло время следующего опроса очереди.
• В push-сценарии очередь сразу же отдаёт
клиентам сообщения по мере поступления.
Задержки нет, но клиенты не управляют своей
нагрузкой.
Очереди сообщений
Достоинства
• Независимость набора технологий, развёртывания и масштабируемости сервисов
• Стандартный, простой и надёжный канал связи (передача текста по HTTP через порт
80)
• Оптимизированный обмен сообщениями
• Стабильная спецификация обмена сообщениями
• Изолированность контекстов домена (Domain contexts)
• Простота подключения и отключения сервисов
• Асинхронность обмена сообщениями помогает управлять нагрузкой на систему

Недостатки
• Разные веб-сервисы тяжело интегрировать из-за различий в языках передачи
сообщений. Например, два веб-сервиса, использующих разные JSON-представления
одной и той же концепции.
Интеграция сервисов
Сервис-ориентированная
архитектура
Обязательным условием построения и внедрения архитектуры системы на основе SOA является
использование единой инфраструктуры описания сервисов (репозитория сервисов), разрешенных
протоколов доступа и обмена сообщениями, форматов сообщений.
Упомянутая инфраструктура образует так называемую интеграционную шину (Enterprise Service
Bus — ESB), являющуюся одним из центральных компонентов системы. Она устанавливает единые
правила публикации сервисов, управления и информационного взаимодействия между
приложениями различных систем, входящих в состав интегрированной системы. Это упрощает
управление приложениями и их поддержку, а также снижает риск фрагментации приложений и
процессов.
Сервис-ориентированная
архитектура
Каждая из служб взаимодействует не с остальными службами напрямую, а только с шиной. ИШ
образует однородную среду информационного взаимодействия и является фундаментом для
интеграции информационных систем, функционирующих в различных учреждениях и ведомствах. ИШ
определяет кем, где, каким образом и в каком порядке должны обрабатываться запросы.
Если сервис (информационный ресурс) не поддерживает эти правила, необходимо создавать
промежуточный модуль-адаптер, который предоставляет системе необходимый интерфейс и
обеспечивает взаимодействие с ресурсом.
Изменение и совершенствование бизнес-процессов в компаниях занимает годы. По усредненным
данным Gartner Group: 80 % ИТ-бюджета — это расходы на сопровождение систем, из них 35 % —
затраты на интеграцию приложений, 60 % стоимости внедрения корпоративной ИС составляют
расходы на интеграцию, 50 % ИТ-бюджета потрачено на обеспечение интерфейсов систем.
Использование SOA архитектуры позволяет эффективно организовать оперативную адаптацию ИТ-
систем под требования бизнеса, что дает стратегическое преимущество компании, заключающееся в:
• повышение скорости адаптации бизнеса к быстроменяющимся требованиям рынка (Agility);
• расширении взаимодействия гетерогенных корпоративных информационных систем при
сохранение сделанных в них инвестиций;
• сокращение расходов на ИТ-системы на основе повторного использования их функциональных
компонентов;
• повышение производительности труда клиентов, партнеров и сотрудников (на основе архитектуры
Web 2.0).
Сервисная шина предприятия (ESB)
ESB возникла во времена, когда в компаниях были отдельные
приложения. Например, одно для работы с финансами, другое
для учёта персонала, третье для управления складом, и т. д., и их
нужно было как-то связывать друг с другом, как-то
интегрировать. Но все эти приложения создавались без учёта
интеграции, не было стандартного языка для взаимодействия
приложений (как и сегодня). Поэтому разработчики приложений
предусматривали конечные точки для отправки и приёма данных
в определённом формате. Компании-клиенты потом
интегрировали приложения, налаживая между ними каналы
связи и преобразуя сообщения с одного языка приложения в
другой.
Очередь сообщений может упростить взаимодействие
приложений, но она не способна решить проблему разных
форматов языков. Впрочем, была сделана попытка превратить
очередь сообщений из простого канала связи в посредника,
доставляющего сообщения и преобразующего их в нужные
форматы/языки. ESB стал следующей ступенью в естественной
эволюции простой очереди сообщений.
Сервисная шина предприятия (ESB)
В этой архитектуре используется модульное приложение (composite application), обычно
ориентированное на пользователей, которое общается с веб-сервисами для выполнения каких-то
операций. В свою очередь, эти веб-сервисы тоже могут общаться с другими веб-сервисами,
впоследствии возвращая приложению какие-то данные. Но ни приложение, ни бэкенд-сервисы
ничего друг о друге не знают, включая расположение и протоколы связи. Они знают лишь, с каким
сервисом хотят связаться и где находится сервисная шина.
Клиент (сервис или модульное приложение) отправляет запрос на сервисную шину, которая
преобразует сообщение в формат, поддерживаемый в точке назначения, и перенаправляет туда
запрос. Всё взаимодействие идёт через сервисную шину, так что если она падает, то с ней падают и
все остальные системы. То есть ESB — ключевой посредник, очень сложный компонент системы.
Это очень упрощённое описание архитектуры ESB. Более того, хотя ESB является главным
компонентом архитектуры, в системе могут использоваться и другие компоненты вроде доменных
брокеров (Domain Broker), сервисов данных (Data Service), сервисов процессной оркестровки (Process
Orchestration Service) и обработчиков правил (Rules Engine). Тот же паттерн может использовать
интегрированная архитектура (federated design): система разделена на бизнес-домены со своими
ESB, и все ESB соединены друг с другом. У такой схемы выше производительность и нет единой точки
отказа: если какая-то ESB упадёт, то пострадает лишь её бизнес-домен.
Сервисная шина предприятия (ESB)
Главные обязанности ESB:
• Отслеживать и маршрутизировать обмен сообщениями между
сервисами
• Преобразовывать сообщения между общающимися сервисными
компонентами
• Управлять развёртыванием и версионированием сервисов
• Управлять использованием избыточных сервисов
• Предоставлять стандартные сервисы обработки событий,
преобразования и сопоставления данных, сервисы очередей
сообщений и событий, сервисы обеспечения безопасности или
обработки исключений, сервисы преобразования протоколов и
обеспечения необходимого качества связи
Сервисная шина предприятия (ESB)
Сервисная шина предприятия (ESB)
Достоинства
• Независимость набора технологий, развёртывания и масштабируемости сервисов
• Стандартный, простой и надёжный канал связи (передача текста по HTTP через порт 80)
• Оптимизированный обмен сообщениями
• Стабильная спецификация обмена сообщениями
• Изолированность контекстов домена (Domain contexts)
• Простота подключения и отключения сервисов
• Асинхронность обмена сообщениями помогает управлять нагрузкой на систему
• Единая точка для управления версионированием и преобразованием

Недостатки
• Ниже скорость связи, особенно между уже совместимыми сервисами
• Централизованная логика:
 Единая точка отказа, способная обрушить системы связи всей компании
 Большая сложность конфигурирования и поддержки
 Со временем можно прийти к хранению в ESB бизнес-правил
 Шина так сложна, что для её управления вам потребуется целая команда
 Высокая зависимость сервисов от ESB
Микросервисы
Главное различие микросервисов и шины в том, что ESB была создана в контексте
интеграции отдельных приложений, чтобы получилось единое корпоративное
распределённое приложение. А микросервисная архитектура создавалась в
контексте быстро и постоянно меняющихся бизнесов, которые (в основном) с нуля
создают собственные облачные приложения.
То есть в случае с ESB у нас уже были приложения, которые нам не «принадлежат»,
и поэтому мы не могли их изменить. А в случае с микросервисами мы полностью
контролируем приложения (при этом в системе могут использоваться и сторонние
веб-сервисы).
Характер построения/проектирования микросервисов не требует глубокой
интеграции. Микросервисы должны соответствовать бизнес-концепции,
ограниченному контексту. Они должны сохранять своё состояние, быть
независимыми от других микросервисов, и потому они меньше нуждаются в
интеграции. То есть низкая взаимозависимость и высокая связность привели к
замечательному побочному эффекту — уменьшению потребности в интеграции.
Микросервисы
[Микросервисы — это] маленькие автономные сервисы, работающие вместе и
спроектированные вокруг бизнес-домена. — Sam Newman 2015, Principles Of
Microservices
Главным недостатком архитектуры ESB было очень сложное
централизованное приложение, от которого зависели все остальные
приложения. А в микросервисной архитектуре это приложение почти целиком
убрано.
Ещё остались элементы, пронизывающие всю экосистему микросервисов. Но у
них гораздо меньше задач по сравнению с ESB. К примеру, для асинхронной
связи между микросервисами до сих пор применяется очередь сообщений, но
это лишь канал для передачи сообщений, не более того. Или можно вспомнить
шлюз экосистемы микросервисов, через который проходит весь внешний
обмен данными.
Микросервисы
Сэм Ньюман, автор Building Microservices, выделяет восемь принципов микросервисной архитектуры:
• Проектирование сервисов вокруг бизнес-доменов. Это может дать нам стабильные интерфейсы,
высокосвязные и мало зависящие друг от друга модули кода, а также чётко определённые
разграниченные контексты.
• Культура автоматизации. Это даст нам гораздо больше свободы, мы сможем развернуть больше
модулей.
• Скрытие подробностей реализации. Это позволяет сервисам развиваться независимо друг от друга.
• Полная децентрализация. Децентрализуйте принятие решений и архитектурные концепции,
предоставьте командам автономность, чтобы компания сама превратилась в сложную адаптивную
систему, способную быстро приспосабливаться к переменам.
• Независимое развёртывание. Можно развёртывать новую версию сервиса, не меняя ничего другого.
• Сначала потребитель. Сервис должен быть простым в использовании, в том числе другими
сервисами.
• Изолирование сбоев. Если один сервис падает, другие продолжают работать, это делает всю систему
устойчивой к сбоям.
• Удобство мониторинга. В системе много компонентов, поэтому трудно уследить за всем, что в ней
происходит. Нам нужны сложные инструменты мониторинга, позволяющие заглянуть в каждый
уголок системы и отследить любую цепочку событий.
Микросервисы
Сообщество предпочитает другой подход: умные конечные точки
и глупые каналы. Микросервисы, из которых собираются
приложения, должны как можно меньше зависеть друг от друга и
при этом быть очень тесно связанными — они содержат
собственную доменную логику и работают скорее как фильтры с
точки зрения классического Unix: получают запросы, применяют
логику и генерируют ответы. Они оркестрируются с помощью
простых REST-подобных протоколов, а не сложных протоколов
вроде WS-Choreography или BPEL либо какого-то
централизованного инструмента.
— Martin Fowler 2014, Microservices
Микросервисы
Достоинства
• Независимость набора технологий, развёртывания и масштабируемости сервисов.
• Стандартный, простой и надёжный канал связи (передача текста по HTTP через порт 80).
• Оптимизированный обмен сообщениями.
• Стабильная спецификация обмена сообщениями.
• Изолированность контекстов домена (Domain contexts).
• Простота подключения и отключения сервисов.
• Асинхронность обмена сообщениями помогает управлять нагрузкой на систему.
• Синхронность обмена сообщениями помогает управлять производительностью системы.
• Полностью независимые и автономные сервисы.
• Бизнес-логика хранится только в сервисах.
• Позволяют компании превратиться в сложную адаптивную систему, состоящую из нескольких маленьких автономных
частей/команд, способную быстро адаптироваться к переменам.

Недостатки
• Высокая сложность эксплуатации:
 Нужно много вложить в сильную DevOps-культуру.
 Использование многочисленных технологий и библиотек может выйти из-под контроля.
 Нужно аккуратно управлять изменениями входных/выходных API, потому что эти интерфейсы будут использовать многие приложения.
 Использование «согласованности в конечном счёте» (eventual consistency) может привести к серьёзным последствиям, которые нужно
учитывать при разработке приложения, от бэкенда до UX.
 Тестирование усложняется, потому что изменения в интерфейсе могут непредсказуемо влиять на другие сервисы.
Жизненный цикл сервиса
Жизненный цикл сервиса начинается
в момент его ввода в эксплуатацию
(определения) и заканчивается в
момент его вывода из эксплуатации
или переориентирования. Жизненный
цикл сервиса предполагает
управление сервисом на трех этапах:
этапе формирования требований и
анализа, этапе проектирования и
разработки и этапе эксплуатации в
ИТ-среде.
Жизненный цикл сервиса
Управление жизненным циклом
сервиса
Управление — это процессы, средства и организационная
структура, наличие которых необходимо для успешной
реализации SOA. Эффективное повторное использование сервиса
может быть достигнуто только в случае следования стандартам и
процедурам в течение всего жизненного цикла этого сервиса.
Ввиду совместного использования сервисов приложениями, они
должны проектироваться, разрабатываться и развертываться
сервисы с особой тщательностью, т.к. только так можно избежать
негативного воздействия на уже имеющихся пользователей.
Управление жизненным циклом
сервиса
При использовании сервисов различными организационными единицами
возникает конфликт приоритетов. Эффективное управление позволяет
максимально обеспечить возможность повторного использования сервисов
при минимальных потерях.
Среди основных задач управления SOA можно выделить следующие:
• Публикация стандартов и руководств по SOA
• Определение и реализация процессов, способствующих использованию и
повторному использованию сервисов в рамках проекта
• Контроль всех находящихся в разделяемом доступе сервисов предприятия
или подразделения
• Поощрение создания стандартов и руководств в рамках организации
• Информирование о результатах SOA в рамках организации
• Управление сервисами укрепляет полный жизненный цикл сервисов
Цикл жизни SOA и различные его
этапы
• Этап моделирования
 Этапмоделирования включает в себя анализ деятельности и сбор требований, за
которыми следует моделирование и оптимизация бизнес-процесса. Модель
помогает сформировать общее понимание процесса, его целей и результатов. Она
также гарантирует соответствие проекта бизнес-требованиям и обеспечивает
исходные критерии для последующего измерения производительности.
• Этап сборки
 На этом этапе существующие активы (например, ERP-система, финансовые системы
и т.д.), которые будут использоваться в моделируемых процессах, инкапсулируются
в сервисы, тогда как отсутствующие нужные функциональности реализуются и
тестируются. Когда все сервисы становятся доступными, можно скоординировать
их для реализации бизнес-процесса.
Цикл жизни SOA и различные его
этапы
• Этап развертывания
 На этапе развертывания среда времени исполнения настраивается на необходимый
уровень качества сервиса и на удовлетворение требований безопасности. Среда
может масштабироваться и оптимизироваться для повышения надежности работы
критичных процессов и для обеспечения гибкости, позволяющей динамически
обновлять ее в случае каких-либо изменений.
• Этап управления
 На этом этапе выполняется мониторинг ряда аспектов, таких как доступность
сервисов, время реакции, контроль версий сервисов. Важную роль на этом этапе
играет мониторинг ключевых показателей производительности (key performance
indicators - KPI) процесса. Он помогает предотвратить или изолировать и
диагностировать возникающие проблемы в реальном времени, а также обеспечить
обратную связь с целью улучшения производительности бизнес-процесса и
устранения узких мест. Эта обратная связь передается на этап моделирования
(первый этап) с целью усовершенствования процесса.
 Система межведомственного
электронного взаимодействия
Система межведомственного электронного взаимодействия (СМЭВ) —
информационная система, которая позволяет федеральным, региональным и местным
органам власти, кредитным организациям (банкам), внебюджетным фондам, и прочим
участникам СМЭВ обмениваться данными, необходимыми для оказания
государственных услуг гражданам и организациям, в электронном виде.
Создана в соответствии с Федеральным законом Российской Федерации от 27 июля
2010 года № 210-ФЗ «Об организации предоставления государственных и
муниципальных услуг».
Положительный эффект
• Граждане избавлены от необходимости собирать документы в различных
государственных органах.
• Теперь гражданин, обращающийся за государственной услугой, должен предоставить
только документы личного хранения (паспорт, свидетельство о рождении и т. д.). Все
остальные справки собирает само ведомство.
• Государственный орган не вправе требовать от граждан или организаций,
обратившихся за госуслугой, сведения, которые уже имеются в распоряжении
другого государственного органа.
 Компонентно-ориентированное
программирование
Компонентно-ориентированный подход может применяться во многих языках
программирования с помощью стандартных конструкций (таких как: классы,
интерфейсы, пакеты, модули).
Существуют языки программирования, реализующие на конструктивном уровне
компонентно-ориентированное программирование:
«Оберон» (ограниченно);
«Компонентный Паскаль».
В рамках языка «Java» — компонентно-ориентированное программирование
реализуется посредством компонентов, называемых «JavaBeans», поддержанных в
одной из ранних спецификаций языка;
В платформе «.NET» — реализован компонентно-ориентированный подход,
обеспечивающий создание и повторное использование компонентов для любого языка
программирования, поддерживаемого платформой.
Классический подход к построению
высоконагруженного веб-сервиса
1. Много серверов, поделённых на роли.
2. Часть серверов (роль Frontend) предназначена для отдачи статических ресурсов
(изображений, CSS, JS-файлов) и “распределения” фронта входящего траффика по
нижестоящим узлам. Основной софт, как правило, Nginx.
3. Нижестоящие узлы (роль Backend) занимаются динамическими вычислениями.
Проще говоря, это может быть типичная связка Apache+PHP.
4. Ещё одна группа серверов предназначена для хранения данных. Это MySQL,
Memcache, Redis и так далее.
5. Сам код веб-сервиса (в данном примере – PHP-код) одинаково скопирован на все
узлы, где есть Apache+PHP, и одинаково обрабатывает те запросы, которые
“пришлись” на тот или иной узел.
6. Базы данных “размазываются” по своей группе серверов, и нагрузка на них
балансируется аналогичным образом.
Недостатки классического подхода
Основной тренд – усложнение. С течением времени жизни проекта
“классическая” схема всё более и более усложняется. С добавлением
каждого нового сервера нужно вводить его в схему распределения
траффика. Безусловно, в крупных проектах введение сервера в роль –
“однокнопочное” действие, но тем не менее – это рост инфраструктуры,
которую нужно поддерживать. И тем более – в случае, когда текущих
мощностей под БД уже не хватает, и нужно “по живому” (без остановки
сервиса) переносить или разносить базу данных на новые сервера.
Но самая главная проблема – наращивание кластера распределения
траффика никак не приводит к снижению сложности программного
кода. Вы можете безупречно построить кластер, но код останется таким
же, как был.
Недостатки классического подхода
Деплой не атомарен. Говоря понятными словами, выкладывание новой версии
проекта на боевые сервера занимает какое-то время. Нужно физически загрузить
файлы на N-дцать машин, произвести изменения в БД, сбросить кэши (много
разных кэшей), и единомоментно на всех серверах закончить обработку запросов
“старым кодом” и начать обработку “новым кодом”. Иначе может возникнуть
множество мелких конфликтов, когда часть запроса пользователя обработана по-
старому, часть по-новому, какая-то часть легла в базу данных по “старой схеме”,
часть “по новой”, и так далее.
Поэтому, в идеале все хотят приостанавливать работу сервиса на время
обновления (несколько секунд или десятков секунд), и затем включать снова. В
реальности, при потоке хотя бы в 1000 запросов в секунду, никто так не делает,
предпочитая регулярно исправлять мелкие коллизии “руками”, либо покрывая
защитным программированием, поддерживающим обратную совместимость “до
седьмого колена”. О том, насколько регулярная поддержка обратной
совместимости усложняет жизнь программистам (и удорожает проект в целом) –
сообразительный читатель может задуматься сам.
Недостатки классического подхода
Используется HTTP. Протокол HTTP очевидно устарел морально и
технически, и если вы следите (например) за мобильной
разработкой – вы знаете, что он повсеместно вытесняется более
легковесными протоколами. Но основной недостаток в другом:
протокол HTTP “в браузере” требует завершения петли – требует
ответа в ограниченное время. Это обязывает сервис вычислить и
подготовить ответ строго в тот небольшой таймаут, который ему
позволяет браузер. Если сервис в данный момент перегружен –
запрос будет потерян безвозвратно.
Поэтому в “типичных веб-проектах” прибегают к различным
хитростям типа Long polling или иной форме периодических
запросов, что не только усложняет архитектуру, но и перегружает
сервис излишним “дёрганием впустую”.
Недостатки классического подхода
Инициализация скрипта на каждый запрос. Это следствие
использования HTTP и скриптовых языков вроде PHP, которые по давно
устоявшейся традиции запускаются заново в ответ на каждый запрос.
Да-да, в ответ на каждый из 1000 запросов в секунду PHP-скрипт будет
стартовать заново, инициализовать все переменные заново,
устанавливать соединения с БД заново. На практике бывает так, что на
обработку запроса нужно 0.005 секунды, а скрипт инициализируется
порядка 0.05 секунды – в десять раз дольше!
Иными словами, 90% времени ваши сервера заняты не обработкой
запросов клиентов, а бесполезной инициализацией скриптов.
Попробуйте перевести это в деньги. Поэтому придумана масса
обходных путей вроде OPcode-кэширования, персистентных
коннекшенов к БД, локальных кэшей вроде Memcache или Redis,
предназначенных для того чтобы погасить этот неприятный эффект.
Недостатки классического подхода
Монолитное приложение. Как бы вы ни делили приложение на модули, как
бы ни старались разносить код по сложной структуре каталогов, какой бы
lazy autoloading вы ни использовали – критерий один: если для выкладки
хотя бы одного изменения вам нужно выложить приложение целиком, – у
вас монолитное приложение. Иного не дано.
Недостатки монолитных приложений массово описаны в литературе.
Кратко можно упомянуть один из главных: если вы хотите, чтобы даже
самая мелкая фича была на продакшене не позднее чем через час, вам
нужно уместить всю производственную цепочку в один час. Постановка
задачи, реализация, проверка обратной совместимости, написание тестов,
написание документации, прогон через отдел ручного тестирования,
исправление ошибок – всё в течение часа.
Потому что если вы выкладываете приложение целиком ровно в 00 минут
каждого часа, то к концу каждого часа вы должны приводить всё
приложение в стабильное состояние.
Недостатки классического подхода
Веб-интерфейс отрисовывается бэкэндом. В типичном случае, внешний
вид (и соответственно HTML-код) страниц проекта отрисовывается на
стороне Backend-а, как правило, в ответ на каждый запрос. Это избыточная,
ничем не оправданная затрата ресурсов и денег.
Политическое разделение отделов. Отдел системных администраторов
отвечает за то, чтобы входящий фронт траффика был “размазан” по куче
серверов, на которых крутится PHP-код. Отдел программистов отвечает за
PHP-код. Если PHP-код не успел обработать какой-то конкретный запрос,
то за это отвечает непонятно кто – либо админ, который “пустил” слишком
много траффика на сервак и перегрузил его, либо программист, который
написал неоптимальный скрипт. Если начинает тормозить база данных – то
тоже непонятно кто остаётся крайним: админ, который не сообразил
вовремя её реплицировать или программист, который тоже мог бы
сообразить.
 Первые шаги к идеалу
1. Спроектируйте всю систему как SOA (сервисно-ориентированную
архитектуру) с ESB (шиной обмена сообщениями предприятия),
отказавшись от монолитного подхода, чтобы каждую независимую
часть бизнес-логики обрабатывал отдельный “сервис”, а между собой
они бы общались по независимой шине обмена.
2. Откажитесь от синхронности. Например, в синхронной схеме “запрос –
обработка – ответ” это одна петля HTTP, которая не имеет жёсткого
контроля завершённости и легко может прерваться. В асинхронной –
три отдельных процесса: запрос (отправлен и подтверждён), обработка
(с повтором в случае сбоя), доставка ответа (с гарантией).
3. Поделите проект на два приложения – Frontend и Backend. В случае веб-
сервиса, фронтенд – это (как правило) JavaScript-приложение. Суть в
том, чтобы приложения работали асинхронно и развязанно
относительно друг друга, обмениваясь сообщениями по двустороннему
протоколу связи.
 Первые шаги к идеалу
4. Откажитесь от HTTP в пользу WebSocket. Протокол WebSocket обладает
фантастическим быстродействием по сравнению с HTTP, не имеет никаких “петель
с таймаутами”, и позволяет передавать в обе стороны любые данные (в том числе
бинарные).
5. Обеспечьте “хранение” протекающих запросов. Как только запрос принят от
клиента, скажите ему “Confirm” и сохраните этот запрос. Как только бэкэнд
освободится от предыдущего цикла обработки – передайте запрос ему. Пока
запрос “идёт” между узлами бэкэнда, сохраняйте его с момента когда он “вошёл” в
узел” и фиксируйте его как только он “вышел” из узла. Таким образом, если какой-
то узел “упадёт”, система не потеряет запрос и тут же направит его снова в
обработку. По окончанию обработки направьте результат клиенту, и храните его до
тех пор, пока клиент не скажет “Confirm”.
6. Обеспечьте параллельность вычислений для тех операций, которые могут
выполняться параллельно с точки зрения бизнес-логики, и последовательность для
тех, которые должны выполняться строго последовательно. Этот пункт написан не с
претензией на “Капитана Очевидность”, а чтобы показать, что не любой бизнес-
процесс можно “вслепую положить” на многопоточный код.
 Первые шаги к идеалу
4. Откажитесь от HTTP в пользу WebSocket. Протокол WebSocket обладает
фантастическим быстродействием по сравнению с HTTP, не имеет никаких “петель
с таймаутами”, и позволяет передавать в обе стороны любые данные (в том числе
бинарные).
5. Обеспечьте “хранение” протекающих запросов. Как только запрос принят от
клиента, скажите ему “Confirm” и сохраните этот запрос. Как только бэкэнд
освободится от предыдущего цикла обработки – передайте запрос ему. Пока
запрос “идёт” между узлами бэкэнда, сохраняйте его с момента когда он “вошёл” в
узел” и фиксируйте его как только он “вышел” из узла. Таким образом, если какой-
то узел “упадёт”, система не потеряет запрос и тут же направит его снова в
обработку. По окончанию обработки направьте результат клиенту, и храните его до
тех пор, пока клиент не скажет “Confirm”.
6. Обеспечьте параллельность вычислений для тех операций, которые могут
выполняться параллельно с точки зрения бизнес-логики, и последовательность для
тех, которые должны выполняться строго последовательно. Этот пункт написан не с
претензией на “Капитана Очевидность”, а чтобы показать, что не любой бизнес-
процесс можно “вслепую положить” на многопоточный код.
 Четыре проблемы параллельных
вычислений
Синхронизация
Когда несколько модулей одной и той же программы запускаются на разных
процессорах, то возникает необходимость в синхронизации их действий.
Модулю А могут быть необходимы результаты работы модулей В и С, поэтому начать
свое выполнение модуль А может лишь по завершении работы как модуля В, так и
модуля С, которые могут выполняться параллельно, но не известно, какой из них
первым закончит работу. В любом случае запуск модуля А на выполнение должен быть
синхронизирован с окончанием работ модулей В и С.
При распараллеливании по данным один и тот же модуль F может быть запущен на k
процессорах и параллельно выполняться, обрабатывая разные подмножества данных
(X1, X2, …Xk). Результаты работы k процессоров затем объединяются в процессе работы
модуля G. Понятно, что запуск на выполнение модуля G должен быть синхронизирован с
окончанием работы модуля F на всех параллельно работающих k процессорах.
Параллельные вычисления требуют тщательной синхронизации работы модулей
программы, выполняемых разными процессорами.
 Четыре проблемы параллельных
вычислений
Гонка данных (Data race)
Так называемая проблема "гонки данных" возникает для мультипроцессорных
компьютеров с общей памятью. Поскольку процессоры работают параллельно, то в
одни и те же моменты времени они могут получать доступ к одним и тем же данным,
хранимым в общей памяти, как для чтения, так и для записи.
Если совместное чтение данных представляется возможным и допустимым, то
одновременная запись двух разных значений в одну и ту же ячейку памяти не
допустима. Запись всегда будет идти по очереди. Конкурирование процессоров за
запись в одно и то же слово памяти и называется "гонкой данных". Интересно, что в
этой гонке выигрывает не тот, кто пришел первый, а тот, кто пришел последний,
поскольку именно его результаты будут сохранены в памяти. Это соответствует
пословице: "хорошо смеется тот, кто смеется последним".
Чтобы справиться с проблемой "гонки данных", существуют разные механизмы
закрытия памяти - одного из видов совместно используемого ресурса. Тот, кто
выигрывает гонку и приходит первым, закрывает ресурс для доступа. Проигравшие
гонку прерывают выполнение и становятся в очередь за обладание ресурсом.
 Четыре проблемы параллельных
вычислений
Гонка данных (Data race) - продолжение
Обладатель ресурса спокойно выполняет свою работу, а по ее окончании открывает
ресурс, с которым теперь начинает работать тот, кто первым стоит в очереди.
Гонка данных - это одна из самых серьезных проблем параллельного
программирования, поскольку при некорректно организованной блокировке ресурса
программа может завершаться с некорректными результатами без возникновения
исключительных ситуаций.
Плохо, когда в процессе работы программы происходит отказ и нужные нам
результаты не могут быть получены. Но еще хуже, когда программа завершается,
выдает результаты, но эти результаты ошибочны. Плохо, когда студент на экзамене
говорит: "не знаю", но хуже, когда он говорит "глупости".
 Четыре проблемы параллельных
вычислений
Клинч или мертвая блокировка(deadlock)
Чтобы справиться с гонкой данных, приходится включать блокировку, закрывая ресурс для
других конкурентов, которые должны прервать свою работу и томиться в очереди, ожидая
момента освобождения ресурса. Блокировка - полезный механизм, обойтись без которого в
ряде ситуаций просто невозможно. Но блокировка - это и опасный механизм, порождающий
прерывание работы всей программы, когда возникает ситуация, называемая тупиком,
клинчем или смертельным объятием.
Рассмотрим простейшую ситуацию, приводящую к возникновению клинча. Пусть есть два
конкурента А и В, претендующие на два ресурса f и g. Пусть гонку за ресурс f выиграл А и
соответственно закрыл этот ресурс для В. Гонку за ресурс g выиграл В и закрыл ресурс для А.
Но А, чтобы закончить свою работу нужен ресурс g, поэтому он стал в очередь, ожидая
освобождения ресурса g. Симметрично, В томится в очереди, ожидая освобождения ресурса
f. Возникает ситуация клинча, когда ни А, ни В не могут продолжить свою работу.
В боксе, когда два боксера входят в клинч, сцепившись друг с другом, нужен судья, дающий
команду "break", чтобы боксеры могли разойтись и продолжить бой. Так и в параллельных
вычислениях при возникновении клинча, только внешнее воздействие может разрешить
ситуацию.
 Четыре проблемы параллельных
вычислений
Послать - Получить (Send - Receive или Map - Reduce)
Для мультикомпьютерных комплексов, где каждый компьютер комплекса имеет
собственную память, проблемы гонки данных и клинча не столь актуальны. Здесь
возникает своя не менее серьезная проблема. Хотя каждый компьютер комплекса
работает со своими данными, но все параллельно работающие компьютеры решают
одну и ту же задачу, поэтому без обмена информацией обойтись невозможно. В
процессе работы компьютеры должны обмениваться данными, посылая друг другу
сообщения. В кластерах (типичном виде мультикомпьютерного комплекса)
компьютеры объединены высокоскоростными линиями связи. Тем не менее, передача
данных является медленной операцией, и время на передачу данных может "съесть"
весь выигрыш, полученный за счет распараллеливания вычислений. Поэтому при
анализе эффективности работы программы, работающей на кластере или другом
мультикомпьютерном комплексе, где параллельно работающие процессоры
обмениваются сообщениями по линиям связи, не имея доступа к общей памяти,
важную роль играют операции п осылки и получения сообщений (send - receive, map -
reduce).
Процессы и потоки
Задача. Обедающие философы.
Пять безмолвных философов сидят вокруг круглого
стола, перед каждым философом стоит тарелка с
роллами (их 10 штук в тарелке). Палочки лежат на
столе между каждой парой ближайших философов.
Каждый философ может либо есть, либо
размышлять. Приём пищи ограничен количеством
оставшихся роллов. Тем не менее, философ может
есть только тогда, когда держит две палочки —
взятую справа и слева.
Каждый философ может взять ближайшую палочку
(если она доступна), или положить — если он уже
держит её. Взятие каждой палочки и возвращение её
на стол являются раздельными действиями, которые
должны выполняться одно за другим.
Суть проблемы заключается в том, чтобы
разработать модель поведения (параллельный
алгоритм), при котором ни один из философов не
будет голодать, то есть они более-менее
равномерно съедят все свои роллы.
Задача. Обедающие философы.
Пять безмолвных философов сидят вокруг круглого
стола, перед каждым философом стоит тарелка с
роллами (их 10 штук в тарелке). Палочки лежат на
столе между каждой парой ближайших философов.
Каждый философ может либо есть, либо
размышлять. Приём пищи ограничен количеством
оставшихся роллов. Тем не менее, философ может
есть только тогда, когда держит две палочки —
взятую справа и слева.
Каждый философ может взять ближайшую палочку
(если она доступна), или положить — если он уже
держит её. Взятие каждой палочки и возвращение её
на стол являются раздельными действиями, которые
должны выполняться одно за другим.
Суть проблемы заключается в том, чтобы
разработать модель поведения (параллельный
алгоритм), при котором ни один из философов не
будет голодать, то есть они более-менее
равномерно съедят все свои роллы.
Функции СМЭВ
• Ведение реестра электронных сервисов
• Ведение политик безопасности, применяемых к зарегистрированным электронным сервисам
• Маршрутизация сообщений к зарегистрированным электронным сервисам при синхронном и
асинхронном взаимодействии
• Протоколирование обращений (входящих и исходящий сообщений) к электронным сервисам
• Гарантированная доставка сообщений, осуществляемая за счет механизма повторных
вызовов электронных сервисов при сбоях
• Обеспечение оповещения Оператора СМЭВ о сбоях в функционировании электронных
сервисов
• Передача информации о событиях на СМЭВ по подписке заинтересованным Пользователям
(информационным системам)
• Формирование динамически создаваемой статистики использования электронных сервисов
• Подписание электронных сообщений электронной подписью
• Форматно-логический контроль входящих сообщений
• Контроль и мониторинг процессов межведомственного обмена с использованием СМЭВ
Техническое описание СМЭВ
СМЭВ состоит из сети защищенных каналов связи между узлами,
расположенными в центрах обработки данных Ростелекома. Каждый
узел СМЭВ — это шина на базе Oracle Enterprise Service Bus. Участники
СМЭВ являются поставщиками и потребителями сведений:
• каждый поставщик сведений публикует и регистрирует в СМЭВ свой
электронный сервис, который предназначен для обработки запросов и
выдачи сведений
• каждый потребитель сведений получает доступ к опубликованным
сервисам в СМЭВ в случае необходимости, реализует адаптер,
который умеет правильно запрашивать сведения и получать ответ.
Оператор СМЭВ — Министерство связи и массовых коммуникаций
Российской Федерации.
Строительством инфраструктуры СМЭВ занимается «Ростелеком».
Технические подробности
взаимодействия
• Взаимодействие информационных систем через СМЭВ осуществляется с
использованием электронных сервисов, реализованных в виде веб-сервисов.
• Для передачи электронных сообщений используется протокол SOAP поверх HTTP.
• Для размещения электронной подписи в сообщениях применяются стандарты
XMLDsig и PKCS #7 (RFC 2318).
• Для электронного документооборота используется формат PDF/A с размещением
реквизитов электронного документа в XML-файле.
• Ограничение доступа реализовано на основании сведений, передаваемых в
сообщении с использованием стандарта WS-Security.
• Форматы и правила разработки электронных сервисов и применения технологии
электронной подписи регламентируются приказом Минкомсвязи РФ N 190 от 27
декабря 2010 года, а также Методическими рекомендациями по разработке
электронных сервисов и применению технологии электронной подписи.
• СМЭВ обладает функциями протоколирования взаимодействия. Также СМЭВ
позволяет установить кто, в каком объёме и на основании каких привилегий
делал запрос информации.
XMLDsig / Подпись XML
Подпись XML (также называемая XMLDSig , XML-DSig , XML-Sig ) определяет
синтаксис XML для цифровых подписей и определяется в рекомендации W3C
XML Signature Syntax and Processing . Функционально это имеет много общего с
PKCS # 7 (RFC 2315) но более расширяемо и ориентировано на подписание
документов XML. Он используется различными веб- технологиями, такими как
SOAP , SAML и другими.
Подписи XML могут использоваться для подписи данных - ресурса - любого
типа , обычно документов XML, но все, что доступно через URL, может быть
подписано. XML-подпись, используемая для подписи ресурса вне его
содержащего XML-документа, называется отдельной сигнатурой ; если он
используется для подписи какой-либо части содержащего его документа, он
называется окутанной подписью; если он содержит подписанные данные
внутри себя, он называется обходящей подписью.
Структура XMLDsig / Подписи XML
<Подпись>
<SignedInfo>
<CanonicalizationMethod />
<SignatureMethod />
<Reference>
<Transforms />
<DigestMethod />
<DigestValue />
</ Reference>
<Reference /> и т. Д.
</ SignedInfo>
<SignatureValue />
<KeyInfo / >
<Объект />
</ Подпись>
Структура XMLDsig / Подписи XML
• SignedInfoЭлемент содержит или ссылки на подписанные данные и определяет , какие используются
алгоритмы.
 SignatureMethodИ CanonicalizationMethodэлементы используются в SignatureValueэлементе и включены в ,
SignedInfoчтобы защитить их от несанкционированного доступа .
 Один или несколько Referenceэлементов определяют ресурс, подписанный ссылкой URI; и любые
преобразования, которые должны применяться к ресурсу до его подписания. Преобразование может быть
выражением XPath, которое выбирает определенное подмножество дерева документа.
 DigestMethod задает хэш-алгоритм перед применением хэша.
 DigestValueсодержит закодированный в Base64 результат применения алгоритма хеширования к
преобразованному ресурсу (ресурсам), определенным в Referenceатрибутах элемента.
• SignatureValueЭлемент содержит Base64 результат кодируются подпись - подпись генерируется с
параметрами , указанными в SignatureMethodэлементе - от SignedInfoэлемента после применения
алгоритма , указанного CanonicalizationMethod.
• KeyInfoэлемент необязательно позволяет подписчику предоставлять получателям ключ, который
проверяет подпись, обычно в виде одного или нескольких цифровых сертификатов X.509 .
Предполагающая сторона должна идентифицировать ключ из контекста, если KeyInfoего нет.
• ObjectЭлемент (необязательно) содержит подписанные данные , если это обволакивающая подпись.
Валидация и соображения
безопасности
При проверке подписи XML выполняется процедура, называемая Core Validation .
1. Проверка ссылок: каждый Referenceдайджест проверяется путем получения
соответствующего ресурса и применения любых преобразований, а затем указанного
метода дайджеста. Результат сравнивается с записанным DigestValue; если они не
совпадают, проверка не выполняется.
2. Проверка подписи:SignedInfo элемент сериализовать с использованием методы
канонизации , указанной в CanonicalizationMethod, ключе данные извлекаются с
помощью KeyInfoили с помощью других средств, а также подпись проверяется с
использованием методы , указанной в SignatureMethod.
Эта процедура устанавливает, действительно ли ресурсы были подписаны предполагаемой
стороной. Однако из-за расширяемости методов канонизации и преобразования
проверяющая сторона также должна убедиться, что то, что фактически было подписано или
переварено, действительно было тем, что было в исходных данных, другими словами, что
используемым там алгоритмам можно доверять не для изменения значения подписанных
данных.
Поскольку структура подписанного документа может быть изменена, что приводит к атакам
«обертывания подписей», процесс проверки должен также охватывать структуру документа
XML. Подписанный элемент и элемент подписи должны выбираться с использованием
абсолютного выражения XPath , а не getElementByNameметодов.
СМЭВ 3: Понятия и правила обмена
информацией
СМЭВ обеспечивает взаимодействие информационных систем (далее – ИС)
федеральных органов исполнительной власти, государственных
внебюджетных фондов, исполнительных органов государственной власти
субъектов Российской Федерации, органов местного самоуправления,
государственных и муниципальных учреждений, многофункциональных
центров, иных органов и организаций (далее - органы и организации),
используемых при предоставлении государственных и муниципальных услуг и
исполнении государственных и муниципальных функций в электронной форме.
Органы и организации выступают в качестве участников взаимодействия.
Участники взаимодействия могут запрашивать сведения или предоставлять их
другим участникам, в зависимости от этого они являются потребителями или
поставщиками сведений, путем обмена данными между ИС участников с
использованием единого электронного сервиса СМЭВ (далее – единый
электронный сервис). Единый электронный сервис реализован в виде веб-
сервиса, предоставляемого СМЭВ.
СМЭВ 3: Понятия и правила обмена
информацией
В рамках информационного взаимодействия ИС поставщика и потребителя
обмениваются сообщениями. ИС, отправляющая сообщение через СМЭВ,
является отправителем сообщения, а ИС, получающая сообщение из СМЭВ, –
получателем.
Упрощенно, процесс обмена сообщениями между ИС потребителя и ИС
поставщика через
СМЭВ включает последовательность следующих шагов:
− передача запроса от ИС потребителя в СМЭВ;
− размещение запроса в СМЭВ в очереди запросов поставщика;
− получение запроса ИС поставщика из СМЭВ;
− подготовка поставщиком ответа на запрос;
− передача подготовленного ответа из ИС поставщика в СМЭВ;
− размещение ответа в СМЭВ в очереди ответов потребителя;
− получение ответа ИС потребителя из СМЭВ.
СМЭВ 3: Обмен информацией
Роль ESB в структуре SOA
Роль ESB в структуре SOA