Understanding BizTalk Server 2006 R2

Understanding BizTalk Server 2006 R2:

Introducing BizTalk Server 2006:

No application is an island. Whether we like it or not, tying systems together has become the norm. Yet connecting software is about more than just exchanging bytes. As organizations move toward a service-oriented world, the real goal—creating effective business processes that unite separate systems into a coherent whole—comes within reach.

BizTalk Server 2006 supports this goal. Like its predecessors, this latest release allows connecting diverse software, then graphically creating and modifying process logic that uses that software. The product also lets information workers monitor running processes, interact with trading partners, and perform other business-oriented tasks.

Built on the foundation of its predecessor, BizTalk Server 2004, this new release will look familiar to anyone who's used this earlier version. The most important new additions in BizTalk Server 2006 are:

Better support for deploying, monitoring, and managing applications.

Significantly simpler installation.

Improved capabilities for Business Activity Monitoring (BAM).

BizTalk Server 2006 also uses the latest releases of other Microsoft technologies. It's built on version

2.0 of the .NET Framework, for example, and its developer tools are hosted in Visual Studio 2005. For storage, the product can use SQL Server 2005, the latest version of Microsoft's flagship database product, or SQL Server 2000, the previous release. BizTalk Server 2006 can also run on 64-bit Windows, taking advantage of the larger memory and other benefits this new generation of hardware offers.

Combining different systems into effective business processes is a challenging problem. Accordingly, BizTalk Server 2006 includes a range of technologies. The figure below illustrates the product's major components.

Information Worker Technologies

As the figure suggests, the heart of the product is the BizTalk Server 2006 Engine. The engine has two main parts:

A messaging component that provides the ability to communicate with a range of other software. By relying on pluggable adapters for different kinds of communication, the engine can support a variety of protocols and data formats, including web services and many others.

Support for creating and running graphically-defined processes called
orchestrations. Built on top of the engine's messaging components, orchestrations implement the logic that drives all or part of a business process.

Several other technologies can also be used in concert with the engine, including:

A Business Rules Engine that allows evaluating complex sets of rules.

A Health and Activity Tracking tool that lets developers and administrators monitor and manage the engine and the orchestrations it runs.

An Enterprise Single Sign-on facility, providing the ability to map authentication information between Windows and non-Windows systems.

On top of this foundation, BizTalk Server 2006 provides a group of technologies that address the more business-oriented needs of information workers. Those technologies are:

Business Activity Monitoring, allowing information workers to monitor a running business process. The information is displayed in business rather than technical terms, and what gets displayed can be controlled directly by business people.

Business Activity Services, allowing information workers to set up and manage interactions with trading partners.

All of these technologies are focused on solving the problems inherent in using a diverse set of software to support automated business processes. The next section examines how these solutions might look.

How BizTalk Server 2006 Is Used:

The great majority of modern business processes depend at least in part on software. While some of these processes are supported by a single application, many others rely on diverse software systems. This software has commonly been created at different times, on different platforms, and using different technologies. Given this, automating those business processes requires connecting diverse systems.

Addressing this challenge goes by various names: business process automation (BPA), business process management (BPM), and others. Whatever it's called, two scenarios are most important for application integration. One is connecting applications within a single organization, commonly referred to as enterprise application integration (EAI). The other, called business-to-business (B2B) integration connects applications in different organizations.

The figure below shows a simple example of the core BizTalk Server 2006 engine applied to an EAI problem. In this scenario, an inventory application, perhaps running on an IBM mainframe, notices that the stock of an item is low and so issues a request to order more of that item. This request is sent to a BizTalk Server 2006 orchestration (step 1), which then issues a request to this organization's ERP application requesting a purchase order (step 2). The ERP application, which might be running on a Unix system, sends back the requested PO (step 3), and the BizTalk Server 2006 orchestration then informs a fulfillment application, perhaps built on Windows using the .NET Framework, that the item should be ordered (step 4).

BizTalk Server 2006 Architecture:

The following figure provides a high-level overview of the BizTalk Server architecture from a messaging perspective

In this simplified view, a message is received through a receive location defined in a given receive port. This message is processed by the receive location and then published to the MessageBox database, the main persistence and routing mechanism for BizTalk Server. The MessageBox evaluates active subscriptions and routes the message to those orchestrations and send ports with matching subscriptions. Orchestrations may process the message and publish messages through the MessageBox to a send port where it is pushed out to its final destination.

The following are key components involved in BizTalk Server message processing.

Receive Ports and Receive Locations

A receive port is a collection of one or more receive locations that define specific entry points into BizTalk Server. A receive location is the configuration of a single endpoint (URL) to receive messages. The location contains configuration information for both a receive adapter and a receive pipeline. The adapter is responsible for the transport and communications part of receiving a message. Examples include the File adapter and SOAP adapter, each of which receives messages from different types of sources. The receive pipeline is responsible for preparing the message for publishing into the MessageBox. A pipeline is a series of components that are executed in sequence, each providing specific processing to a message such as decryption/encryption, parsing, or validation.

Send Ports and Send Port Groups

A send port is the combination of a send pipeline and a send adapter. A send port group is a collection of send ports and works much like an e-mail distribution list. A message sent to a send port group will be sent to all send ports in that group. The send pipeline is used to prepare a message coming from BizTalk Server for transmission to another service. The send adapter is responsible for actually sending the message using a specific protocol such as SOAP, or FTP.

Orchestrations

Orchestrations can subscribe to (receive) and publish (send) messages through the MessageBox. In addition, orchestrations can construct new messages. Messages are received using the subscription and routing mechanism already discussed. When subscriptions are filled for orchestrations, a new instance is activated and the message is delivered, or in the case of instance subscriptions, the instance is rehydrated if necessary and the message are then delivered. When messages are sent from an orchestration, they are published to the MessageBox in the same manner as a message arriving at a receive location with the appropriate properties is inserted into the database for use in routing.

MessageBox Database

The heart of the publish/subscribe engine in BizTalk Server is the MessageBox database. The MessageBox is made up of two components: one or more Microsoft SQL Server databases and the Message Agent. The SQL Server database provides the persistence store for many things including messages, message properties, subscriptions, orchestration states, tracking data, and host queues for routing.

Hosts and Host Instances

A host is a logical representation of a Microsoft Windows process that executes BizTalk Server artifacts such as send ports and orchestrations. A host instance is the physical representation of a host on a specific server. A host can be either an in-process host, which means it is owned and managed by BizTalk Server, or an isolated host, which means that the BizTalk Server code is running in a process that is not controlled by BizTalk Server. A good example of an isolated host is Internet Information Services (IIS), which hosts the receive functionality of the HTTP and SOAP adapters. Hosts are defined for an entire BizTalk Server group; a collection of BizTalk Servers that share configuration, MessageBoxes, ports, and so on

Adapters:

Adapters are the communication interface for BizTalk to and from the outside world. They perform whatever communication semantics or protocols that the remote system requires, thus hiding any complexity that is required when interfacing with remote systems, particularly legacy ones.

Adapters are commonly referred to as bit shovelers because of the way they move the binary bits from the outside world into BizTalk and from BizTalk back out to the outside world, effectively feeding the BizTalk engine with work—like a fireman feeding coal into the engine of a steam train.

No conversion or translation of messages is performed by adapters; they purely bring the bits into BizTalk so that pipelines can then optionally perform any data translation, such as converting a flat file to an XML document. This chapter begins with an overview of the adapter architecture along with features offered to adapters, and then the remainder of the chapter discusses each of the mainstream adapters