Lynden is a family of transportation and logistics companies specialized in shipping to Alaska and other locations worldwide. Over land, on the water, in the air – or in any combination Lynden has been helping customers solve transportation problems for over a century.
freight tracking and cross docking system which consists of handheld barcode
scanners which are running a C# application on Windows CE (written in-house),
needed a reliable way to communicate with each other using our backend ActiveMQ
Java Message Service infrastructure. These devices include Symbol MC9090
handheld scanners, WT4090 wrist mount scanners as well as VC5090 forklift
mounted scanners (all pictured below).
MC 9090 Handheld Device
VC 5090 Forklift Mounted Device
WT 4090 Wristmount Device
There were a number of challenges integrating these devices which were running .Net software communicating via a Java messaging server. The original route we headed down was to use the .Net Messaging Service API (NMS) for ActiveMQ, with the devices communicating directly to the message broker. The NMS libraries are .NET assemblies that provide access to ActiveMQ via the native OpenWire protocol. This approach however proved to be an ineffective solution for the following reasons.
- We learned that the next release of the .NET Message Service API (NMS) library would be dropping support for Windows CE. So even if we wanted to continue this route we either couldn’t or we’d need to modify the NMS library ourselves to support our CE clients.
- NMS/OpenWire failover protocol was problematic on Windows CE. Even though we were only running 1 production messaging broker, we were using the failover protocol on the client since it provided a way for the client to automatically attempt to reconnect to the messaging broker should the connection go down. (This happens frequently on these devices).
- Unreliable network connections. To expand on the point above further, devices are constantly taken in and out of truck trailers where the Wi-Fi connections are spotty. Connections to the messaging system were not always getting properly cleaned up, and as a result, excessive resources would gradually be consumed over time on the broker which caused instability and occasional crashes on the server side.
In light of the above challenges it was decided to develop a proxy server to handle the communication between the CE devices and the messaging broker and act as a buffer for all the frequent disconnects/reconnects that the devices experienced. We had initially looked at the REST API provided by ActiveMQ, but due to lack of support for durable subscriptions at the time (it may support them now), we ruled that option out.
Apache MINA and the MINA State Machine Libraries
The Apache MINA libraries provide a way to create network applications in an efficient and scalable way. The framework makes use of Java NIO and features an event driven API which allowed for a very elegant design of the proxy server. Even better, the MINA State Machine (which has no official release at this time, but the code can be downloaded and built from the MINA Subversion repository) provided an easy way to manage various states of the messaging clients (ie. Connected, Subscribed, Unsubscribed, etc). The proxy will create a connection to the message broker on behalf of each connected client, maintain subscriptions to the various topics or queues that the client was interested in. If the client’s network connection disappears, the proxy will hold the connection to the broker open for up to an hour and if the client hasn’t returned by then, the connection to the broker is closed down in an orderly way.
An ASCII based protocol was
used as the communication medium between the clients and the proxy server which
would allow us to easily integrate other applications such as our Java
and .NET desktop clients. The desktop
applications’ connection to the messaging system are somewhat transient
(as users stop and start the application), although not as transient as
the device connections in the our warehouses.
The proxy would still provide a buffer between the clients and the
broker and clean up any unused resources. The ASCII protocol would also
allow us to tie in our legacy BASIC applications to the messaging system which
are running on the UniVerse database and application platform. Existing
server side Java applications would still be allowed to talk directly with the
broker because in theory, their connection to the messaging system should be
constant and stable. We are currently hosting the proxy server within our
Glassfish v3 application server with our other web applications since it
provides an easy way to manage the proxy's lifecycle. The chart below
illustrates the current paths the various applications in our system take to
access the message server.
One obvious weakness with the design that is illustrated above is that of failover support (or lack thereof). Even if we were to run multiple message brokers for fault tolerance, the proxy server itself is still a single point of failure within the system. Support for Java and BASIC clients as previously mentioned will also be at the top of our list of additions to make to our messaging solution.