On 3/22/07, Alex_ynr <[EMAIL PROTECTED]> wrote:
Ok, that sounds promising.
Which is the base poller component to extend?
You should take a look at the
org.apache.servicemix.file.FilePollerEndpoint in the servicemix-file
component for an example of this. It extends the
org.apache.servicemix.common.endpoints.PollingEndpoint for the polling
capabilities.
Also, a generic DB component that supported the kind of behaviour I'm
looking for would be quite hard to do since I need to get data from 2 (or
more)tables into one transaction. Generalising this use case would lead to
creating a way to handle this. Maybe I havent looked carefully at the
ServiceMix documentation but I don't think it supports something like that,
i.e. having 2 startpoints , having the data from both accessible within a
"transaction" but only one of them responsible for the flow.
For example, in the case I mentioned, I think it would look something like
this: (btw, I'm not that familiar with ServiceMix so I hope what I'm saying
makes sense)
Similar to the file-binding example in the documentation, instead of having
a single component as the provider (getOrders) we would have something like
getOrders and getOrderItems.
Both poll the DB continuously, but the getOrderItems "messages" stay in the
NMR until the relevant getOrders item has reached it at which point a new
composite message is built from those 2 sets of data (like the complete
order as it would have been in the file in that example) and sent to the
placeOrders component.
You could build a single database poller component and just deploy two
configurations of it. Then it sounds like you'd need to orchestrate
the use of these two so that when getOrderItems messages arrive,
they're held until the getOrders item message arrives and the two are
transformed via XSLT into a single message.
Also, rather than a SELECT Count(*) etc. I think it should be more like
define the query, define the no of rows per event (do we handle 1 at a time
even if there are more? all of them? a specific amount? etc.) and define
which field is the primary key and use that to poll the DB
OK, so we'd need to look closer at your use case, but I think we could
create some base functionality in the database polling component to
make it functional and then build some additional configuration
features on top of that.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Castor - http://castor.org/
