Este artículo proviene de un motor de traducción automática.

Aspectos básicos

Enrutadores en Service Bus

JUVAL LOWY

En Mis anteriores dos columnas, descrito el bus de servicio de .NET se diseñó para solucionar el problema de núcleo, de conexión a Internet y problemas de seguridad relacionados. Sin embargo, el bus de servicios ofrece mucho más simple conectividad y retransmisión de mensajería. Esta columna comienza con el registro de servicio y, a continuación, describe aspectos de los enrutadores. Mi próxima columna que dedicar a las colas en la nube. En ambas columnas describiré nuevos modelos de diseño eficaces, y cómo combinar los enrutadores y las colas y mi auxiliar clases y herramientas para simplificar la experiencia general.

El registro de servicios

El bus de servicio de .NET ofrece una fuente ATOM de servicios de escucha en la dirección de base de solución o en cualquiera de sus sub-URIs. Para ver la fuente desplazándose a la solución (o el identificador URI) con un explorador. La fuente sirve como un registro y un directorio para los servicios y aspectos (tales como enrutadores y las colas) en la solución.

De forma predeterminada, el servicio no está visible en el explorador. Puede controlar la publicación de registro de servicio mediante la clase de comportamiento de extremo ServiceRegistrySettings, que se define como sigue:

public enum DiscoveryType
{
Public,
Private
}
public class ServiceRegistrySettings : IEndpointBehavior
{
public ServiceRegistrySettings();
public ServiceRegistrySettings(DiscoveryType discoveryType);
public DiscoveryType DiscoveryMode
{get;set;}
public string DisplayName
{get;set;}
}

El host debe agregar ese comportamiento mediante programación a cada extremo que desee publicar en el registro. (No hay ningún comportamiento coincidente configurable). Por ejemplo, para publicar todos los extremos en el registro, utilizaría el código que se muestra aquí:

IEndpointBehavior registeryBehavior =
new ServiceRegistrySettings(DiscoveryType.Public);
ServiceHost host = new ServiceHost(typeof(MyService));
foreach(ServiceEndpoint endpoint in host.Description.Endpoints)
{
endpoint.Behaviors.Add(registeryBehavior);
}
host.Open();

Figura 1 en el Explorador de bus de servicios

Para ayudar a visualizar el bus de servicio, he desarrollado el Explorador de bus de servicio, se muestra en de figura 1. La herramienta acepta el nombre de la solución para explorar y, después de iniciar sesión en la fuente, visualizar para los servicios en ejecución. Todo el explorador que hace es analizar la fuente ATOM y colocar los elementos en el árbol a la izquierda. Puede explorar varias soluciones y ver en el panel derecho de las páginas de administración de la solución. La herramienta también muestra los enrutadores disponibles y las colas y es muy útil en administración.

Nube como interceptor

El bus de servicios realmente inicialmente se desarrolló para solucionar los problemas de conectividad agudo de llamadas a través del Web. Sin embargo, tiene la posibilidad de mucho más. Compare la arquitectura básica de Windows Communication Foundation (WCF) con la arquitectura de bus de servicio. En ambos casos, el cliente no interactúa directamente con el servicio, pero en su lugar middleware intercepta las llamadas. En el caso de WCF normal, el software intermedio es el proxy y la cadena de interpretación conducen al servicio, como se muestra en de figura 2.

En el caso de las llamadas retransmitidas, el software intermedio se compone de la middleware WCF normal y el bus de servicio, como se muestra en de figura 3. Desde el punto de vista de arquitectura, éste es el mismo diseño, interceptar las llamadas a proporcionar valor adicional. En la versión actual del bus de servicio, ese valor adicional es la posibilidad de instalar los enrutadores y las colas. De hecho, Creo que el bus de servicio tiene gran potencial para interceptores eficaces y sin duda será el aspectos adicionales disponibles a lo largo del tiempo.

Intercepta llamadas WCF estándar de la figura 2

Figura 3 la nube como interceptor

Uniones como enrutadores

