Сервис-ориентированная архитектура
Сервис-ориентированная архитектура (SOA) - это модель разработки программного обеспечения для распределенных прикладных компонентов, которая включает функции обнаружения, контроля доступа, сопоставления данных и безопасности. Есть три основные цели SOA, все из которых направлены на разные этапы жизненного цикла приложения:
- Первая цель направлена на структурирование процедур или программных компонентов как услуг. Эти сервисы предназначены для слабой связи с приложениями, поэтому они используются только при необходимости. Они также предназначены для легкого использования разработчиками программного обеспечения, которым необходимо создавать приложения согласованно.
- Вторая цель - предоставить механизм публикации доступных сервисов, который включает их функциональность и требования к вводу / выводу. Сервисы публикуются таким образом, чтобы разработчики могли легко включать их в приложения.
- Третья цель SOA - контролировать использование этих сервисов, чтобы избежать проблем безопасности и управления. Безопасность в SOA в значительной степени зависит от безопасности отдельных компонентов в рамках архитектуры, процедур идентификации и аутентификации, связанных с этими компонентами, а также от защиты фактических соединений между компонентами архитектуры.
SOA - это широкая архитектурная модель, которая определяет цели приложения, а также подходы, которые будут использоваться для достижения этих целей. Разработчики должны определить конкретные спецификации реализации, обычно связанные с официальными спецификациями языка описания веб-сервисов (WSDL) и протокола SOAP.
Появление SOA
В течение десятилетий разработка программного обеспечения требовала использования модульных функциональных элементов, выполняющих определенную работу в нескольких местах приложения. Поскольку операции интеграции приложений и совместного использования компонентов стали связаны с пулами хостинговых ресурсов и распределенных баз данных, предприятиям был необходим способ адаптировать свою модель разработки на основе процедур к использованию удаленных распределенных компонентов. Простые модели, такие как удаленный вызов процедур (RPC), были началом в правильном направлении, но у RPC отсутствовали функции безопасности и независимые от данных функции, необходимые для действительно открытых и распределенных операций.
Решение этой проблемы состояло в том, чтобы переопределить старую модель работы в более широкий и более четко спроектированный набор сервисов, которые могли бы быть предоставлены приложению с использованием полностью распределенных программных компонентов. Архитектура, которая обернула эти сервисы в механизмы для поддержки открытого использования при полной безопасности и управлении, называлась сервис-ориентированной архитектурой, или SOA. SOA была введена в конце 1990-х годов как набор принципов или требований, а в течение десятилетия возникло несколько приемлемых реализаций.
Модели WS и WSDL
Первоначально реализации SOA основывались на технологиях RPC и объектных брокеров, доступных в районе 2000 года. Но SOA быстро разделился на два лагеря. Первый - это лагерь веб-сервисов (WS), который представляет собой высокоструктурированное и формализованное управление удаленными процедурами и компонентами. Второй - это лагерь передачи состояния представительства (REST), который представляет использование интернет-технологий для доступа к удаленным компонентам приложений.
Модель SOA WS использует WSDL для соединения интерфейсов со службами и SOAP для определения API процедур или компонентов. Принципы WS использовались для связи приложений через корпоративную сервисную шину (ESB), что помогло предприятиям интегрировать свои приложения, обеспечить эффективность и улучшить управление данными.
Целый ряд стандартов WS был разработан и продвинут такими промышленными гигантами, как IBM и Microsoft. Эти стандарты предлагали безопасный и гибкий способ разделения программного обеспечения на серию распределенных частей. Однако модель была сложна в использовании и часто вносила значительные накладные расходы в рабочие процессы, которые проходили между компонентами приложения.
Модель SOA WS никогда не достигала уровней принятия, что предсказывали ее сторонники; на самом деле она столкнулась с другой моделью удаленных компонентов, основанной на Интернет: REST. Интерфейсы прикладных программ (API) RESTful не требовали больших затрат и были просты для понимания. Поскольку интернет все больше интегрируется с приложениями, API-интерфейсы RESTful стали рассматриваться как будущее этого направления.
SOA и микросервисы
Напряженность между SOA как набором принципов и SOA как специфической программной реализацией достигла пика перед лицом виртуализации и облачных вычислений. Сочетание виртуализации и облака побуждает разработчиков программного обеспечения создавать приложения из более мелких функциональных компонентов. Микросервисы, одна из важнейших современных тенденций в области программного обеспечения, стали кульминацией этой модели разработки. Поскольку больше компонентов означает больше интерфейсов и более сложный дизайн программного обеспечения, эта тенденция выявила сложности и недостатки производительности большинства реализаций SOA.
Программные архитектуры на основе микросервисов - это всего лишь модернизированные реализации модели SOA. Программные компоненты разрабатываются как сервисы, предоставляемые через API, как того требует SOA. API-брокер обеспечивает доступ к компонентам и обеспечивает соблюдение правил безопасности и управления. Это также гарантирует существование программных методов для согласования различных форматов ввода / вывода микросервисов для приложений, которые их используют.
Но SOA сегодня так же эффективен, как и при первом появлении. Принципы SOA перенесли нас в облако и поддерживают самые передовые методы разработки облачного программного обеспечения, применяемые сегодня.