Библиотека сайта rus-linux.net
Система обмена сообщениями ZeroMQ
Глава 24 из книги "Архитектура приложений с открытым исходным кодом", том 2.Оригинал: "ZeroMQ".
Автор: Martin Sústrik, перевод: Н.Ромоданов
24.10. Интерфейс API
Пользовательский интерфейс является наиболее важной частью любого продукта. Это единственная часть вашей программы, которая видна внешнему миру, и если вы сделаете ее неправильно, то мир будет ненавидеть вас. В конечном изделии это либо графический интерфейс, либо интерфейс командной строки. В библиотеках - это интерфейс API.
В ранних версиях ØMQ интерфейс API базировался на модели обменов и очередей AMQP (смотрите спецификации AMQP). С исторической точки зрения было бы интересно взглянуть на документ white paper from 2007, в котором делается попытка примирить AMQP с бесброкерной моделью обмена сообщениями. Я потратил окончание 2009 года на его переписывание почти с нуля, чтобы вместо этого использовать интерфейс BSD Socket API. Это был поворотный момент; с этого момента количество применений библиотеки ØMQ взлетело. Если раньше это был нишевый продукт, используемый только горсткой экспертов по сообщениям, то после этого он стал обычным инструментом, удобным для любого. Через год или около того размер сообщества увеличился в десять раз, было реализовано несколько привязок к 20 различным языкам и т.д.
Пользовательский интерфейс определяет восприятие продукта. При практически оставшихся тех же самых функциональных возможностях - просто за счет изменения интерфейса API - ØMQ превратился из продукта уровня «enterprise messaging» (промышленной системы обмена сообщения) в «сетевой» продукт. Иными словами, восприятие изменилось со «сложной части инфраструктуры для крупных банков» на то, что «это помогает мне отправить мое сообщение длиной в 10 байт из приложения A в приложение B».
Усвоенный урок: Разберитесь с тем, каким, как вы хотите, должен быть ваш проект, и проектируйте соответствующий пользовательский интерфейс. Если у вас есть пользовательский интерфейс, который не совпадает с видением проекта, то это является 100% гарантией движения к провалу.
Одним из важных аспектов перехода на интерфейс BSD Sockets API было то, что он не был революционным недавно изобретенным API, а уже существовал и был хорошо известен. На самом деле, интерфейс BSD Sockets API является одним из старейших API, которым сегодня по-прежнему активно пользуются; он восходит к 1983 году и к 4.2BSD Unix. Он широко распространен и стабилен в течение буквально десятилетий.
Вышеуказанный факт дает много преимуществ. Во-первых, это интерфейс API, который известен каждому, поэтому кривая обучения будет до неприличия плоской. Даже если вы никогда не слышали о ØMQ, вы можете создать свое первое приложение через пару минут благодаря тому, что вы можете воспользоваться знаниями о BSD Sockets.
Во-вторых, использование широко распространенного интерфейса API позволяет интегрировать ØMQ с существующими технологиями. Например, представление объектов ØMQ в виде «сокетов» или «дескрипторов файлов» позволяет в одном и том же цикле событий выполнять обработку событий TCP, UDP, конвейеров, файлов и ØMQ. Другой пример: экспериментальный проект по переносу функций, похожих на ØMQ, в ядро Linux оказывается в реализации довольно простым. За счет применения того же самого по концептуальности фреймворка уже сейчас можно пользоваться большей частью инфраструктуры ØMQ.
Третьим и, вероятно, самым главным, является тот факт, что поскольку интерфейс BSD Sockets API выжил в течение почти трех десятилетий несмотря на многочисленные попытки его заменить, это означает, что в нем самом изначально есть нечто. Разработчики BSD Sockets API, намеренно или случайно, приняли правильные проектные решения. Использовав это API, мы можем автоматически воспользоваться этими проектными решениями даже не зная, какими они были и какие проблемы они решали.
Усвоенный урок: Хотя интерес к повторному использованию кода был повышен с незапамятных времен, а позже к нему присоединилось повторное использование щаблонов, важно думать о повторном использовании решений в еще более общем виде. Когда разрабатываете продукт, взгляните на аналогичные продукты. Проверьте, какие не удались, а какие оказались успешными; изучите успешные проекты. Не поддавайтесь синдрому «Здесь ничего не придумано». Повторно используйте идеи, интерфейсы API, концептуальные фреймворки, которые вы посчитаете подходящими. Поступая таким образом, вы позволяете пользователям повторно использовать имеющиеся у них знания. В то же время вы можете избежать технических ловушек даже в случае, если вы на данный момент их не осознаете.
Далее: 24.11. Шаблоны обмена сообщениями