Xpoint
   [напомнить пароль]

Вопрос 3. А как бы Вы реализовали данную задачу?

Метки: [без меток]
2006-07-22 08:40:13 [обр] VSergeyV[досье]

АДАЧА. Необходимо реализовать распределенную программу, предназначенную для внесения изменений в БД/несколько БД, необходимо
предусмотреть, что БД может быть удаленно недоступна (что реально бывает часто).
Клиентский уровень необходимо реализовать с помощью Java Web Start, планируется что клиентский уровень общается с БД не на прямую а через какой-либо Java-сервер, на котором реализованы очереди и обработчик их - очередь поступивших заданий и очередь ответов клиенту о внесении изменений. На Java-сервере должнен быть некая "демоническая" составляющая, которая будет брать задание из очереди заданий и осуществлять попытку выполнить его, т.е. осуществить запрос к БД, в случае неудачи "демон" должен не убирать задание из очереди заданий, а в случае удачи убирать задание из очереди заданий и добавлять в очередь ответов клиенту необходимый ответ.

Клиентское приложение общается с Java-сервер допустим через SOAP либо RMI.

Вопрос 1. Как наиболее лучше реализовать очереди и обработчик очередей?
Еще к вопросу 1. Можно использовать очереди JMS и допустим EJB компоненты управляемые сообщениями? Компоненты управляемые
сообщениями вызывается тогда когда в очереди есть сообщения(объекты), более того насколько я помню, возможен вызов сразу нескольких обработчиков, каждый на одно сообщение, если в очереди более одного сообщения. При вызове обработчика - объекта EJB компонента управляемого сообщениями, происходит также автоматическое удаление объекта сообщения из очереди на которую он был "натравлен" для обработки. Если учеть, что допускается отсутствие соединения с БД, то необходимо будет сделать какую-нибудь задержку в EJB компоненте управляемом сообщениями...
Оправдано ли сделать "тупенький" демон - зацикленный код с задержкой, который смотрит очередь запросов, пытается их выполнить, а
также управляет очередями сообщений?
Есть ли более совершенный способы реализации этих демонов, чем зацикленный код?

Вопрос 2. Лучше использовать RMI или SOAP для взаимодействия клиентского приложения и приложения на сервере?

Вопрос 3. А как бы Вы реализовали данную задачу?

спустя 2 часа 5 минут [обр] 30-ый(59/584)[досье]

Вот только никаких самодельных демонов! Есть Application Server - его и используйте. Например JBoss.

Можно использовать JMS, можно EJB управляемые сообщениями (это собственно говоря надстройка над JMS). Если вы решите ограничится тольку JMS, то можете не связываться с полноценным сервером приложений, а подискать что-нибудь попроще.

У вас есть тут одна неприятность, которая AFAIK не покрывается стандартом J2EE. А именно "повторить запрос через N минут". Тут вам придется открыть документацию к выбранному Application Server'у и поискать решение там. Либо посмотреть на сайте Apache, там наверняка есть какой-нибудь Framework для этой цели. (Кстати можно в J2EE 1.5 посмотреть, может там уже есть.)

Если же эта "задержка" небольшая... типа десятков секунд, то можно просто подвесить на это время компонент JMS. Пусть он просто не возвращает управление и джет внутри себя. Но тут надо смотреть на количество клиентов и запростов, чтобы у вас пул компонентов не зашкалил.

Если у вас не планируется не-Джавных клиентов или каких-нибудь HTTP-прокси, через которые это все должно работать, я бы очень бы советывал отказаться от SOAP и RMI, а использовать напрямую средства удаленного доступа из EJB (по сути это тоже RMI, но обернутое в EJB'шный API).

Сказать точно, что делать - довольно сложно. Проект не простой и надо смотреть внимательно. В частности не нужны ли там чудом транзакции разбитые на несколько сообщений или какие-нибудь блокировки. Если нужны - то все в разы усложняется.

Кроме этого - а почем собственно "база данных может быть недоступна"??? Может стоит подумать о решении проблемы на этом уровне. Заменой сервера баз данных или организацией кластера. Кластер - это тоже не фонтан какая простая (да и не дешевая) задача, но вы по крайней мере будуте работать в рамках стандартных компонентов.

спустя 2 дня 10 часов [обр] VSergeyV[досье]
Просто, недоступность БД - мешает только при удаленном ее использовании, 99,999999999% - клиентских приложений для БД это локальные клиенты, находящиеся в одной локальной сети, вместе с БД...
Я не филолог чтобы правильно тему обозвать:(
спустя 1 час 48 минут [обр] 30-ый(59/584)[досье]

Да ну ее тему, вы бы с задачей определились :-)

Если вы ставите Application Server, будть он хоть сервером сообщений, хоть EJB-сервером. Так вот если вы ставите сервер приложений и он стоит в одной локальной сети с БД, то у вас 100% клиентов БД - локальное клиенты. Т.е. у БД будет только 1 (прописью: один) клиент - вышеупомянутый сервер приложений.

Плюс что-то мне цифра не нравится. Чтобы разработка распределенной системы для 0,000000001% пользователей себя окупила, у вас должно быть сотни миллионов пользователей в системе. Либо это должна быть какая-то система управления баллистическими ракетами, где такое расточительство оправдано.

спустя 24 дня [обр] Адамян Андрей[досье]
Я бы использовал для такой задачи JMS + наверное JAXM
JMS умеет заниматься всей той логикой о которой говорилось в задаче(постановка в очередь, ожидания доступности). А JAXM умеет организовывать постоянный асинхронный connection между клиентом и сервером. Протокол обмена SOAP.
Powered by POEM™ Engine Copyright © 2002-2005