S   D   O
   I 6ª ENTREGA DEL COLECCIONABLE
    T
   A    I
   U
   R    L
   G    C
   N
   I
   D
   C

Precio: 6  € (Españ
(España)
a) (IVA incluido) • AÑ
incluido) AÑO
O XI.
XI. 2.
2.ªª ÉPOCA • Nº 122 •
ÉPOCA UNA PUBLICACIÓN DE: REVISTAS PROF
ROFESI
ESIONALES S. L .
ONALES

 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. Pocas cosas reflejan tan bien el progreso de la tecnología como los teléfonos móviles.
móviles . En muy
solop@revistasprofesionales.com
pocos años, han pasado de ser simples teléfonos a auténticas plataformas de ocio.
C/ Valentin Beato 42, 3ª. 28037 - Madrid.
Curiosamente, continuamos llamando “teléfono móvil” a un dispositivo que, ciertamente, algún
http://www.revistasprofesionales.com
http://digital.revistasprofesionales.com día lo fue, pero no cabe duda de que hoy ese término ha quedado obsoleto. Los fabricantes de
Editor
estos “teléfonos” inundan el mercado con nuevos modelos, las operadoras de telecomunicacio-
Agustín Buelta nes nos abruman con agresivas campañas de publicidad y, todo ello, acaba en un consumo des-
•••••••••••••••••••••••••••••••••• mesurado de estos servicios. La última tecnología
t ecnología que se ha incorporado a los dispositivos
dispositi vos móvi-
Coordinación Técnica-Redac
Técnica-Redacciónción les es la que puede transformar nuestro terminal en una auténtica consola de videojuegos.
Carlos Laparra Ciertamente, este tipo de productos van destinados a los consumidores más jóvenes. Según
••••••••••••••••••••••••••••••••••
Maquetación
se desprende de los estudios realizados por las compañías del sector, 3 de cada 5 ciudadanos
Raúl Clavijo 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 repre-
Asesoría de Publicidad sentan el 11%, frente al 29% que representan otro tipo de contenidos, como por ejemplo las
Felipe Ribagorda imágenes. De hecho, estos datos han sido respaldados por un estudio hecho por la consultora
Tel.: 91 304 87 64
Barcelona
Screen Digest, en el que se afirma que el 80% de los ingresos derivados de los juegos y sus des-
C/ Rocafort, 241/243, 5º 1ª cargas provienen de Japón y Corea. En este sentido, queda claro que América y Europa repre-
Mariano Sánchez sentan un mercado relativamente virgen, y por lo tanto con muchas posibilidades en el nacien-
Tel.: 93 322 12 38 te 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
Suscripciones
Tel: 91 304 87 64
las plataformas con más cuota de mercado: Nokia.
Fax: 91 327 13 03
•••••••••••••••••••••••••••••••••••
Impresión
Ideas de Impresión
SUMARIO
•••••••••••••••••••••••••••••••••••
Distribución
Motorpress Ibérica ACTUALIDAD
10 Windows Longhorn: La evolución
Longhorn: evolución de .NET (I)

Distribución Mexico
DISPOSITIVOS MÓVILES
DIMSA - Angel Bosch
Bosch 16 Juegos de calidad comercial en J2ME (I)
angelbosch@infosel.net.mx
Distribución, números atrasados y suscripciones
Renacimiento, 180. Col. San Juan Tlihuaca MIDDLEWARE
Azcapotzalco. 02400 México D.F.
24  XAML (II)
36 Desarrollo visual de IGUs Java 
Distribución Argentina

REDES
Capital Federal: Distrimachisa
Interior: York Agency,
Agency, S. A.
Tel. (005411) 43 31 50 51
42  Sistemas de Gestión de Contenidos (y II)
••••••••••••••••••••••••••••••••••
La revista Sólo Programadores no tiene por qué 48  Servlets Filters (I)
estar de acuerdo con las opiniones escritas por sus
colaboradores en los artículos firmados. DISEÑO
El editor prohibe expresamente la reproducción
54  La diferencia entre el éxito y el fracaso 
total o parcial de los contenidos de la revista
sin su autorización escrita. 58  Diseño multiplataforma
multiplataforma para aplicacione
aplicacioness C++ (I)
Depósito legal: M-26827-1994
 Y además…
PRINTED IN SPAIN
COPYRIGHT
COPYRIG HT 30-02-20
30-02-2005
05
P.V.P. 6,00 Euros 04  Noticias 
Precio en Canarias, Ceuta y Melilla:
06  javaHispano:
 javaHispano: NetBeans 4.0, db4objects,
db4objects, APIs Java
Java y más 
6,15 Euros
08  Canal Panda: Los sistemas móviles, un peligro para la seguridad corporativa 
32  Contenido del CD-ROM 
Asociación Española de Editoriales 64 Preguntas y respuestas 
de Publicaciones Periódicas
 EDITORIAL
Un mercado prometedor
 Número 122 - Marzo 2005
Edita: REVISTAS PROFESIONALES S.L. Pocas cosas reflejan tan bien el progreso de la tecnología como los teléfonos móviles.
móviles . En muy
solop@revistasprofesionales.com
pocos años, han pasado de ser simples teléfonos a auténticas plataformas de ocio.
C/ Valentin Beato 42, 3ª. 28037 - Madrid.
Curiosamente, continuamos llamando “teléfono móvil” a un dispositivo que, ciertamente, algún
http://www.revistasprofesionales.com
http://digital.revistasprofesionales.com día lo fue, pero no cabe duda de que hoy ese término ha quedado obsoleto. Los fabricantes de
Editor
estos “teléfonos” inundan el mercado con nuevos modelos, las operadoras de telecomunicacio-
Agustín Buelta nes nos abruman con agresivas campañas de publicidad y, todo ello, acaba en un consumo des-
•••••••••••••••••••••••••••••••••• mesurado de estos servicios. La última tecnología
t ecnología que se ha incorporado a los dispositivos
dispositi vos móvi-
Coordinación Técnica-Redac
Técnica-Redacciónción les es la que puede transformar nuestro terminal en una auténtica consola de videojuegos.
Carlos Laparra Ciertamente, este tipo de productos van destinados a los consumidores más jóvenes. Según
••••••••••••••••••••••••••••••••••
Maquetación
se desprende de los estudios realizados por las compañías del sector, 3 de cada 5 ciudadanos
Raúl Clavijo 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 repre-
Asesoría de Publicidad sentan el 11%, frente al 29% que representan otro tipo de contenidos, como por ejemplo las
Felipe Ribagorda imágenes. De hecho, estos datos han sido respaldados por un estudio hecho por la consultora
Tel.: 91 304 87 64
Barcelona
Screen Digest, en el que se afirma que el 80% de los ingresos derivados de los juegos y sus des-
C/ Rocafort, 241/243, 5º 1ª cargas provienen de Japón y Corea. En este sentido, queda claro que América y Europa repre-
Mariano Sánchez sentan un mercado relativamente virgen, y por lo tanto con muchas posibilidades en el nacien-
Tel.: 93 322 12 38 te 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
Suscripciones
Tel: 91 304 87 64
las plataformas con más cuota de mercado: Nokia.
Fax: 91 327 13 03
•••••••••••••••••••••••••••••••••••
Impresión
Ideas de Impresión
SUMARIO
•••••••••••••••••••••••••••••••••••
Distribución
Motorpress Ibérica ACTUALIDAD
10 Windows Longhorn: La evolución
Longhorn: evolución de .NET (I)

Distribución Mexico
DISPOSITIVOS MÓVILES
DIMSA - Angel Bosch
Bosch 16 Juegos de calidad comercial en J2ME (I)
angelbosch@infosel.net.mx
Distribución, números atrasados y suscripciones
Renacimiento, 180. Col. San Juan Tlihuaca MIDDLEWARE
Azcapotzalco. 02400 México D.F.
24  XAML (II)
36 Desarrollo visual de IGUs Java 
Distribución Argentina

REDES
Capital Federal: Distrimachisa
Interior: York Agency,
Agency, S. A.
Tel. (005411) 43 31 50 51
42  Sistemas de Gestión de Contenidos (y II)
••••••••••••••••••••••••••••••••••
La revista Sólo Programadores no tiene por qué 48  Servlets Filters (I)
estar de acuerdo con las opiniones escritas por sus
colaboradores en los artículos firmados. DISEÑO
El editor prohibe expresamente la reproducción
54  La diferencia entre el éxito y el fracaso 
total o parcial de los contenidos de la revista
sin su autorización escrita. 58  Diseño multiplataforma
multiplataforma para aplicacione
aplicacioness C++ (I)
Depósito legal: M-26827-1994
 Y además…
PRINTED IN SPAIN
COPYRIGHT
COPYRIG HT 30-02-20
30-02-2005
05
P.V.P. 6,00 Euros 04  Noticias 
Precio en Canarias, Ceuta y Melilla:
06  javaHispano:
 javaHispano: NetBeans 4.0, db4objects,
db4objects, APIs Java
Java y más 
6,15 Euros
08  Canal Panda: Los sistemas móviles, un peligro para la seguridad corporativa 
32  Contenido del CD-ROM 
Asociación Española de Editoriales 64 Preguntas y respuestas 
de Publicaciones Periódicas
 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 inte-
ré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 freewa-
re, 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 cono-
cidas y libres de toda sospecha hayan sido manipuladas para contener
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 caracte-
rí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 soft-
ware integrado que está diseñada para conectar sistemas dispares y
hacer rodar las aplicaciones sobre las que están construidos los nego-
cios de las grandes compañías. Lo que hace único a Diablo es su capa-
SUN MICROSYSTEMS
Bankinter innova con J2ME
Java continúa en
su proceso de
consolidación
como la platafor-
ma número uno
para servicios
inalámbricos de
datos. Según fuentes de Sun, ya existen unos 300 modelos distin-
tos 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 incre-
mentar su ARPU (ingresos medios por usuario) gracias a la implanta-
SOLO PROGRAMADORES nº 122 4 http://digital.revistasprofesionales.com
un programa espía. Esta manera de ocul-
tarse en el interior de programas no sos-
pechosos posibilita que se instalen en el
PC, al mismo tiempo que el usuario insta-
la la aplicación que acaba de descargar. Un
spyware oculto en un sistema puede per-
mitir elaborar el perfil de un usuario mos-
trando, 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 tecno-
logía y propiedad intelectual que aporta GIANT para proporcionar a los
usuarios del sistema operativo Microsoft Windows unas nuevas herra-
mientas para proteger sus sistemas frente a las amenazas que repre-
sentan 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 analiza-
rá el PC del usuario para localizar cualquier spyware u otro software mali-
cioso, 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.
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án-
dares 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, valora-
ciones, 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.

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 tra-
baje 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 introdu-
cido en el concepto de Grid Computing,
diremos que para solucionar la “incapa-
cidad” 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 desarro-
llar conjuntamente el proyecto MegaGrid, una iniciativa para des-
arrollar un modelo estándar de diseño e implantación de una infraes-
tructura Grid Computing. Las cuatro compañías combinan sus prin-
cipales tecnologías y recursos técnicos para ofrecer a sus clientes una
solución corporativa Grid Computing integrada y completa que
SUN MICROSYSTEMS
Sun y la Universidad Rey Juan Carlos entablan
una alianza tecnológica
El Rector de la Universidad Rey Juan
Carlos, Pedro González Trevijano
Sánchez y el director general de Sun
Microsystems Ibérica, Adolfo Hernández,
han firmado un acuerdo tecnológico de
colaboración que permite que la
Universidad use gratuitamente los pro-
ductos software de Sun para fines
docentes y entornos de investigación.
El software cedido por Sun Microsystems
a la Universidad Rey Juan Carlos incluye
servidores web y de directorio, servidores
de aplicaciones e integración, aplicaciones
de correo electrónico, calendario y cola-  El Rector de la Universidad Rey Juan Carlos, Pedro
boració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
momento de la firma del acuerdo.
http://digital.revistasprofesionales.com
NOTICIAS
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, pos-
teriormente se definen unas infraestructuras Grid Computing efecti-
vas, 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 com-
puesta por servidores PowerEdge basados en procesadores Intel.
 EMC incorpora una infraestructura completa de almacenamien-
to en red.
 Intel contribuye con su experiencia en la gestión de procesado-
res 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 solu-
ciones de Grid Computing, permitiendo que éstas puedan ofrecer servi-
cios 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 también cederá una licencia con fines didácticos de su software de
escritorio Java Desktop System, que podrá ser utilizado tanto por parte
de los estudiantes como por parte del
personal docente y de administració
administraciónn
de la entidad educativa. Esta solución
incluye el entorno de escritorio com-
pleto, la suite de productividad ofimá-
tica StarOffice 7, un innovador entor-
no de ventanas, el popular navegador
Mozilla y un sistema operativo Linux
integrado, además de aplicaciones de
correo electrónico, agenda y mensa-
 jería instantánea.
