Book Image

Microsoft BizTalk ESB Toolkit 2.1

Book Image

Microsoft BizTalk ESB Toolkit 2.1

Overview of this book

An Enterprise Service Bus (ESB) is an architectural pattern and a key enabler in implementing the infrastructure for a service-oriented architecture (SOA). The BizTalk ESB Toolkit is a collection of tools and libraries that extend the BizTalk Server capabilities of supporting a loosely coupled and dynamic messaging architecture. It functions as middleware that provides tools for rapid mediation between services and their consumers. Enabling maximum flexibility at runtime, the BizTalk ESB Toolkit simplifies loosely coupled composition of service endpoints and management of service interactions. The thing about the technology that gets most readers excited is how easy it is to quickly implement flexible and well-architected ESB solutions. "Microsoft BizTalk Server 2010 ESB Toolkit 2.1" provides you with an easy-to-follow view of the tools and services that make up the toolkit. The content is packed with practical examples on how to utilize the technology, which will be appealing to the readers. This book provides you with all the information you need in one publication. The content is based on practical examples on how to use the technology to make it easier for readers to follow. This book starts off with a quick, high level introduction to ESB architectural principles, how these principles map into the ESB toolkit features, and an introduction to the different components that provide those features. The book then reveals the ins and outs of Itineraries. Next, you'll get engaged in the different ways errors can be handled and monitored by means of the ESB Toolkit features. There will be a hands-on sample on building a custom Repair and Resubmit solution to reprocess failed messages. Get to know the different web services that expose the ESB Toolkit features to external applications and how to use them with quick samples. The book ends with a preview to the new version of the toolkit.
Table of Contents (13 chapters)

Understanding the basics

An Enterprise Service Bus (ESB) is an architectural model that defines the patterns to integrate IT systems by interconnecting an ecosystem of loosely coupled and interoperable business services and components in an elastic way. The ultimate goal is to provide a flexible implementation of the enterprise business processes in such a flexible way that those processes can be efficiently adapted to the ever-changing circumstances of the enterprise.

In the following figure, we can see different example business processes that could be run within our ESB, as a set of decoupled business services or stages:

The VETRO pattern

In most cases, a business process is all about how information travels through the process and how it is handled along the way, and thus the ESB model predicates the integration of such business processes in terms of the five basic steps that conform to the VETRO pattern:

  • Validate: This is usually the very first step of the information processing, where we ensure that the information received is in the format expected, although there can be other validation steps along the process. This validation against the mutually agreed service/data contracts ensures that the information flowing through the ESB is legitimate and compliant with the expectations of any system connected to the bus.

  • Enrich: During this step, the information is enriched so it contains all the data required to continue its journey and provide a meaningful input to the target system.

  • Transform: The information is transformed to the format the target system expects and understands. This step could happen as the information arrives at the ESB (where in this case the target system is the ESB itself) where the information would be transformed into a canonical format (quite often defined by the company's Enterprise Data Model), as well as when the information leaves the ESB, transforming it from the canonical format to the format expected by the target system.

  • Route: In systems integration, the information intrinsically has to travel from one place to the other, and that is what happens during this stage. The next step the information needs to take is identified and the route is applied so the process can continue as expected.

  • Operate: The business processes are all about triggering actions within the enterprise that achieve the mission the process is designed for. In this stage, the target system is delivered the input information so any required actions are taken and any expected outcomes are produced. In essence, the Operate step is the invocation of a target service or even an interaction with the target service.

The ESB receives messages from the systems connected to it and performs one or more of the steps mentioned previously. All those steps that define how a message needs to be handled by the ESB are defined as itineraries, that are a set of decoupled processing steps that doesn't necessarily know about the whole process the message just went through or is going to go through afterwards, but they just know what they have to do with the message they just received for processing.

This doesn't sound like rocket science or anything very new, but what the ESB adds to the pattern is the means to make all these stages along the process as decoupled and configurable as possible, so once a process is in place any further changes can be made with the smaller effort and the smallest impact possible on existing systems.

ESB capabilities

An ESB has different features and capabilities that support one or many of the elements of the VETRO pattern.

The main capabilities that support this model in the ESB are listed in the following table:


Mapping to VETRO


Message Routing


Dynamic and configurable message routing allows flexible processes to be changed even at runtime



Adapters and other protocol transformation components facilitate the connections between heterogeneous systems

Exchange Patterns


Business processes usually require different message exchange patterns, such as synchronous/asynchronous, pub-sub, and so on



Systems that understand different data formats and structures require a man in the middle to help them talk to each other

Service Directory


Loosely coupled service architectures require a centralized directory where consumers can find the service they need to use

Rules Dynamic Resolution


The configurable and elastic behavior ESB predicates require a rule system that provides flexibility to the other capabilities of the system



Information needs to be validated to ensure it complies with the definition of the business processes



The business processes are usually composed of multiple subprocesses that will be invoked to enrich and transform the information as the overall process runs

Service Orchestration



Assured Delivery


Some features such as message queuing or assured delivery are required to ensure reliable and predictable execution of business processes

Management and Governance


We need to be able to configure and monitor the behavior of the processes so we are always on top of what is happening in our business



The execution of our business processes needs to rely on a security system that ensures that all the parties involved are who they claim to be and are allowed to take the actions they want to perform

If you have been working with BizTalk Server for some time or have some basic knowledge about its architecture and features, you will find that most of those cover these capabilities any ESB system is required to have, but you will also appreciate that some of them could be implemented in different ways, requiring some extra effort from your architecture team to decide the best way of doing so.

Here is where the ESB Toolkit comes to help. Based on the years of experience of architects and IT teams building integrations solutions with BizTalk, these patterns and capabilities have been packaged as a set of guidelines and re-usable components that will help you to build an ESB solution with a more predictable and efficient result.