Un blog de interoperabilidad recomendable

Encontre este blog de una persona llamada Jesus Rodriguez

Me llama la atencion el alto nivel tecnico que tiene, y la cantidad de temas de los que habla

Configuración de Rails y SQL Server

La naturaleza multiplataforma de Ruby On Rails nos demanda adecuarnos a todos los ambientes de ejecución disponibles aún y cuando estos no sigan la filosofía del software libre.

Un ambiente que se va a presentar muy comunmente es Windows y SQL Server.

Entonces he aquí la receta sencilla y probada para soportar SQL Server dentro de Rails.

Primero, habrá que descargarse la gem ruby-dbi desde http://rubyforge.org/projects/ruby-dbi . ruby-dbi es un mecanismo de acceso a datos inspirado en Perl::DBI. En la gem viene incluido el soporte a varias bases de datos y durante el proceso de instalación se selecciona cuales se van a soportar.

La descarga es un archivo .tar el cual se expande en un directorio desde el cual ejecutamos las siguientes instrucciones:


# primero configuramos el ambiente para usar ActiveX Data Objects (depende de win32ole)
c:\>ruby setup.rb config --with=dbi,dbd_ado

# la llamada de siempre
c:\>ruby setup.rb setup

# finalmente la instalación
c:\>ruby setup.rb install


Con esto ya tenemos la capacidad de acceder a SQL Server desde Ruby. Ahora falta configurar SQL Server para que permita conexiones mediante usuario/contraseña. Para esto configuramos el modo de autenticación "mixed" dentro de las propiedades de seguridad del servidor.

A continuación se crean el login de SQL Server y la base de datos asociando el login como dbo de la base recién creada y se crea el proyecto rails como de costumbre.


c:\>rails proyecto


Después se actualizan los datos del archivo config/database.yml


development:
  adapter: sqlserver
  database: database_development
  username: user
  password: password
  host: .\SQLEXPRESS


Esta configuración funciona con las versiones 2000 y 2005 de SQL Server. La diferencia que he encontrado es el manejo de valores nulos en columnas de tipo integer. En SQL Server 2005 sustituye los valores nulos con ceros mientras que en la versión 2000 funciona correctamente.

Finito.

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

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.