Some of you may have already worked with the Petals JMS component.
This connector works in two different modes. In the first one, said provider, the component exposes services. When invoked, these services post messages on a JMS queue or topic. In the second mode, said consumer, Petals listens to JMS queues or topics and propagates JMS messages as Petals messages intended to Petals services.
The Petals JMS connector is not part of the Petals distribution, for the moment. You have to get the source code from our SVN and compile it yourself.
To put it in the distribution, it would need to support the new Petals logging mechanism. Besides, we have many upgrades to perform on this component. However, it works and can be used in some cases.
Here comes the point where I talk about interactions with ActiveMQ (AMQ).
AMQ is pretty nice and easy to use. I think we can say this is one of the key JMS products in the open-source field. However, there are some limitations to know when using it with Petals. And this is not due to Petals.
Petals and JMS servers can interact through the Petals JMS component. To work, this component needs a JNDI. More exactly, JMS queues and topics must be made available through a JNDI server, so that both Petals and AMQ can read and write in them. Unfortunately, AMQ does not provide a real JNDI implementation. This results in a strong limitation: you cannot work with Petals ESB, AMQ and static queues or topics.
There are 3 workarounds:
- Do not use AMQ’s JNDI implementation and use an external one.
- Use dynamic queues or topics. This is a specific mechanism of AMQ. Basically, it consists in choosing dynamicQueues/yourQueue or dynamicTopics/yourTopic as your JMS destination.
- Add a specific property in the JMS client (Petals JMS connector). Currently, the only solution is to patch the component. I have submitted a feature request to give more flexiblity in what we can pass to the initial context.
This information was also added to the documentation of the Petals JMS component.