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

После этого приложение может обрабатывать запросы пользователя, которыми является простая структура из текстовых и числовых параметров.
Результатом запроса является также некоторое множество объектов-структур. Пользователь может поставить на обработку сразу группу запросов, заняв приложение работой на десятки минут.
Приложение работает с интерфейсом на Swing.

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

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

2. Менеджер запросов просматривает очередь обработанных запросов и уведомляет клиента о завершении обработки.

3. Клиент может вводить запросы через веб-браузер, смотреть сколько обработано и просматривать результат.

Клиентская часть: веб-приложение Java EE; Желательно самое простое т.к. мне это еще предстоит изучать.
Сервер обработки запросов: имеющееся приложение Java SE, дополненное менеджером запросов.
Связь между двумя компонентами, как я понял, удобнее наладить одним из 2-х способов:
1. RMI;
2. Web-services;

Сама идея веб-сервиса хороша, но меня смущает то, что примеры подобных программ работают в виде HelloWorld. Как вы понимаете, я не планирую выполнять в веб-сервисе ресурсоемкие задачи. Веб-сервис должен только регистрировать запрос и уведомлять о его завершении (т.е. желательна связь в обоих направлениях). Меня интересует, могу ли я зарегистрировать как веб-сервис метод, являющийся частью выполняющегося Java SE-приложения и правильно ли вообще смотреть в сторону WS в такой ситуации.

Я ориентируюсь на этот пример http://java.sun.com/developer/technicalArt.../J2SE/jax_ws_2/
но он не дает мне ответ, как создать веб-сервис из работающего приложения.

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



Да ради бога, в вашем случае получается очень простая очередь.




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




Ну и зачем писать web сервис? Зачем вам RMI? Зачем 2-а компонента?

Если у вашего приложения нормальный API, не сплетенный намертво с представлением, то и разворачивайте свое
приложение на сервере. Со временем, если очень захочется, можете превратить его в web сервис - непонятно правда зачем делать сервис из монстра.


P.S. Я не знаю конкретно вашу задачу (и на сколько вы планируете в будущем масштабировать свое решение), но если вопрос только в удаленном доступе, но пользователю можно ставить толстого клиента со SWING, то я бы превратил такое приложение в обычный сервер с возможностью удаленного доступа клиентов к API сервера, вот тут уже можно по RMI, или что там у нас сейчас модно?

Как не крутите, но, при более-менее продвинутом интерфейсе, доступ через Интернет, по своему удобству напоминает надевание штанов через голову.
Как при разработке, так и для бедного пользователя.

Мне больше нравится то, что автор топика хочет сделать, т.е. раздельно два приложения. Если они будут на одном компьютере (слово "сервер" уже тут трудно использовать), или на разных, но в локальной сети, то для общения между ними стандартный вариант RMI. Веб-сервис для обмена между серверными компонентами в данном случае выглядит излишеством. 

Это сообщение отредактировал(а) COVD - 25.2.2011, 14:37

Вариант разворачивания отдельно сервера/ов приложений разумеется тоже имеет право на жизнь.

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

Мой же вариант наименее ресурсоемкий и может быть при реальном успехе легко масштабирован, в т. ч. и на работу с серверами приложений.

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

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

Вообще, описанная задача, на мой взгляд, хорошо вписывается в концепцию grid - вычислений. 

Есть очередь задач. Есть независимые ноды, т.е. приложения-исполнители. В данном контексте это "программа на Java SE, выполняющая ресурсоемкий расчет". Исполнители берут задачу из очереди и возвращают результат, берут новую... Если исполнителей больше одного, то их можно рестартовывать относительно безболезненно для системы. Время старта уже не столь критично. При возрастании потока задач количество исполнителей может быть легко увеличено.  "Дирижируют" этим хозяйством приложения типа http://hadoop.apache.org/ , http://www.gridgain.com/ и др. 
Или можно начать с ознакомления с http://www.jgroups.org/ , или  http://www.hazelcast.com/ Это удобней для внутрисерверного обмена, чем голый RMI. По крайней мере снимает необходимость прописывать сетевые адреса - приложения сами находят друг друга при старте.

Добавлено через 14 минут и 3 секунды

Я догадываюсь, что "доступ через Интернет" здесь, очевидно, используется как синоним  для "клиентское приложение (html, javascript ) работающее в браузере".  Потому что клиентское приложение на java Swing тоже может иметь доступ к серверу через Интернет (а не через локальную сеть). А так, да, есть определенные преимущества у Swing клиента. Или, другими словами, у "толстого" клиента.

а какое преимущество у Spring Remoting?

Хм, кажется так и есть (особенно с учетом больших требований к ресурсам), но только если сама задача имеет серьезное коммерческое значение и несет серьезную нагрузку.



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

Или хотя бы, если верить документации, тем, что "Spring's HTTP invoker is a good choice if you need HTTP-based remoting ...."
Т.к.
"When using RMI, it's not possible to access the objects through the HTTP protocol, unless you're tunneling the RMI traffic."

На самом деле ничего кроме tunneling быть не может. Т.е. на серверной стороне по-любому должен быть, грубо говоря, сервлет, который обрабатывает хттп:80 запросы и перенаправляет их в RMI  или в Spring. Возможно, Spring это делает более удобным для программиста способом. Особенно, если учесть, что Spring уже пролез практически везде . 

Там же начинается с прекрасной фразы "JAX-WS 2.0 is extremely easy to use." 

Они превращают приложение в сервис путем добавления в приложение классов встроенного веб-сервера, который по умолчанию принимает запросы на порту 8080. Это для теста, а для продакшн порт надо менять на 80. Если порт никем не занят, то приложение должно нормально стартовать.

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

  1. Проект не коммерческий, это исследовательское ПО, которое росло вместе с созданием алгоритмов, подготовкой данных, т.е. создавалось без начального ТЗ, на протяжении длительного времени. Для размещения на сервере приложений проект надо сильно рефакторить. Мне бы очень не хотелось иметь доступ через интернет такой ценой.
  2. Кроме того, поправьте меня, если я не прав, размещение на сервере приложений накладывает ограничения. Например, использование нескольких ядер процессора под отдельные потоки не удастся. Получиться ли использовать стороннее ПО, например, пакеты математических расчетов, я не знаю. Т.е. может и можно, но не будучи специалистом в EE я не хочу ломать работающее решение и экспериментировать.
  2. В качестве интерфейса мне видится именно веб-страница, потому что требования элементарные, они легко обеспечиваются средствами HTML. Любое дополнительное действие, которое должен выполнить пользователь для запуска нежелательно, поэтому я не хочу, чтобы пользователь устанавливал себе какое-либо GUI-приложение.
  3. Второй компонентой я предполагал то, что будет создавать пользовательский интерфейс, это мне казалось правильным делать на Java EE. Я новичок в серверных технологиях Java, но полагаю, смогу сделать простые вещи в приемлимое время. Начал разыскивать наиболее естественные пути связать веб-серверное приложение и имеющееся standalone, и с этой точки вышел на WS и RMI, после чего начал выяснять у сообщества.
  4. Что касается Hadoop и прочего, то да, это интересно, но у меня не стоит задача нарастить перформанс. Просто дать удаленному пользователю ввести запрос и через некоторое время увидеть в браузере результат.
  
  К сожалению, не успел поэкспериментировать с предложенными вариантами, но спасибо за оживленное обсуждение.

Это сообщение отредактировал(а) Alexander06 - 2.3.2011, 02:27

Всем спасибо, тему закрываю.