Existe una gran variedad y latitud con respecto a los "servicios web". Me parece útil tomar nota explícita de lo que estamos hablando:
web = transported over HTTP(S)
service = remote procedure call (RPC)
Tenga en cuenta que la parte HTTP (S) del presente simplemente especifica el medio de transporte, pero no el contenido. También tenga en cuenta que la parte RPC de esto simplemente especifica el comportamiento (básicamente invocar de forma remota una función nombrada con argumentos que devuelve un resultado) pero no el contenido.
Una pregunta crítica que surge es si usted controla ambos lados de la comunicación. Si es así, pero especialmente si no es así, debe preocuparse por la interoperabilidad.
SOAP es un estándar para implementar un servicio web que especifica el uso de XML con formato específico para el contenido de la solicitud y la respuesta. Es MUY pesado, y todavía hay problemas con la interoperabilidad en varias implementaciones.
Hay muchas implementaciones personalizadas, la mayoría de las cuales son más livianas, pero es casi seguro que tendrá problemas de interoperabilidad.
Dado que cualquier tipo de contenido se puede utilizar potencialmente para lograr un servicio web, recomiendo elegir algo que sea capaz de manejar contenido complejo (en diversos grados), estandarizado, liviano y robusto.
Recientemente me he inclinado por JSON para el formato de contenido. Recomiendo considerar lo mismo, especialmente si está considerando implementar AJAX.
Los mejores deseos.
¿Ya se decidió por una plataforma? Java, C#, ¿algo más? ¿Estás en desacuerdo con el uso de SOAP o estás abierto a algo RESTful en su lugar? –