The Service Bus provides your service endpoints with secure, Internet-accessible addresses regardless of the actual network location of the machine hosting the service. The accessibility the Service Bus provides extends even to machines with common connectivity constraints, such as:

• Machines residing behind a Network Address Translation (NAT) service whose primary IP (v4) address is in a private range not normally Internet addressable (such as 10.x.x.x, 192.168.x.x, or 172.16.x.x-172.31.x.x).
  
  
• Machines residing behind one or more firewalls that normally prevent incoming connections.
  
  
• Machines without permanently assigned IP addresses under publically registered domain names.
  
  

Such constraints have long represented a major obstacle to many developers seeking to create network-aware applications that can leverage Internet connectivity – for example, direct connectivity between a small business and its customers.

To overcome these obstacles, the Service Bus acts as a Web Service intermediary router, complete transparent to the messages sent between endpoints. SOAP, WS-* (WS-ReliableMessaging or WS-Coordination/WS-AtomicTransaction) or even custom Web Services protocols may be used to transport messages via the Service Bus. Message content may be protected from inspection or modification through message-level security.

HTTP support is especially noteworthy. Beyond the capability of an RFC 2616 HTTP proxy that is limited to listening on a well-known, pre-specified address and port, the Service Bus acts as an externally-hosted HTTP listener and allows HTTP requests to be exchanged between services regardless of their location.

The Service Bus utilizes a set of .NET messaging protocol primitives. These bindings create publically accessible and, if so configured, publically discoverable HTTP listener endpoints on the Service Bus:”

To provide the desired connectivity, the Service Bus acts as a Web Service intermediary router. In most respects, the Service Bus is completely transparent for SOAP messages and protocols used between endpoints. Endpoints that connect through the Service Bus can use message-level security (with or without reliance on the Access Control Service) to protect messages and therefore make it effectively impossible for the Service Bus to inspect or modify elements in the message if that were a concern. Endpoints can also use other WS-* protocols, such as WS-ReliableMessaging or WS-Coordination/WS-AtomicTransaction, or any other custom Web Services protocol transparently through the Relay.

Additionally, the Service Bus can act as an intermediary for HTTP messages. While this functionality might seem similar to the function of an RFC 2616 HTTP proxy, the relay's role towards client and service is in fact substantially different. The Service Bus is acting as an externally-hosted HTTP listener to allow the service receiving and responding to HTTP requests regardless of its network location. In contrast, an HTTP proxy expects that the accessed HTTP service is actively listening for messages on a well-known address and port specified by the client.

The SOAP and HTTP relay capabilities are implemented on top of a set of messaging protocol primitives whose functionality is fully exposed through the .NET programming model today. Those underlying messaging protocol primitives will, over the course of the next releases, be gradually exposed for consumption and composition from other runtime environments or for the construction of alternate .NET programming models that customers might want to provide over these primitives. For more information, see Creating a Custom Service Bus Binding.

1. Register your endpoint
   
   The .NET Service Bus provides a service registry for publishing and discovering service endpoint references within a solution. It allows you to publish endpoint references as either simple URI’s or as official WS-Addressing endpoint references. Others can then discover a solution’s endpoint references by browsing to the solution’s base address and retrieving an Atom feed that contains the information.
   
   There are two ways to publish endpoint references into the service registry. The most common approach is to let WCF take care of it for you when you register listeners with the relay service. The relay service automatically populates the service registry with endpoint references as you create listeners through the WCF bindings (and corresponding channels) that come with the .NET Services SDK. You can also manually publish endpoint references into the service registry through an AtomPub interface. For more information, see Discovering and Exposing a .NET Service Application.
   
   
