helloworld_topic_notifier vs jms_topic

[michaela77]

I am trying to design a publish-subscriber example running on JBoss ESB, so I am going through the quickstarts. What is the difference between these two quick starts, at least in terms of how the subscribers/listeners are working?

What I want to do is have a webservice send a message to the ESB, which publishes it to a topic.

Then I want to have an example subscriber (other people will be writing their own subscribers, this is just an example to point to and demonstrate the capabilities) which will get notified that there is a message on the topic, get the message, and then it will do something with that message.

I'm not sure which quickstarts pertain to my intended design, but I think it's a mix of both.

I think I need the HTTP Gateway quickstart to actually send a message via a webservice to the ESB. Then can it stick it directly on a JMS Topic? Would that be esb aware or unaware?

Then how do I subscribe to the topic? I need it to be durable, but the topic is (I think) ESB Aware, so would that be the jms_topic quickstart and follow how those subscribers work?

[tcunning]

It sounds like you're looking for helloworld_topic_notifier, where a message is sent to a JMS queue and then the ESB outputs the message to a file, a topic, and the console.     You want to look at the notification action in that example, and probably add it to something like publish_as_webservice or webservice_proxy_basic.

In this situation, at least how you've explained it, where the ESB is sending messages to the topic, the topic would probably be ESB unaware, and you'd just write a small client to do the subscription and logging.

[michaela77]

Thanks for the response. I thought I was understanding it, but now I'm not so sure. Here's my setup so far:

Publisher:

     HTTP Gateway which successfully receives a webservice call. It makes a ServiceInvoker call to an action which sticks the message on an ESB queue. As part of that action I have:

                    <target class="NotifyTopics">

                                    <topic jndiName="topic/my_notify_topic"/>

                                </target>

So this sticks the message on a non-ESB topic - at least that is how I understand it to work. I want a durable subscriber to pick up these messages.

I have this Subscriber:

     jms-provider has two buses: topic/my_notify_topic (non-esb) and topic/my_notify_topic_esb (esb)

     for the listeners, the non-esb topic is the gateway. I also define a third listener in the form of HTTP gateway. My action for the service is httprouter which has an endpoint of a webservice I have running on a different server that receives the xml and processes it.

From all the examples I've seen creating subscribers, they are one off pojo classes that set clientId and one other field I can't think of off the top of my head - and these fields are what make it durable. But my Subscriber ESB project doesn't even have a java class - it just has the xml files which define how the service works. And, it all seems to work fine. I can run a test end to end and everything gets passed along correctly. But I need it to be durable. Can I make that happen with what I have now?

Actually now that I think about it, I need to be able to receive the messages regardless of whether my subscribing webservice is running. So I need to handle a failure of the Subscriber ESB trying to pass on the message to the webservice, and still be able to process those messages once the webservice comes back online. Any pointers on where I can look to figure out how to handle that? Or do I need to redesign my services?

[tcunning]

Maybe I'm confused as to what you're trying to do.     You want the ESB to receive a message from a webservice, pass it to a topic - and you also want another ESB service which receives messages from that topic?      The second part I thought was just a standalone subscriber based on your first message.       If you can clarify your design, we can defintely help you out.

[michaela77]

The big overview is: I need to be able to publish a message to a topic, which probably 200 subscribers will be listening to, and they will do <something> with the message once they get it. They need to be durable subscribers, because one of more of them could go offline for a period of time, and need to process the messages when they get back up. I'm writing just one of those subscribers right now, to showcase how it works. That subscriber is going to call a different webservice which will process the message somehow. I need to know how to handle a scenario where the webservice I'm trying to call is down - that seems to be part 2 of the puzzle.

And part one of the puzzle is where the subscribers live and how they are configured. So I guess I thought I needed the subscriber to be deployed on the ESB. I'm not sure how it would work otherwise, how it would be deployed on a different server and then still be connected to the ESB (trying to avoid having to mess with mutual ssl, firewalls, ports, etc). I figured having the subscriber (or all 200 of them, all written by different organizations) installed on the ESB would be the best option.