There are a couple of approaches - You could write a new component to handle your persistence - this would give you full flexiblity in your implementation and that new component would have your hibernate code in place. This would in essence be a Service Engine implementation, if you put your code in here you could feasibly put the transformation logic (Java POJO mapping) in your service units (since these can contain code) and therefore you would be able to "re-use" your persistence mapping different XML documents in each Service Unit.
The other - and perhaps cleaner - way would be to write a JSR181 Service Unit which maps a "standard" XML document with represents your POJO Hibernate Model from an XML document to your POJO's in this case your JSR181 Service Unit would be a POJO and have the hibernate code either in it - or included as a JAR. Then you could use the servicemix-saxon service engine or the older lightweight transformation engine to transform the incoming XML to your "standard" XML document for your JSR181 Service Unit. These could be deployed in another Service Unit and thus adding new mappings would require mapping the external XML to the internal XML. Just some thoughts :) P On 10/3/06, moraleslos <[EMAIL PROTECTED]> wrote:
Thanks for the response. Wrapping my persistence code as a JBI component? Currently we are using Hibernate for persistence. Basically the data we extract from the external XML file using SAX parser gets put into a POJO which we then have hibernate persist into our database. How will I refactor/recode this into JBI? I'm not familiar with JBI/ESB/.. but I did read about it through the Servicemix docs but assume it was used for communication between components rather than for persistence... Thanks in advance. -los James.Strachan wrote: > > On 10/3/06, moraleslos wrote: >> Hi, >> I'm new to Servicemix and the concept of ESB/JBI in general. Currently >> I'm >> evaluating ways to integrate various data sources that we use for our >> product. Instead of developing specific integration modules for each >> data >> source, I would like to consolidate all of the data sources being >> imported >> into some sort of integration layer. Hence I came upon ESB and >> Servicemix. >> >> Now, if I continue with the ESB/Servicemix route, I want to make sure >> that >> I'm doing the right thing. I would like to integrate one data source >> first >> before moving along with the others. This external datasource is a >> vendor-specific XML file. Currently we ftp this XML file onto our >> server, >> read/extract contents with a SAX Parser, and store data into our >> database. >> This is runned as a daemon process (e.g. polls for XML files every day). >> For a scenario such as this, can Servicemix/ESB handle this process more >> elegantly? I'm looking at the long term since many of our external data >> sources will be similar to the process described above. Thanks in >> advance! > > Sounds like a good fit for ServiceMix which already has a whole host > of components for doing things like this. The only thing you may want > to do is wrap up your current persistence code as a JBI component so > that you can save a blob of XML however you like in your database; > other than that the rest of the things you describe are generic JBI > services/components. > > -- > > James > ------- > http://radio.weblogs.com/0112098/ > > -- View this message in context: http://www.nabble.com/Would-servicemix-work-with-ftp-xml-integration-tf2376311.html#a6621031 Sent from the ServiceMix - User mailing list archive at Nabble.com.
