I was stopped by the words “Contract-Driven Messaging” in the article “An XML Guru’s Guide to BizTalk Server 2004, Part I” by Aaron Skonnard (“Contract-Driven Messaging”
http://msdn.microsoft.com/msdnmag/issues/05/11/ServiceStation/#S6)
What does in mean the “Contract-driven” in the BizTalk?
The contract in the BizTalk means the same thing as in WCF, the signatures of the objects (documents, messages). But not only the the objects with entry data but the with context data. For example, the addresses of the endpoint where those documents came, the delivery transport protocol etc.
http://msdn.microsoft.com/msdnmag/issues/05/11/ServiceStation/#S6)
What does in mean the “Contract-driven” in the BizTalk?
The contract in the BizTalk means the same thing as in WCF, the signatures of the objects (documents, messages). But not only the the objects with entry data but the with context data. For example, the addresses of the endpoint where those documents came, the delivery transport protocol etc.
What is it means from the BizTalk point of view?
In BizTalk almost all messages are in the internal XML format and have a type (which compounded of the target namespace and the root element of the schema of this message). Contract-Driven Messaging from the BizTalk point of view is the Message-type driven messaging, because in the BizTalk the “Contract” is exactly the message type. Plus the context of the message!
In BizTalk almost all messages are in the internal XML format and have a type (which compounded of the target namespace and the root element of the schema of this message). Contract-Driven Messaging from the BizTalk point of view is the Message-type driven messaging, because in the BizTalk the “Contract” is exactly the message type. Plus the context of the message!
How has the message got the type? The type is defined explicitly if the message comes to the BizTalk in the XML format.
How has the message got the type if it comes in other format, say comma-delimited text format? In this case the BizTalk uses the content and the context information to produce the message type. For instance, in EDI document the message type produced by the several data fields inside document and, maybe, the context information as an FTP address of the receive location of this document. And we have to explicitly map those input data set to the message type (as a namespace + the root node). Usually we don’t have the values from the input data to pass it implicitly or by some rule to the message type.
How has the message got the type if it comes in other format, say comma-delimited text format? In this case the BizTalk uses the content and the context information to produce the message type. For instance, in EDI document the message type produced by the several data fields inside document and, maybe, the context information as an FTP address of the receive location of this document. And we have to explicitly map those input data set to the message type (as a namespace + the root node). Usually we don’t have the values from the input data to pass it implicitly or by some rule to the message type.
OK, and what does it mean the messaging “driven” by?
It means transformation and routing.
Thansformations like mapping, batching/debatching, aggregating, copying.
Routing is a choosing the subscribers of the message.
It means transformation and routing.
Thansformations like mapping, batching/debatching, aggregating, copying.
Routing is a choosing the subscribers of the message.
And one more interesting aspect of the “contract-driveness”. With it the data could be processed automatically, without human intervention. Data has all intrinsic information to be processed.