Windows Azure Service Bus (1) Fundamentals

Windows Azure Platform Family of articles Catalog

When we are developing cloud-based Windows Azure, software in the cloud often needs to interact with other software. These other software may include other software on the Internet, or intranet software.

For intranet software, Azure provides a site-to-site (S2S) VPN and Point-to-site (P2S) VPN to connect to the VPN connection between Azure and intranet applications. However, if the intranet application uses Network address translation (NAT), S2S and P2S are unable to support the VPN Device behind the NAT.

Obtain an externally facing IPv4 IP for your VPN device. This IP address was required for a site-to-site configuration and was used for your VPN device, which cannot be located Behi nd a NAT.

In this scenario, the service bus features that Windows Azure provides can help users resolve the above issues.

Service Bus Basics

Service Bus is a multi-tenant cloud service, which means that the service can be shared by multiple users. Each user, such as an application developer, creates a namespace and then defines the communication mechanism that the user needs within that namespace.

The schema diagram for Service bus runs is as follows:

　　

Within a namespace, users can use one or more instances of three different communication mechanisms, each of which uses different ways to connect to the application. The following were:

-Queue. Allows one-way communication, each acting as an intermediary (sometimes referred to as a proxy), which stores the messages sent until they are received.

-Theme (Topic). Use a subscription to provide one-way communication. The topic acts as a proxy for the queue, but the topic only allows each subscription to see messages that meet certain criteria.

-Relay (Relay). Provides two-way communication. Unlike queues and topics, trunks do not store messages in routing, it is not a proxy. Instead, the relay simply passes the message to the target application.

When you create a queue, topic, or trunk, name it. In combination with any naming of your namespace, this name creates a unique identifier for an object. The application can provide this name to the Service Bus and then communicate with each other using queues, topics, or trunks.

　　

To use any of these objects, Windows applications can use Windows Communication Foundation (WCF). For queues and topics, Windows applications can also use the messaging APIs defined by service Bus. Queues and topics can also be accessed via HTTP, and Microsoft provides SDKs for Java, node. js, and other languages in order to make it easier to use them through non-Windows applications.

It is important to understand that even if the Service Bus itself is running in the cloud (that is, Microsoft Windows Azure Datacenter), applications that use it can run anywhere. You can use service Bus to connect applications running on Windows Azure or applications that run in your own datacenter. You can also use service Bus to connect applications running on Windows Azure or other cloud platforms via on-premises applications or through tablets and phones. You can even connect home appliances, sensors, and other devices to a central application or other application. Service Bus is a universal communication mechanism in the cloud that can be accessed almost anywhere. The way service Bus is used depends on what the application needs to do.

Queue

Assume that you decide to use a Service Bus queue to connect two applications. Figure 2 illustrates this situation.

Service Bus Queue Chart

Figure 2:service Bus Queue provides a one-way asynchronous queueing method.

The process is simple: the sender sends a message to the Service Bus queue, and the receiver receives the message at a later time. A queue can have only one receiver, 2, or multiple applications can read messages from the same queue. In the latter case, each message is usually read by only one receiver, and the queue does not provide a multicast service.

Each message consists of two parts: a set of properties and a binary message body for each key/value pair. How you use it depends on what the application is trying to do. For example, an application that sends a recent sales message might contain properties seller= "Ava" and amount=10000. The message body may contain scanned images of the signed sales contract, and if the contract is not included, simply leave it blank.

The receiver can read the message from the Service Bus queue in two different ways. The first approach is called Receiveanddelete, which is to remove the message from the queue and delete it immediately. This is simple, but if the recipient crashes before the message finishes processing, the message is lost. Because the message was removed from the queue, the receiver cannot access the message.

The second way PeekLock is designed to help solve this problem. As with Receiveanddelete, PeekLock can remove messages from the queue. However, it does not delete the message. Instead, it locks the message so that it is not visible to other receivers, and then waits for one of the following three events:

• If the receiver successfully processes the message, completion is called, and the queue deletes the message.
• If the receiver determines that it cannot process the message successfully, it will call discard. The queue unlocks the message so that it can be used by other receivers.
• If the receiver does not call these two commands within the configurable time period (default of 60 seconds), the queue assumes that the receiver failed. In this case, the queue behaves as if the receiver had called discard, that is, making the message available to other receivers.

Note that this can happen: the same message may be sent two times, that is, it may be delivered to two different receivers. Applications that use service Bus queues must be prepared for this. For easier duplicate detection, each message has a unique MessageID property that, by default, remains the same regardless of how many times the message is read from the queue.

