- Getting Started with BizTalk Services
- Karthik Bharathy Jon Fancey
- 559字
- 2021-11-12 16:30:08
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.
- 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
- INSTANT Citrix XenDesktop 5 Starter
- 自愿審計動機與質量研究：基于我國中期財務報告審計的經驗證據
- Citrix XenApp? 7.5 Desktop Virtualization Solutions
- 金融保險集團內部審計創新與實踐
- 讓財報說話：世界500強CFO帶你輕松讀財報（鮮讀版）
- 注冊會計師全國統一考試專用教材：審計
- 項目管理（第二版）
- 企業能源審計與節能規劃
- SAP ABAP Advanced Cookbook
- 基本有用的計量經濟學
- 振蕩指標MACD：波段操作精解（升級版）
- 企業內部審計全流程指南
- 傳習集2
- 公司內部審計
- Implementing VMware Horizon 7.7