Hi Kishanthan, This focusses mainly on MB related transport implementation i.e if a MB server side transport will be written Netty/MQTT, this model focusses on bring an abstraction between the components/message flows
we might be apply some of the generic logic which would be used here for any Netty based transport implementation. Will have a discussion on that. Thanks, Pamod On Thu, Mar 17, 2016 at 11:02 PM, Kishanthan Thangarajah < [email protected]> wrote: > 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 > > -- *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
