Mostrando las entradas con la etiqueta SOA. Mostrar todas las entradas
Mostrando las entradas con la etiqueta SOA. Mostrar todas las entradas

martes, 24 de mayo de 2022

De transformación tecnológica en transformación

Hola queridos 3 lectores, hace mucho que dejamos su 3 autores abandonado este blog, pero nunca es tarde  para seguir dejando escrito lo que vamos viendo en este mundo llamado tecnologias de la Información.

Continuo en la Institucion de Salud, la más grande de latinoamerica, con otras responsabilidades, ahora del lado de la operacion que soporta todos los sistemas.

Hace poco tuve la visita de un amigo que platicando con él me decia que como he vivido estos años en esta institución y espontaneamente le dije de ola en ola, y le conte un poco de mi historia.

Aún recuerdo cuando por casualidad de la vida, llegue al mundo de los sistemas, fue por allá de 1994 cuando estudie el bachillerato tecnológico para "Técnico Programador Analista", y ahí empezó la magia con el "Hola Mundo" en COBOL y el 000100 IDENTIFICATION DIVISION.


En esos 3 años, empece a conocer COBOL, PASCAL, C y C++, cada uno con su encanto, en Sistemas Operativos conocí el MS-DOS y hasta programar en ventanas y eventos con clics en Visual Basic.

En poco tiempo me vi envuelto en la magia de una carrera llamada Ing. en Sistemas Computacionales ( en el glorioso Instituto Tecnológico de Pachuca), donde aprendí grandes cosas desde profundizar en matemáticas, estadísticas hasta electrónica, algoritmos, y "nuevas" tecnologias, pero sobre todo aprendí que por mucho que trates de ir al día, la tecnología avanza demasiado rápido y el dificil seguirle el paso.

Eso mismo pasa en la industria, en las empresas que invierten en tecnología para soportar sus procesos de negocio,. En el poco tiempo de experiencia que tengo en este mundo, he visto nacer grandes transformaciones digitales.

Si tratara de resumir lo que he visto de mi experiencia sobre transformaciones y tratando de hacer un escueto roadmap podría resumir algo así:

PROCESAMIENTO BACK OFFICE ---> CLIENTE SERVIDOR ---> SERVIDORES DE APLICACIONES ---> INTEGRACIÓN DE SERVICIOS ----> DIGITALIZACIÓN ---> SERVICIOS EN NUBE ---> CONTENEDORES

En ese pequeño roadmap, muchas tecnologías han emergido como lideres desde los 70's a nuestros días, desde IBM  Mainframe, HP Tandems, SPARCs, X86, Servicios de Nube, Contenedores, Microservicios y sin mencionar los diversos lenguajes de desarrollo.

Como en el mar la vida es mas sabrosa, le he bautizado olas de Transformación Tecnológica, a lo que me ha tocado vivir y por raro que parezca siempre observo que lo de moda es los "LEGADOS" y como usas esa información para REUTILIZARLOS o REEMPLAZARLOS con las "nuevas" tecnologías.

El ritmo con el que avanza la tecnología y los visionarios tecnológicos demandan nuevas cosas es muy rápido, en ciclos promedio en 6 años lo nuevo se vuelve legado y lo legado obsoleto, y sin embargo... se mueve.

El mantener los legados es un tema de alto costo para las empresas, ya que debes de manejar contratos extendidos de soporte y tener demasiados especialistas para atender las necesidades que aun en fechas recientes el negocio te demanda.

En fin, el conclusión, creo que debemos de aprender a vivir con este ritmo y construir en la actualizad soluciones robustas que soporten el paso del tiempo cuando estas se vuelvan un legado... así como  subirse y de ser posible dirigir los ciclos de transformación tecnológica que estamos pasando en cada una de sus empresas o instituciones.

Saludos

lunes, 30 de septiembre de 2013

En el 2013 que ha pasado

Bien, pues este blog fue terriblemente abandonado por todos sus autores , je Aunque les digo, que los tres autores siguen vivos y coleando El Tuzo sigue en la institución de salud que yo deje en julio 2012. Chillicoder sigue pegando duro a Rails ... Técnicamente que ha pasado por mi vida de bytes He aprendido Node.js Me he metido a TOGAF y me he certificado, al igual que Archimate... Me adentre a ver los puntos de arquitectura de software y aterrizarlo con patrones de Fowler y POSA ... Y los MOOC me han ayudado mucho . Gracias a ellos se puede aterrizar el tema de Big Data, Programación funcional, arquitectura empresarial Estoy con deseo de un bocado de implantar una arquitectura empresarial que haga sentido a la organización que decida esa aventura ... No me he metido al asunto de emprendedores, aunque sigo de cerca varias ideas Gamification me inspira para algo así El tema de software factories aun no lo abandono como un concepto viable para implantar DSL, DDD, patrones SOA no reniego de ella, solo veo cuanto falta por rascar en el tema ... Sigo renegando de programadores, arquitectos y similares que son soberbios o que no hacen bien su chamba El Tuzo y otro nuevo amigo, Rafael Cruz, agregaron otra comunidad de arquitectura a la mexicana ...

