You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Paul Fremantle <pz...@gmail.com> on 2007/08/02 13:01:14 UTC
DOOM and SOAPEnvelope
I recently found some parts of DOOM that weren't implemented (I got
TODO exceptions).
I believe these were in implementations of SOAPEnvelope/SOAPBody. I
also had a problem where DOOM couldn't cope with an empty Namespace.
Anyway, my point is this. Surely we shouldn't have two implementations
of the SOAP* interfaces - one for DOOM and one for LLOM? Won't the
code be exactly the same in both cases?
If not, I'm sure we could refactor so it is.
Paul
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] DOOM and SOAPEnvelope
Posted by R J Scheuerle Jr <sc...@us.ibm.com>.
"Paul Fremantle" <pz...@gmail.com> wrote on 08/02/2007 06:01:14 AM:
> I recently found some parts of DOOM that weren't implemented (I got
> TODO exceptions).
>
> I believe these were in implementations of SOAPEnvelope/SOAPBody. I
> also had a problem where DOOM couldn't cope with an empty Namespace.
>
> Anyway, my point is this. Surely we shouldn't have two implementations
> of the SOAP* interfaces - one for DOOM and one for LLOM? Won't the
> code be exactly the same in both cases?
The SOAP implementation objects extend the DOOM or LLOM objects. Thus>
two implementation hierarchies are needed (one for DOOM and one for LLOM).
An alternative approach is to have a single SOAP implementation hierarchy
that
delegates to an OM tree. Then you would have a single SOAP implementation.
However this has a different set of challenges. The main challenge is that
you may have
two objects for each element (e.g. A lightweight SOAPEnvelope object that
delegates to an OMElement).
If you took this approach, I also suggest splitting out the SAAJ code and
using a similar approach.).
SAAJ objects extend (versus delegate) to LLOM objects.
Is there any benefit to moving the SAAJ model to Axiom. The only downside
is that Axis2 would still need
to implement SOAPConnection...but the rest of the code is basically
modelling code.
>
> If not, I'm sure we could refactor so it is.
>
> Paul
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
Rich Scheuerle
IBM Web Services
Apache Axis2 (scheu@apache.org)
512-838-5115 (IBM TL 678-5115)
Re: [AXIS2] DOOM and SOAPEnvelope
Posted by R J Scheuerle Jr <sc...@us.ibm.com>.
"Paul Fremantle" <pz...@gmail.com> wrote on 08/02/2007 06:01:14 AM:
> I recently found some parts of DOOM that weren't implemented (I got
> TODO exceptions).
>
> I believe these were in implementations of SOAPEnvelope/SOAPBody. I
> also had a problem where DOOM couldn't cope with an empty Namespace.
>
> Anyway, my point is this. Surely we shouldn't have two implementations
> of the SOAP* interfaces - one for DOOM and one for LLOM? Won't the
> code be exactly the same in both cases?
The SOAP implementation objects extend the DOOM or LLOM objects. Thus>
two implementation hierarchies are needed (one for DOOM and one for LLOM).
An alternative approach is to have a single SOAP implementation hierarchy
that
delegates to an OM tree. Then you would have a single SOAP implementation.
However this has a different set of challenges. The main challenge is that
you may have
two objects for each element (e.g. A lightweight SOAPEnvelope object that
delegates to an OMElement).
If you took this approach, I also suggest splitting out the SAAJ code and
using a similar approach.).
SAAJ objects extend (versus delegate) to LLOM objects.
Is there any benefit to moving the SAAJ model to Axiom. The only downside
is that Axis2 would still need
to implement SOAPConnection...but the rest of the code is basically
modelling code.
>
> If not, I'm sure we could refactor so it is.
>
> Paul
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
Rich Scheuerle
IBM Web Services
Apache Axis2 (scheu@apache.org)
512-838-5115 (IBM TL 678-5115)