Virtualización con VMware ESXi

                                                              

Esta es una tecnología que ya tiene muchos años, de hecho es una  tecnología que ya se utilizaba en sistemas Mainframe.  Desde hace un tiempo que utilizo productos de VMWare, realmente tienen una suite de soluciones que podría decirse abarca todos los tipos de necesidades, desde el VMWare player (gratuito), que permite cargar maquinas virtuales, hasta productos que permiten el manejo de datacenters para la administración de servidores virtualizados.

En esta ocasión me toco trabajar con VMWare ESXi, este es un producto que me pareció muy interesante, primero porque se puede utilizar libre de cargo (puede licenciarse para obtener soporte), y porque además utiliza un hypervisor que corre sobre utilizando una muy baja cantidad de recursos (32 Mb de RAM y aproximadamente 1 GB de espacio de disco).

La instalación la probé en un DELL PowerEdge 1950 y un 2900, además también pude hacer una instalación en un Pendrive y correrlo desde mi notebook Thinkpad T61P ( Lo cual es interesante para poder mostrar productos que pueden estar instalados en un servidor de storage externo al cual se se puede acceder mediante la red desde el producto)

Para resumir un poco, enumero algunas de las ventajas mas interesantes de este producto

• No requiere un sistema operativo para el HOST, el hypervisor corre sobre un SO *NIX que tiene un consumo de recursos súper reducido
• Las maquinas virtuales corren prácticamente sobre el hardware
• Se puede particionar el servidor y asignar recursos según las necesidades que se tengan, se puede asignar procesadores, memoria, etc…
• Posibilidades de administración centralizada utilizando herramientas de VMWare para manejo data centers
• El producto se puede usar gratis (aunque si se quiere soporte debe licenciarse)
• Versiones para 32bits y 64bits (la ultima versión es solo para 64bits)
• Importación y exportación en formato OVF, con este formato pude lograr pasar una VM que pesaba 79Gb a 15Gb                         

BPEL Designer

Estuve buscando algún designer de BPEL, hasta el momento siempre use el de SAP XI que trae con su herramienta de ccBPM o el SOA Designer de ARIS, el tema con estas herramientas que son bastante buenas y potentes requieren de licencias, y yo quería hacer algunas pruebas simples en mi casa, me acorde de que existia uno de Oracle que se podía usar con Eclipse pero vi que estaba medio abandonado, lo mas conveniente era bajarse directamente el JDeveloper con el IAS y la suite de SOA... si bien JDeveloper es una IDE muy potente y yo la use por un buen tiempo, el IAS tiene un apetito (o al menos las versiones que use) bastante grande de memoria así que seguí buscando alternativas.

El siguiente que encontré fue uno de Active Endpoints pero luego en algunos foros decía que había una versión free que estaba algo limitada y que la paga era bastante mas completa, por lo que ni siquiera me tome el trabajo de bajarla.

Siguiendo con mi búsqueda llegue al STP (SOA Tools platatorm) de Eclipse, y vi que había muchas herramientas, todas muy interesantes incluso un editor de BPMN, otro de BPEL, pero me desalento un poco que todavía siga en incubación (mas que nada porque quería probar algo rápido, por lo general no tengo problemas de usar proyectos que estén en incubación, pero no quería arriesgarme a luchar con problemas de inmadurez).

Así que finalmente me acorde de Netbeans (tengo que reconocer que nunca fui fanático de esta IDE, siempre me sentí mas cómodo con Eclipse, aunque tuviera que andar haciendo todo tipo de búsquedas para encontrar los plugins) y me baje la versión 6 que trae un editor de BPEL y además trae un app server para desplegar el BPEL y ejecutarlo,

La verdad que me gusto bastante esta nueva versión de Netbeans, fui directamente a ver la parte de BPEL y tiene algunos ejemplos que están muy buenos y que ya tienen todo armado para desplegarlos en el App server que nos instala cuando lo bajamos.

Para mi próximo Post voy a armar un pequeño tutorial de BPEL usando esta herramienta.

Enterprise Service Bus - WSo2 ESB

Etiquetas de Technorati: ESB,SOA,BPM

  

