Эталонная модель OASIS SOA

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

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

Описание

История

Эталонная модель OASIS SOA является продуктом Технического комитета (TC) эталонной модели OASIS SOA (SOA-RM). ^[2] До этой инициативы не существовало стандартного определения SOA. Технический комитет SOA-RM был создан в феврале 2005 года для разработки базовой эталонной модели для руководства и содействия созданию конкретных сервис-ориентированных архитектур, а также для публикации эталонной модели для SOA, а также одной или нескольких эталонных архитектур на основе эталонной архитектуры. Модель. ^[3] Эталонная модель была одобрена членами OASIS в качестве стандарта в октябре 2006 года. ^[4]

Технический комитет OASIS SOA-RM начал работу над сопутствующей эталонной архитектурой во время окончательного периода утверждения эталонной модели, а Фонд эталонной архитектуры OASIS для сервис-ориентированной архитектуры (SOA-RAF) ^[5] был одобрен в качестве спецификации комитета OASIS в декабре 2012 года.

Хотя эталонная модель OASIS SOA получила одобрение в некоторых кругах, ^[6] многочисленные другие усилия по спецификации SOA ^[7]^[8] также обсуждались в период разработки SOA-RAF. Совместные усилия по «гармонизации» отдельных усилий были начаты с OASIS , The Open Group и Object Management Group (OMG) в период 2008-2009 годов. Хотя дискуссии выявили очевидную общность, гармонизация в то время была недостижима, и конечным продуктом стал совместный документ «Навигация по ландшафту открытых стандартов SOA вокруг архитектуры». ^[9] опубликовано в июле 2009 года. Кроме того, Приложение C к SOA-RAF содержит краткое изложение других усилий по стандартизации SOA. Дискуссии продолжаются и по настоящее время. Ниже (и в самом SOA-RM) обсуждается, как несколько эталонных архитектур могут быть получены из одной эталонной модели.

Текущий статус

ТК SOA-RM остается активным и продолжает обсуждение таких тем, как детализация сервисов и интерфейсов. В результате этих обсуждений могут возникнуть дополнительные замечания Комитета.

Основные понятия

Определение SOA в OASIS

Согласно спецификации SOA-RM, SOA — это парадигма организации и использования распределенных возможностей, которые могут находиться под контролем разных доменов владения. Он обеспечивает единые средства для предложения, обнаружения, взаимодействия и использования возможностей для достижения желаемых эффектов в соответствии с измеримыми предварительными условиями и ожиданиями. Спецификация SOA-RM основывает свое определение SOA на концепции «потребностей и возможностей», где SOA обеспечивает механизм сопоставления потребностей потребителей услуг с возможностями, предоставляемыми поставщиками услуг.

Услуга

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

Ниже приведены основные понятия, которые эталонная модель определяет в отношении сервисов. Видимость, Взаимодействие и Эффект реального мира касаются динамических аспектов сервисов (взаимодействия с сервисами), тогда как остальные концепции касаются статических аспектов:

Описание услуги: Информация, необходимая для использования или рассмотрения возможности использования услуги. Целью описания является облегчение взаимодействия и прозрачности между участниками взаимодействия служб, особенно когда участники находятся в разных доменах владения.
Видимость: возможность для тех, у кого есть потребности, и для тех, у кого есть возможности, взаимодействовать друг с другом. Видимость включает не только наличие услуги, но также наличие достаточных знаний потребителя о поставщике и знания поставщика о потребителе, чтобы между сторонами была установлена готовность инициировать или продолжать взаимодействие. Обычно это делается путем предоставления описаний таких аспектов, как функции и технические требования, соответствующие ограничения и политики, а также механизмы доступа или реагирования.
Взаимодействие: относится к взаимодействию между поставщиками услуг и потребителями. Взаимодействие, обычно опосредованное обменом сообщениями, происходит через серию обменов информацией и вызываемых действий. Результатом взаимодействия является эффект реального мира.
Эффект реального мира: Фактический результат использования услуги. Это может быть возврат информации или изменение состояния сущностей (известных или неизвестных), участвующих во взаимодействии.
Контекст исполнения: набор технических и бизнес-элементов, которые образуют путь между теми, у кого есть потребности, и теми, у кого есть возможности, и которые устанавливают условия, при которых поставщики услуг и потребители будут взаимодействовать. Все взаимодействия основаны на определенном контексте выполнения, который позволяет поставщикам услуг и потребителям взаимодействовать и обеспечивает точку принятия решения для любых политик и контрактов, которые могут быть в силе.
Контракт и политика: Политика представляет собой некоторое ограничение или условие использования, развертывания или описания принадлежащего объекта, как это определено любым участником, тогда как контракт представляет собой соглашение между двумя или более сторонами. Эталонная модель ориентирована в первую очередь на концепцию политик и контрактов применительно к услугам.

