Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <42280CC9.6090807@cs.indiana.edu>
Date: Fri, 04 Mar 2005 02:22:49 -0500
From: Aleksander Slominski <aslom@cs.indiana.edu>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: axis-dev@ws.apache.org
Subject: Re: [Axis2] SOAP 1.1 and/or 1.2
References: <200503040349.j243mrDm088140@squid.cmb.ac.lk>
In-Reply-To: <200503040349.j243mrDm088140@squid.cmb.ac.lk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Eran Chinthaka wrote:

>Well Alek,
>
>Your suggestion sounds good for me .
>
>I like the notation of setSOAPFragrance(SOAP12)   (nice method name :)
>
it is my creative take on flavors - i was getting tired of WS flavors ;-)

>).
>And if the user is not setting this, he can access the headers using normal
>OM methods.
>  
>
yes - SoapUtil is an utility - you use it only if you need it.

>But still I can't figure out a better way to do this. 
>
>Can we just provide only the SOAP 1.2 methods, and if SOAP 1.1 message
>comes, OM will make sure you get the SOAP 1.2 picture from the information
>you get.
>  
>
yes - but there are small differences - in abstract API message may look 
like (subset of) SOAP 1.2 but you need to account for differences.

and if SOAP 1.1 comes in then response should be SOAP 1.1 as well.

>I think same thing has done in WOM as well.
>  
>
good analogy.

alek

>Thoughts,
>Eran Chinthaka
>
>-----Original Message-----
>From: Aleksander Slominski [mailto:aslom@cs.indiana.edu] 
>Sent: Thursday, March 03, 2005 10:30 PM
>To: axis-dev@ws.apache.org
>Subject: Re: [Axis2] SOAP 1.1 and/or 1.2
>
>Eran Chinthaka wrote:
>
>  
>
>>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.
>>
>>    
>>
>it is easy to carve out common abstractions (or common model as Ajith 
>called it) and typical message manipulation patterns can be shared 
>between SOAP 1.1 and 1.2 - just provide convenient methods to detect 
>version of SOAP and provide implementation of abstract methods.
>
>as you have in OM actual XML of message then handler can access and 
>manipulate SOAP as XML in any way it find fit including SOAP 1.1 or 1.2 
>specific if you have SOAP 1.2 specific requirements (and make sure to 
>reject SOAP 1.1 messages ...).
>
>i have examples in XSUL you can check out - it works like that:
>
>SoapUtil soapUtil = SoapUtil.selectSoapFragrance(incomingDocumentEl, new 
>SoapUtil[]{
>Soap12Util.getInstance(), Soap11Util.getInstance()});
>
>SoapUtil is common abstraction and selectSoapFragrance() will ask set of 
>SOAP implementations (1.1 and 1.2) if they recognize XML document. after 
>you have soapUtil you can use it.
>
>for example one common operation is to generate SOAP fault infoset (that 
>works both for SOAP 1.1 and 1.2):
>
>public abstract XmlElement generateSoapFault(XmlNamespace faultCodeValueNs,
>String faultCodeValueName,
>String reasonTextEnglish,
>Throwable ex)
>
>for details see:
>http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/java/modules/soap_uti
>l/xsul/soap/
>
>anyway that is just one way to do it.
>
>HTH,
>
>alek
>
>  
>
>>Comments/ Thoughts ..
>>
>>Regards,
>>
>>Eran Chinthaka
>>
>>    
>>
>
>
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay