Couple notes about the soap/tcp stuff: Some of the advantages: The main advantage of the soap/tcp stuff is that it "chunks" the messages so that streaming will work. We already do this by default with HTTP. (metro doesn't) Thus, that advantage is somewhat lost. Actually, soap/tcp may be WORSE than HTTP+chunking. With http+chunking, each "frame" header is, at most, 4 bytes (just the size of the chunk in hex). With soap/tcp, each frame involves a larger header marking the channel, size, etc.....
The other advantages: 1) Stateful fastinfoset vocab - this could be implemented of HTTP + sessions as well. 2) Up front content-type negotiation - with soap/http, the first message is pretty much always plane soap, but we set the Accept-Content-Type header to say "respond with fastinfoset if you can". If it does, all future messages are fastinfoset. The upfront negotiation avoids the first message being plane soap. If you KNOW the other endpoint supports it, you can force it in CXF by configuring the interceptor/feature to "always" mode. 3) Binary headers - the size and codes and stuff in the frame header are binary, not text, thus avoiding the parsing of those. This really is only useful for TONS of small messages. 4) Socket multi-plexing - this is definitely useful, but the JDK URLConnection does do keep-alives (unforunately, not very long keep alive timeout) which helps mitigate for very chatty services. Dan On Thursday 21 August 2008 9:26:49 am nicolas de loof wrote: > Hello, > > I'm read some blogs and benchmarks about use of FastInfoset in replacement > for textual XML in SOAP messages over HTTP > (http://java.sun.com/developer/technicalArticles/WebServices/fastWS/), > and about SOAP over TCP ( > http://blogs.sun.com/oleksiys/entry/soap_tcp_makes_web_services) that seems > to be a Microsoft .Net initiative for faster services. > > Is there any support for those transport/marshalling alternatives in CXF ? > > Nicolas -- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
