Здравствуйте, 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.