Microsoft BizTalk Server 2002 enables you to build business-to-business (B2B) solutions and integrate your own internal systems. Using BizTalk Server, you can tie together applications that would otherwise not communicate with one another, allow your customers to access your line of business servers and applications, or allow you to access your own suppliers’ and partners’ systems and applications. Because BizTalk Server is so powerful, as you can imagine, it’s almost equally as complex. Before you reach for the BizTalk Server CD and run Setup, you have to prepare your network.
BizTalk Server 2002 in a nutshell
BizTalk Server acts as a gateway between systems, whether local or remote, enabling disparate systems and applications to communicate and share data. BizTalk Server orchestrates the exchange of XML documents between applications, which allows them to share their data with one another. BizTalk’s Messaging Services is the key component that enables BizTalk Server to send, receive, parse, and track documents; generate and correlate receipts; and map and validate data in the documents. Orchestration Services lets you define relationships between processes, and specify how documents are created and processed.
BizTalk Server Accelerators speed the process of deploying custom BizTalk Server solutions by providing preconfigured schemas and other tools needed to connect specific types of systems. For example, the HIPAA Accelerator helps health industry IT administrators quickly connect systems without running afoul of the HIPAA requirements.
In short, BizTalk Server is a bit like a black box that sits between disparate systems. It handles the bi-directional translation and processing needed to enable those systems to communicate. It can shave literally thousands of hours off the development time you would otherwise spend creating a custom application to serve the same purpose. For more information about BizTalk Server, see the Daily Drill Down “Learn how you can build your B2B around BizTalk Server 2002”.
BizTalk Server deployment models
Before we get into firewall planning and other network infrastructure issues, you first need to understand the deployment methods you have for BizTalk Server. BizTalk Server can address both B2B and enterprise application integration (EAI), and how you deploy BizTalk—including network infrastructure changes—naturally depends on how you’re going to use it. In the simplest scenario, a single BizTalk Server serves as a hub for other systems that need to communicate with one another. For example, you might need to connect an inventory control application with a purchasing application, each residing on a different server. BizTalk would sit between these two and manage the flow of information between them. This single BizTalk Server could handle multiple servers and applications.
This point-to-point hub deployment is an efficient and inexpensive way for small- to medium-size companies to integrate applications, but it’s not a viable choice for larger organizations that need to provide fault tolerance, load balancing, and/or access by external partners. To serve these more complex deployments, BizTalk Server supports the Publish and Subscribe (Pub-Sub) model for application integration.
In this model, an application publishes information and another application subscribes to that data. The Pub-Sub model greatly simplifies integrating a large number of applications or partners because, rather than create individual point-to-point connections between applications, you instead create a common framework for an application to publish its data. Multiple remote applications can then subscribe to that data. For example, you don’t need to build a separate connection to each of your partners to enable them to tie into your ordering system—you need only to publish the data they need, then allow them to subscribe to and use that data.
BizTalk Server supports this one-to-many model through distribution lists, which are collections of previously defined BizTalk Server messaging ports. Each messaging port references another application or organization. You can then create channels for specific document types to cause them to be delivered to the distribution list, and thereby to the other applications or organizations. Taking a broader look, you can create a distribution bus of BizTalk Server groups that each serve a particular department, division, or one or more external partners. Each server group can accommodate the specific needs of its own target clientele.
The first step in planning a BizTalk Server deployment is to determine which model suits your needs. If you’re integrating a handful of applications within your own organization, then a point-to-point model with BizTalk Server as the hub is probably the best, most cost-effective solution. If you need to integrate several applications in several departments, however, or you need to support external partners, you need to look beyond the point-to-point model and consider a distributed model.
Begin by mapping out the applications and clients you need to integrate and support. At this point, your diagram won’t reflect the actual network infrastructure or physical server relationships, but instead will reflect the logical flow between applications. As you learn more about how BizTalk Server works, you can begin to translate that logical diagram into actual network and server structures.
Any time you need to grant an outside entity access to some portion of your network, you open a hole that presents at least some security risk. Opening a hole in the network to a friendly partner is like unlocking a door to your building: Anyone can walk in if they’re persistent enough, whether they work for that partner or not. Exposing your Web site to the world is one thing; exposing your purchasing or inventory system generally has much greater security risks. That’s why it’s important to focus on issues that will affect your firewalls and network security infrastructure as you begin planning a BizTalk Server deployment.
BizTalk Server supports three main mechanisms for receiving documents: HTTP, File, and Message Queuing. You configure these protocols through the BizTalk Server Administration console. BizTalk Server can also use HTTP and HTTPS (SSL) through ASP pages and IIS, FTP through IIS, and SMTP through an Exchange Server script.
Each of these protocols naturally has implications for your network. If you already have port 80 open to service HTTP requests, then HTTP might be a likely choice for BizTalk Server communications. Choosing other protocols for external access would mean opening the corresponding ports on your external firewall, and is certainly a workable solution. You just need to be aware of what ports are open and what security risks they entail.
BizTalk Server works in concert with IIS, Commerce Server, and similar Web service platforms to provide the framework by which the traffic passes through the external firewall to the waiting BizTalk Servers. A common approach is to place the Web servers in the perimeter network and place the BizTalk Servers behind the internal firewall where they and the data they serve can be better protected. You could simply pass the traffic through port 80 to the internal network, but you could also use other methods to move the data in and out.
For example, you might use port 80 to pass traffic through the external firewall, but use HTTPS over port 443 (or a port you choose) to pass the traffic into the internal network. In either scenario, network load balancing can distribute the traffic load not only to the Web servers in the perimeter network, but also to the BizTalk Servers on the internal network.
Using off-the-shelf components and standard protocols and ports isn’t the only option you have for moving data to and from the BizTalk Servers. You can create a custom application that sits on its own server between the Web servers and the BizTalk Servers to perform transactional message handling. The application would pull messages from the Web servers’ queues and send them to the BizTalk Servers, distributing them to provide load balancing. This custom application would also handle traffic moving from the BizTalk Servers to the Web servers. Using such a custom application naturally requires that you perform the development efforts needed to make it happen, but allows you to use Message Queuing Services (MSMQ) for increased reliability.
As you begin planning the deployment, take a look at how your BizTalk Server groups need to interconnect and communicate. Also look at your partners, if any, and decide the best, most secure way for traffic to flow between you and them. Look at your existing network infrastructure—particularly as it relates to Internet access—and decide which protocols and communication methods make the most sense for your deployment. With that information in hand, you can start planning the changes and additions—including firewall changes and filtering—that your network will require to support the deployment.
Clustering and load balancing
Clustering and load balancing are probably not issues if your organization is small and you are integrating a small number of applications and systems. As the number of systems grows, or you begin to extend your enterprise applications to your business partners, load balancing and clustering become important considerations. Clustering can even be important for very small BizTalk deployments.
If your business relies on two mission-critical applications talking to each other, then your deployment is certainly a candidate for clustering. If you can’t afford the many hours it would probably take to put everything back together from backups after a major failure, you need to add failover capability.
As I’ve already mentioned, BizTalk Server can rely on the Network Load Balancing (NLB) service built into Windows 2000 Advanced Server, Windows 2000 Datacenter Server, and .NET Server Enterprise Edition and Datacenter platforms. NLB allows traffic to be directed to least-loaded servers, distributing the processing load across multiple servers. At a minimum, each server should have two network interfaces: one to handle the NLB management overhead traffic and another to handle the BizTalk traffic.
BizTalk Server and IIS can also both implement COM+ load balancing, which is included in Microsoft Application Center 2000, as an alternative load balancing mechanism. This type of load balancing is specifically designed to support distributed COM+ applications and messaging, so this is the mechanism you would likely use if you create a custom COM+ application to move the traffic between your Web servers and the BizTalk Servers. If you’re not using COM, then NLB is a less expensive alternative.
When you move past load balancing, the next consideration is clustering, which will provide failover capability for your Web servers and BizTalk Servers, as appropriate to your requirements. BizTalk Server itself provides built-in redundancy in that the BizTalk Servers in a server group all share a common SQL database server. If one server in the group fails, the others continue processing requests without interruption because the servers don’t maintain any data locally. If the SQL Server goes down, however, then all of the BizTalk Servers are figuratively dead in the water, even though nothing has happened to them directly. So, you should consider clustering for SQL Server if you need to ensure uninterrupted access.
Microsoft Cluster Services (MSCS) is included with Windows 2000 Advanced Server and Datacenter Server, as well as with .NET Server Enterprise Edition and Datacenter Server. MSCS supports clustering of up to two nodes under Windows 2000 Advanced Server/Enterprise Edition and four nodes under Datacenter Server. It’s also available as an add-on service for Windows NT Server for up to two nodes. Applications must be cluster-aware to function under MSCS.
In an MSCS cluster, servers each have their own file system for the operating system, but share a storage system for clustered applications and data. The primary function that MSCS provides is to ensure application availability through failover, which is the ability of the cluster to move application processing from one server in the cluster to another when a hardware or application failure occurs. For example, if one of the servers in our BizTalk SQL Server cluster fails, the transactions being handled by the failed server can migrate to a healthy server in the cluster. When a server comes back online in the cluster, the application can fail back to the original server.
MSCS provides stateful clustering. When a server goes offline, the server fails over to another server in the cluster without losing the data associated with each failed application. Therefore, in stateful clustering, the cluster maintains the user and application state during a failover, with the user and application state failing over to the other server.
An important advantage to MSCS not directly related to failover is its ability to accomplish rolling upgrades without taking a service offline. For example, when it’s time to upgrade SQL Server in your BizTalk cluster, you take one server out of the cluster and any current connections fail over to the remaining nodes. You upgrade the server and then restore it to the cluster, where it resumes its duties. You then sequentially upgrade the other servers in the cluster in the same way. At the end of the process, you’ve upgraded all your servers while still providing uninterrupted service to your users or customers.
When you’re planning your BizTalk deployment, consider availability for your SQL Servers and their data, and then plan clusters accordingly. Keep in mind that the database and other common data will be stored on a storage device common to all servers in the cluster. This presents some hardware considerations that you might not have experienced if you’ve never created a cluster. Do your homework on the Cluster service to learn what shared disk subsystems you’ll need to make it happen.
When you’re considering clustering, look past SQL Server to some of the other components and services that will support BizTalk. For example, message queuing through MSMQ can be clustered to provide additional fault tolerance, which is an important consideration if you’re using MSMQ in your BizTalk topology. File servers that handle BizTalk-related files are also candidates for clustering. For example, if you’re using text files to transfer data between BizTalk servers or partners, the target file servers should be protected by clustering. In addition, consider clustering the WebDAV repository, which BizTalk Server uses to store XML document specifications, maps, and flat file conversion specifications.
There are many different configurations you can choose when clustering to support BizTalk Server. However, BizTalk Server only supports active/passive clusters. That is, only one server in the cluster can be active. If the active server fails, the process fails over to another server in the cluster, which then becomes active. However, you can divide the BizTalk services among multiple servers in a cluster such that, for example, one server handles the Messaging services while the other handles Orchestration services.
For now, understand that clustering is an important aspect of a reliable and effective BizTalk Server deployment. As you begin to design your logical and physical server structures, keep in mind that messaging should generally be clustered for best reliability. Also, SQL Server should definitely be clustered because it is a common potential failure point for all of the BizTalk Servers in a group. You can place SQL Server on the same cluster node as BizTalk Server, although you should not do so if the database will serve several servers in a group or you anticipate a heavy load on the database. Split the functions onto different servers and clusters if you expect the servers to be hit hard.
Finally, don’t forget that even though BizTalk Server doesn’t support active/active clusters, you can delegate separate BizTalk services to different nodes within a cluster. This lets you distribute the load while keeping your server costs down—nodes in a cluster won’t be idle waiting for a failure to occur, but instead can pull their share of the weight.
It’s not as bad as it sounds
Network security, load balancing, and clustering are all core supporting technologies that you’ll need to understand before you get too far into your BizTalk Server deployment planning. You’ll need to understand how the protocols come into play, how the traffic moves through your firewalls, and how you can configure those firewalls to allow the necessary traffic in and out while still protecting the network and your servers. Take some time to bone up on load balancing and clustering with an eye on shared disk subsystems, network interface issues such as IP address sharing, and related issues. In particular, develop a good working knowledge of SQL Server clustering because, at the very least, your databases should be clustered.