Interoperabilidad de Servicios Web
Esta página pretende darle información para que usted pueda tener garantías de que sus aplicaciones de servicios Web van a funcionar entre plataformas y entornos de aplicación diversos. Guía de Interoperabilidad de Servicios Web (WSIG)Predecir si existe interoperabilidad a nivel de servicios Web entre dos plataformas a veces es muy complicado. La serie de documentos de la Guía de Interoperabilidad de Servicios Web (WSIG) ofrece directrices que permiten conectar aplicaciones utilizando juegos de herramientas concretos.
Artículos
Multimedia (en inglés)
| Links Destacados (en inglés)
Simon Guest habla sobre Interoperabilidad e Integración (en inglés)
¿Nunca ha utilizado blogs ni RSS? Consulte esta página.  Cómo se puede saber si un servicio Web es realmente un servicio Web?. Me preguntaron "¿Cómo se puede saber si un servicio Web es realmente un servicio Web?". Si alguien dice que tiene un servicio Web (o más importante, si están tratando de vendérselo!), ¿qué preguntas tendría que hacerle? Pensé que lo mejor era agrupar las 10 cosas que nos permiten tener esa certeza, y por supuesto, si me he olvidado de algo, ¡bienvenido! 1. Utiliza WSDL. Un servicio Web debe exponer su contrato de servicio usando WSDL. Si no puede entregar un documento WSDL, probablemente se trata solo de XML sobre HTTP. 2. Utiliza SOAP. Todos los mensajes enviados y recibidos por un servicio Web deben utilizar formato SOAP. Si no utiliza SOAP, seguramente se trata de XML sobre HTTP. 3. Utiliza XSD. Todos los tipos de datos en el bloque de datos (payload) de SOAP deben cumplir normativa XSD. No se permiten tipos nativos de ninguna plataforma. Si no utiliza XSD, seguramente se trata de XML sobre HTTP. 4. Utiliza XML. Los mensajes subsiguientes deben, por supuesto, estar formateados con XML. 5. Ausencia de datos binarios arbitrarios. El bloque de datos del mensaje debe ser ASCII de 7 bits y no puede contener cadenas binarias. No se puede enviar ningún dato binario mediante un servicio Web utilizando SwA, DIME o MTOM (preferiblemente MTOM). 6. El transporte probablemente es HTTP. Aunque no es un requisito, la mayoría de los servicios Web actuales usan HTTP como transporte. Los servicios Web compatibles deben definirse para funcionar sobre HTTP. 7. El descubrimiento debe poder hacerse mediante UDDI. De nuevo, aunque no es un requisito, sebe ser posible alojar el punto de acceso al servicio Web usando UDDI. 8. Versiones de Especificaciones normalizadas. Las versiones de todas las especificaciones mencionadas antes (WSDL, SOAP, XSD, XML, HTTP, UDDI) deben estar en línea con la última versión del Perfil Básico WS-I (http://www.ws-i.org) para garantizar que el servicio Web es compatible entre distintos fabricantes. 9. Sus operaciones deben ser de tipo Documento. Las operaciones a/desde un servicio Web deben ser en estilo Documento/Mensaje (p.ej. SendOrder(order o)). El estilo RPC debe eliminarse (p.ej. SetOrderLine1(orderId id)). 10. Debe ser compatible con WS-*. Los servicios Web deberían poder aceptar bloques de datos y extensiones de WS-* para garantizar la compatibilidad a nivel de seguridad, fiabilidad y transacciones (aunque no todas las pilas de implementación soportan esta definición aún). Publicado el 26 de enero de 2006 | |||||||||||||||||||||||||||||||
Última actualización de esta página: 2 de Julio de 2007 | ||||||||||||||||||||||||||||||||
Mi nombre es Simon Guest, soy Program manager en el equipo de Estrategia de Arquitectura. En esta sección le mostramos las aportaciones más recientes sobre interoperabilidad de servicios Web en mi 