So, in my scenario, this is the best I can describe it.

I want to deploy a couple of web services to my servicemix instance.  These
will be consumed by a legacy system that already knows how to talk to these
web services.  I want to put these requests into a modified format on a JMS
queue for working and return immediately back to the client (e.g. don't
wait for the JMS listener to process these).

On the JMS side, I expect to go through a few different transforms, one
reading remote data; another converting it into a common jax-b based
structure and then finally sending that JAX-B message to another system for
processing.

That other system will send a request over when it's done indicating that
some data has to go to the first system, which I'm sure will also work fine.

Ideally, I think I want my webservice to process things normally, other
than having a producer that can put message data on to the queue.  Based on
how it's structured, I'd prefer to not have anything in the mix in front or
behind it, but could hear some arguments on why this might be best.  The
service has a single method, with the signature:

public boolean importData(int sourceId, int targetId, String sourceRepo,
String sourceRepoGroup, int dataElementId);

which simply returns true as long as the WS Is up (right now, this just
dumps a message onto a JMS queue).  I can't change the argument structure,
but perhaps it can go in a wrap object; not sure.

After some reading, I thought my best solution would be to use a producer
template, and then the wrapped version.  So I threw this into my
webservice, just to see if i could get it to log messages:

@EndpointInject(uri="log:events")
  ProducerTemplate producer;

and then in the body

producer.sendBody("Received sourceRepo as "+sourceRepo);

Which (I honestly wasn't surprised here) generated a null pointer
exception.  So I guess I can't inject this into my webservice endpoint?

Is this use case sensible?  It's probably not ideal for the ESB, but it
kind of keeps things moving in the webservice with minimal changes.

Thanks!

John

Reply via email to