martes, 25 de septiembre de 2012

De vuelta a la actividad

Hola queridos 3 lectores,

Hasta hace unos meses me daba a la tarea de empaparme de conceptos de arquitectura empresarial, estudiando y leyendo con el fin de reforzar algunos proyectos que llevo a cabo, en esta ardua vida de búsqueda de oportunidades.

Me he topado en los últimos meses a diferentes retos tanto técnicos como laborales y de cada uno de ellos voy aprendiendo.

No había tenido oportunidad de agradecer a gusdelact por todo el apoyo que me brindo durante casi 8 anios de convivir juntos y enfrentar varias responsabilidades, he aprendido mucho de el, ha sido mi guru. En este largo camino de lo profesional te deseo mucha suerte mi estimado.

Ahora he quedado al mando por decirlo de una manera de un equipo de trabajo que sigue con la filosofia de este grupo de locos y eso me hace ser mucho mas responsable y cuidar al equipo. Sigo aprendiendo día con día que lo valioso que es el crecer tanto humanamente como profesionalmente para alimentarte de los buenos resultados.

Sigo aprendiendo que por mas que digas ser "algo" o saber de "algo" no vale mas que los hechos y el trabajo. Aprendo que a veces tienes que ver el traje del emperador aunque sea un poquito con tal de que te dejen trabajar. Aprendo que los "Pseudo Arquitectos"siguen siendo arrogantes y hasta tontos, pero que hay que lidiar con ellos. Creo en el trabajo y la honestidad de la gente que en verdad desea aprender por el deseo de hacerlo o no por el ego del saber.

Actualmente me encuentro con varios retos profesionales en mi institucion y fuera de ella cosas interesantes de TOGAF, de ALM, de SOA Reference, etc que les ire platicando poco a poco.

Espero nos vuelvan a leer y como dice un clásico ....

Por una integración mejor.

Hasta la vista

Tuzo



viernes, 1 de julio de 2011

Entre Middleware te veras

Que tal muchachos, feliz viernes!!!! yeeeah

Hace algunos meses por necesidades de un proyecto (por cierto muy interesante), nos invitan a participar en la parte de arquitectura de integración, que dicho sea de paso es usando plataforma OpenSource.

Herramientas Middleware muy interesantes son ocupadas dentro de la arquitectura algunas de ellas:
  • MDM - Talend Community Edition: Un excelente propuesta de Bases de Datos Maestros.
  • Application Server: Jboss
  • Enterprise Service Bus - Jboss ESB : De los ESBs mas intuitivos que me toco trabajar.
El proyecto involucra varios retos que si se plantean de manera general, son muy conocidos en el ámbito de integración en la industria, aquí algunos:
  • Comunicación con Bases de Datos Legadas
  • Comunicación con Aplicaciones Legadas que usan COBOL
  • Comunicación con una MDM
  • Comunicación con un BPM
  • y le podemos seguir.
Dentro de la arquitectura, se tomo la decisión de usar al ESB como mediador de todas las peticiones a los sistemas legados o propietarios (tal como se hace comúnmente), lo cual resulto muy interesante, ya que seria el ESB quien tendría que manejar conceptos de EIP en este sentido, tales como transformaciones, ruteo basado en contenido, Pipelines, etc.

Particularmente los Post siguientes, serán hablando del tema de Jboss ESB y estarán enfocados a como resolver ciertos escenarios de integración de los cuales comúnmente me he topado en estos ya 7 años como Arquitecto/Ingeniero de Integración de Aplicaciones, la mayoría trabajando con middleware de BEA (Aqualogic ESB, ALDS) ahora ORACLE (SOA Suite)

Les adelanto algunos temas puntuales del Jboss ESB que vamos a tocar en el uso de:
  • org.jboss.soa.esb.actions.soap.proxy.SOAPProxy
  • org.jboss.soa.esb.actions.routing.http.HttpRouter
  • org.jboss.soa.esb.actions.transformation.xslt.XsltAction
  • org.jboss.soa.esb.actions.ContentBasedRouter
  • org.jboss.soa.esb.actions.SystemPrintln
Cada uno de estos temas los veremos en conjunto con ejemplos de su uso.

Por una integración mejor, nos vemos pronto.

Saludos Tuzo




domingo, 23 de enero de 2011

Integración a la mexicana Recargada

Hola!

Tendremos todavía lectores?

Han pasado varios años desde que creamos este blog. El Tuzo y yo seguimos trabajando juntos. Chillicoder ha recorrido un camino aparte, pero bien metido a Ruby

Y de Ruby quiero hablar

Estoy este fin de semana preparando clases, inicio en la ULSA, programación Web es la materia. Después de observar como ORACLE ha llevado a Java, he decidido por primera vez en mis casi 14 años dando clase, no impartir sobre la plataforma Java. La última vez trate sobre GRAILS

