ActiveMQ JNDI support only for testing?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

ActiveMQ JNDI support only for testing?

janylj
Hello,

I tried ActiveMQ JNDI support. It seems to me only for testing, because the administrative objects are specified in the jndi.properties of client machine. There is no centralized place to manage the ConnectionFactory or Destination. And we could not control who could access them.

Is my understanding correct or I miss something? Thank you very much.
Reply | Threaded
Open this post in threaded view
|

Re: ActiveMQ JNDI support only for testing?

Antsa
janylj wrote
I tried ActiveMQ JNDI support. It seems to me only for testing, because the administrative objects are specified in the jndi.properties of client machine. There is no centralized place to manage the ConnectionFactory or Destination. And we could not control who could access them.

Is my understanding correct or I miss something? Thank you very much.
Did you find a solution?  Is it not possible to get a client to find destinations published in JNDI on the server hosting the broker?
Antony
Reply | Threaded
Open this post in threaded view
|

Re: ActiveMQ JNDI support only for testing?

huntc
I'm curious as to what is trying to be achieved here. Could you please explain why it is useful to perform a naming/directory lookup for a queue or topic name?

My recommendation is to have well known queue and topic names that are global in scope. For example, use the java convention to specify a queue or topic name. Here's one of mine:

com.classactionpl.flights.javaTopic
Reply | Threaded
Open this post in threaded view
|

Re: ActiveMQ JNDI support only for testing?

James Strachan-2
In reply to this post by janylj
2009/2/10 janylj <[hidden email]>:
>
> Hello,
>
> I tried ActiveMQ JNDI support. It seems to me only for testing, because the
> administrative objects are specified in the jndi.properties of client
> machine. There is no centralized place to manage the ConnectionFactory or
> Destination. And we could not control who could access them.
>
> Is my understanding correct or I miss something? Thank you very much.

You can use any JNDI provider you want. If you really want to store
the topic and queue objects in some remote JNDI server go right ahead,
noone is stopping you.

However the ActiveMQ JNDI provider is intended to avoid dependency on
some remote JNDI server and so by *design* it uses a local client side
configuration. This is perfectly fine for production use too :)

Another approach is using Spring to avoid depending on a remote,
distributed JNDI provider. But if you really wanna use a distributed
JNDI provider just pick one you want and put the ActiveMQ administered
objects (queues, topics and connection factories) in there. Pretty
much all J2EE containers come with some remote JNDI server
implementation.

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/
Reply | Threaded
Open this post in threaded view
|

Re: ActiveMQ JNDI support only for testing?

janylj
In reply to this post by huntc
I was trying to have a centralized repository of destinations and ConnectionFactory. I could use a uniform namespace for destination to avoid conflicting. However, I don't want to allow users creating destination or ConnectionFactory on the fly. I would like them accessing the broker only through administrative objects.

Because my clients are not running inside J2EE container, I am using LDAP for JNDI. I wish ActiveMQ has a built JNDI server in the broker side. Therefore, I don't have to deploy another LDAP server and worry about its HA solution and other topics that we have already invested in the broker side.

Thank you.

huntc wrote
I'm curious as to what is trying to be achieved here. Could you please explain why it is useful to perform a naming/directory lookup for a queue or topic name?

My recommendation is to have well known queue and topic names that are global in scope. For example, use the java convention to specify a queue or topic name. Here's one of mine:

com.classactionpl.flights.javaTopic
Reply | Threaded
Open this post in threaded view
|

Re: ActiveMQ JNDI support only for testing?

James Strachan-2
2009/3/17 janylj <[hidden email]>:

>
> I was trying to have a centralized repository of destinations and
> ConnectionFactory. I could use a uniform namespace for destination to avoid
> conflicting. However, I don't want to allow users creating destination or
> ConnectionFactory on the fly. I would like them accessing the broker only
> through administrative objects.
>
> Because my clients are not running inside J2EE container, I am using LDAP
> for JNDI. I wish ActiveMQ has a built JNDI server in the broker side.
> Therefore, I don't have to deploy another LDAP server and worry about its HA
> solution and other topics that we have already invested in the broker side.

A message broker is kinda different from a HA LDAP server - however
you can just deploy Apache Directory Server in the same JVM as the
broker if you like...

http://directory.apache.org/

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/
Reply | Threaded
Open this post in threaded view
|

Re: ActiveMQ JNDI support only for testing?

janylj
Thanks James for a great suggestion of Apache Directory Server. I didn't know that Apache Directory Server could be deployed in the same JVM as ActiveMQ broker.

Do you happen to know whether Apache Directory Server have similar failover url as ActiveMQ? For example, we have a pair of HA broker (A and AFailover). If A goes down, the JMS client would automatically re-connect to AFailover through failover url. Because Apache Directory Server is deployed in the same JVM of A, A goes down, the JNDI of A also goes down. Can JNDI be automatically failed over to AFailover?

Thanks again.

