INTRODUCCIÓN
Durante la vConference celebrada en Enero del presente año, en la que se presentó el nuevo producto V7, se hizo especial hincapié en la multiplataforma, presentándola como una de las características claves del nuevo producto. La multiplataforma es la clave del concepto, de la implementación, del diseño, del marketing y en definitiva del éxito de V7.
El presente documento pretende mostrar los elementos clave, tanto tecnológicos como de arquitectura, que dotan a V7 de esta característica esencial y tan esperada: la posibilidad de crear aplicaciones que puedan ser ejecutadas sobre distintas plataformas sin que el desarrollador tenga que emplear ni una sola línea de código en ello.
MULTIPLATAFORMA: ¿DE QUÉ?
Al ser la plataforma Velneo un “conjunto de aplicaciones” diseñadas para “desarrollar y ejecutar otras aplicaciones” el concepto de multiplataforma debe estar adecuadamente definido en todos sus posibles aspectos.
Lo que se va a portar a otros sistemas son los propios ejecutables que conforman la plataforma Velneo V7 (vServer, vClient, vDevelop …). Habrá una serie de versiones de cada uno de estos ejecutables, y cada conjunto de ellos permitirá utilizar las funcionalidades de V7 en una serie de combinaciones de sistema / hardware.
Por su parte las aplicaciones desarrolladas usando V7 son multiplataforma “per se”, ya que podría decirse que realmente son otros (vServer, vClient…) los que interactúan con el sistema y el hardware. Esto, además de conseguir que las aplicaciones desarrolladas con V7 sean multiplataforma, sin que los desarrolladores tengan ni siquiera que pensar en ello, permite que sean ínter operables también de forma transparente; esto quiere decir que el conjunto de archivos que constituyen una aplicación desarrollada con V7 (el equivalente de los antiguos archivos “.map”) es único, pudiendo obtenerse con una cualquiera de las versiones de vDevelop para distintas plataformas, ponerse a servir con vServer en cualquier otra plataforma distinta o igual a la anterior, y accederse con distintos vClients desde todas las plataformas soportadas a la vez.
MULTIPLATAFORMA: ¿CÓMO?
La necesidad de la multiplataforma es inherente a los sistemas de la información desde el propio nacimiento de la informática. Podemos considerar que existen tres grandes aproximaciones a la resolución de esta necesidad:
- a) Programación múltiple: programar y mantener código separado para cada plataforma que se desee soportar. Solución directa, sencilla y de buen rendimiento. Problemas principales: complejidad en el desarrollo (debemos enfrentarnos a las particularidades de todos los sistemas), complejidad del mantenimiento y, sobre todo, pérdida de unicidad del código, ya que inevitablemente irán apareciendo aspectos particulares que en un sistema se resuelven de una manera y en otros de otro, y que a lo largo de las sucesivas versiones irán produciendo código cada vez más distinto entre las distintas plataformas.
- b) Programación virtual: programar para un único entorno hardware / software abstracto: máquina virtual. Nuestro código estará soportado en todas aquellas plataformas que implementen esta máquina virtual. Solución elegante y fácil de mantener e implementar. Problema principal: pérdida muy acusada de rendimiento. A esto se añade el hecho de que los desarrolladores están restringidos al uso exclusivo de los recursos que la máquina virtual pone a su disposición, y a hacerlo con las herramientas, y de la manera, que los desarrolladores de la máquina virtual decidan. El ejemplo clásico de máquina virtual es Java, pero el .NET framework de Microsoft también se acoge a esta filosofía, estando de hecho pensado para poder portar los desarrollos elaborados usando .NET a las diversas plataformas soportadas por Microsoft (x86, 64 bits, equipos con Windows CE, equipos con XP embebed…) sin “casi” cambiar el código.
- c) Programación dividida: separar en programación la funcionalidad que “deseamos” implementar de la que “necesitamos” implementar. La que deseamos implementar, por regla general, no estará atada a ningún hardware ni sistema en concreto y conceptualmente será portable a cualquier sistema. La que necesitamos implementar incluye la interacción con el hardware y con el sistema. Para esta última, imprescindible pero que no es la clave del valor añadido de nuestra aplicación, se buscan soluciones externas de alta garantía y rendimiento que soporten la multiplataforma. Evidentemente la solución escogida afectará a la manera en que implementemos nuestra funcionalidad propia. Se trata de una solución de compromiso inteligente entre las dos anteriores, ya que tiene sus dos ventajas principales (obtenemos aplicaciones finales que interactúan directamente con cada sistema, y externalizamos el problema de la ejecución en otros sistemas y hardware), sin sus dos inconvenientes fundamentales (no se pierde la unicidad del código y no hay merma en el rendimiento).
Esta tercera vía es la que se ha seguido en el desarrollo de V7. El elemento crítico en este tipo de implementación es, por supuesto, la elección de la solución externa para la portabilidad a múltiples plataformas. Tras analizar muchas de las soluciones existentes, tanto a nivel de arquitectura como a nivel de implementación, se ha decidido finalmente utilizar el framework de desarrollo para C++ de QT, perteneciente a la empresa Trolltech, y usada entre otros por HP, IBM, Siemens y la NASA.
MULTIPLATAFORMA: ARQUITECTURA
La arquitectura de desarrollo surgida del uso de QT como framework de trabajo es la siguiente:
El código desarrollado en C++ hace uso intensivo la API de QT, allá donde las aplicaciones clásicas harían uso de frameworks específicos para Windows (como MFC) o Linux (Xt, Motif, Athena…). De esta manera se obtiene un código completo unificado en todas las plataformas soportadas, ya que la API de QT es única para todos ellos, e incluye todo el interfaz gráfico y de comunicación entre procesos. De hecho es la propia API de QT la que vincula en tiempo de diseño las funciones apropiadas de las API de bajo nivel de cada plataforma (API de Win32, Xlib y Carbon). Esto también nos asegura un elevado rendimiento en las aplicaciones desarrolladas con V7, ya que entre nuestro código y la ejecución del mismo por parte del sistema operativo sólo hay una capa intermedia: la API nativa de cada sistema. La arquitecturas tradicionales para conseguir la multiplataforma hacen uso de al menos dos capas intermedias, ya que las APIs que ofrecen no se comunican directamente con las APIs de bajo nivel de cada sistema, sino que lo hacen con uno o varios frameworks de cada sistema (por ejemplo, en lugar de comunicarse con la API nativa de Windows o con Xlib, se comunican previamente con MFC o con Motif).
En cuanto a la arquitectura de ejecución de la plataforma, que es a la que realmente están sujetas las aplicaciones desarrolladas por V7, responde al siguiente esquema, derivado del anterior al tener en cuenta las características especiales de QT en cuanto a disposición del framework como librerías:
Lo que este arquitectura implica es que una vez que tenemos en uso los distintos ejecutables que componen la plataforma V7 para cada sistema, la ejecución de los mismos es directa: el ejecutable de V7, basado en QT, obtenido para cada sistema, interactúa directamente con la API de bajo nivel de dicho sistema, de la misma manera que un ejecutable programado únicamente para ese sistema haría.
El uso de QT es transparente para el usuario de los ejecutables que componen la plataforma V7 (los desarrolladores de V7), y por supuesto para los usuarios finales de las aplicaciones desarrolladas con V7. Sin embargo existen una serie de diferencias estructurales muy importantes que es interesante resaltar. Dos son los aspectos fundamentales, relacionados con la multiplataforma, en que el uso de QT hace diferente a V7 de otras aplicaciones estándar:
Estructura de clases: la API de QT proporciona un conjunto jerárquico de clases de las que se derivan todos los demás objetos y propiedades usados en el desarrollo de V7. Este conjunto es el que limita el propio concepto de multiplataforma: para aquellos elementos no contemplados por ninguna de estas clases el soporte en los distintos sistemas debe ser programado específicamente.
Signals and slots: el mecanismo de comunicación entre procesos típico de las aplicaciones gráficas desarrolladas para entornos Windows (mecanismo de eventos) no es portable a otros sistemas; es por esto motivo que QT implementa un sistema propio denominado “Signals and slots”. QT se ocupa de la implementación a bajo nivel de este modo de comunicación dentro de cada plataforma soportada.
MULTIPLATAFORMA: LAS EXCEPCIONES
Las limitaciones comentadas en el uso de la jerarquía de clases propia de QT se traducen en la posibilidad de que ciertas características, para las cuales QT no brinda soporte, puedan estar soportadas desde Velneo en algunas plataformas y en otras no. Por ejemplo, el acceso al puerto serie no está soportado por QT. La tecnología Velneo implementa, en la V7, el acceso al puerto serie bajo sistemas en plataformas Windows x86; es muy posible que también para sistemas UNIX POSIX-compatibles (Linux, IRIX, AIX…) y para sistemas MacOS X (tanto Power PC como Intel) se ofrezca este soporte para acceder al puerto serie, aunque aún no está decidido si en la V7 o en alguna revisión posterior.
Aquellas limitaciones de QT en la portabilidad a otros sistemas / arquitecturas que la propia tecnología Velneo decida no solucionar en sus versiones comerciales, podrían ser resueltas mediante el uso de plugins o de otros componentes externos desarrollados por los propios usuarios.
MULTIPLATAFORMA : ¿DÓNDE ?
En cuanto a los sistemas soportados estos, lógicamente, estarán definidos, en primera instancia, por aquellos que sean soportados por QT en cada momento.
Plataformas soportadas hoy en día, con las limitaciones mencionadas:
- i)Windows: las diferentes versiones de Windows, incluyendo Windows Vista y Windows para 64 bits.
- ii) Linux estándar como binario (se paquetizará sólo para las principales distribuciones: Debian, Red Hat, Suse…)
- iii) Múltiples Unix: FreeBSD, Solaris / SUN, AIX, HP-UX, IRIX…
- iv) Mac tanto sobre Power PC como sobre Intel.
La lista actualizada de plataformas soportadas se puede seguir en: http://www.trolltech.com/developer/platforms/index.html
Etiquetas: arquitectura, multiplataforma
- Valorar esta entrada
(Sin votos) - Comentarios (21)
- Comentar
- Imprimir
Por ACU2496 #
Bastante denso, pero fácil de seguir.
Mucha información, pero bien estructurada.
Por ADE #
Información completa y fácil de asimilar
Por CSA17256 #
Perfectamente descriptivo en todos sus aspectos. Deja clarísimo en qué consiste, cómo se realiza y cuáles son sus límites. Sólo queda verlo…
Por victor #
Quizas demasiado completo, eso si da mucha información de como trbaja la multiplataforma y que plataformas soporta.
Por EUR21539 #
Algunas dudas:
* Imagino que, en cada revisión de las herramientas V7, habrá una lista de sistemas (y versiones!) soportadas, dependientes de la capacidad de la versión concreta de las librerías QT utilizadas.
* Se ha hablado de las diferentes versiones de Windows… ¿También Windows para Power PC? ¿Seguirá habiendo problemas, por ejemplo, con WinXP y los sockets, o al trabajar contra el API nativo desaparecerán?
* Se habló de “Signal and slots”, pero no se dieron muchos detalles, sobre todo de las diferencias que nos podremos encontrar a los que hemos trabajado con los típicos eventos Windows en otras herramientas. Imagino que hayan tratado de emular, con su propia tecnología, los eventos Windows, pero faltan detalles (que quizá no sean propios de este documento, sino de otros).
Comparado con los documentos anteriores, es mucho más denso, pero creo que se entiende bien, teniendo en cuenta que se ampliará la información en posteriores documentos.
Por CAR13924 #
Por AGU3991 #
Denso, para leerlo dos o tres veces y luego pensárselo. Interesante y nos meteis cada vez más ganas de ver un ejemplo, o algo, no sé , empezar a trastear.
Por CESARFI #
Por TIM21812 #
Perfecto.
Por INT1442 #
Para la relectura obligatoria. Un poco denso.
Por CIB21863 #
¿Podremos probar algo en estas fiestas?
Por EFE21852 #
Completo, estructurado y comprensible. Muy buena exposición.
Un saludo,
Fran.
Por LUI19615 #
Una buena explicacion del problema de la multiplataforma y de como se soluciona.
Por JES12 #
Deja claro donde estan las bondades y donde los límites. Aparentemente para aplicaciones que no requieran trabajos a nivel de hardware parece no presentar ninguna complicación para seguir disfrutando de la programacion en Velazquez.
Por RAMIRO #
Por JOS1768 #
Por SEC21999 #
Perfecto y con la profundidad justa.
Por DIN16843 #
Me parece una buena y amplia explicación del tratamiento de la multiplataforma.
Por malvarez #
Hola; voy a tratar de puntualizar un poco más los distintos
temas que se han planteado a propósito de este documento:
Lista de sistemas y versiones soportadas: correcto; en la URL http://www.trolltech.com/developer/platforms/index.html (que
se menciona en el documento) se indican las plataformas oficialmente
soportadas en cada momento, con sus limitaciones, caso de haberlas; es
posible que V7 y sus sucesivas versiones se puedan ejecutar sobre alguna
más, no incluida en la lista, pero las oficiales, y sobre las que se dará
soporte, son las indicadas en esta lista, salvo indicación expresa por
parte del equipo de Velneo.
1997 cesó oficialmente el soporte de Microsoft a chipset basados en Power
PC. La última versión de un sistema operativo de Microsoft que corría
sobre Power PC era Microsoft Windows NT 4.0 Este sistema operativo en su
versión x86, está soportado por V7, pero desconocemos si los cambios en el
núcleo de NT para portarlo a Power PC afectan a nuestra plataforma o no, y
tampoco está previsto que se pruebe, por lo que en principio la respuesta
es que no está soportado.
al usar el API nativo: cualquier problema que se pueda derivar del uso de
las MFCs en Windows desaparece, ya que las MFCs no se usan (de hecho en el
producto anterior, Velazquez Visual, tampoco se usaban al 100 %); sin
embargo los problemas a qué se hace referencia (sockets) no son de las
MFCs, sino del propio Kernel y en concreto de la capa hall, con lo cual en
principio persistirían. En realidad no se trata de un problema, sino de
una manera especial de hacer las cosas por parte de Windows XP y 2003
Server que choca frontalmente con el manejo que Velazquez Visual hacía de
los recursos de red. V7 enfrenta estos problemas de una manera
completamente distinta, aportando un nuevo subsistema de acceso a recursos
TCP/IP, con lo cual el problema concreto de los sockets desaparecerá, pero
no gracias al uso del API nativo del sistema, sino gracias a la nueva
implementación del acceso a red por parte de V7.
aplicaciones con interfaze gráfico de usuario (GUI) responden al modelo de
programación conocido como “event-driven”, frente a las
aplicaciones clásicas que seguían el modo de procesamiento secuencial o de
lotes (batch). QT es un framework para desarrollo de aplicaciones GUI, y
por tanto debe aportar una solución para implementar este modelo
“event-driven”, o sea, una solución para comunicación entre los
eventos originados por procesos, por el sistema o por el propio usuario y
los objetos y procesos que deban responder a dichos eventos. La solución
de QT se denomina “Signals and Slots” y difiere radicalmente, en
su implementación, de la usada, por ejemplo, en programación MFC. Al
programador de Velneo esta implementación le resulta aún mucho más lejana
y sobre todo le resulta absolutamente transparente, ya que para establecer
qué es lo que va a ocurrir cuando, por ejemplo, un usuario de sus
aplicaciones pulse sobre un botón determinado de un formulario concreto
(evento click asociado a objeto botón), lo único que va a tener que hacer
es asignar a la propiedad concreta, de ese botón en ese formulario, el
proceso u objeto a invocar de entre los disponibles. De cualquier forma
para el desarrollador de Velneo interesado, y con conocimientos C++, hay
información más detallada en las siguientes URLs:
http://doc.trolltech.com/3.3/signalsandslots.html
http://doc.trolltech.com/3.3/eventsandfilters.html
Por EUR21539 #
Por antonio #