Another Design Question - SOAP and WSDL - Subclass or not XMLElement

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 ?
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 :)

Thanks in advance,

Cédrick

[1] http://download.oracle.com/javase/6/docs/api/javax/xml/soap/

On 5 January 2011 16:25, Cédrick Béler <[hidden email]> 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.

>> 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...


yes I get your point, I'll get something simpler first.

Thx

---- On Wed, 05 Jan 2011 07:25:24 -0800 Cédrick Béler  wrote ----

I don't know much about SOAP, but you could map special SOAP elements to custom XMLElement subclasses like this:
XMLPluggableElementFactory new
    handleElement: 'Envelope' namespaceURI: 'http://www.w3.org/2003/05/soap-envelope' withClass: SOAPEnvelope;
    handleElement: 'Header' namespaceURI: 'http://www.w3.org/2003/05/soap-envelope' withClass: SOAPHeader;
    handleElement: 'Body' namespaceURI: 'http://www.w3.org/2003/05/soap-envelope' withClass: SOAPBody;
...

Note that according to the spec, the prefixes used are arbitrary, so you can't assume a "soap:" prefix will be present and instead must look for the SOAP namespace URI explicitly. You probably also ought to avoid repeating it everywhere, maybe using an accessor like #soapURI when you need it.

Anyway, next, add these methods to SOAPEnvelope or whatever you have decided to call it:

header
^ self elementAt: 'Header' namespaceURI:'http://www.w3.org/2003/05/soap-envelope' 

body
^ self elementAt: 'Body' namespaceURI:'http://www.w3.org/2003/05/soap-envelope'

and assuming the "Envelope" element has child elements named "Header" and "Body", those accessor messages will return them, and because of how you configured the factory, they should be instances of SOAPHeader and SOAPBody respectively. If they aren't present, then those methods will return nil (use the #elementAt:namespaceURI:ifAbsent: form if you want different behavior).

>Cédrick
>
>[1] http://download.oracle.com/javase/6/docs/api/javax/xml/soap/ 
>
>