The Microsoft BizTalk Server is basically a messaging system that is based on a model called Publish-Subscribe. This Publish-Subscribe model being an asynchronous programming technique allows information sharing between publishers (entities that send information) and subscribers (entities that receive information) smoothly. The Publish-Subscribe model gives two biggest advantages - scalability and flexibility.

The Publish-Subscribe model works as if one is addressing an audience through a speech so that the speaker is the publisher and the people in the audience are subscribers. The number of people in the audience is irrelevant; the only thing relevant is the way of information communication. The way in which the information is projected to the subscribers forms the scalability – reaching a larger number of people through a louder way.

For the speech (content) of the publisher too the number of people is unaccounted. In fact, during the speech existing listeners can leave and newer subscribers can enter at their will without affecting the publisher or the speech. Hence the publisher is not coupled with any individual subscribers and the number of subscribers too is anonymous for the publisher. This defines the flexibility of the BizTalk Server system.

BizTalk Server development allows the system to handle messages in the same way, i.e. the BizTalk Server (the speaker) publishes messages to a common area (the audience), and processes (the people) in that common area that are interested in consuming the published messages subscribe to them (orchestrations, receive or send ports, or directly bound ports).

Though, the Publish-Subscribe model isn’t meant to work for all subscribers receiving all messages. The model has a filter of interests that passes the messages related to the subject of which the subscribers have subscribed to. In BizTalk development there are two general filters – one to filter out messages based on their topics, and the other filters the messages based on their content.

So we are done with the Subscribers in the BizTalk development architecture and now for the Publisher’s part. One can publish messages in BizTalk through:

1> Sending a message to a receive port

2> Calling an orchestration from another orchestration

3> Creating a direct bound port (more about this in a future article)

4> Publishing messages for which there are no subscribers (known as routing failures)

BizTalk provides a robust platform for business processing as it can overcome any system failures including hardware and software. The SQL Server is majorly accounted for this robustness as it is BizTalk's message and configuration store. The SQL Server also stores and routes messages for BizTalk in addition to publishing and subscribing to them. MessageBox is the logical name for the common location and BizTalk SQL Server database where publications and subscriptions take place in the BizTalk Server. Other than the fact that it exists and that its implementation is an integral part of BizTalk development there’s nothing significant of the MessageBox for a developer.

Lastly, a message's type is defined by its XML representation, and is treated just like C# treats its own types. And during message passing too one cannot pass a string to a function that expects an integer, lest the compiler generates an error.