Message Topologies

Message topologies describe how messages are sent between one or more senders and one or more receivers. Message topologies can describe simple application-to-application connectedness, but they can also describe complex application-to-enterprise connectedness. When looking at the latter, the real power of service-oriented applications is apparent. In a nutshell, the possible topologies are much richer and enable complexity far beyond what is was within reach with component-oriented applications.

On one level, a message topology is composed of one or more MEPs. While there are boundless permutations of possible topologies, there are four generally accepted categories of message topologies: point-to-point, datagram point-to-point, brokered, and peer-to-peer (P2P). It is important to note that unlike MEPs, the names of these various message topologies are not widely agreed upon, so I have taken some liberty with their names. Likewise, it is possible to increase or decrease the number of message topologies, but these four are adequate for the purposes of this discussion.

Point-to-Point

The simplest and most widely used message topology, point-to-point is the fundamental building block for other message topologies. Simply stated, the point-to-point topology is one sender exchanging messages with one receiver. As you saw in the preceding section, this message exchange can be described by a datagram, request-reply, or duplex MEP.

Forward-Only Point-to-Point

In my opinion, datagram point-to-point is the most interesting topology, but it is also the hardest to implement. In essence, the forward-only point-to-point topology is a chain of datagram messages sent to different participants. It is important to note that this topology is composed of datagram MEPs only. It is possible for a message to return to a participant, but this must be explicitly stated in the address of the message, rather than implied, as it often is in the Request-Reply MEP. In general, this topology relies heavily on the <From>, <ReplyTo>, <FaultTo>, <RelatesTo>, <MessageID>, and <To> WS-Addressing header blocks.

Figure 3-4: Forward-only point-to-point message topology

Brokered

As the development community embraces messaging applications, it will become more and more important to broker the messaging interactions between these applications. A similar need appeared when the Internet and e-commerce started to gain popularity. The prototypical example from this era is a load balancer in a server farm. Among other things, a load balancer directs traffic to available resources. Over time, load balancers have become more and more intelligent, and this trend shows no sign of slowing down. I expect the same sort of evolution to happen in the world of service-oriented applications.

In general terms, a broker is a messaging participant that forwards messages to other endpoints. The broker can use a set of processing rules to determine when, where, and how messages are forwarded to other participants. A brokered topology can be further categorized to include distributed brokering, centralized brokering, or hybrid brokering. These brokering topologies are similar to the various e-mail server topologies in use today.

Furthermore, the famous publish-subscribe topology fits within the definition of the brokered topology. In publish-subscribe, participants subscribe to certain messages by registering interest with one or more publishing participants. When a message that subscribers have registered interest in is sent to the publishing participant, the publishing participant distributes that message to all subscribers. In other words, the publisher is the broker. In SOAP speak, a broker is an intermediary, but it can be addressed directly. Figure 3-5 illustrates a basic brokered topology.

Figure 3-5: Brokered topology

Peer-to-Peer

Peer-to-peer (P2P) applications, like Groove and Microsoft Windows Live messenger, have rapidly gained popularity. Essentially, a true P2P application is one that communicates directly with other P2P applications. P2P applications can communicate with other P2P applications in a one-to-one, one-to-many, and even many-to-many scenario. P2P applications do not have the traditional dependency on a server because they are able to communicate directly with other applications via a mesh. A mesh is a named, discoverable, self-maintaining set of nodes. Before participating in a P2P message exchange, an application must first join the mesh. In general, P2P message topologies are highly scalable and resilient while still providing rich interactions between participants. Figure 3-6 shows a P2P topology. As you will see later in this book, WCF provides out-of-the-box support for P2P topologies.

Figure 3-6: Peer-to-peer topology