Hi,
I have not looked into the SOAP specs in detail but may I suggest a
solution. I'm sure SOAP 1.1 and 1.2 has similar properties and
behaviors even though they are named diffrently. So my guess is we can
have a common model (one of our own) that has both the features and
have two implementations of that set of interfaces for SOAP 1.1 and
1.2 (or whatever comes later even :))
The internal engine works with our model and wouldn't see the diff. 

thoughts ?


On Thu, 3 Mar 2005 11:49:59 +0600, Eran Chinthaka
<[EMAIL PROTECTED]> wrote:
> 
> 
> Hi,
> 
>  
> 
> We implemented a SOAP layer on top of OM using the SOAPBuilder. But it was
> in accordance with SOAP 1.1. But now I think its time to support SOAP 1.2 as
> well. There we have a problem as some of the things are bit different in 1.2
> compared to 1.1. (see here
> http://www.w3.org/TR/2003/REC-soap12-part0-20030624/#L4697)
> 
>  
> 
> For example; SOAP fault element has many difference between these two. 
> 
> And there are some name changes as well. For example actor has changed to
> role. So I have a problem which method to use. Is it getRole() or getActor()
> I should use ? or put both ? 
> 
>  
> 
> When u think about handlers accessing the SOAP message using OM, one might
> write there code to comply with SOAP 1.1 and whilst other with SOAP 1.2. 
> 
>  
> 
> If you put a method like getRole, well that can be used to return actor for
> SOAP 1.1. But is it ok ?
> 
>  
> 
> Plus, there are some specific information available in SOAP faults. In 1.2
> Code and Reason are mandatory and the element hierarchy there is different
> to (of more informative) than SOAP 1.1.
> 
>  
> 
> So how do we support both â.. ??
> 
>  
> 
> Option 1 : Having two SOAP builders for SOAP 1.1 and SOAP 1.2. But then
> handler writers will have to have a big if.. else ..
> 
> Option 2 : Support SOAP 1.2 only and if there is something missing, user
> (handler writer or any other accessing SOAP), must take care of that.
> 
> Option 3 : ââ.. ??
> 
>  
> 
> I'd like to see a very convenient API for user to manipulate the SOAP
> message using OM.
> 
>  
> 
> Comments/ Thoughts ..
> 
>  
> 
>  
> 
> Regards,
> 
> Eran Chinthaka
> 
>  


-- 
Ajith Ranabahu

Reply via email to