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(). 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 > > -- Ajith Ranabahu
