Just a quick couple of points: There are a LOT of changes happening in web services threse days, including that SwA (Soap with Attachments) is formally replaced with MTOM at the same time that WS-I 1.1 came out. Ditto that DIME is also nogo in SOAP 1.2 and WS-I 1.1. Plus, last fall, the XML protocol group published a binary capability called XOP. JBoss is working on replacing Apache Axis with their own stack. They have a good wiki on the general subject, esp. since they are working toward J2EE 5.0: http://www.jboss.org/wiki/Wiki.jsp?page=JBossWS Apache Axis 1.2 is much more robust than 1.1, and 1.2 was specifically targeted to deliver WS-I 1.0 conformance. Axis 1.2 supports wrapped/doc/literal, which seems to improve one's chances to get interoperability with .Net. (of course, you may not care.) It certainly gets you out of the traditional java -> XML serialization problems that appear in (e.g.) jax-rpc. including that wrapped/doc/literal is a much smaller footprint over the wire than fully specified java package.class naming conventions.
fyi - b --- Chris Duck <[EMAIL PROTECTED]> wrote: > I have been doing some research on SOAP > implementations and came across > this link > http://www.sosnoski.com/presents/cleansoap/results.html > with > some speed comparisons. It does not include Apache > SOAP, but does > include Axis (in several configurations), and I have > read that Axis is > significantly faster than Apache SOAP so anything > should be an > improvement over what we've got right now. > > Anyway according to this, JAX-RPC outperforms Axis > (doc/lit) for small > to medium sized responses. I am not sure where SJ > would be classified > on the "density" scale, but thought it would be > worth a look. > > Chris > > Robert MacGrogan wrote: > > Marc, you make a good point about having to work > against multiple servers. If we have a good SOAP > > API, then, you're right, we shouldn't have to > change it. The problem is, the API is not > > necessarily all that good. And sometimes improving > the functionality of existing features requires > > modifying the existing API. > > > > One way limit the impact of backward compatability > would be to have the client be backward > > compatible but not the server. If you get the > latest client, you'll be able to work against any > > existing server. Or we could freeze the most > significant API's, connect, get project object, get > > file object, get file, check in, and check out. Or > at least required future versions of the server > > to always support the current API for those > features. > > > > You make a good case, Marc. I'll definitely > consider what you're saying. > > > > By the way, my first work on the 2.2 release will > focus on speeding up SJ. I'm going to change SJ > > to use SAX to read XML files instead of DOM. This > should have a pretty big impact, I think. And > > I'm going to switch SJ to use the latest version > of Apache Axis. One change between Apache SOAP > > and Apache Axis is that AS uses DOM and AA uses > SAX. Using SAX for all SOAP calls should speed up > > SJ significantly. > > > > --Rob > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the hype. > Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > SourceJammer-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/sourcejammer-devel > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ SourceJammer-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sourcejammer-devel
