If you were using JAXB2 to do the marshalling of your XML to POJOs and using JPA to deal with persistence of your POJOS., then we could use the JSR 181 component to write a generic component to do XML persistence using JPA.
What would be ideal would be Schema First ==========
From an XSD, you code generate the POJOs using JAXB2 along with
something like hyperjaxb3 to add the JPA annotations (used in hibernate 3 along with TopLink and OpenJPA) then there'd be POJOs capable of persisting themselves. Or... POJO First =========
From a bunch of JAXB2-enabled POJOS which use the JPA annotations, we
can use the JAXB2 maven plugin to auto-generate the XSD and we should be able to auto-generate the WSDL too Then we should be able to create a JSR 181 based component which allows XML to be submitted or queried over JBI to do the persistence via JPA. On 10/3/06, Philip Dodds <[EMAIL PROTECTED]> wrote:
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. > >
-- James ------- http://radio.weblogs.com/0112098/