Retomando las ideas de Bruce Tate, en su libro Beyond Java, he decidido aplicar el camino, al igual que Chillicoder.

Durante ya los casi 5 años en los que Ruby on Rails ha evolucionado, encuentro una plataforma madura y bien diseñada.

Aunque seguimos usando Web Services con SOAP, WSDL y JMS; y seguimos usando el Service Bus de ahora ORACLE; ya tengo un rato que me percato de la existencia de REST y como simplifica el desarrollo

Me doy cuenta que la visión de llenar Internet con servicios Web basados en SOAP no prospero. Me encuentro al contrario, toda una serie de servicios implantados por Google, Amazon, Twitter, bajo un diseño simple

Y de cloud computing me encuentro conceptos similares a los planteados en los inicios de concepción de SOA. En algún blog anterior hable del concepto de X As a Service. Ahora, el tener la capacidad de exponer Hardware y Sistema operativo como Servicio, supero las expectativas de esos tiempos

Ahora hasta tengo un teléfono movil inteligente como los llaman hoy, un iPhone. Ya he probado el progamar sobre BlackBerry y iPhone. Me falta Android

Me percato, que el concepto de servicio no se ha perdido. En muchos lados, veo como varios "computologos" hablan de la muerte de SOA o de que ya no está "in". Me da risa esa visión de consultor que no aplica nada de lo que escribe, tipo Gartner

En una platica que oi de Mike Rossen, hablaba él de experiencias en implantaciones de SOA. Al final, la conclusión es que las organizaciones posiblemente no implantarán en su totalidad SOA. Pero la industria de software si está basando fuertemente en dicho concepto

En el temario de la materia a la que me refiero, incluí varias ideas. Espero que mis alumnos absorban los conceptos básicos para llegar a tocar los temas de servicios. Pongo aquí la liga de la presentación http://sites.google.com/site/cibgusdelact/progweb8012011/tema0/Introduccion Programacion Web.pdf

Me doy cuenta de nuevas oportunidades de trabajo, ya sea en el actual o pensar en nuevos lugares. Veo que se necesitan personas técnicas que sepan de este tema, que tengan experiencia en pasadas tecnologías que trataron la misma visión

De ahí que llamo a esta entrada, Integración Recargada por que veo nuevas posibilidades por aprender y de ahí aplicar

Empezando el 2011, y con retos interesantes en la chamba

martes, 27 de octubre de 2009

Empezando la implantación de SOA

Voy a tratar de ir actualizando de manera frecuente el blog, orientado a narrar las experiencias en la implantación de SOA.

De entrada, la semana pasada me ví envuelto en el típico caso de un Web Service que no conocía, pero que se volvió crítico para la operación de la institución donde trabajo. Al final, me querían colgar el muerto a mí, argumentando que yo manejo la interoperabilidad. Como siempre, el dueño del servicio vela por cumplir con necesidades propias de su línea de negocio.

Estoy arrancando un proyeto de Gobernabilidad SOA, en el cual se va a definir el proceso de desarrollo basado en servicios y la estructura de un posible Centro de Excelencia SOA.

Y un montón de trabajo para estabilizar la infraestructura. Me dí cuenta que el ESB podríamos tenerlo montado en 12 computadores tipo SunBlade

Por cierto, cada vez que veo el resultado de que Oracle comprara a BEA, me doy cuenta que fue un error. Los cuates de Oracle solo quieren vender, pero sin ni siquera saber conceptos básicos como middlware, BPM o servidor de aplicaciones. Con ganas de cambiar TODO lo de Oracle a software libre.

martes, 16 de junio de 2009

¿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

domingo, 29 de marzo de 2009

SOA no solo es Tecnología de Información

Arquitectua Orientada a Servicios ...

Algunos ya dicen que SOA está desapareciendo, que ha sido un fracaso.

La verdad, creo que mucho de lo que ha pasado es que la industria ha visto el implementar SOA como comprar e instalar productos, o como una iniciativa de Tecnologia de Informacion, o por construir WebServices se dicen SOA.

Eso lleva a que al final, para la organización no hay mucho cambio con respecto a la manera como la tecnología de información se implanta.

Es típico, que en cualquier organización, primero se empieza a diseñar un servicio con procesos manuales. Una vez que se empieza a operar dicho proceso, se dan cuenta que tienen muchas labores dignas de automatizar, y van y solicitan a sistemas, una nueva aplicación.

Y por desgracia, cuando llega al área de sistemas, se enfoca a que dicha aplicacion solucione para ese proceso, sin tomar en cuenta todo el contexto de la organización. Y luego cuando se dan cuenta los de sistemas, a jalar copias de base de datos de otras aplicaciones, a intercambiarse archivos planos, interfaces punto a punto y dependencias altas entre las aplicaciones.

Y mientras, la organización perdiendo oportunidades de oro, teniendo escenarios donde por falta de una integración entre sus sistemas, se tardan un largo tiempo en obtener resultados.

