The MessageBox
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.
Ports
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 Ports
One-way. Provides for asynchronous "fire and forget" messaging.
Request-response. Provides synchronous messaging support.
Send Ports
Static/dynamic one-way. The directional inverse of one-way receive.
Static/dynamic solicit-response. The directional inverse of request-response.
| 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. |
Hosts and Applications
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.
Previous Page
