Introduction
I have heard they ask "How would you explain Excel (any product) to your grandmother?" in many companies; a question popularized by Microsoft, I believe. First, I am not so sure my grandma would understand any technology product so easily. Also, I am not sure if this is a good question to ask a software developer; maybe, to someone from sales, yes! On the record, I must say that my grandmother is an incredibly smart lady. So the question really boils down to "How you would make an IT common man understand what a product is all about?" This is what I am trying to endeavor in this article.
Sometime back, I had to explain to a group of non-IT folks about BizTalk Server. You know the people who wouldn't understand all these geeky terms like SOA, XML, SOAP, or Orchestrations (pardon me, she says she knows about SOAP!). I thought I'd share my experience here in this article for the benefit of the CodeProject community. This article is aimed at you if you have heard about this wonderful thing called BizTalk Server, and want to understand what it is clearly before diving into the marketing material which seems to be the same for every product - the "panacea" of all your problems.
Drawing a Parallel
BizTalk Server is Microsoft's enterprise application integration solution, with built-in support for XML and SOAP. It offers integration with Visual Studio .NET, and provides speed, reliability, and flexibility for standards-based enterprise application integration. An analogy they say is "Similarity in some respects between things that are otherwise dissimilar". So for me, to explain BizTalk, I would start off with an analogy. In the section below, I am comparing BizTalk Server to a Customs facility.
The Customs Facility
What we have in the figure above is a Customs facility. We have an Import Terminal through which a large number of packages come in by different modes of transport: planes, ships, buses, trucks, barges. These packages then go through a standard inspection process, with several stages including identifying the package, unpacking the contents, and then identifying the shipper. The packages then go to a central store. From there, customs inspection of the packages takes place. The process could be different for different types of packages, and there is a "Customs Inspection Rules and Regulations Manual" which details the inspection process, and which in practice, gets updated from time to time. After a package passes the inspection process, it is sent back to the central store, from where it is packaged and sent to the correct destination.
The BizTalk Server Architecture
The figure above is the architecture of a BizTalk Server messaging subsystem. As you will notice, this figure is same as the previous figure except for the labeling. Here, instead of packages moving, we have XML messages that are moving. The files come in through Receive Ports and are passed to the "Message Box" through a "Receive Pipeline". They are then picked up by "BizTalk Orchestrations" and are processed. Custom rules maybe loaded and executed at this point. They are then send out using a Receive Pipeline through a "Send Port" to the destination.
Receive Ports
The Receive Ports are how messages come into BizTalk. Messages can come into BizTalk by any means of transport like HTTP, SOAP, SQL, file, EDI; just like the way packages arrive via planes, ships, buses, or trucks. How they are transported does not change how they are processed later. This is a very powerful feature because it gives you the ability to change the transport type and the source of the data even after your application is deployed, without changing your application implementation. For instance, let us say some sales related data is coming in from a shared "FILE" folder in Europe connected via WAN today, tomorrow you can configure it as an FTP pickup from a remote server from India, or probably accept it as an HTTP request over the web posted from a browser.
Adaptors
Adaptors are the BizTalk way of handling additional transport. Just like you can have a private plane fly your package in, you can write your own adaptor for a custom transport, like say POP3. So there is always scope for buying or writing your own custom adaptor to integrate with all the other available transports. For instance, you can have a DB2 adaptor or a SAP adaptor.
Receive Pipeline
The Receive Pipeline contains different mechanisms like "Decoding" (if encoded), "Disassembling" (if there are multiple parts), and "Party Resolution". This is similar to the unpacking and identifying the sender, in our example. Just like we have an express lane for certain packages, there is a "Pass Through" pipeline facility in BizTalk which is essential a smooth transfer to the Message Box. Just like you can have special handling instructions for certain packages, you can write custom pipeline components using the framework.
Message Box and Subscriptions
The BizTalk Message Box lies in the heart of the BizTalk messaging subsystem; this is like our central store. This message box is, in fact, realized as a SQL Store; so this way, BizTalk ensures reliability for your messages in terms of guaranteed delivery. Even if a node in BizTalk fails, the message will be picked up by another node in the farm. BizTalk also ensures that it does not delete the file from a pickup folder location while using file/any transport, unless it is persisted completely in SQL. Well, this also means you need to have a fault tolerant SQL Server architecture. Just like we will be noting down a few important details while we unpack the packages, in the pipeline, certain properties are promoted into the context, like transport information: the most important of these being the incoming XMLSchema#RootNode. The BizTalk Publish-Subscribe mechanism identifies which Orchestrations subscribe to that particular message, based on this promoted information, and routes it accordingly.
Orchestrations
Orchestrations are processes that are defined in the Business Process Execution Language (BPEL). This could be something like, say: if quantity is greater than threshold, apply discount, else standard discount. At this stage, you can also change the format of the message using Transformation Maps, or you can call some other web service to do an operation like credit card verification. This is like our example in which we have the customs inspection process and checking with the bank if the excise payment is cleared.
Business Rules Engine
Business Rules Engine is used by BizTalk to load the current policies which are a collection of Rules from the Orchestration. These rules are kept separately as these could change from time to time. In our example above, this would be something like, during Olympics there could be certain relaxations in guidelines or certain promotions in effect. These change from time to time, and they are kept separate. This is the idea behind the Rule Store in BizTalk.
Send Pipeline
The "Send Pipelines" are just the opposite of the "Receive Pipelines" and they do operations like "Encoding" the message, or "Assembling" or "Signing" the message. This is like packing and sealing a package before we send it. Just like we have different types of packaging like bubble wrapping and cushion mailers, there could be different pipeline components at this stage.
Send Ports
Send Ports also handle transport like receive ports, but their direction is the reverse. Here, the message direction is from the Message Box to the destination. Send Ports can subscribe to a message directly from the Message Box, without passing through the orchestration. This is like having a package coming in from a certain shipper which has a prior clearance attached with it. This is called Content Based Routing (CBR).
Summary
The example above of the Customs facility is certainly flawed when you think deeper because the BizTalk Server is way more powerful than this example to illustrate. But for a person who is quite new to BizTalk, this is a good start. I hope this article has addressed that objective, has got you excited about BizTalk, and has lived up to its title.
I feel a small sample is in order here, at the least a CBR, maybe picking up a file and sending it to an FTP location or maybe even another folder. But I guess that has to be another article, to stay within the scope of the original objective.
P.S.: The views expressed in these essays are those of the author, and in no way represent, nor are they endorsed by Microsoft or anyone else, as far as I know.
History
- Version 1.0 - January 25, 2006.
