Подскажите, существует ли что-нибудь вроде шаблонов проектирования клиент-серверных приложений?
Т.е. скажем необходимо сделать эхо-сервер, а шаблон заключался бы в описании того, как удобнее и лучше это сделать средствами java. Например, писать класс Server, представлюящий из себя синглетон и реализовать в нем методы getMessage, sendMessage и accept. Вторым классом был бы ServerListener implements Runnable, в котором бы реализовывался бы цикл приема сообщений приблизительно так:
Socket s = Server.etInstance().accept();
while(!s.isClose()){
String msg = Server.getInstance().getMessage();
Server.getInstance().sendMessage();
}
ну или что во что горазд... Если паттернов нет, подскажите, пожалуйста, как делать правильно. Задача заключается в написании демона, который бы висел на двух портах и прослушивал бы приходящие ообщения с последующим их анализом. Спасибо.
16.08.07 18:30: Перенесено модератором из 'Java' — Blazkowicz
Здравствуйте, d4u, Вы писали:
[skipped] d4u>ну или что во что горазд... Если паттернов нет, подскажите, пожалуйста, как делать правильно. Задача заключается в написании демона, который бы висел на двух портах и прослушивал бы приходящие ообщения с последующим их анализом. Спасибо.
Это ж опухнуть тогда можно... (имеешь ввиду посмотреть, как там сделано?)... использавть, т.е. реализовать — не подходит.
Надо защищенное ssl соединение на 1 порте делать, на другом нет. Я пошел так:
класс SSLSocketFactory — служит для создания сокетов с какими угодно параметрами,
класс SSLSocketListener — создает тред листенер на передаваемый в него сокет
класс SSLManager — создает и управляет теми сокетами, которые мне нужны
вот только корректно ли это?... блин, заморачиваюсь с этими паттернами и best practice ... голова пухнет
Здравствуйте, d4u, Вы писали: d4u>Это ж опухнуть тогда можно... (имеешь ввиду посмотреть, как там сделано?)...
не-е, я предлагал использовать JMS для обмена сообщениями
d4u>использавть, т.е. реализовать — не подходит.
хозяин — барин
Hello, Tolyan!
You wrote on Thu, 16 Aug 2007 11:09:45 GMT:
T> не-е, я предлагал использовать JMS для обмена сообщениями
То, что в JMS есть слово message еще не значит, что JMS нужно использовать для обмена сообщениями
Ключевое понятие в JMS — асинхронность, соответственно эта технология приемлема, когда нужен асинхронный обмен сообщениями.
Здравствуйте, YК, Вы писали:
YК>То, что в JMS есть слово message еще не значит, что JMS нужно использовать для обмена сообщениями YК>Ключевое понятие в JMS — асинхронность, соответственно эта технология приемлема, когда нужен асинхронный обмен сообщениями.
Прочитай внимательно сообщение автора
Задача заключается в написании демона, который бы висел на двух портах и прослушивал бы приходящие ообщения с последующим их анализом. Спасибо.
Hello, Tolyan!
You wrote on Thu, 16 Aug 2007 14:47:14 GMT:
YК>> То, что в JMS есть слово message еще не значит, что JMS нужно YК>> использовать для обмена сообщениями YК>> Ключевое понятие в JMS — асинхронность, соответственно эта YК>> технология приемлема, когда нужен асинхронный обмен YК>> сообщениями.
T> Прочитай внимательно сообщение автора
Задача заключается в
T> написании демона, который бы висел на двух портах и прослушивал бы
T> приходящие ообщения с последующим их анализом. Спасибо.
И где здесь про асинхронность? Про то, что прием может быть как синхронным, так и асинхронным в курсе?
Здравствуйте, YК, Вы писали:
T>> Прочитай внимательно сообщение автора
Задача заключается в
T>> написании демона, который бы висел на двух портах и прослушивал бы
T>> приходящие ообщения с последующим их анализом. Спасибо.
YК>И где здесь про асинхронность? Про то, что прием может быть как синхронным, так и асинхронным в курсе?
Да уважаемы, я в курсе. Даже если "Ключевое понятие в JMS — асинхронность", то сказал что обмен сообщениями в предполагаемом решении должен быть синхронный .
Здравствуйте, Tolyan, Вы писали:
T>>> Прочитай внимательно сообщение автора
Задача заключается в
T>>> написании демона, который бы висел на двух портах и прослушивал бы
T>>> приходящие ообщения с последующим их анализом. Спасибо.
YК>>И где здесь про асинхронность? Про то, что прием может быть как синхронным, так и асинхронным в курсе? T>Да уважаемы, я в курсе. Даже если "Ключевое понятие в JMS — асинхронность", то сказал что обмен сообщениями в предполагаемом решении должен быть синхронный .
Ну и к чему тогда цитата?
Про синхронный обмен никто не сказал, так же как и про асинхронный. Поэтому советовать JMS для решения тривиальной задачи, стоящей перед автором, как минимум странно, потому что:
a) JMS неизбежно вносит оверхед, как в виде необходимости специального программного обеспечения, так и усложнением программной модели.
б) Задача, в первую очередь решаемая JMS — развязать поставщиков и потребителей услуг. Для простенькой схемы взаимодействия, требуемой в описанном случае это едва ли необходимо
в) Вторая задача, решаемая JMS — за счет асинхронности обеспечить обслуживание такой нагрузки, с которой синхронный режим попросту не справится. Очевидно, не наш случай, потому что об этом ни слова не сказано.
Да кто сказал что предполагается тривиалоьная задача??? Человек в кратце описал суть, но под этим может стоять какая угодно проблема. Человек спросил, я предложил. Далее решать ему стит ли применять данную технологию.
ЗЫ Даже самую простую задачу не стоит решать прямо в лоб, т.к. когда потребуется ее расширять, то больше времени потратишь на рефактринг.
Hello, Tolyan!
You wrote on Fri, 17 Aug 2007 06:45:26 GMT:
T> Да кто сказал что предполагается тривиалоьная задача??? Человек в T> кратце описал суть, но под этим может стоять какая угодно T> проблема.
Ерудна. Задача была описана ясно — написание демона, принимающего сообщения по сети. Задача это тривиальная и решается элементарно.
T> ЗЫ Даже самую простую задачу не стоит решать прямо в лоб, т.к. T> когда потребуется ее расширять, то больше времени потратишь на T> рефактринг.
Здравствуйте, YК, Вы писали:
YК>Hello, Tolyan! YК>You wrote on Fri, 17 Aug 2007 06:45:26 GMT:
T>> Да кто сказал что предполагается тривиалоьная задача??? Человек в T>> кратце описал суть, но под этим может стоять какая угодно T>> проблема.
YК>Ерудна. Задача была описана ясно — написание демона, принимающего сообщения по сети. Задача это тривиальная и решается элементарно.
да, ты прав, я просто не заметил приатаченную проектую документацию. Извини.
T>> ЗЫ Даже самую простую задачу не стоит решать прямо в лоб, т.к. T>> когда потребуется ее расширять, то больше времени потратишь на T>> рефактринг.
YК>Абсолютно абстрактные и ничего не значащие слова.
Здравствуйте, d4u, Вы писали:
d4u>Подскажите, существует ли что-нибудь вроде шаблонов проектирования клиент-серверных приложений? d4u>Т.е. скажем необходимо сделать эхо-сервер, а шаблон заключался бы в описании того, как удобнее и лучше это сделать средствами java. Например, писать класс Server, представлюящий из себя синглетон и реализовать в нем методы getMessage, sendMessage и accept. Вторым классом был бы ServerListener implements Runnable, в котором бы реализовывался бы цикл приема сообщений приблизительно так: d4u>Socket s = Server.etInstance().accept(); d4u>while(!s.isClose()){ d4u> String msg = Server.getInstance().getMessage(); d4u> Server.getInstance().sendMessage(); d4u>}
d4u>ну или что во что горазд... Если паттернов нет, подскажите, пожалуйста, как делать правильно. Задача заключается в написании демона, который бы висел на двух портах и прослушивал бы приходящие ообщения с последующим их анализом. Спасибо.
Я бы использовал Jini
Сначала сам писал шаблоны, переходил с синхронных на асинхронные API...
Потом наткнулся на примеры JINI, и его архитектуру остановился.
Фильтры и стеки протоколов реализуются очень просто.
.
