Fortunately, if you love the product like you do, you can be assured that BizTalk has not
been relegated to the graveyard by these sexy new ESBs. In fact,
BizTalk forms the very heart of Microsoft's ESB solution. BizTalk is so
important that Microsoft has issued a collection of documents and
components to help you get the most from BizTalk in an ESB environment.
That collection is termed the Enterprise Service Bus Toolkit.
1. Functional Capabilities
The question that you should be
asking yourself at this point is, how can BizTalk, which has always
been positioned as a hub-and-spoke EAI engine, now act as an ESB? Some
people might suspect that Microsoft is simply trying to take an existing
product and squeeze a little more life out of it by rebranding it to
align with the architectural flavor of the day.
Well, in order to answer this question, you need to take a look at the capabilities that most ESBs typically need to provide:
This is not meant to be an
exhaustive list of all ESB requirements or a formal definition of an
ESB. The focus of this article is Microsoft's ESB Toolkit and not the
concept of ESBs in general. We've just included this list to give a
general baseline with which to compare the core functions that an ESB
provides against the native capabilities that BizTalk provides. Any
experienced BizTalk developer will quickly see that a large number of
these ESB requirements align nicely with the capabilities that BizTalk
already provides.
2. Aligning the ESB with Your Core SOA Goals
Now, if you were to look at
these functional requirements only, you might easily arrive at the
conclusion that BizTalk can act as an ESB for you. This would not be a
bad conclusion per se; however, before settling on this conclusion, you
need to stop and look beyond these core functional requirements. ESBs
are simply one layer within an overall SOA. Therefore, you need to
remember some of the core principles that are driving the decision to
adopt SOA in the first place. Flexibility, agility, and reuse are three
key goals of SOA, and since the ESB is just a layer within the SOA, then
it too needs to be aligned with these goals.
You probably design
services with the goal of having them be reusable building blocks that
can be easily composed or assembled into new business processes. As
business requirements change, you expect that you will be able to
quickly modify these services and the processes they are a part of. The
hope is that SOA will provide you with an application platform that is
quicker to adapt to change and that can be modified with less effort
than the older monolithic applications can. To achieve this, developers
are designing services to be loosely coupled, highly reusable, and
generic. Since an ESB is a core building block within an overall SOA, it
needs to strive to achieve these same goals. An ESB should make it easy
for applications to quickly locate and consume remote services and
allow developers to quickly compose base services into larger processes.
An ESB must not, under any circumstances, become a bottle-neck to the
overall speed at which services, processes, and applications can be
developed or modified. It really needs to be a lightweight, flexible,
and generic layer that sits between service consumers and service
providers.
3. BizTalk as an ESB?
It is this need for
reusability, flexibility, and agility that makes some people question
BizTalk's ability to function as an ESB. In the past, BizTalk was
positioned as an EAI engine that functioned as a hub-and-spoke solution.
Within its role as the hub, BizTalk had to know everything and define
everything. For example, it required a schema for every message it would
ever process. Its send ports had to be configured to point to specific
locations. Receive ports were configured to pick up specific messages
from only one exact location. It was not unusual for BizTalk solutions
to be very large, complex, and tightly coupled. They rarely resembled
the flexible, agile, and reusable type of solution required for an ESB.
However, just
because BizTalk solutions have traditionally been implemented this way
does not mean that they need to be. In fact, BizTalk has many dynamic
tools and components that can be used in a highly reusable and dynamic
manner to build very flexible solutions. So, the issue is not that
BizTalk is inherently inflexible but rather that people have not been
designing their projects to take advantage of the flexibility that it
does provide.
One example of this is the
way in which most developers use maps inside BizTalk. Most developers
use a map either by linking it directly to a port or by using a
Transform shape in an orchestration. Both of these approaches require
that you specify the map name while developing and configuring the
project. By specifying the map during development, you are essentially
hard-coding the map name into the project. That map and only that map
will run when a message is processed. This results in an incredibly
tightly coupled solution.
To support the goals of the
ESB, what you really need is a mapping engine that will allow you to
specify a map name at runtime instead of at design time. This way, you
can determine the name of the map that you need just as a message is
received, and then you can dynamically execute that one map. The next
time you receive a message, you might decide that you need to run an
entirely different map.
What many BizTalk
developers do not know is that BizTalk already has this functionality
built in. BizTalk's mapping engine can be invoked directly via .NET
APIs. These APIs allow you to pass in the name of the map you want to
run at runtime. Therefore, if you spend a bit of time writing code, you
can implement a very dynamic, generic, and reusable mapping service
using BizTalk.
4. Getting Developers on Board
There are many other
examples showing how BizTalk can be used in a more flexible and generic
way. So, a valid question to ask is, if BizTalk has these dynamic
abilities, why are developers and architects not using them? The quick
answer to this question is fairly simple; many developers either do not
know about these features or do not understand how to use them. Or they
find them difficult to design, troubleshoot, and maintain. Now, if this
were the only problem, then it could easily be solved through simple
education. However, there is a second reason that it is much more
problematic. To use a lot of these dynamic capabilities, developers have
to write a significant amount of code on their own. They have to build a
bunch of "plumbing" to hook together all of these BizTalk components in
order to implement an effective ESB. Most developers have neither the
time nor the mandate to work on this type of plumbing and instead need
to focus on the core needs of the business.
Therefore, it is simply
not practical to tell someone that BizTalk can function as an ESB as
long as they're willing to invest a fair amount of time to develop all
of this required plumbing. You are faced with a significant gap between
what BizTalk can do in theory and what is practical to do in reality.
It was this gap that drove the
initial development of Microsoft's Enterprise Service Bus Toolkit. The
ESB Toolkit has a number of key goals:
Providing an architectural toolkit on how to use BizTalk as an ESB
Reducing the amount of plumbing that developers need to build in order to implement the prescribed architecture
Providing
ready-to-use components and tools that reduce the amount of time and
effort that organizations need to invest in order to deploy an ESB
Providing detailed samples and a toolkit on how to use the ESB Toolkit components to implement common integration patterns
In this toolkit (or, as
we'll often refer to it, the ESB Toolkit or ESBT), Microsoft has built a
number of new components and frameworks that allow you to use BizTalk
in a much different way than you have in the past. This toolkit really
represents a new way of thinking about BizTalk and a new way of using
it. Essentially, you can think of the ESB Toolkit as an accelerator that
sits on top of BizTalk in order to implement a highly reusable,
flexible, and generic ESB.
Version 1.0 of the ESB
Toolkit was first released to run on top of BizTalk 2006-R2. Version 2.0
was released shortly after BizTalk 2009 was released. We will do the following:
Review the architecture and concepts that make up version 2.0 of the ESB Toolkit
Review the components and frameworks that are used to implement the ESB Toolkit architecture
Show how to use these tools and components to implement common ESB requirements
NOTE
The ESB Toolkit was
initially developed by Microsoft's Patterns & Practices team, and it
was released through Microsoft's open source project-hosting site
CodePlex. With version 2.0 of the toolkit, Microsoft no longer includes
the source code for the core components as part of the default
installation, and it is no longer available via CodePlex. The toolkit is
now available at www.microsoft.com/downloads/.