Hace poco tuve que hacer una demostración de un middleware de integración y sabia que había sido comparado contra otros sistemas que estaban mas orientados a ser sistemas de ESB, el sistema que iba a mostrar tenia esas características pero quería conocer otros sistemas del mercado y decidí bajarme el de WSO2.

Esta empresa ofrece un Service BUS que es gratis y esta basado en Synapse, que es un proyecto de Apache para crear un broker de servicios.

Me parece interesante recalcar dos cosas, la primera es que el instalador de este ESB ocupa menos de 40mb y el sistema instalado usa menos de 52mb, algo bastante liviano si comparamos a otros ESB del mercado, también el nivel de prestaciones es bastante mas básico, pero no por eso deja de ser una alternativa interesante.

La consola que trae es bastante intuitiva y en pocos minutos y leyendo un poco de la documentación pude crear un endpoint y publicarlo por medio de un proxy.

La consola tiene este aspecto:

Desde esta consola podemos manejar la configuración del ESB.

Algunas de las características que pude ver son:

• Crear un proxy que es expuesto mediante un WSDL que podemos crear específicamente o usando uno existente
  • Crear pipelines de procesamiento para los mensajes de entrada y salida, en un pipeline definimos acciones que se van a ejecutar durante el procesamiento de un mensaje dentro del BUS, por ejemplo podemos definir el endpoint al que va a ir dirigido el mensaje, logging, transformación (mediante XSLT). Estos pipelines en esta herramienta reciben el nombre de Sequences
  • Definir el endpoint al que va a invocar el Proxy, que puede ser un web service, o un servicio que realice tareas de balanceo de carga, etc...
  • Definir niveles de logueo
  • Monitoreo de las actividades dentro del WS

A continuación un vídeo de ejemplo de como crear un Proxy que llama a un Web Service pasando por el ESB de WSo2.

Task list - Remember the milk

Existen una gran variedad de aplicaciones para mantener ordenadas las tareas del día a día, Google calendar, mails, outlook etc...

Recientemente me cruce por la web con una aplicación muy interesante con un nombre muy curioso, "Remember the milk" este Task List manager se integra perfectamente con Google Calendar, y también con GMail donde podemos ver una lista de tareas al costado de la lista de mails

Otra capacidad que tiene es la de enviar los recordatorios, estos pueden ser enviados vía SMS a un celular, mail, o mediante mensajes instantáneos.

Y lo mejor de todo... For free!  :-)

Existe una versión pro que es paga que además permite sincronizar con dispositivos mobile.

Nuevo libro de OSWorkflow

Recientemente a través de un feed me encuentro con la grata noticia de que apareció un libro de OSWorkflow. Para mi sorpresa me encuentro con que además el libro lo escribió alguien a quien conocí personalmente en una breve ocasión justamente por un tema de integracion de una herramienta de BPM con un desarrollo que realizaron sobre la plataforma de OSWorkflow.
Con lo que seguramente vamos a poder encontrarnos con un libro que nos puede dar una dimensión real sobre el uso de OSWorkflow en situaciones reales.

El contenido del mismo es:

Chapter 1 gives an overview of the BPM technology and the workflow engine, along with an analysis of the different type of BPMS.

Chapter 2 introduces OSWorkflow and teaches the basics of the workflow engine along with a real life example.

Chapter 3 introduces several key features of OSWorkflow like handling persistent and transient variables, variable interpolation, built in OSWorkflow functions, Conditions, BeanShell scripting.

Chapter 4 covers Persistence of variables across invocations, and the FunctionProviders along with integrating OSWorkflow with Spring.

Chapter 5 introduces and integrates Rules engine and Drools open source rule engine.

Chapter 6 we explore the Quartz task scheduler, its integration with OSWorkflow and we give a tutorial with Quartz sending events and actions to OSWorkflow.

Chapter 7 introduces Event Stream Processing and Complex Event Processing. We give an OSWorkflow function provider that interfaces with the ESPer CEP engine and allows the monitoring of real time process information and events.

Chapter 8 gives OSWorkflow visualization of its business process information with the Pentaho Open source BI solution. Using the charting capabilities of Pentaho we build an enterprise process dashboard to monitor and analyze the processes.

Los datos del libro

Language English
Paperback 200 pages [191mm x 235mm]
Release date August 2007
ISBN 1847191525
ISBN 13 978-1-847191-52-6
Author(s) Diego Adrian Naya Lazo

