BizTalk Server has been around for quite a long time, evolving over the years and becoming one of the most complete and powerful middleware products in the market, helping thousands of companies to fulfill their requirements in terms of Systems Integration.
With such a powerful product and the flexibility it provides to implement integration solutions, it's more than useful to have at hand a set of architectural patterns and re-usable components. These will support our design and help us to reach the most successful result possible. And here's where the ESB Toolkit comes into the picture.
In this chapter, we will have an overview of:
- What is Enterprise Service Bus (ESB)
- What are the architectural principles that define an ESB
- How the ESB Toolkit helps to build better integration solutions
- What are the ESB Toolkit features and components
The content within this book is not meant to be a long dissertation about the different architectural terms and acronyms coined over time that lead into the definition of what an ESB is about. We will save you some time by going straight to the point of defining the basics of ESB so you can spend that extra time on enjoying a good BBQ.
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:
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.
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:
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.