Up to this point, I've discussed fundamental aspects of messaging and have provided a glimpse into what makes the BizTalk Messaging Engine so unique. Key to BizTalk Server's ability to provide reliable messaging is the SQL Server MessageBox
database. The MessageBox
is at the heart of the Messaging Engine and provides the core persistence for the publish-and-subscribe model on which the Messaging Engine is built. Every message received via an adapter is processed via a pipeline and serialized into the MessageBox
. Once a message is written to the MessageBox
, BizTalk takes ownership of the message. Based on metadata in the message, orchestrations or ports (covered shortly) subscribing to particular metadata are notified of message arrival and message events of interest.
In addition to providing reliable messaging, the MessageBox
supports the ability for orchestration to persist its state at various intervals within a workflow or business process. Orchestration instances can be dehydrated and later re-hydrated, providing the ability to suspend and resume long-running processes.
In BTS 2006, think of a port as a logical endpoint as well as an authentication and authorization boundary. In general, BTS 2006 supports two types of ports: send and receive. Depending on the intended direction, receive ports provide a conduit for consuming messages and send ports provide a manner in which to send messages.
In a messaging context, logical ports are associated with adapters (via physical ports) that define physical aspects of the endpoint such as protocol and URL or URI (including file UNCs or queue names).
For example, a port that is used to receive a file would be associated with the File adapter and a URI of C:\FileDrop would be specified to identify the location for submitting files. A port that is used to send a SOAP message might be associated with a physical URL such as http://localhost/MyService.
BizTalk is all about loose coupling and ports are one area where BTS 2006 really shines. Since ports are a logical construct, it is quite possible to define a receive port with multiple physical locations (known as receive locations). A receive location is paired with a corresponding adapter based on the transport or pseudo-protocol chosen. This level of abstraction allows for a service to be exposed via a SOAP URL, File URI and/or durable message queue, all the while insulating the business process from these low-level implementation details. This is especially true when configuring a port as dynamic.
Consider the following general port option characteristics:
Receive PortsRequest-response. Provides synchronous messaging support.
One-way. Provides for asynchronous "fire and forget" messaging.
Static/dynamic one-way. The directional inverse of one-way receive.
Static/dynamic solicit-response. The directional inverse of request-response.
Hosts and Applications
|Author's Note: Static send ports require physical configuration at design-time, whereas dynamic leaves this to a deployment-time decision. Not surprisingly, choosing dynamic send-and-receive ports is the best option for the ultimate flexibility and is recommended for production scenarios.
In BTS 2006, hosts provide a way to manage many of the messaging artifacts just discussed (such as ports, pipelines, and receive locations) into isolated or combined run-time processes. Services, orchestrations, pipelines, and receive locations can be factored out into different host instances, allowing you to scale out your BizTalk Server deployment. For example, a host instance is associated to a host where the host instance is actually a physical BizTalk Server. By creating multiple host instances for deploying send, receive, and processing artifacts, deployments can be tuned and evolve in accordance with changes in load.
There are two main types of hosts: in-process and isolated. In-process objects are hosted within the BTSNTSVC.exe process. Other services, such as SOAP services hosted by ASP.NET, run on IIS and are therefore isolated from the in-process run time.
Applications are a new feature in BTS 2006 that allow for the grouping of similar artifacts for ease of management. For example, you can organize ports, pipelines, orchestrations, and other artifacts within an application called RetailOperations, simplifying management and deployment of the artifacts as a single logical unit.