SObjectizer не является жестким каркасом потому, что он не требует, чтобы все приложение было «написано на агентах». Напротив, SObjectizer позволяет реализовать лишь часть объектов приложения в виде агентов. Так, с помощью SObjectizer создавались CGI-модули, в которых SObjectizer запускался только для выполнения одного действия — запроса данных от другого приложения. После выполнения этого запроса SObjectizer останавливался, а CGI-модуль продолжал свою работу. При этом объем кода CGI, который работал с SObjectizer, составлял всего несколько процентов от общего объема кода модуля.

Также SObjectizer не накладывает органичений на способы интерактивного взаимодействия с пользователем. С помощью SObjectizer можно создавать «черные ящики», работающие вообще без какого-либо диалога с пользователем. Но можно создавать и полноценные GUI-приложения с применением готовых оконных библиотек, таких как MFC, ATL, WTL, Qt, wxWindows и др.

Но главное, что тогда произошло изменение способа мышления лично у меня — я стал испытывать затруднения с решением задач, в которых нельзя было применить агентный подход.

Главная политическая проблема SObjectizer в том, что SObjectizer существует только на C++ и только для C++. В частности, возможности SObjectizer для создания распределенных приложений можно использовать исключительно в С++. Конечно, SObjectizer не мешает использовать в этом же приложении иные способы взаимодействия (CORBA, COM, SOAP, XML-RPC). Но и не помогает. А если в приложение встраивается ручная поддержка CORBA или SOAP, то встает вопрос: “К чему тогда вообще использовать SObjectizer?” И ответ на этот вопрос, особенно когда требуется интероперабельность с написанными на других языках приложениями, часто бывает не в пользу SObjectizer.

Еще одна проблема наследуется SObjectizer от C++. В последнее время у C++ появились очень серьезные конкуренты. С одной стороны, это Java и .Net/C# с огромным количеством готовых библиотек и IDE нового поколения. Очень многих программистов от C++ отталкивает отсутствие настолько же удобных IDE (с автодополнением, автоподсказкой, поддержкой рефакторинга) как IDEA и Eclipse для Java, или VisualStudio+ReSharper для C#. В С++ с этим дела обстоят неважно. A у SObjectizer еще хуже — ведь сейчас нет ни одной IDE, способной поддерживать специфические особенности SObjectizer (хотя бы так, как VisualStudio помогла использовать MFC)...

ProcessMessage(Message msg)

// это сигнатура сообщения
public delegate void CurrencyChangedMsg(object sender, string currencyCode, double currency);

// это наш главный диспетчер
public interface ICurrencyMarket {
    event CurrencyChangedMsg CurrencyChanged;
}

public class AirportTabloid : Form {

blah blah blah 

    void ConnectToCurrencyMarkets() {
        // подписываемся на события от 3-х разных диспетчеров во всем мире.
        ICurrencyMarket market = (ICurrencyMarket)RemotingServices
            .Connect("tcp://currency.market.com:8085/Dispatcher", typeof(ICurrencyMarket))
        market.CurrencyChanged += OnCurrencyChanged;

        market = (ICurrencyMarket)RemotingServices
            .Connect("http://www.currency.jp/currency", typeof(ICurrencyMarket))
        market.CurrencyChanged += OnCurrencyChanged;

        market = (ICurrencyMarket)RemotingServices
            .Connect("iiop://privatbank.ru:11500/Dispatcher", typeof(ICurrencyMarket))
        market.CurrencyChanged += OnCurrencyChanged;
    }

    void OnCurrencyChanged(object sender, string currencyCode, double currency) {
        TextBox tb = FindByCurrencyCode(currencyCode);
        if(tb!=null)
            tb.Text = currency.Format("C");
    }

}

E>Следствием всего этого дела является, имхо, более простой способ создания многопоточных приложений. В чем-то похожий на подход Erlang-а. Но отличающийся от встроенных механизмов поддержки многопоточности в Ada или Java. Если диспетчеры обеспечивают для агента гарантию запуска его обработчиков только на контексте одной нити в один момент времени, то проблем взаимной синхронизации вообще нет. К этому привыкаешь и необходимость ручной работы с mutex-ами или condition variables начинает казаться слишком утомительной

E>В общем, в результате обычной декомпозиции ООП

