¿Puede una API en SOAP/WSDL mantenerse compatible con versiones anteriores fácilmente?

Question

Al usar una biblioteca IPC, es importante que brinde la posibilidad de que tanto el cliente como el servidor puedan comunicarse incluso cuando su versión de la API sea diferente. Como estoy considerando usar SOAP para nuestra aplicación de cliente/servidor, me pregunto si una solución SOAP/WSDL puede manejar bien los cambios de la API.

Por ejemplo:

• Adición de parámetros a las funciones existentes
• agregar variables a estructuras existentes que se utilizan en las funciones existentes
• funciones Extracción
• Extracción de parámetros de las funciones existentes
• variables de Extracción desde las estructuras existentes que se usan en las funciones existentes
• Chang ing del tipo de un parámetro utilizado en una función existente
• Cambiar el orden de los parámetros en una función existente
• Cambiar el orden de piezas de material compuesto en un struct existente
• Cambiar el nombre de funciones existentes
• parámetros Cambiar el nombre de

Nota: por "estructura" me refiero a un tipo compuesto

Answer 1

Hasta donde yo sé, no hay tales cosas según el estándar SOAP/WSDL. Pero existen herramientas para enfrentar estos problemas. Por ejemplo, en Glassfish puede especificar XSL hoja de estilos para transformar la solicitud/respuesta de un servicio web. Otra solución, como la suite Oracle SOA, ofrece herramientas mucho más elaboradas para administrar el control de versiones del servicio web y la integración del componente. El mensaje puede ser enrutado automáticamente a una versión diferente de un servicio web y/o transformado. Deberá verificar qué ofrece su infraestructura objetivo.

EDITAR:

XML y XSD es más flexible en cuanto a la evolución del esquema de tipos y serialización en lenguajes orientados a objetos. Algunas cosas se pueden hacer compatibles con versiones anteriores simplemente declarándolas como opcionales, p. Ej.

• Adición de parámetros a funciones existentes - si un parámetro es opcional, se obtiene un valor null si el cliente no lo envía
• Adición de las variables en la estructura que se utilizan en las funciones existentes existente - si el valor es opcional, se obtiene null si el cliente no se lo proporciona
• funciones Extracción - no hay magia aquí
• Extracción de parámetros de las funciones existentes - parámetros enviados por el cliente serán superfluos acuerdo con la nueva definición y se omitirá
• las variables de estructura existente que se utilizan en las funciones existentes Extracción - No sé, en este caso
• Cambiar el tipo de parámetro utilizado en una función existente - eso depende del cambio. Para un tipo simple, la serialización/deserialización aún puede funcionar, p. Cadena a int.

Tenga en cuenta que no estoy 100% seguro de la lista. Pero algunas pruebas pueden mostrarle lo que funciona y lo que no funciona. El punto es que XML se envía por cable, por lo que da cierta flexibilidad.

Answer 2

no lo hace. Deberás gestionarlo de forma manual de alguna manera. Normalmente, al crear una nueva interfaz a medida que introduce cambios principales/de última hora.

En términos más generales, este es un problema arquitectónico, en lugar de uno técnico. Una vez que se publica una interfaz, realmente debe pensar en cómo manejar los cambios.