SALES: 1-800-867-1380

Service Bus Relayed Messaging

Updated: February 4, 2015

This section contains information and guidance about the relayed messaging pattern supported by Microsoft Azure Service Bus. Service Bus enables two applications to communicate securely regardless of where they may be located. At the highest conceptual level, using Service Bus requires:

  1. One Web service that either possesses a Shared Access Signature (SAS) key or is trusted by the Access Control service to create endpoints and receive and send messages (typically responses but also event notifications) from the Service Bus endpoint that it creates.

  2. One client application that either possesses a SAS key or is trusted by the Access Control service to send and receive messages (typically requests and responses but also event notifications) at a Service Bus endpoint.

There is only one difference between the two Web service applications: the first Web service possesses a SAS key or is trusted by Access Control to create an endpoint—that is, an address, or Uniform Resource Indicator (URI)—with Service Bus. For more information about endpoints and addresses and how they are used in Windows Communication Foundation (WCF) and Service Bus, see Specifying an Endpoint Address. The second Web application (the client), however, cannot create, affect, or manage the registered Service Bus endpoint; instead, it possesses a SAS key or is trusted by Access Control to interact with endpoints that are already registered.

Typically, the former type of application is referred to as a service (instead of client or calling application), because without a controlling or managing Web service, Service Bus would have no endpoints with which other Web-enabled applications can communicate. Web applications that interact with a pre-existing Service Bus endpoint are conventionally referred to as Web service client applications, because they consume the features available at a registered Service Bus endpoint.

Microsoft Azure Service Bus supports two types of messaging patterns: relayed messaging and brokered messaging. The two messaging patterns are discussed in the Relayed and Brokered Messaging topic. This section provides an overview of the technical features of the Service Bus relayed messaging pattern, at a high level. The following additional topics in this section describe application development with Service Bus from the point of view of a development lifecycle. Not every development goal requires starting at any one point in the cycle; if you have to develop a client that invokes a service published by Service Bus, you do not have to read about publishing a service endpoint. Instead, start with Building a Service Bus Client Application.

In This Section

Service Bus Relayed Messaging Tutorial
Describes how to build a simple Microsoft Azure Service Bus client application and service using the Service Bus “relay” messaging capabilities.

Service Bus REST Tutorial
Describes how to build a simple Service Bus host application that exposes a REST-based interface.

Service Bus Programming Lifecycle
Describes general programming lifecycles for creating an application that uses Service Bus.

Service Bus Bindings
Describes all of the Service Bus WCF bindings and the standard WCF bindings to which they correspond.

Designing a WCF Contract for Service Bus
Describes how to design an Windows Communication Foundation (WCF) service contract that can be registered to be available on at a Service Bus endpoint.

Configuring a WCF Service to Register with Service Bus
Describes how to configure an application that uses WCF.

Securing and Authenticating a Service Bus Connection
Describes how to make a Service Bus application more secure.

Building a Service for Service Bus
Describes how to set up a WCF service for hosting.

Building a Service Bus Client Application
Describes how to build a client application that connects to and uses a Service Bus service endpoint to communicate with the originating service.

Discovering and Exposing a Service Bus Service
Describes how to use the Service Bus service registry to register service endpoints, expose them in the registry, publish WSDL metadata exchange endpoints, and locate service endpoints that have been registered to be publicly visible.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
© 2015 Microsoft