Click here to Skip to main content
12,756,621 members (31,462 online)
Click here to Skip to main content
Add your own
alternative version

Tagged as

Stats

13.1K views
4 bookmarked
Posted 9 Apr 2009

Understanding Publish Subscribe in BizTalk

, 9 Apr 2009 CPOL
Rate this:
Please Sign up or sign in to vote.
BizTalk Server's publish-subscribe model makes it possible to create innovative, maintainable, and scalable solutions that effectively take advantage of available resources to provide a balance between ease of development, deployment, and performance.

BizTalk Server's publish-subscribe model makes it possible to create innovative, maintainable, and scalable solutions that effectively take advantage of available resources to provide a balance between ease of development, deployment, and performance. Find out about publish-subscribe and learn how it works in BizTalk Server.


BizTalk is a messaging system that is based on a model called publish-subscribe. The publish-subscribe model is an asynchronous programming technique that makes it easier to share information between entities that send information (publishers) and entities that receive information (subscribers). The main advantages of the publish-subscribe model include scalability (the ability to take advantage of available, changing, resources) and flexibility (works as the basis for many other programming approaches).

In more concrete terms, think of publish-subscribe as if you are a speaker at a conference. You publish information using your voice and the audience is consuming that information by listening. You are actively publishing information and members of the audience register their interest by being present and listening.

You can speak to an audience of one person or hundreds - the only difference is in how you project that information (speaking plainly, loudly, or using a microphone). The way you project the information is the one aspect of scalability - you can reach more members of the audience over a larger physical space with resources like a microphone and, for a small room, a small speaker or several large speakers for a larger area.

Your speech (content) is the same there is one person or hundreds of people in the audience. Audience members can leave and new members can join at any time without affecting your ability to publish information. Since people can join or leave at anytime, you are effectively decoupled from not only the overall audience, but also, the identity of the individual members of the audience - you are essentially making a speech to anonymous members of the public.

BizTalk handles messages in the same way: BizTalk publishes messages to a common area and processes that are interested in consuming the published messages subscribe to them (orchestrations, receive or send ports, or directly bound ports).

The publish-subscribe model wouldn't work if all subscribers receive all messages. When a subscriber registers its interest, the registration includes filters to select messages of interest. In general, there are two types of filters - topic based filters that BizTalk represents as Receive Ports or Send Ports, and content based filters which filter messages based on their content - BizTalk provides several means of filtering based on content.

So what does a BizTalk subscription look like? Here is an example:

http://schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortID == 
   {E2CAB447-6BB0-4C51-ABB2-8F02A19A8837}


And


http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType == 
    http://example.com/sample#Person


The subscription includes both types of filters that I mentioned earlier:

  • The topic filter is based on the ReceivePortID
  • The content filter is based on an attribute called MessageType

A Receive Port is an abstraction (logical representation) of a means to receive a message using a specific protocol or location. For example, BizTalk can receive messages in files, from Message Queues, or via HTTP (among the methods - there are others). The specific protocols and locations are referred to as Receive Locations. There can be several Receive Locations per Receive Port making it possible to accept messages from a variety of locations and treat them the same way in BizTalk. The following is how BizTalk represents a Receive Port in the Orchestration Designer:

fig01_receivePort


The MessageType is a representation of a message's type. BizTalk represents all messages in XML. One important aspect of all XML documents is its namespace. Briefly, a namespace allows you to describe a Person (for example) in one way without affecting anyone else's description - since Person can mean different things to other applications. Another important aspect of all XML documents is the name of the document's root node. In the preceding example, the combination of the message's namespace and name of the root node are represented as:

http://example.com/sample#Person


The hash symbol (#) separates the namespace from the name of the root node. I'll explain more about the concepts of XML namespaces and root node names in a future blog post.

So where is the "Publish" part of publish-subscribe? You can publish messages in BizTalk in a variety of ways including:

  • Sending a message to a receive port
  • Calling an orchestration from another orchestration
  • Creating a direct bound port (more about this in a future blog post)
  • Publishing messages for which there are no subscribers (known as routing failures)


Many naive solutions use BizTalk Server as if it's another procedural programming language. BizTalk Server's publish-subscribe model makes it possible to create innovative, maintainable solutions that effectively take advantage of available resources to provide a balance between ease of development and deployment and performance.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Erik Westermann
Software Developer (Senior) erikwestermann.com
Canada Canada
Erik is a senior developer-writer with more than 14 years professional programming experience designing and developing large scale database and Internet-centric applications for organizations including MSN.ca, ADP, Nortel, lemontonic.com, EDS, Merrill Lynch, ePost, CIBC, TD Securities, IBC, CIHI, InnovaPost, etc.

Erik has been specializing in BizTalk Server-based solutions for five contiguous years to date. His experience includes many SOA and ESB-style applications using technologies like Commerce Server, SharePoint, ASP.NET and advanced .NET Framework.

You may also be interested in...

Pro
Pro

Comments and Discussions

 
-- There are no messages in this forum --
Permalink | Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.170217.1 | Last Updated 9 Apr 2009
Article Copyright 2009 by Erik Westermann
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid