4.2 BizTalk Server Deployment

---

Deploying a BizTalk Server configuration can be an involved process, depending upon the business requirements.

Small and medium-sized organizations can often use a single BizTalk Server as a routing and transformation hub. All of the necessary channels, schedules, and ports are built to support the specific integration requirements (see Figure 4.15).

Figure 4.15: Hubbased BizTalk Server for small and medium-sized organizations.

Larger organizations should probably consider the use of a more distributed and manageable solution than the single small-business hub. This distributed architecture is often referred to as publish and subscribe, shortened to Pub-Sub, and it allows an element of abstraction so that publishers and subscribers to data is unaware of each other. With this model, systems can be plugged and unplugged from the data integration bus with no impact on any other publisher or subscriber. BizTalk Server can be configured to support this data bus approach (see Figure 4.16).

Figure 4.16: Using BizTalk Server as a data bus.

Whatever architecture is chosen, typical deployment considerations would include the following:

• Security and firewalls

• Scalability and load balancing

• The design of the BizTalk Server groups

• Setup of messaging and orchestration services

4.2.1 Security and Firewalls

Of importance to any integrated system permitting files to be submitted from 'foreign' sources is security. Most of BizTalk Server security is based on either Windows 2000 or Microsoft SQL Server, which is used to keep data secure in the messaging management database. If you are building COM+ components, either SQL Server or Windows authentication can be used.

Windows 2000 security features, and therefore BizTalk Server, include the following:

• Public-key infrastructure

• Microsoft component services

• Microsoft Cryptography API

• Kerberos Protocol

Certificates are a useful tool for securing data with a trading partner, but do require some time-consuming management and, for large-scale installations, may prove to be a significant administration overhead. Probably a more popular model would be to use Secure Sockets Layer, or SSL. SSL is a feature of Internet Information Server, IIS, that negotiates an encryption algorithm between a Web client and server, checks key information, and authenticates the validity of the server to the client. Data is then encrypted using session keys negotiated in the initial handshake process.

Most organizations would use a firewall to restrict network traffic to HTTPS and FTP protocols. A limited number of other ports may be opened, such as port 80 for HTTP, and double firewalls are often put in place to isolate Web servers from an internal LAN (see Figure 4.17).

Figure 4.17: Secure BizTalk configuration for Web access.

4.2.2 Scalability and Load Balancing

There are three layers to BizTalk Server: the BizTalk services, SQL Server, and the transport services. All of these can influence how any BizTalk Server installation will perform at any time. BizTalk Server supports either scaling up or scaling out, depending upon the strategy that you wish to adopt (see Chapter 10 for further details).

To scale up a BizTalk Server installation, all of the usual rules apply- fast processor with a large level III cache, SMP box with eight processors, 512MB RAM, multiple disks and controllers for message queuing, distributed transaction coordinator, and dual network cards. In addition, BizTalk Server ideally needs to run on a dedicated server to ensure full access to these resources.

4.2.3 HTTP/HTTPS

If you are using HTTP/HTTPS, configure the inbound Receive service on a server separate from BizTalk Server. If you must use the same server, add additional hardware to cater to the processing of inbound documents. Some organizations I have worked with have failed to cater to this inbound traffic, which has significantly affected BizTalk Server performance.

4.2.4 File Receive

The file Receive function can be sped up by placing the receive directory on a local server rather than a network server. This removes the network latency; although small per file received, it can soon mount up. Using a disk array can also improve throughput.

4.2.5 SMTP

SMTP is designed for network e-mail, and as such is not as scalable as it could be when used to deliver documents to BizTalk Server. Any SMTP product-be it Microsoft Exchange or another-will need to have additional hardware added to ensure it is able to cope with BizTalk Server document submission. If you plan to use S/MIME, expect even further degradation in performance unless you add significant additional hardware.

4.2.6 Message Queuing

Transactional, local queues on BizTalk Server are much preferred to remote queues; they avoid network latency and the need to query Active Directory. Extra performance can be gained by switching off transactional queues, but nontransactional queues will not offer the same level of reliability.

---