I strongly suggest you re-consider the Zebra websocket solution at this point.
The best solution still might be the mini web server solution.
My experience with a Zebra websocket solution:
Background:
I initially tried creating a node.js solution (I had read in several places that any server is doable).
But after a few failed connection attempts even after getting Zebra signed certs - and the printer/server going through a successful handshake process - it still failed with a cryptic error, that when looked into is related to the printer trying to verify that a particular Tomcat version/server is being used!!!???
I did get a response from a Zebra developer who is developing a .Net solution but is also unable to get it working and is waiting on further information from the Zebra 'engineers' before they could complete the solution. They said they would send through the information when they had it and hoped to get it within a week (more than a week - no luck yet).
So - I decided to put together a Tomcat server - the only example Zebra has working... I got the example servlet running but started getting new cert problems (as I had changed servers/domains etc.)
This got me thinking about the whole clunky process - and recognised the 1 deal breaker - the very restrictive ssl authentication and signing process is just too risky.
E.g. Lets say you have 100+ customers relying on this solution.
If you EVER have problems with the cert (e.g. domain name change, server setup change or cert invalidation/expiry) - then ALL 100+ customers are without their printer.
But you can't just fix it yourself - To fix/generate a new cert etc. re-sign process is slow and reliant on external resources! (this is a manual Zebra process btw - you send via an email and you are then left waiting considerable time before a Zebra employee responds with a signed cert).
This will mean that all 100+ customers are without printer services for considerable time but you have NO OPTION but to have Zebra sign your cert. To me this is an unacceptable risk - (the websocket solution should NOT be reliant on a Zebra signed cert - after all you are installing YOUR(or YOUR clients) printer you then configure the printer to specify an EXACT domain name/address for it to connect to).
With your mini server solution - if a client has a problem - it will only affect that single customer and you are NOT relying on an external company to sign certs to fix the problem.
Here are the identified problems and their associated risks.
PROBLEM 1) Very poorly implemented - I cannot (and they also cannot) get it to connect to a standard server other than a VERY specific Tomcat setup!!!
RISK LEVEL: LOW - i.e. it's an initial cost and time burden - but once working the ongoing risk of this problem causing further issue is minimal.
RISKS:
a) Restricts the development to very specific servers and technologies.
b) Increased time and costs to initial development/testing.
PROBLEM 2) Poorly documented - I have identified (and Zebra have verified) several mistakes in documentation - documentation is also scattered with important information thrown into a hard to find readme.txt file separate to the rest of the documentation.
RISK LEVEL: LOW - i.e. it's an initial cost and time burden - but once working the ongoing risk of this problem causing further issue is minimal.
RISKS:
a) Slows initial development.
b) Increased time and costs to initial setup/development.
PROBLEM 3) Printer security / ssl authentication is poorly planned and implemented. It involved multiple steps - is extremely restrictive and involves a slow zebra signing process that creates an ongoing risk.
RISK LEVEL: HIGH - i.e. This is the reason we cannot work with this solution.
RISKS:
a) Restricts the development to very specific servers and technologies.
b) Slows initial development.
c) Increased time and costs to initial setup/development.
d) Creates an ongoing HIGH LEVEL risk to the project as follows:
---> The idea is that a company would rely on this printer connection solution - therefore any potential downtime would cause MAJOR BUSINESS DISRUPTION.
---> ANY of the following scenarios would mean ALL customers relying on this websocket solution would be without printer services for several days while new Zebra signed certs are organised:
---> 1) Cert expires, 2) Cert is invalidated, 3) Server is moved, 4) domain details change, 5) Tomcat server setup is modified (due to the way the printer verifies certain Tomcat/server settings)
---> Also, the above 5 scenarios are only known based on my testing so far - there could be other possible restrictions that could mean cert failures that I have not come across yet.
Summary:
IMO Problem 3 poses an unacceptable risk and the following 2 things need to happen before I would re-consider Zebra websockets.
1) They need proper documentation on how the websockets connect to a server as it is hidden and even the Zebra employees are currently in the dark.
2) They need to remove some of the authentication restrictions - so that you can fix any problem without a time consuming Zebra interaction.