Integration Topologies

 

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Integration Patterns

June 2004

Summary: This chapter builds on previous chapters by describing overall integration topologies. This chapter presents a series of related patterns that help you analyze the alternative methods and the tradeoffs to consider when you choose between integration topology alternatives.

Contents

Point-to-Point Connection

Broker

Message Bus

Publish/Subscribe

A More Detailed Look at Topologies

Using Topologies Together

Integration Topology Level Patterns

"Always design a thing by considering it in its next larger context—a chair in a room, a room in a house, a house in an environment, an environment in a city plan."—Eliel Saarinen, a Finnish-American architect and city planner

Earlier chapters covered integration layers and the various approaches used to connect layered applications. Making these connections and creating integration layers are important parts of your integration design. Equally important, however, is the larger context that these connections and layers form as you join them together. The design of this integration context should specify the locations, structure, and channels that you use to connect these elements together to form a coherent whole. This context is called an integration topology.

As you consider integration designs, you will notice key differences between designing for conventional applications and designing for integration. During application design, you are usually in control of synchronous request and reply interactions, message flow, and the multiplicities of messages. You have a fairly straightforward programming model that you can use to coordinate elements, exceptions, and retries. This is not always true when you design for integration.

As you design for integration, your application becomes a computational resource that provides and consumes services as part of a larger integration architecture. And while your system may be simply connected point-to-point with another service, your system may also be a provider or publisher of business events to other systems. If your system is a provider or publisher, your event message might be sent to a message broker or to a message bus. These components may then send copies of the message to many other subscribed applications or systems. Other systems may be connected or removed from these message brokers or message buses without any modifications to your system. In fact, your system may not have any direct knowledge of these other systems at all.

To understand how to design systems as service providers and consumers, it is important to have a working knowledge of integration topologies. These topologies cover the flow of messages though an integration architecture, and they introduce elements such as message brokers and message buses. Although topics like physical topologies may seem unimportant at this level of abstraction, it turns out that some integration elements, such as message buses, are tightly coupled to lower-level topologies. Therefore, it is important to understand how these lower levels work in order to fully understand the higher-level topologies.

This chapter starts, as many integration architectures do, by considering a basic Point-to-Point Connection pattern. It then progresses to a more complex integration pattern–the Broker (and its variants). Unlike the coupled endpoints in a Point-to-Point Connection, the Broker decouples the source from the target by inserting intermediaries. After the Broker, the next pattern is the Message Bus. The Message Bus pattern further decouples endpoints by using agreed-upon message schemas, command messages, and shared infrastructure. Finally, the chapter examines another pattern used by all three of the previous patterns to notify interested subscribers–Publish/Subscribe. After describing these four patterns, the chapter takes a more detailed look at logical and physical topologies to help you better understand the collaborations within the Point-to-Point Connection, the Broker, and the Message Bus patterns*.*

Point-to-Point Connection

Many integration projects start with the need to connect two systems, and the easiest way to do so is to use the Point-to-Point Connection pattern. A point-to-point connection ensures that only one receiver receives a particular message. For this to work, the sending system must know the location of the receiving node. The sending system often must translate the message into a format that the receiving system understands.

When you use point-to-point connections, each system determines the address of all the other nodes that it needs to communicate with. When target addresses or protocol details change, all the systems that communicate with the target server must be updated. As the size of your integration network grows and as the frequency of change increases, the operational cost associated with this approach becomes significant.

Most integration scenarios require you to transform the data between the source system and the target systems. Additionally, in many scenarios, developers want to take advantage of some conditional logic when they configure message routing. If you use point-to-point connections, this logic is often duplicated on each server that requires transformation and routing. Duplicate code is expensive to write, and it is difficult to maintain, to extend, to test, and to manage.

The strength of the Point-to-Point Connection pattern is how simple it is to implement. The weakness of the Point-to-Point Connection pattern is the duplication of transformation and routing code between systems, and the high configuration cost of endpoint address changes. To minimize these weaknesses, you can add another layer of indirection between endpoints that contains a broker.

Broker

The Broker pattern and its variants are often used in both application design and integration design. The foundation work for this pattern is contained in Pattern-Oriented Software Architecture, Volume 1: A System of Patterns [Buschmann96]. The original pattern presented in this work is rather large in scope and contains four themes of particular interest for integration:

