Export (0) Print
Expand All

Microsoft BizTalk Server 2000 Deployment Considerations

Microsoft Coproration

February 2001

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

Contents

Introduction
Deployment Models
   
Small- to Medium-sized Organization Application Integration
   
Large Organization Application Integration
      
XML format integration
      
BizTalk Server distribution lists
      
Loosely coupled integration using a data distribution bus
Deployment Considerations
   
Firewall Restrictions and Considerations
      
HTTP-only interactions
      
Responses and time-outs in long-running processes
      
Message Queuing fan-out
   
Load Balancing Considerations
      
COM+ component load balancing
      
Windows Network Load Balancing Service
   
Building Scalable and Available Web Applications
      
Synchronous Web-based model
      
Synchronous facade on an asynchronous back-end processing system
   
Designing BizTalk Server Groups
      
Redundant server group configurations
      
Partitioned or specialized server group configurations
      
BizTalk Servers running BizTalk Orchestration Services
   
BizTalk Messaging Services
      
BizTalk messaging objects
      
Custom BizTalk messaging components
      
Application integration components
      
ASP property pages
      
Tracking database maintenance
   
BizTalk Orchestration Services
      
BizTalk Orchestration .skx and .skv files
      
Implementation technologies
      
BizTalk Server run-time authentication and identity
      
Configuring BizTalk Orchestration Services
      
Persistence database configuration and maintenance
      
Security
         
Security administration
      
Server affinity of XLANG schedules
      
Message queue size limits
      
Scalability issues
      
Shutting down applications that host XLANG schedules
      
Message queuing dead letter queues
      
XLANG schedule activation
      
Updating XLANG schedules
Conclusion
For More Information

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 article 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 article.

This article 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:
    1. 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.
    2. Load balancing considerations. This section describes how to increase performance and optimize the use of processing power in a multiple-server deployment.
    3. 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.
    4. Designing BizTalk Server groups. This section explains the key organizing principle in BizTalk Server Administration.
    5. BizTalk Messaging Services. This section describes some background information, information about best practices, and troubleshooting tips relating to BizTalk Messaging Services.
    6. 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.

Ee265614.btsdeployment01(en-US,BTS.10).gif

Figure 1. 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 the central 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 is unaware of each other. Data is 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.

Ee265614.btsdeployment02(en-US,BTS.10).gif

Figure 2. 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.

HTTP-only interactions

Many Web-based applications require synchronous interactions between the client and the server. Although there are concerns about the scalability of this type of application architecture, it is still the predominant scenario that is deployed on the Internet at this time. Synchronous Web-based applications receive a request from a client and return a response to the client using the same request session. This is the model for HTTP Request and HTTP Response. Many clients expect HTTP Response to carry a business-level response to the request that they posted. The expectation is that the request waits for the response. The following scenario describes an architecture that complies with this synchronous requirement.

This scenario includes a data farm of Internet Information Services (IIS) servers. The data farm might also include Commerce Servers. These servers receive documents over HTTPS and then submit the documents to a BizTalk Server group for processing. In this scenario, there might be a firewall that allows only HTTP traffic through port 80 between the IIS and Commerce Server data farm and the BizTalk Server group.

To build a configuration based on this scenario, you must adhere to the following requirements:

  • The IIS and Commerce Server data farm and the BizTalk Server group must be scaled out independently.
  • Communication between the two data farms must be restricted to port 80 and use HTTP exclusively.
  • Load balance requests across servers in both data farms must be made independently.
  • Optionally, you can design support for synchronous HTTP interactions between Web clients and BizTalk Servers.

To comply with these requirements, it is often not possible to use Distributed Component Object Model (DCOM) calls between the data farms. DCOM calls from the IIS and Commerce Servers in the DMZ to BizTalk Servers would require the opening of arbitrary ports. This is often unacceptable in a business environment.

The following illustration shows a configuration based on the scenario described in this section, using Microsoft Internet Security and Acceleration (ISA) Server as the firewall server.

Ee265614.btsdeployment03(en-US,BTS.10).gif

Figure 3. Configuration based on the scenario described in this section, using Microsoft Internet Security and Acceleration (ISA) Server as the firewall server

This configuration provides a simple implementation model. The two data farms are loosely coupled and can scale out independently by using HTTP and the Network Load Balancing Service (NLBS) as intermediary load-balancing servers.

Active Server Pages (ASPs) on Commerce Server and IIS servers in the DMZ use the server-optimized MSXML 3.0 HTTP client to forward HTTP Requests with messages to the internal IIS and BizTalk Servers over HTTPS. The MSXML 3.0 HTTP client is multithreaded and reentrant. Optionally, a Microsoft Internet Security and Acceleration server can be used to implement a request-forwarding reverse proxy.

