As part of the Real World Windows Azure series, I talked with Davide Bedin, Chief Technology Officer at BEDIN Shop Systems, about how the company took a long-term strategic bet on Windows Azure to deliver their aKite retail management solution. Here’s what he had to say:
David Ingham: Tell us about your company and the aKite service you offer to your customers?
Davide Bedin: BEDIN Shop Systems, based in Cornuda, Treviso, Italy, has more than 20 years of experience in developing point-of-sale (POS) and in-store systems for retailers. We have established an international reputation for pioneering the use of Microsoft technology in solutions for small to large-sized retailers, independent stores, and chains.
aKite is a point-of-sale and in-store Software as a Service (SaaS) solution, designed entirely on Windows Azure. The aKite Retail Web Services, hosted in Windows Azure, save and analyze data, and connect stores with the headquarters and any other external Web service.
Two smart client applications, POS.net for front store operations and SHOP.net for back office tasks, work disconnected and cooperate in a peer-to-peer way, therefore no server is needed in the store. This is a key advantage as this often-underutilized server would be a single point of failure and consume unnecessary energy.
aKite removes complexity from the store, making life simpler for retailers. aKite also provide economic benefits, as no capital investment is required, just an all-inclusive per-seat and per-store charge. Deployment is simple too – ClickOnce install allows a broken PC to be replaced, or even a new store opened, in just a matter of minutes.
DI: What were the main challenges you were trying to address using a message-based architecture?
DB: The first challenge was synchronization of data between the smart clients and the Retail Web Services, hosted on Windows Azure. Price list updates are one concrete example that requires event notification from the Web Services to the smart clients. This isn’t difficult at small scale but aKite supports many moderate-sized chains and some very large ones with many stores, so the aggregate task of distributing such notifications represents a real challenge. aKite provides the ability for retailers to prepare such updates in advance but there is still a requirement to propagate the updates to the clients as fast as possible. There are also situations where a retailer may need to make such updates with little notice even when hundreds of stores are involved. The traditional approach to addressing this problem would be to have the clients intensively poll a Web service, checking for updates. This technique has the obvious downside of consuming resources on the Web service. Windows Azure Service Bus is a much better fit as it provides an efficient way to push events to the clients and allows the application to focus on its core job.
After gaining experience using Service Bus for this synchronization scenario, we learned more about its elegance and potential. We saw that it could dramatically help the asynchronous messaging between the components that make up the aKite Retail Web Services: the goal here was to find a solution that reduced load on the database, in which messages were stored, as well as improving resiliency and reliability.
DI: How did Service Bus help solve these technical challenges?
DB: In general, Service Bus allows us to concentrate on the aKite business logic only, relieving our services from the dealing with event notification and messaging. For the synchronization scenario, the adoption of Service Bus translated into 60% less calls to the aKite Retail Web Services coming from clients. We also saw improved performance in sending and consuming notifications.
Service Bus has allowed us to create a loosely coupled architecture for both the client-to-service connectivity and also between the components that together comprise the Retail Web Services – we are able to focus on the business content of the messages rather than their delivery. Components simply send messages to Service Bus queues and topics, without being aware of the component that will ultimately process it. This loose coupling allowed us to creatively combine different scenarios together and will let us easily support new unexpected scenarios in the future. For example, should the need arise to create a new service component that processes server events in a new way, then a new subscription can be created with a filter to match only the messages that are relevant for the new scenario.
In my point of view, introducing Service Bus into the service architecture brings more value than just addressing our immediate needs, it provides a level of “future proofing” that means we should be able to react to changes and evolution over time in a richer and faster way.
DI: What messaging scenarios did you actually build using Service Bus?
DB: We currently rely on Service Bus to support many different scenarios. As I mentioned, the first scenario we approached is the notification of data updates and other information to the aKite smart clients running in the stores. Notification messages are sent to a Service Bus topic. Properties on the message identify which stores should receive the notification. Each client has its own subscription to the topic with a filter that ensures it only receives the relevant messages. Preparation and notification of updates happen in response to events signaled by any service component of aKite. These events are also represented as messages sent to a Topic and consumed from a subscription by a worker role.
In another scenario, each front-of-store POS.net client sends sales documents to the aKite Retail Web Services via Service Bus queues. The queues help us to respond to sudden and unforeseen changes in the sales activity of a chain of stores. A number of worker role instances are always listening to the queues for incoming messages. The load-leveling nature of the queues means that peaks and troughs in load are easily accommodated – queue lengths simply grow and contract. Should the situation arise that overall load consistently increases then more worker role instances can be added to share the work.
Another Service Bus messaging pattern is used within the Retail Web Services. A sales document from a POS.net client passes through several different steps as part of the backend processing, many of which are either computationally intensive or require extensive interactions with the database. Each of these steps is performed by a worker role and communication between the roles is achieved with Service Bus topics. Each worker role listens to a number of subscriptions, each subscription carrying data for either a whole chain of stores or, in the case of a large chain, a subset of the stores. Upon completion of its work, each processing step sends a message to the topic to pass the document to the next step. The different worker roles are able to dynamically and automatically split the overall workload among the different worker instances resulting in a very flexible and architecture that is able to scale appropriately to deal with system load.
DI: How would describe the developer experience when working with Service Bus?
The Service Bus object model is clear and the usage scenarios described by the samples and documentation cover many possible use-cases. Having Service Bus baked directly into the Windows Azure client library is an additional simplification.
We were early adopters of Service Bus and as is often the case with nascent technologies, there initially wasn’t much tooling support available. The arrival of the Service Bus Explorer tool has been, and continues to be, an extremely important tool to explore, debug and test Service Bus.
DI: Have you rolled out your solution (service) to the end customer?
Yes, Service Bus now supports every user of aKite. We are continuously rolling out new features and improvements and every customer, existing and new, big or small, benefits from the continuous growth of the product.