Microsoft recently released BizTalk Server 2004 as a product to facilitate the implementation of a Service Oriented Architecture (SOA) within an enterprise. The product is designed to encapsulate business processes formerly conducted by tightly-coupled, difficult to maintain applications which functioned as silos and replace them with a universal, transaction-based messaging system.

This capability will provide enterprises with an easy to maintain, and to modify, system of business process automation that is asynchronous in nature. Since the language of BizTalk is XML, this allows great versatility when communicating across disparate platforms via internal applications or external trading partners. Additionally, with a rich set of integration components called adapters provided out-of-the-box and via third-party vendors, the cross-platform messaging capability between applications is greatly enhanced. The sections in this continuing series about implementing BizTalk 2004 in an enterprise discusses the steps required to begin development following a review and understanding of core BizTalk components.

Installing BizTalk 2004

The product installation for BizTalk 2004 is not a directly straight forward process. In order to install the product, there are several prerequisites that must be completed to a server prior to beginning installation. From a developer perspective, there are a variety of methods to set up BizTalk and begin development.

Same Machine Installation

Most developers may choose to install BizTalk Server 2004 and the development component on their primary development machines. This ensures that the development tools and the server environment are always available and no additional communication or security configuration would have to be completed in order for development and testing of an orchestration to proceed. This is often the fastest and simplest approach to begin development in BizTalk.

However, this approach can lead to issues when deploying to a quality assurance or production environment. Typically, server installations won’t have the same security configuration, network communication levels or components as those installed on the same machine the orchestration was designed on. Developers must be wary that if this configuration option is chosen that modifications may be required to allow the orchestration to be deployed to a remote BizTalk server.

Developer/Server Installation

Developers can install BizTalk Server 2004 in a more separated capacity, simulating the “real world” configuration of the production BizTalk environment from the start. This means that the developers will work through configuration management for the product, and ensure that prior to completion of orchestration development, that all requirements are considered for the orchestration to operate on a stand-alone BizTalk server.

One method to accomplish this is to use a common BizTalk development server running on separate hardware. Developers will install the BizTalk developer components (the BizTalk tools integrate directly into the .NET IDE) while registering a remotely installed BizTalk Server (without the development tools installed). This simulates the production environment and eliminates any assumptions that developers make due to the server and the development tools existing on the same machine.

If server hardware for a shared environment is not available, or developing multiple orchestrations simultaneously with a common BizTalk server is not feasible, developers can use virtual machines. Using Microsoft Virtual PC 2004, each developer can maintain their own fully configured BizTalk 2004 server environment and achieve the same benefits as if there was a separate physical server.

Installing BizTalk Server 2004

Once the installation methodology is chosen, the remaining tasks are to complete the install and begin development. Regardless of the methodology, the following list details the requirements for the BizTalk Server 2004 installation. These elements are listed in order of precedence and thus, must be installed in order. 

 Table 1.1: BizTalk Server 2004 installation requirements and order.

In addition, the BizTalk configuration wizard will require some domain accounts. Ensure your network administration team is available during the installation process to create service accounts. Refrain from running the server, even in a development environment, with your own user account (due to security requirements like password changes, and so on).

Developing and Deploying BizTalk Server Orchestrations

Once the installation is complete, and the development methodology chosen, orchestration development can begin. Following the accumulation of business requirements, accompanied by a technical design document, developers must now learn about the components of BizTalk (previously mentioned in this article) and combine them into functioning BizTalk assemblies.

Additionally, developers must be able to provide and articulate deployment methodologies to administrators so that orchestration promotion to quality assurance and production servers becomes a smooth transition.

Learning and Development

The task of learning about the components of BizTalk, when to use them and how to combine them to form the first orchestration, can be challenging. At this point, there are sparse resources and tutorials on available on the subject. Additionally, classes and official literature from Microsoft Press are planned for October of 2004.

One of the best ways for developers to become familiar with the tasks of developing and deploying orchestrations is to install the SDK from the product media and begin reading and understanding the samples. The product is not necessarily intuitive (not enough to be picked up with relatively little to no experience and quickly learned), and background in the components is a must. This is one product where actually installing and following the sample guide documentation is extremely beneficial.

During the development process, orchestration designers will continuously deploy and test the orchestration. During this process of continuous development and unit testing, developers should become familiar with the deployment model and methodologies for BizTalk Server.

Deployment

Once development and unit testing of a functional orchestration is complete, developers must begin to address the deployment methodology for the orchestration. There are two significant components to orchestration deployment. The first component is to deploy the assembly created by BizTalk and configure the binding of send and receive ports. This is accomplished using a specialized Setup and Deployment project in the .NET IDE specifically for BizTalk assemblies. The second component is to register the assembly to be deployed with the BizTalk message box database. Both of these steps are required to successfully deploy an assembly.