En el bus de servicio, cada URI de la solución es realmente una unión de mensajería direccionable. El cliente puede enviar un mensaje para que los de unión y la unión puede retransmitir a los servicios. Sin embargo, cada unión puede funcionar también como un enrutador. Varios servicios pueden suscribir a ese enrutador y el enrutador puede reenviar el mensaje de cliente mismo para todas ellas o simplemente un solo uno de ellos, como se muestra en de figura 4.

El cliente está desacoplado de los servicios está detrás del enrutador, y lo que el cliente está preocupado, puede no incluso haber los servicios está detrás del enrutador. Todo el cliente necesita saber es donde se encuentra el enrutador que necesita para enviar mensajes. Confía en el enrutador que configurarse con la directiva de distribución adecuados. Debido a que indirectness de los mensajes son intrínsecamente de una forma y, de hecho, WCF insiste en que el enlace utilizado por el cliente y los servicios de suscripción es el enlace de retransmisión unidireccional. El cliente no tiene forma de recibir los resultados de los servicios o de que se evalúen de errores del servicio. Esto sería el caso incluso si el enlace no de una forma. Si el mensaje de cliente que se está multiplexado a varios servicios, a continuación, por definición no es ningún significado para los resultados devueltos por la operación (desde qué servicio?) o para errores (de qué servicio?). También es posible para los servicios para volver a llamar a su cliente.

de la figura 4 el bus de servicios como un enrutador

Directiva de enrutador

El Administrador de la solución administra los enrutadores independientemente de los servicios. Cada enrutador debe tener una directiva que rigen su comportamiento y la duración. El cuadro de, el Administrador de solución debe realizar llamadas mediante programación para crear y administrar enrutadores. Todas las directivas de unión de mensajería se derivan de la clase abstracta JunctionPolicy, que se muestra en de figura 5.

La propiedad de la unión de descubrimiento es una enumeración del tipo DiscoverabilityPolicy. Controla si se incluye la unión en el ATOM fuente de la solución. Descubrimiento de forma predeterminada DiscoverabilityPolicy.Managers, lo que significa una directiva privada. Si se establece en DiscoverabilityPolicy.Public, publica a la fuente. La propiedad ExpirationInstant controla la duración de la unión. Una vez que la directiva ha caducado, se quita la unión. El valor predeterminado ExpirationInstant es un día. Obviamente, que puede o no ser adecuado para los enrutadores (o colas), por lo que normalmente es necesario establecerla en el valor que desee y supervisarlo. Como la unión a punto de caducar, se debe renovar si la unión está todavía en uso. Llame a que el tiempo de concesión de “ ” de la unión de renovación y llame a la parte que amplía la concesión “ patrocinador. ” Por último, la propiedad TransportProtection controla la seguridad de transferencia del mensaje para la unión. Al registrar o recuperar mensajes WCF sin procesar a o desde las uniones de mensajería, está limitado a utilizar seguridad de transporte con el valor de TransportProtectionPolicy.AllPaths. Seguridad de transporte es el predeterminado para todas las directivas de unión y recomiendo nunca estableciéndola en cualquier otro valor.

Figura 5 de la clase JunctionPolicy

public enum DiscoverabilityPolicy
{
Managers,Public //More values
}
public enum TransportProtectionPolicy
{
None,AllPaths
}
[DataContract]
public abstract class JunctionPolicy
{
public JunctionPolicy();
public JunctionPolicy(JunctionPolicy policyToCopy);
public DateTime ExpirationInstant
{get;set;}
public DiscoverabilityPolicy Discoverability
{get;set;}
public TransportProtectionPolicy TransportProtection
{get;set;}
//More members
}

Figura 6 de la clase RouterPolicy

public enum MessageDistributionPolicy
{
AllSubscribers,
OneSubscriber
}
[DataContract]
public class RouterPolicy : JunctionPolicy,...
{
public RouterPolicy();
public RouterPolicy(RouterPolicy otherRouterPolicy);
public int MaxSubscribers
{get;set;}
public MessageDistributionPolicy MessageDistribution
{get;set;}
//More members
}

