Hi all, not sure how many parts there will be to this subject but there could potentially be 'lots'.

I thought I'd let you know that a new version of BizTalk is being released on Sept. 14th and MS Corp have decided that Sydney (our international cosmopolitan) city is one of 3 places for a World Wide Launch.....coool.

So a typical BizTalk conversation goes something like this.....
"Biz.... what? I think we had one of them but the wheels fell off..."
Then I'll walk into the client site and see 20 000 lines of custom integration code with a consultant telling they wrote it all themselves......
Me: "You could have used BizTalk and written 2000 lines of code and be finished 9 months earlier"
"Oh!"

The 64 million dollar question is "What is BizTalk?" "How does it help me?" (I could at this point start to read some bullet points off the back of a cereal pack but let's get comfy.

To developers BizTalk provides an Environment/Framework in which to impliment reliable messaging based solutions, be it short or long running, async or sync. This 'environment' is comparable to COM+ (or MTS those who remember) and COM. As developers we all jumped into these COM+ applications, because they provided all the nice things and we could get on with specific coding. Faster time to market.

BizTalk provides a great 'integration' environment - it's able to talk on many different layers and be 'plugged' directly into various application layers such as SAP, SIEBEL, Oracle Financials - with the intention of doing this out of the box.

BizTalk can consume/publish all sorts of Services be it WS/WSE/WCF services (the latter I'll expand on).

All the work that BizTalk does, is performed out of the BizTalk environment. This 'hosting' environment is durable, reliable and fault tolerant. Also BTS servers are 'cluster ready' and we can slice and dice the amount of processing load in many different ways within our 'cluster'. Given to you straight out of the box.

Internally BizTalk likes 'things' to be XML based keeping it adhearing to Business process standards/WS-* standards/BPEL standards....in English - it's standards based through and through (good to know when you're talking to other systems). BTS translates from document format X to document format Y. e.g. flatfile to XML; XML to EDI; flatfile to EDI etc etc.

So at this point developers will be saying "I've got Workflow Foundation, I've heard I should use it, unless I'm talking to NASA...then I should use BizTalk"
- yes and no. In my experience of production working with WF for 18 months (I was on TAP programs etc), someone who says there's no need to write code for WF.....you can call 'Shinanigans!'. Any *meaningful* WF Demo, the presenter will usually go to some snippet library and copy in about 10 000 lines of WF code and say "10 mins in the oven...and it looks like this - viola!"

At this point in the game - WF is a framework. It is designed (actually by the BTS core engine team :) to be plugged into any environment; from ASP.NET webpages to Excel spreadsheets. It has a 'rule engine' class and all the bells and whistles - WF as colours, graphics and nice flow diagrams. Visually it's superb - I love the fact that it's visually descriptive.

Back to the point - WF is now being plugged into Sharepoint, Speech server, Office Communication server etc. Brilliant and great. Workflow within your apps - all cool.

Problem: We still have to find a place to run our Workflows. BizTalk provides a great hosting environment for many elements - why not include WF?

WF + BTS can live together very nicely to solve a problem. Generally BTS provides the fault-tolerant environment while WF performs the actual state to state transition actions. Security/Role checks and verification can all be done by BTS at the front door. I've given a MSDN webcast on this very topic. Onwards.....

A very cool feature of BTS (that I haven't been able to find elsewhere) is something called Content Based Routing (or CBR for those in the know :)
This gives us (the solution designers/developers) to essentially determine the path a message should take through Biztalk (I call 'plumbing') based on the data it contains. e.g. if an Order is less than $500 or greater than $500. This is pretty powerful for many reasons.

We also have a BizTalk rules engine that is pretty optimised, executes fast and we can get access to it via .NET classes if desired. Wrap it in a WCF/WS service and boom - you've got a central rules engine accessible from everywhere (NOTE: a common request is client's wanting to utilise the Rules Engine only. Easiest and cheapest way is to buy BizTalk RFID services as the Rules Engine comes with it - approx US$1800)

Instrumentation and Monitoring
A feature of Biztalk is Business Activity Monitoring (BAM) - this allows us to track/monitor all sorts of aspects to how BizTalk is processing our work. From time taken, to mins and max's as well as sums and totals; written away into a SQL OLAP Cube for BI analysis etc. (BTS comes with an ASP.NET BAM site where we get some great functionality).

Importantly we can also publish other information to BAM from our own non-BTS applications; WCF Services and WF workflows that run. This in essence gives us full End-to-end monitoring of 'what BTS is doing'

Publishing WCF Services (I'd better wrap this up just looking at the time....)
Developers - we love WCF Services (those who worked extensively with each of the underlying technologies - MSMQ, Pipes, etc will know the pain.

From a dev/design perspective - in a BTS-less world we publish our first WCF Service, run around the office cheering like all your footy tips came in on the weekend. Let's say your WCF Service has a 'receive' operation (two-way) and you'll send something back.

As per good WCF programming we have 'Data Contracts' (things that specify the 'shape' of the message) underlying this service exposed through an EndPoint - works a treat.

Let's move on a little - you're then asked to expose another endpoint for a different 'message shape' (hence another Data Contract) and generally it will be a different Endpoint.

For 5 messages this is approach is cool....for 55 messages......your IT pro guys aren't inviting your to their BBQs anymore....and we think it's time for a new bottle of Lynx!

Enter BizTalk!!! In BTS land we can publish 1 endpoint - 'ReceiveAllRequests'. BTS upon receipt of the inbound message, will dynamically do a look up on the 'Data Contract' for a matching schema and apply it.

Thus what you have 'deployed' in the BTS environment, BTS will use. Whether it's 5 or 5005 different 'data contracts'/schemas/message types. If I can be a little cheeky - BTS has evolved in the WCF Service space by providing ways of already managing the need for multiple WCF Services/Endpoints.....imagine....deploying a solution with just 1 endpoint.....

(I walked into a client site the other day with over 400 WCF Services.....oh yeah!! it certainly was SOA......shame it didn't save a customer :)

It's goodnight from me and good night from him....hope you enjoyed and talk soon.

Cheers,

Mick.