activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Fernandez <joe.fernan...@ttmsolutions.com>
Subject Re: Add simple service registry to ActiveMQ
Date Thu, 23 Oct 2008 14:45:09 GMT

Re the DS, you wouldn't have to restrict yourself to Java objects. Sounds
like all you need in the DS is some sort of entry that can be used to map a
service or component name to queue name.  

Joe



Maarten_D wrote:
> 
> Hi Matthew & Joe,
> 
> Thanks for the tips. I looked into ZeroConf as well, but that feature of
> ActiveMQ has almost no documentation, and the project that it relies on,
> jmDNS, has literally no documentation that I could find. I'd rather go
> with something that has a little more info about it out there.
> 
> A central DS seems like a good option, especially because JNDI is fairly
> easy to work with. The only downside would be that binding Java objects to
> be discovered basically makes the whole system Java only. As one of our
> components is an MS Exchange plugin, that would be a problem.
> 
> I'm actually having a hard time figuring out what ServiceMix uses as its
> service registry. Anyone know?
> 
> Regards,
> Maarten
> 
> 
> 
> Joe Fernandez wrote:
>> 
>> What about employing a central LDAP directory service like ApacheDS? 
>> 
>> Your service providers would dynamically bind and unbind their services
>> to and from the DS. The service consumers then use the DS to lookup the
>> services. You can probably do all this relatively easily via the JNDI as
>> long as the objects you bind to the DS are Referenceable or
>> Serializeable.  
>> 
>> Here's an example of how to bind an ActiveMQConnectionFactory, which does
>> implement Referenceable 
>> 
>>  Context ctx = new InitialContext();                              
>>  ActiveMQConnectionFactory factory1 = new ActiveMQConnectionFactory();
>>  factory1.setBrokerURL("tcp://localhost:61683");
>>  ctx.bind("cn=factory1", factory1); 
>> 
>> and here's an example of looking it up
>> 
>> Context ctx = new InitialContext();                                       
>> ActiveMQConnectionFactory factory1 = (ActiveMQConnectionFactory)
>> ctx.lookup("cn=factory1");
>> System.out.println(factory1.getBrokerURL());
>> 
>> Here are the corresponding properties that you'd use to point the above
>> code to the LDAP DS
>> 
>> java.naming.factory.initial = com.sun.jndi.ldap.LdapCtxFactory
>> java.naming.provider.url=ldap://192.168.1.148:10389/ou=adminobjects,o=ActiveMQ,dc=example,dc=com
>> java.naming.security.credentials=secret
>> java.naming.security.principal=uid=admin,ou=system
>>  
>> Those properties can be in a local jndi.properties file our you could
>> pass them via a hashtable to the  InitialContext constructor. 
>> 
>> Hope this helps
>> 
>> Joe
>> http://www.ttmsolutions.com - get a free ActiveMQ user guide
>> 
>> 
>> 
>> Maarten_D wrote:
>>> 
>>> Hi,
>>> 
>>> I'm developing a distributed system that has four types of components
>>> that need to work together. At first I just had a simple configuration
>>> with 1 component of each type, working and wired together using
>>> ActiveMQ. I now want to expand the system to include multiple components
>>> of each type and support dynamic adding/removing of components. Since
>>> the exact topography of the component network can't be known in advance,
>>> I need some sort of component discovery mechanism.
>>> 
>>> Let me give a concrete example:
>>> Component A generates messages that need to be processed by component B.
>>> Right now, component A knows where to find component B because it has
>>> the queue name hardwired into its configuration. I want to develop a
>>> system where component A and B can both be started unawares of each
>>> other, and component B can then somehow discover the queue that
>>> component A puts its messages on, and start consuming. That way I could
>>> deploy 100 instances of component B, and not have to do any
>>> configuration: they would all know where to find work.
>>> 
>>> So now my question: what is the best way to add this sort of service
>>> discovery mechanism to ActiveMQ? I've looked at ServiceMix, which
>>> supports service discovery, but moving to a full-blown ESB just for one
>>> feature seems like overkill. I've also looked at jUDDI, but that seems
>>> to be very web services specific. Of course it would be fairly easy to
>>> implement a trivial service discovery mechanism using just JMS, but I
>>> don't want to do the work unless I really have to.
>>> 
>>> Does anyone know of a good solution to this problem?
>>> 
>>> Regards,
>>> Maarten
>>> 
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Add-simple-service-registry-to-ActiveMQ-tp20129668p20132479.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Mime
View raw message