¿y los estandares apa?

Bien pues aqui de regreso a este lindo blog, queridos 2 lectores..

Bien tengo varios temas pendientes, ejemplos de Mule temas de SOA Governance.. documentacion de Servicios, etc etc etc... en fin... ya estoy trabajando en ellos.

Bueno pues a lo que me trajo este "quejapost". hace ya unos meses escribimos un post acerca de la importantcia de los contratos, en el que basicamente podriamos concluir con la frase que he tomado hace tiempo "la culpa no la tiene el SERVICIO, si no quien lo IMPLEMENTA ( o mejor aun QUIEN LO DISEÑA )"...

Y me vuelvo a preguntar ¿y los estandares apa?..... lo que mas me "encanta" es que cuando se les cuestiona a ciertas personas de la implementacion de sus servicios, contestan "pus si estamos usando WSDL, SOAP, XSD son estandares no?"... ahora si que me pasa como condorito cuando sucede eso.......ploof!!

Bueno pues deseo compartirles que hace unos dias nos toco participar en una integracion entre Secretaria de Economia y el Seguro Social.... concretamente para las parte de alta rapida de empresas..... bueno pues nosotros seremos expositores de algunos servicios, para lo cual agendamos una reunion con estos monitos de Economia para tratar asuntos tecnicos.

Para no hacer el cuento largo, el cuate tecnico me dice "Nosotros necesitamos que ustedes expongan un servicio que reciba un STRING y regrese un STRING y en el se coloque el XML tal y como se definieron los XSD de entrada salida" ... charros y me vuelvo a preguntar ¿y los estandares apa? .... pense que no podria haber algo mas feo que usar un ANY en un servicio Web.... pero que sorpresa me lleve con estos cuates.... en fin..

Lo mas chusco, fue cuando le comente que "nosotros no podriamos usar un servicio expuesto de esa manera, que era necesario hacer el WSDL concreto con los valores de entrada, salida, y mensajes de error" y este amigo comenta "es que tenemos una tecnologia de bus de integracion ESTANDAR (claro es estandar usar STRING) que permite DESACOPLARNOS de otras soluciones y si me mueves el contrato, entonces no podemos hacerlo ( y entonces endonde quedo lo desacoplado del asunto)" ...

Bueno pues despues de desahogarme con ustedes.. .el mensaje que deseo dar a este post es:

- Definan contratos de negocio: usenlo como su diccionario de datos, en algunas framworks como el SOMA se le llama "Service Interface"
- Especifiquen sus servicios: es decir entradas, salidas, mensajes de error, todo ello usando XSDs, en SOMA esto es "Service Contract" y esta en la disciplina de "Service Specification"
- Definan sus WSDLs, en la medida de lo posible NO usen Any o String para mandar cualquier XML de respuesta.... eso le quita el sentido a elaborar un Contrato de Negocio
- En la definicion de su Servicio, siempre consideren informacion necesaria para manejo de errores: ERROR, NUMERO, DESCRIPCION.

Porque si no volvere a preguntarme ¿y los estandares apa?

Por una integracion mejor, hasta la vista

Tuzo

Mashups o Web como servicio

Explicando brevemente un concepto que se ha manejado ultimamente, mashups (asociado con Web 2.0)

Un mashup es un componente web (que a la vezpuede ser consumido como un webservice tipo SOAP o REST) y que integra informacion de distintas fuentes de informacion.

Es decir, un mashup permite consumir informacion de una pagina Web o un WebService o de servicios como Google Maps, Blogger, Flicker o del.icio.us.

Resuelve problemas en los cuales, si es necesario consumir datos de una aplicacion Web, basada en HTML, permite capturar la informacion que se tiene en una pagina.

El concepto es muy interesante y poderoso, ya que es un mecanismo que permite exponer paginas Web como servicios.

Les recomiendo visiten la documentacion del proyecto WSO2 server mashup.

Otro ejemplo, pero no tan accesible para probar (es decir, algun gerente de ventas te estara cuestionando para que usar el software antes de dartelo) es el de la empresa JackBe , con su tecnologia Presto


Cierro este comentario, dejando que mediten las posibilidades de integrar a las aplicaciones informacion que vienen de Internet.

La importancia de los contratos

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

PartnerApi Library: Por fin ve la luz

