We were discussing the use case of stream storage with message broker. We continue the discussion today.
A message broker can roll over all data eventually to persistence, so the choice of storage does not hamper the core functionality of the message broker.
A stream storage can be hosted on any Tier2 storage whether it is files or blobs. The choice of tier 2 storage does not hamper the functionality of the stream store. In fact, the append only unbounded data nature of messages in the queue is exactly what makes the stream store more appealing to these message brokers
The message broker is more than a publisher subscriber. It is the potential for a platform for meaningful insight into events.
The rules of a message broker need not be AMQP endpoint based address lookup. We are dealing with messages that are intended for multiple recipients. For that matter instead of addresses, regex and rich expressions may be allowed. and internally the same message may be relayed to different queues at lightning speed from queue specific initiation. We are not just putting the message broker on steroids, we are also making it smarter by allowing the user to customize the rules. These rules can be authored in the form of expressions and statements much like a program with lots of if then conditions ordered by their execution sequence. The message broker works more than a gateway server. It is a lookup of objects without sacrificing performance and without restrictions to the organization of objects within or distributed stores. It works much like routers and although we have referred to message broker as a networking layer over storage, it provides a query execution service as well.
Why gateway service cannot be implemented like this
For (Zone zone : ZoneScanner.getZones ()) {
If (zone.equals ( currentZone)) {
}
}
Imagine if this were to be performed at every data-path it would be repeated and costly.
A message broker can roll over all data eventually to persistence, so the choice of storage does not hamper the core functionality of the message broker.
A stream storage can be hosted on any Tier2 storage whether it is files or blobs. The choice of tier 2 storage does not hamper the functionality of the stream store. In fact, the append only unbounded data nature of messages in the queue is exactly what makes the stream store more appealing to these message brokers
The message broker is more than a publisher subscriber. It is the potential for a platform for meaningful insight into events.
The rules of a message broker need not be AMQP endpoint based address lookup. We are dealing with messages that are intended for multiple recipients. For that matter instead of addresses, regex and rich expressions may be allowed. and internally the same message may be relayed to different queues at lightning speed from queue specific initiation. We are not just putting the message broker on steroids, we are also making it smarter by allowing the user to customize the rules. These rules can be authored in the form of expressions and statements much like a program with lots of if then conditions ordered by their execution sequence. The message broker works more than a gateway server. It is a lookup of objects without sacrificing performance and without restrictions to the organization of objects within or distributed stores. It works much like routers and although we have referred to message broker as a networking layer over storage, it provides a query execution service as well.
Why gateway service cannot be implemented like this
For (Zone zone : ZoneScanner.getZones ()) {
If (zone.equals ( currentZone)) {
}
}
Imagine if this were to be performed at every data-path it would be repeated and costly.
No comments:
Post a Comment