On 5 January 2011 16:25, Cédrick Béler <[email protected]> wrote: > Hi there, > > While doing my experiments with SOAP and friends, I've come to the > conclusion, I'll redo mainly SOAP because previous implementation is linked > to an independent XML representation. I find XMLSupport very nice in design > and well documented so I consider it as a basis for implementing SOAP (to me > it's a really good example of package as they should be). > > 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? > 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. > Thanks in advance, > > Cédrick > > [1] http://download.oracle.com/javase/6/docs/api/javax/xml/soap/ > > -- Best regards, Igor Stasenko AKA sig.
