Canoo anuncia OpenDolphin 0.7
Abraham
Canoo ha anunciado OpenDolphin 0.7; OpenDolphin es un proyecto que pretende conectar las tecnologías de escritorio de Java (Swing y JavaFX) con los servidores de aplicaciones Java EE de un modo sencillo para el programador. A diferencia de la mayor parte de las aplicaciones típicas en las que un cliente de escritorio accede a un servidor de aplicaciones, con OpenDolphin el servidor no tiene por qué actuar como un mero repositorio de datos sobre el cual realizamos consultas o hacemos actualizaciones, sino que permite que la lógica de la aplicación resida en el servidor.
En una aplicación con OpenDolphin el servidor se encarga de gestionar los datos y además contiene la lógica del negocio. El cliente se encarga sólo de la presentación. Y tanto el servidor como el cliente comparten un "Modelo de presentación", que permite al servidor manipular qué es lo que hay que presentar al usuario, y al cliente le sirve de base para construir la vista. Pero no se trata de un modelo de la aplicación, sino de un modelo puramente orientado a la presentación de datos. Esta imagen describe la arquitectura de OpenDolphin:
Aunque ahora mismo la versión del proyecto disponible es la 0.7, se trata de una versión que se encuentra en un estado de desarrollo bastante avanzado ya que Canoo pretende anunciar la versión 1.0 de OpenDolphin a finales de este mes. Aquí os dejo un video demo de la funcionalidad de este proyecto:
Reader Comments (9)
Usted disculpe, compañero, pero hasta donde yo sé, cuando un GUI habla con un Servidor de Aplicaciones, la lógica de negocio debe estar en él, no en la capa de presentación (para eso (entre otras cosas) están los EJB). De hecho, en los casos de HTML, la lógica de negocio siempre está en el Servidor de Aplicaciones. Hay aplicaciones que tienen más de un interface de usuario (HTML y Swing p.ej.) y en estos casos está claro que no vamos a escribir dos veces la lógica de negocio.
Otra cosa es que Dolphin haga esto más simple para aplicaciones Swing y FX, que no lo sé, aunque personalmente encuentro bastante simple obtener una referencia a un EJB alojado en un Servidor de Aplicaciones y hacer una llamada a alguno de sus métodos...
En fin, tendré que estudiar Dolphin a ver qué ofrece.
En cualquier caso, muchas gracias por la información.
En la práctica yo creo que una aplicación de escritorio no es raro que alguna parte de la lógica de la aplicación termine en el cliente. Por ejemplo, al mejor se aplica algún algoritmo de minería de datos sobre los datos, o se aplica algún filtro para que se dejen de visualizar ciertos datos, filtro del cual el servidor "no sabe nada". Lo mismo pasa en las aplicaciones AJAX ricas. Yo entiendo que aquí el propósito es que toda la lógica esté en el servidor, incluido cosas como aplicar filtros a los datos para, por ejemplo, ver sólo los clientes cuyo apellido empieza por A.
No es lógica de negocios, es la lógica de presentación (lo que en la imagen ponen como "PM" o "shared presentation model").
Dicho de otra manera para todo lo relacionado a carga predictiva, autocompletado y recarga. en lugar de jalar de dos o tres EJB (a consumir directamente desde swing o por WS / AJAX en web) y terminar de formatear y ajustar en local (ya sea en java / swing o en javascript /HTML) esto queda del lado del servidor.
Personalmente, no soy muy amante de este "patrón de diseño" ya que se sobrecarga al servidor con tareas que (por naturaleza) son de "cara al usuario" mientras que se desperdicia la capacidad de procesamiento de sus equipos.
Pero como se suele decir,
Para gustos colores.
PD: El nombre "Dolphin" me suena de algo, creo que es marca registrada .
¿Abría que avisarle a esta gente, antes que les llegue el primer burofax ?.
:D
Dolphin es el nombre de uno de dos navegadores web más populares para Android
Interesante debate
estoy en desacuerdo la reglas de negocio deben estar siempre en un servidor a parte centralizado pero la lógica de negocio debe estar en los clientes
Es horrible mandar toda la información al servidor cada ves que se quiera realizar un calculo en lo personal me parece tonto y dogmático. Las computadores actuales incluso las mas baratas ya hace mucho tiempo que tiene el poder no ser un mero terminal bruto
Los terminales brutos me enferman yo quiero mega aplicaciones en el cliente donde yo pueda hacer todo clase de transformaciones visualizaciones y lo que sea en mi maquina y tal ves mandarlo al servidor cuando se me de la gana
Estamos en el 2013 las computadores son super potentes mucho mas si se lo comparan con las computadoras antiguas con las que los dogmáticos aun siguen pensando que usamos
Estoy aun mas de acuerdo que toda la shared presentación (como ellos lo llaman) debe estar en el cliente y me parece un salvajismo estar comunicándose con el servidor a cada rato para hacer cálculos tontos que el framework me pueda hacer automáticamente en el cliente
Hola Luis, creo que es interesante lo que planteas, quizá los antiguos dogmas (basados en antiguos parámetros) deben adaptarse a los cambios (con nuevos parámetros) y formar nuevos dogmas.
Un saludo
@luis
"yo pueda hacer todo clase de transformaciones visualizaciones y lo que sea en mi maquina y tal vez mandarlo al servidor cuando se me de la gana."
Esto también tiene su pega, desde la perspectiva de los datos ya que lo que estés manipulando en local puede haber quedado desactualizado.
Para mí lo mejor es mandar los dogmas al diablo, concentrarme en los requerimientos, el contexto de ejecución (si esto es internet, intranet, LAN o WAN, offline, semi offline, con redes de baja latencia, alta latencia) y que funcionalidad es crítica para el usuario.
Solo entonces veo que patrón empleo y para que parte del sistema.
Las navajas suizas, no deberían existir en ninguna caja de herramientas.
Aun así,
Para gustos colores.
Hiall,
my Spanish is not good enough for the discussion but as far as I understood, there is a debate whether application logic on the server is useful.
There are multiple considerations to this.
First, the dolphin approach enforces a clear separation of concerns. Speaking in MVC terms, View and Controller are strictly separated. At compile time, they are not even on the same classpath! This separation ensures the ability to later migrate to other widget toolkits or upgrade to newer version at minimal costs, fully protecting your investment in application logic.
Second, the clear separation allows dolphin to enforce a foolproof thread handling. All UI code runs in the UI thread, all controller code runs outside. You cannot do it wrong!
Third, application logic is best located near the data source. You only transfer, what should be visible, which - given any resolution - cannot be much. Minimal data transfer in an asynchronous fashion is key to responsive user interfaces.
thanks for having me
Dierk