Revista Solo Programadores #122

S D O I I T U A L R G C

6ª ENTREGA DEL COLECCIONABLE

N I D C

AÑO O XI. XI. 2. 2.ªª ÉPOC ÉPOCA A • Nº 122 • Precio: 6 € (Españ (España) a) (IVA inclu incluido) ido) • AÑ

UNA PUBLICACIÓN DE:

ROFESI ESIONA ONALES LES S. L . REVISTAS PROF

Y ADEMÁS… ACTUALIDAD Windows Longhorn: la evolución de .NET MIDDLEWARE XAML, un cambio radical en la programación de IGUs Eclipse Visual Editor REDES Los CMS Open Source y el API de Portlets Programa un filtro en tu aplicación web DISEÑO Borland y el ciclo de vida: la diferencia entre el éxito y el fracaso Construye aplicacion aplicaciones es multiplataforma con C++ y ACE CANAL PANDA Nuevos peligros para la seguridad corporativa 00122

Noticias, javaHispano, Preguntas y Respuestas

8

413042 303299

EDITORIAL Un mercado prometedor Número 122 - Marzo 2005 Edita: REVISTAS PROFESIONALES S.L. [email protected] C/ Valentin Beato 42, 3ª. 28037 - Madrid. http://www.revistasprofesionales.com http://digital.revistasprofesionales.com Editor Agustín Buelta •••••••••••••••••••••••••••••••••• Coordinación Técnica-Redac Técnica-Redacción ción Carlos Laparra •••••••••••••••••••••••••••••••••• Maquetación Raúl Clavijo •••••••••••••••••••••••••••••••••• Asesoría de Publicidad Felipe Ribagorda Tel.: 91 304 87 64 Barcelona C/ Rocafort, 241/243, 5º 1ª Mariano Sánchez Tel.: 93 322 12 38 •••••••••••••••••••••••••••••••••• Suscripciones Tel: 91 304 87 64

Pocas cosas reflejan tan bien el progreso de la tecnología como los teléfonos móviles. móviles . En muy pocos años, han pasado de ser simples teléfonos a auténticas plataformas de ocio. Curiosamente, continuamos llamando “teléfono móvil” a un dispositivo que, ciertamente, algún día lo fue, pero no cabe duda de que hoy ese término ha quedado obsoleto. Los fabricantes de estos “teléfonos” inundan el mercado con nuevos modelos, las operadoras de telecomunicaciones nos abruman con agresivas campañas de publicidad y, todo ello, acaba en un consumo desmesurado de estos servicios. La última tecnología t ecnología que se ha incorporado a los dispositivos dispositi vos móviles es la que puede transformar nuestro terminal en una auténtica consola de videojuegos. Ciertamente, este tipo de productos van destinados a los consumidores más jóvenes. Según se desprende de los estudios realizados por las compañías del sector, 3 de cada 5 ciudadanos europeos de entre 15 y 35 años adquirieron algún contenido o servicio para ser consumido desde su teléfono móvil en el año 2004. De este consumo, los juegos Java para móviles representan el 11%, frente al 29% que representan otro tipo de contenidos, como por ejemplo las imágenes. De hecho, estos datos han sido respaldados por un estudio hecho por la consultora Screen Digest, en el que se afirma que el 80% de los ingresos derivados de los juegos y sus descargas provienen de Japón y Corea. En este sentido, queda claro que América y Europa representan un mercado relativamente virgen, y por lo tanto con muchas posibilidades en el naciente sector de los juegos en teléfonos móviles. Por este motivo hemos creído oportuno mostrar al lector, con un curso completísimo, cómo desarrollar juegos de calidad comercial para una de las plataformas con más cuota de mercado: Nokia.

Fax: 91 327 13 03

••••••••••••••••••••••••••••••••••• Impresión Ideas de Impresión ••••••••••••••••••••••••••••••••••• Distribución Motorpress Ibérica

SUMARIO

ACTUALIDAD 10 Windows

Distribución Mexico DIMSA - Angel Bosch Bosch [email protected] Distribución, números atrasados y suscripciones Renacimiento, 180. Col. San Juan Tlihuaca Azcapotzalco. 02400 México D.F. Distribución Argentina Capital Federal: Distrimachisa Interior: York Agency, Agency, S. A. Tel. (005411) 43 31 50 51 •••••••••••••••••••••••••••••••••• La revista Sólo Programadores no tiene por qué estar de acuerdo con las opiniones escritas por sus colaboradores en los artículos firmados. El editor prohibe expresamente la reproducción total o parcial de los contenidos de la revista sin su autorización escrita.

Depósito legal: M-26827-1994 PRINTED IN SPAIN COPYRIGHT COPYRIG HT 30-02-20 30-02-2005 05 P.V.P. 6,00 Euros Precio en Canarias, Ceuta y Melilla: 6,15 Euros

Asociación Española de Editoriales de Publicaciones Periódicas

Longhorn: La evolución Longhorn: evolución de .NET (I)

DISPOSITIVOS MÓVILES 16 Juegos

de calidad comercial en J2ME (I)

MIDDLEWARE 24 XAML

(II) 36 Desarrollo visual de IGUs Java

REDES 42 Sistemas

de Gestión de Contenidos (y II) 48 Servlets Filters (I)

DISEÑO 54 La

diferencia entre el éxito y el fracaso 58 Diseño multiplataforma multiplataforma para aplicacione aplicaciones s C++ (I) Y además… 04 Noticias 06 javaHispano: javaHispano: NetBeans

4.0, db4objects, db4objects, APIs Java Java y más 08 Canal Panda: Los sistemas móviles, un peligro para la seguridad corporativa 32 Contenido del CD-ROM 64 Preguntas y respuestas

EDITORIAL Un mercado prometedor Número 122 - Marzo 2005 Edita: REVISTAS PROFESIONALES S.L. [email protected] C/ Valentin Beato 42, 3ª. 28037 - Madrid. http://www.revistasprofesionales.com http://digital.revistasprofesionales.com Editor Agustín Buelta •••••••••••••••••••••••••••••••••• Coordinación Técnica-Redac Técnica-Redacción ción Carlos Laparra •••••••••••••••••••••••••••••••••• Maquetación Raúl Clavijo •••••••••••••••••••••••••••••••••• Asesoría de Publicidad Felipe Ribagorda Tel.: 91 304 87 64 Barcelona C/ Rocafort, 241/243, 5º 1ª Mariano Sánchez Tel.: 93 322 12 38 •••••••••••••••••••••••••••••••••• Suscripciones Tel: 91 304 87 64

Pocas cosas reflejan tan bien el progreso de la tecnología como los teléfonos móviles. móviles . En muy pocos años, han pasado de ser simples teléfonos a auténticas plataformas de ocio. Curiosamente, continuamos llamando “teléfono móvil” a un dispositivo que, ciertamente, algún día lo fue, pero no cabe duda de que hoy ese término ha quedado obsoleto. Los fabricantes de estos “teléfonos” inundan el mercado con nuevos modelos, las operadoras de telecomunicaciones nos abruman con agresivas campañas de publicidad y, todo ello, acaba en un consumo desmesurado de estos servicios. La última tecnología t ecnología que se ha incorporado a los dispositivos dispositi vos móviles es la que puede transformar nuestro terminal en una auténtica consola de videojuegos. Ciertamente, este tipo de productos van destinados a los consumidores más jóvenes. Según se desprende de los estudios realizados por las compañías del sector, 3 de cada 5 ciudadanos europeos de entre 15 y 35 años adquirieron algún contenido o servicio para ser consumido desde su teléfono móvil en el año 2004. De este consumo, los juegos Java para móviles representan el 11%, frente al 29% que representan otro tipo de contenidos, como por ejemplo las imágenes. De hecho, estos datos han sido respaldados por un estudio hecho por la consultora Screen Digest, en el que se afirma que el 80% de los ingresos derivados de los juegos y sus descargas provienen de Japón y Corea. En este sentido, queda claro que América y Europa representan un mercado relativamente virgen, y por lo tanto con muchas posibilidades en el naciente sector de los juegos en teléfonos móviles. Por este motivo hemos creído oportuno mostrar al lector, con un curso completísimo, cómo desarrollar juegos de calidad comercial para una de las plataformas con más cuota de mercado: Nokia.

Fax: 91 327 13 03

••••••••••••••••••••••••••••••••••• Impresión Ideas de Impresión ••••••••••••••••••••••••••••••••••• Distribución Motorpress Ibérica

SUMARIO

ACTUALIDAD 10 Windows

Distribución Mexico DIMSA - Angel Bosch Bosch [email protected] Distribución, números atrasados y suscripciones Renacimiento, 180. Col. San Juan Tlihuaca Azcapotzalco. 02400 México D.F. Distribución Argentina Capital Federal: Distrimachisa Interior: York Agency, Agency, S. A. Tel. (005411) 43 31 50 51 •••••••••••••••••••••••••••••••••• La revista Sólo Programadores no tiene por qué estar de acuerdo con las opiniones escritas por sus colaboradores en los artículos firmados. El editor prohibe expresamente la reproducción total o parcial de los contenidos de la revista sin su autorización escrita.

Depósito legal: M-26827-1994 PRINTED IN SPAIN COPYRIGHT COPYRIG HT 30-02-20 30-02-2005 05 P.V.P. 6,00 Euros Precio en Canarias, Ceuta y Melilla: 6,15 Euros

Asociación Española de Editoriales de Publicaciones Periódicas

Longhorn: La evolución Longhorn: evolución de .NET (I)

DISPOSITIVOS MÓVILES 16 Juegos

de calidad comercial en J2ME (I)

MIDDLEWARE 24 XAML

(II) 36 Desarrollo visual de IGUs Java

REDES 42 Sistemas

de Gestión de Contenidos (y II) 48 Servlets Filters (I)

DISEÑO 54 La

diferencia entre el éxito y el fracaso 58 Diseño multiplataforma multiplataforma para aplicacione aplicaciones s C++ (I) Y además… 04 Noticias 06 javaHispano: javaHispano: NetBeans

4.0, db4objects, db4objects, APIs Java Java y más 08 Canal Panda: Los sistemas móviles, un peligro para la seguridad corporativa 32 Contenido del CD-ROM 64 Preguntas y respuestas

NOTICIAS

MICROSOFT

Microsoft entra en la lucha contra el software espía

Microsoft ha anunciado recientemente la adquisición de GIANT Company Software, el proveedor de algunos de los mejores productos diseñados para impedir la instalación de spyware en los equipos, y la empresa que ha desarrollado diversas e innovadoras soluciones para garantizar la seguridad en Internet. Pero… ¿Qué es el spyware? ¿Por qué luchar contra él? El creciente interés (por parte de usuarios maliciosos y de compañías de ética dudosa) en conocer los hábitos de navegación de los internautas ha propiciado la proliferación del spyware. Se denomina spyware (o programa espía) a las aplicaciones diseñadas para conseguir datos de los usuarios sin que éstos se percaten ni de su presencia, ni de las acciones que llevan a cabo. Suelen llegar a los ordenadores a través de programas freeware, shareware, o demos de cualquier tipo que aparentemente no tienen ninguna peligrosidad. Que una descarga contenga o no spyware no depende tanto de si el archivo a descargar es fiable o no, sino de dónde se descarga. De hecho, puede darse el caso de que aplicaciones conocidas y libres de toda sospecha hayan sido manipuladas para contener

un programa espía. Esta manera de ocultarse en el interior de programas no sospechosos posibilita que se instalen en el PC, al mismo tiempo que el usuario instala la aplicación que acaba de descargar. Un spyware oculto en un sistema puede permitir elaborar el perfil de un usuario mostrando, por ejemplo, sus preferencias en cuanto a tipo de páginas web que visita, tiempo que navega, su equipo de fútbol favorito, etc. Estos y otros datos permiten identificar a cada internauta, sobre todo con propósitos comerciales. Microsoft, para poner solución a esta problemática, utilizará la tecnología y propiedad intelectual que aporta GIANT para proporcionar a los usuarios del sistema operativo Microsoft Windows unas nuevas herramientas para proteger sus sistemas frente a las amenazas que representan el spyware y otro software malicioso. Microsoft va a poner a disposición de sus clientes en los próximos días la versión beta de una herramienta basada en el AntiSpyware de GIANT para eliminar, proteger y detectar spyware. Esta próxima versión beta analizará el PC del usuario para localizar cualquier spyware u otro software malicioso, y eliminarlos posteriormente. La solución será configurable para bloquear la instalación en el sistema de spyware conocido o cualquier otro software malicioso. Esta herramienta estará disponible para el sistema operativo Microsoft Windows 2000 y versiones posteriores.

BEA SYSTEMS

BEA habilita la descarga de WebLogic 9.0 BEA Systems desveló hace unas semanas la última versión de BEA WebLogic Server 9.0. Su nombre… “Diablo”. Mejorada con importantes características, Diablo es la piedra angular de la recién lanzada solución BEA WebLogic Platform 9.0, la última generación de componentes de software integrado que está diseñada para conectar sistemas dispares y hacer rodar las aplicaciones sobre las que están construidos los negocios de las grandes compañías. Lo que hace único a Diablo es su capaSUN MICROSYSTEMS

Bankinter innova con J2ME Java continúa en su proceso de consolidación como la plataforma número uno para servicios inalámbricos de datos. Según fuentes de Sun, ya existen unos 300 modelos distintos de teléfonos móviles con Java integrado, fabricados por firmas como LG, Motorola, Nokia, Samsung, Sharp, Siemens o Sony Ericsson. Sun calcula que el 60 por ciento de todos los teléfonos móviles que se comercializan a escala global ya llevan la tecnología Java integrada. Asimismo, más de 90 operadores de comunicaciones móviles (entre los que figuran Telefónica Móviles y Vodafone) han conseguido incrementar su ARPU (ingresos medios por usuario) gracias a la implantaSOLO PROGRAMADORES nº 122

4

cidad para ayudar a las compañías a desplegar rápidamente un alto volumen de aplicaciones bajo Arquitecturas Orientadas a Servicios (SOA) con el mínimo impacto en su negocio. En línea con la tradicional trayectoria de WebLogic, Diablo soporta los últimos estándares de la industria como J2EE 1.4 y los últimos estándares de servicios web, ayudando a los desarrolladores a crear de forma rápida aplicaciones interoperables y portátiles. Diablo está disponible para su descarga en la dirección http://www.bea.com/diablo. ción de la tecnología Java. Actualmente, existe una gran cantidad de aplicaciones móviles basadas en Java disponibles para su descarga, que suponen un mercado valorado en unos 3.000 millones de dólares. Esta cifra podría llegar a 15.000 millones de dólares en 2007-2008, según las previsiones de Sun Microsystems. Prueba del buen rendimiento de Java en los terminarles móviles es el innovador servicio ofrecido recientemente por Bankinter denominado Broker Bankinter y basado enteramente en la plataforma J2ME. El nuevo servicio Broker Bankinter, único y pionero en el mercado español, permite a los usuarios la utilización del teléfono móvil como canal para realizar operaciones bursátiles en tiempo real. En una primera fase, el servicio cubre el área de servicios de broker, que incluye la consulta de mercados de valores a escala nacional e internacional (índices, valoraciones, alertas, etc.) y la gestión de carteras con consultas y ejecución de órdenes de compraventa a través del teclado del teléfono móvil. Sun Microsystems también ha aportado a este innovador proyecto los servicios de consultoría, la dirección del proyecto y el desarrollo de todas las aplicaciones J2ME, aspecto, este último, que se ha realizado siguiendo los estándares de la tecnología Java y bajo un exhaustivo control de calidad por parte de Bankinter. http://digital.revistasprofesionales.com

NOTICIAS

IBM

IBM cede 500 patentes a la comunidad Open Source Los desarrolladores de software libre podrán acceder libremente a tecnología IBM gracias a la cesión de 500 patentes por parte de la Compañía. IBM cree que se trata de la mayor cesión de patentes de la historia y representa un giro en el modo en el que la empresa gestiona su propiedad intelectual. La cesión es válida para todo individuo, comunidad o empresa que trabaje en el desarrollo de software o que utilice software de código abierto de acuerdo con la definición actual o futura de la iniciativa Open Source. EMC

Dell, EMC, Intel y Oracle se unen para facilitar el Grid Computing Para aquellos que no se hayan introducido en el concepto de Grid Computing, diremos que para solucionar la “incapacidad” de un superordenador a la hora de resolver un problema de alto nivel de computación, surgió el concepto de Computación Distribuida o Grid Computing, que consiste en dividir el problema en varios fragmentos y hacer así la computación en varios ordenadores organizados organizados y conectados a una infraestructura de telecomunicaciones distribuida. En este sentido, Dell, EMC, Intel y Oracle se han unido para desarrollar conjuntamente el proyecto MegaGrid, una iniciativa para desarrollar un modelo estándar de diseño e implantación de una infraestructura Grid Computing. Las cuatro compañías combinan sus principales tecnologías y recursos técnicos para ofrecer a sus clientes una solución corporativa Grid Computing integrada y completa que

El objetivo de IBM es que esta cesión se convierta en la base de un conjunto de patentes comunes de todo el sector de las tecnologías de la información. Aunque la propiedad intelectual es uno de los pilares de la innovación, los avances tecnológicos dependen a menudo de la capacidad para colaborar y compartir el conocimiento. La nueva política de propiedad intelectual de IBM está dirigida tanto a proteger los derechos sobre la invención como a acelerar la expansión de una infraestructura global basada en software de código abierto. Pese a este tipo de iniciativas, IBM sigue siendo, y con diferencia, la compañía con más patentes registradas en la Oficina de Patentes y Marcas de Estados Unidos. Gracias a una inversión en I+D de 5.000 dólares, IBM consiguió en 2004 3.248 patentes. supere las SMP (varias máquinas multiprocesador funcionando con memoria compartida) tradicionales y a menor coste. La fase inicial del proyecto MegaGrid se centra en el diseño, prueba y documentación de las mejores prácticas efectivas de la industria, posteriormente se definen unas infraestructuras Grid Computing efectivas, teniendo en consideración criterios de coste y rendimiento. Cada patrocinador del proyecto MegaGrid invierte en recursos técnicos para desarrollar,, probar y validar las mejores prácticas de Grid Computing: desarrollar  Dell aporta una infraestructura completa de servidores en red compuesta por servidores PowerEdge basados en procesadores Intel.  EMC incorpora una infraestructura completa de almacenamiento en red.  Intel contribuye con su experiencia en la gestión de procesadores y servidores Intel, con herramientas de optimización y otros recursos que facilitan la integración del diseño.  Oracle proporciona su infraestructura de tecnología Oracle 10g y alberga el centro de desarrollo para el proyecto MegaGrid en su Global IT Data Center. La meta del proyecto MegaGrid es permitir a grandes organizaciones de cualquier segmento vertical de la industria obtener ventajas de las soluciones de Grid Computing, permitiendo que éstas puedan ofrecer servicios bajo demanda y, por lo tanto, mejorar así los niveles de servicio.

mas de sobremesa, sistemas operativos, software de gestión, entornos de almacenamiento para misión crítica y aplicaciones para informática en red. Sun y la Universidad Rey Juan Carlos entablan Sun también cederá una licencia con fines didácticos de su software de una alianza tecnológica escritorio Java Desktop System, que podrá ser utilizado tanto por parte El Rector de la Universidad Rey Juan de los estudiantes como por parte del Carlos, Pedro González Trevijano personal docente y de administració administración n Sánchez y el director general de Sun de la entidad educativa. Esta solución Microsystems Ibérica, Adolfo Hernández, incluye el entorno de escritorio comhan firmado un acuerdo tecnológico de pleto, la suite de productividad ofimácolaboración que permite que la tica StarOffice 7, un innovador entorUniversidad use gratuitamente los prono de ventanas, el popular navegador ductos software de Sun para fines Mozilla y un sistema operativo Linux docentes y entornos de investigación. integrado, además de aplicaciones de El software cedido por Sun Microsystems correo electrónico, agenda y mensaa la Universidad Rey Juan Carlos incluye jería instantánea. servidores web y de directorio, servidores Además, como socio tecnológico de de aplicaciones e integración, aplicaciones la universidad, Sun colaborará con la de correo electrónico, calendario y cola- El Rector de la Universidad Rey Juan Carlos, Pedro institución en otros aspectos relaboración, desarrollo de aplicaciones, González Trevijano Sánchez y el director general de cionados con la mejora de la calidad seguridad en red, aplicaciones para siste- Sun Microsystems Ibérica, Adolfo Hernández en un en los estudios de dicha universidad. SUN MICROSYSTEMS

momento de la firma del acuerdo.

http://digital.revistasprofesionales.com

5

SOLO PROGRAMADORES nº 122

JAVAHISPANO

Actualidad Java de la mano de javaHispano eBay abandona Passport Passport, creado por Microsoft, y Liberty Alliance, iniciativa fundada por Sun que cuenta con el respaldado de más de 150 empresas y está soportada por Java, son dos sistemas de identificación globales de la web que pretenden conseguir el “Single Singn On” (SSO); ésto es, que una vez identificado un usuario éste no tenga que volver a introducir un par usuario/clave al entrar en otro portal. eBay fue uno de los primeros adoptantes de la propuesta de Microsoft. Sin embargo los cambios introducidos por la empresa de Redmond en la arquitectura de Passport (probablemente un intento de solucionar los agujeros de seguridad descubiertos recientemente), junto con el abandono de las tecnologías de Microsoft para basar los servicios de eBay en la plataforma J2EE, han llevado al gigante de las subastas a abandonar esta solución. El sistema Passport era una forma opcional no mayoritaria de acceder a eBay, y esta decisión sólo afectará a los usuarios que se identificaban mediante este sistema. eBay no es el primer gran servicio de la red que abandona la propuesta de Microsoft: Monster.com, portal de recursos humanos, también se despidió de Passport a finales del año pasado. Esto, sin duda, hará ganar más peso a la solución competidora de Passport: Liberty Alliance.

