Здравствуйте, eao197, Вы писали:
E>Под "ТАКИМИ" понимается SObjectizer? Или вообще разработка библиотек и фреймворков?
Имеется ввиду проекты с предполагаемым числом строк в 100000.
_>> надо знать как минимум логику работы _>>1) Процессора (выборка-исполенние) _>>2) Памяти _>>3) Контроллеров прерываний и их взаимодействие с процем _>>...ну и, короче, знать основы работы на НИЗАХ как и почему и хотеть(!) интересоваться этим дальше.
E>Это очень спорное утверждение, выходящее за рамки обсуждения SObjectizer, но все-таки можно ли его обосновать?
Просто: Мне кажется, что многие менеджеры обработки данных: агент, роутер, свич, светофор наконец. имеет одну и ту же природу — обработывают данные. Знание плюсов и минусов одинаковых по природе объектов, но различающийхся по способу обработки развивает кругозор, позволяет быстрее входить "в тему", понимать логику работы, предлагать лучшие варианты сходу (так как у работника большой кругозор!). Мне трудно судить по вашему знанию аппаратных средств, но компьютер устроен так же — посылка сообщений некоторым своим частям через прерывания, которых есть приоритет, на прерывания можно "подписаться" можно посылать прерывания по таймеру, замаскировать их ну и тд. Наверно, идея понятна, кто владеет информацией — владеет всем миром.
E>Не берусь судить о вашем опыте по найму сотрудников, но предположу, что знание ассемблера не потребуется при проектировании многоуровневого распределенного приложения. Нет, конечно же общая эрудиция и способность к перестройке мышления, которая достигается знаниями разных языков и инструментов -- это все большой плюс. Но гораздо важнее оценивать способность человека к обучению, наличие у него здавого смысла, желания работать и обучаться, возможность перестраивать свое видение проблемы в зависимости от условий.
Мы говорим об одном и том же. я подчеркнул, что синтаксис не главное, а в знаниях ассемблера имелось ввиду, чтобы были практические знания по работе частей компьютера.
E>Вот здесь я вообще потерял нить рассуждений. E>Зачем писать на SObjectizer алгоритм работы 2-х кэшей? Для имитационного моделирования? Если так, то про какую оптимальность доставки сообщений может идти речь? E>Зачем какой-то иерархический протокол доставки сообщений (с упоминанием локальных и глобальных сетей)? E>Мне кажется, что этот абзац содержит в себе какие-то внутренние противоречия. И не понятно, какое отношение он имеет к велосипедам вообще и к SObjectizer в частности.
Тут надо понимать некоторую аналогию — кеши — это два зеркала в интеренета, например (опять аналогия из жизни). и требуется обеспечить синхронизацию между ними.
E>Если же вы думаете, что при разработке программного обеспечения (software) нужно искать аналогии в аппаратуре (hardware), то может быть скажете, где в аппаратуре можно найти аналогию сборки мусора (GC)? E>Это я к тому, что на мой взгляд, в мире не так уж много принципиально разных идей. И какая-нибудь идея может иметь разные воплощения в разных областях, будь то software или hardware (как то асинхронное взаимодействие). Вот только совсем не факт, что какая-то реализация идеи в hardware должна становиться догмой в software.
Верно не факт, что идея из hardware, что должна становиться догмой в software, но надо ее знать, чтобы знать, чем идея в software лучше. А то вот я написал HelloWord на SObjectizer, если бы я не знаю другие языки, я бы сказал — круто (серое вещество не работает). А так я начинаю сравнивать со всеми другими языками на автомате и оценивать его возможности.
Про GC не думал, но это не значит что ее нет, но и не значит что она есть.
_>>Не надо тут говорить, что у SObjectizer уникальная идея. я больше чем убежден (более-менее серьезный разговор это развеет) что это не так.
E>Не говорил я такого. E>Я сказал: E>
E>Его возможностей (как внутреннего инструмента) вполне достаточно. Поэтому можно сказать, что нет свежих идей, которые бы дали новый толчок развитию SObjectizer.
E>Идеи как раз есть. Только это все наши собственные идеи. А хотелось бы услышать новые, неожиданные, из тех областей, про которые мы, возможно, даже не слышали. Чтобы в идеале кто-то взял и сказал: "Я считаю, что SObjectizer мог бы пригодиться вот здесь, но для этого нужно, чтобы он поддерживал то-то и то-то." E>А мы бы в ответ: "Ух ты! А ведь действительно... Погнали!" E>Но еще важнее, чтобы реализованная в SObjectizer идея была бы опробованна на практике. Чтобы не оказалось, что мы сделали фишку, предоставляющую только академический интерес.
E>Ну, например, время от времени возникает желание сделать сообщение-сигнал. Т.е., если сообщение A было отосланно, но еще не обработано, то повторые отсылки A не приводят к появлению новых экземпляров A. Или иногда высказываются предположение, что очереди заявок к агентам можно было бы ограничить по глубине. Скажем, стоит в очереди 2000 событий, новое не ставится, т.к. агент перегружен. Или идея перехвата сообщений с возможностью возобновления его обработки в дальнейшем. Или идея о сохранении сообщений в очередях на диске для обеспечения их гарантированной доставки...
Могу предложить так же реализовать обработку ответа от агента: перегружен, поставил в очередь, такое сообщение уже существует. А так же некоторые сервисы агента — уведодомление о доставке, проверка статуса сообщения.
E>Хочется сохранить разумный баланс между функциональностью SObjectizer и сложностью его реализации. Чтобы не превратить SObjectizer в барахолку неиспользуемых возможностей, которую очень трудно сопровождать.
А это уже вопрос архитектуры, разделения проекта на функциональные части, огранизации производства. 2-3 человека это сопросождать не смогут 100%.
_>>У людей в белых халатах из Research-центров всегда есть куча идей и куча денег — нет времени это все реализовать.
E>Ранняя история описывалась в ранней же моей статье История одного проекта. Но если этого не достаточно, то я могу сделать небольшой экскурс от истоков до сегодняшнего дня. E>А нынешний вид SObjectizer и так оОочень сильно отличается от того, что было в самом начале.
Отлично, осталось только добавить, то что нужно вам. А что добавлять должны решать как минимум 3 человека
Надо написать список плюсов и минусов (а для этого как я говорил надо иметь знания в других областях) прийти к общему мнению.
В общем я как всегда сумбурно все написал, что никто ничего не понял. сорри если что.
Здравствуйте, Аноним, Вы писали:
E>>Зачем писать на SObjectizer алгоритм работы 2-х кэшей? Для имитационного моделирования? Если так, то про какую оптимальность доставки сообщений может идти речь? А>Тут надо понимать некоторую аналогию — кеши — это два зеркала в интеренета, например (опять аналогия из жизни). и требуется обеспечить синхронизацию между ними.
И? Вы думаете, что для решения этой задачи нужно прежде всего обращать внимание на возможности SObjectizer?
На первом месте здесь будет сам алгоритм синхронизации, алгоритм обеспечения безопасности синхронизации и пр. А уже как результирующий алгоритм будет воплощаться с помощью SObjectizer -- это уже дело пятое, если не десятое.
А>Верно не факт, что идея из hardware, что должна становиться догмой в software, но надо ее знать, чтобы знать, чем идея в software лучше. А то вот я написал HelloWord на SObjectizer, если бы я не знаю другие языки, я бы сказал — круто (серое вещество не работает). А так я начинаю сравнивать со всеми другими языками на автомате и оценивать его возможности.
Мысль, вероятно правильная, но вот аналогия, имхо, не очень
Оценивать язык программирования на основании внешнего вида примера HelloWorld -- это весьма наивно.
К тому же SObjectizer -- это не язык программирования. Это инструмент, который в данное время предназначен для одного (и только одного) языка. Так что, если уж его сравнивать, что с чем нибудь подобным. А то ведь можно пытаться сравнить детектив и пиво, т.к. они являются средством времяпрепровождения.
И давайте взглянем на этот вопрос с другой стороны. Есть читатели, которые, как говорится, "в теме". Они могут сравнить SObjectizer, к примеру с Erlang или с SWITCH. Но ведь это очень специфическая область, про которые не так уж много читателей знают. Для кого-то может стать вообще откровением, что подобный инструмент существует (как для меня существование Erlang в свое время). Этот кто-то может примерить SObjectizer к своей задаче. А кто-то может заинтересоваться данной темой и пойти искать аналогичные инструменты.
Да и если пробовать составить впечатление о программировании на SObjectizer, то лучше делать это не на HelloWorld, а на более сложных примерах. Скажем, на high_traffic/server.cpp и high_traffic/client.cpp.
А>Могу предложить так же реализовать обработку ответа от агента: перегружен, поставил в очередь, такое сообщение уже существует. А так же некоторые сервисы агента — уведодомление о доставке, проверка статуса сообщения.
Ну вот, видите, сколько сразу предложений возникло. Для этого SObjectizer и выносится на обозрение.
Вот вам, к примеру, такая функциональность кажется полезной. А вот мне -- нет, т.к. я считаю, что подобные вещи делают связь между агентами более жесткой. Что приведет к проблемам масштабирования приложения, когда часть агентов потребуется переместить в другой процесс на другой узел сети. Вот у меня такое зашоренное мнение. И было бы интересно услышать контраргументы.
E>>Хочется сохранить разумный баланс между функциональностью SObjectizer и сложностью его реализации. Чтобы не превратить SObjectizer в барахолку неиспользуемых возможностей, которую очень трудно сопровождать. А>А это уже вопрос архитектуры, разделения проекта на функциональные части, огранизации производства. 2-3 человека это сопросождать не смогут 100%.
Угу. А еще вопрос целесообразности производства
_>>>У людей в белых халатах из Research-центров всегда есть куча идей и куча денег — нет времени это все реализовать.
А>Отлично, осталось только добавить, то что нужно вам. А что добавлять должны решать как минимум 3 человека
Вот как раз третьего и не хватает
Так что, можно сказать, озираемся по сторонам и спрашиваем у окружающих: "Третьим будешь?"
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, remark, Вы писали:
R>>4. Синхронные сообщения — всё-таки они нужны. Их отсутствие сужает область применения, если не в два раза, то по крайней мере на треть. R>>Это всё равно как заставить у всех функций использовать возвращаемый тип только void.
А>Позволю себе не согласиться с автором данного тезиса. Наоборот, жестко синхронная система подобна последовательному алгоритму, только в распределенном варианте исполнения. Более того синхронность и асинхронность — это всего лишь примитивы реализации взаимодействия, обладающие разными семантиками. И только от поставленной задачи зависит какой сопсоб взаимодействия агентов (компонент, процессов, потоков и прочее.....) лучше всего выбрать.
Сам же подтвердил мой тезис Я и говорю, что существуют такие задачи, для которых лучше подходит синхронное взаимодействие.
А>На мой взгляд и синхронный, и асинхронный способы обладают своими недостатками и преимуществами.
Бесспорно. Но при этом нет способа, который "лучше по всем параметрам", поэтому-то они и существуют оба.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>А если надо будет 2 таких сообщения подряд обработать? В начале обработать одно, все агенты отписываются, потом отсылается сообщение, что агентам можно заново подписываться. они снова подписываются, потом рассылается второе сообщение и агенты опять отписываются
E>Что-то я про два сообщения подряд не понял.
Ну в том примере про so_sysconf ты написал, что при необходимости выполнить некий тип действия (shutdown приложения), который фактически является синхронным (посылается сообщение и только после обработки сообщения всеми заинтересованными лицами выполнение продолжается), использовалась очень сложная схема: агенты регистрировались у некого вспомогательного объекта, потом обрабатывали сообщение, потом разрегистрировались у вспомогательного объекта, и после разрегистрации всех агентов, считалось, что обработка сообщения закончилась.
Я говорю о масштабируемости такого решения. А если надо будет выполнить несколько таких действий подряд? То агентам придётся постоянно то регистрироваться, то разрегистрироваться у вспомогательного объекта? А если надо будет выполнять несколько типов таких действий, то придётся создать несколько вспомогательных объектов?
E>Это тривиальный случай с возвратом long-а. Он не интересен. На практике как раз синхронность требовалась когда в сообшении-запросе передавался большой объем данных, а назад требовалось получить так же сложный объект с результатами их обработки/анализа/проверки.
Ну это уже зависит от задачи! Что надо сделать, то и надо реализовать. Если результаты надо объединять по &&, то надо объединять по &&. Если надо объединять по ||, то надо объединять по ||. Если надо складывать, то надо складывать. Если надо все результаты складывать в один контейнер, то надо складывать.
Возможности синхронной обработки тут ни при чём.
Здравствуйте, remark, Вы писали:
E>>Что-то я про два сообщения подряд не понял.
R>Ну в том примере про so_sysconf ты написал, что при необходимости выполнить некий тип действия (shutdown приложения), который фактически является синхронным (посылается сообщение и только после обработки сообщения всеми заинтересованными лицами выполнение продолжается), использовалась очень сложная схема: агенты регистрировались у некого вспомогательного объекта, потом обрабатывали сообщение, потом разрегистрировались у вспомогательного объекта, и после разрегистрации всех агентов, считалось, что обработка сообщения закончилась.
Да эта схема сложная только для агента a_shutdowner из so_sysconf, который процесс shutdown-а контролирует. Для агентов, которые заинтересованны в корректном закрытии при shutdown-е все достаточно тривиально: в начале своей работы отослать сообщение a_shutdowner о регистрации, поймать сообщение о shutdown-е, отослать сообщение о дерегистрации.
R>Я говорю о масштабируемости такого решения. А если надо будет выполнить несколько таких действий подряд? То агентам придётся постоянно то регистрироваться, то разрегистрироваться у вспомогательного объекта? А если надо будет выполнять несколько типов таких действий, то придётся создать несколько вспомогательных объектов?
Здесь видно две стороны масштабируемости. Во-первых, сколько агентов смогут обрабатывать одну операцию (тот же shutdown?). Если операция выполняется асинхронно, то ограничений не видно -- агенты смогут выполнять ее параллельно. Причем, что важно, большая часть агентов начнет обрабатывать shutdown одновременно, поскольку многие будут работать на параллельных нитях. А вот если shutdown делать синхронным, то нужно будет дергать агентов поочереди, ожидать завершение, дергать следующего и т.д. Мало того, что при большом количестве агентов эта операция будет не быстрой, так еще и система будет наполовину заглушена, наполовину работать в обычном режиме. Если же агенты довольно плотно взаимодействуют друг с другом, то что будет твориться в такой полузаглушенной системе...
Во-вторых, о количестве операций, которые требуют такой массовой реакции. Имхо, таких операций просто не может быть много. К тому же, они обрабатываются по одному принципу -- в начале работы отсылка куда-то регистрационной информации (здесь без разницы, сколько таких мест), затем реация на уведомления (опять же, таких реакций будет столько же, сколько и в синхронном варианте), затем дерегистрация. Мне кажется, что в синхронной реализации все будет точно так же: реализуем какой-то интерфейс, чтобы наш метод смогли вызвать. В начале работы о себе куда-то сообщаем. Обрабатываем воздействие и удаляем информацию о себе (либо просто подтверждаем возможность удаления этой информации). В принципе, все получается очень похоже.
R>Ну это уже зависит от задачи! Что надо сделать, то и надо реализовать. Если результаты надо объединять по &&, то надо объединять по &&. Если надо объединять по ||, то надо объединять по ||. Если надо складывать, то надо складывать. Если надо все результаты складывать в один контейнер, то надо складывать. R>Возможности синхронной обработки тут ни при чём.
При чем, при чем
Если мне в ответ будут подсовывать указатели на объекты разных типов, то максимум, что я смогу сделать -- это сохранить их все как void*. Но что-то мне не нравится такой подход.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
R>>Ну это уже зависит от задачи! Что надо сделать, то и надо реализовать. Если результаты надо объединять по &&, то надо объединять по &&. Если надо объединять по ||, то надо объединять по ||. Если надо складывать, то надо складывать. Если надо все результаты складывать в один контейнер, то надо складывать. R>>Возможности синхронной обработки тут ни при чём.
E>При чем, при чем E>Если мне в ответ будут подсовывать указатели на объекты разных типов, то максимум, что я смогу сделать -- это сохранить их все как void*. Но что-то мне не нравится такой подход.
Не понимаю.
Есть определённая задача: несколько кого-то должны что-то обработать и что-то возвратить кому-то обратно. И потом этот кто-то должен что-то сделать со всем, что ему вернули.
Будет ли это происходить асинхронно: все кто обрабытвал сообщение пошлют какие-то данные обратно в сообщениях.
Или синхронно: отправителю сразу вернётся массив каких-то ответов.
Разницы в плане обработки ответов не вижу ну абсолютно никакой. Так или иначе инициатор сообщения окажется с набором каких-то данных. При чём в обоих случаях наборы будут одинаковые.
Если он может что-то сделать с данными в асинхронном варианте, то он уж точно может сделать по крайней мере тоже самое в синхронном варианте.
Здравствуйте, eao197, Вы писали:
R>>Прошу заметить, что DisconnectedState не нужен член Socket socket_
E>А теперь представь, что все агенты в SObjectizer вынуждены менять свои состояния через создание нового объекта-состояния. Агентов могут быть сотни тысяч. А некоторые агенты могут менять свое состояние сотни раз в секунду. И это при том, что реальной очистки ресурсов будут требовать считанные единицы действительно тяжеловесных агентов.
R>>Ну или, например, канал приёма коротких сообщений. Допустим администратор может его включать/отключать (или это происходит автоматически). В активном состоянии каналу может требоваться достаточно много ресурсов: сокет, дополнительный поток, внутрениий буфер, какие-то кэши. А в отключённом состоянии ему это всё не нужно.
E>Ну и в чем проблема? Сокет по любому придется закрывать. Вызовешь у объекта типа CSocket метод close() при смене состояния и все. E>Поток уснет на каком-нибудь condition variable и никаких ресурсов требовать не будет. Кэши почистятся. E>Имхо, повторное создание/уничтожение всего этого хозяйства при смене состояния будет гораздо дороже, чем однократное создание его с последующим переводом в standby/ready.
Да. Но всё это приходится делать вручную. Надо об этом помнить. При переходе из такого-то состояния в такое-то надо не забыть разрушить/перевести в такое-то состояние такой-то объект. А при переходе обратно надо не забыть создать объект назад. Надо не забыть, что в таком-то состоянии нельзя обращаться к такому-то члену, т.к. он как бы не актуален в этом состоянии.
Имхо такая замечательная идиома языка с++ как конструктор/деструктор гораздо больше подходят для этой цели, они даже специально сделаны для таких задач.
Если я добавил Socket в Активное_состояние, занчит он автоматически создастся, занчит он автоматически закроется, значит я к нему случайно не обращусь когда не надо.
Если речь идёт об объектах, которых тысячи и миллионы, например короткие сообщения, то никто не мешает в целях оптимизации вынести данные из состояния назад в сам объект. Такой вариант можно предусмотреть отдельно как stateless states.
Если же речь идёт о каких-то "архитектурных" и "больших" агентах системы, которых единицы/десятки, и у которых состояния меняются например только по воле системного администратора, например не чаще чем пару раз в день, то я выбираю для таких агентов логическую стройность и меньшую склонность к ошибкам, чем повышение производительности.
E>>>Кстати, что-то вроде соц.опроса. Представь, что ты присматривался бы к использованию SObjectizer. И увидел бы, что тебе нужно делать описания агентов вот в таком Ruby DSL. Отпугнуло бы это тебя?
R>>Меня лично нет. R>>Хотя знаю людей, которых всяческие навороты отпугивают — им лучше, что бы всё по старому, по привычному. R>>Меня гораздо больше отпугивают вещи, которые такие DSL как раз призваны решать — а именно когда в коде есть много вещей, которые хорошо было бы описывать декларативно, но приходится описывать имепративно, да ещё зашивая в описание множество всяких не относящихся к делу вещей — например, описания множества однотипных классов-сущностей, описание структры БД в коде, написание запросов к БД и т.д. R>>Хотя такой DSL мог бы меня отпугнуть в след. ситуации: DSL в сторонней библиотеке, к которой нет хорошей документации, и я как раз решаю юзать е или нет. Тут DSL может отпугнуть, т.к. всё-таки всё услажняется: т.е. надо помимо кода ещё какие-то файлы писать, как-то дополнительно их обрабатывать и т.д. R>>А вот если например такой DSL уже используется в проекте, есть примеры, есть знающие люди, налажена компиляция DSL, то тут я только за.
E>Спасибо за высказанное мнение. E>Надеюсь, что SObjectizer таки относится к библиотекам, для которой есть хорошая документация
Ну она не то что бы плохая...
Но касательно распространённых языков/технологий/инструментов всегда есть книги (желательно на разных языках), есть сообщества, есть промоутинг. Даже я бы наверное сказал, что всё это как раз и делает эти вещи распространёнными.
Здравствуйте, remark, Вы писали:
R>Да. Но всё это приходится делать вручную. Надо об этом помнить. При переходе из такого-то состояния в такое-то надо не забыть разрушить/перевести в такое-то состояние такой-то объект. А при переходе обратно надо не забыть создать объект назад. Надо не забыть, что в таком-то состоянии нельзя обращаться к такому-то члену, т.к. он как бы не актуален в этом состоянии. R>Имхо такая замечательная идиома языка с++ как конструктор/деструктор гораздо больше подходят для этой цели, они даже специально сделаны для таких задач. R>Если я добавил Socket в Активное_состояние, занчит он автоматически создастся, занчит он автоматически закроется, значит я к нему случайно не обращусь когда не надо. R>Если речь идёт об объектах, которых тысячи и миллионы, например короткие сообщения, то никто не мешает в целях оптимизации вынести данные из состояния назад в сам объект. Такой вариант можно предусмотреть отдельно как stateless states.
Но как быть, если эти агенты не могут быть stateless?
R>Если же речь идёт о каких-то "архитектурных" и "больших" агентах системы, которых единицы/десятки, и у которых состояния меняются например только по воле системного администратора, например не чаще чем пару раз в день, то я выбираю для таких агентов логическую стройность и меньшую склонность к ошибкам, чем повышение производительности.
Боюсь, что все это выглядит стройно только на словах. На практике у подавляющего большинства агентов значения атрибутов агента нужно сохранять между состояниями. И только у очень малой части агентов нужно выполнять какие-то действия по очистке/переинициализации ресурсов во время смены состояния.
Да и создавать агента в виде 5-6 классов (классы-состояния + класс-агент) и оформлять это через шаблоны...
namespace traffic_sync {
class initial_state_t : public state_t { ... };
class empty_queue_state_t : public state_t { ... };
class wait_response_state_t : public state_t { ... };
class wait_timeout_state_t : public state_t { ... };
class a_traffic_sync_t : public agent_t<
initial_state_t,
empty_queue_state_t,
wait_response_state_t,
wait_timeout_state_t >
{
...
};
}
лично мне не кажется удобным
Да и это настолько далеко от сегодняшней реализации SObjectizer, что рассматривать подобное изменение способа описания/реализации агента, что может рассматриваться только в качестве теоритических изысканий. Может быть для SObjectizer v.6.0
E>>Надеюсь, что SObjectizer таки относится к библиотекам, для которой есть хорошая документация
R>Ну она не то что бы плохая... R>Но касательно распространённых языков/технологий/инструментов всегда есть книги (желательно на разных языках), есть сообщества, есть промоутинг. Даже я бы наверное сказал, что всё это как раз и делает эти вещи распространёнными.
Ну дыкть для того, чтобы сообщество сформировалось и затеян весь сыр-бор. А наше нынешнее обсуждение -- это промоутинг и есть
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, remark, Вы писали:
E>>При чем, при чем E>>Если мне в ответ будут подсовывать указатели на объекты разных типов, то максимум, что я смогу сделать -- это сохранить их все как void*. Но что-то мне не нравится такой подход.
R>Есть определённая задача: несколько кого-то должны что-то обработать и что-то возвратить кому-то обратно. И потом этот кто-то должен что-то сделать со всем, что ему вернули. R>Будет ли это происходить асинхронно: все кто обрабытвал сообщение пошлют какие-то данные обратно в сообщениях. R>Или синхронно: отправителю сразу вернётся массив каких-то ответов. R>Разницы в плане обработки ответов не вижу ну абсолютно никакой.
Разница очень существена как для отправителя ответа, так и для получателя ответа.
Вот как мне видится асинхронный вариант.
Агент, который инициирует некоторое действие:
void a_initiator_t::evt_initiate()
{
...
so_4::api::send_msg( some_agent, "msg_action", 0 );
...
}
// И вот в этих событиях он обрабатывает асинхронные ответы в виде типизированных сообщений.
// Можно обратить внимание на то, что внутри обработчика не нужно заботится об определении
// типа сообщения. И вовсе не обязательно, чтобы все msg_*_answer были производными от
// общего корня.void a_initiator_t::evt_some_answer( const msg_some_answer & cmd ) { ... }
void a_initiator_t::evt_another_answer( const msg_another_answer & cmd ) { ... }
void a_initiator_t::evt_yet_another_answer( const msg_yet_another_answer & cmd ) { ... }
А вот так агенты-исполнители будут отвечать инициатору:
Здесь у инициатора нет необходимости разбираться с типами ответов -- об этом заботится SObjectizer.
Теперь можно попробовать рассмотреть два варианта синхронного взаимодействия. Оба варианта отличаются способом отсылки результата. В первом случае агенты-исполнители отсылают ответ точно так же, как в асинхронном варианте и как было показано выше. Т.е. для агента-исполнителя прозрачно, сработал ли его event в синхронном или асинхронном режиме. Что весьма удобно, на мой взгляд. Только этот способ наиболее сложен для SObjectizer, т.к. SObjectizer должен как-то понять, что отосланное обычным образом сообщение из синхронно вызванного события на самом деле является синхронным ответом. Мне представляется, что в общем случае SObjectizer не сможет определить этого.
Во втором случае агенты-исполнители должны явно указать, что они оттдают синхронный ответ:
Вот тебе лично какой вариант больше нравится?
По мере написания пришло в голову, что можно сделать вот так... Перед отправкой синхронного запроса можно перечислить, какие сообщения ожидаются в ответ и сразу же указать их обработчиков:
А агенты-исполнители отсылают ответы обычным образом, как асинхронные сообщения. Но SObjectizer знает имена этих сообщений, и как только они появляются, складывает их в синхронный ответ. Остальные же сообщения рассылаются как обычно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Да. Но всё это приходится делать вручную. Надо об этом помнить. При переходе из такого-то состояния в такое-то надо не забыть разрушить/перевести в такое-то состояние такой-то объект. А при переходе обратно надо не забыть создать объект назад. Надо не забыть, что в таком-то состоянии нельзя обращаться к такому-то члену, т.к. он как бы не актуален в этом состоянии. R>>Имхо такая замечательная идиома языка с++ как конструктор/деструктор гораздо больше подходят для этой цели, они даже специально сделаны для таких задач. R>>Если я добавил Socket в Активное_состояние, занчит он автоматически создастся, занчит он автоматически закроется, значит я к нему случайно не обращусь когда не надо. R>>Если речь идёт об объектах, которых тысячи и миллионы, например короткие сообщения, то никто не мешает в целях оптимизации вынести данные из состояния назад в сам объект. Такой вариант можно предусмотреть отдельно как stateless states.
E>Но как быть, если эти агенты не могут быть stateless?
Нет, не агент stateless, а state stateless
E>>>Надеюсь, что SObjectizer таки относится к библиотекам, для которой есть хорошая документация
R>>Ну она не то что бы плохая... R>>Но касательно распространённых языков/технологий/инструментов всегда есть книги (желательно на разных языках), есть сообщества, есть промоутинг. Даже я бы наверное сказал, что всё это как раз и делает эти вещи распространёнными.
E>Ну дыкть для того, чтобы сообщество сформировалось и затеян весь сыр-бор. А наше нынешнее обсуждение -- это промоутинг и есть
Надо на большем кол-ве форумов. Может с каждого по паре энтузиастов и заинтересованных лиц и будет.
Здравствуйте, remark, Вы писали:
E>>Но как быть, если эти агенты не могут быть stateless?
R>Нет, не агент stateless, а state stateless
stateless state
Смешно. С учетом того, что состояние определяет поведение, а не структуру (данные) объекта.
E>>Ну дыкть для того, чтобы сообщество сформировалось и затеян весь сыр-бор. А наше нынешнее обсуждение -- это промоутинг и есть
R>Надо на большем кол-ве форумов.
Каких, например?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, remark, Вы писали:
E>>>Но как быть, если эти агенты не могут быть stateless?
R>>Нет, не агент stateless, а state stateless
E>stateless state
E>Смешно. С учетом того, что состояние определяет поведение, а не структуру (данные) объекта.
Я надеюсь, ты имеешь в виду "что состояние определяет поведение, а не структуру (данные) объекта в SObjectizer", а не вообще. Я предлагаю сделать возможность иметь более традиционный вариант, когда состояние определяет и данные (см. например паттерн State GOF). Мне более привычен традиционный ОО подход, когда поведение объединяется с данными нужными для этого поведения. В конце концов как может быть поведение без данных.
E>>>Ну дыкть для того, чтобы сообщество сформировалось и затеян весь сыр-бор. А наше нынешнее обсуждение -- это промоутинг и есть
R>>Надо на большем кол-ве форумов.
E>Каких, например?
Здравствуйте, remark, Вы писали:
E>>Смешно. С учетом того, что состояние определяет поведение, а не структуру (данные) объекта.
R>Я надеюсь, ты имеешь в виду "что состояние определяет поведение, а не структуру (данные) объекта в SObjectizer", а не вообще.
Да. Именно в SObjectizer
Это ведь тема, посвященная SObjectizer
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Имхо, самое полезное, если будет порт на c++/cli. И работы меньше, чем переписывать на c# и все преимущетсва .net использовать можно.
E>Вот это роль SObjectizer как до сих пор видел ее я. То, что SObjectizer написан на C++ -- это следствие истории его развития ("Все мы жертвы цепи нелепых случайностей" (C) К.Вонегут). Если в SObjectizer-е будет заинтересованность, то он может быть реализован и на других языках (не сразу, конечно). Мне хотелось бы понять, будет ли в этом потребность (т.е. заинтересованность читателей журнала и форума) и, если будет, то к какому языку прежде всего нужно будет присмотреться.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, remark, Вы писали:
E>>>Смешно. С учетом того, что состояние определяет поведение, а не структуру (данные) объекта.
R>>Я надеюсь, ты имеешь в виду "что состояние определяет поведение, а не структуру (данные) объекта в SObjectizer", а не вообще.
E>Да. Именно в SObjectizer E>Это ведь тема, посвященная SObjectizer
Понятно. Я же хотел предложить некоторые идеи, которые могли бы на мой взгляд улучшить SObjectizer. Ты же сам хотел критики.
В целом, идея очень здравая. Поддерживаю.
Я так понял, что SObjectizer достаточно лёгкий. Т.е. его можно поднять только что бы организовать взаимодействие между двумя агентами. А сколько уйдёт времени и кода на то, что бы прикрутить SObjectizer к проекту и организовать взаимодействие между 2 агентами?
По поводу перехода SObjectizer на другие языки. здесь
было очень плодовитое обсуждение. Я сейчас тоже склоняюсь больше в сторону C#. Многие вещи, которые на с++ представляют серьёзную проблемы, там бы делались настолько элементарно...
Например, сериализация, в С# надо написать ровно 0 строк кода, что бы обеспечить сериализацию. А это важный аспект для такой системы как SObjectizer.
Причём для сериализации там есть несколько сериализаторов. Т.е. внутри приложения можно использовать бинарный, что обеспечит скорость. А вне приложения можно использовать XML-сериализатор. Тогда уже можно обеспечить взаимодействие и с Java, и с чем угодно.
Есть только одно но, С# жестко привяжет SObjectizer к Windows и M$... Меня лично это не пугает, но тем не менее.
Там же есть такая крутая вещь как IAsyncResult, которая уже здесь упоминалась. Она красиво решит проблему синхронного выполнения. И можно сделать идентификацию сообщений всё-таки типобезопасной, а не на основе строковых имен, причём без ущерба там вещах, о которых ты писал, как о причинах использования строковых имён.
Вобщем, если SObjectizer перевести на С#, то придётся наверное процентов 90 кода удалить по причине ненужности. Я, когда начал писать на С#, довольно скоро выработал такую привычку "если хочешь, что-то реализовать, то вначале открой help по .net, скорее всего ты там уже найдёшь то, что ты хочешь реализовать"
Хотя сам я сейчас профессионально работаю (всё ещё ) с с++, т.ч. интерес более из интереса, чем профессиональный.
Здравствуйте, remark, Вы писали:
R>Я так понял, что SObjectizer достаточно лёгкий. Т.е. его можно поднять только что бы организовать взаимодействие между двумя агентами. А сколько уйдёт времени и кода на то, что бы прикрутить SObjectizer к проекту и организовать взаимодействие между 2 агентами?
Время зависит от уровня знания SObjectizer и степени сложности агентов, с которыми нужно будет работать.
Что касается кода -- то это зависит от сложности агентов. Необходимо будет реализовать:
* запуск SObjectizer Run-Time (если речь идет не о полностью SObjectizer-приложении, то делать это нужно на контексте отдельной нити, т.к. она окажется заблокированной). Например, вот так:
//
// Нить, на которой будет происходить запуск SObjectizer-а
//
ACE_THR_FUNC_RETURN
sobjectizer_thread( void * )
{
std::auto_ptr< so_4::timer_thread::timer_thread_t >
timer_ptr( so_4::timer_thread::simple::create_timer_thread() );
std::auto_ptr< so_4::rt::dispatcher_t >
disp_ptr( so_4::disp::active_obj::create_disp( *timer_ptr ) );
so_4::ret_code_t rc = so_4::api::start( *disp_ptr, 0 );
if( rc )
{
std::cerr << "start: " << rc << std::endl;
}
return 0;
}
int
main( int argc, char ** argv )
{
if( 2 == argc )
{
ACE_Thread_Manager::instance()->spawn( &sobjectizer_thread );
// Засыпаем, чтобы дать стартовать SObjectizer.
// Это самый простой способ синхронизации с sobj_thread_t.
ACE_OS::sleep( 1 );
...
* реализации агентов и описания агентов для SObjectizer. Собственно, реализация агента -- это обычный C++ класс с определением и реализацией. А описание агента для SObjectizer может выглядеть так:
Резюмируя: не так лаконично, как можно было бы сделать в Lisp, Ruby или Nemerle. Но и довольно просто, чтобы писать просто руками, без IDE и Wizard-ов, не испытывая при этом трудностей.
Приведенные фрагменты кода взяты из примера filter/c1.cpp
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
было очень плодовитое обсуждение. Я сейчас тоже склоняюсь больше в сторону C#. Многие вещи, которые на с++ представляют серьёзную проблемы, там бы делались настолько элементарно...
А я сейчас в сторону C# уже не склоняюсь
R>Например, сериализация, в С# надо написать ровно 0 строк кода, что бы обеспечить сериализацию. А это важный аспект для такой системы как SObjectizer.
Для сериализации в SObjectizer используется ObjESSty
, так что сериализация сложных (не циклических структур) в SObjectizer выполняется без проблем. Да еще в ObjESSty заложена возможность поддержки прозрачной расширяемости объектов, что очень удобно на практике при сопровождении распределенных приложений.
R>Причём для сериализации там есть несколько сериализаторов. Т.е. внутри приложения можно использовать бинарный, что обеспечит скорость. А вне приложения можно использовать XML-сериализатор. Тогда уже можно обеспечить взаимодействие и с Java, и с чем угодно.
Проблема взаимодействия SObjectizer с приложениями на других языках заключается не столько в способе сериализации данных, сколько в необходимости поддержки SOP. Либо внешенее приложение должно поддерживать SOP-соединения и соответствующую логику, либо же в SObjectizer нужно делать другие типы входов (например, на основе XML-RPC).
R>Есть только одно но, С# жестко привяжет SObjectizer к Windows и M$... Меня лично это не пугает, но тем не менее.
А меня пугает
R>Там же есть такая крутая вещь как IAsyncResult, которая уже здесь упоминалась. Она красиво решит проблему синхронного выполнения. И можно сделать идентификацию сообщений всё-таки типобезопасной, а не на основе строковых имен, причём без ущерба там вещах, о которых ты писал, как о причинах использования строковых имён.
R>Вобщем, если SObjectizer перевести на С#, то придётся наверное процентов 90 кода удалить по причине ненужности. Я, когда начал писать на С#, довольно скоро выработал такую привычку "если хочешь, что-то реализовать, то вначале открой help по .net, скорее всего ты там уже найдёшь то, что ты хочешь реализовать"
За последнее время я прикинул возможности портирования SObjectizer на несколько разных языков: D, Java, Scala (у него есть интероперабильность с JDK), Nemerle, Ruby и даже Eiffel (кстати, очень приличный язык, жалко, что его маркетологи загубили). И пришел к выводу, что вопрос о том, что в конкретном языке/платформе будет удобно для SObjectizer, возможно, даже не самый интересный и важный. От языка/платформы SObjectizer нужна, во-первых, большая библиотека (вроде JDK, .NET Framework, Ruby Library или ACE в C++). По этой причине D и Eiffel, к сожалению пока пролетают. Во-вторых, хотелось бы, чтобы язык предоставлял возможность для реализации DSL, необходимых SObjectizer. Здесь лидерами являются Nemerle и Ruby.
Но более важный вопрос в том, насколько нужен будет сам SObjectizer на конкретном языке/платформе. Ну например, будет SObjectizer for Java. Кому-нибудь он вообще понадобится? Аналогичный вопрос и по поводу SObjectizer for C# (Nemerle, Scala). Складывается впечатление, что чем более богатый Framework предоставляет платформа, тем менее нужен для нее SObjectizer. Взать тот же IAsyncResult в .NET, а так же развитые средства для организации удаленного взаимодействия в .NET (либо в JDK). Ну и зачем там спрашивается еще и SObjectizer? Может статься, что на мейнстримовых платформах SObjectizer будет нужен еще меньшему количеству разработчиков, чем в случае C++/Ruby/D/Eiffel. Так же не нужно забывать о таком феномене, что мейнстримовые разработчики имеют склонность использовать мейнстримовые же инструменты. SObjectizer таким инструментом никогда не станет
А вот если посмотреть на менее признаные языки (в первую очередь C++, а так же Ruby и D), то окажется, что в них SObjectizer предлагает разработчику часть инструментов, которые есть .NET/JDK, но нет в C++/Ruby/D. Поэтому для таких языков SObjectizer может стать более востребованным.
Ну и один из самых важных факторов: SObjectizer сейчас активно используется только в нашей компании (пока, я надеюсь, т.к. статистика SourceForge свидетельствует о наличии интереса к SObjectizer). А у нас разработка идет на C++ и Java (J2EE). Причем Java проекты не нуждаются в порте SObjectizer на Java. Посему просто нет причин, чтобы сейчас нам портировать SObjectizer на C# или Java. Есть желание сделать порт SObjectizer на Ruby, чтобы некоторые инструменты реализовывать быстрее (и делать их компактнее).
Но, если у кого-то будет серьезная заинтересованность в SObjectizer для C# или Java, то это дело можно будет реализовать (либо в выпуске соответствующего проекта под заказ ), либо в виде ветви OpenSource-проекта.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Я так понял, что SObjectizer достаточно лёгкий. Т.е. его можно поднять только что бы организовать взаимодействие между двумя агентами. А сколько уйдёт времени и кода на то, что бы прикрутить SObjectizer к проекту и организовать взаимодействие между 2 агентами?
E>Время зависит от уровня знания SObjectizer и степени сложности агентов, с которыми нужно будет работать.
[skip]
Спасибо. Понял.
В существующий "самобытном" проект как-то не очень сподручно прикручивать новый фреймворк, тем более тот, о котором никто пока ничего не знает.
А к сожалению программистов, новые проекты начинаются не так часто, как им бы того хотелось но в новом проекте, возможно подумаю об использовании SObjectizer.
, так что сериализация сложных (не циклических структур) в SObjectizer выполняется без проблем. Да еще в ObjESSty заложена возможность поддержки прозрачной расширяемости объектов, что очень удобно на практике при сопровождении распределенных приложений.
Я синтаксис его использования не смотрел, но думаю, что ObjESSty серьёзно сливает в этом плане встроенным в С# возможностям.
E>Проблема взаимодействия SObjectizer с приложениями на других языках заключается не столько в способе сериализации данных, сколько в необходимости поддержки SOP. Либо внешенее приложение должно поддерживать SOP-соединения и соответствующую логику, либо же в SObjectizer нужно делать другие типы входов (например, на основе XML-RPC).
Вот это, я думаю, перспективно... Но с учтётом того, что SObjectizer применяется только в одной компании, наверное, пока не надо
E>Во-вторых, хотелось бы, чтобы язык предоставлял возможность для реализации DSL, необходимых SObjectizer. Здесь лидерами являются Nemerle и Ruby.
Опять скажу по поводу С#. DSL на нём делать нельзя. Но там есть аттрибуты, которые могут дать достаточно "приятный" синтаксис описания.
Например, сообщения — ты не хотел их наследовать от одного класса. Можно их просто помечать аттрибутом:
[Message]
class MyMessage
{...}
Аналогично — агенты. Плюс ещё можно использовать параметры в аттрибутах:
[Agent (Threading = Active, Visible = Global)]
class Queue
{
[MessageHandler(SomeMessage)]
public void OnSomeMessage(SomeMessage msg);
}
А с применением рефлекшана, от падает необходимость в повторном описании всех полей сообщения. Т.е. достаточно его просто пометить аттрибутом.
E>Но более важный вопрос в том, насколько нужен будет сам SObjectizer на конкретном языке/платформе. Ну например, будет SObjectizer for Java. Кому-нибудь он вообще понадобится? Аналогичный вопрос и по поводу SObjectizer for C# (Nemerle, Scala). Складывается впечатление, что чем более богатый Framework предоставляет платформа, тем менее нужен для нее SObjectizer. Взать тот же IAsyncResult в .NET, а так же развитые средства для организации удаленного взаимодействия в .NET (либо в JDK). Ну и зачем там спрашивается еще и SObjectizer? Может статься, что на мейнстримовых платформах SObjectizer будет нужен еще меньшему количеству разработчиков, чем в случае C++/Ruby/D/Eiffel. Так же не нужно забывать о таком феномене, что мейнстримовые разработчики имеют склонность использовать мейнстримовые же инструменты. SObjectizer таким инструментом никогда не станет
E>А вот если посмотреть на менее признаные языки (в первую очередь C++, а так же Ruby и D), то окажется, что в них SObjectizer предлагает разработчику часть инструментов, которые есть .NET/JDK, но нет в C++/Ruby/D. Поэтому для таких языков SObjectizer может стать более востребованным.
на менее признаные языки — в первую очередь C++
Я думаю, что такой фреймворк, как SObjectizer, мог бы быть полезным для C# и Java.
Мог бы потому что там есть много полезных вещей — рефлекшн, IAsyncResult, потоки, сокеты, но там нет того, что могло бы объединить всё это в законченный фрейморк для создания определённого круга приложений (многопоточные серверные приложения, не самые тривиальные толстые клиенты и т.д.)
Нет базового класса, от которых я мог бы отнаследовать агента, нет ядра распределения сообщений и т.д.
Т.е. если сейчас я сяду делать приложение на С# то, мне придётся всё это изобретать самому. Конечно из более высокоуровневых деталей сем в с++, но всё же.
Я говорю о таком фреймворке как WinForms (для gui толстых клиентов) или asp.net (для web приложений)
В общем, я бы не сказал, что он там не нужен. Просто может необходимость в нём не так видна как в с++, т.к. в распоряжении всё-таки более высокоуровневые вещи, и не приходится всё это делать с нуля как в с++. А так собственно необходимость не меньше.
Другой вопрос, что на C#/Java сейчас делают меньше приложений такого класса, в которых нужен SObjectizer. Понятно, что в asp.net SObjectizer не нужен. Мне кажется, что бОльшую часть приложений такого класса сейчас делают всё же именно на С++.