He ahi la importancia de una arquitectura comun para las soluciones de tecnologia de información. El chiste de la arquitectura es poner orden, organizar.

Ahora, si dicha orientación se da, pensando que se construyen servicios que permiten automatizar las actividades de los procesos, entonces lo que se puede provocar es que la tecnología se vaya constituyendo a través de servicios de negocio.

El camino que deriva la creación de un servicio debe ser asi:

* Estrategia de negocio u organización. Define los objetivos a alcanzar.
* Servicios de negocio. Manera como la organización entrega un bien o servicio a sus clientes,empleados y/o proveedores.
* Capacidades de Arquitectura Empresarial. Las funcionalidades de tecnología.
* Plataforma de Tecnología de Información. Componentes de software y hardware.


Es decir, cualquier servicio, se origina por alguna necesidad de negocio y tiene como vista, compartir y reutilizar información.

Pero las personas que estan en la organización, en lugar de concebir la automatización de sus procesos a través de aplicaciones, lo hacen a través de servicios.

Pero a ellos no les debe importar si esta en un sistema UNIX con Oracle y Java, o si está en Windows con SQL Server y C#. Lo que debe importar es la información que ofrece y las operaciones de negocio que realiza.

En resumen, SOA no es algo nuevo. Es lo que siempre se ha buscado como, lograr que la tecnología de información sirva al negocio.

SOA es una iniciativa de negocio guiada por el departamento de tecnología de información, que transforma la manera como la información se hace disponible, que permite que el area de tecnología de información ya no sea de apoyo, si no que se convierta en sustantiva.

Es dificil para alguien que ha tenido una preparación de ingeniera de sistemas, llegar a estas conclusiones.

Normalmente nos acostumbramos a resolver problemas técnicos, de hecho a veces perdemos el foco y hacemos soluciones técnicamente complejas. Pero en algunos casos, ni sabemos que problema del negocio estamos solucionando o cuanto es el impacto (y tambien cuando falla el asunto, no somos capaces de medir).

En cambio, enfocado a servicios, el desarrollador de soluciones sabe claramente la contribución al negocio.

Asi que, dudo que SOA sea un fracaso. El reto es cambiar la manera de pensar de la gente de sistemas y de los usuarios, en los cuales ya se deje de ver la tecnología de información como algo opcional.

sábado, 3 de enero de 2009

Bolero de Ravel y Arquitectura Orientada a Servicios

Desde hace un rato se me habia ocurrido esta idea, en un concierto donde tocaron el Bolero de Maurice Ravel.

Todo la obra esta llevada por un solo patron musical, sin embargo es interesante notar como los distintos instrumentos de la orquesta lo interpretan.

Y al final, gracias al poderoso concepto de la armonia (lo que para los nosotros los de software es el equivalente de arquitectura) se puede hacer que toda la orquesta utilice el mismo tema y de un efecto total.

Y de ahi es donde empieza la analogia.

Si el patron musical se toma como analogia de un servicio, en el cual, sea cual sea el rol del componente de software, se debe de hablar de una manera estandar y comun.

Para poner el patron comun, se pone un canal de integracion (el service bus) que es responsable de recibir, procesar y transformar mensajes. Si se le dice a todos los demas componentes de software como usar a dicho canal de integracion (ejecutar el patron musical), se puede empezar con la ejecucion.

Entonces llega una aplicacion Java y toma el patron como modelo. Si quiere informacion debe publicar un mensaje a un canal de integracion. Y la aplicacion Java, para dar informacion a otros, debe publicarse como servicio al canal de integracion, ya sea utilizando JMS o SOAP, de manera sincrona o asincrona.

Y por otro lado, llega un sistema de base de datos, el cual puede exponer sus registros como servicios, e intercambiarlos como XML, los cuales deja disponible via el canal de servicios, de nuevo utilizando SOAP.

Y de repente se une un sistema ERP o un CRM. Aunque dichos sistemas ya estan hechos, tambien necesitan informacion y compartir informacion con otras aplicaciones. Cada vez que realizan una actividad, reportan al canal de integracion, un evento de negocio. Dan de alta a un cliente, a enviar un mensaje al canal. Que en una aplicacion se refleja un movimiento de dinero, el ERP recibe un evento de negocio.

Y entonces, es posible combinar las aplicaciones Java, las bases de datos, el ERP y el CRM. Y entonces llega los servicios compuestos a la arquitectura, que ensamblan a todos los componentes entre si y utilizan al canal de integracion para orquestar, transformar y comunicar a todos los servicios nucleo entre si.

Y muchos de esos servicios compuestos, representan los servicios que da una empresa, o servicios de negocio. Cada servicio de negocio es una actividad de un proceso. El proceso necesita ejecutar actividades, tomar informacion de donde necesite. Entonces se incorpora a la arquitectura el administrador de procesos de negocio, que permite concebir todas las actividades de la empresa como procesos. Se pueden medir, se pueden simular, se pueden mejorar. Y sigue hablando el mismo patron, enviar mensajes al canal de integracion, utilizar protocolos comunes. El proceso toma informacion de los clientes, refleja operaciones en finanzas, toma decisiones del sistema de recursos humanos, crea nueva informacion.

