Impact of Namespace Style Choice on BizTalk Components

I could make up a statistic that says “83% of all BizTalk schemas use the namespace automatically assigned to it” and probably not be wildly off.  That said, I wondered if BizTalk handled all the different namespace styles in the same way.  Specifically, does BizTalk care if we use schemas with traditional “URL-style” namespaces, URN namespaces, single value namespaces, and empty namespaces?  Short answer: it doesn’t matter.

I suspect that many XSD designers currently go with a URL-based approach like so:


However, you could also prefer to go with a Uniform Resource Name style like this:


You might also choose to do something easier for you to understand, which might be a single identifier.  For instance, you could just use a namespace called “Enterprise” for company wide schemas, or “Vendor” for all external partner formats.


Finally, you may say “forget it” and not use a namespace at all.


The first thing I tested was simple routing.  The subscription for a URN-style message looked like this:


The “single value” format subscription looks like this:


Finally, if you have no namespace at all on your schema, the message subscription could look like this:


In that case, all you have is the root node name.  After testing each routing scenario, as you might expect, they all work perfectly fine.  I threw a property schema onto each schema, and there were no problems routing there either.

I also tested each schema with the Business Rules Engine and each worked fine as well.

Moral of the story?  Use a namespace style that works best for your organization, and, put some real thought into it.  For instance, if a system that you have to integrate with can’t do namespaces, don’t worry about changing the problem system since BizTalk can work just fine.

I didn’t go through all the possible orchestration, mapping and WCF serialization scenarios, but would expect that we’d see similar behavior.  Any other real-life tales of namespaces you wish to share?


Author: Richard Seroter

Richard Seroter is Director of Developer Relations and Outbound Product Management at Google Cloud. He’s also an instructor at Pluralsight, a frequent public speaker, the author of multiple books on software design and development, and a former editor plus former 12-time Microsoft MVP for cloud. As Director of Developer Relations and Outbound Product Management, Richard leads an organization of Google Cloud developer advocates, engineers, platform builders, and outbound product managers that help customers find success in their cloud journey. Richard maintains a regularly updated blog on topics of architecture and solution design and can be found on Twitter as @rseroter.

5 thoughts

  1. heheh thanks for finding this out! I was always suspecting BT does not care but never had time to prove it myself )

  2. Since BizTalk uses targetnamespace#rootnode name i think it’s logical for it to work without targetnamespace, but i think this is not true in BizTalk 2004.

  3. I found a case that no namespace at all didnt work.
    When you try to Import a schema type to another schema (required for an envelope debatching scenario)

  4. Interesting!

    There are two things about “Xml namespaces” (XML NS)(I prefer use this name not just “namespace” and not a “target namespace”).
    First: we have to separate the “language”/”assembly”[/”CLR”] namespaces (let’s name them as Namespaces (NS) and Xml namespaces. To me they should be linked (for example, let’s generate Xml NS from the NS. I’m sick of this “” 😦 ).
    Second: URL is used as an address. And this is the main ambiguous thing in using URL as XML NS. Companies usually got strict rules to use the domain URL. That means we always have to explicitly discuss these things *before* using URLs as XML NSs. We have to ask a question: Do we want to use the XML NS as addresses? (For example, for the REST Web-services it makes sense.)

    BTW I saw the Xml parsers (not inside BizTalk) that check if the XML NS are the well-formed URI. That’s why using a “single value format is a bad idea.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.