Silverlight 3 for Kiosk Apps? Of Course!

Several of the customers I work with are looking to build kiosk or point-of-sale applications with Silverlight. The ease of deployment with browser-based Silverlight applications is definitely appealing. Sharing applications or components between customers’ kiosks and web sites is another appealing reasons to go with Silverlight. This post outlines the architecture decisions between Silverlight and WPF and presents architecture options for Silverlight based solutions. A follow up post will discuss the Silverlight implementation details.

However, POS systems or kiosks often need integration with local peripherals, such as credit card readers, barcode scanners, printers, etc. Since Silverlight browser applications run in a sandbox access to these devices isn’t immediately available. Therefore we need to find a way to insert a bridge between the peripherals and the Silverlight application to read data from the devices and forward the data to the Silverlight app.

To get started, let’s look at applications that can communicate with local peripherals. Desktop applications can communicate with local devices. Devices usually ship with C++ or .NET libraries to read data or sink events from devices. Therefore Desktop applications are usually preferred for POS systems. Microsoft has a POS for .NET framework to simplify development of applications that need access to a wide array of peripherals. WPF offers a very compelling option to build the application UI and building the UI in WPF is a great step to share assets between the kiosk and the Web. The following table summarizes the decision points to decide between a full desktop application or a Silverlight app.

If the cons weigh too high and you really need a browser-based app, for example when you’re running in shared kiosk environments or if ease of deployment is much more important than peripheral integration, then you have a couple of options with Silverlight.

First, you can simply load the Silverlight application with a control hosted in a desktop application via the COM hosting interfaces. The host application can load the Silverlight application from a web URL, i.e. once you install the host application, you can still download the Silverlight application from the web. The Silverlight hosting interfaces even allow managing the download process, customize caching of .xap files and other resources through the IXcpControlHost interface.

For communication between the Silverlight app and the device manager running in the host application, the Silverlight application can expose an interface via the scriptable object bridge. That bridge is intended for communicating with the javascript engine of a web browser but it works in other containers as well. The scriptable object is accessible to the Win32 host via COM IDispatch interfaces, which the host application can invoke to send data to the embedded Silverlight application as shown in the diagram below.

You may at this point decide that the custom host is all you need, but may also want to run the application in a browser, for example because the Silverlight application integrates with an existing web site or you need to comply with an industry standard like CUSS.

In the past, applications installed a local web server like Cassini which hosted a .NET component that would communicate with local resources as needed. The Silverlight application would make REST calls to the “web server” which would handle the communication with a peripheral device or other local resources.

However, this approach had a couple of drawbacks. First, running a local web server requires administrator privileges and is often frowned upon because of potential security risks. Second, communication always had to be initiated by the Silverlight application. The peripheral could not send notifications to the application running in the browser.

With Silverlight 3 we have an alternative that doesn’t require a local “web server”. Silverlight 3 introduced the ability for Silverlight applications to communicate regardless what application container they are running in. One Silverlight application would send messages over a “named channel” with a LocalMessageSender object. Another Silverlight application can listen on that named channel with a LocalMessageReceiver object.

In our case the Win32 application could be an application without a visible UI that only acts as a bridge between the peripherals and the browser application.

In a scenario where the need for a local peripherals is limited to a single, well-known device, the effort to write a C++ host and communicate with the device in unmanaged code isn’t a daunting task. More sophisticated POS solutions may require more than one peripheral type. They may even require supporting different device configurations, i.e. bar code readers from different vendors. These types of POS applications typically require POS abstraction frameworks like POS for .NET. However, in that case the host application could be either a managed C++ application with C++ code to implement the COM host for the Silverlight “bridge” application and .NET code to manage peripheral interaction.

To close with some food for thought, there may be a completely browser based alternative that I haven’t tested out yet. Instead of running a Silverlight bridge in a separate Win32 application you could try to build a C++ ActiveX control to host the Silverlight “bridge” and the native device interaction code. This approach presents some security challenges that can be mitigated, but you still have to deal with the perceptions of pushing down an ActiveX control.

You do have the benefits of clean separation between a cross-platform application that run on any platform that supports Silverlight and the platform specific extensions that need to manage interaction with local peripherals. You also have the benefit of a fully browser-based deployment model.