Y entonces, cada servicio compuesto, se expone como una interface de usuario a un portal. En el portal los usuarios pueden acceder a toda la informacion que quieren, hablando con los servicios, siguiendo el mismo ritmo que los anteriores componentes.

Y eso permite que los usuarios del portal tengan voz propia, que usen la informacion para mejorar su trabajo, que pueden ensamblar su informacion. Y tienen agilidad para cambiar su trabajo.

Y asi se logra la federacion de todo el software de una organizacion!! Todos hablando de la misma manera, organizados para un fin comun, de acuerdo a la arquitectura empresarial y ayudando a iniciar el cambio en una organizacion muy grande pero que le da la oportunidad de decir: !Puedo cambiar!

Los dejo con un video con la version abreviada del Bolero de Ravel, pero bastante bien interpretado, y con voces humanas

domingo, 28 de septiembre de 2008

Web Services con Mule CXF y Spring

Hola que tal

Despues de un rico desayuno en un agradable domingo en casa de mis padres, saque del polvo mi cuenta de integracion y pues aqui estamos; Antes de entrar en materia he de comentarles que han pasado muchas cosas interesantes en el trabajo, una que me tiene muy entusiasmado es el proyecto de SOA, mas alla del nombre, es interesante ver como gran parte de la comunidad de sistemas tiene su propia definion de SOA lo entendemos de diferentes maneras (no quiero pensar en la gente que es de negocio).. es un reto interesante en lo personal ya que se derivan muchas cosas desde la parte tecnica como la parte de venta la parte de convencer todo lo que vamos a estar haciend... en fin. Estuve leyendo el ultimo post de gustavo y comparto la opinion acerca de nuestros hermanos de la india, asi como en mexico, en la india hay gente muy trabajadora, muy comprometida y sobretodo sencilla, ya les contare mas detalle lo que estamos haciendo por aca en el trabajo.

Bien pues despues de lo anterior..... el post de hoy habla de de como combinar Spring, CXF y MULE, para generar y exponer servicios web usando el ESB Mule.

Bien, en muchas ocasiones me ha tocado ver como compañeros del trabajo les encargan generar un servicio web que exponga funcionalidad de negocio y me sorprende ver como tardan mas en generar todo la talacha que implica el exponer el servicio, que en lo que generan sus servicios de negocio.... creo que todo lo anterior tiene una explicacion, no estamos acostumbrados a trabajar con frameworks. Hoy en dia existen framworks como spring que como dicen en muchas paginas "hace la plomeria el plumbing", este tipo de marcos de trabajo nos permiten concentrarnos en generar nunestros componentes de negocio. En el siguiente ejemplo vamos a ver como exponemos un POJO como servicio web.

Bien los ingredientes son:

  • La distribucion de Mule (que esta basada en spring)
  • Si gustan usamos Eclipse Mule IDE
Es todo, ahora bien iniciamos pensando que tenemos un POJO sencillo basado en una INTERFAZ que realiza los siguientes calculos :D suma, resta, multiplicacion y division.

El codigo como sigue

public interface ICalculadora {
public float suma(float a, float b);
public float resta(float a, float b);
public float division(float a, float b);
public float multiplicacion(float a, float b);

}

y la implementacion

public class CalculadoraImpl implements ICalculadora {
public float division(float a, float b) {
if (b==0) return -1;
else return a/b;

}
public float multiplicacion(float a, float b) { return a*b;}
public float resta(float a, float b) { return a-b; }
public float suma(float a, float b) { return a+b; }
}

woow!!!, ahora bien si este pojo lo queremos usar con spring lo unico que necesitamos haces es su archivo de configuracion el application context:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

<bean id="calculadora"
class="ejercicio.CalculadoraImpl"
scope="singleton">
</bean>

</beans>

Ahora bien... hasta aqui nada nuevo... para los que han manejado spring no tiene nada de complicado lo anterior. Bien, pues vamos a hacer la pregunta que generalmente se coloca en el google "How do I expose my POJO as a webservice in Mule?", hay varios caminos... uno de ellos es usando CXF de apache para lo cual debemos de colocar una serie de anotaciones en nuestra clase y nuestra interfaz... veamos:

import javax.jws.WebResult;
import javax.jws.WebService;

@WebService
public interface ICalculadora {

@WebResult(name="suma")
public float suma(float a, float b);

@WebResult(name="resta")
public float resta(float a, float b);

@WebResult(name="division")
public float division(float a, float b);

@WebResult(name="multiplicacion")
public float multiplicacion(float a, float b);

}

y para la implementacion:

import javax.jws.WebService;

