Compartir a través de


¿Qué binding elegir?       

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).

NetTcpRelayBinding

NetTcpRelayBinding es seguramente la opción más habitual que se empleará para realizar la comunicación a través del servicio de relay. Es la alternativa que mejor rendimiento ofrece.

Este tipo de binding permite comunicación bidireccionales, unidireccionales e incluso permite comunicaciones duplex con callbacks, todo ello a través del servicio de relay.

Para poder utilizar este bindings es necesario poder realizar la comunicación a través del puerto 808 TCP (o 828 si se emplea seguridad de transporte).

NetTcpRelayBinding  no tiene un límite máximo en el tamaño de los mensajes y es capaz de mantener la sesión, asegurando que las comunicaciones que se realizan a través del mismo proxy se realizan contra el mismo servicio.

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.

Como aspecto negativo, decir que este tipo de binding no es interoperable.

WSHttpRelayBinding

WSHttpRelayBinding permite enviar y recibir mensajes interoperables a través del protocolo HTTP p HTTPS.

Este tipo de binding es similar a NetTcpRelayBinding  salvo por el hecho de que sólo soporta la comunicación a través de servicio de relay.

Este tipo de binding puede ser una buena alternativa si existe un requisito de interoperabilidad o si el puerto TCP que necesita el binding TCP no se encuentra disponible.

NetOnewayRelayBinding

Con NetOnewayRelayBinding 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, se encarga de intentar hacer llegar los datos al servicio. El servicio nunca puede responder.

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".

Existe un máximo para del 64 kb para el tamaño de los mensajes que se envían al servicio de relay.

En este caso, el cliente nunca tiene la seguridad de que el mensaje ha llegado al destinatario, incluso puede darse el caso de que el servicio envíe mensajes a un servicio que no existe.

Este tipo de binding podría ser útil cuando se desea realizan una comunicación entre un cliente y un servicio y no depender del estado del servicio, por ejemplo, en entornos desconectados. El servicio no tiene por qué estar disponible pero en el momento en el que lo esté recibirá los mensajes almacenados en el buffer.

NetEventRelayBinding

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. El sistema de relay no asegura el orden de los mensajes.

Este tipo de binding puede ser útil para implementar un mecanismo de comunicación basado en el patrón publicador-subscriptor.