Сервис-Ориентированная Архитектура - Service-oriented architecture

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

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

Согласно одному из многих определений SOA, служба имеет четыре свойства:

  1. Он логически представляет собой повторяемую бизнес-деятельность с заданным результатом.
  2. Он самодостаточен.
  3. Это черный ящик для своих потребителей, то есть потребитель не должен знать о внутренней работе службы.
  4. Он может состоять из других сервисов.

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

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

Обзор

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

Определение понятий

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

В октябре 2009 г. был опубликован манифест по сервис-ориентированной архитектуре. В нем были сформулированы шесть основных ценностей, которые перечислены ниже:

  1. Ценности бизнеса придается большее значение, чем технической стратегии.
  2. Стратегическим целям придается большее значение, чем выгодам, связанным с конкретным проектом.
  3. Внутренняя совместимость имеет большее значение, чем индивидуальная интеграция.
  4. Совместно используемым службам придается большее значение, чем реализациям для конкретных целей.
  5. Гибкости уделяется больше внимания, чем оптимизации.
  6. Эволюционному совершенствованию придается большее значение, чем стремлению к изначальному совершенству.

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

Принципы

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

Стандартный договор на обслуживание
Службы соответствуют стандартному соглашению о взаимодействии, как определено в совокупности одним или несколькими документами с описанием службы в рамках данного набора служб.
Автономность ссылок на сервисы (аспект слабой связи)
Взаимосвязь между сервисами сведена к минимуму до уровня, на котором они знают только о своем существовании.
Прозрачность местоположения службы (аспект слабой связи)
Сервисы можно вызывать из любого места в сети, где бы они ни находились.
Долговечность службы
Услуги должны быть долговечными. Там, где это возможно, службы должны избегать принуждения потребителей к изменению, если им не требуются новые функции. Если вы позвоните в службу сегодня, вы сможете позвонить в ту же службу завтра.
Абстракция службы
Сервисы действуют как черные ящики, то есть их внутренняя логика скрыта от потребителей.
Автономность обслуживания
Сервисы независимы и контролируют инкапсулируемые ими функциональные возможности как во время разработки, так и во время выполнения.
Безгражданство услуги
Службы не имеют состояния, то есть либо возвращают запрошенное значение, либо выдают исключение, что сводит к минимуму использование ресурсов.
Детализация сервиса
Принцип обеспечения адекватного размера и объема услуг. Функциональность, предоставляемая сервисом пользователю, должна быть актуальной.
Нормализация обслуживания
Сервисы декомпозируются или консолидируются (нормализуются) для минимизации избыточности. В некоторых случаях это невозможно. Это те случаи, когда требуются оптимизация производительности, доступ и агрегирование.
Возможность компоновки сервисов
Сервисы можно использовать для создания других сервисов.
Обнаружение службы
Сервисы дополняются коммуникативными метаданными, с помощью которых они могут быть эффективно обнаружены и интерпретированы.
Возможность многократного использования сервиса
Логика разделена на различные службы, чтобы способствовать повторному использованию кода.
Инкапсуляция службы
Многие сервисы, которые изначально не планировались в рамках SOA, могут быть инкапсулированы или стать частью SOA.

Узоры

Каждый строительный блок SOA может играть любую из трех ролей:

Поставщик услуг
Он создает веб-службу и предоставляет информацию о ней в реестр служб. Каждый провайдер обсуждает множество способов и причин, например, какую услугу предоставить, чему придать большее значение: безопасность или легкая доступность, какую цену предложить услугу и многое другое . Провайдер также должен решить, в какую категорию должна быть включена услуга для данной брокерской услуги и какие соглашения с торговыми партнерами необходимы для использования услуги.
Брокер сервисов, реестр сервисов или репозиторий сервисов
Его основная функция - сделать информацию о веб-сервисе доступной любому потенциальному заказчику. Тот, кто внедряет брокера, определяет объем брокера. Публичные брокеры доступны везде и везде, но частные брокеры доступны только ограниченному кругу людей. UDDI был ранней, более активно не поддерживаемой попыткой предоставить обнаружение веб-сервисов .
Заказчик услуг / потребитель
Он находит записи в реестре брокера с помощью различных операций поиска, а затем связывается с поставщиком услуг, чтобы вызвать одну из своих веб-служб. Какая бы услуга ни была нужна потребителям услуг, они должны передать ее брокерам, связать с соответствующей услугой и затем использовать. Они могут получить доступ к нескольким службам, если служба предоставляет несколько служб.

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

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

Подходы к реализации

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

Разработчики обычно создают SOA, используя стандарты веб-сервисов. Одним из примеров является протокол SOAP , который получил широкое признание в отрасли после рекомендации версии 1.2 от консорциума W3C (World Wide Web Consortium) в 2003 году. Эти стандарты (также называемые спецификациями веб-сервисов ) также обеспечивают большую совместимость и некоторую защиту от блокировки. проприетарному программному обеспечению. Однако можно также реализовать SOA, используя любую другую сервисную технологию, такую ​​как Jini , CORBA , Internet Communications Engine , REST или gRPC .

Архитектуры могут работать независимо от конкретных технологий и, следовательно, могут быть реализованы с использованием широкого спектра технологий, включая:

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

Эти службы взаимодействуют на основе формального определения (или контракта, например, WSDL), которое не зависит от базовой платформы и языка программирования. Определение интерфейса скрывает реализацию языковой службы. Таким образом, системы на основе SOA могут функционировать независимо от технологий и платформ разработки (таких как Java, .NET и т. Д.). Например, службы, написанные на C #, работающие на платформах .NET, и службы, написанные на Java, работающие на платформах Java EE , могут использоваться общим составным приложением (или клиентом). Приложения, работающие на любой платформе, также могут использовать сервисы, работающие на другой платформе, как веб-сервисы, которые облегчают повторное использование. Управляемые среды также могут объединять устаревшие системы COBOL и представлять их как программные услуги. .

