Yossi Dahan [BizTalk]

Google
 

Tuesday, November 06, 2007

Subscriptions and multi-part messages

As we all know at the heart of BizTalk there's the publish subscribe mechanism that determines what process gets a copy of a message to work on (and where); we also know that most typically a message is assigned a message-type when it enters BizTalk, which is typically composed of the root node and xml namespace, and that most often it is the message type that drives those subscriptions.

It is also often said that BizTalk is a strongly typed system, although, I suspect, this refers mostly to the orchestration environment and less to the messaging environment as almost anything in an orchestration, as it is in programming languages such as the C# or VB.net, has a type (class) and an instance.

For example - when you want to declare a port - you are really first declaring a port type, and then a port of that type; when you create a correlation set you first define a correlation type, and then a correlation set of this type, etc.

Unfortunately, when it comes to messages, quite possibly the most fundamental item in an orchestration, the picture gets a little bit more confusing -

In an orchestration you can create a message out of four "things" -

  • A .net class - in which case the class is the type behind the message

  • A schema - in which case the xsd is the type behind the message

  • A multi-part message type - in which case you are required to declare the type first in the types section of the orchestration view pane.

  • A web part - in which case a multi-part message type has been created for you when you've added a web reference.


  • While all four options follow on the type-instance approach, which keeps the statement that an orchestration is a strongly typed environment correct, it can be somewhat confusing to understand to those beginning with BizTalk Server.

    However - what's furthermore confusing is that there seem to be a gap between what a message type means in the orchestration environment and what it means in the messaging environment, and there's a potential for confusion where the two meet -

    As discussed earlier, in the messaging world a message type is typically the root node and xml namespace when dealing with Xml, when dealing with .net types the same applies if you consider the xml that is a result of a serialisation of the class as what determines the message-type (and not the class itself) it is the serialisation attributes that will determine the namespace and root node used and as such the message type used.

    The question is - what is the story with multi-part messages in the messaging layer?

    Well - the basic answer is quite short - in the messaging layer - the namespace and root node of the body part of a multi-part message is used as the message type.

    This, however, can cause some problems with subscriptions and developers must be aware of this difference of approach between the two layers -

    Lets see if I can demonstrate this with an abstract scenario -

    I create a solution with two orchestrations - ProcA and ProcB
    I also add to my solution two schemas A.xsd and B.xsd

    In ProcA I take in a message of type A.xsd in an activating receive
    In ProcB I take in a message of type B.xsd in an activating receive.

    I've effectively created two subscriptions for these messages, pretty basic.

    Now, imagine I have a third process, ProcC, and that this process has a multi-part message with two parts - first part uses a different schema - C.xsd and second part uses A.xsd.
    Effectively, I've created a new type in my orchestration which has a name and is composed of C.xsd and A.xd (lets call the type C*)

    What would happen if ProcC published such a message to the message box? We'll get a routing failure as we don't have any process subscribing to that message.

    What I think can be confusing is what "that message" means in that context-

    While in the orchestration a multi-part message with two parts is a completely different message from any of the other ones defined in the process, in the messaging layer, it's the body part that counts, so that the reason my multi-part message had no subscribers is not down to the fact that there was no orchestration subscribing to C* (the multi-part message) but that there was no orchestration subscribing to a message of type C.xsd (the type of the first part in the multi-part message)

    And indeed - if I created a new multi-part message where the first (body) part was of type A.xsd and the second part was of schema C.xsd (call it A*) and published it to the message box, contrary to what one might expect (which would be another routing faliure, as there's no process subscribing to A*) ProcA will get triggered.

    Although in the orchestration world a message of type A.xsd and a multi-part message A* are two completely different types (even if one of the parts in A* is, indeed, defined using A.xsd) in the messaging world, it is only the type of the body part that counts so that the two are the same.

    Hope this makes sense

    Labels: , ,

    1 Comments:

    • Yossi,
      An excellent article on multi-part messaging - something I've never really given too much thought to before.

      Nick.

      By Anonymous Nick Heppleston, at 07/11/2007 09:39  

    Post a Comment

    << Home