Похожие презентации:
Архитектурные принципы развития FORIS-SOA
1.
Архитектурные принципы развития FORIS-SOA2.
План темыМодульная архитектура FORIS. Архитектура SOA
Технологические основы SOA. Технологии
WS/WCF
Workflow. Исполнитель бизнес-процессов
(оркестратор)
Service Registry. Предоставление информации о
службах и их конфигурации
Архитектурные принципы развития FORIS-SOA
2
3.
Модульная архитектура FORIS. АрхитектураSOA
Преимущества модульной архитектуры FORIS. Взаимодействие
систем при выполнении бизнес-процессов
Архитектура SOA. Координация служб в бизнес-процессах.
Интеграционная шина
4.
Преимущества модульной архитектурыСистема FORIS состоит из взаимодействующих между собой подсистем, каждая из
которых состоит из различных модулей. Модульная архитектура FORIS позволяет
получить практически неограниченную масштабируемость. При необходимости
каждую подсистему можно расширить за счет добавления новых модулей. В
настоящий момент система FORIS может поддерживать от 10 тысяч до 100
миллионов абонентов.
Архитектурные принципы развития FORIS-SOA
4
5.
Архитектура SOASOA (Service-Oriented Architecture), или служебно (сервисно) - ориентированная
архитектура, - стиль программирования и архитектурный подход к разработке
программного обеспечения, при котором приложение организовано в функциональные
элементы кода с заданным поведением, называемые службами.
Служба(сервис) – это группа методов с общим набором требований и общими
функциональными целями. Служба вызывается другими модулями, которым нужно
выполнить соответствующее действия в зависимости от результата. Функции имеют
явно определенную и общедоступную сигнатуру, которая публикуется таким образом,
что другая программа (клиент службы) может пользоваться функциями службы как
черным ящиком.
Появление концепции SOA стало закономерным шагом на пути поиска решения
одной из самых насущных и сложных проблем ИТ-индустрии – проблемы интеграции
приложений.
Архитектурные принципы развития FORIS-SOA
5
6.
Архитектура SOAПриложение 1
Приложение 2
Приложение 3
Приложение 4
Приложение 5
Прямая интеграция приложений
Если в компании существует N приложений, каждое из которых интегрировано со
всеми остальными посредством соответствующих интерфейсов, то с добавлением
всего лишь одного нового приложения понадобиться 2N новых интерфейсов.
Архитектурные принципы развития FORIS-SOA
6
7.
Архитектура SOAСервис 1
Сервис 2
Сервис 3
Управление
потоком заданий
Сервис 4
Сервис 5
Сервис 6
SOA. Модель сервисной шины
Добавление одного сервиса приведет только к добавлению одного дополнительного
интерфейса для интеграции с остальными компонентами архитектуры.
Архитектурные принципы развития FORIS-SOA
7
8.
Архитектура SOAПриведем формальное определение сервисно-ориентированной архитектуры, которое
сформулировано специалистами корпорации IBM : “SOA - это прикладная архитектура, в
которой все функции определены как независимые сервисы с вызываемыми
интерфейсами. Обращение к этим сервисам в определенной последовательности
позволяет реализовать тот или иной бизнес-процесс”.
С точки зрения разработчиков, ту же мысль можно передать несколько иными словами:
SOA — это компонентная модель, в которой разные функциональные единицы
приложений, называемые сервисами, взаимодействуют по сети посредством
интерфейсов. Расшифруем данные определения.
Архитектурные принципы развития FORIS-SOA
8
9.
Архитектура SOA1. Все функции приложений определены как сервисы. В качестве сервиса может
выступать как целое приложение, так и отдельные его функциональные модули.
Сервисами могут быть прикладные функции, реализующие определенную бизнес-логику,
бизнес-транзакции, состоящие из нескольких функций более низкого уровня, и
системные функции, отражающие специфику различных операционных платформ.
2. Все сервисы независимы друг от друга. Они выполняют определенные действия по
запросам, полученным от других сервисов, и возвращают результаты. Все детали этого
полностью скрыты: в концепции SOA сервисы - это "черные ящики".
3. В интерфейсе сервиса определены параметры и описан результат. Иными словами,
интерфейс определяет суть сервиса, а не технологию его реализации. На архитектурном
уровне для обращения к сервису не имеет значения, является он локальным
(реализован в данной системе) или удаленным (внешний по отношению к ней), какой
протокол используется для передачи вызова, какие компоненты инфраструктуры при
этом задействованы.
Архитектурные принципы развития FORIS-SOA
9
10.
Архитектура SOAИнтерфейсы — ключевые элементы SOA. Они должны быть нейтральными к
специфике реализации сервиса, которые определяются аппаратной платформой,
операционной системой, языком программирования. Подобный нейтралитет
обеспечивает универсальность взаимодействия сервисов в разнородной среде, а
сервисы, интегрированные посредством таких интерфейсов, являются слабо
связанными.
В SOA приложение разрабатывается исходя из логики бизнес-процесса. Процесс
разбивается на некоторую последовательность шагов, каждый из которых
реализуется как сервисный компонент приложения. И эти компоненты интегрируются
таким образом, чтобы их выполнение в определенной последовательности приводило
к нужному бизнес-результату.
Архитектурные принципы развития FORIS-SOA
10
11.
Архитектура SOAСервисная шина предприятия (enterprise service bus, ESB) архитектурная
концепция, используемая для сервисно-ориентированной интеграции. Ее задача предоставить единый механизм передачи запросов и получения результатов
сервисов, выполнения необходимых преобразований сообщений и транспортных
протоколов (скажем, от SOAP на базе HTTP к SOAP на основе WebSphere MQ),
обеспечения требований безопасности доступа и, что наиболее важно, управления
потоком обращений к сервисам. Благодаря такому управлению выполняется нужная
последовательность вызовов сервиса для реализации бизнес-процесса.
Архитектурные принципы развития FORIS-SOA
11
12.
Технологии WS/WCFТехнологические основы SOA. Преимущества технологии WCF
Базовая композиция приложения WCF. Сборка, хост, клиент
Понятие АВС(address, binding, contract)
13.
Технологические основы SOAЧтобы разработать приложение в SOA, нужны технологии и протоколы. Поскольку SOA
предназначена для создания распределенных и кроссплатформенных приложений, эти
поддерживаемые технологии и протоколы должны быть промышленными стандартами.
Рассмотрим самые популярные стандарты в мире SOA.
SOAP
Simple Object Access Protocol представляет собой спецификацию XML обмена данными
в виде структурированной информации в сообщениях. SOAP стандартизирует способ
обмена данными и не зависит от платформы, так как основан на XML. Сообщение
SOAP просто переносит данные в виде сообщения. Конверт SOAP содержит
(необязательный) заголовок и (обязательный) элемент – тело. Заголовок может
содержать информацию, нужную для выделения технической инфраструктуры для
поддержки коммуникаций, и не связан с бизнес-функциональностью. Элемент (тело)
содержит функциональные данные как полезную информацию. Каждый параметр для
действия службы представлен в теле в виде последовательности данных.
Архитектурные принципы развития FORIS-SOA
13
14.
Технологические основы SOAПример сообщения SOAP.
<soap:Envelope
xmlns:soap=“http://www.w3.org/2001/12/soap-envelope”
soap:encodingStyle=“http://www.w3.org/2001/12/soap-encoding”>
<soap:Body xmlns:m=“http://www.example.org/stock”>
<m:GetStockPrice>
<m:StockName>XYZ</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>
Архитектурные принципы развития FORIS-SOA
14
15.
Технологические основы SOAWS-* протокол
SOAP – спецификация формата функциональных данных в теле и технических данных
в заголовках. SOAP сам не всегда определяет значение заголовка. WS-* - это набор
протоколов, которые стандартизирует реализацию определенных требований и
режимов при работе с распространяемыми сообщениями, пользуясь заголовками в
сообщениях SOAP. Эти протоколы описывают, как канал должен выполнять обмен
сообщениями безопасно, транзакционно и надежно, пользуясь заголовками в
сообщениях SOAP. WS-* - набор протоколов, причем каждый протокол имеет свое
предназначение. (WS-Routing, WS-Security, WS-Reliability, WS-Policy, WS-Transactions)
WSDL
WSDL (Web Services Description Language) представляет собой описание соглашений в
формате XML и содержит все метаданные для интерфейса службы, включая имена
функций, имена и типы параметров, а также типы возвращаемых значений. Файл
WSDL определяет соглашение независимо от платформы, так как типы определяются в
типах XML.
Архитектурные принципы развития FORIS-SOA
15
16.
Технологические основы SOAПриложение .NET
на платформе Win32
HTTP и XML
Веб-сервер
Прокси
веб-службы
Приложение Java
на платформе Unix
HTTP и XML
Веб-служба
XML
Прокси
веб-службы
Приложение Java (или.NET)
на платформе Macintosh
HTTP и XML
Прокси
веб-службы
Веб-службы XML обеспечивают очень высокую степень взаимодействия
Архитектурные принципы развития FORIS-SOA
16
17.
Технологические основы SOAОперационная система Windows предоставляет множество API-интерфейсов для
построения распределенных систем – DCOM, COM+, MSMQ, .NET Remoting,
именованные каналы, сокеты (все эти API-интерфейсы обеспечивают минимальную
поддержку доступа удаленных пользователей в независимой манере). Ни один
распределенный API-интерфейс не является безупречным. Один из потенциальных
недостатков веб-служб состоит в том, что они могут страдать от некоторых проблем с
производительностью (учитывая использование HTTP и XML для представления
данных). Другой недостаток связан с тем, что веб-службы могут оказаться не
идеальным решением для “домашних” приложений, где беспрепятственно можно
применять протоколы на основе TCP и двоичное форматирование данных.
WCF (Windows Communication Foundation) – это инструментальный набор
распределенных вычислений, который интегрирует все ранее независимые технологии
распределенной обработки в один стройный API-интерфейс.
Архитектурные принципы развития FORIS-SOA
17
18.
Технологические основы SOAПротокол
Канал
Сообщения
Хост
Служба
Сообщения
Политика
Схема
и
контракты
Работа службы
Архитектурные принципы развития FORIS-SOA
18
19.
Технологические основы SOAСлужба, в которой содержатся методы, пользуется каналом для того, чтобы его могли
найти и использовать клиенты. Клиенты службы также пользуются каналом, который
совместим с каналом службы, чтобы фактически вызывать методы и отправлять
нужные данные службе.
Канал представляет собой комбинацию схемы, соглашения и стратегии с одной
стороны и используемого протокола с другой. Протокол, например HTTP или MSMQ, в
данном случае перемещает данные и поддерживается операционной системой, на
которой реализованы службы.
Архитектурные принципы развития FORIS-SOA
19
20.
Базовая композиция приложения WCF. Сборка, хост, клиентПри построении распределенной системы WCF обычно создаются три
взаимосвязанных сборки.
Сборка службы WCF. Эта библиотека *.dll содержит классы и интерфейсы,
представляющие общую функциональность, которая предлагается внешним
клиентам.
Хост службы WCF. Это программный модуль – сущность, которая принимает
в себе сборку службы WCF.
Клиент WCF. Это приложение, которое обращается к функциональности
службы через промежуточный прокси.
Архитектурные принципы развития FORIS-SOA
20
21.
Базовая композиция приложения WCF. Сборка, хост, клиентКлиентское приложение
Прокси
Конфигурационный файл
Хост WCF
Служба WCF
Конфигурационный файл
Высокоуровневое представление типичного приложения WCF
Архитектурные принципы развития FORIS-SOA
21
22.
Понятие АВС(address, binding, contract) в WCFХосты и клиенты взаимодействуют друг с другом, согласовывая так
называемые ABC – условное наименование для запоминания основных
строительных блоков приложения WCF, таких как адрес, привязка и контракт
(address, binding, contract – ABC).
Адрес. Описывает местоположение службы.
Привязка. WCF поставляется с множеством различных привязок, которые
указывают сетевые протоколы, механизмы кодирования и транспортный
уровень.
Контракт. Предоставляет описание каждого метода, представленной
службой WCF.
Архитектурные принципы развития FORIS-SOA
22
23.
Понятие АВС(address, binding, contract) в WCFПрименение файла *.config на серверной или клиентской стороне не является
обязательным. При желании можно жестко закодировать хост ( а также клиент),
указав необходимые детали ( то есть конечные точки, привязку, адреса).
Очевидная проблема такого подхода состоит в том, что если нужно изменить
детали настройки, понадобиться вносить изменения в код, перекомпилировать
и заново развертывать множество сборок. Использование файла *.config
делает кодовую базу намного более гибкой, поскольку все изменения настроек
производятся редактированием конфигурационных файлов и последующим
перезапуском.
Архитектурные принципы развития FORIS-SOA
23
24.
Пример службы WCFКлиентское приложение
(MagicEightBallServiceClient.exe)
Прокси
Конфигурационный файл
MagicEightBallServiceClient.exe.config
Хост WCF
(MagicEightBallServiceHost.exe)
Служба WCF
MagicEightBallServiceLib.dll
Конфигурационный файл
MagicEightBallServiceHost.exe.config
Магический шар Magic 8-Ball – это игрушка, позволяющая получить шуточное
предсказание будущего. В интерфейсе IEightBall определен единственный метод
ObtainAnswerToQuestion, который позволяет клиенту задать вопрос магическому шару,
чтобы получить случайный ответ. (пример взят из книги Эндрю Троелсена “Язык
программирования С# и платформа .NET 4)
Архитектурные принципы развития FORIS-SOA
24
25.
Пример службы WCF. Конфигурационный файл службыАдрес службы
basicHttpBinding – эта привязка использует HTTP в качестве транспорта и Text/XML в
качестве метода кодирования сообщений по умолчанию.
Архитектурные принципы развития FORIS-SOA
25
26.
Пример службы WCF. Конфигурационный файл клиентаКонечная точка – адрес,
привязка, контракт
Архитектурные принципы развития FORIS-SOA
26
27.
Пример службы WCF. Удаленный вызов метода службыВызов службы MagicEightBallService
с помощью HTTP метода POST
Архитектурные принципы развития FORIS-SOA
27
28.
Пример службы WCF. Удаленный вызов метода службыВызов метода ObtainAnswerToQuestion
по SOAP
Архитектурные принципы развития FORIS-SOA
28
29.
Пример службы WCF. Вызов метода службыОтвет метода ObtainAnswerToQuestion
по SOAP
Архитектурные принципы развития FORIS-SOA
29
30.
Workflow. Исполнитель бизнес-процессов(оркестратор)
Как Workflow координирует и исполняет бизнес-процессы
Архитектура Workflow
Задание логики исполнения бизнес-процессов. Язык PDL
31.
Как Workflow координирует и исполняет бизнес-процессыWorkflow – это:
1. Система исполнения бизнес-процессов
2. SOA-совместимая интеграционная шина
Workflow обращается к независимым сервисам с помощью модулей-клиентов данных
сервисов.
Если на предприятии появляется новый сервис, то в Workflow
соответственно необходимо импортировать новый модуль-клиент для взаимодействия с
этим сервисом.
Последовательность обращений к необходимым сервисам (описание логики бизнеспроцесса) определяется в xml-документе с помощью языка PDL (process definition
language). XML-документ с описанием бизнес-процесса также должен быть
импортирован в Workflow.
Архитектурные принципы развития FORIS-SOA
31
32.
Как Workflow координирует и исполняет бизнес-процессыВнешние системы
ЕСПП
Oracle GlassFish
Enterprice Service Bus
CRM Marti
Customer
Management
TellBill
22
11
SPA
UPRGS
1
33
MG
2
Cash Register
Security
RI
Workflow Suite
44
4
55
5
66
6
3
SUPS
R&D
Catalogues
Stock
Workflow обращается к независимым сервисам с помощью модулей-клиентов,
предварительно импортированным в Workflow, количество обращений к различным
сервисам и их последовательность определяется в описании бизнес-процесса на языке
PDL.
Архитектурные принципы развития FORIS-SOA
32
33.
Архитектура WorkflowWorkflow Suite:
• BPE (Business-process Engine)
• Service Registry
• Resource Locking
• Human task management
BPE
подсистема управления бизнес-процессами и взаимодействия
с системами
Service Registry
подсистема, предоставляющая сведения о службах, их
развертывании и конфигурации
Resource Locking
подсистема управления блокировками ресурсов
Human task
management
подсистема, позволяющая вовлечь в выполнение бизнеспроцесса человека
Архитектурные принципы развития FORIS-SOA
33
34.
Архитектура WorkflowBPE (Business-process Engine):
• Assembly Importer
• PDL Importer
• Facade Service
• Processor Service
• Workflow Enterprise Manager
Assembly Importer
утилита для импорта в Workflow сборок, содержащих в себе
информацию о типах данных, операциях и службах
PDL Importer
утилита для импорта в Workflow бизнес-процессов
Facade Service
сервис WCF отвечающий за создание экземпляров процессов и
выполнение стартовой логики
Processor Service
обеспечивает основную обработку логики бизнес-процесса, не
взаимодействует с клиентскими приложениями (только с БД)
Workflow Enterprise подсистема мониторинга и администрирования
Manager
Архитектурные принципы развития FORIS-SOA
34
35.
Архитектура Workflow. Модульная архитектура системыWorkflow Suite
WCF
Service Registry
Config DB
BAR DB
Service 1
SOAP/ WCF
Workflow
Enterprise
Manager
Workflow 2.0 (Facade, Processor)
Node DB
Customer Management
. . .
Service N
Resource
Locking
Модульная архитектура системы
Архитектурные принципы развития FORIS-SOA
35
36.
Архитектура WorkflowConfig DB
в конфигурационной базе данных Workflow хранятся
метаданные (определение данных), которые необходимы
системе для создания, обработки и предоставления
информации о процессах. Конфигурационная база данных
всегда одна
Node DB
в узловой базе данных Workflow хранятся экземпляры
процессов и история их выполнения. Узловых баз данных может
быть несколько
Архитектурные принципы развития FORIS-SOA
36
37.
Архитектура Workflow. Схема развертыванияАрхитектурные принципы развития FORIS-SOA
37
38.
Задание логики исполнения бизнес-процессов. Язык PDLPDL (Process Definition Language, язык определения процесса) — интерпретируемый язык
Это означает, что интерпретатор (в данном случае, ядро Workflow) выполняет языковые
инструкции непосредственно, без предварительного перевода. PDL определяет данные
(переменные простых или структурных типов), с которыми работает процесс, а также
порядок, в котором должны быть выполнены операции над этими данными. Язык
включает разнообразные управляющие конструкции (последовательность, параллельное
выполнение, цикл, условный переключатель, транзакционный блок, обработчик ошибок и
пр.) и простые активности (вызов локальной или удаленной операции, присваивание,
ожидание сообщения, задержка и пр.); их комбинация позволяет алгоритмическим
образом задавать довольно сложные бизнес-процессы.
Использование языка PDL для описания бизнес-процессов позволяет унифицировать
способ реализации бизнес-процессов на предоставление услуг.
Архитектурные принципы развития FORIS-SOA
38
39.
Задание логики исполнения бизнес-процессов. Язык PDLПример тестового бизнес-процесса
Архитектурные принципы развития FORIS-SOA
39
40.
Задание логики исполнения бизнес-процессов. Язык PDLСценарий ввода в эксплуатацию нового типа процесса выглядит так:
1. С помощью утилиты Assembly Importer в Workflow регистрируются типы данных и
операции, используемые в процессе;
2. В каком-нибудь XML-редакторе пишется определение типа процесса, использующее
эти объекты;
3. С помощью утилиты Pdl Importer определение типа процесса импортируется в
Workflow;
4. Workflow автоматически генерирует метод создания экземпляров процесса этого типа;
5. Программисты используют этот метод для создания экземпляров процессов с
необходимыми данными (они передаются в аргументах метода);
6. Workflow обрабатывает (то есть выполняет) созданные процессы;
7. Служба поддержки использует средства мониторинга для того, чтобы убедиться, что
все в порядке.
Архитектурные принципы развития FORIS-SOA
40
41.
Service RegistryДля чего необходим Service Registry
Предоставление сведения о службах, их конфигурации и
серверах развертывания
Создание сконфигурированного экземпляра прокси для служб и
клиентов
42.
Для чего необходим Service RegistryСервис 1
ServiceHost1.config
Клиент 2
ServiceClient2.config
Управление
потоком заданий
Workflow
Клиент 1
Сервис 2
ServiceClient1.config
ServiceHost2.config
Для служб и их клиентов необходимо поддерживать в актуальном состоянии
конфигурационные файлы ServiceHost.config и ServiceClient.config (название и
структура файлов могут отличаться и зависят от типа служб). Когда служб много и они
находятся на различных серверах, поддерживать корректные настройки данных
конфигурационных файлов “вручную” становится проблематично и потенциально ведет
к созданию ошибок и некорректной работе всей системы.
Архитектурные принципы развития FORIS-SOA
42
43.
Для чего необходим Service RegistryСервис 1
Клиент 2
ServiceRegistry.Client.dll
ServiceRegistry.Client.dll
Клиент 1
Сервис 2
ServiceRegistry.Client.dll
ServiceRegistry.Client.dll
Управление
потоком заданий
Workflow
Service Registry
service1.config
service2.config
service3.config
service4.config
Service Registry позволяет автоматизировать процесс
создания сконфигурированных экземпляров прокси для
служб и их клиентов.
Архитектурные принципы развития FORIS-SOA
43
44.
Предоставление сведения о службах, их конфигурации исерверах развертывания
Service Registry – это система входящая в состав Workflow Suite, которая предоставляет
сведения о службах, использующихся в компании, их конфигурации (протоколах
доступа, параметрам подключения и т.д) и серверах развёртывания.
Service Registry также предоставляет сервисы, основанные на этой информации – такие
как создание сконфигурированного экземпляра прокси.
Реестр служб с соответствующей информацией хранится в конфигурационной базе
данных Service Registry. Предварительно администратор системы должен внести
информацию о службах в конфигурационную базу с помощью web-консоли или
консольной утилиты регистрации служб.
Архитектурные принципы развития FORIS-SOA
44
45.
Создание сконфигурированного экземпляра прокси дляслужб и клиентов
Клиенты системы Service Registry (службы и их клиенты) используют библиотеку
динамического связывания Marti.ServiceRegistry.Client.dll. Данная библиотека содержит
класс, в котором определены два метода:
создание сконфигурированного экземпляра прокси-класса службы CreateConfiguredProxy
создание сконфигурированного экземпляра хоста службы - CreateConfiguredHost
Клиенты Service Registry вызывают данные методы, чтобы получить необходимый для их
работы сконфигурированный экземпляр прокси.
Архитектурные принципы развития FORIS-SOA
45