Technologies and techniques used to develop and implement applications to solve business problems have made several evolutionary strides within the past decade. Methodologies and practices surrounding client-server applications evolved into n-tier applications in which Web applications were, and still are, prevalent. These n-tier applications ushered in an era of ubiquitous access and no-touch deployment for complex workflows and application functionality to clients. As of late, many technologies introduced by the .NET framework now extend those attributes back to the thick client application model. Now called “smart clients,” developers and businesses can enjoy the rich experience and interfaces of a Windows application while realizing no touch deployment, offline synchronization capabilities, and operation over the Internet.

The Service-oriented Architecture

The next evolutionary steps of software technologies and practices exist as the implementation of a Service-oriented Architecture (SOA). This framework philosophy has rocketed to the forefront of those charged with solving business problems with technology, and has come to the attention of those who are responsible for controlling cost of ownership and increasing maintainability.

As more and more applications are being built to store and transform data, there is a prevalent need within many enterprises to ensure that these data stores do not become islands or information silos. In other words, it is important for many of these applications to interoperate and share data. In this manner, code reuse and the componentization of IT infrastructure and applications is ideal. There are several methods to accomplish this goal today. Microsoft recently introduced Web services as an approach to allow disparate corporate applications communicate with each other and share data and functionality.

Web services were a key step in ensuring that several separate applications and processes could find a common method to communicate. This caused a paradigm shift in the way developers built software. No longer did developers have to regard their application as closed or sealed monolithic pieces of code. The software development model shifted to ensuring that open and extensible design patterns were followed so that other applications could build off of routines, objects, properties and methods encapsulated in a building block fashion.

This shift encapsulates one of the base principles of a SOA. The goal is to componentize applications that contain business logic into generic units of functionality that can be referenced in more specific consumer applications. Continuing along this supposition, a new trend has emerged. Instead of a myriad of small, highly focused, custom applications calling each other in specific ways, the goal is to encapsulate business processes in a software framework that allows for quick and easy maintenance and adjustment to business processes, while promoting the building block concept of application development.

BizTalk 2004 and the Service-Oriented Architecture

Microsoft has released BizTalk Server 2004 as a method of providing this software framework to allow organizations to implement a SOA. While this is not the first version of the product, it is the first version designed on the .NET platform. As a result, it is fully aware of .NET technologies and integrates directly within the .NET IDE.

This product serves as the glue between multiple business processes. The advantage is that developers no longer have to write custom, tightly coupled and highly specific applications to link to one another. This requirement has been replaced by BizTalk. The BizTalk product was designed to serve as a method of linking information silos and sources of data together within an organization, while providing support for transactional consistency, advanced business processes and ease of maintainability. As a result, BizTalk lends itself directly to helping facilitate Enterprise Application Integration (EAI) as well as to external trading partners (B2B).

The BizTalk product promotes a paradigm shift in software design that supports asynchronous and long-running transactions. In this manner, applications conduct communication through messaging instead of synchronous calls. It can be argued that this approach provides the ability to stem bottlenecks that are traditional encountered in many applications today.

Through the use of a system of adapters or interfaces into popular technology frameworks and the use of several built-in workflow and task management capabilities, BizTalk allows for the concrete definition of a business process in workflow format and the maintainability of that process that provides integration across multiple platforms.

There are several scenarios for using BizTalk. Many organizations are adopting the product as a replacement for EDI within the organization. A popular example is the product’s capability to support a P.O. purchasing process. Other applications might be more operational and can include a credit card processing service for an e-commerce site, or transaction processing between two business entities using asynchronous messaging.

One of BizTalk’s strengths is its flexible integration with other platforms. It interoperates with other platforms out of the box and third-party vendors are completing their own adapters to enable BizTalk to talk to their platforms. Coupled with the new design surfaces in the .NET IDE, developers can quickly build and deploy workflows that tie together varying business processes without writing tightly any coupled code. This ability makes it easy for other developers to visualize workflow rules, modify them, and deploy them as the business process evolves.

The following section outlines BizTalk components and defines the nomenclature common to BizTalk.

BizTalk Components

BizTalk is comprised of several components ranging from applications that provide the capability to monitor business processes, to designing and deploying orchestrations. Each of these components is described from differing aspects of functionality.

Leveraging BizTalk Components

From a developer’s perspective, the experience in creating a BizTalk assembly is integrated into the Visual Studio .NET IDE. When installing the product, users can elect to install the developer tools, which integrate into the IDE. This provides several additions to the IDE, including new project templates (BizTalk Projects), a BizTalk Server Explorer (similar to the IDE’s Server Explorer) as well as new design surfaces, including toolboxes, schema tools, and other elements that allow BizTalk development.

Once the developer has these tools installed, design for the specified business process can begin. This process definition is called an “orchestration.” This fundamental BizTalk object defines the steps of a workflow, actions within that workflow, and any additional transactional consistency and rollback requirements for a business process. The entire software development concept behind BizTalk is asynchronous messaging. Thus, all inputs to an orchestration are received through ports and consist of messages. Each message consists of data housed in an XML Schema defined during the orchestration creation. Completed orchestrations consist of .NET assemblies that must be strong named and deployed. However, during this entire process, the developer does not write any actual code. BizTalk attempts to shift the paradigm from having to write code that must be maintained to having a design surface that easily encapsulates the process in a graphical manner.

