BizTalk`s loose-coupling: message views

One of the things that really turns me on about BizTalk is how it truly enables loose-coupling via XML messaging. Like I said in this post, loose-coupling is a term that is often flung around but rarely achieved in practice especially by most of today`s Web services frameworks, which is ironic. Achieving loose-coupling throughout a system is typically accomplished by exchanging messages that both sides understand. However, the key to loose-coupling is enabling flexibility in the local interpretation of the contract.When System A sends an invoice message to System B, and System B is able to process it successfully, one could argue that it`s loosely-coupled. However, the local processing code running on System B is often tightly-coupled to the message contract, disallowing possible deviations. In this case, if the message coming isn`t valid according to the message contract, the system rejects the message and fails. This is an example of local code that is tightly-coupled against the message contract. A loosely-coupled implementation would simply look for the elements and attributes that it needs to function properly and ignore the rest.This is how most successful - and widespread - XML applications work today. RSS is a great example. There are numerous competing RSS-like formats and differing implementations. And on top of that, there are many invalid RSS feeds floating around the Web that we successfully consume. This is because RSS applications can be built in a way to look for the elements it absolutely needs to function and handle missing stuff gracefully. The key here is the flexibility in the local processing logic relative to the RSS formats.What`s interesting today is that most Web services frameworks generate services that are tightly-coupled to their message contracts. I find this interesting because despite that fact, they usually don`t provide built-in validation mechanisms. XmlSerializer tries to beloose, but doesn`t quite make it, plus the mapping to objects confuses the issue and drops XML`s flexibility on the floor.Since the code oneach side of the wire tends to be tightly-coupled, many of us argue that in order to ensure interoperability, one should start by defining the message contract andthen generate the implementation code for each side (contract-first). This typically ensures that both sides with produce/consume the same message formats.BizTalk is different. It BizTalkprovides out-of-the-box mechanisms for supporting numerous message formats that essentially convey the same information. For example, a given BizTalk business process (orchestration) can be defined in terms of a single XML message format (think of it as the "internal view") and then you can define multiple entry points (ports) for invoking that business process, each of which expects a different message format (an "externalview"), which may be communicated over different transport protocols. You can also define automatic transformations the will occur between the external/internal views when passing through a port. This is your chance to look for the pieces of information you care about - that you absolutely need to function properly - and map it accordingly, ignoring possible deviations. These transformations are most often between differing XML formats, but they can also handle non-XML formats as well. BizTalk takes things even further. In order to inspect messages as they travel through BizTalk, you must "promote" fields and properties on the message that BizTalk will make available to you. Ilike thinking of this asanother view of the message, similar toa database view. You define what parts of the message are needed within the business process (via promotions), then BizTalk takes care of making those available to you, while ignoring the other information found in the message as it travels through the system. This offers some powerful possibilities in the light of this discussion on loose-coupling.At the recent Indigo SDR, I had some interesting discussions with various folks on the possibilities of adding a similar feature to Web services stacks. Can you imagine a model where you author Web service signatures by mapping method parameters to XPath expressions that will be evaluated against incoming messages The mapped parameters would be equivalent to BizTalk`s notion of promoted properties. This ability would give Web service developers greater flexibility in building loosely-coupled endpoints capable of dealing with a variety of message variants.Obviously it would not be theright fit for every application, but it would give WS developers the IDispatch equivalent in a message-oriented world.Obviously, the implications of such a model would greatly impact the way I feel about contract-first development.