Такая ситуация.
Есть машина с Linux или Win, на которой крутится java-приложение (назовем его RfidReader).
На этой же машине запускается браузер (firefox), который грузит некоторый applet (назовем его RfidLogger).
Нужно обеспечить передачу данных между java-приложением (RfidReader) и applet-ом (RfidLogger).
Цель всего этого — заставить браузер реагировать на состояние RFID-считывателя.
Как вариант можно положить функционал java-приложения в applet, но вариант не очень удачный, так как существует еще одно приложение, которое взаимодействует с RfigReader-ом и его уже не положишь в applet и через JNI с ним обмениваться данными тоже не получится.
Здравствуйте, modelware, Вы писали:
M>Есть машина с Linux или Win, на которой крутится java-приложение (назовем его RfidReader). M>На этой же машине запускается браузер (firefox), который грузит некоторый applet (назовем его RfidLogger). M>Нужно обеспечить передачу данных между java-приложением (RfidReader) и applet-ом (RfidLogger). M>Цель всего этого — заставить браузер реагировать на состояние RFID-считывателя.
а зачем для этого апплет? по идее в RfidReader, который, как я понимаю,- обычное standalone-приложение, можно заембеддить http-серверок (jetty), и замонстрить в web sockets, либо даже попроще, если задача позволяет,- обычные сервлеты или даже jetty http-handlers, и поллинг со стороны браузера
Здравствуйте, C0s, Вы писали:
C0s>а зачем для этого апплет? по идее в RfidReader, который, как я понимаю,- обычное standalone-приложение, можно заембеддить http-серверок (jetty), и замонстрить в web sockets, либо даже попроще, если задача позволяет,- обычные сервлеты или даже jetty http-handlers, и поллинг со стороны браузера
Здравствуйте, frёёm, Вы писали:
ёё>Ну если апплет подписан можно через сокеты строить взаимодействие... ёё>Если не подписан...наверно только через сервер
Там Оракл сейчас накуралесил с безопасностью, так что может даже подписанный с локальным хостом не свяжется.
Здравствуйте, modelware, Вы писали:
M>Как вариант можно положить функционал java-приложения в applet, но вариант не очень удачный, так как существует еще одно приложение, которое взаимодействует с RfigReader-ом и его уже не положишь в applet и через JNI с ним обмениваться данными тоже не получится.
Аплет откуда грузится и для чего он вообще нужен? Ты пишешь что машина слабая, при этом смело запускаешь 2 Java процесса, вместо того чтобы поднять простой WebSocket сервер и обращаться к нему из браузера.
Здравствуйте, Blazkowicz, Вы писали:
B>Аплет откуда грузится и для чего он вообще нужен? Ты пишешь что машина слабая, при этом смело запускаешь 2 Java процесса, вместо того чтобы поднять простой WebSocket сервер и обращаться к нему из браузера.
Аплет нужен, чтобы осуществлять идентификацию пользователя в web-приложении через rfid-карточку.
On 13.01.2016 01:23, modelware wrote: > Такая ситуация. > Есть машина с Linux или Win, на которой крутится java-приложение > (назовем его RfidReader). > На этой же машине запускается браузер (firefox), который грузит > некоторый applet (назовем его RfidLogger). > Нужно обеспечить передачу данных между java-приложением (RfidReader) и > applet-ом (RfidLogger). > > Цель всего этого — заставить браузер реагировать на состояние > RFID-считывателя.
Общаться приложение и апплет могут (и наверное даже должны) через TCP
сокеты на localhost, но если браузер строго файрфокс — то я бы подумал
про написание плагина к нему, т.к. в свете тенденций отказа от NPAPI вся
дальнейшая судьба апплетов как технологии — под вопросом.
Здравствуйте, modelware, Вы писали:
B>>Аплет откуда грузится и для чего он вообще нужен? Ты пишешь что машина слабая, при этом смело запускаешь 2 Java процесса, вместо того чтобы поднять простой WebSocket сервер и обращаться к нему из браузера. M>Аплет нужен, чтобы осуществлять идентификацию пользователя в web-приложении через rfid-карточку.
Понятнее не стало. Почему именно для этого нужен апплет? Что он делает такого что не умеет JS?
Здравствуйте, modelware, Вы писали:
C0s>>а зачем для этого апплет? по идее в RfidReader, который, как я понимаю,- обычное standalone-приложение, можно заембеддить http-серверок (jetty), и замонстрить в web sockets, либо даже попроще, если задача позволяет,- обычные сервлеты или даже jetty http-handlers, и поллинг со стороны браузера
M>Было такое предложение, но машина очень слабая.
HTTP-сервер не даёт никакой особенной нагрузки на машину. Если на машине больше 16 МБ оперативной памяти, это вообще не стоит упоминания. Если, конечно, вы там не решите развернуть какую-нибудь WebSphere Portal Вторая JVM, обслуживающая запущенный апплет, займёт куда больше ресурсов, чем веб-сервер.
Единственный правильный вариант сегодня — запускать на localhost веб-сервер на каком-нибудь порту, а в веб-приложении с помощью JS соединяться с ним и взаимодействовать как душе угодно. Лучше всего через WebSocket.
А про апплеты забудьте. Они уже не работаю в хроме, они скоро не будут работать в FF. Это устаревшая технология.
Единственный тонкий момент будет с HTTPS. Могу расписать подробней. Если ваш сайт работает через HTTP, проблем не будет.
Здравствуйте, vsb, Вы писали:
vsb>Единственный правильный вариант сегодня — запускать на localhost веб-сервер на каком-нибудь порту, а в веб-приложении с помощью JS соединяться с ним и взаимодействовать как душе угодно. Лучше всего через WebSocket.
vsb>А про апплеты забудьте. Они уже не работаю в хроме, они скоро не будут работать в FF. Это устаревшая технология.
vsb>Единственный тонкий момент будет с HTTPS. Могу расписать подробней. Если ваш сайт работает через HTTP, проблем не будет.
Похоже это действительно единственный вариант.
Сайт на https. Распишите проблемы. Буду благодарен. Может через личку?
Здравствуйте, modelware, Вы писали:
M>Доступ к нативным библиотекам
А как же? M>и через JNI с ним обмениваться данными тоже не получится.
Теперь стало совсем не понятно какая роль у standalone модуля.
Здравствуйте, modelware, Вы писали:
M>Похоже это действительно единственный вариант. M>Сайт на https. Распишите проблемы. Буду благодарен. Может через личку?
Проблема следующая. Если сайт на HTTPS, то многие (все?) браузеры не дадут установить незащищённое WebSocket-соединение. Т.е. WebSocket-соединение тоже должно защищено через HTTPS-соединение. Значит ваш локальный веб-сервер на 127.0.0.1 должен принимать HTTPS-соединения. И, конечно, показывать браузеру сертификат, которому браузер будет доверять. Есть два способа сделать такой сертификат: либо сгенерировать самоподписанный сертификат для IP-адреса 127.0.0.1 и установить этот сертификат как доверенный в браузер (надо сделать один раз, но процедура не совсем тривиальная для пользователя); либо создать поддомен localhost.mywebsite.com, получить на этот поддомен нормальный сертификат от любого удостоверяющего центра и прописать в DNS адрес 127.0.0.1 для этого поддомена. Соответственно вебсокет открывать на wss://localhost.mywebsite.com:12345.
Второй вариант для пользователя самый простой (не нужно добавлять в браузер сертификат), но вам придётся распространять закрытый ключ вместе с вашим клиентским приложением. Это нарушение условий любого удостоверяющего центра и в теории ваш сертификат могут отозвать. На практике, конечно, вряд ли это случится.
Здравствуйте, hrensgory, Вы писали:
H>Общаться приложение и апплет могут (и наверное даже должны) через TCP H>сокеты на localhost, но если браузер строго файрфокс — то я бы подумал H>про написание плагина к нему, т.к. в свете тенденций отказа от NPAPI вся H>дальнейшая судьба апплетов как технологии — под вопросом.
Вторая JVM, обслуживающая запущенный апплет, займёт куда больше ресурсов, чем веб-сервер.