Enterprise integration architecture y ESB Architecture??

No se cuando realmente empecé a trabajar en temas de integración, en mis comienzos en una empresa que manejaba transacciones de tarjetas de crédito uno de mis primeros desarrollos fue un programa que tomaba datos de un archivo que luego eran procesados y se cargaban datos que era utilizados en otros sistemas.

Eso de alguna manera era una forma de integración (este tipo de integraciones es denominada integración de datos) donde un sistema que dependía de datos de otro lo hacia por medio de interfaces que eran archivos.

Tarde un poco en entender que eso era una interfase, creo que fue en una reunión con analistas de un modulo de SAP donde se hablaba de tener varias interfaces, en mi mente yo imaginaba “Uhh cuantos conectores que se va a necesitar desarrollar” pero alguien me dijo “a los archivos planos les llaman interfaces” Ohhh ahora entiendo!

El tema es que en algún momento nos vamos a topar con algún problema de integración, ya sea en sus formas mas simples (intercambio de archivos, por medio de una base de datos, o utilizando algún middleware especializado), todo esto es lo que para mi cae dentro de la categoría de AI (architecture integration, y si integro aplicaciones de negocios como un CRM , un ERP, BW, tenemos lo que hoy se llama EAI).

Por lo general en una empresa que tiene uno de estos sitemas nos encontramos con que no es el único sistema y que este provee y se alimenta de información/servicios provenientes de otros sistemas, y es donde empezamos a ver integraciones de diferentes tipos, con diferentes niveles de complejidad y en cantidades “industriales”.

La moda de querer vender SOA en todo producto que se lanza al mercado puso mas en evidencia el tema de integración y como todo paradigma emergente trajo aparejados muchos nuevos conceptos muchas nuevas siglas y mucha confusión.

Hoy ya conocemos siglas como SOA (Service oriented architecture), ESB (Enterprise service bus), EDA (Event driven architecture), WS-*(Especificaciones de Web Services), REST (Representational state transfer), BAM (Business activity monitoring), CEP (Complex event processing).

Entonces terminamos confundiendo algunos conceptos, en una trabajo que tuve que revisar, encontre que la propuesta mezclaba algunas cosas, y estas representaban errores conceptuales donde se mezclaban patrones de arquitectura con herramientas, esto me parece un error bastante grueso porque representa las bases! Y si no tenemos en claro las bases difícilmente podamos comprender el resto.

Lo mas notorio que encontré en este ultimo tiempo fue en un blog de alguien que me parece una eminencia en el tema, un desliz de este tipo, donde habla de una arquitectura llamada “ESB architecture” leyendo el blog creo entender a lo que el llama ESB architecture, pero me parece que es muy importante poder distinguir que ESB es una herramienta de integración que centraliza las comunicaciones y provee una serie de servicios para la interacción de los sistemas, pero que no es una forma de arquitectura en si, al menos para mi no lo es y para otros tampoco.

Por esto me gustaría compartir este link de un blog que para mi no tiene desperdicio que da una explicación muy buena de EAI, ademas tiene notas muy buenas sobre EDA.

xDash

Se trata de un framework de integración que esta basado en el protocolo JABBER, me pareció muy interesante.
La arquitectura no es ninguna novedad, se trata de un ESB montado sobre un sistema de mensajeria asincronica, no es muy diferente a lo que hace el Integrator server de Wesbphere, usando MQSeries.

Pero de todas formas me parece interesante debido a que estuve investigando un poco de algo que cada vez va a ser mas usado, SOA y EDA.
Hoy se habla mucho de SOA, el paradigma principal de SOA es Request/Response, EDA en cambio plantea una arquitectura basada en eventos, donde el paradigma es Publish/Subscribe.Muchas soluciones requieren de una combinación de estas dos Arquitecturas, y ahí es donde entran a jugar los mix de sistemas basados en mensajes, hasta ahora JMS es hoy por hoy el standar de facto, pero es interesante explorar otras tecnologías como JABBER que pueden llegar a ser muy eficientes (miles de usuarios todos los días lo demuestran)

Interoperabilidad JMS .Net

Leyendo un poco en Infoq encontre un artículo de interoperabilidad de .Net y JMS, es algo por demas interesante debido a la cantidad de implementaciones que existen hoy de Middlewares que usan JMS.

