I've been working on a sub-project within Apache Qpid called Qpid
Dispatch Router. I'd like to invite use, participation, feedback,
criticism, etc.
There are a couple of basic introductory points to be made:
* Dispatch Router is built on top of the Qpid Proton engine and driver
APIs (The C implementations thereof).
* A router is not a broker. The idea of a message router was born
from the awkwardness of trying to build scaled-up messaging networks
out of brokers.
* A network built from routers provides interconnect between brokers,
between clients and brokers, or between clients and clients (i.e.
point-to-point non-brokered).
* The message router brings together the two separate worlds of
Messaging and Networking. Such a confluence was made possible by
the AMQP 1.0 protocol. The vision is to provide a messaging
interconnect that has all the advanced semantics of AMQP along with
the scale, resiliency, and ease of deployment of an IP network.
The code is in early stages of development and has not been through any
kind of release. It builds only in Posix-based environments (Linux,
etc.) and it only functions as a single stand-alone router at present
(inter-router links are not yet fully implemented). The router can be
used with both the Proton Messenger API and the Qpid Messaging Client
APIs that support AMQP 1.0 (and, in theory, with any AMQP 1.0 endpoint).
The code can be found in the Subversion tree under "qpid/extras/dispatch".
http://svn.apache.org/repos/asf/qpid/trunk/qpid/extras/dispatch
There is a draft web page for it here:
http://qpid.apache.org/components/dispatch-router/index.html
Qpid Dispatch Router will provide two basic mechanisms for message
routing. *Message Routing* forwards individual messages to their
destination(s) based on the address in the message's "to" field. *Link
Routing* propagates link-attaches across the network to the peer
addressed in the link's "source" or "target" field. This is similar to
creating a "virtual channel" across the network and allows the full
semantics (transactions, flow-control, etc.) to be provided end-to-end
(as though the participating endpoints were directly connected).
Currently, only Message Routing is implemented.
The following is a brief example of the router's use to illustrate how
it works:
[Refer to the README file for building instructions]
[The router executable and Proton Messenger examples are assumed to be
in the execution path]
Run the following in separate terminal windows:
$ router/dispatch-router -c <path-to-config-file>
$ recv amqp://0.0.0.0:5672/my_address/1
$ recv amqp://0.0.0.0:5672/my_address/1
$ recv amqp://0.0.0.0:5672/my_address/another
$ send -a amqp://0.0.0.0:5672/my_address/1 CONTENT
$ send -a amqp://0.0.0.0:5672/my_address/another CONTENT
The first line starts the router process (assumed to be configured to
listen on port 5672). The "recv" examples create connections to the
router and subscribe to two different address (two use the same
address). The "send" examples create connections to the router and send
messages to their respective addresses.
If everything works, the first sent message will be received by the
first two receivers and the second sent message will be received only by
the third receiver.
Regards,
-Ted
Dispatch Router. I'd like to invite use, participation, feedback,
criticism, etc.
There are a couple of basic introductory points to be made:
* Dispatch Router is built on top of the Qpid Proton engine and driver
APIs (The C implementations thereof).
* A router is not a broker. The idea of a message router was born
from the awkwardness of trying to build scaled-up messaging networks
out of brokers.
* A network built from routers provides interconnect between brokers,
between clients and brokers, or between clients and clients (i.e.
point-to-point non-brokered).
* The message router brings together the two separate worlds of
Messaging and Networking. Such a confluence was made possible by
the AMQP 1.0 protocol. The vision is to provide a messaging
interconnect that has all the advanced semantics of AMQP along with
the scale, resiliency, and ease of deployment of an IP network.
The code is in early stages of development and has not been through any
kind of release. It builds only in Posix-based environments (Linux,
etc.) and it only functions as a single stand-alone router at present
(inter-router links are not yet fully implemented). The router can be
used with both the Proton Messenger API and the Qpid Messaging Client
APIs that support AMQP 1.0 (and, in theory, with any AMQP 1.0 endpoint).
The code can be found in the Subversion tree under "qpid/extras/dispatch".
http://svn.apache.org/repos/asf/qpid/trunk/qpid/extras/dispatch
There is a draft web page for it here:
http://qpid.apache.org/components/dispatch-router/index.html
Qpid Dispatch Router will provide two basic mechanisms for message
routing. *Message Routing* forwards individual messages to their
destination(s) based on the address in the message's "to" field. *Link
Routing* propagates link-attaches across the network to the peer
addressed in the link's "source" or "target" field. This is similar to
creating a "virtual channel" across the network and allows the full
semantics (transactions, flow-control, etc.) to be provided end-to-end
(as though the participating endpoints were directly connected).
Currently, only Message Routing is implemented.
The following is a brief example of the router's use to illustrate how
it works:
[Refer to the README file for building instructions]
[The router executable and Proton Messenger examples are assumed to be
in the execution path]
Run the following in separate terminal windows:
$ router/dispatch-router -c <path-to-config-file>
$ recv amqp://0.0.0.0:5672/my_address/1
$ recv amqp://0.0.0.0:5672/my_address/1
$ recv amqp://0.0.0.0:5672/my_address/another
$ send -a amqp://0.0.0.0:5672/my_address/1 CONTENT
$ send -a amqp://0.0.0.0:5672/my_address/another CONTENT
The first line starts the router process (assumed to be configured to
listen on port 5672). The "recv" examples create connections to the
router and subscribe to two different address (two use the same
address). The "send" examples create connections to the router and send
messages to their respective addresses.
If everything works, the first sent message will be received by the
first two receivers and the second sent message will be received only by
the third receiver.
Regards,
-Ted