Web services offer the advantage of providing a common framework of communication between different systems. The concept is powerful enough to bridge the gap between different programs, different development languages and different operating systems.
It should, therefore, not come as a surprise to know that payment systems users increasingly require their payment systems to connect to web services. Some payment systems are better at this than others. But I've found that the majority of payment systems have ISO 8583 so close to their heart that it's not as easy as it should be to use an external web service.
During the last few months, I've decided to tackle this in a generic way to allow payment systems to connect to web services at the backend. The approach is simple: create a SOA adapter that translates ISO 8583 to web service calls in a configurable way. The SOA adapter would connect to the payment system, receive an incoming ISO 8583 message, understand what is being said, call the appropriate web service and return the results to the payment system using an ISO 8583 response message.
This seems easy enough at first glance and it's a task that, in some form of another, most developers have encountered at some point of their career. Communicate with one system using its own language/API and translate what is being said to another system's language/API.
In the context of the SOA adapter, there is a complication. On the one hand you have web services that, more or less, use the same language. But on the other hand you have payment systems that use ISO 8583 in completely different ways that are often incompatible between each other.
One approach to tackle this is to create different flavors of the SOA adapter. This way you could end up with SOA.BaseI, SOA.Biciso, SOA.PostBridge and several other combinations that cater for specific needs. While this could solve the problem, it quickly adds up maintenance costs as it's necessary to keep track of different versions of the software.
The approach I've used is to code an ISO 8583 implementation generic enough to be able to read the application-level protocol from an XML configuration file. In this way, you have a single version of the software which comes with several configuration files so you just pick one that works for you. Plus, you get the benefit that you can implement an ISO 8583 customization by changing an existing XML file or by creating a new one; no code changes.
After completing this development exercise, the result is a clever piece of middleware that can be used to quickly connect payment systems to external web services using configuration only. The notion appears to be good enough to market. An end-user could connect the SOA adapter to their system, edit a few configuration files to describe their web services, their methods and parameters and SOA adapter just picks this info up and does the rest.
It may come as a surprise to some but the most difficult task which I'm still battling with is the creation of a user interface to drive the configuration. Strictly speaking, a config GUI is not required to use SOA adapter, especially when the technical background of potential end-users is considered. But, like my boss says, a GUI is more than just a necessary evil; it's the front end of the system and plays a major role in forming the perception users can have of the whole system.