• Creating client-side proxies, server-side proxies, and the related infrastructure to encapsulate the complexities of distributed communication
• Providing a means for systems to register services with a broker so they can be consumed by other systems
• Providing a means for systems to locate necessary services
• Describing how brokers and endpoints can collaborate using both direct and indirect communication

In the first work in this pattern series, Enterprise Solution Patterns using Microsoft .NET [Trowbridge03], Broker is discussed in the context of client proxies and server proxies using Distributed Object Integration. However, that discussion did not emphasize direct and indirect communication or naming services. This chapter breaks the primary Broker pattern down to a hierarchy of specialized patterns where each specialized pattern has particular responsibilities that refine the responsibilities of the primary Broker pattern.

The intent of a broker is to decouple source systems from target systems. In the context of Distributed Object Integration, the source system may send a marshaled set of parameters when the source system requests a method invocation from the target system. In the context of Service-Oriented Integration, the source system may send a message that requests a service from a target system. While the contexts vary significantly, both use a Broker pattern to decouple the source systems and the target systems.

A broker decouples source systems and target systems by assuming responsibility for coordinating communication between endpoints. There are three responsibilities that are involved in communication. These three responsibilities include the following:

• Routing. Routing involves determining the location of a target system, and it is performed by using direct and indirect communication.
• Endpoint registration. Endpoint registration is the mechanism that a system can use to register itself with the Broker so that other systems can discover that system.
• Transformation. Transformation is the process where an element is converted from one format to another.

In this case, the source element is the message that is sent by the source system, and the target element is the message that is received by the target system. Figure 1 shows the Broker pattern and the three related patterns that refine the basic Broker pattern*:Direct Broker*, Indirect Broker, and Message Broker [Hohpe04].

Figure 1. Broker and related patterns

A direct broker establishes initial communication between endpoints. After the initial communication, the two endpoints communicate directly by using client-side and server-side Proxies [Gamma95]. Figure 2 illustrates a Direct Broker implementation.

Figure 2. Sequence diagram for a Direct Broker implementation

In contrast, an indirect broker is a middleman, and all the communication between endpoints passes through it. Using an indirect broker allows a sender to be unaware of target details and provides central control of the message flow. In this way, Indirect Broker is similar to Mediator [Gamma95]. Mediator "keeps objects from referring to each other explicitly, and it lets you vary their interaction independently" [Gamma95]. Figure 3 shows how an indirect broker acts as a mediator between source systems and target systems.

Figure 3. Sequence diagram for an Indirect Broker implementation

While the Indirect Broker pattern is useful when you need to control communications, Direct Broker offers better performance, especially when an additional intermediary is not needed for all communications.

The Message Broker pattern is a specialized version of the Broker pattern [Buschmann96, Trowbridge03]. A message broker communicates exclusively by using messages and indirect communication. The Message Broker is an important and frequently used integration pattern. It is often referred to as a hub-and-spoke architecture.

Let's examine several Broker implementations to see how this pattern and its variations work in practice.

Broker Examples

To illustrate how the Broker pattern is used, let's look at the following five examples of the Broker pattern in action:

• Microsoft Distributed Common Object Model (DCOM)
• Microsoft .NET Framework Remoting
• Common Object Request Broker Architecture (CORBA)
• Universal Description Discovery and Integration (UDDI)
• Microsoft BizTalk Server 2004

DCOM

Microsoft's Distributed Common Object Model (DCOM) is an example of Distributed Object Integration that uses a direct broker. When a calling application on a source server wants to create and use an object on a target server, DCOM coordinates communications between these endpoints. To coordinate this communication, DCOM first locates the target server by using configuration information that is stored in the registry. DCOM then creates a client proxy on the source system and a server proxy (stub) on the target system. Subsequent communication occurs directly between the client proxy and the server proxy (stub) using point-to-point connections as shown in figure 4.

Figure 4. Sequence diagram showing DCOM acting as a direct broker

.NET Framework Remoting

.NET Framework remoting is another example of Distributed Object Integration that uses Direct Broker. The collaboration is the same as the collaboration that is shown in Figure 4. However, unlike DCOM, .NET Framework remoting does not retrieve the server location from the registry. Instead, the URL for the server is passed as a parameter to the **Activator.GetObject()**method call. This call then sets up communication between proxies. After the channels are registered and the proxies have been set up, subsequent communication occurs directly between proxies by using a point-to-point connection. This implementation uses the server and client proxies' portion of the Broker pattern, but does not directly use a naming service to register and to locate endpoints.

