Здравствуйте, GarryIV, Вы писали:
C0s>>а, так ты хочешь сказать, что ответ надо отдавать всё тот же html?
GIV>именно так.
очередная задача из серии "хочется странного"?
GIV>Пообщался с представителем Оракла — посоветовал мой вариант "в лоб" из первого поста. Видимо на этом и остановимся за неимением лучших альтернатив...
да, тогда я тоже думаю, что альтернатив толковых как бы нет
Здравствуйте, GarryIV, Вы писали:
GIV>Ситуация такая
если я правильно понимаю проблему, то вижу три общих пути решения:
1) завязаться на фичу аппсервера. возможно, oracle уже эту задачу как-то решил, просто мы об этом не знаем. тогда — ответы в документации
2) написать коннектор к веб-контейнеру, который и реализует нужный протокол. насколько это сложно — не знаю, понятно же, что это будет зависимое от контейнера решение
3) решить задачу архитектурно. к примеру, у меня бы это выглядело как приложение на ejb, доступ к функциональности которого реализуется вручную по всем необходимым протоколам. т.е. доступ по iiop/rmi, а также в виде веб-сервисов типа как бы сразу есть, а всё, чего не хватает, пришлось бы писать самому
Есть J2EE приложение обслуживающее HTTP запросы то бишь банальное web приложение.
Цель научить приложение отвечать по другому протоколу. Скажем запросы принимаются из очереди сообщений ответы отсылаются в сокет.
Протокол суть некоторое подмножество HTTP — из него только надо POST и GET с параметрами и куками. Ответы вообще чистый HTTP — нормальный ответ сгенеренный приложением.
Насколько я нарыл на уровне J2EE ничего не предлагается (у того же оракла нашел как JMS сделать over http а мне надо наоборот ) только наличие интерфейсов ServletRequest и HttpServletRequest внушает некоторый оптимизм.
Решение "в лоб" конечно вижу. Отдельное приложение принимает сообщение из очереди делает локальный HTTP запрос и ответ отсылает куда надо. Хочется более элегантного решения чтоли с меньшим оверхедом.
PS: А в других контейнерах эта задача как то решается?
PPS: Это надо для работы в ДМЗ. Во избежание флейма сразу скажу, что о существовании прямых способов организации DMZ я в курсе. Интересует именно возможность общения с контейнером по другому протоколу. Причем именно JMS тут не догма а лишь вариант, теоретически меня интересует возможность хоть поверх SMTP работать.
Здравствуйте, 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?
Пообщался с представителем Оракла — посоветовал мой вариант "в лоб" из первого поста. Видимо на этом и остановимся за неимением лучших альтернатив...
Здравствуйте, C0s, Вы писали:
C0s>>>а, так ты хочешь сказать, что ответ надо отдавать всё тот же html?
GIV>>именно так.
C0s>очередная задача из серии "хочется странного"?
Вовсе не хочется, мне по крайней мере Это специалисты одного_крутого_банка_заказчика хочут
Здравствуйте, GarryIV, Вы писали:
GIV>Вовсе не хочется, мне по крайней мере Это специалисты одного_крутого_банка_заказчика хочут
да я понимаю, что не тебе... слушай, а может у них просто консультанты подсказывают неверные пути решения проблем?
какова изначальная-то проблема? а то, вдруг, всё решается на уровне правильного системного администрирования?