Setting up a Healthy Messaging Infrastructure

Setting up a national architecture for healthcare messaging is not simple. In the Netherlands, a national infrastructure is being rolled out based on XML, HL7v3 and Web Services. We’ll look at the problems encountered and their solutions – and we’ll do a little what-if RESTful exercise.

How does geography influence software design? The national healthcare messaging infrastructures of the Netherlands, the UK and Canada are very different. The underlying cause is their different geography.

What does a real infrastructure look like? It’s not just clients and servers, not just an added firewall. We’ll look at a typical healthcare scenario where a single message traverses several systems, XML-aware and not, before even reaching the firewall, and look at implications for the architecture. Most assumptions from a browser-based world are not valid anymore. Security poses a major problem for such environments, where tunneling messages over SSL is not an option anymore. We’ll discuss alternative security solutions and their merits.

Are WS-* standards plug-and-play components or not? For security and reliability there are supported WS-* standards. Unluckily, they introduce new problems while solving others. They do not compose well with a layered software architecture. Reliability is often very much an application-level consideration: how does this compose with a transport-level solution?

Just roll out the next version? Version changes are one of the most complex aspects of a messaging architecture. Most changes will break existing applications, and having many, many endpoints makes ‘big bang’ version changes impossible. We’ll look at approaches chosen to tackle the problems.

And how about REST? The Dutch architecture was set up using SOAP and WSDL at a time when REST was still a thesis, and RESTafarians where few and far between. The WS-stack has been a disillusion in some respects, but REST isn’t simply the holy grail. We’ll do a what-if RESTful redesign of the Dutch architecture and look at potential (dis)advantages. REST does not help much with reliability and security issues. Nor do the scaling advantages of REST come out well when all communication is tunneled over SSL. RESTful use or URI’s to identify everything – hypermedia containing state – does offer clear advantages. REST does not compose well with existing messaging infrastructures without a major redesign. The strengths of REST versus SOA align with the fundamental differences between messaging and publishing.