@WebService(endpointInterface = "ejercicio.ICalculadora",
serviceName = "Calculadora")
public class CalculadoraImpl implements ICalculadora {

public float division(float a, float b) {
if (b==0) return -1;
else return a/b;

}

public float multiplicacion(float a, float b) {
return a*b;
}

public float resta(float a, float b) {
return a-b;
}

public float suma(float a, float b) {
return a+b;

}

}

Las anotaciones usadas @WebService indican que la clase es un servicio web y @WebResult los valores a recibir. Estas anotaciones serviran para que CXF y Mule compongan el WSDL que describira nuestro servicio.

Una vez colocadas las anotaciones lo que sigue es generar nuestro archivo de configuracion de Mule mule-config.xml tal y como sigue:

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesource.org/schema/mule/core/2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:spring="http://www.springframework.org/schema/beans"
xmlns:soap="http://www.mulesource.org/schema/mule/soap/2.0"
xmlns:cxf="http://www.mulesource.org/schema/mule/cxf/2.0"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.mulesource.org/schema/mule/core/2.0 http://www.mulesource.org/schema/mule/core/2.0/mule.xsd
http://www.mulesource.org/schema/mule/soap/2.0 http://www.mulesource.org/schema/mule/soap/2.0/mule-soap.xsd
http://www.mulesource.org/schema/mule/cxf/2.0 http://www.mulesource.org/schema/mule/cxf/2.0/mule-cxf.xsd">

<spring:beans>
<spring:import resource="springContext.xml"/>
</spring:beans>

<model name="servicescalculadora">
<service name="Calculadora">
<inbound>
<cxf:inbound-endpoint address="http://localhost:65082/services/Calculadora" />
</inbound>
<component>
<spring-object bean="calculadora" />
</component>
</service>
</model>

</mule>


Bien pues ya tenemos todos los componentes, ahora vamos a ejecutar nuestro archivo de configuracion de mule, si lo hacen si el ide consideren todas las dependencias para que el poryecto compile:

MULE_HOME\mule -config mule-config.xml

Se ejecuta el servidor de mule al finalizar debemos de ver algo como lo siguiente:

INFO: Setting the server's publish address to be http://localhost:65082/services/Calculadora

Bien, pues listo! ya estsmos en posibilidades de ver el WSDL

http://localhost:65082/services/Calculadora?WSDL

Ahora solo es cuestion de ejecutar pruebas con nuestro servicio web, en lo personal yo uso SOAP UI, pero pues lo pueden hacer con cualquier herramienta que pueda mandar peticiones hacia sua servicios web.



Bueno pues es todo, esperemos que les sirva, quejas y sugerencias seran bien recibidas.

Por una integracion mejor, hasta la vista!!

Tuzo

lunes, 14 de julio de 2008

Business Capabilities y SOA

Hace como 3 meses, se dio el foro de Arquitectura que organiza Microsoft

Puede solo ir a las conferencias de las 9 a.m.

Y el segundo dia fue muy bueno, ya que expuso Arvindra Sehmi sobre el concepto de "Competencias de la Empresa y Arquitectura Orientada a Servicios" ( o en ingles, Business Capabilities y SOA)

Durante su platica empezo a contestarme las preguntas que tanto me han inquietado, sobre una metodologia para tomar el modelo de negocio de una empresa y a partir de eso especificar la estrategia SOA.

Esta metodologia se me hace solida. En el blog de Arvindra encontraran detalles sobre como verlo

Mientras, yo sigo buscando la aplicacion del modelo de Competencias de la Empresa, ya que estoy en el momento en el que tengo que tomar un rol en el cual debo ser quien entienda las necesidades de arquitectura de cuatro grandes proyectos que son el nucleo de la organizacion para la que trabajo. Creo que ese rol de manera formal se llama arquitecto empresarial, espero no estar pecando de presumido.

Les contare como me fue

miércoles, 5 de marzo de 2008

Con muchas cosas que compartir..

Hi folks.... pues regresando a dar un poquito de lata.

Ya con los primeros 2 meses del año que se fueron como agua...he de comentarles que este año trae consigo retos muy importantes tanto en lo profesional como en lo personal y hay que enfrentarlos como dice una cancion... con alma vida y corazon

Pues a lo que me truje chencha dijeran...

Hay muchos temas que me interesa tocar: SOA, Arquitectura Empresarial, Continuar con los ejemplos de Integracion de aplicaciones, hablar de algunos modelos y marcos de referencia, mas de ESBs Open Source, en fin...

Estos 2 dias estaremos asistiendo el buen Gus y su servidor a platicas de Cutter Enterprise Architectre Summit, de entrada las platicas del dia de hoy me parecieron bastante interesantes en especial la denominada "Enterprise Architecture By Example" el ponenete Mike Rosen.