Además, como socio tecnológico de
la universidad, Sun colaborará con la
institución en otros aspectos rela-
en los estudios de dicha universidad.
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 res-
paldado de más de 150 empresas y está soportada por Java, son dos sistemas de identificación glo-
bales de la web que pretenden conseguir el “Single Singn On” (SSO); ésto es, que una vez identifica-
do 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 intro-
ducidos por la empresa de Redmond en la arquitectura de Passport (probablemente un intento de solu-
cionar 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 rein-
genierí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 impor-
tantes es que el modelo del proyecto está completamente
basado en Apache Ant, pudiendo compilar el proyecto
externamente sin necesidad de emplear previamente nin-
guna opción del tipo “exportar a Ant”.
Ant”. El soporte a la refac-
torizació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 des-
arrollada 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.

SOLO PROGRAMADORES nº 122 6 http://digital.revistasprofesionales.com

  JAVAHISPANO
 javaHispano

db4objects disponible bajo licencia libre

db4o (http://www.db4o.com/) es una base de datos orien-

tada a dispositivos empotrados con requerimientos de
tiempo real. db4o permite almacenar de un modo sencillo
y eficiente objetos nativos Java y .NET; sus creadores ase-
guran 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 emple-
an 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 documenta-
ció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, com-
mons-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 directa-
mente 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 apli-
caciones 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

sobre a aplicación web, medida en hits por segundo. JCrawler

JCrawler es una herramienta para testar aplicaciones web que per-
mite realizar test de estrés. La herramienta se configura indicando
un conjunto de URLs de partida así como una carga a generar
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 (abraham.otero@javahispano.org) es responsable de calidad y miembro de la junta de javaHispano.

http://digital.revistasprofesionales.com 7 SOLO PROGRAMADORES nº 122

 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 vigi-
la más la conexión a Internet, la existencia de
herramientas de seguridad en las máquinas ins-
taladas en la red, la formación de los usuarios,
etc. Sin embargo, al mismo tiempo que se avan-
za en este sentido, nos encontramos que la tec-
nologí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 consi-
dera 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 mu-
chos días fuera del entorno “seguro” de la ofi-
cina, sin que la política de seguridad estableci-
da en la compañía pueda ampararles ante posi-
bles 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 orde-
nador conectado a Internet en la habitación del
SOLO PROGRAMADORES nº 122 8 http://digital.revistasprofesionales.com
hotel. Acostumbrado al entorno de la oficina, los
niveles de seguridad quedan, generalmente, en
segundo plano. Las consecuencias de su despre-
ocupación pueden ser graves, ya que la ausencia
de un firewall en el portátil permite que los hac-
kers puedan hacer del PC un terreno conquista-
do, 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 com-
petencia 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 adminis-
tradores 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 tro-
yanos, el spyware... todo ello podrá ser volcado
directamente a la red si no se toman las medi-
das oportunas. Sin duda existirán herramientas
que eviten la propagación de este tipo de códi-
gos 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 per-
sonal externo se conecte a la red con sus ordena-
dores 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 seguri-
dad? Los administradores de red tienen bastan-
tes problemas ya en su trabajo diario como para
ir verificando uno a uno los ordenadores de cada
uno de los subcontratados, situación que ade-
más puede resultar embarazosa ya que las nor-
 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 sis-
temas móviles a la red corporativa. Previo a la
posibilidad de que un usuario rompa las políti-
cas de seguridad, debe llevarse un control
exhaustivo y automático de la situación de la
seguridad de los ordenadores portátiles de per-
sonal externo, o de la empresa pero que hayan
estado desplazados.
Cuando un sistema se conecta a la red corpo-
rativa, hay que asegurarse de que el equipo es
seguro, entendiendo como seguro que cumple
el nivel de seguridad indicado por el adminis-
trador 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
Es recomendable
chequeo realizado deberá permitirse o dene-
garse el acceso, o incluso establecer un nivel comprobar
de seguridad en el equipo que se adapte a los
requerimientos corporativos de seguridad. los niveles
Sin embargo, en muchas ocasiones la conexión
de equipos externos está ya prevista, por lo que de seguridad
se redirige hacia determinados segmentos de
red o se establecen automáticamente permisos de un equipo
y restricciones, sin que llegue a producirse un
conflicto de intereses entre políticas de seguri- ajeno antes
dad de distintas empresas.
Como vemos, la conexión de equipos externos de conectarlo
a la red fija de una empresa no está exenta de
problemas, y debe controlarse con mucho cui- a nuestra red
dado. 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.

Sobre el autor
Fernando de la Cuadra (Fdelacuadra@pandasoftware.com) 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 legales de la LOPD y la LSSICE hasta cómo detec-
Pérez García tar una intrusión en el sistema, pasando por
Editorial: Mc Graw Hill temas como el anonimato y la privacidad, la pro-
Páginas: 440 tección de redes y equipos o las auditorías y los
Precio aproximado: 30 Euros análisis forenses.
ISBN: 84-481-4008-7 Aunque las publicaciones sobre seguridad son
Con la colaboración de Panda Software abundantes, el lector encontrará en Seguridad 
informática para empresas y particulares  una
Mientras que la práctica totalidad de libros sobre obra de nivel intermedio pensada desde el pri-
seguridad informática existentes en el mercado mer momento para su aplicación en empresas
abordan el tema desde un medianas y pequeñas que no necesitan com-
lenguaje técnico, orientado plejas arquitecturas de
principalmente a adminis- seguridad, pero que no
tradores de red o programa- por ello deben descui-
dores, Seguridad informáti- darla. Esta obra, escrita
ca para empresas y particu- en castellano, se adecua
lares está dirigido al profe- perfectamente al entorno
sional liberal y la PYME. de las PYME españolas,
Por eso, haciendo uso de cuya realidad conocen los
herramientas que vienen autores.
suministradas con el pro- Desde cómo protegerse del
pio sistema operativo o malware hasta qué hacer con
que son en su mayoría el spam, todos los problemas
gratuitas, con esta obra cotidianos relacionados con el
se puede aprender valor de la información son
desde cuáles son las abordados en este libro cuyo
medidas de seguridad objetivo es que, con muy poco
a implantar para cum- esfuerzo, se pueda alcanzar un
plir con las exigencias nivel de seguridad razonable.

http://digital.revistasprofesionales.com 9 SOLO PROGRAMADORES nº 122

  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 rumo-
res 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 inten-
ción de que sea la continuación natural a sus esfuer-
zos 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 subsis-
tema llamado WinFS) no vería la luz en verano de
2006, fecha para la que está prevista la salida ofi-
cial, sino de forma parcial (ésto es, lo que afecta
únicamente al equipo local) y que (en ese momen-
to) se distribuirá como una beta opcionalmente
instalable, que posiblemente estará lista en su ver-
sión final a comienzos de 2007.
Hablaremos de todo esto, y de cómo se estructura
y fundamenta el nuevo sistema (totalmente cons-
truido 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, inevita-
blemente, 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 mante-
nido desde finales de los 80 por algo totalmente
nuevo? Quizá la respuesta se encuentre en la segu-
ridad y (en buena medida) en las nuevas arquitec-
turas 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 inte-
grando 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 abor-
da 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 pro-
ductos 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 nor-
mativa. Así, desde el inicio, se implica directa-
mente en la creación del estándar XML. Para
ello, incorpora a sus filas a una de las lumbre-
ras mundiales en lenguajes de marcas, el fran-
cés Jean Paoli, quien junto a Tim Bray, repre-
sentando 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 aproba-
ción definitiva de lo que hoy es el nuevo para-
digma 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í, independiente-
mente 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 len-
guaje 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 ade-
lante, 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, atracti-
va 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  misma signatura que el delegado (en tiempo
el nuevo lenguaje. A falta de un nombre mejor,
vamos a llamarlo J++”. Y previamente, añadía:
“hemos conseguido un adecuado maridaje entre  Esta ejecución administrada supone, por
la simplicidad sintáctica de Java y la potencia de  tanto, que los errores pueden ser siempre
C++”. El lector puede ver este e-mail en interceptados. Además, el sistema de tipos es
http://techupdate.zdnet.com/techupdate/sto- común a todos los lenguajes (CTS), y los ejecu-
ries/main/0,14179,2133983,00.html. Hasta ese tables no dependen más que de sí mismos
punto, habían sido C/C++ y Java las fuentes de para la instalación y distribución, haciendo de
inspiración para la creación de lo que ahora la plataforma el marco ideal para el nuevo sis-
conocemos como C# (por cierto, lo del ‘#’, es tema. Por si esto fuera poco, en un mundo de
debido a que simboliza 4 signos ‘+’, como una arquitecturas distribuidas, el soporte nativo de
continuación del trabajo de Bjarne Stroustrup en XML y la facilidad de producción y consumo
el 67. Además, según nos confesaba en una de servicios web, ofrecen un valor añadido que
entrevista posterior (la entrevista se realizó en el resulta crítico en el nuevo subsistema de
Tech-Ed de 2001 en Barcelona, y se encuentra comunicaciones que el sistema incluye (de
publicada en la sección de artículos de nombre clave Indigo).
http://www.elavefenix.net), otros lenguajes teóri- Como ya sabe el lector, .NET apareció hace ya
cos sirvieron en ocasiones de fundamento, como 3 años. En el camino, otros personajes conoci-
es el caso de Haskell u Oberon). dos del mundo del desarrollo han sentido el
atractivo de esta nueva plataforma (y también
Los delegados y la seguridad de los beneficios económicos de la empresa
que lo promociona), incorporándose a distin-
Pero, no nos desviemos de nuestro camino tas áreas del desarrollo de .NET y Longhorn:
hacia Longhorn. Antes de poder crear algo Don Box (autor del estándar XML-Schemas),
tan ambicioso sobre lo que fundamentar Stan Lippman (co-autor junto a Stroustrup del
incluso un nuevo sistema operativo, había lenguaje C++), Peter Drayton (especialista en
problemas graves que resolver. CLR), Yousef Khalidi (arquitecto principal de
Al menos, así lo veía Hejlsberg, quien, en la Solaris 9 y Cluster 3.0, de Sun Microsystems) y
citada conversación veía el problema de la más recientemente, Blake Stone (arquitecto de
siguiente forma (resumo la parte que es fun- JBuilder, de Borland), son algunos de los más
damental aquí para la compresión): “El proble- significativos. Estas son (entonces) algunas de
ma de los errores del sistema operativo ha sido las principales causas y también de los princi-
una de las cuestiones críticas a dilucidar a la pales protagonistas de la historia. Repasemos
hora de la construcción de la nueva platafor- ahora la historia en sí.
ma. Más del 90% es a causa de los drivers y lo
único que podemos hacer con eso, es garanti- Las bases arquitectónicas de Longhorn
zar un esfuerzo por nuestra parte y las compa-
ñías productoras de hardware en ese sentido. Con todo esto por delante, y una nueva ver-
Pero, aún así, existe casi un 10% que es debido sión de la plataforma .NET (ahora se encuen-
a nuestro software. Los análisis que hicimos de  tra en la versión 2.0), comenzó el diseño del
las pantallas azules (las llamadas “Blue  nuevo sistema con unos supuestos muy
Screens of Death”) arrojaban unos resultados  ambiciosos. Para comenzar, se pretende que
sorprendentes. Casi la totalidad se debe única- Longhorn sea instalable en tantos equipos
mente a dos problemas: punteros a función como sea posible (aún usando un grupo fun-
perdidos y problemas de casting (conversión de  cional reducido). Para ello, se han firmado
tipos de datos). Por eso se me ocurrió el con- acuerdos de colaboración con los fabricantes
cepto de delegado, que, no sólo garantiza la de hardware, para intentar extender lo máxi-
presencia de las funciones receptoras de una mo posible la Lista de Compatibilidad de
llamada, (evitando el problema de los punteros  Hardware (HCL), y garantizar (al menos, así se
a función), sino que obliga a que cualquier des- ha dicho), que incluso un Pentium II con 16
tinatario de esa llamada a función tenga la MB de Ram pueda ser el equipo de destino.
De hecho nuevos elementos de la interfaz de
de compilación), terminando definitivamente  usuario como el denominado “Mi Hardware”,
con los problemas de casting” . darán un acceso y posibilidad de configura-
ción sin precedentes al hardware instalado
en el equipo.

http://digital.revistasprofesionales.com 11 SOLO PROGRAMADORES nº 122

  ACTUALIDAD

A todo este conjunto de subsistemas consti-

tuyentes de lo que será la nueva API de
Longhorn, se le denomina WinFX, y permiti-
rá la ejecución de aplicaciones por compati-
bilidad, tan atrás como hasta Win16.
Y otra característica notable: tanto Avalon
como Indigo, serán instalables “en retrospecti-
va”, 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 fun-
cionamiento en el próximo número).

El nuevo modelo de desarrollo

de aplicaciones y WinFX
Pero antes de que vayamos al código, vamos a
describir, de cara al usuario avanzado, toda esa
 El objetivo de Longhorn no sólo es soportar el mayor hardware posible, sino también arquitectura y las implicaciones que va a supo-
ofrecer opciones muy avanzadas de configuración del mismo.
ner, de forma que dispongamos de una imagen
En el otro lado de la balanza, el objetivo es que  Indigo: subsistema de comunicaciones, más o menos plástica de tales cambios.
el sistema pueda aprovechar al máximo las basado en la arquitectura SOA (también Con los anteriores supuestos, el abordaje del
altas prestaciones de los equipos actuales, y que llamada arquitectura orientada a servi- sistema se basa en un cambio completo de
esté preparado para aprovechar todo el hard- cios web). paradigma, que los “evangelistas” de Microsoft
ware disponible, ofreciendo al usuario lo que se  WinFS (Windows Future Storage): han definido como “Programa una vez y dis-
denomina una “nueva experiencia de usuario”, subsistema de almacenamiento. tribuye como y cuando quieras”. Así, se trata
cuya riqueza de posibilidades estará condicio-  Palladium: subsistema de seguridad. de un modelo totalmente orientado a objetos,
nada por la potencia del procesador y de la tar- Diseñado de acuerdo a la iniciativa donde un objeto Application suministra toda
 jeta gráfica que poseamos. Así, si disponemos Trustworthy Computing (Informática la infraestructura de ejecución y cuya “metá-
de una tarjera de 32MB y AGP4 podremos Fiable), a la que pertenecen en la actuali- fora de programación”, (por seguir su propia
acceder a lo que ellos denominan AERO. Un sis- dad, IBM, HP, Oracle, Sun, Microsoft, etc. terminología) es similar a la de ASP.NET. Esto
tema de dibujo de ventanas basado en DirectX  Otros subsistemas asociados como las ayu- es, la interfaz de usuario de una aplicación (si
con una impresionante gama de posibilidades. das, la distribución instantánea de aplica- es que dispone de tal cosa) se escribe en un
Si (además) llegamos o sobrepasamos los ciones (one-touch deployment), y un gran lenguaje de marcas tipo XML, como el lector
64MB, tendremos acceso a AERO-GLASS, la paquete de mejoras e innovaciones. que está siguiendo la serie sobre XAML muy
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.  Esquema de los nuevos subsistemas de Longhorn.

SOLO PROGRAMADORES nº 122 12 http://digital.revistasprofesionales.com

  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 len-
guajes 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 apa-
rició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 progra-
mable, lo mejor de Windows y de la web.
Existe pues, una clara separación entre pre-
sentación y funcionalidad, similar a la de
ASP.NET (o incluso a la de los ficheros XML y  La seguridad es uno de los aspectos que más debe cuidar un sistema operativo.
las hojas de estilo extendidas (XSL), usadas
para su interpretación visual). De hecho la los nuevos chips lleven integradas caracterís- al usuario adecuado. Además, usando la tec-
interpretación gráfica de un fichero XAML es ticas de seguridad que Longhorn pueda apro- nología DRM (Administración de Derechos
directamente una ventana, incluso si no exis- vechar de forma nativa. Son micros que incor- Digitales) Palladium evitará la distribución de
te código fuente asociado con él. De esta porarán esas funcionalidades sin detrimento música, películas, y otro tipo de propiedades
forma el aprovechamiento de las capacidades de la ejecución o el rendimiento y que darán intelectuales a través de Internet (ignoramos a
de DirectX en el dibujo y el pintado en VSYNC origen a toda una nueva generación de soft- la fecha, si esta característica se podrá desins-
con doble buffer, permitirá a los marcos de las ware que aprovechará tales características, talar…) y las productoras de películas y la
ventanas aparecer en parte sombreadas y en aunque los chips y el software básico que lo industria de la música podrán usar esta tecno-
parte translúcidas, haciendo el texto más fácil utiliza permitirá que algunas de esas noveda- logía para permitir a sus clientes usar los dere-
de leer, y dispondremos, igualmente, de trans- des sean utilizadas por equipos antiguos. chos contra el copiado de CDs o películas, por
parencias y animaciones que faciliten y poten- Palladium tiene como algunos de sus objetivos ejemplo. Se asegura que Palladium podrá pro-
cien el uso del sistema. Y todo esto, con visua- más destacados, la posibilidad de informar teger el correo electrónico de tal forma que no
lizaciones de una calidad más moderna y más acerca de con quién se está tratando “on-line”, podrá ser reenviado o copiado a otra gente sin
alta que la utilizada hasta ahora (dependiendo pudiendo limitar (de forma configurable) lo permiso. También se podrán crear documen-
de la potencia de la tarjeta gráfica). Si sólo dis- que llega de Internet y lo que ejecuta cada PC. tos de texto sólo accesibles en fechas determi-
ponemos de una tarjeta básica, (menor de La información se verificará antes de que se nadas u otras circunstancias a establecer.
32MB de memoria), tendremos un sistema pueda acceder a ella. Se protegerán los datos
gráfico tipo Windows 2000. mediante encriptación y el sistema podrá Avalon y algunas consecuencias
Estas novedades en la arquitectura, implican la mantener la integridad de los documentos adicionales
construcción de tipos de aplicaciones total- para que no puedan ser alterados sin el con-
mente nuevas, yendo desde las tradicionales, sentimiento del usuario. ¿Y qué otras consecuencias (meramente ope-
compiladas, a aquellas que se descargan por De igual forma, no se podrán ejecutar progra- rativas, no de programación) nos vamos a
Internet y se ejecutan en el cliente sin dejar mas no autorizados, evitando que los virus encontrar? Pues, depende del subsistema que
huella (una vez concluida su ejecución), u otras afecten al funcionamiento. Respecto al spam, analicemos. Pero en cada uno de ellos un
que se actualizan automáticamente, e incluso será evitado antes de que llegue a la bandeja montón, según parece. Gracias a Avalon, dis-
aplicaciones compiladas de tipo navegador de entrada. El correo no solicitado que se pondremos de las siguientes características:
que se descargan y ejecutan progresivamente. quiera recibir sólo será permitido si sigue una  El menú inicio se podrá convertir en una

serie de credenciales que coincidan con nues- barra lateral realizada en XML que ocu-
Palladium y la seguridad tros parámetros de usuario previamente defi- pará la posición lateral de la pantalla.
nidos. El sistema aplica un nuevo motor de  Se podrá personalizar al igual que la

¿Y qué hay de la seguridad? Palladium es el inteligencia artificial actualmente terminado lista de programas del menú inicio.
nombre clave para un nuevo sistema de segu- y en fase de pruebas en Microsoft Research.  Se mejorarán “Mis Documentos”, “Mis

ridad basado en gran parte en el propio hard- En el otro sentido, también se controlará lo imágenes” y “Mi música”, con despliegues
ware. Microsoft ha llegado a acuerdos con los que sale del PC usando agentes de software de información mejorados que usarán las
principales fabricantes (Intel y AMD) para que que garantizarán que los datos sólo alcanzan últimas innovaciones multimedia.

http://digital.revistasprofesionales.com 13 SOLO PROGRAMADORES nº 122

  ACTUALIDAD
 Avalon mejora notablemente la interfaz gráfica. En esta figura podemos ver el nuevo
aspecto de “Mis imágenes”.
 “Mis Imágenes” incluirá nuevas opcio-
nes para crear un álbum de fotos, des-
cargar 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 completa-
mente en Longhorn e incluirá varias
características nuevas. Esta nueva ver-
sión estará basada en Microsoft
Producer, un añadido de PowerPoint
2003.
 Otra mejora será la del Soporte de
Pantalla Inteligente. Una versión simpli-
ficada de éste ya fue incorporada en el
Service Pack 1 de Windows XP. Esto,
permitirá que dos usuarios puedan ini-
ciar 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
SOLO PROGRAMADORES nº 122 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 transac-
cional) 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 conteni-
do y otros criterios como el nombre del archi-
vo, 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 ningu-
na 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, bus-
car y compartir ficheros.
WinFS es particularmente potente para alma-
cenar datos que necesitan ser buscados o com-
partidos por usuarios y aplicaciones, y en
WinFS, la información se estructura de forma
distinta e independientemente de cómo esté
archivada físicamente. El cómo los usuarios y
aplicaciones organizan esta información, tam-
bién está separada de cómo se almacena en
disco. Los datos pueden ser organizados usan-
do una estructura conectada de carpetas, nom-
bres 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
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 men-
sajería de alto rendimiento, con independencia
de los transportes y canales, y un modelo de
servicios orientado al atributo (al tipo de infor-
mació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 exis-
tente, y que, al igual que sucederá con Avalon,
podrá estar disponible también para las platafor-
mas 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 vera-
no cuando aparezca la primera beta oficial del
producto. Hasta entonces, haremos una revi-
sión de lo que supone Longhorn desde el punto
de vista del desarrollador en el próximo núme-
ro de Sólo Programadores , basándonos en las
versiones “preview” disponibles, tanto del pro-
ducto en sí, como del SDK de WinFX.
http://digital.revistasprofesionales.com
DISPOSITIVOS MÓVILES
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
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   Espectacularidad, ya que son los terminales
desarrollar juegos de auténtica
calidad comercial específicos para
este tipo de terminales.
Introducción
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 exa-
minaremos 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 ins-
talado 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 termina-
les 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éfo-
nos para el mercado de consumo.
Se ha elegido la Serie 60 de Nokia por varios moti-
vos, entre los que cabe destacar los siguientes:
 Cuota de mercado, ya que Nokia actualmen-
te es el líder indiscutible del sector.
 Demanda, ya que los poseedores de este tipo
de terminales son los mayores demandantes
de juegos Java.
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 procedi-
mientos similares se podría usar la API de
Siemens por ejemplo.
Lo primero que debemos saber como programado-
res es sobre qué sistema operativo vamos a pro-
gramar. El “Windows” en telefonía móvil se llama
Symbian OS. Y decimos el “Windows”, no sólo por-
que 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 dis-
tintos, 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 publica-
ció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 desarro-
llar juegos para teléfonos móviles con sistema ope-
rativo 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
 DISPOSITIVOS MÓVILES
 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 J2ME Symbian OS
desventajas de usar código interpretado. Éstas
Tamaño de aplicación
son principalmente baja velocidad de ejecu- permitido
Decenas de Kb Varios MB
ción y limitaciones funcionales. Para entender
estas desventajas hay que saber distinguir Estándar abierto Sí Sí
entre código interpretado y código nativo, que Deployment (Despliegue) Grande Más pequeño
aunque muchos de nuestros lectores ya cono-
cerán las diferencias, vamos a hacer en pocas Soporte de varios
Sí Sí
fabricantes
líneas un pequeño repaso a ello:
 El código nativo es el código que obten- Sí, sin embargo las aplicaciones
dríamos al compilar un programa en de Symbian OS son normalmen-
Instalación OTA Sí
C++. Es el código máquina que puede te tan grandes que es imposible
ser ejecutado por el sistema operativo la distribución OTA
del teléfono móvil. Ejecución de forma nativa No Sí
 El código interpretado es el código que
Lenguaje de programación Java C++
obtendríamos al compilar un programa
en Java. Ese código debe ser traducido a Comunicación con servidores
Sí Sí
código máquina en el momento de su remotos
ejecución, por la Máquina Virtual Java. Animación en 2D Sí Sí
Esa traducción es la responsable de la
baja velocidad de ejecución mencionada Normalmente No. Sólo para los
anteriormente. móviles de última generación que
Cuando se habla de limitaciones funcionales se Animación en 3D soportan la especificación JSR- Sí
está haciendo referencia a que sólo se dispon- 184. Una completa API 3D basa-
drá de los recursos que la implementación de la da en Open GL es Open GL ES
máquina virtual Java nos permita utilizar. La
máquina virtual Java, por tanto, nos aísla , en la Normalmente No. J2ME puede
llamada “sandbox”(caja de arena), de las pecu- reproducir vídeos en teléfonos
liaridades del teléfono que se está programan- Mostrar vídeos
que soporten la Java Mobile
Sí, si lo permite el terminal
do. Razón por la cuál nuestro programa Java no Media API como el Nokia 3650 y
podrá, por ejemplo, usar la conexión por infra- posteriores o en teléfonos con
rrojos del teléfono, a no ser que el fabricante MIDP 2.0
nos proporcione una API a tal efecto. Por poner
un ejemplo, la especificación MIDP 1.0 de J2ME Normalmente No. Se necesita la
Audio MIDI API propietaria del fabricante o Sí
no permite el uso de ningún tipo de sonido. No MIDP 2.0
obstante los fabricantes de terminales con
capacidad para reproducir sonidos polifónicos Normalmente No. Se necesita la
o MIDI, como Nokia o Sony-Ericsson, permiten Audio de alta calidad API propietaria del fabricante o Sí
descargar desde la web las APIs que, entre otras, MIDP 2.0
nos proporcionan funciones para que nuestros
programas puedan sacar el máximo partido de Normalmente No. Acceso a los
sus terminales. En el cuadro “Comparación SMS desde J2ME es posible usan-
J2ME y Symbian OS” se muestra una compara- Acceso a SMS
do la Nokia SMS API (soportada Sí (Además MMS si lo soporta el
tiva entre las dos tecnologías comentadas ante- en Nokia 3410) o la Wireless terminal)
riormente. Messaging API (soportada por los
Nokia 3650 y posteriores)
Limitaciones de la plataforma
Normalmente No. Sólo para ter-
Cuando hablamos de limitaciones de la pla- Acceso a puerto de
minales con MIDP 2.0 ya que Siempre que lo tenga el terminal
Infrarrojos y Bl bluetooth
taforma, nos referimos no sólo a las limita- soportan la Bluetooth API
ciones que tienen los teléfonos móviles en
comparación con los ordenadores de sobre- Acceso a la agenda,
No Sí
mesa, sino también a las de J2ME en compa- calendario…
ración con J2SE (Java 2 Second Edition). En Marcar un teléfono No Sí
los siguientes apartados se enumeran dichas Complicaciones de desarrollo
limitaciones. Menos que Symbian Sí
multiplataforma

http://digital.revistasprofesionales.com 17 SOLO PROGRAMADORES nº 122

DISPOSITIVOS MÓVILES
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 termi-
nales móviles han experimentado un impor-
tante 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 diferen-
cia es el número de colores que pueden repre-
sentar. Desde monocromo hasta los 65.535
colores de los terminales más actuales.
Hay que tener especial cuidado cuando des-
arrollemos juegos susceptibles de ser ejecu-
tados 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 cons-
truir formularios que se verán correctamente
en cualquier pantalla, cuando hacemos un
 juego al final siempre tendremos que usar la
 Figura 2. Despliegue por puerto de comunicaciones.
SOLO PROGRAMADORES nº 122 18
 Figura 1. Despliegue OTA.
clase “Canvas” (lienzo). Y el uso de ésta está
fuertemente ligado a la resolución de la pan-
talla. Para que nuestro juego fuera lo más por-
table posible, lo ideal sería que todos los gráfi-
cos 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 velo-
cidad 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 tene-
mos como objetivo, pues habrá teléfonos que
aún capaces de ejecutar nuestro programa sin
problemas, la baja calidad de su pantalla a
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 direc-
tamente 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 mer-
cado 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 res-
puesta 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 encuen-
tra 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 conti-
nuada de una tecla deberemos hacerlo a la
antigua usanza, almacenando dicha tecla en
una variable, tal y como se explicará más ade-
lante, junto con la forma de detectar la pulsa-
ció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

 Juegos de calidad comercial en J2ME (I)
tipo JAR (Java Archive). Por tanto, las limi-
taciones de tamaño se refieren al tamaño
que ocupa el archivo .jar final del juego
listo para distribuirse.
Aunque el espacio de almacenamiento dis-
ponible en los móviles suele ser muy limita-
do, é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 proce-
so de distribución (deployment) de los jue-
gos 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 trans-
ferencia muy baja. Hasta que no se popula-
rice el uso de redes UMTS (Universal Mobile
Telecommunications System) nuestra apli-
cación deberá viajar por redes de banda
estrecha, pero en cualquier caso el cliente
que compre nuestro producto deberá aca-
rrear con los gastos de la transmisión del
fichero .jar hasta su móvil. Aunque los ter-
minales más potentes podrían soportar jue-
gos que ocuparan más de 1MB sin demasia-
dos 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 blueto-
oth (véase la figura 2). Sin embargo, actual-
mente 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éto-
dos facilitarían la piratería de los programas.
El modelo de negocio novedoso que ha pues-
to 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 pro-
pio sistema operativo del teléfono.
Los procesadores que suelen ejecutar J2ME
son tan poco potentes que no se pueden per-
mitir 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 con-
tadas ocasiones, y debamos nosotros explíci-
tamente 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
DISPOSITIVOS MÓVILES
función de las prestaciones del móvil. Sin
embargo, hay un mínimo de 64KB de memo-
ria 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 emulado-
res que usamos para probar nuestros juegos
en tiempo de desarrollo nos mostrarán siem-
pre en pantalla la cantidad de memoria
usada en todo momento, dato éste que ten-
dremos 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 digita-
les 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 dema-
siado en el aspecto sonoro.
Procesador
Los procesadores de los teléfonos móviles
son por lo general muy lentos y nuestros
19 SOLO PROGRAMADORES nº 122
DISPOSITIVOS MÓVILES
programas no deberían demandar dema-
siados recursos de ellos. Más aún si esta-
mos desarrollando en Java, porque a parte
de los recursos que demande el sistema
operativo, que no son pocos, se estará eje-
cutando 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 mode-
los, 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 prin-
cipio, 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 ines-
tables. Debemos tener en cuenta esto si
pretendemos que nuestra aplicación envíe
o reciba datos. El usuario de nuestro pro-
grama 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
Comparación DP 1.x y DP 2.0
Developer Platform 1.0 for Series 60
MIDP 1.0
CLDC 1.0
Wireless Messaging API (JSR-120)
(excepto el Nokia 7650)
Mobile Media API (JSR-135)
(excepto el Nokia 7650)
XHTML browsing
Mensajería MMS (Mensajes Multimedia)
Sin posibilidad de programar
bluetooth con J2ME
Symbian OS v6.1
Ejemplo: Nokia 3650
actualidad, las operadoras españolas aca-
ban de empezar a comercializar UMTS aun-
que 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 aloja-
da en un servidor, o quizá enviar o recibir
un par de imágenes de baja resolución
. guiar tanto del número de modelo como
La Serie 60 de Nokia
La Serie 60 de Nokia es una línea de produc-
tos guiada por las prestaciones en contrapo-
sició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 platafor-
mas son muy distintas entre sí. Incluso
entre los distintos modelos de una misma
serie se encuentran diferencias importan-
tes en cuanto a recursos y disposición del
teclado.
Por tanto, antes de desarrollar una aplica-
ción para un terminal móvil hay que cono-
cer las capacidades de la plataforma objeti-
vo, 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 concre-
to que nos ocupa, lo único que tiene en
Developer Platform 2.0 for Series 60
MIDP 2.0
CLDC 1.0
Wireless Messaging API (JSR-120)
Mobile Media API (JSR-135)
XHTML Browsing sobre TCP/IP
Mensajes MMS con Synchronized Multimedia
Integration Language (SMIL)
APIs for Bluetooth (JSR-82)
Symbian OS v7.0
Ejemplo: Nokia 6600
común la Serie 60 de Nokia es el tamaño de
la pantalla (176x208 píxeles), una profundi-
dad 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 apa-
rece en el mercado dentro de la Serie 60 es
superior al anterior, y no nos deberemos
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 inter-
medias, por lo que normalmente nos referi-
mos 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 mode-
los de la Serie 60 de Nokia por orden de
aparición.
7650
Primer modelo de la Serie 60 (véase la figu-
ra 4). Modelo de alta gama y alto coste,
http://digital.revistasprofesionales.com

 Juegos de calidad comercial en J2ME (I)
 Figura 4. Modelo  Figura 5. Modelo  
7650 de Nokia.  3650 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 soni-
do 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 disposi-
ció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.
http://digital.revistasprofesionales.com
Figura 6. Modelo  Figura 7. Modelo
N-Gage de Nokia. 6600 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 plata-
forma. 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 ante-
riormente 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 incor-
porada, 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 progra-
mación de juegos. La versión para el merca-
do 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áxi-
ma (heap size) es de 3MB.
DISPOSITIVOS MÓVILES
 Figura 8. Modelo  Figura 9. Modelo
 3660 de Nokia. 7610 de Nokia.
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 america-
na 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 incorpo-
rar una cámara de 1 Megapíxel. Además
es novedoso también su puerto USB Pop-
Port 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 apli-
cació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óvi-
les 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 ejecu-
tan 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, cuan-
do desarrollemos un juego deberemos adap-
tar los gráficos al terminal en el que quere-
mos que funcione nuestra aplicación. Para
ello deberemos conocer con exactitud las
características de la pantalla de nuestro ter-
minal. Esto no es otra cosa que “interrogar” a
la clase “Canvas” sobre sus propiedades, aun-
que también tendremos que sacar algunas
21 SOLO PROGRAMADORES nº 122
DISPOSITIVOS MÓVILES
 
 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 pro-
grama 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 debe-
mos implementar su método “paint()” al ins-
tanciarla. 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 necesa-
rio tener el J2SE SDK (http://java.sun.com/j2se/
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.
SOLO PROGRAMADORES nº 122 22
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 dare-
mos 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 observare-
mos 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:
[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 lis-
tado 1 al directorio de fuentes correspon-
diente, 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 emu-
lador 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 disponi-
ble para nuestro juego un área de 176x144
píxeles, cuando según dijimos anterior-
http://digital.revistasprofesionales.com
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 even-
to “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 interac-
ción con nuestros juegos.
Aunque la clase “Canvas” en principio pare-
ce estar relacionada con gráficos, vemos que
también lo está con el teclado. Esta propie-
dad 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 per-
tenecen al objeto “Display”, y como observa-
mos 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 mos-
trar 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 colo-
res podía mostrar estaba en torno a los
65.000. En el emulador vemos que la panta-
lla muestra 16 millones de colores. Si ejecu-
tamos 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 profun-
didad 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.
 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
En el artículo anterior conocimos las ideas bási-
cas de la estructura de XAML y vimos también
que marcará un hito en la forma en la que se pro-
gramarán las aplicaciones. El hecho de que cam-
bie el motor gráfico implica nuevas posibilidades
y abre el espectro a un nuevo conjunto de aplica-
ciones que serán vistas como una mezcla entre lo
mejor del web y Windows, multimedia, y docu-
mentos. 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 afortuna-
damente aquí comenzaré a desvelar varias carac-
terísticas que si bien mencioné brevemente ahora
ya se está en condiciones de plasmar. Por supues-
to 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 carac-
XAML permite terísticas de XAML y así lograr que esté en carre-
ra para los próximos años.
crear IGUs
Las 6 verdades absolutas sobre XAML
visualizables tanto
Los siguientes 6 puntos ya los vimos en la entrega
en ventanas como anterior, pero deseo refrescar su memoria sobre todo
porque sé que un mes puede llegar a ser mucho tiem-
en navegadores po para tener presente la totalidad de un artículo.
SOLO PROGRAMADORES nº 122 24
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 median-
te código (escritura de eventos para contro-
les, 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 con-
troles que no son de Windows Forms, aunque
en casos extremos se pueden también inser-
tar 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 ade-
cuar el tamaño de los controles de un contenedor
(ventana, marco, etc.) de acuerdo al espacio dispo-
nible, aunque en realidad lo que hacía la infraes-
tructura era reducir los anchos y altos de los ele-
mentos. Mediante las propiedades “Anchor” y
“Dock” se definían medidas relativas al contenedor
o borde y finalmente si el mismo cambiaba los con-
troles 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

 Vea ahora la figura 1, en ella se muestran 3
copias de la misma ventana la que he adecua-
do su tamaño manualmente estirando y/o
contrayendo sus bordes. ¿Qué hay de fantás-
tico en ello? Si presta atención notará que su
contenido ha sido realmente adecuado de
acuerdo al espacio disponible, esto es así por-
que 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 contene-
dor especial llamado “ViewBox”. Pero antes
vamos a analizar brevemente el modelo pro-
puesto 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 distin-
guir 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 decidi-
do 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 difie-
ren de lo que se conoce actualmente.
El primer tipo es el llamado “aplicaciones de
páginas múltiples” y es conceptualmente simi-
lar 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 gene-
ral 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
MIDDLEWARE
 XAML (II)
 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 informa- código a alguna de las páginas entonces se
ción como podrían ser documentos o gráficos. dice que se tiene una aplicación y allí la apro-
Debido a ello están disponibles varias caracte- ximación es diferente. En estos casos se debe-
rísticas para la gestión de la visualización rá compilar el código para poder visualizar su
como puede ser zoom y vistas de una o más resultado de forma funcional. Para ello se uti-
páginas, firmas de documentos, etc. Éste es un liza una herramienta llamada MSBUILD de la
importante capítulo para la nueva infraestruc- que hablaremos en próximas entregas.
tura ya que se ha hecho un esfuerzo muy Otra cosa muy importante a entender es que
grande y como veremos en próximas entregas las aplicaciones navegables o de documentos
se ha adicionado una nueva y completa
infraestructura para la visualización de docu-
mentos. Prometo cubrir este punto en su tota-
lidad en breve.
Finalmente se tienen las “aplicaciones de ven-
tana” donde se cuenta con una o más venta-
nas 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 transparen-
cia total entre ellos. Digo la mayor parte por-
que por supuesto que no es posible emplear
los llamados controles de navegación cuan-
do se usa el modelo de ventanas.
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 sim-
plemente haciendo doble clic; se abrirá enton-
ces el visor predeterminado y mostrará su
 Figura 2. Ejemplo de los tres tipos de 
contenido, al igual que se hace hoy en día con aplicaciones WinFX propuestos por el 
una página HTML. Ahora bien, si se asocia nuevo modelo de Microsoft.
25 SOLO PROGRAMADORES nº 122
 MIDDLEWARE

LISTADO 1 El contenedor ViewBox

pueden ser visualizadas tanto dentro de una
<Viewbox>
ventana como dentro de un navegador. El <Canvas Width=”350” Height=”80” Background=”Gold”>
cambio de un tipo a otro debe indicarse en <!—Aquí dibuja los controles—>
tiempo de compilación, esto no implica en </Canvas>
</Viewbox>
general más que modificar un parámetro de
compilación, lo que hace muy fácil abstraerse 1.-Controles contenedores contenga un panel y que a su vez este panel
del modelo. 2.-Controles de interacción con el usuario contenga otros y así sucesivamente.
Como último decir que la creación de con- El primer grupo ofrece diferentes alternativas El primer paso es entonces elegir uno de
troles también puede ser realizada mediante de paneles, es decir, aquellos que se encarga- ellos de acuerdo a las características que
código prescindiendo de los documentos rán de almacenar a los demás elementos. éste ofrece, lo que lógicamente podrá reper-
XAML. Esto es así ya que como comenté Podemos imaginarnos esto como un conjun- cutir en la conducta de sus miembros. Una
anteriormente cada control es una clase de to de distintos tipos de contenedores para los vez hecho ésto pasaremos a hacer uso del
la infraestructura la cual puede ser gestiona- más diversos usos. La importancia de los segundo grupo, el que ofrece desde botones,
da de forma estándar como tantas otras. controles contenedores radica en que luego hipervínculos, multimedia, etc. Pero antes de
sus integrantes podrán ganar sus caracterís- comenzar a escribir XAML quiero detenerme
Trabajando con contenedores ticas. Por ejemplo, existe un control llamado para comentarle las diferentes alternativas
“ViewBox” que se encarga de que si cambia que necesitará tener instalado si quiere pro-
 Vamos a empezar viendo cómo trabajar con su tamaño se adecue su contenido. Como ve, gramar en XAML:
documentos “sueltos”, esto es, sin lógica aso- éste es el tipo de panel que he utilizado para 1.- Visor XAML de Xamlon y también con-
ciada a ellos. Una vez que entendamos el fun- el ejemplo de la figura 1, el contenido del lis- versor de Flash a este formato
cionamiento comenzaremos a vincular todo tado 1 es un resumen de su código. (http://www.xamlon.com).
esto con los diferentes tipos de aplicación. A A su vez algunos controles de interacción 2.- Visor XAML de Mobiform, que contiene
modo de organizar los distintos tipos de con- con el usuario tienen que ser obligatoria- el único editor gráfico en el momento
trol, he separado a los mismos dentro de 2 gru- mente almacenados por un contenedor (http://www.mobiform.com).
pos lógicos, aunque esta división es totalmen- específico, veremos ésto cuando tratemos al 3.-  Visor XAML de Microsoft contenido
te ficticia y solamente tiene el fin de que pueda tipo “Gris”. Además se pueden anidar varios dentro del paquete SDK de WinFX
entender su funcionamiento y relación: contenedores, por ejemplo que “ViewBox” (http://www.msdn.microsoft.com).
Los 7 tipos de contenedor
Espacio de nombres
Control Descripción
en .NET Framework 2.0
Define un área en el cual cada elemento contenido puede ser dibujado en una coordenada del
Canvas 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.
Establece una cuadrícula consistente de filas y columnas; cada elemento puede ser posiciona-
Gris do 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. 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 for-
Text mato. Es mucho más liviano en recursos, en comparación con “TextPanel”, pero ofrece menos funciona- System.Windows.Controls
lidades.
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.
El contenido del mismo será escalado al tamaño del contenedor. Puede contener un sólo hijo
 ViewBox directo, aunque ésto no es un problema ya que se puede insertar un panel y luego dentro de System.Windows.Documents
éste otros.

SOLO PROGRAMADORES nº 122 26 http://digital.revistasprofesionales.com

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

<TextPanel xmlns=”http://schemas.microsoft.com/2003/xaml” FontFamily=”Palatino Linotype”>

<Heading OutlineLevel=”5”>.NET framework</Heading>
<Heading OutlineLevel=”4”>.NET framework</Heading>
<Heading OutlineLevel=”3”>.NET framework</Heading>

<Paragraph>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 imple-
mentados.</Paragraph>

<Block FontSize=”30” HorizontalAlignment=”Center” Capitals=”Titling”>Guía de migración y actualización a</Block>

<Block FontSize=”30” HorizontalAlignment=”Center”>Visual Basic .NET</Block>
<Block></Block>
<Block HorizontalAlignment=”Center” Capitals=”Titling”>Erich Buhler</Block>
<Block></Block>
<Block HorizontalAlignment=”Center” Capitals=”Unicase”>McGraw-Hill</Block>
<Block HorizontalAlignment=”Center” Capitals=”AllSmallCaps”>ISBN 84-481-3271-8</Block>
<LineBreak/>

<List>
<ListElementItem><Bold>Todo lo que necesita conocer</Bold></ListElementItem>
<ListElementItem><Underline>Explicado en forma sencilla</Underline></ListElementItem>
<ListElementItem><Bold><Underline>18 capítulos</Underline></Bold></ListElementItem>
<ListElementItem><Italic>Casi 1.000 páginas</Italic></ListElementItem>
</List>
</TextPanel>

Es importante destacar que la implementación
WinFX del SDK de Microsoft es lógicamente la
que ofrece el conjunto más amplio de carac-
terísticas. Sin embargo al momento de escribir
este artículo la misma requiere que esté sus-
crito a la MSDN. Por su parte Mobiform cuen-
ta 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 posi-
bles 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.
Canvas... el modelo tradicional
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 posicio-
nados en un valor fijo del eje vertical y horizon-
tal respectivo al contenedor. El listado 3 emplea
un “Canvas” principal y luego otros secunda-
rios 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
a las propiedades “Left” y “Top” del panel prin-
cipal para indicar su posicionamiento dentro
del mismo. Véase el resultado en la figura 4.
DockPanel
“DockPanel” organiza los elementos contenidos
en forma horizontal o vertical uno con respec-
to al otro. Cada control integrante puede esta-
blecer 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 res-
pecto 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 eti-
quetas HTML. Ello hace que sea fácil compren-
der su funcionamiento. Básicamente es posible
especificar desde diferentes tipos de letras a blo-
ques, pasando por párrafos o listas de elemen-
tos, así como también jerarquía de títulos. El lis-
tado 2 muestra cómo exhibir un texto formate-  Figura 3. El código del listado 2 en ejecución.

SOLO PROGRAMADORES nº 122 28 http://digital.revistasprofesionales.com


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 modifi-
que 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 conte-
nido que pueda en algún momento ocupar
más de una línea y tenga que ser reorganiza-
do dinámicamente. Básicamente este panel
contiene propiedades para indicar el alinea-
miento y qué hacer si se sobrepasa la línea. A
su vez el panel puede reacomodar sus miem-
bros de forma que se utilice mejor el espacio.
El listado 5 muestra cómo “FlowPanel” reorga-
niza automáticamente su contenido cuando el
tamaño del panel es menor que el de la longi-
tud 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 con-
tenido a su nuevo tamaño, pero a diferencia
con otras aproximaciones, el mismo es real-
mente escalado en vez de limitarse solamente a
disminuir los espacios o tamaño de los contro-
les. Como podemos apreciar en el listado 6 se
 Figura 4. El código del listado 3 en
ejecución.
http://digital.revistasprofesionales.com
MIDDLEWARE
 XAML (II)
LISTADO 3 Combinación de Canvas
<Canvas
xmlns=”http://schemas.microsoft.com/2003/xaml”
Height=”600”
Width=”800”>
<Canvas Height=”100” Width=”100” Top=”10” Left=”0”>
<Rectangle Width=”100” Height=”100” Fill=”red”/>
</Canvas>
<Canvas Height=”100” Width=”100” Top=”110” Left=”100”>
<Rectangle Width=”100” Height=”100” Fill=”green”/>
</Canvas>
<Canvas Height=”100” Width=”100” Top=”50” Left=”50”>
<Rectangle Width=”100” Height=”100” Fill=”blue”/>
</Canvas>
<Button Canvas.Left=”10” Canvas.Top=”220” Width=”100” Height=”50”>Hace
algo...</Button>
</Canvas>
LISTADO 4 Organizando elementos con DockPanel
<DockPanel
xmlns=”http://schemas.microsoft.com/2003/xaml”>
<DockPanel
Height=”100%”
Width=”50%”>
<Button DockPanel.Dock=”Top” Width=”20%” Height=”10%”>Arriba</Button>
<Button DockPanel.Dock=”Bottom” Width=”20%” Height=”30%”>Medio</Button>
<Button DockPanel.Dock=”Bottom” Width=”20%” Height=”10%”>Abajo</Button>
</DockPanel>
<DockPanel
xmlns=”http://schemas.microsoft.com/2003/xaml”
Height=”100%”
Width=”50%”>
<Button DockPanel.Dock=”Fill”>Completo</Button>
</DockPanel>
</DockPanel>
cuenta con propiedades de alto y ancho máxi- ellos tendrá que adicionar alguno de los
mo, lo que lógicamente indicará que en caso de paneles vistos anteriormente y luego ya sí
sobrepasarse la altura o ancho el contenido se dentro del mismo los elementos que desee.
fije utilizando esta información (véase de nuevo
la figura 1). Recursos y estilos
Debe tener en cuenta que “ViewBox” puede
contener un sólo control secundario, por lo En XAML es muy sencillo personalizar la apa-
que en caso de que desee insertar más de riencia de los controles y de la aplicación
 Figura 5. El código del listado 4 en ejecución.
29 SOLO PROGRAMADORES nº 122
 MIDDLEWARE
 Figura 6. El código del listado 5 en
ejecución.
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 ele-
mento 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 ele-
mento 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 referen-
cia al recurso utilizando llaves, y recordando
que se diferencia entre mayúsculas y minús-
culas. La siguiente línea establecerá como
fondo del botón el relleno definido en el
recurso del panel:
<Button Background=”{MiColor}”/>
En tiempo de ejecución el valor “Micolor”
será buscado en la colección de recursos del
botón, pero al no haber nadie con este nom-
bre se subirá en la jerarquía hasta que se
encuentre uno con la misma denominación.
Sin embargo existe una utilidad que es real-
mente interesante, la que radica en la posi-
bilidad de definir un objeto plantilla y pos-
teriormente aplicar las características del
mismo a otro objeto del mismo tipo; a esto
se lo denomina “Estilo” (véase el listado 8 y
la figura 7).
 Figura 7. Como se aprecia en la figura,
la personalización de los controles  conflicto siempre se descartará el valor del
mediante estilos va más allá de un simple 
cambio de colores.
SOLO PROGRAMADORES nº 122 30
LISTADO 5 Reorganizando el contenido con FlowPanel
<Border xmlns=”http://schemas.microsoft.com/2003/xaml” Background=”White”>
<FlowPanel>
<Border Background=”Yellow” Width=”1in” Height=”1in”/>
<Border Background=”Blue” Width=”1in” Height=”1in”/>
<Border Background=”Red” Width=”1in” Height=”1in”/>
<Border Background=”Green” Width=”1in” Height=”1in”/>
</FlowPanel>
</Border>
LISTADO 6 Ejemplo de ViewBox
<Window xmlns=”http://schemas.microsoft.com/2003/xaml/”>
<Viewbox MaxHeight=”600” MaxWidth=”800”>
<Canvas Width=”350” Height=”80” Background=”Gold”>
<Label ID=”Label1” Height=”18” Width=”177” Canvas.Top=”17”
Canvas.Left=”15” FontSize=”12”>Nombre del archivo:</Label>
<TextBox Height=”24” Width=”177” Canvas.Top=”16” Canvas.Left=”139”
Foreground=”Black” BorderBrush=”Black” FontSize=”12”/>
<Button Height=”20” Width=”77” Canvas.Top=”49” Canvas.Left=”153”
BorderBrush=”Black” FontSize=”12”>Abrir</Button>
<Button Height=”20” Width=”77” Canvas.Top=”49” Canvas.Left=”238”
Foreground=”Black” BorderBrush=”Black” FontSize=”12”>Cancelar
</Button>
</Canvas>
</Viewbox>
</Window>
LISTADO 7 Definiendo un nuevo recurso
<Border
xmlns=”http://schemas.microsoft.com/2003/xaml”
xmlns:def=”Definition”
Background=”Yellow”>
<FlowPanel>
<FlowPanel.Resources>
<SolidColorBrush def:Name=”MiColor” Color=”Red”/>
</FlowPanel.Resources>
<Button Background=”{MiColor}”/>
<Ellipse Fill=”{MiColor}”/>
</FlowPanel>
</Border>
LISTADO 8 Definiendo un nuevo estilo
<Border
xmlns=”http://schemas.microsoft.com/2003/xaml”
xmlns:def=”Definition”
Background=”BlanchedAlmond”>
<FlowPanel>
<FlowPanel.Resources>
<Style def:Name=”MiPlantillaBoton”>
<Button Background=”Red” FontSize=”18” Height=”30”/>
</Style>
</FlowPanel.Resources>
<Button>Botón normal</Button>
<Button Style=”{MiPlantillaBoton}”>¡Este sí que es un botón con esti-
lo!</Button>
</FlowPanel>
</Border>
En este caso se ha definido un botón de plan- Conclusiones
tilla que contiene el posible estilo a utilizar.
Aquí se incluye el color de fondo, de fuente y Hasta aquí hemos llegado, sé que nos falta
la altura, pero nada con respecto al resto de mucho por ver y como siempre hay poco
las propiedades. En tiempo de ejecución se espacio. En la próxima entrega seguiremos
dibujará el botón utilizando el estilo y poste- avanzando en el tema de estilos ya que le
riormente se aplicarán los valores establecidos brinda mucha flexibilidad (aquí simplemente
en el propio control. Para el caso de haber un he hecho una breve reseña). Además conoce-
remos más sobre controles y documentos.
estilo quedando el del elemento en sí. 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 limi-
taciones 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 panta-
lla 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 revolu-
cionar el sector con un nuevo modelo de
programación declarativo para las interfa-
ces de usuario. En este punto, el lector
encontrará ejemplos de interfaces pro-
gramadas con XAML. En las páginas del
artículo se explica cómo y dónde
obtener las aplicaciones para visuali-
zar estas interfaces gráficas.
Servlets Filters (I)
Podríamos encontrar muchísimas uti-
lidades para un filtro en una aplica-
ción web. En esta ocasión, ofrecemos la
implementación de un filtro que “proce-
sará” 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 des-
arrollo más populares para los programa-
SOLO PROGRAMADORES nº 122 32
dores Java. En esta sección se incluye el do, en gran parte, las cuestiones tecnoló-
proyecto que se ha venido desarrollando en gicas referidas a la implementación. En
el artículo. última instancia, se pretende que las apli-
caciones puedan ser menos vulnerables a
Programación los cambios tecnológicos.
Por ejemplo, AndroMDA es capaz de recibir
AndroMDA 3.0M3 como entrada un modelo conceptual (dise-
AndroMDA es una herramienta construida ñado con una herramienta CASE) y generar
siguiendo el paradigma del desarrollo de a partir de él el código que lo implementa.
software dirigido por modelos, o más con-
cretamente, la propuesta MDA (Model CMS
Driven Architecture) de OMG. Para aque- Los Sistemas Gestores de Contenidos (CMS)
llos no iniciados en los conceptos que son una buena opción para el desarrollo de
esconde MDA, diremos que este paradig- portales web. Sin duda es una buena noticia
ma propone un modelo de desarrollo de 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 plata-
forma J2EE).
Recomendamos visitar el site
http://www.opensourcecms.com,
pues en él hay multitud de conteni-
dos de interés, tanto para quienes
estén interesados en iniciar un des-
arrollo con un CMS, como para quie-
nes quieran ampliar sus conocimien-
tos 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
software basado en enfatizar las tareas de son los contenedores de Servlets más
especificación, dejando que la lógica sea populares, sin embargo Resin se diferencia
implementada de forma automática por en algo fundamental: también dispone de
las herramientas (como un contenedor de EJBs.
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 refe-
conocimiento 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++.
http://digital.revistasprofesionales.com
 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  te un ejemplo práctico a VE, veremos cómo instalarlo,
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 herra-
mienta 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.
SOLO PROGRAMADORES nº 122 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 median-
y las posibilidades que tiene para el desarrollo auto-
mático de interfaces de usuario. Como el lector recor-
dará, 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 plug-
ins. Un plug-in es una unidad de ejecución que
amplia la funcionalidad de la plataforma. De hecho
la plataforma propiamente dicha apenas ofrece fun-
cionalidad, básicamente permite gestionar recursos
y manejar programas Java, y en el SDK que es la dis-
tribució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 estruc-
tura 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 plug-
ins 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 pro-
yecto 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

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 pue-
den obtener enlaces a esos dos plug-ins.
Nosotros usaremos durante el artículo las ver-
siones 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 conteni-
do del directorio descomprimido “Features”
bajo el directorio “Features” de Eclipse y el con-
tenido 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 que-
remos 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 resu-
men todos los posibles contenedores de compo-
nentes 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 pode-
mos ver cómo verá el usuario la clase en tiem-
po 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 gene-
rado automáticamente, estas dos zonas están
conectadas de manera que si por ejemplo cam-
biamos el tamaño del Frame en la zona 1, vere-
mos 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ña-
dir nuevos componentes a la clase creada,
como podemos ver incluye todos los compo-
nentes Swing posibles. Desde la paleta es posi-
ble añadir un componente al Frame simple-
mente arrastrando y soltando, y automática-
mente se añade el código necesario a la clase.
La cuarta zona es la vista de JavaBeans. Los com-
ponentes 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 apa-
rece en gris en la pantalla, y en la zona de códi-
go 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 propieda-
des del componente. Esta zona cambia depen-
diendo del componente seleccionado, según las
posibles propiedades del mismo. Por ejemplo,
en el caso del Frame podemos editar propieda-
des como por ejemplo el “Layout”. Si cambiamos
las propiedades de la zona 5 se modifica auto-
máticamente el código generado en la zona
visual (zona 1) y en la zona de código (zona 2).
MIDDLEWARE
 Vamos ahora a probar el editor visual. En pri-
mer 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 nues-
tra 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 des-
arrollo 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 apli-
cación normal Java, opción “Run”->“Run as”-
>“Java Application”. Como vemos el resultado
final es el mismo de cualquiera de las dos for-
mas 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 construc-
tor de la clase se llama a un método de iniciali-
37 SOLO PROGRAMADORES nº 122
 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 almace-
nan 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 cre-
ada simplemente arrastrando y soltando, sin
embargo ya que queremos presentar las
posibilidades de VE vamos a elegir otro enfo-
que. Vamos a crear un panel personalizado,
con una serie de componentes sencillos y
luego vamos a insertar en la pantalla princi-
pal 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”.
SOLO PROGRAMADORES nº 122 38
Para alinear los tres componentes, igualar la dis-
tancia 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 resal-
tado en rojo el botón a seleccionar y la ventana
que aparece. La ventana de “Customize Layout”
permite ajustar los componentes a la parte supe-
rior del panel, igualarlos en alto y ancho, distri-
buirlos entre el espacio tanto horizontal como
vertical del panel… con lo cual fácilmente se con-
sigue un diseño más profesional.
Podemos comprobar la apariencia del panel
seleccionándolo en la vista de Beans y eligien-
do “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
Al nuevo panel que nos crea VE le vamos a componente añadido al panel crea un campo
cambiar algunas propiedades, en primer de la clase del tipo oportuno, y en el método
lugar le modificamos la propiedad del “initialize” configura propiedades del panel
“Layout”. Por defecto un panel se crea con la como el Layout y le añade como hijos los obje-
propiedad layout fijada a “FlowLayout”, en tos anteriores tras inicializarlos.
nuestro caso la cambiaremos por un valor El objetivo de nuestro panel será almacenar el
“null”. A continuación añadiremos a este texto que introduzca el usuario en una propie-
panel un par de componentes, añadiremos dad del panel llamada “Nombre”, de tipo “String”
una etiqueta (“JLabel”) a la que le cambiamos y a dicha propiedad le añadiremos un método
el campo “Text” por “Nombre”, un botón para fijarle el valor y para recogerlo, por lo tanto
(“JButton”) al que le ponemos como texto habrá que añadir el siguiente código:
“OK” y un campo de texto (“JTextField”), hasta private String nombre = “N/A” ;
crear un diseño parecido al que se puede ver
public String getNombre()
en la figura 3.
LISTADO 1 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;
}
}
http://digital.revistasprofesionales.com
 MIDDLEWARE
Desarrollo visual de IGUs Java

{ 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 algu-
na 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);
 Figura 3. Panel personalizado.
getJTextField().setText(string);
private JTextField getJTextField() { public void actionPerformed(java.awt.
this.nombre = string;
… event.ActionEvent e)
} {setNombre( jTextField.getText());}
jTextField.addActionListener
Como se puede observar, básicamente lo que (new java.awt.event.ActionListener() { Ahora cuado el usuario escriba algo en el campo
hemos hecho es invocar a un método public void actionPerformed(java. de texto, dicho valor se fijará en la propiedad
“firePropertyChange”. Este método se ocupa de awt.event.ActionEvent e) “Nombre” del panel, y el método que lo fija,
lanzar un evento indicando que la propiedad se “setNombre”, se ocupará de lanzar un evento
{System.out.println(“action
ha modificado. De esta manera, para que cual- indicando que la propiedad se ha modificado.
Performed()”);}
quier otro objeto se entere de que se ha modi- Como podemos ver con VE se facilita mucho la
});
ficado la propiedad, basta con que implemen- gestión de eventos. Si en lugar de seleccionar la
te un manejador del evento que genera el … opción de “Action Performed” hubiéramos selec-
método “setNombre”, veremos más adelante } cionado la opción “Add Events”, nos aparecería
cómo hacerlo. una nueva ventana en la cual podríamos ver
Como podemos ver el manejador del evento catalogados por secciones todos los eventos
Eventos creado sólo escribe por la consola un mensaje posibles, como por ejemplo eventos que respon-
de texto. Podemos modificar esa línea para dan cuando una tecla es pulsada, etc. En esa
Ya tenemos creada nuestra propiedad donde añadir la inteligencia que queramos al maneja- pantalla podremos añadir un manejador de cual-
almacenar el valor, pero ahora necesitamos dor. Nosotros vamos a modificar esa línea y quiera de los eventos que se puedan producir.
enterarnos de cuándo el usuario introduce cambiarla por una que fije la propiedad al valor   Vamos a repetir el proceso para añadir un
un nuevo texto en el campo de texto o cuán- introducido en el campo de texto: evento a la pulsación del botón, para ello selec-
do 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 con-
vierte 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 pulsa-
mos el botón derecho del ratón, nos aparece-
rá un menú emergente en el que selecciona-
mos la opción “Events”->“Action Performed”.
 Veremos que automáticamente se nos modi-
fica el método “getTextField” y se añade el
código del manejador (listener) que se mues-
tra a continuación:  Figura 4. Alineando los componentes.

http://digital.revistasprofesionales.com 39 SOLO PROGRAMADORES nº 122

 MIDDLEWARE

LISTADO 2 Código del panel generado automáticamente “MiPanel”. Cuando seleccionemos el Bean nos
aparecerán resaltadas sobre el Frame las distin-
public class MiPanel extends JPanel {
tas zonas en las que podemos insertar el nuevo
private JLabel jLabel = null; componente, y arrastraremos el componente
private JTextField jTextField = null; seleccionado sobre la zona que queramos, al
private JButton jButton = null;
igual que haríamos con un componente normal
public MiPanel() { … } añadido desde la paleta. En este ejemplo la
private void initialize() { arrastraremos a la zona central del Frame.
this.setLayout(null); Como vemos, el Panel que habíamos creado
this.setSize(271, 56);
jLabel = new JLabel();
antes se inserta en el Frame que será la panta-
jLabel.setBounds(31, 21, 53, 20); lla principal de nuestra aplicación. Como no
this.add(jLabel, null); vamos a añadir más componentes a la pantalla
this.add(getJTextField(), null);
this.add(getJButton(), null); pues podemos redimensionar la pantalla para
} que se ajuste mejor al tamaño del Panel que
private JTextField getJTextField() {
if (jTextField == null) {
hemos insertado.
jTextField = new JTextField(); El código que VE nos ha generado para inser-
jTextField.setBounds(100, 21, 53, 20); tar el Panel en la pantalla principal es el
}
return jTextField; siguiente:
} private MiPanel miPanel = null;

private JButton getJButton() { private MiPanel getMiPanel() {

if (jButton == null) {
jButton = new JButton();
jButton.setBounds(168, 21, 53, 20);
jButton.setText(“OK”);
}
return jButton;
} 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 propie-
dad “Nombre” del panel:
private JButton getJButton() {
…
jButton.addActionListener(new java.
awt.event.ActionListener() {
public void actionPerformed(java.
awt.event.ActionEvent e)
{setNombre( jTextField.getText());}
});
…
} programa y el panel creado, además vamos a
Ya tenemos casi completo nuestro panel, nos
hemos ocupado de que tenga el aspecto que que-
remos 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 ini-
ciarse tenga el valor de la propiedad “Nombre”:
… cual podemos buscar los JavaBeans disponibles.
private JTextField getJTextField() {
…
jTextField.setText(nombre);
… veremos que tiene una propiedad llamada
}
Si nos fijamos ahora en la vista de JavaBeans
(véase la figura 3), veremos que se han añadi-  
do 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
ver cómo crear un manejador que reaccione
cuando se modifique la propiedad del panel.
Primero seleccionamos el Frame principal, y pul-
samos el botón de la barra de tareas de elegir
Bean, el botón que aparece resaltado en un cír-
culo rojo en la figura 3 (parte superior derecha
de la figura). Nos aparecerá una pantalla en la
Escribimos en nuestro caso el nombre que le
hayamos puesto al panel, en este ejemplo
if (miPanel == null) {
miPanel = new MiPanel();
}
}
Si ahora pinchamos en la zona del panel de la
pantalla principal y miramos las propiedades
“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 selec-
cionar 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 seleccio-
namos 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 pan-
talla principal qué hacer cuando el usuario la

SOLO PROGRAMADORES nº 122 40 http://digital.revistasprofesionales.com

 MIDDLEWARE
Desarrollo visual de IGUs Java

Listener de cambio de propiedades

cierre. El proceso es el mismo que hemos LISTADO 3 generado automáticamente
hecho antes, generar un manejador que res-
private MiPanel getMiPanel() {
ponda a un evento, en este caso el cierre de la if (miPanel == null) {
ventana. Seleccionamos el Frame y pulsamos el miPanel = new MiPanel();
botón derecho, en el menú emergente que miPanel.setNombre(“N/A”);
miPanel.addPropertyChangeListener(“nombre”, new
aparece seleccionamos “WindowClossing”, y java.beans.PropertyChangeListener() {
modificamos el manejador que nos genera VE, public void propertyChange(java.beans.PropertyChangeEvent e) {
System.out.println(“propertyChange(nombre)”);
añadiendo el código “System.exit(0);” como }
vemos en el listado 4. });
}
Ya tenemos la aplicación lista, ahora podemos return miPanel;
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 men- LISTADO 4 Código de finalización de la aplicación
saje indicando que se ha modificado la propiedad.
private void initialize() {
El enfoque que hemos elegido de crear un panel this.setTitle(“Hola Mundo”);
y a ese panel añadirle los componentes sencillos this.setSize(351, 90);
y luego insertar el panel en la pantalla principal this.setContentPane(getJContentPane());
this.setVisible(true);
de la aplicación puede parecer excesivamente this.addWindowListener(new java.awt.event.WindowAdapter() {
complicado. En realidad habríamos conseguido public void windowClosing(java.awt.event.WindowEvent e) {
System.exit(0);
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 flexi-
ble. 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 importan-
te, 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
 Figura 5. Diferentes Look And Feel.
vamos al menú “Windows”->“Preferences”
para abrir la pestaña de “Java”->“VE”. Nos apa-
rece una pantalla con un apartado con los dis-
tintos 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 aspec-
to 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 ejecu-
ció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();
}
Si ahora ejecutamos de nuevo la aplicación vere-
mos 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 ejecu-
temos 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 aspec-
to correcto en todos los entornos sería conve-
niente 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 lim-
pieza 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 nece-
sita de una máquina bastante potente, pero al
ritmo que avanza el hardware esto no parece un
problema demasiado importante.

http://digital.revistasprofesionales.com 41 SOLO PROGRAMADORES nº 122

 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 basa-
dos en PHP, sistemas basados en Java y sistemas
basados en el empleo de otras tecnologías. Dentro
de esta última familia repasamos las característi-
cas 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  mas extensiones de estos CMS disponibles para su
Open Source.
SOLO PROGRAMADORES nº 122 42
la solución idónea para organizaciones que bus-
quen una solución integrada. Seguidamente vere-
mos 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 soft-
ware 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 ser-
vidores de aplicaciones y bases de datos existen-
tes 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 platafor-
mas J2EE o .NET, en gran parte debido a que el
balanceo de carga no está tan fácilmente imple-
mentado 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 simila-
res, 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 comu-
nidad 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 rendi-
miento 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ísi-
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 admi-
nistración, etc. Además, no ofrecen muchas
opciones para diseñar la apariencia y distri-
bució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 de-
sarrollo fue iniciado en 1999. También está
basado en PHP, MySQL y Apache, pero es de
mayor robustez y escalabilidad que los ante-
riores, 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  Figura 2. Portal de Postnuke, el otro gran CMS Open Source en PHP.
sitios web dentro de un mismo CMS, gracias
a aplicar un modelo de bases de datos vir-
tuales, y la incorporación de un motor de taforma: OpenCMS, Magnolia, Jboss Nukes, servidores de aplicaciones J2EE, excelente
workflow basado en la tecnología XML. Jahia, o incluso el CMS impulsado por la soporte para el estándar XML y tecnologías
comunidad JavaHispano, colaboradora habi- derivadas como Web Services, motores de
Soluciones CMS basadas en la tual de esta revista, Canyamo, con el que plantillas para el renderizado HTML, etc. No
plataforma J2EE ésta ha desarrollado su portal web. obstante, cada proyecto sigue sus propias
Todos estos sistemas se benefician de las pautas de desarrollo, y tiene sus propias
Actualmente la plataforma de desarrollo ventajas de la plataforma Java: portabilidad políticas de calidad y diseños. Esto hace que
empresarial J2EE parece estar imponiéndose a todas las plataformas para las que haya la comunidad existente detrás de cada uno
para la construcción de aplicaciones de lado disponible una máquina virtual, conectivi- de ellos sea desigual. Como en este artículo
del servidor. Por esta razón, existe un gran dad con cualquier tipo de base de datos no podemos hablar de todos ellos, comenta-
número de CMS desarrollados bajo esta pla- mediante el estándar JDBC, integración con remos algunas de las principales caracterís-
ticas 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 infre-
cuente en los proyectos de software libre).
Además, no requiere de ninguna base de
datos adicional.

OpenCMS
OpenCMS comparte con Magnolia todos
los beneficios derivados de utilizar la pla-
taforma Java. Además, también resulta
bastante sencillo de instalar. OpenCMS dis-
pone de una comunidad más amplia que
Magnolia pues ha surgido como un pro-
 Figura 3. Creación de workflows en OpenCMS. yecto libre promovido por su propia comu-

http://digital.revistasprofesionales.com 43 SOLO PROGRAMADORES nº 122

 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 organiza-
dos 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 reposito-
rio 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ña-
dirlos al repositorio, y desde éste a la pági-
na que se está creando. Esto facilita nota-
blemente la gestión de estos recursos, y
evita su duplicidad. OpenCMS también pro-
porciona herramientas gráficas para la cre-
ación de workflows. En la figura 3 podemos
ver cómo gracias a esta herramienta se
pueden crear tareas y asignárselas a usua-
rios dentro del workflow de creación de
contenidos. Esta herramienta permite ade-
má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 presen-
tación establecidas. Para evitar los proble-
mas 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 conteni-
do 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 conte-
nidos que tienen un carácter muy estático,
como imágenes o archivos binarios. Otro
punto destacable de OpenCMS es la inclu-
sión de características de seguridad:
OpenCMS permite aplicar encriptado fuerte
a todo el sitio web o a parte de él, etique-
tando a sus contenidos como “sólo accesi-
bles 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 existen-
tes es cada vez mayor. La mayoría de estos
sistemas han creado mecanismos para su
fácil extensión, basados en el empleo de fra-
meworks que permitan la creación de com-
ponentes de portal denominados Portlets.
De esta forma, cuando construimos un por-
tal web con nuestra herramienta CMS y le
añadimos una sección de noticias, el compo-
nente de software encargado de implemen-
tar esta funcionalidad sería un Portlet, des-
arrollado con el framework proporcionado
por el CMS.
No obstante, esta variedad de frameworks
incompatibles unos de otros representa un
problema, puesto que los componentes des-
arrollados para un CMS no son reutilizables
para otros CMS. Esto ha desembocado, den-
tro del mundo Java, en la especificación JSR-
168 o especificación de Portlets, cuyo objeti-
vo es proporcionar interoperabilidad entre
Portlets y portales.
Desde el punto de vista de esta aproxima-
ción, un CMS estaría formado por un con-
tenedor de Portlets, que gestionaría los
componentes de portal, recibiría peticiones
y generaría contenido dinámico. Los porta-
les 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 mecanis-
mos 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 proce-
sa las peticiones de clientes, solicita todos
aquellos Portlets que formen parte de la pági-
na actual del usuario al contenedor de Portlets,
que se encargará de cargarlos y ejecutarlos,
volcando finalmente en la página final el con-
tenido de la ejecución de cada Portlet. El con-
tenedor de Portlets proporciona el entorno de
http://digital.revistasprofesionales.com

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 informa-
ció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 con-
sigue 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 esta-
rí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 utili-
zado para realizar operaciones costo-
sas 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 redi-
recció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 libe-
rar 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 especifi-
cació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 sali-
das. El modo de edición se utiliza para
modificar las configuraciones de usua-
rio que les permiten personalizar la
apariencia del Portlet, y el modo de
ayuda se emplea para visualizar en
pantalla información sobre el funcio-
namiento 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 empa-
quetados juntos en fichero WAR. Para los
lectores que desconozcan esta plataforma
de desarrollo empresarial, cabe decir que
un descriptor de despliegue es un docu-
mento XML que proporciona información
de configuración sobre el Portlet al conte-
nedor, y que un fichero WAR es un fichero
de empaquetado para componentes des-
plegados en un servidor de aplicaciones.
REDES
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 inclui-
da 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 con-
tenedor (para la comunicación portal-conte-
nedor) 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 peti-
ciones de los clientes y accede al contene-
dor a través del API de invocación del con-
tenedor de Portlets. Para tal fin, aquellos
servicios que invoquen al contenedor de
Portlets deben implementar la interfaz SPI
para proveedores de servicios. Esto es nece-
sario 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 por-
tal. 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 quere-
45 SOLO PROGRAMADORES nº 122
 REDES

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, permitien-
do a un usuario navegar entre los domi-
nios de diferentes portales sin tener que
volver a autentificarse al cambiar de
portal. Básicamente consiste en un pro-
tocolo 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
 Figura 5. Arquitectura del contenedor de Portlets y portal de Portlets Pluto. concebida en un primer momento para con-
seguir la integración de los diferentes porta-
mos desplegar. Este script de despliegue cientos de URLs y autentificarse en tantos les departamentales de una misma organiza-
forma parte de la instalación de Pluto. sitios como portales contengan la informa- ción. Un paso más en este sentido consiste en
Por último, una vez desplegados los Portlets ción que requiere consultar. Para ello, estos la federación entre portales de diferentes
y registrados en el componente de portal, portales deberán coordinarse para propor- organizaciones. Para dar respuesta a esta
habría que definir la apariencia final del cionar una sola autentificación (lo que se necesidad han surgido proyectos como
portal. Para tal fin, Pluto utiliza el archivo viene a denominar “single sign-on”), lo que Liberty (http://www.projectliberty.org), o
de configuración “pageregistry.xml”. En esta implica crear un único usuario para todos Microsoft Passport (http://www.passport.net).
estructura XML se incluirán etiquetas para estos portales. Además, deberán comuni-
introducir la salida de un Portlet en la com- carse para intercambiar contenido entre Conclusiones
posición final de la página, indicando la ellos y así atender las solicitudes de sus
orientación que deben tomar sus salidas en usuarios. Evidentemente, esta coordinación A lo largo de estos dos artículos hemos tra-
dicha composición final. entre portales no sería posible sin la elabo- tado de introducir al lector en el tipo de sis-
ración de estándares a los que todos se tema que constituye un CMS. Hemos visto
Siguiente paso en la gestión de adhieran. En este sentido la industria de algunas de sus principales características y
portales: portales federados elaboración de gestores de contenido y ser- funcionalidades, y una pequeña muestra de
vidores de portal ha creado varios estánda- productos comerciales y de carácter libre.
Según la prestigiosa consultora Garnet res para alcanzar este objetivo: En la parte final de la serie, nos hemos cen-
Group, los sistemas WCM tenderán hacia la  El estándar JSR-168, descrito con ante- trado en una interesante iniciativa para la
construcción de portales federados. Este rioridad, para buscar la portabilidad de estandarización de los elementos de portal
tipo de portales se basan en permitir a sus Portlets creados por diferentes fabri- para CMS en la plataforma Java: la especi-
usuarios, bien sea de una intranet, extranet cantes a diferentes servidores de portal. ficación JSR-168.
o de Internet, acceder a una determinada  El estándar WSRP (Web Services for No obstante, a la hora de optar por una solu-
información de forma transparente a la Remote Portlets) trata de dar solución al ción u otra no sólo influyen los condicionan-
localización real del contenido. En conse- problema del intercambio de contenido tes técnicos o económicos. También influye la
cuencia, los diferentes portales que conten- entre portales remotos. Para ello, se apoya plataforma tecnológica (sistema operativo,
gan esta información se integrarán de en la tecnología de servicios web, de forma bases de datos, servidor de aplicaciones, etc.)
forma que el usuario no necesite recordar que para acceder a contenido albergado 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 adminis-
trador 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.

SOLO PROGRAMADORES nº 122 46 http://digital.revistasprofesionales.com

 REDES

Servlets Filters (I)

Los filtros permiten
procesar tanto las
peticiones que
llegan a nuestra
aplicación como
las respuestas
de ésta
ADOLFO ALADRO GARCÍA
Agregando filtros a nuestra
aplicación web podremos interceptar  +— /html
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
A veces resulta muy útil poder procesar las peti-
ciones HTTP atendidas por un servidor de aplica-
ciones 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 des-
arrollado 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 genera-
do 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ícu-
los 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
LISTADO 1 directorios con Caucho
/digital.revistasprofesionales
|
| |
| +- /WEB-INF
| |
| +- web.xml
|
+— /WEB-INF
|
+- classes
Configuración
El listado 1 muestra la típica estructura de direc-
torios y subdirectorios que presenta una aplica-
ció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 defi-
nen los Servlets y los filtros, se indican cuáles son
los classpath, se establecen variables de inicializa-
ció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 “WEB-
INF”. 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 fiche-
ros .CLASS correspondientes a las clases de la apli-
cació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: “<filter>” y “<filter-
mapping>”. La etiqueta “<filter>” permite esta-
blecer el nombre del filtro (el atributo “filter-
name”) y la clase que lo implementa (el atribu-
to “filter-class”). La segunda etiqueta, “<filter-
mapping>”, proporciona una forma de definir
reglas que se aplican a las URL correspondien-
tes a las peticiones y que determinan cuáles de
estas peticiones son filtradas o no. Así el atribu-
to “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 fil-
tro o no en ese caso.

SOLO PROGRAMADORES nº 122 48 http://digital.revistasprofesionales.com

 REDES
Servlets Filters (I)

LISTADO 2 Definición del filtro spp-filter

<web-app id=”/” app-dir=”C:/Proyectos/digital.revistasprofesionales.com/html”>

<classpath id=”../WEB-INF/classes” source=”../WEB-INF/classes”/>
<welcome-file-list>index.xtp, index.jsp, index.html</welcome-file-list>
<filter filter-name=”spp-filter” filter-class=”com.spp.servletfilters.filter.FSerlvetFiltersFilter”/>
<filter-mapping url-pattern=”/SServletFiltersServlet/*” filter-name=”spp-filter”/>
<servlet-mapping url-pattern=”SServletFiltersServlet” servlet-name=”SServletFiltersServlet”/>
<servlet servlet-name=”SServletFiltersServlet” servlet-class=”com.spp.servletfilters.servlet.SServletFiltersServlet”/>
</web-app>

En el listado 2 se muestra un fichero LISTADO 3 Nuestro primer filtro

“web.xml” que define un filtro cuyo nombre
es “spp-filter” y que está implementado en la HttpServletRequest req = (HttpServletRequest) request;

clase “FSerlvetFiltersFilter”, perteneciente al for (Enumeration e = req.getHeaderNames(); e.hasMoreElements() ;) {

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 eti-
queta “<servlet>” permite establecer el nom-
bre del Servlet (el atributo “servlet-name”) y la
clase que lo implementa (el atributo “servlet-
class”). Por otro lado, la etiqueta “<servlet-
mapping>” especifica qué URL correspon-
dientes 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.
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 private FilterConfig config = null;

cuando el filtro va a emplearse por primera public void init(FilterConfig config)

Esqueleto de un filtro
En los filtros, existen dos métodos principa-
les que deben implementarse, y que se deno-
minan “init” y “doFilter”. El primero se ejecu-
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 imple-
mentación más sencilla del método init:
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 respectivamen-
te con la petición y la respuesta. El tercer
parámetro permite gestionar la concatena-
ció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.

http://digital.revistasprofesionales.com 49 SOLO PROGRAMADORES nº 122

 REDES

LISTADO 4 La clase ServletResponseWrapperImg

De las líneas anteriores se deduce que todas
class ServletResponseWrapperImg
extends HttpServletResponseWrapper
aquellas peticiones que terminen con la
{ cadena de texto “jpg” serán procesadas por
protected HttpServletResponse responseOrig = null; el filtro que se corresponde con la clase
protected ServletOutputStream servletOutputStream = null;
“FSerlvetFiltersImgFilter”, cuyo método prin-
public ServletResponseWrapperImg(HttpServletResponse response) cipal, “doFilter”, es tal y como sigue:
{
super(response); HttpServletResponse res = (HttpServlet
responseOrig = response; Response)response;
}
... ServletResponseWrapperImg servlet
} ResponseWrapperImg = new ServletResponse
WrapperImg(res);
LISTADO 5 Los métodos a implementar next.doFilter(request, servletResponse

public ServletOutputStream getOutputStream() WrapperImg);

throws IOException
{ Como se verá dentro de poco, la clase
if (servletOutputStream==null) {
servletOutputStream = new ServletOutputStreamImg(responseOrig);
}
return servletOutputStream;
} ver” el tratamiento de las peticiones de
public void flushBuffer()
throws IOException
{
servletOutputStream.flush();
} define a un filtro.
public ServletResponse getResponse()
{ cuenta con dos propiedades definidas como
return this;
}
Este filtro no haría nada salvo pasar la peti-
ción al siguiente filtro que se haya configu-
rado 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.ser-
vlet.HttpServletRequest” simplemente modifi-
cando 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 nom-
bre. Asimismo los métodos “getAuthType”,
“getContentLength”, “getContentType”, etc.,
permiten conocer todos los datos de la petición.
Procesamiento de las respuestas
El filtro del listado 3 es muy simple. En rea-
lidad no hace nada especial, ni con la peti-
ción ni con la respuesta. En la práctica los fil-
tros se emplean para procesar anticipada-
mente las peticiones o bien para tratar las
respuestas dadas por los Servlets o las pági-
nas JSP justo después de que se hayan pro-
ducido y antes de que éstas lleguen al nave-
gador del usuario. La gran ventaja de los fil-
tros es que se pueden modificar las funcio-
nalidades de las aplicaciones web por capas,
evitando además que haya que rescribir el
código de la programación original. A conti-
nuación se va a estudiar un caso más com-
plejo en el que se emplea un filtro que pro-
cesa 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”:
<filter filter-name=”img-filter”
filter-class=”com.spp.servletfilters.
filter.FSerlvetFiltersImgFilter”/>
<filter-mapping url-pattern=”*jpg”
filter-name=”img-filter”/>
“ServletResponseWrapperImg” extiende a la
clase “HttpServletResponseWrapper”, que es
una clase del API con la que se puede “envol-
forma que éstas se procesen de una manera
determinada, independientemente de lo que
haga la aplicación web. Esto es justo lo que
La clase “ServletResponseWrapperImg”
“protected” y que almacenan respectiva-
mente el objeto original correspondiente a la
respuesta y un flujo de escritura. Estúdiese el
listado 4.
El constructor llama en primer lugar al cons-
tructor 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 ejecu-
te el método por defecto.
En el caso que nos ocupa se necesita proce-
sar 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 presen-
ta en el listado 6.
Los dos primeros miembros de la clase
guardan el objeto correspondiente a la

SOLO PROGRAMADORES nº 122 50 http://digital.revistasprofesionales.com

 REDES
Servlets Filters (I)

LISTADO 6 La clase ServletOutputStreamImg

para ser tratados después. Esta misma
class ServletOutputStreamImg
extends ServletOutputStream
clase, cuando haya acabado el procesa-
{ miento de dichos datos, será quien final-
protected HttpServletResponse response = null; mente los mande al cliente. Por lo tanto
protected ServletOutputStream servletOutputStream = null;
protected ByteArrayOutputStream baos = null; “ServletOutputStreamImg” implementará
protected boolean bClosed = false; los métodos del listado 7.
public ServletOutputStreamImg(HttpServletResponse response) El mecanismo es sencillo: en vez de escribir
throws IOException en la salida estándar para estos casos se
{
super();
escribe en el buffer interno utilizando la
bClosed = false; clase “ByteArrayOutputStream”.
this.response = response; La ejecución del método “close” marca el
this.servletOutputStream = response.getOutputStream();
baos = new ByteArrayOutputStream(); 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 throw new IOException(“This output
{
stream has already been closed”);
if (bClosed) {
throw new IOException(“Cannot write to a closed output stream”); }
}
baos.write((byte)b); byte[] bytes = baos.toByteArray();
} ...

public void write(byte b[]) }

throws IOException
{
write(b, 0, b.length);
} El método “toByteArray” de la clase
“ByteArrayOutputStream” devuelve un array
public void write(byte b[], int off, int len)
de bytes con los datos escritos hasta el
throws IOException
{ momento. Este array representa la imagen
if (bClosed) { original devuelta. Existen muchas formas de
throw new IOException(“Cannot write to a closed output stream”);
} escalar una imagen pero quizás la más sen-
baos.write(b, off, len); cilla consiste en emplear el método
}
“getScaledInstance” de la clase “Image”. Pero

respuesta y el canal de escritura origina-

les. La propiedad denominada “baos” se
empleará para almacenar en un buffer
intermedio los datos de la imagen devuel-
ta (antes de ser escalada). Finalmente el
miembro “bClosed” contiene un valor
booleano que indica si el flujo de escritu-
ra está cerrado o no. El constructor de la
clase llama en primer lugar al constructor
de la clase padre y después pasa a inicia-
lizar 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 eje-
cución de esos métodos no sea “real”, es
decir, que los datos no se manden al clien-  Respuesta dada por el servidor cuando se solicita una imagen JPG y se ha activado el 
te sino que se almacenen internamente  filtro que la escala.

http://digital.revistasprofesionales.com 51 SOLO PROGRAMADORES nº 122

 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 bas-
tante 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 apli-
cación de filtros para procesar las peticio-
nes 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  <filter filter-name=”ip-filter”
respuestas dadas por el servidor de aplicaciones.
filter-class=”com.spp.servletfilters.
filter.FSerlvetFiltersIPFilter”/>

LISTADO 8 Código del filtro ip-filter <filter-mapping url-pattern=”*”

filter-name=”ip-filter”/>
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain next)
throws IOException, ServletException Obsérvese que esta definición debe situarse
{ la primera de todas y que además el patrón
HttpServletRequest req = (HttpServletRequest)request;
HttpServletResponse res = (HttpServletResponse)response;
que se aplica en la URL es asterisco (*), es
decir, que se filtrarán todas las peticiones.
String sRemoteAddr = req.getRemoteAddr(); El código del filtro es bastante sencillo y
if (sRemoteAddr!=null && sRemoteAddr.equals(“33.33.33.33”)) {
next.doFilter(request, response); puede verse en el listado 8.
} else { El método “getRemoteAddr” del objeto
res.sendRedirect(“http://digital.revistasprofesionales.com”);
}
“HttpServletRequest” devuelve la direc-
} ción IP desde la que se realizó la petición.
Si esta dirección no se corresponde con lo
antes de poder emplear este método es pre- Para este ejemplo simplemente se va a deseado una de las opciones más sencillas
ciso obtener la propia imagen a partir del reducir el tamaño de las imágenes a su consiste en emplear el método
array de bytes: cuarta parte: “sendRedirect” de forma que el navegador
ImageIcon imageIcon = new ImageIcon int iNewWidth = imageIcon.getIconWidth() redirige automáticamente a la portada del
(bytes); / 4; site. Evidentemente este mecanismo se
int iNewHeight = imageIcon.getIcon
puede hacer todo lo complejo que la apli-
La ventaja principal de usar la clase Height() / 4;
cación requiera, de forma que se puede
“ImageIcon” es que, a diferencia de lo que mostrar una página de error, o incluso
ocurre con otras técnicas para leer imáge- Con estos datos escalar la imagen es tan mostrar todo un site alternativo para ese
nes con Java, ésta no devuelve el control simple como ejecutar: caso.
al programa principal hasta que la imagen imageIcon.getImage().getScaledInstance
no se ha cargado en su totalidad, por lo (iNewWidth, iNewHeight, Image.SCALE_ Conclusiones
que inmediatamente después de haber DEFAULT)
llamado al constructor se puede comen- Hemos visto los fundamentos de los filtros
zar el tratamiento de la imagen sin peligro Ahora bien, este método devuelve un objeto Java con algunos ejemplos sencillos. En el
de que se encuentre parcialmente carga- del tipo “Image” y para que la imagen pueda siguiente capítulo profundizaremos en más
da. escribirse es preciso tener un objeto del tipo ejemplos hasta haber visto cuáles son los fil-
En el siguiente paso determinamos los “BufferedImage”. La conversión entre objetos tros que más comúnmente se usan en las
nuevos valores para la imagen escalda. “Image” y “BufferedImage” se ha empaque- aplicaciones web actuales.

SOLO PROGRAMADORES nº 122 52 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ára-
mos pequeñas aplicaciones y, durante toda la sema-
na previa a la entrega, recuerdo las discusiones con
mis compañeros de promoción (cómo no, en la can-
tina) en las que intentábamos ponernos de acuerdo
sobre qué era realmente lo que el profesor había soli-
citado. Cada compañero había construido interna-
mente un conjunto de requisitos. Por supuesto, cada
uno de nosotros creíamos tener la razón e imple-
mentaba su propia versión de la aplicación solicitada.
Nuestra sorpresa era mayúscula cuando descubría-
mos que, el día de entrega, el profesor, con una cruel
sonrisa, nos decía que lo que habíamos implementa-
do 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 acla-
rar 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 objeti-
vos 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… ”.
SOLO PROGRAMADORES nº 122 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 ges-
tió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 sobre-
costes. ¿Exageración? ¿Derrotismo? Seguro que más
de uno no ha podido evitar una leve sonrisa recor-
dando alguna de sus vivencias pasadas o presentes…
En efecto, la gestión efectiva y eficiente de los requi-
sitos de una aplicación es el gran reto de los des-
arrollos 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, supo-
ne 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 proble-
ma Entonces, ¿qué hacer?
La gestión de los requisitos es una técnica de inge-
niería muy antigua. Cualquier empresa de desarro-
llo 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 pan-
tallas 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 facto-
rí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

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, necesita-
mos mucho más que una simple documenta-
ción de requisitos.
Las empresas de desarrollo buscan solucio-
nes 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 cam-
bio 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 clien-
te antes de abordarlo. Soluciones que permi-
tan de forma automatizada eliminar la
ambigüedad, trazar con otras partes del pro-
yecto (planificación, pruebas, análisis,…) los
requisitos, notificar los cambios inmediata-
mente a los miembros del equipo de des-
arrollo,… en definitiva, soluciones que
implementen las más modernas recomenda-
ciones para una correcta gestión de requisi-
tos, como las definidas por el cada vez más
aceptado nivel de medición de la calidad de
los procesos de desarrollo: CMMI.
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 des-
arrollo. 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 indi-
vidual nuestras aplicaciones, ¿cómo no lo íba-
http://digital.revistasprofesionales.com
mos a conseguir ahora que teníamos la opor-
tunidad 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 familiari-
zados. 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 des-
arrollo 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 gran-
des compañías internacionales. La promo-
 El ciclo de vida para la solución JBuilder.
DISEÑO
ción del software entre diferentes entornos
es una necesidad habitual, como lo es poder
gestionar versiones de la aplicación, peticio-
nes de cambio o tareas. De igual forma, el
garantizar la calidad homogénea de una apli-
cació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 pue-
dan 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 desarrolla-
dores. 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 cam-
bio 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 esfuer-
zo 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 planifi-
cación de un proyecto a la herramienta de tra-
55 SOLO PROGRAMADORES nº 122
 DISEÑO
bajo en grupo, de forma que a partir de una pla-
nificació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 pro-
yecto y cohesionamos internamente el equi-
po, automatizando los procesos de desarro-
llo, 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
Las empresas que contratan proyectos softwa-
re son, afortunadamente, cada vez más exigen-
tes 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 inter-
nos 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 objeti-
vos perseguidos son, por un lado, que las apli-
caciones puedan ser mantenidas por el depar-
tamento interno de informática y, por otro, que
las empresas no tengan que depender de un
proveedor concreto y puedan asignar diferen-
tes 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 origi-
nal pueda abordar el mantenimiento y/o evolu-
ción del sistema.
El principal elemento diferenciador de las
compañías de desarrollo es la calidad que
imprimen a sus proyectos. Cuando una com-
pañí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 des-
arrollo 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-
SOLO PROGRAMADORES nº 122 56
 El ciclo de vida para Visual Studio .NET 
turas y guías de estilo y la ejecución de
métricas de calidad del diseño (acoplamien-
to, cohesión, encapsulamiento, herencia,…)
Estas herramientas deben de poder ser perso-
nalizables, para que los equipos de desarrollo
puedan configurar sus propios patrones de
diseño, su propio conjunto de normas sintácti-
cas 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.
La productividad
Precisamente con las herramientas de codifi-
cación está relacionado el segundo factor crí-
tico de desarrollo: la productividad. En la
actualidad, los desarrolladores de aplicacio-
nes que utilizan Ultraedit o vi son afortuna-
damente 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 desplie-
gue,... 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 programa-
dores. Hay muchas alternativas en el merca-
do pero, al mismo tiempo, se busca que el
código generado sea portable (o portátil,
como correctamente se debería denominar a
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 aplica-
ción desarrollada para WebSphere debería de
poderse portar a WebLogic o a Oracle AS con
un simple proceso de recompilación. Un equi-
po 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.
Las pruebas
Por último, otro factor clave en el éxito del pro-
yecto es la correcta planificación y ejecución de
pruebas (funcionales y de rendimiento). Las
pruebas no deben ser una parte aislada del des-
arrollo, sino que lo que se busca es que poda-
mos ejecutar de forma continuada nuestro
conjunto de pruebas y, que éstas puedan rela-
cionarse 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 per-
mitan 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
http://digital.revistasprofesionales.com

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 crea-
ción de objetos temporales) y el funcionamien-
to de los hilos de ejecución (excesiva conten-
ción de threads o deadlocks). Monitorizar de
forma continuada el funcionamiento de la JVM
(Java/J2EE) o el CLR (.NET) permite detectar pro-
blemas de rendimiento antes de que la aplica-
ción esté integrada, minimizando así el impac-
to de resolución del problema.
De igual forma, cuando la aplicación ya está
integrada, incluso en producción, y realiza-
mos 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 respues-  
ta, 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 condi-
cionado 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 apli-
caciones de las cuáles en muchos casos depen-
den vidas humanas y, en cualquier caso, gran-
des 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 conoci-
mientos y herramientas adecuadas.
El ciclo de vida
En esta introducción, hemos abordado los  
principales retos y problemas de los desarro-
llos 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 cali-
dad de los desarrollos, la necesidad de dis-
poner 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 inter-
na 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 codifi-
cación desde hace más de 20 años. Sin
embargo, como respuesta a las necesidades
de los desarrolladores, a vuestras necesida-
http://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 princi-
pales 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 solucio-
nes del ciclo de vida, no solamente entre
las propias herramientas de Borland,
sino con otras alternativas líderes del
mercado.
 Soluciones flexibles, extensibles y perso-
nalizables.
 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 soft-
ware 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 edicio-
nes especiales para entornos de desarrollo
J2EE, C++ y .NET, por fin es posible que per-
files multidisciplinares trabajen paralela-
mente con modelo y código independiente-
mente 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
DISEÑO
que consideran las empresas con equipos
distribuidos de desarrollo, que requieren de
una única solución para gestionar sus ver-
siones, 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 distri-
buida nuestras aplicaciones J2EE y .NET,
complementando las herramientas de prue-
bas 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 herra-
mientas 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 pro-
gramadores”, o leéis una revista que es “sólo
para programadores”? Estoy seguro que vues-
tra 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 solu-
cionarlas, 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 SOLO PROGRAMADORES nº 122
 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
Aunque no es el caso más común, muchas
veces nos encontramos con que nuestras apli-
caciones 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 nece-
sitemos que nuestra aplicación funcione no
sólo en distintas variantes de Unix sino tam-
bién en Windows. En estos casos las diferen-
cias son aún mayores y hacer el “port” desde
un sistema a otro puede tener un coste y com-
plejidad 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
ACE es la librería escribir el código una vez y ejecutarlo en cual-
quier plataforma deseada. También .NET (y el
más usada para proyecto MONO) está ofreciendo esta “porta-
bilidad”, sin embargo el problema de estos
crear código C++ lenguajes interpretados es que imponen a
nuestra aplicación una penalización de veloci-
portable dad que algunas aplicaciones críticas no pue-
SOLO PROGRAMADORES nº 122 58
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 cuidado-
so 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 apren-
deremos cómo diseñar e implementar código
C++ que sea independiente del sistema ope-
rativo. 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 pro-
gramador. 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 agru-
parse 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 memo-
ria. 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í.
http://digital.revistasprofesionales.com

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 dis-
ponibles 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 thre-
ads.
 Sincronización entre threads.
 Gestión de procesos.
Estas incompatibilidades nos obligan a
escribir diferente código para cada siste-
ma operativo y compilar condicionalmen-
te uno u otro. Esto tiene varias desventa-
 jas, siendo la duplicación de código la más
evidente. Pero también implica que debe-
remos 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 pro-
gramador en una plataforma lo estarán en
otras. Hay funciones que no son estándar y
por lo tanto no existen en algunas platafor-
mas 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
http://digital.revistasprofesionales.com
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 con-
veniente 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
 Figura 2. Uso de ACE para abstraer el sistema operativo.
DISEÑO
concebida para ejecutarse en varias pla-
taformas 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 acce-
de de manera directa a las funciones de
la plataforma. Como vemos, esta aplica-
ció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 aplica-
ción deba funcionar con otro sistema,
deberemos plantearnos un diseño que
tenga en cuenta este escenario. En cual-
quier diseño, cuando algún elemento
puede variar, se agrega un nivel de indi-
recció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 ofrez-
ca 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
59 SOLO PROGRAMADORES nº 122
 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 des-
perdigadas 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 imple-
mentar 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 siste-
ma operativo y luego una familia de clases
concretas que implementan esa funcionali-
dad usando ACE. Durante la ejecución de la
aplicación el Abstract Factory creará las ins-
tancias de las clases concretas que utilizan
ACE. En la figura 3 podemos ver los compo-
nentes de esta arquitectura. Este diseño nos  Figura 3. Arquitectura flexible que permitiría sustituir facilmente ACE.
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 Principios de diseño de ACE  Simplificar el código a escribir por el
distinta de ACE sólo con crear una nueva La librería ACE fue pensada y construida programador para los casos más comu-
familia de clases concretas. Esta es la teniendo en cuenta los conceptos más avan- nes de uso de la librería. La forma de
estructura más flexible a la que podemos zados de patrones de diseño de software. lograrlo es creando métodos que agru-
recurrir pero también la más compleja y no Entre los principales principios de diseño pen varias llamadas a funciones que
en todos los casos será necesaria. A la hora empleados podemos destacar: sean generalmente usadas en conjunto
de diseñar software no sólo es importante  Usar Wrapper Façades para forzar la y proveer valores predeterminados que
saber dónde agregar niveles de indirección verificación estricta de tipos de dato por sean los más usados para todos aque-
sino también saber cuándo dejar de hacerlo. el compilador. La idea es no exponer llos parámetros que sea posible.
Para más información sobre este patrón se estructuras internas a la implementa-  Usar jerarquías de clases para crear un
puede recurrir al libro “Patrones de Diseño” ción como ocurre en C. La principal téc- diseño fácil de entender, usar y exten-
de Eric Gamma y otros autores. nica usada es crear clases C++ que der.
hagan que el compilador verifique los  Ocultar diferencias entre plataformas
ACE tipos usados. siempre que sea posible. En el caso en
ACE es una librería gratuita que nos faci-
litará enormemente la portabilidad de
nuestra aplicación. El código fuente de
ACE ha sido compilado en multitud de sis-
temas operativos con lo cual su correcto
uso nos permitirá migrar sin mayores pro-
blemas, actuando como una capa inter-
media entre el sistema operativo y nues-
tro 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 encontrare-
mos 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.
 Figura 4. Página de descarga de ACE.

SOLO PROGRAMADORES nº 122 60 http://digital.revistasprofesionales.com

 DISEÑO
Diseño multiplataforma para aplicaciones C++ (I)

que todas las plataformas soportan LISTADO 1 main.cpp

una funcionalidad dada, se compila el
//main.cpp
código perteneciente a una u otra. Si #include <ace/config.h>
hay alguna plataforma en particular #include <ace/OS.h>
que no tiene alguna funcionalidad #include <string>
específica se intenta emular por códi- int main(int argc, char* argv[])
go propio de ACE siempre que sea {
posible. return 0;
 Permitir compilar con la funcionali- }
dad mínima necesaria. Supongamos
una plataforma que no soporte thre- estáticas de depuración multi-hilo para rio “ACE_ROOT” en la lista de direc-
ads. Si ACE, que implementa threads, la configuración “Debug” y librerías torios de búsqueda de inclusión
se intenta compilar con los threads estáticas mult-hilo para la configura- (include).
activos la compilación fallaría por no ción “Release”. Si por error selecciona-  En “C++” -> “Cabeceras precompila-
estar soportados por la plataforma. mos las librerías dinámicas (DLL) en esta das”, no usar cabeceras precompiladas.
Si alguien desea crear una aplicación opción, obtendremos errores bastante  En “C/C++” -> “Generación de códi-
que no requiere threads se vería extraños a la hora de compilar nuestras go”, cambiar las librería de un sólo
impedido de hacerlo a causa de que aplicaciones que utilicen ACE. hilo de ejecución por las librerías
su plataforma no soporta una fun- Hacer clic en “Aceptar”, activar la configura- multi-hilo.
cionalidad que él ni siquiera necesita. ción “Debug” de la solución y presionar F7  En la opción “Vinculador” ->
Esto es demasiado restrictivo y por para compilar ACE. Si todo va bien, esto “Entrada”, añadir la ruta completa del
eso ACE permite activar y desactivar dejará como resultado el fichero “ACE.lib” en fichero “ACE.lib” como dependencia
opciones de compilación de manera el directorio “ACE_ROOT\lib”. adicional.
que se pueda compilar en una plata- Es posible que al compilar la solución  En “C/C++” -> “Pre procesador”, aña-
forma que soporte las capacidades completa los resultados sean tener un dir la definición del preprocesador
mínimas requeridas por cada aplica- proyecto (ACE) compilado con éxito y “ACE_AS_STATIC_LIB”.
ción. otros dos (RMCast y TMCast) que generan Es importante que todos los cambios en las
 Optimizar el código para obtener la un mensaje de error. El proyecto de ACE propiedades del proyecto se hagan tanto en
máxima eficiencia posible. para Visual Studio incluye estas dos libre- la configuración de Debug como en la de
rías adicionales que dependen de ACE y Release. Ya tenemos listo el esqueleto que
Compilar ACE con Visual C++ que no usaremos. Sus proyectos están utilizaremos como punto de partida para
Descargar el fichero “ACE-5.4.zip” y extraer su configurados de manera predeterminada todas nuestras aplicaciones por lo cual es
contenido en un directorio de nuestro disco. para que su configuración Debug intente conveniente hacer una copia de resguardo
Dentro de este directorio se creará automáti- compilar con la versión Debug de ACE en antes de seguir. A continuación agregare-
camente uno de nombre “ACE_Wrappers” al una librería llamada “ACEd.lib” pero en mos las siguientes líneas al principio del
cual llamaremos “ACE_ROOT” durante el resto algunas distribuciones de ACE, al compilar archivo “main.cpp”:
de la serie. en modo Debug, la librería generada se #include <ace/Dirent_Selector.h>
Para comenzar, en el directorio “ACE_ llama “ACE.lib” en lugar de “ACEd.lib” y de
ACE_Dirent_Selector dir;
ROOT\ace”, crearemos un fichero llamado ahí el error. No es necesario preocuparse
“config.h” que contenga: por esto pues no afecta para nada a nues- Por último ejecutaremos el programa presio-
#define ACE_AS_STATIC_LIBS tras prácticas. nando F5. Si compila y ejecuta sin errores, ya
tenemos enlazada nuestra aplicación con la
#define ACE_HAS_STANDARD_CPP_LIBRARY 1
Usar ACE desde una aplicación con librería ACE.
#include “ace/config-win32.h”  Visual C++
Para crear una aplicación que use la librería Compilar ACE con g++ en Linux
ACE provee archivos de proyecto para ACE ir al menú “Archivo” -> “Nuevo” -> Debemos descargar el archivo “ACE-
  Visual Studio 6.0 y .NET. En “Proyecto”, seleccionar “Proyectos Visual 5.4.tar.gz”, copiarlo en un directorio y a con-
“ACE_ROOT\ace”, abriremos “ace.sln” para C++”, elegir la opción “Proyecto de Consola tinuación ejecutar los siguientes pasos:
compilar con Visual Studio.NET. ACE puede Win 32” (no confundir con aplicación de $tar -xvzf ACE-5.4.tar.gz
compilarse como una librería dinámica o console .NET), entrar el nombre “main” para
$cd ACE_wrappers/
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 pro- $export ACE_ROOT=$PWD
que no sea necesario distribuir la librería grama que modificaremos un poco: $cd ace/
dinámica junto con los ejecutables.  Reemplazaremos todo el contenido del
En Visual Studio, en el menú “Proyecto” -> archivo donde se encuentra definida la $ln -s config-linux.h config.h
“Propiedades”: función “_tmain” por el contenido del $cd $ACE_ROOT/include/makeinclude
 En la sección “General”, en “Tipo de listado 1.
$ln -s platform_linux.GNU platform_
Configuración” elegir “biblioteca estáti-  En la ficha de propiedades del proyecto
ca (.lib)”. y para todas las configuraciones: macros.GNU

 En la sección “C/C++” -> “Generación  En la entrada “C/C++” -> “General”, $cd $ACE_ROOT/ace
de Código”, seleccionar las librerías añadir la ruta completa del directo- $make debug=0 static_libs_only=1

http://digital.revistasprofesionales.com 61 SOLO PROGRAMADORES nº 122

 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.
Entero de 64 bits sin signo. Puede emularlo aún
ACE_UINT64
en plataformas de 32 bits.
ACE_SIZEOF_CHAR Longitud en bytes de un char.
ACE_SIZEOF_SHORT Longitud en bytes de un short.
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.

ACE_SIZEOF_INT Longitud en bytes de un int. Incompatibilidades del sistema

ACE_SIZEOF_LONG
ACE_SIZEOF_LONG_LONG
ACE_SIZEOF_VOID_P
ACE_SIZEOF_FLOAT
ACE_SIZEOF_DOUBLE
ACE_SIZEOF_LONG_DOUBLE
ACE_BYTE_ORDER
Al final del proceso se habrá creado la libre-
rí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ác-
ticas de esta serie. A continuación agregare-
mos las siguientes líneas a “main.cpp”:
#include <ace/Dirent_Selector.h>
ACE_Dirent_Selector dir;
LISTADO 2 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);
Longitud en bytes de un long.
Longitud en bytes de un long long int.
Longitud en bytes de un puntero.
Longitud en bytes de un float.
Longitud en bytes de un double.
Longitud en bytes de un long double.
Ordenamiento de los bytes en la plataforma:
ACE_BIG_ENDIAN o ACE_LITTLE_ENDIAN.
Para compilar y crear el ejecutable de la
aplicación de prueba haremos lo siguiente:
$g++ -I$ACE_ROOT -c main.cpp
$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á enla-
zado estáticamente con la librería ACE.
Incompatibilidad entre plataformas
El punto de incompatibilidad más impor-
tante 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-
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 crea-
remos un servidor echo (reenvía al clien-
te 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

SOLO PROGRAMADORES nº 122 62 http://digital.revistasprofesionales.com

 DISEÑO
Diseño multiplataforma para aplicaciones C++ (I)

LISTADO 3 Cliente echo usando sockets bloquea la ejecución hasta que llega una
petición de conexión de un cliente. En
#include <ace/config.h>
#include <ace/OS.h>
ese momento la función “accept()”
#include <ace/INET_Addr.h> devuelve el control y se procesa la peti-
#include <ace/SOCK_Stream.h> ción. Al igual que en el cliente, se usa un
#include “ace/SOCK_Connector.h” objeto de clase “ACE_SOCK_Stream” para
#include <iostream>
#include <string> leer y escribir en el socket. Todo el códi-
go de gestión de peticiones se encuentra
int main(int argc, char* argv[]) { dentro de un while para que continúe
if (argc<=1) {
std::cout << “Uso: main mensaje” << std::endl; esperando más peticiones una vez que
return -1; termina con una. En un caso real un ser-
} vidor de sockets crea un nuevo thread
ACE_INET_Addr srvr (7, ACE_LOCALHOST); para gestionar cada petición y el proce-
ACE_SOCK_Connector connector;
ACE_SOCK_Stream peer; samiento de cada una procede de mane-
if (-1 == connector.connect (peer, srvr)){ ra independiente pero para mantener el
std::cout << “Error al conectar al servidor” << std::endl; código simple, este ejemplo usa un sólo
return -1;
} thread.
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; Conclusiones
peer.close ();
return 0; En esta primera entrega hemos hecho una
} presentación de la librería ACE y aprendido
a incluirla en nuestros programas. También
agregado de que además es mucho más podemos ver la implementación completa pudimos apreciar la potencia de sus clases
fácil de programar. El código ACE equi- del código del servidor echo. a la hora de simplificar la creación de soc-
valente a los ejemplos anteriores es el Se crea un objeto de tipo kets. En las próximas entregas veremos la
siguiente: “ACE_SOCK_Acceptor” al cual le indica- manera de realizar tareas como acceder al
ACE_INET_Addr srvr (80, ACE_LOCALHOST); remos el puerto donde debe escuchar y sistema de archivos o crear aplicaciones
llamaremos al método “accept()”, que multi-thread.
ACE_SOCK_Connector connector;

ACE_SOCK_Stream peer;
LISTADO 4 Servidor echo usando sockets
connector.connect(peer, srvr);
#include <ace/config.h>
Este código puede compilarse sin pro- #include <ace/OS.h>
blemas en cualquier plataforma en la #include <ace/INET_Addr.h>
que ACE esté disponible y como vemos #include <ace/SOCK_Stream.h>
#include <ace/SOCK_Acceptor.h>
es mucho más simple. En el listado 3 #include <iostream>
podemos ver todo el código necesario #include <string>
para implementar el cliente echo con
int main(int argc, char* argv[])
ACE. Las conexiones por sockets en ACE {
se efectúan utilizando un patrón ACE_INET_Addr port_to_listen(7);
Connector/Acceptor en el cual el accep- ACE_SOCK_Acceptor acceptor;
if (acceptor.open (port_to_listen, 1) == -1) {
tor espera peticiones y el connector las std::cout <<
inicia. El objeto connector de clase “Error al crear el socket server” << std::endl;
“ACE_SOCK_Connector” encapsula un return -1;
socket cliente y el objeto “peer” de clase }
ACE_SOCK_Stream peer;
“ACE_SOCK_Stream” representa el canal ACE_INET_Addr peer_addr;
de datos que éste abre hacia el otro while (true) {
extremo de la conexión a través del cual if (acceptor.accept (peer, &peer_addr) == -1) {
std::cout << “Error al aceptar una conexión” << std::endl;
es posible tanto leer como escribir. La return -1;
función miembro “send_n()” se bloquea }
hasta que consigue enviar la cantidad de else {
bytes indicada como segundo paráme- char buffer[4096];
ssize_t bytes_received;
tro. A continuación, la función “recv()” while ((bytes_received = peer.recv(buffer, sizeof(buffer))) > 0){
lee los datos disponibles en el buffer. std::cout << std::string(buffer,bytes_received) << std::endl;
También hay funciones que permiten peer.send_n (buffer, bytes_received);
}
bloquear o especificar un tiempo límite peer.close ();
de espera para leer datos. }
Una vez que tenemos listo el cliente creare- }
return (0);
mos el código del servidor. En el listado 4 }

http://digital.revistasprofesionales.com 63 SOLO PROGRAMADORES nº 122

 DUDAS
Preguntas y respuestas
ADOLFO ALADRO GARCÍA
Estoy trabajando con XML/XSLT en el
navegador. Hasta el momento todas las
páginas que he desarrollado están pensa-
das para Internet Explorer pero me gus-
taría que también pudieran verse correc-
tamente 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 com-
patibles 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 dife-
renciación de los objetos que soporta el nave-
gador 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 existen-
cia de objetos y funciones como por ejemplo
“document.all” y “document.getElementById”
para determinar el navegador que se está uti-
lizando.
Cabe señalar que este método no es perfec-
to. 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 ante-
rior es más que suficiente.
SOLO PROGRAMADORES nº 122 64
LISTADO 1 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 “XSLTProcessor”, se emplea para las transforma-
permiten diferenciar entre navegadores se ciones con XSLT. El objeto “XMLSerializer” permite
puede empezar a desarrollar el resto del códi- convertir un documento XML en una cadena de
go. La función “InitXMLEngine” es la responsa- texto. Finalmente, “DOMParser” se emplea para
ble de inicializar los objetos que se emplean hacer justo lo contrario del objeto anterior, es decir,
para trabajar con XML/XSLT (véase el listado 1). para obtener un documento XML a partir de una
Si el navegador es Firefox se crean los objetos cadena de texto.
“XMLHttpRequest”, “XSLTProcessor”, “XMLSeriali- En el caso de que el navegador sea IE los obje-
zer” y “DOMParser”, utilizando directamente los tos se llaman y obtienen de forma diferente
constructores del mismo nombre. El primero sirve aunque básicamente sirven para las mismas
para realizar llamadas HTTP (también puede tareas que se han descrito anteriormente.
emplearse para leer ficheros XML/XSLT locales, La siguiente función se denomina “LoadData”
aunque no sea estrictamente una llamada HTTP), y como su propio nombre indica se usará para
obteniendo así un documento XML. El segundo, 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 PC, introducción a
.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
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, consu-
mo de servicios web desde .NET,
patrones J2EE, diseño de inter-
faces Swing y la primera entre-
ga del coleccionable ASP.NET.
1 CD-ROM incluido.
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 - rpsuscripciones@revistasprofesionales.com
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.
 Domiciliación Bancaria  Contra Reembolso (5€ de gastos de envio por paquete)
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.