Есть J2EE приложение обслуживающее HTTP запросы то бишь банальное web приложение.
Цель научить приложение отвечать по другому протоколу. Скажем запросы принимаются из очереди сообщений ответы отсылаются в сокет.
Протокол суть некоторое подмножество HTTP — из него только надо POST и GET с параметрами и куками. Ответы вообще чистый HTTP — нормальный ответ сгенеренный приложением.
Насколько я нарыл на уровне J2EE ничего не предлагается (у того же оракла нашел как JMS сделать over http а мне надо наоборот ) только наличие интерфейсов ServletRequest и HttpServletRequest внушает некоторый оптимизм.
Решение "в лоб" конечно вижу. Отдельное приложение принимает сообщение из очереди делает локальный HTTP запрос и ответ отсылает куда надо. Хочется более элегантного решения чтоли с меньшим оверхедом.
PS: А в других контейнерах эта задача как то решается?
PPS: Это надо для работы в ДМЗ. Во избежание флейма сразу скажу, что о существовании прямых способов организации DMZ я в курсе. Интересует именно возможность общения с контейнером по другому протоколу. Причем именно JMS тут не догма а лишь вариант, теоретически меня интересует возможность хоть поверх SMTP работать.
Здравствуйте, GarryIV, Вы писали:
GIV>Ситуация такая
если я правильно понимаю проблему, то вижу три общих пути решения:
1) завязаться на фичу аппсервера. возможно, oracle уже эту задачу как-то решил, просто мы об этом не знаем. тогда — ответы в документации
2) написать коннектор к веб-контейнеру, который и реализует нужный протокол. насколько это сложно — не знаю, понятно же, что это будет зависимое от контейнера решение
3) решить задачу архитектурно. к примеру, у меня бы это выглядело как приложение на ejb, доступ к функциональности которого реализуется вручную по всем необходимым протоколам. т.е. доступ по iiop/rmi, а также в виде веб-сервисов типа как бы сразу есть, а всё, чего не хватает, пришлось бы писать самому
Здравствуйте, C0s, Вы писали:
C0s>если я правильно понимаю проблему, то вижу три общих пути решения:
Да правильно, все так и есть.
C0s>1) завязаться на фичу аппсервера. возможно, oracle уже эту задачу как-то решил, просто мы об этом не знаем. тогда — ответы в документации
Это я в первую очередь перерыл. Но пока безрезультатно...
C0s>2) написать коннектор к веб-контейнеру, который и реализует нужный протокол. насколько это сложно — не знаю, понятно же, что это будет зависимое от контейнера решение
О, спасибо! По этому кейворду я еще не искал. Зависимость от контейнера не пугает, наоборот чем больше написано за нас тем лучше.
C0s>3) решить задачу архитектурно. к примеру, у меня бы это выглядело как приложение на ejb, доступ к функциональности которого реализуется вручную по всем необходимым протоколам. т.е. доступ по iiop/rmi, а также в виде веб-сервисов типа как бы сразу есть, а всё, чего не хватает, пришлось бы писать самому
Этот вариант очевиден но неприемлим по соображениям сроков\денег. Необходимо чтоб существующие servlet->struts->jsp продолжали работать. Это ведь не полноценный протокол а как бы замена http. Или есть способ из ejb инициировать обработку запроса web контейнером с минимальным гемороем (без переделки прикладного кода)?
Здравствуйте, GarryIV, Вы писали:
C0s>>2) написать коннектор к веб-контейнеру, который и реализует нужный протокол. насколько это сложно — не знаю, понятно же, что это будет зависимое от контейнера решение GIV>О, спасибо! По этому кейворду я еще не искал. Зависимость от контейнера не пугает, наоборот чем больше написано за нас тем лучше.
скажем, в томкате это, если я правильно представляю, будет какая-то реализация org.apache.coyote.ProtocolHandler
но оговорюсь, я таким не занимался, оценить сложность не возьмусь
C0s>>3) решить задачу архитектурно. к примеру, у меня бы это выглядело как приложение на ejb, доступ к функциональности которого реализуется вручную по всем необходимым протоколам. т.е. доступ по iiop/rmi, а также в виде веб-сервисов типа как бы сразу есть, а всё, чего не хватает, пришлось бы писать самому
GIV>Этот вариант очевиден но неприемлим по соображениям сроков\денег. Необходимо чтоб существующие servlet->struts->jsp продолжали работать. Это ведь не полноценный протокол а как бы замена http. Или есть способ из ejb инициировать обработку запроса web контейнером с минимальным гемороем (без переделки прикладного кода)?
ejb здесь было неключевым словом. ключевым было выделение ядра, которое реализует логику. а уже вокруг ядра создаются реализации разных протоколов доступа к этой логике. т.е. технического трюка здесь нет, только лишь рацпредложение сделать всё по уму. но раз нет времени, то значит нет.
Здравствуйте, C0s, Вы писали:
C0s>Здравствуйте, GarryIV, Вы писали:
C0s>>>2) написать коннектор к веб-контейнеру, который и реализует нужный протокол. насколько это сложно — не знаю, понятно же, что это будет зависимое от контейнера решение GIV>>О, спасибо! По этому кейворду я еще не искал. Зависимость от контейнера не пугает, наоборот чем больше написано за нас тем лучше.
C0s>скажем, в томкате это, если я правильно представляю, будет какая-то реализация org.apache.coyote.ProtocolHandler C0s>но оговорюсь, я таким не занимался, оценить сложность не возьмусь
C open source гораздо проще дело обстоит...
C0s>>>3) решить задачу архитектурно. к примеру, у меня бы это выглядело как приложение на ejb, доступ к функциональности которого реализуется вручную по всем необходимым протоколам. т.е. доступ по iiop/rmi, а также в виде веб-сервисов типа как бы сразу есть, а всё, чего не хватает, пришлось бы писать самому
GIV>>Этот вариант очевиден но неприемлим по соображениям сроков\денег. Необходимо чтоб существующие servlet->struts->jsp продолжали работать. Это ведь не полноценный протокол а как бы замена http. Или есть способ из ejb инициировать обработку запроса web контейнером с минимальным гемороем (без переделки прикладного кода)?
C0s>ejb здесь было неключевым словом. ключевым было выделение ядра, которое реализует логику. а уже вокруг ядра создаются реализации разных протоколов доступа к этой логике. т.е. технического трюка здесь нет, только лишь рацпредложение сделать всё по уму. но раз нет времени, то значит нет.
Ядро есть и его завести по любому протоколу в случае необходимости не проблема. Проблема как заставить отработать presentation layer который тесно завязан на сервлеты с JSP.
Здравствуйте, GarryIV, Вы писали:
GIV>Ядро есть и его завести по любому протоколу в случае необходимости не проблема. Проблема как заставить отработать presentation layer который тесно завязан на сервлеты с JSP.
а, так ты хочешь сказать, что ответ надо отдавать всё тот же html?
Здравствуйте, C0s, Вы писали:
GIV>>Ядро есть и его завести по любому протоколу в случае необходимости не проблема. Проблема как заставить отработать presentation layer который тесно завязан на сервлеты с JSP.
C0s>а, так ты хочешь сказать, что ответ надо отдавать всё тот же html?
Здравствуйте, C0s, Вы писали:
GIV>>Ядро есть и его завести по любому протоколу в случае необходимости не проблема. Проблема как заставить отработать presentation layer который тесно завязан на сервлеты с JSP.
C0s>а, так ты хочешь сказать, что ответ надо отдавать всё тот же html?
Пообщался с представителем Оракла — посоветовал мой вариант "в лоб" из первого поста. Видимо на этом и остановимся за неимением лучших альтернатив...
Здравствуйте, GarryIV, Вы писали:
C0s>>а, так ты хочешь сказать, что ответ надо отдавать всё тот же html?
GIV>именно так.
очередная задача из серии "хочется странного"?
GIV>Пообщался с представителем Оракла — посоветовал мой вариант "в лоб" из первого поста. Видимо на этом и остановимся за неимением лучших альтернатив...
да, тогда я тоже думаю, что альтернатив толковых как бы нет
Здравствуйте, C0s, Вы писали:
C0s>>>а, так ты хочешь сказать, что ответ надо отдавать всё тот же html?
GIV>>именно так.
C0s>очередная задача из серии "хочется странного"?
Вовсе не хочется, мне по крайней мере Это специалисты одного_крутого_банка_заказчика хочут
Здравствуйте, GarryIV, Вы писали:
GIV>Вовсе не хочется, мне по крайней мере Это специалисты одного_крутого_банка_заказчика хочут
да я понимаю, что не тебе... слушай, а может у них просто консультанты подсказывают неверные пути решения проблем?
какова изначальная-то проблема? а то, вдруг, всё решается на уровне правильного системного администрирования?
) только наличие интерфейсов ServletRequest и HttpServletRequest внушает некоторый оптимизм.
Это специалисты одного_крутого_банка_заказчика хочут 