El uso de mensajes es una de las soluciones mas escalables a la hora de realizar integraciones entre sistemas.

Ademas existe una extensa literatura, y patrones sobre integración utilizando esta técnica.

Para mas info sobre estos patrones visitar la pagina de Enterprise integration patterns

Implementing an Enterprise Services Architecture

Implementing an Enterprise Services Architecture

Una guia como para arrancar con la implementacion de arquitecturas ESOA.

Esta interesante, y despeja algunas dudas que surgen a la hora de ponerse a trabajar en ese topico.

WS-*/REST Wars

Estoy leyendo últimamente muchos post de lo que parece una batalla por establecer cual es la mejor arquitectura para aplicaciones basadas en servicios o en recursos si hablamos en terminos de REST.

Por un lado esta los WS-REST y por otro todo el stack WS-*, y están los detractores y los defensores de cada uno de estos estilos, lo que mas me llama la atención es el fervor casi religioso con el que cada uno defiende el estilo que le parece mas correcto.
Mi conclusión es que REST es un estilo que puede servir en ciertos casos y en otros no, lo mismo que WS-*.

Creo que es trabajo del arquitecto poder apartarse de estos fanatismos y poder decidir en base a criterios uniformes y bien establecidos, donde la desicion que se tome este orientada a cumplir con una serie de objetivos y no con una tendencia o moda de la comunidad.

Otra guerra muy interesante y también graciosa por el tono de alguno de los POST es la de XFire y AXIS2.

Business Process Management - BPM

BPM es una de esas disciplinas que la gente que siempre se dedico a desarrollos de sistemas a veces ve pasar medio de costado, o directamente ni saben de que se trata, como era mi caso hace un tiempo atrás.

In an Nutshell la practica de BPM se encarga de la administración de los procesos de la organización las principales actividades que lleva a cabo son:

• Diseño Modelado de los procesos
• Ejecución de los procesos
• Optimizacion de los procesos
• Monitoreo de los procesos

Hoy en día la sigla BPM es mucho mas conocida que hace varios años atras, recuerdo que la primera vez que tuve un acercamiento fue en 1998 aproximadamente, cuando fui a una reunión en un banco mayorista, y la gente que estaba modelando los procesos del banco nos hizo una demostración de una herramienta llamada Aris, vimos cosas muy interesantes a nivel de modelado y de simulación de procesos, el problema es que necesitábamos ademas poder de alguna forma ejecutar esos procesos, y la plataforma no contaba con esas posibilidades.
Pasaron algunos años para que requerimientos de ese tipo puedan ser cumplidos utilizando herramientas y estandares de mercado, hoy contamos con varios de estos estandares y con todo el empuje que están recibiendo las arquitecturas orientadas a servicios.

Acá es donde entra a tener mucha mas importancia BPM, si bien ya de por si es una disciplina muy importante para las organizaciones, esta importancia se potencia mas con la disponibilizacion de los procesos y la creación de ecosistemas donde coexisten sistemas heterogeneos, y donde la próxima generación de aplicaciones sera lo que se llaman Composite aplications (tema que va a dar mucho mas que hablar en el futuro).
Si bien las Composite aplications no son nuevas, la disponibilizacion de los procesos de negocios como servicios para construir sistemas si es algo mas nuevo, y para poder generar respuestas a la velocidad con que se generan los cambios las empresas necesitan mayor flexibilidad en sus procesos de negocios, pero suelen chocarse con la barrera de los sistemas, los cuales no pueden responder con la velocidad requerida para la implementacion de estos cambios.
Hoy por hoy recien se esta empezando a ver la necesidad de la reutilizacion, pero ya no a nivel de codigo, sino a nivel de procesos, y en el futuro vamos a empezar a escuchar mas sobre nuevos roles como el de Business Process Expert , rol que va actuar como nexo entre lo que es procesos y el area que va a implementarlos.

Analizando aplicaciones en producción

Buscando algo de información sobre herramientas para realizar profiling encontré un blog que hablaba sobre el problema de que hacer cuando necesitamos hacer profiling de una aplicación que esta en producción.

Este problema generalmente surge por problemas de performance en la aplicación, por lo que si metemos un profiler la performance se vera todavía mas afectada.