E>Просто у нас нет события без обработчика и обработчика события без события Поэтому для краткости проще называть и события, и обработчики просто событиями.

E>С синхронностью все не так просто

V>>В общем, посмотри на пример. В дотнет ты можешь подписаться на событие, если сигнатура твоего метода совпадает с сигнатурой события. Т.е. ты можешь подписать на один и тот же метод-обработчик события от РАЗНЫХ источников совершенно разного типа (в примере указан один тип для 3-х удаленных серверов, но это могли бы быть совершенно разные 3 типа), которые могут плеваться совершенно разными типами сообщений. Главное — чтобы совпадали сигнатуры.

public delegate void EventHandler(object sender, EventArgs e);

public class MsgBase {}

public delegate void MsgHandler(MsgBase msg); // вот такая сигнатура

public delegate void Notify();

public IMyServer {
    event Notify Event1, Event2, Event3 ... EventN;
}

public MyClient {

    void Connect(IMyServer server) {
        server.Event1+=OnEvent1To3;
        server.Event2+=OnEvent1To3;
        server.Event3+=OnEvent1To3;

        server.Event4+=OnEvent4ToN;
        ...
        server.EventN+=OnEvent4ToN;
    }

    // здесь мы обрабатываем одну группу сообщений
    void OnEvent1To3() { ... }

    // здесь - другую
    void OnEvent4ToN() { ... }
}

E>>>Просто у нас нет события без обработчика и обработчика события без события Поэтому для краткости проще называть и события, и обработчики просто событиями.

V>public class MsgBase {}

V>public delegate void MsgHandler(MsgBase msg); // вот такая сигнатура
V>

ClosePipe(pipeId);
ClosePipe(pipeId, flushMode);
ClosePipe(pipeId, flushMode, flushTimeout);
ClosePipe(pipeId, reopenTimeout);
ClosePipe(pipeId, flushMode, flushTimeout, reopenTimeout);

close_pipe pipe_id
close_pipe pipe_id, :flush_mode => mode
close_pipe pipe_id, :flush_timeout => tv, :flush_mode => mode
close_pipe pipe_id, :reopen_timeout => tv
close_pipe pipe_id, :flush_mode => mode, reopen_timeout => tv_reopen, :flush_mode => tv_flush

msg_close_pipe::send( pipe_id, flush_mode, flush_timeout );
msg_close_pipe::send( pipe_id, flush_mode, flush_timeout, reopen_timeout );

so_4::rt::evt_subscr_t from1to3;
from1to3.add( "server", "event_1" );
from1to3.add( "server", "event_2" );
from1to3.add( "server", "event_3" );
so_4::api::subscribe_event( "a_my", "evt_1to3", from1to3,  so_4::rt::evt_subscr_t::e_change_all );

so_4::rt::evt_subscr_t from4toN;
from4toN.add( "server", "event_4" );
from4toN.add( "server", "event_4" );
so_4::api::subscribe_event( "a_my", "evt_4toN", from4toN, so_4::rt::evt_subscr_t::e_change_all );

зависит от качества кода и алгоритмов

то его АПИ должен быть ориентирован на безопасный язык

"Вы проиграли в футбол потому, что у вас правостороннее движение."

VD>Знашь, я вот сомтрю вокур и удивляюсь. С кем не заговоришь так он не дятел. А вокруг одни дятлы, дятлы, дятлы...

so_subscribe( "evt_hello_time", "msg_hello_time" );

struct TextChangedEvent : Event<TextChangedEvent>
{
    TextChangedEvent(const std::string& text, int id)
        : text_(text)
        , id_(id)
    {}

    std::string text_;
    int id_;
};

send(TextChangedEvent(newText, myID));

void process(const TextChangedEvent& e);

send(message); // Отправка на глобальный коммутатор
send(message, subsystemNcommutator); // Отправка на коммутатор подсистемы N

subscribe(subsystemNCommutator);
subscribe(applicationFrameworkCommutator);

class Socket : public Agent<ActiveSocketState, PassiveSocketState>
{
    //...
};

class ActiveSocketState : State<ActiveSocketState>
{
public:
    void process(SocketDeactivateEvent&);
    void process(SocketPacketReceive&);

private:
    byte internalBuffer[65536];
};

class PassiveSocketState : State<PassiveSocketState>
{
public:
    void process(SocketActivateEvent&);
};

