Mohammed Atef’s Technical blog

BizTalk 2006 architecture

I want to give you simple description about BizTalk architecture.

BizTalk 2006 arcitecture

BizTalk 2006 arcitecture

 The above image contains most important BizTalk components and how it related to each other.
BizTalk is designed to receive inbound messages, pass them through s
ome form of logical processing, and then deliver the result of that processing to an outbound location or subsystem. The art of architecting a BizTalk project begins with how to solve these three simple yet all-important tasks.

Inside BizTalk Server, you will find tools, each of which address a specific type of problem.

I will list all this tools and explain each one

Ports and adapters provide the logical abstraction for sending and receiving messages to and from BizTalk. They allow you to code your application in a generic fashion and not worry about the implementation details of how these messages will be consumed and delivered.

A port is a logical construct that can receive and send messages to/from the BizTalk Messagebox. The port must be married to a specific receive location to accept the message.

The receive location then is tied to a specific adapter, which provides the details of how the message will be transported. BizTalk provides several adapters out of the box including those for FTP, File Access, SOAP,HTTP, SMTP, POP3, MSMQ, and MQSeries.


Business Activity Monitoring (BAM) and Business Activity Services (BAS) provide the infrastructure to perform application instrumentation and metric reporting. BAM provides the ability to instrument your application to provide business-level data that is much more relevant than the default system-level information that is available in the base product.

BAS, on the other hand, provides a simple yet powerful way to display metric data from BAM and other system-level subservices using Microsoft SharePoint Portal Services. Most organizations will integrate the BAS portal into an existing SharePoint infrastructure rather than build an entire SharePoint site around BAS itself.


Pipelines provide a way to examine, verify, and potentially modify messages as they are received from and sent to BizTalk. They allow you to deconstruct messages that contain multiple documents and/or header information into a format that is more logical to the application or business user. Pipelines are applied to ports and are either a send pipeline or a receive pipeline depending on the directional flow of the message.

Pipelines have various stages in which components can be executed. Stages are much like events in that they have a set order in which they execute and can be used to ensure that pipeline component logic executes in the correct order. Each stage can potentially execute more than one pipeline component depending on where it is located.

The stages for the two types of pipeline are as follows:

• Send pipeline stages:

§  Pre-Assemble

§  Assemble

§  Encode

• Receive pipeline stages:

§  Decode

§  Disassemble

§  Validate

§  Resolve Party

Pipeline components are classes that are executed within the various stages of a BizTalk server pipeline. Custom pipeline components implement a specific set of application interfaces

required by the BizTalk framework. Several default pipeline components are shipped with the product that provides standard functionality that most pipelines require, examples of which are as follows:

Disassemblers and assemblers: Components that allow a pipeline to examine an inbound document and separate it into logical parts, or likewise take several separate documents and assemble them into one document. In most projects, the inbound or outbound document is a container or an envelope document that may contain several

other distinct but related document types, each with their own schema.

Validators: These allow for the pipeline to validate the document according to a default specification. The default validators allow the pipeline to verify that the document is valid XML. Custom validators can be written to perform solution-specific validation.

Encoders and decoders: As the name suggests, these allow the pipeline to either decode an inbound message or encode an outbound message. The default BizTalk components allow you to encode or decode S/MIME messages. Most custom encoder/ decoder components perform either custom security routines or specialized cryptographic operations.


Orchestrations are used to graphically model workflow and provide the primary mechanism to implement business process automation within the product. Orchestrations are by far the most powerful tool within the BizTalk Server toolbox as they allow for the rapid development and deployment of complex processes that in many circumstances can be implemented with little to no coding. Orchestrations are created within Visual Studio and are compiled into .NET assemblies that are installed into the BizTalk Management Database. Assemblies deployed to this database must also be installed into the Global Assembly Cache and have a strong name.

The Orchestration Designer is a primarily visual tool.


Transformation(Maps)s allow the application to map one message specification to another and transform data as it is processed. BizTalk messages are XML documents within the system, and as such,  transformations are created from XSL (eXtensible Stylesheet Language) stylesheets. Transformations in BizTalk 2004 used the Microsoft XML Document Object Model (XML DOM) as their primary transformation engine. Starting in BizTalk 2006, the transformation

engine is a custom solution developed by the BizTalk Server team. This new transformation engine is designed to increase the performance of transforming complex and especially large messages while preserving fault tolerance. Transforming large messages

(greater than 10MB) proved to be problematic in BizTalk 2004 due to issues with out-ofmemory conditions that occurred within the transformation engine, which was the main reason for this features’ redesign.


The Messaging Engine is the heart of BizTalk. The engine is responsible for ensuring that messages are received and routed to the proper location, that transaction isolation and consistency occurs, and that errors are reported. In reality, the Messaging Engine is the “Server” component of BizTalk Server. The Messaging Engine uses several BizTalk databases to store message information and metadata as well as system-level parameters. The Messaging Engine uses Microsoft SQL Server as its data storage facility. The central database for messages within BizTalk is called the Messagebox. SQL Server is not required to be physically installed on the same machine as BizTalk Server, and we recommend it be installed in its own environment for

high-transaction and fault-tolerant solutions.


The Business Rule Engine (BRE) is a facility where business rules can be modeled using a simple GUI and called from within the BizTalk Server environment. The BRE is designed to allow for versioning and modification of implemented business rules without having to change the processes within BizTalk that use them. Most solutions use the BRE to implement things that require frequent updates such as a discount policy percentage or calculations that are updated frequently as a result of legal or government regulations.

Electronic Data Interchange (EDI) Services is a documented and accepted set of standards for exchanging electronic documents between organizations. EDI is traditionally used within legacy applications that have been implemented prior to the XML standard from the W3C. EDI documents are text based in nature and have a variety of document specifications depending on the data to be exchanged and the industry that uses them. BizTalk Server provides mechanisms for parsing these EDI documents into XML as well as connectivity to legacy data sources such as Value Added Networks and proprietary dial-up services.


I hope this article be helpful for you.


January 26, 2009 Posted by | Biztalk | , , , , , , | Leave a comment