In the synchronous model, ASP pages on the IIS and BizTalk Servers within an intranet call directly into the local BizTalk Servers by using the SubmitSync method of the IInterchange interface. BizTalk Server returns a response. In the asynchronous model, the ASP page calls the Submit method or places the message onto a local message queue, or file share, that a Message Queuing receive function monitors. When asynchronous calls to the BizTalk Server are used, the following occurs:

  • BizTalk Messaging Services are optimized to receive documents from a message queue by using a Message Queuing receive function. If the document size is greater than 4 megabytes (MB) in ASCII, or 2 MB in Unicode, the message queue size limit is exceeded. In this case, the document must be submitted to BizTalk Server using either the IInterchange interface (to support transactions), or by using a File receive function.
  • ASP pages can quickly save messages in message queues without processing the messages. This reduces the page latency and releases HTTP connections in an expedient manner.
  • ASP pages submit documents to BizTalk Server by using receive functions or the Submit method on the IInterchange interface.

When BizTalk Orchestration Services are used to implement business logic, the document that is passed to the Submit method or the SubmitSync method of the IInterchange interface is processed on the local server by an XLANG schedule instance. You can configure BizTalk Server to activate a new XLANG schedule instance to process the document, or the document can be processed by an activated XLANG schedule instance. For information about configuring BizTalk Orchestration Services, see "BizTalk Orchestration Services" later in this article. If new XLANG schedules are to be activated when a specified document type is received, and if there is a high volume of incoming documents of this type, the tightly coupled approach could overwhelm the servers on which XLANG schedules are activated. Newly activated XLANG schedules will compete for resources with the XLANG schedules that are already running. This might affect the throughput and the latency of the overall application. To avoid this problem use a loosely coupled approach.

Responses and time-outs in long-running processes

In this scenario, the Web page is blocking the HTTP Request that is awaiting a response from the stateless component. The stateless component is polling a queue, awaiting a response message that is based on the globally unique identifier (GUID) of the request (also referred to as the message label). When processing on the back end is expeditious to the client, it appears to be synchronous. If there is heavy load, a time-out thread in the stateless object returns an out parameter to the Web page. This out parameter represents the following instruction:

  • Processing incomplete, please check back later with the Message GUID to retrieve the response.

At that time, the Web page either redirects the client requests to a CheckStatus/FetchResponse page, which simply calls a component to poll the queue, or a script in the client browser handles the response polling. The GUID can be placed in the cookie and used to retrieve the response asynchronously.

Variations of this are possible; for example, using a SQL query to the CheckStatus/FetchResponse page from the Web page or component. This is not possible in businesses that require no direct back-end database interaction from Web servers in the firewall. In this situation, Message Queuing can be used for decoupling and throttling requests from responses.

Message Queuing fan-out

To enable a firewall to allow Internet access to Message Queuing Services, Message Queuing traffic is delivered through port 1801, which is a reserved Transmission Control Protocol (TCP) port. If port 1801 is open for Message Queuing traffic and if asynchronous communication is used for the interaction between the Web client and the BizTalk Servers, it is recommended that you use Message Queuing to move messages out of the DMZ and into the business domain. Because Message Queuing 2.0 does not support remote transacted reads, a custom message queue fan-out component is required to move messages in a transacted fashion to local queues in the data farm. Assuming that messages have not been placed in the queue by an ASP page on the server running Message Queuing, this custom message queue fan-out component can be developed to pull messages off the queue and send them to local queues on the BizTalk Servers. Load balancing schemes can take advantage of Microsoft Windows® Management Instrumentation (WMI) reporting to determine the performance characteristics of each server before forwarding the message to the BizTalk Server with the smallest load.

The following illustration shows a configuration based on the scenario described in this section, using Microsoft Internet Security and Acceleration Server (ISA) as the firewall.

Ee265614.btsdeployment04(en-US,BTS.10).gif

Figure 4. Configuration based on the scenario described in this section, using Microsoft Internet Security and Acceleration Server (ISA) as the firewall

Load Balancing Considerations

To increase performance and optimize the use of processing power in a multiple-server deployment, it is necessary to ensure that new work is submitted to the server that is currently performing the least amount of processing. Load balancing is the process of determining the identity of the server that is currently performing the least amount of processing, and then directing new work to that server.

There are two load-balancing tools you can use in your BizTalk Server deployment:

  • COM+ component load balancing
  • Windows Network Load Balancing Service

COM+ component load balancing

COM+ component load balancing implements load balancing on the middle tier of a three-tier deployment. In a three-tier deployment, the middle tier provides business services. The deployment model described in this section uses component load balancing to distribute the Submit method load across a BizTalk Server data farm where the messages are moved through the DMZ from IIS and Commerce Servers by using Message Queuing. Within a single transaction, a component reads messages from the clustered Message Queuing server, making a Distributed Component Object Model (DCOM) invocation to the Submit method on the IInterchange interface. Although a synchronous implementation can be used, it is recommended that you use the asynchronous model for component load balancing because of the improvement in scalability that can be achieved with Message Queuing.

The following illustration shows a configuration based on the scenario described in this section, using Microsoft Internet Security and Acceleration (ISA) Server as the firewall server.

Ee265614.btsdeployment05(en-US,BTS.10).gif