2. The listener makes a service request
   
   The listener connects to the Relay through an outbound port and creates a socket for communication, specifying the rendezvous address it wants to “listen” on. This connection may be one-way, request/response, publish/subscription.
   
   As implied above, the connection between any listener and the Relay is always initiated from the listener side. In most connection modes, the listener initiates a secured outbound TCP socket connection into the Relay, authenticates, and then tells the Relay at which place in the naming tree it wants to start listening and what type of listener should be established. For more information, see Securing and Authenticating a .NET Services Connection.
   
   When a service endpoint is opened using any of the WCF bindings provided in the Microsoft.ServiceBus namespace, the listener establishes an outbound-only connection to the cloud-based Service Bus, creating a cloud-based listener that resides at the selected URI in the solution namespace. To establish the listener connection(s), most Microsoft.ServiceBus bindings require TCP ports 808, 818, 819, and 828 to be opened for outbound traffic on the Firewall(s) towards your Internet gateway. Exceptions are the NetEventRelayBinding and NetOnewayRelayBinding, which can optionally communicate relying solely on ports 80 and 443.
   
   Note that your action will fail if you open a listener on a URI that is already used by some other listener. In particular, you cannot open a listener within the URI scope of another listener. For example, if there is a listener on ./Sales/Leads/, you cannot open an additional listener on any suffix of that scope, such as ./Sales/Leads/Statistics/. Messages are routed to services using a longest-prefix-match algorithm. This allowis services to receive messages where the service wants to evaluate the URI suffix directly. Thus, any two listener URIs can share a common prefix, but neither URI must be a prefix of the other.
   
   
3. The Service Bus the request to the listening service
   
   Toward listening services, the Relay takes on the same role as operating-system-provided listeners, such as Windows HTTP.SYS. Instead of listening for HTTP requests locally, a relayed HTTP service establishes an HTTP listener endpoint inside the cloud-based Relay, and clients send requests to that cloud-based listener, from where they are forwarded to the listening service.
   
   Since a number of tightly managed networking environments block outbound socket connections and permit only outbound HTTP traffic, the socket-based listeners are complemented by an HTTP-based multiplexing polling mechanism that builds on a cloud-based message buffer. In the PDC release, the HTTP-based listeners support only the unicast and multicast datagram communication, but bidirectional connectivity is easily achievable by pairing two unicast connections with mutually reversed client and listener roles.).
   
   
4. The listening service responds, and the Service Bus the response to the client
   
   For one-way messaging, a single receiver registers with the relay to “listen” for messages on a particular rendezvous address within the .NET Service Bus. Senders can then “send” messages to the .NET Service Bus address to have the messages “relayed” to the registered receiver. Using one-way communication through the relay offers a more aggressive network traversal mode because it’s then possible for both the sender and the receiver to use HTTP (e.g., the receiver can poll for messages from the relay via HTTP). Request/response messaging is very similar, only you’ll typically use TCP on the receiver end.
   
   The relay service makes it easy to implement publish/subscribe architectures by allowing multiple receivers to register on the same .NET Service Bus rendezvous address. In that case, when a sender transmits a message to that rendezvous address, the relay service will distribute the transmitted message to all currently registered receivers, thereby providing multicast capabilities through the relay.
   
   Both senders and receivers can communicate with the relay using either TCP or HTTP. You typically use the former when you care more about performance and throughput and the latter when you care more about interoperability or when you need to ensure you’re able to communicate through firewalls.
   
   
5. If available, Direct Connect acts to increase the efficiency of the connection.
   
   In addition to relayed communications, the .NET Service Bus also provides a capability for establishing direct connectivity between senders and receivers in order to improve performance and throughput. Senders and receivers still communicate with the relay through a common rendezvous address but then it tries to help them connect directly to one another in order to avoid future relayed transmissions.
   
   The way the relay accomplishes this is through a mutual port predication algorithm based on probing information from the sender and receiver. The relay service looks at this probing information and does its best to predict what ports are going to be open on their respective NAT devices. It can then provide that information to the sender/receiver so that they can attempt to establish a direct connection with one another. If the relay service predicts correctly, the connection will succeed, otherwise it can try again until it decides to give up and to stick with the relayed connection.
   
   This approach is similar to the approach used by many of today’s instant messaging applications when transferring files between users. Next time you use that feature, pay attention to the initial file transfer speed and whether or not it significantly speeds up at some point during the process. If you notice a significant boost in transfer speed, you just witnessed the upgrade to a direct connection.
   
   

With these connectivity options, the Relay can provide public, bidirectional connectivity to almost any service, regardless of whether the hosting machine is located behind a NAT or whether the Firewalls layered up towards the public network do not allow inbound traffic. The automatic mapping into the Naming system means that the service also gains a public address and the service can, on demand, be automatically published into the Service Registry to make the service discoverable.