Hace algunos años fui contratado para integrar un CRM y Salesforce (se llamaba así en ese entonces). Para realizar la integración usé C# y el Enterprise API de Salesforce para llevar los datos del CRM al repositorio en línea de Salesforce. Un ejercicio harto interesante. También leí algo acerca de la PartnerApi y de ahí surgió la inquietud de utilizarla.

El objetivo que se me presentó en mi mente fue crear una biblioteca que simplificara el uso de esta PartnerApi y pues después de mmuuuucho tiempo aquí está.

Acabo de publicar el código, licenciado bajo LGPL, para que todo mundo lo revise, lo use y ojalá y contribuya a este proyecto.

Cualquier comentario, sugerencia o pregunta son bienvenidas.

Finito.

Web Services Manejables

Hola que tal! de nuevo por aqui

Como se habran dado cuenta, hace algunos dias hablamos (o nos quejamos jeje ) del diseno de unos servicios web.... aqui les dejo unas recomendaciones (Best Practices) a tomar en cuenta, quiza sean simples... pero elementales.. aunque muchas ocasiones no se siguen ;)

• NO usar elementos simples en las firmas de los metodos ; tomando como ejemplo public int obtenerCotizaciones(int nss), tenemos un problema: la escalabilidad del mensaje, si desearamos agregar la fecha de alta trendriamos que colocarlo de la siguiente manera public int obtenerCotizaciones(int nss,long fecha).. MAL , en lugar de eso debemos modelar un objeto que defina mi negocio (tanto entradas como salidas).... siguiendo con el ejemplo definamos:

• public class entradaCotizaciones {
  private int nss;
  private long fecha;
  }
• public class salidaCotizaciones {
  private int numeroCotizaciones;
  
  private boolean error;
  private int codigoError;
  private String descripcion;
  
  }
• public salidaCotizaciones obtenerCotizaciones(entradaCotizaciones entrada)

Esto permitita escalar el mensaje sin alterar la manera de invocar siempre que sea necesario.

• Usar Built-Data Types al disenar el XSD del servicio
• Si se pretende utilizar mensajes estandar (Hl7, eGov, xCIL, XNAL), evitar el uso de anyType en el envio del mensaje, es recomendable generar un modelo de negocio basado en los XSD que vienen con el estandar.
• Muy importante, definir los elementos para el manejo de errores, que permitan manipular la respuesta de acuerdo a las condiciones que se presenten
  
• private boolean error; // describe si existie o no error
  private int codigoError; // indica el tipo del error
  private String descripcion; // describe que fue lo que sucedio
  

Como veran son muy simples, pero son la base para generar Servicios Web manejables y escalables en el mensaje.

Va pues, comentarios bienvenidos :)

Por una integracion mejor, hasta la vista!

Tuzo

La culpa no la tiene el servicio sino el que lo hace Web Service

Hace un par de días hubo una acalorada discusión en relación a un proceso de integración entre dos sistemas: el expediente clínico electónico (ECE) y el sistema que se encarga de administrar a los usuarios de los diversos servicios de centros deportivos y sociales.

Resulta que los web services que expone ECE se definen en el correspondiente WSDL de la sigte manera:

<s:element name="CargaReferencia">
 <s:complextype>
  <s:sequence>
   <s:element minoccurs="0" maxoccurs="1" name="docHL7Referencia">
    <s:complextype mixed="true">
     <s:sequence>
      <s:any/>
     </s:sequence>
    </s:complextype>
   </s:element>
  </s:sequence>
 </s:complextype>
</s:element>

Y del otro lado se tiene

<s:element name="procesaOci">
 <s:complexType>
  <s:sequence>
   <s:any/>
  </s:sequence>
 </s:complexType>
</s:element>

Es decir. Técnicamente reciben cualquier cosa (<s:any/>).

Hace un poco más de un año, se realizó una junta para evaluar una propuesta de arquitectura para los servicios del ECE. Lo curioso es que pasado el tiempo siguen en las mismas.

¿pa'qué definir un contrato? Le pasamos cualquier cosa. ¿pa'qué validar contra un esquema? La validación la hacemos con un flujo o mejor aún: tirando código (que se factura por hora). No tiene ningún caso desacoplar, incluso cuando existen appliances para validar esquemas.

El chiste del outsourcing es quemar horas reinventando el hilo negro, divagando en arquitecturas y pelearse entre sí.

En fin, la culpa no la tiene el servicio.

Finito.