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:
  • 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.

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

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.