Queues can be very useful in many cases. Even if two applications are not running at the same time, the queue can also enable communication between the two applications, which is especially handy for batch processing and mobile applications. Queues that have these receivers also provide automatic load balancing when the messages that are sent are propagated to multiple receivers.

Theme

Queues, while useful in some cases, are not always the correct solution. Sometimes the Service Bus topic is better. This is illustrated in Figure 3.

Service Bus topics and subscription charts

Figure 3: Depending on the filter specified by the subscription application, it can receive some or all of the messages sent to the Service Bus topic.

Topics are similar to queues in many ways. The sender submits the message to the topic in the same way that the message is submitted to the queue, and the message looks the same as the message that uses the queue. The biggest difference is that the subject lets each receiving application create its own subscription by defining a filter. The subscriber will then see only the messages that match the filter. For example, Figure 3 shows a sender and a topic with three subscribers, each with its own filter:

• Subscriber 1 receives only messages that contain the seller= "Ava" attribute.
• Subscriber 2 receives a message that contains the seller= "Ruby" attribute and/or the Amount attribute with a value greater than 100,000. Ruby may be a sales manager, so she wants to see her own sales as well as all the big single sales that others do.
• Subscriber 3 sets its filter to True, which means that it will receive all messages. For example, this application may be responsible for maintaining and auditing records, so it needs to see the full content.

As with queues, subscribers to a topic can read messages using Receiveanddelete or PeekLock. Unlike queues, however, a single message sent to a topic can be received by multiple subscribers. This method, often referred to as publication and subscription, is useful when multiple applications are interested in the same message. By defining the appropriate filters, each Subscriber can access only the part of the message flow that needs to be viewed.

Relay

Both queues and topics provide one-way asynchronous communication through proxies. Traffic flows in one direction only, and there is no direct connection between the sender and the receiver. But what if you don't want to do that? Suppose your application needs to send and receive messages at the same time, or you might want to have direct links between applications without needing to store messages between them in a location. To address this type of problem, Service Bus provides a trunk, shown in 4.

Service Bus Relay Chart

Figure 4:service Bus Relay provides synchronous two-way communication between applications.

The obvious question about relaying is: why do I use trunks? Even if I don't need a queue, why should I use the cloud service for application communication rather than direct interaction? The answer is that direct conversations are more difficult than you think.

Suppose you want to connect two local applications, both of which run in the Enterprise data center. Each application is behind a firewall, and each data center is likely to use network address translation (NAT). Firewalls block incoming data on almost all ports, and NAT means that the computer running each application is likely to have no fixed IP address. Without some extra help, connecting these applications over the public Internet can create problems.

Service Bus Relay can provide this help. To communicate in two-way through trunking, each application is required to establish an outbound TCP connection using service Bus and then remain open. All communication between the two applications will be transmitted through these connections. Because each connection is built from within the datacenter, the firewall will allow incoming traffic to each application (that is, data sent over the trunk) without opening a new port. This approach also solves the NAT problem because each application is consistent across the entire communication endpoint. By relaying data, applications can avoid problems that cause communication difficulties.

To use service Bus trunking, the application relies on Windows communication Foundation (WCF). Service Bus provides a WCF binding that makes it easier for Windows applications to interact with trunks. Applications that have used WCF typically need only specify one of the bindings to interact with the relay. However, unlike queues and topics, using trunks from non-Windows applications (where possible) requires some programming effort; No standard libraries are available.

Unlike queues and topics, an application does not explicitly create trunks. Conversely, a relay is created automatically when the application that wants to receive the message establishes a TCP connection to the Service Bus. When the connection is interrupted, the trunk is deleted. To enable applications to find trunks created by a particular listener, Service Bus provides a registry that allows specific trunks to be located by name.

Trunking is the correct solution when you need to communicate directly. For example, an airline ticketing system that runs in an on-premises datacenter can access the system from check-in counters, mobile devices, and other computers. Applications running on all of these systems may rely on Service Bus relays in the cloud for communication, regardless of where they run.

Connecting applications are always part of building a complete solution, and it's hard to see this problem disappear forever. By providing cloud-based technologies for this purpose, that is, queues, topics, and Trunks, Service Bus is designed to make this basic functionality simpler and more widely available.

Reference: http://www.windowsazure.cn/zh-cn/develop/net/fundamentals/hybrid-solutions/#Fig2

Windows Azure Service Bus (1) Fundamentals