Srinath Perera wrote:
we have it discussedthist earlier (?!) but AFAIR the "optimization" trend won at that time.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
+1 to separation, this will make easier to support SOAP 1.1 and 1.2 with a common abstraction and/or separate sets of classes/interfaces for SOAP 1.1 and 1.2 including SAAJ as a layer that is directly on top of XML Infoset OM and donot need to interfere with other SOAP abstraction layer.
alek
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
-- The best way to predict the future is to invent it - Alan Kay
