Microsoft® BizTalk™ Server 2000 Deployment Considerations

White Paper

Published: February 2001

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred.

Copyright © 2001 Microsoft Corporation. All rights reserved.

Microsoft, ActiveX, BizTalk, SourceSafe, Visio, Visual Basic, Visual C++, and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Abstract

Microsoft® BizTalk™ Server 2000 provides the infrastructure to enable solutions for business-to-business electronic commerce and enterprise application integration (EAI). This white paper describes deployment configurations, explains why you might decide to implement each configuration, and offers guidelines for building them.

Table of Contents

Microsoft BizTalk Server 2000 Deployment Considerations 1

Introduction 1

Deployment Models 2

Small- to Medium-sized Organization Application Integration 2

Large Organization Application Integration 3

XML Format Integration 3

BizTalk Server Distribution Lists 3

Loosely Coupled Integration Using a Data Distribution Bus 4

Deployment Considerations 4

Firewall Restrictions and Considerations 4

HTTP-Only Interactions 5

Responses and Time-Outs in Long-Running Processes 7

Message Queuing Fan-Out 7

Load Balancing Considerations 8

COM+ Component Load Balancing 8

Windows Network Load Balancing Service 9

Building Scalable and Available Web Applications 9

Synchronous Web-based Model 10

Synchronous Façade on an Asynchronous Back-end Processing System 10

Designing BizTalk Server Groups 11

Redundant Server Group Configurations 11

Partitioned or Specialized Server Group Configurations 12

BizTalk Servers running BizTalk Orchestration Services 13

BizTalk Messaging Services 13

BizTalk Messaging Objects 13

Custom BizTalk Messaging Components 14

Application Integration Components 14

ASP Property Pages 15

Tracking Database Maintenance 15

BizTalk Orchestration Services 15

BizTalk Orchestration .skx and .skv Files 15

Implementation Technologies 16

BizTalk Server Run-Time Authentication and Identity 16

Configuring BizTalk Orchestration Services 17

Persistence Database Configuration and Maintenance 17

Security 18

Security administration 18

Server Affinity of XLANG Schedules 18

Message Queue Size Limits 18

Scalability Issues 18

Shutting Down Applications That Host XLANG Schedules 20

Message Queuing Dead Letter Queues 20

XLANG Schedule Activation 20

Updating XLANG Schedules 21

Conclusion 21

For More Information 22

Microsoft BizTalk Server 2000 Deployment Considerations

Microsoft BizTalk Server 2000 Deployment Considerations

White Paper

Published: February 2001

Introduction

Microsoft® BizTalk™ Server 2000 provides an application infrastructure that enables businesses to implement remote data interchange with external partners. BizTalk Server 2000 also solves the problem of integrating dissimilar applications across multiple remote and autonomous business units within a business domain. This white paper describes the deployment models and considerations for business-to-business electronic-commerce and enterprise application integration (EAI) implementations. For small businesses, deploying BizTalk Server can be straightforward and relatively trivial, but for large global businesses with a distributed application environment, much care and thought must be taken to design a deployment architecture that reduces the complexity of management while providing a robust and extensible application environment.

It is highly recommended that you have an understanding of the information contained in the BizTalk Server 2000 product documentation before you read this white paper.

This white paper outlines two basic deployment models and six types of deployment considerations:

·  Deployment models. The deployment models are grouped into two general categories: application integration within a small- to medium-sized organization (SMORG), and application integration within a large organization (LORG). The information in this section will help you determine which deployment model is appropriate for your business environment.

·  Deployment considerations. This section contains a variety of guidelines that describe the issues you need to consider when you deploy BizTalk Server 2000. The six most important deployment considerations are:

·  Firewall restrictions and considerations. Many of the constraints that are placed on the implementation of business-to-business deployments are driven by the need for protection from external attacks. This section describes what you need to consider when you deploy BizTalk Server 2000 behind a firewall.

·  Load balancing considerations. This section describes how to increase performance and optimize the use of processing power in a multiple-server deployment.

·  Building scalable and available Web applications. This section compares the issues you need to consider when you build Web applications using either the synchronous model or the asynchronous model.

·  Designing BizTalk Server groups. This section explains the key organizing principle in BizTalk Server Administration.

·  BizTalk Messaging Services. This section describes some background information, information about best practices, and troubleshooting tips relating to BizTalk Messaging Services.

·  BizTalk Orchestration Services. This section describes some of the design issues that are specific to BizTalk Orchestration Services that you need to consider for BizTalk Server deployment.

Deployment Models

Unlike many competitive products that focus on either external or internal data interchange, BizTalk Server 2000 offers a platform and feature set that solves both the business-to-business and enterprise application integration (EAI) problem set. It can be as difficult to integrate custom-built applications with applications that are purchased as it is to integrate business processes between trading partners. The architecture for integrating applications within a business depends greatly on the size of the business, its structure, and the complexity of the business processes. The following sections focus on two deployment models. The first deployment model is for a simple small- to medium-sized business. The second model is for a more complex, large-scale business.

Small- to Medium-sized Organization Application Integration

Typically, small- to medium-sized organizations (SMORGs) have a centralized Information Technology (IT) group that controls systems and applications. Often, a limited number of systems and applications within these businesses are core to business operations. Point-to-point application integration is a typical deployment architecture in this environment.

