Developing Applications that Use Service Bus

There must be a host application for the Web service that registers an endpoint with the Service Bus, and a client application must make requests on the Service Bus endpoint. Typically the following host application types are used:

• .NET Framework applications
  
  
• Windows Azure applications
  
  
• Scripts in both server-side and client-side Web pages
  
  
• Smart devices that have either SOAP or REST networking programming models
  
  

Fundamentally, you can use any HTTP programming model to use REST-style messages to register an endpoint with the Service Bus or to use a Service Bus endpoint that has already been published. However, it is often easier to understand how to use the Access Control service and Service Bus in the context of a technology with which you are familiar.

• If you are familiar with WCF applications, you can use this service to obtain permission from Access Control to create (or register) an endpoint address that uses the Service Bus. Subsequently, any SOAP or REST client—whether WCF or built on a non-Microsoft platform—can use the WCF Web service by invoking operations on the Service Bus address. Depending on the security requirements established by the original Web service when it registered the endpoint with the Service Bus, the client application may also have to obtain permission from Access Control to send or listen for messages by using the Service Bus.
  
  
• If you are familiar with Windows Azure applications with WCF-based services and clients, you will develop the host application locally and then run it in Windows Azure. This is true even if you use .NET Framework HTTP programming to do REST-style Web service and client communication.
  
  
• If you are familiar with REST-based Web services and you can use either a WCF SOAP-based service to authorize your application and use the Service Bus, or you can use a REST-based application to do this. The WCF Web Programming Model makes it easy to build a REST service that does this, but you can do your REST-based communication with the Service Bus any way you want. In fact, if you use REST on the Web service side and the client side, you can use the Message Buffer as a temporary storage of messages that can be retrieved by callers.
  
  

The Service Bus is made to enable bidirectional communication between service-oriented applications anywhere in the world. However, the real world is full of limits, and the Service Bus does not support every protocol you might ever want or need. For example, in this release, the system-supplied bindings support only a subset of the protocols supported by WCF. What happens when you want to use a protocol that is not supported by the system-supplied bindings? The answer is that you can either implement a WCF custom binding that does support your required protocol – or you can create a bridge between any two endpoints that enables a bidirectional stream. As the Service Bus securely exposes service contracts if the contract specifies a two-way stream, you can then host that service on the Service Bus and exchange binary data – that is, any custom protocol – using the Service Bus. You can even associate ports on either side with the binary stream, which enables pre-existing applications to communicate through the Service Bus using their own proprietary protocol. Finally, you are doing this secured by tokens from Access Control and through firewalls and NAT routers.

At the highest level, the standard Service Bus development lifecycle appears as follows. (For a different view of the development lifecycle based more on technological approach than workflow, see Service Bus Programming Lifecycle.)

1. Create an account that uses the Service Bus and establish a namespace and endpoint. For more information, see How to: Create or Modify a Service Bus Service Namespace.
   
   
2. There must be a Web service running to register an endpoint. If you have one built, go to the next step. If not, build one. For more information, see Designing a WCF Contract for the Service Bus. (For more information about building services that use WCF, see Designing and Implementing Services in WCF)
   
   
3. There are two main mechanisms to register and host endpoints with the Service Bus: WCF and SOAP using the Windows Azure Service Bus SDK, or REST-style Web services, in which case you can use the WCF Web Programming Model, .NET HTTP programming, or any other REST programming platform on any device.
   
   
   1. WCF and SOAP-style usage.
      
      
      1. Design and implement your WCF service.
         
         
      2. Choose and implement a host. This can be a local .NET application or a Windows Azure hosted application.
         
         
      3. Configure the local WCF service to register itself with Service Bus. For more information, see Configuring a WCF Service to Register with the Service Bus
         
         
      4. Execute the host application.
         
         
      5. Build any clients. See step 4.
         
         
   2. Use REST (use any REST-enabled HTTP programming platform, including the WCF REST Programming Model, to:
      
      
      1. Obtain the authorization token from the Access Control Service and create a configuration that represents the message buffer parameters. For more information, see How to: Configure an AppFabric Service Bus Message Buffer.
         
         
      2. Connect to Service Bus and use your configuration values to create a message buffer. For more information, see How to: Create and Connect to an AppFabric Service Bus Message Buffer.
         
         
      3. Send messages to the message buffer. For more information, see How to: Send Messages to an AppFabric Service Bus Message Buffer.
         
         
      4. Check the message buffer for messages. For more information, see How to: Retrieve a Message from an AppFabric Service Bus Message Buffer.
         
         
4. Create or modify a client application. For more information, see Building a Service Bus Client Application.