I had an interesting conversation with some folks in the standards community about this today. Many people thought that Web Services are over kill for the ATM environment. I sat back and thought about it for a moment, what I came up with is... Heck ya, we could use it on ATMs. So a common pitfall that technologist and architects fall into that debatable dialog that some of the time does not occur. Could I implement this or SHOULD I implement this.
From my perspective coming from the banking arena, it is advantageous for banks to move to the web service stack. It has never been easier (at least in theory) to move to this technology. Now that a good percentage of the ATMs are no longer using the legacy SNA protocol which was replaced by TCP/IP. Also many of the ATMs now run Windows XP instead of OS/2. So from a technology perspective it can be accomplished. When we look at the concerns for going to Web Services the common response is that the current bandwidth is minimal and this could move that up a bit. The short answer is yes it will, but not by much. We are still talking about text along the wire (XML). With the text is a more structure and a variety of web services behaviors to choose from. It can be as chunking as you want it. Banks want more technology at the ATMs to support rich user interfaces with functionality such as: check imaging / processing and support for portal type functionality to name just a few.
From a business perspective banks have been wanting to revamp the ATM functionality for years. Many banks see the ATM as an opportunity to Cross and Up Sell services. Imagine walking up to an ATM and being able to order checks or maybe change your address. Big efficiency gains, reduction of labor on the bank side and the customer feels empowered. This is especially beneficial for customers that do not use online banking. The cost of ownership could be reduced as well by using industry standard protocols. No more custom glue. Banks can now create agile back-end infrastructures that can handle tedious Mergers and Acquisitions for example. Having a consistent message layer to handle those ATM course grained services.
