axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eran Chinthaka" <chinth...@opensource.lk>
Subject RE: [Axis2] SOAP 1.1 and/or 1.2
Date Fri, 04 Mar 2005 03:42:19 GMT
Well Alek,

Your suggestion sounds good for me .

I like the notation of setSOAPFragrance(SOAP12)   (nice method name :)).
And if the user is not setting this, he can access the headers using normal
OM methods.

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.

I think same thing has done in WOM as well.

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





Mime
View raw message