Re: [ebxmlms-develop] Sun WSDP1.2 without jaxm

[Ronald v. K. <rv...@ab...>]

Ng Chi Yuen [Cyng] probeerde het volgende duidelijk te maken op 
25-6-2003 10:36:

>Hi,
>
>  
>
>>Axis saaj compliant (the api), so i think you mean removing the sun
>>reference-implementation of saaj?
>>    
>>
>
>        Actually, the current 1.0 branch can already work with Axis
>(except digital signature). Our thought is to remove Sun's RI of SAAJ.
>
I know, got it running here... but initally i removed all jaxm libs.. 
and then it doesn't work  (it didn't even compile, but I missed that 
part stupid me)
didn't try signatures yet (but you already reported that that doesn't 
work yet)

>
>  
>
>>Or do you realy want to start using the lowlevel axis api of jdom?
>>Personally I wouldn't do that. Just stick with saaj and use the axis
>>implementation. (doesn't axis use jdom?)
>>    
>>
>
>        Axis does not ride on JDOM but just DOM (Xerces). Well, keeping
>SAAJ API is fine for me. The current 1.0 branch is exactly what it is.
>However, I just mean that if there is any modification to packaging,
>simply switching to JDOM is not that difficult because SAAJ is now quite
>now transparent to users. Users just know EbxmlMessage and SAAJ of Axis
>is just an implementation. Of course, the only reason to switch to JDOM
>is for efficiency.
>
I do not realy have a preference..  internally we normally change things 
if it results in more than 5% performance gain, otherwise we don't 
bother (unless it's a real simpel switch) . We've had a situation 
however where we had 4 changes 4% each and we did implement them (16% 
overall is a lot)

>
>  
>
>>Great, on an internal project we currently have thrown all sun http
>>classes overboard and use commons-httpclient  from apache. This gives us
>>better proxy support (including authentication, even NTLM) because the
>>Sun has some issues there, especially with M$ proxies. And
>>http-keepalive, which especially on busy connections, leads to 300%
>>performance gain.
>>    
>>
>
>        This idea inspires me. I don't ever use Apache httpclient but
>I think we would also review whether we use keep-alive feature and
>bypassing Sun's http code. Http.java is now quite ready to add codes
>for adding user authentication, proxy support, and performance tune.
>  
>
I'll look into this a little. What will be important is the whole 
queueing thing. For another server we are running, we have a jms queue 
per destination, with an MDB's that can use a connection from a 
connectionpool (per destination).

<sidenote>
We use jms since many jms servers (at least IBM, Bea and JBoss) 
currently support redeliverytimeouts, timetolive, maximum retries, a 
dead-letter-queue etc. so we did not have to implement anything for 
this. The only issue they do not support, or only partly, is ordered 
delivery within a subset of messages in the same queue.
</sidenote>

>  
>
>>Doesn't axis use jdom and Sun dom4j?.... I'l have a look So if  the sun
>>implementation of saaj is not used anymore we could switch to whatever
>>we want.
>>    
>>
>
>        As said, we ultimate goal should be switching to Axis. However,
>Axis currently has a really "nice" feature. It would serialize the XML
>document in a pretty way by adding indenting white spaces. My colleague
>and I ever trace the source codes and it seems that there is no way to
>call SAAJ method to disable such a "nice" feature. After signing with
>digital signature, the serialization breaks it. This is the reason why
>up to now, I do not yet upload Axis libraries into lib/.
>  
>
Realy??... is this a problem of axis xml-dsig? After reading a 
cannonicalization document  indenting whitespace seems to matter... 
hmm.. is a bug already filed with the axis developers? Where does it go 
wrong? Do you have a class name and a line number?  We  internally want 
to start using xml-dsig as wel with axis so probably run into this as 
well. Maybe a collegue of mine can make a pacht for axis and submit it.

>  
>
>>btw, did you ever have a look at  jxpath.... I you want clean code....e.g.
>>Address address = null;
>>Collection locations = vendor.getLocations();
>>Iterator it = locations.iterator();
>>while (it.hasNext()){
>>    Location location = (Location)it.next();
>>    String zipCode = location.getAddress().getZipCode();
>>    if (zipCode.equals("90210")){
>>      address = location.getAddress();
>>      break;
>>    }
>>}
>>can be written as
>>    Address address = (Address)JXPathContext.newContext(vendor).
>>         getValue("locations[address/zipCode='90210']/address");
>>especially the manipulation of the ebxmlmessage would then be realy
>>clean... just learn the xsd
>>    
>>
>
>        Oh, I don't ever look at JXpath. From the above coding style,
>the code is obviously cleaner. But I wonder if there is any concern,
>e.g., performance degradation (evaluating the expression instead of
>manipulating a DOM tree), or there is a strong dependency to use this extra
>library. Is JXpath quite stable and widely now? Anyway, I am open to this
>and we will discuss.
>  
>
A In real complex documents there is a performance issue, but on some 
tests we did, performance degradation was only relative to this piece of 
code (40%), but if you look at the absolute numbers (or relative to te 
full application) it was marginal.

If you guys have an option to do a performancetest, I'll try to change 
some pieces of the code to use jxpath and we can see. I do not mean we 
(you) should switch to jxpath, I just thought i'd mention it. (it is on 
apache btw and uses jdom)

Ronald