Сервис-ориентированная архитектура

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

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

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

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

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

• 1 Обзор
• 2 Определение концепций
• 3 Принципы
• 4 Шаблоны
• 5 Подходы к реализации
• 6 Организационные преимущества
• 7 Критика
• 8 Расширения и варианты
  • 8.1 Архитектуры, управляемые событиями
  • 8.2 Интерфейсы прикладного программирования
  • 8.3 Web 2.0
  • 8.4 Микросервисы
• 9 См. Также
• 10 Ссылки

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

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

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

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

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

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

Стандартизированный контракт на обслуживание

Услуги соответствуют стандартному соглашению о взаимодействии, как определено в совокупности одним или несколькими документами с описанием услуг в рамках данного набора услуг.

Ссылка на услугу автономия (аспект слабой связи)

Взаимосвязь между службами сведена к минимуму до уровня, на котором они знают только о своем существовании.

Прозрачность местоположения службы (аспект слабой связи)

Службы можно вызывать из любого места в сети, где бы они ни находились.

Срок службы

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

Абстракция службы

Службы действуют как черные ящики, которые их внутренняя логика скрыта от потребителей.

Автономность службы

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

Отсутствие состояния службы

Службы являются без состояния, то есть либо вернуть запрошенное значение, либо дать исключение, что минимизирует использование ресурсов.

Гранулярность службы

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

Нормализация сервиса

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

Возможность компоновки сервисов

Сервисы могут использоваться для составления других сервисов.

Обнаружение сервисов

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

Повторное использование службы

Логика разделена на различные службы, чтобы способствовать повторному использованию кода.

Служба инкапсуляция

Многие службы, которые изначально не планировались SOA, может быть инкапсулирован или стать частью SOA.

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

Поставщик услуг

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

Брокер, реестр услуг или репозиторий услуг

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

запросчик / потребитель службы

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

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

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

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

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

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

• веб-службы на основе WSDL и SOAP
• обмен сообщениями, например, с ActiveMQ, JMS, RabbitMQ
• RESTful HTTP с передачей репрезентативного состояния (REST), составляющей его собственный архитектурный стиль на основе ограничений
• OPC-UA
• WCF (реализация веб-служб Microsoft, является частью WCF)
• Apache Thrift
• gRPC
• SORCER

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Web 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 с целостным мониторингом сервисов. 251>См. Также