Я настоятельно рекомендую вам пересмотреть решение Zebra websocket на этом этапе.
Лучшим решением по-прежнему может быть решение для мини-веб-сервера.
Мой опыт работы с решением для веб-сайтов Zebra: Предпосылки:
Сначала я попытался создать решение node.js (в нескольких местах я читал, что любой сервер выполним). Но после нескольких неудачных попыток подключения даже после получения сертификатов, подписанных Zebra, а также после успешного завершения процесса установления связи между принтером / сервером, он по-прежнему не работал с загадочной ошибкой, которая при проверке связана с попыткой принтера проверить, что конкретный Tomcat версия / сервер уже используется !!! ???
Я получил ответ от разработчика Zebra, который разрабатывает решение .Net, но также не может заставить его работать и ожидает дополнительной информации от «инженеров» Zebra, прежде чем они смогут завершить решение. Они сказали, что отправят информацию, когда она будет у них, и надеялись получить ее в течение недели (больше недели - пока не повезло).
Итак - я решил собрать сервер Tomcat - единственный пример, который работает Zebra ... Я запустил пример сервлета, но начал получать новые проблемы с сертификатами (поскольку я сменил серверы / домены и т. Д.). Это заставило меня задуматься обо всем неуклюжий процесс - и признал нарушение 1 сделки - очень ограничительный процесс аутентификации и подписи ssl слишком рискован.
Например. Допустим, у вас более 100 клиентов, полагающихся на это решение. Если у вас ВСЕГДА есть проблемы с сертификатом (например, изменение имени домена, изменение настройки сервера или недействительность / истечение срока действия сертификата) - то ВСЕ 100+ клиентов остаются без своего принтера. Но вы не можете просто исправить это самостоятельно - для исправления / создания нового сертификата и т. Д. Процесс повторной подписи медленный и зависит от внешних ресурсов! (это ручной процесс Zebra, кстати, вы отправляете по электронной почте, а затем вам приходится ждать значительное время, прежде чем сотрудник Zebra ответит подписанным сертификатом).
Это будет означать, что все 100+ клиентов не будут пользоваться услугами принтера в течение значительного времени, но у вас НЕТ ВАРИАНТА, кроме как заставить Zebra подписать ваш сертификат. Для меня это неприемлемый риск - (решение websocket НЕ должно зависеть от сертификата, подписанного Zebra - после всего, что вы устанавливаете ВАШ (или ВАШИ клиенты) принтер, вы затем настраиваете принтер, чтобы указать ТОЧНОЕ доменное имя / адрес для него подключиться к).
С вашим мини-сервером - если у клиента есть проблема - это повлияет только на этого единственного клиента, и вы НЕ полагаетесь на внешнюю компанию, чтобы подписать сертификаты для решения проблемы.
Вот выявленные проблемы и связанные с ними риски.
ПРОБЛЕМА 1) Очень плохо реализовано - я не могу (и они также не могут) заставить его подключиться к стандартному серверу, кроме ОЧЕНЬ специфической настройки Tomcat !!! УРОВЕНЬ РИСКА: НИЗКИЙ - т. Е. Это начальные затраты и временное бремя - но после работы постоянный риск возникновения этой проблемы, вызывающей дальнейшие проблемы, минимален. РИСКИ: а) Ограничивает разработку очень специфическими серверами и технологиями. б) Увеличение времени и затрат на первоначальную разработку / тестирование.
ПРОБЛЕМА 2) Плохо документировано - я обнаружил (и Zebra проверила) несколько ошибок в документации - документация также разбросана с важной информацией, брошенной в трудно найти файл readme.txt отдельно от остальной документации. УРОВЕНЬ РИСКА: НИЗКИЙ - то есть это начальные затраты и временное бремя - но после работы постоянный риск возникновения этой проблемы, вызывающей дальнейшие проблемы, минимален. РИСКИ: а) Замедляет начальное развитие. б) Увеличение времени и затрат на первоначальную настройку / разработку.
ПРОБЛЕМА 3) Безопасность принтера / проверка подлинности ssl плохо спланированы и реализованы. Он включает в себя несколько шагов - чрезвычайно ограничен и включает в себя медленный процесс подписи зебры, который создает постоянный риск. УРОВЕНЬ РИСКА: ВЫСОКИЙ - т.е. по этой причине мы не можем работать с этим решением. РИСКИ: а) Ограничивает разработку очень специфическими серверами и технологиями. б) Замедляет начальное развитие. c) Увеличение времени и затрат на первоначальную настройку / разработку. г) Создает постоянный ВЫСОКИЙ УРОВЕНЬ риска для проекта, а именно: ---> Идея состоит в том, что компания будет полагаться на это решение для подключения принтера - поэтому любое возможное время простоя приведет к СЕРЬЕЗНОМУ СЛУЧАЮ БИЗНЕСА. ---> ЛЮБОЙ из следующих сценариев будет означать, что ВСЕ клиенты, полагающиеся на это решение websocket, будут без услуг принтера в течение нескольких дней, пока будут организованы новые подписанные Zebra сертификаты: ---> 1) Срок действия сертификата истекает, 2) Сертификат недействителен, 3 ) Сервер перемещен, 4) Детали домена изменены, 5) Настройка сервера Tomcat изменена (из-за способа, которым принтер проверяет определенные настройки Tomcat / сервера) ---> Кроме того, вышеупомянутые 5 сценариев известны только на основе моего тестирования, поэтому далеко - могут быть другие возможные ограничения, которые могут означать сбои сертификатов, с которыми я еще не сталкивался.
Резюме: Проблема 3 IMO представляет собой неприемлемый риск, и должны произойти следующие 2 вещи, прежде чем я повторно рассмотрю веб-узлы Zebra. 1) Им нужна надлежащая документация о том, как веб-сокеты подключаются к серверу, поскольку он скрыт, и даже сотрудники Zebra в настоящее время находятся в неведении. 2) Им необходимо снять некоторые ограничения аутентификации, чтобы вы могли решить любую проблему без трудоемкого взаимодействия с Zebra.
person
Aaron
schedule
11.06.2015