Once the developer completes the orchestration, several steps must be done to allow BizTalk to compile and deploy the assembly. Below is a list of terms that outline some important development-based concepts for BizTalk.

Orchestration

An orchestration represents the logic behind workflows that represent business processes. Orchestrations define the actions to be taken when a message (information bound to an XML schema) is received. Developers use the orchestration designer to define activities to be executed when a specific type of message is received on a port. Orchestration design is facilitated by the .NET IDE and a design surface or canvass onto which developers can drag shapes and workflow pointers to create a business process.

The design process for an orchestration, while different than writing actual lines of code, is similar to the process for constructing traditional assemblies. Just as with a traditional assembly developed using C# or VB.NET, output messages, source control messages, and compile messages are still communicated to the developer in the same fashion. Developers must successfully compile an orchestration before it can be deployed.

Port

A port is an early- or late-bound entry and exit (Send and Receive) point for messages within an orchestration. A port may be set up within BizTalk to receive a message of a specific type (defined by an XML schema during design time by the developer).

Once the orchestration is connected or bound to this port, it automatically processes messages by obtaining them from the port. Consequently, when completed, it can send messages (transformed, contrived, or otherwise) to a send port. Ports can be defined in the BizTalk explorer and can simply be placeholders during design time in the orchestration.

Adapter

Adapters are an object that provide BizTalk with the capability to talk to multiple software platforms and facilitates the push or pull of messages between the orchestration’s send and receive ports. In essence, the adapter gives BizTalk the ability to conduct messaging and transactions with source systems.

There are several adapters that come with BizTalk Server, including the SQL Server Adapter, Flat File Adapter, and so on. In the case of the SQL Server adapter, BizTalk will be able to reach into a SQL Server database and pull out information. This information will be mapped to a schema and can be passed to a Receive port that is looking for information of that type.

Schemas

Schemas define message types that the orchestration will process and the ports will send or receive. In many instances involving message transformation, a developer will build an XML schema that relates to incoming information provided via an Adapter. The BizTalk inspects the message schema and attempts to assign the information provided by the adapter to the schema defined for a port in the case of an incoming message. BizTalk then looks for an orchestration based on the message type. Once it finds the orchestration, it initializes an instance of the orchestration (in reality, a .NET assembly) and hands it the message.

Schemas are developed using a new .NET IDE tools that support quick and easy schema design using a drag-and-drop interface. These .xsd schemas then become the model for orchestration messages.

Mappings

Mappings provide a method of modifying and transforming information from an incoming message and transmitting the modified information as part of an output message. Developers will use the BizTalk Mapper in the .NET IDE as a means of transforming elements in a message schema to elements in an output schema. The BizTalk Mapper also provides support for Functoids. Functoids are objects that can be dropped onto the BizTalk Mapper canvass to provide enhanced transformation capabilities during a mapping operation. These functions include common string, numeric and date time modifications, and manipulations. A link provides a direct method of transforming the data from the incoming message to the outgoing message.

Pipelines

Pipelines exist as precursors to the actual workflow and tasks in an orchestration. Pipelines often facilitate the transformation of messages from their original format into that of XML so BizTalk can process it and map it to schemas. Pipelines can also enhance the transformation of the message by providing encryption or decryption as well as expose properties for programmatic or expression manipulation in an orchestration.

BizTalk Infrastructure

The BizTalk infrastructure consists of an engine component that services the actual messaging and orchestration instances as well as a series of components that provide monitoring and activity tracking. The primary data store and operational requirement for BizTalk 2004 is SQL Server 2000. The following sections describe the BizTalk components.

BizTalk Server Engine

The BizTalk Server Engine allows developers to create and implement orchestrations and manages those orchestrations as they conduct messaging transactions between applications. The engine hosts orchestrations as .NET assemblies, controls their instances, as well as provides the framework for the components in the previous section. As a result, the entire process of message reception through a receive adapter; processing through a pipeline, storage, and processing through an orchestration instance; and transformation/transmission through an outgoing port and adapter are all driven by operational components of the engine.

MessageBox

The BizTalk engine stores all of its data, including messages, operational data, and other informational elements in the MessageBox. The MessageBox exists as a SQL Server database that is established during the configuration phase of product installation.

The MessageBox database stores subscriptions and tracking information as well as provides a channel to deliver messages to matching subscriptions. Additionally, the MessageBox stores metadata about each BizTalk host. This information can be reported on by using the built-in tools for message tracking and activity monitoring.

Because the MessageBox database is critical to the operation of BizTalk, the primary method for ensuring availability is to provide a clustered SQL Server environment for the MessageBox. From a scale-out perspective, multiple MessageBox databases can be added to a BizTalk server installation. TBy using the configuration wizard, administrators can add additional MessageBox databases for increased message processing. These new MessageBox databases are created on additional SQL Servers.

Establishing BizTalk within the Enterprise

Once developers are familiar with the concepts surrounding SOA within the enterprise and are conversant in the ability of BizTalk’s various components and capabilities to provide the framework for a SOA implementation, the next task is to begin establishing a development instance. Part 2 of this series on BizTalk focuses on the requirements of establishing a BizTalk Server installation, as well as developing methodologies and practices for the product.

--

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.