Granite Data Services 1.0.0

Acaba de aparecer Granite Data Services 1.0.0. Desde la decisión de Adobe de ofrecer BlazeDS como software Open Source, los responsables de GraniteDS se volcaron en tener una versión final 1.0 lista para finales de Enero y parece que lo han conseguido. Puedes descargarlo desde el siguiente enlace.

Aquí tenéis una lista de las características de dicha versión:

  • Data Push (Gravity): this new feature is implemented as AMF3 data sent over HTTP (Comet, freely based on the Bayeux protocol).
  • Spring integration is now complete with full support of Acegi security.
  • Seam integration is new and experimental feature in GDS 1.0. A sample application is available.
  • Guice/Warp integration is new and experimental feature in GDS 1.0. A sample application is also available.
  • Gas3 (the ActionScript3 code generator) gives better performance and brings support for Java Enum types and all kind of Ejb3.
  • Flex3 beta3 compatibility: GDS 1.0 is fully compatible with Flex3 beta3.

Puedes ver la documentación aquí.

La competencia actual entre BlazeDS y GraniteDS es muy buena para la evolución de ambos proyectos. La opción de Adobe está basada en una parte del producto oficial de Adobe (Live Cycle Data Services) mientras que Granite ofrece otras posibilidades como integración con Acegi, Spring, o un generador de VOs.

5 Comentarios

  1. Roy

    Carlos,

    ¿sabes dónde puedo encontrar documentación para la integración de Gravity-Hibernate-Flex ? He trabajado un buen tiempo con Hibernate (integrado con JSF/JSP) y estoy explorando Flex para un nuevo proyecto no menor!

    Como todo el mundo, tengo problema con LazyInitializationException (es ridículo pensar en la opción lazy-false)… y no he encontrado soluciones adecuadas y robustas con BlazeDS ni LiveCycle DS.

    Entiendo que Gravity tiene este tema resuelto… pero en la propia documentación de Gravity no encuentro mucho de su integración con hibernate.

    Desde ya te agradezco por la información!

  2. Carlos Rovira

    Hola Roy,

    Gravity no tiene resuelto este tema. Granite tiene un sistema basado en manejar la serialización y deserialización de los VO hasta el cliente con los externalizers. Pero este tema no tiene que ver con Gravity. De hecho parece que gravity no termina de estar del todo maduro.

    Por otra parte, no es tan ridículo el desestimar el uso de lazy en arquitecturas RIA. Ten en cuenta que el manejo de las entidades lo estás haciendo en remoto desde cliente y tienes un montón de posibilidades. En arquitecturas tradicionales, el manejo de lazy estaba más acoplado a la capa del middleware y cobraba mayor sentido.

    Quizá este sea uno de esos casos en los que tenemos que replantearnos el uso y metodos tradicionales y ver si tienen sentido en las nuevas arquitecturas RIA.

    Sea como sea, todavía queda encontrar una solución “oficial” y que los distintos productos (BlazeDS, GraniteDS, LCDS, etc…) la implementen…

  3. Roy

    Gracias Carlos por tu respuesta…

    El error fue mío: escribí “gravity” cuando estaba pensando en Granite! Tienes algo de Granite, externalizers e Hibernate?

    > “Por otra parte, no es tan ridículo el desestimar el uso de lazy en arquitecturas RIA….”

    No sé si estamos hablando de lo mismo, pero yo pienso que el uso de LAZY es fundamental (lazy=true) y mi problema (como el de todos) tiene que ver con no correr el riesgo de cargar la base entera con un simple “FROM Algo” (lazy=false), cuando yo sólo necesito una lista de “Algo”…

    > “Quizá este sea uno de esos casos en los que tenemos que replantearnos el uso y metodos tradicionales y ver si tienen sentido en las nuevas arquitecturas RIA.”

    Estoy contigo en esto… la arquitectura RIA no se compara con las tradicionales (típicos Request-Response) y corremos el riesgo de intentar seguir trabajando de la misma forma!

    >”Sea como sea, todavía queda encontrar una solución “oficial” y que los distintos productos (BlazeDS, GraniteDS, LCDS, etc…) la implementen…”

    Ojalá que pronto! Bye…

  4. Carlos Rovira

    Efectivamente, hablamos de lo mismo. Hay un debate abierto actualmente acerca de ese tipo de automatismo desde el cliente. De hecho el “cargar la base entera” no tiene por que darse ya que la mayoría de motores te permiten configurar el numero de niveles que quieres traerte. Por tanto puedes hacer que el motor de persistencia solo traiga un nivel y el resto de extracciones se realicen en base a una lógica controlada de tu aplicación. Como te decía, los automatismos en este aspecto son bastante complejos y hasta cierto punto un poco naturales ya que estamos haciendo un lazy remoto que puede llevarnos a inconsistencias en la aplicación que no se daban cuando esa logica estaba entre el middleware y la base de datos.

  5. Franck Wolff

    Hi,

    Just to let you know that GraniteDS 2.0.0.GA (final) was released. Granite Data Services is a free, LGPL’d, alternative to Adobe LiveCycle Data Services for Java Entreprise platforms.

    This final 2.0 release is a major update, bugfix, and repackaging of all GraniteDS technologies. It also introduces new persistence engines support (OpenJPA and DataNucleus/JPOX), new application servers support (GlassFish v3, WebLogic 10, Google App Engine, and OSGi) and new specification support (Servlet 3.0 preview).

    Regards,
    Franck.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Acerca de Made In Flex

Made In Flex es una comunidad de desarrolladores de Apache Flex creada en 2006.

Apache Flex, anteriormente conocido como Adobe Flex, es un SDK (kit de desarrollo de software) para crear aplicaciones enriquecidas - multiplataforma basadas en Adobe Flash donado por Adobe a la fundación Apache in 2011 y promocionado a proyecto de primer nivel en Diciembre de 2012.

Actualmente estamos cambiando muchos aspectos del sitio web para ofrecer un sitio útil para toda la comunidad que tenga en cuenta las necesidades actuales.

Últimas Fotos

Instalador de Apache Flex

Entrar o Registrase