struct SyncMessageParams
{
    int result;
    Event messageProcessed; // Событие, что сообщение обработано
    void wait(); // Ждать, пока сообщение не обработается
};

SyncMessageParams params;
async_send("msg", &params);
params.wait(); // Ждём пока сообщение будет обработано
if (params.result) ...;

R>Хочу сразу сказать, что идея создания таких фреймворков, и этого в частности, мне нравится. Поэтому критику прошу рассматривать как конструктивную и имеющую цель приблизить наступление светлого будущего

R>so_subscribe( "evt_hello_time", "msg_hello_time" );
R>

{send-msg
    {agent aag_3::smsc_map::default::a_router }
    {msg     msg_configure }
}
send
exit

so_send_stdin "какой-то IP" < reconfigure.sop

1.upto( 5000 ) do |i|
    puts <<-EOF
{send-msg
    {agent    aag_3::smpp_smsc::bserver.trx::a_channel }
    {msg    msg_imit_delivery_receipt }
    {field    m_short_message
        {string-stream "id:#{i} sub:001 dlvrd:001 submit date:0508251625 done date:0508251625 stat:DELIVRD err:000 text:AAG3 test"} }
}
    EOF
    puts "send" if 0 == i % 10
end

puts "exit"

ruby imit_delivery_receipt.rb | so_send_stdin "какой-то IP"

Нужно сказать, что использование so_send_stdin производит сильные впечатления. Подключаешься к работающему приложению и буквально можещь ощущать его пульс и воздействовать на него

struct msg_hello_time {
  static const std::string so_msg_name = "msg_hello_time";
  ...
};

so_subscribe( SO4_EVENT_NAME( a_hello_t, evt_hello_time ), SO4_MSG_NAME( msg_hello_time ) );

subscribe< msg_hello_time >( &a_hello_t::evt_hello_time );

R>void process(const TextChangedEvent& e);
R>

R>struct SyncMessageParams
R>{
R>    int result;
R>    Event messageProcessed; // Событие, что сообщение обработано
R>    void wait(); // Ждать, пока сообщение не обработается
R>};

R>SyncMessageParams params;
R>async_send("msg", &params);
R>params.wait(); // Ждём пока сообщение будет обработано
R>if (params.result) ...;
R>

// Инициатор синхронного сообщения.
so_4::rt::sync_response_t< msg_response > resp;
if( !so_4::api::send_msg_safely( some_agent, "msg_do_this", request, receiver_name, resp ) )
  {
    // Сообщение отправлено. Можно ждать результата.
    ...
    if( !resp.wait() )
      // Результат получен. Обрабатываем его.
      ...
    else // Произошла ошибка получения результата.
      ...
  }
else // Произошла ошибка отсылки синхронного сообщения.
  ...

// Код обработчика синхронного сообщения.
void
evt_do_this(
  so_4::rt::event_data_t & event_data,
  const msg_do_this & cmd )
  {
    // Обработка.
    ...
    // Отсылка ответа.
    event_data.reply( new msg_response( ... ) );
    ...
  }

E>Не тебя одного это пугает, по началу. Однако, практика показывает, что все не так страшно

E>1.upto( 5000 ) do |i|
E>    puts <<-EOF
E>{send-msg
E>    {agent    aag_3::smpp_smsc::bserver.trx::a_channel }
E>    {msg    msg_imit_delivery_receipt }
E>    {field    m_short_message
E>        {string-stream "id:#{i} sub:001 dlvrd:001 submit date:0508251625 done date:0508251625 stat:DELIVRD err:000 text:AAG3 test"} }
E>}
E>    EOF
E>    puts "send" if 0 == i % 10
E>end

E>puts "exit"
E>

SOL4_MSG_START(msg_alarm, msg_alarm)
  SOL4_MSG_FIELD(m_sensor_name)
  SOL4_MSG_FIELD(m_current_value)
  SOL4_MSG_FIELD(m_max)
SOL4_MSG_FINISH()

E>Ну и еще, вероятно, сказалось то, что я не являюсь фанатичным стороником статической типизации. Имхо, некоторая доля динамизма в статически типизированной программе не помешает

struct SMSStateChange: Event {};
struct SMSReceivedEvent: SMSStateChange{};
struct SMSSavedToDBEvent: SMSStateChange{};

void subscrive(SMSSavedToDBEvent& e);

