Techniques for delaying change

Throughout this chapter (and hopefully the entire book!), we've been looking at building loosely-coupled services that accommodate flexibility and change. This includes direct bound ports that loosely coupled the messaging and orchestration layers, transforming messages at the edges to enable internal progression of components, applying explicit versioning attributes to schemas, and much more. Here, I'd like to investigate two ways to build solutions for volatile situations where change is constant and adaptability is vital.

Flexible fields

First, let's talk about situations where we want to future-proof parts of our schema that seem to be likely candidates for extension. In essence, we want to create a sort of flex field that enables us to stash additional information into the message even though there aren't explicit schema fields to hold that information. This is done through the use of the xsd:any element type. One example of using this is on an Address node...