Software Factories & SOA

El concepto de Software Factories, planteado por Jack Greenfield plantea un modelo para construir software a partir de combinar modelos, herramientas, patrones y frameworks que permitan automatizar el desarrollo de software. Este diagrama que pongo, es la ruta de lectura del libro








La idea es, en lugar de poner en documentos todo el proceso, hacerlo vivir por medio de un software factory.




Es posible hablar del concepto de un software factory que permita automatizar el proceso de implantar un sistema de nomina o inventario. Es como dar una plantilla de un proceso y ajustarlo al punto en particular. Este concepto puede tumbar a los ERPs facilmente, o mejor, ojala los gigantes de los ERPs lo pudieran entender


Pero voy a un punto interesante, y continuando mi entrada de "ideas, ideas"

Estaba pensando ultimamente en un IDE que permitiera completar todo el ciclo de SOA, es decir, con un wizard que funcione asi
1. Tomar una aplicación existente de tu organización y hacer que se convierta en un servicio
(dar next)
2. Seleccionar, la infraestructura de SOA en la que va a ser publicado:

+ Como servicio del ESB
+ Como dato del ISB (information service bus)
+ Como regla de negocio del Rule Engine Broker
+ Como metadato del Registro UDDI
+ Como documento del repositorio documental
+ Como servicio de presentacion (mashup) del portal
+ Como proceso de negocio en el repositorio del BPM
(seleccione uno o mas)
3. Seleccionar las funciones de la aplicación que van a ser exportadas
4. Opciones avanzadas, personalización por cada tipo de servicio a ser publicado
5. Dar Finish para generar servicios

¿Que facil suena?
Ya me imagino la complejidad del pseudocaso de uso que acabo de narrar. De entrada el IDE va a necesitar varios GB de RAM para ejecutarse

Creo que la idea no debe ir por ahi
Cada opcion del "Wizard" que indico, equivale a un proceso de desarrollo para generar componentes de integración. En este blog hemos hablado de los antipatrones, y por supuesto hay patrones para construir dichos componentes

Entonces, por que no hacer un software factory por cada tipo de servicio, es decir, por dominio del problema y que plasme los patrones, frameworks que hemos hablado
Cada software factory, al ser una plantilla puede irse ajustando por cada tipo de aplicación que está integrando
Y el software factory ya ajustado, arrojaria distintos tipos de componentes de integración

Asi ya no son necesarios los wizards

Y ahora piensean, los software factories tienen como caracteristica el que se pueden ensamblar entre ellas, se puede hacer un pipeline de factories y se crean software factories compuestas

Es decir, se puede hacer todo un proceso de desarrollo de servicios de integración a partir de software factories

¿Ya esta la visión, ahora quien empieza a concretar?

FONASOL: Pendiente

Pues bien, el FONASOL concluyó el sábado y ya tengo un bonche de recuerdos más que atesorar, nuevos amigos que conocer y algunas fotos que compartir.

Definitivamente es una historia para contar por episodios. No se desconecten.

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