void subscrive(SMSStateChange& e);

R>>void process(const TextChangedEvent& e);
R>>

void SomeClass::process(SomeEvent&);

R>"А вот это попробуйте"

class SomeAgent < So4::Rt::Agent
  # Событие, которое получает event_data. Приоритет и подписка определяется в динамике.
  so4_event :evt_1 do |event_data|
    # Код обработчика события.
    ...
  end

  # Событие, которое не получает вообще никаких аргументов.
  so4_event :evt_2 do ... end

  # Событие, которое получает и event_data и сообщение.
  # Сразу же определяется инцидент и приоритет.
  so4_event :evt_3,
    :msg => Start, :owner => :starter, # Инцидентом является сообщение starter.Start.
    :priority => 1 do |event_data, msg|
    # Код обработчика события...
  end

  # Распределение событий по состояниям.
  so4_state :st_initial,
    :events => [ :evt_1 ]

  so4_state :st_normal,
    :events => [ :evt_2, evt_3 ],
    :on_enter => :on_enter_st_shutdown # Для Ruby здесь даже можно блок кода определить.
end

E>Во-первых, обращения к каналу в состоянии st_disconnected, скорее всего, все равно потребуются. Хотя бы для инициирования переподключения

E>Во-вторых, в SObjectizer я бы выделил канал в другого агента И так на самом деле и происходит. В составе SObjectizer есть транспортные агенты (для работы с SOP и с RAW-каналами (a_cln_channel_t, a_raw_cln_channel_t)), которые в своем состояние st_disconnected дергают свой атрибут-канал для восстановления подключения. Когда подключение восстанавливается, они отсылают сообщение об этом. Если агент, занимающийся обработкой транзкций заинтересован в этом сообщении, то он подписывается на это сообщение.

struct DisconnectedState : SocketState
{
    virtual void Connect(const std::string& address, int port)
    {
        goto_state(new ConnectedState(address, port));
    }
};


struct ConnectedState : SocketState
{
    ConnectedState(const std::string& address, int port)
        : socket_(address, port)
    {}

    virtual void Disconnect()
    {
        goto_state(new DisconnectedState);
    }

    virtual std::string Receive()
    {
        return socket_.Receive();
    };

    Socket socket_;
};

R>>"А вот это попробуйте"

E>Я когда стал обдумывать DSL для описания агентов еще задумался о том, чтобы портировать SObjectizer в Ruby

E>В общем, есть впечатление, что в Ruby SObjectizer использовать даже удобнее было бы

R>>Забавно. Типа "ну вы вообще конечно начинайте готовиться к завершению программы, но процесс всё равно умрёт неожиданно"

E>

struct Result
{
private:
long result_;
public:
void setResult(long result)
{
InterlockedExchange(&result_, result_ && result);
}
};

R>>struct SyncMessageParams
R>>{
R>>    int result;
R>>    Event messageProcessed; // Событие, что сообщение обработано
R>>    void wait(); // Ждать, пока сообщение не обработается
R>>};

R>>SyncMessageParams params;
R>>async_send("msg", &params);
R>>params.wait(); // Ждём пока сообщение будет обработано
R>>if (params.result) ...;
R>>

E>Это не правильный код

class SyncResult
{
private:
    Event event_;
    int result_;
        
public:
    void set(int result)
    {
        result_ = result;
        event_.Set();
    }

    int waitForProcess()
    {
        WaitForSingleObject(event_);
        return result_;
    }
};

class SyncMessage
{
private:
    SyncResult& sync_;
    int result_;

public:
    SyncMessage(SyncResult& sync)
        : sync_(sync)
        , result(0)
    {}

    void setResult(int result)
    {
        // По некому закону объединяем result_ и result
    }

    //...

    ~SyncMessage()
    {
                // Это выполняется при удалении сообщения - очевидно, что это происходит после обработки сообщения всеми подписчиками
        sync_.set(result_);
    }};


int main()
{
    SyncResult syncResult;
    so4::send("msg", new SyncMessage(syncResult));
    int syncProcessResult = syncResult.waitForProcess();
}

new msg_some_action( param1, param2, param3 );

m = new msg_some_action();
m->param1 = param1;
m->param2 = param2;
m->param3 = param3;

aag_3::smpp_smsc::some_operator::a_channel
aag_3::smpp_smsc::some_operator::a_send_history
aag_3::smpp_smsc::some_operator::a_receive_history

