Как вы, возможно, заметили, мне настолько нравится протокол WAMP, что я даже написал пару его имплементаций на JS и LUA. Но сейчас мне хочется порассуждать на тему использования WAMP в качестве основы для информационных систем (далее ИС), построенных по принципу SOA.
Для начала, скажу пару слов про SOA для тех, кто не очень знаком с этим термином. Итак, SOA, Service Oriented Architecture, или же по-русски сервисно-ориентированная архитектура — это не фреймворк, не протокол, не приложение, а архитектурный подход к разработке программного обеспечения, который основывается на следующих принципах:
- Сервисно-ориентированность. Основной единицей является сервис. Это логически обособленный программный модуль, который выполняет конкретную повторяющуюся бизнес-функцию из всего бизнес-процесса предприятия. Например, сервис отправки емейл-уведомлений.
- Сервисные контракты (интерфейсы). Доступ к сервисам осуществляется через четко определенные интерфейсы, которые являются платформо и языково независимыми и используют открытые стандарты.
- Слабое связывание компонентов. Сервисы могут быть связаны между собой только по средством интерфейсов, и все что сервисы знают про друг друга — это то, что они есть.
- Абстракция. Сервисы для внешнего мира выглядят как черные ящики, то есть они скрывают свою внутреннюю реализацию и предоставляют только интерфейсы для обращений к себе из вне.
- Автономность. Еще раз повторюсь, что каждый сервис — это логически завершенная единица, и каждый сервис выполняет заложенную в него бизнес-логику не прибегая к какой-либо помощи из вне. Это не исключает возможность обращения сервиса к другим сервисам, так как это может быть частью этой самой бизнес-логики.
- Повторное использование. Нет смысла делать сервис, который выполняет одну маленькую бизнес-функцию, которая используется в каком-то одном конкретном месте. В сервисы имеет смысл выносить какие-то бизнес-функции, которые могут быть задействованы в разных бизнес-процессах. Тот же сервис оповещения по емейл может использоваться как для оповещения клиентов, так и менеджеров.
- Statelessness. Сервисы не хранят состояния между вызовами.
- Обнаружение сервисов. О каждом сервисе, входящем в состав ИС, известно его общедоступное месторасположение и интерфейс взаимодействия. Так же сюда стоит отнести возможность легкого динамического подключения сервисов во время работы ИС.
На современном предприятии может одновременно существовать даже несколько сложных информационных систем, которые рано или поздно должны будут взаимодействовать друг с другом и в итоге превратятся в одно информационное пространство предприятия. И вероятнее всего, бизнес-процессы в разных департаментах или направлениях имеют схожее устройство и некоторые одинаковые бизнес-функции. Именно в таких случаях использование сервисно-ориентированного подхода может дать наибольшую выгоду.
Вот как может выглядеть архитектура ИС, построенной по принципам SOA.
Важным элементом, без которого не обходится ни одна ИС, основанная на СОА, является сервисная шина предприятия (ESB, Enterprise Service Bus). Все сервисы так или иначе обмениваются информацией между собой. Обычно, это устроено по средством отправки сообщений. В большой ИС потоки сообщений могут доходить до сотен и тысяч в секунду. Так вот, основная и главная задача сервисной шины — это доставлять сообщения адресатам.
Другим, не менее важным элементом ИС является реестр сервисов. Его задача — предоставление данных о сервисах. Он необходим как разработчикам на этапе проектирования и построения новых сервисов, так и во время функционирования системы для взаимодействия с сервисами.
Среди прочих элементов ИС можно отметить:
- Workflow Engine, задачей которого является управление бизнес-процессами.
- Service Broker, который занимается управлением сервисами, анализом и запуском зависимостей, и который плотно взаимодействует с реестром сервисов.
- Супервизор, который занимается мониторингом работоспособности и доступности сервисов, а так же отслеживанием запросов во внешние ИС.
Но эти элементы не являются обязательными. И продемонстрированы в качестве примера СОА ИС, построенной на базе технологического стэка Oracle SOA Suite.
Чтобы приступить к реализации СОА, необходимо, чтобы были определены и описаны бизнес-процессы, проанализировав которые можно было бы найти схожие задачи, которые стоит выносить в сервисы и только затем приступать к написанию программных модулей.
Цель сервисно-ориентированной архитектуры — это предоставление потребителям возможности вызывать сервисы, опубликованные провайдерами. Потребителями являются какие-либо клиентские приложения, а под провайдерами подразумеваются обычно информационные системы в целом.
Выбор технической основы и стандартов, на которых будет базироваться ИС так же имеет большое значение. В энтерпрайз мире уже давно и прочно доминирует Java и стандарты, так или иначе, базирующиеся на XML, такие как WSDL, SOAP, BPEL, WS-Security и прочие. Но SOA являясь архитектурным паттерном, не регламентирует использование конкретных технологий. Поэтому в качестве технической базы могут использоваться любые стандарты, удовлетворяющие требованиям:
- Открытость стандарта.
- Независимость от языка, платформы, операционной системы.
Сейчас, по большей части, SOA у многих ассоциируется с Enterprise системами, Java, тоннами XML-кода во всех его ипостасях (WSDL/SOAP/WS-*), но никто не мешает нам проектировать наши веб-ориентированные приложения основываясь на SOA. И вот здесь на сцену выходит WAMP. Это открытый протокол, уже есть множество его имплементаций на разных языках. Давайте посмотрим, как базовые компоненты SOA можно соотнести с компонентами WAMP.
| SOA | WAMP | |
| Сервис | ⬌ | Программный модуль, который регистрирует в рамках домена на WAMP-роутере одну или несколько процедур, которые могут быть вызваны клиентскими приложениями. |
| Вызов потребителем некоторого сервиса | ⬌ | вызов RPC, зарегистрированной на WAMP-роутере. При этом WAMP-роутер скрывает от потребителя конечное месторазмещение сервиса, нет необходимости жестко прописывать адрес сервиса, все что нужно знать — это название хранимой процедуры, которое уникально в рамках всего домена. |
| Реестр сервисов | ⬌ | WAMP роутер обладет всей информацией о зарегистрированных подписчиках, провайдерах RPC и вообще всех клиентах, подключенных к домену. В рамках расширенного профиля описано, как можно получить подробную информацию о зарегистрированных процедурах. |
| Отправка клиентом сообщений, без необходимости подтверждения | ⬌ | Публикация сообщений в определенный топик, на который подписывается некоторый сервис, например логер, который их обрабатывает. |
| Авторизация и прозрачная работа с несколькими сервисами в рамках системы | ⬌ | В WAMP неймспейсом является домен, и можно провести авторизацию клиентов для какого-либо взаимодействия с доменом. После успешной авторизации клиент может обращаться к любым сервисам без необходимости повторной авторизации. |
| Мониторинг сервисов | ⬌ | В рамках расширенного профиля описана возможность, как получать разную мета-информацию в runtime: это и подписка/отписка клиентов от топика, и публикация сообщений и прочее. |
Наверное, многих интересует вопрос нагрузки и масштабируемости. По этому поводу скажу следующее. Во-первых, в рамках расширенного профиля в WAMP предусмотрены партиционированные регистрации процедур, это значит, что на роутере сразу несколько провайдеров могут зарегистрировать одну и ту же RPC, а клиент в дальнейшем может указывать как он хочет чтобы процедура была выполнена: на одном провайдере или же на всех сразу, более того, можно указать способ получения результат: агрегированный или же прогрессивный. Во-вторых, вопрос масштабируемости, конечно же, лежит на конкретной имплементации WAMP-роутера. Например, Crossbar.IO, роутер на питоне, из коробки умеет работать в кластере из нескольких узлов. Wiola, роутер на связке Nginx/LUA, в качестве runtime-хранилища использует redis, так что можно запустить несколько узлов, принимающих запросы и вынести отдельно redis-кластер.
В заключении хочется сказать, что прошли те времена, когда на одном сервере, на одном языке можно было написать приложение, которое решало бы все задачи. Системы растут, усложняются, и разные компоненты пишутся с использованием разных технологий для эффективного решения задач, наряду с этим растет и количество пользователей, возрастает нагрузка, и одного сервера уже точно не хватит, каким бы мощным он не был. И WAMP, как мне кажется, очень даже подходит в качестве основы для создания таких разнородных композитных приложений: это открытый, простой и легкий протокол, у него уже есть множество имплементаций как клиентов, так и роутеров на разных языках, и он по своей сути предназначен для решений тех же архитектурных задач, что и SOA.