But there come the design question. To me SOAP elements are particular XMLDocument and XMLElement. Indeed, I found the interfaces of java 6 which was quite what I have in mind [1].
I think the main problem (to me) is that XMLElement in Smalltalk has an inst var containing all children node. I think this is different in java. The consequence is to model SOAPEnvelope (subclass of XMLElement), I can't really add a body and header field respectively for the SOAPHeader and SOAPBody object. Instead I should put them in the children collection node. Is it a good practice ? Do I use a factory to ensure there's at least one and only one body and eventually a header ? Any other pattern for such situations ?
hmm.. the existence if separate class for each of xml elements doesn't automatically means that it can validate a SOAP document that it is well formed, isn't?
yes sure, but I thought it will help...
Or would you avoid to subclass ?
Secondary question: As I found this java API, I got really tempted to use a similar organization. It it authorized ? I couldn't really parse the license file :)
As to me, i'd better leave the xml domain as soon as possible by validating it and then parsing its elements into something, which is reification of actual SOAP query/response model , without trying to resemble an xml dom tree.
yes I get your point, I'll get something simpler first. Thx
Thanks in advance,
Cédrick
[1] http://download.oracle.com/javase/6/docs/api/javax/xml/soap/
-- Best regards, Igor Stasenko AKA sig.