Ya hablare mas a detalle de AE, pero de entrada creo que hoy dia estamos entrando a un punto interesante en la parte de Arquitectura, mas alla de la Arquitectura de Software (que como parte de la AE no deja de ser importante), existen diferentes aspectos que que necesitamos tomar en cuentas al definir una arquitectura empresarial, Mike lo denomina Enterprise Architecture Stack, y se compone principalmente de 4 arquitecturas:
  • Arquitectura de Negocio: Cadenas de valor , Modelos del negocio, Portafolio de servicios, Procesos de negocio
  • Arquitectura de Informacion: Informacion que soporta la toma de decisiones, Modelos de datos del negocio, informacion de datos operacionales y transaccionales
  • Arquitectura de Aplicaciones: Informacion de las responsabilidades de los componentes que forman parte de una aplicacion
  • Arquitectura Tecnologica: Harware, software, Infraestructura de Red, Data Centers
Lo anterior sin dejar fuera a la Organizacion misma y a la gente que la compone.

Mike menciona tambien que existen un modelo para evaluar la Madures de una Arquitectura Empresarial, tal como lo manejan el CMMI o el SOA Maturity Model.. ya platicare de esto con un poco mas de detalle.

Bueno pues los dejo con una presentacion que me parecio interesante se llama: Pragmatic SOA by Arjen Poutsma, espero la visiten

Ciao

Tuzo

jueves, 22 de noviembre de 2007

Libro Open Source ESBs in Action

Por fin!

Con alegria me entere que ya salio un libro que trata de ESBs Open Source (Manning), el capitulo 1 esta disponible para lectura en linea. Mule ESB, Service Mix, Open ESB, Jboss ESB, Synapse son algunos de los que se mencionan en el libro.

Explorare su contenido y ya dare mis comentarios.

Existe otro libro de ESB pero este habla de Aqualogic Service Bus, el titulo del libro es: The Definitive Guide to SOA: BEA Aqualogic Service Bus.

Saludos!

Tuzo

martes, 6 de noviembre de 2007

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

miércoles, 12 de septiembre de 2007

Entre change management y pantallas verdes

Quizás este post debería estar más del lado de Tuzoftware .... Pero se vale... ;)

¿cuantas veces les ha tocado hacer un cambio en una aplicación? ¿Cuantas veces pensamos en las aplicaciones que se verán afectadas cuando cambiamos algo? ¿Quienes de nosotros tenemos un control de nuestras aplicaciones así como las dependencias que tenemos con otros sistemas?
¿Cuantas veces no les ha pasado que alguna área cambia versión de aplicación y las nuestras dejan de funcionar correctamente? nunca !!.. que bien!!! ... pero a los que nos ha pasado eso y fuera de los dolores de cabeza, a los jefes esperando, el tiempo encima.... todo, todo es desesperante.......... ahora combinen esa situación con una solución de integración mmm digamos ..... Mainframe si Mainframe, pantallas verdes, screen scraping, emuladores 3270... ¿Interesante escenario?

La finalidad de este post es tratar de mostrar una de las debilidades pienso yo, que existe en la integración de aplicaciones basada en captura de pantallas o screen scraping. Cabe resaltar que este tipo de integración tiene una ventaja importante: no es intrusivo en las aplicaciones a las que se trata de integrar.

Aquí en la empresa, tenemos varias interfaces basadas en este estilo de integración (échale un vistazo a esta liga ); como veras nosotros utilizamos Iway Telnet 3270, que es una serie de APIs que permiten interactuar con las pantallas verdes del mainframe... bien pues el punto flaco de estas interfaces es que están altamente acopladas por decirlo de alguna manera a las coordenadas, quien ha trabajado alguna vez con COBOL sabe de que le estoy hablando...

Bajo este esquema hasta un guión"-" te puede afectar (y mas si lo agregan de un día a otro :S, ahh y en la noche), sí, literalmente un guión te puede afectar.... eso fue lo que nos paso recientemente... se agrego un carácter a una pantalla de una aplicación dentro del mainframe y esto ocasiono que se movieran las posiciones de los campos, es decir, si para mi el campo 76 era NSS, ahora se había recorrido hasta la 78.... el punto delicado aquí es que la producción estaba parada mientras se detectaba el error, una vez que se detecto se dio marcha atrás a la versión de la aplicación mainframe....... mientras todo esto ocurría la operación se detuvo por al rededor de 3 horas...

Se aplico el cambio tal y como se debió de hacer desde un principio, es decir nos colocaron la versión de la aplicación mainframe en DESARROLLO hicimos los ajustes en nuestra interfase y liberamos a la par las nuevas versiones...

Todo el cuento anterior se pudo evitar teniendo un buen CONTROL DE CAMBIOS... se escucha tan sencillo y a veces trillado cuando nos hablan de esto en CMM, ITIL, RUP, en lo que ustedes quieran.... pero créanme que es muy importante...

Para muestra basta un botón... ¿recuerdas cuantos millones perdió TELCEL hace unos meses debido a un problema en su sistema?

Por una integración mejor, hasta la vista!!!

Tuzo

jueves, 14 de junio de 2007

The role of ESBs

Hola que tal

