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 :)
lunes, 21 de mayo de 2007
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
Suscribirse a:
Entradas (Atom)