As BizTalk developers know, receive, business processing, and sending messages, occur in the process space of a Host Instance.

In this post, I’m interested in the receive and send processing:

Starting at the receive end, BizTalk Messaging Engine – also called Endpoint Manager or EPM – is responsible for hosting the receive port including the adapter and the pipeline.

The adapter picks the message from the wire and passes it to the Receive Pipeline. Within the pipeline, the message passes through the various components. Finally an optional map can be used to transform the message before being sent to the MessageBox.

The Message Agent sub-service – hosted within the BTSNTSVC runtime process – then passes the message to the Host queue for publishing into the Message Box.

The Host queue is represented by a set of tables inside the messagebox database. Each new host you create will have these tables created. For example, these are the queue tables created for the default in-process and isolated hosts:

So, the message finally is stored inside the messagebox. At this stage, note that the message context and message parts are stored in the messagebox…

The MessageBox also holds subscription information. These are the criteria that specified which endpoints are subscribed to receive published messages. For example, for a message published by the receive port, which orchestrations or send ports are subscribed to get this message.

Now at the send end, the Message Agent is periodically checking the subscriptions, and when it finds a send port whose subscribed to the message, it passes the messages to an optional map for transformation. Then the send pipeline gets the message which again goes through the components, before being sent via the adapter to the wire. Again the EPM is responsible for hosting the send port including the adapter and the pipeline.

The MessageBox is the database which holds crucial information for the functioning of BizTalk architecture. This includes:

–messages and their constituent message parts.

–Message context

–The subscription information required for the functioning of the publish and subscribe model. This includes a set of stored procedures that contain the logic for subscription matching.

–Persisted Orchestrations state

–Tracking data. The messagebox holds tracking information until they are moved into the tracking database.

Note that, as I showed you in the previous diagram, The Message Agent is the only way for any other BizTalk components to interact with the MessageBox. So practically, the MessageBox is abstracted by the Message Agent, which is the only component allowed to talk directly to it:

BizTalk messaging is based on the Content-Based Publish and Subscribe Architecture

The architecture says that:

–Systems that want to get messages, will have to register – or subscribe – their interest

–This subscription is based on certain criteria; for example, a subscriber might say that I want all messages of a certain type, or messages that came from a certain receive location such as a FTP, or messages that were transmitted over a certain protocol such as HTTP…and many other subscription criteria. Of course a subscriber might subscribe over a combination of criteria, for example, to get messages of a certain type that were received on a specific FTP location.

–Now when messages are posted – or published – into a message store. Their subscription criteria is evaluated; and accordingly the messages is delivered to those subscribers that match these criteria.

This architecture has 2 important characteristics:

–The nature of asynchronous messaging in this architecture, means that publishers and subscribers are not directly connected;

–and publishers do not know ahead of time what endpoints will subscribe to their messages.

BizTalk implements the content-based publish and subscribe model, using the following components:

First, the content upon which the subscription criteria are set, comes from message context. There is a dedicated section for this topic, but as a high level look, context properties are message metadata that can be either

 –system or user-defined

–system context properties are created (or more commonly known as promoted), using receive adapters and pipelines. Data such as receive port name, or the transport type, are examples of such system context properties

–user context properties are defined by developers, and they represent information of interest for the sake of application processing; for example the PO Number or the number of records of a repeating element.

Note that relying on context properties to define subscriptions is a concept known as Content-Based Routing or (CBR)

The next element required to implement the publish-subscribe architecture is a store for messages to be published to, and for subscription criteria to be stored in. This element in BizTalk is represented by the MessageBox database. Also the Message Agent, evaluates these subscriptions and deliver messages to the intended subscribers.

Finally, publishers and subscribers in BizTalk are represented by receive and send ports, as well as orchestrations. The role of components might vary between a publisher and a subscriber, based on the scenario.

I will elaborate on this in the next section.

So, the thing that’s obvious, is that Receive Ports are always publishers. Receive ports never get messages from the MessageBox. They always receive messages via adapters, and publish these messages into the messagebox.

Orchestrations, can be both publishers and subscribers. When an Orchestration is expecting a message via a Receive Shape, then its playing the role of a subscriber.

On the other hand, when an Orchestration is sending a message via a Send Shape, its playing the role of a publisher.

In the case, where an Ox is calling another Ox via the Call Ox shape; in this case, the caller Ox is the publisher, while the called Ox is the subscriber

Orchestrations also appear in an interesting scenario; which is called Direct Binding.

In direct binding, you do not bind logical ports within an Ox to any physical ports. Instead when using direct binding, Oxs exchange messages between each other without the involvement of physical receive and send ports.

In this model, an Ox publishes a message which is either targeted to a specific Ox, or to any Orchestration matching specific filters. You can think of this, as an “internal” publish and subscribe architecture.

There are 3 types of direct bindings, but a detailed discussion is outside the scope of this post.

Send ports can play the role of a publisher, in case of a Solicit-Response send port. Solicit-Response means that the port is sending a message and expecting a synchronous response from the destination application; for example from a request-response WCF service. In this case, the response message coming back to the send port will be published into the MessageBox.

Other than that, Send ports play the role of subscribers; as they subscribe for messages that then are sent out to the target destinations.

When the subscriber is an Orchestration, there are two types of subscriptions:

–The first type, is called Activation Subscription. This means that a message, when received by the subscriber – or the Orchestration – will start new instance of that Orchestration.

–The second type, is called Instance Subscription. This means that message is handed to an existing instance of an already running Orchestration instance.

For example, lets say that you have a PO Orchestration.

When the PO message is received for the first time, this kicks in a new instance of the orchestration; this is called Activation Subscription.

Now assume later in the process, that a confirmation message from an inventory system is required before the process can continue. This inventory message is given to the already running instance and will not activate a new instance. This is called Instance Subscription.