The BizTalk 2004 SDK provides a sample deployment project which allows developers to package their orchestration into a familiar .msi file. The MSI file can be turned over to server administrators for deployment.

BizTalk 2004 requires that developers register all assemblies generated by the IDE with the Global Assembly Cache (GAC) on the destination server and consequently have them signed with a strong name. In fact, the .NET IDE will prohibit successful orchestration compilation unless a strong name is specified. Once the assembly is strong named, developers can utilize the MSI deployment practice.

The MSI installer project is not a project type available in the .NET IDE, but must be copied for each BizTalk solution and added as a project. Configure the project by including the primary output of your most dependent project (it will automatically include the least dependent if you have project references set). Additionally, developers must ensure all BTS assemblies are included in the Global Assembly Cache folder within the setup project (the GAC folder may have to be added manually in the setup project) and all other files should be excluded with the following exceptions: BTSIAssemblyOrder.DLL, BTSICustomAction.dll, btstd.xml, BindingSchema.xml.

The BizTalk deployment wizard can export an XML file of binding information for the binding of orchestration assemblies to receive ports and send ports, once these ports are created and configured on the server. Once complete, the project can be built and the MSI can be deployed to the server.

The second part of the deployment activity is to deploy the configuration information about the assembly to the BizTalk MessageBox database. This essentially informs BizTalk that the assembly is present and that message processing on the orchestration can begin. This activity of deploying configuration information to the BizTalk MessageBox database can be done within the IDE. This can be accomplished by configuring solution build actions in the solution properties dialog box. In this dialog, developers can specify to which BizTalk server to deploy.

Monitoring Deployed Orchestrations

The best method of ensuring successful orchestration deployment is post implementation monitoring. BizTalk provides tools and capabilities for developers and administrators to conduct this monitoring in great detail. The heath and Activity Tracking (HAT) utility can monitor and track orchestration processes, messages and errors. Additionally, information can be obtained from the application event log.

The HAT tool requires the use of Office Web Components 10 or above to present its data. Essentially, the HAT allows administrators and developers the ability to query the MessageBox database using a series of preformatted queries executed from the HAT interface. Additionally, if the MessageBox database schema is studied and understood, the HAT allows custom SQL to be submitted against the MessageBox.

The HAT utility is an excellent method for determining the processing capabilities of an orchestration. Additionally it allows administrators to clear suspended messages in the event of an orchestration error. By default, the HAT installs on the BizTalk Server machine but can be installed on other machines for remote monitoring. Administrators can also use HAT to display information about processing steps messages undertake as they pass through orchestrations. This type of real-time monitoring and tracking provide developers with a palpable window into what their orchestrations actually do with messages. This tool also allows for orchestration debugging and stepping through the process that a message will follow in the orchestration.

Post Deployment Integration

One of the most powerful benefits of the BizTalk product is the way that it allows business users to communicate processes to BizTalk developers. Another benefit is how quickly developers can create easy to maintain orchestrations which conduct business processes without writing tightly coupled code. There are many additional components to BizTalk’s implementation within a Service Oriented Architecture that can further tighten the relationship between the business and the implementation of the business rules (there is a Visio add in that allows business analysts to create basic orchestrations for import into the orchestration designer).

From a monitoring and intelligence standpoint, BizTalk comes packaged with a data warehouse structure to query and receive real-time alerts and statistics about orchestrations and their transaction processing. These capabilities seamlessly integrate with other Microsoft products. The following table illustrates how each product can be used to provide business users and administrators with insight into transaction processing with BizTalk.

 Table 1.2:BizTalk integration and monitoring solutions.

Additionally, there are specific tasks required to scale out a BizTalk server implementation into BizTalk Server Groups. Maintaining the components of BizTalk, including the MessageBox database and tracking databases, Analysis Server databases for BAM and other server components are also tasks that are specific to the product and should all be considered as necessary elements when implementing an SOA with BizTalk. In the near future, the BizTalk product will be available to work with the Indigo messaging subsystem that will be introduced by Longhorn.

These significant changes in application architecture and business process implementation methodology signal the maturation of the SOA concept. By using BizTalk Server 2004, organizations can realize the benefits of these concepts.

--

Eric Charran is currently working as a Technical Architect and Web Developer, in Horsham, PA. Eric holds Microsoft Certifications in SQL Server and has significant experience in planning, designing, and modeling n-tier applications using SQL Server 2000, as well as architecting and implementing .NET framework based applications, solutions and Web services. Eric’s other professional skills encompass Database Administration, Data Warehousing and Application Architecture, Modeling and Design, as well as Data Warehouse Transformation and Population using DTS. Eric is also skilled in developing and implementing ASP.NET and Windows forms applications, using technologies such as COM+, the .NET framework, VB.NET and other .NET languages.