다음을 통해 공유

Understanding Biztalk Pub-Sub Architecture.

  • 아티클

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 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.