Hace unos dias en el trabajo me encomendaron la tarea de trabajar con unos compañeros que deseaban exponer unos servicios de Abastecimiento de medicamentos a sus proveedores....
Ellos ya habian avanzado un poco y me comentaban "Ya tenemos desarrollados unos WebServices", a lo que les pedi que me pasaran su WSDL
Al echarle un vistazo a ese documento me encontre algo como lo siguiente (entre otras cosas):
como operacion de entrada:
s:element name="ObtenerOrdenes"
como parametro:
element minOccurs="0" maxOccurs="1" name="SQL" type="s:string"
como respuesta:
s:any
Ok veamos que tenemos. El nombre OBTENERORDENES de entrada me suena a negocio hasta ahi todo va bien, el problema viene en el parametro que estan pasando se llama SQL, que por el solo nombre me pone a pensar que estan pasando sentencias de SQL para hacer la consulta (lo cual deja abierto al cliente a poner cualquier cosa dentro de la consulta)
Luego veamos la respuesta, si vemos regresa un Any (Que los que han leido el blog, siempre nos oponemos al uso de ANY como resultado o entrada) que cuando les pregunte me dijeron coloquialmente que ahi regresaban el "ResulSet" ajale!!! osea que si regresan la consulta tal cual de su base de datos.... y para finalizar en el servicio no hay ningun mensaje que indique los errores que pueden ocurrir.
Bien ya no pongo los demas metodos, porque solo estos me permiten ejemplificar la importancia de manejar un buen contrato.
Al diseñar un contrato de negocio de un servicio (independientemente si lo vas a hacer con: Web Services, RMI, COM, o palomas mensajeras) es muy importante definir los mensajes que estatas intercambiando entre el servicio, es decir, basicamente es constuir un layout (que tenga nombres, tipos de datos, tamaño y si es obligatorio el campo) de las ENTRADAS, SALIDAS y MENSAJES DE ERROR.
Asi de sencillo, en verdad utilizar esta practica nos ayudado mucho cuando tratamos de integrar aplicaciones.
Saludos
Tuzo
martes, 6 de noviembre de 2007
Suscribirse a:
Comentarios de la entrada (Atom)
1 comentario:
Si se ponen de pechito caray...
O sea, al exponer un WS buscas integrar sin acoplar así que al tener que enviar una sentencia SQL están 1) Abriendo una brecha de seguridad (más bien una super carretera) y 2) Mega-acoplando el consumidor al WS...
Dónde es posible esto? Solo en México :D
Publicar un comentario