En este nuevo número vamos a ver un problema muy muy común cuando trabajamos con arquitecturas SOA o intentamos hacerlo (como es mi caso). Seguro que vamos a tener diferentes servicios y seguro que varios de esos servicios van a utilizar tipos comunes. El problema es que cuando importamos estos servicios en el cliente se nos generan dos tipos (no compatibles) para el mismo tipo compartido.
En primer lugar vamos a suponer que los servicios son implementados como Web Services (asmx).
Para solucionarlo hay que hacer dos cosas:
- Conseguir que los WSDL presenten exactamente la misma serialización para el tipo común. Para ello tenemos que especificar el tipo XML de nuestra clase. Debemos poner un namespace a nuestro tipo común. Ésto, unido a que el nombre del tipo y los campos van a serializar siempre igual, hará que ambos WSDLs definan el tipo común de igual forma.
- Decirle a nuestro gran generador de proxies que sea un poco cuidadoso y si detecta dos tipos iguales (namespace, nombre de tipo y esquema) que sólo genere una clase).
De esta forma generamos un único tipo en el cliente. Nos olvidamos de problemas de castings entre tipos (que eran iguales pero distintos) y de no poder pasar a un servicio los tipos que me devolvía otro. Vale... Pero ¿Cómo se hace? En este link nos explican cómo dar los dos pasos: http://msdn.microsoft.com/en-us/library/aa480505.aspx En este otro nos explican cómo dar el segundo paso más fácil. http://quickstarts.asp.net/QuickStartv20/webservices/doc/TypeSharing.aspx
Y en WCF??
Así --> http://geeks.ms/blogs/jlsoria/archive/2008/07/16/wcf-compartici-243-n-de-tipos-entre-referencias-a-servicios.aspx
Ahora os cuento mi vida. Como todos sabéis, estoy currando con Flex y ya van varias veces que me está condicionando en cosas muy importantes. Varios ejemplos son las entregas anteriores:
Aunque Flex (action script) define enumeraciones, los esquemas xsd también, por tanto WSDL también. Resulta que el generador de proxies tiene un bug y no funcionan (documentado por Adobe y sin workarround ni miras de que vayan a solucionarlo). Esto me ha obligado a no usar enumeraciones --> bajoncete
Aunque el protocolo SOAP define soap faults para transportar errores, y es así como se transportan las excepciones. Flex "descarta" la información que tú pasas en el soap fault y siempre manda la misma excepción genérica al proxy que ha generado. Entonces, nunca puedes ver nada de la excepción --> no puedes usar excepciones para comunicar errores (Documentado por Abobe y el WorkArround es "No uses excepciones") --> bajonazo!!
Ahora, cómo no, he encontrado aquí http://bugs.adobe.com/jira/browse/FB-1251 que no es capaz de darse cuenta de que hay un tipo común entre dos servicios. Dice que hay un workarround aunque no asegura que siempre vaya a funcionar. Ya he perdido mucho tiempo en el proyecto por temas como este. Mi problema actual es que tengo que hacer un servicio bastante más grande de lo que me gustaría (unión de dos), aunque la aplicación no es muy grande y el servicio tampoco es exagerado. A estas alturas no estoy a tiempo de cambiarlo y arriesgarme. Si algún alma caritativa tiene alguna idea o amigo de Flex (me consta que miguelín sí lo tiene ;) ) agradecería su ayuda eternamente.En la siguiente entrega hablaremos de dónde se puede limpiar el almacenamiento de contraseñas responsable que, por ejemplo, no se nos pida nunca la contraseña cuando accedemos al TFS. Es un coñazo cuando queremos cambiar la cuenta con que accedemos.
Un saludo a todos.
Mario.
No hay comentarios:
Publicar un comentario