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

Если речь идет о том, что приходит сообщение извне и что-то делается в ответ - это все же не клиент, а наверное  сервис или сервер.



приложение в ходе выполнения задания только может при необходимости запрашивать дополнительную информацию (например, у других приложений)

Это сообщение отредактировал(а) COVD - 17.10.2009, 18:50

CMYK
Standalone сервис номер1 -- висит на приемке сообщений.
Все что он делает:

• принял сообщение
• залогировал это факт
• положил соощение в некий буфер обмена1 (это может быть таблица в базе данных, Message Queue или какой нибудь другой mail box)
• залогировал и это факт тоже
• если нужно нотифицировал того кто прислал сообщение, что оно принято к рассмотрению
• это тоже можно залогировать

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

Standalone сервис номер2 -- обрабатывает очередь сообщений
Что умеет он:

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

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

Можно еще сервис3, который будет мониторить буфер обмена2 и сообщать результаты обработки куда надо.

Получится весьма масштабируемое решение.

Можно еще сервис4, который будет проверять консистентность трех предыдущих и бороться за их живучесть (рестартовать и т.п.), а так же следить за состоянием буферов обмена (переполнение, дубликаты и т.п.) и предпринимать какие-то действия на этот счет (сообщать куда надо, чистить и т.п.). Совершенству нет предела  

Это сообщение отредактировал(а) Maksym - 17.10.2009, 19:00

Я наверно не полностью описал задачу.
Попробую так. Мне нужно организовать передачу данных между приложениями например: есть приложение которое думает там себе чего то, выполняет разные задачи. Захотелось ему подключиться к интернету (первое что пришло в голову), это приложение отправляет команду другому приложению которое отвечает за подключение\отключение к интернету и выводу различной информации об этом подключении на экран. Допустим потом захотелось ему вычислить площадь круга и еще выполнить несколько задач, для этого также есть отдельные модули которые выполняют эти задачи (один модуль на выполнение какой то определенной цели). Я так подумал подходит сервер клиент к такой ситеме. Поэтуму мне нужно узнать какая должна быть архитектура такого клинта, чтобы можно было дать задание, а при необходимости дать еще дополнительное задание.
Может быть есть другие технологии которые лучше адаптированы к такому подходу?

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

Да, похоже я зря старался   Ну да ладно. 
Сервер-клиент в данном случае не совсем то. Нужна шина, на которой будут регистрироваться и висеть твои сервисы, через нее же они будут предоставлять свои услуги. Ты просто говориш шине: "Хочу интернет, вот логин, пароль", "Хочу пдф, вот данные для него", а шина знает где искать нужный сервис, как в него впихнуть входные данные, как вернуть результат.
На энтерпрайзном уровне аналогичная технология это ESB.

От чего же зря? Это тоже интересно.
Шина значит и ESB. буду разбираться, спасибо за помощь. 

  

Я тоже так думаю   

мое мнение, для подобных задач, надо прекращать изобретать велосипеды..... ведь много умных дядек сидят и делают разные фреймворки.... почему бы не строить подобные программы например основываясь на OSGI, наделал кучу плагинов и включаешь/выключаешь их когда надо... сделал например один интерфэйс для соединений сделал плагин например на основе Apache Mina и включил его когда надо.... надоела Mina, взял другой фреймворк, подогнал под свой интерфэйс и все....   я использую Eclipse RCP  и очень доволен — большую часть работы за меня уже давно сделали, остается только бизнес логика....

Это сообщение отредактировал(а) firedrago - 18.10.2009, 11:38