Тема 4. 2: Сервис-ориентированные архитектуры (SOA, соа)

Контрольные вопросы

1. Что понимается под термином «распределенные приложения»?

2. Чем отличается схема взаимодействия централизованного и распределённого приложений?

3. Какой язык программирования преимущественно используется для создания сетевых приложений в сети Internet.

4. Достоинства языка программирования Java.

5. Какая платформа удовлетворяет распределенным системам нового поколения?

6. Достоинства платформы .NET?

7. Перечислите основные требования к системе обработки информации в масштабе предприятия.

8. Между какими объектами осуществляются связи в схеме распределения вычислений?

9. Перечислите базовые уровни архитектуры распределенного приложения.

 

 

 

Изучаемые вопросы:

 

1. Элементы и характеристики SOA.

2. Сервис-ориентированный анализ и проектирование.

3. Концепция управления распределенными службами.

4. Контрольные вопросы.

 

Учебная цель:

 

Ознакомить студентов с интеллектуальными технологиями технико-экономических систем, сервис-ориентированными архитектурами.

 

Время: 2 часа

 

Литература:

1. Г. Маклеод (Hugh Macleod) «Самый хорошо охраняемый секрет Облаков» technorati.com/posls/lv3vwaZ9hbuGSZx iQseIqa Sli29LQGiWvRkNoZ4bO%3D?reactions

2. Радченко Г.И. Распределенные вычислительные системы / Г.И. Радченко. -Челябинск: Фотохудожник, 2012. - 184 с.

3. Сейдаметова З.С., Аблялнмова Э.И., Меджитова Л.М., Сейтвелиева С.Н., Темненко В.А. Облачные технологии и образование: под общ. ред. З.С. Сейдаметовой. -Симферополь: «ДИАЙПИ», 2012. - 204 с.

 

1. Элементы и характеристики SOA.Архитектура, основанная на сервисах - это новый шаг в направлении комплексного решения проблемы создания распределенных приложений, выполняющихся на многих компьютерах. Она отличается от архитектуры, основанной на объектах (object oriented architecture), тем, что при необходимости выполнить какие-либо действия необходимо просто идентифицировать контракт, описать, как выглядят данные, и получить возможность динамически переключаться между сервисами, реализующими нужную пользователю функциональность, и выбирать сервис из нескольких доступных.

Service-Oriented Architecture (SOA) - это архитектура, обеспечивающая интеграцию и связность, и предназначенная для использования естественно возникающей гетерогенности систем и инфраструктур [4]. Существует много взглядов на концепцию SOA, она развивается, превращая Интернет в утилиту, доступную для всех способов обмена данными, коммерции и коммуникации.

Архитектура включает в себя стандарты для процессов, технологий и интерфейсов. Одной из целей сервис-ориентированной архитектуры является обеспечение реакции на такое подвижное, деятельное видение предприятия путем формирования предложений с обоснованной ценностью для бизнеса. Предприятие не реализует SOA по принципу «все сразу», т.к. существует потребность в постепенных стратегиях внедрения, которые решают следующие вопросы:

- составление экономического обоснования внедрения архитектуры;

- оценка имеющихся технологий;

- выбор пилотного энергетического бизнес-проекта и стороны бизнеса;

- распространение в масштабе предприятия;

- распространение в сети партнеров.

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

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

Характеристики определяют, как разные домены взаимодействуют друг с другом. К ним относятся: платформа, местоположение, протоколы, язык программирования, структура вызова, безопасность, управление версиями служб, модель служб, информационная модель, формат данных.

Для служб предприятия общими являются все или часть этих характеристик, и они влияют на то, какие действия выполняет служба, как она их выполняет. В [10] выделены следующие четыре архитектурных домена с субдоменами, которые влияют на то, где может существовать служба и какие функции она может выполнять:

- домен инфраструктурных служб с субдоменами;

- бизнес-службы утилиты;

- автоматизация на уровне служб и оркестровка;

- виртуализация ресурсов;

- домен промежуточного программного обеспечения;

- домен бизнес-служб;

- домен прикладных служб с субдоменами:

- субдомен модели прикладного программирования;

- субдомен готового коммерческого программного обеспечения;

- субдомен управления информацией.

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

В общем виде SOA предполагает наличие трех основных участников: поставщика сервиса, потребителя сервиса и реестра сервисов (рис.11.1). Взаимодействие участников выглядит достаточно просто: поставщик сервиса регистрирует свои сервисы в реестре, а потребитель обращается к реестру с запросом. Отсутствие любого из этих элементов недопустимо, а добавление других составляющих на практике не только возможно, но и неизбежно. Среди таких элементов могут быть всевозможные программные средства промежуточного слоя, контролирующие порядок и контекст взаимодействия, осуществляющие мониторинг и управление сервисами, а также управление метаданными и другие вспомогательные процессы.

Для использования сервиса необходимо следовать соглашению об интерфейсе для обращения к сервису - интерфейс должен не зависеть от платформы. SOA реализует масштабируемость сервисов – возможность добавления сервисов, а также их модернизацию. Поставщик сервиса и его потребитель оказываются несвязанными - они общаются с помощью сообщений.

 

 

Рис.11.1. Общая схема SOA

 

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

Модель SOA не зависит от технологий, использующихся для реализации SOA, а основным методологически значимым ее компонентом является реестр сервисов. В обозначенном на схеме асинхронном протоколе общения провайдера и потребителя сервисов он выполняет функции посредника.

