web service de complejidad innecesaria

Da la necesidad mas apremiante cada día de tener redes inter-conectadas,

es evidente que se necesitan mecanismos ágiles y sencillos para permitir

que la información fluya de forma sencilla y segura entre los diferentes puntos de

la red.

Hay sin dudas múltiples formas de hacerlo , pero de forma general existen herramientas  diseñadas específicamente para estos propósitos, cada una de ellas cumplen a cabalidad con la misión para lo cual fueron hechas, unas para brindar seguridad, otras para el transporte de datos, otras para manejar la conectividad, protocolos de transporte, seguridad, conformación etc.

Es decir hay de todo para todo.

Entre los modelos de integración de redes saltan a la vista como notables VPN en cualquiera de sus sabores para brindar seguridad, Webservice del tipo Axis2 o Httpclient para la integración, tcp/udp como protocolos de conexíon

etc.

Sin embargo en el ejercicio de las integración se viene notando una fuerte tendencia a involucrar en el modelo de integración es decir en el webservice , httpclient, capas de seguridad, encriptamiento, protocolos de comunicación e incluso reglas del negocio.

Esto hace que cuando se pretende integrar dos redes, el "cliente", tenga

aprenderse las reglas del negocio de las contra-parte, con voluminosos manuales, para aprenderse una capa "artificial de integración" para poder usar los mismos esquemas de encriptamiento, algunas veces créanme muy, pero muy rebuscados, reglas del negocio que deberían ser transparentes para el usuario y un largo etc, de abuso  del esquema de integración por webservice.

Y si ha este se le añade, que entregan "APIS" algunos llamados incorrectamente "DTOS", específicos pre-compilados o no, que vuelven la tarea de integrarse una trabajo de pesadilla, peleando por tratar de reproducir el escenario en que "servidor" se ingenio esa maravilla de integración". peleando con el lenguaje y versiones del mismo sobre un sistema operativo especifico, cosa bastante peculiar y que dice algo sobre el integrador, los webservice "deben ser transparentes al lenguaje de programación y al sistema operativo " para eso fueron hechos.

Es menester informar que los webservice en general si fueron bien elaborados,

solo deben constar de unos procedimientos, rutinas  o procesos como los quieran llamar que se almacena en los generadores automáticos de stubs en el procedimiento general "CALL" y solo consta de la llamada a los procedimientos y un generador llamado STUB, que lo único que contiene son

los SETTER y GETTER de las variables de los procedimientos llamados, nada

mas.

Y que se me tira de la lengua podriamos decir que para un weservice bien conformado   aplica a que los webservice en general generan

archivos XML, siglas en inglés de "eXtensible Markup Language" (lenguaje de marcas extensible), no hacen nada por cuenta propia. Simplemente son una forma de almacenar datos para que otros programas puedan leerlos fácilmente.

En teoría  debes poder abrir, editar y crear un archivo XML con cualquier editor de texto. XML, a veces es así de sencillo otras  puedo usar

generadores de cliente como wdsl2java o Nusoap, para como decía Kiko del "chavo", evitarme la fatiga.

También aconsejan enormemente los creadores de los webservice como Axios2 pasar las variables  STRING o en su primitivas , integer y boolean,

Nada de esos arreglos rebuscados de arreglos de arreglos de vectores que son listas de arreglos complex , que ve uno en ciertas "APIS" y que se ve a a gatas

para que adivinar que querían hacer con semejante maravilla  de ingenio , creatividad y alta ingeniería, no nos pasemos de listos tratando de enseñarle al webservice hacer su trabajo.

También se debe tener claro que un web service solo debería constar de los siguientes procedimientos y en lo posible deberían ser auto definidos y auto explicativos,porque se buscan cada nombre para los procesos y variables que valgame Dios.

1. Proceso de conexión

2. Proceso de autenticar  credenciales de ingreso

3. Proceso(s) de paso de la información de la integración en cuestión 

4. Proceso de respuesta de la conexión y del envío y parámetros.

5. Proceso de cierre de conexión

De forma esquemática el programa para pasar una compra podría lucir algo como así donde fecha,consecutivo,cliente,producto,valor debería ser lo único a pasar de forma directa,Sin cálculos  ni llamadas a funciones externas.

*********************************************************************

 respuesta=conexion("http://miservidor.com?wsdl",usuario, contrasena);

 if (respuesta)

   {

     response=compra(fecha,consecutivo,cliente,producto,valor)

   }

 else

   {

      print ("error: no se estableció conexión");

      return ;

   }

 if (response != "0k")

   {

      close()

      print ("error:" + response) ;

      return;

    }

 close() ;

return;

**********************************************************************

Y eso es todo.

Las cosas simples y semillas no solo agilizan los procesos sino que ayudan a los negocios y permiten que estos evolucionen y crezcan.

Recordemos que nos todos somos geniales ni especialistas en adivinar el pensamiento del Mega Integrador.

Por último:

Quiero recalcar que una "genialidad de estas" le puede costar a la empresa proveedora del "servicio" mucho dinero en perdidas porque los clientes viven muy ocupados para malgastarlos en desenredar esos galimatías y prefieren perder las perlas por no ensartarlas.