James.Strachan wrote
2009/3/17 janylj <janylj@gmail.com>:
>
> I was trying to have a centralized repository of destinations and
> ConnectionFactory. I could use a uniform namespace for destination to avoid
> conflicting. However, I don't want to allow users creating destination or
> ConnectionFactory on the fly. I would like them accessing the broker only
> through administrative objects.
>
> Because my clients are not running inside J2EE container, I am using LDAP
> for JNDI. I wish ActiveMQ has a built JNDI server in the broker side.
> Therefore, I don't have to deploy another LDAP server and worry about its HA
> solution and other topics that we have already invested in the broker side.

A message broker is kinda different from a HA LDAP server - however
you can just deploy Apache Directory Server in the same JVM as the
broker if you like...

http://directory.apache.org/

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/
Reply | Threaded
Open this post in threaded view
|

Re: ActiveMQ JNDI support only for testing?

James Strachan-2
Thats a question for the Apache Directory user lists I'm afraid

2009/3/17 janylj <[hidden email]>:

>
> Thanks James for a great suggestion of Apache Directory Server. I didn't know
> that Apache Directory Server could be deployed in the same JVM as ActiveMQ
> broker.
>
> Do you happen to know whether Apache Directory Server have similar failover
> url as ActiveMQ? For example, we have a pair of HA broker (A and AFailover).
> If A goes down, the JMS client would automatically re-connect to AFailover
> through failover url. Because Apache Directory Server is deployed in the
> same JVM of A, A goes down, the JNDI of A also goes down. Can JNDI be
> automatically failed over to AFailover?
>
> Thanks again.
>
>
> James.Strachan wrote:
>>
>> 2009/3/17 janylj <[hidden email]>:
>>>
>>> I was trying to have a centralized repository of destinations and
>>> ConnectionFactory. I could use a uniform namespace for destination to
>>> avoid
>>> conflicting. However, I don't want to allow users creating destination or
>>> ConnectionFactory on the fly. I would like them accessing the broker only
>>> through administrative objects.
>>>
>>> Because my clients are not running inside J2EE container, I am using LDAP
>>> for JNDI. I wish ActiveMQ has a built JNDI server in the broker side.
>>> Therefore, I don't have to deploy another LDAP server and worry about its
>>> HA
>>> solution and other topics that we have already invested in the broker
>>> side.
>>
>> A message broker is kinda different from a HA LDAP server - however
>> you can just deploy Apache Directory Server in the same JVM as the
>> broker if you like...
>>
>> http://directory.apache.org/
>>
>> --
>> James
>> -------
>> http://macstrac.blogspot.com/
>>
>> Open Source Integration
>> http://fusesource.com/
>>
>>
>
> --
> View this message in context: http://www.nabble.com/ActiveMQ-JNDI-support-only-for-testing--tp21925743p22564448.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>



--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/
Reply | Threaded
Open this post in threaded view
|

Re: ActiveMQ JNDI support only for testing?

Antsa
In reply to this post by huntc
huntc wrote
I'm curious as to what is trying to be achieved here. Could you please explain why it is useful to perform a naming/directory lookup for a queue or topic name?
My use case is probably due to my newbie status with JMS.  Session.createTopic javadocs imply that normal JMS usage would rarely require this and I felt it implied that it was not really the way to do things.  I was therefore looking at generic ways to create Destination objects in the client side.

My solution for the moment is to use Spring's JmsTemplate class which takes String destinationName and then uses the configured destinationResolver to get the object.

Antony
Reply | Threaded
Open this post in threaded view
|

Re: ActiveMQ JNDI support only for testing?

huntc
In reply to this post by janylj
janylj wrote
I was trying to have a centralized repository of destinations and ConnectionFactory. I could use a uniform namespace for destination to avoid conflicting. However, I don't want to allow users creating destination or ConnectionFactory on the fly. I would like them accessing the broker only through administrative objects.
I believe you are going about this the wrong way. What you really want is topic/queue authorisation i.e. only let certain authenticated users do certain things within the broker.

You might find my blog entry on securing ActiveMQ useful. Authorisation is covered.

http://christopherhunt-software.blogspot.com/2009/03/mutual-ssl-authentication-and-ldap.html
Reply | Threaded
Open this post in threaded view
|

Re: ActiveMQ JNDI support only for testing?

James Strachan-2
In reply to this post by Antsa
2009/3/18 Antsa <[hidden email]>:

>
>
> huntc wrote:
>>
>> I'm curious as to what is trying to be achieved here. Could you please
>> explain why it is useful to perform a naming/directory lookup for a queue
>> or topic name?
>>
> My use case is probably due to my newbie status with JMS.
> Session.createTopic javadocs imply that normal JMS usage would rarely
> require this and I felt it implied that it was not really the way to do
> things.  I was therefore looking at generic ways to create Destination
> objects in the client side.
>
> My solution for the moment is to use Spring's JmsTemplate class which takes
> String destinationName and then uses the configured destinationResolver to
> get the object.

Than sounds fine to me.

I think some of the motivation since J2EE came along of putting all
your resources (connections, destinations etc) into JNDI was so that a
single deployment unit can be used in dev, testing, production without
being changed - yet you'll be using different database/broker servers
in each environment. Folks could, if they want, use different
topic/queue names in dev to production.

