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 Trans 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. Software Development