Read my comments below.
On Fri, Jun 7, 2013 at 12:57 PM, Hasitha Hiranya <[email protected]> wrote: > Hi, > > As we are planning for the $Subject after we have released MB 2.1.0 > properly, I want to bring out some changes I would like to see in Message > Broker architecture and modularization. > > > - Rather than implementing AMQP 1.0.0 ourselves I would like to borrow > it from outside and integrate. We need to do a comprehensive investigation > on this and only if there is no suitable solution we should carefully plan > to implement it ourselves. This will definitely need a considerable effort. > > Regarding the AMQP1.0 Implementation : We can review http://activemq.apache.org/apollo/ which supports AMQP 1.0 spec. Unfortunately they don't have client lib for that so we may have to use Qpid proton http://qpid.apache.org/proton/ for that purpose. We should separate out the in-memory implementation apart from the Cassandra Message Store implementation. i noted Qpid already has an in-memory implementation. Maybe we should try to implement it in our way. > > - We should have a very clear interface Message Store. We need to > promote the interface everywhere in the code. For now we have Cassandra > Message Store and we access it everywhere in a singleton way, which is not > going to work. Ideally, we should bring the model to a stage that we can > plug-in any Message Store implementation and refer it by qpid-config file. > > <messageStore> > > > <class>org.wso2.carbon.andes.authentication.andes.CassandraMessageStore</class> > <MessageStore> > > > - Currently, we have implemented our own way to get messages addressed > to queues and deliver it to the subscribers and handle acknowledgements, > neglecting the qpid implementation and their state model. But still, we do > not have our own way of delivering messages to topic subscribers. IMO, we > need to implement this. Further there is a consideration when we are > implementing this such that, there should be a common place to, > - track messages > - track delivery and publishing speed > - plug message expiration > - plug message selectors > - put in delivery headers > - plug in message priority implementation > - etc, etc features we provide > > Otherwise, we have to maintain two codes when providing every > single feature. > ++1, for this. > > - Need to fix JMS Transactions properly. IMO it works, but we are > missing some method implementation regarding transactions in message store. > We need to have a look at Qpid code, understand what they are and implement > them in a suitable way. > - Even if we are having some singleton classes which can be accessed > anywhere in code, we should not access them everywhere in code. What I mean > by that is we need to keep crystal clear separation of concerns in class > level. > - We have given unnecessary overhead to Cassandra Message store. For > instance, we have started Cluster Manager in Cassandra Message Store which > is wrong. Message Store class should be only for getting, storing and > removing messages. It is not suitable to call Andes related operations > within message store. > - We must get our security model correct. This should be > given precedence. > - We are planning to move to CQL instead of Hector. > - We are planning to integrate Hazelcast to implement in-memory mode > in a distributed way. > > +1, for this. Totally agree with Hazelcast. > > - We should decide on in-order-message delivery. It is so slow that it > is unusable. Maybe we can use Hazelcast itself to do the synchronization > instead of ZooKeeper we are using now. > - All the way, we have to think of tenant aspect too. How billing and > metering is done? how to separate queue and topic usage tenant-wise etc. We > have addressed this with current implementation to a certain extent. But > when we design for MB 3.0.0 we should be aware of this from the very > beginning. > > On a side note: > >>If we are writing AMQP 1.0 we will be making a broker from scratch. What > we write will not be integatable to Qpid. > >>Maybe we should reconsider using ActiveMQ as the core rather than Qpid? I > see when grading brokers Qpid has relatively less grading. > Worth looking at Active MQ before we do MB 3.0. > > I believe only after the above modular and architectural > and implementation aspect changes are done we are at a state to implement > new features for Message Broker 3.0.0 (message selectors, priority queues > etc). > > Then only the model is fixed and release by release MB product would be > much more stable. > Then only we can implement features in much more consistence and very > clear way. > Then only we can give out new features much more easily with less > unexpected bugs (as we have a consistent implementation) > Then only we can make a fancy UI on top of the model. > > WDYT on above? > > @Team > Please add the agreeing things on this to MB 3.0.0 roadmap. > > Thanks. > > -- > *Hasitha Abeykoon* > Software Engineer; WSO2, Inc.; http://wso2.com > *cell:* *+94 719363063* > *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>* * > * > * > -- Malinga Pathmal, Technical Lead, WSO2, Inc. : http://wso2.com/ Phone : (+94) 715335898
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
