Schemas define the messages that travel between our service endpoints and represent a core aspect of the service contract. As the need arises to reshape our schema to fit changing business needs, it's critical to understand the impact our choices have and strategies for minimizing impact on existing consumers.

What if we have an existing BizTalk schema exposed via a WCF service to client applications and decide to reorganize the underlying node structure of the schema? Alternately, what if we chose to remove existing schema elements and add new required ones? From our earlier discussion, this would seem to be a blatant breaking change. However, if you perform a vanilla exposure of a BizTalk schema as a service, these types of schema changes do not cause an immediate runtime exception in the client application, which is bound to earlier service versions.

At the beginning of this book, we talked about the fact that BizTalk receive locations are inherently "type-less"...