BizTalk is a broad and inherently flexible product that can be used to build a large variety of applications; however, it exists to solve very complicated problems, it has a long ramp-up time associated with it, and many people simply find it too daunting to consider. As a reaction to these hurdles, this article will discuss different application styles that can be built with BizTalk instead of attempting to describe it and its features. A set of questions for determining when BizTalk Server could be used will also be presented.

We won't try to cover all the application styles that can be built with BizTalk. Some applications styles are very similar, differing only in why they would be implemented not in how they would be implemented. We'll cover the most common styles of applications that we've encountered.

BizTalk Application Styles
Real-world applications built with BizTalk Server will vary widely in how closely they subscribe to any one of the following styles and they will often be a blend of several of the ones presented in this article. Industry jargon is avoided when possible to keep the descriptions as free from misinterpretation as possible. The application styles will be presented starting with the simplest and moving on to the most complex but only in a very general sense.

Messaging
The Messaging application style is one of the simplest that can be built with BizTalk. It's also the most prevalent application style because it serves as the basis for almost all the others. In this application style, messages enter BizTalk from a publishing system and BizTalk sends them to one or more subscribing systems. The publishing system can send a message to BizTalk or BizTalk can retrieve the message from the publishing system using a polling mechanism. The publishing pattern used for implementation depends on the scenario as well as the BizTalk Adapter that's used.

This application style is defined by asynchronous message processing and routing. Internally, all messaging is asynchronous inside BizTalk although from a client application perspective it can appear to be synchronous processing. Message routing refers to the process of determining which subscribers an incoming message should be sent to. Additionally, this application style often involves message transformations from one data and/or structure format to another data and/or structure format due to system differences or requirements.

All other application styles mentioned in this article except the Business Rules Engine use the messaging application style as the foundation of their own style.

Business Rules Engine
The Business Rules Engine application style is also used as a foundation for other application styles. This doesn't mean that this application style is simple. In the Business Rules Engine application style, business rules are abstracted so that they're not compiled. Instead, they;re stored as metadata and executed in BizTalk's Business Rules Engine (BRE), which is implemented in the .NET assembly provided with BizTalk. This means the rules can be modified without requiring re-compilation and in some cases without IT staff involvement.

The Business Rules Engine application style can be used from BizTalk or as a standalone server-side rules engine. When used "standalone" the BRE will need a distributed technology wrapper (Web Services, .NET Remoting, etc.) to act as a façade.

This application style can range from being quite simple, such as when it's used as a configuration store, to quite complex, such as when it's used to manage complex, frequently changing credit-scoring rules.

Enterprise Application Integration
The Enterprise Application Integration (EAI) BizTalk application style is a very common application style whose complexity varies widely based on the complexity of the applications involved, their data formats, and the messaging patterns used. In this application style, two or more applications in the same organization are integrated using at least the Messaging application style. Transformation is almost always involved because the applications being integrated usually have different data formats and data requirements.

EAI applications can range from high-throughput batch-like processes where heavy volumes of messages pass from one system to another in a short period of time to near-real-time messaging where messages flow from one system to another as business events occur. Combinations of these two types of the EAI application style are common as well.

BizTalk is well suited to this application style and can remove the point-to-point integration solutions that define many existing EAI implementations.

Business to Business (B2B)
The B2B BizTalk application style is also a very common BizTalk application style whose complexity varies widely. One facet of the B2B style that can make it more complex than the EAI Application style is that multiple organizations are involved which can make project responsibility and accountability challenging. Otherwise, it's very similar to the EAI application style except that the systems involved reside in different organizations. Messaging is always involved and transformation is usually involved for the same reasons outlined in the EAI application style.

B2B applications also range from high-throughput batch-like processes to near-real time processes. B2B applications often involve a suite of common protocols including FTP, SFTP, FTPS, HTTP, SOAP, SSL, and various EDI protocols.

Application Façade The Application Façade application style is very common and can range in complexity depending on the types of applications and their number. In this style, BizTalk acts as a façade between consumers that use a service and the application that provides the service. This usually requires a low-latency solution because the consumers are often end users utilizing client applications.

There are many reasons for using this application style, including decoupling systems, eliminating point-to-point integration solutions, and implementing aggregations from multiple providers behind a single façade.

When application façade s aggregate information from multiple providers their complexity can increase greatly because of performance issues, stale data, down systems, time-outs, conditional system usage based on context, transformation to a common message format, and filtering.

Application Server Replacement The Application Server Replacement application style is very similar to the Application Façade except that it's centered on a single application. This application has become more common over the last several months.

In this application style, standard .NET Web Services, .NET Remoting objects, or other application server technologies are replaced with BizTalk Server and a series of SOAP or HTTP services hosted in BizTalk. There are many reasons for doing this:

• To prepare for future integration, or future movement to an Application Façade or Service Oriented Architecture
• To use BizTalk's ability to scale easily to meet increased volumes
• To use the BRE as a core piece of the application server
• To use BizTalk's Business Activity Monitoring to learn more about the application's usage and the data flowing through a system