The programming model for both the client and the server is very straightforward. For more information, see Implementing Broker with .NET Remoting Using Server-Activated Objects [Trowbridge03] and Implementing Broker with .NET Remoting Using Client-Activated Objects [Trowbridge03].

CORBA

The Common Object Request Broker Architecture (CORBA) is a specification that has multiple implementations. While these implementations vary in practice, this section focuses on an implementation that uses Distributed Object Integration with a direct broker.

Upon startup, an object request broker (ORB) acting as a client sends a User Datagram Packet (UDP) broadcast on its local subnet to find a naming service. The ORB then stores the location of the first naming service that responds to this request. Because this is a broadcast, the communication uses a bus-based logical topology. (See the topology section later in this section for more information about topologies.)

Using this naming service, the ORB requests the location of the target server on behalf of the client. Assuming the server has previously registered with the naming service, the naming service then returns the server location to the ORB. After the ORB obtains the server location, it sets up a client proxy and a server proxy (skeleton). All subsequent communication occurs directly between the client proxy and the server proxy by using a point-to-point connection*.*

UDDI

The Universal Description Discovery and Integration (UDDI) specification defines a SOAP-based Web service for finding and registering Web services. UDDI is also a publicly accessible set of implementations of the specification. These implementations enable businesses to register and to discover Web services. UDDI implementations can be either private or public.

At run time, a UDDI server can act as a Direct Broker between two Web services. The interaction starts with the consuming service. The consuming service then contacts the UDDI server. The UDDI server locates the target service and returns it to the consuming service. After receiving the target's location in the UDDI binding template and after receiving the target's configuration, the consuming service communicates directly with the providing service.

For more information about how to use UDDI at run time, see "Using UDDI at Run Time, Part I" and "Using UDDI at Run Time, Part II" by Karsten Januszewski [Januszewski01, Januszewski02].

BizTalk Server 2004

BizTalk Server 2004 is a versatile platform infrastructure component that you can configure in many different ways. Most importantly, you can use BizTalk Server 2004 as the component that implements Message Broker. Unlike the previous examples that used direct brokers, Message Broker is a refinement of the Indirect Broker pattern. Systems that use Indirect Broker do not communicate directly with each other. Instead, they communicate through a middleman—the indirect broker. The source system communicates the logical name of the target to the indirect broker. The indirect broker then looks up the target system that is registered under the logical name and passes the communication to the target system. A message broker is a specialized type of indirect broker that communicates by using messages. For a detailed example, see Implementing Message Broker with BizTalk Server 2004.

The preceding five examples demonstrate that the Broker pattern and its variants are frequently used for systems integration. Compared to Point-to-Point Connection, it effectively decouples source systems and target systems by adding another level of indirection. There are situations, however, that call for even greater decoupling. In these situations, you often want a data format and a message structure that are common across multiple systems. You also want a shared infrastructure that can communicate these common messages to any interested system. At this point, it is time to consider Message Bus.

Message Bus

The notion of a bus originated in the field of electrical engineering where a common bus is used to carry current of a specific voltage and frequency. This notion is extended with the buses that are found in computer hardware systems so that it includes not only common voltages, but also agreed-upon messages such as a data bus and an address bus. A message bus extends this concept to provide a common communication mechanism between disparate systems. To provide this common mechanism, the systems must have three elements:

• A set of agreed-upon message schemas
• A set of common command messages [Hohpe04]
• A shared infrastructure for sending bus messages to recipients

This shared infrastructure can be achieved either by using a Message Router [Hohpe04] or by using a Publish/Subscribe mechanism. In this book, the focus is on message buses that use Publish/Subscribe mechanisms. For details on how to design a message bus that uses message-oriented middleware and a message router, see Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions [Hohpe04].

Figure 5 shows a Message Bus associated with a Publish/Subscribe implementation.

Figure 5. Message Bus associated with a Publish/Subscribe pattern implementation

