Hi, I'll try my best to answer your questions/comments, but if you need more information, please ask.
> One observations these xml beans generated classes do not have > an inbuilt relationship (inheritance tree) which limits reusability. This may have something to do with teh way your schema is constructed. Which schema design pattern are you using? XmlBeans generates types based on this so if you have a bunch of local types you might be just seeing the effect for this. I would like to know would it be a good idea to use these xml beans generated classes as transfer objects or can I create custom classes (transfer objects) extending these generated classes & introduce some business logic in these custom classes. I'm not sure what you mean by 'transfer objects', can you explain that a little further. XmlBeans has a way to introduce logic into the generated classes using the extensions mechanism. More information is available here, http://wiki.apache.org/xmlbeans/ExtensionInterfacesFeature http://wiki.apache.org/xmlbeans/PrePostSetFeature but one thing to note, building is different (AFAIK) and everything can be scomp'ed together checks like null pointer checks for each & every field before fetching and setting values because of inherent nature of the underlying xml elements & attributes. I would think the xmlbeans api handles most of this for you with the isNil methods, also, if the elements are required, calling a validate on the type should let you know if something is not correct. But using a separate transfer objects layer also keeps the client code separate and would not be affected if there are any changes to the underlying WSDL and we can carry out the modifications at a centralised location (i.e. some sort of mapper layer). I like the idea of using the 'mapper layer' to abstract from changes associated with versioning, but without the details or knowing what exactly you mean by transfer objects its hard to know true pros and cons. Hope this helps, -Jacob Danner On 9/13/07, zulu <[EMAIL PROTECTED]> wrote: > > Hi All, > > We have a requirement where in we need to communicate with a web service > WSDL. Currently we are generating set of java classes (using xml beans) out > of this wsdl. > > Our application will be using these java classes to set the data before > calling the web service and also will get data wrapped in these classes. > > We did a proof of concept for the same and everything looks manageable for a > small example but we have around 35 different types of web service calls to > make (to & fro) each with a huge xml payload. > > We do not have much idea on xml beans or java to xml binding and would like > to know what are some of the guidelines best practices to adopt > > One observations these xml beans generated classes do not have > an inbuilt relationship (inheritance tree) which limits reusability. > > I would like to know would it be a good idea to use these xml beans > generated classes as transfer objects or can I create custom classes > (transfer objects) extending these generated > classes & introduce some business logic in these custom classes. > > > Also currently in our code we have to do a lot of checks like null pointer > checks for each & every field before fetching and setting values because of > inherent nature of the underlying xml elements & attributes. > WHat i fear is when we go about creating code for moving data between > application transfer objects & xmlbean generated classes there would lot of > null pointer checks making the code unnecessarily ugly. > But using a separate transfer objects layer also keeps the client code > separate and would not be affected if there are any changes to the > underlying WSDL and we can carry out the modifications at a centralised > location (i.e. some sort of mapper layer). > > Do post your suggestions on the pros & crons of each approach. > > -- > View this message in context: > http://www.nabble.com/evaluating-xmlbeans-and-best-practices-tf4440007.html#a12668083 > Sent from the Xml Beans - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
