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.
- 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.
- 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.
- 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.
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>* *
*
*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