The Publish/Subscribe pattern describes a collaboration where one system subscribes to change messages or to event messages that are produced by another system. In the Message Bus context, a system can subscribe to bus messages. After the system subscribes, the system is then sent all the messages that are addressed to this common bus. Although message buses often use Publish/Subscribe implementations, these implementations are used by other topologies as well. For example, Point-to-Point Connection and Message Broker can also use Publish/Subscribe collaborations.

The advantage of a message bus is that once it is established, the cost of adding new applications is minimal. A new application can subscribe to bus messages without affecting other subscribers. Because all systems, including the new system, understand common message schemas and command messages, there is no need for additional translation. However, as you add a new system to the bus, it may be useful to use an Adapter [Gamma95] to encapsulate any translation needed to initially connect with the message bus.

The disadvantage of a message broker is the significant amount of work that is involved in creating common message schemas, command messages, and shared infrastructure within an enterprise. Because these systems typically cross organizational boundaries and systems, gaining agreement on these key areas may be extremely difficult, time consuming, or impossible.

Message Bus implementations vary significantly depending on the kind of Publish/Subscribe mechanism they employ. Because a Publish/Subscribe mechanism is such an integral part of a Message Bus implementation, the next section looks at this pattern more closely.

Publish/Subscribe

At a high level, the Publish/Subscribe [Buschmann96] pattern helps keep cooperating systems synchronized by one-way propagation of messages because one publisher sends a message to any number of intended subscribers. However, there are significant differences in the next level of design within the pattern. These differences lead to three refinements of the Publish/Subscribe pattern: List-Based Publish/Subscribe, Broadcast-Based Publish/Subscribe, and Content-Based Publish/Subscribe.

List-Based Publish/Subscribe

A List-Based Publish/Subscribe pattern advises you to identify a subject and to maintain a list of subscribers for that subject. When events occur, you have the subject notify each subscriber on the subscription list. A classic way to implement this design is described in the Observer [Gamma95] pattern. When you use this pattern, you identify two classes: subjects and observers. Assuming you use a push model update, you add three methods to the subject: Attach(),Detach(), and Notify(). You add one method to the observer—Update().

To use an observer, all interested observers register with the subject by using the **Attach()**method. As changes occur to the subject, the subject then calls each registered observer by using the **Notify()**method. For a detailed explanation of the Observer pattern, see Design Patterns: Elements of Reusable Object-Oriented Software [Gamma95].

An observer works fine if you have created instances of objects that reify all your observers and subjects. An observer is especially well suited to situations where you have one-to-many relationships between your subjects and your observers. However, in the context of integration, you often have many observers that are linked to many subjects, which complicates the basic Observer pattern. One way to implement this many-to-many relationship is to create many subjects and to have each subject contain a list of observers.

If you use this object structure to implement Publish/Subscribe, you must write these relationships to persistent storage between process executions. To do so within a relational database, you must add an associative table to resolve the many-to-many dependencies between subject and observer. After you write this information to persistent storage in a set of tables, you can directly query the database for the list of subscribers for a topic.

Maintaining lists of published topics (subjects) and subscribers (observers) and then notifying each one individually as events occur is the essence of List-Based Publish/Subscribe implementations. A very different means of achieving the same result is a Broadcast-Based Publish/Subscribe implementation.

Broadcast-Based Publish/Subscribe

When you use a Broadcast-Based Publish/Subscribe approach [Tannebaum01, Oki93], an event publisher creates a message and broadcasts it to the local area network (LAN). A service on each listening node inspects the subject line. If the listening node matches the subject line to a subject that it subscribes to, the listening node processes the message. If the subject does not match, the listening node ignores the message.

Subject lines are hierarchical and may contain multiple fields that are separated by periods. Listening nodes that are interested in a particular subject can subscribe to these fields by using wildcards, if required.

Although this Broadcast-Based Publish/Subscribe implementation is an effective method for decoupling producers from consumers, it is sometimes useful to identify particular topic subscribers. To identify topic subscribers, a coordinating process sends a message that asks listening nodes to reply if they subscribe to a particular topic. Responses are then returned by each listening node to the provider to identify the subscribers.

Because all messages are sent to all listening nodes, and because each node is responsible for filtering unwanted messages, some authors refer to this as a publish/subscribe channel with reactive filtering [Hohpe04].

Content-Based Publish/Subscribe

