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:[EMAIL PROTECTED]
Sent: Thursday, March 03, 2005 10:30 PM
To: [email protected]
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
