Eran Chinthaka wrote:

Well Ajith,

IMO, this abstraction will give you something else, which you have never
expected.

For example, we have role and actor. How do u name the method to get that.
Is it getRole() or getActor() or getXXX().


probably using SOAP 1.2 terminology is the best choice as it is a standard.

this is with assumption that over time SOAP 1.2 will completely phase out SOAP 1.1

alek

Well IMHO, this abstraction will definitely lose the point of providing SOAP
specific OM. Will some one use the getXXX() method to get the actor ???

Thoughts,
Eran Chinthaka



-----Original Message-----
From: Ajith Ranabahu [mailto:[EMAIL PROTECTED] Sent: Thursday, March 03, 2005 5:40 PM
To: [email protected]; [EMAIL PROTECTED]
Subject: Re: [Axis2] SOAP 1.1 and/or 1.2


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










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



Reply via email to