Both Broadcast-Based Publish/Subscribe implementations and List-Based Publish/Subscribe implementations can be broadly categorized as topic-based because they both use predefined subjects as many-to-many channels. Publish/Subscribe implementations have recently evolved to include a new form—Content-Based Publish/Subscribe. The difference between topic-based and content-based approaches is as follows:

In a topic-based system, processes exchange information through a set of predefined subjects (topics) which represent many-to-many distinct (and fixed) logical channels. Content-based systems are more flexible as subscriptions are related to specific information content and, therefore, each combination of information items can actually be seen as a single dynamic logical channel. This exponential enlargement of potential logical channels has changed the way to implement a pub/sub system. [Baldoni]

The practical implication of this approach is that messages are intelligently routed to their final destination based on the content of the message. This approach overcomes the limitation of a broadcast-based system, where distribution is coupled to a multicast tree that is based on Transmission Control Protocol (TCP). It also gives the integration architect a great deal of flexibility when deciding on content-based routing logic.

A More Detailed Look at Topologies

To fully understand how collaborations that are based on Point-to-Point Connection, Broker, and Message Bus work together with other parts of your technical architecture, it is useful to view your system's topologies from three discrete topology levels: physical, logical, and integration.

Note   This section discusses low-level layers of the Open Systems Interconnection (OSI) stack. It then moves on to discuss the top layer (Application), bypassing many important layers. This is intentional because this section only discusses the relationship between these low-level layers and the integration topology pattern choices. It does not mean that these layers are not important. However, they are not architecturally significant for this particular discussion.

Topology Levels

Because the terms point-to-point, bus, and hub were first defined at the physical level, this section starts with a review of the physical network topology level. In addition to a physical connection, you also need a logical communication protocol. That logical communication protocol also implies a topology. After logical and physical topology levels are established, it is possible to establish patterns of communication between the collaborating nodes. These patterns of communication and collaboration form an integration topology level that is described by the Point-to-Point Connection, the Broker, and the Message Bus patterns.

In some cases, the topology used at the integration topology level and the topology used at the physical topology level may be the same topology. In other cases, a system may use different topologies at the integration topology level, the logical topology level, and the physical topology level. It therefore is useful to separate topologies from topology levels to avoid potential confusion. This section discusses the physical, logical, and integration topology levels in more detail.

Note   The term topology is used within the industry to refer to both the arrangement of nodes within a network (for example, bus or hub) and to the physical and logical network levels of elements. However, the remainder of this chapter uses the following convention. Topology describes the arrangement of elements (for example, bus or hub). Topology level is used to indicate the levels of elements, such as the physical versus the logical levels. This convention permits clarity if, for example, the chapter refers to a system that uses a bus-based topology at the physical topology level.

Physical Topology Level

The first level to consider is the physical topology. The physical topology level describes the way that each system node physically connects to the network. The topology choices are point-to-point, bus, hub, and ring. These four topologies are illustrated in Figure 6.

Figure 6. Four physical topologies

You can determine the topology that is used at the physical topology level of any set of hardware nodes by observing the arrangement of the network cables and the devices that connect the nodes. Logical network protocols use this topology to facilitate communication between the nodes. Because these protocols assume a particular sequence of communication and a logical structure between nodes, these collaborations form topologies at the physical topology level.

Logical Topology Level

A logical topology level describes the means, the sequence, and the protocol that physical nodes use to communicate. The most popular network protocol today is the Ethernet standard (IEEE 802.3). Ethernet uses a bus-based topology at the logical topology level. Ethernet is bus based because the original protocol was designed so that all packets on a network or on a subnetwork were sent to all nodes on the same network segment. This configuration requires each listening node to filter unwanted packets. The protocol provides for collisions that may occur if more than one node transmits simultaneously. Since the original protocol was developed, advances in network hardware have enabled devices to route messages to selected nodes to improve performance. One such advance is the development of switches. The Ethernet protocol also has evolved to take advantage of these developments, but it still supports a bus-based logical topology.

A less-used network protocol is token passing (IEEE 802.5). Token passing uses a ring-based topology at the logical topology level. With this topology, each node connects to the next node in the ring and passes a message in a circular fashion until it arrives at the intended destination.

As shown in Figure 7, the topology of the logical topology level and the topology of the physical topology level correspond exactly in some cases.

Figure 7. Direct mapping of topologies at the logical and physical topology levels