Figure 5. Configuration based on the scenario described in this section, using Microsoft Internet Security and Acceleration (ISA) Server as the firewall server

Windows Network Load Balancing Service

Windows Network Load Balancing Service (NLBS), a component of Microsoft Windows 2000 Advanced Server and Windows 2000 Datacenter Server, distributes Internet Protocol (IP) requests across cluster members. NLBS is a software-based load balancer that resides on each cluster member. NLBS can be used to distribute HTTP calls across BizTalk Servers running within an IIS data farm. It is recommended that you separate NLBS traffic from BizTalk Server and Microsoft SQL Server™ processing traffic by using two network interface cards (NICs) in each NLBS server.

Building Scalable and Available Web Applications

There are two core models you can use to build scalable and available Web applications. These models are:

  • A synchronous Web-based model.
  • A synchronous façade on an asynchronous back-end processing system.

Synchronous Web-based model

When using the Component Object Model (COM), the SubmitSync method on the IInterchange interface is used to make synchronous calls into BizTalk Server. In this way, a response document can be returned to the caller by using a back-end application integration component or by using an XLANG schedule. If the SubmitSync method is used, care must be taken to handle time-out and back-end application processing component failures. Using an asynchronous model is a more scalable approach to building application services, but it does not always correspond to many of the current synchronous Web application models. A request-response correlation architecture must be implemented to provide users and client applications with the synchronous façade that either provides an asynchronous Submit method invocation, or sends a response to a message queue.

Due to the nature of processing Web applications that require a synchronous HTTP interface, there are many scalability issues. Retaining open connections for long periods of time can make the application unavailable for new requests. The design goals for the processing of Web applications requiring a synchronous HTTP interface are:

  • To receive and save the request, providing the caller with the acknowledgement and assurance that the request was received and understood.
  • To process the request without impacting the ability to receive new requests.
  • To return a response to the caller that is correlated to their request. When the scenario requires, return the response on the same HTTP connection stream of the original request.
  • To support time-outs of the client requests by providing a subsequent mechanism that retrieves stored (queued) responses.

Synchronous façade on an asynchronous back-end processing system

Many businesses want the Web-based user experience (or the programmatic experience) to be synchronous, if possible. However, understanding that there are scalability limitations when implementing a front-to-back synchronous solution, these businesses have chosen to place a synchronous façade on an asynchronous, back-end processing application architecture. In this way, these applications can continue to receive requests at high rates regardless of the back-end processing latencies. The back end can then be scaled out independently of the Web server layer.

The Web page that is accessed passes the message to a stateless component. This stateless component invokes a component (that might be pooled) to encapsulate Message Queuing and save the message to a queue. Either the Web page or the stateless component provides a globally unique identifier (GUID) to each request message. If the stateless component provides the GUID, the GUID is returned to the ASP page as an out parameter or placed into the IIS application or session object. In this way, messages can be safely moved from the DMZ through a single port in the last firewall into the business domain. These messages are then read within a Distributed Transaction Coordinator (DTC) transaction from the queue. This is known as a clustered resource. The messages are then sent in a load-balanced fashion to a data farm of processing servers using either COM+ Component Load Balancing or Message Queuing by a multithreaded component or service.

Designing BizTalk Server Groups

A BizTalk Server group is the key organizing principle in BizTalk Server. BizTalk Server groups are collections of individual BizTalk Servers that are centrally managed, configured, and monitored. BizTalk Server uses the following queues to contain incoming and outgoing documents that are in various stages of routing and processing in BizTalk Server:

  • Work queue
  • Scheduled queue
  • Retry queue
  • Suspended queue

All servers in a group can be configured the same so they perform the same receiving and processing functions. Alternatively, servers can be configured to perform a specific function, such as receive only. The purpose of grouping is to provide redundancy and to increase performance and fault tolerance. This section provides recommendations for structuring a BizTalk Server group.

BizTalk Servers in a group host services that manage document interchange between endpoints and/or applications. These services include messaging components that are used to send and receive documents, and orchestration components that are used to implement business logic and manage state for long-running transactions.

Redundant server group configurations

In a redundant server group configuration, all BizTalk Servers within a group are configured to share the same Shared Queue, Tracking, and BizTalk Messaging Management database. In this configuration, a document is posted to an ASP page. The ASP page is configured to place documents in a specific message queue that a Message Queuing receive function monitors. The Messaging Queuing receive function submits the document to BizTalk Server, where it is placed in the Work queue. The first available server picks up the document from the Work queue and completes processing. This solution enables any server in the group to process the document. The following illustration shows the structure of a group of servers.

Ee265614.btsdeployment06(en-US,BTS.10).gif

Figure 6. Structure of a group of servers

Partitioned or specialized server group configurations

