Harry Pierson on BizTalk

by | Jan 18, 2007 | BizTalk Community Blogs via Syndication

Harry
Pierson talked a bit about the stuff he’s learning on BizTalk Server in Morning
Coffee 12 entry (btw, loving the, keep it up!). Looks like he’s attending a great
class with Matt
Milner. A few comments that sparked my interest:

Harry says that conceptually BizTalk hasn’t changed all that much since the 2000/2002
days. I’m not sure I’d agree, but that would depend on what he means by “conceptually” :-)

I’d say that from an architecture point of view, the the change between 2002 and 2004
was a very significant one, requiring you to adapt to a lot of new stuff. Here’s
why I feel this way:

  • The orchestration engine was pretty much rewritten. The designer by itself is a great
    improvement, but it’s far more than that:
    • There’s no more interpreted XLANG, now we have XLANG/s
    • Orchestrations (*.odx) are compiled down to C# and then to MSIL.
    • Now we have a pretty powerful correlation mechanism as well as convoys.
    • Native .NET support (it is .NET after all!)
  • The messaging model changed significantly:
    • Most of the terminology changed. Remember channels, AICs and Receive Functions?
    • The messaging model is now mostly symmetrical, unlike in 2000/2002 where the send
      and receive sides were very different.
    • The pipeline model is far nicer (have I mentioned I love pipelines? they’re fantastic!).
    • The adapter framework. Sure beats down anything we had in 2000/2002! Writing adapters
      is still hard, but writing them in .NET is far easier. Application Integration Components
      (AIC) were a kludge, anyway.
  • New features:
    • Enterprise Single Sign-On
    • Business Activity Monitoring: Don’t disregard the power of BAM, it’s one of the coolest
      features in BizTalk and coming soon to WCF and WF thanks to the new BAM interceptors
      for WCF and WF in BizTalk 2006 R2.
    • Business Rules Engine

Maybe it’s just me, but I do consider that the change between 2002 and 2004 to be
very significant and a much needed improvement. But I’d agree that from some points
of view, yes, BizTalk is still BizTalk (e.g. you still use it for the same and a lot
of the usage scenarios haven’t changed at a conceptual level). Personally, I consider
understanding the BizTalk architecture an absolute must for any BizTalk developer,
and as you can see, I get all excited talking about it :-)

Harry also mentioned something I’ve heard a lot of people say: that the Pub/Sub engine
in the BizTalk MessageBox was mostly useful for messaging-only scenarios. I agree
that’s what it might seem so at first but just to reinforce what Matt said in the
class: The Message Box really is the heart of BizTalk and the Pub/Sub engine in it
is exactly what gives it that power!

So let me briefly enumerate just why the Pub/Sub engine is extremely relevant to orchestrations
in BizTalk:

  • The Pub/Sub engine processes any message that comes into BizTalk, and that includes
    messages that fire orchestration instances. Even when you do the simplest Port to
    Orchestration bindings, subscriptions are still created/evaluated/matched in the MessageBox
    to enable the processing to happen.
  • The MessageBox message store, which as Harry correctly points out, can be thought
    of (to a degree) as a set of queues, coupled with the Pub/Sub engine gives BizTalk
    some pretty powerful features. One of them is the capability to balance processing
    loads between multiple BizTalk processing servers in a single BizTalk Group.

    Basically the idea is that you can have a single BizTalk Host with multiple instances
    (example, instances HA and HB in servers A and B respectively) and when a message
    is received and fires an orchestration instance, then BizTalk might start some of
    those instances in server A and other in server B. That’s something you get mostly
    for free with BizTalk (though you still need to know how to take advantage of it and
    how to architect for it).

  • Direct Binding: Direct
    binding     exposes the Pub/Sub model in the MessageBox to Orchestrations like no
    other binding model does. It allows you to create orchestrations that are not bound
    to a physical receive or send port but rather that directly subscribe or publish messages
    to the MessageBox. This gives you a lot of power and flexibility in how orchestrations
    connect to each other and how they connect to ports because it allows you to use them
    and harness the full flexibility offered by the Pub/Sub engine.
  • Correlation Sets: A correlation basically gives you the ability to route an incoming
    message into an existing orchestration instance (i.e. one already up waiting for it),
    instead of always firing a new instance. When you initialize a Correlation Set what
    essentially happens under the covers is that a new temporary subscription is
    created (called an Instance Subscription), so the Pub/Sub engine is pretty important
    for this aspect as well.

    This is actually one of the aspects that I find more lacking in the current Windows
    Workflow Foundation implementation, and it’s the lack of a reusable, generic correlation
    engine. There is a basic correlation support for the HandleExternalEvent and InvokeExternalMethod
    activities, but it’s not really very reusable. This means pretty much every developer
    creating custom IEventActivity implementations needs to build their own correlation
    mechanism if its needed, and it can be quite a bit of work, specially if you need
    to make it work across a farm of machines hosting the workflows (BizTalk already
    does this for you thanks to the Message Box architecture).

Hopefully this makes it more obvious just how important the Pub/Sub engine in the
Message Box is to BizTalk Orchestrations! Did I mention I love this stuff?