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

OASIS SOA Reference Model

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

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

Описание

История

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

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

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

Текущее состояние

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

Основные концепции

OASIS определение SOA

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

Служба

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

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

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

Пример SOA

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

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

SOA и процессы

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

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

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

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

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

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


Рекомендации

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