aag_3::smpp_smsc::another_operator::a_channel
aag_3::smpp_smsc::another_operator::a_send_history
aag_3::smpp_smsc::another_operator::a_receive_history

aag_3::smsc_map::default::a_router
aag_3::smsc_map::default::a_state_mon
aag_3::smsc_map::another_server::a_router
aag_3::smsc_map::another_server::a_state_mon

mbsms_gate_1::some_provider::a_send_retranslator
mbsms_gate_1::some_provider::a_receive_retranslator

mbsms_gate_1::another_provider::a_receive_retranslator
mbsms_gate_1::another_provider::a_receive_retranslator

Его возможностей (как внутреннего инструмента) вполне достаточно. Поэтому можно сказать, что нет свежих идей, которые бы дали новый толчок развитию SObjectizer.

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 >
  {
    ...
  };

}

E>>Надеюсь, что SObjectizer таки относится к библиотекам, для которой есть хорошая документация

E>>При чем, при чем

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 ) { ... }

void a_some_actor_t::evt_action( const msg_action & cmd )
  {
    ...
    // Отсылаем ответ.
    so_4::api::send_msg_safely( so_query_name(), "msg_some_answer", new msg_some_answer( ... ) );
  }

void a_another_actor_t::evt_action( const msg_action & cmd )
  {
    ...
    // Отсылаем ответ.
    so_4::api::send_msg_safely( so_query_name(), "msg_another_answer", new msg_another_answer( ... ) );
  }

void a_yet_another_actor_t::evt_action( const msg_action & cmd )
  {
    ...
    // Отсылаем ответ.
    so_4::api::send_msg_safely( so_query_name(), "msg_yet_another_answer", new msg_yet_another_answer( ... ) );
  }

void a_some_actor_t::evt_action( const so_4::rt::event_data_t & event_data, const msg_action & cmd )
  {
    ...
    // Отсылаем ответ.
    event_data.reply( "msg_some_answer", new msg_some_answer( ... ) );
  }

void a_another_actor_t::evt_action( const so_4::rt::event_data_t & event_data, const msg_action & cmd )
  {
    ...
    // Отсылаем ответ.
    event_data.reply( "msg_another_answer", new msg_another_answer( ... ) );
  }

void a_yet_another_actor_t::evt_action( const so_4::rt::event_data_t & event_data, const msg_action & cmd )
  {
    ...
    // Отсылаем ответ.
    event_data.reply( "msg_yet_another_answer", new msg_yet_another_answer( ... ) );
  }

void a_initiator_t::evt_initiate()
  {
    ...
    so_4::rt::sync_response_t response = so_4::api::sync_msg( some_agent, "msg_action", 0 );
    if( !response.result() && !response.wait( timeout ) )
      {
        // Получили ответ, нужно обрабатывать.
        for( so_4::rt::sync_response_t::const_iterator it = response.begin(), it_end = response.end();
          it != it_end; ++it )
          {
            if( "msg_some_answer" == it->msg_name() )
              process_some_answer( reinterpret_cast< msg_some_answer * >( it->msg_data() ) );
            else if( "msg_another_answer" == it->msg_name() )
              process_another_answer( reinterpret_cast< msg_another_answer * >( it->msg_data() ) );
            else if( "msg_yet_another_answer" == it->msg_name() )
              process_yet_another_answer( reinterpret_cast< msg_yet_another_answer * >( it->msg_data() ) );
          }
      }
    ...
  }

    if( !response.result() && !response.wait( timeout ) )
      {
        response.handle( "msg_some_answer", &a_initiator_t::process_some_answer );
        response.handle( "msg_another_answer", &a_initiator_t::process_another_answer );
        response.handle( "msg_yet_another_answer", &a_initiator_t::process_yet_another_answer );
      }

void a_initiator_t::evt_initiate()
  {
    ...
    so_4::rt::sync_request_t request;
    request.add_handler( "msg_some_answer", &a_initiator_t::process_some_answer );
    request.add_handler( "msg_another_answer", &a_initiator_t::process_another_answer );
    request.add_handler( "msg_yet_another_answer", &a_initiator_t::process_yet_another_answer );
    if( !request.send( some_agent, "msg_action" ) && !request.wait( timeout ) )
      request.handle();
    else
      ...
  }