La FSF aclara los términos de la licencia LGPL La Free Software Foundation ha aclarado (http://www.gnu.org/licenses/lgpl-java.html) varias dudas acerca del uso de librerías LGPL desde Java. Según la FSF cuando un código no libre se liga con una librería LGPL (y esto ocurre desde el momento que importe cualquiera de sus clases o interfaces) el desarrollo debe permitir que los usuarios hagan reingeniería inversa para depurar problemas derivados del cambio de la versión actual de la librería librería por versiones futuras o modificaciones modificaciones de ésta. El desarrollo propietario no tiene obligación de distribuir el código fuente, ni de dar documentación acerca de él, pero sí de permitir la reingeniería inversa. Habitualmente las licencias comerciales tienen cláusulas que impiden esta práctica, por lo que es posible que actualmente haya proyectos comerciales que violen la licencia LGPL sin saberlo.

NetBeans 4.0 Siguiendo el itinerario previsto ya está disponible la versión 4.0 del IDE NetBeans. Una de las novedades más importantes es que el modelo del proyecto está completamente basado en Apache Ant, pudiendo compilar el proyecto externamente sin necesidad de emplear previamente ninguna opción del tipo “exportar a Ant”. Ant”. El soporte a la refactorización, al JDK 1.5 y al desarrollo de aplicaciones J2ME MIDP 2.0 y CLDC 1.1 son otras novedades interesantes. También hay mejoras en el desarrollo de aplicaciones web, aunque será la versión 4.1 (planeada para abril de este año) la que aportará un mayor cambio cualitativo en este área, ya que incorporará soporte para EJBs, validación de formularios, configuración de servicios y componentes web, así como un asistente para el despliegue de la aplicación. Por último cabe destacar la integración de NetBeans con JFluid, una herramienta de profiling libre desarrollada dentro de proyecto NetBeans. JFluid permite monitorizar el heap y la actividad del Garbage Collector, el consumo de CPU de la aplicación en conjunto o de un determinado fragmento de código y monitorizar la actividad de los Threads.


6


JAVAHISPANO

javaHispano

db4objects disponible bajo licencia libre db4o (http://www.db4o.com/) es una base de datos orientada a dispositivos empotrados con requerimientos de tiempo real. db4o permite almacenar de un modo sencillo y eficiente objetos nativos Java y .NET; sus creadores aseguran que es la primera base de datos del mercado que permite almacenar objetos de ambas plataformas. Recientemente db4o ha pasado a distribuirse bajo una doble licencia, libre y comercial, prueba de la apuesta de la compañía por el Software Libre. A modo de curiosidad, los coches de alta gama de BMW o el tren español AVE emplean esta base de datos, lo cual es una excelente prueba de la validez de esta solución.

Repositorios on-line de APIs Java Recientemente han surgido dos iniciativas que pretenden agrupar en un mismo portal un con junto de APIs Java, creando de este modo un punto de acceso único a todas las APIs recopiladas, y ofreciendo un valor añadido, como herramientas de búsqueda, agregar notas a la documentación, proponer preguntas y respuestas, añadir código de ejemplo… El pionero fue JDocs (http://www.jdocs.com), una iniciativa de javalobby.org. En él se recopilan más de 130 APIs oficiales de diferentes proyectos, como las de los kits de desarrollo de Sun, commons-lang, commons-collections, Eclipse, Lucene, JGoodies… Un poco más tarde apareció JSourcery (http://www.jsourcery.com), que incluye por lo de ahora las APIs de todos los proyectos de Apache, el cliente de Bittorrent Azureus, y la del JDK 1.4.2. El valor añadido de JSourcery sobre JDocs es que al navegar por el API podemos acceder directamente a una versión HTML del código fuente de cada clase, método o constructor.

JLayer, accediendo a MP3 desde Java JLayer es una librería libre 100% Java que permite tanto convertir audio a MP3 como reproducir archivos que se encuentren en el segundo formato. La librería tiene dos versiones; por un lado JLayer, versión destinada a aplicaciones de escritorio de la cual está disponible una versión estable. JLayer ha sido testado con el JDK 5.0, y es muy eficiente. Por otro lado está JLayerME-CDC que, como podemos deducir de su nombre, está orientado al desarrollo de aplicaciones J2ME. Por ahora no hay una versión estable de JLayerME-CDC, aunque la versión actual ya es usable. La licencia es, en ambos casos, LGPL.

JCrawler 1.0

JCrawler es una herramienta para testar aplicaciones web que permite realizar test de estrés. La herramienta se configura indicando un conjunto de URLs de partida así como una carga a generar

sobre a aplicación web, medida en hits por segundo. JCrawler empieza a navegar, partiendo de las URLs base, dirigido por una serie de patrones de navegación típicos de los seres humanos. JCrawler mantiene una carga constante sobre la aplicación, y soporta redirects y cookies; esto, junto con el empleo de patrones de navegación basados en comportamientos humanos, hace los test altamente realistas. Su licencia es CPL, es decir, es libre, y ha sido incluido en el CD-ROM que acompaña a la revista.

Sobre el autor

Abraham Otero ([email protected]) es responsable de calidad y miembro de la junta de javaHispano. http://digital.revistasprofesionales.com

7


CANAL PANDA

Los sistemas móviles, un peligro para la seguridad corporativa FERNANDO DE LA CUADRA

Las ventajas que ofrece el uso de equipos móviles, como ordenadores portátiles o teléfonos de última generación son indiscutibles, sin embargo llevan consigo unos problemas de seguridad que pueden convertirlos en una amenaza para nuestra red corporativa. En los últimos años, el nivel de seguridad de las empresas ha mejorado mucho. Cada vez se vigila más la conexión a Internet, la existencia de herramientas de seguridad en las máquinas instaladas en la red, la formación de los usuarios, etc. Sin embargo, al mismo tiempo que se avanza en este sentido, nos encontramos que la tecnología también lo hace pero en una dirección que puede, sin duda, entrar en conflicto con las políticas de seguridad clásicas: la movilidad. Hoy en día se considera cada vez más la necesidad de que muchos de los empleados en las empresas dispongan de equipos informáticos móviles, desde ordenadores portátiles a teléfonos de última generación. Todos estos equipos están durante muchos días fuera del entorno “seguro” de la oficina, sin que la política de seguridad establecida en la compañía pueda ampararles ante posibles ataques. A un comercial desplazado durante un tiempo fuera de la oficina lo que más suele preocuparle es cómo recibir su correo electrónico en el ordenador conectado a Internet en la habitación del SOLO PROGRAMADORES nº 122

8

hotel. Acostumbrado al entorno de la oficina, los niveles de seguridad quedan, generalmente, en segundo plano. Las consecuencias de su despreocupación pueden ser graves, ya que la ausencia de un firewall en el portátil permite que los hackers puedan hacer del PC un terreno conquistado, y un antivirus sin actualizar puede ser la causa de que el ordenador se convierta en un zombi. Los problemas que pueden plantearse son muchos, ya que en este tipo de ordenadores la información almacenada suele ser estratégica: proyectos, ofertas comerciales, bases de datos de clientes, etc. Se trata de material de gran valor, que no debe caer en manos de la competencia ni en las de un hacker con pocos escrúpulos. A todo esto hay que añadir un elemento más que sin duda debería preocupar a los administradores de las redes corporativas: tarde o temprano ese ordenador volverá a conectarse a la red corporativa, con todo aquello que haya “recogido” de Internet en el tiempo que estuvo ausente. Las herramientas de hacking, los troyanos, el spyware... todo ello podrá ser volcado directamente a la red si no se toman las medidas oportunas. Sin duda existirán herramientas que eviten la propagación de este tipo de códigos en la empresa, pero hemos dejado una puerta abierta a una serie de elementos sin control. Otro problema que suele pasar desapercibido es la conexión de sistemas ajenos a la empresa. Cada vez más servicios se subcontratan dentro de las grandes corporaciones, haciendo que mucho personal externo se conecte a la red con sus ordenadores portátiles para desempeñar sus tareas como si de un empleado más se tratara. Estos ordenadores suelen tener instalados ya algunos sistemas de seguridad, desde antivirus a firewalls, pero... ¿son suficientemente seguros como para que cumplan las políticas de seguridad? Los administradores de red tienen bastantes problemas ya en su trabajo diario como para ir verificando uno a uno los ordenadores de cada uno de los subcontratados, situación que además puede resultar embarazosa ya que las norhttp://digital.revistasprofesionales.com

CANAL PANDA

Los sistemas móviles, un peligro para la seguridad corporativa

mas sobre la intimidad de los ordenadores de los trabajadores pueden ser muy distintas en cada compañía. Todo esto desemboca en la necesidad de un control específico sobre las conexiones de sistemas móviles a la red corporativa. Previo a la posibilidad de que un usuario rompa las políticas de seguridad, debe llevarse un control exhaustivo y automático de la situación de la seguridad de los ordenadores portátiles de personal externo, o de la empresa pero que hayan estado desplazados. Cuando un sistema se conecta a la red corporativa, hay que asegurarse de que el equipo es seguro, entendiendo como seguro que cumple el nivel de seguridad indicado por el administrador de la red. De esta forma, se impide la entrada de malware en la empresa a través de estas conexiones. En función del resultado del

chequeo realizado deberá permitirse o denegarse el acceso, o incluso establecer un nivel de seguridad en el equipo que se adapte a los requerimientos corporativos de seguridad. Sin embargo, en muchas ocasiones la conexión de equipos externos está ya prevista, por lo que se redirige hacia determinados segmentos de red o se establecen automáticamente permisos y restricciones, sin que llegue a producirse un conflicto de intereses entre políticas de seguridad de distintas empresas. Como vemos, la conexión de equipos externos a la red fija de una empresa no está exenta de problemas, y debe controlarse con mucho cuidado. Las herramientas de protección de estos equipos van a convertirse, en un espacio muy corto de tiempo, en un elemento básico a la hora de implementar la política de seguridad empresarial.

Es recomendable comprobar los niveles de seguridad de un equipo ajeno antes de conectarlo a nuestra red

Sobre el autor Fernando de la Cuadra ([email protected]) es editor técnico internacional de Panda Software (http://www.pandasoftware.com).

Seguridad informática para empresas y particulares Autores: Gonzalo Álvarez Marañón, Pedro Pablo

Pérez García Editorial: Mc Graw Hill Páginas: 440 Precio aproximado: 30 Euros ISBN: 84-481-4008-7 Con la colaboración de Panda Software Mientras que la práctica totalidad de libros sobre seguridad informática existentes en el mercado abordan el tema desde un lenguaje técnico, orientado principalmente a administradores de red o programadores, Seguridad informática para empresas y particulares está dirigido al profe-

sional liberal y la PYME. Por eso, haciendo uso de herramientas que vienen suministradas con el propio sistema operativo o que son en su mayoría gratuitas, con esta obra se puede aprender desde cuáles son las medidas de seguridad a implantar para cumplir con las exigencias http://digital.revistasprofesionales.com

legales de la LOPD y la LSSICE hasta cómo detectar una intrusión en el sistema, pasando por temas como el anonimato y la privacidad, la protección de redes y equipos o las auditorías y los análisis forenses. Aunque las publicaciones sobre seguridad son abundantes, el lector encontrará en Seguridad informática para empresas y particulares una obra de nivel intermedio pensada desde el primer momento para su aplicación en empresas medianas y pequeñas que no necesitan complejas arquitecturas de seguridad, pero que no por ello deben descuidarla. Esta obra, escrita en castellano, se adecua perfectamente al entorno de las PYME españolas, cuya realidad conocen los autores. Desde cómo protegerse del malware hasta qué hacer con el spam, todos los problemas cotidianos relacionados con el valor de la información son abordados en este libro cuyo objetivo es que, con muy poco esfuerzo, se pueda alcanzar un nivel de seguridad razonable. 9


ACTUALIDAD

Windows Longhorn: La evolución de .NET (I) MARINO POSADAS (MVP Visual Developer – Visual C#)

Seguro que el lector más curioso se estará preguntando qué novedades traerá consigo la nueva versión de Windows. En esta serie de artículos analizaremos las novedades al respecto, que no son pocas, desde el punto de vista del usuario pero también desde el punto de vista del desarrollador. Introducción El lector, probablemente, ya habrá escuchado rumores sobre una nueva versión del sistema operativo de Microsoft. En realidad, sobre toda una revolución en los sistemas operativos de la compañía de Redmond, que, por primera vez, aborda la construcción de algo tan complejo partiendo desde cero, y con la intención de que sea la continuación natural a sus esfuerzos por conseguir una plataforma administrada (cuyo código ejecutable es supervisado) y segura. Y todo esto, dentro de unos planes tan ambiciosos que, a mediados del año pasado y, con objeto de

El escritorio de Longhorn. SOLO PROGRAMADORES nº 122

10

garantizar su salida al mercado en tiempo y forma, provocaban el anuncio por parte Jim Alchin, Vicepresidente del Grupo de Plataformas de Microsoft, de que una parte del sistema (el subsistema llamado WinFS) no vería la luz en verano de 2006, fecha para la que está prevista la salida oficial, sino de forma parcial (ésto es, lo que afecta únicamente al equipo local) y que (en ese momento) se distribuirá como una beta opcionalmente instalable, que posiblemente estará lista en su versión final a comienzos de 2007. Hablaremos de todo esto, y de cómo se estructura y fundamenta el nuevo sistema (totalmente construido en .NET) y totalmente reescrito, cosa que no sucedía desde Windows 3.0. Y es que, cuando Microsoft abordó la construcción de la plataforma .NET, no se trataba exclusivamente de una nueva forma de construir aplicaciones Windows, sino del abandono del modelo COM/DCOM/COM+ en favor de un nuevo modelo, que debía conllevar, inevitablemente, cambios profundos en todos los sistemas operativos (y en el resto de aplicaciones) que se construyesen a partir de ese momento. Veamos algunos de los porqués de tales cambios.

El porqué de un cambio tan radical La pregunta crucial es: ¿Cuál fue el “leit motiv” que obligó a Microsoft a abandonar un trabajo mantenido desde finales de los 80 por algo totalmente nuevo? Quizá la respuesta se encuentre en la seguridad y (en buena medida) en las nuevas arquitecturas distribuidas (especialmente SOA: Services Oriented Architecture). Pero lo que ahora vemos, no es sino la consecuencia de unos cambios que comenzaron en 1996, cuando Bill Gates decidió dejar la gestión administrativa en manos de Steve Ballmer, y retomar sus orígenes, como arquitecto de software. En ese momento, comienza también la creación (que no el diseño, que había empezado ya) de lo que podía ser una nueva plataforma que compitiese con J2EE, aprendiendo lo bueno de ésta, mejorando rendimiento y productividad, e integrando lo que (ya en ese momento) se preveía como nuevo estándar universal: XML y los servicios web. Como una de las primeras decisiones, se aborda el “fichaje” de Anders Hejlsberg (véase el cuadro http://digital.revistasprofesionales.com

ACTUALIDAD

Windows Longhorn: La evolución de .NET (I)

Anders Hejlsberg Hejlsberg es Distinguished Engineer en Microsoft y pasó 13 años en Borland como Arquitecto Jefe de Plataformas, en los que dirigió (entre otros proyectos notables) la creación de Turbo Pascal y Delphi. En el campo de los lenguajes su último trabajo fue el diseño e implementación del lenguaje C# (junto a Scott Wiltamuth y Peter Golde). “Anders Hejlsberg”). Hejlsberg abandona Borland tras 13 fructíferos años (en los que crea Turbo Pascal y Delphi, entre otros productos estrella) con una promesa de libertad absoluta, la posibilidad de realizar todos los fichajes posteriores que fuese necesario, y la firme voluntad de crear una plataforma nueva que sustituyese a la ya vetusta COM (ActiveX, para los amigos). Pero, además, la nueva plataforma debía de ser estándar. Microsoft quería demostrar que buena parte de las críticas recibidas en el pasado por esta causa, se habían debido a razones comerciales, simplemente, y nunca a razones técnicas o de incapacidad de crear software que cumpliese con determinada normativa. Así, desde el inicio, se implica directamente en la creación del estándar XML. Para ello, incorpora a sus filas a una de las lumbreras mundiales en lenguajes de marcas, el francés Jean Paoli, quien junto a Tim Bray, representando a la línea Netscape-Sun-Oracle y Sperberg-McQueen de la Universidad de Chicago, en representación del mundo académico, conseguían a finales de 1999, la aprobación definitiva de lo que hoy es el nuevo paradigma de la transferencia de información: sustituir las marcas binarias utilizadas hasta el momento, por las marcas (<,>) de texto plano, de forma que todos los ordenadores hablen un mismo lenguaje entre sí, independientemente de la plataforma. De hecho, el sistema común de tipos (Common Type System) de .NET tiene mucho de inspiración en lo que (poco más adelante) se convertiría en el lenguaje de metadatos de XML: XML-Schemas. Con tan buenos fundamentos y algún otro fichaje no menos importante, (aunque quizá menos espectacular) que comentamos más adelante, continúa el diseño de la plataforma y (al tiempo) la creación de un nuevo lenguaje que aprovechará todo lo nuevo que ésta pudiera aportar, dentro de una sintaxis elegante, atractiva y poderosa. De hecho, durante el contencioso contra Sun Microsystems salió a colación un famoso e-mail de Hejlsberg, dirigido a Bill Gates, y otros arquitectos, en el que se comentaba: “ya tenemos casi perfilado el cuerpo de lo que va a ser el nuevo lenguaje. A falta de un nombre mejor, vamos a llamarlo J++”. Y previamente, añadía: “hemos conseguido un adecuado maridaje entre la simplicidad sintáctica de Java y la potencia de http://digital.revistasprofesionales.com

C++”. El lector puede ver este e-mail en http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2133983,00.html. Hasta ese punto, habían sido C/C++ y Java las fuentes de inspiración para la creación de lo que ahora conocemos como C# (por cierto, lo del ‘#’, es debido a que simboliza 4 signos ‘+’, como una continuación del trabajo de Bjarne Stroustrup en el 67. Además, según nos confesaba en una entrevista posterior (la entrevista se realizó en el Tech-Ed de 2001 en Barcelona, y se encuentra publicada en la sección de artículos de http://www.elavefenix.net), otros lenguajes teóricos sirvieron en ocasiones de fundamento, como es el caso de Haskell u Oberon).

Los delegados y la seguridad Pero, no nos desviemos de nuestro camino hacia Longhorn. Antes de poder crear algo tan ambicioso sobre lo que fundamentar incluso un nuevo sistema operativo, había problemas graves que resolver. Al menos, así lo veía Hejlsberg, quien, en la citada conversación veía el problema de la siguiente forma (resumo la parte que es fundamental aquí para la compresión): “El problema de los errores del sistema operativo ha sido una de las cuestiones críticas a dilucidar a la hora de la construcción de la nueva plataforma. Más del 90% es a causa de los drivers y lo único que podemos hacer con eso, es garantizar un esfuerzo por nuestra parte y las compañías productoras de hardware en ese sentido. Pero, aún así, existe casi un 10% que es debido a nuestro software. Los análisis que hicimos de las pantallas azules (las llamadas “Blue Screens of Death”) arrojaban unos resultados sorprendentes. Casi la totalidad se debe únicamente a dos problemas: punteros a función perdidos y problemas de casting (conversión de tipos de datos). Por eso se me ocurrió el concepto de delegado, que, no sólo garantiza la presencia de las funciones receptoras de una llamada, (evitando el problema de los punteros a función), sino que obliga a que cualquier destinatario de esa llamada a función tenga la misma signatura que el delegado (en tiempo de compilación), terminando definitivamente con los problemas de casting” . Esta ejecución administrada supone, por tanto, que los errores pueden ser siempre

interceptados. Además, el sistema de tipos es común a todos los lenguajes (CTS), y los ejecutables no dependen más que de sí mismos para la instalación y distribución, haciendo de la plataforma el marco ideal para el nuevo sistema. Por si esto fuera poco, en un mundo de arquitecturas distribuidas, el soporte nativo de XML y la facilidad de producción y consumo de servicios web, ofrecen un valor añadido que resulta crítico en el nuevo subsistema de comunicaciones que el sistema incluye (de nombre clave Indigo). Como ya sabe el lector, .NET apareció hace ya 3 años. En el camino, otros personajes conocidos del mundo del desarrollo han sentido el atractivo de esta nueva plataforma (y también de los beneficios económicos de la empresa que lo promociona), incorporándose a distintas áreas del desarrollo de .NET y Longhorn: Don Box (autor del estándar XML-Schemas), Stan Lippman (co-autor junto a Stroustrup del lenguaje C++), Peter Drayton (especialista en CLR), Yousef Khalidi (arquitecto principal de Solaris 9 y Cluster 3.0, de Sun Microsystems) y más recientemente, Blake Stone (arquitecto de JBuilder, de Borland), son algunos de los más significativos. Estas son (entonces) algunas de las principales causas y también de los principales protagonistas de la historia. Repasemos ahora la historia en sí.

Las bases arquitectónicas de Longhorn Con todo esto por delante, y una nueva versión de la plataforma .NET (ahora se encuentra en la versión 2.0), comenzó el diseño del nuevo sistema con unos supuestos muy ambiciosos. Para comenzar, se pretende que Longhorn sea instalable en tantos equipos como sea posible (aún usando un grupo funcional reducido). Para ello, se han firmado acuerdos de colaboración con los fabricantes de hardware, para intentar extender lo máximo posible la Lista de Compatibilidad de Hardware (HCL), y garantizar (al menos, así se ha dicho), que incluso un Pentium II con 16 MB de Ram pueda ser el equipo de destino. De hecho nuevos elementos de la interfaz de usuario como el denominado “Mi Hardware”, darán un acceso y posibilidad de configuración sin precedentes al hardware instalado en el equipo.

11


ACTUALIDAD

A todo este conjunto de subsistemas constituyentes de lo que será la nueva API de Longhorn, se le denomina WinFX, y permitirá la ejecución de aplicaciones por compatibilidad, tan atrás como hasta Win16. Y otra característica notable: tanto Avalon como Indigo, serán instalables “en retrospectiva”, esto es, se podrán implantar en sistemas Windows XP y Windows 2003. (de hecho, ya existe desde diciembre del año pasado una versión “preview” de WinFX disponible para pruebas de desarrolladores, y que utilizaremos para mostrar algunas características de funcionamiento en el próximo número).

El nuevo modelo de desarrollo de aplicaciones y WinFX

El objetivo de Longhorn no sólo es soportar el mayor hardware posible, sino también ofrecer opciones muy avanzadas de configuración del mismo.

En el otro lado de la balanza, el objetivo es que el sistema pueda aprovechar al máximo las altas prestaciones de los equipos actuales, y que esté preparado para aprovechar todo el hardware disponible, ofreciendo al usuario lo que se denomina una “nueva experiencia de usuario”, cuya riqueza de posibilidades estará condicionada por la potencia del procesador y de la tar jeta gráfica que poseamos. Así, si disponemos de una tarjera de 32MB y AGP4 podremos acceder a lo que ellos denominan AERO. Un sistema de dibujo de ventanas basado en DirectX con una impresionante gama de posibilidades. Si (además) llegamos o sobrepasamos los 64MB, tendremos acceso a AERO-GLASS, la experiencia más rica de usuario implantada hasta la fecha, con ventanas que se sitúan en el espacio y no en el plano (y que pueden girar y moverse libremente por él), diferentes grados de transparencias para facilitar la lectura, y muchas otras características, que ya hemos podido ver en las primeras alphas del producto, si bien en un estado muy embrionario. Todas estas novedades no son más que una parte de los cuatro nuevos subsistemas que conforman el núcleo central de Longhorn (véase la figura con los subsistemas de Longhorn):  Avalon: subsistema gráfico. Basado en DirectX. Basados en él están las antes citadas experiencias de usuario: Aero y Aero-Glass. El lector puede profundizar sobre Avalon y sus nuevas posibilidades en la serie de artículos sobre XAML que se inició el mes anterior.


12









Indigo: subsistema de comunicaciones, basado en la arquitectura SOA (también llamada arquitectura orientada a servicios web). WinFS (Windows Future Storage): subsistema de almacenamiento. Palladium: subsistema de seguridad. Diseñado de acuerdo a la iniciativa Trustworthy Computing (Informática Fiable), a la que pertenecen en la actualidad, IBM, HP, Oracle, Sun, Microsoft, etc. Otros subsistemas asociados como las ayudas, la distribución instantánea de aplicaciones (one-touch deployment), y un gran paquete de mejoras e innovaciones.

Pero antes de que vayamos al código, vamos a describir, de cara al usuario avanzado, toda esa arquitectura y las implicaciones que va a suponer, de forma que dispongamos de una imagen más o menos plástica de tales cambios. Con los anteriores supuestos, el abordaje del sistema se basa en un cambio completo de paradigma, que los “evangelistas” de Microsoft han definido como “Programa una vez y distribuye como y cuando quieras”. Así, se trata de un modelo totalmente orientado a objetos, donde un objeto Application suministra toda la infraestructura de ejecución y cuya “metáfora de programación”, (por seguir su propia terminología) es similar a la de ASP.NET. Esto es, la interfaz de usuario de una aplicación (si es que dispone de tal cosa) se escribe en un lenguaje de marcas tipo XML, como el lector que está siguiendo la serie sobre XAML muy

Esquema de los nuevos subsistemas de Longhorn.


ACTUALIDAD

Windows Longhorn: La evolución de .NET (I)

bien sabe: en concreto es una versión propia del estándar XForms, llamada XAML, que sirve para describir elementos de IU en términos de elementos de marcado y que es compilada antes de su ejecución. La parte funcional del programa, se codifica en cualquiera de los lenguajes disponibles para la plataforma .NET (unos 30 en estos momentos, si bien Visual Studio .NET 2005 y la siguiente versión, de nombre clave Orcas, sólo incluirán de forma predeterminada C++, C#, Visual Basic .NET y J#). Se comprende ahora el porqué de la aparición del concepto de clases parciales en la próxima versión de Visual Studio 2005, como parte fundamental del nuevo modelo. Se trata de obtener de una única arquitectura programable, lo mejor de Windows y de la web. Existe pues, una clara separación entre presentación y funcionalidad, similar a la de ASP.NET (o incluso a la de los ficheros XML y las hojas de estilo extendidas (XSL), usadas para su interpretación visual). De hecho la interpretación gráfica de un fichero XAML es directamente una ventana, incluso si no existe código fuente asociado con él. De esta forma el aprovechamiento de las capacidades de DirectX en el dibujo y el pintado en VSYNC con doble buffer, permitirá a los marcos de las ventanas aparecer en parte sombreadas y en parte translúcidas, haciendo el texto más fácil de leer, y dispondremos, igualmente, de transparencias y animaciones que faciliten y potencien el uso del sistema. Y todo esto, con visualizaciones de una calidad más moderna y más alta que la utilizada hasta ahora (dependiendo de la potencia de la tarjeta gráfica). Si sólo disponemos de una tarjeta básica, (menor de 32MB de memoria), tendremos un sistema gráfico tipo Windows 2000. Estas novedades en la arquitectura, implican la construcción de tipos de aplicaciones totalmente nuevas, yendo desde las tradicionales, compiladas, a aquellas que se descargan por Internet y se ejecutan en el cliente sin dejar huella (una vez concluida su ejecución), u otras que se actualizan automáticamente, e incluso aplicaciones compiladas de tipo navegador que se descargan y ejecutan progresivamente.

Palladium y la seguridad ¿Y qué hay de la seguridad? Palladium es el nombre clave para un nuevo sistema de seguridad basado en gran parte en el propio hardware. Microsoft ha llegado a acuerdos con los principales fabricantes (Intel y AMD) para que http://digital.revistasprofesionales.com

La seguridad es uno de los aspectos que más debe cuidar un sistema operativo.

los nuevos chips lleven integradas características de seguridad que Longhorn pueda aprovechar de forma nativa. Son micros que incorporarán esas funcionalidades sin detrimento de la ejecución o el rendimiento y que darán origen a toda una nueva generación de software que aprovechará tales características, aunque los chips y el software básico que lo utiliza permitirá que algunas de esas novedades sean utilizadas por equipos antiguos. Palladium tiene como algunos de sus objetivos más destacados, la posibilidad de informar acerca de con quién se está tratando “on-line”, pudiendo limitar (de forma configurable) lo que llega de Internet y lo que ejecuta cada PC. La información se verificará antes de que se pueda acceder a ella. Se protegerán los datos mediante encriptación y el sistema podrá mantener la integridad de los documentos para que no puedan ser alterados sin el consentimiento del usuario. De igual forma, no se podrán ejecutar programas no autorizados, evitando que los virus afecten al funcionamiento. Respecto al spam, será evitado antes de que llegue a la bandeja de entrada. El correo no solicitado que se quiera recibir sólo será permitido si sigue una serie de credenciales que coincidan con nuestros parámetros de usuario previamente definidos. El sistema aplica un nuevo motor de inteligencia artificial actualmente terminado y en fase de pruebas en Microsoft Research. En el otro sentido, también se controlará lo que sale del PC usando agentes de software que garantizarán que los datos sólo alcanzan

al usuario adecuado. Además, usando la tecnología DRM (Administración de Derechos Digitales) Palladium evitará la distribución de música, películas, y otro tipo de propiedades intelectuales a través de Internet (ignoramos a la fecha, si esta característica se podrá desinstalar…) y las productoras de películas y la industria de la música podrán usar esta tecnología para permitir a sus clientes usar los derechos contra el copiado de CDs o películas, por ejemplo. Se asegura que Palladium podrá proteger el correo electrónico de tal forma que no podrá ser reenviado o copiado a otra gente sin permiso. También se podrán crear documentos de texto sólo accesibles en fechas determinadas u otras circunstancias a establecer.

Avalon y algunas consecuencias adicionales ¿Y qué otras consecuencias (meramente operativas, no de programación) nos vamos a encontrar? Pues, depende del subsistema que analicemos. Pero en cada uno de ellos un montón, según parece. Gracias a Avalon, dispondremos de las siguientes características:  El menú inicio se podrá convertir en una barra lateral realizada en XML que ocupará la posición lateral de la pantalla.  Se podrá personalizar al igual que la lista de programas del menú inicio.  Se mejorarán “Mis Documentos”, “Mis imágenes” y “Mi música”, con despliegues de información mejorados que usarán las últimas innovaciones multimedia.

13


ACTUALIDAD

archivada físicamente. El cómo los usuarios y aplicaciones organizan esta información, también está separada de cómo se almacena en disco. Los datos pueden ser organizados usando una estructura conectada de carpetas, nombres de espacios para datos, propiedades, tablas o identificadores invariantes o relacionales. Para beneficiar a los desarrolladores, WinFS soporta servicios de datos unificados para todas las aplicaciones de usuario final. Algunos los más notables, son los Servicios Integrados de Datos, como la sincronización, notificación, el almacenamiento unificado y un modelo común de seguridad, así como su integración con otras tecnologías como redes punto a punto (P2P) y servicios de directorio.

Indigo y las comunicaciones Avalon mejora notablemente la interfaz gráfica. En esta figura podemos ver el nuevo aspecto de “Mis imágenes”. 





“Mis Imágenes” incluirá nuevas opciones para crear un álbum de fotos, descargar vídeos de una cámara digital, o grabar un DVD. Tanto DVD-R/RW como DVD+R/RW estarán soportados. También se incluirá Windows Movie Maker 2, que será rehecho completamente en Longhorn e incluirá varias características nuevas. Esta nueva versión estará basada en Microsoft Producer, un añadido de PowerPoint 2003. Otra mejora será la del Soporte de Pantalla Inteligente. Una versión simplificada de éste ya fue incorporada en el Service Pack 1 de Windows XP. Esto, permitirá que dos usuarios puedan iniciar sesión en el mismo sistema, uno empleando la primera pantalla y el otro la secundaria. Se esperan asimismo mejoras de velocidad en este sistema.

WinFS y las implicaciones Aunque no es cierto que WinFS no vaya a estar presente en absoluto en la versión inicial de Longhorn, tal y como se ha comentado por ahí, sí que lo es que no lo va a estar en toda su extensión, tal y como se pensó en un principio, y que esa funcionalidad será suministrada en forma de beta instalable, hasta que aparezca completo en su versión final en 2007. Tal y como se había concebido, Windows Future Storage reúne lo mejor de dos entornos de trabajo con datos, los sistemas de ficheros


14

(buenos en streaming) y las bases de datos (buenas en indexación y búsquedas). WinFS mantiene una base de datos estructurada con las propiedades de los ficheros almacenados en el SO, y utiliza NTFS (que ahora es transaccional) para almacenar los ficheros. WinFS soporta un indexado eficiente del contenido del fichero, con lo cual se enriquece cualquier tipo de búsqueda que sería tremendamente difícil en otro sistema de archivos (pudiendo buscar incluso, otros objetos del sistema, como por ejemplo, contactos, o correos). En WinFS es sencillo buscar ficheros basados en su contenido y otros criterios como el nombre del archivo, titulo, autor o fecha de publicación. Aunque, en principio, WinFS se pensó que podría ser usado con máquinas que ejecuten versiones anteriores de Windows con tal que su sistema de archivos sea NTFS, este punto no está del todo claro al día de la fecha. Lo que sí es cierto, es que los ficheros almacenados en WinFS pueden ser accedidos usando las nuevas APIs de WinFS o bien el actual Win32 API. Como complemento, las actuales aplicaciones Win32, podrán acceder a los ficheros almacenados en WinFS con ninguna o con una muy pequeña modificación. Los ficheros pueden ser almacenados con WinFS o con NTFS, pero WinFS es mucho más eficiente que NTFS para organizar, buscar y compartir ficheros. WinFS es particularmente potente para almacenar datos que necesitan ser buscados o compartidos por usuarios y aplicaciones, y en WinFS, la información se estructura de forma distinta e independientemente de cómo esté

Por último concluimos esta primera revisión de Longhorn con unas pinceladas sobre el subsistema de comunicaciones, Indigo. Aunque iremos más en detalle y con algo de código fuente en el próximo número, hay que citar que Indigo pretende unificar todos los servicios del sistema operativo, permitiendo la interoperatividad con los actuales, y dotando al usuario de un API de acceso común. Así mismo, suministrará un sistema de mensajería de alto rendimiento, con independencia de los transportes y canales, y un modelo de servicios orientado al atributo (al tipo de información que se transporta). Por otra parte, sus contenedores podrán ser diversos, variando desde aplicaciones ASP.NET u otros servicios, hasta clásicos EXEs, componentes COM+, o incluso, los nuevos “containers” que definirá el modelo de aplicaciones de Longhorn. En suma, se trata de un nuevo diseño basado en el modelo de Arquitectura Orientada a Servicios (SOA), capaz de interactuar con casi todo lo existente, y que, al igual que sucederá con Avalon, podrá estar disponible también para las plataformas Windows 2003 y Windows XP Service Pack 2.

Conclusiones En fin, un montón de novedades, algunas de ellas en fase de depuración y otras bastante avanzadas que esperamos poder ver este verano cuando aparezca la primera beta oficial del producto. Hasta entonces, haremos una revisión de lo que supone Longhorn desde el punto de vista del desarrollador en el próximo número de Sólo Programadores , basándonos en las versiones “preview” disponibles, tanto del producto en sí, como del SDK de WinFX. http://digital.revistasprofesionales.com

DISPOSITIVOS MÓVILES

Juegos de calidad comercial en J2ME (I) ALBERTO GUTIÉRREZ MARTÍNEZ FRANCISCO JOSÉ GA RCÍA PEÑALVO (Profesor titular del departamento de Informática y Automática de la Universidad de Salamanca)

En los números anteriores de Sólo Programadores se presentaron las bases para el desarrollo de un videojuego con J2ME. Sin embargo, con esta serie de artículos queremos ir más allá. Nuestro objetivo será aprender el API de Nokia para poder desarrollar juegos de auténtica calidad comercial específicos para este tipo de terminales. Introducción

Con el API de Nokia ganaremos un 30% de pantalla que se desperdicia si sólo programamos con MIDP 1.0 SOLO PROGRAMADORES nº 122

16

En esta serie de cinco artículos vamos a conocer las limitaciones de la primera versión del perfil de programación de terminales móviles con Java, es decir, MIDP (Mobile Information Device Profile) versión 1.0, J2ME (Java 2 Micro Edition) y aprender a superarlas con APIs (Application Programming Interfaces) propietarias, con especial atención a la de Nokia. Conoceremos, además, los problemas de programar para un teléfono real, para lo que examinaremos en profundidad las características de varios terminales de Nokia. En los dos últimos artículos de la serie configuraremos un IDE gratuito para trabajar con J2ME y programaremos un “matamarcianos” clásico a pantalla completa con sonido digital. Con todo ello habremos aprendido las técnicas que usan los juegos de última generación para sacar el máximo partido a nuestros móviles. Como requisitos previos se supone que el lector tiene unos conocimientos básicos de J2ME y tiene instalado todo lo necesario para poder compilar un MIDlet (nombre que se le da a las aplicaciones desarrolladas con MIDP). Antes de empezar a desarrollar juegos Java de calidad comercial, es fundamental conocer dónde enmarcaremos dicha tecnología. Esta serie de artículos estará centrada a los terminales Nokia, y más concretamente a los de la Serie 60, plataforma que incluye teléfonos de altas

prestaciones y que se verá más adelante, aunque también se hará referencia en ocasiones a la Serie 40 de Nokia, plataforma que incluye teléfonos para el mercado de consumo. Se ha elegido la Serie 60 de Nokia por varios motivos, entre los que cabe destacar los siguientes:  Cuota de mercado, ya que Nokia actualmente es el líder indiscutible del sector.  Demanda, ya que los poseedores de este tipo de terminales son los mayores demandantes de juegos Java.  Espectacularidad, ya que son los terminales que permiten unos juegos más espectaculares.  Adaptación al Terminal objetivo, ya que los desarrolladores profesionales de juegos Java adaptan sus juegos a sus terminales objetivo para sacar el mayor partido de ellos. De modo que siempre habrá que acabar utilizando una API propietaria de un fabricante, que en este caso será la de Nokia, pero siguiendo procedimientos similares se podría usar la API de Siemens por ejemplo. Lo primero que debemos saber como programadores es sobre qué sistema operativo vamos a programar. El “Windows” en telefonía móvil se llama Symbian OS. Y decimos el “Windows”, no sólo porque sea un sistema operativo gráfico, sino porque está tan extendido en los teléfonos móviles, como Windows en los ordenadores personales. Actualmente la mayoría de los fabricantes de teléfonos móviles (Nokia, Sony-Ericsson, Siemens, Samsung y Panasonic, entre otros), instalan Symbian OS en sus terminales, aunque cambian la interfaz gráfica y parecen sistemas operativos distintos, por debajo todos ejecutan el mismo sistema operativo. Por poner un ejemplo, los Sony-Ericsson de gama alta, como el P-800, ejecutan Symbian pero por encima implementan una interfaz de usuario llamada UIQ. En el momento de la publicación de esta serie de artículos, Symbian OS va por su versión 8, que ya tienen teléfonos como el Nokia 6630. Actualmente existen dos tecnologías para desarrollar juegos para teléfonos móviles con sistema operativo Symbian, una es la que nos ocupa (J2ME) y otra es C++. Debemos tener muy claro que desde el momento en el que decidimos emplear tecnología Java para nuestras aplicaciones nos habremos http://digital.revistasprofesionales.com

Juegos de calidad comercial en J2ME (I)


Comparación J2ME y Symbian OS atado no sólo a las ventajas sino también a las desventajas de usar código interpretado. Éstas son principalmente baja velocidad de ejecución y limitaciones funcionales. Para entender estas desventajas hay que saber distinguir entre código interpretado y código nativo, que aunque muchos de nuestros lectores ya conocerán las diferencias, vamos a hacer en pocas líneas un pequeño repaso a ello:  El código nativo es el código que obtendríamos al compilar un programa en C++. Es el código máquina que puede ser ejecutado por el sistema operativo del teléfono móvil.  El código interpretado es el código que obtendríamos al compilar un programa en Java. Ese código debe ser traducido a código máquina en el momento de su ejecución, por la Máquina Virtual Java. Esa traducción es la responsable de la baja velocidad de ejecución mencionada anteriormente. Cuando se habla de limitaciones funcionales se está haciendo referencia a que sólo se dispondrá de los recursos que la implementación de la máquina virtual Java nos permita utilizar. La máquina virtual Java, por tanto, nos aísla , en la llamada “sandbox”(caja de arena), de las peculiaridades del teléfono que se está programando. Razón por la cuál nuestro programa Java no podrá, por ejemplo, usar la conexión por infrarrojos del teléfono, a no ser que el fabricante nos proporcione una API a tal efecto. Por poner un ejemplo, la especificación MIDP 1.0 de J2ME no permite el uso de ningún tipo de sonido. No obstante los fabricantes de terminales con capacidad para reproducir sonidos polifónicos o MIDI, como Nokia o Sony-Ericsson, permiten descargar desde la web las APIs que, entre otras, nos proporcionan funciones para que nuestros programas puedan sacar el máximo partido de sus terminales. En el cuadro “Comparación J2ME y Symbian OS” se muestra una comparativa entre las dos tecnologías comentadas anteriormente.

J2ME

Symbian OS

Tamaño de aplicación permitido

Decenas de Kb

Varios MB

Estándar abierto

Sí

Sí

Deployment (Despliegue)

Grande

Más pequeño

Soporte de varios fabricantes

Sí

Sí

Instalación OTA

Sí

Sí, sin embargo las aplicaciones de Symbian OS son normalmente tan grandes que es imposible la distribución OTA

Ejecución de forma nativa

No

Sí

Lenguaje de programación

Java

C++

Comunicación con servidores remotos

Sí

Sí

Animación en 2D

Sí

Sí

Animación en 3D

Normalmente No. Sólo para los móviles de última generación que soportan la especificación JSR184. Una completa API 3D basada en Open GL es Open GL ES

Sí

Mostrar vídeos

Normalmente No. J2ME puede reproducir vídeos en teléfonos que soporten la Java Mobile Media API como el Nokia 3650 y posteriores o en teléfonos con MIDP 2.0

Sí, si lo permite el terminal

Audio MIDI

Normalmente No. Se necesita la API propietaria del fabricante o MIDP 2.0

Sí

Audio de alta calidad

Normalmente No. Se necesita la API propietaria del fabricante o MIDP 2.0

Sí

Acceso a SMS

Normalmente No. Acceso a los SMS desde J2ME es posible usando la Nokia SMS API (soportada Sí (Además MMS si lo soporta el en Nokia 3410) o la Wireless terminal) Messaging API (soportada por los Nokia 3650 y posteriores)

Limitaciones de la plataforma Cuando hablamos de limitaciones de la plataforma, nos referimos no sólo a las limitaciones que tienen los teléfonos móviles en comparación con los ordenadores de sobremesa, sino también a las de J2ME en comparación con J2SE (Java 2 Second Edition). En los siguientes apartados se enumeran dichas limitaciones. http://digital.revistasprofesionales.com

Acceso a puerto de Infrarrojos y Bl bluetooth

Normalmente No. Sólo para terminales con MIDP 2.0 ya que soportan la Bluetooth API

Siempre que lo tenga el terminal

Acceso a la agenda, calendario…

No

Sí

Marcar un teléfono

No

Sí

Complicaciones de desarrollo multiplataforma

Menos que Symbian

Sí

17



Energía Es el principal problema de cualquier aparato electrónico y el causante, de forma directa o indirecta, del resto de limitaciones. Es éste un campo de continua investigación, ya que cada vez los aparatos electrónicos son más comple jos y demandan más recursos energéticos para funcionar. Aunque en la actualidad con la popularidad de las baterías de Litio los terminales móviles han experimentado un importante incremento de autonomía, debemos siempre tener en consideración a la hora de programar nuestros juegos las limitaciones energéticas. Por ejemplo, no deberemos abusar de la vibración pues acabaremos con la batería del teléfono en poco tiempo. Además, que el juego use vibración o sonido, deberían ser opciones configurables. Y es que el altavoz del teléfono es otro gran consumidor de energía. Pantalla Hay casi tantas variantes como modelos de teléfonos en el mercado. La principal diferencia es el número de colores que pueden representar. Desde monocromo hasta los 65.535 colores de los terminales más actuales. Hay que tener especial cuidado cuando desarrollemos juegos susceptibles de ser ejecutados en pantallas monocromas o de escala de grises, ya que si los gráficos no están especialmente adaptados, lo más probable es que sean tan confusos que no se pueda llegar a jugar con un mínimo de calidad. La resolución de la pantalla será otro factor importantísimo a tener en cuenta. Aunque en J2ME podemos utilizar controles para construir formularios que se verán correctamente en cualquier pantalla, cuando hacemos un juego al final siempre tendremos que usar la

Figura 1. Despliegue OTA.

clase “Canvas” (lienzo). Y el uso de ésta está fuertemente ligado a la resolución de la pantalla. Para que nuestro juego fuera lo más portable posible, lo ideal sería que todos los gráficos que se utilicen fueran escalables, de modo que se pudiera adaptar el juego a cualquier tamaño de pantalla. Esto sólo será posible en contadas ocasiones, así que tendremos que adaptar nuestro juego a cada resolución. Por lo tanto en este tipo de desarrollos será de vital importancia que nuestro código tenga una buena estructura que aísle todo lo posible la lógica del juego de las rutinas gráficas. Otro aspecto a tener muy en cuenta es la velocidad de refresco de la pantalla. Si estamos creando un juego de acción en el que, por ejemplo, usemos “scrolls” rápidos, deberemos probarlo sobre todos los terminales que tenemos como objetivo, pues habrá teléfonos que aún capaces de ejecutar nuestro programa sin problemas, la baja calidad de su pantalla a

Figura 2. Despliegue por puerto de comunicaciones.


18

color mostrará los gráficos en movimiento tan borrosos que serán impracticables. Teclado Un factor determinante para el éxito de un juego es su jugabilidad. Y ésta depende directamente de los controles que el dispositivo nos proporcione. En el momento de publicación de esta serie de artículos, el único móvil del mercado concebido para jugar es el Nokia N-Gage y su evolución el Nokia N-Gage QD. El resto de los móviles, en el mejor de los casos, no están preparados nada más que para movernos en las cuatro direcciones. Por si esto fuera poco, además los teclados no suelen tener una respuesta rápida, y lo que es aún peor, cada móvil tiene una disposición distinta de las teclas, que puede llegar a ser tan problemática que haga imposible el manejo del juego en determinados modelos. Especial atención en este aspecto merece el Nokia 3650, cuyo teclado se encuentra en disposición circular. Por lo tanto no sería mala idea permitir al usuario configurar los controles a su gusto. Por otra parte, en lo referente a las facilidades de J2ME para gestionar las pulsaciones de teclado, son un tanto escasas pero suficientes. Por ejemplo, para detectar la pulsación continuada de una tecla deberemos hacerlo a la antigua usanza, almacenando dicha tecla en una variable, tal y como se explicará más adelante, junto con la forma de detectar la pulsación simultánea de varias teclas. Tamaño A la hora de desplegar una aplicación MIDP, toda la lógica y los recursos de la aplicación quedan empaquetados en un fichero de http://digital.revistasprofesionales.com


tipo JAR (Java Archive). Por tanto, las limitaciones de tamaño se refieren al tamaño que ocupa el archivo .jar final del juego listo para distribuirse. Aunque el espacio de almacenamiento disponible en los móviles suele ser muy limitado, éste no será nuestro principal problema. La razón por la que no deberemos superar un tamaño límite, que puede estar entorno a los 150KB, está relacionada con el proceso de distribución (deployment) de los juegos para móviles. El modelo de negocio actual de la venta de aplicaciones para móviles consiste en que nosotros como desarrolladores llegamos a un acuerdo con la operadora, de modo que ella se encarga de hacer accesible nuestro juego a sus clientes y de la facturación. A cambio, la operadora se queda con un porcentaje por cada descarga del juego. A esta forma de distribución de las aplicaciones Java se la llama OTA (Over-The-Air provisioning, véase la figura 1). Por tanto, nuestro fichero deberá viajar por una red GSM (Global System for Mobile) o por una GPRS (General Packet Radio Service), redes que tienen una tasa de transferencia muy baja. Hasta que no se popularice el uso de redes UMTS (Universal Mobile Telecommunications System) nuestra aplicación deberá viajar por redes de banda estrecha, pero en cualquier caso el cliente que compre nuestro producto deberá acarrear con los gastos de la transmisión del fichero .jar hasta su móvil. Aunque los terminales más potentes podrían soportar juegos que ocuparan más de 1MB sin demasiados problemas, no habría ningún cliente que se descargara dicha cantidad de datos, por lo menos con los precios actuales. Además, las operadoras imponen un límite de tamaño máximo para OTA, que deberemos conocer de antemano a la hora de crear nuestro juego. Por poner un ejemplo práctico, la Serie 40 de Nokia impone un límite de 64KB para el fichero .jar, y de 5KB para el fichero JAD (Java Application Descriptor). Las aplicaciones J2ME se pueden instalar también usando USB (Universal Serial Bus), un puerto de infrarrojos o mediante bluetooth (véase la figura 2). Sin embargo, actualmente no existe ningún modelo de negocio que permita el aprovechamiento de estos modos de instalación, ya que el usuario necesitaría tener un ordenador. Aunque el http://digital.revistasprofesionales.com


Figura 3. Despliegue mediante memory card.

problema fundamental es que estos métodos facilitarían la piratería de los programas. El modelo de negocio novedoso que ha puesto en marcha Nokia con la Nokia N-Gage consiste en distribuir los juegos en SD cards (vease la figura 3), equiparando el negocio al de las videoconsolas. Aunque la mayoría de los juegos en este soporte son nativos de Nokia, también los hay hechos en Java. Gracias a este soporte no habría la limitación de tamaño comentada anteriormente. Memoria de ejecución Aunque nuestro programa no ocupe mucho espacio en disco, puede ser capaz de acabar rápidamente con la memoria de ejecución del móvil. Si, por ejemplo, nos dedicamos a instanciar objetos indiscriminadamente sin liberarlos explícitamente, es más que probable que veamos el fatídico mensaje de “Memoria Insuficiente”, de forma que nuestro juego muera, pudiendo incluso en ocasiones llegar a matar hasta al propio sistema operativo del teléfono. Los procesadores que suelen ejecutar J2ME son tan poco potentes que no se pueden permitir el “lujo” de llevar una gestión minuciosa de los objetos en memoria que ya no se van a usar, como hace J2SE. Eso significa que el recolector de basura sólo sea llamado en contadas ocasiones, y debamos nosotros explícitamente invocar al método “System.gc()” de vez en cuando. Cada fabricante de terminales decide el tamaño de esta memoria de ejecución en

función de las prestaciones del móvil. Sin embargo, hay un mínimo de 64KB de memoria de ejecución que el estándar CLDC (Connection Limited Devide Configuration) obliga que tengan todos los terminales. Por ejemplo, la Serie 60 de Nokia tiene cerca de 4MB de memoria de ejecución. Los emuladores que usamos para probar nuestros juegos en tiempo de desarrollo nos mostrarán siempre en pantalla la cantidad de memoria usada en todo momento, dato éste que tendremos que vigilar para que nunca esté demasiado cerca del límite que tenga nuestro terminal objetivo. Sonido MIDP 1.0 no soporta el uso de sonido. Por tanto, a no ser que usemos una API específica del fabricante que permita reproducir sonidos polifónicos, nuestro juego será completamente mudo. Además, la mayoría de los modelos tienen unos altavoces de baja calidad, lo cual habrá que tener en cuenta, pues será inútil usar sonidos digitales de alta calidad. En este aspecto las cosas están cambiando y teléfonos como los Sony-Ericsson y los Samsung tienen un sonido estéreo de gran calidad. No así los Nokia, en los que actualmente no merecerá mucho la pena que nos esmeremos demasiado en el aspecto sonoro. Procesador Los procesadores de los teléfonos móviles son por lo general muy lentos y nuestros 19



Comparación DP 1.x y DP 2.0 programas no deberían demandar demasiados recursos de ellos. Más aún si estamos desarrollando en Java, porque a parte de los recursos que demande el sistema operativo, que no son pocos, se estará ejecutando la máquina virtual Java, y encima de todo esto, se deberá ejecutar nuestro juego. Para complicar un poco más las cosas, los fabricantes de móviles no mencionan el tipo de procesador que utilizan sus modelos, ni mucho menos la frecuencia de éstos. Además, las diferencias de rendimiento entre distintos modelos son muy variables, como ejemplo, en la Serie 60 de Nokia, hay una diferencia notable de rendimiento entre el Nokia 7650 y el Nokia 3650, siendo éste último más rápido que el anterior. Por tanto, como siempre, deberemos probar nuestros juegos en los modelos objetivo, pues un juego que es capaz de “mover” un Nokia 3650 por ejemplo, en un Nokia 7650 puede ser impracticable. Ausencia de float y double Como se ha comentado en el apartado anterior, los procesadores de los teléfonos móviles son muy sencillos, tan sencillos que normalmente no tienen ni unidad de coma flotante. Es por esta razón que J2ME no dispone de los tipos de datos primitivos float y double. Sin ellos se dificulta, en principio, hacer cálculos trigonométricos, razón por la que han desaparecido métodos de la clase “Math” como “cos()” y “sin()”. En próximos artículos daremos una solución para este problema usando una clase de libre distribución llamada “MathFP”. Hilos sin método stop() Otro de los múltiples recortes de J2ME es la supresión de métodos en la clase “Thread”. En próximos artículos hablaremos del traba jo con hilos, e indicaremos cómo parar un hilo que no tiene método “stop()”. Red de comunicaciones de banda estrecha Como ya se ha mencionado anteriormente al hablar del tamaño final del juego, las redes GSM y GPRS son lentas, caras e inestables. Debemos tener en cuenta esto si pretendemos que nuestra aplicación envíe o reciba datos. El usuario de nuestro programa deberá estar siempre bien informado del uso que se haga de la red, pues el uso de este recurso le cuesta dinero. En la SOLO PROGRAMADORES nº 122

20

Developer Platform 1.0 for Series 60

Developer Platform 2.0 for Series 60

MIDP 1.0

MIDP 2.0

CLDC 1.0

CLDC 1.0

Wireless Messaging API (JSR-120) (excepto el Nokia 7650)

Wireless Messaging API (JSR-120)

Mobile Media API (JSR-135) (excepto el Nokia 7650)

Mobile Media API (JSR-135)

XHTML browsing

XHTML Browsing sobre TCP/IP

Mensajería MMS (Mensajes Multimedia)

Mensajes MMS con Synchronized Multimedia Integration Language (SMIL)

Sin posibilidad de programar bluetooth con J2ME

APIs for Bluetooth (JSR-82)

Symbian OS v6.1

Symbian OS v7.0

Ejemplo: Nokia 3650

Ejemplo: Nokia 6600

actualidad, las operadoras españolas acaban de empezar a comercializar UMTS aunque todavía existen muy pocos usuarios con terminales de tercera generación. Por tanto, con la red actual, para nuestro juego puede ser factible, por ejemplo, bajarse la lista de las 10 mejores puntuaciones alojada en un servidor, o quizá enviar o recibir un par de imágenes de baja resolución .

común la Serie 60 de Nokia es el tamaño de la pantalla (176x208 píxeles), una profundidad de color mínima de 4.096 colores y capacidad de conexión bluetooth. Otros aspectos como puede ser la capacidad de proceso, o de sonido, son similares pero en absoluto idénticos. Cada modelo que aparece en el mercado dentro de la Serie 60 es superior al anterior, y no nos deberemos guiar tanto del número de modelo como del orden de aparición en el mercado. Por ejemplo, el Nokia 3650 es superior al 7650. Como desarrolladores debemos conocer las características de la plataforma de desarrollo para la Serie 60, (Developer Platform for Series 60). Es importante distinguir entre las dos versiones principales, la 1.0 y la 2.0. Dentro de la versión 1.0 existen otras intermedias, por lo que normalmente nos referimos a ella como versión 1.x. En el cuadro “Comparación DP 1.x y DP 2.0” se muestran las principales características de las dos versiones. Para conocer las características técnicas de cualquier móvil de Nokia, incluidos los de la Serie 60, se pude visitar el enlace http://www.forum.nokia.com/main/1,6566,0 10_40,00.html. A continuación se muestran algunos modelos de la Serie 60 de Nokia por orden de aparición.

La Serie 60 de Nokia La Serie 60 de Nokia es una línea de productos guiada por las prestaciones en contraposición a otras de la misma Nokia guiadas por el precio y el tamaño del terminal, como por ejemplo la Serie 40. Conocer las características técnicas de los terminales objetivo es de vital importancia a la hora de desarrollar aplicaciones para móviles, ya que aunque la tecnología de programación es la misma, las plataformas son muy distintas entre sí. Incluso entre los distintos modelos de una misma serie se encuentran diferencias importantes en cuanto a recursos y disposición del teclado. Por tanto, antes de desarrollar una aplicación para un terminal móvil hay que conocer las capacidades de la plataforma objetivo, y luego ser consciente de que habrá que adaptar la aplicación y hacer las pruebas pertinentes con cada modelo de terminal donde se desee ejecutar. En el caso concreto que nos ocupa, lo único que tiene en

7650 Primer modelo de la Serie 60 (véase la figura 4). Modelo de alta gama y alto coste, http://digital.revistasprofesionales.com


Figura 4. Modelo 7650 de Nokia.


orientado a ejecutivos. Es el único modelo de la Serie 60 que dispone de foto sensor (no programable en MIDP). Este modelo no se comercializó en USA. De serie no lleva software para grabación de vídeo pero Nokia lo proporciona gratuitamente en su web. No tiene lector de tarjetas MMC (MultiMediaCard). Tiene capacidad de sonido polifónico pero dispone de un altavoz de poca calidad. Lleva cámara incorporada. El tamaño máximo de aplicación Java es de 4MB y la memoria de ejecución máxima (heap size) es de 1,4MB. 3650 Terminal multimedia orientado a gente joven (véase la figura 5). Viene de serie con software para grabación de vídeo y para reproducción (Real ONE player). La disposición del teclado en círculo es de vital importancia a tener en cuenta a la hora de definir las teclas de control de nuestro juego. Tiene capacidad de sonido polifónico pero dispone de un altavoz de poca calidad. Incorpora lector de tarjetas MMC. Lleva cámara incorporada. El tamaño máximo de aplicación Java es de 4MB y la memoria de ejecución máxima (heap size) es de 1,4MB. N-Gage Es el primer móvil orientado al mercado del entretenimiento (véase la figura 6). Puede reproducir MP3 y es competencia directa de consolas de videojuegos portátiles como la Gameboy. Los compradores de este modelo serán los usuarios más dispuestos a adquirir nuestros juegos, por lo que ésta

Figura 10. KTootlBar.


Figura 6. Modelo N-Gage de Nokia.


deberá ser nuestra plataforma objetivo. Numerosas compañías desarrolladoras de software de entretenimiento han portado ya los juegos más populares a esta plataforma. Títulos como Tomb Rider y Sonic the Hedgehog ya se encuentran en el mercado, con una calidad en cuanto a gráficos y sonido, muy similar a la de las antiguas consolas de 16 bits como la Megadrive de Sega. Los juegos se distribuyen en tarjetas MMC. Este modelo no incorpora cámara. El tamaño máximo de aplicación Java es de 4MB y la memoria de ejecución máxima (heap size) es de 2,8MB. 6600 Es el primer teléfono de la comentada anteriormente Developer Platform 2.0 for Series 60 (véase la figura 7). Lleva la versión 7 del sistema operativo Symbian que a simple vista no se diferencia mucho de la versión anterior. Su pantalla es de 65.535 colores. La mejora más necesaria que se echaba de menos en modelos anteriores ha sido en lo referente al sonido. Es también destacable la posibilidad de zoom de la cámara incorporada, sin haber variado la resolución ni la calidad de la misma respecto a modelos anteriores. Lo más importante de este teléfono para los programadores Java es que es el primer Nokia en soportar MIDP 2.0, hecho este que facilita bastante la programación de juegos. La versión para el mercado americano de este modelo se llama 6620. El tamaño máximo de aplicación Java es de 4MB y la memoria de ejecución máxima (heap size) es de 3MB.




3660 Es prácticamente idéntico al modelo 3650 salvo que la disposición del teclado ha cambiado de la disposición circular a la típica de cualquier teléfono móvil (véase la figura 8). Además su pantalla es capaz de mostrar 65.535 colores. La versión americana de este modelo se llama 3620. El tamaño máximo de aplicación Java es de 4MB y la memoria de ejecución máxima (heap size) es de 1,4MB. 7610 Es el primer teléfono de Nokia en incorporar una cámara de 1 Megapíxel. Además es novedoso también su puerto USB PopPort que permite una rápida conectividad con un PC. Por todo lo demás, es similar al modelo 3660. El tamaño máximo de aplicación Java es de 4MB y la memoria de ejecución máxima (heap size) es de 8MB.

MIDlet para conocer las capacidades gráficas de nuestro móvil Si las pantallas de la mayoría de los móviles son pequeñas, al utilizar un “Canvas” la pantalla de nuestro juego todavía será más pequeña que la pantalla del móvil. Si se observan los juegos Java comerciales de calidad, como por ejemplo el “Prince of Persia” de Gameloft, veremos que se ejecutan a pantalla completa. ¿Cómo lo hacen? ¡No hay ninguna clase en MIDP 1.0 que sea capaz de conseguir esto! La solución la veremos en próximos artículos cuando hablemos de la clase “FullCanvas” de la API propietaria de Nokia. Como se puede deducir a estas alturas, cuando desarrollemos un juego deberemos adaptar los gráficos al terminal en el que queremos que funcione nuestra aplicación. Para ello deberemos conocer con exactitud las características de la pantalla de nuestro terminal. Esto no es otra cosa que “interrogar” a la clase “Canvas” sobre sus propiedades, aunque también tendremos que sacar algunas 21



downloads.html) y posteriormente instalar el J2ME Wireless Toolkit 2.2 de SUN que puede obtenerse en http://java.sun.com/products/ j2mewtoolkit/download-2_2.html. Una vez instalado el software buscaremos la aplicación KToolBar (véase la figura 10). Pulsaremos sobre “New Project”. Le daremos el nombre que queramos al proyecto (sin espacios) y en el campo “MIDlet name” tendremos que poner “Principal”. Posteriormente aparecerá otro diálogo con la etiqueta “API Selection” activa. Deberemos aquí seleccionar como “Target Platform” MIDP 1.0, y al aceptar observaremos que volvemos al entorno de la KToolBar que ahora nos indica con un texto dónde deberemos poner los fuentes y los recursos del proyecto. Los ficheros fuentes en: [unidad de instalación]/WTK22/[Nombre Proyecto]/src/

Los ficheros de recursos en: Figura 11. Aplicación en ejecución sobre el emulador Serie 60 de Nokia.

propiedades de la clase “Display”. Esto es lo que haremos en el programa que se recoge en el listado 1 incluido en el CD-ROM. Este programa tiene como peculiaridad que hemos hecho el “truco” de Java, para poder usar la clase “Canvas” sin tener que instanciar una clase que herede de ella, ni crear otro .java. La clase “Canvas” es una clase abstracta y debemos implementar su método “paint()” al instanciarla. En esa misma sentencia, además estamos asignando el “Display” al “Canvas” que se ha creado. Por lo demás, el código es auto explicativo, y nos estamos limitando a sacar propiedades de ambas clases (“Canvas” y “Display”) por pantalla.

Compilación Los lectores de Sólo Programadores ya han practicado con las herramientas necesarias para el desarrollo con J2ME, sin embargo repetiremos aquí, una vez más, los pasos a seguir para ejecutar un proyecto J2ME en un emulador. Para desarrollar aplicaciones J2ME es necesario tener el J2SE SDK (http://java.sun.com/j2se/

[unidad de instalación]/WTK22/[Nombre Proyecto]/res/

Y los ficheros de bibliotecas en: [unidad de instalación]/WTK22/[Nombre Proyecto]/lib/

Una vez copiado el archivo “Principal.java” incluido en el CD-ROM y mostrado en el listado 1 al directorio de fuentes correspondiente, sólo tendremos que pulsar en “Build” para compilar y/o “Run” para ejecutar en un emulador, tal como muestra la figura 11.

Conclusiones Analicemos los resultados usando el emulador de Nokia de la Serie 60 (en próximos números veremos su instalación, mientras tanto el lector puede probar el ejemplo con los emuladores que el Wireless Toolkit trae por defecto), y comparándolo con un teléfono real, el Nokia 3650. Lo que debería verse es lo que aparece en la figura 11. De los datos que obtenemos nos fijamos primero en la resolución del “Canvas”. El programa nos dice que tenemos disponible para nuestro juego un área de 176x144 píxeles, cuando según dijimos anterior-

mente la Serie 60 de Nokia tiene un área de pantalla de 176x208 píxeles. Hemos perdido 64 píxeles en altura de nuestra pantalla, lo que supone más de un 30% de la pantalla. El teléfono admite double buffering. Esto significa que el propio teléfono maneja una memoria de vídeo donde hace los cambios oportunos antes de mostrarlos por pantalla en un evento de repintado. Esto a efectos prácticos significa que podremos recoger el objeto “Graphics”, que recibiremos del evento “Paint” del “Canvas”, y pintar sobre él, sabiendo que no vamos a tener el engorroso efecto de parpadeo de nuestros gráficos, que un juego sin double buffering tendría. Como vemos el objeto “Canvas” nos dirá si el teléfono sobre el que estamos ejecutando tiene una pantalla táctil, lo que abriría un gran abanico de posibilidades a la interacción con nuestros juegos. Aunque la clase “Canvas” en principio parece estar relacionada con gráficos, vemos que también lo está con el teclado. Esta propiedad nos dice que el terminal es capaz de detectar cuándo hemos dejado pulsado un botón, levantándose eventos a tal efecto como veremos más adelante. Las dos propiedades que hemos sacado pertenecen al objeto “Display”, y como observamos nos hablan de las posibilidades gráficas de la pantalla. Con la primera sabemos que la pantalla es en color y con la segunda sabemos cuántos colores es capaz de mostrar simultáneamente. Vamos a fijarnos en ésta última. Según las características de la Serie 60 de Nokia, el teléfono que más colores podía mostrar estaba en torno a los 65.000. En el emulador vemos que la pantalla muestra 16 millones de colores. Si ejecutamos la misma aplicación en un Nokia 3650, todas las propiedades salen idénticas, salvo ésta última, en la que aparece el valor real de 4.096 colores. Ésta es una muestra más de que nunca nos deberemos fiar de los emuladores... En el próximo número veremos en profundidad la API propietaria de Nokia para, entre otras cosas, aprovechar ese 30% de pantalla que como acabamos de comprobar se desperdicia si sólo programamos con MIDP 1.0.

Agradecimientos Los autores agradecen a la empresa Flag Solutions (http://www.flagsolutions.net) y al grupo AWEG (Adaptive Web Engineering Group) de la Universidad de Salamanca sus aportaciones y consejos para la elaboración de este artículo.


22


MIDDLEWARE

XAML (II) ERICH R. BÜHLER (MVP en .NET Framework)

XAML cambiará radicalmente la filosofía de desarrollo de las aplicaciones, por lo que a la interfaz de usuario se refiere. En esta segunda entrega analizaremos algunos aspectos centrados en la programación de interfaces bajo esta nueva tecnología. Introducción

XAML permite crear IGUs visualizables tanto en ventanas como en navegadores SOLO PROGRAMADORES nº 122

24

En el artículo anterior conocimos las ideas básicas de la estructura de XAML y vimos también que marcará un hito en la forma en la que se programarán las aplicaciones. El hecho de que cambie el motor gráfico implica nuevas posibilidades y abre el espectro a un nuevo conjunto de aplicaciones que serán vistas como una mezcla entre lo mejor del web y Windows, multimedia, y documentos. Le estoy anticipando que es un buen momento para que comience a aprender XAML si no quiere quedarse atrás. Esto es lo mismo que si hace 12 años (cuando algunas pantallas todavía solían ser de fósforo verde) le hubiese dicho que sería buena idea que considerase programar para Windows. Es que en realidad me he quedado muy corto en el artículo pasado sobre las bondades de la nueva camada de aplicaciones, pero afortunadamente aquí comenzaré a desvelar varias características que si bien mencioné brevemente ahora ya se está en condiciones de plasmar. Por supuesto que si no leyó la entrega anterior no es mala idea que se haga de alguna forma con ella, ya que tengo la intención al finalizar con esta serie de artículos abordando la mayor parte de las características de XAML y así lograr que esté en carrera para los próximos años.

Las 6 verdades absolutas sobre XAML Los siguientes 6 puntos ya los vimos en la entrega anterior, pero deseo refrescar su memoria sobre todo porque sé que un mes puede llegar a ser mucho tiempo para tener presente la totalidad de un artículo.

1.-XAML define una interfaz gráfica avanzada

para una ventana o página utilizando como medio un documento en formato XML. 2.-XAML es un lenguaje declarativo aunque se puede también interactuar con este mediante código (escritura de eventos para controles, creación dinámica de elementos, etc.). 3.-Cada elemento de XAML se corresponde con una clase del nuevo conjunto de clases que se le adicionará a .NET Framework 2.0. 4.-XAML cuenta con su propio conjunto de controles que no son de Windows Forms, aunque en casos extremos se pueden también insertar estos últimos. 5.-La apariencia de controles se establece mediante etiquetas o atributos, contándose con propiedades complejas y la posibilidad de interactuar desde un control hijo con su padre (por ejemplo, un botón que indique la posición dentro de su contenedor). 6.-Todo dentro de XAML (incluso los controles) pueden ser vectoriales, lo que da la ventaja de llegar a ser “resolución independiente”. A estas seis verdades hay que sumarle que es muy sencillo aplicarle una animación a un conjunto de controles de la interfaz gráfica, por ejemplo para que varíe a lo largo del tiempo su forma, tamaño, color, etc. Por supuesto que todo esto es en realidad un pequeño conjunto de las ventajas, he iremos viendo más a lo largo de las distintas entregas.

Resolución independiente Si conoce .NET Framework sabrá que es posible adecuar el tamaño de los controles de un contenedor (ventana, marco, etc.) de acuerdo al espacio disponible, aunque en realidad lo que hacía la infraestructura era reducir los anchos y altos de los elementos. Mediante las propiedades “Anchor” y “Dock” se definían medidas relativas al contenedor o borde y finalmente si el mismo cambiaba los controles disminuían su tamaño o se apretaban entre sí, lo que daba algunas ventajas si nuestro cliente no tenía la resolución de pantalla esperada. Ésto es lo mismo que si usted se muda a una casa más pequeña y desea conservar todos sus muebles, en realidad éstos tendrán el mismo tamaño pero por supuesto dentro de un espacio menor. http://digital.revistasprofesionales.com

MIDDLEWARE

XAML (II)

Vea ahora la figura 1, en ella se muestran 3 copias de la misma ventana la que he adecuado su tamaño manualmente estirando y/o contrayendo sus bordes. ¿Qué hay de fantástico en ello? Si presta atención notará que su contenido ha sido realmente adecuado de acuerdo al espacio disponible, esto es así porque todo es vectorial en XAML incluso los controles. ¡Ahora sus muebles cambian de tamaño de acuerdo al espacio disponible! Por supuesto que ello hace que la solución ofrecida en .NET Framework 1.1 pase a ser una broma de mal gusto comparada con la nueva potencia de auto-ajuste en XAML. Veremos más adelante lo sencillo que es lograr esta característica utilizando un tipo de contenedor especial llamado “ViewBox”. Pero antes vamos a analizar brevemente el modelo propuesto por Microsoft conociendo los nuevos tipos de aplicación.

Nuevos tipos de aplicación Para Microsoft es doble responsabilidad XAML por un lado por ser el padre de esta tecnología y por otro por ser la piedra fundamental de los nuevos tipos de aplicación. Hasta el momento en la programación clásica se podían distinguir 3 tipos diferentes de ellas:  Aplicación web  Aplicación de ventanas  Aplicación de ventanas que interactúa con servicios web XML u otro servicio web El último punto puede no ser considerado un tipo específico de aplicación, pero he decidido incluirlo ya que interactúa con lo mejor de los dos mundos: web y Windows. El nuevo modelo propuesto por Microsoft incluye también 3 tipos llamados aplicaciones WinFX (véase la figura 2), aunque en realidad difieren de lo que se conoce actualmente. El primer tipo es el llamado “aplicaciones de páginas múltiples” y es conceptualmente similar a una aplicación web. Una aplicación de este tipo consistirá de una o más páginas XAML y cada una de ellas representará una interfaz gráfica dentro de la aplicación. Una vez que el usuario finalice con una página podrá pasar a la próxima y así sucesivamente. El código de programación (el que responde a los eventos) de cada una de ellas está en general contenido por un archivo externo, en forma similar a como se hace hoy en día en ASP.NET. El segundo tipo es el de “documentos”, aquí también se tienen múltiples páginas en las que el usuario puede navegar, pero sin embargo el http://digital.revistasprofesionales.com

Figura 1. XAML nos permite construir interfaces vectoriales, lo cual permitirá a nuestras ventanas adaptarse al tamaño necesario sin perder por ello el diseño original.

objetivo principal radica en mostrar información como podrían ser documentos o gráficos. Debido a ello están disponibles varias características para la gestión de la visualización como puede ser zoom y vistas de una o más páginas, firmas de documentos, etc. Éste es un importante capítulo para la nueva infraestructura ya que se ha hecho un esfuerzo muy grande y como veremos en próximas entregas se ha adicionado una nueva y completa infraestructura para la visualización de documentos. Prometo cubrir este punto en su totalidad en breve. Finalmente se tienen las “aplicaciones de ventana” donde se cuenta con una o más ventanas en un modelo similar al que ya conoce, aunque los controles factibles de ser incluidos son muchísimo más amplios que tan sólo el reducido número de los intrínsecos de Windows. Es importante destacar que la mayor parte de los elementos pueden ser utilizados en los tres modelos, lo que brinda una transparencia total entre ellos. Digo la mayor parte porque por supuesto que no es posible emplear los llamados controles de navegación cuando se usa el modelo de ventanas.

código a alguna de las páginas entonces se dice que se tiene una aplicación y allí la aproximación es diferente. En estos casos se deberá compilar el código para poder visualizar su resultado de forma funcional. Para ello se utiliza una herramienta llamada MSBUILD de la que hablaremos en próximas entregas. Otra cosa muy importante a entender es que las aplicaciones navegables o de documentos

Compilación de aplicaciones vs documentos Si se tienen documentos XAML “sueltos”, esto es sin código asociado a los mismos, entonces ellos serán factibles de ser visualizados simplemente haciendo doble clic; se abrirá entonces el visor predeterminado y mostrará su contenido, al igual que se hace hoy en día con una página HTML. Ahora bien, si se asocia

Figura 2. Ejemplo de los tres tipos de aplicaciones WinFX propuestos por el nuevo modelo de Microsoft.

25


MIDDLEWARE

LISTADO 1

pueden ser visualizadas tanto dentro de una ventana como dentro de un navegador. El cambio de un tipo a otro debe indicarse en tiempo de compilación, esto no implica en general más que modificar un parámetro de compilación, lo que hace muy fácil abstraerse del modelo. Como último decir que la creación de controles también puede ser realizada mediante código prescindiendo de los documentos XAML. Esto es así ya que como comenté anteriormente cada control es una clase de la infraestructura la cual puede ser gestionada de forma estándar como tantas otras.

Trabajando con contenedores Vamos a empezar viendo cómo trabajar con documentos “sueltos”, esto es, sin lógica asociada a ellos. Una vez que entendamos el funcionamiento comenzaremos a vincular todo esto con los diferentes tipos de aplicación. A modo de organizar los distintos tipos de control, he separado a los mismos dentro de 2 grupos lógicos, aunque esta división es totalmente ficticia y solamente tiene el fin de que pueda entender su funcionamiento y relación:

El contenedor ViewBox

1.-Controles contenedores 2.-Controles de interacción con el usuario

El primer grupo ofrece diferentes alternativas de paneles, es decir, aquellos que se encargarán de almacenar a los demás elementos. Podemos imaginarnos esto como un conjunto de distintos tipos de contenedores para los más diversos usos. La importancia de los controles contenedores radica en que luego sus integrantes podrán ganar sus características. Por ejemplo, existe un control llamado “ViewBox” que se encarga de que si cambia su tamaño se adecue su contenido. Como ve, éste es el tipo de panel que he utilizado para el ejemplo de la figura 1, el contenido del listado 1 es un resumen de su código. A su vez algunos controles de interacción con el usuario tienen que ser obligatoriamente almacenados por un contenedor específico, veremos ésto cuando tratemos al tipo “Gris”. Además se pueden anidar varios contenedores, por ejemplo que “ViewBox”

contenga un panel y que a su vez este panel contenga otros y así sucesivamente. El primer paso es entonces elegir uno de ellos de acuerdo a las características que éste ofrece, lo que lógicamente podrá repercutir en la conducta de sus miembros. Una vez hecho ésto pasaremos a hacer uso del segundo grupo, el que ofrece desde botones, hipervínculos, multimedia, etc. Pero antes de comenzar a escribir XAML quiero detenerme para comentarle las diferentes alternativas que necesitará tener instalado si quiere programar en XAML: 1.- Visor XAML de Xamlon y también conversor de Flash a este formato (http://www.xamlon.com). 2.- Visor XAML de Mobiform, que contiene el único editor gráfico en el momento (http://www.mobiform.com). 3.- Visor XAML de Microsoft contenido dentro del paquete SDK de WinFX (http://www.msdn.microsoft.com).

Los 7 tipos de contenedor Control

Canvas

Descripción

Espacio de nombres en .NET Framework 2.0

Define un área en el cual cada elemento contenido puede ser dibujado en una coordenada del eje vertical y horizontal relativo al mismo. Es lo más parecido al posicionamiento que utiliza System.Windows.Controls Visual Basic u otros lenguajes para situar los controles en sus formularios.

Define un área en el que los elementos contenidos se pueden organizar uno con respecto al DockPanel otro, tanto sea en forma vertical u horizontal, y se pueden especificar los tamaños de los con- System.Windows.Controls troles en porcentaje relativo al contenedor. FlowPanel Alinea y particiona el contenido (controles) en varias líneas para el caso que exceda la longi- System.Windows.Controls tud del espacio horizontal disponible en la línea. Gris

Establece una cuadrícula consistente de filas y columnas; cada elemento puede ser posicionado dentro de uno de los espacios formados. Es un panel menos pesado en recursos que “Table”, System.Windows.Controls pero también ofrece menos características.

Table

Muestra datos en forma tabular, como lo hace cualquier tabla.

Text

Gestiona una o más líneas de texto como de sólo lectura así como también todo lo referente a su formato. Es mucho más liviano en recursos, en comparación con “TextPanel”, pero ofrece menos funciona- System.Windows.Controls lidades.

System.Windows.Documents

Gestiona una o más líneas de texto como de sólo lectura así como también todo lo referente a su formato. Algunos controles deben ser obligatoriamente contenidos por este tipo de panel. TextPanel Se utiliza en general para darle formato a documentos, aunque no es excluyente. Soporta tam- System.Windows.Documents bién paginación del contenido. ViewBox

El contenido del mismo será escalado al tamaño del contenedor. Puede contener un sólo hijo directo, aunque ésto no es un problema ya que se puede insertar un panel y luego dentro de System.Windows.Documents éste otros.


26


Sólo Programadores en Formato Digital Con el respaldo de más de diez años de publicación mensual y sin interrupciones

Entra en http://digital.revistasprofesionales.com Suscripción anual a Sólo Programadores por sólo 27 euros y a Sólo Programadores y Mundo Linux por sólo 40 euros Regalo de un CD-ROM con el archivo de los 12 ejemplares de la temporada 2003-04

MIDDLEWARE

LISTADO 2

Formateando un texto con TextPanel

.NET framework .NET framework .NET framework

FontFamily=”Palatino Linotype”>

Si piensas en migrar tus aplicaciones de VB4, VB5, o VB6, deberías tener en cuenta que la nueva versión de Microsoft Visual Basic .NET cambia radicalmente la forma en que harás las cosas, y los productos que ya tienes implementados. Guía de migración y actualización a Visual Basic .NET Erich Buhler McGraw-Hill ISBN 84-481-3271-8 Todo lo que necesita conocer Explicado en forma sencilla 18 capítulos Casi 1.000 páginas

Es importante destacar que la implementación WinFX del SDK de Microsoft es lógicamente la que ofrece el conjunto más amplio de características. Sin embargo al momento de escribir este artículo la misma requiere que esté suscrito a la MSDN. Por su parte Mobiform cuenta con un editor gráfico que hace posible diseñar las páginas XAML de forma muy sencilla; por supuesto que no es mala idea tener lo mejor de cada uno. En cuanto a los requisitos de sistema operativo son Windows XP, 2000 o 2003 (dependiendo del producto).

Tipos de contenedor Como vimos anteriormente los tipos de panel condicionarán el comportamiento y las futuras propiedades de su contenido. Existen 7 posibles contenedores y se explican brevemente en el cuadro “Los 7 tipos de contenedor”. No deseo aburrirlo ya que quiero que siga leyendo mi entrega de XAML, y debido a ello veremos en esta segunda parte del curso solamente algunos de los contenedores, y en próximas conoceremos más sobre el resto.

ado empleando varias de las características, mientras que la figura 3 exhibe su resultado.

a las propiedades “Left” y “Top” del panel principal para indicar su posicionamiento dentro del mismo. Véase el resultado en la figura 4.

Canvas... el modelo tradicional

DockPanel

El marco “Canvas” es uno de los más sencillos de utilizar ya que ofrece un modelo cartesiano, ésto es, que los elementos pueden ser posicionados en un valor fijo del eje vertical y horizontal respectivo al contenedor. El listado 3 emplea un “Canvas” principal y luego otros secundarios que almacenarán diferentes rectángulos de distintos colores. Por último se dibuja un botón directamente sobre el control principal, lo que nos servirá nuevamente para ver cómo un elemento secundario interactúa con la jerarquía. En este caso el botón hace referencia

“DockPanel” organiza los elementos contenidos en forma horizontal o vertical uno con respecto al otro. Cada control integrante puede establecer una propiedad llamada “Dock”, la que brinda cinco opciones: “Top” (arriba), “Bottom” (abajo), “Left” (izquierda), “Right” (Derecha), o “Fill” (rellenar). En tiempo de ejecución “DockPanel” examinará las propiedades de cada integrante y determinará su posición con respecto al miembro anterior, así como también si deberá o no cubrir todo el panel. A su vez el

TextPanel... el más sencillo Con “TextPanel” es sencillo darle formato a los textos y afortunadamente utiliza nomenclatura en muchos casos comparable con algunas etiquetas HTML. Ello hace que sea fácil comprender su funcionamiento. Básicamente es posible especificar desde diferentes tipos de letras a bloques, pasando por párrafos o listas de elementos, así como también jerarquía de títulos. El listado 2 muestra cómo exhibir un texto formateSOLO PROGRAMADORES nº 122

28

Figura 3. El código del listado 2 en ejecución.


MIDDLEWARE

XAML (II)

LISTADO 3

tamaño del control se puede especificar como porcentaje de “DockPanel”, lo que hará que si se cambia el tamaño del panel también se modifique el de sus integrantes. El listado 4 utiliza un panel principal y 2 paneles secundarios; estos últimos ocuparán cada uno el 50% del área. El primero definirá varios botones de tamaño y posición relativa, mientras que el segundo es un botón que cubrirá la totalidad del espacio. El resultado puede verse en la figura 5.

FlowPanel “FlowPanel” es utilizado para gestionar contenido que pueda en algún momento ocupar más de una línea y tenga que ser reorganizado dinámicamente. Básicamente este panel contiene propiedades para indicar el alineamiento y qué hacer si se sobrepasa la línea. A su vez el panel puede reacomodar sus miembros de forma que se utilice mejor el espacio. El listado 5 muestra cómo “FlowPanel” reorganiza automáticamente su contenido cuando el tamaño del panel es menor que el de la longitud de sus elementos (véase la figura 6).

ViewBox Hablamos ya brevemente de “ViewBox” al comienzo de este capítulo pero solamente nos basamos en su funcionamiento. Como habrá visto, este panel ajusta dinámicamente el contenido a su nuevo tamaño, pero a diferencia con otras aproximaciones, el mismo es realmente escalado en vez de limitarse solamente a disminuir los espacios o tamaño de los controles. Como podemos apreciar en el listado 6 se



Combinación de Canvas

LISTADO 4

Organizando elementos con DockPanel

cuenta con propiedades de alto y ancho máximo, lo que lógicamente indicará que en caso de sobrepasarse la altura o ancho el contenido se fije utilizando esta información (véase de nuevo la figura 1). Debe tener en cuenta que “ViewBox” puede contener un sólo control secundario, por lo que en caso de que desee insertar más de

ellos tendrá que adicionar alguno de los paneles vistos anteriormente y luego ya sí dentro del mismo los elementos que desee.

Recursos y estilos En XAML es muy sencillo personalizar la apariencia de los controles y de la aplicación


29


MIDDLEWARE

LISTADO 5

Reorganizando el contenido con FlowPanel


mediante la utilización de estilos. Cuando digo personalizar la apariencia veremos que es mucho más flexible que tan sólo modificar los colores. Sin embargo, antes de explicar qué es un estilo debemos comprender qué son los recursos. Preste atención al listado 7. Este código define un nuevo recurso llamado “Micolor” que es un relleno de color Rojo y sólido. Este elemento pasa a ser parte de la colección de recursos del panel. Cada elemento en XAML puede contar una colección de estos. De esta forma es posible definir uno o más miembros en el control que usted desee, pero en general se establece en el elemento principal con el fin de que pueda ser utilizado por los controles de la jerarquía. Una vez que el recurso es creado pasará a estar disponible para los otros objetos, esto es, como suministro de valor para una o más propiedades. Siempre se debe hacer referencia al recurso utilizando llaves, y recordando que se diferencia entre mayúsculas y minúsculas. La siguiente línea establecerá como fondo del botón el relleno definido en el recurso del panel:

LISTADO 7

Definiendo un nuevo recurso

En este caso se ha definido un botón de plantilla que contiene el posible estilo a utilizar. Aquí se incluye el color de fondo, de fuente y la altura, pero nada con respecto al resto de las propiedades. En tiempo de ejecución se dibujará el botón utilizando el estilo y posteriormente se aplicarán los valores establecidos en el propio control. Para el caso de haber un conflicto siempre se descartará el valor del estilo quedando el del elemento en sí.

Conclusiones Hasta aquí hemos llegado, sé que nos falta mucho por ver y como siempre hay poco espacio. En la próxima entrega seguiremos avanzando en el tema de estilos ya que le brinda mucha flexibilidad (aquí simplemente he hecho una breve reseña). Además conoceremos más sobre controles y documentos. Hasta el mes que viene. http://digital.revistasprofesionales.com

CD-ROM

Contenido del CD-ROM Fuentes Juegos de calidad comercial en J2ME (I) Antes de iniciar el diseño y desarrollo de una aplicación sobre un terminal móvil, es necesario conocer las capacidades y limitaciones del mismo. En esta primera entrega, hemos preparado una pequeña aplicación que “interroga” al teléfono móvil (o emulador) y muestra por pantalla ciertas características que nos serán de máximo interés para el desarrollo de nuestro juego.

XAML (II) Como se ha venido comentando a lo largo de estas dos entregas, XAML puede revolucionar el sector con un nuevo modelo de programación declarativo para las interfaces de usuario. En este punto, el lector encontrará ejemplos de interfaces programadas con XAML. En las páginas del artículo se explica cómo y dónde obtener las aplicaciones para visualizar estas interfaces gráficas.

Servlets Filters (I) Podríamos encontrar muchísimas utilidades para un filtro en una aplicación web. En esta ocasión, ofrecemos la implementación de un filtro que “procesará” aquellas peticiones que demanden una imagen. Este ejemplo puede servir de base para que el lector inicie a partir de aquí sus propios desarrollos.

Desarrollo visual de IGUs Java Eclipse es una de las plataformas de desarrollo más populares para los programa-


32

dores Java. En esta sección se incluye el proyecto que se ha venido desarrollando en el artículo.

Programación AndroMDA 3.0M3 AndroMDA es una herramienta construida siguiendo el paradigma del desarrollo de software dirigido por modelos, o más concretamente, la propuesta MDA (Model Driven Architecture) de OMG. Para aquellos no iniciados en los conceptos que esconde MDA, diremos que este paradigma propone un modelo de desarrollo de

do, en gran parte, las cuestiones tecnológicas referidas a la implementación. En última instancia, se pretende que las aplicaciones puedan ser menos vulnerables a los cambios tecnológicos. Por ejemplo, AndroMDA es capaz de recibir como entrada un modelo conceptual (diseñado con una herramienta CASE) y generar a partir de él el código que lo implementa.

CMS Los Sistemas Gestores de Contenidos (CMS) son una buena opción para el desarrollo de portales web. Sin duda es una buena noticia el disponer de una oferta tan variada de CMS, sin embargo, la pregunta resulta obvia: ¿Cómo saber qué CMS es el mejor para mi? El lector encontrará en el CD-ROM las últimas versiones de los CMS PostNuke (orientado al trabajo con Apache, MySQL y PHP), OpenCMS y Magnolia (estos dos últimos pensados para la plataforma J2EE). Recomendamos visitar el site http://www.opensourcecms.com, pues en él hay multitud de contenidos de interés, tanto para quienes estén interesados en iniciar un desarrollo con un CMS, como para quienes quieran ampliar sus conocimientos sobre este tipo de productos.

Resin 3.0.10 Resin es un servidor de aplicaciones Java Open Source que recientemente ha sido liberado con licencia GPL. Tomcat y Resin son los contenedores de Servlets más populares, sin embargo Resin se diferencia en algo fundamental: también dispone de un contenedor de EJBs.

software basado en enfatizar las tareas de especificación, dejando que la lógica sea implementada de forma automática por las herramientas (como por ejemplo Andro MDA). Uno de los objeti- Y además… vos de MDA sería, por Al margen de los productos comentados ejemplo, permitir que anteriormente, en el CD-ROM de este mes alguien con un buen encontraremos la implementación de refeconocimiento del domi- rencia de la especificación Java Portlet nio en el que va a traba- (Pluto 1.0.1), JCrawler (véase la sección jar la aplicación y con “javaHispano”), la plataforma Eclipse con conocimientos de UML, los plug-ins necesarios para convertirlo en pudiera desarrollar el un editor visual de IGUs y la librería ACE software desconocien- para los programadores C++.


MIDDLEWARE

Desarrollo visual de IGUs Java OSCAR COMBARROS, IRENE JIMÉNEZ

VE es un plug-in Open Source de Eclipse que permite el desarrollo rápido de interfaces de usuario. Con Eclipse y VE es posible desarrollar interfaces de usuario con Java Swing tan rápida y fácilmente como lo haríamos en un entorno de desarrollo del estilo Visual Basic. Introducción En el presente artículo trataremos de hacer una introducción al desarrollo de interfaces de usuario con la herramienta Eclipse VE usando el API de Java JFC/Swing. Eclipse es uno de los entornos de desarrollo Java más populares en la actualidad, y los lectores pudieron profundizar en su arquitectura en el número 120. Uno de los problemas más comunes con los que se encuentra un nuevo desarrollador al empezar con Eclipse es el desarrollo de las interfaces de usuario de manera fácil. El SDK de Eclipse no incluye una herramienta para el desarrollo visual de los interfaces, como pueden incluir otras herramientas de desarrollo como JBuilder o NetBeans que permiten crear la interfaz gráfica de manera sencilla simplemente arrastrando componentes desde una paleta. Sin embargo Eclipse soluciona este problema con Eclipse VE (Visual Editor).

Figura 1. Arquitectura de plug-ins de Eclipse.


36

VE es un plug-in que extiende Eclipse y que permite el desarrollo de los interfaces de usuario de manera muy sencilla, y que presenta varias ventajas sobre otros competidores como por ejemplo el implementar varios APIs diferentes como AWT, Swing o SWT. En el presente artículo haremos una introducción mediante un ejemplo práctico a VE, veremos cómo instalarlo, y las posibilidades que tiene para el desarrollo automático de interfaces de usuario. Como el lector recordará, en los números 117, 118, 119 y 120 se publicó el curso “Creación de interfaces con JFC/Swing” acerca de la librería gráfica Swing, sin embargo para seguir el presente artículo no será necesario tener grandes conocimientos sobre esta librería, pues precisamente eso es lo atractivo del plug-in VE.

Instalación de VE Eclipse no es solo un entorno de programación, está diseñado como una plataforma de desarrollo que implementa una serie de servicios básicos, y que puede ampliarse mediante los tan conocidos plugins. Un plug-in es una unidad de ejecución que amplia la funcionalidad de la plataforma. De hecho la plataforma propiamente dicha apenas ofrece funcionalidad, básicamente permite gestionar recursos y manejar programas Java, y en el SDK que es la distribución normal de Eclipse se incluye la plataforma junto con varios plug-ins que permiten ampliar dicha funcionalidad, como se vio en su momento con el artículo “Desarrollo J2EE con herramientas Open Source” publicado en el número 120. En la figura 1 se puede ver un esquema de la estructura de Eclipse, la caja gris representa la distribución básica de Eclipse, el Eclipse SDK que como se puede ver a su vez incluye la plataforma y una serie de plugins básicos. Dicho SDK se puede ampliar con otros plug-ins, en la imagen las cajas con el texto “New tool”. La comunidad Open Source se ha volcado con el desarrollo de distintos plug-ins para Eclipse, además de los plug-ins desarrollados por IBM, padre del proyecto Eclipse y que aún le proporciona soporte. Eso hace que en la actualidad existan plug-ins para Eclipse para hacer prácticamente cualquier cosa, desde editar XML, desplegar EJBs en los servidores más comunes, desarrollo con J2EE, Antlr… VE no es más que eso, un plug-in que amplia la capacidad de la plataforma Eclipse para permitir la http://digital.revistasprofesionales.com

MIDDLEWARE

Desarrollo visual de IGUs Java

creación gráfica de interfaces de usuario de manera fácil. La instalación de un plug-in es muy simple, basta con copiar los ficheros del plug-in en los directorios adecuados de Eclipse, esto es, los directorios “Plugins” y “Features”. VE se puede obtener de la dirección http://www.eclipse.org/ vep/. Como se indica en la página de descarga, para que VE funcione correctamente deben estar instalados otros dos plug-ins, EMF y GEF. En la misma página de descarga de VE se pueden obtener enlaces a esos dos plug-ins. Nosotros usaremos durante el artículo las versiones Eclipse 3.0.1, VE 1.01, EMF 2.0.1 y GEF 3.0.1 (incluidas en el CD-ROM). Una vez obtenidos los ficheros de los plug-ins basta con descomprimirlos y copiar el contenido del directorio descomprimido “Features” bajo el directorio “Features” de Eclipse y el contenido del directorio “Plugins” bajo el directorio “Plugins” de Eclipse. Con solo copiar esos ficheros y volver a lanzar Eclipse los nuevos plug-ins quedan instalados y ya podemos ver la nueva funcionalidad de la plataforma. Para comprobar que todo ha sido correcto, basta con seleccionar la opción “File”>“New”->“Other”. Como veremos ahora, bajo la carpeta Java aparecen un gran número de opciones que no aparecerían antes, como por ejemplo “Visual Class”, “Swing”…

Hola Mundo Ya tenemos instalado correctamente VE, vamos ahora a crear la primera clase de la interfaz de usuario con VE. Para ello creamos un proyecto Java y a continuación elegimos la opción “File”>“New”->“Other”->“Visual Class”. Una clase Visual no es más que una clase normal Java que hereda de alguna de las clases visuales posibles de la API elegida, en nuestro caso Swing, y que implementa ya los métodos necesarios. Aparecerá una nueva ventana, en ella debemos especificar el nombre de la clase y el paquete, además debemos escoger qué tipo de clase queremos crear. En la parte izquierda de la pantalla aparece un listado con todas las clases visuales posibles, dependiendo de si queremos usar AWT, SWT o Swing. Nosotros vamos a usar Swing, y veremos que es posible elegir entre crear Frames, Paneles, Windows, Applets… en resumen todos los posibles contenedores de componentes Swing. En este primer ejemplo vamos a elegir crear un “Frame” y le vamos a especificar que deseamos que nos añada a la clase un método “main”. Una vez seleccionadas estas opciones VE se http://digital.revistasprofesionales.com

encarga de generar todo el código necesario por nosotros y nos abre el editor visual de la clase, en la figura 2 podemos ver las partes principales del editor. En primer lugar en la parte de la imagen etiquetada con un 1 podemos ver cómo verá el usuario la clase en tiempo de ejecución. En esta parte del editor es posible cambiar, por ejemplo, el tamaño del Frame simplemente arrastrando los bordes. En la zona 2, podemos ver el código Java generado automáticamente, estas dos zonas están conectadas de manera que si por ejemplo cambiamos el tamaño del Frame en la zona 1, veremos que se modifica el código Java del método “initialize”, que es donde se especifica el tamaño del Frame en la zona 2. De igual manera, si modificamos el método “initialize” y cambiamos la línea que especifica “this.setSize(300,200);” por “this.setSize(400,200);”, veremos cómo se cambia el tamaño del Frame en la zona 1. La zona 3 es la paleta. La paleta sirve para añadir nuevos componentes a la clase creada, como podemos ver incluye todos los componentes Swing posibles. Desde la paleta es posible añadir un componente al Frame simplemente arrastrando y soltando, y automáticamente se añade el código necesario a la clase. La cuarta zona es la vista de JavaBeans. Los componentes de Swing se empaquetan en Beans, en esta parte de la pantalla podemos ver los Beans que se han creado. Si nos fijamos en ella veremos que ahora tenemos creado un Bean llamado “this” que es de tipo “JFrame”, si lo seleccionamos vemos que se selecciona la pantalla completa del Frame en la zona 1, y en la zona de código se selecciona el método “initialize” que es donde se inicializa el Frame. Debajo de ese Bean se puede ver que se ha creado una clase de tipo “JContentPane”. Si la seleccionamos vemos que se selecciona la parte interior del Frame que aparece en gris en la pantalla, y en la zona de código el método “getJContentPane” que es donde se crea esa clase. Así pues, de momento tenemos un Bean de tipo “JFrame” que a su vez contiene otro Bean de tipo “JContenPane”. Cuando añadamos sucesivamente componentes al Frame, veremos cómo dichos componentes se van creando bajo el “JContentPane”. Por último, la zona 5 es la zona de las propiedades del componente. Esta zona cambia dependiendo del componente seleccionado, según las posibles propiedades del mismo. Por ejemplo, en el caso del Frame podemos editar propiedades como por ejemplo el “Layout”. Si cambiamos las propiedades de la zona 5 se modifica automáticamente el código generado en la zona visual (zona 1) y en la zona de código (zona 2).

Vamos ahora a probar el editor visual. En primer lugar vamos a modificar algunas de las propiedades del Frame creado. Modificamos la propiedad “Visible”, que a priori está fijada a “false”, y la modificamos, fijándola a “true”. A continuación modificamos la propiedad “Title” y le ponemos como título al Frame la cadena, “Hola Mundo”. Ahora vamos a comprobar cómo se vería nuestra aplicación en tiempo de ejecución. Hay dos maneras distintas de ejecutar la aplicación. Puesto que estamos realizando un JavaBean podemos ejecutar simplemente al Frame como si fuera un Bean, o añadir el código necesario al método “main” para que se ejecute como una aplicación normal. Durante el tiempo de desarrollo es normal el ejecutar simplemente como Bean la aplicación para ver el aspecto que tiene aunque ésta solución solo sirva para tiempo de desarrollo. Para ejecutar la aplicación como un Bean, seleccionamos en la vista de Beans (zona 4) el Bean del Frame y ejecutamos la opción “Run”>“Run as”->“Java Bean”. Veremos el resultado de la ejecución de la aplicación y el aspecto que tiene. La otra forma de ejecución también es muy simple, y consisten en añadir al método “main” creado la siguiente línea: public static void main(String[] args) { HolaMundo hm = new HolaMundo(); }

Como puede verse, lo único que hemos hecho es crear una nueva instancia de la clase, que en nuestro caso se llama “HolaMundo”. Como dicha clase ya implementa todos los métodos necesarios de “JFrame”, no es necesario hacer nada más. Ahora ejecutamos la aplicación como una aplicación normal Java, opción “Run”->“Run as”>“Java Application”. Como vemos el resultado final es el mismo de cualquiera de las dos formas de ejecución. En este apartado hemos creado nuestra primera y muy simple interfaz de usuario. Como hemos visto es muy sencillo el crear de manera visual la interfaz, pero a continuación analizaremos el código que nos ha generado VE y complicaremos el ejemplo con nuevas funcionalidades.

Un ejemplo más avanzado Si nos fijamos en el código generado por VE, y que aparece en el listado 1, veremos que es muy simple. Solo ha creado una clase que hereda de “JFrame” y que tiene un “JPanel”. En el constructor de la clase se llama a un método de iniciali-

37


MIDDLEWARE

Figura 2. Desarrollando con Eclipse y VE.

zación el cual se ocupa de fijar propiedades del Frame, como son el tamaño o el título. A su vez la clase tiene un campo “jContentPane” que es una instancia de una clase “JPanel” y que será el panel donde se fijará el contenido del Frame, dicho panel se inicializa en un método “getJContentPanel” si no estaba inicializado anteriormente. Como se puede ver el código generado es bastante limpio y fácil de seguir. Fijémonos ahora en la de componentes Swing. Dicha paleta tiene todos los componentes posibles de una interfaz Swing, organizado en 3 grupos, “Componentes”, donde se almacena el grueso de los componentes, como pueden ser botones, campos de texto, etiquetas, barras de progreso… “Containers” donde se almacenan los componentes que a su vez pueden contener a otros componentes, como pueden ser los paneles y los Frames, y finalmente “Menus” donde están los componentes de los menús. Ahora podríamos añadir cualquiera de estos componentes a la ventana que tenemos creada simplemente arrastrando y soltando, sin embargo ya que queremos presentar las posibilidades de VE vamos a elegir otro enfoque. Vamos a crear un panel personalizado, con una serie de componentes sencillos y luego vamos a insertar en la pantalla principal de la aplicación el Panel personalizado que crearemos. Para crear el panel elegimos la opción “New”>“VisualClass” y en la pantalla que ya vimos antes elegimos crear un panel, y lo llamamos “MiPanel”.


38

Al nuevo panel que nos crea VE le vamos a cambiar algunas propiedades, en primer lugar le modificamos la propiedad del “Layout”. Por defecto un panel se crea con la propiedad layout fijada a “FlowLayout”, en nuestro caso la cambiaremos por un valor “null”. A continuación añadiremos a este panel un par de componentes, añadiremos una etiqueta (“JLabel”) a la que le cambiamos el campo “Text” por “Nombre”, un botón (“JButton”) al que le ponemos como texto “OK” y un campo de texto (“JTextField”), hasta crear un diseño parecido al que se puede ver en la figura 3. LISTADO 1

Para alinear los tres componentes, igualar la distancia entre ellos y este tipo de cosas existen las propiedades de alineado, se puede acceder a ellas pulsando el botón de “Customize layout” de la barra de tareas. En la figura 4 se puede ver resaltado en rojo el botón a seleccionar y la ventana que aparece. La ventana de “Customize Layout” permite ajustar los componentes a la parte superior del panel, igualarlos en alto y ancho, distribuirlos entre el espacio tanto horizontal como vertical del panel… con lo cual fácilmente se consigue un diseño más profesional. Podemos comprobar la apariencia del panel seleccionándolo en la vista de Beans y eligiendo “Run”->“Run As” ->”JavaBean” al igual que hicimos antes con el Frame. Una vez que el panel ya tenga el diseño que queremos vamos a añadirle el código necesario para que lleve a cabo alguna acción. Como podemos ver en el listado 2, el código generado por VE es bastante simple, para cada componente añadido al panel crea un campo de la clase del tipo oportuno, y en el método “initialize” configura propiedades del panel como el Layout y le añade como hijos los objetos anteriores tras inicializarlos. El objetivo de nuestro panel será almacenar el texto que introduzca el usuario en una propiedad del panel llamada “Nombre”, de tipo “String” y a dicha propiedad le añadiremos un método para fijarle el valor y para recogerlo, por lo tanto habrá que añadir el siguiente código: private String nombre = “N/A” ; public String getNombre()

Código del Frame generado automáticamente

import javax.swing.JFrame; public class HolaMundo extends JFrame { private javax.swing.JPanel jContentPane = null; public static void main(String[] args) { ... } public HolaMundo() { super(); initialize(); } private void initialize() { this.setSize(400,200); this.setContentPane(getJContentPane()); this.setTitle(“HOLA MUNDO”); this.setVisible(true); } private javax.swing.JPanel getJContentPane() { if(jContentPane == null) { jContentPane = new javax.swing.JPanel(); jContentPane.setLayout(new java.awt.BorderLayout()); } return jContentPane; } }


MIDDLEWARE


{ return nombre; } public void setNombre(String string) { this.nombre = string; }

Ahora ya tenemos preparada una propiedad en la que almacenar el valor que introduzca el usuario en el campo de texto. Vamos a querer en el futuro que el Frame, o cualquier otro Bean de la IGU que contenga el panel, sea notificado cuando se produzca alguna modificación en el campo nombre del panel, así que cambiaremos el método “setNombre” creado antes por el siguiente código: public void setNombre(String string) { String old = this.nombre; firePropertyChange(“nombre”,old,string); getJTextField().setText(string);

Figura 3. Panel personalizado. private JTextField getJTextField() {

this.nombre = string;

Como se puede observar, básicamente lo que hemos hecho es invocar a un método “firePropertyChange”. Este método se ocupa de lanzar un evento indicando que la propiedad se ha modificado. De esta manera, para que cualquier otro objeto se entere de que se ha modificado la propiedad, basta con que implemente un manejador del evento que genera el método “setNombre”, veremos más adelante cómo hacerlo.

Eventos Ya tenemos creada nuestra propiedad donde almacenar el valor, pero ahora necesitamos enterarnos de cuándo el usuario introduce un nuevo texto en el campo de texto o cuándo pulsa el botón de OK. La manera con la que Swing interactúa con el usuario es mediante eventos. La gestión de eventos es una de las partes más complicadas de programar con Swing y por este motivo fue tratada con amplitud en el curso sobre Swing publicado en Sólo Programadores . Vamos a ver cómo se convierte en algo automático cuando usamos VE. Vamos a añadir el código necesario a la caja de texto para que ésta reaccione ante un evento. Primero la seleccionamos y pulsamos el botón derecho del ratón, nos aparecerá un menú emergente en el que seleccionamos la opción “Events”->“Action Performed”. Veremos que automáticamente se nos modifica el método “getTextField” y se añade el código del manejador (listener) que se muestra a continuación: http://digital.revistasprofesionales.com

event.ActionEvent e)

…

}

public void actionPerformed(java.awt.

jTextField.addActionListener (new java.awt.event.ActionListener() { public void actionPerformed(java. awt.event.ActionEvent e) {System.out.println(“action Performed()”);} }); … }

Como podemos ver el manejador del evento creado sólo escribe por la consola un mensaje de texto. Podemos modificar esa línea para añadir la inteligencia que queramos al manejador. Nosotros vamos a modificar esa línea y cambiarla por una que fije la propiedad al valor introducido en el campo de texto:

{setNombre( jTextField.getText());}

Ahora cuado el usuario escriba algo en el campo de texto, dicho valor se fijará en la propiedad “Nombre” del panel, y el método que lo fija, “setNombre”, se ocupará de lanzar un evento indicando que la propiedad se ha modificado. Como podemos ver con VE se facilita mucho la gestión de eventos. Si en lugar de seleccionar la opción de “Action Performed” hubiéramos seleccionado la opción “Add Events”, nos aparecería una nueva ventana en la cual podríamos ver catalogados por secciones todos los eventos posibles, como por ejemplo eventos que respondan cuando una tecla es pulsada, etc. En esa pantalla podremos añadir un manejador de cualquiera de los eventos que se puedan producir. Vamos a repetir el proceso para añadir un evento a la pulsación del botón, para ello selec-

Figura 4. Alineando los componentes.

39


MIDDLEWARE

LISTADO 2

Código del panel generado automáticamente

public class MiPanel extends JPanel { private JLabel jLabel = null; private JTextField jTextField = null; private JButton jButton = null; public MiPanel() { … } private void initialize() { this.setLayout(null); this.setSize(271, 56); jLabel = new JLabel(); jLabel.setBounds(31, 21, 53, 20); this.add(jLabel, null); this.add(getJTextField(), null); this.add(getJButton(), null); } private JTextField getJTextField() { if (jTextField == null) { jTextField = new JTextField(); jTextField.setBounds(100, 21, 53, 20); } return jTextField; } private JButton getJButton() { if (jButton == null) { jButton = new JButton(); jButton.setBounds(168, 21, 53, 20); jButton.setText(“OK”); } return jButton; }

“MiPanel”. Cuando seleccionemos el Bean nos aparecerán resaltadas sobre el Frame las distintas zonas en las que podemos insertar el nuevo componente, y arrastraremos el componente seleccionado sobre la zona que queramos, al igual que haríamos con un componente normal añadido desde la paleta. En este ejemplo la arrastraremos a la zona central del Frame. Como vemos, el Panel que habíamos creado antes se inserta en el Frame que será la pantalla principal de nuestra aplicación. Como no vamos a añadir más componentes a la pantalla pues podemos redimensionar la pantalla para que se ajuste mejor al tamaño del Panel que hemos insertado. El código que VE nos ha generado para insertar el Panel en la pantalla principal es el siguiente: private MiPanel miPanel = null; private MiPanel getMiPanel() { if (miPanel == null) { miPanel = new MiPanel(); } return miPanel;

} }

cionamos el botón y con el botón derecho seleccionamos las mismas opciones, esto es, “Events”->“Action Performed”, y vemos cómo se añade un código muy parecido al que se añadió al campo de texto, y de igual manera cambiamos la línea que escribe por pantalla un mensaje, por una que fije el valor a la propiedad “Nombre” del panel: private JButton getJButton() { … jButton.addActionListener(new java. awt.event.ActionListener() { public void actionPerformed(java. awt.event.ActionEvent e) {setNombre( jTextField.getText());} }); … }

Ya tenemos casi completo nuestro panel, nos hemos ocupado de que tenga el aspecto que queremos y ahora hemos implementado las acciones que queremos que realice, sólo nos falta un paso, que consiste en añadir una línea al método que inicializa el campo de texto para hacer que al iniciarse tenga el valor de la propiedad “Nombre”: … private JTextField getJTextField() {


40

… jTextField.setText(nombre); … }

Si nos fijamos ahora en la vista de JavaBeans (véase la figura 3), veremos que se han añadido los eventos creados debajo del botón y del campo de texto.

Uniendo nuestro Panel con el programa principal Hasta el momento hemos aprendido a mane jar VE para crear componentes complejos que contengan diferentes componentes de Swing y a gestionar los diferentes eventos de estos componentes fácilmente. En este apartado vamos a unir la pantalla principal de nuestro programa y el panel creado, además vamos a ver cómo crear un manejador que reaccione cuando se modifique la propiedad del panel. Primero seleccionamos el Frame principal, y pulsamos el botón de la barra de tareas de elegir Bean, el botón que aparece resaltado en un círculo rojo en la figura 3 (parte superior derecha de la figura). Nos aparecerá una pantalla en la cual podemos buscar los JavaBeans disponibles. Escribimos en nuestro caso el nombre que le hayamos puesto al panel, en este ejemplo

Si ahora pinchamos en la zona del panel de la pantalla principal y miramos las propiedades veremos que tiene una propiedad llamada “Nombre” que como vimos antes es el campo del Panel donde almacenamos el texto que nos introduzca el usuario en la GUI. Vamos a añadirle al Frame el manejador que se ocupe de llevar a cabo alguna acción cuando el usuario teclee algo en la caja de texto y pulse el botón de OK. Para ello seleccionamos el panel y pulsamos el botón derecho del ratón para seleccionar la opción “Events”->“Add Events”. Esta opción nos conduce a una pantalla en la cual podemos seleccionar todos los eventos posibles, en este caso abrimos la categoría “Property Change” y seleccionamos la propiedad “Nombre”, en la parte derecha de la pantalla nos aparece la nomenclatura que deseamos para el manejador del evento, en este ejemplo seleccionamos la segunda opción, la que nos pide dos parámetros en el manejador. Podemos ver el código que nos genera VE en el listado 3. Como ocurría en ocasiones anteriores, el manejador creado automáticamente solo imprime por pantalla un mensaje, en este ejemplo de juguete vamos a dejar el manejador tal y como está. Ya tenemos prácticamente lista la aplicación, solo nos falta un detalle, y es indicar a la pantalla principal qué hacer cuando el usuario la http://digital.revistasprofesionales.com

MIDDLEWARE


cierre. El proceso es el mismo que hemos hecho antes, generar un manejador que responda a un evento, en este caso el cierre de la ventana. Seleccionamos el Frame y pulsamos el botón derecho, en el menú emergente que aparece seleccionamos “WindowClossing”, y modificamos el manejador que nos genera VE, añadiendo el código “System.exit(0);” como vemos en el listado 4. Ya tenemos la aplicación lista, ahora podemos ejecutarla y comprobar que si introducimos un nuevo texto en la caja de texto y pulsamos el botón de OK, en la consola se imprime un mensaje indicando que se ha modificado la propiedad. El enfoque que hemos elegido de crear un panel y a ese panel añadirle los componentes sencillos y luego insertar el panel en la pantalla principal de la aplicación puede parecer excesivamente complicado. En realidad habríamos conseguido el mismo efecto si directamente hubiéramos insertado en la pantalla principal de la aplicación una etiqueta, un campo de texto y un botón. Sin embargo la opción elegida es mucho más flexible. Si imaginamos una aplicación real, en la cual puede haber multitud de pantallas en las que se repitan formularios, por ejemplo para pedir los datos personales de una persona, este enfoque nos permite reutilizar el código generándolo solo una vez, he insertando el panel en tantos sitios como nos haga falta. Y lo que es más importante, nos permite que modificando una sola vez el panel (por ejemplo para eliminar errores) se modifique en todos los puntos de la aplicación.

El Look And Feel La aplicación ya tiene toda la funcionalidad que queremos pero su apariencia (Look And Feel) no es demasiado actual. En este apartado vamos a ver cómo VE nos facilita el trabajar con diferentes Look And Feels. Para cambiar el Look And Feel con el que diseñamos nuestros componentes tenemos que modificar las propiedades de VE, para ello

LISTADO 3

Listener de cambio de propiedades generado automáticamente

private MiPanel getMiPanel() { if (miPanel == null) { miPanel = new MiPanel(); miPanel.setNombre(“N/A”); miPanel.addPropertyChangeListener(“nombre”, new java.beans.PropertyChangeListener() { public void propertyChange(java.beans.PropertyChangeEvent e) { System.out.println(“propertyChange(nombre)”); } }); } return miPanel; }

LISTADO 4

Código de finalización de la aplicación

private void initialize() { this.setTitle(“Hola Mundo”); this.setSize(351, 90); this.setContentPane(getJContentPane()); this.setVisible(true); this.addWindowListener(new java.awt.event.WindowAdapter() { public void windowClosing(java.awt.event.WindowEvent e) { System.exit(0); } }); }

vamos al menú “Windows”->“Preferences” para abrir la pestaña de “Java”->“VE”. Nos aparece una pantalla con un apartado con los distintos Look And Feel de Swing, y veremos que no aparece seleccionado ninguno. Vamos a seleccionar el Look And Feel de Windows. A continuación cerraremos todas las pantallas que tenemos abiertas, la del Panel y la del Frame y las volvemos a abrir para que VE coja las nuevas propiedades. Como veremos el aspecto del Panel cambia bastante, y su aspecto es mucho más atractivo ahora. Siguiendo estos pasos podemos cambiar el Look And Feel que nos muestra el editor, lo cual es fundamental para comprobar que la IGU se va a comportar como esperamos en cualquier entorno. Si queremos que la aplicación coja un Look And Feel determinado en tiempo de ejecución dependiendo del sistema operativo sobre el que se ejecute, debemos añadirle algo de código a nuestra aplicación. Modificaremos el método “main” del programa añadiéndole las siguientes líneas: public static void main(String[] args) { try { UIManager.setLookAndFeel(UIManager. getSystemLookAndFeelClassName()); } catch (Exception e) {e.printStack Trace();} HolaMundo hm = new HolaMundo(); }

Figura 5. Diferentes Look And Feel.


Si ahora ejecutamos de nuevo la aplicación veremos que se ejecuta con el Look And Feel correcto.

Cuando estamos desarrollando una aplicación que deseamos que se ejecute sobre distintos sistemas operativos (por ejemplo Windows y Linux) es importante el probar diferentes Look And Feels para comprobar que cuando ejecutemos la aplicación en un entorno distinto del de desarrollo no nos llevemos una sorpresa desagradable. En la figura 5 podemos ver el aspecto de la aplicación con distintos Look And Feel, en este caso “Metal”, “Windows” y “CDE/Motif”. Como podemos ver el aspecto que presentará la aplicación si la ejecutamos con un Look And Feel “Motif” no es el esperado, si queremos que la aplicación presente un aspecto correcto en todos los entornos sería conveniente el cambiar el tamaño del botón.

Conclusiones VE permite desarrollar interfaces gráficas de usuario de manera sencilla y rápida, facilitando el desarrollo especialmente a programadores que no son expertos en Swing. La característica más apreciable de VE es la limpieza del código que genera, al contrario que otras aplicaciones de generación gráfica de código, el código generado por VE es bastante limpio y fácil de seguir. Todo ello con el añadido de ser una herramienta que al igual que Eclipse es Open Source y totalmente gratuita. Como única pega se podría mencionar que al igual que Eclipse, para desarrollar de manera fluida necesita de una máquina bastante potente, pero al ritmo que avanza el hardware esto no parece un problema demasiado importante.

41


REDES

Sistemas de Gestión de Contenidos (y II) ALVARO ZABALA ORDÓÑEZ

Para concluir con nuestra revisión a los Sistemas de Gestión de Contenidos veremos las dos grandes familias de CMS existentes (PHP y Java) y describiremos brevemente el API de Portlets, iniciativa que trata de estandarizar la construcción de componentes de portal para el mundo Java. El mes pasado vimos una clasificación de CMS que consideraba tres grandes familias: sistemas basados en PHP, sistemas basados en Java y sistemas basados en el empleo de otras tecnologías. Dentro de esta última familia repasamos las características del que posiblemente sea el CMS Open Source más maduro, Zope. También comentamos que al estar basado en una plataforma tecnológica inusual (base de datos propia orientada a objetos, lenguaje de programación Python) quizás no fuese

Figura 1. Portal de la comunidad de PHP-Nuke, uno de los primeros grandes CMS Open Source. SOLO PROGRAMADORES nº 122

42

la solución idónea para organizaciones que busquen una solución integrada. Seguidamente veremos con más detalle el resto de familias de CMS Open Source.

Soluciones CMS basadas en PHP En esta familia de CMS agrupamos a aquellas soluciones que se apoyan en lo que se viene a denominar la pila de tecnologías “LAMP”, es decir, Linux, Apache, MySQL y PHP. Estos CMS tienen la ventaja de que todas estas tecnologías son muy extendidas dentro del mundo del software libre, pero también tienen el inconveniente de que trabajan en un entorno más heterogéneo, que además debe ser coordinado con otros servidores de aplicaciones y bases de datos existentes en la organización que desea implantar el CMS. El lenguaje de script de servidor PHP está muy extendido, dispone de un amplio soporte y es de ejecución rápida. No obstante, todavía muchos expertos y analistas de sistemas no lo consideran una solución tan fiable para sistemas empresariales como las basadas en las plataformas J2EE o .NET, en gran parte debido a que el balanceo de carga no está tan fácilmente implementado como en las otras. Dentro de los CMS pertenecientes a esta familia cabe destacar PHP-Nuke, PostNuke y Midgard. PHP-Nuke y PostNuke son soluciones muy similares, como su propio nombre deja intuir, empleadas sobretodo para la construcción de portales temáticos de pequeño tamaño, dedicados al ocio, entretenimiento, o temas comunes. PostNuke fue desarrollado por un miembro original de la comunidad de PHP-Nuke que disentía de la dirección que éste estaba tomando. No obstante, el código de PostNuke fue sustituido para mejorar su rendimiento y seguridad. Partiendo de estos CMS han surgido numerosas derivaciones o “forks”, lo que no ha contribuido ni a fomentar el desarrollo de estos productos ni a facilitar la tarea de optar por alguno de ellos para su implantación. El punto fuerte de estas soluciones radica en la comunidad que las respalda. Existen numerosísimas extensiones de estos CMS disponibles para su http://digital.revistasprofesionales.com

REDES

Sistemas de Gestión de Contenidos (y II)

descarga en el web. Aún así, todavía deben avanzar muchísimo en materias como soporte para workflow, ciclo de vida de publicación, herramientas gráficas de administración, etc. Además, no ofrecen muchas opciones para diseñar la apariencia y distribución de los elementos del portal. Ésto hace que todos los sitios web creados con estos CMS tengan una apariencia muy similar. Midgard es un CMS muy maduro cuyo desarrollo fue iniciado en 1999. También está basado en PHP, MySQL y Apache, pero es de mayor robustez y escalabilidad que los anteriores, por lo que puede ser empleado para implementar portales empresariales de carga media o alta. Algunas de las características que dan un valor añadido a Midgard son la accesibilidad (a través del cumplimiento de las directrices WAI del W3C), el soporte para múltiples sitios web dentro de un mismo CMS, gracias a aplicar un modelo de bases de datos virtuales, y la incorporación de un motor de workflow basado en la tecnología XML.

Soluciones CMS basadas en la plataforma J2EE Actualmente la plataforma de desarrollo empresarial J2EE parece estar imponiéndose para la construcción de aplicaciones de lado del servidor. Por esta razón, existe un gran número de CMS desarrollados bajo esta pla-

Figura 2. Portal de Postnuke, el otro gran CMS Open Source en PHP.

taforma: OpenCMS, Magnolia, Jboss Nukes, Jahia, o incluso el CMS impulsado por la comunidad JavaHispano, colaboradora habitual de esta revista, Canyamo, con el que ésta ha desarrollado su portal web. Todos estos sistemas se benefician de las ventajas de la plataforma Java: portabilidad a todas las plataformas para las que haya disponible una máquina virtual, conectividad con cualquier tipo de base de datos mediante el estándar JDBC, integración con

servidores de aplicaciones J2EE, excelente soporte para el estándar XML y tecnologías derivadas como Web Services, motores de plantillas para el renderizado HTML, etc. No obstante, cada proyecto sigue sus propias pautas de desarrollo, y tiene sus propias políticas de calidad y diseños. Esto hace que la comunidad existente detrás de cada uno de ellos sea desigual. Como en este artículo no podemos hablar de todos ellos, comentaremos algunas de las principales características de dos de los más famosos: Magnolia y OpenCMS. Magnolia

El punto fuerte de Magnolia radica en su repositorio de contenidos, que ha sido construido según el estándar JCR (Java Content Repositories). Otro de sus puntos fuertes es el de su distribución, resultando bastante sencilla su instalación y puesta en marcha (característica bastante infrecuente en los proyectos de software libre). Además, no requiere de ninguna base de datos adicional. OpenCMS

Figura 3. Creación de workflows en OpenCMS.


OpenCMS comparte con Magnolia todos los beneficios derivados de utilizar la plataforma Java. Además, también resulta bastante sencillo de instalar. OpenCMS dispone de una comunidad más amplia que Magnolia pues ha surgido como un proyecto libre promovido por su propia comu43


REDES

nidad, al contrario que Magnolia que es desarrollado por una empresa que se encarga de mantenerlo. OpenCMS sí requiere de una base de datos para poder trabajar, e incorpora un motor de workflow al igual que el anterior. Su interfaz gráfica es muy amigable, siendo muy parecida a los exploradores de ficheros más corrientes. En ésta los recursos que forman parte del portal aparecen organizados de forma jerárquica, y en diferentes colores según su estado (en producción, bloqueado y siendo editado por un usuario o eliminado). Proporciona un editor WYSIWYG, al estilo de FrontPage, para la creación de contenidos desde la propia herramienta. También incluye un repositorio de recursos, como imágenes, scripts, etc. de forma que para incrustar uno de estos recursos en una página sólo hay que añadirlos al repositorio, y desde éste a la página que se está creando. Esto facilita notablemente la gestión de estos recursos, y evita su duplicidad. OpenCMS también proporciona herramientas gráficas para la creación de workflows. En la figura 3 podemos ver cómo gracias a esta herramienta se pueden crear tareas y asignárselas a usuarios dentro del workflow de creación de contenidos. Esta herramienta permite además el envío de correos electrónicos a los usuarios a los que se les ha asignado una tarea, la reasignación de la misma a otro usuario, y el envío de un correo notificando la finalización de una tarea a aquel usuario que la creó. OpenCMS es un sistema que se apoya totalmente en la base de datos. En este tipo de sistemas las páginas suelen ser creadas dinámicamente a partir del contenido de la base de datos y de las plantillas de presentación establecidas. Para evitar los problemas de rendimiento que esta característica podría ocasionar, OpenCMS incorpora un mecanismo de caché extensible. La primera vez que una página es solicitada, ésta es generada dinámicamente y almacenada en caché para posteriores peticiones. Cuando se producen modificaciones en el contenido de la base de datos al que está asociado la página, estos cambios son propagados automáticamente a la caché. No obstante, en el caso de que se requiera una versión estática del portal entero o de partes de éste, OpenCMS permite la exportación de estos directamente al servidor web. Ésto es SOLO PROGRAMADORES nº 122

44

Figura 4. Explorador de la estructura del portal de OpenCMS.

de gran utilidad para determinados contenidos que tienen un carácter muy estático, como imágenes o archivos binarios. Otro punto destacable de OpenCMS es la inclusión de características de seguridad: OpenCMS permite aplicar encriptado fuerte a todo el sitio web o a parte de él, etiquetando a sus contenidos como “sólo accesibles a través de conexiones HTTPS”.

Estandarización CMS en el mundo Java: el API de Portlets Como hemos visto a lo largo de estas dos entregas, el número de CMS y WCM existentes es cada vez mayor. La mayoría de estos sistemas han creado mecanismos para su fácil extensión, basados en el empleo de frameworks que permitan la creación de componentes de portal denominados Portlets. De esta forma, cuando construimos un portal web con nuestra herramienta CMS y le añadimos una sección de noticias, el componente de software encargado de implementar esta funcionalidad sería un Portlet, desarrollado con el framework proporcionado por el CMS. No obstante, esta variedad de frameworks incompatibles unos de otros representa un problema, puesto que los componentes desarrollados para un CMS no son reutilizables para otros CMS. Esto ha desembocado, dentro del mundo Java, en la especificación JSR168 o especificación de Portlets, cuyo objetivo es proporcionar interoperabilidad entre Portlets y portales.

Desde el punto de vista de esta aproximación, un CMS estaría formado por un contenedor de Portlets, que gestionaría los componentes de portal, recibiría peticiones y generaría contenido dinámico. Los portales utilizarían los Portlets como elementos de interfaz de usuario ensamblables, que proporcionarían una capa de presentación al sistema. Algunos de los objetivos de esta especificación son:  Definir las especificaciones que debe cumplir el entorno de ejecución para los Portlets, el contenedor de Portlets.  Establecer el API que deben seguir los Portlets para que sean gestionados por el contenedor, a través de los mecanismos de ligadura dinámica, herencia y polimorfismo.  Proporcionar mecanismos para guardar de forma persistente el estado de los Portlets, bien sea en base de datos, XML o cualquier otro mecanismo de persistencia.  Permitir la portabilidad binaria de los Portlets entre diferentes contenedores, y definir un estándar de empaquetado de Portlets para su posterior despliegue en el contenedor. Conforme a esta nueva filosofía, un portal web estaría formado por una aplicación que procesa las peticiones de clientes, solicita todos aquellos Portlets que formen parte de la página actual del usuario al contenedor de Portlets, que se encargará de cargarlos y ejecutarlos, volcando finalmente en la página final el contenido de la ejecución de cada Portlet. El contenedor de Portlets proporciona el entorno de http://digital.revistasprofesionales.com

REDES

Sistemas de Gestión de Contenidos (y II)

ejecución para los Portlets, y se comunica con éstos a través del API de Portlet. A su vez, el contenedor de Portlets es llamado por el portal web a través del API de invocación de Portlets. Por último, el contenedor devuelve información sobre el portal a través del SPI (interfaz para proveedores de servicios). Visión general del API de Portlets

Para entender un poco mejor cómo se consigue la estandarización de los elementos de portal en el mundo Java, haremos un breve repaso al API de Portlets. De acuerdo con la especificación, un Portlet sería una clase Java que implementase la interfaz Portlet, o que heredase de alguna clase que la implemente. Esta interfaz estaría formada por los siguientes métodos:  init(PortletConfig config): En este método se ejecutan todas las tareas de inicialización del Portlet. Se llama una sola vez para cada Portlet, cuando se construye su instancia. Suele ser utilizado para realizar operaciones costosas como cargar datos de la base de datos, leer imágenes de ficheros, etc. que sean necesarias para el Portlet. 

processAction(ActionRequest request, ActionResponse response): Este méto-

do se utiliza para notificar al Portlet que el usuario ha realizado una acción sobre dicho Portlet. Como resultado de ésta, un Portlet puede realizar una redirección, modificar su modo de trabajo (seguidamente veremos qué es esto), cambiar su estado de persistencia, etc. 

render(RenderRequest request, Ren derResponse response): Este método

es llamado por el contenedor para generar la salida del Portlet. Para cada Portlet de la página actual del usuario se llama a este método, y la salida final de todos los Portlets es compuesta según defina la plantilla de composición establecida para la página.  destroy(): La llamada a este método indica el final del ciclo de vida del Portlet, por lo que el Portlet debe liberar todos los recursos costosos que esté consumiendo y guardar de forma persistente su estado. Gracias a que todos los Portlets cumplen el contrato de implementar esta interfaz, cuando el contenedor de Portlets recibe una petición, se encarga de instanciar el Portlet al que está destinada, y de invocar estos http://digital.revistasprofesionales.com

métodos según el orden definido por su ciclo de vida. En virtud a este diseño, se pueden añadir nuevos Portlets sin que el sistema se vea afectado o haya que reiniciarlo. El único requisito es que sigan esta especificación. Modo de trabajo de un Portlet

Anteriormente hemos comentado que como consecuencia de la invocación del método “processAction” un Portlet puede cambiar su modo de trabajo. El modo de un Portlet sirve para indicar la función que el Portlet realiza. Normalmente, los Portlets pueden ejecutar diferentes tareas y crear diferentes contenidos en función de la tarea que estén desempeñando. Gracias al modo de trabajo del Portlet, éste sabe qué función realizar y qué contenido generar ante la petición de un usuario. La especificación clasifica los modos de trabajo de Portlets en tres grandes categorías:  Modos obligatorios: Todo portal debe contemplar los modos de edición, ayuda y vista. En cuanto a los Portlets, deben soportar al menos el modo de vista, necesario para generar sus salidas. El modo de edición se utiliza para modificar las configuraciones de usuario que les permiten personalizar la apariencia del Portlet, y el modo de ayuda se emplea para visualizar en pantalla información sobre el funcionamiento del Portlet.  Modos opcionales: Son modos que un portal podría tener. Tenemos el modo “Acerca de”, el modo “Configuración”, el modo “Previsualización” y el modo “Impresión”. 

Modos específicos de las casas comerciales: Todos aquellos que de-

seen implementar los fabricantes de portales y contenedores de Portlets. Empaquetado y despliegue de Portlets

Al estar basados en la arquitectura J2EE, un Portlet junto con los recursos que necesite y sus descriptores de despliegue son empaquetados juntos en fichero WAR. Para los lectores que desconozcan esta plataforma de desarrollo empresarial, cabe decir que un descriptor de despliegue es un documento XML que proporciona información de configuración sobre el Portlet al contenedor, y que un fichero WAR es un fichero de empaquetado para componentes desplegados en un servidor de aplicaciones.

Implementación de referencia de la especificación: Pluto Pluto es la implementación de referencia de la especificación de Portlets, y ha sido incluida dentro del incubador de proyectos del proyecto Jakarta, proyecto que alberga un gran número de herramientas Open Source de interés para el mundo Java. No obstante, Pluto no pretende ser una solución para entornos empresariales de elevada carga. Su objetivo es mucho más simple: proporcionar a los desarrolladores de componentes de portal un entorno de desarrollo para realizar sus pruebas. La arquitectura de Pluto está formada por dos componentes básicos: el portal y el contenedor de Portlets, por dos interfaces: la interfaz de invocación del contenedor (para la comunicación portal-contenedor) y la interfaz del proveedor de servicios (para la comunicación del contenedor con el portal). En la figura 5 podemos ver esta arquitectura representada de forma gráfica. El servicio de portal de Pluto recibe las peticiones de los clientes y accede al contenedor a través del API de invocación del contenedor de Portlets. Para tal fin, aquellos servicios que invoquen al contenedor de Portlets deben implementar la interfaz SPI para proveedores de servicios. Esto es necesario para independizar el contenedor del portal, ya que cuando el contenedor haya finalizado la ejecución de los Portlets, se comunicará a través de la mencionada interfaz con los usuarios de sus servicios, para obtener información del componente portal. La comunicación entre los Portlets y el contenedor se realiza a través del API de Portlet. Cabe reseñar que este componente es bastante simple, y sólo trata de mostrar cómo debe interactuar un servicio de portal con el contenedor de Portlets, a través de las APIs de invocación y de proveedor de servicios. El contenedor de Portlets está diseñado de tal forma que permanece completamente aislado de cualquier otro elemento del portal. En consecuencia, podría ser embebido dentro de cualquier otro portal. El proceso de despliegue de Portlet en Pluto es bastante sencillo: una vez creado el fichero WAR, se debe ejecutar el script “deployPortlet.bat” especificándole como parámetro la ubicación del archivo de empaquetado WAR del Portlet que quere45


REDES

Figura 5. Arquitectura del contenedor de Portlets y portal de Portlets Pluto.

mos desplegar. Este script de despliegue forma parte de la instalación de Pluto. Por último, una vez desplegados los Portlets y registrados en el componente de portal, habría que definir la apariencia final del portal. Para tal fin, Pluto utiliza el archivo de configuración “pageregistry.xml”. En esta estructura XML se incluirán etiquetas para introducir la salida de un Portlet en la composición final de la página, indicando la orientación que deben tomar sus salidas en dicha composición final.

Siguiente paso en la gestión de portales: portales federados Según la prestigiosa consultora Garnet Group, los sistemas WCM tenderán hacia la construcción de portales federados. Este tipo de portales se basan en permitir a sus usuarios, bien sea de una intranet, extranet o de Internet, acceder a una determinada información de forma transparente a la localización real del contenido. En consecuencia, los diferentes portales que contengan esta información se integrarán de forma que el usuario no necesite recordar

cientos de URLs y autentificarse en tantos sitios como portales contengan la información que requiere consultar. Para ello, estos portales deberán coordinarse para proporcionar una sola autentificación (lo que se viene a denominar “single sign-on”), lo que implica crear un único usuario para todos estos portales. Además, deberán comunicarse para intercambiar contenido entre ellos y así atender las solicitudes de sus usuarios. Evidentemente, esta coordinación entre portales no sería posible sin la elaboración de estándares a los que todos se adhieran. En este sentido la industria de elaboración de gestores de contenido y servidores de portal ha creado varios estándares para alcanzar este objetivo:  El estándar JSR-168, descrito con anterioridad, para buscar la portabilidad de Portlets creados por diferentes fabricantes a diferentes servidores de portal.  El estándar WSRP (Web Services for Remote Portlets) trata de dar solución al problema del intercambio de contenido entre portales remotos. Para ello, se apoya en la tecnología de servicios web, de forma que para acceder a contenido albergado

en otro portal tan solo habría que utilizar un servicio web publicado por éste.  El estándar SAML (Security Assertion Markup Language) trata de federar los esquemas de seguridad establecidos para los diferentes portales, permitiendo a un usuario navegar entre los dominios de diferentes portales sin tener que volver a autentificarse al cambiar de portal. Básicamente consiste en un protocolo basado en el intercambio de aserciones que permite a los sistemas de seguridad de diferentes portales comunicarse entre sí e intercambiar información acerca del perfil de un determinado usuario. La tecnología de portales federados estaba concebida en un primer momento para conseguir la integración de los diferentes portales departamentales de una misma organización. Un paso más en este sentido consiste en la federación entre portales de diferentes organizaciones. Para dar respuesta a esta necesidad han surgido proyectos como Liberty (http://www.projectliberty.org), o Microsoft Passport (http://www.passport.net).

Conclusiones A lo largo de estos dos artículos hemos tratado de introducir al lector en el tipo de sistema que constituye un CMS. Hemos visto algunas de sus principales características y funcionalidades, y una pequeña muestra de productos comerciales y de carácter libre. En la parte final de la serie, nos hemos centrado en una interesante iniciativa para la estandarización de los elementos de portal para CMS en la plataforma Java: la especificación JSR-168. No obstante, a la hora de optar por una solución u otra no sólo influyen los condicionantes técnicos o económicos. También influye la plataforma tecnológica (sistema operativo, bases de datos, servidor de aplicaciones, etc.) que ya se encuentre implantada.

Direcciones de interés     

 

http://www.phpnuke.org: Portal desde el que se puede descargar PHP-Nuke, así como gran número de módulos/Portlets para éste. http://www.postnuke.com: Portal de Postnuke, con descargas de Portlets y el CMS principal. http://www.magnolia.info: Portal del CMS en Java Magnolia. http://www.opencms.org: Portal del CMS OpenCMS. http://www.opensourcecms.com: Portal desde el que se puede acceder a un servidor con un gran número de CMS instalados. Proporciona privilegios de administrador para que sus usuarios puedan evaluar los distintos CMS. http://portals.apache.org/pluto/: Página desde la que se puede descargar Pluto, implementación de referencia de la especificación de Portlets. http://www-106.ibm.com/developerworks/webservices/library/ws-wsrp/: Artículo de IBM en el que se habla de la especificación WSRP. Esta especificación trata de definir un mecanismo de intercambio de información entre portales remotos a través de servicios web.


46


REDES

Servlets Filters (I) ADOLFO ALADRO GARCÍA

LISTADO 1

Agregando filtros a nuestra aplicación web podremos interceptar las peticiones que se hagan sobre ésta, pudiéndolas procesar antes y/o después de pasar el control al Servlet o la página JSP correspondiente. Además, los filtros ofrecen un mecanismo muy útil para añadir funcionalidades a nuestra aplicación web. Introducción

Los filtros permiten procesar tanto las peticiones que llegan a nuestra aplicación como las respuestas de ésta SOLO PROGRAMADORES nº 122

48

A veces resulta muy útil poder procesar las peticiones HTTP atendidas por un servidor de aplicaciones web. El objeto de este tratamiento no es tanto cambiar la funcionalidad de los Servlets y páginas JSP originales como poder añadir otra nueva sin necesidad de rescribir el código ya desarrollado y puesto en producción. En ocasiones se necesita que este procesamiento se haga antes de que la petición se sirva. Por ejemplo, ésto es típico cuando se quieren implementar sistemas que sólo acepten peticiones procedentes de determinadas IP. En otros casos el procesamiento debe llevarse a cabo después, es decir, una vez que se ha generado una respuesta ésta se intercepta y se trata antes de que llegue finalmente al cliente. Uno de los casos más comunes de este segundo tipo es el que se hace para codificar las páginas HTML con gzip para comprimirlas, de forma que reduzca el ancho de banda consumido entre el servidor y el navegador. Los filtros de Java se ajustan perfectamente a los dos modelos expuestos. Su funcionamiento y configuración es muy simple, de forma que varios filtros pueden encadenarse tan solo modificando el fichero de configuración del servidor web. Para los ejemplos que se desarrollarán en estos artículos se empleará Resin 2.1.5 (www.caucho.com) uno de los servidores de aplicaciones web en Java Open Source más populares.

Estructura de directorios con Caucho

/digital.revistasprofesionales | +— /html | | | +- /WEB-INF | | | +- web.xml | +— /WEB-INF | +- classes

Configuración El listado 1 muestra la típica estructura de directorios y subdirectorios que presenta una aplicación web desarrollada con Caucho. El directorio “/digital.revistasprofesionales.com/ html” es el document root del sitio web. El fichero de configuración de la aplicación (donde se definen los Servlets y los filtros, se indican cuáles son los classpath, se establecen variables de inicialización que posteriormente se pueden obtener con el método “getInitParameter”, etc.) se llama “web.xml” y se encuentra en un subdirectorio, dentro del document root, denominado “WEBINF”. A la misma altura que el document root se encuentra también otro directorio que también se llama “WEB-INF”. El directorio “classes” que se especifica es donde se almacenan todos los ficheros .CLASS correspondientes a las clases de la aplicación. El fichero “web.xml” es un documento XML que guarda la configuración tanto de los filtros como de los Servlets. Para el primer caso se definen dos etiquetas: “” y “”. La etiqueta “” permite establecer el nombre del filtro (el atributo “filtername”) y la clase que lo implementa (el atributo “filter-class”). La segunda etiqueta, “”, proporciona una forma de definir reglas que se aplican a las URL correspondientes a las peticiones y que determinan cuáles de estas peticiones son filtradas o no. Así el atributo “filter-name” especifica el filtro a aplicar, y el atributo “url-pattern” la regla que, aplicada a la URL de la petición, indica si debe aplicarse el filtro o no en ese caso. http://digital.revistasprofesionales.com

REDES

Servlets Filters (I)

LISTADO 2

Definición del filtro spp-filter

index.xtp, index.jsp, index.html

En el listado 2 se muestra un fichero “web.xml” que define un filtro cuyo nombre es “spp-filter” y que está implementado en la clase “FSerlvetFiltersFilter”, perteneciente al paquete “com.spp.servletfilters.filter”. Las peticiones que recibe la aplicación web sólo se filtran cuando la URL se ajusta al patrón “/SServletFiltersServlet/*”. Como se puede observar en el código anterior, los Servlets se definen de forma similar. La etiqueta “” permite establecer el nombre del Servlet (el atributo “servlet-name”) y la clase que lo implementa (el atributo “servletclass”). Por otro lado, la etiqueta “” especifica qué URL correspondientes a peticiones son servidas por ese Servlet. El atributo “servlet-name” indica el nombre del Servlet, y el atributo “url-pattern” es el patrón que aplicado a la URL revela si esa petición debe ser atendida o no por el Servlet.

Esqueleto de un filtro En los filtros, existen dos métodos principales que deben implementarse, y que se denominan “init” y “doFilter”. El primero se ejecu-

LISTADO 3

Nuestro primer filtro

HttpServletRequest req = (HttpServletRequest) request; for (Enumeration e = req.getHeaderNames(); e.hasMoreElements() ;) { String sHeaderName = (String)e.nextElement(); String sHeaderValue = req.getHeader(sHeaderName); System.out.println(sHeaderName + “=” + sHeaderValue); } System.out.println(“AuthType()=” + req.getAuthType()); System.out.println(“ContentType()=” + req.getContentType()); System.out.println(“ContentLength()=” + req.getContentLength()); System.out.println(“PathInfo()=” + req.getPathInfo()); System.out.println(“PathTranslated()=” + req.getPathTranslated()); System.out.println(“QueryString()=” + req.getQueryString()); System.out.println(“RemoteAddr()=” + req.getRemoteAddr()); System.out.println(“RemoteHost()=” + req.getRemoteHost()); System.out.println(“RemoteUser()=” + req.getRemoteUser()); System.out.println(“Method()=” + req.getMethod()); System.out.println(“ServletPath()=” + req.getServletPath()); System.out.println(“ServerName()=” + req.getServerName()); System.out.println(“Protocol()=” + req.getProtocol()); System.out.println(“ServerPort()=” + req.getServerPort());

ta en una única ocasión, normalmente cuando el filtro va a emplearse por primera vez. En este método se realizarán entre otras aquellas tareas de inicialización que sean necesarias en función de la naturaleza del filtro. Seguidamente se muestra la implementación más sencilla del método init:

private FilterConfig config = null; public void init(FilterConfig config) throws ServletException { this.config = config; }

En este caso simplemente se guarda en una propiedad de la clase el objeto que contiene la información de configuración del filtro. El método “doFilter” es el responsable de procesar las peticiones, es decir, es quien realmente filtra las peticiones. Se define tal y como sigue a continuación: public void doFilter(ServletRequest request, ServletResponse response, FilterChain next) throws IOException, ServletException { ... }

Los dos primeros parámetros representan los objetos que se corresponden respectivamente con la petición y la respuesta. El tercer parámetro permite gestionar la concatenación de filtros, o lo que es lo mismo, hace posible redirigir la petición al siguiente filtro, si es que hay alguno configurado. El filtro más sencillo que puede definirse es aquél cuyo método “doFilter” tiene una única línea: next.doFilter(request, response);

Respuesta dada por el servidor cuando se solicita una imagen JPG y el filtro que la escala no está activado.


49


REDES

LISTADO 4

La clase ServletResponseWrapperImg

class ServletResponseWrapperImg extends HttpServletResponseWrapper { protected HttpServletResponse responseOrig = null; protected ServletOutputStream servletOutputStream = null; public ServletResponseWrapperImg(HttpServletResponse response) { super(response); responseOrig = response; } ... }

De las líneas anteriores se deduce que todas aquellas peticiones que terminen con la cadena de texto “jpg” serán procesadas por el filtro que se corresponde con la clase “FSerlvetFiltersImgFilter”, cuyo método principal, “doFilter”, es tal y como sigue: HttpServletResponse res = (HttpServlet Response)response; ServletResponseWrapperImg servlet ResponseWrapperImg = new ServletResponse WrapperImg(res);

LISTADO 5

Los métodos a implementar

public ServletOutputStream getOutputStream() throws IOException { if (servletOutputStream==null) { servletOutputStream = new ServletOutputStreamImg(responseOrig); } return servletOutputStream; } public void flushBuffer() throws IOException { servletOutputStream.flush(); } public ServletResponse getResponse() { return this; }

Este filtro no haría nada salvo pasar la petición al siguiente filtro que se haya configurado en el fichero “web.xml”. De no existir, simplemente se pasará la petición al Servlet responsable en última instancia de procesar y atender a dicha petición. Tal y como se ha adelantado, los objetos “request” y “response” permiten gestionar la petición y la respuesta, lo que hace posible que un filtro pueda hacer prácticamente lo mismo que un Servlet. En el listado 3 se muestra el código de un filtro que imprime por la salida estándar el valor de todas las variables HTTP de la solicitud. En primer lugar se obtiene una referencia a un objeto que implementa la interfaz “javax.servlet.HttpServletRequest” simplemente modificando el tipo del parámetro “request”. A partir de este momento se puede trabajar con la variable “req” del mismo modo que se hace en un Servlet, por lo que el método “getHeaderNames” proporciona una colección con los nombres de las cabeceras HTTP de la solicitud, y el método “getHeader” permite conocer el valor de una cabecera dado su nombre. Asimismo los métodos “getAuthType”, “getContentLength”, “getContentType”, etc., permiten conocer todos los datos de la petición.


50

Procesamiento de las respuestas El filtro del listado 3 es muy simple. En realidad no hace nada especial, ni con la petición ni con la respuesta. En la práctica los filtros se emplean para procesar anticipadamente las peticiones o bien para tratar las respuestas dadas por los Servlets o las páginas JSP justo después de que se hayan producido y antes de que éstas lleguen al navegador del usuario. La gran ventaja de los filtros es que se pueden modificar las funcionalidades de las aplicaciones web por capas, evitando además que haya que rescribir el código de la programación original. A continuación se va a estudiar un caso más complejo en el que se emplea un filtro que procesa todas las peticiones HTTP que solicitan imágenes JPG. La función del filtro será escalar dichas imágenes antes de servirlas. En primer lugar se configura el filtro en el fichero “web.xml”:

next.doFilter(request, servletResponse WrapperImg);

Como se verá dentro de poco, la clase “ServletResponseWrapperImg” extiende a la clase “HttpServletResponseWrapper”, que es una clase del API con la que se puede “envolver” el tratamiento de las peticiones de forma que éstas se procesen de una manera determinada, independientemente de lo que haga la aplicación web. Esto es justo lo que define a un filtro. La clase “ServletResponseWrapperImg” cuenta con dos propiedades definidas como “protected” y que almacenan respectivamente el objeto original correspondiente a la respuesta y un flujo de escritura. Estúdiese el listado 4. El constructor llama en primer lugar al constructor de la clase padre y después se asigna la propiedad “responseOrig”. A partir de ahora la clase “ServletResponseWrapperImg” debe implementar aquellos métodos que sean necesarios para el propósito del filtro, dejando que los restantes métodos sean ejecutados por la clase padre, o dicho de otra forma, dejando que en el resto de los casos se ejecute el método por defecto. En el caso que nos ocupa se necesita procesar la imagen devuelta para escalarla por lo que se van a implementar los métodos que luce el listado 5. El primero de ellos es el más importante ya que cuando se llama al método “getOut putStream” se obtiene el flujo de escritura que se empleará más adelante para escribir los datos correspondientes a la lectura, es decir, la propia imagen. Para procesar los datos y hacerlos llegar al cliente se ha creado una nueva clase, “ServletOutputStreamImg”. Esta es la responsable última del tratamiento de las imágenes y su estructura es la que se presenta en el listado 6. Los dos primeros miembros de la clase guardan el objeto correspondiente a la http://digital.revistasprofesionales.com

REDES

Servlets Filters (I)

LISTADO 6

La clase ServletOutputStreamImg

class ServletOutputStreamImg extends ServletOutputStream { protected HttpServletResponse response = null; protected ServletOutputStream servletOutputStream = null; protected ByteArrayOutputStream baos = null; protected boolean bClosed = false; public ServletOutputStreamImg(HttpServletResponse response) throws IOException { super(); bClosed = false; this.response = response; this.servletOutputStream = response.getOutputStream(); baos = new ByteArrayOutputStream(); } ... }

para ser tratados después. Esta misma clase, cuando haya acabado el procesamiento de dichos datos, será quien finalmente los mande al cliente. Por lo tanto “ServletOutputStreamImg” implementará los métodos del listado 7. El mecanismo es sencillo: en vez de escribir en la salida estándar para estos casos se escribe en el buffer interno utilizando la clase “ByteArrayOutputStream”. La ejecución del método “close” marca el final de los datos, momento en el que la clase “ServletOutputStreamImg” tiene que comenzar el tratamiento de los datos: public void close() throws IOException

LISTADO 7

Métodos que implementa la clase ServletOutputStreamImg

{ if (bClosed) {

public void write(int b) throws IOException { if (bClosed) { throw new IOException(“Cannot write to a closed output stream”); } baos.write((byte)b); }

public void write(byte b[], int off, int len) throws IOException { if (bClosed) { throw new IOException(“Cannot write to a closed output stream”); } baos.write(b, off, len); }


stream has already been closed”); } byte[] bytes = baos.toByteArray(); ... }

public void write(byte b[]) throws IOException { write(b, 0, b.length); }

respuesta y el canal de escritura originales. La propiedad denominada “baos” se empleará para almacenar en un buffer intermedio los datos de la imagen devuelta (antes de ser escalada). Finalmente el miembro “bClosed” contiene un valor booleano que indica si el flujo de escritura está cerrado o no. El constructor de la clase llama en primer lugar al constructor de la clase padre y después pasa a inicializar sus miembros. Cuando el servidor devuelve la imagen emplea los métodos de esta clase para escribir los datos, lo que para el caso de las imágenes, que son datos binarios, serán típicamente todos los métodos “write”. El propósito de esta clase es hacer que la ejecución de esos métodos no sea “real”, es decir, que los datos no se manden al cliente sino que se almacenen internamente

throw new IOException(“This output

El método “toByteArray” de la clase “ByteArrayOutputStream” devuelve un array de bytes con los datos escritos hasta el momento. Este array representa la imagen original devuelta. Existen muchas formas de escalar una imagen pero quizás la más sencilla consiste en emplear el método “getScaledInstance” de la clase “Image”. Pero

Respuesta dada por el servidor cuando se solicita una imagen JPG y se ha activado el filtro que la escala.

51


REDES

tado en un método estático llamado “toBufferedImage”. Las diferencias entre los objetos “Image” y “BufferedImage” no son el objeto de este artículo así que no se va a explicar el código del método “toBuffe redImage”, el cual en cualquier caso es bastante sencillo de seguir leyendo el código fuente de los ejemplos.

Procesamiento de las peticiones Uno de los ejemplos más típicos de la aplicación de filtros para procesar las peticiones es aquel que se encarga de aceptar o rechazar las peticiones en función de la IP de origen desde la cual dichas peticiones se han originado. Esta tarea se puede llevar a cabo de forma muy sencilla utilizando un filtro. En primer lugar se debe modificar el fichero “web.xml” para definir el nuevo filtro: Documentación de la clase “HttpServletResponseWrapper”, la cual per mite procesar las respuestas dadas por el servidor de aplicaciones.

LISTADO 8

Código del filtro ip-filter

public void doFilter(ServletRequest request, ServletResponse response, FilterChain next) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest)request; HttpServletResponse res = (HttpServletResponse)response; String sRemoteAddr = req.getRemoteAddr(); if (sRemoteAddr!=null && sRemoteAddr.equals(“33.33.33.33”)) { next.doFilter(request, response); } else { res.sendRedirect(“http://digital.revistasprofesionales.com”); } }

antes de poder emplear este método es preciso obtener la propia imagen a partir del array de bytes:

Para este ejemplo simplemente se va a reducir el tamaño de las imágenes a su cuarta parte:

ImageIcon imageIcon = new ImageIcon

int iNewWidth = imageIcon.getIconWidth()

(bytes);

/ 4;

La ventaja principal de usar la clase “ImageIcon” es que, a diferencia de lo que ocurre con otras técnicas para leer imágenes con Java, ésta no devuelve el control al programa principal hasta que la imagen no se ha cargado en su totalidad, por lo que inmediatamente después de haber llamado al constructor se puede comenzar el tratamiento de la imagen sin peligro de que se encuentre parcialmente cargada. En el siguiente paso determinamos los nuevos valores para la imagen escalda.


52

int iNewHeight = imageIcon.getIcon Height() / 4;

Con estos datos escalar la imagen es tan simple como ejecutar: imageIcon.getImage().getScaledInstance (iNewWidth, iNewHeight, Image.SCALE_ DEFAULT)

Ahora bien, este método devuelve un objeto del tipo “Image” y para que la imagen pueda escribirse es preciso tener un objeto del tipo “BufferedImage”. La conversión entre objetos “Image” y “BufferedImage” se ha empaque-

Obsérvese que esta definición debe situarse la primera de todas y que además el patrón que se aplica en la URL es asterisco (*), es decir, que se filtrarán todas las peticiones. El código del filtro es bastante sencillo y puede verse en el listado 8. El método “getRemoteAddr” del objeto “HttpServletRequest” devuelve la dirección IP desde la que se realizó la petición. Si esta dirección no se corresponde con lo deseado una de las opciones más sencillas consiste en emplear el método “sendRedirect” de forma que el navegador redirige automáticamente a la portada del site. Evidentemente este mecanismo se puede hacer todo lo complejo que la aplicación requiera, de forma que se puede mostrar una página de error, o incluso mostrar todo un site alternativo para ese caso.

Conclusiones Hemos visto los fundamentos de los filtros Java con algunos ejemplos sencillos. En el siguiente capítulo profundizaremos en más ejemplos hasta haber visto cuáles son los filtros que más comúnmente se usan en las aplicaciones web actuales. http://digital.revistasprofesionales.com

DISEÑO

La diferencia entre el éxito y el fracaso JORDI BORJA (Director de Tecnología de Borland)

Todos sabemos que abordar el desarrollo de un proyecto de software entraña muchos problemas que pueden derivar en retrasos y sobrecostes. Como respuesta a las necesidades de gestores de proyectos, analistas, programadores etc., Borland ofrece una completa solución para cada una de las fases del ciclo de vida de las aplicaciones. Introducción Mis primeros pasos en el mundo de la programación fueron en la facultad. Aún recuerdo mis primeras prácticas (con Borland Pascal, curiosamente) en las que el profesor de turno nos pedía que desarrolláramos pequeñas aplicaciones y, durante toda la semana previa a la entrega, recuerdo las discusiones con mis compañeros de promoción (cómo no, en la cantina) en las que intentábamos ponernos de acuerdo sobre qué era realmente lo que el profesor había solicitado. Cada compañero había construido internamente un conjunto de requisitos. Por supuesto, cada uno de nosotros creíamos tener la razón e implementaba su propia versión de la aplicación solicitada. Nuestra sorpresa era mayúscula cuando descubríamos que, el día de entrega, el profesor, con una cruel sonrisa, nos decía que lo que habíamos implementado no era lo que él realmente había solicitado. Aprendimos de nuestros errores y, en las prácticas siguientes, acudíamos al profesor para intentar aclarar nuestras dudas e intentar acotar mejor el alcance de la aplicación. Recuerdo lo terriblemente difícil que era que el profesor nos definiese claramente qué era lo que él esperaba de nosotros. Nunca tenía tiempo para atendernos y explicarnos claramente los objetivos del ejercicio y una y otra vez nos encontrábamos en la entrega con la temida frase: “Está muy bien, pero en realidad lo que os pedía era… ”.


54

Hoy, más de una década después de mi primer contacto con el fascinante mundo del desarrollo, he comprendido que, aquello que creía era una actitud prepotente y torturadora del profesor, es el mayor problema con el que nos encontramos en la actualidad en el aún más complicado mundo del desarrollo empresarial de software.

Los requisitos Los estudios denominados “post-mortem” de los proyectos de desarrollo de software señalan que la principal causa de los retrasos, sobrecostes y/o no aceptación de un desarrollo es una incorrecta gestión de los requisitos. Se calcula que las dos terceras partes de los desarrollos no cubren las expectativas iniciales de los usuarios y, como consecuencia de ello, los proyectos son entregados tarde y con sobrecostes. ¿Exageración? ¿Derrotismo? Seguro que más de uno no ha podido evitar una leve sonrisa recordando alguna de sus vivencias pasadas o presentes… En efecto, la gestión efectiva y eficiente de los requisitos de una aplicación es el gran reto de los desarrollos actuales y es una de las fases del ciclo de vida en la que más esfuerzos de normalización se están llevando. Una incorrecta gestión de requisitos puede llevar a un esfuerzo y coste innecesario. Además, detectar en fase de codificación que un requisito no ha sido correctamente capturado, supone de forma segura un retraso en la planificación. Cuando más tarde se detecta un problema en los requisitos, más compleja es la resolución del problema Entonces, ¿qué hacer? La gestión de los requisitos es una técnica de ingeniería muy antigua. Cualquier empresa de desarrollo tiene sus mecanismos para gestionar catálogos de requisitos, típicamente basada en documentos (recuerdo los proyectos de una compañía en la que trabajé en la que los desarrolladores tenían las pantallas repletas de Post-Its con los requisitos a implementar). Lo que se busca en la actualidad es mucho más que poder documentar requisitos. En un entorno cada vez más globalizado, con factorías de desarrollo a kilómetros de distancia de los clientes, con penalizaciones por retrasos como norma habitual, con clientes (con memoria humana limitada) que manejan varios proyectos softwarede forma concurrente, y en un ambiente competitivo http://digital.revistasprofesionales.com

DISEÑO

La diferencia entre el éxito y el fracaso

Caliber Requirement Manager, para una correcta gestión de los requisitos.

en el que los cambios de los requisitos por parte del cliente para adoptar una ventaja competitiva son la práctica habitual, necesitamos mucho más que una simple documentación de requisitos. Las empresas de desarrollo buscan soluciones distribuidas, que permitan comunicar a clientes y equipos de desarrollo, soluciones que permitan conocer en todo momento, quién, cómo y por qué ha realizado un cambio en un requisito; que permitan conocer qué partes del proyecto se verán afectadas por ese cambio y, por lo tanto cuál va a ser el impacto en tiempo y coste del mismo. Soluciones que permitan garantizar que el impacto del cambio es aceptado por el cliente antes de abordarlo. Soluciones que permitan de forma automatizada eliminar la ambigüedad, trazar con otras partes del proyecto (planificación, pruebas, análisis,…) los requisitos, notificar los cambios inmediatamente a los miembros del equipo de desarrollo,… en definitiva, soluciones que implementen las más modernas recomendaciones para una correcta gestión de requisitos, como las definidas por el cada vez más aceptado nivel de medición de la calidad de los procesos de desarrollo: CMMI.

mos a conseguir ahora que teníamos la oportunidad de unificar esfuerzos y conocimientos? Pero pronto descubrimos otro de los principales problemas en el mundo actual de desarrollo: la comunicación entre los miembros del equipo. Outsourcing y Offshoring son dos términos con los que cada vez estamos más familiarizados. Los equipos de desarrollo ya no tienen que trabajar en casa del cliente. En la era de las comunicaciones, es cada vez más habitual que los diferentes perfiles del equipo de desarrollo estén distribuidos geográficamente, creando centros de especialización. España ha sido reconocida como un país candidato a albergar factorías de software para las grandes compañías internacionales. La promo-

ción del software entre diferentes entornos es una necesidad habitual, como lo es poder gestionar versiones de la aplicación, peticiones de cambio o tareas. De igual forma, el garantizar la calidad homogénea de una aplicación desarrollada por personas que nunca antes han trabajado conjuntamente es un auténtico reto para los equipos de desarrollo. Durante el ciclo de vida de un proyecto, los diferentes perfiles deben de poder trabajar sobre un repositorio centralizado, al que puedan acceder a través de protocolos estándares. Repositorios escalables, que guarden gran cantidad de metainformación preferiblemente en bases de datos y que permitan el acceso rápido y concurrente de múltiples desarrolladores. No hablamos exclusivamente de tener una herramienta de control de versiones (algo obviamente necesario), sino de tener una herramienta que permita gestionar releases, que permita promocionar estas releases entre diferentes entornos (desarrollo, integración, pruebas, preproducción, producción,…) y que permita, por ejemplo, poder crear una vista evolutiva y otra correctiva de una release. Hablamos de poder asignar peticiones de cambio o incidencias a determinados perfiles, y que estos perfiles puedan asociar las modificaciones que realicen en el repositorio a las peticiones de cambio, para que sea posible conocer el esfuerzo asociado a su resolución. De igual forma, buscamos herramientas que permitan poder gestionar la petición de cambio e incidencia en sí, a través de un workflow personalizable, en el que se formalicen los estados de la misma y se definan roles y responsabilidades. Hablamos también de poder trasladar la planificación de un proyecto a la herramienta de tra-

El equipo de trabajo Volviendo a mis tiempos de facultad, recuerdo mis primeras prácticas en grupo. Por primera vez nos sentíamos parte de un equipo de desarrollo. La soledad del programador había sido superada, y a partir de ese momento, nuestras vidas iban a cambiar por completo: si antes habíamos sido capaces de hacer de forma individual nuestras aplicaciones, ¿cómo no lo íbahttp://digital.revistasprofesionales.com

El ciclo de vida para la solución JBuilder.

55


DISEÑO

bajo en grupo, de forma que a partir de una planificación desarrollada, por ejemplo, con MS Project, se generen de forma automática tareas que se asignen a los diferentes miembros del equipo y de esa forma tener en todo momento una visibilidad y control del estado del proyecto. Buscamos herramientas, en definitiva, que sean flexibles, que permitan ser adaptadas a nuestra metodología de desarrollo y ser embebidas en nuestras herramientas diarias de trabajo para que su uso no sea intrusivo. Si conseguimos poder gestionar de forma efectiva y eficiente los requisitos de un proyecto y cohesionamos internamente el equipo, automatizando los procesos de desarrollo, habremos creado la base para garantizar el éxito de nuestros desarrollos. Sin embargo, existen dos factores críticos adicionales en los desarrollos actuales de software: la calidad y la productividad.

La calidad El ciclo de vida para Visual Studio .NET

Las empresas que contratan proyectos software son, afortunadamente, cada vez más exigentes respecto a la calidad de las aplicaciones que reciben. Es habitual encontrarse con pliegos en los que se exige el cumplimiento de estándares de calidad, bien sean éstos universales o internos de las compañías. Habitualmente se exige la utilización de un catálogo de patrones de diseño, una nomenclatura y guías de estilo y la correcta utilización de las técnicas de la Programación Orientada a Objetos. Los objetivos perseguidos son, por un lado, que las aplicaciones puedan ser mantenidas por el departamento interno de informática y, por otro, que las empresas no tengan que depender de un proveedor concreto y puedan asignar diferentes fases del desarrollo a diferentes compañías, sin encontrarse con la desagradable sorpresa de que es totalmente imposible que un equipo diferente al que ha realizado el desarrollo original pueda abordar el mantenimiento y/o evolución del sistema. El principal elemento diferenciador de las compañías de desarrollo es la calidad que imprimen a sus proyectos. Cuando una compañía certifica la calidad de sus entregables antes de que lo haga el cliente (o una empresa externa de auditoría), se asegura una inmejorable imagen de calidad y el mantenimiento de la relación con el cliente, además de evitar penalizaciones o retrasos en las entregas del proyecto. Es por ello, que las mejores empresas de desarrollo han introducido en sus equipos herramientas que permiten la aplicación automática de patrones de diseño sobre el código existente, la verificación automática y continua del cumplimiento de nomencla-


56

turas y guías de estilo y la ejecución de métricas de calidad del diseño (acoplamiento, cohesión, encapsulamiento, herencia,…) Estas herramientas deben de poder ser personalizables, para que los equipos de desarrollo puedan configurar sus propios patrones de diseño, su propio conjunto de normas sintácticas y sus propias métricas de calidad de diseño en función del cliente para el que trabajen. Además, las empresas buscan soluciones que permitan tener siempre sincronizado el código con el modelo y que puedan utilizarse de forma embebida en sus herramientas de codificación.

las aplicaciones que queremos que puedan ser desplegadas sobre diferentes servidores de aplicaciones) y que no se dependa de un proveedor ni tecnología concreta. Una aplicación desarrollada para WebSphere debería de poderse portar a WebLogic o a Oracle AS con un simple proceso de recompilación. Un equipo de desarrollo debería poder usar la misma herramienta de trabajo independientemente de si trabaja sobre Borland Enterprise Server, WebSphere, Sun One u Oracle AS.

La productividad

Por último, otro factor clave en el éxito del proyecto es la correcta planificación y ejecución de pruebas (funcionales y de rendimiento). Las pruebas no deben ser una parte aislada del desarrollo, sino que lo que se busca es que podamos ejecutar de forma continuada nuestro conjunto de pruebas y, que éstas puedan relacionarse con los requisitos, por ejemplo, para conocer qué requisitos de la aplicación han sido probados satisfactoriamente y cuáles no. Cuando hablamos de pruebas de rendimiento, no es suficiente con herramientas que nos permitan conocer el tiempo de respuesta de una aplicación bajo una situación de carga. Si nos limitamos a ejecutar pruebas de carga y de tiempo de respuesta, nada nos garantiza que una aplicación que se comporta correctamente durante la fase de pruebas lo vaya a continuar haciendo tras varias horas en producción. Si el tiempo de respuesta directamente no es el deseado, no tenemos información sobre cuál es la raíz del problema. Las herramientas de caja blanca, permiten monitorizar, de forma interna

Precisamente con las herramientas de codificación está relacionado el segundo factor crítico de desarrollo: la productividad. En la actualidad, los desarrolladores de aplicaciones que utilizan Ultraedit o vi son afortunadamente residuales. Cualquier programador utiliza un entorno integrado de desarrollo especializado en la plataforma sobre la que se desarrolla la aplicación. Cualquier aplicación J2EE, por ejemplo, requiere de la utilización de EJBs, Struts y/o Java Server Faces, Web Services, XML, editar descriptores de despliegue,... El uso de estas tecnologías sin la ayuda de herramientas especializadas es complejo, propenso a errores y poco productivo. Los entornos de desarrollo actuales permiten aumentar la productividad de los programadores. Hay muchas alternativas en el mercado pero, al mismo tiempo, se busca que el código generado sea portable (o portátil, como correctamente se debería denominar a

Las pruebas


DISEÑO

La diferencia entre el éxito y el fracaso

a la aplicación, el consumo de CPU por cada método (o línea de código), la gestión interna de memoria (lotering objects y excesiva creación de objetos temporales) y el funcionamiento de los hilos de ejecución (excesiva contención de threads o deadlocks). Monitorizar de forma continuada el funcionamiento de la JVM (Java/J2EE) o el CLR (.NET) permite detectar problemas de rendimiento antes de que la aplicación esté integrada, minimizando así el impacto de resolución del problema. De igual forma, cuando la aplicación ya está integrada, incluso en producción, y realizamos las pruebas de carga, resulta necesario disponer de herramientas que, de forma intuitiva, permitan conocer qué ocurre desde que llega una petición HTTP(S), IIOP, o SOAP al servidor, hasta que se produce la respuesta, para poder analizar el comportamiento interno de la aplicación. Desde luego, en mis tiempos de universitario, nunca podía llegar a pensar que el éxito del desarrollo de una aplicación estuviese condicionado a factores como los abordados. Qué tiempos aquellos en los que nos poníamos a programar directamente, sin un análisis previo, sin ningún diseño y ¡sin preocuparnos de la calidad! ¿Añoranza o ignorancia? Más bien lo último. Somos ingenieros, desarrollamos aplicaciones de las cuáles en muchos casos dependen vidas humanas y, en cualquier caso, grandes volúmenes de negocio, y estamos todavía aplicando técnicas prehistóricas de desarrollo. La experiencia nos ha demostrado, a clientes y a desarrolladores, que crear un software mejor es posible. Tan sólo necesitamos los conocimientos y herramientas adecuadas.

El ciclo de vida En esta introducción, hemos abordado los principales retos y problemas de los desarrollos actuales: la gestión de los requisitos de los proyectos, la necesidad de disponer de herramientas distribuidas de trabajo en grupo, la necesidad de poder verificar la calidad de los desarrollos, la necesidad de disponer de herramientas que aumenten la productividad del equipo de desarrollo, manteniendo la portabilidad del código y la necesidad de disponer de herramientas que permitan gestionar y ejecutar los planes de pruebas, incluyendo la monitorización interna y distribuida de las aplicaciones. Como muchos de vosotros sabréis, desde vuestras propias primeras experiencias con el mundo del desarrollo, Borland es y ha sido la empresa líder en herramientas de codificación desde hace más de 20 años. Sin embargo, como respuesta a las necesidades de los desarrolladores, a vuestras necesidahttp://digital.revistasprofesionales.com

El ciclo de vida para la solución Eclipse.

des, Borland ha desarrollado una completa solución que cubre cada una de las fases del ciclo de vida de las aplicaciones. Las principales características de esta solución son:  Ajuste 100% a estándares técnicos y metodológicos.  Portabilidad garantizada de todos los entregables del proyecto.  Integración entre las diferentes soluciones del ciclo de vida, no solamente entre las propias herramientas de Borland, sino con otras alternativas líderes del mercado.  Soluciones flexibles, extensibles y personalizables.  Interfaz visual sencilla e intuitiva. Las herramientas de codificación de Borland (Delphi, JBuilder, C++Builder y Mobile Studio) serán posiblemente las herramientas más conocidas por vosotros. Sin embargo, es curioso descubrir que aún se desconocen muchísimas de las funcionalidades y venta jas de estas herramientas. El mercado de las herramientas de codificación es sin duda el más competitivo en el que Borland ofrece sus soluciones, sobre todo desde la aparición de soluciones Open Source. Sin embargo, Borland continúa siendo la solución elegida por las principales empresas de desarrollo. Mi reto es que vosotros descubráis por qué. Together Technologies es una solución de modelado y verificación de calidad del software que ofrece múltiples ventajas respecto a las soluciones clásicas de análisis y diseño Orientado a Objetos. A través de sus ediciones especiales para entornos de desarrollo J2EE, C++ y .NET, por fin es posible que perfiles multidisciplinares trabajen paralelamente con modelo y código independientemente de la plataforma de desarrollo. StarTeam es la solución de trabajo en grupo que mayor crecimiento ha experimentado en los últimos dos años y es la principal opción

que consideran las empresas con equipos distribuidos de desarrollo, que requieren de una única solución para gestionar sus versiones, peticiones de cambio y tareas. Caliber Requirement Manager es una solución diseñada específicamente para la gestión de los requisitos, teniendo en cuenta todas las recomendaciones y necesidades de nuestros grandes clientes y de estándares como CMMI. OptimizeIT Suite y ServerTrace permiten monitorizar en tiempo real y de forma distribuida nuestras aplicaciones J2EE y .NET, complementando las herramientas de pruebas de rendimiento existentes.

Conclusiones Como veis, Borland ofrece herramientas especializadas en cada fase del ciclo de vida. Pero la solución de ciclo de vida de Borland es mucho más que un conjunto de herramientas especializadas. El uso integrado y conjunto de la solución permite que cada perfil de desarrollo pueda acceder a todas las fases del ciclo de vida desde una única herramienta, independientemente de si se utilizan todas las herramientas de Borland u otras alternativas del mercado. La pregunta que os lanzo es: ¿sois “sólo programadores”, o leéis una revista que es “sólo para programadores”? Estoy seguro que vuestra respuesta es la segunda. Únicamente se puede ser un buen programador si se tienen en cuenta las problemáticas anteriores. Es por ello, que, con el objetivo de que conozcáis mejor estas problemáticas, y conozcáis una de las alternativas para solucionarlas, en los próximos números Borland y Sólo Programadores publicarán artículos específicos sobre cada una de las fases del ciclo de vida, analizando las problemáticas asociadas, y cómo las soluciones de Borland permiten resolverlas. ¡Os espero!

57


DISEÑO

Diseño multiplataforma para aplicaciones C++ (I) GABRIEL DOS SANTOS DÁVILA

Con este artículo iniciamos un curso en el que aprenderemos a diseñar e implementar código C++ independiente del sistema operativo. Esto lo conseguiremos gracias a la librería de código abierto ACE, que no sólo nos abstrae de las particularidades de cada plataforma sino que además nos ofrece una implementación de patrones de diseño para sistemas concurrentes o de red. Introducción

ACE es la librería más usada para crear código C++ portable SOLO PROGRAMADORES nº 122

58

Aunque no es el caso más común, muchas veces nos encontramos con que nuestras aplicaciones deben ser capaces de funcionar en más de un sistema operativo. Esto ocurre con mayor asiduidad en aplicaciones para entornos Unix debido a que existen diferencias entre las diferentes versiones de Unix y Linux que hacen que una aplicación programada para uno de estos sistemas no siempre pueda usarse en otro. También puede darse el caso en que necesitemos que nuestra aplicación funcione no sólo en distintas variantes de Unix sino también en Windows. En estos casos las diferencias son aún mayores y hacer el “port” desde un sistema a otro puede tener un coste y complejidad muy elevados. La respuesta más inmediata al problema de una aplicación multi-plataforma suele ser el uso de lenguajes como Java que nos permiten escribir el código una vez y ejecutarlo en cualquier plataforma deseada. También .NET (y el proyecto MONO) está ofreciendo esta “portabilidad”, sin embargo el problema de estos lenguajes interpretados es que imponen a nuestra aplicación una penalización de velocidad que algunas aplicaciones críticas no pue-

den permitirse y es en estos casos cuando debemos recurrir a algún lenguaje que nos permita generar código nativo. Lenguajes como C++ no permiten, a diferencia de Java, crear código compilado independiente de la plataforma pero sí permiten, si se es cuidadoso y se parte de un buen diseño, crear código fuente que pueda ser compilado en cualquier plataforma. En esta serie de artículos aprenderemos cómo diseñar e implementar código C++ que sea independiente del sistema operativo. Para ello usaremos una librería de código abierto llamada ACE (Adaptive Communication Environment) que no sólo nos abstrae de las particularidades de cada sistema sino que además nos provee una implementación de patrones de diseño para sistemas concurrentes o de red.

Diferencias entre plataformas El estándar C++ especifica ciertas condiciones que debe cumplir un compilador y un conjunto de funciones que deben estar accesibles al programador. Desafortunadamente este estándar no incluye nada acerca de la longitud exacta de las variables o funciones de librería estándar para control de threads por ejemplo. Las diferencias entre plataformas pueden agruparse de la siguiente manera:  Diferencias de la arquitectura del hardware.  Diferencias en las funciones del sistema operativo.  Diferencias en las librerías disponibles para el programador. En esta serie nos centraremos en la resolución de problemas relacionados con las diferencias a nivel de sistema operativo. Diferencias de arquitectura Estas son las diferencias en las longitudes de los distintos tipos de datos entre plataformas o el orden en que se guardan los números en memoria. En arquitecturas Intel por ejemplo, un entero de dos bytes se guarda en memoria con sus bytes invertidos mientras que en otras plataformas esto no es así.


DISEÑO

Diseño multiplataforma para aplicaciones C++ (I)

Figura 1. Aplicación que usa directamente funciones del sistema operativo.

Diferencias en el sistema operativo Éstas son quizás las más evidentes. Las librerías para crear threads en Windows son completamente diferentes de aquellas disponibles en sistemas Unix. En este apartado podemos mencionar como “no portables” a las siguientes funcionalidades:  Listar contenido de directorios, crear directorios y otras tareas del sistema de archivos.  Cargar librerías dinámicas (DLL en Windows o SO en Linux) dentro de la aplicación y ejecutar funciones dentro de éstas.  Creación y manipulación de conexiones de red por TCP/IP usando sockets.  Creación de hilos de ejecución o threads.  Sincronización entre threads.  Gestión de procesos. Estas incompatibilidades nos obligan a escribir diferente código para cada sistema operativo y compilar condicionalmente uno u otro. Esto tiene varias desventa jas, siendo la duplicación de código la más evidente. Pero también implica que deberemos invertir tiempo en aprender cómo funciona cada conjunto de funciones de cada sistema operativo. Diferencias en las librerías disponibles No todas las funciones disponibles al programador en una plataforma lo estarán en otras. Hay funciones que no son estándar y por lo tanto no existen en algunas plataformas como es el caso de la función “itoa()” que no está disponible en ciertas versiones de Unix a pesar de ser una función de uso


muy habitual. Para evitar problemas de este tipo, es muy importante informarse acerca de si una función es o no estándar antes de comenzar a utilizarla. Si no hay alternativa a una función que no es estándar lo más conveniente es encapsular el acceso a ella en un solo lugar de la aplicación para que luego sea fácil de cambiar si se debe portar a una plataforma en la que la función no existe.

Diseño El problema de la portabilidad se agrava si una aplicación no fue inicialmente

concebida para ejecutarse en varias plataformas y más tarde durante su ciclo de vida surge este requerimiento. En la figura 1 podemos ver un esquema de la arquitectura de una aplicación que accede de manera directa a las funciones de la plataforma. Como vemos, esta aplicación posee una gran cantidad de puntos de contacto con el sistema operativo, los cuales deberán ser modificados en su totalidad al cambiar a otra plataforma. En general es muy complicado portar una aplicación desarrollada sólo con un sistema operativo en mente. Es por ello que, de existir alguna posibilidad de que en el presente o futuro nuestra aplicación deba funcionar con otro sistema, deberemos plantearnos un diseño que tenga en cuenta este escenario. En cualquier diseño, cuando algún elemento puede variar, se agrega un nivel de indirección adicional que hace que el mismo quede aislado del resto. De esta manera, si cambia, no afectará de manera alguna a los demás componentes. En nuestro caso será la librería ACE la que nos ofrezca este nivel adicional de indirección y en lugar de invocar de manera directa a las funciones del sistema operativo, invocaremos funciones de ACE que a su vez harán llamadas a las funciones correspondientes del sistema operativo en el que estemos trabajando lo cual nos dará la independencia de la plataforma. En la figura 2 podemos ver el esquema de la arquitectura propuesta en el cual la interfaz entre ACE y nuestra aplicación se mantiene constante sin importar la

Figura 2. Uso de ACE para abstraer el sistema operativo.

59


DISEÑO

plataforma subyacente y la interfaz entre ACE y los distintos sistemas operativos es gestionada por ACE. La desventaja de esta aproximación radica en que tendremos invocaciones a ACE desperdigadas por toda nuestra aplicación y si en algún momento deseamos cambiar ACE por otra librería similar, será muy difícil hacerlo. Para evitar esto se puede implementar el patrón de diseño Abstract Factory el cual agrega un nivel más de indirección creando un conjunto de clases abstractas que representen la funcionalidad del sistema operativo y luego una familia de clases concretas que implementan esa funcionalidad usando ACE. Durante la ejecución de la aplicación el Abstract Factory creará las instancias de las clases concretas que utilizan ACE. En la figura 3 podemos ver los componentes de esta arquitectura. Este diseño nos permite separar la creación de las clases del punto donde se utilizan y de esta manera podremos, si es necesario, usar una librería distinta de ACE sólo con crear una nueva familia de clases concretas. Esta es la estructura más flexible a la que podemos recurrir pero también la más compleja y no en todos los casos será necesaria. A la hora de diseñar software no sólo es importante saber dónde agregar niveles de indirección sino también saber cuándo dejar de hacerlo. Para más información sobre este patrón se puede recurrir al libro “Patrones de Diseño” de Eric Gamma y otros autores.

ACE ACE es una librería gratuita que nos facilitará enormemente la portabilidad de nuestra aplicación. El código fuente de ACE ha sido compilado en multitud de sistemas operativos con lo cual su correcto uso nos permitirá migrar sin mayores problemas, actuando como una capa intermedia entre el sistema operativo y nuestro código. Para trabajar con ACE necesitaremos descargar de Internet la librería y si bien existen algunas versiones precompiladas veremos cómo hacer para descargar las fuentes y realizar la compilación a partir de ellas. En la página http://deuce.doc. wustl.edu/Download.html encontraremos enlaces para descargar los fuentes de ACE. De este sitio descargaremos “ACE-5.4.zip” o “ACE-5.4.tar.gz” según nos resulte más cómodo. Es importante descargar una versión release final y no una versión beta. Para facilitar al lector el acceso a este material, se han incluido en el CD-ROM ambos archivos.


60

Figura 3. Arquitectura flexible que permitiría sustituir facilmente ACE.

Principios de diseño de ACE La librería ACE fue pensada y construida teniendo en cuenta los conceptos más avanzados de patrones de diseño de software. Entre los principales principios de diseño empleados podemos destacar:  Usar Wrapper Façades para forzar la verificación estricta de tipos de dato por el compilador. La idea es no exponer estructuras internas a la implementación como ocurre en C. La principal técnica usada es crear clases C++ que hagan que el compilador verifique los tipos usados.







Simplificar el código a escribir por el programador para los casos más comunes de uso de la librería. La forma de lograrlo es creando métodos que agrupen varias llamadas a funciones que sean generalmente usadas en conjunto y proveer valores predeterminados que sean los más usados para todos aquellos parámetros que sea posible. Usar jerarquías de clases para crear un diseño fácil de entender, usar y extender. Ocultar diferencias entre plataformas siempre que sea posible. En el caso en

Figura 4. Página de descarga de ACE.


DISEÑO






que todas las plataformas soportan una funcionalidad dada, se compila el código perteneciente a una u otra. Si hay alguna plataforma en particular que no tiene alguna funcionalidad específica se intenta emular por código propio de ACE siempre que sea posible. Permitir compilar con la funcionalidad mínima necesaria. Supongamos una plataforma que no soporte threads. Si ACE, que implementa threads, se intenta compilar con los threads activos la compilación fallaría por no estar soportados por la plataforma. Si alguien desea crear una aplicación que no requiere threads se vería impedido de hacerlo a causa de que su plataforma no soporta una funcionalidad que él ni siquiera necesita. Esto es demasiado restrictivo y por eso ACE permite activar y desactivar opciones de compilación de manera que se pueda compilar en una plataforma que soporte las capacidades mínimas requeridas por cada aplicación. Optimizar el código para obtener la máxima eficiencia posible.

Compilar ACE con Visual C++ Descargar el fichero “ACE-5.4.zip” y extraer su contenido en un directorio de nuestro disco. Dentro de este directorio se creará automáticamente uno de nombre “ACE_Wrappers” al cual llamaremos “ACE_ROOT” durante el resto de la serie. Para comenzar, en el directorio “ACE_ ROOT\ace”, crearemos un fichero llamado “config.h” que contenga: #define ACE_AS_STATIC_LIBS #define ACE_HAS_STANDARD_CPP_LIBRARY 1

LISTADO 1 //main.cpp #include #include #include int main(int argc, char* argv[]) { return 0; }

estáticas de depuración multi-hilo para la configuración “Debug” y librerías estáticas mult-hilo para la configuración “Release”. Si por error seleccionamos las librerías dinámicas (DLL) en esta opción, obtendremos errores bastante extraños a la hora de compilar nuestras aplicaciones que utilicen ACE. Hacer clic en “Aceptar”, activar la configuración “Debug” de la solución y presionar F7 para compilar ACE. Si todo va bien, esto dejará como resultado el fichero “ACE.lib” en el directorio “ACE_ROOT\lib”. Es posible que al compilar la solución completa los resultados sean tener un proyecto (ACE) compilado con éxito y otros dos (RMCast y TMCast) que generan un mensaje de error. El proyecto de ACE para Visual Studio incluye estas dos librerías adicionales que dependen de ACE y que no usaremos. Sus proyectos están configurados de manera predeterminada para que su configuración Debug intente compilar con la versión Debug de ACE en una librería llamada “ACEd.lib” pero en algunas distribuciones de ACE, al compilar en modo Debug, la librería generada se llama “ACE.lib” en lugar de “ACEd.lib” y de ahí el error. No es necesario preocuparse por esto pues no afecta para nada a nuestras prácticas.

Usar ACE desde una aplicación con Visual C++ #include “ace/config-win32.h” Para crear una aplicación que use la librería ACE provee archivos de proyecto para ACE ir al menú “Archivo” -> “Nuevo” -> Visual Studio 6.0 y .NET. En “Proyecto”, seleccionar “Proyectos Visual “ACE_ROOT\ace”, abriremos “ace.sln” para C++”, elegir la opción “Proyecto de Consola compilar con Visual Studio.NET. ACE puede Win 32” (no confundir con aplicación de compilarse como una librería dinámica o console .NET), entrar el nombre “main” para estática y en nuestro caso lo haremos de el proyecto, presionar “Aceptar” y “Finalizar”. forma estática para que en las aplicaciones Esto nos creará un nuevo esqueleto de proque no sea necesario distribuir la librería grama que modificaremos un poco: dinámica junto con los ejecutables.  Reemplazaremos todo el contenido del En Visual Studio, en el menú “Proyecto” -> archivo donde se encuentra definida la “Propiedades”: función “_tmain” por el contenido del listado 1.  En la sección “General”, en “Tipo de Configuración” elegir “biblioteca estáti En la ficha de propiedades del proyecto ca (.lib)”. y para todas las configuraciones:  En la sección “C/C++” -> “Generación  En la entrada “C/C++” -> “General”, de Código”, seleccionar las librerías añadir la ruta completa del directo-


main.cpp

rio “ACE_ROOT” en la lista de directorios de búsqueda de inclusión (include).  En “C++” -> “Cabeceras precompiladas”, no usar cabeceras precompiladas.  En “C/C++” -> “Generación de código”, cambiar las librería de un sólo hilo de ejecución por las librerías multi-hilo. la opción “Vinculador” ->  En “Entrada”, añadir la ruta completa del fichero “ACE.lib” como dependencia adicional.  En “C/C++” -> “Pre procesador”, añadir la definición del preprocesador “ACE_AS_STATIC_LIB”. Es importante que todos los cambios en las propiedades del proyecto se hagan tanto en la configuración de Debug como en la de Release. Ya tenemos listo el esqueleto que utilizaremos como punto de partida para todas nuestras aplicaciones por lo cual es conveniente hacer una copia de resguardo antes de seguir. A continuación agregaremos las siguientes líneas al principio del archivo “main.cpp”: #include ACE_Dirent_Selector dir;

Por último ejecutaremos el programa presionando F5. Si compila y ejecuta sin errores, ya tenemos enlazada nuestra aplicación con la librería ACE. Compilar ACE con g++ en Linux Debemos descargar el archivo “ACE5.4.tar.gz”, copiarlo en un directorio y a continuación ejecutar los siguientes pasos: $tar -xvzf ACE-5.4.tar.gz $cd ACE_wrappers/ $export ACE_ROOT=$PWD $cd ace/ $ln -s config-linux.h config.h $cd $ACE_ROOT/include/makeinclude $ln -s platform_linux.GNU platform_ macros.GNU $cd $ACE_ROOT/ace $make debug=0 static_libs_only=1

61


DISEÑO

Definiciones de tipos de datos ACE_INT16, ACE_UINT16

Enteros de 16 bits, con y sin signo.

ACE_INT32, ACE_UINT32

Enteros de 32 bits, con y sin signo.

ACE_UINT64

Entero de 64 bits sin signo. Puede emularlo aún en plataformas de 32 bits.

ACE_SIZEOF_CHAR

Longitud en bytes de un char.

ACE_SIZEOF_SHORT

Longitud en bytes de un short.

ACE_SIZEOF_INT

Longitud en bytes de un int.

ACE_SIZEOF_LONG

Longitud en bytes de un long.

ACE_SIZEOF_LONG_LONG

Longitud en bytes de un long long int.

ACE_SIZEOF_VOID_P

Longitud en bytes de un puntero.

ACE_SIZEOF_FLOAT

Longitud en bytes de un float.

ACE_SIZEOF_DOUBLE

Longitud en bytes de un double.

ACE_SIZEOF_LONG_DOUBLE

Longitud en bytes de un long double.

ACE_BYTE_ORDER

Ordenamiento de los bytes en la plataforma: ACE_BIG_ENDIAN o ACE_LITTLE_ENDIAN.

Al final del proceso se habrá creado la librería estática “libACE.a” en “ACE_ROOT/ace”. Usar ACE desde una aplicación con g++ en Linux Como primer paso, crearemos el archivo “main.cpp” con el contenido del listado 1. En este punto haremos una copia de resguardo de “main.cpp” que luego usaremos como punto de partida para cada una de las prácticas de esta serie. A continuación agregaremos las siguientes líneas a “main.cpp”: #include ACE_Dirent_Selector dir;

LISTADO 2

Para compilar y crear el ejecutable de la aplicación de prueba haremos lo siguiente: $g++ -I$ACE_ROOT

$g++ -o prueba *.o -L$ACE_ROOT/ace -l ACE

Si no obtenemos ningún mensaje de error, estos comandos dan como resultado el archivo ejecutable “prueba” que está enlazado estáticamente con la librería ACE. Incompatibilidad entre plataformas El punto de incompatibilidad más importante a nivel de hardware es el de los tamaños de los tipos de datos. Esto es porque el estándar C++ no define estric-

Sockets en Unix y en Windows

//VERSIÓN UNIX struct sockaddr_in srvr; memset (&srvr, 0, sizeof(srvr)); srvr.sin_family = AF_INET; srvr.sin_addr.s_addr = inet_addr (“127.0.0.1”); srvr.sin_port = htons (80); fd = socket (AF_INET, SOCK_STREAM, 0); connect (fd,(struct sockaddr *)&srvr,sizeof(srvr)); //VERSIÓN WINDOWS nRet = WSAStartup(wVersionRequested, &wsaData); SOCKET sock; struct sockaddr_in saDest; saDest.sin_addr.s_addr = “127.0.0.1”; saDest.sin_family = AF_INET; saDest.sin_port = 80; sock = socket(AF_INET, SOCK_STREAM, IPPROTO_ICMP);


62

-c main.cpp

tamente los tipos de datos en cuanto a su longitud sino en cuanto a qué es lo que pueden contener. ACE define un conjunto de macros que representan tipos de datos de manera portable y otros que permiten obtener información de la plataforma actual. En el cuadro “Definiciones de tipos de datos” podemos ver una lista de éstas definiciones y una explicación de cada una de ellas.

Incompatibilidades del sistema operativo ACE provee un conjunto de clases llamadas Wrapper Façades cuya función consiste en proveer un abstracción genérica sobre el sistema operativo. Para ello provee clases que encapsulan todos los aspectos que cambian de un sistema operativo a otro que hemos enumerado al comienzo de este artículo. Conexiones de red TCP/IP Una conexión de red TCP/IP se crea desde un programa por medio de la creación de elementos llamados sockets. Un socket es como un descriptor de archivo pero que permite transferir datos por una red TCP/IP como Internet. La lógica sobre cómo crear y utilizar un socket no varía entre sistemas operativos pero si los nombres de las funciones específicas para hacerlo. Para demostrar el uso de las conexiones por socket con ACE crearemos un servidor echo (reenvía al cliente todo lo que recibe) y un cliente que lo utilice. Sin embargo antes, estúdiese el listado 2. En él, se muestra cómo abrir un socket cliente tanto en Unix (arriba) como en Windows (abajo). Dicho código simplemente muestra la manera de establecer una conexión por sockets en Unix y en Windows, pero no hace uso de la conexión y tampoco hace ningún control de errores. Como puede verse en el listado 2, el código es bastante diferente. La solución para crear una aplicación que pueda compilarse en Linux y Windows podría ser en este caso usar compilación condicional para incluir en el ejecutable el código correspondiente a cada plataforma pero esta solución se hace más complicada a medida que el tamaño de la aplicación y los sistemas operativos a soportar aumentan. Una mejor solución es utilizar ACE y escribir código portable sólo una vez con el


DISEÑO


LISTADO 3 #include #include #include #include #include #include #include

bloquea la ejecución hasta que llega una petición de conexión de un cliente. En ese momento la función “accept()” devuelve el control y se procesa la petición. Al igual que en el cliente, se usa un objeto de clase “ACE_SOCK_Stream” para leer y escribir en el socket. Todo el código de gestión de peticiones se encuentra dentro de un while para que continúe esperando más peticiones una vez que termina con una. En un caso real un servidor de sockets crea un nuevo thread para gestionar cada petición y el procesamiento de cada una procede de manera independiente pero para mantener el código simple, este ejemplo usa un sólo thread.

Cliente echo usando sockets

“ace/SOCK_Connector.h”

int main(int argc, char* argv[]) { if (argc<=1) { std::cout << “Uso: main mensaje” << std::endl; return -1; } ACE_INET_Addr srvr (7, ACE_LOCALHOST); ACE_SOCK_Connector connector; ACE_SOCK_Stream peer; if (-1 == connector.connect (peer, srvr)){ std::cout << “Error al conectar al servidor” << std::endl; return -1; } peer.send_n(argv[1], sizeof(argv[1])); char buf[1000]; int bc = peer.recv (buf, sizeof(buf)); std::cout << std::string(buf,bc) << std::endl; peer.close (); return 0; }

agregado de que además es mucho más fácil de programar. El código ACE equivalente a los ejemplos anteriores es el siguiente: ACE_INET_Addr srvr (80, ACE_LOCALHOST); ACE_SOCK_Connector connector; ACE_SOCK_Stream peer;

podemos ver la implementación completa del código del servidor echo. Se crea un objeto de tipo “ACE_SOCK_Acceptor” al cual le indicaremos el puerto donde debe escuchar y llamaremos al método “accept()”, que LISTADO 4

connector.connect(peer, srvr);

Este código puede compilarse sin problemas en cualquier plataforma en la que ACE esté disponible y como vemos es mucho más simple. En el listado 3 podemos ver todo el código necesario para implementar el cliente echo con ACE. Las conexiones por sockets en ACE se efectúan utilizando un patrón Connector/Acceptor en el cual el acceptor espera peticiones y el connector las inicia. El objeto connector de clase “ACE_SOCK_Connector” encapsula un socket cliente y el objeto “peer” de clase “ACE_SOCK_Stream” representa el canal de datos que éste abre hacia el otro extremo de la conexión a través del cual es posible tanto leer como escribir. La función miembro “send_n()” se bloquea hasta que consigue enviar la cantidad de bytes indicada como segundo parámetro. A continuación, la función “recv()” lee los datos disponibles en el buffer. También hay funciones que permiten bloquear o especificar un tiempo límite de espera para leer datos. Una vez que tenemos listo el cliente crearemos el código del servidor. En el listado 4 http://digital.revistasprofesionales.com

Conclusiones

#include #include #include #include #include #include #include

En esta primera entrega hemos hecho una presentación de la librería ACE y aprendido a incluirla en nuestros programas. También pudimos apreciar la potencia de sus clases a la hora de simplificar la creación de sockets. En las próximas entregas veremos la manera de realizar tareas como acceder al sistema de archivos o crear aplicaciones multi-thread.

Servidor echo usando sockets

int main(int argc, char* argv[]) { ACE_INET_Addr port_to_listen(7); ACE_SOCK_Acceptor acceptor; if (acceptor.open (port_to_listen, 1) == -1) { std::cout << “Error al crear el socket server” << std::endl; return -1; } ACE_SOCK_Stream peer; ACE_INET_Addr peer_addr; while (true) { if (acceptor.accept (peer, &peer_addr) == -1) { std::cout << “Error al aceptar una conexión” << std::endl; return -1; } else { char buffer[4096]; ssize_t bytes_received; while ((bytes_received = peer.recv(buffer, sizeof(buffer))) > 0){ std::cout << std::string(buffer,bytes_received) << std::endl; peer.send_n (buffer, bytes_received); } peer.close (); } } return (0); }

63


DUDAS

Preguntas y respuestas ADOLFO ALADRO GARCÍA

LISTADO 1

Estoy trabajando con XML/XSLT en el navegador. Hasta el momento todas las páginas que he desarrollado están pensadas para Internet Explorer pero me gustaría que también pudieran verse correctamente en Firefox. ¿Existe alguna forma de hacer que sean compatibles?

Existen algunas diferencias notables entre los motores de XML/XSLT de IE y Firefox pero sí que se pueden crear páginas compatibles de forma que el comportamiento en ambos navegadores sea prácticamente el mismo, si bien es necesario complicar un poco el código Javascript. En primer lugar se requiere un método para diferenciar entre un navegador y el otro. Hay muchísimas formas de llevar a cabo esta tarea. En Internet se pueden encontrar numerosos ejemplos, algunos muy diferentes entre sí. Uno de los más sencillos es el que se presenta a continuación, y que se fundamenta en la diferenciación de los objetos que soporta el navegador en el que está mostrándose la página: var ns6 = !document.all && document. getElementById; var ie5 = document.all && !document. fireEvent && !window.opera; var ie55= document.all && document. fireEvent && !document.createComment; var ie6 = document.all && document. fireEvent && document.createComment;

Las expresiones anteriores evalúan la existencia de objetos y funciones como por ejemplo “document.all” y “document.getElementById” para determinar el navegador que se está utilizando. Cabe señalar que este método no es perfecto. Todo depende de la audiencia, es decir, si ésta es muy variada probablemente el script deba complicarse para detectar más casos (otros navegadores, otras pequeñas diferencias entre versiones, etc.) pero para la mayor parte de los casos el código anterior es más que suficiente. SOLO PROGRAMADORES nº 122

64

Empezando a trabajar con XML/XSLT

var oXSLTemplate, oFreeThreadedDOMDocument, oXSLProcessor, oXMLHttpRequest; var oXMLSerializer, oDOMDocumentOutput, oDOMParser; function InitXMLEngine() { try { if (ns6) { oXMLHttpRequest = new XMLHttpRequest(); oXSLProcessor = new XSLTProcessor(); oXMLSerializer = new XMLSerializer(); oDOMParser = new DOMParser(); } else { oDOMDocumentData = new ActiveXObject("MSXML2.DOMDocument"); oXSLTemplate = new ActiveXObject("MSXML2.XSLTemplate"); oDOMDocumentStylesheet = new ActiveXObject("MSXML2.FreeThreadedDOMDocument"); oXMLHttpRequest = new ActiveXObject("MSXML2.XMLHTTP"); } } catch (e) { alert("InitXMLEngine error: " + e.description); } }

LISTADO 2

Cargando los datos XML

function LoadData() { try { if (ns6) { oXMLHttpRequest.open("GET", "source.xml", false); oXMLHttpRequest.send(null); oDOMDocumentData = oXMLHttpRequest.responseXML; } else { oDOMDocumentData.async = false; oDOMDocumentData.preserveWhiteSpace = false; oDOMDocumentData.load("source.xml"); oDOMDocumentData.documentElement.normalize(); } } catch (e) { alert("LoadData error: " + e.description); } }

Una vez establecidas las variables globales que permiten diferenciar entre navegadores se puede empezar a desarrollar el resto del código. La función “InitXMLEngine” es la responsable de inicializar los objetos que se emplean para trabajar con XML/XSLT (véase el listado 1). Si el navegador es Firefox se crean los objetos “XMLHttpRequest”, “XSLTProcessor”, “XMLSerializer” y “DOMParser”, utilizando directamente los constructores del mismo nombre. El primero sirve para realizar llamadas HTTP (también puede emplearse para leer ficheros XML/XSLT locales, aunque no sea estrictamente una llamada HTTP), obteniendo así un documento XML. El segundo,

“XSLTProcessor”, se emplea para las transformaciones con XSLT. El objeto “XMLSerializer” permite convertir un documento XML en una cadena de texto. Finalmente, “DOMParser” se emplea para hacer justo lo contrario del objeto anterior, es decir, para obtener un documento XML a partir de una cadena de texto. En el caso de que el navegador sea IE los objetos se llaman y obtienen de forma diferente aunque básicamente sirven para las mismas tareas que se han descrito anteriormente. La siguiente función se denomina “LoadData” y como su propio nombre indica se usará para cargar los datos XML (véase el listado 2). http://digital.revistasprofesionales.com

NÚMEROS ANTERIORES 121 - Enero 2005

120 - Diciembre 2004

Las interfaces del futuro con

Introducción a la programación

XAML, finalizamos nuestro

de juegos con J2ME, aplicaciones

videojuego con J2ME, integra-

web con Python, herramientas

ción de Python con Java, XML

Open Source para J2EE, persis-

e IA, XQuery, Sistemas de

tencia con Hibernate, creación

Gestión de Contenidos, XSL-FO

de servicios web con Java, diseño

avanzado y la quinta entrega

de interfaces Swing, profundiza-

del coleccionable ASP.NET.

mos en XSL-FO y la cuarta entre-

2 CD-ROMs incluidos.

ga del coleccionable ASP.NET. 1 CD-ROM incluido.

119 - Noviembre 2004

118 - Octubre 2004

Persistencia de datos en J2ME,

Programación sobre Pocket PC y

aplicaciones de escritorio sobre

Tablet

.NET, programación gráfica con

Python, creación de un servidor

Python, Firebird sometido a aná-

de mensajería instantánea, pro-

lisis, optimización de servicios

gramación de servicios web en

web en .NET, diseño de interfaces

.NET, patrones J2EE, diseño de

Swing, conversión de XML a PDF

interfaces Swing y la segunda

con XSL-FO y la tercera entrega

entrega

del coleccionable ASP.NET.

ASP.NET.

1 CD-ROM incluido.

1 CD-ROM incluido.

117 - Septiembre 2004 .NET para programadores C++, el modelo transaccional de los EJB, creación de un cliente de mensajería instantánea, consumo de servicios web desde .NET, patrones J2EE, diseño de interfaces Swing y la primera entrega del coleccionable ASP.NET. 1 CD-ROM incluido.

PC,

del

introducción

coleccionable

Si te falta algún número de la temporada 04/05, ahora tienes la oportunidad de conseguirlo Precio Oferta descuento Precio por ejemplar: 6€

1 a 10 = 10% dto. / 11 a 20 = 20% dto. 21 a 30 = 30% dto. / 31 a 40 = 40% dto. +40 = 50%

BOLETÍN DE PEDIDO

Rellene o fotocopie el cupón y envielo a REVISTAS PROFESIONALES, S.L. (Revista SÓLO PROGRAMADORES) C/ Valentín Beato, 42 - 3ª Planta - 28037 MADRID Tel.: 91 304 87 64 - Fax: 91 327 13 03 - www.revistasprofesionales.com - [email protected] Deseo me envíen los número/s: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NOMBRE Y APELLIDOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .EDAD.................TELÉFONO................................ DOMICILIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C.P.: CIUDAD . . . . . . . . . . . . . . . . . .PROVINCIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

FORMAS DE PAGO Giro Postal a nombre de REVISTAS PROFESIONALES, S.L.  Talon Bancario a nombre de REVISTAS PROFESIONALES S.L.  Contra Reembolso (5€ de gastos de envio por paquete) Domiciliación Bancaria Banco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domicilio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Firma: Numero de cuenta: _ _ _ _/ _ _ _ _/ _ _ / _ _ _ _ _ _ _ _ _ _ _ _ Titular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  Tarjeta VISA _ _ _ _/ _ _ _ _/ _ _ _ _/ _ _ _ _/ Fecha de caducidad: Extranjero: Gastos de envio 5€ por paquete. Unica forma de pago tarjeta VISA.  

a

Revista Solo Programadores #122

Recommend Documents