Gente,
En esta ocacion les dejo un dato de una expo que pinta interesante.
Es la Ekoparty. La entrada es paga, pero si les interesa y pueden hacer que alguna empresa se los banque, no hay problema.
Tienen trainings muy buenos, asi que chusmeenlos un poco.
Saludos.
jueves, 4 de septiembre de 2008
domingo, 3 de agosto de 2008
Patrones SOA y de Workflow
Santiago Blanco (ver su blog que es muy bueno) me paso el siguiente link de worklow patterns... MUY BUENO!!! Indican los patrones tipicos de control de flujo, manejo de datos, de recursos y de excepciones.
Encima, marcan que productos soportan cada patron!!!!
Link a la pagina
Patrones de SOA y buenas practicas... de quien otro si no es Thomas Erl: http://www.soapatterns.org/
Que lo disfruten!!
Saludos
Encima, marcan que productos soportan cada patron!!!!
Link a la pagina
Patrones de SOA y buenas practicas... de quien otro si no es Thomas Erl: http://www.soapatterns.org/
Que lo disfruten!!
Saludos
POEM, una alternativa al BPMN
POEM es una metodologia abierta para el modelado de procesos en la empresa. Se puede ver en el siguiente link
y.....Un poster de POEM es todo arquitecto de empresa deberia tener en una pared, aunque no lo use!!!! :D
Porque? porque queda bien :P
NAH! realmente es util y resume la metodologia POEM para modelar los procesos de la empresa. link al poster
Saludos.
y.....Un poster de POEM es todo arquitecto de empresa deberia tener en una pared, aunque no lo use!!!! :D
Porque? porque queda bien :P
NAH! realmente es util y resume la metodologia POEM para modelar los procesos de la empresa. link al poster
Saludos.
SOA: Arquitectura de referencia
Existen varias metodologias para llegar a una arquitectura SOA.
Este link, que se lo debo a Pablo Albornoz (gracias Pablo!!!) nos sirve de checklist, y nos indica tooooodo lo que nos puede faltar para tener una arquitectura SOA completita y bien definida. Link
Cuando querramos ver que pasos seguir y que nos falta hacer, podemos seguir esta referencia.
Saludos!
Este link, que se lo debo a Pablo Albornoz (gracias Pablo!!!) nos sirve de checklist, y nos indica tooooodo lo que nos puede faltar para tener una arquitectura SOA completita y bien definida. Link
Cuando querramos ver que pasos seguir y que nos falta hacer, podemos seguir esta referencia.
Saludos!
¿Estandares? WS-*
Si hay algo que se respeta menos que un semaforo en rojo, en la provincia de buenos aires de noche, son los estandares de Servicios WS-*
Thomas Erl (un Groso) los explica un poquito en su pagina soa specifications
y Tambien en http://www.ws-standards.com/
El hecho es que cada proveedor hace con sus productos lo que quiere.
No todos los frameworks
no todos los productos
no todos los proveedores
orientados al desarrollo y soporte de WS soportan los estandares de WS.
Microsoft desarrollo sus estandares de Transacciones, seguridad y adressing como mas le parecio. Extendio el estandard y hace pleno uso de el, haciendo casi imposible confiar en una integracion completa con otros productos (incluso de BEA y de IBM con los que comparte mas estandares definidos en OASIS).
WS-Addressing.... esta ampliamente difundido, pero no por todos los frameworks, asi que antes que esperar que un framework o un producto resuelva el pooling de espera de una respuesta de servicio por el id del mensaje, hay que hacerle un par de pruebas de integracion con otros productos similares y puede ser preferible generar un servicio con callback a la vieja usanza o asumir el costo de poolear a la espera de respuesta.
WS-Security.... la forma "estandar" de microsoft es "estandar" consigo misma. Aun asi, es uno ampliamente soportado.
WS-ReliableMessaging... nada en contra, nada a favor. Todavia no tuve la oportunidad de usarlo , ni que me resulte util.
WS-Transaction... JAJAJAJAJAJAJAJAJAJA el sueño del pibe. Todavia sigo sacando canas verdes con la compensacion de servicios, con transacciones distribuidas y demas. Esto aun esta verde. Igual, la idea es buena, pero.... en las AT, aun tienen faces de 2PC que en algunos casos pueden resultar en lockings de recursos. Estos son unos buenos links para ver. WS-T Parte 1, Parte 2 y Parte 3
Bueno, esto es un poco con lo que me fui encontrando. Los WS-* no son la solucion a nuestros problemas de arquitectura y diseño aun, porque no se pueden (aun) realizar una integracion confiable.
En una arquitectura empresarial, se debe ir a lo ultimo seguro y estable, sin dejar de lado las nuevas tendencias que quedaran para analizar.
Saludos.
Thomas Erl (un Groso) los explica un poquito en su pagina soa specifications
y Tambien en http://www.ws-standards.com/
El hecho es que cada proveedor hace con sus productos lo que quiere.
No todos los frameworks
no todos los productos
no todos los proveedores
orientados al desarrollo y soporte de WS soportan los estandares de WS.
Microsoft desarrollo sus estandares de Transacciones, seguridad y adressing como mas le parecio. Extendio el estandard y hace pleno uso de el, haciendo casi imposible confiar en una integracion completa con otros productos (incluso de BEA y de IBM con los que comparte mas estandares definidos en OASIS).
WS-Addressing.... esta ampliamente difundido, pero no por todos los frameworks, asi que antes que esperar que un framework o un producto resuelva el pooling de espera de una respuesta de servicio por el id del mensaje, hay que hacerle un par de pruebas de integracion con otros productos similares y puede ser preferible generar un servicio con callback a la vieja usanza o asumir el costo de poolear a la espera de respuesta.
WS-Security.... la forma "estandar" de microsoft es "estandar" consigo misma. Aun asi, es uno ampliamente soportado.
WS-ReliableMessaging... nada en contra, nada a favor. Todavia no tuve la oportunidad de usarlo , ni que me resulte util.
WS-Transaction... JAJAJAJAJAJAJAJAJAJA el sueño del pibe. Todavia sigo sacando canas verdes con la compensacion de servicios, con transacciones distribuidas y demas. Esto aun esta verde. Igual, la idea es buena, pero.... en las AT, aun tienen faces de 2PC que en algunos casos pueden resultar en lockings de recursos. Estos son unos buenos links para ver. WS-T Parte 1, Parte 2 y Parte 3
Bueno, esto es un poco con lo que me fui encontrando. Los WS-* no son la solucion a nuestros problemas de arquitectura y diseño aun, porque no se pueden (aun) realizar una integracion confiable.
En una arquitectura empresarial, se debe ir a lo ultimo seguro y estable, sin dejar de lado las nuevas tendencias que quedaran para analizar.
Saludos.
jueves, 31 de julio de 2008
Analisis en SOA
Hace tiempo que vengo estudiando como es el mejor camino para implementar un analisis SOA.
Aca escribo un poco de lo que estuve viendo.
En fin, parece que para el analisis y la entrega de servicios en una metodologia SOA existen dos caminos posibles. TOP-DOWN y BOTTOM-UP. Pueden verlos aqui
Cuando lo lei, asocie la forma de delivery BOTTOM-UP a la forma de analisis orientada a la necesidad actual cuando los requerimientos provienen de sistemas legacy y los procesos de negocio no estan definidos; y la TOP-DOWN, cuando se parte del analisis basado en entidades de negocio, procesos de negocio y demas descomposiciones, que se pueden ver aqui
Igual, se debe tener en claro que todo el proceso tendera tarde o temprano a ser un TOP-DOWN, de lo contrario no se llegara a una Arquitectura SOA ideal, donde IT este alineado al negocio.
Otra cosa que dice MSOAM es que el analista funcional debe trabajar en conjunto con el tecnico (aqui).
Con los analistas tecnicos deben trabajar si o si, ya que estos son los que conocen las restricciones tecnologicas, los patrones de diseño y podran modelar los servicios de manera acorde a los estandares empresariales. Un analista funcional no podra modelar las entradas, salidas y capacidades de un servicio por si mismo; especialmente hoy en dia, que la vision orientada a servicios es escaza.
Cuando se habla de analistas funcionales son analistas cross al negocio. Eso quiere decir que el analista no debe conocer UNA aplicacion o UN proceso de negocio, sino meterse en todos los procesos y conocer un poco de tooooodo IT en la empresa.
Es por eso que el analista SOA debe trabajar (o consultar antes de definir, al menos) con la gente que modela y documenta los procesos de negocio.
El ciclo de vida de servicios debe estar bien definido y se deben formalizar los pasos para la creacion, eliminacion o modificacion de un servicio, como tambien los pedidos para su consumicion. Sin esto, no se podran generar politicas adecuadas para el repositorio...
Para un correcto analisis, se debe poseer un repositorio de entidades de negocio y de servicios Y con un proceso de GOVERNANCE bien definido es fundamental.
La existencia del repositorio y la definicion de la metadata de cada servicio sera lo que permita modelarlos y centralizar la informacion de servicios en toda la empresa.
No se habla unicamente de UDDI, ya que este estandar es limitado. Se habla de un repositorio a nivel de analisis y diseño, que permita automatizar el proceso de modelado y descubrimiento de servicios, como tambien asi su aprobacion por parte de la SOA BOARD (que sera el sector/comision/grupo de sectore que tendran el governance de los servicios en la empresa y definiran los estandares).
El proceso de Governance debe estar bien definido, y los estandares y modelado de negocio tambien. Aqui hay un articulo sobre la importancia del governance
La metodologia de analisis debe ser iterativa!!!! no se debe querer relevar tooooooda la informacion de tooooooodos los procesos para comenzar a definir servicios que sean reutilizables.
Los servicios son altamente modificables y apuntan a la reutilizacion, por lo que se debe analizar por partes a los procesos de negocio/procesos de la empresa para poder entregar los primeros servicios. Luego, estos se iran modificando con la aparicion de nuevos requerimientos, para eso se definio un repositorio y un ciclo de vida de servicios.
Con los links y la metodologia en si, hay bastante para profundizar. SOA Es una metodologia que sigue cambiando y que cada consultor hace, hoy en dia, como mas le parece.
Es importante tener una metodologia de analisis que se ajuste a las necesidades de la empresa, dependiendo su grado de madurez (me gusta la piramide de ese link, es muy clara). El grado 3 de madurez, es el mas dificil de lograr, el resto sale con fritas.
Saludos.
Aca escribo un poco de lo que estuve viendo.
- La metodologia de IBM SOMA
- La de Thomas Erl (la mejorcita) MSOAM y otro link de lo mismo
- Las de ciclo de vida de los servicios de BEA (que no me dejo mucho) y
- Las recomendadas por las SOA practitioners guide
En fin, parece que para el analisis y la entrega de servicios en una metodologia SOA existen dos caminos posibles. TOP-DOWN y BOTTOM-UP. Pueden verlos aqui
Cuando lo lei, asocie la forma de delivery BOTTOM-UP a la forma de analisis orientada a la necesidad actual cuando los requerimientos provienen de sistemas legacy y los procesos de negocio no estan definidos; y la TOP-DOWN, cuando se parte del analisis basado en entidades de negocio, procesos de negocio y demas descomposiciones, que se pueden ver aqui
Igual, se debe tener en claro que todo el proceso tendera tarde o temprano a ser un TOP-DOWN, de lo contrario no se llegara a una Arquitectura SOA ideal, donde IT este alineado al negocio.
Otra cosa que dice MSOAM es que el analista funcional debe trabajar en conjunto con el tecnico (aqui).
Con los analistas tecnicos deben trabajar si o si, ya que estos son los que conocen las restricciones tecnologicas, los patrones de diseño y podran modelar los servicios de manera acorde a los estandares empresariales. Un analista funcional no podra modelar las entradas, salidas y capacidades de un servicio por si mismo; especialmente hoy en dia, que la vision orientada a servicios es escaza.
Cuando se habla de analistas funcionales son analistas cross al negocio. Eso quiere decir que el analista no debe conocer UNA aplicacion o UN proceso de negocio, sino meterse en todos los procesos y conocer un poco de tooooodo IT en la empresa.
Es por eso que el analista SOA debe trabajar (o consultar antes de definir, al menos) con la gente que modela y documenta los procesos de negocio.
El ciclo de vida de servicios debe estar bien definido y se deben formalizar los pasos para la creacion, eliminacion o modificacion de un servicio, como tambien los pedidos para su consumicion. Sin esto, no se podran generar politicas adecuadas para el repositorio...
Para un correcto analisis, se debe poseer un repositorio de entidades de negocio y de servicios Y con un proceso de GOVERNANCE bien definido es fundamental.
La existencia del repositorio y la definicion de la metadata de cada servicio sera lo que permita modelarlos y centralizar la informacion de servicios en toda la empresa.
No se habla unicamente de UDDI, ya que este estandar es limitado. Se habla de un repositorio a nivel de analisis y diseño, que permita automatizar el proceso de modelado y descubrimiento de servicios, como tambien asi su aprobacion por parte de la SOA BOARD (que sera el sector/comision/grupo de sectore que tendran el governance de los servicios en la empresa y definiran los estandares).
El proceso de Governance debe estar bien definido, y los estandares y modelado de negocio tambien. Aqui hay un articulo sobre la importancia del governance
La metodologia de analisis debe ser iterativa!!!! no se debe querer relevar tooooooda la informacion de tooooooodos los procesos para comenzar a definir servicios que sean reutilizables.
Los servicios son altamente modificables y apuntan a la reutilizacion, por lo que se debe analizar por partes a los procesos de negocio/procesos de la empresa para poder entregar los primeros servicios. Luego, estos se iran modificando con la aparicion de nuevos requerimientos, para eso se definio un repositorio y un ciclo de vida de servicios.
Con los links y la metodologia en si, hay bastante para profundizar. SOA Es una metodologia que sigue cambiando y que cada consultor hace, hoy en dia, como mas le parece.
Es importante tener una metodologia de analisis que se ajuste a las necesidades de la empresa, dependiendo su grado de madurez (me gusta la piramide de ese link, es muy clara). El grado 3 de madurez, es el mas dificil de lograr, el resto sale con fritas.
Saludos.
Oracle BEA, como sera la fusion
En este link que pongo a continuacion esta el roadmap que va a tomar la gente de Oracle.
http://www.espaciosoa.net/2008/07/02/conversion-de-productos-de-bea-y-oracle/
Por suerte, van a quedarse con JRockit como VM de los aplicattion server fusionados, lejos, lo mejor de BEA
Van a seguir teniendo la BAM de oracle, por lo que solo se podra implementar sobre un server con windows instalado. Uno de sus tantos requisitos es ese.
Saludos.
http://www.espaciosoa.net/2008/07/02/conversion-de-productos-de-bea-y-oracle/
Por suerte, van a quedarse con JRockit como VM de los aplicattion server fusionados, lejos, lo mejor de BEA
Van a seguir teniendo la BAM de oracle, por lo que solo se podra implementar sobre un server con windows instalado. Uno de sus tantos requisitos es ese.
Saludos.
lunes, 7 de julio de 2008
REST
Para los que no conocen REST, es una forma de intercambio de informacion al estilo web service, basada en comandos comunes de HTTP como son el GET y el POST.
Este es el caballito de batalla de todos los que opinan que SOAP es un estandar pesado y agrandado en vano (comparto que se han realizado estandares que nadie respeta y que SOAP es mucho mas flexible de lo que deberia ser).
De forma Simple, REST combate los largos pedidos XML para hacer pedidos via URL y Query String, retornando solo lo necesario, sin ningun adorno adicional.
Actualmente existen frameworks de Web Services que soportan implementaciones SOAP o REST de forma trasparente (Apache CSF por ejemplo) e incluso existen ESB's REST :D.
Al fin y al cabo, son Web Services, lo unico que cambia es como lo transportan.
Les adjunto un par de links para que sigan el tema.
Que lo disfruten!
Saludos.
Este es el caballito de batalla de todos los que opinan que SOAP es un estandar pesado y agrandado en vano (comparto que se han realizado estandares que nadie respeta y que SOAP es mucho mas flexible de lo que deberia ser).
De forma Simple, REST combate los largos pedidos XML para hacer pedidos via URL y Query String, retornando solo lo necesario, sin ningun adorno adicional.
Actualmente existen frameworks de Web Services que soportan implementaciones SOAP o REST de forma trasparente (Apache CSF por ejemplo) e incluso existen ESB's REST :D.
Al fin y al cabo, son Web Services, lo unico que cambia es como lo transportan.
Les adjunto un par de links para que sigan el tema.
- Introduccion a REST: http://www.infoq.com/articles/rest-introduction
- Y un articulo muy gracioso que dice "Como le explique REST a mi esposa" :D : http://tomayko.com/writings/rest-to-my-wife
Que lo disfruten!
Saludos.
Ataques comunes a aplicaciones con Web Services
Existen ciertas vulnerabilidades que pueden ser explotadas en las aplicaciones que consumen o exponen a web services.
Muchas, estan resumidas en el siguiente documento que efectua un top ten de los ataques mas comunes. Es un pdf.
Aca tienen un documento de OWASP sobre como proteger aplicaciones que consumen/exponen WEB Services. Es una presentacion de powerpoint.
Para mencionar algunos:
Estos problemas son propios del trabajo con XML, por lo que deben tenerse en cuenta y se debe hacer un analisis de la exposicion al riesgo que estamos dispuestos a afrontar, buscando una solucion que los mitigue (dentro de los costos planeados).
Que lo disfruten!
Saludos.
Muchas, estan resumidas en el siguiente documento que efectua un top ten de los ataques mas comunes. Es un pdf.
Aca tienen un documento de OWASP sobre como proteger aplicaciones que consumen/exponen WEB Services. Es una presentacion de powerpoint.
Para mencionar algunos:
- XPATH Injection. Un ataque bastante simple y si una aplicacion usa el XPATH de esta manera (por ejemplo, con el uso de condiciones de XSLT para mostrar contenido sensible) merece ser castigada con este ataque. El link que les adjunto tiene un ejemplo que puede explicarlo mejor que yo.
- XML Bomb. Este es complicado. Hace que el XSD o DTD asociado sea recursivo y tolere una cantidad remota muy grande de elementos. Esto hace que el parser de XML (si tiene activa la validacion del XML al parsear) se cuelgue y provoque, en el peor de los casos una caida por consumo de memoria o un Denial of Service (DoS). Si se llega a incluir un DTD o XSD de contenido exponencial en un mensaje, la unica forma de corregirlo es deshabilitando la validacion de XSD's o DTD's, trayendo otros inconvenientes y teniendo que validar los inputs la aplicacion.
- XXE (External Entity Atacks). Es cuando realizan un ataque con un cambio de alias, ruteando los xsd's/dtd's que importamos en nuestros XML's hacia otro lugar, que hace que el contenido del atacante sea valido. Esto quiere decir que podremos colocar numeros donde no se permitia, strings que estaban prohibidas, etc...
- Large Payloads. Como el nombre lo dice, un XML gigantesco que trata de provocar un DoS.
Estos problemas son propios del trabajo con XML, por lo que deben tenerse en cuenta y se debe hacer un analisis de la exposicion al riesgo que estamos dispuestos a afrontar, buscando una solucion que los mitigue (dentro de los costos planeados).
Que lo disfruten!
Saludos.
Issue de Spring Batch
Spring Batch es una aplicacion para realizar procesos batch's de manera "simple", o por lo menos asi deberia ser.
El framework no es malo, aunque es escazo en documentacion, ejemplos y tiene una API muy extensa en cuanto a jerarquias de objetos. Aun asi, parece que la consultora que lo creo (Accenture) posee mas ejemplos que los que estan publicados, posiblemente de trabajos internos en la creacion del framework o de trabajos para clientes.
El unico tema a tener en cuenta es con los mapeos en memoria, no son thread safe, por lo que en un ambiente de produccion, con un batch multithreading, se debe configurar la persistencia del framework (mantiene los estados de los procesos y otras configuraciones) contra una BD y no contra memoria. link al respecto
"The Map*Daos were never designed to be thread safe. To be honest, we only ever thought they would be used for testing. They can be made thread safe if you open an issue in JIRA. (N.B. this is not related to the original topic of this thread.)".
Todavia no son thread safe.
El framework no es malo, aunque es escazo en documentacion, ejemplos y tiene una API muy extensa en cuanto a jerarquias de objetos. Aun asi, parece que la consultora que lo creo (Accenture) posee mas ejemplos que los que estan publicados, posiblemente de trabajos internos en la creacion del framework o de trabajos para clientes.
El unico tema a tener en cuenta es con los mapeos en memoria, no son thread safe, por lo que en un ambiente de produccion, con un batch multithreading, se debe configurar la persistencia del framework (mantiene los estados de los procesos y otras configuraciones) contra una BD y no contra memoria. link al respecto
"The Map*Daos were never designed to be thread safe. To be honest, we only ever thought they would be used for testing. They can be made thread safe if you open an issue in JIRA. (N.B. this is not related to the original topic of this thread.)".
Todavia no son thread safe.
OWASP
OWASP (The Open Web Application Security Project) es una asociación sin ánimo de lucro que proporciona recursos, documentación, software, etc, para promover la seguridad entre los desarrolladores de aplicaciones web.
Contiene las guias para la segurizacion de las aplicaciones y cada tanto recopila las vulnerabilidades mas afectadas y efectua un Top Ten, hicieron uno en el 2007 y otro en el 2004.
La pagina es http://www.owasp.org
Es un recurso muy util para cualquier sector de seguridad informatica y para los desarrolladores.
Saludos.
Contiene las guias para la segurizacion de las aplicaciones y cada tanto recopila las vulnerabilidades mas afectadas y efectua un Top Ten, hicieron uno en el 2007 y otro en el 2004.
La pagina es http://www.owasp.org
Es un recurso muy util para cualquier sector de seguridad informatica y para los desarrolladores.
- Para los primeros, les da un framework de referencia y una lista de vulnerabilidades y formas de corregirlas.
- Para los segundos los capacita en el desarrollo de aplicaciones mas seguras, ya que la seguridad es un proceso que debe estar presente desde el analisis de un software y debe estar pensado en su desarrollo. Planearlo para mas adelante aumenta los costos en el proceso de construccion.
- Contiene un catalogo de ataques comunes.
- Vulnerabilidades
- y para los Javeros. Segurizacion de aplicaciones web hechas en Java. link
Saludos.
domingo, 8 de junio de 2008
Frameworks para RIA
RIA: En palabras simples, queremos que el cliente vea la aplicacion web como una aplicacion comoda y de escritorio, pero sin usar applets o cosas como eran el "WebOnSwing" en su momento.
Voy a describir los 3 frameworks mas importantes que escuche/vi/use/lei para la creacion de aplicaciones RIA (Rich Internet Application):
Flex: "El framework" para trabajar con Flash, porque.... es de adobe :P.
http://flex.org/
Si alguna vez quisieron incluir una funcionalidad en flash para que se comunique con la capa de negocio, utilicen Flex. Es simple, es rapido, permite mapear via JSon obejtos en la capa de presentacion y en la logica. Soporta feeds constantes, conexiones en segundo plano, mapeo de objetos y todo lo que tienen estos frameworks.
Hay otros frameworks (como OpenLaslo) que poseen una funcionalidad similar y ofrecen tambien el manejo por javascript, peor no le llegan ni a los talones a las capacidades que Flex ofrece.
Se puede bajar el entorno de desarrollo de la pagina, que es un eclipse preparado completamente para trabajar con Flex.
Desventajas:
Ventajas:
GWT: OHHHH poderoso Google! :P
http://code.google.com/webtoolkit/
Si hay algo que me gusta de este framework es el soporte que google hace por detras. Una vez tuvimos un inconveniente, realizamos un post y se abrio el bug al toque. En el siguiente release ya estaba incluida la mejora :D
Otra biblioteca de este estilo (pero con ideas mas tradicionales) son IceFaces y algunos componentes de JSF.
Ventajas:
Desventajas:
Yahoo UI: Yahoo, no estas muerto!!!... todavia ¬¬
http://developer.yahoo.com/yui/
Esta es la que menos conozco.
Yahoo UI es una biblioteca Javascript completisima para el desarrollo de aplicaciones RIA. Otra similar pero que no le llega ni a los talones es Dojo.
Ventaja:
Desventaja:
Que lo disfruten!
Saludos.
Voy a describir los 3 frameworks mas importantes que escuche/vi/use/lei para la creacion de aplicaciones RIA (Rich Internet Application):
Flex: "El framework" para trabajar con Flash, porque.... es de adobe :P.
http://flex.org/
Si alguna vez quisieron incluir una funcionalidad en flash para que se comunique con la capa de negocio, utilicen Flex. Es simple, es rapido, permite mapear via JSon obejtos en la capa de presentacion y en la logica. Soporta feeds constantes, conexiones en segundo plano, mapeo de objetos y todo lo que tienen estos frameworks.
Hay otros frameworks (como OpenLaslo) que poseen una funcionalidad similar y ofrecen tambien el manejo por javascript, peor no le llegan ni a los talones a las capacidades que Flex ofrece.
Se puede bajar el entorno de desarrollo de la pagina, que es un eclipse preparado completamente para trabajar con Flex.
Desventajas:
- El truco? Necesitas tener si o si el plugin flash instalado en tu navegador para ver una aplicacion hecha en... Flash :P duhhhh! El 80% de los usuarios de internet lo poseen, por lo que no veo cual es la limitacion en hacer una aplicacion con esto.
- No es completamente abierto, hay algunas restricciones en los protocolos de comunicacion. Si bien uno puede optar por utilizar JSON o XML, hay otro propietario de Flex (creo que binario) que es mucho mas rapido.
- Hay que codificar una pequeña cantidad de objetos del lado de la presentacion para que puedan ser maniupulados en el flash (en script de flash) que se mapean contra nuestro modelo.
Ventajas:
- Es mas rapido que una aplicacion Ajax en el sentido que una vez descargado el componente Flash, ya no vuelve a solicitarse, por lo que la navegacion es mucho mas dinamica.
- El poder de Flash!
GWT: OHHHH poderoso Google! :P
http://code.google.com/webtoolkit/
Si hay algo que me gusta de este framework es el soporte que google hace por detras. Una vez tuvimos un inconveniente, realizamos un post y se abrio el bug al toque. En el siguiente release ya estaba incluida la mejora :D
Otra biblioteca de este estilo (pero con ideas mas tradicionales) son IceFaces y algunos componentes de JSF.
Ventajas:
- GWT permite realizar una aplicacion Ajax Style, pudiendo debuggearla en tiempo de desarrollo con editores Java (como el Eclipse), lo que ayuda a descubrir inconvenientes, que de otra manera deberiamos ver en Javascript (cosa muy dificil).
- Una vez que se deploya, se convierte todo (excepto los servicios de nuestro lado que brindan informacion) en un HTML tunneado para ser mas pequeño y veloz, por lo que es mas liviano que el resto de los frameworks (hay forma de hacer que genere un HTML "Human readable", pero llegado a ese punto estamos en problemas, no es la idea).
- Viste google? gmail? bueno, todo eso lo podes hacer con este framework.
- El soporte es google.
Desventajas:
- En tiempo de desarrollo se utiliza un tomcat y una consola asociada al framework.
- El Codigo generado es inentendible.
- Es dificil hacer el deploy junto con una aplicacion ya existente, por tener un ambiente de desarrollo y empaquetado particular, pero con un par de vueltas sale andando.
Yahoo UI: Yahoo, no estas muerto!!!... todavia ¬¬
http://developer.yahoo.com/yui/
Esta es la que menos conozco.
Yahoo UI es una biblioteca Javascript completisima para el desarrollo de aplicaciones RIA. Otra similar pero que no le llega ni a los talones es Dojo.
Ventaja:
- Es Javascript, lo que tenga del lado del server, no importa.
- Es liviana y simple. Ataca a problemas puntuales de presentacion.
Desventaja:
- No es un framework cross side, asi que hay que tener bien diferenciadas las capas y esto implica mas desarrollo del lado del servidor.
Que lo disfruten!
Saludos.
Frameworks para WebServices
Buenas,
Voy a hacer un listado de los frameworks para el desarrollo de web services que conozco o he visto:
Spring WS:
http://static.springframework.org/spring-ws/site/
Cuando vi los ejemplos, me parecio limitado con respecto a otros frameworks. Calculo que con el desarrollo del Spring Application Platform esta API ira creciendo.
Soporta WS-Security y se puede integrar con Acegi.
Apache CXF:
http://cxf.apache.org/
Un frameworks cuyo poder reside en trabajar con annotations, es decir, rapido de programar y sacar andando. Es el resultado de la fusion de CXF con XFire.
Soporta WS-Security y WS-Addresing. Con este framework se puede trabajar sobre Apache Tuscany (SCA) y con Containers que soporten JBI (como OpenESB).
Lo interesante, es que tambien soporta REST y JSON!!!!!! :D... Creo que ningun otro tiene este nivel de soporte!
Axis 1.4:
http://ws.apache.org/axis/
El viejo y querido Axis 1.4 que nos salva las papas del fuego cuando tenemos problemas de integracion con servicios legacy :P... porque? porque es tan viejo como los legacy y la mayoria de los viejos web services estan hechos con esto, con el RPCServlet de Apache o con alguna implementacion propietaria :P.
Que se puede decir de Axis 1.4 excepto que se va a ver en muchos lados, funciona, tiene bibliotecas para C++ y no solo Java y que ya no tiene mas desarrollo!!!!!!!!!!!! O sea, no lo usen para nuevos desarrollos, porque se quedo en la 1.4.
Axis 2:
http://ws.apache.org/axis2/
PUAJJJJJ
y tambien se puede decir PUAJJJJJJJJ.
En el esfuerzo por hacer simple el armado de web services, crearon un propio contenedor y una integracion con spring que levanta un classloader propio dentro del classloader del contenedor que ya tenemos.
Se fueron de lo estandar para generar su propio estilo de paquete.
Si bien soportan varios tipos de bindings, frameworks y algunos estandares como WS-Adressing y WS-Policy. Ademas de poder escribir en SOAP 1.2, la branch del Axis 1.4 (porque fue un desarrollo paralelo) quedo demasiado propietaria en un mundo de estandares e integraciones.
EJB3:
http://www.theregister.co.uk/2007/01/23/ejb_web_services/
Este es un ejemplo de como hacerlo con JBOSS.
De este me entere hace muy poco. EJB3 permite la exposicion de los POJO's como webservice a través de annotations. Luego el contenedor es el encargado de tomar ese POJO y publicarlo. Es muy parecido a como lo hace .NET.
No vi ejemplos en otras plataformas que no sea JBOSS... porque JBOSS es el unico que soporta el estandar completo al momento de la creación de esta entry.
Los demas:
Hay otros frameworks propietarios, como son los de Oracle, Bea y demas, pero de esos no voy a hablar... para eso estan los proveedores, las demos y las exposiciones que tratan de venderlos. Creo que si no se utiliza un framework abierto, se ata el desarrollo a la tecnologia y a un proveedor... y no hay nada peor que comprar bibliotecas para el desarrollo :P
Que lo disfruten!
Saludos.
Voy a hacer un listado de los frameworks para el desarrollo de web services que conozco o he visto:
Spring WS:
http://static.springframework.org/spring-ws/site/
Cuando vi los ejemplos, me parecio limitado con respecto a otros frameworks. Calculo que con el desarrollo del Spring Application Platform esta API ira creciendo.
Soporta WS-Security y se puede integrar con Acegi.
Apache CXF:
http://cxf.apache.org/
Un frameworks cuyo poder reside en trabajar con annotations, es decir, rapido de programar y sacar andando. Es el resultado de la fusion de CXF con XFire.
Soporta WS-Security y WS-Addresing. Con este framework se puede trabajar sobre Apache Tuscany (SCA) y con Containers que soporten JBI (como OpenESB).
Lo interesante, es que tambien soporta REST y JSON!!!!!! :D... Creo que ningun otro tiene este nivel de soporte!
Axis 1.4:
http://ws.apache.org/axis/
El viejo y querido Axis 1.4 que nos salva las papas del fuego cuando tenemos problemas de integracion con servicios legacy :P... porque? porque es tan viejo como los legacy y la mayoria de los viejos web services estan hechos con esto, con el RPCServlet de Apache o con alguna implementacion propietaria :P.
Que se puede decir de Axis 1.4 excepto que se va a ver en muchos lados, funciona, tiene bibliotecas para C++ y no solo Java y que ya no tiene mas desarrollo!!!!!!!!!!!! O sea, no lo usen para nuevos desarrollos, porque se quedo en la 1.4.
Axis 2:
http://ws.apache.org/axis2/
PUAJJJJJ
y tambien se puede decir PUAJJJJJJJJ.
En el esfuerzo por hacer simple el armado de web services, crearon un propio contenedor y una integracion con spring que levanta un classloader propio dentro del classloader del contenedor que ya tenemos.
Se fueron de lo estandar para generar su propio estilo de paquete.
Si bien soportan varios tipos de bindings, frameworks y algunos estandares como WS-Adressing y WS-Policy. Ademas de poder escribir en SOAP 1.2, la branch del Axis 1.4 (porque fue un desarrollo paralelo) quedo demasiado propietaria en un mundo de estandares e integraciones.
EJB3:
http://www.theregister.co.uk/2007/01/23/ejb_web_services/
Este es un ejemplo de como hacerlo con JBOSS.
De este me entere hace muy poco. EJB3 permite la exposicion de los POJO's como webservice a través de annotations. Luego el contenedor es el encargado de tomar ese POJO y publicarlo. Es muy parecido a como lo hace .NET.
No vi ejemplos en otras plataformas que no sea JBOSS... porque JBOSS es el unico que soporta el estandar completo al momento de la creación de esta entry.
Los demas:
Hay otros frameworks propietarios, como son los de Oracle, Bea y demas, pero de esos no voy a hablar... para eso estan los proveedores, las demos y las exposiciones que tratan de venderlos. Creo que si no se utiliza un framework abierto, se ata el desarrollo a la tecnologia y a un proveedor... y no hay nada peor que comprar bibliotecas para el desarrollo :P
Que lo disfruten!
Saludos.
Google shell y cosas futuras
OHHHH poderoso google!!!! que nos traes hoy de innovador? :P
Bueno, esto.... no salio de google.
Es el Google Shell no oficial :D, es decir, como utilizar google como si fuera un shell de unix :P... si, muy geek, ya se.... pero esta bueno y merece una ojeada:
http://www.goosh.org/
Comentario aparte: actualmente estoy investigando (Gracias Pablo A. por la data) OSGI, SCA (Implementaciones: Apache Tuscany y Spring Application Platform), SDO para desarrollo de Arquitecturas de Integracion basadas en servicios y metodologias como Togaf (SOA) y NGOSS de TMForum (SID, CBE, eTom y demas para modelar el negocio). Me va a llevar un tiempo, asi que cuando lo tenga mas definido hago 3 post de los buenos.
Saludos
Bueno, esto.... no salio de google.
Es el Google Shell no oficial :D, es decir, como utilizar google como si fuera un shell de unix :P... si, muy geek, ya se.... pero esta bueno y merece una ojeada:
http://www.goosh.org/
Comentario aparte: actualmente estoy investigando (Gracias Pablo A. por la data) OSGI, SCA (Implementaciones: Apache Tuscany y Spring Application Platform), SDO para desarrollo de Arquitecturas de Integracion basadas en servicios y metodologias como Togaf (SOA) y NGOSS de TMForum (SID, CBE, eTom y demas para modelar el negocio). Me va a llevar un tiempo, asi que cuando lo tenga mas definido hago 3 post de los buenos.
Saludos
EAI
Les paso un link interesante sobre EAI (Enterprise Integration Patterns).
http://www.enterpriseintegrationpatterns.com
Es un "sneak peak" del libro "Enterprise Integration Patterns" que hace bastante que salio.
El libro esta un poco viejo ya, pero es la base de los patrones de Integracion.
Tienen muy buenos consejos sobre el manejo de colas, esa parte aun sigue siendo util. La parte de web services es la que esta un poco anticuada.
Leer este libro o por lo menos ver el link que les paso servira para descubrir modos de resolver problemas comunes que quizas no hubieran imaginado nunca, ponerle un nombre y asentar la idea de un tipo de solucion generica y repetitiva a problemas de cierta indole y a tener un lenguaje estandar para comunicarse con otros arquitectos de EAI (y evitar estar con la boca abierta cuando nos nombren algun pattern que nos es desconocido).
Que lo disfruten!
Saludos.
http://www.enterpriseintegratio
Es un "sneak peak" del libro "Enterprise Integration Patterns" que hace bastante que salio.
El libro esta un poco viejo ya, pero es la base de los patrones de Integracion.
Tienen muy buenos consejos sobre el manejo de colas, esa parte aun sigue siendo util. La parte de web services es la que esta un poco anticuada.
Leer este libro o por lo menos ver el link que les paso servira para descubrir modos de resolver problemas comunes que quizas no hubieran imaginado nunca, ponerle un nombre y asentar la idea de un tipo de solucion generica y repetitiva a problemas de cierta indole y a tener un lenguaje estandar para comunicarse con otros arquitectos de EAI (y evitar estar con la boca abierta cuando nos nombren algun pattern que nos es desconocido).
Que lo disfruten!
Saludos.
jueves, 29 de mayo de 2008
Continuous Integration
Si lo dice Fowler.... hay que creerle
Les dejo el link al articulo de fowler
Si no le creen a Fowler, aca tienen la wikipedia....que dice lo que dice fowler
Existen varios CI servers que pueden integrarse al desarrollo de aplicaciones Java.
y les dejo un link sumamente interesante:
Matriz completisima y comparativa de diferentes productos de CI
Babeense :D
Saludos.
"Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage."
Martin Fowler
Les dejo el link al articulo de fowler
Si no le creen a Fowler, aca tienen la wikipedia....que dice lo que dice fowler
Existen varios CI servers que pueden integrarse al desarrollo de aplicaciones Java.
- Continuum de Apache (eh.... ta bueno sep sep. Bastante facil de instalar. Open Source)
- Cruise Control (Lo conozco como el mas antiguo y completo. Tiene una version para .NET. Open Source)
- Dimensions Build de Serena (funciona con y para Serena. Por si se estan quedando pelados de luchar con Dimensions, este es el producto que poseen. Pago)
y les dejo un link sumamente interesante:
Matriz completisima y comparativa de diferentes productos de CI
Babeense :D
Saludos.
Revision de Codigo
Hoy en dia me encuentro escribiendo estandares y buenas practicas para la programacion en Java, y en algunos casos, para cualquier desarrollo que trate de ser dinamico (no digo agil, digo dinamico porque los diferencio en metodologia).
Creo que la revision de codigo es un fantasma empresarial al que muchas veces le han atribuido mas poder de resolucion de problemas del que tiene.
La revision de codigo automatica es el primer paso a una politica de desarrollo que termine en un Continuous Integration (voy a retomar este tema en otra entry) con buenas auditorias, de modo tal que el codigo se mejore continuamente y se modifique de una forma mas segura, llegando a produccion un codigo probado y lo mas estable posible, mitigando riesgos en ambientes productivos.
La idea que tengo ahora, es (en orden de prioridades):
Eso es lo que apunto en el primer paso. ya que creo que los pasos a Continuous Integration son:
No hablo de la integracion con todo el ciclo de SCM, ya que eso depende de las politicas de la empresa (si van a asociar cada cambio o si van a asociar un shipment por pedido, etc....). Ademas, el circuito de aprobacion de pedidos puede verse de forma separada, el ciclo de desarrollo como una caja negra y la salida (version, entregable, rollout, etc...) como el producto final del SCM.
La idea, es que la mayor parte del trabajo sea automatica, por lo que no voy a ponerme a revisar cada regla que escribo, sino, que voy a buscar herramientas que se integren facilmente al desarrollo que lo hagan por mi.
Para .NET ya lo tenemos. Ahi todo bien, se integra con el IDE, se generan reportes y la auditoria de estos reportes.....bueno, todo bien.
Para Java aun no, asi que vamos a usar alguno de estos:
checkstyle
Se integra con eclipse y maven, esta ampliamente difundido, genera reportes en diferentes formatos. Es configurable desde el IDE, se pueden exportar e importar las reglas a traves de un XML, se pueden extender las reglas.
Limitacion: Evalua codigo estatico, sin tomar en cuenta euristicas de codigo en tiempo de ejecucion. Las reglas evaluan el contexto de una sola clase y no todo el programa.
PRO: Ya hay gente que lo esta usando y definio un conjunto de reglas.
PMD
Se integra con eclipse y maven, esta ampliamente difundido, genera reportes en diferentes formatos. Es configurable desde el IDE, se pueden exportar e importar las reglas, se pueden extender las reglas.
Limitaciones: remarla para que lo pongan y aprendan. Evalua codigo estatico, sin tomar en cuenta euristicas de codigo en tiempo de ejecucion.
PRO: Es igual que checkstyle pero permite que las reglas que se crean actuen en un contexto de ejecucion de programa y no de clase.
Otros...
Hay uno de Parasoft (tiene muy buenos productos, como Jtest que genera los casos de prueba funcional visualmente y de ahi podes obtener los Junit. Y trabaja con python :D) que aplica euristicas sobre el codigo estatico que evaluan como se comportara en tiempo de ejecucion.... Guaaauuuuu, pero es pago y es caro, ergo NOT.
Asi que, por el momento me encuentro escribiendo documentos, para al final llegar a la meta.
Paso a paso :D
Igual, esto tiene muuuuucho mas sentidos en compañias que tienen mucho desarrollo in-house y mas sentido para compañias productoras de aplicaciones.
Saludos.
Creo que la revision de codigo es un fantasma empresarial al que muchas veces le han atribuido mas poder de resolucion de problemas del que tiene.
La revision de codigo automatica es el primer paso a una politica de desarrollo que termine en un Continuous Integration (voy a retomar este tema en otra entry) con buenas auditorias, de modo tal que el codigo se mejore continuamente y se modifique de una forma mas segura, llegando a produccion un codigo probado y lo mas estable posible, mitigando riesgos en ambientes productivos.
La idea que tengo ahora, es (en orden de prioridades):
- Revisar el formato del codigo... ok, eso ayuda a entender el codigo de la empresa siempre y cuando se determinen las reglas de nomenclatura mas importantes, el idioma del codigo, las entidades de negocio principales (para que este relacionado con el aspecto funcional y sea entendible) y archivos shipment y destinados al deploy.
- Corregir errores tipicos en el codigo estatico.
- Revisar de reglas de codigo de la empresa.
- Revisar y recomendar buenas practicas en el codigo (automaticamente) a modo de ir capacitando a los recursos.
- Crear un workspace comun a los diferentes proyectos y estandarizar los frameworks de desarrollo (maven).
Eso es lo que apunto en el primer paso. ya que creo que los pasos a Continuous Integration son:
- a- Repositorio comun, trabajo en equipo ordenado. b-Division clara de ambientes de desarrollo, prueba, preproduccion y produccion.
- Pruebas funcionales y regression tests
- Revisiones de codigo, estandarizaciones, convensions (si, hablo de poner maven y fijar un repositorio propio en lo posible donde controle los fwks y versiones que se pueden utilizar), buenas practicas
- Auditorias y automatizacion del proceso
- Stress test y automatizacion de pruebas funcionales
- Continuous Intregation (CI para los amigos :D).
No hablo de la integracion con todo el ciclo de SCM, ya que eso depende de las politicas de la empresa (si van a asociar cada cambio o si van a asociar un shipment por pedido, etc....). Ademas, el circuito de aprobacion de pedidos puede verse de forma separada, el ciclo de desarrollo como una caja negra y la salida (version, entregable, rollout, etc...) como el producto final del SCM.
- 1 y 2 ya los tengo, me faltan los demas.
- El 3 lo estoy haciendo.
- Para el 4 necesito fuerza de trabajo (mas gente, aunque esto depende de cuanto desarrollo in-house tenga la empresa)
- Para el 5, necesito suerte, porque voy a tener que trabajar muuuuucho para que las distintas areas me presten atencion y para que se definan las politicas de performance, atributos de calidad y se automaticen las pruebas funcionales :P
- Para el 6, si tengo todo lo demas solo necesito equipamiento de infraestructura y gente que brinde el soporte.
- Eso es lo que vengo calculando por ahora.
La idea, es que la mayor parte del trabajo sea automatica, por lo que no voy a ponerme a revisar cada regla que escribo, sino, que voy a buscar herramientas que se integren facilmente al desarrollo que lo hagan por mi.
Para .NET ya lo tenemos. Ahi todo bien, se integra con el IDE, se generan reportes y la auditoria de estos reportes.....bueno, todo bien.
Para Java aun no, asi que vamos a usar alguno de estos:
checkstyle
Se integra con eclipse y maven, esta ampliamente difundido, genera reportes en diferentes formatos. Es configurable desde el IDE, se pueden exportar e importar las reglas a traves de un XML, se pueden extender las reglas.
Limitacion: Evalua codigo estatico, sin tomar en cuenta euristicas de codigo en tiempo de ejecucion. Las reglas evaluan el contexto de una sola clase y no todo el programa.
PRO: Ya hay gente que lo esta usando y definio un conjunto de reglas.
PMD
Se integra con eclipse y maven, esta ampliamente difundido, genera reportes en diferentes formatos. Es configurable desde el IDE, se pueden exportar e importar las reglas, se pueden extender las reglas.
Limitaciones: remarla para que lo pongan y aprendan. Evalua codigo estatico, sin tomar en cuenta euristicas de codigo en tiempo de ejecucion.
PRO: Es igual que checkstyle pero permite que las reglas que se crean actuen en un contexto de ejecucion de programa y no de clase.
Otros...
Hay uno de Parasoft (tiene muy buenos productos, como Jtest que genera los casos de prueba funcional visualmente y de ahi podes obtener los Junit. Y trabaja con python :D) que aplica euristicas sobre el codigo estatico que evaluan como se comportara en tiempo de ejecucion.... Guaaauuuuu, pero es pago y es caro, ergo NOT.
Asi que, por el momento me encuentro escribiendo documentos, para al final llegar a la meta.
Paso a paso :D
Igual, esto tiene muuuuucho mas sentidos en compañias que tienen mucho desarrollo in-house y mas sentido para compañias productoras de aplicaciones.
Saludos.
lunes, 26 de mayo de 2008
Ruby
Ruby es un lenguaje de scripting dinamico bastante piola.
Se puede integrar con Java o .NET.
Viene pegando muy fuerte desde la salida de "Ruby on Rails", que permite la creacion de una aplicacion web de forma muy facil, rapida y divertida.
Les dejo un par de links interesantes para que vean:
Try Ruby!
http://tryruby.hobix.com/
El mejor tutorial que vi, veo y creo que vere en mucho tiempo. Es interactivo y muy, pero muy divertido :D
Un Eclipse para programar con Ruby:
http://rubyeclipse.sourceforge.net/
Ruby On Rails:
http://www.rubyonrails.org/
Aca tienen un par de screencast incluso, si se cansan de leer.
Saludos
Se puede integrar con Java o .NET.
Viene pegando muy fuerte desde la salida de "Ruby on Rails", que permite la creacion de una aplicacion web de forma muy facil, rapida y divertida.
Les dejo un par de links interesantes para que vean:
Try Ruby!
http://tryruby.hobix.com/
El mejor tutorial que vi, veo y creo que vere en mucho tiempo. Es interactivo y muy, pero muy divertido :D
Un Eclipse para programar con Ruby:
http://rubyeclipse.sourceforge.net/
Ruby On Rails:
http://www.rubyonrails.org/
Aca tienen un par de screencast incluso, si se cansan de leer.
Saludos
domingo, 25 de mayo de 2008
Sistemas de Monitoreo
Aca dejo un link de una compañia (AKCP) que se encarga de hacer la integracion de NMS (Network Management Systems) y que se encargo de hacer una descripcion para cada sistema que soportan.
Es una buena referencia para tener en cuenta:
http://www.akcpinc.com/company/nms.htm
Yo use BigBrother, Tivoli y HP Open View.
En el trabajo actual, tambien estamos usando Control M de BMC:
http://www.bmc.com/products/proddocview/0,2832,19052_19429_23437_1521,00.html
http://en.wikipedia.org/wiki/CONTROL-M
Pero esto no es de monitoreo, sino de ejecucion remota (algo que tambien tiene Tivoli).
Es un producto muy completo en cuanto a que tiene puede disparar eventos ante la llegada de un mensaje a una cola, la invocacion de un web service, etc...
Con respecto a Java:
En la JVM puede habilitarse la opcion de monitoreo SNMP. http://java.sun.com/j2se/1.5.0/docs/guide/management/SNMP.html
APIS SNMP para java:
Java No tiene SNMP
Jakarta En su biblioteca de commons de red no tiene soporte para SNMP
SNMP4J Es extremadamente precaria la doc. Tanto que los ejemplos se encuentran en la mismas clases :P y deben ser vistos en la javadoc. Se basa en una biblioteca SNMP de C++
JSNMP Es una biblioteca Java... Paga :P. Algo que no es recomendable es comprar bibliotecas... Es preferible comprar productos. Comprar libs es raro, el soporte de las libs puede ser patetico, las veces que vi comprar libs terminaron en resultados caoticos en cuanto a utilizacion y soporte. Ergo... NO COMPRO libs.
Saludos.
Es una buena referencia para tener en cuenta:
http://www.akcpinc.com/company/nms.htm
Yo use BigBrother, Tivoli y HP Open View.
En el trabajo actual, tambien estamos usando Control M de BMC:
http://www.bmc.com/products/proddocview/0,2832,19052_19429_23437_1521,00.html
http://en.wikipedia.org/wiki/CONTROL-M
Pero esto no es de monitoreo, sino de ejecucion remota (algo que tambien tiene Tivoli).
Es un producto muy completo en cuanto a que tiene puede disparar eventos ante la llegada de un mensaje a una cola, la invocacion de un web service, etc...
Con respecto a Java:
En la JVM puede habilitarse la opcion de monitoreo SNMP. http://java.sun.com/j2se/1.5.0/docs/guide/management/SNMP.html
APIS SNMP para java:
Java No tiene SNMP
Jakarta En su biblioteca de commons de red no tiene soporte para SNMP
SNMP4J Es extremadamente precaria la doc. Tanto que los ejemplos se encuentran en la mismas clases :P y deben ser vistos en la javadoc. Se basa en una biblioteca SNMP de C++
JSNMP Es una biblioteca Java... Paga :P. Algo que no es recomendable es comprar bibliotecas... Es preferible comprar productos. Comprar libs es raro, el soporte de las libs puede ser patetico, las veces que vi comprar libs terminaron en resultados caoticos en cuanto a utilizacion y soporte. Ergo... NO COMPRO libs.
Saludos.
Integrando .NET y Java
Como hacer que dos mundos diferentes se vean?
Esa es la pregunta que nos haciamos en mi nuevo trabajo.
Resulta que tenemos una aplicacion que tiene fuertemente encapsulada la logica de negocio y no puede desacoplarse.
El paso tipico seria poner un motor de reglas, un motor de BPM, de BPEL o algo para sacar la logica de ahi dentro y poder exponerla como servicio o en algun lugar normal de donde pueda consumir cualquier aplicacion (quizas con costo de performance, qos y tolerancia a fallos).
Resulta que no podemos hacer eso aun, por lo que requerimos copiar el codigo y hacerlo lo mas transportable y desacoplable a futuro posible. Estaria muy bueno poder hacer una biblioteca generica que represente una capa de negocio que se pueda utilizar en cualquier app, hecha en cualquier lenguaje. He aqui el problema... como integrar mundos diferentes? como integro Java y .NET si no puedo hacerlo con un servicio, un package de BD, un socket, una cola, ni un motor de reglas? Si tuviera que hacerlo con codigo como lo haria?
Al investigar descubrimos un par de cosas interesantes, aunque al final haremos una lib para Java y otra para .NET:
Integracion directa:
JNBridge
Las clases .NET se ven en Java, las clases Java se ven en .NET. Simple.
http://www.jnbridge.com/jnbphow.htm
Este es un producto pago.
Integracion por una 3ra tecnologia:
En estos casos, desde Java o .NET se pueden ver clases de un 3er lenguaje. En este caso lenguajes de scripting.
Desde el lenguaje de scripting (dependiendo del framework) se pueden ver las clases de Java o .NET.
Problema: debuggeo complicado, probables problemas en la integracion de las libs (en el manejo de memoria), codificacion antinatural :P
Python
Python for .NET
Jython
Ruby
Ruby para .NET . Hay varios interpretes. Esta es al direccion de un blog que habla al respecto Entry
JRuby
Groovy
Esta integrado en Java, pero no en .NET. Es que, esta pensado para Java
"An agile dynamic language for the Java Platform"
http://groovy.codehaus.org/
Javascript
Java soporta engines de interpretacion de javascript via rhino
Intuyo que .NET debe soportar VBScript, sino... bueno, capaz ni es util :P
Por framework que cargue los objetos:
Spring puede utilizar engines de interpretacion de lenguajes, al fin de que declarando que un bean esta hecho en ruby/python/groovy pueda crearse y utilizarse en codigo Java. Les dejo 2 formas:
Documentacion de spring:
http://static.springframework.org/spring/docs/2.0.x/reference/dynamic-language.html
Un ejemplo de un blog para hacerlo de otra forma, con una Ruby Bean Factory:
http://jroller.com/habuma/entry/spring_meet_ruby
Ademas de eso, Java 1.6 soporta engines para lenguajes de scripting:
http://java.sun.com/javase/6/docs/technotes/guides/scripting/index.html
La idea esta basada en el framework rhino
Pero Spring .NET y la VM de .NET todavia no soportan lenguajes dinamicos.
Espero que les sirva esta pequeña investigacion.
Saludos
Esa es la pregunta que nos haciamos en mi nuevo trabajo.
Resulta que tenemos una aplicacion que tiene fuertemente encapsulada la logica de negocio y no puede desacoplarse.
El paso tipico seria poner un motor de reglas, un motor de BPM, de BPEL o algo para sacar la logica de ahi dentro y poder exponerla como servicio o en algun lugar normal de donde pueda consumir cualquier aplicacion (quizas con costo de performance, qos y tolerancia a fallos).
Resulta que no podemos hacer eso aun, por lo que requerimos copiar el codigo y hacerlo lo mas transportable y desacoplable a futuro posible. Estaria muy bueno poder hacer una biblioteca generica que represente una capa de negocio que se pueda utilizar en cualquier app, hecha en cualquier lenguaje. He aqui el problema... como integrar mundos diferentes? como integro Java y .NET si no puedo hacerlo con un servicio, un package de BD, un socket, una cola, ni un motor de reglas? Si tuviera que hacerlo con codigo como lo haria?
Al investigar descubrimos un par de cosas interesantes, aunque al final haremos una lib para Java y otra para .NET:
Integracion directa:
JNBridge
Las clases .NET se ven en Java, las clases Java se ven en .NET. Simple.
http://www.jnbridge.com
Este es un producto pago.
Integracion por una 3ra tecnologia:
En estos casos, desde Java o .NET se pueden ver clases de un 3er lenguaje. En este caso lenguajes de scripting.
Desde el lenguaje de scripting (dependiendo del framework) se pueden ver las clases de Java o .NET.
Problema: debuggeo complicado, probables problemas en la integracion de las libs (en el manejo de memoria), codificacion antinatural :P
Python
Python for .NET
Jython
Ruby
Ruby para .NET . Hay varios interpretes. Esta es al direccion de un blog que habla al respecto Entry
JRuby
Groovy
Esta integrado en Java, pero no en .NET. Es que, esta pensado para Java
"An agile dynamic language for the Java Platform"
http://groovy.codehaus.org/
Javascript
Java soporta engines de interpretacion de javascript via rhino
Intuyo que .NET debe soportar VBScript, sino... bueno, capaz ni es util :P
Por framework que cargue los objetos:
Spring puede utilizar engines de interpretacion de lenguajes, al fin de que declarando que un bean esta hecho en ruby/python/groovy pueda crearse y utilizarse en codigo Java. Les dejo 2 formas:
Documentacion de spring:
http://static.springframework.org/spring/docs/2.0.x/reference/dynamic-language.html
Un ejemplo de un blog para hacerlo de otra forma, con una Ruby Bean Factory:
http://jroller.com/habuma/entry/spring_meet_ruby
Ademas de eso, Java 1.6 soporta engines para lenguajes de scripting:
http://java.sun.com/javase/6/docs/technotes/guides/scripting/index.html
La idea esta basada en el framework rhino
Pero Spring .NET y la VM de .NET todavia no soportan lenguajes dinamicos.
Espero que les sirva esta pequeña investigacion.
Saludos
viernes, 16 de mayo de 2008
Analisis disfuncional, parte 2
Logre convencerlos.... cosa rara
En el pasaje al nuevo repositorio se va a subir todo igual, versionar la version inicial y a partir de ahi se haran las operaciones.....
O sea, como les pedia...
Me empiezo a asustar.... nunca me habian dado bolilla. Puedo enviciarme :P
Saludos.
En el pasaje al nuevo repositorio se va a subir todo igual, versionar la version inicial y a partir de ahi se haran las operaciones.....
O sea, como les pedia...
Me empiezo a asustar.... nunca me habian dado bolilla. Puedo enviciarme :P
Saludos.
jueves, 15 de mayo de 2008
Analisis disfuncional
En sistemas, aun pensamos que todos los problemas se resuelven con programacion.
ERROR!
Sistemas de informacion implica definir procesos de conversion de datos a informacion pero no siempre llega a automatizarse a traves de un programa informatico.
Un error comun que ocurre en los analistas, es que cuando tienen una herramienta que resuelve un problema les parece infinitamente modificable para ajustar a otras necesidades similares.
Existen casos de sobreautomatizacion, donde generar un programa es 10000 veces mas complicado y problematico que definir un buen proceso manual.
La pluma es mas poderosa que el click: No todo es automatizable, existen validaciones que solo se pueden dar manualmente.
La revision humana es factible de errores, los data entries tambien. Hay veces que los circuitos humanos bien definidos pueden funcionar de manera mas segura que un sistema y la revision por ojo humano no puede ser reemplazada por un sistema complicado pasible de ataques.
Ejemplo: en el caso de alta de nuevos usuarios en un sistema remoto, que no debe ser accesible por cualquiera y cuando se posee un centro de atencion, podriamos eliminar los workflows asociados al alta y crearlos via formularios y back-office (una persona que los da de alta), siempre que el volumen y la demanda sea acotada. No informaticemos todo de entrada.
Es asi como una compañia gano en tiempo de salida al mercado en su phonobanking y otra en numeros amigos... pero shhhh no digan nada jeje
Herramienta Martillo: Cuando nuestra herramienta es un martillo, todo parece un clavo. No todo se ajusta a nuestro problema, algunas veces, tenemos que pensar mas alla de los sistemas (y mas alla aun de los sistemas existentes). Debemos pensar si es viable el esfuerzo de hacer un sistema.
Ejemplo: por algo que es poco usable y complicado de mantener....
El usuario quiere que se le automice el proceso de borrado de archivos basura en su maquina a traves de un conjunto de regla que definira mensualmente. El proceso de borrado se efectuara una vez al mes, la definicion de reglas se hara en un XML parseable y la cantidad de archivos mensuales a borrar son todos los que cumplan un filtro de nombre en un directorio.
Reingenieria infinita: Los programas no son infinitamente modificables, ya que terminarian en una reingenieria constante (hasta los chicles tienen limites)... y reingenieria es una palabra magica que soluciona todo lo que fue un caos, pero... al no corregir nunca la actitud se puede caer en infinitas reingenierias.
Detalles tecnicos de diseño y desarrollo en los requerimientos: ok ok, puede pasar... pero, es un problema cuando llegan requerimientos del estilo: el usuario escribe un XML con el pedido a hacer y blablabla...
Por favor, escribanlo puro y que la gente tecnica decida como va a ser el formato. No lo atemos a la idea del cliente... especialmente si va a terminar realizandose con un programa o una interfaz que va a hacer la implementacion transparente.
Hoy escribi esto porque por enesima vez, por desconocimiento de las herramientas existentes, me choque con un requerimiento que como programador tuve decir que se puede hacer y como arquitecto dije que es en vano realizarlo y que va en contra de toda logica.
El requerimiento era modificar un script de shell de traspazo de repositorios (o sea, algo para un problema puntual y salir del paso) para que se adapte a un conjunto de reglas a definir sobre la reestructuracion de directorios, para hacer automaticamente y la primera vez que se sube ese proyecto al nuevo repo.
Estas reglas debian documentarse en un xml que seria parseable por el todavia simple script de shell. Estas reglas eran validadas por un circuito de UAT (user aceptance test).
Digo yo... los analistas.... no deberian decirle al usuario lo que le dije yo a ellos:
1- que suban las cosas como estan y hagan los cambios despues para que sea traceable dentro del mismo repo y comparable con el anterior (querian que se mantenga la misma revision aunque en la reestructuracion los paths cambien). No manchemos la pelota por favor.
2- shell script es para un problema puntual, esto ya es un programa que lee un pseudocodigo de reglas (es cualquiera :P)
3- si solo se va a hacer una sola vez, que lo reestructuren manualmente y no pierdan tiempo con XML's. Los clientes de repositorios pueden hacerlo
4- No digan XML, no saben como va a ser. Denme las reglas.
5- que no hagan un proceso de sistemas de una solucion puntual que puede resolverse con herramientas existentes --> no reinventen la rueda y lean la documentacion de las herramientas.
Esta tarea puede realizarse con clientes pesados que manejan filtros... pero al no conocer este tipo de herramientas, el usuario pidio informatizar y modificar una que existia....
Regla de oro conclusiva:
ERROR!
Sistemas de informacion implica definir procesos de conversion de datos a informacion pero no siempre llega a automatizarse a traves de un programa informatico.
Un error comun que ocurre en los analistas, es que cuando tienen una herramienta que resuelve un problema les parece infinitamente modificable para ajustar a otras necesidades similares.
Existen casos de sobreautomatizacion, donde generar un programa es 10000 veces mas complicado y problematico que definir un buen proceso manual.
Expongo algunos items de los que fui viendo
La pluma es mas poderosa que el click: No todo es automatizable, existen validaciones que solo se pueden dar manualmente.
La revision humana es factible de errores, los data entries tambien. Hay veces que los circuitos humanos bien definidos pueden funcionar de manera mas segura que un sistema y la revision por ojo humano no puede ser reemplazada por un sistema complicado pasible de ataques.
Ejemplo: en el caso de alta de nuevos usuarios en un sistema remoto, que no debe ser accesible por cualquiera y cuando se posee un centro de atencion, podriamos eliminar los workflows asociados al alta y crearlos via formularios y back-office (una persona que los da de alta), siempre que el volumen y la demanda sea acotada. No informaticemos todo de entrada.
Es asi como una compañia gano en tiempo de salida al mercado en su phonobanking y otra en numeros amigos... pero shhhh no digan nada jeje
Otra mas simple, cosas que se pueden hacer manualmente si se pregunta el costo beneficio
Herramienta Martillo: Cuando nuestra herramienta es un martillo, todo parece un clavo. No todo se ajusta a nuestro problema, algunas veces, tenemos que pensar mas alla de los sistemas (y mas alla aun de los sistemas existentes). Debemos pensar si es viable el esfuerzo de hacer un sistema.
Ejemplo: por algo que es poco usable y complicado de mantener....
El usuario quiere que se le automice el proceso de borrado de archivos basura en su maquina a traves de un conjunto de regla que definira mensualmente. El proceso de borrado se efectuara una vez al mes, la definicion de reglas se hara en un XML parseable y la cantidad de archivos mensuales a borrar son todos los que cumplan un filtro de nombre en un directorio.
Podriamos plantearnos si el usuario en vez de definirnos toooooodo esto no hace un schedule del sistema operativo o directamente lo borra el. Cuanto esfuerzo de analisis, desarrollo, versionado conlleva esto y cuanto beneficio aporta????? Seguramente luego de esto va a querer mas cosas, lo que lleva al siguiente punto:
Reingenieria infinita: Los programas no son infinitamente modificables, ya que terminarian en una reingenieria constante (hasta los chicles tienen limites)... y reingenieria es una palabra magica que soluciona todo lo que fue un caos, pero... al no corregir nunca la actitud se puede caer en infinitas reingenierias.
Otro problema tipico en la especificacion de requerimientos
Detalles tecnicos de diseño y desarrollo en los requerimientos: ok ok, puede pasar... pero, es un problema cuando llegan requerimientos del estilo: el usuario escribe un XML con el pedido a hacer y blablabla...
Por favor, escribanlo puro y que la gente tecnica decida como va a ser el formato. No lo atemos a la idea del cliente... especialmente si va a terminar realizandose con un programa o una interfaz que va a hacer la implementacion transparente.
Hoy escribi esto porque por enesima vez, por desconocimiento de las herramientas existentes, me choque con un requerimiento que como programador tuve decir que se puede hacer y como arquitecto dije que es en vano realizarlo y que va en contra de toda logica.
El requerimiento era modificar un script de shell de traspazo de repositorios (o sea, algo para un problema puntual y salir del paso) para que se adapte a un conjunto de reglas a definir sobre la reestructuracion de directorios, para hacer automaticamente y la primera vez que se sube ese proyecto al nuevo repo.
Estas reglas debian documentarse en un xml que seria parseable por el todavia simple script de shell. Estas reglas eran validadas por un circuito de UAT (user aceptance test).
Digo yo... los analistas.... no deberian decirle al usuario lo que le dije yo a ellos:
1- que suban las cosas como estan y hagan los cambios despues para que sea traceable dentro del mismo repo y comparable con el anterior (querian que se mantenga la misma revision aunque en la reestructuracion los paths cambien). No manchemos la pelota por favor.
2- shell script es para un problema puntual, esto ya es un programa que lee un pseudocodigo de reglas (es cualquiera :P)
3- si solo se va a hacer una sola vez, que lo reestructuren manualmente y no pierdan tiempo con XML's. Los clientes de repositorios pueden hacerlo
4- No digan XML, no saben como va a ser. Denme las reglas.
5- que no hagan un proceso de sistemas de una solucion puntual que puede resolverse con herramientas existentes --> no reinventen la rueda y lean la documentacion de las herramientas.
Esta tarea puede realizarse con clientes pesados que manejan filtros... pero al no conocer este tipo de herramientas, el usuario pidio informatizar y modificar una que existia....
Regla de oro conclusiva:
"When your only tool is a hammer, everything looks like a nail"
miércoles, 14 de mayo de 2008
Problemas al loguear la IP cliente
Hoy estamos corriendo detras de un tema que es obtener la IP cliente este en la topologia que este.
Necesitamos loguear los accesos y sacar estadisticas sobre estas ip's. Al estilo Apache, nosotros podemos tomar cualquier header HTTP y loguearlo en un access.log
En el caso de Oracle Web Cache, que actua de Proxy reverso, esta setea la ip cliente en un header HTTP llamado "Client-IP" (que no encontre en el estandard HTTP 1.1). Este es nuestro reverse proxy interno.
En el caso del balanceador, el CISCO que tenemos JUSTO no tiene la funcionalidad de setear el header "X-Forwaded-for", asi que nos estamos queriendo matar. Adjunto un link de una pagina muy interesante sobre el tema:
http://lbdigest.com/2008/01/09/question-about-source-ip-addresses/
Algunos proxies de internet setean el X-Forwarded-for, otros dispositivos intermedios pueden setear otros headers (Como "NP-Client" o algo asi), pero el estandar es el X-Forwarded-for.
En el PEOR de los casos, y si la aplicacion es propia, lo unico que queda es que la ip del cliente venga como un parametro de aplicacion, por lo que nos veremos obligados a, si es HTTP, obtenerla a traves de un applet/server side javascript. Por javascript puro no hay forma de obtenerlo y VBScript esta atado a IE.
Adjunto un link al respecto. Como obtenerla en distintos lenguajes:
http://javascript.about.com/library/blip.htm
Una de las mas prolijas dentro de toda la desprolijidad es invocar a la JVM que esta en el browser:
<html>
<body>
<script language="javascript">
var ip = java.net.InetAddress.getLocalHost().getHostAddress();
document.writeln('IP=="' + ip + '"');
script>
body>
html>
(los tags no estan cerrados por problemas de publicacion en el blog)
Diviertanse :D
Saludos.
Necesitamos loguear los accesos y sacar estadisticas sobre estas ip's. Al estilo Apache, nosotros podemos tomar cualquier header HTTP y loguearlo en un access.log
En el caso de Oracle Web Cache, que actua de Proxy reverso, esta setea la ip cliente en un header HTTP llamado "Client-IP" (que no encontre en el estandard HTTP 1.1). Este es nuestro reverse proxy interno.
En el caso del balanceador, el CISCO que tenemos JUSTO no tiene la funcionalidad de setear el header "X-Forwaded-for", asi que nos estamos queriendo matar. Adjunto un link de una pagina muy interesante sobre el tema:
http://lbdigest.com/2008/01/09/question-about-source-ip-addresses/
Algunos proxies de internet setean el X-Forwarded-for, otros dispositivos intermedios pueden setear otros headers (Como "NP-Client" o algo asi), pero el estandar es el X-Forwarded-for.
En el PEOR de los casos, y si la aplicacion es propia, lo unico que queda es que la ip del cliente venga como un parametro de aplicacion, por lo que nos veremos obligados a, si es HTTP, obtenerla a traves de un applet/server side javascript. Por javascript puro no hay forma de obtenerlo y VBScript esta atado a IE.
Adjunto un link al respecto. Como obtenerla en distintos lenguajes:
http://javascript.about.com/library/blip.htm
Una de las mas prolijas dentro de toda la desprolijidad es invocar a la JVM que esta en el browser:
<html>
<body>
<script language="javascript">
var ip = java.net.InetAddress.getLocalHost().getHostAddress();
document.writeln('IP=="' + ip + '"');
script>
body>
html>
(los tags no estan cerrados por problemas de publicacion en el blog)
Python existe hace bocha y es 10 veces mas facil de leer que un codigo perl (una comparacion mas justa, un parseo y trabajo con strings bien hecho en python es mas facil de leer que un parseo y manejo de strings hecho en perl :D)
Hace tiempo que los lenguajes de scripting estan empujando con mas fuerza con ganas de entrar al mercado de aplicaciones comerciales… Y ERA HORA!!!!
Python es uno de los mas avanzados al respecto (especialmente en Juegos, Aplicaciones matematicas y de todo tipo jeje)
Antes estaba el código maquina y se paso a assembler
De assembler, se paso a C y otros
de C se pasa a algo como java, .NET
De Java y .NET se pasa a ?
El proximo nivel de abstraccion podria ser lenguaje scripting, quien sabe.
Todo sea por tratar de decirle a la maquina en el idioma mas humano posible "che! negra, dame un listado de pedidos del usuario ordenado por categoria que no esten vencidos, leemelo y mandamelo a imprimir en un formato bonito de 3 columnas"
Hay una charla muy copada de Neil Ford y Fowler donde hablan de la aparicion de Ruby on rails y otros, y de quitar el ruido que hay en los lenguajes. bah! en realidad habla de Domain Specific Languages (DSLs) y demases, pero a mi me gusto interpretarlo asi (jeje)
http://www.theserverside.com
Desde hace tiempo, para facilitar un poco a la programacion en C++ existe TCL/TK que se integra perfectamente con el lenguaje.
Ahora aparecieron para java cosas como el feature de scripting de la java 1.6 (creo que se basa en rhino), jython para integrarlo con python (Gracias Alecu por bombardearme con idea pythonescas), jruby que viene a ser un ruby y algo que puede ser groso: Groovy, que me presento un amigo :D (gracias Gon!)
No se cual va a ser el que pegue mas fuerte, pero va a estar interesante acompañar el proceso :D (si es que realmente hay o se da alguno)
Si les cabe el tema de python, miren estos videos:
http://plone.org/about/movies
En especial el de Better Web APP development.
Igual, es un poco injusto al hablar de la integracion de plone (BDOO hehca en python), comparada con la de ruby on rails (BD con estructura de tablas especifica).
De paso no esta mal darse una vuelta por el sitio de plone :P
Si realmente les cabió el tema python, les recomiendo el sitio de unos amigos: http://www.python.com.ar/moin
Son los chicos del Pyar (grupo argentino de usuarios de Python). Son gente muy copada y grosa.
Diviertanse :D
Saludos.
Grid Computing
Ultimamente estoy viendo muchos productos Java destinados al Grid Computing.
Parece que esta tratando de entrar en la conciencia del mercado sistemico, desde el desarrollo.
Una de las bases de todos estos productos es que los nodos se agreguen dinamicamente con mucha facilidad.
GridGain
http://www.gridgain.com/
Realmente permite hacer un grid, pero a costo de que la aplicacion este diseñada y codificada especificamente para procesar en un Grid.
Requiere un alto conocimiento tecnico y no es sencillo darle a programadores semi senior y junior la tarea de decidir que Split de tasks hacer. Es probable que el lider tecnico/arquitecto de software tenga overhead en un grupo de desarrollo que intenta construir con esta herramienta, por estar decidiendo a cada rato que tareas seran spliteables y cuales no conviene splitear.
No es transparente al codigo, por lo que no es facil "portear" aplicaciones viejas a un esquema Grid.
Aun asi, el producto es uno de los primeros que veo que hacen Grid en cuanto a procesamiento y no unicamente datos.
Tiene unos screencast muy copados, para el que no quiera leer demasiado. Merece la pena ojearlo.
Terracotta
http://www.terracotta.org/
Terracota es un Objecto Broker. La idea es dejar de pensar en RMI y comunicacion entre procesos remotos para comenzar a pensar en aplicaciones simples en el que la VM hara el broadcast de obejtos entre distintos nodos (EJB, te comes los mocos!!!! excepto el fabuloso MDB, claro).
Tenes una doble VM, donde una es el worker y esa publica a otra que se sincroniza con los demas nodos. La VM sincronizada despues publica los objetos a la worker.
Me llego un comentario que Sun piensa lanzar un feature parecido en alguna version de la VM, pero Sun es lento con los cambios.
PRO: Es trasparente a la aplicacion y se integra con spring. Si use Spring, mi codigo no deberia verse muy impactado. No es un Grid de procesamiento ni de datos, sino que es un productor-consumidor-broker de objetos. Eso hace que los objetos de un nodo, se vean en TODOS los nodos con la misma data.
Es una de las mas difundidas. Existen casos de exito de esta herramienta, porque ya hay desarrollos que la utilizan.
CONTRA: El nivel de transacciones entre VM's es altisimo, asegurar el sincronismo requiere un interesante trabajo de testeo (aun no confio mucho en el sincronismo de la herramienta).
Oracle Tangosol Coherence
http://www.oracle.com/technology/products/coherence/index.html
Es un especie de SAN. Usa un esquema de cacheo de datos y el desarrollador ve el acceso de objetos como la obtencion de entries de un Map.
Es un Grid de datos, no de procesamiento (por mas que los datos sean objetos). Permite que en varios nodos se vean los mismos registros con manejo de failover.
Para aplicaciones web es "semi-trasparente" ya que la persistencia de la sesion se maneja en una memoria "que parece compartida" que es accedida por todos los nodos del Grid.
Realmente es una ayuda al balanceo, ya que puede eliminar el schema de sticky sessions.
La persistencia se hace completamente en memoria, por lo que si se caen el nodo primario y el de backup, pueden perderse datos.
PRO: Es memoria, es configurable, es un grid de datos.
CONTRA: Para aplicaciones comerciales es pago, requiere codificacion para publicacion de objetos que no sean una simple HTTPSession, no es tan facil de configurar como parece. Oracle aun lo esta manoseando.
GigaSpaces
http://www.gigaspaces.com/pr_overview.html
Aun no lo pude observar, sinceramente. En cuanto pueda, le pego una ojeada.
Enjoy it.
Saludos.
Parece que esta tratando de entrar en la conciencia del mercado sistemico, desde el desarrollo.
Una de las bases de todos estos productos es que los nodos se agreguen dinamicamente con mucha facilidad.
GridGain
http://www.gridgain.com/
Realmente permite hacer un grid, pero a costo de que la aplicacion este diseñada y codificada especificamente para procesar en un Grid.
Requiere un alto conocimiento tecnico y no es sencillo darle a programadores semi senior y junior la tarea de decidir que Split de tasks hacer. Es probable que el lider tecnico/arquitecto de software tenga overhead en un grupo de desarrollo que intenta construir con esta herramienta, por estar decidiendo a cada rato que tareas seran spliteables y cuales no conviene splitear.
No es transparente al codigo, por lo que no es facil "portear" aplicaciones viejas a un esquema Grid.
Aun asi, el producto es uno de los primeros que veo que hacen Grid en cuanto a procesamiento y no unicamente datos.
Tiene unos screencast muy copados, para el que no quiera leer demasiado. Merece la pena ojearlo.
Terracotta
http://www.terracotta.org/
Terracota es un Objecto Broker. La idea es dejar de pensar en RMI y comunicacion entre procesos remotos para comenzar a pensar en aplicaciones simples en el que la VM hara el broadcast de obejtos entre distintos nodos (EJB, te comes los mocos!!!! excepto el fabuloso MDB, claro).
Tenes una doble VM, donde una es el worker y esa publica a otra que se sincroniza con los demas nodos. La VM sincronizada despues publica los objetos a la worker.
Me llego un comentario que Sun piensa lanzar un feature parecido en alguna version de la VM, pero Sun es lento con los cambios.
PRO: Es trasparente a la aplicacion y se integra con spring. Si use Spring, mi codigo no deberia verse muy impactado. No es un Grid de procesamiento ni de datos, sino que es un productor-consumidor-broker de objetos. Eso hace que los objetos de un nodo, se vean en TODOS los nodos con la misma data.
Es una de las mas difundidas. Existen casos de exito de esta herramienta, porque ya hay desarrollos que la utilizan.
CONTRA: El nivel de transacciones entre VM's es altisimo, asegurar el sincronismo requiere un interesante trabajo de testeo (aun no confio mucho en el sincronismo de la herramienta).
Oracle Tangosol Coherence
http://www.oracle.com/technology/products/coherence/index.html
Es un especie de SAN. Usa un esquema de cacheo de datos y el desarrollador ve el acceso de objetos como la obtencion de entries de un Map.
Es un Grid de datos, no de procesamiento (por mas que los datos sean objetos). Permite que en varios nodos se vean los mismos registros con manejo de failover.
Para aplicaciones web es "semi-trasparente" ya que la persistencia de la sesion se maneja en una memoria "que parece compartida" que es accedida por todos los nodos del Grid.
Realmente es una ayuda al balanceo, ya que puede eliminar el schema de sticky sessions.
La persistencia se hace completamente en memoria, por lo que si se caen el nodo primario y el de backup, pueden perderse datos.
PRO: Es memoria, es configurable, es un grid de datos.
CONTRA: Para aplicaciones comerciales es pago, requiere codificacion para publicacion de objetos que no sean una simple HTTPSession, no es tan facil de configurar como parece. Oracle aun lo esta manoseando.
GigaSpaces
http://www.gigaspaces.com/pr
Aun no lo pude observar, sinceramente. En cuanto pueda, le pego una ojeada.
Enjoy it.
Saludos.
Paginas utiles para un Quick Start
Creo que los Javeros siempre queremos conocer un poco de todos los framework que existen, incluso el JBanana (http://www.jbanana.org, https://jbanana.dev.java.net/). Todavia no se bien si es para mandarnos la parte o si es para no quedar con la boca abierta cuando alguien nos diga que esta usando muchas libs con nombre *J*algo.
La verdad, es que no hay tiempo suficiente para aprender todo y si bien hay screen casts y walkthroughs, uno no conoce bien los "fwks" hasta que se sienta a codificar algo que deba solucionar una necesidad REAL. Es por eso que existe gente que nos da esqueletos y ejemplos de codigos comunes, para ayudarnos a solucionar rapidamente problemas con los "fwks" existentes. Aca les paso dos ejemplos de buenos tipos (:P):
http://appfuse.org/display/APF/Home
Esta siempre es la misma aplicacion, pero desarrollada con fwks diferentes. No es lo suficientemente grande para hacer una prueba de carga, pero da una idea de tiempos y funcionalidad. Obviamente, el codigo con diferentes versiones es muy apreciado.
http://www.java2s.com/
Ejemplos de java a necesidades comunes.
Necesitas un ABM? Necesitas un Hola Mundo? Necesitas usar JBiX y no sabes por donde empezar? Bueno, bajate un ejemplo, correlo y despues contame...
Realmente son de ayuda ante problemas puntuales y sirven para dar un vistazo rapido a diferentes soluciones de un mismo problema.
Enjoy it!
Saludos.
La verdad, es que no hay tiempo suficiente para aprender todo y si bien hay screen casts y walkthroughs, uno no conoce bien los "fwks" hasta que se sienta a codificar algo que deba solucionar una necesidad REAL. Es por eso que existe gente que nos da esqueletos y ejemplos de codigos comunes, para ayudarnos a solucionar rapidamente problemas con los "fwks" existentes. Aca les paso dos ejemplos de buenos tipos (:P):
http://appfuse.org/display/APF/Home
Esta siempre es la misma aplicacion, pero desarrollada con fwks diferentes. No es lo suficientemente grande para hacer una prueba de carga, pero da una idea de tiempos y funcionalidad. Obviamente, el codigo con diferentes versiones es muy apreciado.
http://www.java2s.com/
Ejemplos de java a necesidades comunes.
Necesitas un ABM? Necesitas un Hola Mundo? Necesitas usar JBiX y no sabes por donde empezar? Bueno, bajate un ejemplo, correlo y despues contame...
Realmente son de ayuda ante problemas puntuales y sirven para dar un vistazo rapido a diferentes soluciones de un mismo problema.
Enjoy it!
Saludos.
jueves, 24 de abril de 2008
Blades Opteron
Los Blade Opteron Dual Core tienen problemas de sincronizacion entre los diferentes cpu's por lo que hacen que la hora del equipo avance mas rapido de lo normal y se vaya desfazando gradualmente.
Para corregirlo hay que tocar un parametro en el inicio de los sistemas (a mi me toco tocar en Red Hat's AS4 el /boot/groob/menu.lst que es un link al groob.conf) y rebootear el equipo.
Les dejo la advertencia y el link de HP.
Advisory: (Revision) HP ProLiant Servers Using Dual-Core or More Than One Single-Core AMD Opteron Processor May Experience Incorrect Operating System Time When Running Systems That Use the System Time Stamp Counter
JPA
Quien busque rapidez en el desarrollo, un enfoque de diseño top-down e independencia de la tecnologia que soportara su persistencia (en Java) debera volcarse tarde o temprano hacia JPA.
JPA es un estandar de persistencia Java fijado por Sun, se basa en Annotations y permite que el framework de persistencia varie de forma transparente, siempre que uno se ate a los Annotation estandar.
Todo el que haya trabajado con EJB 3.0 ya ha usado JPA en una medida.
Introduccion a JPA en el tutorial de java:
http://java.sun.com/javaee/5/docs/tutorial/doc/bnbpz.html
Actualmente Oracle Toplink e Hibernate 3 soportan JPA.
Nota: Hibernate 3 aun tiene problemas en su EntityManager para detectar Annotation de Hibernate. La Annotation Entity es completamente ignorada por el framework, pero no las de Proxy. Es conveniente, y casi una obligacion, usar siempre las Annotations estandar.
Cuando tenga mas data interesante voy a charlar mas del tema...
Saludos.
JPA es un estandar de persistencia Java fijado por Sun, se basa en Annotations y permite que el framework de persistencia varie de forma transparente, siempre que uno se ate a los Annotation estandar.
Todo el que haya trabajado con EJB 3.0 ya ha usado JPA en una medida.
Introduccion a JPA en el tutorial de java:
http://java.sun.com/javaee/5/docs/tutorial/doc/bnbpz.html
Actualmente Oracle Toplink e Hibernate 3 soportan JPA.
Nota: Hibernate 3 aun tiene problemas en su EntityManager para detectar Annotation de Hibernate. La Annotation Entity es completamente ignorada por el framework, pero no las de Proxy. Es conveniente, y casi una obligacion, usar siempre las Annotations estandar.
Cuando tenga mas data interesante voy a charlar mas del tema...
Saludos.
CXF ya es Top Level Project!!!
y que carajo es eso???
CXF es un framework para el desarrollo de WebService en JAVA rapido, completo y facil de aprender. Soporta SOAP y Rest.
CXF es una mezcla de XFIRE y algun desarrollo de jakarta. Aun esta en el Apache Incubator, pero ya fue graduado a Top Level Project!!!
http://incubator.apache.org/projects/cxf.html
Y si ven el aviso del 16/4:
http://www.nabble.com/CXF-has-graduated!-p16730373.html
Esto es una gran noticia para todos aquellos que opinaban que Axis 1.4, Axis 2 (en especial), Spring Web Service, JAXRPC y las soluciones del mercado en general eran decepcionantes.
Saludos.
CXF es un framework para el desarrollo de WebService en JAVA rapido, completo y facil de aprender. Soporta SOAP y Rest.
CXF es una mezcla de XFIRE y algun desarrollo de jakarta. Aun esta en el Apache Incubator, pero ya fue graduado a Top Level Project!!!
http://incubator.apache.org/projects/cxf.html
Y si ven el aviso del 16/4:
http://www.nabble.com/CXF-has-graduated!-p16730373.html
Esto es una gran noticia para todos aquellos que opinaban que Axis 1.4, Axis 2 (en especial), Spring Web Service, JAXRPC y las soluciones del mercado en general eran decepcionantes.
Saludos.
main( )
Hola Mundo!
Y tenia que ser asi nomas :P
Siendo sistemico no podria comenzar un blog de otra forma.
Vamos a ver hasta donde llego con este blog y si tiene un poco mas de suerte que mi lastimoso space de msn :P
La idea inicial es ir posteando los problemas o cosas nuevas que vaya encontrando en el entorno profesional, pero no voy a tardar en agregar algunas cosas personales.
Saludos.
Y tenia que ser asi nomas :P
Siendo sistemico no podria comenzar un blog de otra forma.
Vamos a ver hasta donde llego con este blog y si tiene un poco mas de suerte que mi lastimoso space de msn :P
La idea inicial es ir posteando los problemas o cosas nuevas que vaya encontrando en el entorno profesional, pero no voy a tardar en agregar algunas cosas personales.
Saludos.
Suscribirse a:
Entradas (Atom)
