Transport Service
The framework provides a message service implementation which supports a pub/sub interface. Producers publish messages over topics and consumers consume messages by subscribing to topics. A Topic has one or more contexts and is of the form “id.kind/id.kind/eventName” where the character ‘/’ is a context separator. The first context is referred to as the root context and it binds to a transport instance. Let’s consider an example topic: “Rtbdpod.Messaging/EventConsumerAdvertisement”. This topic has only one context “Rtbdpod.Messaging” and it is the root context. This root context is bound to a specific transport instance.
Transport implementations are created using the Message Service transport abstraction and injected in to the message service at run time. Message Service is a singleton and is created by Spring Container. It has dynamic configuration which is applied at run time. The dynamic configuration contains a list of transport instances to be plugged in to Message Service singleton. For each transport a list of root context bindings are specified along with any transport specific properties. These properties can be changed at run time.
The Messaging stack currently currently supports two pluggable transport implementations that enable messages to be sent from a producing application to a consuming application using different message distribution patterns.
The messaging stack is shown below.
#Netty transport
Netty transport is used to asynchronously send events from a publishing application to a consuming application cluster. It supports a discovery protocol so that the producer side of the stack discovers the consumer application instances for a given root context.
The advertisement and discovery messages flow over topics named "Rtbdpod.Messaging/EventConsumerAdvertisement" and "Rtdpod.Messaging/EventConsumerDiscover" by default. These messages flow through the Zookeeper transport requiring that a zookeeper transport instance be bound to a root context named "Rtbdpod.Messaging". However this can be changed if need be by setting the following properties for netty transport - "advertisementTopic" and "discoverTopic" and changing the zookeeper transport root context accordingly.
Netty Transport offers QOS in the form of different pluggable event schedulers. The scheduler schedules events to consumer application cluster using weighted round robin, weighted random or consistent hashing algorithms. There are scheduler implementations for each of these algorithms and they can be injected at run time based on need through dynamic configuration. Since the root context of a topic is bound to a transport instance, one can pick the QOS by specifying the topic bound to the root context. In addition this transport instance can be provisioned to both batch and compress the payload. It also provides a way to provision connection pooling and a few socket options.
This transport provides multicast like functionality using zookeeper. It provides a pub-sub interface and messages can be published and consumed similar to the Netty transport. It is bound to a root context named Rtbdpod.Messaging. This can be changed through configuration. The Zookeeper transport bean is specified in a Spring XML file.