I dabbled with JAXB 2 as you suggested. JAXB 2 looks good but the issue is it generates many classes that won't get persisted. This is not the fault of JAXB, its just due to the nature of the XML we get (we don't need a lot of the data). Instead, I was thinking about using a tool like Castor to populate our domain-specific bean from the XML. If I do it this way, how will servicemix fit into the scheme of things?
Also suppose that I do use JAXB 2 w/ hyperjaxb (the schema-first suggestion). I don't understand where JSR 181 fits into all of this. Isn't this used for Web Services? I thought I would be using an FTP/polling mechanism to retrieve the XML... not sure how JSR 181 is used to make the retrieval of the XML file work. Thanks in advance. -los James.Strachan wrote: > > 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/ > > -- View this message in context: http://www.nabble.com/Would-servicemix-work-with-ftp-xml-integration-tf2376311.html#a6627027 Sent from the ServiceMix - User mailing list archive at Nabble.com.
