понял.. Вы о том что у сервера только один исполнитель...  ага.. это не то.. но по этому поводу у мя вопрос : 
исполнители должны иметь каждый свою группу сообщений или некоторые сообщения будут для исполнителей общие ?

у каждого свои сообщения + общие.
общие, это:
я хочу реализовать переброс исключений со стороны сервера клиенту. возможно еще какие-то технические данные.

еще момент. проблема с конструкторами исполнителей. каким образом реализовать поддержку аргументов для конструкторов?

Добавлено через 2 минуты и 15 секунд
сейчас приведу структуру классов для понимания..

Добавлено через 12 минут и 20 секунд

где IF - тип исполнителя.

опять на помню, может уговорю пересмотреть контракт с сервером с запрос->ответ, на вызов<->вызов




оставить создание исполнителя на стороне пользователя..

Добавлено через 42 секунды
как вариант передавать библиотеке ссылку на фабрику..

Добавлено через 3 минуты и 18 секунд
итак для начал нам нужно ограничить проблему.. 
что мы имеем ?
набор некоторых типов данных с ид
набор исполнителей

нам надо доставить данные нужному/нужным исполнителям.. алсо нужно предусмотреть таблицу соответсвий, желательно статическую по отношению к исполнителям.. 

я пока что не представляю как это должно выглядеть/функционировать.. на самом деле, я понимаю, что то, каким образом сейчас происходит общение - это тупик. но не понимаю я как это должно функционировать  
поясните плиз ;)


да, вариант.. набросаю пример..

не торопитесь с этим ..

Добавлено через 12 секунд

сейчас

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

  

Ваша схема (если убрать все лишнее) выглядит так :

главный недостаток в том, что сервер предоставляет информацию ТОЛЬКО по запросу пользователя..
то есть например сообщения чата, будут читаться только когда пользователь запросит, а сервер должен их хранить все это время... 
а не тогда когда кто то написал.. 
 

Если посмотреть на классиков (DCOM например), то там для этих случаев используют callback'и. Т.е. по сути локальный сервер на стороне пользователя + локальный пользователь на стороне сервера. 

а вот так примерно выглядит схема вызов<->вызов : 


Добавлено @ 12:48

не знаю как в там в DCOM, но фактически асинхронные callback`и я и предлагаю.. 
  
только вот НЕ с соотношением один вызов один каллбяк )

Это сообщение отредактировал(а) mes - 26.10.2010, 12:50

что-то не въезжаю.. откуда на стороне клиента может взяться сервер, и на стороне сервера клиент? кто тогда является сервером?

правда справедливость названия  каллбяков в данном случае условна и зависит от способа рассмотрения..

Добавлено @ 12:52

есть локальный сервер и удаленный 

Добавлено @ 12:52
с клиентом то же самое )

Добавлено @ 12:59
boostcoder, в общем чтоб не путаться
 если информация содержится/накапливается на сервере а клиент ее должен считать, то Ваш способ подходит
если нужна возможность непосредственного взаимодействия клиента с клиентами или ж просто нужна возможность уведомления от сервера в независимости от запроса клиента то не подойдет. 


Это сообщение отредактировал(а) mes - 26.10.2010, 12:59

Один в один с твоим предложением   

Оба. Равно как и клиентом, тоже оба.

да, собирался реализовать обратные колбэки от сервера клиенту. так что нужно.


т.е. чтоб скомпилить клиентскую сторону, должна быть доступна реализация сервера, и на оборот? я правильно понял?

вот например фирма выполняет заказ.. она в этот момент сервер, а заказчик клиент, 
а когда фирма высылает ему счет для оплаты, то заказчик сервер, а фирма клиент 
т.е. все зависит от темы рассмотрения.. 


Добавлено @ 13:11

не совсем так.. клиентский клиент и клиентский сервер, несколько (а может и совершенно) другие чем серверный сервер и серверный клиент 


Добавлено @ 13:11
все зависит от исполнения.. 

Добавлено @ 13:14
boostcoder, вот с точки зрения основной идеи вашей программы, (не знаю что там но допустим чат)
сервер будет сервером вашего чата, а клиент, клиентом вашего чата,
но и тот и другой могут иметь серверы удаленых вызовов.. 


Это сообщение отредактировал(а) mes - 26.10.2010, 13:15

т.е. мне нужно сейчас разделить реализацию сервера и клиента на две части.
сервер:
1. класс с аксэптором слушающим порт(КАСП).
2. класс взаимодействующий с сокетом клиента(КВСК).

клиент:
1. класс взаимодействующий с сокетом сервера(КВСС).
2. сериализатор/десериализатор команд(СДК).

мысли в слух..
на стороне сервера создаем объект КАСП и СДК. КАСП используется по назначению, в то время, как СДК используется для реализации обратных вызовов клиента.
на стороне клиента создаем объект КВСС и КВСК. КВСС используется по назначению, в то время, как КВСК используется 

запутался..

Добавлено через 55 секунд
в таком случае, нужно два соединения? одно клиента-с-сервером, второе сервера-с-клиентом? так?