In this configuration, all servers in the group are configured to share the same Shared Queue, Tracking, and BizTalk Messaging Management databases. However, at least one BizTalk Server is specifically configured to receive documents, usually by using the HTTP transport service. A document arrives in a message queue and is picked up and submitted to BizTalk Server. The BizTalk Server that runs the Message Queuing receive function does not participate in document processing. This results in rapid document submission that helps prevent documents from accumulating in the message queue. BizTalk Servers configured only to receive documents provide the following functionality:

  • Decryption, decoding, and digital signature verification.
  • Parsing and document validation.
  • Submitting the document to the Work queue for processing on successful submissions or into the Suspended queue for faulty submissions.

The other BizTalk Servers in the group are responsible for processing. In this partitioned configuration, the server used to receive documents must be part of a fail-over cluster to provide fault tolerance. This is because the receiving server is neither functionally replicated nor redundant. The following illustration shows the structure of a group of servers for partitioned processing.

Ee265614.btsdeployment07(en-US,BTS.10).gif

Figure 7. Structure of a group of servers for partitioned processing

To configure a BizTalk Server to receive documents

  1. Open BizTalk Server Administration, expand Microsoft BizTalk Server 2000, and expand the server group for the server that you want to configure.
  2. Right-click the server that you want to configure and click Properties.

    The Properties dialog box appears.

  3. Clear the Participate in work-item processing check box.

To configure a BizTalk Server for document processing

  1. Open BizTalk Server Administration, expand Microsoft BizTalk Server 2000, and expand the server group for the server that you want to configure.
  2. Right-click the server that you want to configure, click Properties.

    The Properties dialog box appears.

  3. Select the Participate in work-item processing check box.
  4. In the Maximum number of receive function threads allowed box, type a value greater than zero.
  5. In the Maximum number of worker threads per processor allowed box, type the number of worker threads that you want to use.
    Note   The server will not participate in document processing if no receive functions are activated and no applications post documents to it by using the IInterchange interface.

BizTalk Servers running BizTalk Orchestration Services

BizTalk Orchestration Services can either run on the same server that runs BizTalk Messaging Services, or BizTalk Orchestration Services can be scaled out on individually dedicated BizTalk Servers. By scaling out BizTalk Orchestration Services on individually dedicated servers, BizTalk Messaging Services do not need to contend for CPU and file I/O resources with BizTalk Orchestration Services. XLANG schedule activation requires server affinity for rehydrated XLANG schedule instances; therefore, BizTalk Servers running BizTalk Orchestration Services must be clustered in an active-passive manner. Active servers and passive servers are part of a redundant configuration that provides a high level of availability. If the server that is performing the processing (the active server) fails, one or more of the passive servers will become active and perform the processing. In this configuration, if the active server fails, the passive server continues executing the XLANG schedule instances from the last known state.

BizTalk Messaging Services

It is highly recommended that you review the information in the topic "BizTalk Services" in the BizTalk Server 2000 product documentation before you read this section. This section contains background information, information about best practices, and troubleshooting tips relating to BizTalk Messaging Services.

BizTalk messaging objects

BizTalk Server uses the following objects to configure the necessary properties to process and transmit submitted work items:

  • Channels. A set of properties that direct BizTalk Server through the appropriate steps to process documents. Channel properties include a source organization or application, a document definition, a map, and field and document tracking settings.
  • Messaging ports. A set of properties that specify how an interchange or document is transported to a destination organization or application. Messaging port properties include transport services, destination organization or application, security settings, and envelope settings.
  • Distribution lists. A group of messaging ports. Use a distribution list to send the same document to more than one trading partner organization or applications. In the BizTalk Messaging Configuration object model, a distribution list is called a port group.
  • Organizations. The trading partners with which your business exchanges interchanges and documents. An organization can be internal, such as an application of another division of a company. Alternatively, an organization can be external, such as a different business.
  • Document definitions. A set of properties that represents an inbound or outbound document and that might provide a pointer to a specification. A specification defines the document structure, document type, and version. However, a pointer from the document definition to a specification is not required.
  • Envelopes. A set of properties that can represent the transport information for a document. An envelope associated with an inbound interchange or document provides BizTalk Server with the information that it needs to interpret the submitted document. For example, the envelope can contain a pointer to the document definition. An envelope associated with an outbound interchange or document gives BizTalk Server the information that it needs to create the document. Envelope properties are optional for most file formats.
  • BizTalk Configuration Assistant (BTConfigAssistant). This tool enables you to view all of the details of a configuration. It also provides a mechanism for easily importing and exporting configurations, and deploying BizTalk Messaging Services to a new server. BTConfigAssistant is in the Messaging Samples folder in the Microsoft BizTalk Server installation drive. Browse to \Program Files\Microsoft BizTalk Server\SDK\Messaging Samples on the installation drive to find this tool. This is only a relative path. Depending on your installation of BizTalk Server 2000, you might have to modify this path.

Custom BizTalk messaging components

There are several extensibility options for BizTalk Messaging Services. These include the ability to integrate custom components that implement one or more integration interfaces.