Though given how easy it is to create topics/queues with ActiveMQ I'd
recommend just using the correct names of queue/topic you want to use
in production everywhere - then just having one or more brokers for
each environment. i.e. the only real thing that changes between
dev/test/production for ActiveMQ is the broker connection URL. This
then avoids having loads of double indirections and things that could
go wrong (e.g. remote JNDI servers - then configuring on both the
client and on the JNDI server the mapping between JNDI names to
topic/queue names - which are super easy to get wrong causing loads of
wasted time head scratching).

In practice I've found putting JMS destinations into a remote JNDI
server to be nothing but loads of hard work for no actual gain.

Using spring's property resolving mechanism seems a reasonable
solution so that this URL (and the database connection URL you'll
probably be using too) can be changed in testing & production.

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/
Reply | Threaded
Open this post in threaded view
|

Re: ActiveMQ JNDI support only for testing?

janylj
In reply to this post by huntc
Hello Huntc,

I read your blog especially the Authorisation part. I think we are talking about the same thing. The LDAP server I set up also uses ACI to grant or limit the access to specific topic/queue.

I guess this discussion is mainly about whether ActiveMQ has an embedded JNDI provider for centralized management. Because the LDAP server I have to set up is exclusive for ActiveMQ, however, the availability of LDAP server is separate from ActiveMQ. In other words, if LDAP says you could use this queue, you still could not use the queue if ActiveMQ broker is down. Vice versa, if LDAP server is down, although all the resources are available in the JMS broker, you still could not uses any of them.

Lijun

huntc wrote
janylj wrote
I was trying to have a centralized repository of destinations and ConnectionFactory. I could use a uniform namespace for destination to avoid conflicting. However, I don't want to allow users creating destination or ConnectionFactory on the fly. I would like them accessing the broker only through administrative objects.
I believe you are going about this the wrong way. What you really want is topic/queue authorisation i.e. only let certain authenticated users do certain things within the broker.

You might find my blog entry on securing ActiveMQ useful. Authorisation is covered.

http://christopherhunt-software.blogspot.com/2009/03/mutual-ssl-authentication-and-ldap.html
Reply | Threaded
Open this post in threaded view
|

Re: ActiveMQ JNDI support only for testing?

djencks
I'm really mystified by why you want to rely on remote ldap to look up  
a connection factory or destinations.  I don't think you've thought  
through what information needs to be distributed where by what means  
and I think you are going towards a much harder to administer  
heavyweight solution than you need.

For connection factories:

ldap:  you need to tell each client where the ldap server is.

amq properties file: you need to tell each client the broker url to use

This is the same amount of information... but with the properties file  
you don't need an ldap server.

Furthermore, IMO the ldap solution won't really work except for  
clients that are small enough to not need connection pooling.  Even  
for implementations that might be able to export a connection pooling  
connection factory from remote ldap, I can't imagine that you'd want  
the pooling configuration anywhere but in the application that needs  
the pooling.

For destinations with security:

You need broker side authorization anyway, since any client can just  
create a connection factory and destinations without ldap anyway.  So  
what good does it do to set up the destinations in ldap?

I'm not trying to tell you what you should or shouldn't do, but I'd  
like to understand how ldap actually meets your needs... and not  
getting it.

thanks
david jencks

On Mar 18, 2009, at 9:56 AM, janylj wrote:

>
> Hello Huntc,
>
> I read your blog especially the Authorisation part. I think we are  
> talking
> about the same thing. The LDAP server I set up also uses ACI to  
> grant or
> limit the access to specific topic/queue.
>
> I guess this discussion is mainly about whether ActiveMQ has an  
> embedded
> JNDI provider for centralized management. Because the LDAP server I  
> have to
> set up is exclusive for ActiveMQ, however, the availability of LDAP  
> server
> is separate from ActiveMQ. In other words, if LDAP says you could  
> use this
> queue, you still could not use the queue if ActiveMQ broker is down.  
> Vice
> versa, if LDAP server is down, although all the resources are  
> available in
> the JMS broker, you still could not uses any of them.
>
> Lijun
>
>
> huntc wrote:
>>
>>
>> janylj wrote:
>>>
>>> I was trying to have a centralized repository of destinations and
>>> ConnectionFactory. I could use a uniform namespace for destination  
>>> to
>>> avoid conflicting. However, I don't want to allow users creating
>>> destination or ConnectionFactory on the fly. I would like them  
>>> accessing
>>> the broker only through administrative objects.
>>>
>>
>> I believe you are going about this the wrong way. What you really  
>> want is
>> topic/queue authorisation i.e. only let certain authenticated users  
>> do
>> certain things within the broker.
>>
>> You might find my blog entry on securing ActiveMQ useful.  
>> Authorisation is
>> covered.
>>
>> http://christopherhunt-software.blogspot.com/2009/03/mutual-ssl-authentication-and-ldap.html
>>
>>
>
> --
> View this message in context: http://www.nabble.com/ActiveMQ-JNDI-support-only-for-testing--tp21925743p22583570.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>