Petro123вадяHoBTID, это вызывает WebSocketServer.
вот тут у тебя проблема.
Если система растёт, то это не буквально растёт onMessage() на 200 методов.
Ты очень любил websockets?. Вот и получаешь его результат.
IMHO
да, я очень люблю websockets, и рост onMessage ни сколько не мешает этому.
это можно сделать и на ajax, и получить теже 200 методов. только головняков будет больше. проверено.
а многие вещи с ajax просто не реализуемы.
это 100-200 методов не недостаток websockets, а лишь результат того, что послать запрос на сервер очень дешево и получить ответ также.
если надо на сервере обработать данные с клиента - я должен отправить на него (либо через ajax либо через websockets) команду и данные. пусть тем же xml, на сервере распарсить и выполнить требуемой командой действия над данными.
тоже и на клиенте - команда + данные, только на javascript все решается проще window [comanda] (data)
так что websockets здесь только облегчает жизнь.

Petro123вадя,
вот и приведи свои 200 методов.
Тебя просили.
есть поля с возможностью поиска+редактирования найденного, + в зависимостиот найденного - отображаются еще несколько полей, также с возможностию редактирования.
к примеру (очень грубо) выбираешь клиента-список товаара,выбираешь товар-куча его свойств.
не обновлять же при каждом выборе страницу.
для клиента - как минимум 3 запроса - для поиска, для отправки редактированного, для удаления(как вариант пометка как не действующий).
а если делать удобный интерфейс - фильтры, сотрировки ...
1 страница -10-15 запросов, страниц 10-15, вот и посчитай
это не для сайта, это для корпоративного портала.
авторhttp//имяПриложения/ИмяМетода?ПарамМетода1=фф, ПарамМетода2= ....
ну и что я отправляю: имяметода|параметр%параметр...
мне проще распарсить мою сторку - всего два сплита

авторну, дак не все они идут через одно игольное ушко onMessage?
Нафига тогда ЯП _высокого_ уровня?

почему ты считаешь игольным ушком?
http//имяПриложения/ИмяМетода?ПарамМетода1=фф, ПарамМетода2= ....
также можно считать игольным ушком.

чем отличается http//имяПриложения/ИмяМетода?ПарамМетода1=фф, ПарамМетода2= .... от websockets?

websockets удобней, проще, быстрее, универсальней, двунаправленно

авторRest Full (url семантика) хотя бы по семантике тот же самый как код методов программиста.
Он как минимум сохраняет состояние программы у пользователя на рабочем столе.
Было бы оригинально, если бы мне предлагали писать новый протокол общения сервера и клиента на TCP по порту 1521
Ты пишешь обвязку над сокетами? Фреймворк для прикладника-программиста?
Тогда так в теме и пиши.
мы видимо о разном говорим...
есть протокол websockets(ws) альтернатива ajax, comet и пр. поддерживается даже ie10+
опуская весь путь от браузера до сервера, имеем слушателя на понравившемся порту, сообщение после прочей обработки, расшифровки попадает в onMessage. по спецификации websockets пересылает строку (либо массив байт), как использовать эту строку - отдано прикладной программе.
я разделителями делю на части - команда и данные
команда = имя метода для обработки(для простоты).
причем здесь
авторТы пишешь обвязку над сокетами? Фреймворк для прикладника-программиста?
очень грубо говоря - я пишу вебморду для работы с данными - формы ввода, просмотра, и пр., как продолжение грубой фссоциации - интернет магазин с раширенными фунциями. можно сделать и десктоп , но придется устанавливать, а так открыл браузер и работай.(ws хорошо встроится и в десктоп, и в андроид)

авторты не БАД'ы продаешь? ))...с такой формулировкой?
Откуда тогда полиморфизм и твоя тема на сокетах?
чтоб это написать
websockets удобней, проще, быстрее, универсальней, двунаправленно
надо бадов накушаться?
против каких пунктов из выше перечисленных ты против?
одно то, что инициатором сообщения может быть сервер многого стоит. тут даже comet курит в стороне, не говоря об ajax.

авторЧто тут технологически красиво - сложно сказать.
У него сейчас 15 методов. А будет ли 500 - неизвестно.

вот я и ищу более "красивого вида"
даже при 20 методах всё красиво и для сопровождения и для отладки.
if мне не нравится, уже писал.
"паттерн команд" тоже не очень, по скорости я думах, что проиграет рефлексии

авторВ сервлет 3.0 у меня есть

@WebServlet("/ИмяПроцедуры")
public class ИмяПроцедуры extends HttpServlet {
и есть
request.getParameter("ПараметрПроцедуры");


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

но для 100+ именПроцедур у тебя тоже возникнут аналогичные проблемы.
все методы в одном файле?

Petro123вадя,
off
- а зачем мне сервер будет спамить в браузер?
- сервлет в отдельном файле
а вот тут и есть преимущества - всё дело в трактовке .
если трактовать как спам - то да, это безобразие.
1)
а если тебе (опять очень грубый пример) нужно отображать изменения кучи параметров в браузере изменения случайны каждое изменение рекое, но таких изменений 20 в минуту .
ты своим способом будешь бомбить сервер на вопрос - покажи ка мне, а не изменилось ли что?
а если таких клиентов 50+
у тебя сервер будет работать в пустоту,
а если использовать "спам" - изменение пришло - сервер разослал "подписчикам" только изменённые данные и курит
2)
я выбрал клиента - уменя обновилось в окне несколько полей - сервер отправил несколько последовательно ответов для обновления этих полей и метод для обновления конкретного поля я использую многократно. в любоим месте. просто вызываю метод с нужным параметром - и он отправляет данные для обновления , нужно отобразить изменения 10 полей - сервер отправит 10 сообщений - ООП.

авторвадя,
1) у тебя ведь не такой проект? Мало ли каких проектов есть на свете.
Опиши свой проект...в отдельной теме.
100% что он уже есть в сети и учебниках.
Просто флейм неинтересен.
у меня именно такие проекты.
в сети такого нет, использование websocets в сети пока просто демонстрация чата на ws.
я нашел хорошую библиотеку для ws её несколько модифицировал (эти тонкости ws пока в инете не рассматривают)
и использую вариант wss (с шифрованием).
если есть желание можно в скапе обсудить
с удовольствием послушаю дельные замечания.

Basil A. Sidorovвадяа если тебе (опять очень грубый пример) нужно отображать изменения кучи параметров в браузере изменения случайны каждое изменение рекое, но таких изменений 20 в минуту .
ты своим способом будешь бомбить сервер на вопрос - покажи ка мне, а не изменилось ли что?Никто ничего бомбить не будет - сервер не обязан мгновенно отвечать "ничего не изменилось". Может подожать секунд пятнадцать и, если что-то изменилось - прислать данные. Не изменилось - вот тогда так и скажет.
Этакая авторегулировка частоты опроса.
опять очень грубый пример
можно найти решение, но если есть более простое - почему его не использовать?
нужно на клиенте делать таймер, чтоб раз в 15 секунд опрашивать. на сервере запрос чтоб "спал".
а если в эти 15 секунд потребуется сделать ещё какой запрос? более короткий? что его обработает на клиенте?
как ответ от первого? или ?