Re: [servicemix-user] Re: JDBC Component?

Tue, 25 Oct 2005 10:45:14 -0700

I have been successful thus far with the following flow.

    QuartzTimer -> XSQL query -> Transform -> Trace

My next goal is to implement this:

    QuartzTimer -> XSQL query -> Transform -> XSQL update
                                                                |-> Trace

Would anyone happen to have an example of how to compose the XSQL update request? I have found some documentation on xsql:update-request, but am not sure how to pass the data for update in the ServiceMix context.

Thanks,
Matt

On 10/24/05, George Gastaldi <[EMAIL PROTECTED]> wrote:
You could try the following:
 
Using a RobustInOnly Exchange, configure the following path:
 
XSQL -> JMS Topic
          |->  XSLT -> XSQL
 
The first XSQL component fetches the rows from the database, the XSLT component transforms it to another XSQL document and the third XSQL component updates the rows.
 
I guess this is kinda nice, any bad points ?

 -----Original Message-----
From: Matt DeHoust [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 24, 2005 3:02 PM
To: [email protected]
Subject: Re: [servicemix-user] Re: JDBC Component?

In general I prefer to use the simplest solution. The component should be able to poll and update the database. The use case goes something like this. As enterprise user information is updated or added in the system of record (an RDBMS table), that information along with some basic information from the HR system needs to be made available to components that know how to provision users in other systems in the enterprise. The information required can be obtained via a SQL query. New and updated information is marked using a column in the "user" table. Once the user information is retrieved, the same column must be updated to indicate the user information has been received. I'd like to poll the database for user changes and update the flag once the information has been successfully placed on a JMS topic. Provisioning components will subscribe to the topic and do their thing as the information becomes available.

Here are my thoughts on the possibilities you mentioned.

1. XSQL
I have not been able to find much documentation on this technology. If there is a working example out there, I'd be interested in trying it.

2. XSLT
I'd rather not place the queries here. It would be much cleaner to have a database aware component seed the bus and another component perform any XSLT transformations if necessary. I prefer separating those concerns.

3. Groovy
I like Groovy, it just doesn't feel right for this solution. I'd use it in lieu of another solution.

4. JAXB/EJB 3/Hibernate or SDO
I am a big fan of Hibernate. I may choose to leverage it if I implement a POJO solution. The others seem to have promise as general component offerings in ServiceMix, but probably will not be ready within my time frame.

5. OpenAdaptor
I have some experience with OpenAdaptor. Although it works (and there's a lot to be said for something that works), the current implementation does not fit well within my development environment. For example, the dependency on a properties file to configure all components makes it hard to test. I much prefer the IoC paradigm. Perhaps oa3 will adopt such a strategy. I'd be more open to integrating ServiceMix with Mule, which also provides a polling JDBC component.

What do you think would be the most fruitful direction for me to take?

Thanks,
Matt

On 10/24/05, jstrachan <[EMAIL PROTECTED] > wrote:
Matt DeHoust wrote:
> Hello,
>
> I have a situation where changes to data in a relational database table
> need to propagate to other systems with some business
> rules/transformations along the way. I have been unable to find any
> examples in ServiceMix where components access a database via JDBC (or
> Hibernate, etc.). I am new to ESB, so my conceptual understanding is
> still forming. Can I use ServiceMix to put the messages onto the ESB if
> they originate in a relational database? I realize I can implement a
> POJO to access the database, but I'm wondering if there's a general
> solution available in ServiceMix.

Right now there's the XSQL component which can be used to query/poll
databases turning results into XML and invoking them into the ESB to be
processed. We've also go the XSLT component which if you're using Xalan
it has some simple SQL tags inside.

Finally if you're using a Groovy script you can use Groovy SQL to query
from the database.

However we don't yet have a general purpose XML <-> SQL component.

FWIW what I'd really like is to use JAXB2 to auto-generate the POJOs
from an XSD/WSDL; then use something like hyperjaxb (or something like
it preferably for EJB 3 persistence the kinda JSR for hibernate-like
persistence engines). Then we'd have a good way to go from any XSD into
a good relational database model efficiently - using nice typed POJOs
(the most efficient representation for typed XML) and using all the
object-relational mapping features of tools like hibernate & toplink.

Another option is to create an SDO based component which polls the
database using some SQL mechanism, turning the results into an SDO which
knows how to turn itself into XML and back again etc.

Finally, we could integrate OpenAdaptor which has something similar to
it ( http://openadaptor.org).

Which particular solution seems most appropriate to your needs?

--

James
-------
http://radio.weblogs.com/0112098/



Reply via email to