| Author |
Message |
< RabbitMQ mailing list ~ Implementation / Specification Stability? |
| Guest |
 Posted: Fri Oct 19, 2007 1:15 am |
 |
|
|
Guest
|
Howdy,
I'm investigating using AMQP and RabbitMQ as our service
infrastructure backbone.
I've run into some interesting incompatibilities between Qpid at
RabbitMQ -- an example:
- Qpid does not support the Access Class
- RabbitMQ's client API requires it
- According to https://issues.apache.org/jira/browse/QPID-552, the
Access class has been removed for 0-10, and replaced with sessions.
This leads to my questions:
-- Is it crazy to hope for backwards compatibility with older
clients as both the specification, and the RabbitMQ implementation,
advance?
-- Will RabbitMQ Java API compatibility be broken as the
specification changes?
In other words, am I engaging in massive foot-shooting by trying to
build on AMQP now, and should I exercise judicious patience?
Thanks!
Landon Fuller
Post recived from mailinglist |
|
|
| Back to top |
|
| alexis |
| Posted: Fri Oct 19, 2007 3:37 pm |
|
|
|
User
Joined: 06 Sep 2007
Posts: 80
Location: London
|
Hi Landon
Welcome to the list. Thanks for your questions and sorry for being
slow to reply.
I have discussed them with the team and my replies are below.
On 10/19/07, Landon Fuller <landonf@threerings.net> wrote:
> I'm investigating using AMQP and RabbitMQ as our service
> infrastructure backbone.
Great! Please tell us more - several other people have reported
similar use cases and getting them discussed on this list is an
excellent way for community members to benefit from each other's ideas
and work.
> I've run into some interesting incompatibilities between Qpid at
> RabbitMQ -- an example:
> - Qpid does not support the Access Class
> - RabbitMQ's client API requires it
> - According to https://issues.apache.org/jira/browse/QPID-552, the
> Access class has been removed for 0-10, and replaced with sessions.
Across implementations: we have a java client property
(com.rabbitmq.client.ConnectionParameters.suppressAccessRequest) that
allows us to suppress access.request checks, specifically developed
for working with QPid. This, plus migration to using the 0-9 XML or
the 0-8qpid XML, lets you interoperate at a very crude level.
That is - you should be able to drop in the XML as a config file, and
let RabbitMQ do rest automatically, to achieve interop. Let me know
if this works.
We are intimately involved with Sessions design for 0-10. Feel free
to ask more about that here. The access tickets will be deprecated
from the AMQP spec, since a better solution for security is on its
way. If 0-10 ends up ratified without access.request support, we may
remove access.request entirely from rabbitmq, even from the 0-8
implementation. No other implementation supports this part of the
specification.
You can also use SSL with AMQP -- we have experimented with this in
RabbitMQ but not released code yet.
> This leads to my questions:
> -- Is it crazy to hope for backwards compatibility with older
> clients as both the specification, and the RabbitMQ implementation,
> advance?
No you are not crazy.
At RabbitMQ we are 100% committed to interop.
> -- Will RabbitMQ Java API compatibility be broken as the
> specification changes?
No it will not.
We are developing clients with seamless interop.
MORE pedantically .... For 0-8 to 0-10 compatibility, the important
idea is to program to the model. The model isn't changing too far -
queues, exchanges, consumers, and bindings all still exist - so
*designing* for AMQP will be very similar. The API will change, but
will not change drastically. There will be added complications around
session setup and teardown, but the core operations (publish, get,
consume, declare, delete) will map in an obvious and mechanical way
from 0-8 to 0-10.
> In other words, am I engaging in massive foot-shooting by trying to
> build on AMQP now, and should I exercise judicious patience?
No you are not shooting yourself in the foot at all 
We have production users today who (as I understand it) are happy with
0-8, and are happy with the upgrade path should they need to follow
it.
> Thanks!
> Landon Fuller
My pleasure
alexis
--
Alexis Richardson
+44 20 7617 7339 (UK)
+44 77 9865 2911 (cell)
+1 650 206 2517 (US)
_______________________________________________
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 |
  
