Недавно вышедшая версия 4.4.0-b6 стала достаточно близким приближением к тому, что мне хотелось бы видеть в финальном релизе 4.4.0. А посему появляется время задуматься о том, что будет дальше...
5. Но вот каким он будет? По крайней мере, это будет OpenSource проект под BSD (или ей подобной) лицензией
Некоторые свои мысли о том, зачем нужен SO5 и что в нем должно быть, я попытался описать здесь.
Приглашаю к обсуждению всех, кто интересуется событийно-ориентированным и/или агентно-ориентированным программированием вообще и SObjectizer-ом в частности. А так же тех, кто пытался, пытается или только еще хочет попытаться создать собственный событийно-ориентированный фреймворк. Хотя бы в порядке обмена опытом.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Приглашаю к обсуждению всех, кто интересуется событийно-ориентированным и/или агентно-ориентированным программированием вообще и SObjectizer-ом в частности. А так же тех, кто пытался, пытается или только еще хочет попытаться создать собственный событийно-ориентированный фреймворк. Хотя бы в порядке обмена опытом.
по поводу отсутствия трэйсов в исключениях:
давно пользую классик (исходники приводил здесь
) для получения backtrace. давно ждал когда бустеры аппрувнут boost:exception... в 1.36 это наконец случилось. выкинул некоторые свои велосипеды и сделал себе следующее:
namespace example {
class exception : public std::exception, public boost::exception
{
public:
/// Type of attached to exception backtrace datatypedef boost::error_info<struct tag_backtrace, debug::backtrace> trace_info;
/// Default constructor push backtrace info
exception()
{
*this << trace_info(debug::backtrace());
}
~exception() throw()
{
}
template <typename T>
boost::shared_ptr<const typename T::value_type> get() const
{
return boost::get_error_info<T>(*this);
}
boost::shared_ptr<const debug::backtrace> trace() const
{
return get<trace_info>();
}
/// default implementation for \c what()char const* what() const throw()
{
return boost::exception::diagnostic_information();
}
};
} // namespace example
наследую классы исключений от базового и в каждом имею backtrace который при соответствующем debug/verbose level'e можно распечатать...
насколько я понял по обсуждениям из ветки где опубликовал сорцы backtrace в винде тоже можно получить stack trace...
Здравствуйте, eao197, Вы писали:
E>Доброго дня!
E>Недавно вышедшая версия 4.4.0-b6 стала достаточно близким приближением к тому, что мне хотелось бы видеть в финальном релизе 4.4.0. А посему появляется время задуматься о том, что будет дальше...
E>А дальше будет SObjectizer
5. Но вот каким он будет? По крайней мере, это будет OpenSource проект под BSD (или ей подобной) лицензией
E>Некоторые свои мысли о том, зачем нужен SO5 и что в нем должно быть, я попытался описать здесь.
E>Приглашаю к обсуждению всех, кто интересуется событийно-ориентированным и/или агентно-ориентированным программированием вообще и SObjectizer-ом в частности. А так же тех, кто пытался, пытается или только еще хочет попытаться создать собственный событийно-ориентированный фреймворк. Хотя бы в порядке обмена опытом.
Пара вопросов по поводу подсистемы обмена сообщениями:
1. Есть ли возможность прикрутить свой собственный движок? Например, ту же упомянутую TibRV (в конце концов, она отлично реализует роутинг и диспетчеризацию).
2. Твоя система сообщений полностью децентрализована, так ведь? Т.е. нет ни global ordering, ни persistence, ни recovery via replay (это главные проблемы TivRV)? Если так, есть какие-то мысли сделать это дело?
3. Каковы характеристики твоей подсистемы? Сколько она может сообщений в секунду прокачать по гигабитной сети, на одном хосте?
4. Насколкьо все завязано на формат сообщений? Можно ли использовать свой формат (скажем, FIX)?
Насчет исключений — посмотри на boost::exception — там есть и стеки, и цепочки
Здравствуйте, zaufi, Вы писали:
Z>наследую классы исключений от базового и в каждом имею backtrace который при соответствующем debug/verbose level'e можно распечатать...
Т.е., если приложение скомпилировано в release и без отладочной информации, то backtrace не будет?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, jazzer, Вы писали:
J>1. Есть ли возможность прикрутить свой собственный движок? Например, ту же упомянутую TibRV (в конце концов, она отлично реализует роутинг и диспетчеризацию).
Нет.
И не понятно -- зачем? Если уже есть движок для диспетчеризации сообщений, то зачем нужен SO?
J>2. Твоя система сообщений полностью децентрализована, так ведь?
Если речь идет о распределенных приложениях, то да -- децентрализована.
J>Т.е. нет ни global ordering, ни persistence, ни recovery via replay
Нет. Если разработчику это нужно, то ему самому придется этим заниматься.
J>Если так, есть какие-то мысли сделать это дело?
Необходимости в этом не было. Поэтому не было и мыслей. Будет необходимость -- будут и мысли и, наверное, реализация.
J>3. Каковы характеристики твоей подсистемы? Сколько она может сообщений в секунду прокачать по гигабитной сети, на одном хосте?
На одном хосте в режиме запрос-ответ (длина запроса 256 байт) ~6200 сообщений в секунду. В асинхронном режиме группами по 100 пакетов -- ~11000, группами по 1000 пакетов -- ~12000 сообщений в секунду. Это на Core2Duo 2GHz, WinXP SP2, VC++ 7.1SP1.
На Gigabit проверю завтра на работе.
J>4. Насколкьо все завязано на формат сообщений? Можно ли использовать свой формат (скажем, FIX)?
Сейчас сильно завязано. Все общение идет по SOP протоколу, который использует свою сериализацию. Можно делать свою сериализацию для собственных типов -- вот как-то так.
Хотя опять же -- инструмент свой, можно повернуть его так, как нужно.
J>Насчет исключений — посмотри на boost::exception — там есть и стеки, и цепочки
Посмотрю.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, zaufi, Вы писали:
Z>>наследую классы исключений от базового и в каждом имею backtrace который при соответствующем debug/verbose level'e можно распечатать...
E>Т.е., если приложение скомпилировано в release и без отладочной информации, то backtrace не будет?
release — будет, но кривое и, возможно, с выпавшими кадрами.
без отладочной информации — а зачем? сейчас же нормальные компиляторы позволяют генерить ее в релизной версии, причем ее можно и положить где-нть рядом и не поставлять в финальном дистрибе.
без нее стек будет выглядеть примерно так:
модуль — адрес
модуль — адрес
...
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
J>>1. Есть ли возможность прикрутить свой собственный движок? Например, ту же упомянутую TibRV (в конце концов, она отлично реализует роутинг и диспетчеризацию).
E>Нет. E>И не понятно -- зачем? Если уже есть движок для диспетчеризации сообщений, то зачем нужен SO?
Ну например, потому что она уже используется в компании. И фраза "мы поставим приблуду поверх проверенной и всем известной тибки" выглядит для бизнеса значительно лучше фразы "мы поставим ваще абсолютно новую приблуду".
Здравствуйте, eao197, Вы писали:
E>На одном хосте в режиме запрос-ответ (длина запроса 256 байт) ~6200 сообщений в секунду. В асинхронном режиме группами по 100 пакетов -- ~11000, группами по 1000 пакетов -- ~12000 сообщений в секунду. Это на Core2Duo 2GHz, WinXP SP2, VC++ 7.1SP1.
E>На Gigabit проверю завтра на работе.
На двух хостах (сервер Core2Duo 2.4GHz, WinXP SP3; клиент Core2Duo 2GHz, WinXP SP2):
— синхронный режим запрос-ответ: ~1600;
— асинхронный режим, группы по 100 пакетов -- ~3500;
— асинхронный режим, группы по 1000 пакетов -- ~13500;
— асинхронный режим, группы по 1100-1300 пакетов -- ~16000..17000;
2jazzer: если не сложно, дай оценку таким цифрам с точки зрения TibcoRV. А то мне пока таких скоростей хватает, но я не знаю, к чему еще можно стремиться.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, jazzer, Вы писали:
J>>>1. Есть ли возможность прикрутить свой собственный движок? Например, ту же упомянутую TibRV (в конце концов, она отлично реализует роутинг и диспетчеризацию).
E>>Нет. E>>И не понятно -- зачем? Если уже есть движок для диспетчеризации сообщений, то зачем нужен SO?
J>Ну например, потому что она уже используется в компании. И фраза "мы поставим приблуду поверх проверенной и всем известной тибки" выглядит для бизнеса значительно лучше фразы "мы поставим ваще абсолютно новую приблуду".
Ну как раз такая постановка вопроса и не очень для меня понятна. Если механизмы диспетчеризации из TibcoRV устраивают, но хочется большего, то можно же создать свою предметно-ориентированную нашлепку над TibcoRV.
А если механизмы диспетчеризации из TibcoRV не устраивают...
В любом случае SO может использоваться только в небольшой части приложения, поскольку SO не налагает сколько-нибудь серьезных требований. Так что в одной части может использоваться TibcoRV, а в другой -- SO.
Ключевой чертой SO является использование диспетчера для предоставления контекста для запуска событий агентов. В SO определяется интерфейс диспетчера, который может быть реализован по разному. Так, в SO есть диспетчер главной нити для Qt -- в нем события агентов, завязанных на этот диспетчер, передаются на главную нить приложения средствами Qt и запускаются на ней же.
Может быть, можно будет реализовать этот интерфейс и для средств диспетчеризации TibcoRV. Только здесь нужно понимать, что придется использовать понятия SO (такие как agent_t, msg_data_t, dispatcher_binding_t, event_data_t). И я не уверен, что они гладко лягут на TibcoRV.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, alsemm, Вы писали:
E>>Недавно вышедшая версия 4.4.0-b6 стала достаточно близким приближением к тому, что мне хотелось бы видеть в финальном релизе 4.4.0. А посему появляется время задуматься о том, что будет дальше... A>Из люопытства заглянул на http://sobjectizer.sourceforge.net/. Создалось противоречивое впечатление о проекте. С одной стороны документация есть, на первый взгляд, добротная — http://sobjectizer.sourceforge.net/docs/so4.4/index.html (зтолько ачем она на русском — не очень понятно), релизы регулярно выходят.
На русском потому, что мой уровень владения английским языком не позволяет писать ее на английском. Уж лучше пусть будет нормальная документация на русском, чем плохая на английском, имхо. Перевести то ее, при желании и необходимости можно будет, а вот улучшить плохую документацию -- вряд ли
A>Вопрос: проектом кто-нибудь пользуется, кроме разаботчиков?
Мне не известно о том, чтобы SObjectizer кем-то использовался в серьезных проектах. Время от времени люди пишут о том, что попробовали и чего-то им не хватило или столкнулись с какой-то проблемой. Но продолжили ли они эксперименты с SObjectizer -- я не знаю.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, alsemm, Вы писали:
A>Вопрос: проектом кто-нибудь пользуется, кроме разаботчиков?
Например, в настоящее время SObjectizer используется в системе тестирования технологических алгоритмов ПО процессорно-релейной централизации, разработанной в лаборатории "БЭМС ТС" БелГУТа.
SObjectizer был выбран как удобный инструмент диспетчеризации для эмуляции полевых устройств и поведения дежурного по станции за АРМ'ом. На тот момент разработчики системы уже использовали C++ как основной и в рамках проекта нужно было решить вопрос с точной генерацией событий и поведением полевых устройств. Агентная модель и инструментарий SObjectizer пришлись как раз кстати.
К слову говоря, выбор был не совсем случайным. Я являюсь разработчиком в Intervale и опыт использования SObjectizer был. С одной стороны было предложено использование именно SObjectizer, с другой стороны было сразу ясно какие преимущества дает такое решение.
Здравствуйте, eao197, Вы писали:
E>Приглашаю к обсуждению всех, кто интересуется событийно-ориентированным и/или агентно-ориентированным программированием вообще и SObjectizer-ом в частности. А так же тех, кто пытался, пытается или только еще хочет попытаться создать собственный событийно-ориентированный фреймворк. Хотя бы в порядке обмена опытом.
Скажи, решена ли проблема контроля загрузки, и как?
E>Негативным проявлением подобной непредсказуемости агентного приложения является ситуация, при которой агенты начинают генерировать друг другу больше сообщений, чем они в состоянии обработать.
Здравствуйте, Кодёнок, Вы писали:
Кё>Скажи, решена ли проблема контроля загрузки, и как?
В рамках текущей версии 4.4 разрешить ее на уровне SObjectizer пока не представляется возможным, т.к. в 4.4 вообще отсутствует такое понятие, как очередь сообщений для одного агента. Поэтому ее решение полностью отдано на откуп прикладному разработчику.
Этому аспекту планируется уделить очень серьезное внимание как раз в будущих версиях, которые пока условно называются SObjectizer5. Мы у себя провели некоторые предварительные обсуждения того, какими средствами можно защищать приложения от неконтролируемого распространения сообщений. Они как раз были описаны в в моих заметках:
* введение ограничений на размеры очередей заявок для отдельных агентов. Лишние заявки просто игнорируются и выбрасываются. Может быть при этом агент сам может указать какие заявки могут выбрасываться;
* выбрасывание повторных сообщений. Например, агент раз в секунду получает периодическое сообщение msg_check_activity. Если из-за загрузки системы он не успел получить предыдущее msg_check_activity (заявка все еще находится в очереди заявок), то новое msg_check_activity игнорируется;
* перенаправление сообщений на других агентов, которые, к примеру, вместо прикладной обработки сообщения сразу отсылают отрицательный ответ отправителю сообщения.
В любом случае, когда такие меры предпринимает сам SObjectizer, это означает, что часть прикладных сообщений будет либо выброшена, либо обработана не так, как это хотел бы пользователь. Следовательно, прикладная программа должна быть создана в расчете на такое поведение. Что, в итоге означает, что само приложение должно предпринимать меры по защите от собственной перегрузки.
Сам я считаю, что контроль загруженности является задачей прикладного программиста. SObjectizer сам по себе не генерирует лишней работы, это прикладная программа эту работу провоцирует. Причем, иногда, совершенно на ровном месте.
Вот совсем недавний пример. Написанный на SObjectizer компонент должен был опрашивать некое устройство раз в пять секунд. Программист для этого завел периодическое таймерное сообщение с темпом пять секунд. По его пришествии производился опрос устройство. Операции опроса так же давался тайм-аут на пять секунд, т.к. предполагалось, что уж за это время ответ от устройства должен быть получен. И так оно и было, пока устройство не начало сбоить. И операция опроса завершалась по истечении пятисекундного тайм-аута.
И произошла классическая ситуация -- таймерные заявки генеряться быстрее, чем они обрабатываются, поскольку операция опроса устройства чуть-чуть длительнее периода генерации заявок.
Причем темп в пять секунд -- это просто огромные цифры по сравнению с другими задачами, на которых используется SObjectizer. И все равно здесь мы умудрились напортачить. А если бы SObjectizer, например, просто выбрасывал "лишние" таймерные заявки, то это бы только замаскировало ошибку разработчика.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Сам я считаю, что контроль загруженности является задачей прикладного программиста. SObjectizer сам по себе не генерирует лишней работы, это прикладная программа эту работу провоцирует. Причем, иногда, совершенно на ровном месте.
Спасибо. Но я не совсем согласен, что это должна быть исключительно задача программиста.
Если сравнивать процессы ОС и актеров (которые сами по себе есть легковесные процессы), то я вижу три вида перегрузки, на которые реакция твоей системы и современной ОС существенно разная:
1. Переполнение стека.
Процессы системы: функция вызывает сама себя два раза подряд (если нет раскрутки хвостовой рекурсии — то одного хватит). Система защищает другие процессы прибиванием процесса, где произошло переполнение стека (если он не обработает исключение).
Актеры: обработчик сообщения шлет сам себе два таких же сообщения. Произойдет зажирание памяти под 100%, другие актеры и вся система — парализованы.
2. Загрузка процессора.
Процессы системы: бесконечный цикл или тяжелые вычисления. Система защищает другие процессы, распределяя время по приоритетам. Другие процессы не будут парализованы.
Актеры: обработчик сообщения делает тяжелое вычисление и шлет сам себе такое же сообщение. Или создает миллион помощников, каждый из которых получает сообщение. Если все актеры равны, то остальные актеры, которых может быть мало — всего 10 000 например, будут парализованы этим миллионом.
3. Зажирание памяти.
Это бесконечное создание новых объектов или актеров. От этого никто не защищает, хотя некоторые ОС (Linux) позволяют выборочно ограничить процессам максимум выделяемой памяти.
В случае с обычными процессами, программист только делит систему на процессы/потоки, и получает готовую приемлемую защиту в пунктах 1 и 2, а в п.3 администратор (или родительский процесс) может хотя бы ограничить вред.
Можно ли в агентно-ориентированной системе сделать такого же рода защиту, чтобы программист (в данном случае тим-лидер или архитектор) только поделил агентов-актеров на некоторые условные модули и подмодули (в смысле что каждый актер принадлежит одному конкретному модулю, хотя связи между ними могут быть произвольные), и затем даже в случае сбоя какого-то модуля, написаного новичком, остальные не были парализованы? Например, сбой в управлении вентиляцией не обязательно должен выводить из строя всю систему здания — охрану, освещение и т.д.
В какого рода контроль загрузки целится SO5, или это еще не решено? В идеале конечно хочется такое же полуавтоматическое распределение ресурсов и защиту, что дают существующие механизмы ОС.
Здравствуйте, Кодёнок, Вы писали:
Кё>Но я не совсем согласен, что это должна быть исключительно задача программиста.
Поскольку ты не одинок в этом мнении, мы и хотим заложить в SO5 средства для защиты от черезмерной загрузки
Кё>1. Переполнение стека. Кё>2. Загрузка процессора. Кё>3. Зажирание памяти.
Интересно. Я никогда не думал о том, что на SObjectizer можно распространить некоторые механизмы ОС. Поскольку ОС может прибивать процессы, а вот SObjectizer не может просто так уничтожать агентов.
Кё>Можно ли в агентно-ориентированной системе сделать такого же рода защиту, чтобы программист (в данном случае тим-лидер или архитектор) только поделил агентов-актеров на некоторые условные модули и подмодули (в смысле что каждый актер принадлежит одному конкретному модулю, хотя связи между ними могут быть произвольные), и затем даже в случае сбоя какого-то модуля, написаного новичком, остальные не были парализованы?
Наверное, что-то можно придумать. Надо покурить эту тему.
>Например, сбой в управлении вентиляцией не обязательно должен выводить из строя всю систему здания — охрану, освещение и т.д.
Самое надежное решение здесь -- это разбивать систему на отдельные SObjectizer-процессы. Чтобы падение одного не сказывалось на других.
Кё>В какого рода контроль загрузки целится SO5, или это еще не решено?
Еще не решено. Я перечислил три пункта, которые бы были востребованны в наших системах. Если будут еще какие-то идеи и предложения, то мы очень внимательно их рассмотрим и, при их состоятельности, обязательно попробуем реализовать.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Поддержка паттерна запрос-ответ.
Вместе с сообщением всегда идёт отправитель сообщения. Получатель сообщения может с помощью специальной функции сказать, что он отвечает на такое-то сообщение. Соотв. ответ маршрутизируется только одному агенту, не зависимо от обстоятельств.
Контекст сообщения.
Связано с паттерном запрос-ответ. Отправитель может прикрепить к сообщению произвольный контекст, по сути тоже сообщение. Получатель его не видит, но если он отвечает на это сообщение, то контекст возвращается к отправителю исходного сообщения.
Критично для поддержки stateless агентов.
Перехват сообщений.
Сторонний агент подписывается на перехват неких сообщений. Перехват может происходить (1) синхронно при отправке, (2) синхронно при получении, (3) асинхронно. При перехвате агент может прервать обработку. Может ли он менять сообщение — сложный вопрос. Главное — что перехват должен абсолютно прозрачен для исходных агентов — и отправителя и получателя.
Критично для расширяемости. Позволяет реализовывать например следующую схему. Идёт общение по какому-то каналу. Подкладываем dll'ку, агент из которой перехватывает все входящие и исходящие сообщения и прозрачно архивирует/деархивирует или шифрует/дешефрует.
Не знаю, возможно это и подразумевается под интеграцией MBAPI в SObjectizer.
Возможно, подобная интеграция MBAPI с ядром SObjectizer расширит SObjectizer новыми понятиями. Так, в SObjectizer существуют только агенты и рассылка сообщений (целенаправленная или широковещательная). Добавление mbox-ов и перехвата/перемаршутизации сообщений может ввести в SObjectizer такие понятия, как:
* доска объявлений -- это специальная сущность, используемая для широковещательной рассылки сообщений всем заинтересованным получателям. Сообщение как бы вывешивается на доску объявлений и все желающие могут прочитать его;
* канал, в котором все получатели сообщения выстраиваются в цепочку и сообщение передается от одного звена цепочки к другому. На уровне канала возможен перехват сообщения, его модификация и перемаршрутизация.
Почему новые понятия? Доска объявлений — это и есть широковещательная рассылка как она есть сейчас. Канал — это и есть целенаправленная рассылка, как она есть сейчас. Или я совсем чего-то не догоняю?
Другое дело, что эти существующие понятия можно расширить новыми фичами. Но по-сути вроде ничего не меняется.
Здравствуйте, remark, Вы писали:
R>Почему новые понятия? Доска объявлений — это и есть широковещательная рассылка как она есть сейчас. Канал — это и есть целенаправленная рассылка, как она есть сейчас. Или я совсем чего-то не догоняю? R>Другое дело, что эти существующие понятия можно расширить новыми фичами. Но по-сути вроде ничего не меняется.
Канал -- это явно выстроенная цепочка агентов, модицифирующих некую информацию по мере ее продвижения по каналу. Например, первый агент формирует текст, второй агент обрамляет этот текст в формат некоего пакета данных, третий шифрует этот пакет, четвертый подписывает, пятый обрамляет результат в виде нового пакета данных, шестой передает пакет в коммуникационный канал или сохраняет в БД. По сути, это явное воплощение pipes and filters шаблона.
Я задумался о его выделении в специальное понятие, поскольку, на мой взгляд:
— для канала требуются специальные средства конструирования канала. Например, агент-шифратор должен предшествовать агенту-подписывателю. Это должно гарантироваться вне зависимости от того, какой из этих агентов первым зарегистрируется в системе;
— канал должен оказываться разорванным при выпадении значимых звеньев. Например, если агент-шифратор прекратит по какой-то причине свою работу, то сообщения должны перестать ходить по каналу. В то же время, какие-то незначимые узлы могут добавляться и удаляться из канала безболезненно. Например, между агентом-формирователем текста и агентом-упаковщиком может на какое-то время вклиниться агент, собирающий статистику или проверяющий орфографию. Изъятие такого агента из канала не должно нарушать движение данных по каналу;
— передача сообщения между элементами канала, возможно, должа иметь какую-то специальную форму. Т.е. должен быть новый метод в API, который явно указывает, что сообщение передается либо дальше по каналу, либо должно отсылаться в другой канал.
По опыту использования MBAPI можно сказать, что организация каналов возможна и просто при наличии средств перехвата и перемаршрутизации сообщений. Но здесь не получается достичь того, чтобы:
— агенты занимали нужные места в цепочке. В MBAPI это получается лишь посредством приоритетов, т.е. приоритеты нужно просчитывать заранее, а в последствии их приходится перераспределять для того, чтобы куда-то вставить новое звено;
— не обеспечивается разрыв канала, если какое-то из ключевых звеньев удаляется. Получается, что просто исчезает перехватчик с некоторым приоритетом. А остальные перехватчики продолжают свою работу.
Ну и плюс ко всему вышеизложенному, для каналов можно разрабатывать средства контроля нагруженности и инструменты для предотвращения/преодоления перегрузок.
Доска объявлений изначально задумывалась как некое понятие для коммутации каналов. Например, доска объявлений может быть как точкой входа в канал (начальной точкой), так и точкой завершения канала (целевой точкой). Тогда какой-то агент вывешивает сообщение на доску объявлений и оно автоматом проваливается во все каналы, для которых доска объявлений является начальной точкой. Аналогично, когда последнее звено канала выдает наружу сообщение, то сообщение оказывается вывешенным на целевой доске объявлений (и, возможно, провалиться в какие-то другие каналы).
Однако, пару недель назад я пытался обдумать, как вообще может выглядеть использование досок объявлений в SO-приложениях. И ничего путного не придумал. Поэтому, возможно, этого понятия не будет, т.к. оно действительно хорошо реализуется широковещательной рассылкой. Но в тексте "Первого взгляда..." (который был написан довольно давно) я решил это понятие оставить.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, remark, Вы писали:
R>Поддержка паттерна запрос-ответ. R>Вместе с сообщением всегда идёт отправитель сообщения. Получатель сообщения может с помощью специальной функции сказать, что он отвечает на такое-то сообщение. Соотв. ответ маршрутизируется только одному агенту, не зависимо от обстоятельств.
R>Контекст сообщения. R>Связано с паттерном запрос-ответ. Отправитель может прикрепить к сообщению произвольный контекст, по сути тоже сообщение. Получатель его не видит, но если он отвечает на это сообщение, то контекст возвращается к отправителю исходного сообщения. R>Критично для поддержки stateless агентов.
Сначала несколько общих слов.
В SObjectizer хочется придерживаться принципа С++: не платишь за то, что не используешь. Применительно к запросу-ответу и контексту сообщения это означает, что SO не должен добавлять каких-либо накладных расходов к сообщениям, которые не участвуют в реализации данных паттернов.
А это означает, что поддержку идентификаторов запросов/ответов и контекстов сообщений, имхо, лучше вынести на более высокий уровень. Например, SO никак не поддерживает этих понятий. Но есть базовые классы для сообщений, наследование от которых добавляет поддержку идентификаторов/контекстов к сообщениям. Требуется агенту получать сообщения в ответ на свои запросы -- пусть оформляет соответствующим образом запрос.
Что касается контекста, то это вообще интересный вопрос.
Во-первых, я не согласен, что контекст не должен быть виден получателю сообщения. Более того, с сообщением может быть связано несколько контекстов. Вот сейчас у нас, средствами MBAPI реализовано несколько распределенных программных систем, в которых прослеживаются цепочки компонентов. Допустим, у нас есть операция, состоящая из трех фаз -- S (начало), R (результат), F (завершение). При наличии трех компонентов в системе это выглядит так:
A B C
|--------S------>| |
| |--------S----->|
| |<-------R------|
|<-------R-------| |
|--------F------>| |
| |--------F----->|
Компонент B является stateless компонентом. Он должен где-то сохранить информацию о том, от кого поступил S, куда передать R и куда отослать F. Если компонент C так же является stateless-компонентом, то ему так же нужно понимать, для какого S приходит F и что при получении F нужно делать (в зависимости от того, какой был R). Для того, чтобы это все работало, компоненты B и C добавляют в сообщения свои контексты. Получается что-то вроде:
A B C
|--------S------>| |
| |-----S(b)----->|
| |<--R(b,c)------|
|<--R(b',c)------| |
|---F(b',c)----->| |
| |-----F(c)----->|
где b, b' и c -- это связанные с сообщением контексты.
Если добавить в эту схему еще один компонент, то количество контекстов, задействованных в сообщениях может еще возрасти.
Так же, контексты вместе с сообщениями могут собираться в БД. Скажем, если есть какой-то промежуточный узел, предназначенный для сглаживания пиков нагрузки и который гарантирует на своем выходе некую стабильную скорость передачи сообщений. При получении всплеска трафика он может сохранить избыточные сообщения в БД, а затем поднимать их оттуда по мере надобности.
Имхо, все это проще достигается, если контексты представлены обычными полями сообщения и видны пользователю.
Во-вторых, понятие контекста известно под термином Async Completion Token (судя по твоей оценке на этом сообщении
мне не нужно лишний раз об этом рассказывать). И его поддержка, имхо должна быть не столько частью SObjectizer, сколько частью прикладной логики (что из себя представляет контекст, сколько контекстов, какие между ними связи) и системы сериализации (чтобы неизвестные промежуточным узлам структуры данных безпрепятственно проходили через узел).
R>Перехват сообщений. R>Сторонний агент подписывается на перехват неких сообщений. Перехват может происходить (1) синхронно при отправке, (2) синхронно при получении, (3) асинхронно. При перехвате агент может прервать обработку. Может ли он менять сообщение — сложный вопрос. Главное — что перехват должен абсолютно прозрачен для исходных агентов — и отправителя и получателя. R>Критично для расширяемости. Позволяет реализовывать например следующую схему. Идёт общение по какому-то каналу. Подкладываем dll'ку, агент из которой перехватывает все входящие и исходящие сообщения и прозрачно архивирует/деархивирует или шифрует/дешефрует.
На мой взгляд, поддержка в SO понялия канала будет решать изрядную долю задач, которые могли бы реализовываться с помощью перехвата сообщений. А нужно ли будет иметь перехват еще для чего-нибудь -- это уже отдельный вопрос.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
По крайней мере, это будет OpenSource проект под BSD (или ей подобной) лицензией 
