I think we are mixing up two different requirements - "on-the-wire" SOAP compliance and SAAJ support for developer programming model.
I thought Sanjiva recently said that OM will provide the minimal goal of "on-the-wire" compatibility, which means the SOAP message sent out by Axis2 engine using just OM should be SOAP compliant to be interoperable with other SOAP stacks. If OM itself does not provide such SOAP compliance, I'm not sure if the performance measurements using OM make much sense, if Axis2 is meant to be a SOAP processor. SAAJ is different issue. Axis core need not support SAAJ, and I think we all agree on this. However this might mean that the existing code (clients, handlers, server-side) using SAAJ and JAXRPC model will need porting to Axis2, if the user want to use our OM for its performance. Portability of existing code written for other compliant engines including Axis 1.2 is also important, i feel. Performance is good thing, but we need to balance the costs. IMHO, SOAP engines could provide compatibility and portability just like EJB containers or servlet containers do. User should have fewer criteria such as performance and licensing while evaluating the SOAP stacks, and should not worry about compatibility and portability. - venkat On Tue, 22 Mar 2005 09:50:57 +0530, Ashutosh Shahi <[EMAIL PROTECTED]> wrote: > Hi, > Correct me if I am wrong, but does this mean there is a plan to > remove SOAPEnvelope, SOAPHeader, SOAPBody and other soap specific > classes from org.apache.axis.om? > If yes, then how do u plan to provide a wrapper for soap specific > classes? Do they go in some separate package? Or is it left completely > to the client to create a correct soap message? > > Ashutosh > > > On Tue, 22 Mar 2005 08:19:35 +0600, Srinath Perera <[EMAIL PROTECTED]> wrote: > > > Yes I am truly with option 1. > > > When looking back at the things I feel the same as Dasarath. We could > > > have left out certain changes all together. Currently I feel the > > > architecture is corrupted to a certain extent. If someone goes through > > > the class hierarchies there will be certain places where its not > > > streamlined. > > > I feel what we did with implementing SOAP classes was not suitable.( > > > Not saying it is wrong. A SOAP object hierarchy is a must!. But the > > > way we have implemented the SOAP classes is "too tight" with OM). We > > > should have thought of a looser implementation. Builder checks for > > > SOAP compliancy and everything else that matters should have been > > > more "stream lined". > > > Since we have a lot of work ahead that depends on OM I am ok with any > > > effort to refactor and correct anything with OM right now. > > +1, You know I too happy to make the OM and SOAP classes seperate. My > > view is OM should represents XML (bit relaxed XML without PI's ect) > > and build a layer on the OM for SOAPEnvelope ect .. that do the > > validation ect. > > > > But if OM accepts the responisbility of creating the SOAPEnvelope..ect > > then it is the reposnibility of OM to validate the SOAPEnvelope..ect. > > I belive we discussed and agree on this earlier > > Thanks > > Srinath > > > > > On Mon, 21 Mar 2005 02:38:58 -0800 (PST), Dasarath Weeratunge > > > <[EMAIL PROTECTED]> wrote: > > > > If you are in doubt about how much recent > > > > architectural changes may have affected (or killed) OM > > > > performance please look at the following test results: > > > > > > > > https://svn.apache.org/repos/asf/webservices/axis/trunk/archive/java/scratch/dasarath/om/$1/ > > > > > > > > --Dasarath > > > > > > > > --- Eran Chinthaka <[EMAIL PROTECTED]> wrote: > > > > > Hi all, > > > > > > > > > > This will some relate to the thread "Doubt on Detail > > > > > Element in SOAPFault". > > > > > > > > > > AXIOM was not meant to check the compliance with > > > > > SOAP spec or anything else. > > > > > It will just hold the infoset. The reason behind me > > > > > putting a SAAJ like api > > > > > on top of OM was to provide developer convenience. > > > > > For example, rather than > > > > > saying element.getFirstElement(), developers love to > > > > > use > > > > > envelope.getHeader(). So, that was the intention of > > > > > providing that sort of > > > > > SOAP jargon in to Axiom. This was our initial idea. > > > > > > > > > > But later, some have put some checks in to the AXIOM > > > > > SOAP api. And the > > > > > earlier thread also was asking about this > > > > > validation. > > > > > > > > > > So I have a small question on this. What should we > > > > > have in AXIOM ?? > > > > > > > > > > 1. Shall we "KISS" Axiom, and let it be just a info > > > > > set holder. > > > > > - If this is the case, this will not affect the > > > > > performance, due to > > > > > validation and stuff. And if we make it like this > > > > > how we gonna provide > > > > > validation or do we need to provide validation. Can > > > > > we leave this up to the > > > > > user ? > > > > > 2. Shall we make AXIOM SOAP stuff do validation on > > > > > SOAP 1.1 spec as well. > > > > > - This will definitely affect the performance. > > > > > > > > > > > > > > > IMHO, I prefer option 1, which is basically my > > > > > initial idea as well. > > > > > > > > > > What do you all think about this ? > > > > > > > > > > > > > > > Thanks, > > > > > Eran Chinthaka > > > > > > > > > > > > > > > > > > > > > > > __________________________________________________ > > > > Do You Yahoo!? > > > > Tired of spam? Yahoo! Mail has the best spam protection around > > > > http://mail.yahoo.com > > > > > > > > > > -- > > > Ajith Ranabahu > > > > > >