BizTalk Server 2000 Enterprise Edition supports product extensibility that enables more complex document processing. The extensions available in BizTalk Server Enterprise Edition are:

  • Custom parsers. To enable parsing of formats that are not supported in the native parsers provided by BizTalk Server 2000, the enterprise edition enables you to create custom parser components that conform to a well-defined parser interface. You can configure these components in BizTalk Server to parse documents for the formats that they support.
  • Custom serializers. To enable serializing of documents into proprietary or other formats that are not supported by the serializers that are provided with BizTalk Server 2000, the enterprise edition enables you to create custom serializer components that conform to a well-defined serializer interface. You can configure these components in BizTalk Server to serialize documents into the formats that they support.
  • Custom preprocessing components. BizTalk Messaging Services support a preprocessing link to the Message Queuing and File receive functions that allows custom components implementing the IPreProcess interface to provide custom processing on the receiving of documents prior to submission to the server.

Application integration components

Integrating with BizTalk Messaging Services using the Component Object Model (COM) at the transport layer is possible by implementing one of two sets of interfaces:

  • IPipelineComponent and IPipelineComponentAdmin
  • IBTSAppIntegration

Any object that implements the interface set (or the single interface) and selects the AIC messaging port transport type will be invoked by BizTalk Messaging Services when a document passes through the messaging port. Registering these AICs with an affinity GUID or within a COM+ application package enables them to appear in BizTalk Messaging Manager.

ASP property pages

AICs that implement the IPipelineComponent set of interfaces can optionally receive additional configuration data at run time along with the delivery of messages on the CDictionary object. The additional run-time data is configured by placing ASP property pages in the directory designated for the property pages (for example, \Program Files\Microsoft BizTalk Server\MessagingManager\pipeline). To select and set the values of these property pages, open BizTalk Messaging Manager and edit the channel. The Advanced button in the last dialog box enables you to set the properties for the primary transport.

Tracking database maintenance

When document tracking is used, the Tracking database will increase in size. It is necessary to implement SQL replication and purge procedures to move data from the Tracking database to a data warehouse. To maintain the Tracking database, you can use DTA_SampleJobs.sql, a sample SQL Server script that is provided to remove records from the Tracking database. You can find this sample script in the \Program Files\Microsoft BizTalk Server\SDK\Messaging Samples\SQLServerAgentJobs folder. Review the readme included with this sample for more information about how to tailor the script to your specific BizTalk Server deployment.

Note   If you are using SQL Server 7.0 with Service Pack (SP) 2, the tables that have image or text columns might not shrink in size, even if you delete rows from those tables in the Tracking database. SQL Server SP 3 helps to alleviate this issue. SP 3 is available at the Microsoft SQL Server Web site (www.microsoft.com/sql/downloads/sp3.htm).

This issue does not occur in SQL Server 2000.

If you configure your BizTalk Server deployment to track documents, you might need to change the following SQL Server settings for the Tracking database:

  • Auto shrink
  • Truncate log on checkpoint
  • Automatically grow file

    The option, Automatically grow file, is the recommended configuration option for the Tracking database.

For more information about maintaining the Tracking database, see "Administering Databases" in the Microsoft BizTalk Server 2000 Operations article.

BizTalk Orchestration Services

It is highly recommended that you review the information in the topics "BizTalk Services" and "Server Administration" in the BizTalk Server 2000 product documentation before you read this section. The Server Administration topics contain detailed information about the configuration of BizTalk Servers running BizTalk Orchestration Services. This section contains background information, information about best practices, and troubleshooting tips relating to BizTalk Orchestration Services.

BizTalk Orchestration .skx and .skv files

In BizTalk Orchestration Designer, XLANG schedule drawings are saved with the .skv file extension. You can then compile the XLANG schedule drawing into an XLANG schedule, which is an XML-structured file with the .skx file extension. The XLANG Scheduler Engine can then process the .skx file. You will need to implement version control for both .skv files and .skx files using products such as Microsoft Visual SourceSafe®.

Implementation technologies

BizTalk Orchestration Designer provides four Implementation shapes. These shapes are used to describe the implementation technologies that are used to implement a port in a business process. The implementation technologies are:

  • COM components. This implementation technology enables you to use preexisting components or applications to perform actions within an XLANG schedule. The COM implementation technology is synchronous. There is always a bidirectional flow of messages when an action is performed.
  • Windows Script Components. This implementation technology enables you to use preexisting components or applications to perform actions within an XLANG schedule, using a Windows Script Component (.wsc) file. The Windows Script Component implementation technology is synchronous. There is always a bidirectional flow of messages when an action is performed.
  • Message Queuing. This implementation technology enables an XLANG schedule to communicate with another XLANG schedule (or with an application), in a loosely coupled manner by using a message queue.
  • BizTalk Messaging. This implementation technology enables you to use BizTalk Messaging Services to exchange messages between BizTalk Orchestration Services and BizTalk Messaging Services.

By visually inspecting the *.skv file, you can build an inventory of the required implementation technologies. It is also possible to create a list of specific binding objects programmatically by parsing the *.skx files and extracting binding-specific elements.

The following code shows XLANG binding examples:

COM binding