Afortunadamente se pueden tomar snapshots de la ejecución de una aplicación java a partir de Java 5 update 7 y de Java 1.4.2_12, estos snapshots pueden ser analizados con algunas herramientas que permiten obtener información bastante interesante como esta corriendo la aplicación y recursos que se están utilizando.

Podran encontrar mas informacion en estos links:

Blog que discute el tema de HEAP DUMP en Java

Herramientas para analizar HEAP DUMPS

• Samurai
• HAT
• HPROF
  

Explorando nuevos usos de Jabber

Estaba mirando un poco JMS y decidí bajar el Websphere CE para hacer pruebas, cuando voy a al configuración del servidor de JMS encuentro que puedo agregar un Jabber Listener.

Esto me hizo recordar inmediatamente un evento al que había asistido de Oracle, donde en una de las demos que había, mostraban una aplicación que se accedía desde un cliente de IM que podía acceder servidores Jabber, donde el sistema desplegaba un menú y el usuario indicaba mediante un numero que opción quería y el sistema le respondía nuevamente con la información que había solicitado.

En ese momento se me ocurrieron sistemas interactivos para una mesa de ayuda, o para consultas de datos, todo es valido como opción para poder exponer información.

Me puse a ver un poco y encontré otra forma de usar Jabber dentro de una aplicación, y es combinado con Log4J, me parece muy interesante ya que puede servir para mandar mensajes a un administrador o a alguien que este monitoreando determinada aplicación.

Aca dejo la URL del artículo para que lo vean, de paso es un buen ejemplo de como construir appenders para Log4j.

JavaScript The Objec tWay

Estuve trabajando un poco con algunas cosas que estaban hechas con JavaScript, y tenia que introducir un pequeño cambio en algo que se suponía debería ser sencillo, afortunadamente no lo fue, y tuve que ponerme a refactorizar todo el código que estaba escrito en una forma totalmente procedural utilizando el nefasto estilo spaghetti.

Tarde o temprano iba a tener que meterle algo de mano a cosas hechas en JavaScript, y como esas que uno espera nunca tener que hacer, llego ese momento.

Recordé que una vez escuche que en JavaScript se podía llegar a trabajar en una forma bastante “objetosa” así que decidí ponerme a investigar un poco y encontré que efectivamente se puede y que además se pueden hacer cosas bastante interesantes que ni me imaginaba.

Por ejemplo, se pueden crear Clases y generar instancias de estas, se puede llegar a construir una herencia con un mecanismo que se llama prototipado:
Clases con JavaScript:

function Reporte() {
this.inicializar = function(e) {
window.alert("Esto es una prueba de prototipos con JS");
}

this.testTrue = function(e) {
return false;
}
}

function main() {
var aReporte = new Reporte();
aReporte.inicializar();
if(aReporte.testTrue()) {
window.alert("La validacion dio verdadera");
}
}

En el ejemplo se ve como se crea una Clase llamada Reporte, esta clase contiene una funcion llamara inicializar, que emite un mensaje y en la funcion main se ve como se usa la clase Reporte

Herencia con JavaScript

function superClass() {
this.supertest = superTest;
}

function subClass() {
this.inheritFrom = superClass;
this.inheritFrom();
this.subtest = subTest;
}

function superTest() {
return "superTest";
}

function subTest() {
return "subTest";
}

var newClass = new subClass();
alert(newClass.subtest());
alert(newClass.supertest());

Esto es un poco de lo que vi hoy, dejo algunos links que me sirvieron bastante.

• Tutorial OOP javaScript
• Object Oriented JavaScript
  

Ciencia Ficción en Bits

Hace poco encontré un viejo Diskette de cuando estaba cursando en la secundaria en 4to año, algunos eones atrás, increíblemente estaba etiquetado, algo que solo hacia con discos que realmente creía interesantes.
Lo que decía la etiqueta era AXXON , repentinamente recordé que era el contenido del disco, una revista!!

La revista AXXON era una publicación de ciencia ficción gratuita que se distribuía en Diskette, estaba hecha creo en Turbo Pascal, usando programación grafica, incluía en sus cuentos imágenes y enlaces estilo HTML, y eran muy buenas historias.
Buscando en Google encontré que tienen una pagina y que hoy es aun mas interesante que cuando la conocí, así que si les gusta el genero les recomiendo que se den una vuelta y disfruten de buenas historias.

