I have created a HornetQ Topic with one durable subscriber (clustered Configuration). Node 1 is primary and Node 2 is secondary. Everything is working fine here. Now I want to consume data from the this topic (exampleTopic). I want to create a BPEL process/ java program that will consume data from this HornetQ topic. What are the configurations do I have to do on the weblogic console? This is first time I am using HornetQ so, if any one can give me steps that would be a great help. And What parameter should I use in java program that will connect to HornetQ.
There's been a curious rash of JBoss/BPEL questions over the last week! I think the easiest course of action would be to first get your provider and topic working without any WebLogic or BPEL code involved (use the provider's samples and doc). This ensures you have a working JMS provider. Second, consult with the BPEL doc/newsgroups to see if BPEL itself provides help with arbitrary provider JMS integration - I assume it probably does. And finally third, read the posts from the past week in this newsgroup for further advice.
hornet q comes with a jca adapter. You can deploy this in weblogic. You can use a third party adapter in soa
You can also use the jms adapter provided by oracle. Add required hornet q jars and appropriate connection factory
Just a note:
I've only very rarely seen that a 3rd party adapter is required to integrate a third party JMS provider into WL. Since JCA can be complex and isn't normally required, I recommend using the arguably simpler and certainly far more commonly leveraged approach of direct JMS integration.
Assuming you've already investigated BPEL and found that it doesn't have a JMS integration facility that you can leverage, then the most common solution for making third party JMS available is to place the third party jars in the system classpath in combination with one of the options described in the Interop FAQ (http://docs.oracle.com/cd/E21764_01/web.1111/e13727/interop.htm#JMSPG553).
Another option may be to use WebLogic JMS for messaging. It's often the highest performing, most scalable, and most functional choice.
WebLogic Messaging Team, Technical Lead