|
| tonyg |
| Posted: Fri Oct 19, 2007 4:13 pm |
|
|
|
User
Joined: 07 Nov 2006
Posts: 199
|
Hi,
Alexis Richardson wrote:
> That is - you should be able to drop in the XML as a config file, and
> let RabbitMQ do rest automatically, to achieve interop. Let me know
> if this works.
To be precise: switching to a different AMQP specification XML file is
something that's done at compile-time, and is a bit of a hack. We have a
good approach in the pipeline for getting smooth interoperation for
current 0-8/0-9 implementations, but the *current* Java client can't
have its "dialect" switched at runtime.
> You can also use SSL with AMQP -- we have experimented with this in
> RabbitMQ but not released code yet.
Expect client-side support (as simple as using a different
SocketFactory) for SSL/TLS in the next release. The server-side of the
approach is to use relaying SSL proxy, e.g. stunnel4
(http://www.stunnel.org).
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: Fri Oct 19, 2007 11:52 pm |
|
|
|
Guest
|
On Oct 19, 2007, at 8:37 AM, Alexis Richardson wrote:
> Hi Landon
>
> Welcome to the list. Thanks for your questions and sorry for being
> slow to reply.
Thanks! That was pretty quick =)
> On 10/19/07, Landon Fuller <landonf@threerings.net> wrote:
>
>> I'm investigating using AMQP and RabbitMQ as our service
>> infrastructure backbone.
>
> Great! Please tell us more - several other people have reported
> similar use cases and getting them discussed on this list is an
> excellent way for community members to benefit from each other's ideas
> and work.
Sure. Hope this isn't too verbose -- I'll throw this out there, with
the caveat that
this is a rough explanation of my current thinking, I'm sure it's
both incomplete
and imperfect, and I'd appreciate input.
First, an introduction to our problem space. We write reasonably
large online
multiplayer games, using Java. All our games implement some variation
of the "place" model:
Within the game, there is the notion of a 'place', and your client
is in it.
A place could be a room, or a pirate ship, or a 10x10 grid of a larger
virtual world. Each place is responsible for maintaining its own
state, and
allowing clients to permute the state of that place.
A client may be in several places at once: you could be playing a
puzzle (place A) while you're also aboard a pirate ship (place B).
In my ideal universe, I view places as a service, instances of which
can be started on any server
in a cluster. I'd like implementing these services to be as easy as
possible, with most of the
complexity hidden from the game developer. In some instances, the end-
user may be a game
developer, and we'll run their code in a javascript sandbox on
dedicated machines.
I see the following two abstractions as being most valuable for this
sort of service building:
- RPC:
RPC services use a request queue, and per-client response queues.
Any number of providers
can attach to the request queue and respond to requests -- that's
an application level detail.
Service providers can detach from a queue, and requests simply
queue up until they can be
handled again.
We can dispatch RPC requests to Java (possibly via a reflective
dispatcher), JavaScript
(via Rhino), or another server/language entirely.
Incoming requests can arrive via AMPQ, or external RPC brokers,
such as services implementing
XML-RPC, JSON-RPC, Hessian -- etc.
- Data queue:
Very simple queue API for providing events/data to the RPC clients.
An RPC service can place
data in the queue for client consumption. This can be used to
provide data to simple polling clients,
without requiring long-blocking server-side RPC threads. This is
also a prime candidate for wrapping
with a HTTP REST interface.
"Place" is only the first step. We also need banking, currency
exchanges, chat & presence (eg, jabber),
event logging services (for tracking server & user behavior); I'm
hoping these abstractions are a good
foundation towards building those services out.
The above is actually what I've started working on now. In addition
to the groundwork , I also expect to
solve issues like handling service lookups / request routing.
> No you are not shooting yourself in the foot at all
>
> We have production users today who (as I understand it) are happy with
> 0-8, and are happy with the upgrade path should they need to follow
> it.
Thanks for your reply, that provides me with quite a bit more
confidence.
-landonf
Post recived from mailinglist |
|
|
| Back to top |
|
| 0x6e6562 |
| Posted: Sat Oct 20, 2007 12:15 pm |
|
|
|
User
Joined: 12 Jul 2007
Posts: 250
|
Landon,
> - RPC:
> RPC services use a request queue, and per-client response queues.
> Any number of providers
> can attach to the request queue and respond to requests -- that's
> an application level detail.
> Service providers can detach from a queue, and requests simply
> queue up until they can be
> handled again.
>
> We can dispatch RPC requests to Java (possibly via a reflective
> dispatcher), JavaScript
> (via Rhino), or another server/language entirely.
>
> Incoming requests can arrive via AMPQ, or external RPC brokers,
> such as services implementing
> XML-RPC, JSON-RPC, Hessian -- etc.
This is currently possible. I am using a wrapper around the Java
RpcClient to that puts Hessian encoded calls onto a queue that gets
consumed by an Erlang rpc handler, which in turn decodes the Hessian
payload, invokes a service API, encodes the response which goes back
out to the Java client. Pretty simple stuff really, though what I have
done on the Java side is a rough cut, because I've been concentrating
*productizing* the Erlang side of things. I envisage at some stage to
produce a SCA connector to hide this plumbing from the application
code, but I'm not going to harp on about what is currently vapourware.
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 |
|
| Guest |
| Posted: Tue Oct 23, 2007 2:45 am |
|
|
|
Guest
|
On Oct 20, 2007, at 5:15 AM, Ben Hood wrote:
> This is currently possible. I am using a wrapper around the Java
> RpcClient to that puts Hessian encoded calls onto a queue that gets
> consumed by an Erlang rpc handler, which in turn decodes the Hessian
> payload, invokes a service API, encodes the response which goes back
> out to the Java client. Pretty simple stuff really, though what I have
> done on the Java side is a rough cut, because I've been concentrating
> *productizing* the Erlang side of things. I envisage at some stage to
> produce a SCA connector to hide this plumbing from the application
> code, but I'm not going to harp on about what is currently vapourware.
Neat -- This is roughly what I've got wired up, amusingly, also using
Hessian.
Have you delved into security? That's my next concern -- how to
prevent a client/peer from reading requests off of the RPC service
queue?
Cheers,
landonf
Post recived from mailinglist |
|
|
| Back to top |
|
| tonyg |
| Posted: Tue Oct 23, 2007 10:38 am |
|
|
|
User
Joined: 07 Nov 2006
Posts: 199
|
Landon Fuller wrote:
> Have you delved into security? That's my next concern -- how to prevent
> a client/peer from reading requests off of the RPC service queue?
Perhaps have a realm for the services? Client users would be permitted
only to write to exchanges/queues in the realm, and Server users would
be permitted only to read (and of course to create
queues/exchanges/bindings - this is the "active" permission).
http://www.rabbitmq.com/admin-guide.html#set_permissions contains info
on using the admin tool to configure realms and permissions. I'm
imagining something like:
rabbitmqctl add_realm / /data/services
rabbitmqctl add_user serviceuser pass1
rabbitmqctl map_user_vhost serviceuser /
rabbitmqctl set_permissions serviceuser / /data/services \
active passive write read
rabbitmqctl add_user clientuser pass2
rabbitmqctl map_user_vhost clientuser /
rabbitmqctl set_permissions clientuser / /data/services \
passive write
rabbitmqctl list_vhost_users /
rabbitmqctl list_realms /
rabbitmqctl list_permissions serviceuser /
rabbitmqctl list_permissions clientuser /
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 |
|
| tonyg |
| Posted: Tue Oct 23, 2007 10:40 am |
|
|
|
User
Joined: 07 Nov 2006
Posts: 199
|
Tony Garnock-Jones wrote:
> Perhaps have a realm for the services? Client users would be permitted
> only to write to exchanges/queues in the realm, and Server users would
> be permitted only to read (and of course to create
> queues/exchanges/bindings - this is the "active" permission).
Of course, clients need reply queues. You'd perhaps use either the
default realm, /data, for that, or set up a realm specifically for reply
queues, where the client user has active rights.
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 Oct 23, 2007 5:42 pm |
|
|
|
Guest
|
On Oct 23, 2007, at 03:40, Tony Garnock-Jones wrote:
> Tony Garnock-Jones wrote:
>> Perhaps have a realm for the services? Client users would be
>> permitted
>> only to write to exchanges/queues in the realm, and Server users
>> would
>> be permitted only to read (and of course to create
>> queues/exchanges/bindings - this is the "active" permission).
>
> Of course, clients need reply queues. You'd perhaps use either the
> default realm, /data, for that, or set up a realm specifically for
> reply
> queues, where the client user has active rights.
OK -- I was not sure if multiple realms were considered a reasonable
implementation strategy.
As far as preventing clients from reading each other's reply queues,
the best bet seems to be generating a 'securely' random queue name.
Thanks!
Landon
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Oct 23, 2007 5:44 pm |
|
|
|
Guest
|
Landon Fuller wrote:
>
> On Oct 23, 2007, at 03:40, Tony Garnock-Jones wrote:
>
>> Tony Garnock-Jones wrote:
>>> Perhaps have a realm for the services? Client users would be permitted
>>> only to write to exchanges/queues in the realm, and Server users would
>>> be permitted only to read (and of course to create
>>> queues/exchanges/bindings - this is the "active" permission).
>>
>> Of course, clients need reply queues. You'd perhaps use either the
>> default realm, /data, for that, or set up a realm specifically for reply
>> queues, where the client user has active rights.
>
> OK -- I was not sure if multiple realms were considered a reasonable
> implementation strategy.
>
> As far as preventing clients from reading each other's reply queues,
> the best bet seems to be generating a 'securely' random queue name.
>
From the Spec side we are discussing doing this with RBAC in the
Security SIG for 0-11.
Carl.
_______________________________________________
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 |
|
| number |
| Posted: Mon Jun 04, 2012 8:48 am |
|
|
|
User
Joined: 04 Jun 2012
Posts: 18
|
|
| Back to top |
|
| yeti |
| Posted: Sat Sep 01, 2012 6:00 am |
|
|
|
User
Joined: 01 Sep 2012
Posts: 17
Location: fgf
|
| Welcome to our cheap *beep* outlet, where you can always buy the most affordable price to a your favorite cheap purses. These cheap designer *beep*. The Bella Ziptop Satchel features 2 exterior cell phone pockets and is a combination of classic and modern style cheap designer purses.These are hand crafted in Italian tradition and the collection comes in timeless shapes styles that highlight the richness of the leather. |
|
|
| 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