Пример SOA

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

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

SOA и процессы

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

Вторичные понятия

Определение эталонной модели OASIS

Согласно спецификации SOA-RM, эталонная модель — это абстрактная структура для понимания существенных взаимосвязей между объектами некоторой среды. Это позволяет разрабатывать конкретные эталонные или конкретные архитектуры с использованием согласованных стандартов или спецификаций, поддерживающих эту среду. Эталонная модель состоит из минимального набора объединяющих концепций, аксиом и отношений внутри конкретной проблемной области и не зависит от конкретных стандартов, технологий, реализаций или других конкретных деталей. Таким образом, эталонная модель SOA представляет собой абстрактную структуру для понимания существенных взаимосвязей между объектами SOA.

Эталонная модель против эталонной архитектуры

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

Ссылки

^ «Эталонная модель OASIS для сервис-ориентированной архитектуры 1.0, официальный стандарт OASIS (нормативный PDF), 12 октября 2006 г.» (PDF) .
^ «Эталонная модель OASIS SOA TC» . ОАЗИС . Проверено 5 февраля 2015 г.
^ Никалл, Дуэйн (4 января 2006 г.). «Зачем нам нужна эталонная модель OASIS SOA» . Слабо связанный . Проверено 5 февраля 2015 г.
^ «Члены OASIS одобряют эталонную модель SOA» . Сетка сегодня . 30 октября 2006 г. Архивировано из оригинала 27 сентября 2007 г.
^ «Фонд эталонной архитектуры OASIS для сервис-ориентированной архитектуры, версия 1.0, спецификация комитета 01 (авторитетный PDF), 4 декабря 2012 г.» (PDF) .
^ Рассмотрение эталонной модели SOA, часть 1 , Рассмотрение эталонной модели SOA, часть 2.
^ Линтикум, Дэйв (4 февраля 2007 г.). «Открытая группа обсуждает эталонную архитектуру SOA...» Infoworld . Архивировано из оригинала 7 июня 2007 года.
^ Литтл, Марк (21 февраля 2007 г.). «Тсс… есть эталонная модель SOA? Хотите еще одну?» . ИнфоQ . Проверено 5 февраля 2015 г.
^ «Навигация по ландшафту открытых стандартов SOA в архитектуре», совместный документ The Open Group, OASIS и OMG, июль 2009 г.» (PDF) .

[1] «Эталонная модель OASIS для сервис-ориентированной архитектуры 1.0, официальный стандарт OASIS (нормативный PDF), 12 октября 2006 г.» (PDF) .

[2] «Эталонная модель OASIS SOA TC» . ОАЗИС . Проверено 5 февраля 2015 г.

[3] Никалл, Дуэйн (4 января 2006 г.). «Зачем нам нужна эталонная модель OASIS SOA» . Слабо связанный . Проверено 5 февраля 2015 г.

[4] «Члены OASIS одобряют эталонную модель SOA» . Сетка сегодня . 30 октября 2006 г. Архивировано из оригинала 27 сентября 2007 г.

[5] «Фонд эталонной архитектуры OASIS для сервис-ориентированной архитектуры, версия 1.0, спецификация комитета 01 (авторитетный PDF), 4 декабря 2012 г.» (PDF) .

[6] Рассмотрение эталонной модели SOA, часть 1 , Рассмотрение эталонной модели SOA, часть 2.

[7] Линтикум, Дэйв (4 февраля 2007 г.). «Открытая группа обсуждает эталонную архитектуру SOA...» Infoworld . Архивировано из оригинала 7 июня 2007 года.

[8] Литтл, Марк (21 февраля 2007 г.). «Тсс… есть эталонная модель SOA? Хотите еще одну?» . ИнфоQ . Проверено 5 февраля 2015 г.

[9] «Навигация по ландшафту открытых стандартов SOA в архитектуре», совместный документ The Open Group, OASIS и OMG, июль 2009 г.» (PDF) .

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]