Провайдер размещает информацию о своих сервисах в реестре, что дает возможность потребителю в любой момент найти необходимый ему сервис. За этим процессом общения скрывается основное качество SOA – слабая связанность. Благодаря этому свойству сервисы обретают мобильность, способность перемещаться с одного сервера на другой, не требуя согласования и координации со всеми потребителями.

Естественно, что потребители сервисов в ряде случаев не способны и не должны принимать во внимание регулярное перераспределение ресурсов, обеспечивающих функционирование сервисов. Позднее связывание также позволяет отложить момент конечной сборки связей до времени исполнения, а не времени разработки программы, что характерно для традиционных монолитных систем. Можно также во время исполнения менять параметры связи (такие как адрес, протокол и канал взаимодействия). Это придает несколько измерений гибкости самой связке между провайдером и потребителем сервиса, соответственно вызываемым и осуществляющим вызов объектами. В частности, провайдер и потребитель могут исполняться на сколь угодно физически удаленных инфраструктурах.

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

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

Одной из отличительных черт SOA является наличие контрактов, описывающих интерфейсы сервисов. Такой контракт представляет собой документ, специфицирующий ожидания сервиса по отношению к его потребителям и наоборот. Контракты Web-сервисов описываются WSDL- документом, определяющим в нотации XML, как потребители должны обращаться к сервису. Использование XML на этом этапе имеет принципиальное значение, позволяя и провайдеру, и потребителю сервиса не зависеть от определенной платформы.

Технические контракты, формулируемые провайдером сервисов, должны быть доступны потенциальным потребителям для интерпретации, анализа и реализации интеграции. Для этого используется специальный реестр, каталогизирующий доступные сервисы.

2. Сервис-ориентированный анализ и проектирование.Методы анализа и проектирования за последние четыре десятилетия сделали значительный шаг в развитии. Последние разработки связаны с моделированием и использованием метаданных в качестве основы для методов и инструментов, удовлетворяющих широкому диапазону задач, от моделирования бизнес-процессов до автоматизированной генерации исполняемого программного обеспечения.

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

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

 

Таблица 11.1. Мероприятия по обеспечению сервис-ориентированного моделирования

Роль

Проводимые мероприятия

Потребитель

Идентифи-кация сервиса

Катего-ризация

сервиса

Решения по

раскрытию

сервиса

Хореография или

композция

Качество

обслуживания

Поставщик

Идентифи-кация

компонета

Спецификация

компонента

Реализация

сервиса

Управление

сервисом

Реализация

стандартов

 

Привязка

сервиса к

компонентам

Разбиение SOA на уровни

Создание

технического

 прототипа

Выбор продукта

Архитектурные решения

 

Поставщику в данном случае необходимо опубликовать сервисы, которые он желает поддерживать, как с позиций функциональности, так и с позиций обеспечения требуемого качества обслуживания (QОS). Это неявно выраженное соглашение между поставщиком и потребителем могло бы сформироваться в явно выраженные условия соглашений об уровне услуг (SLA), установленные или электронным способом или путем подписания юридических документов.

Мероприятия, описанные выше, можно отобразить в виде потоков в сервис-ориентированном моделировании и архитектурном методе, как это показано на рис. 11.2 [5].

Процесс сервис-ориентированного моделирования и построения архитектуры состоит из трех основных шагов: идентификации, спецификации и реализации сервисов, компонентов и потоков (обычно путем объединения сервисов).

1) Идентификация сервиса. Данный процесс состоит из комбинации нисходящих, восходящих и исходящих методик декомпозиции сферы влияния (домена), анализа существующих средств и моделирования задач, и средств для ее решения, а также моделирования сервисов.

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

 

 

Рис. 11.2. Метод сервис-ориентированного моделирования и архитектуры

 

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

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

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

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

Анализ подсистемы заключается в создании моделей объекта для представления внутренних выработок и конструкций подсистем, раскрывающих и анализирующих сервисы. Проектная конструкция "подсистемы" впоследствии реализуется, как конструкция реализации крупного структурного компонента, реализующего сервисы в данном мероприятии.

2) Спецификация компонента. В этом важном мероприятии определяются следующие детали компонента, реализующего сервисы: данные, правила, сервисы, настраиваемый профиль, вариации. Здесь также задаются спецификации обмена сообщениями, спецификации событий и дается определение управления.

3) Размещение сервиса. Размещение сервиса заключается в распределении сервисов по подсистемам, которые уже были идентифицированы. В этих подсистемах присутствуют корпоративные компоненты, реализующие их опубликованную функциональность.

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

Первая модель управления обычно выполняет сортировку событий, концентрируясь на приеме событий и направлении их в соответствующие группы сортировки для решения. Сортировочная модель управления может эволюционировать в следующий уровень - модель решения элементарных проблем за короткое время, еще до передачи сведений о событиях. Независимо от модели управления работа большинства центров управления IT направляется событиями, которые запускают выполнение действий. Это могут быть события Tivoli Event Console™ или новые уведомления об ошибках (trouble tickets), создаваемые функциями автоматизации-интеграции. Эти системы также могут устанавливать приоритет событий, определять временную последовательность, приоритет, влияние на бизнес и географию.

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

Более высокий уровень IT-управления - это операции, направляемые бизнес-службами. Главная проблема управления на этом уровне заключается в понимании бизнес-служб и их компонентов.

Основные области IT-управления в SOA показаны на рис. 11.3.

 

 

Рис. 11.3. Ключевые области управления SOA

 

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