For example, a set of nodes that are connected with a bus-based topology at the physical topology level might also be connected with a bus-based topology at the logical topology level. This topology is the topology that often exists when you use the Ethernet protocol. Or, a set of nodes that are connected with a ring-based topology at the physical topology level might also be connected with a ring-based topology at the logical topology level. This is the topology that exists when you use token passing. However, it is important to understand that the topologies used at the physical and logical topology levels do not have to be the same. In practice, they are often different.

For example, multiple nodes might be connected in a hub-based topology (100Base-T) at the physical topology level, and a bus-based topology (Ethernet) might be used at the logical topology level. In this case, an incoming packet is broadcast to all the nodes that are physically connected to the hub, and the hub effectively acts as a bus. Each listening node is then responsible for filtering the unwanted messages. Figure 8 shows a bus-based topology at the logical topology level. The bus-based topology is mapped to both a bus-based topology and to a hub-based topology at the physical topology level.

Figure 8. A bus-based topology at the logical topology level mapped to both a bus-based topology and a hub-based topology at the physical topology level

Another example of different topologies at the logical and physical topology levels is a ring-based topology at the logical topology level that runs on top of a bus topology at the physical topology level. This configuration is described in IEEE 802.4. In this configuration, messages are passed in the logical topology level through a ring of nodes, but the nodes are connected by using a bus-based or a hub-based topology at the physical topology level.

As you analyze a set of connected systems in detail, it is useful to clarify the topology level you are referring to. This helps to separate the logical issues from the physical issues. Above the logical level, the integration topology level describes the arrangement of integrated systems.

Integration Topology Level

The integration topology level describes the arrangement of channels, collaborations, and mechanisms that different systems and services use to communicate. This topology level consists of different combinations of three patterns: Point-to-Point Connection, Broker, and Message Bus. These patterns, along with the related Publish/Subscribe pattern, are illustrated in Figure 9 by using circles.

Figure 9. Integration patterns related to topologies

Now let's look at how integration topologies interact with logical and physical topologies in more detail.

Using Topologies Together

To design an integration architecture, you must decide on high-level collaborations in the integration topology level. These collaborations use other combinations of collaborations and topologies in the logical topology level. In turn, these collaborations use, and in some situations are constrained by, the topologies used in the physical topology level. Note that each level has its own set of concerns and responsibilities. Let's now look at these collaborations in more detail.

Point-to-Point Connection

Figure 10 shows how to implement the Point-to-Point Connection pattern. Given the popularity of Ethernet, point-to-point connections are often connected by a bus in the logical topology level. Using common network devices like routers, hubs, and switches, the physical topology level is usually either hub based or bus based. Regardless of the topologies used at the physical and logical topology levels, from an integration pattern perspective, the nodes are using a Point-to-Point Connection pattern if both of the following are true:

• Exactly one message is sent to and received by one target node.
• The responsibility for determining the target location and protocol lies with the sender.

Figure 10. Topologies stack for a Point-to-Point Connection integration pattern

Breaking these topologies into discrete levels lets you qualify topology discussions by using a frame of reference. For example, using the configuration that is shown in Figure 10, you might have a Point-to-Point Connection topology at the integration topology level that is connected to a bus topology at the logical topology level and to a bus or hub topology at the physical topology level.

Broker

The collaboration described in the Broker pattern uses a combination of many other topologies. For example, let's review the CORBA direct broker example that is discussed earlier in this chapter.

"Upon startup, an object request broker (ORB) acting as a client sends a UDP broadcast on its local subnet to find a naming service."

Here, a broker uses a bus topology at the logical topology level to send a broadcast to all the systems that are connected to its subnet. In this case, the topology used at the physical topology level is irrelevant, but it is likely to be hub based or bus based due to the ubiquity of Ethernet. Note that the naming service must be located on the same subnet as the ORB for this scheme to work.

"Using this naming service, the ORB requests the location of the target server on behalf of the client."

This is a standard broker collaboration. The main requirement here is that the source system be able to connect point-to-point with the naming service. Therefore, the topologies used at the logical and physical topology levels are less important. Again, due to the ubiquity of Ethernet, the topology used at the logical topology level is likely to be bus based, but the topology used at the physical topology level is likely to be either hub based or bus based.

"All subsequent communication occurs directly between the client proxy and the server proxy by using a point-to-point connection. "

