Life cycle and architecture

Unlike most other Azure services deployments, BizTalk Services provisions dedicated resources for storage and compute instances that are isolated across tenants. This means that no two deployments have anything in common between them. The advantage is that you can write any custom code and be assured that you cannot impact the performance or availability of other deployments. This dedicated deployment also offers isolation of data at the storage level, thus increasing the privacy of data and SLA of the service.

Broadly categorizing, there are three steps to go through before you can have an active usable deployment. The first is to provision the service using standard Azure tools, including the Azure portal to create the service; the second is to deploy the necessary artifacts and configuration outlined in the BizTalk Services concepts section using Visual Studio and the BizTalk Services portal; and the third is sending or receiving the messages.

The architecture of BizTalk Services contains three key components:

• Provisioning services: This is a set of Microsoft services that manage the lifecycle of a BizTalk Services deployment as well as monitor its health. It also includes components to bill the end user based on usage of BizTalk Services. The management interface to the service is exposed via the Red Dog Front End (RDFE) public API. The Azure Management Portal or PowerShell scripts from the user go via the RDFE API. Using the service, you can scale up/down your deployment as well as back up and restore deployment across datacenters.

  Note

  Red Dog was the original codename for Azure, with the "FE" being the publicly accessible frontend that users directly interact with either via the Azure portal or service management APIs.

• Per tenant BizTalk Services: This is the per tenant deployment that is created in the user's Azure subscription. A BizTalk Services deployment is identified by the deployment name and is accessible using the URL secured by the Access Control Service (ACS). All artifacts such as bridges and schemas are added into the deployment with a URL which is a sub-path of the deployment URL. For example, a bridge is added under <deployment URL>/default/<bridgeName>. Here default is the namespace name where the artifacts are grouped into.

• Per tenant dependencies: These dependencies are the Azure services required for tracking, troubleshooting, and security. For example, BizTalk Services provides a tracking store, which is an Azure SQL database where the processing status of messages, along with related properties, are stored as the messages pass through a bridge. The information from the tracking store is shown in the BizTalk Services portal tracking view. Archiving and monitoring is stored in Azure storage blobs and tables. Archived messages are stored in blob containers based on the date of the archive. The storage also contains the Azure table WADLogsTable, where tracing information for a bridge can be obtained. Finally, Access Control Service regulates access to all endpoints in the deployment. During deployment creation, the provisioning service uses the Management Service credentials to programmatically access ACS to create a relying party for the BizTalk Services deployment, add rule groups for Send, Listen, and Manage claims, and create the service identity with the necessary passwords for directly talking to ACS for deployment of the artifacts. The interaction between these components is illustrated in the following figure:

  

  Block diagram of BizTalk Services shared and per tenant services