In a SMORG environment, you can deploy BizTalk Server as a routing and transformation hub that connects all applications with a single BizTalk Server group to facilitate application integration. Channels, ports, and XLANG schedules are created for the purpose of integrating specific applications. This model for a simple deployment of BizTalk Server is suitable for SMORGs. The same deployment in a LORG environment can quickly become inefficient and unmanageable. In point-to-point application integration, there is a one-to-one relationship between an application on one system and an application on another system. For example, a procurement application on one system might have a point-to-point application integration relationship with an inventory application on another system. Using BizTalk Server, management is centralized and each application is under the control of a single group.

The following illustration shows point-to-point application integration.

Large Organization Application Integration

Many large businesses do not use a single centrally managed system. Large organizations (LORGs) are typically organized in autonomous, discrete business units that develop, maintain, support, and administer their own systems. There is a need for these business units to share data with applications that are controlled by other business units as well as to communicate with external trading partners. Cross-business-unit integration is the combined burden of central the Information Technology (IT) group and the business unit development staff.

Many LORGs need a more distributed and manageable solution than the simple point-to-point application integration used by SMORGs. Competitive EAI technologies that specifically market to LORGs have adopted a new paradigm for integrating applications, known as Publish and Subscribe, or Pub-Sub. In Pub-Sub–based integration products, the publishers of, and subscribers to, the data are unaware of each other. Data are published by one application and subscribed to by other applications. This paradigm focuses on integrating applications with the data distribution infrastructure of the business domain, instead of integrating applications directly with each other. In this model, applications can be easily plugged into the business network data bus and the applications can participate in the business process flow without creating tightly coupled dependencies between systems. The BizTalk Server distributed integration bus can be deployed to provide Pub-Sub–based integration functionality. The BizTalk Server distributed integration bus is made up of distribution lists that enable a one-to-many data distribution model.

The following illustration shows one-to-many application integration using the BizTalk Server distributed integration bus.

XML Format Integration

Because applications are not bound by interfaces or common data stores but by common or intermediary data formats, the applications can evolve their implementations without affecting the overall process flow of the business. BizTalk Server 2000 provides the basis for implementing content-based routing and an integration platform based on formats of document types, also known as specifications. BizTalk Server is document-type or specification-centric in nature. To achieve a greater level of business integration than most other products, BizTalk Server uses XML. When applications require specific non-XML formats, BizTalk Server provides transformation and serialization features that can deliver data in the native format of the target application or endpoint at the point of integration/transport. The ultimate goal is that the data flowing between applications is in an intermediary XML format and not in a format of any particular or specific application. This goal might not be realized initially and does not hamper the integration.

BizTalk Server Distribution Lists

A key feature of BizTalk Server is the distribution list, which allows one-to-many distribution of data to applications and other BizTalk Server groups. Distribution lists are implemented in BizTalk Messaging Services by first creating a distribution list that contains a set of previously configured messaging ports. Channels for particular types of documents are then added to deliver documents to the distribution list that contains a collection of messaging ports that determines the delivery endpoints of the document. Each messaging port in the distribution list refers to another organization or application.

Loosely Coupled Integration Using a Data Distribution Bus

BizTalk Server distribution lists facilitate the deployment of BizTalk Server-based enterprise application integration (EAI) middleware that interconnects applications and external counter-parties in a loosely coupled fashion. In this context, loosely coupled is defined as integrating endpoints by using a messaging infrastructure that does not require the sending and receiving endpoints to be preconfigured with specific knowledge of the counter endpoint's existence. Each BizTalk Server group can be configured as a part of a BizTalk Server data distribution bus so that each BizTalk Server group is aware of other BizTalk Server groups that have channels configured to receive and process a particular set of data. In this fashion, BizTalk Server groups can be linked for more efficient distribution of data by using distribution lists. Each BizTalk Server group can represent a subset of all endpoints, whether they are applications or trading partners. Effectively, each BizTalk Server group can serve to model the business unit and departmental system partitioning. For example, BizTalk Server groups used by the accounting department do not need to carry configuration data for subscribing members of other BizTalk Server groups that require copies of the same messages. BizTalk Server inter-group document delivery is a more efficient way to distribute data than using application-to-application integration.

Deployment Considerations

The architecture for deploying EAI, using distributed and discrete application processing, is driven by the necessity to build business domains and boundaries. This section discusses and recommends solutions for these deployment problems. As deployments of BizTalk Server mature, new and updated XLANG schedules must be seamlessly integrated with tools that provide version control of server configurations. In high-performance environments, it is critical that BizTalk Server can be remotely monitored and proactively administered.

The BizTalk Server 2000 deployment areas for you to consider are:

·  Firewall restrictions and considerations.

·  Load balancing considerations.

·  Building scalable and available Web applications.

·  Designing BizTalk Server groups.

·  BizTalk Messaging Services.

·  BizTalk Orchestration Services.

Firewall Restrictions and Considerations

Among the challenges that arise when businesses engage in business-to-business data interchange is the question of how companies can implement robust application solutions while maintaining a secure environment. Protecting systems and data is paramount to most businesses. Web-based application deployment must take into account the dangerous and volatile environment encountered on the Internet, where attacks are anticipated and occur frequently. To protect their domains, many businesses use firewalls that restrict network traffic to the HTTPS and FTP transport protocols. Additionally, firewalls open only a limited number of ports to the Internet (for example, port 80 for HTTP). Also, double firewalls are often used to isolate Web servers from an intranet or from local area networks (LANs). The space between these firewalls is referred to as the demilitarized zone (DMZ). In the past, network groups within businesses have stipulated that data cannot be persisted within the DMZ, and that all traffic from the DMZ to an intranet must be strictly monitored or filtered for textual data, using HTTP as the transport protocol. However, some of these restrictions have recently been relaxed, as new business models require the implementation of Web-based applications running dynamic content. Previously, only static Web content crossed into the DMZ.