Recomendaciones para procesos de integración con Web-Services

Please download to get full document.

View again

All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
 10
 
  Recomendaciones para procesos de integración con Web-Services Este documento es producto de la experiencia en integración vía Web Services. La información recopila una serie de lecciones aprendidas a partir
Related documents
Share
Transcript
Recomendaciones para procesos de integración con Web-Services Este documento es producto de la experiencia en integración vía Web Services. La información recopila una serie de lecciones aprendidas a partir de errores cometidos durante procesos anteriores. El objetivo de estas recomendaciones es minimizar errores, y facilitar los procesos de integración con nuestros clientes. Recomendaciones Generales 1- Manejar una especificación común de la integración, que sea única para las partes (contrato de integración). Esta debe incluir: a. Esquemas generales de comunicación. b. Esquemas de mensajería en WSDL y XSD. c. Frecuencias, cantidad y tamaño de todos los mensajes que intervienen en la comunicación. d. Garantizar la firma de las partes sobre la especificación. 2- Establecer el modelo de comunicación: a. Síncrono: b. Asíncrono: i. Envío de Mensaje Ejecución y Respuesta i. Envío de Mensaje Acuso de recibo ii. Envío respuesta Acuso de recibo 3- Diseñar los esquemas de mensajería sobre un modelo de datos maduro. 4- Establecer claramente los requerimientos de información mediante la definición de una gramática asociada a cada tipo de mensaje. En particular se recomienda utilizar el lenguaje de especificación de gramáticas para XML, XSD. 5- Establecer uno o varios archivos técnicos de especificación WSDL, que describan en detalle los servicios disponibles, y que además incluyan los respectivos componentes de gramática definidos en el punto anterior. Es muy importante aclarar que estos archivos de descripción tendrán siempre prelación, en términos de alcance de la especificación, sobre cualquier otro tipo de descripción que se realice. Lo anterior tiene como objetivo facilitar a un tercero el entendimiento de la especificación planteada, por ejemplo archivo word y excel, y ejemplos generados. 6- Usar una gramática asociada implícita que permita entender fácilmente el mensaje creado. Es decir, buscar el uso de tags y atributos que tengan sentido dentro del contexto del mensaje. De esta forma, se podrá analizar fácilmente un mensaje de XML, así no se cuente con la gramática. El uso de tags y atributos genéricos no es recomendable, pues dificultan la lectura del mensaje, e implican una serie de supuestos de contexto que no siempre están disponibles. 7- Utilizar Namespaces para identificar unívocamente el origen de las gramáticas utilizadas. Se recomienda tener un punto de referencia en la red, en caso de requerir información al respecto. 8- Utilizar estándares aceptados en la industria, independientes al fabricante. Esto con el fin de minimizar las interpretaciones erróneas que puedan darse en el transcurso del proceso de integración. De hecho, ante cualquier disputa técnica, serán los estándares quienes diriman, en primera instancia, los conflictos relacionados con interpretaciones que hayan surgido con respecto a los detalles técnicos de la integración. 9- Se recomienda utilizar los siguientes estándares: a. El mensaje XML se especifica según la versión XML 1.0 definida: (http://www.w3.org/tr/rec-xml/) b. La integración está basada en el documento WSDL (Web Service Description Language) definido para el proyecto. Este documento incluye, entre otras definiciones, las estructuras de cada uno de los mensajes, tanto de solicitud como de respuesta. Además, incluye los mecanismos de comunicación utilizados. (http://schemas.xmlsoap.org/wsdl/) c. Para la definición del esquema de mensajería se debe utilizar el estándar XSDL (XML Schema Definition Language) contenido en el respectivo archivo XSD. (http://www.w3.org/2001/xmlschema) d. Todo mensaje debe ser enviado en una envoltura SOAP (Simple Objects Access Protocol) versión 1.1, orientado a identificar errores y monitorear las transacciones realizadas. (SOAP: SOAP ENCODING: Especificación de tipo archivo MIME asociado al Mensaje SOAP: e. Comunicación vía http (http://schemas.xmlsoap.org/wsdl/http/) f. La codificación por defecto será UTF-8, a menos que se defina en el encabezado del mensaje la codificación ISO que equivale a ISO- Latin1, la cual utilizan los equipos con Windows. (http://www.unicode.org/versions/unicode5.2.0/) g. Los archivos que sean enviados dentro del mensaje XML, deberán tener el formato estándar PDF/A, y ser codificados según el estándar Base64. h. PDF/A: i. Base64: ) j. Para la comunicación segura a través de firma digital, se debe utilizar el estándar WSS (Web Services Security v1.0 (WS-Security 2004) [OASIS ]). (http://docs.oasis-open.org/wss/2004/01/) 10- Utilizar validadores de gramáticas XSD s para validar los mensajes que van a ser enviados a: a. El servicio (Consumo) b. El servicio (Publicación) 11- Evitar iniciar pruebas de integración hasta tanto los mensajes generados, en una y otra vía, cumplan con los estándares definidos, y hayan sido validados plenamente. Esto tiene como finalidad evitar pérdida de tiempo y desgaste en pruebas de validación que pueden ser realizadas, en forma independiente y autónoma, por cada una de las partes. 12- Manejar desde el principio un esquema de errores basado en estándares como SOAP 1.1 ó SOAP 1.2, el cual permita identificar fácilmente los siguientes errores: a. La fuente del error i. Emisor ii. Receptor b. El detalle del error i. Léxico ii. Sintáctico iii. Homologación iv. Semántico (Reglas de negocio y precondiciones para ejecutar el servicio) 13- En caso de problemas en la integración, se debe recurrir a herramientas disponibles en la red, que sean de carácter neutral. Esto con el propósito de dirimir conflictos asociados con el incumplimiento de un estándar, o especificación dada, e identificar los problemas relacionados. Se propone utilizar la herramienta ALTOVA XMLSPY (http://www.altova.com/download/xmlspy/xml_editor_enterprise.html) 14- Establecer un esquema de validación en el sitio que publica el servicio, y usar el protocolo SOAP para reportar los errores al emisor. Identificar, como mínimo, los siguientes tipos de errores: a. XML bien formado, y además debe utilizar el set de caracteres que se especifica. En caso de no tener explícito el set de caracteres, se asumirá UTF-8 b. Validación del paquete SOAP. Con lo cual se garantiza que el mensaje utiliza correctamente el estándar SOAP. c. Mensaje XML contenido en el paquete SOAP, de acuerdo al esquema definido para el Web Service. Para tal fin, el mensaje debe regirse por la gramática descrita en el XSD respectivo. En este punto debe identificarse el uso correcto de tags, así como la validez de la estructura del mensaje en los siguientes términos: i. Tags y atributos ii. Tipos de datos iii. Elementos obligatorios y opcionales iv. Estructuras y subestructuras del mensaje d. Homologaciones. Se debe garantizar que la información enviada está diligenciada de forma carrecta, en términos de los nombres y valores utilizados. También se debe confirmar que esté incluida dentro de las tablas de homologación, definidas de común acuerdo. e. Manejo de valor por defecto. 15- Dentro del tag FAULT se debe utilizar una especificación para descripción de errores, la cual contendrá el esquema del mensaje de error. Adicionalmente, se colocará dentro del tag faultcode el responsable o la naturaleza del error, según la especificación estándar. (Ver especificación SOAP) 16- Contar con un sistema o mecanismo que permita rastrear o monitorear la dinámica alrededor de los servicios definidos, bien sea utilizando un bus de integración, un monitor de WebServices o logs. Es fundamental tener un log de todas las comunicaciones. 17- Controlar y/o validar la aparición de mensajes repetidos. 18- Utilizar Id s en todos los mensajes de envío y respuesta; de esta forma se garantiza el rastreo de la información en cada sistema de manera univoca, lo cual permite identificar rápidamente las causas de los errores y excepciones que se presenten. 19- Establecer un mecanismo que garantice la consistencia entre la información de la base de datos, y la información de las tablas de homologación. Por ejemplo: a. Manejar las tablas de homologación en la base de datos. b. Verificar cualquier cambio en la BD, frente a las tablas de homologación. Recomendaciones para evitar problemas técnicos al usar herramientas de generación de código.net: 1- Evitar incluir atributos en la raíz del XML. Esto genera problemas con los kits de desarrollo de Microsoft. 2- Pegar el esquema XSD en el WSDL (no referenciarlo). Esto también causa problemas con los kits de desarrollo de Microsoft. Lecciones aprendidas en homologación 1- Definir un protocolo para solucionar los casos indeterminados. De esta manera se agiliza el proceso cuando se presente de nuevo el caso. 2- Establecer responsables para cada caso en que la homologación requiera soporte. 3- Evitar homologaciones de uno a varios. 4- Cuando se requieran homologaciones uno a varios, se debe establecer un acuerdo para proceder en caso de que las reglas cambien. 5- Acordar cual será la resolución de los casos cuando la información del mensaje sea obligatoria, pero corresponda a fuentes de información opcionales.
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks
SAVE OUR EARTH

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!

x