-
1. Re: Hot Deploy with JBM 2
timfox Jan 7, 2008 5:21 AM (in response to ataylor)I have been thinking about this (and other things - more later) a lot over the Christmas period.
I would like to make some changes, that I believe would make our system's configuration much simpler and more elegant.
The JBM 2.0 messaging core will be JMS agnostic, but is also a fully functioning messaging system that can be used/ embedded for OEMs etc.
The core should know nothing about JMS queues, topics, or durable subscriptions since these are JMS concepts, not core concepts.
Therefore the core should have no destination deployment configuration at all.
With core, connection factories are created directly (new JBossConnectionFactory()), so there is no need for them to exist in JNDI, same for destinations.
We can avoid a destination deployment script altogether - instead destinations are created on the fly as users use them - the first to use a destination creates it.
We then control access as to who can create, read and write using our security policy - so there's no need for destination deploy/undeploy etc. Just need a security policy.
The security policy should be overhauled to work hierarchically, e.g. you would declare something like:<security name="topics.newsfeed.bbc.*"> <role name="guest" read="true" write="false"/> <role name="publisher" read="true" write="false" create="false"/> <role name="admin" read="true" write="true" create="true"/> </security> <security name="*"> ..default security... </security> <security name="tmp.*"> ...temp destination security... </security> etc
So, it's the security policy that determines whether users can create, read or write to a queue, the actual queues are created on the fly (if the security config allows it).
This removes the need for a redeployable destination deployment file. The only thing that needs to be hot deployable is the security policy.
So that's the core messaging.
Now, for JMS we have a further requirement of "JMS administered objects" (see JMS spec).
These are the connection factories and JMS queues and topics that the user may want preconfigured in JNDI.
This is not part of the messaging core, and is very simple to implement - just a trivial JBoss service that instantiates the connection factory and destination objects and inserts them in JNDI - this service does not need to talk to messaging core at all - it's completely independent. -
2. Re: Hot Deploy with JBM 2
ataylor Jan 7, 2008 5:47 AM (in response to ataylor)The JBM 2.0 messaging core will be JMS agnostic, but is also a fully functioning messaging system that can be used/ embedded for OEMs etc.
The core should know nothing about JMS queues, topics, or durable subscriptions since these are JMS concepts, not core concepts.
I agree.Therefore the core should have no destination deployment configuration at all.
What about configuring destination properties such as redeliverydelay etc, where would these be held.With core, connection factories are created directly (new JBossConnectionFactory()), so there is no need for them to exist in JNDI, same for destinations.
Again, where would we set these properties.So, it's the security policy that determines whether users can create, read or write to a queue, the actual queues are created on the fly (if the security config allows it).
what about topics, how would the security work since the user may not know the name of each consumer at deployment time? -
3. Re: Hot Deploy with JBM 2
timfox Jan 7, 2008 6:02 AM (in response to ataylor)"ataylor" wrote:
What about configuring destination properties such as redeliverydelay etc, where would these be held.
Any overrides can be specified on any group of queues using wildcards in the queues.xml file.
what about topics, how would the security work since the user may not know the name of each consumer at deployment time?
Can you elaborate on that? -
4. Re: Hot Deploy with JBM 2
ataylor Jan 7, 2008 6:08 AM (in response to ataylor)its ok, ive ready the other post.