Языки программирования высокого уровня, такие как BPEL, и спецификации, такие как WS-CDL и WS-Coordination, расширяют концепцию сервиса, предоставляя метод определения и поддержки оркестровки мелкозернистых сервисов в более грубые бизнес-сервисы, которые архитекторы могут, в свою очередь, включать в рабочие процессы и бизнес-процессы, реализованные в составных приложениях или порталах .

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

Элементы SOA, Дирк Крафциг, Карл Бэнке и Дирк Слама
Мета-модель SOA, Linthicum Group, 2007 г.

Организационные преимущества

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

Идея SOA заключается в том, что организация может взглянуть на проблему целостно. Бизнес имеет более полный контроль. Теоретически не может быть массы разработчиков, использующих любые наборы инструментов, которые им понравятся. Скорее они будут кодировать в соответствии со стандартом, установленным в бизнесе. Они также могут разрабатывать корпоративную SOA, инкапсулирующую бизнес-ориентированную инфраструктуру. SOA также была проиллюстрирована как система автомагистралей, обеспечивающая эффективность для водителей автомобилей. Дело в том, что если бы у всех была машина, но нигде не было бы шоссе, все было бы ограничено и дезорганизовано в любой попытке добраться куда-нибудь быстро или эффективно. Вице-президент IBM по веб-службам Майкл Либоу говорит, что SOA «строит дороги».

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

Служба представляет собой автономную функциональную единицу, доступную только через формально определенный интерфейс. Услуги могут быть своего рода «нанопредприятиями», которые легко производить и улучшать. Также сервисы могут быть «мегакорпорациями», построенными как слаженная работа подчиненных сервисов.

Причины для рассмотрения реализации услуг как отдельных проектов от более крупных:

  1. Разделение продвигает бизнес-концепцию о том, что услуги могут быть предоставлены быстро и независимо от более крупных и медленных проектов, типичных для организации. Бизнес начинает понимать системы и упрощенные пользовательские интерфейсы, вызывающие сервисы. Это способствует ловкости . Другими словами, он способствует развитию бизнес-инноваций и сокращает время вывода продукта на рынок.
  2. Разделение способствует отделению услуг от потребляющих проектов. Это способствует хорошему дизайну, поскольку услуга разрабатывается без знания того, кто ее потребители.
  3. Документация и тестовые артефакты службы не встраиваются в детали более крупного проекта. Это важно, когда сервис необходимо повторно использовать позже.

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

Примеры могут оказаться полезными для помощи в документировании услуги до уровня, на котором она станет полезной. Документация по некоторым API в рамках процесса сообщества Java предоставляет хорошие примеры. Поскольку они являются исчерпывающими, сотрудники обычно используют только важные подмножества. Примером такого файла является файл ossjsa.pdf в JSR-89 .

Критика

SOA была объединена с веб-сервисами ; однако веб-службы - это лишь один из вариантов реализации шаблонов, составляющих стиль SOA. В отсутствие собственных или двоичных форм удаленного вызова процедур (RPC) приложения могут работать медленнее и требовать большей вычислительной мощности, что увеличивает затраты. Большинство реализаций несут эти накладные расходы, но SOA можно реализовать с использованием технологий (например, Java Business Integration (JBI), Windows Communication Foundation (WCF) и службы распределения данных (DDS)), которые не зависят от удаленных вызовов процедур или трансляции через XML или JSON. В то же время появляющиеся технологии синтаксического анализа XML с открытым исходным кодом (такие как VTD-XML ) и различные XML-совместимые двоичные форматы обещают значительно улучшить производительность SOA.

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

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

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

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

Расширения и варианты

Архитектура, управляемая событиями

Основная статья: Архитектура, управляемая событиями

Интерфейсы прикладного программирования

Основная статья: Интерфейсы прикладного программирования

Интерфейсы прикладного программирования (API) - это фреймворки, через которые разработчики могут взаимодействовать с веб-приложением.

Веб 2.0

Тим О'Рейли ввел термин « Web 2.0 » для описания воспринимаемого, быстро растущего набора веб-приложений. Тема, которая получила широкое освещение, включает отношения между Web 2.0 и сервис-ориентированными архитектурами.

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

Философия Web 2.0 и SOA обслуживает разные потребности пользователей и, таким образом, обнаруживает различия в дизайне, а также в технологиях, используемых в реальных приложениях. Однако по состоянию на 2008 г. варианты использования продемонстрировали потенциал объединения технологий и принципов как Web 2.0, так и SOA.

Микросервисы

Основная статья: Микросервисы

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

Единого общепринятого определения микросервисов не существует. В литературе можно найти следующие характеристики и принципы:

  • мелкозернистые интерфейсы (для независимо развертываемых сервисов),
  • бизнес-ориентированная разработка (например, предметно-ориентированный дизайн ),
  • Архитектуры облачных приложений IDEAL,
  • полиглотное программирование и настойчивость,
  • легкое развертывание контейнера,
  • децентрализованная непрерывная доставка и
  • DevOps с комплексным мониторингом сервисов.

Сервисно-ориентированные архитектуры для интерактивных приложений

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

Смотрите также

использованная литература

Послушайте эту статью ( 54 минуты )
Разговорный значок Википедии
Этот аудиофайл был создан на основе редакции этой статьи от 27 октября 2011 г. и не отражает последующих правок. (2011-10-27)
( Аудио справка  · Больше устных статей )