Имаме множество http(s) сървъри на Jetty, всички зад различни защитни стени. http сървърите са на сайтове на клиенти (не са под наш контрол). Отварянето на портове в защитните стени на тези сайтове не е опция. В момента тези сървъри обслужват само JSON документи в отговор на REST заявки.
Имаме уеб клиенти, които трябва да взаимодействат с даден http сървър въз основа на URL параметър или стойност на заглавка.
Това изглежда като проста ситуация с прокси сървър - с изключение на защитната стена.
Подходът, който опитвам в момента, е следният:
Имате централизиран прокси сървър (също базиран на Jetty), който слуша за входящи заявки за регистрация от отдалечените http сървъри. Заявката за регистрация ще бъде под формата на Websocket връзка, която ще се поддържа жива, докато отдалеченият HTTP сървър е наличен. При регистрация прокси сървърът ще улови връзката с уеб сокет и ще я съпостави с идентификатор на ресурс.
Уеб клиентът ще се свърже с прокси сървъра и ще включи идентификатора на ресурса в URL адреса или заглавката.
Прокси сървърът ще определи подходящия Websocket за използване, след което ще предаде заявката на HTTP сървъра. Така заявката и отговорът ще пътуват през Websocket. След като отговорът бъде получен, той ще бъде върнат на уеб клиента.
Така че всичко това е добре и добре на теория - това, което се опитвам да разбера е:
а) има ли по-добър начин да се постигне това?
b) Кой е най-добрият начин да настроите Jetty да извършва прокси в края на канала на HTTP сървъра?
Предполагам, че мога да използвам HttpClient на Jetty, но това, което наистина искам да направя, е просто да изтегля HTTP байтовете от websocket и да ги насоча директно към конектора на Jetty. Изглежда, че няма смисъл да анализираме всичко. Предполагам, че мога да отворя обикновена връзка със сокет на localhost, да взема байтовете от websocket и да го направя по този начин - но изглежда глупаво да маршрутизирам през операционната система по този начин (вече работя вътре среда Jetty на HTTP сървъра).
Със сигурност изглежда, че това е вид проблем, който може би вече е решен... Може би чрез използване на персонализирана връзка към кей, която работи на WebSockets вместо TCP/IP сокети?
Актуализация: докато си играех с това, изглежда, че друг труден проблем е как да се справя с поведението на заявка/отговор (и в идеалния случай да поддържам muxing през websocket канала). Един потенциален ресурс, който открих, е подпротоколът WAMP за уеб сокети: http://wamp.ws/
