mr.JackПроблема в том, что время работы сервлета зависит не от него самого. Сервлет должен обращаться к некоторым сторонним приложениям, он, своего рода мост между клиентом и другими приложениями. По этому, пока сервлет не соберет данные с приложений - полный отчет для клиентов не будет доступен. Что бы хоть как то ускорить отображение данных я подумал про описанный в первом посте сценарий. Кроме того, отчет для этого клиента должен быть получен только им самим, доступ других клиентов к чужому отчету нужно ограничить. Вот именно в этом ключе мне необходимо решение.
Компанент получает от клиента задачу. (Вопрос а нахера нам тут именно сервлет вообще оставим открытым).
Он раскладывает эту задачу на подзадачи и складывает в очереди (JMS/MQ).
Обработчики, забирают сообщения из очереди и отправляют 3м-сторонам. (Это всегда синхронно, или с вариантами?)
Полученые от 3х сторон результаты складываются в базу. Через очередь идёт нотификация "центральному обработчику результатов".
Обрабочик результатов на каждое сообщение проверяет, готов ли результат целиком. Если готов, то оправляет его клиенту.
Для начала вам стоит изобразить эту схему на квадратиках и затем для каждой стрелочки и каждого блока подбирать конкретное решение, потому что их масса:
- Получение запроса. Сокет vs HTTP. Скорее всего лучше HTTP, сокет нужен только для достижения большой производительности.
- Протокол. Если нагрузка огромная, то лучше бинарные кроссплатформеные - hessian, protobuf. Если пофиг, то XML, но не просто XML а SOAP Web Service. С другой стороны и RESTful с JSON модно и современно.
- SOAP Web Service как проще всего реализовать? Правильно! JAX-WS (но есть и варианты Spring-WS, CXF)
- RESTful - Spring MVC или JAX-RS.
- Очередь... тут вообще масса вариантов. Apache MQ, вроде довольно популярная из бесплатных.
- Отдельный вопрос это как организовать асинхронное общение с клиентом. Держать ли запрос через Comet, или всё же просто выдавать статус по переодическим запросам.
... и это мы ещё не подошли к тебе EJB
Обязательно ли использовать Tomcat? Если вам лениво разбираться в море технологий, можно взять, например, JBoss и там половина из вышеперечисленного уже реализована, дополнительных библиотек не понадобится.
mr.JackThe web container initializes a servlet after loading and instantiating the servlet class and before delivering requests from clients.
перевод : веб контейнер инициализирует сервлет после загрузки и создания экземпляра класса сервлета и после доставки запроса от клиента.
От "клиентов". В общем случае, экземпляр сервлета один.
mr.JackТ.е., получается, после каждого запроса.. да, я что то не так понял похоже. А как правильно? Где почитать/посмотреть можно?
Читать в спецификации
http://www.oracle.com/technetwork/java/index-jsp-135475.html
mr.JackМожете отсюда подробнее? Пока нашел вот это,
http://tomcat.apache.org/tomcat-5.5-doc/catalina/docs/api/org/apache/tomcat/util/threads/ThreadPool.html , ищу более подробные описания, примеры, так как, повторюсь, пока сложно мыслить "в среде".
Просто поверьте наслово, все серверы работают с пулами потоков. Кроме совершенно экзотических.
mr.JackИз того, что я понял из беглово ознакомления с JMS, Вы имеете ввиду модель "от пункта к пункту". Применительно к моей задаче, можно реализовать так: сервер периодически посылает сообщения клиенту и получает отклик. Если ответа нет - то клиент потерян. Верно?
Вам нужно асинхронно послать задачи в третьи системы, получить ответ и асинхронно отдать ответ клиенту. Ассинхронность реализуется через очереди (Message Queue). В JEE спецификация называется JMS. Но можно использовать и другой API.
mr.Jack1. В качестве контейнера сервлетов используется tomcat. Для него нужно накручивать сторонние разработки, вот это например
http://tomee.apache.org/tomcat-jms.html . Это хорошая идея?
Если вы хотите использовать JEE стэк (JMS, JAX-WS), то лучше взять полноценный сервер. Если томкат - обязаловка, то да. Надо прикручивать готовые решения самостоятельно.
mr.Jack2. Как я понял, использование JMS возможно, если обе стороны имеют Java в качестве платформы. В моем случае это не так, платформа будет совершенно другой.
JMS вам нужен для асинхронных операций внутри сервера. Комуникация с клиентом это отдельная тема.
mr.JackБыла мысль про JSON, почему то я ее откинул. Наверно JSON даже удобнее. Но, Вы видимо спросили не просто из любопытства, вероятно есть что то о чем я пока не догадываюсь и Вы можете поделиться?
Бинарные протоколы быстрее. Текстовые протоколы имеют более широкое распространение (браузеры, мобильные девайсы)
Смогут ли ваши не Java клиенты работать с вашим JSON мы не знаем. А смогут ли они это делать асинхронно? А если смогут, то как, через висящий запрос или обратный адрес?
mr.JackКлиенты - другие платформы. Про зависимость от протовола - согласен, нужно сделать так, что бы зависимость была не сильной.
Какие другие платформы? Вообще любые? Или какая-то конкретная?
