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

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

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

• 1 Описание
  • 1.1 История
  • 1.2 Текущее состояние
• 2 Основные концепции
  • 2.1 Определение SOA в OASIS
  • 2.2 Сервис
  • 2.3 Пример SOA
  • 2.4 SOA и процессы
• 3 Дополнительные концепции
  • 3.1 Определение эталонной модели OASIS
  • 3.2 Сравнение эталонной модели и эталонной архитектуры
• 4 Ссылки

История

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

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

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

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

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

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

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

Служба

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

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

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

Пример SOA

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

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

SOA и процессы

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

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

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

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

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

.