Cada directiva de enrutador se expresa con la clase RouterPolicy, definida en de figura 6. Las dos principales propiedades aquí son MaxSubscribers y MessageDistribution. Como su nombre implica, MaxSubscribers es el número máximo de suscriptores simultáneos pueden conectarse al enrutador. El valor predeterminado es 1 y el valor máximo es 50. Una vez que el enrutador es de salida sobrepasa, servicios adicionales intentando suscribirse obtener un error. MessageDistribution es una enumeración del tipo MessageDistributionPolicy y valores predeterminados para MessageDistributionPolicy.OneSubscriber--es decir, sólo uno de los servicios de suscripción Obtiene el mensaje. Si se establece en MessageDistributionPolicy.AllSubscribers entrega el mensaje a todos los servicios.

Administrar la directiva de enrutador

Puede utilizar la clase RouterManagementClient, que se muestra aquí, para administrar las directivas de enrutador:

public static class RouterManagementClient
{
public static RouterClient CreateRouter(
TransportClientEndpointBehavior credential,
Uri routerUri,RouterPolicy policy);
public static void DeleteRouter(
TransportClientEndpointBehavior credential,
Uri routerUri);
public static RouterClient GetRouter(
TransportClientEndpointBehavior credential,
Uri routerUri);
public static RouterPolicy GetRouterPolicy(
TransportClientEndpointBehavior credential,
Uri routerUri);
public static DateTime RenewRouter(
TransportClientEndpointBehavior credential,
Uri routerUri,TimeSpan requestedExpiration);
}

