Что такое СОА? Принципы сервис-ориентированной архитектуры

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

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

SOA просто упрощает работу программных компонентов в различных сетях друг с другом.

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

Принципы сервис-ориентированной архитектуры (SOA)

Существует 9 типов принципов проектирования SOA, которые упомянуты ниже.

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

Услуги соответствуют описанию услуги. У сервиса должно быть какое-то описание, описывающее, о чем идет речь. Это облегчает клиентским приложениям понимание того, что делает служба.

2. Ослабленная связь

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

3. Абстракция сервиса

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

4. Повторное использование сервиса

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

5. Автономность обслуживания

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

6. Служба безгражданства

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

7. Доступность услуг

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

8. Компонуемость сервисов

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

9. Совместимость сервисов

Услуги должны использовать стандарты, которые позволяют различным абонентам использовать услугу. В веб-сервисах стандарты как XML и связь через HTTP используется для обеспечения соответствия этому принципу.