Архитектуры и модели программ и знаний

Основные понятия Service- Oriented Architecture (SOA)

Сервис – компонента программы, непосредственно доступная пользователюПример сервиса: Получение прогноза погоды через ИнтернетОсновной принцип: С точки зрения пользователя, программный продукт

представляет собой набор простых в использовании Web-сервисов с удобным графическим Web-интерфейсом

Сервис-ориентированная модель должна быть расширяемой (пользователь должен иметь возможность добавить новые сервисы или изменить набор доступных сервисов)

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

Метод реализации Web-сервисов (.NET, Java и др.) для пользователя не важенРазработчик должен иметь возможность публикации своих Web-сервисовПоддержка SOA:

Microsoft SharePoint (простой инструмент для создания расширяемых Web- страниц и Web-сервисов);

UDDI (Universal Discovery, Description and Integration) – технология для публикации и поиска Web-сервисов (Microsoft)

(C) Сафонов В.О. 2012

SOA: Принципы архитектуры

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

например, размещение заказа авиабилета

Структура Web-сервисов описана на языке WSDL (Web Service Definition Language) – расширении XML

В качестве коммуникационного протокола при обмене данными используется SOAP (Simple Object Access Protocol), также основанный на представлении в форме XMLПреимущество SOA: Позволяет быстро разработать Web- приложение, используя существующий набор Web-сервисов, без каких-либо измененийРеализация сервисов может выполняться на любом языке,

спри условии соблюдения всех протоколов – от COBOL до C#

(C) Сафонов В.О. 2012

SOA: Требования к разработке и использованию сервисов

Возможность взаимодействия (interoperability) между различными языками разработки сервисовОриентация на создание “федерации ресурсов”

(federated data warehouse). Единый бизнес- формат для каждого элемента данных

(C) Сафонов В.О. 2012

SOA: Основные принципы разработки, сопровождения и использования

Повторная используемость, модульность, компонентная ориентация, взаимодействиеСоответствие общим и специфическим стандартамИдентификация сервисов, их разбиение на

категории, мониторинг и отслеживание их работы

(C) Сафонов В.О. 2012

SOA: Важнейшие принципы архитектуры

Инкапсуляция сервисов (каждый сервис реализован как АТД; детали его реализации не известны разработчикам других сервисов)

Слабое связывание сервисов; они не должны использовать особенности реализации друг друга, но лишь должны быть осведомлены о существовании друг другаКонтрактное проектирование сервисов: Каждый сервис должен

удовлетворять заранее оговоренному всеми разработчиками контракту

Возможность обнаружения сервисов (discoverability) с помощью общепринятых технологий (например, UDDI – Universal Discovery, Description and Integration)

Вывод: Согласованность реализации сервисов с данными принципами позволяет различным сервисам, реализованным на различных платформах (например, .NET и Java), взаимодействовать друг с другом

(C) Сафонов В.О. 2012

Web-сервисы – распространенный метод реализации SOA

Две стороны взаимодействия с Web-сервисом в SOA: - Поставщик Web-сервиса (service provider): через UDDI осуществляет публикацию Web-сервиса; обеспечивает возможность его обнаружения; предусматривает возможность выдачи WSDL- описания Web-сервиса по запросу пользователя

Потребитель Web-сервиса (service requester) – обнаруживает Web-сервис с помощью механизма discovery; генерирует запросы к Web-сервису: уточняет его структуру по полученному от сервиса WSDL-описанию; вызывает специфицированные в нем Web-методы

(C) Сафонов В.О. 2012

SOA 2.0: Дальнейшее развитие

архитектуры SOA

(C) Сафонов В.О. 2012

Структура контракта сервиса

Заголовок

имя, версия, владелец

Распределение ответственностей за сервис (RACI

– Responsible, Accountable, Consulted, Informed)Тип сервиса (презентация, процесс, данные и т.д.)

Функциональная часть:

Т ребования к функциональностиОперации сервисаСпособ их вызова

Прочие требования: ограничения, качество сервиса и др.

(C) Сафонов В.О. 2012

Преимущества и недостатки SOA

Преимущества: Важная попытка стандартизации архитектуры клиент-серверного ПО; отражает лучшие образцы ранее разработанных сервисовНедостатки: Более низкая производительность,

вследствие использования в реализации протоколов и механизмов удаленного вызова процедур и методов (RPC, RMI и др.)

SOA и Web 2.0: Интенсивно развивающийся набор сервисов Web 2.0 – социальные сети, виртуальные миры и т.д. – в значительной степени соответствует модели SOA

(C) Сафонов В.О. 2012