BizTalk Server provides many features that enable organizations to continuously improve their business processes, their level of customer service and their bottom line; however, most .NET developers and architects have never examined the product. This article will introduce the reader to many of BizTalk's features and discuss their benefits.

BizTalk Artifacts
The first BizTalk feature discussed in this article is composed of four artifacts that are used in almost all BizTalk applications: schemas, maps, orchestrations, and pipelines. Each of these artifacts has a related Visual Studio designer.

SCHEMAS
Schemas are simply XML Schemas. Schemas are templates for the messages that BizTalk receives, processes, and sends. They are edited in Visual Studio using the BizTalk Schema Editor that comes with BizTalk. Schemas are the base BizTalk artifacts and they are like normal schemas except they may have BizTalk-specific schema annotations. These annotations are used as context for BizTalk items such as flat -file-to-XML conversions, EDI-to-XML conversions and promoting context properties used in routing messages.

MAPS
Maps transform messages from a source schema format to a target schema format. They are created with the BizTalk Mapper, a visual tool used to map between schemas by drawing lines from source to target and by using functoids. Functoids are BizTalk components that provide encapsulated functionality for doing things like Boolean logic and string manipulation. Maps can also be created by importing custom XSLT into the BizTalk Mapper.

Orchestrations are visual representations of business processes that are created with the Orchestration Designer. The Orchestration Designer has many shapes associated with it including decision, loop, scope (sometimes similar to the .NET try-catch statement), receive, send, etc. The Orchestration Designer has an Orchestration View window used to create types in the orchestration as well as to set their properties. Orchestrations provide an intermediary artifact between code that would be written in C# or VB.NET and a diagram that would be created in Visio. As such, they're excellent artifacts for communicating between technical and business users.

PIPELINES
After BizTalk gets a message via an adapter (see below), the adapter passes the message to the BizTalk Messaging Engine that subsequently sends the message through a pipeline. Pipelines are where pre- (when receiving) and post- (when sending) processing occurs in BizTalk. Pipelines are edited using the Pipeline Editor. Receive pipelines almost always convert the incoming message to XML. They also support decoding (unencrypting, unzipping, etc.) and certificate resolution. Send pipelines are used for converting XML messages to non-XML formats and for encoding (encrypting, zipping, etc.) messages.

These four artifacts provide a framework for developing business process and integration applications. Each has specific responsibilities related to it, which makes solution design and implementation easier and less time consuming. The graphical editors associated with the artifacts are also beneficial due to their ability to abstract the implementation away from pure source code. Many organizations have homegrown integration and messaging frameworks that have similar concepts to the four artifacts mentioned. Now BizTalk's core features and their benefits will be reviewed so that readers understand why BizTalk is more useful than most homegrown frameworks.

Core BizTalk Features
PUBLISH-SUBSCRIBE MESSAGING ENGINE
The messaging engine moves messages from adapters to the MessageBox database and from the MessageBox database to subscribers. The messaging engine does this using context properties associated with each message and subscriptions related to those context properties. Subscribers can be orchestrations and/or send ports. Send ports are made up of configuration data about an adapter, URI, pipeline, and optionally maps associated with sending a message from BizTalk. When messages enter BizTalk they can be routed to multiple subscribers because the messaging engine supports the publish-subscribe pattern. This makes it easy to add new subscribers to existing messages and reuse previously implemented orchestrations by routing messages from new publishers to them. This can drastically reduce the amount of time associated with subsequent solutions.

ADAPTERS
Adapters are the BizTalk components that communicate with applications and systems. They're the first component that messages pass through when entering BizTalk and the last component that messages pass through when leaving BizTalk. There are two broad categories of adapters: application and protocol. Application adapters communicate with applications such as SQL Server, JD Edwards, PeopleSoft, etc. Protocol adapters support communication over various protocols such as HTTP, SOAP, FTP, etc. There are roughly 25 adapters included in BizTalk Server 2006. These adapters eliminate the time associated with building proxy components that would normally need to be created to communicate between various systems. Custom adapters can also be built using the BizTalk Adapter Framework if the out-of-the-box adapters don't meet your needs.

ORCHESTRATION ENGINE
The orchestration engine manages the instantiation and processing of orchestrations. This engine and its related facilities provide several runtime features that require explanation:

• Short-Term and Long-Term State Management - This is the ability to manage short- and long-running business processes and their state (variables, messages, context, etc.); the orchestration engine can manage orchestrations that run for anywhere from milliseconds to years. This feature also includes facilities for managing state when exceptions occur and providing for message replay.
• Dehydration - This is the automatic persistence, and subsequent restoration, of orchestration instances to and from the MessageBox database. This feature's purpose is centered on performance management.
• Interception - This is the ability to send data points to other BizTalk components without requiring developers to implement the data publishing in orchestrations. The current interception collectors are BizTalk's tracking infrastructure and Business Activity Monitoring infrastructure.
• Feature Integration - This is the integration with other BizTalk features including the Business Rules Engine and Business Activity Services.
• Correlation - This is the ability to route messages back to an existing orchestration instance instead of instantiating a new orchestration instance. For example, a shipping orchestration might be initiated by a new shipment message but can't continue until it gets a packaging message. Correlation relies on context properties for routing messages to the appropriate orchestration instances. Context properties can be pulled from the message bodies or from the context associated with their receipt, for example, URI, port name, date-time, etc. Continuing with the shipping orchestration example, the packaging message would likely be correlated using a "shipmentId" context property.
• Convoy Support - This builds on the correlation concept and is the ability to receive more than one message in an orchestration instance. In its simplest form, convoys provide support for getting messages in a sequence in a single orchestration instance. An example of a simple convoy form is an order processing orchestration that gets a purchase order and then an invoice.

  In a more complex form, convoys provide support for receiving one of many messages to start or continue an orchestration while allowing the messages that didn't start or continue the orchestration to be routed to that same orchestration instance. An example of the complex convoy form is an approvals workflow that requires multiple approvals, any of which will start the orchestration but all of which must be received before the orchestration instance will continue.

BUSINESS RULES ENGINE
The Business Rules Engine (BRE) provides facilities for encapsulating business rules in a manner that doesn't require them to be embedded in source code. Business rules are grouped in Policies that are usually stored in BizTalk's BizTalkRuleEngineDb database. The BRE can be used directly from standard .NET applications, although it's normally used from orchestrations.

The BRE can be used for implementing a large number of very complex business rules. When it's used this way, intellectual property can be embedded in it, thereby providing benefits for organizations trying to minimize business losses due to employee attrition and organizations attempting to capitalize on the IP's encapsulation. The BRE is often used as a simple configuration store for BizTalk solutions. This can eliminate hard-coding items into BizTalk solutions that would later require re-compilation and re-deployment when the items need to be updated. The BRE vision includes the idea that business rules can be defined, tested, and deployed with little to no IT administrator interaction. This means that business rules could be updated based on the business's schedule and without the normal costs associated with deployment.