| Author |
Message |
|
| Guest |
 Posted: Fri Nov 23, 2007 2:07 pm |
 |
|
|
Guest
|
| OK - I've successfully got simple enqueue and dequeue working against a single queue. |
|
|
| Back to top |
|
| tonyg |
| Posted: Mon Nov 26, 2007 4:43 pm |
|
|
|
User
Joined: 07 Nov 2006
Posts: 199
|
Hi John,
John Watson wrote:
> OK - I've successfully got simple enqueue and dequeue working against a
> single queue.
Cool.
> Next question, can you point me at some documentation
> that explains how message routing works (or if not yet implemented,
> where it lives in the roadmap, and how it's maybe expected to work)?
Routing is implemented for
- fanout
- direct
- topic
exchanges, all of which are documented in the AMQP 0-8 specification.
See
https://jira.amqp.org/confluence/download/attachments/720900/amqp0-8.pdf?version=1,
sections 2.1.3 and 3.1.3.
The API for all this is largely in the interaction of exchangeDeclare(),
queueBind(), and basicPublish().
> Ideally I'd like to be able to do content-based-routing based (say) on
> XPath expressions into XML content.
There is no XPath exchange defined by AMQP 0-8. If you can shoehorn your
routing into routing-keys, then maybe direct or topic exchanges will
server your purpose; otherwise, I'm afraid you're stuck with simulating
a router at an application level:
exchange ---> app-level router's queue
|
V
Java application doing
xpath-based routing
/|\
/ | \
V V V
exchanges, queues that are
actual targets
So messages enter the broker, leave the broker, are routed, and are
delivered again.
The xpath-router can be implemented in Java or Erlang. If it's
implemented in Erlang, it can be colocated on the broker's node.
If it's implemented in erlang, we can go even further, and make it an
experimental exchange type: we could get some experience with xpath
exchanges, which could then subsequently be proposed for standardisation...
Regards,
Tony
--
[][][] Tony Garnock-Jones | Mob: +44 (0)7905 974 211
[][] LShift Ltd | Tel: +44 (0)20 7729 7060
[] [] http://www.lshift.net/ | Email: tonyg@lshift.net
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
  
|
| Guest |
| Posted: Tue Nov 27, 2007 9:14 am |
|
|
|
Guest
|
Thanks very much, Tony.
A lot to digest here - I'll respond again, I hope, when I've done a bit
more reading. In principle, I wouldn't be averse to having a crack at an
erlang XPath routing engine - however I need to learn the language
properly first, and this is still a spare-time project at the moment!
John
*************************************************************
Satellite Information Services Limited Registered Office:
17 Corsham Street London N1 6DR, Company No. 4243307
The information in this e-mail (which includes any files
transmitted with it) is confidential and is intended for the
addressee only. Unauthorised recipients are required to
maintain confidentiality. If you have received this e-mail
in error please notify the sender immediately, destroy any
copies and delete it from your computer system.
*************************************************************
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Nov 28, 2007 11:02 am |
|
|
|
Guest
|
Hi Tony,
You say:
> The API for all this is largely in the interaction of
exchangeDeclare(), queueBind(), and
> basicPublish().
I've had another look at the AMQP spec and the API javadoc. What I find
strange is that exchanges and queues are set up and administered only
via the API. I would have expected this to be done via the admin tool.
It seems to me that these objects will tend to be shared between
different application programs which have different concerns, and in
most cases will be long lived, and the API gives me more of an
impression of transience.
Or am I missing something more fundamental about the philosophy of AMQP?
cheers
John
*************************************************************
Satellite Information Services Limited Registered Office:
17 Corsham Street London N1 6DR, Company No. 4243307
The information in this e-mail (which includes any files
transmitted with it) is confidential and is intended for the
addressee only. Unauthorised recipients are required to
maintain confidentiality. If you have received this e-mail
in error please notify the sender immediately, destroy any
copies and delete it from your computer system.
*************************************************************
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Nov 28, 2007 11:07 am |
|
|
|
Guest
|
> Or am I missing something more fundamental about the philosophy of AMQP?
This is the case because of the zero-config feature of AMQP. I.e.
install and run the software on 1000 boxes of your server farm without
any extra work.
Applications themselves are then responsible for creating the 'wiring'.
Martin
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Nov 28, 2007 11:39 am |
|
|
|
Guest
|
Martin wrote
> This is the case because of the zero-config feature of AMQP. I.e.
> install and run the software on 1000 boxes of your server farm without
any extra work.
Well, to me, this seems to be deferring the administration to some other
kind of process. Suppose that you wish to publish messages to 1000
different customers, each with their own box. Let's say each customer
has his own routing rules, and that these rules are quite complex, and
change from time to time as and when business requirements change and
cause different subsets of the available messages to be received.
Suppose also that you want to control the message routing yourself (in
response, say to a customer buying a new service from you), and you want
absolute control over the security of your own box. What must you do?
John
*************************************************************
Satellite Information Services Limited Registered Office:
17 Corsham Street London N1 6DR, Company No. 4243307
The information in this e-mail (which includes any files
transmitted with it) is confidential and is intended for the
addressee only. Unauthorised recipients are required to
maintain confidentiality. If you have received this e-mail
in error please notify the sender immediately, destroy any
copies and delete it from your computer system.
*************************************************************
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Nov 28, 2007 11:51 am |
|
|
|
Guest
|
I would probably implement this in a following way:
1. I would separate messages into different exchanges. Each exchange
would correspond to a service customer can buy. The producer application
creates the exchanges on the startup. When client buys a service, he
gets access to the corresponding exchange.
2. Client application creates its own queue and binds to desired
exchange (of course only if the service was bought already, otherwise it
should get access error) with any routing criteria. These criteria can
be changed afterwards using Queue.Bind and Queue.Unbind commands.
Martin
John Watson wrote:
> Martin wrote
>> This is the case because of the zero-config feature of AMQP. I.e.
>> install and run the software on 1000 boxes of your server farm without
> any extra work.
>
> Well, to me, this seems to be deferring the administration to some other
> kind of process. Suppose that you wish to publish messages to 1000
> different customers, each with their own box. Let's say each customer
> has his own routing rules, and that these rules are quite complex, and
> change from time to time as and when business requirements change and
> cause different subsets of the available messages to be received.
>
> Suppose also that you want to control the message routing yourself (in
> response, say to a customer buying a new service from you), and you want
> absolute control over the security of your own box. What must you do?
>
> John
>
> *************************************************************
> Satellite Information Services Limited Registered Office:
> 17 Corsham Street London N1 6DR, Company No. 4243307
>
> The information in this e-mail (which includes any files
> transmitted with it) is confidential and is intended for the
> addressee only. Unauthorised recipients are required to
> maintain confidentiality. If you have received this e-mail
> in error please notify the sender immediately, destroy any
> copies and delete it from your computer system.
> *************************************************************
>
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Nov 28, 2007 5:09 pm |
|
|
|
Guest
|
Martin wrote:
> I would probably implement this in a following way:
>
> 1. I would separate messages into different exchanges. Each exchange
would correspond to > a service customer can buy. The producer
application creates the exchanges on the
> startup. When client buys a service, he gets access to the
corresponding exchange.
>
> 2. Client application creates its own queue and binds to desired
exchange (of course only
> if the service was bought already, otherwise it should get access
error) with any routing
> criteria. These criteria can be changed afterwards using Queue.Bind
and Queue.Unbind
> commands.
Interesting..... I think I'm beginning to get the picture, but I'm
still not completely happy. Suppose you have 500 different exchanges
necessary to manage this. Your producer application does (what I'd call
the administration job) of creating the exchanges and is now busy
routing messages to all the different exchanges. A customer contacts us
and says he wants to get message type 'D' in addition to messages 'A',
'B' and 'C' that he had before. Maybe there's already an exchange with
this profile, maybe not.
The 'admin' task now is firstly (maybe) to create the new exchange and
secondly to reconfigure the customer appl to point to a new exchange.
The first task requires the producer program to be stopped,
reconfigured, and restarted. The second requires us to contact the
customer.
(At the moment we manage this sort of thing with our IBM Websphere MQ
network simply by reconfiguring the 'broking' rules - the customer stays
attached to the same queue and does not need to be contacted, and we
don't need necessarily to bounce the broker.)
Cheers
John
*************************************************************
Satellite Information Services Limited Registered Office:
17 Corsham Street London N1 6DR, Company No. 4243307
The information in this e-mail (which includes any files
transmitted with it) is confidential and is intended for the
addressee only. Unauthorised recipients are required to
maintain confidentiality. If you have received this e-mail
in error please notify the sender immediately, destroy any
copies and delete it from your computer system.
*************************************************************
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Nov 28, 2007 5:48 pm |
|
|
|
Guest
|
> Interesting..... I think I'm beginning to get the picture, but I'm
> still not completely happy. Suppose you have 500 different exchanges
> necessary to manage this. Your producer application does (what I'd call
> the administration job) of creating the exchanges and is now busy
> routing messages to all the different exchanges. A customer contacts us
> and says he wants to get message type 'D' in addition to messages 'A',
> 'B' and 'C' that he had before. Maybe there's already an exchange with
> this profile, maybe not.
I suppose you know what services you are offering in advance. So the
producer application can create all of them as it starts.
When client calls and requests access to some service the only thing you
have to do is to grant him necessary privileges to bind to the specific
exchange. I don't know how this can be done using RabbitMQ. *Question
for RabbitMQ team!*
> The 'admin' task now is firstly (maybe) to create the new exchange and
> secondly to reconfigure the customer appl to point to a new exchange.
> The first task requires the producer program to be stopped,
> reconfigured, and restarted.
Not true. Take into account that exchanges can be created dynamically in
the runtime. So if you want to add services without restarting the
broker, either publiching application or a separate admin application
can take care of that.
Note: The AMQP protocol is specifically designed to allow this kind of
interaction. The default semantics for commands like Exchange.Declare is
'create the exchange if it does not already exist' meaning that you can
safely 'declare' the exchange even from multiple applications.
> The second requires us to contact the
> customer.
You can choose to create bindings to consumer's queue from producer
side, which is kind of uncommon, but well doable in run-time though.
Martin
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Nov 29, 2007 7:40 am |
|
|
|
Guest
|
Martin Sustrik wrote:
> When client calls and requests access to some service the only thing you
> have to do is to grant him necessary privileges to bind to the specific
> exchange. I don't know how this can be done using RabbitMQ. *Question
> for RabbitMQ team!*
Exchanges and queues belong to realms. Realms can be created using the
rabbitmqctl admin tool - see
http://www.rabbitmq.com/admin-guide.html#add_realm. The realm of an
exchange/queue is determined at the time of their creation.
Publishing to an exchange requires the user to have 'write' access to
the exchange's realm. This can be granted with the rabbitmqctl admin
tool - see http://www.rabbitmq.com/admin-guide.html#set_permissions.
So far so good.
However, binding a queue to an exchange requires the user to have
'active' access to the *queue*'s realm. The AMQP 0-8 spec says nothing
about the exchange's realm in this context.
So there doesn't appear to be a way to restrict queue-exchange bindings.
Also, the concept of realms is being revamped/removed(?) in AMQP 0-10.
Matthias.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Nov 29, 2007 9:48 am |
|
|
|
Guest
|
Thanks very much for your answers, Martin. It's becoming clearer.
You say:
> So if you want to add services without restarting the
> broker, either publiching application or a separate admin application
> can take care of that.
I would choose a separate admin application to add services. Which
brings me to my original point - wouldn't it be more convenient to add
this functionality to the admin tool itself?
John
-----Original Message-----
From: Martin Sustrik [mailto:sustrik@imatix.com]
Sent: 28 November 2007 17:48
To: John Watson
Cc: rabbitmq-discuss@lists.rabbitmq.com
Subject: Re: [rabbitmq-discuss] Message routing
> Interesting..... I think I'm beginning to get the picture, but I'm
> still not completely happy. Suppose you have 500 different exchanges
> necessary to manage this. Your producer application does (what I'd
call
> the administration job) of creating the exchanges and is now busy
> routing messages to all the different exchanges. A customer contacts
us
> and says he wants to get message type 'D' in addition to messages 'A',
> 'B' and 'C' that he had before. Maybe there's already an exchange
with
> this profile, maybe not.
I suppose you know what services you are offering in advance. So the
producer application can create all of them as it starts.
When client calls and requests access to some service the only thing you
have to do is to grant him necessary privileges to bind to the specific
exchange. I don't know how this can be done using RabbitMQ. *Question
for RabbitMQ team!*
> The 'admin' task now is firstly (maybe) to create the new exchange and
> secondly to reconfigure the customer appl to point to a new exchange.
> The first task requires the producer program to be stopped,
> reconfigured, and restarted.
Not true. Take into account that exchanges can be created dynamically in
the runtime. So if you want to add services without restarting the
broker, either publiching application or a separate admin application
can take care of that.
Note: The AMQP protocol is specifically designed to allow this kind of
interaction. The default semantics for commands like Exchange.Declare is
'create the exchange if it does not already exist' meaning that you can
safely 'declare' the exchange even from multiple applications.
> The second requires us to contact the
> customer.
You can choose to create bindings to consumer's queue from producer
side, which is kind of uncommon, but well doable in run-time though.
Martin
*************************************************************
Satellite Information Services Limited Registered Office:
17 Corsham Street London N1 6DR, Company No. 4243307
The information in this e-mail (which includes any files
transmitted with it) is confidential and is intended for the
addressee only. Unauthorised recipients are required to
maintain confidentiality. If you have received this e-mail
in error please notify the sender immediately, destroy any
copies and delete it from your computer system.
*************************************************************
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Nov 29, 2007 9:52 am |
|
|
|
Guest
|
> You say:
>> So if you want to add services without restarting the
>> broker, either publiching application or a separate admin application
>> can take care of that.
>
> I would choose a separate admin application to add services. Which
> brings me to my original point - wouldn't it be more convenient to add
> this functionality to the admin tool itself?
Yup. The point is that AMQP knows nothing about administration - it's a
simple client/server wire-level protocol. However, the commands it
provides allows you to implement the admin tool in any way you want. The
admin tool from AMQP's point of view will be just another client
applcation. I suppose RabbitMQ already has some kind of admin tool
available.
Martin
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| 0x6e6562 |
| Posted: Mon Dec 03, 2007 12:26 am |
|
|
|
User
Joined: 12 Jul 2007
Posts: 250
|
> Yup. The point is that AMQP knows nothing about administration -
> it's a
> simple client/server wire-level protocol. However, the commands it
> provides allows you to implement the admin tool in any way you want.
> The
> admin tool from AMQP's point of view will be just another client
> applcation. I suppose RabbitMQ already has some kind of admin tool
> available.
As Matthias pointed out earlier, you can use the rabbitmqctl script
which invokes the API defined in the rabbit_access_control module.
Currently I'm working on exposing this via by RPC over AMQP. I have
defined a Java interface that is proxied by the RpcClient in the
Rabbit Java library. The data binding is achieved by using Hessian 2.0.
This is essentially a poor man's version of SCA - using AMQP and
Hessian as bindings to orchestrate a service contract.
The source code for the proxy and the tests are in the mtn repository
for the rabbit erlang-client.
This is still work in progress, but the basic flows work.
HTH,
Ben
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
