Pues mientras casi todo mundo esta de vacaciones y yo sintiendome como el cuadrado de Flatland, que intuye que hay mas alla de lo que normalmente se llama vida, expongo las ideas para cerrar el año (odio medir la vida en cierres de año, por lo que esta es señal de que estoy envejeciendo y volviendome algo conservador)
Llevo años hablando de Arquitectura Empresarial (Zachman, FEA, TOGAF) y tratando de explicar en que consiste
Lo que me doy cuenta es como he evolucionado en el enfoque y me permito hacer una simulacion de una bitacora de como fue la historia
+ La primera vez, fue cuando me pidieron hiciera un modelo de arquitectura para todas las arquitecturas. Fue hace ya 4 años y me fui topando con el concepto de arquitectura empresarial. Despues de un rato de investigar y medio juntar bibliografia, me di cuenta de la famosa matriz de Zachman. Como cuate mas orientado a los bytes, me clave mucho en la parte tecnologica y por ahi me surgio la idea de hablar de arquitectura de aplicaciones, datos e infraestructura y obtener un modelo para soportar integracion entre aplicaciones y unificarlas
+ La segunda vez, un buen amigo, Juan Lozada, me ayudo a entender como en la practica se puede concebir el marco de Zachman. Y de el oi los terminos como Governance y referencia a modelos de calidad o mejores practicas como CMMI, ITIL, COBIT, PMBOK. De ahi salieron documentos que tenian como objetivo el normar el actuar de toda una organizacion y todo parecia indicar que ya habia algo hecho
+ Pero el tratar de hacer la vision realidad siempre fue un reto. Llegas con tu marco de referencia (el cual por cierto no era perfecto) y te topas que ya existen aplicaciones ejecutandose y que fueron hechas sin tomar en cuenta el concepto de arquitectura, sin embargo estan operando y dando servicio y generando impacto en la organizacion. No tienen la mejor arquitectura sin embargo son valores de lao organizacion. ¿Entonces que hacer? Ponerse en un papel dogmatico tipo Iglesia en la Edad Media o ser tolerante. La respuesta era obvia ser tolerante y tratar de organizar poco a poco para que las aplicaciones empiecen a tomar buenas practicas
+ Sin embargo, los eventos externos, eventos politicos, riñas de poder, no permiten que la vision sea comprendida, atascado un rato en resolver problemas operativos, pobre marco de referencia de arquitectura empresarial empolvandose. Sin embargo si se dispone de tecnlogia, ESB, Gestor de contenido, Motor de reglas de negocio, muchos sabores de BPM, marco de referencia, muchas maneras de hacer sevicios Web, Portal, registro UDDI
+ Cambio de aires, nueva administracion en la organizacion, se topan con que existe mucha tecnologia, muchas aplicaciones, pero visiones dispares y tambien costos altos en TI que deben ser controlados. Lo que si reconocen es que no hay estandares. Sin embargo si se habian definido. ¿Que habia pasado? El modelo de la organizacion orienta a que se creen silos de informacion, poco unificados y muy propensos a ser manipulados por cuestiones politicas.
+ El problema no es tanto la cuestion tecnologica es la interoperabilidad entre las personas. La vision del marco de referencia de Zachman necesita tomar en cuenta a la organizacion. Ups! Creo que el primer renglon del marco de Zachman si sirve para algo!
+ Chamba para unificar las visiones, se confunden proyectos para beneficio como cotos de poder para poder impresionar a los altos mandos de la TI. Se manipulan conceptos tecnologicos para hacer creer que existen muchos beneficios en hacerlo pero sin tomar en cuenta el como, olvidando que la organizacion necesita un alto impacto. Sin embargo, no son malas ideas, algo tiene que unificar todo, algo como un marco de referencia de arquitectura empresarial.
+ Eureka, platicando con un amigo, me sugiere que si quiero hablar de una arquitectura empresarial, piense en un modelo de operacion de servicios (operation management). Me doy cuenta que no era lo mismo que investigacion de operaciones. Me compro tres y muy buenos libros en el tema y me doy cuenta que hablan de procesos, servicios, cadenas de valor, mucho de ellos aplicados para ERP, CRM, SCM. ¡Sin embargo no quiero que la organizacion donde estoy trate de solucionar todo con un ERP! He dicho muchas cosas sobre lo que pienso sobre un ERP pero principalmente no es la panacea y menos para la organizacion donde trabajo
+ Pero el modelo de administracion de operaciones es bueno. Pienso en que cadenas de valor tenemos:
+ La que da servicios a nuestros clientes (ciudadanos). Su objetivo es fomentar el autoservicio y darles la mayor informacion que necesiten sin enredarlos en procesos burocraticos. Un call center, un portal y otras estrategias bien diseñadas (como kiosocos) pueden dar impacto. Pero es muy importante que este cadena de valor se flexible, la menos complicada y la que debe ser capaz de entregar la informacion a los ciudadanos sin importar su condicion social, educacion
+ La que soporta la operacion de la organizacion. La organizacion esta basada en servicios, no manufactura, pero es muy criticada por los servicios que da y su burocracia. Entonces es necesario que la cadena de valor de operacion sea capaz de permitir que los que otorgan el servicio conozcan de su trabajo (gestion del conocimiento), que tengan un proceso base que seguir y que se pueda medir (BPM y BAM) y con referencia a modelos de calidad (TQM, Six Sigma, ISO), permitir que manipulen sus procesos y reglas de negocio, fomentar flujos de trabajo centrados en documentos (gestion de contenido). Ademas otorgarles herramientas de TI para innovar (colaboracion, mashups, Web 2.0), hacer un portal de operacion de la organizacion
+ La que soporta todos los procesos de la organizacion. Tomar las aplicaciones ya existentes y convertirlas a servicios, utilizando SOA, usar las herramientas como ESB, Data Services y gobernarlos a traves de un servicio de registros. Esto es el "backend" de la organizacion.
+ La que soporta a los administradores de la organizacion, alta direccion, los que definen las politicas, los modelos de operacion, manejan presupuesto, toman decisiones, tienen que cumplir con normatividad gubernamental. Dar herramientas especializadas que tomen informacion de todas las demas cadenas de valores, analisis de informacion y procesos, simulacion. Integrarlos para que usando la TI definan y mejoren los procesos de la organizacion
+ La que soporta la informacion de la organizacion, la cadena de valor de TI. La TI para innovar. Definir catalogos de servicios con ITIL, mesa de ayuda para TI, aplicar los modelos de desarrollo y mantnimiento de software (CMMI RUP), oficina de administracion de proyectos (PMO, PMBOK), servicios de infraestructura de software y hardware, orientar a calidad en servicios de TI, hacer que cada integrante de TI sea un agente de cambio e innovacion
+Entonces la arquitectura empresarial es entender a las cadenas de valor de la organizacion, soportar su ejecucion con Tecnologia de Informacion y utilizar como estrategia de implantacion los modelos de SOA+BPM+ Web 2.0
Suena muy bien la idea. Es un buen reto, me imagino que si se logra en la organizacion puede hacer que la TI le de el valor. Hace justicia a nuestra chamba de ingenieros y lo mas importante, hace que nuestros clientes tengan servicios de primera
El punto es convencer a mucha gente, a la propia de TI, a los demas no TI de la organizacion. a los clientes, proveedores y reguladores
Interoperabilidad entre personas, lo mas dificil, buen reto para el 2008, pero vale la pena intentarlo
viernes, 28 de diciembre de 2007
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
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
lunes, 19 de noviembre de 2007
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:
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.
Después se actualizan los datos del archivo config/database.yml
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.
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.
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
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
lunes, 3 de septiembre de 2007
Bitácoras, Trazas, Logs, Logging
Una consabida forma de ver que sucede con tus programas es "pintar" los valores de tus variables. Esta rústica forma de depurar también tiene otra acepción: loggear :S
¿quién dijo que poner System.out.println (javeros) o Console.WriteLine (.net) por cada línea es manejar una bitácora? No lo sé, pero en los ambientes java (que es lo que tengo más cercano) tenemos mega-archivos log de cientos de megabytes generados con poderosos System.out.println statements. Logging is cool!
Pero, eso no es logging. En casi cada aplicación "grande" o "empresarial" (lo que sea que significa esto) se incluye algún mecanismo de bitácoras. Agregar sentencias de rastreo es un mecanismo de "bajo nivel" para depurar código. Puede ser que sea la única opción por no existir un depurador para la plataforma o por que ya se trata de un ambiente multitarea/multihilos.
En el caso de una aplicación ejecutándose en un ambiente de producción, tampoco se puede hacer uso de herramientas de desarrollo o depuración. Casos así requieren que se le otorgue a los administradores u operadores herramientas que les permitan monitorear el comportamiento de los sistemas.
Para hablar de logging se requiere cumplir una serie de requisitos. Uno de ellos son los "contextos", entidades que contienen la información precisa de la ejecución de la aplicación. También se requiere distinguir diferentes niveles de severidad, desde el error fatal hasta mensajes de depuración; estas características deben poder configurarse fuera del código de la aplicación, es decir, en los programas incluimos todas las llamadas de rastreo que consideremos pero dependiendo de la configuración se van ir grabando las seleccionadas.
También tiene sus desventajas. El registro de entradas en archivos o bases de datos consume tiempo de procesador, llamadas a dispositivos que finalmente se ve como un cierto grado de lentitud en la aplicación. Si se registran demasiadas entradas, el log se torna ilegible. Si se filtran demasiados niveles de severidad, puede ser que se pierdan elementos que podrían auxiliar a resolver problemas.
Como ya es costumbre, el mundo java ha pasado por esto antes y gracias a la colaboración de muchas personas se construyó un framework para este tipo de necesidades. Ha sido tal el éxito de esta iniciativa que se desarrollaron componentes similares para otras plataformas y lenguajes (C++/PHP/Ruby) e incluso se incluye en algunos productos comerciales, BEA WebLogic Server por ejemplo (aunque ninguno de los programadores que conozco lo usan, siguen con sus pinchis println's) y obvio, también se construyo para .NET.
En este caso, log4net respeta todos los principios de su ancestro log4j y tenemos archivos de configuración, contextos, jerarquía de loggers e implementaciones de "appenders" que nos permiten tener diferentes destinos para nuestros logs. Ahora si, "logs".
El primer ejercicio de muestra del uso de log4net lo pueden encontrar en mi repositorio de ideas Google Code. Mediante subversion pueden obtener una copia de trabajo y trastear un rato con él.
Finito.
¿quién dijo que poner System.out.println (javeros) o Console.WriteLine (.net) por cada línea es manejar una bitácora? No lo sé, pero en los ambientes java (que es lo que tengo más cercano) tenemos mega-archivos log de cientos de megabytes generados con poderosos System.out.println statements. Logging is cool!
Pero, eso no es logging. En casi cada aplicación "grande" o "empresarial" (lo que sea que significa esto) se incluye algún mecanismo de bitácoras. Agregar sentencias de rastreo es un mecanismo de "bajo nivel" para depurar código. Puede ser que sea la única opción por no existir un depurador para la plataforma o por que ya se trata de un ambiente multitarea/multihilos.
En el caso de una aplicación ejecutándose en un ambiente de producción, tampoco se puede hacer uso de herramientas de desarrollo o depuración. Casos así requieren que se le otorgue a los administradores u operadores herramientas que les permitan monitorear el comportamiento de los sistemas.
Para hablar de logging se requiere cumplir una serie de requisitos. Uno de ellos son los "contextos", entidades que contienen la información precisa de la ejecución de la aplicación. También se requiere distinguir diferentes niveles de severidad, desde el error fatal hasta mensajes de depuración; estas características deben poder configurarse fuera del código de la aplicación, es decir, en los programas incluimos todas las llamadas de rastreo que consideremos pero dependiendo de la configuración se van ir grabando las seleccionadas.
También tiene sus desventajas. El registro de entradas en archivos o bases de datos consume tiempo de procesador, llamadas a dispositivos que finalmente se ve como un cierto grado de lentitud en la aplicación. Si se registran demasiadas entradas, el log se torna ilegible. Si se filtran demasiados niveles de severidad, puede ser que se pierdan elementos que podrían auxiliar a resolver problemas.
Como ya es costumbre, el mundo java ha pasado por esto antes y gracias a la colaboración de muchas personas se construyó un framework para este tipo de necesidades. Ha sido tal el éxito de esta iniciativa que se desarrollaron componentes similares para otras plataformas y lenguajes (C++/PHP/Ruby) e incluso se incluye en algunos productos comerciales, BEA WebLogic Server por ejemplo (aunque ninguno de los programadores que conozco lo usan, siguen con sus pinchis println's) y obvio, también se construyo para .NET.
En este caso, log4net respeta todos los principios de su ancestro log4j y tenemos archivos de configuración, contextos, jerarquía de loggers e implementaciones de "appenders" que nos permiten tener diferentes destinos para nuestros logs. Ahora si, "logs".
El primer ejercicio de muestra del uso de log4net lo pueden encontrar en mi repositorio de ideas Google Code. Mediante subversion pueden obtener una copia de trabajo y trastear un rato con él.
Finito.
jueves, 23 de agosto de 2007
De vuelta
Hola que tal
Por acá de vuelta a estos rollos (después de que ya que el buen Gus se canso de hacer posts y el buen Chillicoder de copiar-pegar lo que pone en su blog :P)..Bueno pues hay muchas cosas interesantes que poner; digo después de mes y cacho de no escribir... segurito algo debió de haber ocurrido.. ;)
Esta semana me invito el buen Gus a un curso de ITIL Foundation en HP - instalaciones en el bello basurero de Santa Fe (que por cierto ya mero convierten en sapo a Gustavo, que dizque "por invitarme" chaft!!) , sinceramente es el primer contacto que tengo con este tema y se me ha hecho harto interesante.
Para los que están como yo.. ósea que es su primera vez en este tema, solo me limitare a comentar que es un marco de referencia que consta de varios libros que ofrecen una guía para la administración de servicios de Tecnología de Información... entiéndase por servicio de TI a todo aquello que permite llevar a cabo la operación de una empresa, dígase hardware, software, componentes, etc. en otra ocasión hablare un poquito mas de este tema, así de como ITIL puede ayudarnos a mejorar nuestra administración de servicios TI.
Saludos
Bonus Track: Lenguaje PURASPE
En el desarrollo del curso de ITIL nuestro instructor nos hablo de un lenguaje que el bautizo como PURASPE, que no es otra cosa que hablar en otro idioma diferente al que hablan nuestros usuarios ... le hablamos de web services, de applications server, de firewalls, algunos pochismos.. eso es PURASPE en acción, curiosamente el comentario lo reforzó un doctor especialista que se encuentra también tomando el curso y menciono lo siguiente "ha veces llegan los de TI y empiezan a decir: que el CMMI, que Web Server, que SOAP... pobres chamaquitos, creen que con hablar con muchos tecnicismos van a impresionar a un doctor especialista" en cierta medida tiene razón… aunque posteriormente el doctor estaba dando unos ejemplos de su ramo y nos hablo en PURASPE.... a lo que un compañero le dijo "y no crea que por hablar así va a impresionar a un ingeniero" jaja, en fin aquí nadie sabe mas ni menos.. Ya lo dice el principio de Peter "Todos llegamos a un nivel de incompetencia"
Aquí el mensaje es tal como dice el buen chillicoder... "ENTRE SERVICIOS TE VEAS..."
Va pues saludos... ah por cierto PURASPE significa - Puras Pendejadas
La construcción de los Helpers
Derivado del desarrollo de Operación PyME y un poco de sentido común aparece la tarea de construir un framework para construir más rápidamente y fácilmente la aplicación.
Se ha vuelto un concepto casi obligado el utilizar un framework de objetos de negocio pero ¿qué entendemos por esto? Un conjunto de clases que permiten modelar los objetos de un dominio y nos permitan olvidarnos de las tareas mundanas. La idea de fondo es utilizar la mayor parte de nuestra energía solucionando problemas de negocio y la menos posible en los problemas de tecnología.
Así han aparecido en el medio infinidad de frameworks con este objetivo, en todos los lenguajes y en todas las plataformas. Hasta parece que ya se ha llegado a un punto de saturación para estos proyectos. Sin embargo siguen apareciendo.
No existe el framework perfecto, como tampoco el lenguaje perfecto ni la plataforma perfecta. Y siguiendo nuestro inevitable anhelo de perfección vamos creando más proyectos tratando de solventar los errores que encontramos en otros.
No existe una metodología perfecta para construir un framework, generalmente la construcción es influenciada por el tema de moda: aspectos, programación orientada a objetos, inyección de dependencias, objetos auto-suficientes. Algunas empresas han publicado documentos para describir como han concebido y construido los frameworks que ofrecen. Entre estas últimas aparece notoriamente Microsoft.
Después de lanzar al mercado la tecnología .NET, Microsoft ha batallado duramente para posicionarla como una tecnología empresarial (cualquiera que sea su significado). Parte de esos esfuerzos ha sido el desarrollo de bibliotecas de componentes que faciliten el desarrollo de aplicaciones. El esfuerzo inicial dio como resultados los elementos que se conocieron como Application Blocks.
Estos eran conjuntos de clases con un objetivo delimitado. Lo más interesante fue que las construyeron a partir de un análisis que compartieron en forma de guías. En estos documentos exponen los elementos que se consideraron durante el diseño describiendo detalladamente los escenarios y la manera de aplicar la tecnología .NET para construir estas bibliotecas.
Estas bibliotecas fueron rápidamente adoptadas por la comunidad de desarrolladores quienes además fueron enriqueciendo con sus experiencias propias la funcionalidad de las clases incluidas e incluso se combinaron en un nuevo producto que se conoce como Enterprise Library. Sin embargo, tras la aparición del proyecto Mono, que permite la ejecución de programas desarrollados con .NET en plataformas no Windows, se incluyó en la licencia una cláusula que impide la ejecución de los Application Blocks en sistemas operativos distintos a los construidos por Microsoft.
Así que ahora, a pesar de ser elementos tan útiles, los Application Blocks no pueden ser utilizados en Linux o Mac OSX. Existen en el mundo del código abierto cada vez más proyectos basados en .NET y algunos de ellos pudieran resolver los mismos escenarios que se presentan en el diseño de las bibliotecas de Microsoft el ejemplo de inicio es log4net, una biblioteca de clases para registrar entradas en diferentes destinos que forma parte del proyecto Logging Services de la Fundación Apache.
Y también existen otros proyectos que ofrecen alternativas para los otros Application Blocks existentes sin embargo la principal ventaja de la oferta de Microsoft es la unificación que han conseguido y que en los proyectos de software libre se encuentran dispersos e inmersos en otros proyectos y una implementación sencilla, directa y única simplemente no existe.
Así que esta iniciativa (si, una más) es la de tener en un solo conjunto esta funcionalidad partiendo en primer lugar de proyectos ya existentes, como log4net, mostrando como es que se cumplen los escenarios descritos en la documentación de Microsoft y construyendo los elementos necesarios retomando código o creando nuevo para satisfacer las necesidades planteadas por las guías de referencia.
Y si no fuera suficiente... habrá más sobre el tema.
Finito.
Se ha vuelto un concepto casi obligado el utilizar un framework de objetos de negocio pero ¿qué entendemos por esto? Un conjunto de clases que permiten modelar los objetos de un dominio y nos permitan olvidarnos de las tareas mundanas. La idea de fondo es utilizar la mayor parte de nuestra energía solucionando problemas de negocio y la menos posible en los problemas de tecnología.
Así han aparecido en el medio infinidad de frameworks con este objetivo, en todos los lenguajes y en todas las plataformas. Hasta parece que ya se ha llegado a un punto de saturación para estos proyectos. Sin embargo siguen apareciendo.
No existe el framework perfecto, como tampoco el lenguaje perfecto ni la plataforma perfecta. Y siguiendo nuestro inevitable anhelo de perfección vamos creando más proyectos tratando de solventar los errores que encontramos en otros.
No existe una metodología perfecta para construir un framework, generalmente la construcción es influenciada por el tema de moda: aspectos, programación orientada a objetos, inyección de dependencias, objetos auto-suficientes. Algunas empresas han publicado documentos para describir como han concebido y construido los frameworks que ofrecen. Entre estas últimas aparece notoriamente Microsoft.
Después de lanzar al mercado la tecnología .NET, Microsoft ha batallado duramente para posicionarla como una tecnología empresarial (cualquiera que sea su significado). Parte de esos esfuerzos ha sido el desarrollo de bibliotecas de componentes que faciliten el desarrollo de aplicaciones. El esfuerzo inicial dio como resultados los elementos que se conocieron como Application Blocks.
Estos eran conjuntos de clases con un objetivo delimitado. Lo más interesante fue que las construyeron a partir de un análisis que compartieron en forma de guías. En estos documentos exponen los elementos que se consideraron durante el diseño describiendo detalladamente los escenarios y la manera de aplicar la tecnología .NET para construir estas bibliotecas.
Estas bibliotecas fueron rápidamente adoptadas por la comunidad de desarrolladores quienes además fueron enriqueciendo con sus experiencias propias la funcionalidad de las clases incluidas e incluso se combinaron en un nuevo producto que se conoce como Enterprise Library. Sin embargo, tras la aparición del proyecto Mono, que permite la ejecución de programas desarrollados con .NET en plataformas no Windows, se incluyó en la licencia una cláusula que impide la ejecución de los Application Blocks en sistemas operativos distintos a los construidos por Microsoft.
Así que ahora, a pesar de ser elementos tan útiles, los Application Blocks no pueden ser utilizados en Linux o Mac OSX. Existen en el mundo del código abierto cada vez más proyectos basados en .NET y algunos de ellos pudieran resolver los mismos escenarios que se presentan en el diseño de las bibliotecas de Microsoft el ejemplo de inicio es log4net, una biblioteca de clases para registrar entradas en diferentes destinos que forma parte del proyecto Logging Services de la Fundación Apache.
Y también existen otros proyectos que ofrecen alternativas para los otros Application Blocks existentes sin embargo la principal ventaja de la oferta de Microsoft es la unificación que han conseguido y que en los proyectos de software libre se encuentran dispersos e inmersos en otros proyectos y una implementación sencilla, directa y única simplemente no existe.
Así que esta iniciativa (si, una más) es la de tener en un solo conjunto esta funcionalidad partiendo en primer lugar de proyectos ya existentes, como log4net, mostrando como es que se cumplen los escenarios descritos en la documentación de Microsoft y construyendo los elementos necesarios retomando código o creando nuevo para satisfacer las necesidades planteadas por las guías de referencia.
Y si no fuera suficiente... habrá más sobre el tema.
Finito.
martes, 26 de junio de 2007
PartnerApi Library: Por fin ve la luz
Hace algunos años fui contratado para integrar un CRM y Salesforce (se llamaba así en ese entonces). Para realizar la integración usé C# y el Enterprise API de Salesforce para llevar los datos del CRM al repositorio en línea de Salesforce. Un ejercicio harto interesante. También leí algo acerca de la PartnerApi y de ahí surgió la inquietud de utilizarla.
El objetivo que se me presentó en mi mente fue crear una biblioteca que simplificara el uso de esta PartnerApi y pues después de mmuuuucho tiempo aquí está.
Acabo de publicar el código, licenciado bajo LGPL, para que todo mundo lo revise, lo use y ojalá y contribuya a este proyecto.
Cualquier comentario, sugerencia o pregunta son bienvenidas.
Finito.
El objetivo que se me presentó en mi mente fue crear una biblioteca que simplificara el uso de esta PartnerApi y pues después de mmuuuucho tiempo aquí está.
Acabo de publicar el código, licenciado bajo LGPL, para que todo mundo lo revise, lo use y ojalá y contribuya a este proyecto.
Cualquier comentario, sugerencia o pregunta son bienvenidas.
Finito.
Enterprise Architecture
Hola que tal!!!
Hace unos meses escuche el termino Arquitectura Empresarial y como buen técnico de entrada pensé que hablaba de arquitectura de software, de componentes en fin todo relacionado con tecnología y no es que estuviera mal, pero en una empresa no todo es tecnología... el buen Gus siempre hacia énfasis en ver todas las perspectivas que encontramos dentro de una organización.... lo que le da vida....
Si quisiera hablar de Arquitectura empresarial en una frase la dejaría como sigue: "Se refiere a el conjunto de PROCESOS DE NEGOCIO de una organización, como estos procesos son implementados con TECNOLOGIA y como son llevados a cabo por PERSONAS", quizá gus, o muchos de ustedes complementaran esta frase... , como pueden ver este tridente PERSONAS-PROCESOS-TECNOLOGIA es el alma de una empresa...
Para la empresa lo mas importante son sus PROCESOS de negocio... todos y cada uno de ellos desde procesos bancarios, procesos de pagos, procesos de nomina... en fin los que se les ocurran.... por otra parte están las PERSONAS el lado humano el lado que echa a andar los procesos, cumpliendo tareas especificas que permitirán lograr los objetivos de la organización.... y soportando ambas cosas esta
Un Framework muy interesante es el llamado Framework de Zachman para Arquitectura empresarial, el cual define diferentes perspectivas como Que (datos), Como (funciones), Donde (ubicación), Quien (personas), Cuando (tiempo) y Porque(Motivación), a su vez estas perspectivas pueden cruzarse con el Alcance (objetivos estratégicos de la organización), Modelo Empresarial (Modelado de procesos de negocio), el Modelo del Sistema(Modelos Lógicos), Modelo Tecnológico (Definición y desarrollo de la solución), Componentes y los Sistemas en operación (Empresa Funcionando)....
Si algún día necesitan realizar un diagnostico de
Ahora veamos la famosa pregunta ¿como alinear TI a los objetivos de la organización?.. Quizá la respuesta la encontremos en la arquitectura empresarial....
Saludos!!!
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
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
domingo, 10 de junio de 2007
Otras formas de innovación
Como ya varios saben, soy lector regular del blog de Scott Hanselman. Es un tipo realmente brillante no solo tirando código sino llevando la tecnología a nichos que simplemente dejamos pasar de largo.
¿Cuántas veces se ha utilizado Google Earth para buscar monumentos, la casa de tu novia o una dirección? Peor aún ¿cuántas veces no se ha usado para buscar gente desnuda tomando el sol en el patio de su casa?. Puede ser divertido pero definitivamente es un desperdicio de tecnología.
Pues bien, Scott publicó un post sobre como utilizar Google Earth o Virtual Earth para visualizar un nuevo fraccionamiento.
Lo interesante de esto es que son herramientas que están al alcance de cualquier persona. No necesitas ser un mega-dooper-super experto en AutoCAD o cosa similar (claro, el resultado tampoco es igual), simplemente con unas pocas herramientas en tu PC casera consigues el resultado.
Eso también es innovación. Los mexicanos nos preciamos mucho de ser ocurrentes, tal vez alguien acá de este lado de la frontera tuvo la misma ocurrencia. Pero al no compartir ese conocimiento cualquier otro que sí lo hace se convierte en innovador por ese simple hecho.
Estamos muy acostumbrados a construir nichos y compartir un poquito de conocimiento con otros para convertirlos en nuestros aliados. Armamos batallas de escritorio para tirar los nichos de otros. Negociamos con el conocimiento como con cualquier baratija.
Entonces ¡compártamos nuestro conocimiento! Una de las bellezas del software libre es ese ambiente de compartir, de buscar a quién ofrecerle (sin ningún interés por detrás) lo último que construimos, de pedir opinión a otros para mejorar, de mirar en el trabajo del vecino para buscar una segunda opinión sobre lo que estamos haciendo.
Busquemos compartir en lugar de aislar. Tratar el conocimiento, simple o formalizado, con el valor que se merece. Tratemos a los demás como compañeros de creación.
Finito.
¿Cuántas veces se ha utilizado Google Earth para buscar monumentos, la casa de tu novia o una dirección? Peor aún ¿cuántas veces no se ha usado para buscar gente desnuda tomando el sol en el patio de su casa?. Puede ser divertido pero definitivamente es un desperdicio de tecnología.
Pues bien, Scott publicó un post sobre como utilizar Google Earth o Virtual Earth para visualizar un nuevo fraccionamiento.
Lo interesante de esto es que son herramientas que están al alcance de cualquier persona. No necesitas ser un mega-dooper-super experto en AutoCAD o cosa similar (claro, el resultado tampoco es igual), simplemente con unas pocas herramientas en tu PC casera consigues el resultado.
Eso también es innovación. Los mexicanos nos preciamos mucho de ser ocurrentes, tal vez alguien acá de este lado de la frontera tuvo la misma ocurrencia. Pero al no compartir ese conocimiento cualquier otro que sí lo hace se convierte en innovador por ese simple hecho.
Estamos muy acostumbrados a construir nichos y compartir un poquito de conocimiento con otros para convertirlos en nuestros aliados. Armamos batallas de escritorio para tirar los nichos de otros. Negociamos con el conocimiento como con cualquier baratija.
Entonces ¡compártamos nuestro conocimiento! Una de las bellezas del software libre es ese ambiente de compartir, de buscar a quién ofrecerle (sin ningún interés por detrás) lo último que construimos, de pedir opinión a otros para mejorar, de mirar en el trabajo del vecino para buscar una segunda opinión sobre lo que estamos haciendo.
Busquemos compartir en lugar de aislar. Tratar el conocimiento, simple o formalizado, con el valor que se merece. Tratemos a los demás como compañeros de creación.
Finito.
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?
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?
martes, 5 de junio de 2007
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.
Definitivamente es una historia para contar por episodios. No se desconecten.
Finito.
lunes, 4 de junio de 2007
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 ;)
Va pues, comentarios bienvenidos :)
Por una integracion mejor, hasta la vista!
Tuzo
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)
- 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
Va pues, comentarios bienvenidos :)
Por una integracion mejor, hasta la vista!
Tuzo
lunes, 28 de mayo de 2007
CMMI
Bueno, esto deberia estar mas del lado del post de Tuzoftwar, pero el tuzo no me invito al club de tobby-tuzos, y menos por que en la final le iba yo al America y solo por el afan de molestarlo
Empecemos con lo que quiero decir
Mucho de lo expuesto aqui en este blog, puede ya ser calificados como antipatterns de integracion, como lo han notado. Y habla de lo que no se debe hacer.
Sin embargo, muchas veces, sea cual sea el tamaño de la organizacion que desarrolla, siempre se acaba en un punto en el cual algo no fue interpretado como se debia
El punto es, y ahora que lo veo; es muy arriesgado aventarse a desarrollar sin tener un modelo de referencia. Sin embargo todos lo hacemos
Normalmente los de sistemas, vemos el punto de programar, tirar codigo, hacer arquitectura, integrar.
Pero se nos olvida facilmente que detras de ese esfuerzo estan grupos de seres humanos y que tienen un ritmo de trabajo cuando trabajan en equipo.
La administracion de proyectos trata de atacar esa problematica, que tiene varias soluciones por ser enfocada a la mas incierta de las variables, el humano y lograr la meta.
El CMMI es un modelo que indica como debe madurar una organizacion que desarrolla software tomando en cuenta los humanos, definiendo un proceso y lograr obtener productos de software
Lo primero que pide es que seas capaz de administrar tus proyectos, que puedas hacer que algo que lograste una vez, vuelva a suceder; y que minimo te dediques a controlar los requerimientos. Este es el nivel 2 de CMMI. No se preocupa por decir como hacer la ingenieria de software. Y tambien pide que controles tus cambios antes de que te ahogues con ellos, que asegures la calidad y tomes medida (lo que no se puede medir no se puede administrar)
El nivel 3 de CMMI basicamente dice, escribe tu proceso indicando la manera como quieres que todos trabajen y de ahi, ajusta tus proyectos a esa vision (no siempre vas a modelar en UML o si?) y coordinate con otros grupos de trabajo. Y hecho eso, empieza a ver la ingenieria de software, analizar, desarrollar e integrar componentes. Y revisa que cada componente cumpla con lo especificado y validar que se pueda usar por el usuario.
El nivel 4 dice, ya que defines procesos, mide cuantitaviamente como los trabajas y empieza a estimar tu desarrollo en base a estadistica, y reducir la incertidumbre
Y el nivel 5 es, si ya haces tu proceso, ya lo mides, ahora preparate para innovar, para meter nueva tecnologia, para aprovechar oportunidades
Si, son cinco niveles , nada sencillos de alcanzar, pero la verdad es lo fundamental para sacar cualquier proyecto de desarrollo
He visto mucha gente desgastarse en poner decenas o centenas de programadores para sacar mas rapido proyectos, he visto muchos gritando y matando gente bajando la calidad de vida, trabajo inutil en sabado y domingo. Y he visto como en muchos proyectos se tienen que admitir resultados tecnicamente mediocres, con que jale mañana esta bien, al otro dia vemos
Y no es mala fe de las personas, creo que cuando todos arrancamos un proyecto, pensamos " acabo en la fecha, siendo amigos de todos los involucrados y me tomo mis vacaciones". Pero es vivir de la ilusion
Sin embargo, esa buena fe de las personas puede ser mejor utilizada si decidieran abrir su mente al modelo que les menciono o similar. Es ser profesional en tu manera de ser, es hacer lo que debe hacerse, quitarte de tu complejo de superprogramador o de mandon
Solo es estudiar, leer y usarlo para servir a los demas en base a tu conocimiento
Asi que yo creo que mucho de lo puesto en este blog, integracion a la mexicana no es para enfatizar el error de alguien. Es para aprender de la experiencia y demostrar que mas vale razonar las cosas que andar de griton o neurastenico con la gente, que al final son humanos como todos.
Asi que, busquen en Google la palabra CMMI. Puede ser que se topen con un documento muy grande del SEI, muy abstracto; pero al entenderlo, se van a perctar que es tan noble como cualquier pieza de ingenieria hecha por los humanos.
Una vez mas, esto no es religion es ingenieria
Empecemos con lo que quiero decir
Mucho de lo expuesto aqui en este blog, puede ya ser calificados como antipatterns de integracion, como lo han notado. Y habla de lo que no se debe hacer.
Sin embargo, muchas veces, sea cual sea el tamaño de la organizacion que desarrolla, siempre se acaba en un punto en el cual algo no fue interpretado como se debia
El punto es, y ahora que lo veo; es muy arriesgado aventarse a desarrollar sin tener un modelo de referencia. Sin embargo todos lo hacemos
Normalmente los de sistemas, vemos el punto de programar, tirar codigo, hacer arquitectura, integrar.
Pero se nos olvida facilmente que detras de ese esfuerzo estan grupos de seres humanos y que tienen un ritmo de trabajo cuando trabajan en equipo.
La administracion de proyectos trata de atacar esa problematica, que tiene varias soluciones por ser enfocada a la mas incierta de las variables, el humano y lograr la meta.
El CMMI es un modelo que indica como debe madurar una organizacion que desarrolla software tomando en cuenta los humanos, definiendo un proceso y lograr obtener productos de software
Lo primero que pide es que seas capaz de administrar tus proyectos, que puedas hacer que algo que lograste una vez, vuelva a suceder; y que minimo te dediques a controlar los requerimientos. Este es el nivel 2 de CMMI. No se preocupa por decir como hacer la ingenieria de software. Y tambien pide que controles tus cambios antes de que te ahogues con ellos, que asegures la calidad y tomes medida (lo que no se puede medir no se puede administrar)
El nivel 3 de CMMI basicamente dice, escribe tu proceso indicando la manera como quieres que todos trabajen y de ahi, ajusta tus proyectos a esa vision (no siempre vas a modelar en UML o si?) y coordinate con otros grupos de trabajo. Y hecho eso, empieza a ver la ingenieria de software, analizar, desarrollar e integrar componentes. Y revisa que cada componente cumpla con lo especificado y validar que se pueda usar por el usuario.
El nivel 4 dice, ya que defines procesos, mide cuantitaviamente como los trabajas y empieza a estimar tu desarrollo en base a estadistica, y reducir la incertidumbre
Y el nivel 5 es, si ya haces tu proceso, ya lo mides, ahora preparate para innovar, para meter nueva tecnologia, para aprovechar oportunidades
Si, son cinco niveles , nada sencillos de alcanzar, pero la verdad es lo fundamental para sacar cualquier proyecto de desarrollo
He visto mucha gente desgastarse en poner decenas o centenas de programadores para sacar mas rapido proyectos, he visto muchos gritando y matando gente bajando la calidad de vida, trabajo inutil en sabado y domingo. Y he visto como en muchos proyectos se tienen que admitir resultados tecnicamente mediocres, con que jale mañana esta bien, al otro dia vemos
Y no es mala fe de las personas, creo que cuando todos arrancamos un proyecto, pensamos " acabo en la fecha, siendo amigos de todos los involucrados y me tomo mis vacaciones". Pero es vivir de la ilusion
Sin embargo, esa buena fe de las personas puede ser mejor utilizada si decidieran abrir su mente al modelo que les menciono o similar. Es ser profesional en tu manera de ser, es hacer lo que debe hacerse, quitarte de tu complejo de superprogramador o de mandon
Solo es estudiar, leer y usarlo para servir a los demas en base a tu conocimiento
Asi que yo creo que mucho de lo puesto en este blog, integracion a la mexicana no es para enfatizar el error de alguien. Es para aprender de la experiencia y demostrar que mas vale razonar las cosas que andar de griton o neurastenico con la gente, que al final son humanos como todos.
Asi que, busquen en Google la palabra CMMI. Puede ser que se topen con un documento muy grande del SEI, muy abstracto; pero al entenderlo, se van a perctar que es tan noble como cualquier pieza de ingenieria hecha por los humanos.
Una vez mas, esto no es religion es ingenieria
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.
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
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, 21 de mayo de 2007
SOAPUI una buena herramienta
Hola que tal !!!!!
De nuevo por aqui... esperando que tengan un excelente inicio de semana!!!!
... pues quiero recomendarles una herramienta libre que me encontre en la red, quiza ya algunos de ustedes la han usado su nombre es SoapUI, esta herramiente es muy buena, excelente diria yo... puedes hacer invocaciones de webservices y para mi lo mas practico que le encontre a la herramienta... generacion de mockservices...
Es muy sencilla de utilizar... solo registras tu WSDL y listo !!! ya tienes un generador de peticiones...
SoapUi lo utilizo para enviar mensajes al canal ESB, asi como para generar clientes de web services sin necesidad de montar un application server para mi servicio web....espero les sea de utilizad...
PD. trate de hacerla jalar en ubuntu.. y por alguna razon...no me funciono.. si alguno de ustedes lo logra.. ponganse la del puebla...
Por una integracion mejor, hasta la vista!!!
Tuzo, mas feliz que nunca :)
De nuevo por aqui... esperando que tengan un excelente inicio de semana!!!!
... pues quiero recomendarles una herramienta libre que me encontre en la red, quiza ya algunos de ustedes la han usado su nombre es SoapUI, esta herramiente es muy buena, excelente diria yo... puedes hacer invocaciones de webservices y para mi lo mas practico que le encontre a la herramienta... generacion de mockservices...
Es muy sencilla de utilizar... solo registras tu WSDL y listo !!! ya tienes un generador de peticiones...
SoapUi lo utilizo para enviar mensajes al canal ESB, asi como para generar clientes de web services sin necesidad de montar un application server para mi servicio web....espero les sea de utilizad...
PD. trate de hacerla jalar en ubuntu.. y por alguna razon...no me funciono.. si alguno de ustedes lo logra.. ponganse la del puebla...
Por una integracion mejor, hasta la vista!!!
Tuzo, mas feliz que nunca :)
miércoles, 16 de mayo de 2007
Barbaridades y cosas similares en el desarrollo de software
Hola que tal !!!
...... pues los quiero invitar a que visiten el blog tuzoftware.blogspot.com que abrieron unos buenos amigos (de la bella ciudad de pachuca por supuesto¡¡¡) con los que he compartido buenos y malos ratos dentro del desarrollo de sistemas.... al buen Toño, Rulo, Ivancillo, Ranas y al Zamo, que estaran platicando lo que viven dia a dia ( y alguna que otra frustracion :D) en las cuestiones en desarrollo de software y otras barbaries como le llaman... a ellos los conoci hace 7 años cuando trabajamos juntos en la Bolsa Mexicana de Valores... tiempo despues formamos una pequeña consultora llamada Tuzoftware y hasta la fecha tenemos contacto...
Por lo pronto el Toño publico su primer post que habla de ... "El negativismo Pragmático" jajaja pues adelante.......... mucha suerte , bienvenidas las aportaciones y experiencias !!!!
Por el buen compartir, hasta la vista!!
Tuzo
...... pues los quiero invitar a que visiten el blog tuzoftware.blogspot.com que abrieron unos buenos amigos (de la bella ciudad de pachuca por supuesto¡¡¡) con los que he compartido buenos y malos ratos dentro del desarrollo de sistemas.... al buen Toño, Rulo, Ivancillo, Ranas y al Zamo, que estaran platicando lo que viven dia a dia ( y alguna que otra frustracion :D) en las cuestiones en desarrollo de software y otras barbaries como le llaman... a ellos los conoci hace 7 años cuando trabajamos juntos en la Bolsa Mexicana de Valores... tiempo despues formamos una pequeña consultora llamada Tuzoftware y hasta la fecha tenemos contacto...
Por lo pronto el Toño publico su primer post que habla de ... "El negativismo Pragmático" jajaja pues adelante.......... mucha suerte , bienvenidas las aportaciones y experiencias !!!!
Por el buen compartir, hasta la vista!!
Tuzo
martes, 15 de mayo de 2007
Utilizando el ruteo basado en contenido y JMS
Hola de nuevo por aqui...
Despues de dos semanas algo ajetreadas entre viajes cortos a la ciudad de pachuca, regresamos al trabajo con las pilas algo bajas, pero con el gusto de continuar con nuestra labor..
En el instituto tenemos sistemas de bastantes sabores... ¿cuantos? R= muchos :D, imperan dos ambientes: aplicaciones que se encuentran en la CD de mexico y monterrey , asi como aplicaciones regadas en las 32 delegaciones de la republica mexicana.
Hace aproximadamente un año nos pidieron el requerimiento de conectar un sistema que esta instalado individualmente en cada delegacion, tiene su servidor y esta completamente independiente...... con otro que se encuentra en el CENATI (centro nacional de tecnologias de informacion) de Monterrey, ventaja numero uno estaban desarrollados en Java (el central en Weblogic y los de las delegaciones en Websphere)....
El requerimiento puntual fue... entregar dictamentes a cada unidad de medicina familiar.. provenientes de el sistema central de salud en el trebajo...
El diseño final fue contener una cola JMS para cada una de las delegaciones y mediante el ruteo basado en contenido para realizar la entrega.... hubo quien sugirio publicar un webservice por cada delegacion para recibir.. en fin... y no es que sea malo.. pero para un ambiente completamente asioncrono las colas JMS funcionan a la perfecccion...
Como se puede ver en la imagen, el sistema de salud en el trabajo invoca de manera sincrona a un servicio web central, este se encarga de guardar el mensaje en una cola central asi como de transformar el mensaje... posteriormente existe un Message Driven Bean consumiendo de la cola central que se basa en el contenido ( Content Based Router, ) para entregar a la cola final que esta en MQ Series.
Algunas ventajas de este modelo: trabajo completamente asincrono, si algun aplicacion de medicina familiar esta abajo los mensajes quedan almacenados en su cola y sobretodo existe garantia de entrega.
Posteriormente hay que revisar algunas estrategias de consumo de colas JMS, porque no todo el codigo que se escribe para consumir es el mejor... ;)...
Por una integracion mejor, hasta la vista!!
Tuzo
Despues de dos semanas algo ajetreadas entre viajes cortos a la ciudad de pachuca, regresamos al trabajo con las pilas algo bajas, pero con el gusto de continuar con nuestra labor..
En el instituto tenemos sistemas de bastantes sabores... ¿cuantos? R= muchos :D, imperan dos ambientes: aplicaciones que se encuentran en la CD de mexico y monterrey , asi como aplicaciones regadas en las 32 delegaciones de la republica mexicana.
Hace aproximadamente un año nos pidieron el requerimiento de conectar un sistema que esta instalado individualmente en cada delegacion, tiene su servidor y esta completamente independiente...... con otro que se encuentra en el CENATI (centro nacional de tecnologias de informacion) de Monterrey, ventaja numero uno estaban desarrollados en Java (el central en Weblogic y los de las delegaciones en Websphere)....
El requerimiento puntual fue... entregar dictamentes a cada unidad de medicina familiar.. provenientes de el sistema central de salud en el trebajo...
El diseño final fue contener una cola JMS para cada una de las delegaciones y mediante el ruteo basado en contenido para realizar la entrega.... hubo quien sugirio publicar un webservice por cada delegacion para recibir.. en fin... y no es que sea malo.. pero para un ambiente completamente asioncrono las colas JMS funcionan a la perfecccion...
Como se puede ver en la imagen, el sistema de salud en el trabajo invoca de manera sincrona a un servicio web central, este se encarga de guardar el mensaje en una cola central asi como de transformar el mensaje... posteriormente existe un Message Driven Bean consumiendo de la cola central que se basa en el contenido ( Content Based Router, ) para entregar a la cola final que esta en MQ Series.
Algunas ventajas de este modelo: trabajo completamente asincrono, si algun aplicacion de medicina familiar esta abajo los mensajes quedan almacenados en su cola y sobretodo existe garantia de entrega.
Posteriormente hay que revisar algunas estrategias de consumo de colas JMS, porque no todo el codigo que se escribe para consumir es el mejor... ;)...
Por una integracion mejor, hasta la vista!!
Tuzo
Habemus Mono
Se acaba de anunciar la liberación de la nueva versión 1.2.4 de Mono.
Entre las novedades más notables encontramos:
Finito.
Entre las novedades más notables encontramos:
- Más de 1,000 métodos agregados y/o actualizados
- Soporte completo de ASP.NET 2.0 (bueno... casi... los Web Parts siguen pendientes pero ¿a quién le importa?)
- Mejoras en el desempeño de ASP.NET
- Inicios de la implementación de C# 3.0
- Mono en Solaris/AMD64
- Y varios items más
Finito.
miércoles, 9 de mayo de 2007
ideas,ideas,ideas
Pues aqui mientras estamos esperando unos mensajes para nuestro ESB, tengo la mente llena de un monton de ideas sobre SOA
Un poco cansado del dia, ya que empece desde las 5:45 a.m., solo voy a vaciar mi subconciente y de ahi espero desarrollar mas entradas del blog
... Usar el modelo de Servicios que vi con uno de los consultores "chipocludos" de BEA, que demostro que los servicios se pueden organizar por servicios de la empresa, de negocio, de conectividad, algo que habia ya pensado en el pasado
... Estructurar un servicio, sus vistas en un portal, como proceso, como data service, como metadato, como documento, como regla de negocio, como politica de seguridad. Y ver como ensamblarlo . Es analogo al modelo de multiples capas
... En menos de un dia me encontre con el concepto de "Programacion orientada a Lenguajes", software factories y convergencia con SOA
... Cambiar mi mente a pensar los sistemas como servicios.
... Integracion con el mainframe
... Insisto, el modelo de Peer-to-peer (P2P) podria influenciar fuertemente a SOA
... Todo mundo dice que este año es el de SOA, y aprovechar esa ventaja para hacer algo interesante, concrectar la idea de la barra multicontactos para conectar sus aplicaciones
... En el renacimiento, crearon tanto por los principios de la vision y filosofia griega. Usaron la razon para hacer obras pereenes, El Orfeo de MonteVerdi, el David de Miguel Angel, la ciudad de Florencia, todos basados en principios similares a la arquitectura, y siguen funcionando. ¿Por que no hacer lo mismo nosotros? ¿Por que no generar un renacimiento en los sistemas y romper dogmas?
Un poco cansado del dia, ya que empece desde las 5:45 a.m., solo voy a vaciar mi subconciente y de ahi espero desarrollar mas entradas del blog
... Usar el modelo de Servicios que vi con uno de los consultores "chipocludos" de BEA, que demostro que los servicios se pueden organizar por servicios de la empresa, de negocio, de conectividad, algo que habia ya pensado en el pasado
... Estructurar un servicio, sus vistas en un portal, como proceso, como data service, como metadato, como documento, como regla de negocio, como politica de seguridad. Y ver como ensamblarlo . Es analogo al modelo de multiples capas
... En menos de un dia me encontre con el concepto de "Programacion orientada a Lenguajes", software factories y convergencia con SOA
... Cambiar mi mente a pensar los sistemas como servicios.
... Integracion con el mainframe
... Insisto, el modelo de Peer-to-peer (P2P) podria influenciar fuertemente a SOA
... Todo mundo dice que este año es el de SOA, y aprovechar esa ventaja para hacer algo interesante, concrectar la idea de la barra multicontactos para conectar sus aplicaciones
... En el renacimiento, crearon tanto por los principios de la vision y filosofia griega. Usaron la razon para hacer obras pereenes, El Orfeo de MonteVerdi, el David de Miguel Angel, la ciudad de Florencia, todos basados en principios similares a la arquitectura, y siguen funcionando. ¿Por que no hacer lo mismo nosotros? ¿Por que no generar un renacimiento en los sistemas y romper dogmas?
Entre servicios te veas
En una prueba de integración entre una aplicación .NET y otra desarrollada en Java nos apareció este mensaje:
¿Qué tiene de malo? (aparte de algunas faltas de ortografía) Son dos servicios que están intercambiando mensajes entre sí. No tienen interacción con el usuario, así que este tipo de mensajes, descriptivos y detallados, son completamente desaprovechados en este contexto.
Entonces ¿cuál es el modo correcto de devolver errores en este caso? No sé cual sea el modo correcto. Lo que a mi me gusta es el estilo de AppExchange Web Service API.
AppExchange (anteriormente conocida como Salesforce) es una empresa que ofrece software as a service (SaaS), en particular un CRM que compite directamente contra los grandes: Siebel, SAP y otros. Les ha ganado una gran tajada del mercado y sigue abriendo áreas de oportunidad. La API que comento la ofrecen mediante servicios web y tiene la funcionalidad de agregar, actualizar, borrar y buscar items de su mega repositorio de datos.
Así, en esas operaciones obviamente se envían y devuelven resultados en un contexto de integración de servicios. ¿Cómo le hacen? Va la referencia del API:
Tenemos la llamada create que recibe un arreglo de sObjects (tipo nativo de AppExchange) y como resultado devuelve un arreglo de objetos SaveResult. Ahora veamos SaveResult:
Nos devuelve un objeto con el identificador único (idField), una bandera de éxito o fracaso (successField) y un arreglo de objetos Error, igualmente veamos:
En fieldsField tenemos el o los nombres de los campos que provocaron el error; messageField es el texto descriptivo del error y finalmente statusCodeField que es el código que identifica el error dentro de un catálogo disponible en el WSDL del servicio.
Si bien tenemos un texto descriptivo, tenemos otras referencias (statusCodeField, successField) que nos permiten atender el problema y darle solución dentro de un contexto de integración.
A mi parecer es la falta de comprensión de los escenarios en los que se trabaja lo que provoca este tipo de diseños. Ya se requiere cambiar el modelo y empezar a modelar servicios. En algún momento habrá un servicio que se encargue de interactuar con el usuario y habrá que darle la suficiente información para que resuelva los problemas que lleguen a aparecer.
Por eso, entre servicios te veas, comportate como un servicio.
Finito.
Exito: 0
Código Error: 100
Desc. Error: mx.gob.imss.sigoi.quejaVerbal.exception.ValidaCampoException:
El campo Calidad de la persona que se comunica es requerido.
El campo Nombre de la persona que se comunica es requerido.
El campo Apellido paterno de la persona que se comunica es requerido.
El campo Lada de teléfono particular de la persona que se comunica tiene que ser numérico.
El campo Lada de teléfono particular de la persona que se comunica tiene una longitud no valida, menor a 2 Caracteres
El campo Teléfono particular de la persona que se comunica tiene que ser numérico.
El campo Teléfono particular de la persona que se comunica tiene una longitud no valida, menor a 8 Caracteres
El campo Teléfono celular de la persona que se comunica tiene que ser numérico.
El campo Teléfono celular de la persona que se comunica tiene una longitud no valida, menor a 12 Caracteres
El campo Correo electrónico de la persona que se comunica no tiene un formato adecuado
Se tiene que incluir al menos un medio de contacto valido de la persona que se
comunica: Lada y número de teléfono particular, número de teléfono celular, correo electrónico, o dirección completa
Es necesario capturar el NSS de la persona que se comunica
Es necesario capturar el NSS de la persona que solicita el servicio
El campo Calidad de la persona que solicita el servicio es requerido.
El campo Teléfono celular del usuario que solicita el servicio tiene que ser numérico.
El campo Teléfono celular del usuario que solicita el servicio tiene una longitud no valida, menor a 12 Caracteres
El campo Entidad federativa del usuario que solicita el servicio tiene que ser numérico.
El campo Entidad federativa del usuario que solicita el servicio no es un valor válido de catálogo
El campo Clasificación de la solicitud del planteamiento tiene que ser numérico.
El campo Clasificación de la solicitud del planteamiento no es un valor válido de catálogo
El campo Tema del planteamiento tiene que ser numérico.
El campo Tema del planteamiento no es un valor válido de catálogo
El campo Subtema del planteamiento tiene que ser numérico.
El campo Subtema del planteamiento no es un valor válido de catálogo
El campo Delegación de Adscripción del planteamiento no es un valor válido de catálogo
El campo Unidad Medica de Adscripción del planteamiento tiene que ser numérico.
El campo Unidad Medica de Adscripción del planteamiento no es un valor válido de catálogo
El campo Delegación o UMAE involucrada en la gestión o queja del planteamiento tiene que ser numérico.
El campo Delegación o UMAE involucrada en la gestión o queja del planteamiento no es un valor válido de catálogo
El campo Subdeleación y/o Unidad involucrada en la gestión o queja del planteamiento tiene que ser numérico.
El campo Subdeleación y/o Unidad involucrada en la gestión o queja del planteamiento no es un valor válido de catálogo
¿Qué tiene de malo? (aparte de algunas faltas de ortografía) Son dos servicios que están intercambiando mensajes entre sí. No tienen interacción con el usuario, así que este tipo de mensajes, descriptivos y detallados, son completamente desaprovechados en este contexto.
Entonces ¿cuál es el modo correcto de devolver errores en este caso? No sé cual sea el modo correcto. Lo que a mi me gusta es el estilo de AppExchange Web Service API.
AppExchange (anteriormente conocida como Salesforce) es una empresa que ofrece software as a service (SaaS), en particular un CRM que compite directamente contra los grandes: Siebel, SAP y otros. Les ha ganado una gran tajada del mercado y sigue abriendo áreas de oportunidad. La API que comento la ofrecen mediante servicios web y tiene la funcionalidad de agregar, actualizar, borrar y buscar items de su mega repositorio de datos.
Así, en esas operaciones obviamente se envían y devuelven resultados en un contexto de integración de servicios. ¿Cómo le hacen? Va la referencia del API:
SaveResult[] = sfdc.create(sObject[] sObjects);
Tenemos la llamada create que recibe un arreglo de sObjects (tipo nativo de AppExchange) y como resultado devuelve un arreglo de objetos SaveResult. Ahora veamos SaveResult:
private Error[] errorsField;
private string idField;
private bool successField;
Nos devuelve un objeto con el identificador único (idField), una bandera de éxito o fracaso (successField) y un arreglo de objetos Error, igualmente veamos:
private string[] fieldsField;
private string messageField;
private StatusCode statusCodeField;
En fieldsField tenemos el o los nombres de los campos que provocaron el error; messageField es el texto descriptivo del error y finalmente statusCodeField que es el código que identifica el error dentro de un catálogo disponible en el WSDL del servicio.
Si bien tenemos un texto descriptivo, tenemos otras referencias (statusCodeField, successField) que nos permiten atender el problema y darle solución dentro de un contexto de integración.
A mi parecer es la falta de comprensión de los escenarios en los que se trabaja lo que provoca este tipo de diseños. Ya se requiere cambiar el modelo y empezar a modelar servicios. En algún momento habrá un servicio que se encargue de interactuar con el usuario y habrá que darle la suficiente información para que resuelva los problemas que lleguen a aparecer.
Por eso, entre servicios te veas, comportate como un servicio.
Finito.
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
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
martes, 1 de mayo de 2007
Enterprise Information Integration
Hola mis queridos dos lectores!, de nuevo dando lata
Antes de comenzar, quiero agradecer nuevamente al Mtro. Heriberto Garcia por haberme invitado al congreso de TICs en la hermosa ciudad de Pachuca, así tambien a los asistentes que tuve en la platica relacionada con el ESB, en verdad fue una bonita experiencia, en breve publicare el codigo del ejemplo para que le echen un vistazo...
Bueno pues zapatero, a tus zapatos.... hoy en dia hemos escuchado acerca del termino Software Oriented Architecture, una vision arquitectonica que esta tomando un auge importante, aunque no todas las organizaciones estan preparadas aun para dar un paso hacia SOA (que ojo, SOA no es solo web services... ese es tema de otro post).
..una vision que hemos adoptado en el trabajo es es la siguiente: SOA = SODA + EII + BPM+ Registro + ESB y agregare cultura..
Esos temas los iremos tocando poco a poco, hoy hablare de el Enterprise Information Integration, ¿que es? bien... el la idea principal de EII, es que podemos crear un Modelo Virtual de Datos a partir de una fuente fisica, a estos servicios se les conoce como Data Services, esto es muy interesante ya que puedes exponer una fuente de datos como un servicio.
Una de las partes que me llama la atencion del EII, es que puedes federar informacion, es decir, puedes generar multiples modelos fisicos (Base de Datos, XML, File, Web Services) y mediante un modelo Logico puedes generar una sola vista a los datos, esto es muy interesante ya que modelas apartir de tus metadatos, no de las fuentes fisicas.
Algunos ejemplos que vienen a la mente, catalogos comunes, multiples bases de datos accesadas mediante un data service, federacion de multiples fuentes de datos, en fin.
En el trabajo tenemos el Aqualogic Data Services, actualmente estamos en el proceso de explotacion de la herramienta, en breve expondre los casos de uso que estamos echando a andar.
Aqui les dejo unas ligas interesantes acerca de este tema:
EII helps BI adapt to SOA
when to use EII
Understanding the Service Lifecycle within a SOA: Run Time
Espero que esta introduccion a los EIIs les sea de utilidad, estare publicando mas cosas acerca de este tema.
Comentarios, criticas y aportaciones bienvenidas.
Por una integracion mejor, hasta la vista!!
Tuzo.
Antes de comenzar, quiero agradecer nuevamente al Mtro. Heriberto Garcia por haberme invitado al congreso de TICs en la hermosa ciudad de Pachuca, así tambien a los asistentes que tuve en la platica relacionada con el ESB, en verdad fue una bonita experiencia, en breve publicare el codigo del ejemplo para que le echen un vistazo...
Bueno pues zapatero, a tus zapatos.... hoy en dia hemos escuchado acerca del termino Software Oriented Architecture, una vision arquitectonica que esta tomando un auge importante, aunque no todas las organizaciones estan preparadas aun para dar un paso hacia SOA (que ojo, SOA no es solo web services... ese es tema de otro post).
..una vision que hemos adoptado en el trabajo es es la siguiente: SOA = SODA + EII + BPM+ Registro + ESB y agregare cultura..
Esos temas los iremos tocando poco a poco, hoy hablare de el Enterprise Information Integration, ¿que es? bien... el la idea principal de EII, es que podemos crear un Modelo Virtual de Datos a partir de una fuente fisica, a estos servicios se les conoce como Data Services, esto es muy interesante ya que puedes exponer una fuente de datos como un servicio.
Una de las partes que me llama la atencion del EII, es que puedes federar informacion, es decir, puedes generar multiples modelos fisicos (Base de Datos, XML, File, Web Services) y mediante un modelo Logico puedes generar una sola vista a los datos, esto es muy interesante ya que modelas apartir de tus metadatos, no de las fuentes fisicas.
Algunos ejemplos que vienen a la mente, catalogos comunes, multiples bases de datos accesadas mediante un data service, federacion de multiples fuentes de datos, en fin.
En el trabajo tenemos el Aqualogic Data Services, actualmente estamos en el proceso de explotacion de la herramienta, en breve expondre los casos de uso que estamos echando a andar.
Aqui les dejo unas ligas interesantes acerca de este tema:
EII helps BI adapt to SOA
when to use EII
Understanding the Service Lifecycle within a SOA: Run Time
Espero que esta introduccion a los EIIs les sea de utilidad, estare publicando mas cosas acerca de este tema.
Comentarios, criticas y aportaciones bienvenidas.
Por una integracion mejor, hasta la vista!!
Tuzo.
viernes, 27 de abril de 2007
2° Congreso Universitario en TICs - UAEH
Pues el miércoles fue la fecha. Avanzaba el calendario y simplemente no veía llegar el 25. Y finalmente llegó.
Para llegar hubo que dar una vuelta harto curiosa. De la hermana república de Coacalco al paradero del metro de Indios Verdes, la terminal ADO y el autobús a la Bella Airosa. Un viaje tranquilo en el cual tuve el chance de leer un artículo de Juval Lowy sobre lo es al fin y al cabo el patrón Correlation Identifier implementado con WCF.
Finalmente llegué a la terminal de autobuses y ya me estaba esperando Heriberto García Islas, amigo del Tuzo y organizador del Congreso. Nos fuimos a la UAEH y me presentó con algunas autoridades de la uni, me instaló en su cubículo y esperando el inicio de las conferencias me dediqué a dar el rol por el campus.
Había un ambiente muy festivo, caminando me encontré con un concurso de canto y otro de vencidas :P. Había partidos deportivos y un bonche de chavos que iban y venían. Llegué hasta el Polideportivo y me quede contemplando un rato la vista.
El reloj marcó la hora y me regresé para asistir a la conferencia del Dr. Antonio Quiróz acerca de la formalización del modelo Watson-Creek del ADN. Es increíble la forma tan natural y sencilla de hablar de temas tan especializados y conseguir ese link con la audiencia tan jovén (excepto yo). Entre anécdotas personales y de la historia de la ciencia nos dió una introducción a la investigación del ADN y la participación de varios científicos mexicanos, incluido él mismo en análisis, planteamientos y respuestas. Realmente es un personaje.
Al terminar su ponencia, seguía mi turno en otra sala del campus y sin más me dirigí para prepararme. Conectar el proyector a la lap, arrancar, poner la presentación y después de la introducción sobre mi persona empezar. Agregué algunas láminas para esta ocasión y fui platicando sobre el tema Introducción al Proyecto Mono. Finalmente llegué al punto de los demos y los primeros que son los que realizo sobre Windows fluyeron sin complicación, pero al reiniciar la máquina para mostrar los demos en Linux ¿qué creen que pasó?
Sip. Una vez más. ¡torpe, torpe, torpe! No se proyecto nada de nada. No saben como odio eso. La próxima vez, que será en el FONASOL a finales de mayo, primero voy a probar si consigue proyectar desde Linux y voy armar una máquina virtual con Windows para hacer las demos y si no funciona con Linux en Windows voy a tener una máquina virtual con Linux. En fin. Esta vez no hubo muchas preguntas y de nuevo insisto en que si hay comentarios me los hagan llegar. Al final tuve el gusto de conocer a un par de chavos entusiastas del software libre: Darío Navarro Rosales y a David Hernández Pérez, quienes son miembros del GULEH y conocidos de Iver y Akin0, .
Después, Heriberto tuvo el detalle de invitar la comida, pero desgraciadamente su función de organizador le impidió acompañarnos y me senté a comer y platicar con Darío y David. Bueno, medio platicar ya que en ese rato se estaba instalando la Orquesta Sinfónica de UAEH para ofrecer algunas piezas. Terminamos un poco antes de iniciar el concierto y nos acomodamos para escucharlo. Piezas sencillas que encontré en mis recuerdos de cuando miraba las caricaturas en la tele los sábados por la mañana.
No hay nada como la música viva y este caso no fue la excepción. Realmente lo disfruté bastante, sobre todo cuando el director invitó a alguien del público que pasará a dirigir la orquesta y Heriberto saltó como resorte. Un momento muy divertido.
Bueno, fue un día excelente gracias a la gente de la UAEH, empezando por Heriberto por darnos la oportunidad de participar en el Congreso, por conocer al Dr. Quiroz, fue muy, muy emocionante y motivante y por ver chavos clavados con el software libre. Muchas gracias a todos.
Finito.
Para llegar hubo que dar una vuelta harto curiosa. De la hermana república de Coacalco al paradero del metro de Indios Verdes, la terminal ADO y el autobús a la Bella Airosa. Un viaje tranquilo en el cual tuve el chance de leer un artículo de Juval Lowy sobre lo es al fin y al cabo el patrón Correlation Identifier implementado con WCF.
Finalmente llegué a la terminal de autobuses y ya me estaba esperando Heriberto García Islas, amigo del Tuzo y organizador del Congreso. Nos fuimos a la UAEH y me presentó con algunas autoridades de la uni, me instaló en su cubículo y esperando el inicio de las conferencias me dediqué a dar el rol por el campus.
Había un ambiente muy festivo, caminando me encontré con un concurso de canto y otro de vencidas :P. Había partidos deportivos y un bonche de chavos que iban y venían. Llegué hasta el Polideportivo y me quede contemplando un rato la vista.
El reloj marcó la hora y me regresé para asistir a la conferencia del Dr. Antonio Quiróz acerca de la formalización del modelo Watson-Creek del ADN. Es increíble la forma tan natural y sencilla de hablar de temas tan especializados y conseguir ese link con la audiencia tan jovén (excepto yo). Entre anécdotas personales y de la historia de la ciencia nos dió una introducción a la investigación del ADN y la participación de varios científicos mexicanos, incluido él mismo en análisis, planteamientos y respuestas. Realmente es un personaje.
Al terminar su ponencia, seguía mi turno en otra sala del campus y sin más me dirigí para prepararme. Conectar el proyector a la lap, arrancar, poner la presentación y después de la introducción sobre mi persona empezar. Agregué algunas láminas para esta ocasión y fui platicando sobre el tema Introducción al Proyecto Mono. Finalmente llegué al punto de los demos y los primeros que son los que realizo sobre Windows fluyeron sin complicación, pero al reiniciar la máquina para mostrar los demos en Linux ¿qué creen que pasó?
Sip. Una vez más. ¡torpe, torpe, torpe! No se proyecto nada de nada. No saben como odio eso. La próxima vez, que será en el FONASOL a finales de mayo, primero voy a probar si consigue proyectar desde Linux y voy armar una máquina virtual con Windows para hacer las demos y si no funciona con Linux en Windows voy a tener una máquina virtual con Linux. En fin. Esta vez no hubo muchas preguntas y de nuevo insisto en que si hay comentarios me los hagan llegar. Al final tuve el gusto de conocer a un par de chavos entusiastas del software libre: Darío Navarro Rosales y a David Hernández Pérez, quienes son miembros del GULEH y conocidos de Iver y Akin0, .
Después, Heriberto tuvo el detalle de invitar la comida, pero desgraciadamente su función de organizador le impidió acompañarnos y me senté a comer y platicar con Darío y David. Bueno, medio platicar ya que en ese rato se estaba instalando la Orquesta Sinfónica de UAEH para ofrecer algunas piezas. Terminamos un poco antes de iniciar el concierto y nos acomodamos para escucharlo. Piezas sencillas que encontré en mis recuerdos de cuando miraba las caricaturas en la tele los sábados por la mañana.
No hay nada como la música viva y este caso no fue la excepción. Realmente lo disfruté bastante, sobre todo cuando el director invitó a alguien del público que pasará a dirigir la orquesta y Heriberto saltó como resorte. Un momento muy divertido.
Bueno, fue un día excelente gracias a la gente de la UAEH, empezando por Heriberto por darnos la oportunidad de participar en el Congreso, por conocer al Dr. Quiroz, fue muy, muy emocionante y motivante y por ver chavos clavados con el software libre. Muchas gracias a todos.
Finito.
lunes, 23 de abril de 2007
Contratos de Negocio (Parte 2)
Hola que tal !!
De regreso a la chamba :)
La semana pasada fue algo interesante, asistí al Gartner Enterprise Integration Summit, en el cual se tocaron temas de Integración de aplicaciones, Servicios Web, SOA y BPM.... tuve la oportunidad de platicar con algunos ponentes.. en estos días compartiré parte de lo aprendido en estas conferencias...
Pues zapatero a tus zapatos, bien pues la semana pasada publicamos un tema acerca de los contratos de negocio, bien pues ahora toca el turno a la parte TECNICA.....
Una vez que se tiene el contrato de negocio, es necesario revisar la parte técnica de la solución, para lo cual es necesario revisar lo siguiente:
En cuanto a la parte de las Aplicaciones participantes en la integración, por cada una:
- Plataforma de Hardware
- Plataforma de Sistema Operativo
- Protocolos de Red (TCP/IP,SNA)
- Protocolos de Aplicaciones (CORBA, COM, HTTP, Telnet, FTP, SMTP)
- Software de terceros (Bases de datos, Monitor de transacciones, ERP, Servidor de Aplicaciones, Portal)
- Plataforma de desarrollo (C, C++, Java, .Net)
En cuanto a la parte del servicio de integración algunos aspectos importantes son:
- Modelo de invocación (síncrono/asíncrono)
- Protocolo entre consumidor y servicio de integración (RMI, JMS, SOAP, CORBA)
- Protocolo entre publicador y servicio de integración (RMI, JMS, SOAP, CORBA, FTP, HTTP, SMTP, ATMI. etc)
- Acciones ante fallas dentro del servicio de integración
- Acciones ante fallas en el consumidor
- Acciones ante fallas en el publicador
Existen otras cuestiones importantes que se necesitan documentar, como lo es la gestión de mensajes (esto cuando existe una solución mediante MOM) así como la transformación de mensajes (tema de otro post).
Aquí los roles importantes son: persona técnica de ambas aplicaciones y el arquitecto de integración.
Espero que estas 2 entregas, les sirvan como apoyo en su proceso de documentar sus servicios de integración.
Comentarios, críticas, aportaciones bienvenidas :)
Por una integración mejor, hasta la vista!!
Tuzo
lunes, 16 de abril de 2007
Contratos de Negocio (Parte 1)
Hola que tal, mis queridos dos lectores!!!
De nuevo dando lata, después de un agradable fin de semana....:D
Entremos en materia, ahora es el turno de hablar de los contratos de negocio...
Pues bien cada que necesitamos integrar aplicaciones, hemos tomado como regla generar un contrato de negocio.... básicamente es un documento NO TECNICO, que en la mayoría de los casos es generado por los analistas de negocio. Entre otras cosas este documento contiene:
- Datos de entrada: diccionario de datos con nombre, tipo, tamaño, campos requeridos y valores permitidos que serán la entrada para el servicio de negocio a integrar
- Datos de salida: diccionario de datos con nombre, tipo, tamaño y valores permitidos que serán entregados por el servicio de negocio
- Errores de negocio: catalogo de errores que pertenecerán al negocio
- Errores de infraestructura y comunicación: errores que se pueden generar dentro de la infraestructura de integración (esto se detalla en la parte técnica del contrato)
- Diagramas: generalmente diagramas de secuencia que muestran como se dispara el evento
- Frecuencia: mencionar cada cuando se da este evento de negocio, generalmente se expresa en horarios
- Volúmenes esperados: volumen de información esperada por el evento de negocio
Como verán los datos presentados en el documento nos ayudan a nosotros como integradores a tomar ciertas decisiones de la solución técnica.... el rol importante en la generación de este contrato es el Analista de Negocio. Cabe mencionar que nosotros no realizamos ningún trabajo de integración hasta que NO este terminado y acordado este contrato (de ahí su nombre) por ambas partes del negocio.... ;)
Algo muy importante en este contrato es que NO se mencionen cuestiones Técnicas, no se dice si será un servicio web, una cola JMS (aunque muchos usuarios sienten que pueden recomendarte
la solución :S), etc... Este es tema de la segunda parte del contrato: la parte técnica.......
Cualquier comentario, aportación, critica... bienvenido
Por una integración mejor, hasta la vista !!!!!
Tuzo
jueves, 12 de abril de 2007
2do Congreso en TICs, Pachuca Hgo
Hola!!
El dia 25 y 26 de Abril, Chillicoder y su servidor, estaremos dando 2 platicas dentro del marco del 2do Congreso Universitario en Tecnologias y Comunicaciones, a celebrarse en la cd de Pachuca Hidalgo, por cierto quiero agradecer al Mtro. Heriberto Garcia Islas por habernos invitado.
Seran dos platicas una la dara Martin, en la que tratara temas de Mono y otra que dare yo, en la que hablare de ESB y cuestiones de integracion...
Si tienen oportunidad de ir al congreso estan invitados, la entrada es gratuita, solo que no tendran acceso a los materiales de las ponencias.. si quieren tener el material, solo se mochan con 100 pesos para la entrada.
Saludos !!!!
Tuzo
El dia 25 y 26 de Abril, Chillicoder y su servidor, estaremos dando 2 platicas dentro del marco del 2do Congreso Universitario en Tecnologias y Comunicaciones, a celebrarse en la cd de Pachuca Hidalgo, por cierto quiero agradecer al Mtro. Heriberto Garcia Islas por habernos invitado.
Seran dos platicas una la dara Martin, en la que tratara temas de Mono y otra que dare yo, en la que hablare de ESB y cuestiones de integracion...
Si tienen oportunidad de ir al congreso estan invitados, la entrada es gratuita, solo que no tendran acceso a los materiales de las ponencias.. si quieren tener el material, solo se mochan con 100 pesos para la entrada.
Saludos !!!!
Tuzo
martes, 10 de abril de 2007
SOA Maturity Model
De nuevo dando lata¡
¿Es posible medir el nivel de madurez SOA? ....
Hace un tiempo revisando algunos articulos de SOA y ESB, me encontre con un white paper acerca de SOA Maturity Model, en él hablan de un modelo que te ayuda a "medir" el nivel de madurez SOA. Como se daran cuenta, este modelo tiene una relacion directa con los 5 niveles de CMM, solo que el modelo del que les hablo esta mas aterrizado a cuestiones tecnicas de SOA.
Muchas cosas con las que he trabajado y otras de las que habia oido hablar (ESB, BAM, BPM, BPEL etc) hicieron sentido cuando revise el modelo de madurez.
El modelo se compone de 5 niveles...
Comentarios bienvenidos.
Por una integracion mejor, hasta la vista !!!!!!
Tuzo
¿Es posible medir el nivel de madurez SOA? ....
Hace un tiempo revisando algunos articulos de SOA y ESB, me encontre con un white paper acerca de SOA Maturity Model, en él hablan de un modelo que te ayuda a "medir" el nivel de madurez SOA. Como se daran cuenta, este modelo tiene una relacion directa con los 5 niveles de CMM, solo que el modelo del que les hablo esta mas aterrizado a cuestiones tecnicas de SOA.
Muchas cosas con las que he trabajado y otras de las que habia oido hablar (ESB, BAM, BPM, BPEL etc) hicieron sentido cuando revise el modelo de madurez.
El modelo se compone de 5 niveles...
- Initial Services: Indica fases de exploracion y adopcion SOA, se logra que en los proyectos de desarrollo se integre SOA como parte de la arquitectura, se utilizan como estandar WSDL, SOAP, J2EE y .NET, en este nivel existen servicios creados para necesidades inmediatas NO para servicios de negocio
- Architected Services: En este nivel entra la mediacion de servicios, ¿les suena a ESB?, en efecto, aqui entra en juego las caracteristicas de un ESB, mensajeria confiable (WS-RM), transformacion (Xquery), etc.. ademas de contar con un registros de los servicios como lo es UDDI. En este nivel se encuentra la integracion a bases de datos mediante EII.
- Business Services/Collaborative Services: Aqui entra en juego un punto de vista importante de los usuarios: EL NEGOCIO. Para estar en este nivel, ya se debe contar con el desarrollo de servicios de negocio. Existe tambien la colaboracion de servicios para lograr procesos que den mayor sentido a la organizacion, aqui es donde hace sentido lo que se conoce como Business Process Management
- Mesuared Business Services: Aqui en punto principal es el monitoreo de procesos.. tal como lo marca Business Activity Monitoring, por ejemplo proactivity es uno de ellos. En este nivel puedes tener metricas de los procesos de negocio basados en servicios ;)
- Optimized Business Services: como el nombre lo dice... ya que logarste tener metricas, viene la optimizacion de los procesos de negocio, aqui entra una cultura de mejoramiento continuo.
Comentarios bienvenidos.
Por una integracion mejor, hasta la vista !!!!!!
Tuzo
miércoles, 4 de abril de 2007
competing consumers
Hola mis dos lectores!!!! otra vez por aqui dando lata :D
Hace mas de año y medio (o quiza dos :D) cuando el proyecto de interoperabilidad empezo a tener mayor credibilidad en nuestra coordinacion (convencer.... sigue siendo un trabajo harto dificil, tema de otro post :D), nos llegaron una serie de solicitudes para realizar integracion con aplicaciones escritas en COBOL dentro del IBM Mainframe....ejemplificaré el caso de la consulta de los datos de un asegurado.
Teniamos (y seguimos teniendo) una serie de restricciones para el uso de esos sistemas, una de ellas quizá la que motivo este post, es que los usuarios que nos proporcionan para el acceso al sistema en COBOL NO son multisesion.
El resumen de restricciones significativas en el diseño son:
+ Numero limitado de usuarios para consulta, p.e. 10 usuarios
+ La interfaz debe de ser sincrona
+ Los usuarios no son multisesion
+ El usuario COBOL sera revocado, si el sistema en COBOL detecta que se han tratado de conectar el usuario dos veces en el mismo periodo de tiempo
Bien, pues nuevamente recurriendo al libro enterprise integration patterns, encontramos el patron competing consumers.
Como podran ver en la documentacion, este patron permite compartir una Cola JMS entre varios consumidores, de manera que puedes controlar el numero de consumidores y ejecutar tareas en paralelo por cada consumo de mensaje. De esta manera atacamos la restriccion del numero limitado de usuarios, asi como la garantia de que solo el usuario este firmado en un mismo instante de tiempo dentro de la aplicacion COBOL.
El diseño final quedo de la siguiente manera:
Paso 0: Cuando se arranca el servidor, se cargan las startup classes, en las cuales se levantan los N numero de threads de acuerdo al numero de usuarios con los que contemos, en la base de datos se encuentran las contraseñas para cada usuario.
Paso 1: El web service recibe la peticion y genera el mensaje que se enviara a la cola JMS
Paso 2: El web service genera una queue temporal en la cual recibira la respuesta
Paso 3: El Web service agrega al mensaje el objeto de la cola temporal y publica el mensaje en la cola JMS
Paso 4: El Web service se suscribe a la cola temporal que genero en espera de la respuesta
Paso 5: El thread que este disponible recibe la peticion y con las clases de negocio descompone el mensaje para enviarlo via Iway 3270 al mainframe
Paso 6: Mediante el adaptador se navega en la aplicacion y se obtiene el resultado de negocio
Paso 7: El thread obtiene el objeto de la cola temporal en donde va a depositar la respuesta, genera el mensaje de regreso y lo publica a la cola temporal
Paso 8: El web service obtiene el mensaje de su cola temporal suscrito y procesa la salida final al usuario.
Listo!
Pues asi es como resolvimos el problema.. y se puso en accion el patron competing consumers... de aqui surgio un nuevo rol dentro de nuestra area... el GSWD = Green Screen Wrapper Developer jejejeje
Cualquier comentario bienvenido..
Por una integracion mejor, hasta la vista.
Saludos !!!
Tuzo
Hace mas de año y medio (o quiza dos :D) cuando el proyecto de interoperabilidad empezo a tener mayor credibilidad en nuestra coordinacion (convencer.... sigue siendo un trabajo harto dificil, tema de otro post :D), nos llegaron una serie de solicitudes para realizar integracion con aplicaciones escritas en COBOL dentro del IBM Mainframe....ejemplificaré el caso de la consulta de los datos de un asegurado.
Teniamos (y seguimos teniendo) una serie de restricciones para el uso de esos sistemas, una de ellas quizá la que motivo este post, es que los usuarios que nos proporcionan para el acceso al sistema en COBOL NO son multisesion.
El resumen de restricciones significativas en el diseño son:
+ Numero limitado de usuarios para consulta, p.e. 10 usuarios
+ La interfaz debe de ser sincrona
+ Los usuarios no son multisesion
+ El usuario COBOL sera revocado, si el sistema en COBOL detecta que se han tratado de conectar el usuario dos veces en el mismo periodo de tiempo
Bien, pues nuevamente recurriendo al libro enterprise integration patterns, encontramos el patron competing consumers.
Como podran ver en la documentacion, este patron permite compartir una Cola JMS entre varios consumidores, de manera que puedes controlar el numero de consumidores y ejecutar tareas en paralelo por cada consumo de mensaje. De esta manera atacamos la restriccion del numero limitado de usuarios, asi como la garantia de que solo el usuario este firmado en un mismo instante de tiempo dentro de la aplicacion COBOL.
El diseño final quedo de la siguiente manera:
Paso 0: Cuando se arranca el servidor, se cargan las startup classes, en las cuales se levantan los N numero de threads de acuerdo al numero de usuarios con los que contemos, en la base de datos se encuentran las contraseñas para cada usuario.
Paso 1: El web service recibe la peticion y genera el mensaje que se enviara a la cola JMS
Paso 2: El web service genera una queue temporal en la cual recibira la respuesta
Paso 3: El Web service agrega al mensaje el objeto de la cola temporal y publica el mensaje en la cola JMS
Paso 4: El Web service se suscribe a la cola temporal que genero en espera de la respuesta
Paso 5: El thread que este disponible recibe la peticion y con las clases de negocio descompone el mensaje para enviarlo via Iway 3270 al mainframe
Paso 6: Mediante el adaptador se navega en la aplicacion y se obtiene el resultado de negocio
Paso 7: El thread obtiene el objeto de la cola temporal en donde va a depositar la respuesta, genera el mensaje de regreso y lo publica a la cola temporal
Paso 8: El web service obtiene el mensaje de su cola temporal suscrito y procesa la salida final al usuario.
Listo!
Pues asi es como resolvimos el problema.. y se puso en accion el patron competing consumers... de aqui surgio un nuevo rol dentro de nuestra area... el GSWD = Green Screen Wrapper Developer jejejeje
Cualquier comentario bienvenido..
Por una integracion mejor, hasta la vista.
Saludos !!!
Tuzo
viernes, 30 de marzo de 2007
patterns in action ;)
De nuevo dando lata!!
Hace unas semanas llegando al trabajo enciendo mi compu y veo un correo en donde me indican que una de las interfaces que recibe dictamenes y los envia a un sistema medico NO estaba funcionando... tranquilamente entro al solaris y al ver el log... oh sorpresa!! .. mis threads estaban atorados y un alegre conjunto de mensajes me decia:
Mar 15, 2007 8:44:02 AM CST Error WebLogicServer BEA-000337 ExecuteThread: '14' for queue: 'weblogic.kernel.Default' has been busy fo
r "657" seconds working on the request "Http Request: /WSRecibeST1/recepcionST1.jws"
.. a lo que tranquilamente me di a la tarea de reiniciar mi servidor pensando que con eso se resolveria el problema y una vez levantado revisar que fue lo que paso... je je je ¡oh sorpresa! los alegres mensajes de mis threads seguian saliendo.... y pense "Pus si mi interfaz ha estado operando en casi un año sin problemas..." asi es Tuzo, pero no con el volumen que mandaron esos dias..
El diseño estaba de la siguiente manera:
... el proceso de envío de dictamenes envía un mensaje XML en formato HL7, el servicio de integracion transforma el Xml a un formato de Java y lo envia al endpoint del servicio RMI, ¿sencillo no?, en efecto pero con lo que no contaba, es que RMI necesita dos threads para procesar una peticion.. es decir por un thread atiende y en otro responde.. por lo que en el momento que me mandaron carga, mis threads de ejecucion se terminaron (tenía 15 :D) y RMI no me regresaba la respuesta hasta que no existiera un thread disponible.... asi que entre en un deadlock..
.. pues de alguna manera teniamos que resolver el problema: controlar el numero de peticiones al servicio RMI.
Revisando el libro Enterprise Integration Patterns, se encuentra un patron llamado Competing Consumers, pensando en aplicar este patron para controlar el numero de threds que envia datos al servicio RMI, nos empezo a llegar la luz.
Gustavo y su servilleta pensamos en utilizar la solucion de Aqualogic Service Bus para este caso.... buscando en la documentacion de ALSB encontramos dos cosas A) el patron throttling pattern que permite controlar el grado de concurrencia y B) el concepto WorkManager que define restricciones de carga en threads, asi que nos pusimos manos a la obra y juntando lo anterior mas unas cuantas colas JMS, el resultado quedo en lo siguiente:
... el servicio envia el mensaje a un proxy service, este lo almacena en una cola JMS y libera la conexion, posteriomente un suscriptor consume (de uno en uno) y ejecuta un business service que se encarga de enviar (uno a uno) a la interfaz del EAI para que esta envíe finalmente al servicio RMI. Para garantizar que nuestra solucion funcionaria en produccion, usamos jmeter para enviar 600 mensajes y respondio sin problemas, enviando todos los mensajes en 1 minuto al servicio final.. como veran, con esta solucion es posible controlar el numero de peticiones al servicio final mediante los WorkManagers.
Tambien pueden aplicar el patron Competing Consumers y tendrian el mismo efecto, en algun momento les comentare como este patron nos resolvio un problema al conectarnos con servicios Mainframe.
Pues esta fue la solucion aplicada..
Comentarios y sugerencias son bienvenidos.
Por una integracion mejor, hasta la vista
Tuzo
Hace unas semanas llegando al trabajo enciendo mi compu y veo un correo en donde me indican que una de las interfaces que recibe dictamenes y los envia a un sistema medico NO estaba funcionando... tranquilamente entro al solaris y al ver el log... oh sorpresa!! .. mis threads estaban atorados y un alegre conjunto de mensajes me decia:
Mar 15, 2007 8:44:02 AM CST Error WebLogicServer BEA-000337 ExecuteThread: '14' for queue: 'weblogic.kernel.Default' has been busy fo
r "657" seconds working on the request "Http Request: /WSRecibeST1/recepcionST1.jws"
.. a lo que tranquilamente me di a la tarea de reiniciar mi servidor pensando que con eso se resolveria el problema y una vez levantado revisar que fue lo que paso... je je je ¡oh sorpresa! los alegres mensajes de mis threads seguian saliendo.... y pense "Pus si mi interfaz ha estado operando en casi un año sin problemas..." asi es Tuzo, pero no con el volumen que mandaron esos dias..
El diseño estaba de la siguiente manera:
... el proceso de envío de dictamenes envía un mensaje XML en formato HL7, el servicio de integracion transforma el Xml a un formato de Java y lo envia al endpoint del servicio RMI, ¿sencillo no?, en efecto pero con lo que no contaba, es que RMI necesita dos threads para procesar una peticion.. es decir por un thread atiende y en otro responde.. por lo que en el momento que me mandaron carga, mis threads de ejecucion se terminaron (tenía 15 :D) y RMI no me regresaba la respuesta hasta que no existiera un thread disponible.... asi que entre en un deadlock..
.. pues de alguna manera teniamos que resolver el problema: controlar el numero de peticiones al servicio RMI.
Revisando el libro Enterprise Integration Patterns, se encuentra un patron llamado Competing Consumers, pensando en aplicar este patron para controlar el numero de threds que envia datos al servicio RMI, nos empezo a llegar la luz.
Gustavo y su servilleta pensamos en utilizar la solucion de Aqualogic Service Bus para este caso.... buscando en la documentacion de ALSB encontramos dos cosas A) el patron throttling pattern que permite controlar el grado de concurrencia y B) el concepto WorkManager que define restricciones de carga en threads, asi que nos pusimos manos a la obra y juntando lo anterior mas unas cuantas colas JMS, el resultado quedo en lo siguiente:
... el servicio envia el mensaje a un proxy service, este lo almacena en una cola JMS y libera la conexion, posteriomente un suscriptor consume (de uno en uno) y ejecuta un business service que se encarga de enviar (uno a uno) a la interfaz del EAI para que esta envíe finalmente al servicio RMI. Para garantizar que nuestra solucion funcionaria en produccion, usamos jmeter para enviar 600 mensajes y respondio sin problemas, enviando todos los mensajes en 1 minuto al servicio final.. como veran, con esta solucion es posible controlar el numero de peticiones al servicio final mediante los WorkManagers.
Tambien pueden aplicar el patron Competing Consumers y tendrian el mismo efecto, en algun momento les comentare como este patron nos resolvio un problema al conectarnos con servicios Mainframe.
Pues esta fue la solucion aplicada..
Comentarios y sugerencias son bienvenidos.
Por una integracion mejor, hasta la vista
Tuzo
jueves, 29 de marzo de 2007
ESB or not ESB?
Hola que tal! aqui de nuevo dando lata :D
ESB or not ESB? jejeje, pues si efectivamente navegando por la red me he encontrado con algunas discusiones acerca de la definicion de un ESB y pues me motivo a escribir este post... espero os sirva...
Bien, pues el concepto de Enterprise Service Bus surge en Gartner en colaboracion con David Chapell (tipo con el cual tuvimos una platica en el 2006). Actualmente el termino ESB es muy nombrado por sistemologos, peeroooo ¿realmente conocemos que es un ESB?
En terminos practicos un ESB es una implementacion de SOA, en palabras cristianas es: conectar un cliente y un proveedor mediante un middleware... veamos a mas detalle
Para entender que es un ESB, es necesario saber primeramente que es lo que hace. La manera en que me "cayo el veinte" es entendiendo el patron de integracion VETRO pattern, culaquier software o hardware que se diga ser un ESB, al menos debe de cumplir con este patron, como Jack el destripador vayamos por partes.....
Validation: Se encarga de realizar la validacion de mensajes que entran al ESB, esta validacion es generalmente basada en estandares, por ejemplo validar el XML de entrada contra su respectivo XSD
Enrichment: Esta parte es la encargada de enriquecer el mensaje inicial del cliente con informacion necesaria para la invocacion del servicio final. En la mayoria de las ocasiones este enriquecimiento es generado en llamadas a servicios de negocio y adicionando informacion al mensaje
Transformation: Esta parte es la encargada de transformar el mensaje original a otro formato que sea necesario por el servicio final, por ejemplo utilizar Xquery para trasformaciones entre archivos XML
Routing: Esta parte es muy interesante, es la encargada de rutear el mensaje a diferentes servicios de acuerdo al contenido o a la operacion o inclusive se pueden tener tablas de ruteo
Operate: Es la parte final, la que se encarga de comunicarse con el servicio final, es decir se conecta con los servicios de negocio.
Adicional a el patron VETRO agregare unos puntos harto importantes:
+ Un ESB es distribuido, es decir no es el clasico hub and spoke, un ESB se puede distribuir en toda la red fisica.
+ Esta basado en un sistema de mensajeria o Message Oriented Middleware, lo cual permite manejar muchos escenarios de manera asincrona.
+ Permite el monitoreo de niveles de servicio de cada uno de los servicios pertenecientes al ESB
+ Permite controlar la calidad de servicio y la calidad de proteccion
Actualmente existen una cantidad considerable de ESB de "marca" y open source, aqui una lista
+ Sonic MQ
+ BEA Aqualogic Service Bus, es el que usamos aqui en el trabajo :D
+ Mule ESB, tambien existente en nuestra arquitectura :D
+ IONA Celtix ESB
+ Apache ServiceMix
Para finalizar quiero compartir con ustedes este podcast de Mark Richards Senior IT architect de IBM, titulado The Enterprise Service Bus: Do We Really Need It?, espero les guste, si no jala el link me dicen, :D
Bueno pues es todo, si me falto algo bienvenido...
Por una integracion mejor, hasta la vista
Tuzo
ESB or not ESB? jejeje, pues si efectivamente navegando por la red me he encontrado con algunas discusiones acerca de la definicion de un ESB y pues me motivo a escribir este post... espero os sirva...
Bien, pues el concepto de Enterprise Service Bus surge en Gartner en colaboracion con David Chapell (tipo con el cual tuvimos una platica en el 2006). Actualmente el termino ESB es muy nombrado por sistemologos, peeroooo ¿realmente conocemos que es un ESB?
En terminos practicos un ESB es una implementacion de SOA, en palabras cristianas es: conectar un cliente y un proveedor mediante un middleware... veamos a mas detalle
Para entender que es un ESB, es necesario saber primeramente que es lo que hace. La manera en que me "cayo el veinte" es entendiendo el patron de integracion VETRO pattern, culaquier software o hardware que se diga ser un ESB, al menos debe de cumplir con este patron, como Jack el destripador vayamos por partes.....
Validation: Se encarga de realizar la validacion de mensajes que entran al ESB, esta validacion es generalmente basada en estandares, por ejemplo validar el XML de entrada contra su respectivo XSD
Enrichment: Esta parte es la encargada de enriquecer el mensaje inicial del cliente con informacion necesaria para la invocacion del servicio final. En la mayoria de las ocasiones este enriquecimiento es generado en llamadas a servicios de negocio y adicionando informacion al mensaje
Transformation: Esta parte es la encargada de transformar el mensaje original a otro formato que sea necesario por el servicio final, por ejemplo utilizar Xquery para trasformaciones entre archivos XML
Routing: Esta parte es muy interesante, es la encargada de rutear el mensaje a diferentes servicios de acuerdo al contenido o a la operacion o inclusive se pueden tener tablas de ruteo
Operate: Es la parte final, la que se encarga de comunicarse con el servicio final, es decir se conecta con los servicios de negocio.
Adicional a el patron VETRO agregare unos puntos harto importantes:
+ Un ESB es distribuido, es decir no es el clasico hub and spoke, un ESB se puede distribuir en toda la red fisica.
+ Esta basado en un sistema de mensajeria o Message Oriented Middleware, lo cual permite manejar muchos escenarios de manera asincrona.
+ Permite el monitoreo de niveles de servicio de cada uno de los servicios pertenecientes al ESB
+ Permite controlar la calidad de servicio y la calidad de proteccion
Actualmente existen una cantidad considerable de ESB de "marca" y open source, aqui una lista
+ Sonic MQ
+ BEA Aqualogic Service Bus, es el que usamos aqui en el trabajo :D
+ Mule ESB, tambien existente en nuestra arquitectura :D
+ IONA Celtix ESB
+ Apache ServiceMix
Para finalizar quiero compartir con ustedes este podcast de Mark Richards Senior IT architect de IBM, titulado The Enterprise Service Bus: Do We Really Need It?, espero les guste, si no jala el link me dicen, :D
Bueno pues es todo, si me falto algo bienvenido...
Por una integracion mejor, hasta la vista
Tuzo
Suscribirse a:
Entradas (Atom)