Sun engineers talk about how they are addressing web service performance issues using ASN.1 to encode XML in this Fast Web Services article.  According to the article, so called Fast is 4 to 10 times faster depending on the complexity of SOAP request and response being exchanged.

Binary XML is one of the first problems I tackled when I first discovered XML many years ago.  Since then XML spec was published and SOAP was introduced.  I was intrigued by SOAP because it shared many characteristics with Inter-Application Communication (IAC) work "Dave" and I worked on for Frontier ages ago.  Looks like the Wheel turned again and now we have Fast Web Services.

My opinion is that, while there will be some web applications which are practically only with Fast Web Services, the performance gain will be lost on most web applications.  Just look at how we have gotten used to squandering memory and bandwidth as availability increased.

Faster performance could encourage finer-grained web services which amounts to fetching a document one word at a time.  Even worse, fine-grained web services increases load on the server-side, not only on web servers, but application servers, database servers, and directory servers.  This is one case where common sense differs from reality.

While thre are ways to avoid these problem, solutions require skills, experiences, resources, and mindshares not readily available in the Lazy Web.  To best use Fast Web Services, consider it after design and implementation phase and either before or even after deployment so that your design don't end up with a built-in dependency and unavoidable waste and abuse stemming from the dependency.