Cuando hablamos de implementar una solucion ESB en alguna organizacion, nos viene a la mente lo costoso que implicara hacer este tipo de proyectos..... en el mercado existen una serie de productos comerciales que ofrecen todas las capacidades que nos entrega un ESB, por mencionar algunos Sonic ESB, Aqualogic Service Bus... ya hasta microsoft ofrece con BizTalk una solucion ESB (segun je je.. sorry)... y el punto aqui es que las licencias anuales se facturan en millones de dolares.... me pregunto... ¿las soluciones ESB estan solo al alcance de grandes companias en el mundo? .. lo que no hemos hecho muchos de nosostros es voltear al mundo open source y ver que tenemos alternativas realmente interesantes como Mule ESB, Celtix, Service Mix, etc.. que bien implementadas se puede obtener un resultado realmente interesante comparado con las soluciones comerciales...

Mas preguntas....¿Como poder justificar una compra de una herramienta que cuesta millones de pesos? ¿Como justificar realmente el valor del modelo SOA? ..... para los que estan trabajando en dependencias gubernamentales (y con esto del decreto de austeridad) ..¿ como se puede de verdad reducir costos anuales de uso de licencias de software?...... quiza estas respuestas estan en las soluciones opensource ... ¿sera?

Bueno pues aqui les dejo una interesante entrevista en la que habla Ross Mason fundador de Mule ESB, acerca del rol de los ESBs...

Por una integracion mejor, hasta la vista!!


Tuzo... Campeon

miércoles, 6 de junio de 2007

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?

jueves, 24 de mayo de 2007

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.

miércoles, 23 de mayo de 2007

WEBCAST Data Services: Essential Foundation For SOA Success

Hola que tal

Hace unos dias me encargaron la mision de trabajar cosas de Data Services usando Aqualogic Data Service Platform.... pues bien, me encontre con un webcast que al menos en el nombre se me hace interesante.... espero lo puedan atender, la cita es el dia 30 de Mayo

Aqui los datos:

TITLE: Data Services: Essential Foundation For SOA Success
WHEN: May 30, 2007 at 2:00 PM EDT (18:00 GMT)
SPEAKER: Sandy Rogers - Program Director for SOA, Web services, and Integration Research at IDC
SPEAKER: Robert Eve - VP Marketing, Composite Software
SPONSOR: Composite Software
SITE: SearchWebServices.com

Sale pues ahi ta

Por una integracion mejor, hasta la vista!

Tuzo

lunes, 7 de mayo de 2007

De como la idea de servicios salvo un dia

Hola
El viernes pasado, estaba yo tranquilamente acabando de dar clases en la ULSA, cuando recibo una llamada...
Gus, se cayo Seguridata

Ja, cualquiera que vea esta entrada, parece que esta viendo una pelicula empezada

Les cuento rapido la historia
Ahi tienen que para donde yo trabajo, el IMSS, varios sistemas requieren de validar una secuencia PCKS7 y obtener un recibo criptografico. Para hacerlo, dependen de un servicio de PKI provisto por el software de una empresa llamada Seguridata

Hace casi 3 años, tuvimos la feliz ocurrencia de codificar ese proceso de verificacion y envio de recibo en un WebService. Dicho WebService fue escrito en Java y es el unico acoplado a las bibliotecas de dicho software. Pero para los clientes es transparente, inclusive se vale que generen su PKCS7 con un API distinto

Al principio, inclusive yo mismo, nos preguntabamos si no habiamos abusado del modelo de WebService. Al fin y al cabo, por que no entregarle a cada aplicacion su correspondiente biblioteca y que cada sistema la manejara como del Dios de los Bytes le diera entender.

Sin embargo, no se privilegio mucho esa filosofia, aunado a que muchos de los desarrolladores no tenian mucha cultura sobre el manejo de infraestructura de llave publica

Han pasado algunos años con dicho servicio en ejecucion. Sin embargo, la crisis mas fuerte se presento la semana pasada, el servicio de Seguridata se vio saturado (diria hiper-duper-super-saturado). Los administradores del servicio no tuvieron mas opcion que repartir la chamba entre varias computadoras y cambiar al host

Asi que el viernes, a las carreras por la contingencia direccione el WebService al nuevo nodo. Solo tuve que modificar a dicho WebService. Las aplicaciones que dependian de el, no tuvieron que ser reinicidas o redistribuidas.

He ahi la magia de la Arquitectura Orientada a Servicios. Desacoplamiento.

Si no se hubiera pensado asi, todas las aplicaciones hubieran realizado muchos cambios y con sus debidos riesgos.

Asi que despues del stress generado por la contingencia, respiere tranquilo y me di cuenta de la fortaleza del modelo

Desacoplen!! Quiza muchos de los que son pro la filosofia de la union libre me entenderan. Es dificil casarse con alguien hasta que la muerte los separe. Quiza para los humanos es muy factible,pero creanme que para los sistemas nada mejor que ser amigovios y solo regirse por el poderoso concepto de contrato o interfase