Archives

Tuesday, February 10, 2009

The Service Bus

The Service Bus is one of the three .NET services available as part of Azure Services platform. At first sight there seemed to be a slightly daunting array of options for using the Service Bus, so here is a first attempt to try and pull the most significant elements together (with some notes after the table). For more detail check the original documentation which can be found here.

Service Bus Bindings (1)

.NET 3.5 WCF Equivalent Binding (2)

Optional HTTP connectivity mode (3)

Multicast Event Distribution

One-way Binding

Default Settings

Uri Scheme (8)

Client (Sender)

Channels

Service

(Listener) Channels

Data Channel Protection

SecurityMode options

Client and Service Authentication (6)

Reliable Messaging

BasicHttpRelayBinding

BasicHttpBinding

 

 

 

SOAP 1.1

WS-I Basic profile 1.1

http

https

80

443

Pair of secure socket connections to the cloud listener (5)

Transport

TransportWithMessageCredential

Yes

 

No

NetEventRelayBinding

N/A

Yes

Yes

N publishers

M listeners

Yes

SOAP 1.2 over TCP

.NET Framing

.NET Binary Serialization

sb

808

or

828 SSL

828 SSL

or

HTTP

(3)

Transport

TransportWithMessageCredential

Yes

No

NetOnewayRelayBinding

N/A

Yes

 

Yes

SOAP 1.2 over TCP

.NET Framing

.NET Binary Serialization

sb

808

or

828 SSL

 

828 SSL

or

HTTP

(3)

Transport

TransportWithMessageCredential

Yes

No?

NetTcpRelayBinding

NetTcpBinding

 

 

 

SOAP 1.2 over TCP

.NET Framing

.NET Binary Serialization

sb

SSL protected only in Relayed mode (7)

Choice of connectivity modes: Relay, Hybrid, Direct (9)

SSL protected only in Relayed mode (7)

Choice of connectivity modes: Relay, Hybrid, Direct (9)

Transport

TransportWithMessageCredential

Yes

Yes

(CTP version doesn't support this for Hybrid and Direct)

WebHttpRelayBinding

WebHttpBinding

 

 

 

Plain HTTP messages

Support for XML and Raw (binary) message encodings - supports REST

http

https

80

443

Pair of secure socket connections to the cloud listener (5)

Transport

Yes

No

WS2007HttpRelayBinding

WS2007HttpBinding

 

 

 

SOAP 1.2

Latest OASIS standards for Reliable Message Exchange and Security

http

https

80

443

Pair of secure socket connections to the cloud listener (5)

Transport

TransportWithMessageCredential

Yes

Yes

WSHttpRelayBinding

WSHttpBinding

 

 

 

SOAP 1.2

Draft WS-* standards for Reliable Message Exchange and Security as available at release of WCF 3.0

http

https

80

443

Pair of secure socket connections to the cloud listener (5)

Transport

TransportWithMessageCredential

Yes

Yes

Service Bus Bindings (1)

These are currently the available bindings in the .NET Services December 2008 CTP. Recommended binding is NetTcpRelayBinding.

.NET 3.5 WCF Equivalent Binding (2)

For the most part the 'Relay' bindings work in the same way as their standard WCF counterparts, except that the listeners are created in the cloud.

Optional HTTP connectivity mode (3)

Features the ability for a receiver to operate using just ports 80 and 443 if connectivity is locked right down. It implements a polling system to check for new messages.

ConnectivityMode

  • ConnectivityMode.Tcp: In this mode, all one-way and event communication is relayed over outbound TCP ports 828 and 808. SSL-secured traffic uses port 828, while unsecured traffic uses port 808.
  • ConnectivityMode.Http: In this mode, all one-way and event communication is relayed over outbound ports 80 and 443 using HTTP or HTTPS. This mode is the backup communication option for environments where outbound communication is constrained to HTTP/HTTPS, where outbound ports 808 and 828 are not available, or where the service/client cannot resolve external DNS names.
  • ConnectivityMode.AutoDetect: This mode automatically selects between the ConnectivityMode.Tcp and ConnectivityMode.Http, and favors TCP if it is available.

Listener Connection (5)

The SSL-protected control channel is using outbound TCP port 828, and the data channel is using outbound port 818. The data channel is SSL-protected if the endpoint URI scheme is "https" and the Security.Mode property is set to one of the EndToEndBasicHttpSecurityMode values Transport or TransportWithMessageCredential.

Security.Transport.RelayClientAuthenticationType (6)

This property controls whether clients of a service are required to present a security token issued by the Access Control service to the Service Bus service when sending messages. Services (listeners) are always required to authenticate with the Access Control service and present an authorization token to the Service Bus. If the service (listener) wants to take over the responsibility of authenticating/authorizing clients, it can opt out of the integration between Access Control and Service Bus by setting this property to RelayClientAuthenticationType.None. The default value is RelayClientAuthenticationType.RelayAccessToken.

Transport Channel Protection (7)

The transport channel protection guards all traffic to and from the Relay, but the data is visible to (but not observed by) the Service Bus infrastructure at the socket relay point. You can employ message security (Security.Mode=EndToEndSecurityMode.Message) to ensure that payload data is protected end-to-end without ever becoming visible to a third party (including the Service Bus infrastructure) at any waypoint.

Uri Scheme (8)

  • sb implies WCF on the client.
  • http/https support non-WCF clients.

Choice of connectivity modes (9)

  1. TcpConnectionMode.Relayed: In this mode, all communication is relayed through the Service Bus cloud. The SSL-protected control connection is used to negotiate a relayed end-to-end socket connection that all Client-Service communication flows through. After the connection is established, the Service Bus infrastructure acts much like a socket forwarder proxy relaying a bidirectional byte stream.
  2. TcpConnectionMode.Hybrid: In this mode, communication is relayed through the Service Bus infrastructure while the Client and Service endpoints negotiate a direct socket connection to each other. The coordination of this direct connection is governed by the Service Bus cloud service. The direct socket connection algorithm is capable of establishing direct connections between two parties that sit behind opposing Firewalls and NAT devices. The algorithm uses only outbound connections for Firewall traversal and relies on a mutual port prediction algorithm for NAT traversal. Since the NAT traversal algorithm is dependent on a very narrowly timed coordination and a best-guess prediction about the expected NAT behavior, the algorithm tends to have a very high success rate for Home and Small Business scenarios with a small number of clients and degrades in its success rate with larger NATs. If a direct connection can be established, the relayed connection is automatically upgraded to the direct connection without message or data loss. If the direct connection cannot be established, data will continue to flow through the Service Bus Relay.
  3. TcpConnectionMode.Direct: This mode is identical to TcpConnectionMode.Hybrid in the .NET Services December 2008 CTP. In a future release, this mode will use the direct connection only once and, if established, never relay any application data through the Service Bus Relay.

No comments:

Post a Comment