RouterManagementClient es una clase estática y todos sus métodos requieren el objeto de credencial (del tipo TransportClientEndpointBehavior, tratado en mi columna anterior (consulte msdn.microsoft.com/magazine/dd942847.aspx de). El código siguiente muestra la creación de un enrutador sencillo y una directiva:

Uri routerAddress =
new Uri(@"sb://MySolution.servicebus.windows.net/MyRouter/");
TransportClientEndpointBehavior credential = ...;
RouterPolicy policy = new RouterPolicy();
policy.ExpirationInstant = DateTime.UtcNow + TimeSpan.FromMinutes(5);
policy.MaxSubscribers = 4;
policy.MessageDistribution = MessageDistributionPolicy.AllSubscribers;
RouterManagementClient.CreateRouter(credential,routerAddress,policy);

En el ejemplo, crear una instancia un objeto de directiva de enrutador y establecer la directiva para algunos valores, como distribuir el mensaje a todos los servicios de suscripción y limitar el enrutador para los suscriptores no más de cuatro. El enrutador está configurado para tener una vida corta de sólo cinco minutos. Todo lo necesario para instalar el enrutador es llamar al método CreateRouter de RouterManagementClient con la directiva y algunas credenciales válidas.

Como alternativa a las llamadas mediante programación, puede utilizar mi explorador de bus de servicios para ver y modificar los enrutadores. Puede crear un nuevo enrutador especificando su dirección y varias propiedades de directiva. En la misma manera, puede eliminar todos los enrutadores de la solución.

También puede revisar y modificar las directivas de enrutadores existentes seleccionándolos en el árbol de la solución y interactuar con sus propiedades en el panel derecho, como se muestra en figura 7.

Todo el cliente debe realizar para exponer mensajes a un enrutador es crear un proxy cuya dirección es la dirección del enrutador y llame al proxy.

Suscribirse a un enrutador

Para que un servicio recibir mensajes de un enrutador, debe suscribirse al enrutador agregando a los host un extremo cuya dirección es dirección ’s enrutador. Una manera de hacerlo es mediante la clase auxiliar RouterClient, que se define como sigue:

public sealed class RouterClient
{
public ServiceEndpoint AddRouterServiceEndpoint<T>(
ServiceHost serviceHost);
//More members
}

Los métodos de RouterManagementClient que creación u obtener un enrutador devuelven una instancia de RouterClient. Deberá llamar a la AddRouterServiceEndpoint < T >método con una instancia de su host de servicio. Puede agregar simplemente un extremo para el host (mediante programación o en un archivo de configuración) cuya dirección es la dirección del enrutador. Aquí se muestra un ejemplo:

<service name = "MyService">
<endpoint
address = "sb://MySolution.servicebus.windows.net/MyRouter/"
binding = "netOnewayRelayBinding"
contract = "..."
/>
</service>

Figura 7 A enrutador en el Explorador de bus de servicios

Figura 8 suscribirse al enrutador

Uso de enrutadores

Los enrutadores tienen tres usos. El primero es el mismo mensaje a varios servicios de difusión. Caso clásico, por supuesto, publica los eventos a servicios, tratando el bus de servicio como un middleware de concentrador de eventos de suscripción. Como se mencionó en mi columna en el problema de abril (consulte msdn.microsoft.com/magazine/dd569756.aspx de), hay más de evento que cumple el ojo, por lo que diferir eventos discutir al final de esta columna de la publicación.

El segundo uso de un enrutador es como un equilibrador de carga entre servicios. Si configura la directiva de enrutador para distribuir mensajes a sólo un único suscriptor, el enrutador en vigor actúa como un equilibrador de carga entre los servicios de suscripción. Todos los equilibradores de carga siga algunos algoritmo en decidir qué servicio va a controlar el mensaje siguiente. Algoritmos comunes incluyen turnos, aleatorio, algunos justo el panel de resultados y la cola. Mis pruebas indican que el bus de servicios utiliza pseudo–round de operación por turnos, es decir, era turnos justo algunos 95 por ciento de la hora. Para simplificar la creación de un enrutador de equilibrio de carga, mi clase auxiliar ServiceBusHelper ofrece una serie de métodos sobrecargados de CreateLoadBalancingRouter, que se muestra aquí:

public static partial class ServiceBusHelper
{
//Uses CardSpace for credential
public static void CreateLoadBalancingRouter(string balancerAddress);
/* Additional CreateLoadBalancingRouter(...)
with different credentials */
}

CreateLoadBalancingRouter crea un enrutador con una directiva que distribuye los mensajes para un único suscriptor. También detecta si el enrutador existe antes de crearlo y automáticamente renueva la concesión del enrutador. La implementación de enrutador CreateLoadBalancing se incluye en descarga de código del artículo.

Todos los métodos CreateLoadBalancingRouter públicos toman tipos de credenciales diferentes (la implementación proporciona utiliza CardSpace), crear una instancia de TransportClientEndpointBehavior y llamada interno sobrecargado CreateLoadBalancingRouter. Esa versión sobrecargada, crea una directiva de equilibrio de carga que también se publica el enrutador para la ATOM fuente y se llama a CreateRouter con la directiva especificada y las credenciales. CreateRouter primero utiliza el método RouterExists para comprobar si ya se ha creado el enrutador. Desgraciadamente, la única forma para comprobar es si se produce un error al intentar obtener directiva del enrutador.

Si existe el enrutador, CreateRouter devuelve su RouterClient correspondiente. Si el enrutador no existe, CreateRouter crea primero un temporizador para supervisar la caducidad de la concesión, mediante una expresión lambda como un patrocinador. A medida que el tiempo de concesión aproxima el final, el temporizador llama a la expresión lambda para renovar la concesión. A continuación, CreateRouter crea el enrutador.

Enrutadores para enrutadores

El tercer uso de enrutadores es para enrutar mensajes a otros uniones, como otros enrutadores (o colas). Para suscribirse a un enrutador a otro, utilice el método SubscribeToRouter de RouterClient, se muestra aquí:

public sealed class RouterClient
{
public RouterSubscriptionClient SubscribeToRouter(
RouterClient routerClient,
TimeSpan requestedTimeout);
//More members
}
[Serializable]
public class RouterSubscriptionClient
{
public DateTime Expires {get;}
public DateTime Renew(TimeSpan requestedExpiration,
TransportClientEndpointBehavior credential);
public void Unsubscribe(TransportClientEndpointBehavior credential);
//More members
}

SubscribeToRouter acepta al cliente de enrutador del enrutador que desea suscribirse y devuelve una instancia de RouterSubscriptionClient. Los principales usos de RouterSubscriptionClient es para cancelar la suscripción y renovar la concesión de suscripción.

Por ejemplo, suponga que tiene un servicio, servicio B y servicio de C. Se requiere que cada llamada de cliente siempre va a servicio A y servicio B o c de servicio. (Imagine que necesita cargar saldo servicio B y C de servicio, pero también mantener un registro de todas las llamadas en el servicio de logbook A). Las directivas de enrutador descritas hasta ahora, de entrega para todos los suscriptores o para un único suscriptor, son inadecuadas. Sin embargo, se pueden satisfacer los requisitos fácilmente utilizando dos enrutadores, como se muestra en figura 8.

El cliente envía los mensajes a un enrutador de nivel superior con una directiva de distribución a todos los servicios. Servicio A se suscribe al enrutador de nivel superior. Un subrouter con una directiva de distribución de un único suscriptor también se suscribe al enrutador de nivel superior. Tanto el servicio B como el servicio C suscribirse a esa subrouter. de la figura 9 muestra la configuración de enrutadores necesarios y cómo suscribirse subrouter al enrutador superior.

Cuando se trata de un servicio de suscripción a un enrutador de suscripción, no hay un detalle importante con respecto a la suscripción que difiere de suscribirse a un enrutador de nivel superior. El extremo de servicio debe indicar que está dispuesto a recibir mensajes desde el enrutador de la suscripción, aunque los mensajes dirigidos al enrutador de nivel superior. Esta indicación es hacen estableciendo la propiedad URI escucha del extremo del servicio de suscripción, mientras que el extremo de servicio propia dirección del enrutador de nivel superior. Con las direcciones de las direcciones en figura 9, ambos servicio B y servicio C tendría que definir sus extremos como sigue:

<service name = "MyService">
<endpoint listenUri =
"sb://MySolution.servicebus.windows.net/MySubRouter/"
address = "sb://MySolution.servicebus.windows.net/MyTopRouter/"
binding = "netOnewayRelayBinding"
contract = "..."
/>
</service>

Puede automatizar esta opción con la extensión de host de servicio siguientes:

public static partial class ServiceBusHelper
{
public static void SubscribeToRouter(this ServiceHost host,
string subRouterAddress)
{
for(int index = 0;
index < host.Description.Endpoints.Count;index++)
{
host.Description.Endpoints[index].ListenUri =
new Uri(subRouterAddress);
}
}
//More members
}

Dado que un enrutador puede suscribirse a varios enrutadores, deben ser muy atento de qué dirección--es decir, el enrutador de nivel superior--desean recibir mensajes de los servicios que suscribirse al enrutador de suscripción.

Tenga en cuenta que quitar el enrutador de nivel superior o terminar la suscripción corta subrouters de mensajes de cliente. A su vez, esto, es una característica de ordenación para administradores de solución, que pueden utilizar este paso para eficaz apagar servicios sin cerrar sus hosts.

Figura 9 suscribirse al enrutador

Uri topRouterAddress =
new Uri(@”sb://MySolution.servicebus.windows.net/MyTopRouter/");
Uri subRouterAddress =
new Uri(@”sb://MySolution.servicebus.windows.net/MySubRouter/");
TransportClientEndpointBehavior credential = ...;
RouterPolicy topRouterPolicy = new RouterPolicy();
subRouterPolicy.MaxSubscribers = 20;
topRouterPolicy.MessageDistribution =
MessageDistributionPolicy.AllSubscribers;
RouterClient topRouterClient = RouterManagementClient.CreateRouter(
credential,topRouterAddress,topRouterPolicy);
RouterPolicy subRouterPolicy = new RouterPolicy();
subRouterPolicy.MaxSubscribers = 30;
subRouterPolicy.MessageDistribution =
MessageDistributionPolicy.OneSubscriber;
RouterClient subRouterClient = RouterManagementClient.CreateRouter(
credential,subRouterAddress,subRouterPolicy);
RouterSubscriptionClient subscription = subRouterClient.
SubscribeToRouter(topRouterClient,
TimeSpan.MaxValue);
//Sometime later
subscription.Unsubscribe(credential);

Uso de enrutadores para eventos

Como mencioné anteriormente, la unión de mensajería en el bus de servicios puede actuar como un concentrador de eventos vulgar y difusión de los mensajes para servicios de suscripción. Necesita instalar una directiva de enrutador que maximiza el número de suscriptores y notifica a todos los suscriptores. Las deficiencias de hacerlo así son similares al uso de los eventos de enlace (explicado en mi columna de abril a msdn.microsoft.com/magazine/dd569756.aspx de). No hay ninguna suscripción por operación, y, por lo tanto, los suscriptores (todos ellos) siempre recibir todos los eventos, incluso eventos no le importa sobre (aquellos que simplemente tiene un extremo coincidente).

La solución no es crear un único enrutador para controlar todos los eventos pero para crear un enrutador por evento. Servicios que están interesados en sólo ese evento se suscribirán a enrutador concreto ese evento ’s. Como con los eventos de enlace, tener un enrutador por evento se consigue tener cada suscriptor administrar una instancia de host por operación, ya que un único host que supervisa todos los enrutadores no hará nada para filtrar los eventos. El suscriptor debe abrir y cerrar el host respectivo para suscribirse o cancelar la suscripción al evento. Esto requiere código tedioso y repetitivo.

La buena noticia es que la clase auxiliar EventsRelayHost que presenta en mi anterior columna ya que está realizando y con un poco de refactorización de una clase base común denominada EventsHost, se puede adaptar para utilizar con enrutadores en lugar del enlace de retransmisión de eventos. (Para enrutadores, es necesario el enlace de retransmisión unidireccional).

En primer lugar, he definido la clase base abstracta EventsHost, que se muestra aquí:

//Partial listing
public abstract class EventsHost
{
public EventsHost(Type serviceType,string baseAddress);
public EventsHost(Type serviceType,string[] baseAddresses);
public abstract void SetBinding(NetOnewayRelayBinding binding);
public abstract void SetBinding(string bindingConfigName)
protected abstract NetOnewayRelayBinding GetBinding();
public void Subscribe();
public void Subscribe(Type contractType);
public void Subscribe(Type contractType,string operation)
public void Unsubscribe();
public void Unsubscribe(Type contractType);
public void Unsubscribe(Type contractType,string operation);
}

Las dos subclases, EventsRelayHost y EventsRouterHost, se definen en implementación de .el de figura 10 de EventsHost y EventsRelayHost se presenta en mi columna anterior.

Figura 10 definir EventsRelayHost

//For use with the events binding, see previous column
public class EventsRelayHost : EventsHost
{...}
public class EventsRouterHost : EventsHost
{
public override void SetBinding(NetOnewayRelayBinding binding)
{
RelayBinding = binding;
}
public override void SetBinding(string bindingConfigName)
{
SetBinding(new NetOnewayRelayBinding(bindingConfigName));
}
protected override NetOnewayRelayBinding GetBinding()
{
return RelayBinding ?? new NetOnewayRelayBinding();
}
}

Es similar a EventsRelayHost EventsRouterHost--ambos administrar un host por evento y es importante no si la dirección que supervisan es la dirección de un extremo de eventos o un enrutador. La única diferencia es que la EventsRouterHost debe utilizar la retransmisión unidireccional enlazar a recibir los eventos, en oposición a los eventos de enlace utiliza EventsRelayHost. Aparte de eso, EventsRouterHost y EventsRelayHost deben ser idénticos. Esto se refleja en el hecho de que se derivan de EventsHost, que realiza el trabajo pesado de administrar los hosts. EventsRouterHost y EventsRelayHost reemplazan simplemente los métodos de administración de enlace.

Aparte de eso, utilizando EventsRouterHost es igual que con EventsRelayHost, donde suscribir y Cancelar suscripción funcionan en lugar de apertura y cierre el host:

EventsHost host = new EventsRouterHost(typeof(MyService),
"sb://MySolution.servicebus.windows.net/...");
host.Subscribe();
...
host.Unsubscribe(typeof(IMyEvents),"OnEvent2");

El código anterior, se abre y cierra un host respectivo internamente que supervisa sólo ese evento.

Crear evento enrutadores

EventsRouterHost requiere que el Administrador de la solución configurar los enrutadores de antemano y no intentará crear los enrutadores. He realizado esa elección deliberadamente para separar la configuración de los enrutadores y sus directivas de los suscriptores. Todo el cliente ve es dirección de la unión ’s y para desencadenar un evento a través de un enlace de retransmisión unidireccional, puede utilizar el mismo EventRelayClientBase presentado en mi columna anterior para publicar los eventos.

Para simplificar el esfuerzo de creación de los enrutadores de evento, puede utilizar mi ServiceBusHelper para crear los enrutadores:

public static partial class ServiceBusHelper
{
//Uses CardSpace for credential
public static RouterClient[] CreateEventRouters(string baseAddress,
Type contractType);
/* Additional CreateEventRouters(...) with different credentials */
}

CreateEventRouters acepta la dirección base del enrutador. Se anexa a la dirección base, el nombre del contrato y el nombre de operación y se abre un enrutador individual en esa dirección. Por ejemplo, dada la siguiente dirección base:

sb://MySolution.servicebus.windows.net/

y esta definición de contrato:

[ServiceContract]
interface IMyEvents
{
[OperationContract(IsOneWay = true)]
void OnEvent1();
[OperationContract(IsOneWay = true)]
void OnEvent2(int number);
[OperationContract(IsOneWay = true)]
void OnEvent3(int number,string text);
}

CreateEventRouters crea los siguientes enrutadores:

sb://MySolution.servicebus.windows.net/IMyEvents/OnEvent1/
sb://MySolution.servicebus.windows.net/IMyEvents/OnEvent2/
sb://MySolution.servicebus.windows.net/IMyEvents/OnEvent3/

Esto es exactamente lo que espera EventsRouterHost. Descarga de código de este artículo proporciona una lista parcial de la implementación de ServiceBusHelper.CreateEventRouters, sin control de errores y algunos de los métodos de sobrecarga de seguridad.

El CreateEventRouters pública que no toma ninguna credencial predeterminada utiliza CardSpace creando un objeto TransportClientEndpointBehavior y pasar al método interno. Ese método utiliza la reflexión para obtener la colección de operaciones en el tipo de contrato de servicio. Para cada operación, llama al método CreateEventRouter, pasándole la dirección para el enrutador y la directiva. La directiva para cada enrutador maxes el número de suscriptores, entrega los eventos a todos ellos y publica el enrutador para la ATOM fuente.

Frente a enrutadores. los eventos de enlace

Para la mayoría de los casos de basada en nubes publicar-suscribirse soluciones, recomiendo los enlace de eventos. En primer lugar, encuentro el límite en el número máximo de suscriptores que un impedimento grave. Es posible que 50 será más adecuado para la aplicación. Sin embargo, ¿qué ocurre si a lo largo del tiempo necesita admitir suscriptores más? Dicho límite no se impone en los eventos de enlace. Otros problemas con el enfoque de los enrutadores son la necesidad de crear de antemano los enrutadores y preocuparse acerca de los patrocinadores de concesión. Los eventos de enlace, por otro lado, funciona como un enrutador de ad-hoc vulgar sin estas obligaciones.

Hay dos graces Guardar para administración de eventos de enrutador. La primera es la opción para los administradores de sistema para utilizar herramientas como el Explorador de bus de servicios para administrar los suscriptores, incluso indirectamente mediante administración de los enrutadores. El segundo y más ubstantial, es la capacidad para combinar los enrutadores con colas de crear en cola publicadores y suscriptores de colas, el enfoque describirá en mi próxima columna.

Juval Lowy es arquitecto de software de IDesign Y ofrece cursos en WCF y asesoramiento sobre arquitectura. Su último libro es “ programación WCF Services, 2ª edición ” (O’Reilly, 2008). También es el director regional de Microsoft de Silicon Valley. Póngase en contacto con Juval en idesign.net de.