Compartir a través de


Mensajería

El service bus de AppFabric tiene como objetivo resolver el desafío de conectividad de Internet, que en muchas ocasiones resulta difícil. A menudo, el servicio con el que conectarse se encuentra detrás de los servidores de seguridad (firewalls software y hardware,) detrás de un balanceador de carga, su dirección es dinámica, sólo se puede resolver su dirección si está la red local...


Figura 1.- Retos de la comunicación

El servicio de Relay

La solución de conectividad a través de Internet puede ser muy sencilla. Si es tan difícil conectar al cliente con el servicio directamente, pues habrá que evitar conectarnos directamente y utiliza en su lugar un servicio de relay, que se encargue de retransmitir los mensajes que van desde el cliente al servidor.

El servicio de relay es un servicio que está en la nube cuyo objetivo es ayudar a comunicar aplicaciones entre sí, evitando los posibles problemas que puede haber es una comunicación directa.

El Service Bus de AppFabric actúa de relay y es capaz de retransmitir los mensajes provenientes de un cliente al destino del mismo. Lógicamente, ambos puntos de la comunicación debe tener acceso al componente que actúa de relay, situación que habitualmente ocurre ya que el servicio de relay se encuentra situado en un lugar "neutral" y las aplicaciones son capaces de realizar comunicaciones de salida hacia el relay.


Figura 2.- Comunicación a través del servicio de relay

Para poder realizar la comunicación entre el cliente y el servicio es necesario que ambos componentes se registren en el servicio de relay. El registro requiere de autenticación.

Si las aplicaciones están desarrolladas con el framework .NET, la tecnología con la que se desarrollaría toda esta comunicación sería Window Communication Foundation.

Es importante destacar que en este caso, a diferencia de una comunicación directa empleando WCF, el servicio siempre tiene que iniciar al menos una comunicación con el servicio de relay para poder recibir peticiones de los clientes. Una vez registrado el servicio, éste quedará a la espera de que el servicio de relay le retransmita los mensajes provenientes de los cliente.

Trabajar con el service bus no es muy diferente a desarrollar aplicaciones con WCF que no hagan uso de este servicio de relay. El servicio bus añade nuevos bindings a los ya existentes para WCF, bindings que permiten la comunicación entre un cliente y un servicio a través de un servicio de relay.

Tipos de bindings

AppFabric Service Bus ofrece múltiples bindings que pueden emplearse para utilizar el servicio de relay, aunque los principales son los bindings de relay para realizar las comunicaciones por TCP (NetTcpRelayBinding), los bindings WS (WSHttpRelayBinding), los bindings unidireccionales (NetOnewayRelayBinding) y los bindings de eventos (NetEventRelayBinding).

A continuación se muestra el fichero de configuración de un servicio construido con WCF y que emplea NetTcpRelayBinding. Importante destacar el contenido de la propiedad address del endpoint, valor que contiene la dirección del servicio de relay.

<system.serviceModel>
<services>
<service name="Service.MyService" >
<endpoint address="sb://mynamespace.servicebus.windows.net/MyService"
behaviorConfiguration ="sharedSecretClientCredentials"
binding="netTcpRelayBinding" contract="Service.IContract" />
</service>
</services>
<behaviors>
<endpointBehaviors >
<behavior name ="sharedSecretClientCredentials">
<transportClientEndpointBehavior credentialType="SharedSecret">
<clientCredentials>
<sharedSecret issuerName="owner"
issuerSecret="Hzw55XAm/jhTiLwHs8dwukK7LFBEmEqDuGJQ/tL+I84="/>
</clientCredentials>
</transportClientEndpointBehavior>
</behavior>
</endpointBehaviors>
</behaviors>
</system.serviceModel>

El binding TCP permite configurar la comunicación de tres maneras diferente; utilizando el servicio de relay, utilizando la comunicación directa o el modo híbrido. En el primer caso todas las comunicaciones se realizan a través del sistema de relay. En el segundo casi las comunicación se realizan de forma directa (sólo la primera comunicación se realiza por el servicio de relay), mientras que la tercera opción es una mezcla de las dos anteriores; siempre que se puede se realizará la conexión de forma directa y cuándo no se puede se realizará a través del servicio de relay.

A la configuración anterior se le puede añadir la siguiente sección con la propiedad connectionMode indicando el modo de funcionamiento deseado.

 <bindings> <!-- Application Binding --> 
<netTcpRelayBinding>
<binding name="lab" connectionMode="Hybrid">
<security mode="None" /> </binding>
</netTcpRelayBinding>
</bindings>

WSHttpRelayBinding permite enviar y recibir mensajes interoperables a través del protocolo HTTP o HTTPS. Este tipo de binding sólo soporta la comunicación a través de servicio de relay.

Con NetOnewayRelayBinding el funcionamiento es algo diferente. El cliente envía los mensajes al servidor, en lugar de al servicio, y éste los almacena en un buffer de datos. El servicio de relay, posteriormente, encargará de intentar hacer llegar los datos al servicio.

Todos los mensajes son siempre unidireccionales y para poder utilizar este tipo de binding se comprueba que todas las operaciones del servicio estén marcadas como "One-Way".

NetEventRelayBinding es una especialización clara pero fundamental del binding unidireccional NetOnewayRelayBinding. En esencia el funcionamiento es el mismo, pero permite que haya varios servicios que puedan estar escuchando a la vez en la misma URI. De esta manera, un cliente puede enviar un mensaje al servicio de relay y ser posteriormente múltiples servicios los que reciban el mensaje.