Hi Alph,
your problem seems to really cry for jms. So if you do not absolutely
have to use soap/http for your webservice I advise to do the following.
I am not exactly sure how to do the database polling but you ssound as
if you know how to do it. So I absstract this away. As your service is
completely asynchronous you can also nicely skip the soap part and
instead I would send a jaxb serialized data class.
from("db").to("bean:transfomer").to("jms")
from("jms").transactional().to("bean:servicebean")
So the idea is to poll the database somehow then use a bean to transform
to your data class. If the classs is jaxb annotated it will be
serialized to xml before calling jms. You only have to have the
camel-jaxb jar on the classpath.
So the bean transformer would be defined in spring and has a method like
this:
DataClass transform(WhateverTheFatabasePollingProduces source) {
};
On the service sidde you have a similar bean with:
void service(DataClasss) {
};
Now to achieve the behaviour with the guaranteed deliver and error
handling you require you can set the queue options so it does several
redelivery attempts and then move the message to an error queue if that
fails.
This may sound a bit unusual if you are not experienced with jms but
this iss exactly the case jms is best in.
Christian
Am 19.04.2011 03:32, schrieb alpheratz:
Looking for advice on the best way to tackle the following...
Need a process to:
+ poll a database table for the arrival of a new record
+ transform the record to the XML appropriate for a document-literal SOAP
webservice
+ send to the webservice
All this is relatively easy; here are the issues:
+ the webservice will respond with an immediate communication status
(ok/fail)
+ the service will also respond at some later time with an asynchronous
processing status (ok/fail)
+ outgoing message (n + 1) should only be sent on receipt of the processing
status response for message (n); polling may be paused waiting for this or
it may continue (requiring messages to be buffered, presumably...this is the
easier alternative maybe?)
+ the incoming async response message may never arrive, of course, so
timeout handling will be required
+ the communication status should ideally allow one to distinguish between
transient comms failures and permanent ones. In the case of transient one
should retry while permanent errors should result in the message being
logged
I'm not a COMPLETE neophyte with Camel but I'd appreciate any expert advice
on the best way to structure a solution. Pointers to examples/blogs/etc.
would be great!
Thoughts/suggestions gratefully accepted.
Thanks in advance.
Cheers,
Alph
--
View this message in context:
http://camel.465427.n5.nabble.com/Would-appreciate-advice-on-the-best-way-to-tackle-a-problem-tp4312202p4312202.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
----
http://www.liquid-reality.de
