Сервис-ориентированная архитектура (SOA) — это архитектурный паттерн в дизайне компьютерного программного обеспечения, в котором компоненты приложения предоставляют услуги другим компонентам по протоколу связи, обычно по сети. Принципы сервис-ориентации не зависят от какого-либо продукта, поставщика или технологии.
SOA просто облегчает взаимодействие программных компонентов в различных сетях.
Веб-сервисы, построенные в соответствии с архитектурой SOA, стремятся сделать веб-сервис более независимым. Сами веб-сервисы могут обмениваться данными друг с другом, и из-за основополагающих принципов, на которых они создаются, им не нужно никакого человеческого взаимодействия, а также не нужны никакие модификации кода. Это гарантирует, что веб-сервисы в сети могут беспрепятственно взаимодействовать друг с другом.
SOA основана на некоторых ключевых принципах, которые упомянуты ниже
- Стандартизированный договор на обслуживание — Услуги соответствуют описанию услуги. Служба должна иметь какое-то описание, описывающее ее суть. Это облегчает клиентским приложениям понимание того, что делает служба.
- Слабая связь — меньше зависимости друг от друга. Это одна из основных характеристик веб-сервисов, в которой говорится, что между веб-сервисами и клиентом, вызывающим веб-сервис, должно быть как можно меньше зависимостей. Поэтому, если функциональность службы изменяется в любой момент времени, она не должна нарушать работу клиентского приложения или останавливать его работу.
- Сервисная абстракция — Сервисы скрывают логику, которую они инкапсулируют, от внешнего мира. Служба не должна раскрывать, как она выполняет свои функции; оно должно просто рассказать клиентскому приложению о том, что оно делает, а не о том, как оно это делает.
- Повторное использование сервисов — логика разделена на сервисы с целью максимального повторного использования. В любой девелоперской компании повторное использование — большая тема, потому что очевидно, что не нужно тратить время и усилия на создание одного и того же кода снова и снова для нескольких приложений, которые в них нуждаются. Следовательно, после написания кода для веб-службы он должен иметь возможность работать с различными типами приложений.
- Автономность службы — службы должны иметь контроль над логикой, которую они инкапсулируют. Служба знает все о том, какие функции она предлагает, и, следовательно, должна также иметь полный контроль над кодом, который она содержит.
- Служба безгражданства — в идеале, службы должны быть без гражданства. Это означает, что службы не должны скрывать информацию от одного государства к другому. Это должно быть сделано из любого клиентского приложения. Примером может служить заказ, размещенный на сайте покупок. Теперь вы можете иметь веб-сервис, который дает вам цену конкретного элемента. Но если товары добавляются в корзину покупок и веб-страница переходит на страницу, где вы делаете платеж, веб-служба не должна нести ответственность за цену товара, подлежащего передаче на страницу оплаты. Вместо этого это должно быть сделано веб-приложением.
- Обнаружение службы — службы могут быть обнаружены (обычно в реестре служб). Мы уже видели это в концепции UDDI, которая выполняет реестр, который может содержать информацию о веб-сервисе.
- Композиционность услуг — сервисы разбивают большие проблемы на маленькие. Никогда не следует встраивать всю функциональность приложения в один сервис, а вместо этого разбивать сервис на модули, каждый из которых имеет отдельную бизнес-функциональность.
- Функциональная совместимость услуг — Сервисы должны использовать стандарты, которые позволяют различным абонентам использовать сервис. В веб-сервисах используются стандарты, такие как XML и связь по HTTP, чтобы обеспечить его соответствие этому принципу.