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