Re: [mindfood] Automatización de actualizaciones en Java

[Jose San Leandro <jose.sanleandro@xxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 10 February 2005 18:35, you wrote:
> > Simplemente, quería sondear opiniones y experiencias previas que
> > tengais relacionadas con automatización de despliegues en Java...
>
> Actualmente, el problema de la actualización automática de aplicaciones
> Java (en el lado cliente) está tratando de resolverse mediante el
> JSR-56: Java Network Launching Protocol (JNLP) [1]. De hecho Java Web
> Start, la implementación de referencia de JNLP, forma parte de la
> plataforma J2SE desde la versión 1.4.
>
> JNLP permite el despliegue de aplicaciones Java a través de la Web en el
> lado cliente, que a diferencia de los applets son ejecutadas fuera del
> ámbito del navegador. Una vez desplegadas, las aplicaciones JNLP pueden
> descargar actualizaciones automáticamente.
>
> JNLP está dirigido a permitir el despliegue basado en Web de
> aplicaciones en el lado cliente, típicamente "rich-clients", y a
> facilitar su mantenimiento y actualización.
>
> En este contexto resulta claro que la actualización de las aplicaciones
> desplegadas resulta un problema y la "auto-actualización" es una
> característica muy conveniente. Sin embargo, no acabo de ver la
> necesidad de una actualización automática de despliegues en el lado
> servidor como la que planteas. Al fin y al cabo, se puede realizar un
> redespliegue de la aplicación cada vez que sea necesario. Teniendo en
> cuenta que, como dice Alejandro, el proceso de despliegue suele estar
> totalmente automatizado, ¿cuál es la ventaja de la auto-actualización en
> el servidor de aplicaciones?. Probablemente estoy pasando algo por alto.

Bueno, en mi opinión sí que considero de utilidad la disponibilidad de una 
gestión de actualizaciones en el lado servidor. Difiero con Daniel en la no 
necesidad de controlar las versiones. Más que un gestor de actualizaciones 
"forward-only", sería deseable que tuviera capacidad para tomar decisiones 
del tipo "esta nueva versión no satisface los requisitos mínimos, y por tanto 
es necesario restaurar la última versión estable", proporcionando un entorno 
de ejecución que ofrezca un "equilibrio estable", es decir, un entorno que 
tienda a auto-estabilizarse.
Para ello, los requisitos pueden ser inabordables, ya que, además de definir 
el mecanismo de transición de un DDL al nuevo, es decir, de cómo transformar 
los modelos de la capa de persistencia (cuya transaccionalidad no la ofrece 
el motor de bd por lo general), sería necesario la definición de cuáles son 
esos requisitos mínimos: pruebas funcionales y no funcionales.
En cualquier caso, ese objetivo me parece muy interesante, aunque de elevada 
complejidad. Me temo que habrá que pasar por muchos JSR cuando alguien vea 
una oportunidad de negocio en eso.

> [1] http://jcp.org/en/jsr/detail?id=056
>
>
> Un saludo,
> Rafa
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: mindfood-unsubscribe@xxxxxxxxxxxxxxx
> For additional commands, e-mail: mindfood-help@xxxxxxxxxxxxxxx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFCC7xRCAvt6RF8M0cRAtmIAJ9N9KMSOcRDQSm3pM5v7wQHESDTawCfQKHf
MTvSnQpJ2owXaOSusK0kXfs=
=Dklz
-----END PGP SIGNATURE-----