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

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

Службы взаимодействуют по сети с использованием протокола, такого как REST или SOAP (простой протокол доступа к объектам). Службы слабо связаны , то есть интерфейс службы не зависит от базовой реализации. Разработчики или системные интеграторы могут объединить одну или несколько служб в приложение, не обязательно зная, как реализована каждая служба.

Эта статья представляет собой обзор Java SOA и ключевых характеристик сервис-ориентированной архитектуры, реализованной с использованием веб-сервисов на основе SOAP. Я также вкратце сравню SOA и микросервисы и расскажу о разнице между веб-сервисами на основе RESTful и SOAP в Java.

SOA и веб-сервисы

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

Почему сервис-ориентированная архитектура?

SOA решает три общие задачи предприятия:

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

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

SOA и микросервисы

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

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

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

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

Мэтью Тайсон

Ключевые характеристики SOA

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

Независимо от масштаба или сложности шаблон сервис-ориентированной архитектуры более или менее одинаков:

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

Реализация сервис-ориентированной архитектуры

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

Мэтью Тайсон

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

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

SOAP vs RESTful веб-службы

Можно принять стиль SOA и реализовать его с помощью REST, например, с помощью JAX-RS API или Spring Boot Actuator, но это обсуждение выходит за рамки данной статьи. См. «SOAP vs REST vs JSON» для полезного сравнения веб-служб SOAP и RESTful. Существует также некоторое совпадение между веб-службами RESTful и более легким стилем, связанным с микросервисами.

Веб-службы на основе SOAP

Веб-сервисы, реализованные с использованием SOAP, по-прежнему более жесткие, чем реализация веб-сервисов или микросервисов RESTful, но гораздо более гибкие, чем первые дни SOA. Здесь мы просто рассмотрим протоколы высокого уровня, необходимые для веб-служб на основе SOAP.

SOAP, WSDL и XSD

SOAP, WSDL и XSD - это фундаментальная инфраструктура реализации веб-службы на основе SOAP. WSDL используется для описания службы, а SOAP - это транспортный уровень для отправки сообщений между потребителями и поставщиками услуг. Службы взаимодействуют с сообщениями, формально определенными с помощью схемы XML (XSD). Вы можете думать о WSDL как о интерфейсе службы (примерно аналогично интерфейсу Java). Реализация выполняется в классах Java, а связь по сети происходит через SOAP. Функционально потребитель будет искать службу, получать WSDL для этой службы, а затем вызывать службу с помощью SOAP.

Безопасность веб-сервисов

Спецификация WS-I Basic Profile 2.0 касается безопасности сообщений. В этой спецификации основное внимание уделяется обмену учетными данными, целостности сообщений и конфиденциальности сообщений.

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

Когда-то краеугольный камень обнаружения веб-сервисов UDDI (универсальное описание, определение и интеграция) ушел в прошлое. Сегодня принято предоставлять веб-службу на основе SOAP так же, как и любую другую службу, через URL-адрес конечной точки. В качестве примера, вы можете использовать JAX-WS Service Endpoint Interface и его @WebServiceи @WebMethodаннотации.

Создание и развертывание веб-сервисов

У разработчиков Java есть несколько вариантов создания и развертывания веб-сервисов на основе SOAP, включая Apache Axis2 и Spring-WS; однако стандартом Java является JAX-WS, Java API для веб-служб XML. Основная идея JAX-WS состоит в том, чтобы создавать классы Java и аннотировать их для создания необходимых артефактов. Под капотом JAX-WS использует несколько пакетов Java, включая JAXB, библиотеку общего назначения для привязки классов Java к XML.

JAX-WS скрывает от разработчика сложность и протоколы, тем самым упрощая процесс определения и развертывания служб SOAP на основе Java. Современные Java IDE, такие как Eclipse, включают полную поддержку разработки веб-сервисов JAX-WS. Спецификация JAX-WS также была выбрана для продолжающейся разработки в Jakarta EE.

Заключение

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

Эта история «Что такое сервис-ориентированная архитектура?» изначально был опубликован JavaWorld.