Are we extending and generalizing the already available transports + messaging abstraction or is this specifically designed for MB use-case?
On Thu, Mar 10, 2016 at 7:23 PM, Pamod Sylvester <[email protected]> wrote: > Hi All, > > Further to the discussion in [1], following is a design derived to revamp > the existing MQTT transport, > > *Goals of the effort * > > 1) Introduce a generalized architecture for MB Netty based transport. > (common functions which will be applicable for all protocols > implementations in general MQTT,AMQP, Websockets etc would be abstracted > out) > 2) Revamp MQTT transport using this generalized architecture. > Current MQTT library we use for the transport *Moquette [2] *internally > handles events through an inbound and a outbound disruptor ring before > handing it over to the andes core, which adds an additional latency the > goal of this effort is to remove the disruptors off the library and use > only the content encoders and decoders of it which in return will allow > boosting of the performance. Another aspect of this effort is to adopt to > Netty 4 APIs for protocol handling which has introduced major > performance improvements. > > *Design* > > [image: Inline image 1] > > As depicted above in the diagram, following is a description, > > 1) *Server : *Would be used to control the execution/lifecycle of the > Netty based server implementation. The idea is to use > *CarbonTransportInitializer > [3]* to invoke/initialize the server implementation. > 2) *AbstractServer* : Will include the most common functionality that > should be included for any Netty based transport implementation (i.e Netty, > AMQP, Websockets) this will have common methods which are generic to all > transport implementations as well as an abstract method i.e " > *createPipeLine()*". > Between transports what would differ is the chain of handlers, hence any > transport implementation extending this class (i.e MQTTServer/AMQPServer) > should override *createPipeLine()* and define the set of handlers > specific to its protocol. > 3) *Broker *: Each handler defined in the Netty pipeline will perform > actions such as encoding/decoding incoming streams and > serializing/deserializing them into messages, these messages will be a set > of commands i.e CONNECT,PUBLISH, SUBSCRIBE, ACKNOWLEDGE and based on the > commands the message should be handled differently, the way a given message > is handled will differ based on different versions of the protocol. *Broker > *Interface would abstract between the messages and the execution of the > commands (message handling semantics) so that it will help adopt to > supporting different versions of same protocols i.e MQTT 3.1, MQTT 3.1.1, > AMQP .91, AMQP 1.0 > 4) *IConnector *: When messages are being handled (semantically) through > the *Broker, *there will be different storage requirements i.e primarily > adding the message to distributed store (andes core), messages would be > expected to be handled in memory etc which requires an abstraction between > the brokering semantics and the storage connectivity. Different stores > wishing to process the messages could write its connector implementing > IConnector. > > Please do share your thoughts/suggestions on this approach. > > [1] [Architecture][MB] Abstracting transport layer from core > [2] https://github.com/andsel/moquette > [3] > https://github.com/wso2/carbon-messaging/blob/master/components/src/main/java/org/wso2/carbon/messaging/CarbonTransportInitializer.java > > Thanks, > Pamod > > > -- > *Pamod Sylvester * > > *WSO2 Inc.; http://wso2.com <http://wso2.com>* > cell: +94 77 7779495 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
