Hi @SG_10718850
That post only offers only half of the answer, because you are also asking "why only that protocol and why not other".
In short, you are not going to find an official description of why we have chosen this protocol, but overall I can tell you its advantages (assuming you've already read the post).
AlwaysOn is a proprietary PTC protocol, that is used by all PTC IIoT components when they interact with each other. If you know MQTT, at a low level it can be seen as similar to MQTT (because it opens a TCP connection that then it keeps open through keepalive messages), but after that it has a bunch of other capabilities outside of the MQTT realm. To recap, MQTT only works with messages (that it publishes, or receives if it subscribed to a topic).
AlwaysOn on the other hand, uses internally a REST-style communication structure, where it basically sends messages to a specific end-point (same end-point being always available also via REST to other clients). These end-points I speak are existing ThingWorx platform end-points, and since AlwaysOn existed since ~8-9 years, whenever you need a specific high-speed interaction with the platform, you always use AlwaysOn.
More important, AlwaysOn includes a binding mechanism, through which VirtualThings (client-side things) bind themselves to RemoteThings (server-side things), which then allow receiving property values, execution of remote services triggered from server, remote file transfer if needed.
Since we have a couple SDKs (also available for customer use), whenever you need high-speed data or fast time to act , Always-On is the logical choice, since all our EdgeSDKs (including what we used in Kepware) abstract the operations you need to do very nicely behind different high-level services.
Another very important thing is bandwidth. MQTT would use, as it is configured today in Kepware, ~30-40% more bandwidth, which, in industrial scenarios, is not exactly something you would want. Serializing the message using stuff like Thrift/Protobuff probably would reduce this bandwidth, but then it would complicate consuming that data on the client side.
So, overall, it's just the logical choice for ThingWorx, considering the available SDKs for AlwaysOn we have.
