Steve Jones wrote: > As someone who is also working in the wild with WS and SOAP I'd say that > the problems I've seen around performance have been the age old ones of > > 1) Fine grained interactions > 2) Chatty interactions > 3) "Ship it all, they'll work out what they need" > 4) Rubbish performance behind the interface being blamed on the interface > > Now clearly SOAP and XML marshalling aren't free, but when we did some > RMI/SOAP tests back in 2003/4 we found that RMI/IIOP v SOAP was a pretty > even fight, now I'll give Dan and Greg the chance to jump on that as
If those were the options, it's a fair fight period. I'd only want to check that the reasoning for selection of those options was appropriate - sure it was, by the way. > being the wrong comparison but it was fair for that project. My first > production experience of SOAP was in 2001 over a 1 MB SSL over the > internet link running off 2 way Intel boxes, it worked for that fine and > I'm confused as to why performance has got worse since then. > Something somewhere is putting in more stuff to ship around the network or something somewhere is a bottleneck that wasn't before.......stating the obvious. > So is the issue with performance actually performance of SOAP, or is it > that people aren't good at building distributed applications. > Second one for sure, probably some of the first as well given that it's likely overloaded with stuff not needed for common cases. > NB to the REST people out there, don't snigger around this as the chatty > nature of REST is liable to create equally large problems against the > weight of SOAP. > Cue arguments about caching being possible with REST and less so with SOAP etc. Have my own opinions on that and can't be bothered to do the why's and wherefore's again. Dan. > Steve > > > On 17/01/07, *Gervas Douglas* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > <<For years those building SOAs have said that "SOAP is too slow" and > Web Services are just the icing on the SOAP cake. However, as somebody > who's out there in the SOA project world right now I think it's fair > to say that many SOAs are indeed slow, and that performance is always > an issue when dealing with Web services. > > However, SOAP could be speeding up. Enter WS-MTOM, or the development > of the SOAP Message Transmission Optimization Mechanism specification. > MTOM offers composability of base64 with the transport efficiency of > SOAP with attachments. However, WS-MTOM wasn't tied into the rest of > the Web Services architecture: there was no standard way for services > to advertise that they were "MTOM ready," until now. > > IBM and Microsoft have recently submitted WS-MTOMPolicy to W3C. This > has now been acknowledged by W3C, which clears the way for a > standardization effort around this issue. > > >From the spec: > > "This specification describes a domain-specific policy assertion > that indicates endpoint support of the optimized MIME multipart/ > related serialization of SOAP messages defined in section 3 of the > SOAP Message Transmission Optimization Mechanism specification. This > policy assertion can be specified within a policy alternative as > defined in WS-Policy Framework and attached to a WSDL description as > defined in WS-PolicyAttachment." > > So, take WS-Policy and MTOM, and it's soon going to be possible for > Web Services across enterprise boundaries to advertise their MTOM > capabilities. Thus, SOAP will be faster. Thus, Web services will be > faster. Thus, our SOAs will be faster. That's a good thing.>> > > You can read this at: > > > <http://weblog.infoworld.com/realworldsoa/archives/2007/01/speed_up_your_s.html?source=NLC-SOA2007-01-18 > > <http://weblog.infoworld.com/realworldsoa/archives/2007/01/speed_up_your_s.html?source=NLC-SOA2007-01-18>> > > Gervas > > >
