Что такое SOA?

Многие, читая новости, статьи, книги и т.п., видят аббревиатуру SOA (Service Oriented Architecture – архитектура, ориентированная на оказание услуг). Но найти точное определение данному термину практически невозможно, хотя он достаточно широко используется для придания «веса». Здесь мне хотелось бы немного рассказать о SOA, о том, как я ее понимаю.

Сначала необходимо понять, что такое SO (Service Orientation – ориентация на оказание услуг, сервис для клиента). Тут мы должны понять, что рассматривать SO мы будем с точки зрения бизнеса, а не программирования, т.е. сервис – это предоставление некоторой услуги клиенту, который запрашивает ее у бизнес-единицы. SO – это принцип создания сервисов по оказанию услуг, при котором некоторые бизнес-процессы группируются вместе и имеют единую точку входа (например, дверь в комнату отдела).

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

В соответствии с SO мы изначально можем разбить компанию на следующие отделы: отдел продаж, отдел закупок и склад. Отдел продаж занимается общением с покупателями. Отдел закупок взаимодействует с поставщиками по вопросам приобретения необходимых товаров на склад. Ну а склад (как отдел компании) в свою очередь отвечает за текущее состояние склада, прием и выдачу товаров. Таким образом, мы смогли разбить нашу компанию на отделы, но каждый из отделов выполняет свой набор функций, в том числе взаимодействие с другими отделами.

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



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

1. Первоначально необходимо проверить наличие товаров на складе из списка покупателя. Для этого продавец связывается с работником склада и запрашивает у него необходимую информацию, а в ответ получает скорректированный список товаров в соответствии с их наличием на складе.
   
   
2. Следующим шагом будет согласование цен на товары в наличии с отделом закупок. При этом продавец отправляет работнику отдела закупок список товаров, а в ответ получает цены на них.
   
   
3. Заключительным шагом для продавца будет простановка резерва на складе, для чего он опять воспользуется услугами работника склада, передав ему список необходимых товаров, а в ответ получит список зарезервированных товаров.

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

Теперь вернемся к программированию. Все выше сказанное можно реализовать в программном коде. Но сначала нам необходимо определить некоторые понятия и принципы реализации.

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

Технологии, с помощью которых может быть реализована SOA, могут быть совершенно различные, при этом их выбор делается на основе физического взаимодействия различных компонентов системы. Так для компании, которая работает в рамках одной локальной сети, реализация SOA через веб-сервисы была бы достаточно затратной по скорости работы системы и объемам передаваемой по LAN информации. В данном случае я бы посоветовал при реализации на платформе Windows + .NET воспользоваться Enterprise Services (ES, COM+). Если организация имеет распределенную структуру или имеет место взаимодействие нескольких организаций, то тут логичнее было бы сделать взаимодействие между компонентами в виде веб-сервисов при взаимодействии через границы сетей (LAN <--> WAN <--> LAN).

Итак, каким же принципам должна соответствовать SOA?

1. Отсутствие сохранения состояния при взаимодействии – сервис не должен сохранять внутри себя состояние между вызовами, т.е. любой из методов сервиса можно вызвать независимо от остальных. Это же может относиться и к взаимодействию между сервисами.
   
   
2. Четкое определение доверительных отношений – необходимо четко определить, каким компонентам или системам на сколько мы можем доверять. Если взаимодействие происходит между разными организациями, то это явный признак поставить самый низкий уровень доверия, при котором должна проверяться вся информация. Если компоненты системы взаимодействуют в рамках одной локальной сети только одной организации, то здесь можно поставить самый высокий уровень доверия, говорящий об отсутствии необходимости проверять полученную информацию (за исключением проверки уровня доступа пользователя).
   
   
3. Агрегация – сервис может представлять собой подобие швейцарского ножа, т.е. некоторый универсальный инструмент, который работает с некоторым количеством более простых и специализированных сервисов, разделяя свой запрос и группируя ответы используемых сервисов. Агрегирующий сервис выступает в виде паттерна Facade.
   
   
4. Независимость от протокола взаимодействия – при взаимодействии между уровнями (layer) и между узлами (tier) в большой системе часто необходимо обеспечить независимость от протокола взаимодействия. Для этого используют Enterprise Service Bus (ESB), для которой делают подключение необходимых протоколов передачи данных. Так же используют для взаимодействия с другими компонентами такие паттерны как Business Delegate, Remote Proxy, Adapter, Broker, Factory и другие.
   
   
5. Автономность – недоступность другого сервиса не должна фатально отражаться на работоспособности системы в целом. Это можно реализовать путем реализации некоторых принципов Smart Client для обеспечения автономности: кэширование данных сервиса на клиентской стороне, при недоступности сервиса сохранение запросов в очереди, которая передается сервису при его доступности.
   
   
6. Слабая связанность – клиент не должен зависеть от сервиса в случае модификации сервиса. Это можно обеспечить путем позднего связывания в процессе выполнения и/или передачей атрибутов вызова с версионностью каждого сложного атрибута, а так же использованием паттернов: Remote Proxy, Adapter, Broker.
   
   
7. Определение и регистрация сервисов – информация о списке сервисов, его методах и местоположении должна быть доступна в виде списка, который может храниться в любом доступном источнике и формате данных (БД, XML, UDDI и т.д.). Сервис должен зарегистрировать себя в таком списке, а клиент сервиса должен иметь способ получить необходимую информацию, чтоб можно было вызвать сервис.