How I got to experience service-oriented architecture in practice

I spent the past six months on interesting projects at one of the largest banks here in the Czech Republic. My biggest discovery was what I’d call SOA in practice. Before I saw it in action, it seemed so abstract that I couldn’t picture anything concrete. Unfortunately, it’s hard to find a three-letter acronym that’s been more thoroughly flogged. Strip away the flowery muck, though, and the idea itself is being put to work. I’ll sketch what that looks like in practice.

Until recently, banks built applications with monolithic architectures. The front end and back end were tightly coupled.

That arrangement puts more than one obstacle in your way. Above all, it’s hard to reuse what the boxes labeled back end and front end offer. To change that, you can hardly take the backbone of a banking system, its back end, start pulling out vertebrae and replace them with something new. The only workable approach is to expose back-end functionality through services. The attentive reader will have spotted the transition to SOA. Unfortunately, back ends are often prehistoric systems, and being able to return XML is a rare exception. Most use text or binary messages.

In practice, you need to expose services on infrastructure that lets you use what today passes for standard technology. An enterprise service bus (ESB) does this, handling conversions at both the transport and application protocol levels. The technology used is web services, SOAP over HTTP.

In this arrangement, the services exposed on the ESB define a model. With SOAP over HTTP, it’s a model for the messages the services receive and return. It has to cover all the information the back ends need, while remaining general enough to avoid binding the client tightly to a particular back-end implementation. It’s called the Canonical Data Model , or CDM.

The CDM serves as a kind of lingua francafor exchanging messages between systems. It’s coarse-grained, which isn’t obvious at first. It might not contain everything a particular client needs, or have it in a form suited to the application’s internal use. Take an address. The CDM defines it a certain way, but the front end or any client may need to add other things to it, such as a Skype or instant messaging account. Now we have three models, the last specific to that application.

The application model is mapped internally to the technology used to store or display it. Various technology-specific annotations get stuck onto it, or it’s bent into shape to make it easier to use. Each application has to map between its own model and the CDM. You can write that by hand or use a handy library like Dozer.

To complicate matters further, models have versions and need some governance. That’s beyond this article and into territory I haven’t explored.

Finally, a few words about something easy to miss but important. Development doesn’t happen in one big bang. Services are created and appear over time. They aren’t always available, and you can’t always use live systems for development. That’s why service simulators are getting a lot of attention. They make it possible, and much easier, to develop applications in an SOA environment. I’ll leave service simulators for another time.