So how does BizTalk Server actually work? BizTalk Server at its core is an event-processing engine, based on a conventional publish-subscribe pattern. Wikipedia defines the publish-subscribe pattern as:

Once a message is received by a BizTalk adapter, it runs through any necessary pre-processing (such as decoding) in BizTalk pipelines, before being subjected to data transformation via BizTalk maps, and finally being published to a central database called the MessageBox. Then, parties which have a corresponding subscription for that message can consume it as they see fit. While introducing a bit of unavoidable latency, the MessageBox database makes up for that by providing us with durability, reliability, and scalability. For instance, if one of our subscriber systems is offline for maintenance, outbound messages are not lost, but rather the MessageBox makes sure to queue messages until the subscriber is ready to receive them. Worried about a large flood of inbound messages that steal processing threads away from other BizTalk activities—no problem! The MessageBox makes sure that each and every message finds its way to its targeted subscriber, even if it must wait until the flood of inbound messages subside.

There are really two ways to look at the way BizTalk is structured. The first is the traditional EAI view, which sees BizTalk receiving messages, and routing them to the next system for consumption. The flow is very linear and BizTalk is seen as a broker between two applications.

However, the other way to consider BizTalk, and the focus of this book, is as a service bus, with numerous input/output channels that process messages in a very dynamic way. That is, instead of visualizing the data flow as a straight path through BizTalk to a destination system, consider BizTalk exposing services as on-ramps to a variety of destinations. Messages published to BizTalk Server may fan out to dozens of subscribers, who have no interest in what the publishing application actually was. Instead of thinking about BizTalk as a simple connector of systems, think of BizTalk as a message bus which coordinates a symphony of events between endpoints.

This concept, first introduced to me by the incomparable Charles Young (http://geekswithblogs.net/cyoung/), is an exciting way to exploit BizTalk's engine in this modern world of service-orientation. In the diagram below, I've shown how the central BizTalk bus has receiver services hanging off of it, and has a multitude of distinct subscriber services that are activated by relevant messages reaching the bus.

What exactly is a message anyway? A message is data processed through BizTalk Server's messaging engine, whether that data is transported as an XML document, a delimited flat file, or a Microsoft Word document. The message content may contain a command (for example InsertCustomer), a document (for example Invoice), or an event (for example VendorAdded). A message has a set of properties associated with it. First and foremost, a message may have a type associated with it which uniquely defines it within the messaging bus. The type is typically comprised of the XML namespace and the root node name (for example http://CompanyA.Purchasing#PurchaseOrder). The message type is much like the class object in an object-oriented programming language; it uniquely identifies entities by their properties. The other critical attribute of a message in BizTalk Server is the property bag called the message context. The message context is a set of name/value properties that stays attached to the message as long as it remains within BizTalk Server. These context values include metadata about the transport used to publish the message, and attributes of the message itself. Properties in the message context that are visible to the BizTalk engine, and therefore available for routing decisions, are called promoted properties.

How does a message actually get into BizTalk Server? A receive location is configured for the actual endpoint that receives messages. The receive location uses a particular adapter, which knows how to absorb the inbound message. For instance, a receive location may be configured to use the FILE adapter which polls a particular directory for XML messages. The receive location stores the file path to monitor, while the adapter provides transport connectivity. Upon receipt of a message, the adapter stamps a set of values into the message context. For the FILE adapter, values such as ReceivedFileName are added to that message's context property bag. Note that BizTalk has both application adapters such as SQL Server, Oracle, and SAP as well as transport-level adapters such as HTTP, MSMQ, and FILE. The key point is that the adapter configuration user experience is virtually identical regardless of the type of adapter chosen.

Receive locations have a particular receive pipeline associated with them. A pipeline is a sequential set of operations that are performed on the inbound message in preparation for being parsed and processed by BizTalk. For instance, I would need a pipeline in order to decrypt, unzip, or validate the XML structure of my inbound message. One of the most critical roles of the pipeline is to identify the type of the inbound message and put the type into the message context as a promoted property. As discussed earlier, a message type is the unique characterization of a message. Think of a receive pipeline as doing all the pre-processing steps necessary for putting the message in its most usable format.

A receive port contains one or more receive locations. Receive ports have XSLT maps associated with them that are applied to messages prior to publishing them to the MessageBox database. What value does a receive port offer me? It acts as a grouping of receive locations where capabilities such as mapping and data tracking can be applied to any of the receive locations associated with it. It may also act as a container that allows me to publish a single entity to BizTalk Server regardless of how it came in, or what it looked like upon receipt. Let's say that my receive port contains three receive locations, which all receive slightly different "invoice" messages from three different external vendors. At the receive port level, I have three maps that take each unrelated message and maps it to a single, common format, before publishing it to BizTalk.

Now that we have a message cleaned up (by the pipeline) and in a final structure (via an XSLT map), it's published to the BizTalk Server MessageBox where message routing can begin. For our purposes, there are two subscribers that we care about. The first type of subscriber is a send port. A send port is conceptually the inverse of the receive location and is responsible for transporting messages out of the BizTalk bus.

It has not only an adapter reference, adapter configuration settings, and a pipeline (much like the receive location), but it also has the ability to apply XSLT maps to outbound messages. If a send port subscribes to a message, it first applies any XSLT maps to the message, then processes it through a send pipeline, and finally uses the adapter to transmit the message out of BizTalk.

The other subscriber for a published message is a BizTalk orchestration. An orchestration is an executable business process, which uses messages to complete operations in a workflow. We'll spend plenty of time working with orchestration subscribers throughout this book.