<portBinding tag="0!57">
<portRef location="LineItemUtil"/> 
<portTranslation>
  <com:interface tag="0!53" iid="55f3c4f3-fb27-4789-a5bd-263bbc4b672a" 
clsid="a8f6910c-bb6b-4edc-a93c-fa104066e858" holdstate="1" />
</portTranslation>
</portBinding>

Message queue binding

<portTranslation>
  <msmq:queue tag="0!41"
queueName=".\private$\Items_in"/>
</portTranslation>

BizTalk Server run-time authentication and identity

When BizTalk Server is installed, a COM+ application named XLANG Scheduler is created on the system. This application can host or execute XLANG schedules. To simplify setup, especially for developers who initially install BizTalk Server, the COM+ application is configured to run as Interactive user. However, in the deployment scenario it is strongly recommended that you do not configure COM+ applications that host XLANG schedules to use the Interactive user account. Instead, configure COM+ applications that host XLANG schedules to run under a specific user account. This account should be distinct for each host, depending on the types of XLANG schedules that are being executed by the different hosts and depending on the security requirements. Configure access to the persistence database for this account, and configure access to any other required resources.

Configuring BizTalk Orchestration Services

On a computer, multiple COM+ applications can be configured to host XLANG schedules. Hosting the BizTalk Orchestration Services run-time environment in different COM+ applications provides the following benefits:

  • Fault isolation. An access violation in an in-process component used by an XLANG schedule can cause the BizTalk Scheduler Engine to fail. This is similar to a poorly written in-process Internet Server Application Programming Interface (ISAPI) dynamic-link library (DLL) causing Internet Information Server (IIS) to fail. If an access violation in an in-process component used by an XLANG schedule does cause the BizTalk Scheduler Engine to fail, it can affect all of the other hosted XLANG schedules. Therefore, it is recommended that you limit the use of in-process components used by XLANG schedules to those that have been thoroughly tested.
  • Flexible security. Different COM+ applications can run using different security settings (such as COM+ roles).

To create a new COM+ application that can host the BizTalk Orchestration run-time environment:

  • When creating the XLANG host, configure the application to run under a specific user identity (ID), do not use Interactive user. Otherwise, you will need to have the system logged in as this user permanently. This is not practical in a business deployment.
  • Use unique accounts for each COM+ application, but group them together to simplify access control.
  • It is recommended that you group all Access Control Lists (ACLs) in a single Windows 2000 group. This will enable you to use a unique identity for each server application and treat them the same with respect to ACLs on other system resources.
  • Configure a Data Source Name (DSN) for the newly created XLANG host. As described in the "Persistence Database Configuration" section of this article, the DSN can point to a database that is shared by other XLANG hosts within the BizTalk Server group.

For more information, see "Create and Configure an XLANG Schedule Host Application" in the BizTalk Server 2000 product documentation.

Note   For Component Services Administration Help, on the Start menu, point to Settings, click Control Panel, double-click Administrative Tools, and then double-click Component Services. Press F1 or on the Help menu, click the Help topics item.

Persistence database configuration and maintenance

BizTalk Orchestration Services use a Microsoft SQL Server database to manage the state of XLANG schedule instances. A Data Source Name (DSN) must be configured for every instance of an XLANG schedule to ensure that each XLANG schedule instance points to a Microsoft SQL Server database. As part of the setup process, the DSN is configured for the default XLANG Scheduler Engine. A DSN, pointing to a Microsoft SQL Server database, must be configured for additional COM+ applications that can host XLANG schedules. Each of the individual BizTalk Servers running BizTalk Orchestration Services can point to different databases, or share a common database. Using multiple Microsoft SQL Servers introduces additional complexity. It is recommended that you deploy a Microsoft SQL Server that is dedicated to providing state management for BizTalk Servers running BizTalk Orchestration Services.

For more information about how to configure a DSN for a persistence database, see "Manage XLANG Applications and Databases" in the BizTalk Server 2000 product documentation.

The persistence database size must be configured to grow as the XLANG Scheduler Engine persists data about activated XLANG schedule instances. BizTalk Orchestration Services will not remove the information about XLANG schedule instances from the persistence database. This is true even for XLANG schedule instances that have completed. Because the persistence database increases in size with use, it is necessary to implement SQL replication and purge procedures to move data from the persistence database to a data warehouse.

Scripts to purge completed XLANG schedule instances, along with other utilities to manage the persistence database are not included with BizTalk Server. For information about maintaining the persistence database, go to the Microsoft BizTalk Server Web site (www.microsoft.com/biztalk/).

Caution   Do not attempt to create your own tool(s) to maintain the persistence database. By creating and using your own tool(s) to maintain the persistence database, you risk deleting important production data or corrupting the persistence database.

Security

XLANG Scheduler, the default COM+ application that is installed by BizTalk Server, defines the security roles that control which users can interact with XLANG hosts in different ways. These security roles apply to all XLANG hosts configured on a server. It is not possible to define unique sets of users for these roles on a per-XLANG host basis. For more information, see "Security for Applications That Host XLANG Schedule Instances" in the BizTalk Server 2000 product documentation.