Había una vez AJAX

El desarrollo WEB que comenzó hace varios años era puramente estático con paginas escritas en HTML que podían tener vínculos con otros documentos, una evolución de este modelo fue las paginas dinámicas que por medio de procesos generaban el código HTML que se presentaba, estos procesos de los denominaba programas CGI y permitían que se acceda a bases de datos y que los contenidos sean mostrados en paginas HTML.

Ese modelo sirvió bastante tiempo pero tenia falencias como el tiempo de ejecución o la cantidad de pedidos que podían ser servidos en un momento determinado, debido a que los programas CGI se ejecutaban en un proceso distinto por cada request que atendían.

Como consecuencia de esto aparecieron otras soluciones que básicamente solventaban los problemas de escalabilidad del modelo CGI. Surgieron servidores que podían correr estos procesos de una manera mucho mas rápida y sin el overhead de la creación de procesos, en esa época Netscape con su servidor WEB tenia un conjunto de librerías llamadas NSAPI y Microsoft con su IIS tenia las ISAPI.

Luego apareció Java que de a poco iba ganando espacio en la WEB y surge un modelo que conceptualmente se parecía a los Netscape y Microsoft, los Servlets, pero con algunas cosas que los hicieron particularmente atractivos para los desarrolladores, y era la simplicidad con la que se podía crearlos, en contrapartida con los modelos de Netscape y de Microsoft.

Pero resulta que el modelo del request y del response para refrescar los datos de la pantalla no había presentado una evolución en todo este tiempo, esto fue así hasta que Google comienza a desplegar aplicaciones como Gmail donde uno podía ver como una aplicación WEB se comportaba casi como una aplicación del tipo Desktop, esto despertó la curiosidad de muchos y es donde se comenzó a hablar de AJAX.

Hoy en día ya nadie se sorprende de ver una aplicación donde las paginas cambian su contenido sin que se realicen refrescos de la misma, es mas hoy es algo que resulta ya molesto tener que refrescar las paginas para cargar la información de un combo.

Pero como con todas las tecnologías que emergen en un principio son algo complicadas y muchas veces caemos en tareas repetitivas o en modelos donde las cosas no son manejables o reutilizables.

La batalla de los entornos de desarrollo como Java y .Net puede llegar a tornarse desiciva si alguno de estos logra abstraer todo esta complejidad y ocultarla al desarrollador.

Microsoft ya esta trabajando en un framework llamado ATLAS que proveerá componentes para ASP .Net que trabajaran con AJAX.

Para Java hay también bastantes frameworks de presentación que están dando soporte para AJAX, y además existe un framework para utilizar de GOOGLE, estuve dándole una mirada a los ejemplos y me pareció excelente el enfoque que dan para poder abstraer la complejidad de desarrollar con esta tecnología , el framework se llama GWT (Google Widget Toolkit)

Que será el próximo paso en la evolución de la WEB ? La WEB Semántica? Nuevos protocolos con estado?

Herramienta para detectar cambios en una API

Un problema que suele presentarse cuando se trabaja con librerías de terceros son los cambios que se pueden realizar entre una versión y otra, muchas veces sucede que no hay buen manejo de estos cambios y la documentación es prácticamente nula.
Un podría seguir utilizando la versión actual pero la gran mayoría de las veces uno se ve forzado a hacer estos cambios porque la nueva versión contiene importantes mejoras con respecto a las anteriores o arreglan bugs.
Las soluciones que se pueden llegar a plantear es reemplazar la API correr un test de regresión y verificar que todo siga funcionando como se esperaba, o en el caso lamentable de no tener forma de testear la aplicación cambiar la API y cruzar los dedos!!
Para cualquiera de los casos anteriores primero debemos reemplazar la API, lo ideal seria poder tener un filtro previo como para poder lograr mayor visibilidad del cambio que se esta por realizar, una forma de poder lograr esto seria comparando las versiones de la API, la que esta en uso y la que se quiere usar para reemplazar y verificar los cambios que hay entre una y otra, esta es una tarea que puede llegar a ser demasiado costosa en tiempo, pero afortunadamente hay una herramienta que nos puede dar una buena mano para realizar esta tarea JDiff lo que hace Jdiff es generar un reporte en HTML con el formato de un JavaDoc con las diferencias que contiene una API con respecto a la otra, muestra los métodos que se agregaron, los que se eliminaron, etc... en la pagina hay varios ejemplos de comparaciones de API.

