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, 27 de octubre de 2009
martes, 20 de octubre de 2009
WorkshopCamp Cd. de México
El BarCamp es una red internacional de "desconferencias" (eventos abiertos y participativos), cuyo contenido es provisto por los participantes. Se enfocan en aplicaciones web en estadios tempranos, tecnologías de código abierto y protocolos sociales. Sin embargo, este tipo de encuentros han ampliado su temática y actualmente incluyen eventos participativos y abiertos alrededor de temas sociales, artísticos, educativos... con fuertes componentes creativos e innovadores en los respectivos ámbitos.
WorkshopCamp será un evento con talleres con una duración de 3 horas impartidos por quien tenga algo que compartir y enseñar en un salón con temas orientados al diseño y desarrollo web.
Habrá dos turnos de talleres, el primero de 10 a 13 hrs y el segundo de 14 a 7 hrs.
El evento se llevará a cabo el próximo Domingo 25 de octubre 2009 en las instalaciones de Ked México, ubicadas en Av. Revolución No. 374, Col. San Pedro de los Pinos a una cuadra del metro San Pedro de los Pinos en la línea 7 del metro.
En lo particular me registré para participar exponiendo sobre el tema de "Behaviour Driven Development" dentro del track de ponencias de México On Rails. Esta vertiente de desarrollo viene a completar mucho de lo expuesto en las metodologías ágiles en las cuales la interacción con el patrocinador del proyecto es indispensable. En el caso de BDD (por sus siglas en inglés) se tiene que resumir los requerimientos a aquellos que:
En el mundo Ruby y Ruby On Rails, se han desarrollado varias herramientas para apoyar las metodologías ágiles y BDD no es la excepción. El producto estrella en este caso es Cucumber, un framework para el soporte de los elementos del BDD. Se apoya en otro producto muy reconocido, RSpec, que permite el desarrollo de pruebas de una manera más natural y coloquial que por ejemplo Test::Unit, el framework estándar de Ruby y RoR.
Como sabemos que no todo mundo está familiarizado con Ruby y su medio ambiente, se incluirán charlas y talleres introductorios a Ruby, JRuby y una sesión de mejores prácticas.
El registro lo pueden realizar en WorkshopCamp Cd. de México.
¡Los esperamos!
Finito.
WorkshopCamp será un evento con talleres con una duración de 3 horas impartidos por quien tenga algo que compartir y enseñar en un salón con temas orientados al diseño y desarrollo web.
Habrá dos turnos de talleres, el primero de 10 a 13 hrs y el segundo de 14 a 7 hrs.
El evento se llevará a cabo el próximo Domingo 25 de octubre 2009 en las instalaciones de Ked México, ubicadas en Av. Revolución No. 374, Col. San Pedro de los Pinos a una cuadra del metro San Pedro de los Pinos en la línea 7 del metro.
En lo particular me registré para participar exponiendo sobre el tema de "Behaviour Driven Development" dentro del track de ponencias de México On Rails. Esta vertiente de desarrollo viene a completar mucho de lo expuesto en las metodologías ágiles en las cuales la interacción con el patrocinador del proyecto es indispensable. En el caso de BDD (por sus siglas en inglés) se tiene que resumir los requerimientos a aquellos que:
- Protejan las ganancias
- Incrementen las ganancias
- Reduzcan los costos
En el mundo Ruby y Ruby On Rails, se han desarrollado varias herramientas para apoyar las metodologías ágiles y BDD no es la excepción. El producto estrella en este caso es Cucumber, un framework para el soporte de los elementos del BDD. Se apoya en otro producto muy reconocido, RSpec, que permite el desarrollo de pruebas de una manera más natural y coloquial que por ejemplo Test::Unit, el framework estándar de Ruby y RoR.
Como sabemos que no todo mundo está familiarizado con Ruby y su medio ambiente, se incluirán charlas y talleres introductorios a Ruby, JRuby y una sesión de mejores prácticas.
El registro lo pueden realizar en WorkshopCamp Cd. de México.
¡Los esperamos!
Finito.
domingo, 6 de septiembre de 2009
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
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
sábado, 6 de junio de 2009
Un día después
Como lo anuncié algunos días atrás, ayer se realizó el RubyCamp en el Instituto de Física de la UNAM en la misma línea de otros eventos estilo 'BarCamp' que se han venido haciendo recientemente y como tal concentra a gente innovadora y entusiasta de la tecnología, particularmente del lenguaje de programación Ruby y su 'killer app': Ruby on Rails.
Alex Juárez y su equipo de trabajo se encargaron del 99% del trabajo de organización del evento el cual incluyo una extensa lista de ponentes (/me incluido) que trataron una variedad de temas pero que nos dejaron con el ansía de seguir realizando eventos de este tipo donde escuchar experiencias e ideas de gente que usa estas herramientas para ganarse el pan y no solo bluffing mercadológico para vendernos algo.
Me parece que es necesario seguir ampliando los espacios para compartir experiencias y traer más material del tema en español. Comentaba en una oportunidad que si bien existen toneladas de información en inglés, es necesario crear nuestra base de conocimientos y compartirla, intercambiar dudas, preguntas, inquietudes sin temor a no obtener respuesta ni a una competencia desleal.
Me sigue inquietando el hecho de que seguimos protegiendo nuestros 'productitos' o 'sistemitas' más que a un niño pequeño e indefenso y por otra parte, en la edición de mayo-julio de la revista Software Guru viene una entrevista a Jorge Zavala que si bien no reconozco en algún ámbito dice algunas frases que me parecen bien ciertas,
También hace referencia a los 'Super Happy Dev House' que se han venido realizando y en lo particular lo asocio con algunos de los eventos 'BarCamp' que han pasado. Hay gente que buscamos compartir lo que creemos bueno, nuestras experiencias y nuestras ambiciones y encontrar algunos otros con las mismas inquietudes, buscar una o más relaciones 'ganar-ganar' donde los beneficios se repartan entre los participantes.
Me quedé con un costal de ideas y un delicioso sabor de boca después de esta experiencia y sin lugar a dudas creo que este ha sido el mejor evento en lo que va del año. Realmente espero el siguiente para participar de nuevo y encontrar más personas participando, intercambiando experiencias y conocimiento.
Finito.
Alex Juárez y su equipo de trabajo se encargaron del 99% del trabajo de organización del evento el cual incluyo una extensa lista de ponentes (/me incluido) que trataron una variedad de temas pero que nos dejaron con el ansía de seguir realizando eventos de este tipo donde escuchar experiencias e ideas de gente que usa estas herramientas para ganarse el pan y no solo bluffing mercadológico para vendernos algo.
Me parece que es necesario seguir ampliando los espacios para compartir experiencias y traer más material del tema en español. Comentaba en una oportunidad que si bien existen toneladas de información en inglés, es necesario crear nuestra base de conocimientos y compartirla, intercambiar dudas, preguntas, inquietudes sin temor a no obtener respuesta ni a una competencia desleal.
Me sigue inquietando el hecho de que seguimos protegiendo nuestros 'productitos' o 'sistemitas' más que a un niño pequeño e indefenso y por otra parte, en la edición de mayo-julio de la revista Software Guru viene una entrevista a Jorge Zavala que si bien no reconozco en algún ámbito dice algunas frases que me parecen bien ciertas,
- "fail fast", si tienes una idea, enfréntala a la realidad, si es buena y funciona, invierte en ella sino continua con la siguiente.
- Necesitas gente con mentes frescas antes que grandes recursos financieros.
- Los negocios son para venderse, no quedarse toda la vida con ellos.
También hace referencia a los 'Super Happy Dev House' que se han venido realizando y en lo particular lo asocio con algunos de los eventos 'BarCamp' que han pasado. Hay gente que buscamos compartir lo que creemos bueno, nuestras experiencias y nuestras ambiciones y encontrar algunos otros con las mismas inquietudes, buscar una o más relaciones 'ganar-ganar' donde los beneficios se repartan entre los participantes.
Me quedé con un costal de ideas y un delicioso sabor de boca después de esta experiencia y sin lugar a dudas creo que este ha sido el mejor evento en lo que va del año. Realmente espero el siguiente para participar de nuevo y encontrar más personas participando, intercambiando experiencias y conocimiento.
Finito.
viernes, 29 de mayo de 2009
RubyCamp
El próximo viernes 5 de junio se realizará el evento RubyCamp en las instalaciones del IFUNAM. Como el nombre lo indica, la organización del evento cae en el formato de los Barcamps y las 'no-conferencias'. Se van a concentrar varios conocidos que trabajan activamente con Ruby y con Ruby On Rails dando breves pero sustanciosas pláticas pero también veo en la agenda del evento, gente nueva en la onda Ruby On Rails.
Así que se extiende la invitación a todos los lectores, más detalles los pueden encontrar en el sitio del evento , en la lista de correos o simplemente síguenos en twitter .
Finito.
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.
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
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
Suscribirse a:
Entradas (Atom)