Рубрики
Разработка

WAMP как основа композитных SOA-приложений

Как вы, возможно, заметили, мне настолько нравится протокол WAMP, что я даже написал пару его имплементаций на JS и LUA. Но сейчас мне хочется порассуждать на тему использования WAMP в качестве основы для информационных систем (далее ИС), построенных по принципу SOA.

Для начала, скажу пару слов про SOA для тех, кто не очень знаком с этим термином. Итак, SOA, Service Oriented Architecture, или же по-русски сервисно-ориентированная архитектура — это не фреймворк, не протокол, не приложение, а архитектурный подход к разработке программного обеспечения, который основывается на следующих принципах:

  • Сервисно-ориентированность. Основной единицей является сервис. Это логически обособленный программный модуль, который выполняет конкретную повторяющуюся бизнес-функцию из всего бизнес-процесса предприятия. Например, сервис отправки емейл-уведомлений.
  • Сервисные контракты (интерфейсы). Доступ к сервисам осуществляется через четко определенные интерфейсы, которые являются платформо и языково независимыми и используют открытые стандарты.
  • Слабое связывание компонентов. Сервисы могут быть связаны между собой только по средством интерфейсов, и все что сервисы знают про друг друга — это то, что они есть.
  • Абстракция. Сервисы для внешнего мира выглядят как черные ящики, то есть они скрывают свою внутреннюю реализацию и предоставляют только интерфейсы для обращений к себе из вне.
  • Автономность. Еще раз повторюсь, что каждый сервис — это логически завершенная единица, и каждый сервис выполняет заложенную в него бизнес-логику не прибегая к какой-либо помощи из вне. Это не исключает возможность обращения сервиса к другим сервисам, так как это может быть частью этой самой бизнес-логики.
  • Повторное использование. Нет смысла делать сервис, который выполняет одну маленькую бизнес-функцию, которая используется в каком-то одном конкретном месте. В сервисы имеет смысл выносить какие-то бизнес-функции, которые могут быть задействованы в разных бизнес-процессах. Тот же сервис оповещения по емейл может использоваться как для оповещения клиентов, так и менеджеров.
  • Statelessness. Сервисы не хранят состояния между вызовами.
  • Обнаружение сервисов. О каждом сервисе, входящем в состав ИС, известно его общедоступное месторасположение и интерфейс взаимодействия. Так же сюда стоит отнести возможность легкого динамического подключения сервисов во время работы ИС.