I'd also thought DIME was in Axis2, but didn't see it in the codebase. The Axis2 TCP support is definitely not DIME-based - it just uses a separate socket connection for each request.
- Dennis Paul Fremantle wrote: > I like your approach. Too many "performance enhancing" projects founder on > not actually seeing what works and what doesn't. > For some reason I thought there was already work on DIME and TCP in Axis2. > But I've never actually looked at the code so I'm probably wrong. > > Paul > > On 10/8/07, Dennis Sosnoski <[EMAIL PROTECTED]> wrote: > >> Sure, I think that could be an excellent idea. >> >> On binary XML, the W3C EXI group (http://www.w3.org/XML/EXI/) is likely >> to be the long-term winner. Sun's "Fast Infoset" has never seemed all >> that fast in tests I've seen (including when used with Axis2), but if >> you're looking for a short-term solution my own XBIS >> (http://www.xbis.org) is a simpler alternative. When I added XBIS >> encoding to my old JibxSoap code I more than doubled performance. Right >> now I have it structured so JiBX can output directly to XBIS and read >> directly from XBIS; if I extend this to include a StAX wrapper it should >> be usable directly with Axis2. It'd be interesting to see how much >> benefit that provided, vs. "Fast Infoset". >> >> On the TCP model, I'm currently implementing a simple DIME-based >> approach for my own work. However, that does not allow for sharing the >> socket connection (something that both Sun's approach and the .Net 3.0 >> net.tcp technique support). I'm going to try some tests to see how much >> benefit you actually get from sharing the socket connection. Offhand I'd >> think the gains would be pretty small, but if they're significant that's >> probably worth doing. DIME doesn't support that directly, but could >> easily be extended to do so. >> >> - Dennis >> >> >> Paul Fremantle wrote: >> >>> I hate to suggest something new (NIH) but maybe we could start an open >>> discussion and forum on what would make a good BinaryXML/TCP model? >>> If we came up with something significantly better then it would be worth >>> doing. >>> >>> Paul >>> >>> On 10/8/07, Dennis Sosnoski <[EMAIL PROTECTED]> wrote: >>> >>> >>>> Hi Paul, >>>> >>>> I think it's an interesting possibility. I've been trying to find out >>>> what .Net is currently using for their net.tcp transport, but that's >>>> proving difficult. The Sun proposal is at least well-defined. >>>> >>>> I wish they'd asked for comments and started a discussion rather than >>>> just making something up, though. Some parts seem lame, such as using >>>> nibble encoding, and requiring a response message for every request >>>> message (not necessarily appropriate with WS-Addressing involved). It's >>>> also a bit heavy-weight, with a SOAP service request to open a channel. >>>> >>>> - Dennis >>>> >>>> -- >>>> Dennis M. Sosnoski >>>> SOA and Web Services in Java >>>> Axis2 Training and Consulting >>>> http://www.sosnoski.com - http://www.sosnoski.co.nz >>>> Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117 >>>> >>>> >>>> >>>> Paul Fremantle wrote: >>>> >>>> >>>>> Guys >>>>> >>>>> We should develop a compatible transport to this transport: >>>>> http://www.infoq.com/news/2007/10/soap-tcp-wcf >>>>> >>>>> Paul >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>>> >>>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