Security administration

Security data used to access resources such as message queues and file shares (for example, Domain\Account) must be implemented for the given deployment environment.

Server affinity of XLANG schedules

Instances of an XLANG schedule have affinity to the COM+ XLANG application and the server on which they were activated. This implies that the XLANG schedule instances are not automatically rehydrated on a different server if the server on which the XLANG schedule instance has affinity fails. One way to address this issue is to set up servers running BizTalk Server in an active-passive type of fail-over cluster. In this configuration, if the active server fails, the passive server continues executing the XLANG schedule instances from the last known state.

Message queue size limits

A message queue has a storage limit of 4 MB per-message that is stored in a message queue and a total limit of 2 gigabytes (GB) for all messages that can be stored in a message queue.

Scalability issues

There are several reasons why the scalability of activated XLANG schedules might be affected by a particular deployment. The most common reasons are discussed here. Some of these are not related to the deployment architecture, but relate to the design and implementation of the XLANG schedules.

  • If Microsoft Visual Basic® components are called in an XLANG schedule, a performance decrease is experienced when there is a large number of outstanding calls. The XLANG Scheduler Engine is configured to execute within a multithreaded apartment, and there is only a limited pool of threads that can be used by the XLANG Scheduler Engine to invoke components that need to execute in single threaded apartments. Because all Visual Basic components are single threaded apartments, calls to these components will block if there are many outstanding concurrent calls. To avoid this problem, use Microsoft Visual C++® to create multithreaded apartment components.
  • Low throughput of XLANG schedule instances is often caused by bottlenecks in the database that is used to store the state of XLANG schedules. The problem is amplified when multiple BizTalk Servers are configured to use the same database. Throughput can be improved by configuring BizTalk Orchestration Services to use different databases. For further improvement, the databases can be configured to use different hard disks. Using different Microsoft SQL Servers for some or all of the Orchestration Services is likely to provide even better results.

    Following are two additional methods you can use to reduce the use of the database by the XLANG Scheduler Engine:

    • Review the design of XLANG schedule drawings to minimize the use of the Transaction shape.
    • Review the design of XLANG schedule drawings to ensure that the latency on receive actions is set to a value that is less than three minutes. This prevents the dehydration of XLANG schedule instances that contain rapidly occurring receive actions.
  • Private message queues are known to perform substantially better than public message queues because they do not require an Active Directory lookup. As described in "Persistence Database Configuration," the persistence database might become a bottleneck.
  • Visual Basic components used from COM+ server applications could deadlock and cause XLANG schedule instances to stop responding. This is a known Visual Basic issue. The workaround is to ensure that the components are built with the Retain in memory option set (from project properties in the Visual Basic environment).
  • Avoid making method calls to components that run for an extended period of time.
  • The XLANG Scheduler Engine uses ActiveX® Data Objects (ADO) to save the state of XLANG schedules to the persistence database. By default, ADO installs itself as apartment threaded, which could cause a severe performance slowdown. You can run a batch file that ADO provides (\Program Files\Common Files\System\ado\makfre15.bat) that converts ADO to be "Both threaded."
  • When XLANG schedules using transactions are executed under heavy stress (a large number of concurrent XLANG schedule instances), Distributed Transaction Coordinator (DTC) transactions might time out. This might occur because the XLANG Scheduler Engine enrolls in the application's DTC transaction to perform state management. XLANG schedule designers might not realize this and set the time-out to a value that might work well under low-stress situations but that can encounter problems at higher stress levels. Transaction time-out values of less than 60 seconds are not recommended.
  • In addition to increasing the transaction time-out, the time-out values for ADO connection and commands might also need to be increased. Executing the following code in a .reg file adds the appropriate registry keys to the registry and also sets the time-out values to 300 seconds (the default is 60 seconds):
    Windows Registry Editor Version 5.00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BizTalk Server\1.0\XLANG Scheduler]
    "ADOConnectionTimeout"=dword:0000012c
    "ADOCommandTimeout"=dword:0000012c
    
    

    Unfortunately, the error messages in the event log may not be very helpful when time-out problems occur. The following entries are typically seen in the event log:

    event log:
    Error1 
    The state of the XLANG schedule instance could not be saved to the database. 
       Detailed information is provided in the following message.
    Module name: mymodule
    Module ID: {EE8FB9FA-AB64-492A-A127-56A1EFDB2C50}
    Instance ID: {6B48FF17-791B-474F-8EE2-AD35FF8E5A30}
    Database error(s):
    Error Code = 0x8004e007 : You made a method call on a COM+ component 
       that has a transaction that has already committed or aborted.
    XLANG Scheduler Engine Internals Information:
    File: d:\bts\private\sked\src\runtime\persistence\persist.cpp
    Line: 261
    Error 2:
    An error was encountered while attempting to persist an XLANG schedule instance.
       Detailed information is provided in the following message.
    Error source: Field
    name: __Correlation__
    HRESULT: 0x80040e14
    Module name: mymodule
    Module ID: {EE8FB9FA-AB64-492A-A127-56A1EFDB2C65}
    Instance ID: {6FE02E74-7FE2-401B-93F3-EC208636257B}
    Error Code = 0x80040e14 : 
    
    