JVM para testear Sistemas de la NASA

La NASA hizo publico y open source una JVM que permite encontrar dentro de un programa los flujos que pueden llevar la ejecucion a un estado en la cual la misma seria inestable.

Según los creadores es capaz de econtrar excepciones mal manejadas, problemas de deadlocks, y que esta especialmente pensado para poder testear aplicaciones multithread.

El proyecto esta hosteado en source forge y su nombre es Java PathFinder

Patrones de diseño

Desde la aparicion en 1995 de el libro Design Patterns: Elements of Reusable Object-Oriented Software de los autores Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides mas conocidos como GoF (Gang of four) el movimiento detrás de los patterns tuvo un auge muy grande.

Surgieron descenas de libros tratando sobre el tema y esto se debe a que los patterns son soluciones probadas y practicas a problemas que son bastante comunes en un determinado dominio, una de las ventajas es que incorporan al dominio del profesional de sistema nuevos lexicos que son comprendidos de manera inmediata y permiten que uno pueda abstraerse de detalles muy complejos que tienen que ver con el dominio de la solucion, como ejemplo uno puede decir “Una factura es un composite de items” y esto ya nos podria dar una idea de que es lo que estamos queriendo hacer.

Debido a esto es que los patterns cobraron una gran importancia dentro de la comunidad de sistemas. A continuacion detallo algunos links bastante interesantes como para poder tener como referencia o como para poder introducirse en el tema.

 

• Java .Net Javapedia -  Patterns
• Wiki de patterns
• Hillside.net
• Patterns and Software: Essential Concepts and Terminology

 

Estos son solo algunos de los muchos sites que ahora se dedican a hablar sobre este tema, tambien han aparecido en su momento libros de J2EE patterns, cuando la tecnologia J2EE todavia era muy nueva y muchos de los patrones que aparecian en ese catalogo todavia no podian calificar para entrar en esa categoria, por el hecho de no ser soluciones ampliamente utilizadas, como consecuencia algunos de estos patterns an quedado deprecados porque no resultaron ser tan buenas soluciones como se las vendia.

Mule 1.0 ESB

Esta disponible la version 1.0 de Mule este framework permite conectar componentes a travez de canales heterogeneos.
Esta basado en ESB (Enterprise Service Bus Architecture). Mule maneja la interaccion de los componentes en forma transparente sin importar que estos residan en distntas VM y sin importar el protocol de transporte.

Breve Resumen de las caracteristicas (extraido del sitio)

Key Features

• J2EE 1.4 Enterprise Service Bus (ESB) and Messaging broker
• Pluggable connectivity such as Jms (1.0.2b and 1.1), vm (embedded), jdbc, tcp, udp, multicast, http, servlet, smtp, pop3, file, xmpp.
• Support for asynchronous, synchronous and request-response event processing over any transport.
• Web Services using Axis or Glue.
• Flexible deploment [Topologies] including Client/Server, Peer-to-Peer, ESB and Enterprise Service Network.
• Declarative and Programmatic transaction support including XA support.
• End-to-End support for routing, transport and transformation of events.
• Spring framework Integration. Can be used as the ESB container and Mule can be easily embedded into Spring applications.
• Highly scalable enterprise server using the SEDA processing model.
• REST API to provide technology agnostic and language neutral web based access to Mule Events
• Powerful event routing based on patterns in the popular EIP book.
• Dynamic, declarative, content-based and rule-based routing options.
• Non-Intrusive approach. Any object can be managed by the ESB container.
• Powerful Application Integration framework
• Fully extensible development model

When to use Mule

The common scenario for using Mule -

• Integration projects where two or more existing systems need to communicate with each other.
• Applications that need to be totally decouple from their surrounding environment or where the ability to scale one more components in the system is needed.
• Single VM Applications where the developer wants to future-proof their application against unexpected distribution or scaling requirements. Mule works very well as a single VM application where interaction between components in the system is achieved in memory with no detectable degradation in performance.