Again, the main requirement is that the source system be able to connect point-to-point to the target. This also is likely to be a bus topology at the logical topology level and a hub or bus topology at the physical topology level.

Although the Broker collaboration may have some amount of coupling to underlying topologies at both the physical and logical topology levels, the amount of coupling is much more pronounced when you use Message Bus in conjunction with a Publish/Subscribe implementation.

Message Bus and Publish/Subscribe

Message Bus implementations can vary greatly depending on the Publish/Subscribe mechanism that they employ. Now let's examine the practical implications of using the three Publish/Subscribe variations together with Message Bus.

Message Bus with Broadcast-Based Publish/Subscribe

To use a Message Bus implementation that contains a Broadcast-Based Publish/Subscribe implementation, a system sends a command message to the message bus. The message bus broadcasts the message to all the nodes that are listening to the bus. The message bus makes no attempt to determine the appropriate subscribers. Instead, each listening node filters any unwanted messages and processes only the messages that it is interested in. Any data associated with the messages is in a common format so that all systems can interpret the command message and the data, and then respond appropriately.

From a topology perspective, this combination of the Message Bus pattern and the Publish/Subscribe patterns uses a bus-based topology at the logical topology level (Ethernet) to make a bus-based broadcast communication from the message bus to all the listening nodes. The physical topology at this point is irrelevant, but it is usually either hub based or bus based.

Message Bus with List-Based Publish/Subscribe

To use a message bus that contains a List-Based Publish/Subscribe implementation, a system sends a command message to the message bus. The message bus then looks up all interested bus subscribers and sends each one a copy of the original message. Any data associated with the message is in a common format so that all systems can interpret the command message and the data, and then respond appropriately.

From a topology perspective, this combination of the Message Bus and Publish/Subscribe patterns is likely to use (but not to be coupled to) a bus topology at the logical topology level (Ethernet) to make point-to-point connections from the message bus to the subscribing nodes, as shown in Figure 11. At this point, the topology used at the physical topology level is irrelevant, but it is usually either hub based or bus based.

Figure 11. A message bus using a bus topology at the logical topology level and a bus or hub topology at the physical topology level

Message Bus with Content-Based Publish/Subscribe

To use a Message Bus pattern that contains a Content-Based Publish/Subscribe implementation, a system sends a command message to the message bus. After the message bus receives the message, it is responsible for matching the message against a set of subscribers. The message bus then forwards the message to each of the appropriate subscribers.

To match the message against a set of subscribers, the message bus must determine if there are any subscribers interested in this particular message. If an interested subscriber exists, the subscriber matches a particular message field or fields and a set of values. If a match exists between the message content and a subscriber, the message is then forwarded to each matching subscriber.

After a subscribing system receives a bus message, the subscribing system is able to process the message because the message contains the common command message and the agreed-upon message schemas.

Although the Message Bus using List-Based Publish/Subscribe and the Message Bus using Content-Based Publish/Subscribe patterns both check for subscriptions before forwarding messages, there are key differences. The list-based approach matches subscriptions on subjects. The content-based approach allows you to identify one or more fields in the message and to identify a set of acceptable values for each field. As a result, you can create very intelligent routing capabilities. This makes the content-based approach more flexible than the list-based approach.

To make Content-BasedPublish/Subscribe work, you need a high performance infrastructure component that can read each message, query a set of potential subscribers, and efficiently route the message to each subscriber. In practice, you can think of this as a message switch. This is exactly how Microsoft BizTalk Server 2004 is designed.

Figure 12 shows the Message Bus pattern using a Publish/Subscribe pattern or one of the Publish/Subscribe variants.

Figure 12. Message Bus using a Publish/Subscribe pattern

Integration Topology Level Patterns

The following table summarizes the integration patterns that are discussed in this chapter.

Table 1: Integration Network Patterns

Pattern	Problem	Associated implementations
Message Broker	How do you integrate applications without enforcing a common interface and also allow each application to initiate interactions with several other applications?	Implementing Message Broker with BizTalk 2004
Message Bus	As an integration solution grows, how can you lower the cost of adding or removing applications?
Publish/Subscribe	How can an application in an integration architecture only send messages to the applications that are interested in receiving the messages without knowing the identities of the receivers?

Start | Previous | Next

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

© Microsoft Corporation. All rights reserved.