Shutting down applications that host XLANG schedules

If you need to bring a BizTalk Server that hosts BizTalk Orchestration Services offline, for example for maintenance purposes, you must perform a controlled shutdown of all XLANG applications to ensure that data associated with XLANG schedules is not lost. A controlled shutdown saves the state for running XLANG schedules to the appropriate persistence database. If you perform a controlled shutdown on the default XLANG Scheduler application, all XLANG schedules are gracefully shut down and preserved. If you perform a controlled shutdown on a COM+ application that you created after installation, only the XLANG schedules associated with that COM+ application are gracefully shut down and preserved. All other XLANG schedules will remain running until you shut down the COM+ application(s) with which they are associated.

To restart the XLANG schedules, you must restart all the schedules at the same time in the default XLANG Scheduler application. You cannot restart applications that are associated with a specific COM+ application.

Message queuing dead letter queues

Each configured XLANG host creates a dead letter queue that is used to store documents that are rejected. The dead letter queue is a private message queue in the following format: <xlang hostname>.deadletter. All XML documents that either fail schema validation or are ill formed (and cannot, therefore, be parsed) are dropped into this queue. Data left in private queues that are created on a per-instance basis for the XLANG schedule is also moved to the dead letter queue before the queues are destroyed.

XLANG schedule activation

The BizTalk Messaging implementation technology in BizTalk Orchestration Services uses a private message queue to pass data between BizTalk Orchestration Services and BizTalk Messaging Services. A private queue is created for each port that is bound to BizTalk Messaging Services when an XLANG schedule instance is activated. The private queue is destroyed when the XLANG schedule instance completes. Per-instance queues might become a management problem when there are hundreds of simultaneously active XLANG schedule instances.

To avoid the use of per-instance queues, use a Message Queuing port, instead of a BizTalk Messaging port, to activate an XLANG schedule. To implement this design, no changes are needed in the configuration of the messaging port in BizTalk Messaging Manager. However, if you require correlation to a running instance of an XLANG schedule, you must use per-instance queues.

Updating XLANG schedules

As newer versions of BizTalk Server become available, you might need to update existing XLANG schedules to run on these newer versions. There are two ways to update an existing XLANG schedule. You can overwrite the original XLANG schedule, or you can add a new XLANG schedule that runs concurrently with the original XLANG schedule.

To overwrite the original XLANG schedule, use BizTalk Orchestration Designer to create a new XLANG schedule drawing and then compile the XLANG schedule drawing as an XLANG schedule that has the same name as the original XLANG schedule. The XLANG schedule drawing is saved as an .skv file. You can then compile the XLANG schedule drawing into an XLANG schedule, which is an XML-structured .skx text file. To update the original XLANG schedule, copy the new .skx file over the original .skx file.

To add a new XLANG schedule that runs concurrently with the original XLANG schedule, use BizTalk Orchestration Designer to create a new XLANG schedule drawing and compile the XLANG schedule drawing as an XLANG schedule with a new name. To ensure that the new XLANG schedule is correctly activated, you must change the XLANG schedule instance activation mechanism to point to the new .skx file instead of pointing to the old .skx file. When you have completed this process, new requests for XLANG schedules create instances of the new XLANG schedule.

Because all XLANG schedules and their components typically work on a per-instance basis, XLANG schedule instances that are in the process of executing the original XLANG schedule continue to run to completion. This includes XLANG schedule instances that have been dehydrated. In this scenario, the execution path continues to follow the original business process, and new requests for XLANG schedules create instances of the new XLANG schedule.

Note   When an XLANG schedule uses an object with an interface that has changed, you must open the XLANG schedule drawing (the .skv file) in BizTalk Orchestration Designer and compile a new .skx file. This updates the binding information in the .skx file, enabling synchronization with the component's type library.

Conclusion

BizTalk Server 2000 enables you to create solutions for enterprise application integration (EAI) and business-to-business integration with strategic trading partners. BizTalk Server 2000 enables Information Technology (IT) professionals and business analysts to build dynamic business processes that span applications, platforms, and businesses over the Internet. BizTalk Server 2000 also enables you to:

  • Integrate dissimilar applications across multiple remote and autonomous business units within a business domain.
  • Implement remote data interchange with external trading partners.
  • Maintain security within your business, even as you use the Internet to expand your ability to implement data interchange with trading partners.
  • Use existing XLANG schedules with future versions of BizTalk Server, as they become available.

For More Information

"Microsoft BizTalk Server 2000 Operations." February 2001. 35 pp. Available on the Microsoft BizTalk Server Web site.

"Orchestrating Business Processes with Microsoft BizTalk Server 2000." February 2001. 22 pp. Available on the Microsoft BizTalk Server Web site.

 

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.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft