Введение в сервис-ориентированную архитектуру, теория: преимущества, обзор составляющих. P. S. Не столько настоящая презентация, сколько черновик. Но раз попросили, то делюсь :)

1. Введение в
сервис-ориентированную
архитектуру

2. Немного
жизненного опыта :)

3. Проблемы некоторых крупных веб-проектов
• Один репозиторий, много когда, много разработчиков.
Неудобно.
• Ответственность каждого конкретного разработчика
размыта. Все отвечают за всё.
• Все компоненты в коде проекта тесно связаны между собой.
Изменение одного компонента может вызвать баги в других.
• Проект завязан на один конкретный язык программирования.
3

4. Как не довести свой проект до жизни такой
• Определяем компоненты в коде так, чтобы они были
максимально изолированы.
• Проектируем интерфейсы для доступа к компонентам так,
чтобы изменение одних компонент не влияло на изменение
других.
• По мере необходимости разносим эти компоненты в разные
репозитории.
4

5. Profit
• Изменение отдельных модулей не вызывает ошибок в
совершенно неожиданных местах проекта.
• В случае, когда был изменен один компонент, не нужно
релизить весь проект целиком.
• Каждому разработчику можно назначить ответственность не за
всё вместе, а только за отдельные вполне конкретные
компоненты.
• Разные компоненты можно писать на разных языках
программирования.
5

6. Как этого достичь?

7. Как этого достичь?
Используем SOA!

8. Теория

9. Enterprise
Сервис-ориентированная архитектура (Service-Oriented
Architecture, SOA) — понятие из мира корпоративных
приложений. Оно тесно связано с вопросами управления
бизнес-процессами предприятия.
Бизнес-процесс — это набор задач, направленный на
создание некоторых продукта или услуги.
9

10. Event-Driving Architecture
Понятие SOA тесно связано с понятием событийно-
ориентированной архитектуры (EDA).
EDA основывается на способности создавать события и
реагировать на них.
Событие — это ситуация, когда изменяется состояние
некоторого объекта.
10

11. Service-Oriented Architecture
Сервис-ориентированная архитектура — это каркас для
интеграции бизнес-процессов в виде сервисов. Все сервисы
стандартизированы, могут переиспользоваться и
комбинироваться для решения бизнес-задач.
11

12. Service-Oriented Architecture
Не только архитектура,
но и методология!
12

13. Манифест SOA
http://www.soa-manifesto.org
• Значимость бизнеса перед технической стратегией.
• Стратегические цели перед выгодами, специфичными для
данного проекта.
• Свойственная способность к взаимодействию перед
специально достигнутой интеграцией.
• Совместно используемые сервисы перед разработками с
узкими, специальными целями.
• Гибкость перед оптимизацией.
• Эволюционные усовершенствования перед попыткой
достичь изначального совершенства.
13

14. Структура SOA
* Enterprise SOA: Service-Oriented Architecture Best Practices by Dirk Krafzig, 2004
14

15. Структура SOA: Фронтенд приложения
Фронтенд приложения
должен быть отделен от сервисов.
У каждого сервиса есть четко определенный интерфейс.
Работа с этим интерфейсом может осуществляться через один
или несколько фронтендов.
15

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

17. Структура SOA: Шина
Понятие «сервисная шина»
(ESB — Enterprise Service Bus)
тесно связано с событиями.
Для оповещения о том, что произошло
событие, некоторый сервис отправляет
в шину сообщение. Другие сервисы, получив это сообщение,
могут отреагировать на событие в соответствие с заданной
бизнес-логикой.
Шина обеспечивает мгновенный обмен сообщениями и
гарантирует, что все сообщения будут доставлены.
17

18. Структура SOA: Сервис
Сервис — ключевое понятие SOA.
Сервисы служат для моделирования
бизнес-процессов.
Традиционно под каждый бизнес-процесс организуется свой
сервис.
18

19. Структура SOA: Сервис
Контракт задает поведение сервиса,
т.е. тот набор действий, который можно
выполнить, обратившись к сервису.
Интерфейсы для доступа к сервисам
должны быть четко определены и
стандартизованы в рамках информационной системы.
Например, для доступа к сервисам может использоваться REST API, соответствующий
корпоративному стандарту. Контрактом сервиса в этом случае будет набор REST-методов,
реализованный для работы с этим сервисом.
19

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

21. Questions?
info@elena.rumyantseva.name
@webdeva