Метка: SOA

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

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

Всем привет! Ох и давно я ничего не писал в блог — надо это как-то исправлять! А вот тут и повод как раз есть 🙂
В этом году, я, неожиданно, выступил на конференции Highload++, которая проходила 7−8 ноября в Сколково. На конференции я рассказал про протокол WAMP и способы его применения.

WAMP расшифровывается как Web Application Messaging Protocol. Это открытый протокол, реализующий два паттерна в рамках одного протокола: RPC и Publish/Subscribe. Как мне кажется, это отличная платформа для сферы Internet of Things, Smart City и вообще бизнес-приложений с большим количеством различных компонентов и сервисов.

Как активный участник группы разработки самого протокола, а также автор нескольких реализаций на JavaScript (Wampy.js) и Lua (Wiola, Loowy), я рассказал про сам протокол WAMP, его основные концепции и парадигмы, возможные сферы применения, реальные примеры использования, а также про имплементацию WAMP-роутера на базе Nginx/Lua и клиента на чистом Lua, некоторые особенности реализации и публикации.

Продолжить чтение «WAMP как основа композитных SOA-приложений и его имплементация на Lua»
Рубрики
Разработка

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

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

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

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

Философское: from __future__ import web.framework.* или где искать идеальный фреймворк?

JS_FrameworksВ последнее время обсуждали с ребятами текущее положение дел в веб-разработке, современные фреймворки и, конечно же, что будет в будущем. Поэтому решил оформить свои рассуждения на эту тему в виде поста. А спустя сколько-нибудь лет посмотрим, как оно будет на самом деле.

Продолжить чтение «Философское: from __future__ import web.framework.* или где искать идеальный фреймворк?»