What is the format of your messages? Could you pack them into a JBossESB Message, for instance? If so, could you not then write your own custom Action that is deployed within a JBossESB service and can be a recipient for your specialized payload? Your current server would bundle the message into a Message, send it to the ESB using one of the existing transports (JMS is probably a good one) and the ESB service picks it up and processes it. When your Action is triggered, it pulls the message from the Message and does whatever you need.
I don't have control over the 3rd party server. In order to get the messages it will deliver, I have to connect and subscribe to their service. Much the same way you would attach to a JMS Topic, but it IS NOT a JMS compliant server by any means.
Once I get the message, which will be through their API, I plan on converting the payload to XML and placing it in a Message so I can "drop" it on the ESB for further processing.
What I'm trying to avoid is writing a "Standalone" application that serves as the "bridge" between the two products.
I would like to create a "Listener" type of service that runs in the JBossESB. I believe the closest thing I've seen is a "Provider". This "Provider" would be configured through the esb xml files to connect, listen, decode and deliver that 3rd party messages to the ESB.
My question is more about approach. Should I write a standalone bridge or can this be integrated into the ESB. I realize that the pattern here kind of makes the ESB Server a client(s) to another server, so I'm hesitant on this approach as well.
how about to use scheduled listener with customized message composer. Check scheduled_services quickstart for an example.
You can also take a look at using a JCA adapter approach.
"One of the core features of the ESB is its ability to consume messages generated from a JCA inflow adapter. The following pages demonstrate how JCA adapters can be configured to generate message traffic into the ESB."
* Integration of a JMS resource adapter:
* Integration of an email resource adapter