Revista Solo Programadores #122

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

Y ADEMÁS…

GRATIS

CD INCLU

IDO 6ª ENTREGA DEL COLECCIONABLE

ACTUALIDADWindows Longhorn:la evolución de .NET

MIDDLEWAREXAML, un cambio radicalen la programación de IGUs

Eclipse Visual Editor

REDESLos CMS Open Sourcey el API de Portlets

Programa un filtro entu aplicación web

DISEÑOBorland y el ciclo de vida:la diferencia entre el éxito y el fracaso

Construye aplicacionesmultiplataforma con C++ y ACE

CANAL PANDANuevos peligros parala seguridad corporativa

Noticias, javaHispano, Preguntas y Respuestas 8 413042 303299

0 0 1 2 2

Número 122 - Marzo 2005

Edita: REVISTAS PROFESIONALES [email protected]

C/ Valentin Beato 42, 3ª. 28037 - Madrid.

http://www.revistasprofesionales.comhttp://digital.revistasprofesionales.com

EditorAgustín Buelta

••••••••••••••••••••••••••••••••••Coordinación Técnica-Redacción

Carlos Laparra••••••••••••••••••••••••••••••••••

MaquetaciónRaúl Clavijo

••••••••••••••••••••••••••••••••••Asesoría de Publicidad

Felipe RibagordaTel.: 91 304 87 64

BarcelonaC/ Rocafort, 241/243, 5º 1ª

Mariano SánchezTel.: 93 322 12 38

••••••••••••••••••••••••••••••••••Suscripciones

Tel: 91 304 87 64Fax: 91 327 13 03

•••••••••••••••••••••••••••••••••••Impresión

Ideas de Impresión•••••••••••••••••••••••••••••••••••

DistribuciónMotorpress Ibérica

Distribución MexicoDIMSA - Angel Bosch

[email protected]ón, números atrasados y suscripciones

Renacimiento, 180. Col. San Juan TlihuacaAzcapotzalco. 02400 México D.F.

Distribución ArgentinaCapital Federal: DistrimachisaInterior: York Agency, S. A.Tel. (005411) 43 31 50 51

••••••••••••••••••••••••••••••••••La revista Sólo Programadores no tiene por qué

estar de acuerdo con las opiniones escritas por suscolaboradores en los artículos firmados.

El editor prohibe expresamente la reproduccióntotal o parcial de los contenidos de la revista

sin su autorización escrita.

Depósito legal: M-26827-1994PRINTED IN SPAIN

COPYRIGHT 30-02-2005P.V.P. 6,00 Euros

Precio en Canarias, Ceuta y Melilla: 6,15 Euros

EEDDIITTOORRIIAALLPocas cosas reflejan tan bien el progreso de la tecnología como los teléfonos móviles. En muy

pocos años, han pasado de ser simples teléfonos a auténticas plataformas de ocio.Curiosamente, continuamos llamando “teléfono móvil” a un dispositivo que, ciertamente, algúndía lo fue, pero no cabe duda de que hoy ese término ha quedado obsoleto. Los fabricantes deestos “teléfonos” inundan el mercado con nuevos modelos, las operadoras de telecomunicacio-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 que se ha incorporado a los dispositivos móvi-les es la que puede transformar nuestro terminal en una auténtica consola de videojuegos.

Ciertamente, este tipo de productos van destinados a los consumidores más jóvenes. Segúnse desprende de los estudios realizados por las compañías del sector, 3 de cada 5 ciudadanoseuropeos de entre 15 y 35 años adquirieron algún contenido o servicio para ser consumidodesde su teléfono móvil en el año 2004. De este consumo, los juegos Java para móviles repre-sentan el 11%, frente al 29% que representan otro tipo de contenidos, como por ejemplo lasimágenes. De hecho, estos datos han sido respaldados por un estudio hecho por la consultoraScreen Digest, en el que se afirma que el 80% de los ingresos derivados de los juegos y sus des-cargas provienen de Japón y Corea. En este sentido, queda claro que América y Europa repre-sentan un mercado relativamente virgen, y por lo tanto con muchas posibilidades en el nacien-te sector de los juegos en teléfonos móviles. Por este motivo hemos creído oportuno mostrar allector, con un curso completísimo, cómo desarrollar juegos de calidad comercial para una delas plataformas con más cuota de mercado: Nokia.

SUMARIO

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

DISPOSITIVOS MÓVILES16 Juegos de calidad comercial en J2ME (I)

MIDDLEWARE24 XAML (II)36 Desarrollo visual de IGUs Java

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

DISEÑO54 La diferencia entre el éxito y el fracaso58 Diseño multiplataforma para aplicaciones C++ (I)

Y además…

04 Noticias06 javaHispano: NetBeans 4.0, db4objects, APIs Java y más08 Canal Panda: Los sistemas móviles, un peligro para la seguridad corporativa32 Contenido del CD-ROM 64 Preguntas y respuestas

Un mercado prometedor

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

NOTICIAS

MICROSOFT

Microsoft entra en la lucha contra el software espía

Microsoft ha anunciado recientemente laadquisición de GIANT Company Software, elproveedor de algunos de los mejores productos

diseñados para impedir la instalación de spyware en los equipos, y laempresa que ha desarrollado diversas e innovadoras soluciones paragarantizar 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 propiciadola proliferación del spyware. Se denomina spyware (o programa espía)a las aplicaciones diseñadas para conseguir datos de los usuarios sinque éstos se percaten ni de su presencia, ni de las acciones que llevana cabo. Suelen llegar a los ordenadores a través de programas freewa-re, shareware, o demos de cualquier tipo que aparentemente no tienenninguna peligrosidad. Que una descarga contenga o no spyware nodepende tanto de si el archivo a descargar es fiable o no, sino de dóndese descarga. De hecho, puede darse el caso de que aplicaciones cono-cidas y libres de toda sospecha hayan sido manipuladas para contener

un programa espía. Esta manera de ocul-tarse en el interior de programas no sos-pechosos posibilita que se instalen en elPC, al mismo tiempo que el usuario insta-la la aplicación que acaba de descargar. Unspyware oculto en un sistema puede per-mitir elaborar el perfil de un usuario mos-trando, por ejemplo, sus preferencias encuanto a tipo de páginas web que visita,tiempo que navega, su equipo de fútbolfavorito, etc. Estos y otros datos permitenidentificar 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 losusuarios 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 laversión beta de una herramienta basada en el AntiSpyware de GIANT paraeliminar, 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 parabloquear la instalación en el sistema de spyware conocido o cualquier otrosoftware malicioso. Esta herramienta estará disponible para el sistemaoperativo Microsoft Windows 2000 y versiones posteriores.

BEA SYSTEMS

BEA habilita la descarga de WebLogic 9.0

BEA Systems desveló hace unassemanas la última versión de BEAWebLogic Server 9.0. Su nombre…“Diablo”.Mejorada con importantes caracte-rísticas, Diablo es la piedra angularde 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 yhacer 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-

cidad para ayudar a las compañías a desplegar rápidamente un altovolumen 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 deforma rápida aplicaciones interoperables y portátiles. Diablo está disponible para su descarga en la direcciónhttp://www.bea.com/diablo.

SUN MICROSYSTEMS

Bankinter innova con J2ME

Java continúa ensu proceso deconso l i dac ióncomo la platafor-ma número unopara serviciosinalá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 firmascomo LG, Motorola, Nokia, Samsung, Sharp, Siemens o SonyEricsson. Sun calcula que el 60 por ciento de todos los teléfonosmóviles que se comercializan a escala global ya llevan la tecnologíaJava integrada.Asimismo, más de 90 operadores de comunicaciones móviles (entrelos que figuran Telefónica Móviles y Vodafone) han conseguido incre-mentar su ARPU (ingresos medios por usuario) gracias a la implanta-

ción de la tecnología Java. Actualmente, existe una gran cantidad deaplicaciones 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 elinnovador servicio ofrecido recientemente por Bankinter denominadoBroker 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 canalpara realizar operaciones bursátiles en tiempo real. En una primera fase,el servicio cubre el área de servicios de broker, que incluye la consulta demercados 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 losservicios de consultoría, la dirección del proyecto y el desarrollo detodas las aplicaciones J2ME, aspecto, este último, que se ha realizadosiguiendo los estándares de la tecnología Java y bajo un exhaustivocontrol de calidad por parte de Bankinter.

http://digital.revistasprofesionales.comSOLO PROGRAMADORES nº 122 4

NOTICIAS

IBM

IBM cede 500 patentes a la comunidad Open Source

Los desarrolladores de software librepodrán acceder libremente a tecnologíaIBM gracias a la cesión de 500 patentespor parte de la Compañía. IBM cree quese trata de la mayor cesión de patentesde la historia y representa un giro en elmodo en el que la empresa gestiona supropiedad 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ódigoabierto de acuerdo con la definición actual o futura de la iniciativaOpen Source.

El objetivo de IBM es queesta cesión se convierta enla base de un conjunto depatentes comunes de todoel sector de las tecnologíasde 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 paracolaborar y compartir el conocimiento. La nueva política de propiedadintelectual de IBM está dirigida tanto a proteger los derechos sobre lainvención como a acelerar la expansión de una infraestructura globalbasada en software de código abierto.Pese a este tipo de iniciativas, IBM sigue siendo, y con diferencia, lacompañía con más patentes registradas en la Oficina de Patentes yMarcas de Estados Unidos. Gracias a una inversión en I+D de 5.000dólares, IBM consiguió en 2004 3.248 patentes.

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 horade resolver un problema de alto nivel decomputación, surgió el concepto deComputación Distribuida o GridComputing, que consiste en dividir elproblema en varios fragmentos y hacer

así la computación en varios ordenadores organizados y conectados auna 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 unasolución corporativa Grid Computing integrada y completa que

supere las SMP (varias máquinas multiprocesador funcionando conmemoria compartida) tradicionales y a menor coste.La fase inicial del proyecto MegaGrid se centra en el diseño, prueba ydocumentació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. Cadapatrocinador del proyecto MegaGrid invierte en recursos técnicos paradesarrollar, probar y validar las mejores prácticas de Grid Computing:� 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 otrosrecursos que facilitan la integración del diseño.

� Oracle proporciona su infraestructura de tecnología Oracle 10gy alberga el centro de desarrollo para el proyecto MegaGrid ensu Global IT Data Center.

La meta del proyecto MegaGrid es permitir a grandes organizaciones decualquier 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.

SUN MICROSYSTEMS

Sun y la Universidad Rey Juan Carlos entablan una alianza tecnológica

El Rector de la Universidad Rey JuanCarlos, Pedro González TrevijanoSánchez y el director general de SunMicrosystems Ibérica, Adolfo Hernández,han firmado un acuerdo tecnológico decolaboración que permite que laUniversidad use gratuitamente los pro-ductos software de Sun para finesdocentes y entornos de investigación.El software cedido por Sun Microsystemsa la Universidad Rey Juan Carlos incluyeservidores web y de directorio, servidoresde aplicaciones e integración, aplicacionesde correo electrónico, calendario y cola-boración, desarrollo de aplicaciones,seguridad en red, aplicaciones para siste-

mas de sobremesa, sistemas operativos, software de gestión, entornosde almacenamiento para misión crítica y aplicaciones para informáticaen red. Sun también cederá una licencia con fines didácticos de su software deescritorio Java Desktop System, que podrá ser utilizado tanto por parte

de los estudiantes como por parte delpersonal docente y de administraciónde la entidad educativa. Esta soluciónincluye el entorno de escritorio com-pleto, la suite de productividad ofimá-tica StarOffice 7, un innovador entor-no de ventanas, el popular navegadorMozilla y un sistema operativo Linuxintegrado, además de aplicaciones decorreo electrónico, agenda y mensa-jería instantánea.Además, como socio tecnológico dela universidad, Sun colaborará con lainstitución en otros aspectos rela-cionados con la mejora de la calidaden los estudios de dicha universidad.

http://digital.revistasprofesionales.com SOLO PROGRAMADORES nº 1225

El Rector de la Universidad Rey Juan Carlos, PedroGonzález Trevijano Sánchez y el director general deSun Microsystems Ibérica, Adolfo Hernández en unmomento de la firma del acuerdo.

SOLO PROGRAMADORES nº 122 6

JAVAHISPANO

http://digital.revistasprofesionales.com

Actualidad Java de la mano de javaHispanoActualidad Java de la mano de javaHispano

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 lassubastas a abandonar esta solución. El sistema Passport era una forma opcional no mayoritaria deacceder 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 sedespidió 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.

eBay abandona Passport

La Free Software Foundation ha aclarado (http://www.gnu.org/licenses/lgpl-java.html) varias dudas acerca del uso de librerías LGPL desdeJava. 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 susclases o interfaces) el desarrollo debe permitir que los usuarios hagan reingeniería inversa para depurar problemas derivados del cambio dela versión actual de la librería por versiones futuras o 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 actualmentehaya proyectos comerciales que violen la licencia LGPL sin saberlo.

La FSF aclara los términos de la licencia LGPL

Siguiendo el itinerario previsto ya está disponible la versión4.0 del IDE NetBeans. Una de las novedades más impor-tantes es que el modelo del proyecto está completamentebasado en Apache Ant, pudiendo compilar el proyectoexternamente sin necesidad de emplear previamente nin-guna opción del tipo “exportar a Ant”. El soporte a la refac-torización, al JDK 1.5 y al desarrollo de aplicaciones J2MEMIDP 2.0 y CLDC 1.1 son otras novedades interesantes.También hay mejoras en el desarrollo de aplicacionesweb, aunque será la versión 4.1 (planeada para abril deeste año) la que aportará un mayor cambio cualitativo eneste área, ya que incorporará soporte para EJBs, validación de formularios, configuración de servicios ycomponentes 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 GarbageCollector, el consumo de CPU de la aplicación en conjunto o de un determinado fragmento de código ymonitorizar la actividad de los Threads.

NetBeans 4.0

SOLO PROGRAMADORES nº 1227

JAVAHISPANOjavaHispano


db4o (http://www.db4o.com/) es una base de datos orien-tada a dispositivos empotrados con requerimientos detiempo real. db4o permite almacenar de un modo sencilloy eficiente objetos nativos Java y .NET; sus creadores ase-guran que es la primera base de datos del mercado quepermite almacenar objetos de ambas plataformas. Recientemente db4o ha pasado a distribuirse bajo unadoble licencia, libre y comercial, prueba de la apuesta de lacompañía por el Software Libre. A modo de curiosidad, loscoches de alta gama de BMW o el tren español AVE emple-an esta base de datos, lo cual es una excelente prueba dela validez de esta solución.

db4objects disponible bajo licencia libre

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 recopilanmá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 ahoralas APIs de todos los proyectos de Apache, el cliente de Bittorrent Azureus, y la del JDK 1.4.2. Elvalor 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.

Repositorios on-line de APIs Java

JLayer es una librería libre 100% Java que permite tanto convertir audio a MP3 como reproducir archivos que seencuentren 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 esmuy eficiente. Por otro lado está JLayerME-CDC que, como podemos deducir de su nombre, está orientado al desarrollo de aplicacionesJ2ME. Por ahora no hay una versión estable de JLayerME-CDC, aunque la versión actual ya es usable. La licencia es, enambos casos, LGPL.

JLayer, accediendo a MP3 desde Java

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

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

JCrawler 1.0

Sobre el autorAbraham Otero ([email protected]) es responsable de calidad y miembro de la junta de javaHispano.


En los últimos años, el nivel de seguridad de lasempresas ha mejorado mucho. Cada vez se vigi-la más la conexión a Internet, la existencia deherramientas 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 conflictocon las políticas deseguridad clásicas:la movilidad.Hoy en día se consi-dera cada vez más lanecesidad de quemuchos de losempleados en lasempresas dispongande equipos informá-ticos móviles, desdeordenadores portá-tiles a teléfonos deúltima generación.Todos estos equiposestá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 tiempofuera de la oficina lo que más suele preocuparlees cómo recibir su correo electrónico en el orde-nador conectado a Internet en la habitación del

hotel. Acostumbrado al entorno de la oficina, losniveles de seguridad quedan, generalmente, ensegundo plano. Las consecuencias de su despre-ocupación pueden ser graves, ya que la ausenciade 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 lacausa de que el ordenador se convierta en unzombi.Los problemas que pueden plantearse sonmuchos, ya que en este tipo de ordenadores lainformación almacenada suele ser estratégica:proyectos, ofertas comerciales, bases de datosde clientes, etc. Se trata de material de granvalor, que no debe caer en manos de la com-petencia ni en las de un hacker con pocosescrúpulos.A todo esto hay que añadir un elemento másque sin duda debería preocupar a los adminis-tradores de las redes corporativas: tarde otemprano ese ordenador volverá a conectarse ala red corporativa, con todo aquello que haya“recogido” de Internet en el tiempo que estuvoausente. Las herramientas de hacking, los tro-yanos, el spyware... todo ello podrá ser volcadodirectamente a la red si no se toman las medi-das oportunas. Sin duda existirán herramientasque eviten la propagación de este tipo de códi-gos en la empresa, pero hemos dejado unapuerta abierta a una serie de elementos sincontrol.Otro problema que suele pasar desapercibido es laconexión de sistemas ajenos a la empresa. Cadavez más servicios se subcontratan dentro de lasgrandes corporaciones, haciendo que mucho per-sonal externo se conecte a la red con sus ordena-dores portátiles para desempeñar sus tareas comosi de un empleado más se tratara.Estos ordenadores suelen tener instalados yaalgunos sistemas de seguridad, desde antivirus afirewalls, pero... ¿son suficientemente seguroscomo para que cumplan las políticas de seguri-dad? Los administradores de red tienen bastan-tes problemas ya en su trabajo diario como parair verificando uno a uno los ordenadores de cadauno de los subcontratados, situación que ade-más puede resultar embarazosa ya que las nor-

8

CANAL PANDA

Los sistemas móviles, un peligropara la seguridad corporativaLos sistemas móviles, un peligropara la seguridad corporativaFERNANDO DE LA CUADRA


Las ventajas que ofrece el uso deequipos móviles, como ordenadoresportátiles o teléfonos de últimageneración son indiscutibles, sinembargo llevan consigo unosproblemas de seguridad que puedenconvertirlos en una amenaza paranuestra red corporativa.


CANAL PANDALos sistemas móviles, un peligro

para la seguridad corporativa


mas sobre la intimidad de los ordenadores de lostrabajadores pueden ser muy distintas en cadacompañía.Todo esto desemboca en la necesidad de uncontrol específico sobre las conexiones de sis-temas móviles a la red corporativa. Previo a laposibilidad de que un usuario rompa las políti-cas de seguridad, debe llevarse un controlexhaustivo y automático de la situación de laseguridad de los ordenadores portátiles de per-sonal externo, o de la empresa pero que hayanestado desplazados.Cuando un sistema se conecta a la red corpo-rativa, hay que asegurarse de que el equipo esseguro, entendiendo como seguro que cumpleel nivel de seguridad indicado por el adminis-trador de la red. De esta forma, se impide laentrada de malware en la empresa a través deestas conexiones. En función del resultado del

chequeo realizado deberá permitirse o dene-garse el acceso, o incluso establecer un nivelde seguridad en el equipo que se adapte a losrequerimientos corporativos de seguridad. Sin embargo, en muchas ocasiones la conexiónde equipos externos está ya prevista, por lo quese redirige hacia determinados segmentos dered o se establecen automáticamente permisosy restricciones, sin que llegue a producirse unconflicto de intereses entre políticas de seguri-dad de distintas empresas.Como vemos, la conexión de equipos externosa la red fija de una empresa no está exenta deproblemas, y debe controlarse con mucho cui-dado. Las herramientas de protección de estosequipos van a convertirse, en un espacio muycorto de tiempo, en un elemento básico a lahora de implementar la política de seguridadempresarial.

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

Mientras que la práctica totalidad de libros sobreseguridad informática existentes en el mercadoabordan el tema desde unlenguaje técnico, orientadoprincipalmente a adminis-tradores de red o programa-dores, Seguridad informáti-ca para empresas y particu-lares está dirigido al profe-sional liberal y la PYME.Por eso, haciendo uso deherramientas que vienensuministradas con el pro-pio sistema operativo oque son en su mayoríagratuitas, con esta obrase puede aprenderdesde cuáles son lasmedidas de seguridada implantar para cum-plir con las exigencias

legales de la LOPD y la LSSICE hasta cómo detec-tar una intrusión en el sistema, pasando portemas como el anonimato y la privacidad, la pro-tección de redes y equipos o las auditorías y losanálisis forenses.Aunque las publicaciones sobre seguridad sonabundantes, el lector encontrará en Seguridadinformática para empresas y particulares unaobra de nivel intermedio pensada desde el pri-mer momento para su aplicación en empresasmedianas y pequeñas que no necesitan com-

plejas arquitecturas deseguridad, pero que nopor ello deben descui-darla. Esta obra, escritaen castellano, se adecuaperfectamente al entornode las PYME españolas,cuya realidad conocen losautores.Desde cómo protegerse delmalware hasta qué hacer conel spam, todos los problemascotidianos relacionados con elvalor de la información sonabordados en este libro cuyoobjetivo es que, con muy pocoesfuerzo, se pueda alcanzar unnivel de seguridad razonable.

Seguridad informática para empresas y particulares

Autores: Gonzalo Álvarez Marañón, Pedro PabloPérez GarcíaEditorial: Mc Graw HillPáginas: 440Precio aproximado: 30 EurosISBN: 84-481-4008-7Con la colaboración de Panda Software

Es recomendablecomprobarlos nivelesde seguridadde un equipoajeno antesde conectarloa nuestra red


Introducción

El lector, probablemente, ya habrá escuchado rumo-res sobre una nueva versión del sistema operativo deMicrosoft. En realidad, sobre toda una revolución enlos sistemas operativos de la compañía de Redmond,que, por primera vez, aborda la construcción de algotan 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 ambiciososque, a mediados del año pasado y, con objeto de

garantizar su salida al mercado en tiempo y forma,provocaban el anuncio por parte Jim Alchin,Vicepresidente del Grupo de Plataformas deMicrosoft, de que una parte del sistema (el subsis-tema llamado WinFS) no vería la luz en verano de2006, 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 opcionalmenteinstalable, que posiblemente estará lista en su ver-sión final a comienzos de 2007. Hablaremos de todo esto, y de cómo se estructuray fundamenta el nuevo sistema (totalmente cons-truido en .NET) y totalmente reescrito, cosa que nosucedía desde Windows 3.0. Y es que, cuandoMicrosoft abordó la construcción de la plataforma.NET, no se trataba exclusivamente de una nuevaforma de construir aplicaciones Windows, sino delabandono del modelo COM/DCOM/COM+ en favorde un nuevo modelo, que debía conllevar, inevita-blemente, cambios profundos en todos los sistemasoperativos (y en el resto de aplicaciones) que seconstruyesen a partir de ese momento. Veamosalgunos de los porqués de tales cambios.

El porqué de un cambio tan radical

La pregunta crucial es: ¿Cuál fue el “leit motiv” queobligó a Microsoft a abandonar un trabajo mante-nido desde finales de los 80 por algo totalmentenuevo? Quizá la respuesta se encuentre en la segu-ridad y (en buena medida) en las nuevas arquitec-turas distribuidas (especialmente SOA: ServicesOriented Architecture). Pero lo que ahora vemos, noes sino la consecuencia de unos cambios quecomenzaron en 1996, cuando Bill Gates decidiódejar la gestión administrativa en manos de SteveBallmer, y retomar sus orígenes, como arquitectode software. En ese momento, comienza también lacreación (que no el diseño, que había empezado ya)de lo que podía ser una nueva plataforma quecompitiese con J2EE, aprendiendo lo bueno de ésta,mejorando rendimiento y productividad, e inte-grando lo que (ya en ese momento) se preveíacomo nuevo estándar universal: XML y los serviciosweb. Como una de las primeras decisiones, se abor-da el “fichaje” de Anders Hejlsberg (véase el cuadro

10

ACTUALIDAD

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

Seguro que el lector más curioso seestará preguntando qué novedadestraerá consigo la nueva versión deWindows. En esta serie de artículosanalizaremos las novedades alrespecto, que no son pocas, desde elpunto de vista del usuario perotambién desde el punto de vista deldesarrollador.

MARINO POSADAS (MVP Visual Developer – Visual C#)


El escritorio de Longhorn.


“Anders Hejlsberg”). Hejlsberg abandonaBorland tras 13 fructíferos años (en los quecrea Turbo Pascal y Delphi, entre otros pro-ductos estrella) con una promesa de libertadabsoluta, la posibilidad de realizar todos losfichajes posteriores que fuese necesario, y lafirme voluntad de crear una plataformanueva que sustituyese a la ya vetusta COM(ActiveX, para los amigos).Pero, además, la nueva plataforma debía deser estándar. Microsoft quería demostrar quebuena parte de las críticas recibidas en elpasado por esta causa, se habían debido arazones comerciales, simplemente, y nunca arazones técnicas o de incapacidad de crearsoftware que cumpliese con determinada nor-mativa. Así, desde el inicio, se implica directa-mente en la creación del estándar XML. Paraello, 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 ySperberg-McQueen de la Universidad deChicago, 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 elmomento, por las marcas (<,>) de texto plano,de forma que todos los ordenadores hablenun mismo lenguaje entre sí, independiente-mente de la plataforma. De hecho, el sistemacomú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 otrofichaje no menos importante, (aunque quizámenos espectacular) que comentamos más ade-lante, continúa el diseño de la plataforma y (altiempo) la creación de un nuevo lenguaje queaprovechará todo lo nuevo que ésta pudieraaportar, dentro de una sintaxis elegante, atracti-va y poderosa. De hecho, durante el contenciosocontra Sun Microsystems salió a colación unfamoso e-mail de Hejlsberg, dirigido a Bill Gates,y otros arquitectos, en el que se comentaba: “yatenemos casi perfilado el cuerpo de lo que va a serel nuevo lenguaje. A falta de un nombre mejor,vamos a llamarlo J++”. Y previamente, añadía:“hemos conseguido un adecuado maridaje entrela simplicidad sintáctica de Java y la potencia de

C++”. El lector puede ver este e-mail enhttp://techupdate.zdnet.com/techupdate/sto-ries/main/0,14179,2133983,00.html. Hasta esepunto, habían sido C/C++ y Java las fuentes deinspiración para la creación de lo que ahoraconocemos como C# (por cierto, lo del ‘#’, esdebido a que simboliza 4 signos ‘+’, como unacontinuación del trabajo de Bjarne Stroustrup enel 67. Además, según nos confesaba en unaentrevista posterior (la entrevista se realizó en elTech-Ed de 2001 en Barcelona, y se encuentrapublicada en la sección de artículos dehttp://www.elavefenix.net), otros lenguajes teóri-cos sirvieron en ocasiones de fundamento, comoes el caso de Haskell u Oberon).

Los delegados y la seguridad

Pero, no nos desviemos de nuestro caminohacia Longhorn. Antes de poder crear algotan ambicioso sobre lo que fundamentarincluso un nuevo sistema operativo, habíaproblemas graves que resolver. Al menos, así lo veía Hejlsberg, quien, en lacitada conversación veía el problema de lasiguiente forma (resumo la parte que es fun-damental aquí para la compresión): “El proble-ma de los errores del sistema operativo ha sidouna de las cuestiones críticas a dilucidar a lahora de la construcción de la nueva platafor-ma. Más del 90% es a causa de los drivers y loúnico que podemos hacer con eso, es garanti-zar un esfuerzo por nuestra parte y las compa-ñías productoras de hardware en ese sentido.Pero, aún así, existe casi un 10% que es debidoa nuestro software. Los análisis que hicimos delas pantallas azules (las llamadas “BlueScreens of Death”) arrojaban unos resultadossorprendentes. Casi la totalidad se debe única-mente a dos problemas: punteros a funciónperdidos y problemas de casting (conversión detipos de datos). Por eso se me ocurrió el con-cepto de delegado, que, no sólo garantiza lapresencia de las funciones receptoras de unallamada, (evitando el problema de los punterosa función), sino que obliga a que cualquier des-tinatario de esa llamada a función tenga lamisma signatura que el delegado (en tiempode compilación), terminando definitivamentecon los problemas de casting”. Esta ejecución administrada supone, portanto, que los errores pueden ser siempre

interceptados. Además, el sistema de tipos escomún a todos los lenguajes (CTS), y los ejecu-tables no dependen más que de sí mismospara la instalación y distribución, haciendo dela plataforma el marco ideal para el nuevo sis-tema. Por si esto fuera poco, en un mundo dearquitecturas distribuidas, el soporte nativo deXML y la facilidad de producción y consumode servicios web, ofrecen un valor añadido queresulta crítico en el nuevo subsistema decomunicaciones que el sistema incluye (denombre clave Indigo). Como ya sabe el lector, .NET apareció hace ya3 años. En el camino, otros personajes conoci-dos del mundo del desarrollo han sentido elatractivo de esta nueva plataforma (y tambiénde los beneficios económicos de la empresaque lo promociona), incorporándose a distin-tas áreas del desarrollo de .NET y Longhorn:Don Box (autor del estándar XML-Schemas),Stan Lippman (co-autor junto a Stroustrup dellenguaje C++), Peter Drayton (especialista enCLR), Yousef Khalidi (arquitecto principal deSolaris 9 y Cluster 3.0, de Sun Microsystems) ymás recientemente, Blake Stone (arquitecto deJBuilder, de Borland), son algunos de los mássignificativos. Estas son (entonces) algunas delas principales causas y también de los princi-pales protagonistas de la historia. Repasemosahora la historia en sí.

Las bases arquitectónicas de Longhorn

Con todo esto por delante, y una nueva ver-sión de la plataforma .NET (ahora se encuen-tra en la versión 2.0), comenzó el diseño delnuevo sistema con unos supuestos muyambiciosos. Para comenzar, se pretende queLonghorn sea instalable en tantos equiposcomo sea posible (aún usando un grupo fun-cional reducido). Para ello, se han firmadoacuerdos de colaboración con los fabricantesde hardware, para intentar extender lo máxi-mo posible la Lista de Compatibilidad deHardware (HCL), y garantizar (al menos, así seha dicho), que incluso un Pentium II con 16MB de Ram pueda ser el equipo de destino.De hecho nuevos elementos de la interfaz deusuario como el denominado “Mi Hardware”,darán un acceso y posibilidad de configura-ción sin precedentes al hardware instaladoen el equipo.

11

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


Anders HejlsbergHejlsberg es Distinguished Engineer en Microsoft y pasó 13 años en Borland como Arquitecto Jefe de Plataformas, en los que dirigió (entreotros 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óndel lenguaje C# (junto a Scott Wiltamuth y Peter Golde).


En el otro lado de la balanza, el objetivo es queel sistema pueda aprovechar al máximo lasaltas prestaciones de los equipos actuales, y queesté preparado para aprovechar todo el hard-ware disponible, ofreciendo al usuario lo que sedenomina una “nueva experiencia de usuario”,cuya riqueza de posibilidades estará condicio-nada por la potencia del procesador y de la tar-jeta gráfica que poseamos. Así, si disponemosde una tarjera de 32MB y AGP4 podremosacceder a lo que ellos denominan AERO. Un sis-tema de dibujo de ventanas basado en DirectXcon una impresionante gama de posibilidades.Si (además) llegamos o sobrepasamos los64MB, tendremos acceso a AERO-GLASS, laexperiencia más rica de usuario implantadahasta la fecha, con ventanas que se sitúan en elespacio y no en el plano (y que pueden girar ymoverse libremente por él), diferentes gradosde transparencias para facilitar la lectura, ymuchas otras características, que ya hemospodido ver en las primeras alphas del producto,si bien en un estado muy embrionario. Todas estas novedades no son más que unaparte de los cuatro nuevos subsistemas queconforman el núcleo central de Longhorn (véasela figura con los subsistemas de Longhorn):� Avalon: subsistema gráfico. Basado en

DirectX. Basados en él están las antescitadas experiencias de usuario: Aero yAero-Glass. El lector puede profundizarsobre Avalon y sus nuevas posibilidadesen la serie de artículos sobre XAML quese inició el mes anterior.

� Indigo: subsistema de comunicaciones,basado en la arquitectura SOA (tambiénllamada arquitectura orientada a servi-cios web).

� WinFS (Windows Future Storage):subsistema de almacenamiento.

� Palladium: subsistema de seguridad.Diseñado de acuerdo a la iniciativaTrustworthy Computing (InformáticaFiable), a la que pertenecen en la actuali-dad, IBM, HP, Oracle, Sun, Microsoft, etc.

� Otros subsistemas asociados como las ayu-das, la distribución instantánea de aplica-ciones (one-touch deployment), y un granpaquete de mejoras e innovaciones.

A todo este conjunto de subsistemas consti-tuyentes de lo que será la nueva API deLonghorn, 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 Avaloncomo Indigo, serán instalables “en retrospecti-va”, esto es, se podrán implantar en sistemasWindows XP y Windows 2003. (de hecho, yaexiste desde diciembre del año pasado unaversión “preview” de WinFX disponible parapruebas de desarrolladores, y que utilizaremospara 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 adescribir, de cara al usuario avanzado, toda esaarquitectura y las implicaciones que va a supo-ner, de forma que dispongamos de una imagenmás o menos plástica de tales cambios. Con los anteriores supuestos, el abordaje delsistema se basa en un cambio completo deparadigma, que los “evangelistas” de Microsofthan definido como “Programa una vez y dis-tribuye como y cuando quieras”. Así, se tratade un modelo totalmente orientado a objetos,donde un objeto Application suministra todala infraestructura de ejecución y cuya “metá-fora de programación”, (por seguir su propiaterminología) es similar a la de ASP.NET. Estoes, la interfaz de usuario de una aplicación (sies que dispone de tal cosa) se escribe en unlenguaje de marcas tipo XML, como el lectorque está siguiendo la serie sobre XAML muy

12

ACTUALIDAD


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

Esquema de los nuevos subsistemas de Longhorn.


bien sabe: en concreto es una versión propiadel estándar XForms, llamada XAML, que sirvepara describir elementos de IU en términos deelementos de marcado y que es compiladaantes de su ejecución. La parte funcional delprograma, se codifica en cualquiera de los len-guajes disponibles para la plataforma .NET(unos 30 en estos momentos, si bien VisualStudio .NET 2005 y la siguiente versión, denombre clave Orcas, sólo incluirán de formapredeterminada C++, C#, Visual Basic .NET yJ#). Se comprende ahora el porqué de la apa-rición del concepto de clases parciales en lapróxima versión de Visual Studio 2005, comoparte fundamental del nuevo modelo. Se tratade 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 deASP.NET (o incluso a la de los ficheros XML ylas hojas de estilo extendidas (XSL), usadaspara su interpretación visual). De hecho lainterpretación gráfica de un fichero XAML esdirectamente una ventana, incluso si no exis-te código fuente asociado con él. De estaforma el aprovechamiento de las capacidadesde DirectX en el dibujo y el pintado en VSYNCcon doble buffer, permitirá a los marcos de lasventanas aparecer en parte sombreadas y enparte translúcidas, haciendo el texto más fácilde leer, y dispondremos, igualmente, de trans-parencias y animaciones que faciliten y poten-cien el uso del sistema. Y todo esto, con visua-lizaciones de una calidad más moderna y másalta que la utilizada hasta ahora (dependiendode la potencia de la tarjeta gráfica). Si sólo dis-ponemos de una tarjeta básica, (menor de32MB de memoria), tendremos un sistemagráfico tipo Windows 2000.Estas novedades en la arquitectura, implican laconstrucción de tipos de aplicaciones total-mente nuevas, yendo desde las tradicionales,compiladas, a aquellas que se descargan porInternet y se ejecutan en el cliente sin dejarhuella (una vez concluida su ejecución), u otrasque se actualizan automáticamente, e inclusoaplicaciones compiladas de tipo navegadorque se descargan y ejecutan progresivamente.

Palladium y la seguridad

¿Y qué hay de la seguridad? Palladium es elnombre clave para un nuevo sistema de segu-ridad basado en gran parte en el propio hard-ware. Microsoft ha llegado a acuerdos con losprincipales fabricantes (Intel y AMD) para que

los nuevos chips lleven integradas caracterís-ticas de seguridad que Longhorn pueda apro-vechar de forma nativa. Son micros que incor-porarán esas funcionalidades sin detrimentode la ejecución o el rendimiento y que daránorigen a toda una nueva generación de soft-ware que aprovechará tales características,aunque los chips y el software básico que loutiliza permitirá que algunas de esas noveda-des sean utilizadas por equipos antiguos.Palladium tiene como algunos de sus objetivosmás destacados, la posibilidad de informaracerca de con quién se está tratando “on-line”,pudiendo limitar (de forma configurable) loque llega de Internet y lo que ejecuta cada PC.La información se verificará antes de que sepueda acceder a ella. Se protegerán los datosmediante encriptación y el sistema podrámantener la integridad de los documentospara que no puedan ser alterados sin el con-sentimiento del usuario.De igual forma, no se podrán ejecutar progra-mas no autorizados, evitando que los virusafecten al funcionamiento. Respecto al spam,será evitado antes de que llegue a la bandejade entrada. El correo no solicitado que sequiera recibir sólo será permitido si sigue unaserie de credenciales que coincidan con nues-tros parámetros de usuario previamente defi-nidos. El sistema aplica un nuevo motor deinteligencia artificial actualmente terminadoy en fase de pruebas en Microsoft Research.En el otro sentido, también se controlará loque sale del PC usando agentes de softwareque garantizarán que los datos sólo alcanzan

al usuario adecuado. Además, usando la tec-nología DRM (Administración de DerechosDigitales) Palladium evitará la distribución demúsica, películas, y otro tipo de propiedadesintelectuales a través de Internet (ignoramos ala fecha, si esta característica se podrá desins-talar…) y las productoras de películas y laindustria de la música podrán usar esta tecno-logía para permitir a sus clientes usar los dere-chos contra el copiado de CDs o películas, porejemplo. Se asegura que Palladium podrá pro-teger el correo electrónico de tal forma que nopodrá ser reenviado o copiado a otra gente sinpermiso. También se podrán crear documen-tos de texto sólo accesibles en fechas determi-nadas u otras circunstancias a establecer.

Avalon y algunas consecuencias adicionales

¿Y qué otras consecuencias (meramente ope-rativas, no de programación) nos vamos aencontrar? Pues, depende del subsistema queanalicemos. Pero en cada uno de ellos unmontón, según parece. Gracias a Avalon, dis-pondremos de las siguientes características:� El menú inicio se podrá convertir en una

barra lateral realizada en XML que ocu-pará la posición lateral de la pantalla.

� Se podrá personalizar al igual que lalista de programas del menú inicio.

� Se mejorarán “Mis Documentos”, “Misimágenes” y “Mi música”, con desplieguesde información mejorados que usarán lasúltimas innovaciones multimedia.

13

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


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


� “Mis Imágenes” incluirá nuevas opcio-nes para crear un álbum de fotos, des-cargar vídeos de una cámara digital, ograbar un DVD. Tanto DVD-R/RW comoDVD+R/RW estarán soportados.

� También se incluirá Windows MovieMaker 2, que será rehecho completa-mente en Longhorn e incluirá variascaracterísticas nuevas. Esta nueva ver-sión estará basada en MicrosoftProducer, un añadido de PowerPoint2003.

� Otra mejora será la del Soporte dePantalla Inteligente. Una versión simpli-ficada de éste ya fue incorporada en elService Pack 1 de Windows XP. Esto,permitirá que dos usuarios puedan ini-ciar sesión en el mismo sistema, unoempleando la primera pantalla y el otrola secundaria. Se esperan asimismomejoras de velocidad en este sistema.

WinFS y las implicaciones

Aunque no es cierto que WinFS no vaya aestar presente en absoluto en la versión inicialde Longhorn, tal y como se ha comentado porahí, sí que lo es que no lo va a estar en toda suextensión, tal y como se pensó en un principio,y que esa funcionalidad será suministrada enforma de beta instalable, hasta que aparezcacompleto en su versión final en 2007. Tal y como se había concebido, WindowsFuture Storage reúne lo mejor de dos entornosde trabajo con datos, los sistemas de ficheros

(buenos en streaming) y las bases de datos(buenas en indexación y búsquedas). WinFSmantiene una base de datos estructurada conlas propiedades de los ficheros almacenadosen el SO, y utiliza NTFS (que ahora es transac-cional) para almacenar los ficheros. WinFSsoporta un indexado eficiente del contenidodel fichero, con lo cual se enriquece cualquiertipo de búsqueda que sería tremendamentedifícil en otro sistema de archivos (pudiendobuscar incluso, otros objetos del sistema, comopor ejemplo, contactos, o correos). En WinFS essencillo 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íaser usado con máquinas que ejecuten versionesanteriores de Windows con tal que su sistema dearchivos sea NTFS, este punto no está del todoclaro al día de la fecha. Lo que sí es cierto, es quelos ficheros almacenados en WinFS pueden seraccedidos usando las nuevas APIs de WinFS obien el actual Win32 API. Como complemento,las actuales aplicaciones Win32, podrán accedera los ficheros almacenados en WinFS con ningu-na o con una muy pequeña modificación. Los ficheros pueden ser almacenados conWinFS o con NTFS, pero WinFS es muchomá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 enWinFS, la información se estructura de formadistinta e independientemente de cómo esté

archivada físicamente. El cómo los usuarios yaplicaciones organizan esta información, tam-bién está separada de cómo se almacena endisco. Los datos pueden ser organizados usan-do una estructura conectada de carpetas, nom-bres de espacios para datos, propiedades, tablaso identificadores invariantes o relacionales.Para beneficiar a los desarrolladores, WinFSsoporta servicios de datos unificados paratodas las aplicaciones de usuario final.Algunos los más notables, son los ServiciosIntegrados de Datos, como la sincronización,notificación, el almacenamiento unificado yun modelo común de seguridad, así como suintegración con otras tecnologías como redespunto a punto (P2P) y servicios de directorio.

Indigo y las comunicaciones

Por último concluimos esta primera revisiónde Longhorn con unas pinceladas sobre elsubsistema de comunicaciones, Indigo.Aunque iremos más en detalle y con algo decódigo fuente en el próximo número, hay quecitar que Indigo pretende unificar todos losservicios del sistema operativo, permitiendo lainteroperatividad con los actuales, y dotandoal usuario de un API de acceso común.Así mismo, suministrará un sistema de men-sajería de alto rendimiento, con independenciade los transportes y canales, y un modelo deservicios orientado al atributo (al tipo de infor-mación que se transporta). Por otra parte, suscontenedores podrán ser diversos, variandodesde aplicaciones ASP.NET u otros servicios,hasta clásicos EXEs, componentes COM+, oincluso, los nuevos “containers” que definirá elmodelo de aplicaciones de Longhorn. En suma, se trata de un nuevo diseño basado enel 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 deellas en fase de depuración y otras bastanteavanzadas que esperamos poder ver este vera-no cuando aparezca la primera beta oficial delproducto. Hasta entonces, haremos una revi-sión de lo que supone Longhorn desde el puntode vista del desarrollador en el próximo núme-ro de Sólo Programadores, basándonos en lasversiones “preview” disponibles, tanto del pro-ducto en sí, como del SDK de WinFX.

14

ACTUALIDAD


Avalon mejora notablemente la interfaz gráfica. En esta figura podemos ver el nuevoaspecto de “Mis imágenes”.


Introducción

En esta serie de cinco artículos vamos a conocerlas limitaciones de la primera versión del perfil deprogramación de terminales móviles con Java, esdecir, MIDP (Mobile Information Device Profile)versión 1.0, J2ME (Java 2 Micro Edition) y aprendera superarlas con APIs (Application ProgrammingInterfaces) propietarias, con especial atención a lade Nokia. Conoceremos, además, los problemas deprogramar para un teléfono real, para lo que exa-minaremos en profundidad las características devarios terminales de Nokia. En los dos últimos artí-culos de la serie configuraremos un IDE gratuitopara trabajar con J2ME y programaremos un“matamarcianos” clásico a pantalla completa consonido digital.Con todo ello habremos aprendido las técnicasque usan los juegos de última generación parasacar el máximo partido a nuestros móviles. Comorequisitos previos se supone que el lector tieneunos conocimientos básicos de J2ME y tiene ins-talado todo lo necesario para poder compilar unMIDlet (nombre que se le da a las aplicacionesdesarrolladas con MIDP).Antes de empezar a desarrollar juegos Java decalidad comercial, es fundamental conocerdónde enmarcaremos dicha tecnología. Estaserie de artículos estará centrada a los termina-les Nokia, y más concretamente a los de la Serie60, plataforma que incluye teléfonos de altas

prestaciones y que se verá más adelante, aunquetambién se hará referencia en ocasiones a laSerie 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 demandantesde juegos Java.

� Espectacularidad, ya que son los terminalesque permiten unos juegos más espectaculares.

� Adaptación al Terminal objetivo, ya que losdesarrolladores profesionales de juegos Javaadaptan sus juegos a sus terminales objetivopara sacar el mayor partido de ellos. De modoque siempre habrá que acabar utilizando unaAPI propietaria de un fabricante, que en estecaso será la de Nokia, pero siguiendo procedi-mientos similares se podría usar la API deSiemens 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 llamaSymbian OS. Y decimos el “Windows”, no sólo por-que sea un sistema operativo gráfico, sino porqueestá tan extendido en los teléfonos móviles, comoWindows 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), instalanSymbian OS en sus terminales, aunque cambian lainterfaz gráfica y parecen sistemas operativos dis-tintos, por debajo todos ejecutan el mismo sistemaoperativo. Por poner un ejemplo, los Sony-Ericssonde gama alta, como el P-800, ejecutan Symbianpero por encima implementan una interfaz deusuario llamada UIQ. En el momento de la publica-ción de esta serie de artículos, Symbian OS va porsu versión 8, que ya tienen teléfonos como elNokia 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) yotra es C++. Debemos tener muy claro que desde elmomento en el que decidimos emplear tecnologíaJava para nuestras aplicaciones nos habremos

16

DISPOSITIVOS MÓVILES

En los números anteriores de SóloProgramadores se presentaron lasbases para el desarrollo de unvideojuego con J2ME. Sin embargo,con esta serie de artículos queremosir más allá. Nuestro objetivo seráaprender el API de Nokia para poderdesarrollar juegos de auténticacalidad comercial específicos paraeste tipo de terminales.

ALBERTO GUTIÉRREZ MARTÍNEZFRANCISCO JOSÉ GARCÍA PEÑALVO (Profesor titular deldepartamento de Informática y Automática de laUniversidad de Salamanca)


Juegos de calidad comercial en J2ME (I)Juegos de calidadcomercial en J2ME (I)

Con el API de Nokiaganaremos un 30%de pantalla que sedesperdicia si sólo

programamoscon MIDP 1.0


atado no sólo a las ventajas sino también a lasdesventajas de usar código interpretado. Éstasson principalmente baja velocidad de ejecu-ción y limitaciones funcionales. Para entenderestas desventajas hay que saber distinguirentre código interpretado y código nativo, queaunque muchos de nuestros lectores ya cono-cerán las diferencias, vamos a hacer en pocaslíneas un pequeño repaso a ello:� El código nativo es el código que obten-

dríamos al compilar un programa enC++. Es el código máquina que puedeser ejecutado por el sistema operativodel teléfono móvil.

� El código interpretado es el código queobtendríamos al compilar un programaen Java. Ese código debe ser traducido acódigo máquina en el momento de suejecución, por la Máquina Virtual Java.Esa traducción es la responsable de labaja velocidad de ejecución mencionadaanteriormente.

Cuando se habla de limitaciones funcionales seestá haciendo referencia a que sólo se dispon-drá de los recursos que la implementación de lamáquina virtual Java nos permita utilizar. Lamáquina virtual Java, por tanto, nos aísla , en lallamada “sandbox” (caja de arena), de las pecu-liaridades del teléfono que se está programan-do. Razón por la cuál nuestro programa Java nopodrá, por ejemplo, usar la conexión por infra-rrojos del teléfono, a no ser que el fabricantenos proporcione una API a tal efecto. Por ponerun ejemplo, la especificación MIDP 1.0 de J2MEno permite el uso de ningún tipo de sonido. Noobstante los fabricantes de terminales concapacidad para reproducir sonidos polifónicoso MIDI, como Nokia o Sony-Ericsson, permitendescargar desde la web las APIs que, entre otras,nos proporcionan funciones para que nuestrosprogramas puedan sacar el máximo partido desus terminales. En el cuadro “ComparaciónJ2ME y Symbian OS” se muestra una compara-tiva entre las dos tecnologías comentadas ante-riormente.

Limitaciones de la plataforma

Cuando hablamos de limitaciones de la pla-taforma, nos referimos no sólo a las limita-ciones que tienen los teléfonos móviles encomparación con los ordenadores de sobre-mesa, sino también a las de J2ME en compa-ración con J2SE (Java 2 Second Edition). Enlos siguientes apartados se enumeran dichaslimitaciones.

17

Juegos de calidad comercial en J2ME (I)DISPOSITIVOS MÓVILES


Comparación J2ME y Symbian OSJ2ME Symbian OS

Tamaño de aplicación permitido Decenas de Kb Varios MB

Estándar abierto Sí Sí

Deployment (Despliegue) Grande Más pequeño

Soporte de variosfabricantes Sí Sí

Instalación OTA Sí

Sí, sin embargo las aplicacionesde Symbian OS son normalmen-te tan grandes que es imposible

la distribución OTA

Ejecución de forma nativa No Sí

Lenguaje de programación Java C++

Comunicación con servidoresremotos Sí Sí

Animación en 2D Sí Sí

Animación en 3D

Normalmente No. Sólo para losmóviles de última generación que

soportan la especificación JSR-184. Una completa API 3D basa-

da en Open GL es Open GL ES

Sí

Mostrar vídeos

Normalmente No. J2ME puedereproducir vídeos en teléfonosque soporten la Java Mobile

Media API como el Nokia 3650 yposteriores o en teléfonos con

MIDP 2.0

Sí, si lo permite el terminal

Audio MIDINormalmente No. Se necesita laAPI propietaria del fabricante o

MIDP 2.0Sí

Audio de alta calidadNormalmente No. Se necesita laAPI propietaria del fabricante o

MIDP 2.0Sí

Acceso a SMS

Normalmente No. Acceso a losSMS desde J2ME es posible usan-do la Nokia SMS API (soportada

en Nokia 3410) o la WirelessMessaging API (soportada por los

Nokia 3650 y posteriores)

Sí (Además MMS si lo soporta elterminal)

Acceso a puerto deInfrarrojos y Bl bluetooth

Normalmente No. Sólo para ter-minales con MIDP 2.0 ya que

soportan la Bluetooth APISiempre que lo tenga el terminal

Acceso a la agenda,calendario… No Sí

Marcar un teléfono No Sí

Complicaciones de desarrollomultiplataforma Menos que Symbian Sí


EnergíaEs el principal problema de cualquier aparatoelectrónico y el causante, de forma directa oindirecta, del resto de limitaciones. Es éste uncampo de continua investigación, ya que cadavez los aparatos electrónicos son más comple-jos y demandan más recursos energéticos parafuncionar. Aunque en la actualidad con lapopularidad de las baterías de Litio los termi-nales móviles han experimentado un impor-tante incremento de autonomía, debemossiempre tener en consideración a la hora deprogramar nuestros juegos las limitacionesenergéticas. Por ejemplo, no deberemos abusarde la vibración pues acabaremos con la bateríadel teléfono en poco tiempo. Además, que eljuego use vibración o sonido, deberían seropciones configurables. Y es que el altavoz delteléfono es otro gran consumidor de energía.

PantallaHay casi tantas variantes como modelos deteléfonos en el mercado. La principal diferen-cia es el número de colores que pueden repre-sentar. Desde monocromo hasta los 65.535colores 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 escalade grises, ya que si los gráficos no estánespecialmente adaptados, lo más probablees que sean tan confusos que no se puedallegar a jugar con un mínimo de calidad.La resolución de la pantalla será otro factorimportantísimo a tener en cuenta. Aunque enJ2ME podemos utilizar controles para cons-truir formularios que se verán correctamenteen cualquier pantalla, cuando hacemos unjuego al final siempre tendremos que usar la

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 modoque se pudiera adaptar el juego a cualquiertamaño de pantalla. Esto sólo será posible encontadas ocasiones, así que tendremos queadaptar nuestro juego a cada resolución. Porlo tanto en este tipo de desarrollos será devital importancia que nuestro código tengauna buena estructura que aísle todo lo posiblela 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 estamoscreando un juego de acción en el que, porejemplo, usemos “scrolls” rápidos, deberemosprobarlo sobre todos los terminales que tene-mos como objetivo, pues habrá teléfonos queaún capaces de ejecutar nuestro programa sinproblemas, la baja calidad de su pantalla a

color mostrará los gráficos en movimiento tanborrosos que serán impracticables.

TecladoUn factor determinante para el éxito de unjuego es su jugabilidad. Y ésta depende direc-tamente de los controles que el dispositivo nosproporcione. En el momento de publicación deesta serie de artículos, el único móvil del mer-cado concebido para jugar es el Nokia N-Gagey su evolución el Nokia N-Gage QD. El resto delos móviles, en el mejor de los casos, no estánpreparados nada más que para movernos enlas 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óviltiene una disposición distinta de las teclas, quepuede llegar a ser tan problemática que hagaimposible el manejo del juego en determinadosmodelos. Especial atención en este aspectomerece el Nokia 3650, cuyo teclado se encuen-tra en disposición circular. Por lo tanto no seríamala idea permitir al usuario configurar loscontroles a su gusto.Por otra parte, en lo referente a las facilidadesde J2ME para gestionar las pulsaciones deteclado, son un tanto escasas pero suficientes.Por ejemplo, para detectar la pulsación conti-nuada de una tecla deberemos hacerlo a laantigua usanza, almacenando dicha tecla enuna 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ñoA la hora de desplegar una aplicación MIDP,toda la lógica y los recursos de la aplicaciónquedan empaquetados en un fichero de

18



Figura 1. Despliegue OTA.

Figura 2. Despliegue por puerto de comunicaciones.


tipo JAR (Java Archive). Por tanto, las limi-taciones de tamaño se refieren al tamañoque ocupa el archivo .jar final del juegolisto 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 superarun tamaño límite, que puede estar entornoa los 150KB, está relacionada con el proce-so de distribución (deployment) de los jue-gos para móviles. El modelo de negocioactual de la venta de aplicaciones paramóviles consiste en que nosotros comodesarrolladores llegamos a un acuerdo conla operadora, de modo que ella se encargade hacer accesible nuestro juego a susclientes y de la facturación. A cambio, laoperadora se queda con un porcentaje porcada descarga del juego. A esta forma dedistribución de las aplicaciones Java se lallama OTA (Over-The-Air provisioning,véase la figura 1).Por tanto, nuestro fichero deberá viajar poruna red GSM (Global System for Mobile) opor una GPRS (General Packet RadioService), redes que tienen una tasa de trans-ferencia muy baja. Hasta que no se popula-rice el uso de redes UMTS (Universal MobileTelecommunications System) nuestra apli-cación deberá viajar por redes de bandaestrecha, pero en cualquier caso el clienteque compre nuestro producto deberá aca-rrear con los gastos de la transmisión delfichero .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 quese descargara dicha cantidad de datos, por lomenos con los precios actuales. Además, lasoperadoras imponen un límite de tamañomáximo para OTA, que deberemos conocerde antemano a la hora de crear nuestrojuego.Por poner un ejemplo práctico, la Serie 40de Nokia impone un límite de 64KB para elfichero .jar, y de 5KB para el fichero JAD(Java Application Descriptor).Las aplicaciones J2ME se pueden instalartambié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 negocioque permita el aprovechamiento de estosmodos de instalación, ya que el usuarionecesitaría tener un ordenador. Aunque el

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-Gageconsiste en distribuir los juegos en SD cards(vease la figura 3), equiparando el negocio alde las videoconsolas. Aunque la mayoría delos juegos en este soporte son nativos deNokia, también los hay hechos en Java.Gracias a este soporte no habría la limitaciónde tamaño comentada anteriormente.

Memoria de ejecuciónAunque nuestro programa no ocupe muchoespacio en disco, puede ser capaz de acabarrápidamente con la memoria de ejecucióndel móvil.Si, por ejemplo, nos dedicamos a instanciarobjetos indiscriminadamente sin liberarlos explí-citamente, es más que probable que veamos elfatídico mensaje de “Memoria Insuficiente”, deforma que nuestro juego muera, pudiendoincluso en ocasiones llegar a matar hasta al pro-pio sistema operativo del teléfono.Los procesadores que suelen ejecutar J2MEson tan poco potentes que no se pueden per-mitir el “lujo” de llevar una gestión minuciosade los objetos en memoria que ya no se van ausar, como hace J2SE. Eso significa que elrecolector de basura sólo sea llamado en con-tadas ocasiones, y debamos nosotros explíci-tamente invocar al método “System.gc()” devez en cuando.Cada fabricante de terminales decide eltamaño de esta memoria de ejecución en

función de las prestaciones del móvil. Sinembargo, 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. Porejemplo, la Serie 60 de Nokia tiene cerca de4MB de memoria de ejecución. Los emulado-res que usamos para probar nuestros juegosen tiempo de desarrollo nos mostrarán siem-pre en pantalla la cantidad de memoriausada en todo momento, dato éste que ten-dremos que vigilar para que nunca estédemasiado cerca del límite que tenga nuestroterminal objetivo.

SonidoMIDP 1.0 no soporta el uso de sonido. Portanto, a no ser que usemos una API especí-fica del fabricante que permita reproducirsonidos polifónicos, nuestro juego serácompletamente mudo. Además, la mayoríade los modelos tienen unos altavoces debaja calidad, lo cual habrá que tener encuenta, pues será inútil usar sonidos digita-les de alta calidad. En este aspecto las cosasestán cambiando y teléfonos como losSony-Ericsson y los Samsung tienen unsonido estéreo de gran calidad. No así losNokia, en los que actualmente no merecerámucho la pena que nos esmeremos dema-siado en el aspecto sonoro.

ProcesadorLos procesadores de los teléfonos móvilesson por lo general muy lentos y nuestros

19



Figura 3. Despliegue mediante memory card.


programas no deberían demandar dema-siados recursos de ellos. Más aún si esta-mos desarrollando en Java, porque a partede los recursos que demande el sistemaoperativo, que no son pocos, se estará eje-cutando la máquina virtual Java, y encimade todo esto, se deberá ejecutar nuestrojuego.Para complicar un poco más las cosas, losfabricantes de móviles no mencionan eltipo de procesador que utilizan sus mode-los, ni mucho menos la frecuencia de éstos.Además, las diferencias de rendimientoentre distintos modelos son muy variables,como ejemplo, en la Serie 60 de Nokia, hayuna diferencia notable de rendimientoentre el Nokia 7650 y el Nokia 3650, siendoéste último más rápido que el anterior. Portanto, como siempre, deberemos probarnuestros juegos en los modelos objetivo,pues un juego que es capaz de “mover” unNokia 3650 por ejemplo, en un Nokia 7650puede ser impracticable.

Ausencia de float y doubleComo se ha comentado en el apartadoanterior, los procesadores de los teléfonosmóviles son muy sencillos, tan sencillos quenormalmente no tienen ni unidad de comaflotante. Es por esta razón que J2ME nodispone de los tipos de datos primitivosfloat y double. Sin ellos se dificulta, en prin-cipio, hacer cálculos trigonométricos, razónpor la que han desaparecido métodos de laclase “Math” como “cos()” y “sin()”. En pró-ximos artículos daremos una solución paraeste problema usando una clase de libredistribución llamada “MathFP”.

Hilos sin método stop()Otro de los múltiples recortes de J2ME es lasupresión de métodos en la clase “Thread”.En próximos artículos hablaremos del traba-jo con hilos, e indicaremos cómo parar unhilo que no tiene método “stop()”.

Red de comunicaciones de banda estrechaComo ya se ha mencionado anteriormenteal hablar del tamaño final del juego, lasredes GSM y GPRS son lentas, caras e ines-tables. Debemos tener en cuenta esto sipretendemos que nuestra aplicación envíeo reciba datos. El usuario de nuestro pro-grama deberá estar siempre bien informadodel uso que se haga de la red, pues el usode este recurso le cuesta dinero. En la

actualidad, las operadoras españolas aca-ban de empezar a comercializar UMTS aun-que todavía existen muy pocos usuarioscon terminales de tercera generación. Portanto, con la red actual, para nuestro juegopuede ser factible, por ejemplo, bajarse lalista de las 10 mejores puntuaciones aloja-da en un servidor, o quizá enviar o recibirun par de imágenes de baja resolución.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 porel precio y el tamaño del terminal, como porejemplo la Serie 40.Conocer las características técnicas de losterminales objetivo es de vital importanciaa la hora de desarrollar aplicaciones paramóviles, ya que aunque la tecnología deprogramación es la misma, las platafor-mas son muy distintas entre sí. Inclusoentre los distintos modelos de una mismaserie se encuentran diferencias importan-tes en cuanto a recursos y disposición delteclado.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á queadaptar la aplicación y hacer las pruebaspertinentes con cada modelo de terminaldonde se desee ejecutar. En el caso concre-to que nos ocupa, lo único que tiene en

común la Serie 60 de Nokia es el tamaño dela pantalla (176x208 píxeles), una profundi-dad de color mínima de 4.096 colores ycapacidad de conexión bluetooth. Otrosaspectos como puede ser la capacidad deproceso, o de sonido, son similares pero enabsoluto idénticos. Cada modelo que apa-rece en el mercado dentro de la Serie 60 essuperior al anterior, y no nos deberemosguiar tanto del número de modelo comodel orden de aparición en el mercado. Porejemplo, el Nokia 3650 es superior al 7650.Como desarrolladores debemos conocer lascaracterísticas de la plataforma de desarrollopara la Serie 60, (Developer Platform forSeries 60). Es importante distinguir entre lasdos 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 delas dos versiones.Para conocer las características técnicas decualquier móvil de Nokia, incluidos los de laSerie 60, se pude visitar el enlacehttp://www.forum.nokia.com/main/1,6566,010_40,00.html.A continuación se muestran algunos mode-los de la Serie 60 de Nokia por orden deaparición.

7650Primer modelo de la Serie 60 (véase la figu-ra 4). Modelo de alta gama y alto coste,

20



Comparación DP 1.x y DP 2.0Developer Platform 1.0 for Series 60 Developer Platform 2.0 for Series 60

MIDP 1.0 MIDP 2.0

CLDC 1.0 CLDC 1.0

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

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

XHTML browsing XHTML Browsing sobre TCP/IP

Mensajería MMS (Mensajes Multimedia) Mensajes MMS con Synchronized MultimediaIntegration Language (SMIL)

Sin posibilidad de programar bluetooth con J2ME APIs for Bluetooth (JSR-82)

Symbian OS v6.1 Symbian OS v7.0

Ejemplo: Nokia 3650 Ejemplo: Nokia 6600


orientado a ejecutivos. Es el único modelode la Serie 60 que dispone de foto sensor(no programable en MIDP). Este modelo nose comercializó en USA. De serie no llevasoftware para grabación de vídeo peroNokia lo proporciona gratuitamente en suweb. No tiene lector de tarjetas MMC(MultiMediaCard). Tiene capacidad de soni-do polifónico pero dispone de un altavoz depoca calidad. Lleva cámara incorporada. Eltamaño máximo de aplicación Java es de4MB y la memoria de ejecución máxima(heap size) es de 1,4MB.

3650Terminal multimedia orientado a gentejoven (véase la figura 5). Viene de serie consoftware para grabación de vídeo y parareproducción (Real ONE player). La disposi-ción del teclado en círculo es de vitalimportancia a tener en cuenta a la hora dedefinir las teclas de control de nuestrojuego. Tiene capacidad de sonido polifónicopero dispone de un altavoz de poca calidad.Incorpora lector de tarjetas MMC. Llevacámara incorporada. El tamaño máximo deaplicación Java es de 4MB y la memoria deejecución máxima (heap size) es de 1,4MB.

N-GageEs el primer móvil orientado al mercado delentretenimiento (véase la figura 6). Puedereproducir MP3 y es competencia directade consolas de videojuegos portátiles comola Gameboy. Los compradores de estemodelo serán los usuarios más dispuestos aadquirir nuestros juegos, por lo que ésta

deberá ser nuestra plataforma objetivo.Numerosas compañías desarrolladoras desoftware de entretenimiento han portadoya los juegos más populares a esta plata-forma. Títulos como Tomb Rider y Sonic theHedgehog ya se encuentran en el mercado,con una calidad en cuanto a gráficos ysonido, muy similar a la de las antiguasconsolas de 16 bits como la Megadrive deSega. Los juegos se distribuyen en tarjetasMMC. Este modelo no incorpora cámara. Eltamaño máximo de aplicación Java es de4MB y la memoria de ejecución máxima(heap size) es de 2,8MB.

6600Es el primer teléfono de la comentada ante-riormente Developer Platform 2.0 for Series60 (véase la figura 7). Lleva la versión 7 delsistema operativo Symbian que a simplevista no se diferencia mucho de la versiónanterior. Su pantalla es de 65.535 colores.La mejora más necesaria que se echaba demenos en modelos anteriores ha sido en loreferente al sonido. Es también destacablela posibilidad de zoom de la cámara incor-porada, sin haber variado la resolución ni lacalidad de la misma respecto a modelosanteriores. Lo más importante de este telé-fono para los programadores Java es que esel 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 llama6620. El tamaño máximo de aplicación Javaes de 4MB y la memoria de ejecución máxi-ma (heap size) es de 3MB.

3660Es prácticamente idéntico al modelo 3650salvo que la disposición del teclado hacambiado de la disposición circular a latípica de cualquier teléfono móvil (véase lafigura 8). Además su pantalla es capaz demostrar 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 yla memoria de ejecución máxima (heapsize) es de 1,4MB.

7610Es el primer teléfono de Nokia en incorpo-rar una cámara de 1 Megapíxel. Ademáses novedoso también su puerto USB Pop-Port que permite una rápida conectividadcon un PC. Por todo lo demás, es similar almodelo 3660. El tamaño máximo de apli-cación Java es de 4MB y la memoria deejecución máxima (heap size) es de 8MB.

MIDlet para conocer las capacidadesgráficas de nuestro móvil

Si las pantallas de la mayoría de los móvi-les son pequeñas, al utilizar un “Canvas” lapantalla de nuestro juego todavía será máspequeña que la pantalla del móvil. Si seobservan los juegos Java comerciales decalidad, como por ejemplo el “Prince ofPersia” de Gameloft, veremos que se ejecu-tan a pantalla completa. ¿Cómo lo hacen?¡No hay ninguna clase en MIDP 1.0 que seacapaz de conseguir esto! La solución laveremos en próximos artículos cuandohablemos de la clase “FullCanvas” de la APIpropietaria 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. Paraello deberemos conocer con exactitud lascaracterísticas de la pantalla de nuestro ter-minal. Esto no es otra cosa que “interrogar” ala clase “Canvas” sobre sus propiedades, aun-que también tendremos que sacar algunas

21



Figura 4. Modelo7650 de Nokia.


Figura 6. Modelo N-Gage de Nokia.




Figura 10. KTootlBar.


propiedades de la clase “Display”. Esto es loque haremos en el programa que se recoge enel listado 1 incluido en el CD-ROM. Este pro-grama tiene como peculiaridad que hemoshecho el “truco” de Java, para poder usar laclase “Canvas” sin tener que instanciar unaclase que herede de ella, ni crear otro .java. Laclase “Canvas” es una clase abstracta y debe-mos implementar su método “paint()” al ins-tanciarla. En esa misma sentencia, ademásestamos asignando el “Display” al “Canvas”que se ha creado. Por lo demás, el código esauto explicativo, y nos estamos limitando asacar propiedades de ambas clases (“Canvas”y “Display”) por pantalla.

Compilación

Los lectores de Sólo Programadores ya hanpracticado con las herramientas necesariaspara el desarrollo con J2ME, sin embargorepetiremos aquí, una vez más, los pasos aseguir para ejecutar un proyecto J2ME en unemulador.Para desarrollar aplicaciones J2ME es necesa-rio tener el J2SE SDK (http://java.sun.com/j2se/

downloads.html) y posteriormente instalar elJ2ME Wireless Toolkit 2.2 de SUN que puedeobtenerse en http://java.sun.com/products/j2mewtoolkit/download-2_2.html.Una vez instalado el software buscaremosla 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 conla etiqueta “API Selection” activa.Deberemos aquí seleccionar como “TargetPlatform” MIDP 1.0, y al aceptar observare-mos que volvemos al entorno de laKToolBar que ahora nos indica con untexto dónde deberemos poner los fuentes ylos recursos del proyecto. Los ficherosfuentes 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 unemulador, tal como muestra la figura 11.

Conclusiones

Analicemos los resultados usando el emu-lador de Nokia de la Serie 60 (en próximosnúmeros veremos su instalación, mientrastanto el lector puede probar el ejemplo conlos emuladores que el Wireless Toolkit traepor defecto), y comparándolo con un telé-fono real, el Nokia 3650. Lo que deberíaverse es lo que aparece en la figura 11.De los datos que obtenemos nos fijamosprimero en la resolución del “Canvas”. Elprograma nos dice que tenemos disponi-ble para nuestro juego un área de 176x144píxeles, cuando según dijimos anterior-

mente la Serie 60 de Nokia tiene un áreade pantalla de 176x208 píxeles. Hemosperdido 64 píxeles en altura de nuestrapantalla, lo que supone más de un 30% dela pantalla.El teléfono admite double buffering. Estosignifica que el propio teléfono maneja unamemoria de vídeo donde hace los cambiosoportunos antes de mostrarlos por pantallaen un evento de repintado. Esto a efectosprácticos significa que podremos recoger elobjeto “Graphics”, que recibiremos del even-to “Paint” del “Canvas”, y pintar sobre él,sabiendo que no vamos a tener el engorrosoefecto de parpadeo de nuestros gráficos, queun juego sin double buffering tendría.Como vemos el objeto “Canvas” nos dirá si elteléfono sobre el que estamos ejecutandotiene una pantalla táctil, lo que abriría ungran 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 quetambién lo está con el teclado. Esta propie-dad nos dice que el terminal es capaz dedetectar cuándo hemos dejado pulsado unbotón, levantándose eventos a tal efectocomo 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áficasde la pantalla. Con la primera sabemos quela pantalla es en color y con la segundasabemos cuántos colores es capaz de mos-trar simultáneamente. Vamos a fijarnos enésta última. Según las características de laSerie 60 de Nokia, el teléfono que más colo-res podía mostrar estaba en torno a los65.000. En el emulador vemos que la panta-lla muestra 16 millones de colores. Si ejecu-tamos la misma aplicación en un Nokia3650, todas las propiedades salen idénticas,salvo ésta última, en la que aparece el valorreal de 4.096 colores. Ésta es una muestramás de que nunca nos deberemos fiar de losemuladores...En el próximo número veremos en profun-didad la API propietaria de Nokia para,entre otras cosas, aprovechar ese 30% depantalla que como acabamos de comprobarse desperdicia si sólo programamos conMIDP 1.0.

22



Figura 11. Aplicación en ejecución sobreel emulador Serie 60 de Nokia.

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


Introducción

En el artículo anterior conocimos las ideas bási-cas de la estructura de XAML y vimos tambiénque 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 posibilidadesy abre el espectro a un nuevo conjunto de aplica-ciones que serán vistas como una mezcla entre lomejor del web y Windows, multimedia, y docu-mentos. Le estoy anticipando que es un buenmomento para que comience a aprender XAML sino quiere quedarse atrás. Esto es lo mismo que sihace 12 años (cuando algunas pantallas todavíasolían ser de fósforo verde) le hubiese dicho quesería buena idea que considerase programar paraWindows. Es que en realidad me he quedado muycorto en el artículo pasado sobre las bondades dela nueva camada de aplicaciones, pero afortuna-damente aquí comenzaré a desvelar varias carac-terísticas que si bien mencioné brevemente ahoraya se está en condiciones de plasmar. Por supues-to que si no leyó la entrega anterior no es malaidea que se haga de alguna forma con ella, ya quetengo la intención al finalizar con esta serie deartículos abordando la mayor parte de las carac-terísticas de XAML y así lograr que esté en carre-ra para los próximos años.

Las 6 verdades absolutas sobre XAML

Los siguientes 6 puntos ya los vimos en la entregaanterior, pero deseo refrescar su memoria sobre todoporque sé que un mes puede llegar a ser mucho tiem-po para tener presente la totalidad de un artículo.

1.-XAML define una interfaz gráfica avanzadapara una ventana o página utilizando comomedio un documento en formato XML.

2.-XAML es un lenguaje declarativo aunque sepuede 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 conuna clase del nuevo conjunto de clases que sele adicionará a .NET Framework 2.0.

4.-XAML cuenta con su propio conjunto de con-troles que no son de Windows Forms, aunqueen casos extremos se pueden también inser-tar estos últimos.

5.-La apariencia de controles se establecemediante etiquetas o atributos, contándosecon propiedades complejas y la posibilidad deinteractuar desde un control hijo con supadre (por ejemplo, un botón que indique laposición dentro de su contenedor).

6.-Todo dentro de XAML (incluso los controles)pueden ser vectoriales, lo que da la ventaja dellegar a ser “resolución independiente”.

A estas seis verdades hay que sumarle que es muysencillo aplicarle una animación a un conjunto decontroles de la interfaz gráfica, por ejemplo paraque varíe a lo largo del tiempo su forma, tamaño,color, etc. Por supuesto que todo esto es en realidadun pequeño conjunto de las ventajas, he iremosviendo 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 contenedoro 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 notenía la resolución de pantalla esperada. Ésto es lomismo 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 supuestodentro de un espacio menor.

24

MIDDLEWARE

XAML (II)XAML (II)

XAML cambiará radicalmente lafilosofía de desarrollo de lasaplicaciones, por lo que a la interfazde usuario se refiere. En estasegunda entrega analizaremosalgunos aspectos centrados en laprogramación de interfaces bajo estanueva tecnología.

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


XAML permitecrear IGUs

visualizables tantoen ventanas como

en navegadores


Vea ahora la figura 1, en ella se muestran 3copias de la misma ventana la que he adecua-do su tamaño manualmente estirando y/ocontrayendo sus bordes. ¿Qué hay de fantás-tico en ello? Si presta atención notará que sucontenido ha sido realmente adecuado deacuerdo al espacio disponible, esto es así por-que todo es vectorial en XAML incluso loscontroles. ¡Ahora sus muebles cambian detamaño de acuerdo al espacio disponible!Por supuesto que ello hace que la soluciónofrecida en .NET Framework 1.1 pase a ser unabroma de mal gusto comparada con la nuevapotencia de auto-ajuste en XAML. Veremosmás adelante lo sencillo que es lograr estacaracterística utilizando un tipo de contene-dor especial llamado “ViewBox”. Pero antesvamos a analizar brevemente el modelo pro-puesto por Microsoft conociendo los nuevostipos de aplicación.

Nuevos tipos de aplicación

Para Microsoft es doble responsabilidad XAMLpor un lado por ser el padre de esta tecnologíay por otro por ser la piedra fundamental de losnuevos tipos de aplicación. Hasta el momentoen 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 webEl último punto puede no ser considerado untipo específico de aplicación, pero he decidi-do incluirlo ya que interactúa con lo mejor delos dos mundos: web y Windows. El nuevomodelo propuesto por Microsoft incluyetambié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 depáginas múltiples” y es conceptualmente simi-lar a una aplicación web. Una aplicación deeste tipo consistirá de una o más páginasXAML y cada una de ellas representará unainterfaz gráfica dentro de la aplicación. Unavez que el usuario finalice con una páginapodrá pasar a la próxima y así sucesivamente.El código de programación (el que responde alos eventos) de cada una de ellas está en gene-ral contenido por un archivo externo, en formasimilar 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 queel usuario puede navegar, pero sin embargo el

objetivo principal radica en mostrar informa-ción como podrían ser documentos o gráficos.Debido a ello están disponibles varias caracte-rísticas para la gestión de la visualizacióncomo puede ser zoom y vistas de una o máspáginas, firmas de documentos, etc. Éste es unimportante capítulo para la nueva infraestruc-tura ya que se ha hecho un esfuerzo muygrande y como veremos en próximas entregasse ha adicionado una nueva y completainfraestructura 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 incluidosson muchísimo más amplios que tan sólo elreducido número de los intrínsecos deWindows.Es importante destacar que la mayor partede los elementos pueden ser utilizados en lostres modelos, lo que brinda una transparen-cia total entre ellos. Digo la mayor parte por-que por supuesto que no es posible emplearlos 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”, estoes sin código asociado a los mismos, entoncesellos serán factibles de ser visualizados sim-plemente haciendo doble clic; se abrirá enton-ces el visor predeterminado y mostrará sucontenido, al igual que se hace hoy en día conuna página HTML. Ahora bien, si se asocia

código a alguna de las páginas entonces sedice que se tiene una aplicación y allí la apro-ximación es diferente. En estos casos se debe-rá compilar el código para poder visualizar suresultado de forma funcional. Para ello se uti-liza una herramienta llamada MSBUILD de laque hablaremos en próximas entregas.Otra cosa muy importante a entender es quelas aplicaciones navegables o de documentos

25

MIDDLEWAREXAML (II)


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

Figura 2. Ejemplo de los tres tipos deaplicaciones WinFX propuestos por elnuevo modelo de Microsoft.


pueden ser visualizadas tanto dentro de unaventana como dentro de un navegador. Elcambio de un tipo a otro debe indicarse entiempo de compilación, esto no implica engeneral más que modificar un parámetro decompilación, lo que hace muy fácil abstraersedel modelo.Como último decir que la creación de con-troles también puede ser realizada mediantecódigo prescindiendo de los documentosXAML. Esto es así ya que como comentéanteriormente cada control es una clase dela infraestructura la cual puede ser gestiona-da de forma estándar como tantas otras.

Trabajando con contenedores

Vamos a empezar viendo cómo trabajar condocumentos “sueltos”, esto es, sin lógica aso-ciada a ellos. Una vez que entendamos el fun-cionamiento comenzaremos a vincular todoesto con los diferentes tipos de aplicación. Amodo de organizar los distintos tipos de con-trol, he separado a los mismos dentro de 2 gru-pos lógicos, aunque esta división es totalmen-te ficticia y solamente tiene el fin de que puedaentender su funcionamiento y relación:

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

El primer grupo ofrece diferentes alternativasde paneles, es decir, aquellos que se encarga-rán de almacenar a los demás elementos.Podemos imaginarnos esto como un conjun-to de distintos tipos de contenedores para losmás diversos usos. La importancia de loscontroles contenedores radica en que luegosus integrantes podrán ganar sus caracterís-ticas. Por ejemplo, existe un control llamado“ViewBox” que se encarga de que si cambiasu tamaño se adecue su contenido. Como ve,éste es el tipo de panel que he utilizado parael ejemplo de la figura 1, el contenido del lis-tado 1 es un resumen de su código.A su vez algunos controles de interaccióncon el usuario tienen que ser obligatoria-mente almacenados por un contenedorespecífico, veremos ésto cuando tratemos altipo “Gris”. Además se pueden anidar varioscontenedores, por ejemplo que “ViewBox”

contenga un panel y que a su vez este panelcontenga otros y así sucesivamente.El primer paso es entonces elegir uno deellos de acuerdo a las características queéste ofrece, lo que lógicamente podrá reper-cutir en la conducta de sus miembros. Unavez hecho ésto pasaremos a hacer uso delsegundo grupo, el que ofrece desde botones,hipervínculos, multimedia, etc. Pero antes decomenzar a escribir XAML quiero detenermepara comentarle las diferentes alternativasque necesitará tener instalado si quiere pro-gramar en XAML:1.-Visor XAML de Xamlon y también con-

versor de Flash a este formato(http://www.xamlon.com).

2.-Visor XAML de Mobiform, que contieneel único editor gráfico en el momento(http://www.mobiform.com).

3.-Visor XAML de Microsoft contenidodentro del paquete SDK de WinFX(http://www.msdn.microsoft.com).

26

MIDDLEWARE


LISTADO 1 El contenedor ViewBox

<Viewbox><Canvas Width=”350” Height=”80” Background=”Gold”><!—Aquí dibuja los controles—></Canvas>

</Viewbox>

Los 7 tipos de contenedor

Control Descripción Espacio de nombresen .NET Framework 2.0

CanvasDefine un área en el cual cada elemento contenido puede ser dibujado en una coordenada deleje vertical y horizontal relativo al mismo. Es lo más parecido al posicionamiento que utilizaVisual Basic u otros lenguajes para situar los controles en sus formularios.

System.Windows.Controls

DockPanelDefine un área en el que los elementos contenidos se pueden organizar uno con respecto alotro, tanto sea en forma vertical u horizontal, y se pueden especificar los tamaños de los con-troles en porcentaje relativo al contenedor.


FlowPanel Alinea y particiona el contenido (controles) en varias líneas para el caso que exceda la longi-tud del espacio horizontal disponible en la línea. System.Windows.Controls

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


Table Muestra datos en forma tabular, como lo hace cualquier tabla. System.Windows.Documents

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


TextPanel

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

System.Windows.Documents

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

System.Windows.Documents

Sólo Programadoresen FormatoDigitalCon el respaldo de más de diez añosde publicación mensual y sin interrupcionesEntra en http://digital.revistasprofesionales.comSuscripció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 ejemplaresde la temporada 2003-04


Es importante destacar que la implementaciónWinFX del SDK de Microsoft es lógicamente laque ofrece el conjunto más amplio de carac-terísticas. Sin embargo al momento de escribireste 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 lomejor de cada uno. En cuanto a los requisitosde sistema operativo son Windows XP, 2000 o2003 (dependiendo del producto).

Tipos de contenedor

Como vimos anteriormente los tipos de panelcondicionarán el comportamiento y las futuraspropiedades de su contenido. Existen 7 posi-bles contenedores y se explican brevemente enel cuadro “Los 7 tipos de contenedor”.No deseo aburrirlo ya que quiero que sigaleyendo mi entrega de XAML, y debido a elloveremos en esta segunda parte del cursosolamente algunos de los contenedores, y enpróximas conoceremos más sobre el resto.

TextPanel... el más sencillo

Con “TextPanel” es sencillo darle formato a lostextos y afortunadamente utiliza nomenclaturaen muchos casos comparable con algunas eti-quetas HTML. Ello hace que sea fácil compren-der su funcionamiento. Básicamente es posibleespecificar 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-

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 sencillosde 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 empleaun “Canvas” principal y luego otros secunda-rios que almacenarán diferentes rectángulosde distintos colores. Por último se dibuja unbotón directamente sobre el control principal,lo que nos servirá nuevamente para ver cómoun elemento secundario interactúa con lajerarquía. En este caso el botón hace referencia

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

DockPanel

“DockPanel” organiza los elementos contenidosen forma horizontal o vertical uno con respec-to al otro. Cada control integrante puede esta-blecer una propiedad llamada “Dock”, la quebrinda cinco opciones: “Top” (arriba), “Bottom”(abajo), “Left” (izquierda), “Right” (Derecha), o“Fill” (rellenar). En tiempo de ejecución“DockPanel” examinará las propiedades de cadaintegrante y determinará su posición con res-pecto al miembro anterior, así como también sideberá o no cubrir todo el panel. A su vez el

28

MIDDLEWARE


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

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ónde 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>


tamaño del control se puede especificar comoporcentaje de “DockPanel”, lo que hará que si secambia el tamaño del panel también se modifi-que el de sus integrantes. El listado 4 utiliza unpanel principal y 2 paneles secundarios; estosúltimos ocuparán cada uno el 50% del área. Elprimero definirá varios botones de tamaño yposición relativa, mientras que el segundo es unbotón que cubrirá la totalidad del espacio. Elresultado puede verse en la figura 5.

FlowPanel

“FlowPanel” es utilizado para gestionar conte-nido que pueda en algún momento ocuparmás de una línea y tenga que ser reorganiza-do dinámicamente. Básicamente este panelcontiene propiedades para indicar el alinea-miento y qué hacer si se sobrepasa la línea. Asu 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 eltamañ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” alcomienzo de este capítulo pero solamente nosbasamos en su funcionamiento. Como habrávisto, este panel ajusta dinámicamente el con-tenido a su nuevo tamaño, pero a diferenciacon otras aproximaciones, el mismo es real-mente escalado en vez de limitarse solamente adisminuir los espacios o tamaño de los contro-les. Como podemos apreciar en el listado 6 se

cuenta con propiedades de alto y ancho máxi-mo, lo que lógicamente indicará que en caso desobrepasarse la altura o ancho el contenido sefije utilizando esta información (véase de nuevola figura 1).Debe tener en cuenta que “ViewBox” puedecontener un sólo control secundario, por loque en caso de que desee insertar más de

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

Recursos y estilos

En XAML es muy sencillo personalizar la apa-riencia de los controles y de la aplicación

29

MIDDLEWAREXAML (II)


Figura 5. El código del listado 4 en ejecución.Figura 4. El código del listado 3 enejecución.

LISTADO 3 Combinación de Canvas

<Canvasxmlns=”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

<DockPanelxmlns=”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>


mediante la utilización de estilos. Cuando digopersonalizar la apariencia veremos que esmucho más flexible que tan sólo modificar loscolores. Sin embargo, antes de explicar qué esun estilo debemos comprender qué son losrecursos. Preste atención al listado 7.Este código define un nuevo recurso llamado“Micolor” que es un relleno de color Rojo ysólido. Este elemento pasa a ser parte de lacolección de recursos del panel. Cada ele-mento en XAML puede contar una colecciónde estos. De esta forma es posible definir unoo más miembros en el control que usteddesee, pero en general se establece en el ele-mento principal con el fin de que pueda serutilizado por los controles de la jerarquía.Una vez que el recurso es creado pasará aestar disponible para los otros objetos, estoes, como suministro de valor para una o máspropiedades. Siempre se debe hacer referen-cia al recurso utilizando llaves, y recordandoque se diferencia entre mayúsculas y minús-culas. La siguiente línea establecerá comofondo del botón el relleno definido en elrecurso del panel:<Button Background=”{MiColor}”/>

En tiempo de ejecución el valor “Micolor”será buscado en la colección de recursos delbotón, pero al no haber nadie con este nom-bre se subirá en la jerarquía hasta que seencuentre 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 delmismo a otro objeto del mismo tipo; a estose lo denomina “Estilo” (véase el listado 8 yla figura 7).

En este caso se ha definido un botón de plan-tilla que contiene el posible estilo a utilizar.Aquí se incluye el color de fondo, de fuente yla altura, pero nada con respecto al resto delas propiedades. En tiempo de ejecución sedibujará el botón utilizando el estilo y poste-riormente se aplicarán los valores establecidosen el propio control. Para el caso de haber unconflicto siempre se descartará el valor delestilo quedando el del elemento en sí.

Conclusiones

Hasta aquí hemos llegado, sé que nos faltamucho por ver y como siempre hay pocoespacio. En la próxima entrega seguiremosavanzando en el tema de estilos ya que lebrinda mucha flexibilidad (aquí simplementehe hecho una breve reseña). Además conoce-remos más sobre controles y documentos.Hasta el mes que viene.

30

MIDDLEWARE


Figura 6. El código del listado 5 enejecución.

Figura 7. Como se aprecia en la figura,la personalización de los controlesmediante estilos va más allá de un simplecambio de colores.

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

<Borderxmlns=”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

<Borderxmlns=”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>


Fuentes

Juegos de calidad comercial en J2ME (I)Antes de iniciar el diseño y desarrollo deuna aplicación sobre un terminal móvil, esnecesario conocer las capacidades y limi-taciones del mismo. En esta primeraentrega, hemos preparado una pequeñaaplicación que “interroga” al teléfonomóvil (o emulador) y muestra por panta-lla ciertas características que nos serán demáximo interés para el desarrollo denuestro juego.

XAML (II)Como se ha venido comentando a lo largode estas dos entregas, XAML puede revolu-cionar el sector con un nuevo modelo deprogramación declarativo para las interfa-ces de usuario. En este punto, el lectorencontrará ejemplos de interfaces pro-gramadas con XAML. En las páginas delartículo se explica cómo y dóndeobtener 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 laimplementación de un filtro que “proce-sará” aquellas peticiones que demandenuna imagen. Este ejemplo puede servir debase para que el lector inicie a partir deaquí sus propios desarrollos.

Desarrollo visual de IGUs JavaEclipse es una de las plataformas de des-arrollo más populares para los programa-

dores Java. En esta sección se incluye elproyecto que se ha venido desarrollando enel artículo.

Programación

AndroMDA 3.0M3AndroMDA es una herramienta construidasiguiendo el paradigma del desarrollo desoftware dirigido por modelos, o más con-cretamente, la propuesta MDA (ModelDriven Architecture) de OMG. Para aque-llos no iniciados en los conceptos queesconde MDA, diremos que este paradig-ma propone un modelo de desarrollo de

software basado en enfatizar las tareas deespecificación, dejando que la lógica seaimplementada de forma automática por

las herramientas (comopor ejemplo AndroMDA). Uno de los objeti-vos de MDA sería, porejemplo, permitir quealguien con un buenconocimiento del domi-nio en el que va a traba-jar la aplicación y conconocimientos de UML,pudiera desarrollar elsoftware desconocien-

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

CMSLos Sistemas Gestores de Contenidos (CMS)son una buena opción para el desarrollo deportales web. Sin duda es una buena noticiael disponer de una oferta tan variada deCMS, 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, MySQLy PHP), OpenCMS y Magnolia (estos

dos últimos pensados para la plata-forma J2EE).Recomendamos visitar el sitehttp://www.opensourcecms.com,pues en él hay multitud de conteni-dos de interés, tanto para quienesesté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.10Resin es un servidor de aplicaciones JavaOpen Source que recientemente ha sidoliberado con licencia GPL. Tomcat y Resinson los contenedores de Servlets máspopulares, sin embargo Resin se diferenciaen algo fundamental: también dispone deun contenedor de EJBs.

Y además…Al margen de los productos comentadosanteriormente, en el CD-ROM de este mesencontraremos la implementación de refe-rencia de la especificación Java Portlet(Pluto 1.0.1), JCrawler (véase la sección“javaHispano”), la plataforma Eclipse conlos plug-ins necesarios para convertirlo enun editor visual de IGUs y la librería ACEpara los programadores C++.

32

CD-ROM


Contenido del CD-ROMContenido del CD-ROM


Introducción

En el presente artículo trataremos de hacer unaintroducción al desarrollo de interfaces de usuariocon la herramienta Eclipse VE usando el API de JavaJFC/Swing. Eclipse es uno de los entornos de desarrollo Java máspopulares en la actualidad, y los lectores pudieronprofundizar en su arquitectura en el número 120. Unode los problemas más comunes con los que seencuentra un nuevo desarrollador al empezar conEclipse es el desarrollo de las interfaces de usuario demanera fácil. El SDK de Eclipse no incluye una herra-mienta para el desarrollo visual de los interfaces, comopueden incluir otras herramientas de desarrollo comoJBuilder o NetBeans que permiten crear la interfazgráfica de manera sencilla simplemente arrastrandocomponentes desde una paleta. Sin embargo Eclipsesoluciona este problema con Eclipse VE (Visual Editor).

VE es un plug-in que extiende Eclipse y que permite eldesarrollo de los interfaces de usuario de manera muysencilla, y que presenta varias ventajas sobre otroscompetidores como por ejemplo el implementarvarios APIs diferentes como AWT, Swing o SWT. En elpresente artículo haremos una introducción median-te un ejemplo práctico a VE, veremos cómo instalarlo,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ó elcurso “Creación de interfaces con JFC/Swing” acercade la librería gráfica Swing, sin embargo para seguir elpresente artículo no será necesario tener grandesconocimientos sobre esta librería, pues precisamenteeso 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 queimplementa una serie de servicios básicos, y quepuede ampliarse mediante los tan conocidos plug-ins. Un plug-in es una unidad de ejecución queamplia la funcionalidad de la plataforma. De hechola plataforma propiamente dicha apenas ofrece fun-cionalidad, básicamente permite gestionar recursosy manejar programas Java, y en el SDK que es la dis-tribución normal de Eclipse se incluye la plataformajunto con varios plug-ins que permiten ampliardicha funcionalidad, como se vio en su momentocon el artículo “Desarrollo J2EE con herramientasOpen 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ónbásica de Eclipse, el Eclipse SDK que como se puedever a su vez incluye la plataforma y una serie de plug-ins básicos. Dicho SDK se puede ampliar con otrosplug-ins, en la imagen las cajas con el texto “New tool”.La comunidad Open Source se ha volcado con eldesarrollo de distintos plug-ins para Eclipse, ademásde los plug-ins desarrollados por IBM, padre del pro-yecto Eclipse y que aún le proporciona soporte. Esohace que en la actualidad existan plug-ins paraEclipse para hacer prácticamente cualquier cosa,desde editar XML, desplegar EJBs en los servidoresmás comunes, desarrollo con J2EE, Antlr…VE no es más que eso, un plug-in que amplia lacapacidad de la plataforma Eclipse para permitir la

36

MIDDLEWARE

Desarrollo visualde IGUs JavaDesarrollo visual de IGUs JavaVE es un plug-in Open Source deEclipse que permite el desarrollorápido de interfaces de usuario. ConEclipse y VE es posible desarrollarinterfaces de usuario con Java Swingtan rápida y fácilmente como loharíamos en un entorno de desarrollodel estilo Visual Basic.

OSCAR COMBARROS, IRENE JIMÉNEZ


Figura 1. Arquitectura de plug-ins de Eclipse.


creación gráfica de interfaces de usuario demanera fácil. La instalación de un plug-in es muy simple,basta con copiar los ficheros del plug-in en losdirectorios adecuados de Eclipse, esto es, losdirectorios “Plugins” y “Features”. VE se puedeobtener de la dirección http://www.eclipse.org/vep/. Como se indica en la página de descarga,para que VE funcione correctamente debenestar 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 GEF3.0.1 (incluidas en el CD-ROM).Una vez obtenidos los ficheros de los plug-insbasta 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 lanzarEclipse los nuevos plug-ins quedan instaladosy ya podemos ver la nueva funcionalidad de laplataforma. Para comprobar que todo ha sidocorrecto, basta con seleccionar la opción “File”->“New”->“Other”. Como veremos ahora, bajola carpeta Java aparecen un gran número deopciones que no aparecerían antes, como porejemplo “Visual Class”, “Swing”…

Hola Mundo

Ya tenemos instalado correctamente VE, vamosahora a crear la primera clase de la interfaz deusuario con VE. Para ello creamos un proyectoJava y a continuación elegimos la opción “File”->“New”->“Other”->“Visual Class”. Una claseVisual no es más que una clase normal Java quehereda de alguna de las clases visuales posiblesde la API elegida, en nuestro caso Swing, y queimplementa ya los métodos necesarios.Aparecerá una nueva ventana, en ella debemosespecificar 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 pantallaaparece un listado con todas las clases visualesposibles, dependiendo de si queremos usar AWT,SWT o Swing. Nosotros vamos a usar Swing, yveremos que es posible elegir entre crearFrames, 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 deseamosque nos añada a la clase un método “main”. Una vez seleccionadas estas opciones VE se

encarga de generar todo el código necesariopor nosotros y nos abre el editor visual de laclase, en la figura 2 podemos ver las partesprincipales del editor. En primer lugar en laparte 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 esposible cambiar, por ejemplo, el tamaño delFrame simplemente arrastrando los bordes. En la zona 2, podemos ver el código Java gene-rado automáticamente, estas dos zonas estánconectadas 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ñodel Frame en la zona 2. De igual manera, simodificamos el método “initialize” y cambiamosla línea que especifica “this.setSize(300,200);”por “this.setSize(400,200);”, veremos cómo secambia 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, enesta parte de la pantalla podemos ver los Beansque se han creado. Si nos fijamos en ella veremosque ahora tenemos creado un Bean llamado“this” que es de tipo “JFrame”, si lo seleccionamosvemos que se selecciona la pantalla completa delFrame en la zona 1, y en la zona de código seselecciona el método “initialize” que es donde seinicializa el Frame. Debajo de ese Bean se puedever que se ha creado una clase de tipo“JContentPane”. Si la seleccionamos vemos quese 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 secrea esa clase. Así pues, de momento tenemos unBean de tipo “JFrame” que a su vez contiene otroBean de tipo “JContenPane”. Cuando añadamossucesivamente componentes al Frame, veremoscómo dichos componentes se van creando bajoel “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 lasposibles propiedades del mismo. Por ejemplo,en el caso del Frame podemos editar propieda-des como por ejemplo el “Layout”. Si cambiamoslas propiedades de la zona 5 se modifica auto-máticamente el código generado en la zonavisual (zona 1) y en la zona de código (zona 2).

Vamos ahora a probar el editor visual. En pri-mer lugar vamos a modificar algunas de laspropiedades del Frame creado. Modificamos lapropiedad “Visible”, que a priori está fijada a“false”, y la modificamos, fijándola a “true”. Acontinuació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 dosmaneras distintas de ejecutar la aplicación.Puesto que estamos realizando un JavaBeanpodemos ejecutar simplemente al Frame comosi fuera un Bean, o añadir el código necesario almétodo “main” para que se ejecute como unaaplicación normal. Durante el tiempo de des-arrollo es normal el ejecutar simplemente comoBean la aplicación para ver el aspecto que tieneaunque ésta solución solo sirva para tiempo dedesarrollo. Para ejecutar la aplicación como un Bean,seleccionamos en la vista de Beans (zona 4) elBean del Frame y ejecutamos la opción “Run”->“Run as”->“Java Bean”. Veremos el resultadode la ejecución de la aplicación y el aspecto quetiene. La otra forma de ejecución también esmuy 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 hechoes crear una nueva instancia de la clase, que ennuestro caso se llama “HolaMundo”. Comodicha clase ya implementa todos los métodosnecesarios de “JFrame”, no es necesario hacernada más. Ahora ejecutamos la aplicación como una apli-cación normal Java, opción “Run”->“Run as”->“Java Application”. Como vemos el resultadofinal es el mismo de cualquiera de las dos for-mas de ejecución. En este apartado hemos creado nuestra primeray muy simple interfaz de usuario. Como hemosvisto es muy sencillo el crear de manera visual lainterfaz, pero a continuación analizaremos elcódigo que nos ha generado VE y complicaremosel ejemplo con nuevas funcionalidades.

Un ejemplo más avanzado

Si nos fijamos en el código generado por VE, yque aparece en el listado 1, veremos que es muysimple. 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

MIDDLEWAREDesarrollo visual de IGUs Java



zación el cual se ocupa de fijar propiedades delFrame, como son el tamaño o el título. A su vezla clase tiene un campo “jContentPane” que esuna instancia de una clase “JPanel” y que será elpanel donde se fijará el contenido del Frame,dicho panel se inicializa en un método“getJContentPanel” si no estaba inicializadoanteriormente. Como se puede ver el códigogenerado es bastante limpio y fácil de seguir. Fijémonos ahora en la de componentes Swing.Dicha paleta tiene todos los componentesposibles de una interfaz Swing, organizado en3 grupos, “Componentes”, donde se almacenael grueso de los componentes, como puedenser botones, campos de texto, etiquetas, barrasde progreso… “Containers” donde se almace-nan los componentes que a su vez puedencontener a otros componentes, como puedenser los paneles y los Frames, y finalmente“Menus” donde están los componentes de losmenús. Ahora podríamos añadir cualquiera de estoscomponentes a la ventana que tenemos cre-ada simplemente arrastrando y soltando, sinembargo ya que queremos presentar lasposibilidades de VE vamos a elegir otro enfo-que. Vamos a crear un panel personalizado,con una serie de componentes sencillos yluego vamos a insertar en la pantalla princi-pal de la aplicación el Panel personalizadoque crearemos.Para crear el panel elegimos la opción “New”->“VisualClass” y en la pantalla que ya vimosantes elegimos crear un panel, y lo llamamos“MiPanel”.

Al nuevo panel que nos crea VE le vamos acambiar algunas propiedades, en primerlugar le modificamos la propiedad del“Layout”. Por defecto un panel se crea con lapropiedad layout fijada a “FlowLayout”, ennuestro caso la cambiaremos por un valor“null”. A continuación añadiremos a estepanel un par de componentes, añadiremosuna etiqueta (“JLabel”) a la que le cambiamosel campo “Text” por “Nombre”, un botón(“JButton”) al que le ponemos como texto“OK” y un campo de texto (“JTextField”), hastacrear un diseño parecido al que se puede veren la figura 3.

Para alinear los tres componentes, igualar la dis-tancia entre ellos y este tipo de cosas existen laspropiedades de alineado, se puede acceder a ellaspulsando el botón de “Customize layout” de labarra de tareas. En la figura 4 se puede ver resal-tado en rojo el botón a seleccionar y la ventanaque 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 comovertical del panel… con lo cual fácilmente se con-sigue un diseño más profesional.Podemos comprobar la apariencia del panelseleccionándolo en la vista de Beans y eligien-do “Run”->“Run As” ->”JavaBean” al igual quehicimos antes con el Frame. Una vez que elpanel ya tenga el diseño que queremos vamosa añadirle el código necesario para que lleve acabo alguna acción. Como podemos ver en el listado 2, el códigogenerado por VE es bastante simple, para cadacomponente añadido al panel crea un campode la clase del tipo oportuno, y en el método“initialize” configura propiedades del panelcomo el Layout y le añade como hijos los obje-tos anteriores tras inicializarlos. El objetivo de nuestro panel será almacenar eltexto que introduzca el usuario en una propie-dad del panel llamada “Nombre”, de tipo “String”y a dicha propiedad le añadiremos un métodopara fijarle el valor y para recogerlo, por lo tantohabrá que añadir el siguiente código:private String nombre = “N/A” ;

public String getNombre()

38

MIDDLEWARE


Figura 2. Desarrollando con Eclipse y VE.

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;

}}


{ return nombre; }

public void setNombre(String string)

{ this.nombre = string; }

Ahora ya tenemos preparada una propiedad enla que almacenar el valor que introduzca elusuario en el campo de texto.Vamos a querer en el futuro que el Frame, ocualquier otro Bean de la IGU que contenga elpanel, 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);

getJTextField().setText(string);

this.nombre = string;

}

Como se puede observar, básicamente lo quehemos hecho es invocar a un método“firePropertyChange”. Este método se ocupa delanzar un evento indicando que la propiedad seha modificado. De esta manera, para que cual-quier otro objeto se entere de que se ha modi-ficado la propiedad, basta con que implemen-te un manejador del evento que genera elmétodo “setNombre”, veremos más adelantecómo hacerlo.

Eventos

Ya tenemos creada nuestra propiedad dondealmacenar el valor, pero ahora necesitamosenterarnos de cuándo el usuario introduceun nuevo texto en el campo de texto o cuán-do pulsa el botón de OK. La manera con laque Swing interactúa con el usuario esmediante eventos.La gestión de eventos es una de las partesmás complicadas de programar con Swing ypor este motivo fue tratada con amplitud enel curso sobre Swing publicado en SóloProgramadores. Vamos a ver cómo se con-vierte en algo automático cuando usamosVE. Vamos a añadir el código necesario a lacaja de texto para que ésta reaccione anteun 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 elcódigo del manejador (listener) que se mues-tra a continuación:

private JTextField getJTextField() {

…

jTextField.addActionListener

(new java.awt.event.ActionListener() {

public void actionPerformed(java.

awt.event.ActionEvent e)

{System.out.println(“action

Performed()”);}

});

…

}

Como podemos ver el manejador del eventocreado sólo escribe por la consola un mensajede texto. Podemos modificar esa línea paraañadir la inteligencia que queramos al maneja-dor. Nosotros vamos a modificar esa línea ycambiarla por una que fije la propiedad al valorintroducido en el campo de texto:

public void actionPerformed(java.awt.

event.ActionEvent e)

{setNombre( jTextField.getText());}

Ahora cuado el usuario escriba algo en el campode texto, dicho valor se fijará en la propiedad“Nombre” del panel, y el método que lo fija,“setNombre”, se ocupará de lanzar un eventoindicando que la propiedad se ha modificado.Como podemos ver con VE se facilita mucho lagestión de eventos. Si en lugar de seleccionar laopción de “Action Performed” hubiéramos selec-cionado la opción “Add Events”, nos apareceríauna nueva ventana en la cual podríamos vercatalogados por secciones todos los eventosposibles, como por ejemplo eventos que respon-dan cuando una tecla es pulsada, etc. En esapantalla podremos añadir un manejador de cual-quiera de los eventos que se puedan producir. Vamos a repetir el proceso para añadir unevento a la pulsación del botón, para ello selec-

39



Figura 3. Panel personalizado.

Figura 4. Alineando los componentes.


cionamos el botón y con el botón derechoseleccionamos las mismas opciones, esto es,“Events”->“Action Performed”, y vemos cómose añade un código muy parecido al que seañadió al campo de texto, y de igual maneracambiamos la línea que escribe por pantalla unmensaje, 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());}

});

…

}

Ya tenemos casi completo nuestro panel, noshemos ocupado de que tenga el aspecto que que-remos y ahora hemos implementado las accionesque queremos que realice, sólo nos falta un paso,que consiste en añadir una línea al método queinicializa el campo de texto para hacer que al ini-ciarse tenga el valor de la propiedad “Nombre”:…

private JTextField getJTextField() {

…

jTextField.setText(nombre);

…

}

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 delcampo de texto.

Uniendo nuestro Panel con el programa principal

Hasta el momento hemos aprendido a mane-jar VE para crear componentes complejos quecontengan diferentes componentes de Swing ya gestionar los diferentes eventos de estoscomponentes fácilmente. En este apartadovamos a unir la pantalla principal de nuestroprograma y el panel creado, además vamos aver cómo crear un manejador que reaccionecuando se modifique la propiedad del panel.Primero seleccionamos el Frame principal, y pul-samos el botón de la barra de tareas de elegirBean, el botón que aparece resaltado en un cír-culo rojo en la figura 3 (parte superior derechade la figura). Nos aparecerá una pantalla en lacual podemos buscar los JavaBeans disponibles.Escribimos en nuestro caso el nombre que lehayamos puesto al panel, en este ejemplo

“MiPanel”. Cuando seleccionemos el Bean nosaparecerán resaltadas sobre el Frame las distin-tas zonas en las que podemos insertar el nuevocomponente, y arrastraremos el componenteseleccionado sobre la zona que queramos, aligual que haríamos con un componente normalañadido desde la paleta. En este ejemplo laarrastraremos a la zona central del Frame.Como vemos, el Panel que habíamos creadoantes se inserta en el Frame que será la panta-lla principal de nuestra aplicación. Como novamos a añadir más componentes a la pantallapues podemos redimensionar la pantalla paraque se ajuste mejor al tamaño del Panel quehemos insertado. El código que VE nos ha generado para inser-tar el Panel en la pantalla principal es elsiguiente:private MiPanel miPanel = null;

private MiPanel getMiPanel() {

if (miPanel == null) {

miPanel = new MiPanel();

}

return miPanel;

}

Si ahora pinchamos en la zona del panel de lapantalla principal y miramos las propiedadesveremos que tiene una propiedad llamada“Nombre” que como vimos antes es el campodel Panel donde almacenamos el texto que nosintroduzca el usuario en la GUI.Vamos a añadirle al Frame el manejador que seocupe de llevar a cabo alguna acción cuando elusuario teclee algo en la caja de texto y pulse elbotón de OK. Para ello seleccionamos el panel ypulsamos el botón derecho del ratón para selec-cionar la opción “Events”->“Add Events”. Estaopción nos conduce a una pantalla en la cualpodemos seleccionar todos los eventos posibles,en este caso abrimos la categoría “PropertyChange” y seleccionamos la propiedad“Nombre”, en la parte derecha de la pantalla nosaparece la nomenclatura que deseamos para elmanejador del evento, en este ejemplo seleccio-namos la segunda opción, la que nos pide dosparámetros en el manejador. Podemos ver elcódigo que nos genera VE en el listado 3.Como ocurría en ocasiones anteriores, elmanejador creado automáticamente soloimprime por pantalla un mensaje, en esteejemplo de juguete vamos a dejar el manejadortal 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

40

MIDDLEWARE


LISTADO 2 Código del panel generado automáticamente

public class MiPanel extends JPanel {

private JLabel jLabel = null;private JTextField jTextField = null;private JButton jButton = null;

public MiPanel() { … }

private void initialize() {this.setLayout(null);this.setSize(271, 56);jLabel = new JLabel();jLabel.setBounds(31, 21, 53, 20);this.add(jLabel, null);this.add(getJTextField(), null);this.add(getJButton(), null);

}private JTextField getJTextField() {

if (jTextField == null) {jTextField = new JTextField();jTextField.setBounds(100, 21, 53, 20);

}return jTextField;

}

private JButton getJButton() {if (jButton == null) {

jButton = new JButton();jButton.setBounds(168, 21, 53, 20);jButton.setText(“OK”);

}return jButton;

}}


cierre. El proceso es el mismo que hemoshecho antes, generar un manejador que res-ponda a un evento, en este caso el cierre de laventana. Seleccionamos el Frame y pulsamos elbotón derecho, en el menú emergente queaparece seleccionamos “WindowClossing”, ymodificamos el manejador que nos genera VE,añadiendo el código “System.exit(0);” comovemos en el listado 4.Ya tenemos la aplicación lista, ahora podemosejecutarla y comprobar que si introducimos unnuevo texto en la caja de texto y pulsamos elbotón de OK, en la consola se imprime un men-saje indicando que se ha modificado la propiedad. El enfoque que hemos elegido de crear un panely a ese panel añadirle los componentes sencillosy luego insertar el panel en la pantalla principalde la aplicación puede parecer excesivamentecomplicado. En realidad habríamos conseguidoel mismo efecto si directamente hubiéramosinsertado en la pantalla principal de la aplicaciónuna etiqueta, un campo de texto y un botón. Sinembargo la opción elegida es mucho más flexi-ble. Si imaginamos una aplicación real, en la cualpuede haber multitud de pantallas en las que serepitan formularios, por ejemplo para pedir losdatos personales de una persona, este enfoquenos permite reutilizar el código generándolo solouna vez, he insertando el panel en tantos sitioscomo nos haga falta. Y lo que es más importan-te, nos permite que modificando una sola vez elpanel (por ejemplo para eliminar errores) semodifique en todos los puntos de la aplicación.

El Look And Feel

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

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 queno aparece seleccionado ninguno. Vamos aseleccionar el Look And Feel de Windows. A continuación cerraremos todas las pantallasque tenemos abiertas, la del Panel y la delFrame y las volvemos a abrir para que VE cojalas nuevas propiedades. Como veremos elaspecto del Panel cambia bastante, y su aspec-to es mucho más atractivo ahora. Siguiendo estos pasos podemos cambiar elLook And Feel que nos muestra el editor, lo cuales fundamental para comprobar que la IGU seva a comportar como esperamos en cualquierentorno. Si queremos que la aplicación coja unLook And Feel determinado en tiempo de ejecu-ción dependiendo del sistema operativo sobreel que se ejecute, debemos añadirle algo decódigo a nuestra aplicación. Modificaremos elmétodo “main” del programa añadiéndole lassiguientes 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ónque deseamos que se ejecute sobre distintossistemas operativos (por ejemplo Windows yLinux) es importante el probar diferentes LookAnd Feels para comprobar que cuando ejecu-temos la aplicación en un entorno distinto delde desarrollo no nos llevemos una sorpresadesagradable. En la figura 5 podemos ver elaspecto de la aplicación con distintos Look AndFeel, en este caso “Metal”, “Windows” y“CDE/Motif”. Como podemos ver el aspecto quepresentará la aplicación si la ejecutamos conun Look And Feel “Motif” no es el esperado, siqueremos 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 deusuario de manera sencilla y rápida, facilitandoel desarrollo especialmente a programadoresque no son expertos en Swing. La característica más apreciable de VE es la lim-pieza del código que genera, al contrario queotras aplicaciones de generación gráfica decódigo, el código generado por VE es bastantelimpio y fácil de seguir. Todo ello con el añadidode ser una herramienta que al igual que Eclipsees Open Source y totalmente gratuita. Comoúnica pega se podría mencionar que al igual queEclipse, para desarrollar de manera fluida nece-sita de una máquina bastante potente, pero alritmo que avanza el hardware esto no parece unproblema demasiado importante.

41



LISTADO 3Listener de cambio de propiedades generado automáticamente

private MiPanel getMiPanel() {if (miPanel == null) {

miPanel = new MiPanel();miPanel.setNombre(“N/A”);miPanel.addPropertyChangeListener(“nombre”, new

java.beans.PropertyChangeListener() { public void propertyChange(java.beans.PropertyChangeEvent e) {

System.out.println(“propertyChange(nombre)”); }

});}return miPanel;

}

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

private void initialize() {this.setTitle(“Hola Mundo”);this.setSize(351, 90);this.setContentPane(getJContentPane());this.setVisible(true);this.addWindowListener(new java.awt.event.WindowAdapter() {

public void windowClosing(java.awt.event.WindowEvent e) { System.exit(0);

}});

}

Figura 5. Diferentes Look And Feel.


El mes pasado vimos una clasificación de CMS queconsideraba tres grandes familias: sistemas basa-dos en PHP, sistemas basados en Java y sistemasbasados en el empleo de otras tecnologías. Dentrode esta última familia repasamos las característi-cas del que posiblemente sea el CMS Open Sourcemás maduro, Zope. También comentamos que alestar basado en una plataforma tecnológicainusual (base de datos propia orientada a objetos,lenguaje de programación Python) quizás no fuese

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 CMSOpen Source.

Soluciones CMS basadas en PHP

En esta familia de CMS agrupamos a aquellassoluciones que se apoyan en lo que se viene adenominar la pila de tecnologías “LAMP”, esdecir, Linux, Apache, MySQL y PHP. Estos CMStienen la ventaja de que todas estas tecnologíasson muy extendidas dentro del mundo del soft-ware libre, pero también tienen el inconvenientede 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 elCMS. El lenguaje de script de servidor PHP estámuy extendido, dispone de un amplio soporte yes de ejecución rápida. No obstante, todavíamuchos expertos y analistas de sistemas no loconsideran una solución tan fiable para sistemasempresariales como las basadas en las platafor-mas J2EE o .NET, en gran parte debido a que elbalanceo de carga no está tan fácilmente imple-mentado como en las otras.Dentro de los CMS pertenecientes a esta familiacabe destacar PHP-Nuke, PostNuke y Midgard.PHP-Nuke y PostNuke son soluciones muy simila-res, como su propio nombre deja intuir, empleadassobretodo para la construcción de portales temá-ticos de pequeño tamaño, dedicados al ocio,entretenimiento, o temas comunes. PostNuke fuedesarrollado por un miembro original de la comu-nidad de PHP-Nuke que disentía de la direcciónque éste estaba tomando. No obstante, el códigode PostNuke fue sustituido para mejorar su rendi-miento y seguridad.Partiendo de estos CMS han surgido numerosasderivaciones o “forks”, lo que no ha contribuido nia fomentar el desarrollo de estos productos ni afacilitar la tarea de optar por alguno de ellos parasu implantación.El punto fuerte de estas soluciones radica en lacomunidad que las respalda. Existen numerosísi-mas extensiones de estos CMS disponibles para su

42

REDES

Sistemas de Gestiónde Contenidos (y II)Sistemas de Gestiónde Contenidos (y II)

Para concluir con nuestra revisión alos Sistemas de Gestión deContenidos veremos las dos grandesfamilias de CMS existentes (PHP yJava) y describiremos brevemente elAPI de Portlets, iniciativa que tratade estandarizar la construcción decomponentes de portal para elmundo Java.

ALVARO ZABALA ORDÓÑEZ


Figura 1. Portal de la comunidad de PHP-Nuke, uno de los primeros grandes CMSOpen Source.


descarga en el web. Aún así, todavía debenavanzar muchísimo en materias comosoporte para workflow, ciclo de vida depublicación, herramientas gráficas de admi-nistración, etc. Además, no ofrecen muchasopciones para diseñar la apariencia y distri-bución de los elementos del portal. Ésto haceque todos los sitios web creados con estosCMS 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 demayor robustez y escalabilidad que los ante-riores, por lo que puede ser empleado paraimplementar portales empresariales decarga media o alta.Algunas de las características que dan unvalor añadido a Midgard son la accesibilidad(a través del cumplimiento de las directricesWAI del W3C), el soporte para múltiplessitios web dentro de un mismo CMS, graciasa aplicar un modelo de bases de datos vir-tuales, y la incorporación de un motor deworkflow basado en la tecnología XML.

Soluciones CMS basadas en la plataforma J2EE

Actualmente la plataforma de desarrolloempresarial J2EE parece estar imponiéndosepara la construcción de aplicaciones de ladodel servidor. Por esta razón, existe un grannúmero de CMS desarrollados bajo esta pla-

taforma: OpenCMS, Magnolia, Jboss Nukes,Jahia, o incluso el CMS impulsado por lacomunidad JavaHispano, colaboradora habi-tual de esta revista, Canyamo, con el queésta ha desarrollado su portal web.Todos estos sistemas se benefician de lasventajas de la plataforma Java: portabilidada todas las plataformas para las que hayadisponible una máquina virtual, conectivi-dad con cualquier tipo de base de datosmediante el estándar JDBC, integración con

servidores de aplicaciones J2EE, excelentesoporte para el estándar XML y tecnologíasderivadas como Web Services, motores deplantillas para el renderizado HTML, etc. Noobstante, cada proyecto sigue sus propiaspautas de desarrollo, y tiene sus propiaspolíticas de calidad y diseños. Esto hace quela comunidad existente detrás de cada unode ellos sea desigual. Como en este artículono podemos hablar de todos ellos, comenta-remos algunas de las principales caracterís-ticas de dos de los más famosos: Magnolia yOpenCMS.

MagnoliaEl punto fuerte de Magnolia radica en surepositorio de contenidos, que ha sidoconstruido según el estándar JCR (JavaContent Repositories). Otro de sus puntosfuertes es el de su distribución, resultandobastante sencilla su instalación y puestaen marcha (característica bastante infre-cuente en los proyectos de software libre).Además, no requiere de ninguna base dedatos adicional.

OpenCMSOpenCMS comparte con Magnolia todoslos beneficios derivados de utilizar la pla-taforma Java. Además, también resultabastante sencillo de instalar. OpenCMS dis-pone de una comunidad más amplia queMagnolia pues ha surgido como un pro-yecto libre promovido por su propia comu-

43

REDESSistemas de Gestión de Contenidos (y II)


Figura 3. Creación de workflows en OpenCMS.

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


nidad, al contrario que Magnolia que esdesarrollado por una empresa que seencarga de mantenerlo. OpenCMS sírequiere de una base de datos para podertrabajar, e incorpora un motor de workflowal igual que el anterior.Su interfaz gráfica es muy amigable, siendomuy parecida a los exploradores de ficherosmás corrientes. En ésta los recursos queforman parte del portal aparecen organiza-dos de forma jerárquica, y en diferentescolores según su estado (en producción,bloqueado y siendo editado por un usuarioo eliminado). Proporciona un editorWYSIWYG, al estilo de FrontPage, para lacreación de contenidos desde la propiaherramienta. También incluye un reposito-rio de recursos, como imágenes, scripts, etc.de forma que para incrustar uno de estosrecursos 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, yevita su duplicidad. OpenCMS también pro-porciona herramientas gráficas para la cre-ación de workflows. En la figura 3 podemosver cómo gracias a esta herramienta sepueden crear tareas y asignárselas a usua-rios dentro del workflow de creación decontenidos. Esta herramienta permite ade-más el envío de correos electrónicos a losusuarios a los que se les ha asignado unatarea, la reasignación de la misma a otrousuario, y el envío de un correo notificandola finalización de una tarea a aquel usuarioque la creó.OpenCMS es un sistema que se apoyatotalmente en la base de datos. En este tipode sistemas las páginas suelen ser creadasdinámicamente a partir del contenido de labase de datos y de las plantillas de presen-tación establecidas. Para evitar los proble-mas de rendimiento que esta característicapodría ocasionar, OpenCMS incorpora unmecanismo de caché extensible. La primeravez que una página es solicitada, ésta esgenerada dinámicamente y almacenada encaché para posteriores peticiones. Cuandose producen modificaciones en el conteni-do de la base de datos al que está asociadola página, estos cambios son propagadosautomáticamente a la caché. No obstante,en el caso de que se requiera una versiónestática del portal entero o de partes deéste, OpenCMS permite la exportación deestos directamente al servidor web. Ésto es

de gran utilidad para determinados conte-nidos que tienen un carácter muy estático,como imágenes o archivos binarios. Otropunto destacable de OpenCMS es la inclu-sión de características de seguridad:OpenCMS permite aplicar encriptado fuertea 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 mundoJava: el API de Portlets

Como hemos visto a lo largo de estas dosentregas, el número de CMS y WCM existen-tes es cada vez mayor. La mayoría de estossistemas han creado mecanismos para sufá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 leañ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 proporcionadopor el CMS.No obstante, esta variedad de frameworksincompatibles unos de otros representa unproblema, puesto que los componentes des-arrollados para un CMS no son reutilizablespara 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 entrePortlets 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 loscomponentes de portal, recibiría peticionesy generaría contenido dinámico. Los porta-les utilizarían los Portlets como elementosde interfaz de usuario ensamblables, queproporcionarían una capa de presentaciónal sistema. Algunos de los objetivos de estaespecificación son:� Definir las especificaciones que debe

cumplir el entorno de ejecución para losPortlets, el contenedor de Portlets.

� Establecer el API que deben seguir losPortlets para que sean gestionados porel contenedor, a través de los mecanis-mos de ligadura dinámica, herencia ypolimorfismo.

� Proporcionar mecanismos para guardarde forma persistente el estado de losPortlets, bien sea en base de datos, XML ocualquier otro mecanismo de persistencia.

� Permitir la portabilidad binaria de losPortlets entre diferentes contenedores,y definir un estándar de empaquetadode Portlets para su posterior despliegueen el contenedor.

Conforme a esta nueva filosofía, un portal webestaría formado por una aplicación que proce-sa las peticiones de clientes, solicita todosaquellos 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

44

REDES


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


ejecución para los Portlets, y se comunica conéstos a través del API de Portlet. A su vez, elcontenedor de Portlets es llamado por el portalweb 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 (interfazpara proveedores de servicios).

Visión general del API de PortletsPara entender un poco mejor cómo se con-sigue la estandarización de los elementos deportal en el mundo Java, haremos un breverepaso al API de Portlets.De acuerdo con la especificación, un Portletsería una clase Java que implementase lainterfaz Portlet, o que heredase de algunaclase 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 deinicialización del Portlet. Se llama unasola vez para cada Portlet, cuando seconstruye su instancia. Suele ser utili-zado para realizar operaciones costo-sas como cargar datos de la base dedatos, 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 Portletque el usuario ha realizado una acciónsobre 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, RenderResponse response): Este métodoes llamado por el contenedor paragenerar la salida del Portlet. Para cadaPortlet de la página actual del usuariose llama a este método, y la salida finalde todos los Portlets es compuestasegún defina la plantilla de composiciónestablecida para la página.

� destroy(): La llamada a este métodoindica el final del ciclo de vida delPortlet, por lo que el Portlet debe libe-rar todos los recursos costosos queesté consumiendo y guardar de formapersistente su estado.

Gracias a que todos los Portlets cumplen elcontrato de implementar esta interfaz,cuando el contenedor de Portlets recibe unapetición, se encarga de instanciar el Portletal que está destinada, y de invocar estos

métodos según el orden definido por su ciclode vida. En virtud a este diseño, se puedenañadir nuevos Portlets sin que el sistema sevea afectado o haya que reiniciarlo. El únicorequisito es que sigan esta especificación.

Modo de trabajo de un PortletAnteriormente hemos comentado quecomo consecuencia de la invocación delmétodo “processAction” un Portlet puedecambiar su modo de trabajo. El modo de unPortlet sirve para indicar la función que elPortlet realiza. Normalmente, los Portletspueden ejecutar diferentes tareas y creardiferentes contenidos en función de latarea que estén desempeñando. Gracias almodo de trabajo del Portlet, éste sabe quéfunción realizar y qué contenido generarante la petición de un usuario. La especifi-cación clasifica los modos de trabajo dePortlets 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 devista, necesario para generar sus sali-das. El modo de edición se utiliza paramodificar las configuraciones de usua-rio que les permiten personalizar laapariencia del Portlet, y el modo deayuda se emplea para visualizar enpantalla información sobre el funcio-namiento del Portlet.

� Modos opcionales: Son modos que unportal podría tener. Tenemos el modo“Acerca de”, el modo “Configuración”, elmodo “Previsualización” y el modo“Impresión”.

� Modos específicos de las casascomerciales: Todos aquellos que de-seen implementar los fabricantes deportales y contenedores de Portlets.

Empaquetado y despliegue de PortletsAl estar basados en la arquitectura J2EE, unPortlet junto con los recursos que necesitey sus descriptores de despliegue son empa-quetados juntos en fichero WAR. Para loslectores que desconozcan esta plataformade desarrollo empresarial, cabe decir queun descriptor de despliegue es un docu-mento XML que proporciona informaciónde configuración sobre el Portlet al conte-nedor, y que un fichero WAR es un ficherode empaquetado para componentes des-plegados en un servidor de aplicaciones.

Implementación de referencia de la especificación: Pluto

Pluto es la implementación de referencia dela especificación de Portlets, y ha sido inclui-da dentro del incubador de proyectos delproyecto Jakarta, proyecto que alberga ungran número de herramientas Open Sourcede interés para el mundo Java. No obstante,Pluto no pretende ser una solución paraentornos empresariales de elevada carga. Suobjetivo es mucho más simple: proporcionara los desarrolladores de componentes deportal un entorno de desarrollo para realizarsus pruebas. La arquitectura de Pluto estáformada por dos componentes básicos: elportal y el contenedor de Portlets, por dosinterfaces: 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 elportal). En la figura 5 podemos ver estaarquitectura 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, aquellosservicios que invoquen al contenedor dePortlets deben implementar la interfaz SPIpara proveedores de servicios. Esto es nece-sario para independizar el contenedor delportal, ya que cuando el contenedor hayafinalizado la ejecución de los Portlets, secomunicará a través de la mencionadainterfaz con los usuarios de sus servicios,para obtener información del componenteportal. La comunicación entre los Portlets yel contenedor se realiza a través del API dePortlet. Cabe reseñar que este componentees bastante simple, y sólo trata de mostrarcómo debe interactuar un servicio de portalcon el contenedor de Portlets, a través delas APIs de invocación y de proveedor deservicios.El contenedor de Portlets está diseñado detal forma que permanece completamenteaislado de cualquier otro elemento del por-tal. En consecuencia, podría ser embebidodentro de cualquier otro portal.El proceso de despliegue de Portlet en Plutoes bastante sencillo: una vez creado elfichero WAR, se debe ejecutar el script“deployPortlet.bat” especificándole comoparámetro la ubicación del archivo deempaquetado WAR del Portlet que quere-

45

REDESSistemas de Gestión de Contenidos (y II)



mos desplegar. Este script de despliegueforma parte de la instalación de Pluto. Por último, una vez desplegados los Portletsy registrados en el componente de portal,habría que definir la apariencia final delportal. Para tal fin, Pluto utiliza el archivode configuración “pageregistry.xml”. En estaestructura XML se incluirán etiquetas paraintroducir la salida de un Portlet en la com-posición final de la página, indicando laorientación que deben tomar sus salidas endicha composición final.

Siguiente paso en la gestión de portales: portales federados

Según la prestigiosa consultora GarnetGroup, los sistemas WCM tenderán hacia laconstrucción de portales federados. Estetipo de portales se basan en permitir a sususuarios, bien sea de una intranet, extraneto de Internet, acceder a una determinadainformación de forma transparente a lalocalización real del contenido. En conse-cuencia, los diferentes portales que conten-gan esta información se integrarán deforma que el usuario no necesite recordar

cientos de URLs y autentificarse en tantossitios como portales contengan la informa-ción que requiere consultar. Para ello, estosportales deberán coordinarse para propor-cionar una sola autentificación (lo que seviene a denominar “single sign-on”), lo queimplica crear un único usuario para todosestos portales. Además, deberán comuni-carse para intercambiar contenido entreellos y así atender las solicitudes de sususuarios. Evidentemente, esta coordinaciónentre portales no sería posible sin la elabo-ración de estándares a los que todos seadhieran. En este sentido la industria deelaboración de gestores de contenido y ser-vidores de portal ha creado varios estánda-res para alcanzar este objetivo:� El estándar JSR-168, descrito con ante-

rioridad, para buscar la portabilidad dePortlets creados por diferentes fabri-cantes a diferentes servidores de portal.

� El estándar WSRP (Web Services forRemote Portlets) trata de dar solución alproblema del intercambio de contenidoentre portales remotos. Para ello, se apoyaen la tecnología de servicios web, de formaque para acceder a contenido albergado

en otro portal tan solo habría que utilizarun servicio web publicado por éste.

� El estándar SAML (Security AssertionMarkup Language) trata de federar losesquemas de seguridad establecidospara los diferentes portales, permitien-do a un usuario navegar entre los domi-nios de diferentes portales sin tener quevolver a autentificarse al cambiar deportal. Básicamente consiste en un pro-tocolo basado en el intercambio deaserciones que permite a los sistemasde seguridad de diferentes portalescomunicarse entre sí e intercambiarinformación acerca del perfil de undeterminado usuario.

La tecnología de portales federados estabaconcebida en un primer momento para con-seguir la integración de los diferentes porta-les departamentales de una misma organiza-ción. Un paso más en este sentido consiste enla federación entre portales de diferentesorganizaciones. Para dar respuesta a estanecesidad han surgido proyectos comoLiberty (http://www.projectliberty.org), oMicrosoft Passport (http://www.passport.net).

Conclusiones

A lo largo de estos dos artículos hemos tra-tado de introducir al lector en el tipo de sis-tema que constituye un CMS. Hemos vistoalgunas de sus principales características yfuncionalidades, y una pequeña muestra deproductos comerciales y de carácter libre.En la parte final de la serie, nos hemos cen-trado en una interesante iniciativa para laestandarización de los elementos de portalpara CMS en la plataforma Java: la especi-ficación JSR-168.No obstante, a la hora de optar por una solu-ción u otra no sólo influyen los condicionan-tes técnicos o económicos. También influye laplataforma tecnológica (sistema operativo,bases de datos, servidor de aplicaciones, etc.)que ya se encuentre implantada.

46

REDES


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

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.


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 estanto cambiar la funcionalidad de los Servlets ypáginas JSP originales como poder añadir otranueva sin necesidad de rescribir el código ya des-arrollado y puesto en producción. En ocasiones senecesita que este procesamiento se haga antes deque la petición se sirva. Por ejemplo, ésto es típicocuando se quieren implementar sistemas que sóloacepten peticiones procedentes de determinadasIP. En otros casos el procesamiento debe llevarse acabo después, es decir, una vez que se ha genera-do una respuesta ésta se intercepta y se trataantes de que llegue finalmente al cliente. Uno delos casos más comunes de este segundo tipo es elque se hace para codificar las páginas HTML congzip para comprimirlas, de forma que reduzca elancho de banda consumido entre el servidor y elnavegador.Los filtros de Java se ajustan perfectamente a losdos modelos expuestos. Su funcionamiento yconfiguración es muy simple, de forma que variosfiltros pueden encadenarse tan solo modificandoel fichero de configuración del servidor web. Paralos 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 JavaOpen Source más populares.

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 ficherode configuración de la aplicación (donde se defi-nen los Servlets y los filtros, se indican cuáles sonlos classpath, se establecen variables de inicializa-ción que posteriormente se pueden obtener con elmé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 seencuentra también otro directorio que también sellama “WEB-INF”. El directorio “classes” que seespecifica 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 queguarda la configuración tanto de los filtroscomo de los Servlets. Para el primer caso sedefinen 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 definirreglas que se aplican a las URL correspondien-tes a las peticiones y que determinan cuáles deestas peticiones son filtradas o no. Así el atribu-to “filter-name” especifica el filtro a aplicar, y elatributo “url-pattern” la regla que, aplicada a laURL de la petición, indica si debe aplicarse el fil-tro o no en ese caso.

48

REDES

Servlets Filters (I)Servlets Filters (I)

Agregando filtros a nuestraaplicación web podremos interceptarlas peticiones que se hagan sobreésta, pudiéndolas procesar antes y/odespués de pasar el control al Servleto la página JSP correspondiente.Además, los filtros ofrecen unmecanismo muy útil para añadirfuncionalidades a nuestra aplicaciónweb.

ADOLFO ALADRO GARCÍA


Los filtros permitenprocesar tanto las

peticiones que llegan a nuestra aplicación como

las respuestasde ésta

LISTADO 1Estructura dedirectorios con Caucho

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

|+- classes


En el listado 2 se muestra un fichero“web.xml” que define un filtro cuyo nombrees “spp-filter” y que está implementado en laclase “FSerlvetFiltersFilter”, perteneciente alpaquete “com.spp.servletfilters.filter”. Laspeticiones que recibe la aplicación web sólose 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 laclase que lo implementa (el atributo “servlet-class”). Por otro lado, la etiqueta “<servlet-mapping>” especifica qué URL correspon-dientes a peticiones son servidas por eseServlet. El atributo “servlet-name” indica elnombre del Servlet, y el atributo “url-pattern”es el patrón que aplicado a la URL revela si esapetición debe ser atendida o no por el Servlet.

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-

ta en una única ocasión, normalmentecuando el filtro va a emplearse por primeravez. En este método se realizarán entre otrasaquellas tareas de inicialización que seannecesarias en función de la naturaleza delfiltro. Seguidamente se muestra la imple-mentación más sencilla del método init:

private FilterConfig config = null;

public void init(FilterConfig config)

throws ServletException

{ this.config = config; }

En este caso simplemente se guarda en unapropiedad de la clase el objeto que contienela información de configuración del filtro.El método “doFilter” es el responsable deprocesar las peticiones, es decir, es quienrealmente filtra las peticiones. Se define tal ycomo sigue a continuación:public void doFilter(ServletRequest

request, ServletResponse response,

FilterChain next) throws IOException,

ServletException

{ ... }

Los dos primeros parámetros representan losobjetos que se corresponden respectivamen-te con la petición y la respuesta. El tercerparámetro permite gestionar la concatena-ción de filtros, o lo que es lo mismo, haceposible redirigir la petición al siguiente filtro,si es que hay alguno configurado.El filtro más sencillo que puede definirse esaquél cuyo método “doFilter” tiene unaúnica línea:next.doFilter(request, response);

49

REDESServlets 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>

LISTADO 3 Nuestro primer filtro

HttpServletRequest req = (HttpServletRequest) request;

for (Enumeration e = req.getHeaderNames(); e.hasMoreElements() ;) {String sHeaderName = (String)e.nextElement();String sHeaderValue = req.getHeader(sHeaderName);

System.out.println(sHeaderName + “=” + sHeaderValue);}System.out.println(“AuthType()=” + req.getAuthType());System.out.println(“ContentType()=” + req.getContentType());System.out.println(“ContentLength()=” + req.getContentLength());System.out.println(“PathInfo()=” + req.getPathInfo());System.out.println(“PathTranslated()=” + req.getPathTranslated());System.out.println(“QueryString()=” + req.getQueryString());System.out.println(“RemoteAddr()=” + req.getRemoteAddr());System.out.println(“RemoteHost()=” + req.getRemoteHost());System.out.println(“RemoteUser()=” + req.getRemoteUser());System.out.println(“Method()=” + req.getMethod());System.out.println(“ServletPath()=” + req.getServletPath());System.out.println(“ServerName()=” + req.getServerName());System.out.println(“Protocol()=” + req.getProtocol());System.out.println(“ServerPort()=” + req.getServerPort());

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


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 Servletresponsable en última instancia de procesary atender a dicha petición.Tal y como se ha adelantado, los objetos“request” y “response” permiten gestionar lapetición y la respuesta, lo que hace posibleque un filtro pueda hacer prácticamente lomismo que un Servlet. En el listado 3 semuestra el código de un filtro que imprimepor la salida estándar el valor de todas lasvariables HTTP de la solicitud.En primer lugar se obtiene una referencia a unobjeto que implementa la interfaz “javax.ser-vlet.HttpServletRequest” simplemente modifi-cando el tipo del parámetro “request”. A partirde este momento se puede trabajar con lavariable “req” del mismo modo que se hace enun Servlet, por lo que el método“getHeaderNames” proporciona una coleccióncon los nombres de las cabeceras HTTP de lasolicitud, y el método “getHeader” permiteconocer 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 lasrespuestas 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 elcó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 solicitanimágenes JPG. La función del filtro seráescalar dichas imágenes antes de servirlas.En primer lugar se configura el filtro en elfichero “web.xml”:<filter filter-name=”img-filter”

filter-class=”com.spp.servletfilters.

filter.FSerlvetFiltersImgFilter”/>

<filter-mapping url-pattern=”*jpg”

filter-name=”img-filter”/>

De las líneas anteriores se deduce que todasaquellas peticiones que terminen con lacadena de texto “jpg” serán procesadas porel filtro que se corresponde con la clase“FSerlvetFiltersImgFilter”, cuyo método prin-cipal, “doFilter”, es tal y como sigue:HttpServletResponse res = (HttpServlet

Response)response;

ServletResponseWrapperImg servlet

ResponseWrapperImg = new ServletResponse

WrapperImg(res);

next.doFilter(request, servletResponse

WrapperImg);

Como se verá dentro de poco, la clase“ServletResponseWrapperImg” extiende a laclase “HttpServletResponseWrapper”, que esuna clase del API con la que se puede “envol-ver” el tratamiento de las peticiones deforma que éstas se procesen de una maneradeterminada, independientemente de lo quehaga la aplicación web. Esto es justo lo quedefine a un filtro.La clase “ServletResponseWrapperImg”cuenta con dos propiedades definidas como“protected” y que almacenan respectiva-mente el objeto original correspondiente a larespuesta y un flujo de escritura. Estúdiese ellistado 4.El constructor llama en primer lugar al cons-tructor de la clase padre y después se asigna lapropiedad “responseOrig”. A partir de ahora laclase “ServletResponseWrapperImg” debeimplementar aquellos métodos que seannecesarios para el propósito del filtro, dejandoque los restantes métodos sean ejecutadospor 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 loque se van a implementar los métodos queluce el listado 5.El primero de ellos es el más importante yaque cuando se llama al método “getOutputStream” se obtiene el flujo de escritura quese empleará más adelante para escribir losdatos correspondientes a la lectura, es decir, lapropia imagen. Para procesar los datos yhacerlos llegar al cliente se ha creado unanueva clase, “ServletOutputStreamImg”. Estaes la responsable última del tratamiento de lasimágenes y su estructura es la que se presen-ta en el listado 6.Los dos primeros miembros de la claseguardan el objeto correspondiente a la

50

REDES


LISTADO 4 La clase ServletResponseWrapperImg

class ServletResponseWrapperImgextends HttpServletResponseWrapper{

protected HttpServletResponse responseOrig = null;protected ServletOutputStream servletOutputStream = null;

public ServletResponseWrapperImg(HttpServletResponse response){

super(response);responseOrig = response;

}...

}

LISTADO 5 Los métodos a implementar

public ServletOutputStream getOutputStream()throws IOException{

if (servletOutputStream==null) {servletOutputStream = new ServletOutputStreamImg(responseOrig);

}return servletOutputStream;

}

public void flushBuffer()throws IOException{

servletOutputStream.flush();}

public ServletResponse getResponse(){

return this;}


respuesta y el canal de escritura origina-les. La propiedad denominada “baos” seempleará para almacenar en un bufferintermedio los datos de la imagen devuel-ta (antes de ser escalada). Finalmente elmiembro “bClosed” contiene un valorbooleano que indica si el flujo de escritu-ra está cerrado o no. El constructor de laclase llama en primer lugar al constructorde la clase padre y después pasa a inicia-lizar sus miembros.Cuando el servidor devuelve la imagenemplea los métodos de esta clase paraescribir los datos, lo que para el caso de lasimágenes, que son datos binarios, serántípicamente todos los métodos “write”. Elpropósito de esta clase es hacer que la eje-cución de esos métodos no sea “real”, esdecir, que los datos no se manden al clien-te sino que se almacenen internamente

para ser tratados después. Esta mismaclase, cuando haya acabado el procesa-miento de dichos datos, será quien final-mente los mande al cliente. Por lo tanto“ServletOutputStreamImg” implementarálos métodos del listado 7.El mecanismo es sencillo: en vez de escribiren la salida estándar para estos casos seescribe en el buffer interno utilizando laclase “ByteArrayOutputStream”.La ejecución del método “close” marca elfinal de los datos, momento en el que laclase “ServletOutputStreamImg” tiene quecomenzar el tratamiento de los datos:public void close()

throws IOException

{

if (bClosed) {

throw new IOException(“This output

stream has already been closed”);

}

byte[] bytes = baos.toByteArray();

...

}

El método “toByteArray” de la clase“ByteArrayOutputStream” devuelve un arrayde bytes con los datos escritos hasta elmomento. Este array representa la imagenoriginal devuelta. Existen muchas formas deescalar una imagen pero quizás la más sen-cilla consiste en emplear el método“getScaledInstance” de la clase “Image”. Pero

51

REDESServlets Filters (I)


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

LISTADO 6 La clase ServletOutputStreamImg

class ServletOutputStreamImgextends ServletOutputStream{

protected HttpServletResponse response = null;protected ServletOutputStream servletOutputStream = null;protected ByteArrayOutputStream baos = null;protected boolean bClosed = false;

public ServletOutputStreamImg(HttpServletResponse response)throws IOException{

super();bClosed = false;this.response = response;this.servletOutputStream = response.getOutputStream();baos = new ByteArrayOutputStream();

}

...}

LISTADO 7 Métodos que implementa la clase ServletOutputStreamImg

public void write(int b)throws IOException{

if (bClosed) {throw new IOException(“Cannot write to a closed output stream”);

}baos.write((byte)b);

}

public void write(byte b[])throws IOException{

write(b, 0, b.length);}

public void write(byte b[], int off, int len)throws IOException{

if (bClosed) {throw new IOException(“Cannot write to a closed output stream”);

}baos.write(b, off, len);

}


antes de poder emplear este método es pre-ciso obtener la propia imagen a partir delarray de bytes:ImageIcon imageIcon = new ImageIcon

(bytes);

La ventaja principal de usar la clase“ImageIcon” es que, a diferencia de lo queocurre con otras técnicas para leer imáge-nes con Java, ésta no devuelve el controlal programa principal hasta que la imagenno se ha cargado en su totalidad, por loque inmediatamente después de haberllamado al constructor se puede comen-zar el tratamiento de la imagen sin peligrode que se encuentre parcialmente carga-da.En el siguiente paso determinamos losnuevos valores para la imagen escalda.

Para este ejemplo simplemente se va areducir el tamaño de las imágenes a sucuarta parte:int iNewWidth = imageIcon.getIconWidth()

/ 4;

int iNewHeight = imageIcon.getIcon

Height() / 4;

Con estos datos escalar la imagen es tansimple como ejecutar:imageIcon.getImage().getScaledInstance

(iNewWidth, iNewHeight, Image.SCALE_

DEFAULT)

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

tado en un método estático llamado“toBufferedImage”. Las diferencias entre losobjetos “Image” y “BufferedImage” no son elobjeto de este artículo así que no se va aexplicar el código del método “toBufferedImage”, el cual en cualquier caso es bas-tante sencillo de seguir leyendo el códigofuente 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 orechazar las peticiones en función de la IPde origen desde la cual dichas peticiones sehan originado. Esta tarea se puede llevar acabo de forma muy sencilla utilizando unfiltro.En primer lugar se debe modificar el fichero“web.xml” para definir el nuevo filtro:<filter filter-name=”ip-filter”

filter-class=”com.spp.servletfilters.

filter.FSerlvetFiltersIPFilter”/>

<filter-mapping url-pattern=”*”

filter-name=”ip-filter”/>

Obsérvese que esta definición debe situarsela primera de todas y que además el patrónque se aplica en la URL es asterisco (*), esdecir, que se filtrarán todas las peticiones.El código del filtro es bastante sencillo ypuede verse en el listado 8.El método “getRemoteAddr” del objeto“HttpServletRequest” devuelve la direc-ción IP desde la que se realizó la petición.Si esta dirección no se corresponde con lodeseado una de las opciones más sencillasconsiste en emplear el método“sendRedirect” de forma que el navegadorredirige automáticamente a la portada delsite. Evidentemente este mecanismo sepuede hacer todo lo complejo que la apli-cación requiera, de forma que se puedemostrar una página de error, o inclusomostrar todo un site alternativo para esecaso.

Conclusiones

Hemos visto los fundamentos de los filtrosJava con algunos ejemplos sencillos. En elsiguiente capítulo profundizaremos en másejemplos hasta haber visto cuáles son los fil-tros que más comúnmente se usan en lasaplicaciones web actuales.

52

REDES


Documentación de la clase “HttpServletResponseWrapper”, la cual permite procesar lasrespuestas dadas por el servidor de aplicaciones.

LISTADO 8 Código del filtro ip-filter

public void doFilter(ServletRequest request, ServletResponse response,FilterChain next)throws IOException, ServletException{

HttpServletRequest req = (HttpServletRequest)request;HttpServletResponse res = (HttpServletResponse)response;

String sRemoteAddr = req.getRemoteAddr();if (sRemoteAddr!=null && sRemoteAddr.equals(“33.33.33.33”)) {

next.doFilter(request, response);} else {

res.sendRedirect(“http://digital.revistasprofesionales.com”);}

}


Introducción

Mis primeros pasos en el mundo de la programaciónfueron en la facultad. Aún recuerdo mis primerasprácticas (con Borland Pascal, curiosamente) en lasque 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 conmis compañeros de promoción (cómo no, en la can-tina) en las que intentábamos ponernos de acuerdosobre 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, cadauno 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 cruelsonrisa, 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ácticassiguientes, acudíamos al profesor para intentar acla-rar nuestras dudas e intentar acotar mejor el alcancede la aplicación. Recuerdo lo terriblemente difícil queera que el profesor nos definiese claramente qué eralo que él esperaba de nosotros. Nunca tenía tiempopara atendernos y explicarnos claramente los objeti-vos del ejercicio y una y otra vez nos encontrábamosen la entrega con la temida frase: “Está muy bien, peroen realidad lo que os pedía era…”.

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

Los requisitos

Los estudios denominados “post-mortem” de losproyectos de desarrollo de software señalan que laprincipal causa de los retrasos, sobrecostes y/o noaceptación de un desarrollo es una incorrecta ges-tión de los requisitos. Se calcula que las dos terceraspartes de los desarrollos no cubren las expectativasiniciales de los usuarios y, como consecuencia deello, los proyectos son entregados tarde y con sobre-costes. ¿Exageración? ¿Derrotismo? Seguro que másde 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 devida en la que más esfuerzos de normalización seestán llevando. Una incorrecta gestión de requisitospuede llevar a un esfuerzo y coste innecesario.Además, detectar en fase de codificación que unrequisito 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 losrequisitos, 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álogosde requisitos, típicamente basada en documentos(recuerdo los proyectos de una compañía en la quetrabajé en la que los desarrolladores tenían las pan-tallas repletas de Post-Its con los requisitos aimplementar). Lo que se busca en la actualidad esmucho 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 losclientes, con penalizaciones por retrasos comonorma habitual, con clientes (con memoria humanalimitada) que manejan varios proyectos software deforma concurrente, y en un ambiente competitivo

54

Todos sabemos que abordar eldesarrollo de un proyecto desoftware entraña muchosproblemas que pueden derivar enretrasos y sobrecostes. Comorespuesta a las necesidades degestores de proyectos, analistas,programadores etc., Borland ofreceuna completa solución para cadauna de las fases del ciclo de vidade las aplicaciones.

JORDI BORJA (Director de Tecnología de Borland)

DISEÑO

La diferencia entre el éxito y el fracasoLa diferencia entreel éxito y el fracaso



en el que los cambios de los requisitos porparte del cliente para adoptar una ventajacompetitiva 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 aclientes y equipos de desarrollo, solucionesque permitan conocer en todo momento,quién, cómo y por qué ha realizado un cam-bio en un requisito; que permitan conocerqué partes del proyecto se verán afectadaspor ese cambio y, por lo tanto cuál va a serel impacto en tiempo y coste del mismo.Soluciones que permitan garantizar que elimpacto del cambio es aceptado por el clien-te antes de abordarlo. Soluciones que permi-tan de forma automatizada eliminar laambigüedad, trazar con otras partes del pro-yecto (planificación, pruebas, análisis,…) losrequisitos, notificar los cambios inmediata-mente a los miembros del equipo de des-arrollo,… en definitiva, soluciones queimplementen las más modernas recomenda-ciones para una correcta gestión de requisi-tos, como las definidas por el cada vez másaceptado nivel de medición de la calidad delos procesos de desarrollo: CMMI.

El equipo de trabajo

Volviendo a mis tiempos de facultad, recuerdomis primeras prácticas en grupo. Por primeravez nos sentíamos parte de un equipo de des-arrollo. La soledad del programador había sidosuperada, y a partir de ese momento, nuestrasvidas iban a cambiar por completo: si anteshabíamos sido capaces de hacer de forma indi-vidual nuestras aplicaciones, ¿cómo no lo íba-

mos a conseguir ahora que teníamos la opor-tunidad de unificar esfuerzos y conocimientos?Pero pronto descubrimos otro de los principalesproblemas en el mundo actual de desarrollo: lacomunicación entre los miembros del equipo. Outsourcing y Offshoring son dos términoscon los que cada vez estamos más familiari-zados. Los equipos de desarrollo ya no tienenque trabajar en casa del cliente. En la era delas comunicaciones, es cada vez más habitualque los diferentes perfiles del equipo de des-arrollo estén distribuidos geográficamente,creando centros de especialización. Españaha sido reconocida como un país candidato aalbergar factorías de software para las gran-des compañías internacionales. La promo-

ción del software entre diferentes entornoses una necesidad habitual, como lo es podergestionar versiones de la aplicación, peticio-nes de cambio o tareas. De igual forma, elgarantizar la calidad homogénea de una apli-cación desarrollada por personas que nuncaantes han trabajado conjuntamente es unauténtico reto para los equipos de desarrollo.Durante el ciclo de vida de un proyecto, losdiferentes perfiles deben de poder trabajarsobre un repositorio centralizado, al que pue-dan acceder a través de protocolos estándares.Repositorios escalables, que guarden grancantidad de metainformación preferiblementeen bases de datos y que permitan el accesorápido y concurrente de múltiples desarrolla-dores. No hablamos exclusivamente de teneruna herramienta de control de versiones (algoobviamente necesario), sino de tener unaherramienta que permita gestionar releases,que permita promocionar estas releases entrediferentes entornos (desarrollo, integración,pruebas, preproducción, producción,…) y quepermita, por ejemplo, poder crear una vistaevolutiva y otra correctiva de una release.Hablamos de poder asignar peticiones de cam-bio o incidencias a determinados perfiles, y queestos perfiles puedan asociar las modificacionesque realicen en el repositorio a las peticiones decambio, para que sea posible conocer el esfuer-zo asociado a su resolución. De igual forma,buscamos herramientas que permitan podergestionar la petición de cambio e incidencia ensí, a través de un workflow personalizable, en elque se formalicen los estados de la misma y sedefinan roles y responsabilidades.Hablamos también de poder trasladar la planifi-cación de un proyecto a la herramienta de tra-

55

DISEÑOLa diferencia entre el éxito y el fracaso


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

El ciclo de vida para la solución JBuilder.


bajo en grupo, de forma que a partir de una pla-nificación desarrollada, por ejemplo, con MSProject, se generen de forma automática tareasque se asignen a los diferentes miembros delequipo y de esa forma tener en todo momentouna visibilidad y control del estado del proyecto.Buscamos herramientas, en definitiva, quesean flexibles, que permitan ser adaptadas anuestra metodología de desarrollo y serembebidas en nuestras herramientas diariasde trabajo para que su uso no sea intrusivo.Si conseguimos poder gestionar de formaefectiva 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 garantizarel éxito de nuestros desarrollos.Sin embargo, existen dos factores críticosadicionales en los desarrollos actuales desoftware: 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 quereciben. Es habitual encontrarse con pliegos enlos que se exige el cumplimiento de estándaresde calidad, bien sean éstos universales o inter-nos de las compañías. Habitualmente se exigela utilización de un catálogo de patrones dediseño, una nomenclatura y guías de estilo y lacorrecta utilización de las técnicas de laProgramació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, quelas empresas no tengan que depender de unproveedor concreto y puedan asignar diferen-tes fases del desarrollo a diferentes compañías,sin encontrarse con la desagradable sorpresa deque es totalmente imposible que un equipodiferente al que ha realizado el desarrollo origi-nal pueda abordar el mantenimiento y/o evolu-ción del sistema.El principal elemento diferenciador de lascompañías de desarrollo es la calidad queimprimen a sus proyectos. Cuando una com-pañía certifica la calidad de sus entregablesantes de que lo haga el cliente (o unaempresa externa de auditoría), se asegurauna inmejorable imagen de calidad y elmantenimiento de la relación con el cliente,además de evitar penalizaciones o retrasosen las entregas del proyecto.Es por ello, que las mejores empresas de des-arrollo han introducido en sus equiposherramientas que permiten la aplicaciónautomática de patrones de diseño sobre elcódigo existente, la verificación automáticay continua del cumplimiento de nomencla-

turas y guías de estilo y la ejecución demé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 desarrollopuedan configurar sus propios patrones dediseño, su propio conjunto de normas sintácti-cas y sus propias métricas de calidad de diseñoen función del cliente para el que trabajen.Además, las empresas buscan soluciones quepermitan tener siempre sincronizado el códigocon el modelo y que puedan utilizarse de formaembebida 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 laactualidad, los desarrolladores de aplicacio-nes que utilizan Ultraedit o vi son afortuna-damente residuales. Cualquier programadorutiliza un entorno integrado de desarrolloespecializado en la plataforma sobre la que sedesarrolla la aplicación. Cualquier aplicaciónJ2EE, por ejemplo, requiere de la utilización deEJBs, Struts y/o Java Server Faces, WebServices, XML, editar descriptores de desplie-gue,... El uso de estas tecnologías sin la ayudade herramientas especializadas es complejo,propenso a errores y poco productivo. Losentornos de desarrollo actuales permitenaumentar la productividad de los programa-dores. Hay muchas alternativas en el merca-do pero, al mismo tiempo, se busca que elcódigo generado sea portable (o portátil,como correctamente se debería denominar a

las aplicaciones que queremos que puedanser desplegadas sobre diferentes servidoresde aplicaciones) y que no se dependa de unproveedor ni tecnología concreta. Una aplica-ción desarrollada para WebSphere debería depoderse portar a WebLogic o a Oracle AS conun simple proceso de recompilación. Un equi-po de desarrollo debería poder usar la mismaherramienta de trabajo independientementede 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 depruebas (funcionales y de rendimiento). Laspruebas no deben ser una parte aislada del des-arrollo, sino que lo que se busca es que poda-mos ejecutar de forma continuada nuestroconjunto de pruebas y, que éstas puedan rela-cionarse con los requisitos, por ejemplo, paraconocer qué requisitos de la aplicación han sidoprobados 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 unaaplicación bajo una situación de carga. Si noslimitamos a ejecutar pruebas de carga y detiempo de respuesta, nada nos garantiza queuna aplicación que se comporta correctamentedurante la fase de pruebas lo vaya a continuarhaciendo tras varias horas en producción. Si eltiempo de respuesta directamente no es eldeseado, no tenemos información sobre cuál esla raíz del problema. Las herramientas de cajablanca, permiten monitorizar, de forma interna

56

DISEÑO


El ciclo de vida para Visual Studio .NET


a la aplicación, el consumo de CPU por cadamétodo (o línea de código), la gestión internade 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 deforma 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 necesariodisponer de herramientas que, de formaintuitiva, permitan conocer qué ocurre desdeque llega una petición HTTP(S), IIOP, o SOAPal servidor, hasta que se produce la respues-ta, para poder analizar el comportamientointerno de la aplicación.Desde luego, en mis tiempos de universitario,nunca podía llegar a pensar que el éxito deldesarrollo de una aplicación estuviese condi-cionado a factores como los abordados. Quétiempos aquellos en los que nos poníamos aprogramar directamente, sin un análisis previo,sin ningún diseño y ¡sin preocuparnos de lacalidad! ¿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íaaplicando técnicas prehistóricas de desarrollo.La experiencia nos ha demostrado, a clientes ya desarrolladores, que crear un software mejores posible. Tan sólo necesitamos los conoci-mientos y herramientas adecuadas.

El ciclo de vida

En esta introducción, hemos abordado losprincipales retos y problemas de los desarro-llos actuales: la gestión de los requisitos delos proyectos, la necesidad de disponer deherramientas distribuidas de trabajo engrupo, la necesidad de poder verificar la cali-dad de los desarrollos, la necesidad de dis-poner de herramientas que aumenten laproductividad del equipo de desarrollo,manteniendo la portabilidad del código y lanecesidad de disponer de herramientas quepermitan gestionar y ejecutar los planes depruebas, incluyendo la monitorización inter-na y distribuida de las aplicaciones.Como muchos de vosotros sabréis, desdevuestras propias primeras experiencias conel mundo del desarrollo, Borland es y ha sidola empresa líder en herramientas de codifi-cación desde hace más de 20 años. Sinembargo, como respuesta a las necesidadesde los desarrolladores, a vuestras necesida-

des, Borland ha desarrollado una completasolución que cubre cada una de las fases delciclo 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 entrelas propias herramientas de Borland,sino con otras alternativas líderes delmercado.

� Soluciones flexibles, extensibles y perso-nalizables.

� Interfaz visual sencilla e intuitiva.Las herramientas de codificación de Borland(Delphi, JBuilder, C++Builder y MobileStudio) serán posiblemente las herramientasmás conocidas por vosotros. Sin embargo, escurioso descubrir que aún se desconocenmuchísimas de las funcionalidades y venta-jas de estas herramientas. El mercado de lasherramientas de codificación es sin duda elmás competitivo en el que Borland ofrecesus soluciones, sobre todo desde la apariciónde soluciones Open Source. Sin embargo,Borland continúa siendo la solución elegidapor las principales empresas de desarrollo.Mi reto es que vosotros descubráis por qué.Together Technologies es una solución demodelado y verificación de calidad del soft-ware que ofrece múltiples ventajas respectoa las soluciones clásicas de análisis y diseñoOrientado a Objetos. A través de sus edicio-nes especiales para entornos de desarrolloJ2EE, 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 grupoque mayor crecimiento ha experimentado enlos últimos dos años y es la principal opción

que consideran las empresas con equiposdistribuidos de desarrollo, que requieren deuna única solución para gestionar sus ver-siones, peticiones de cambio y tareas.Caliber Requirement Manager es una solucióndiseñada específicamente para la gestión delos requisitos, teniendo en cuenta todas lasrecomendaciones y necesidades de nuestrosgrandes clientes y de estándares como CMMI.OptimizeIT Suite y ServerTrace permitenmonitorizar 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 herramientasespecializadas en cada fase del ciclo de vida.Pero la solución de ciclo de vida de Borlandes mucho más que un conjunto de herra-mientas especializadas. El uso integrado yconjunto de la solución permite que cadaperfil de desarrollo pueda acceder a todas lasfases del ciclo de vida desde una únicaherramienta, independientemente de si seutilizan todas las herramientas de Borland uotras alternativas del mercado.La pregunta que os lanzo es: ¿sois “sólo pro-gramadores”, o leéis una revista que es “sólopara programadores”? Estoy seguro que vues-tra respuesta es la segunda. Únicamente sepuede ser un buen programador si se tienenen cuenta las problemáticas anteriores.Es por ello, que, con el objetivo de queconozcáis mejor estas problemáticas, yconozcáis una de las alternativas para solu-cionarlas, en los próximos números Borlandy Sólo Programadores publicarán artículosespecíficos sobre cada una de las fases delciclo de vida, analizando las problemáticasasociadas, y cómo las soluciones de Borlandpermiten resolverlas. ¡Os espero!

57

DISEÑOLa diferencia entre el éxito y el fracaso


El ciclo de vida para la solución Eclipse.


Introducción

Aunque no es el caso más común, muchasveces nos encontramos con que nuestras apli-caciones deben ser capaces de funcionar enmás de un sistema operativo. Esto ocurre conmayor asiduidad en aplicaciones para entornosUnix debido a que existen diferencias entre lasdiferentes versiones de Unix y Linux que hacenque una aplicación programada para uno deestos sistemas no siempre pueda usarse enotro. También puede darse el caso en que nece-sitemos que nuestra aplicación funcione nosó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” desdeun sistema a otro puede tener un coste y com-plejidad muy elevados.La respuesta más inmediata al problema deuna aplicación multi-plataforma suele ser eluso de lenguajes como Java que nos permitenescribir el código una vez y ejecutarlo en cual-quier plataforma deseada. También .NET (y elproyecto MONO) está ofreciendo esta “porta-bilidad”, sin embargo el problema de estoslenguajes interpretados es que imponen anuestra aplicación una penalización de veloci-dad que algunas aplicaciones críticas no pue-

den permitirse y es en estos casos cuandodebemos recurrir a algún lenguaje que nospermita generar código nativo. Lenguajescomo C++ no permiten, a diferencia de Java,crear código compilado independiente de laplataforma pero sí permiten, si se es cuidado-so y se parte de un buen diseño, crear códigofuente que pueda ser compilado en cualquierplataforma. En esta serie de artículos apren-deremos cómo diseñar e implementar códigoC++ que sea independiente del sistema ope-rativo. Para ello usaremos una librería decódigo abierto llamada ACE (AdaptiveCommunication Environment) que no sólonos abstrae de las particularidades de cadasistema sino que además nos provee unaimplementación de patrones de diseño parasistemas concurrentes o de red.

Diferencias entre plataformas

El estándar C++ especifica ciertas condicionesque debe cumplir un compilador y un conjuntode funciones que deben estar accesibles al pro-gramador. Desafortunadamente este estándarno incluye nada acerca de la longitud exacta delas variables o funciones de librería estándarpara 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 deproblemas relacionados con las diferencias a nivelde sistema operativo.

Diferencias de arquitecturaEstas son las diferencias en las longitudes de losdistintos tipos de datos entre plataformas o elorden en que se guardan los números en memo-ria. En arquitecturas Intel por ejemplo, un enterode dos bytes se guarda en memoria con sus bytesinvertidos mientras que en otras plataformasesto no es así.

58

Con este artículo iniciamos uncurso en el que aprenderemos adiseñar e implementar código C++independiente del sistemaoperativo. Esto lo conseguiremosgracias a la librería de códigoabierto ACE, que no sólo nosabstrae de las particularidades decada plataforma sino que ademásnos ofrece una implementación depatrones de diseño para sistemasconcurrentes o de red.

GABRIEL DOS SANTOS DÁVILA

DISEÑO

Diseño multiplataformapara aplicaciones C++ (I)Diseño multiplataformapara aplicaciones C++ (I)


ACE es la libreríamás usada para

crear código C++portable


Diferencias en el sistema operativoÉstas son quizás las más evidentes. Laslibrerías para crear threads en Windows soncompletamente diferentes de aquellas dis-ponibles en sistemas Unix. En este apartadopodemos mencionar como “no portables” alas siguientes funcionalidades:� Listar contenido de directorios, crear

directorios y otras tareas del sistema dearchivos.

� Cargar librerías dinámicas (DLL enWindows o SO en Linux) dentro de laaplicación y ejecutar funciones dentrode éstas.

� Creación y manipulación de conexionesde 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 aescribir 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ásevidente. Pero también implica que debe-remos invertir tiempo en aprender cómofunciona cada conjunto de funciones decada sistema operativo.

Diferencias en las librerías disponiblesNo todas las funciones disponibles al pro-gramador en una plataforma lo estarán enotras. Hay funciones que no son estándar ypor lo tanto no existen en algunas platafor-mas como es el caso de la función “itoa()”que no está disponible en ciertas versionesde Unix a pesar de ser una función de uso

muy habitual. Para evitar problemas de estetipo, es muy importante informarse acercade si una función es o no estándar antes decomenzar a utilizarla. Si no hay alternativa auna función que no es estándar lo más con-veniente es encapsular el acceso a ella en unsolo lugar de la aplicación para que luegosea fácil de cambiar si se debe portar a unaplataforma en la que la función no existe.

Diseño

El problema de la portabilidad se agravasi una aplicación no fue inicialmente

concebida para ejecutarse en varias pla-taformas y más tarde durante su ciclo devida surge este requerimiento. En lafigura 1 podemos ver un esquema de laarquitectura de una aplicación que acce-de de manera directa a las funciones dela plataforma. Como vemos, esta aplica-ción posee una gran cantidad de puntosde contacto con el sistema operativo, loscuales deberán ser modificados en sutotalidad al cambiar a otra plataforma.En general es muy complicado portaruna aplicación desarrollada sólo con unsistema operativo en mente. Es por elloque, de existir alguna posibilidad de queen el presente o futuro nuestra aplica-ción deba funcionar con otro sistema,deberemos plantearnos un diseño quetenga en cuenta este escenario. En cual-quier diseño, cuando algún elementopuede variar, se agrega un nivel de indi-rección adicional que hace que el mismoquede aislado del resto. De esta manera,si cambia, no afectará de manera algunaa los demás componentes. En nuestrocaso será la librería ACE la que nos ofrez-ca este nivel adicional de indirección yen lugar de invocar de manera directa alas funciones del sistema operativo,invocaremos funciones de ACE que a suvez harán llamadas a las funcionescorrespondientes del sistema operativoen el que estemos trabajando lo cual nosdará la independencia de la plataforma.En la figura 2 podemos ver el esquemade la arquitectura propuesta en el cual lainterfaz entre ACE y nuestra aplicaciónse mantiene constante sin importar la

59

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


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

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


plataforma subyacente y la interfaz entreACE y los distintos sistemas operativoses gestionada por ACE.La desventaja de esta aproximación radicaen que tendremos invocaciones a ACE des-perdigadas por toda nuestra aplicación y sien algún momento deseamos cambiar ACEpor otra librería similar, será muy difícilhacerlo. Para evitar esto se puede imple-mentar el patrón de diseño Abstract Factoryel cual agrega un nivel más de indireccióncreando un conjunto de clases abstractasque representen la funcionalidad del siste-ma operativo y luego una familia de clasesconcretas que implementan esa funcionali-dad usando ACE. Durante la ejecución de laaplicación el Abstract Factory creará las ins-tancias de las clases concretas que utilizanACE. En la figura 3 podemos ver los compo-nentes de esta arquitectura. Este diseño nospermite separar la creación de las clases delpunto donde se utilizan y de esta manerapodremos, si es necesario, usar una libreríadistinta de ACE sólo con crear una nuevafamilia de clases concretas. Esta es laestructura más flexible a la que podemosrecurrir pero también la más compleja y noen todos los casos será necesaria. A la horade diseñar software no sólo es importantesaber dónde agregar niveles de indirecciónsino también saber cuándo dejar de hacerlo.Para más información sobre este patrón sepuede recurrir al libro “Patrones de Diseño”de Eric Gamma y otros autores.

ACE

ACE es una librería gratuita que nos faci-litará enormemente la portabilidad denuestra aplicación. El código fuente deACE ha sido compilado en multitud de sis-temas operativos con lo cual su correctouso 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 necesitaremosdescargar de Internet la librería y si bienexisten algunas versiones precompiladasveremos cómo hacer para descargar lasfuentes y realizar la compilación a partirde ellas. En la página http://deuce.doc.wustl.edu/Download.html encontrare-mos enlaces para descargar los fuentesde ACE. De este sitio descargaremos“ACE-5.4.zip” o “ACE-5.4.tar.gz” segúnnos resulte más cómodo. Es importantedescargar una versión release final y nouna versión beta. Para facilitar al lectorel acceso a este material, se han incluidoen el CD-ROM ambos archivos.

Principios de diseño de ACELa librería ACE fue pensada y construidateniendo en cuenta los conceptos más avan-zados de patrones de diseño de software.Entre los principales principios de diseñoempleados podemos destacar:� Usar Wrapper Façades para forzar la

verificación estricta de tipos de dato porel compilador. La idea es no exponerestructuras internas a la implementa-ción como ocurre en C. La principal téc-nica usada es crear clases C++ quehagan que el compilador verifique lostipos usados.

� Simplificar el código a escribir por elprogramador para los casos más comu-nes de uso de la librería. La forma delograrlo es creando métodos que agru-pen varias llamadas a funciones quesean generalmente usadas en conjuntoy proveer valores predeterminados quesean los más usados para todos aque-llos parámetros que sea posible.

� Usar jerarquías de clases para crear undiseño fácil de entender, usar y exten-der.

� Ocultar diferencias entre plataformassiempre que sea posible. En el caso en

60

DISEÑO


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

Figura 4. Página de descarga de ACE.


que todas las plataformas soportanuna funcionalidad dada, se compila elcódigo perteneciente a una u otra. Sihay alguna plataforma en particularque no tiene alguna funcionalidadespecífica se intenta emular por códi-go propio de ACE siempre que seaposible.

� Permitir compilar con la funcionali-dad mínima necesaria. Supongamosuna plataforma que no soporte thre-ads. Si ACE, que implementa threads,se intenta compilar con los threadsactivos la compilación fallaría por noestar soportados por la plataforma.Si alguien desea crear una aplicaciónque no requiere threads se veríaimpedido de hacerlo a causa de quesu plataforma no soporta una fun-cionalidad que él ni siquiera necesita.Esto es demasiado restrictivo y poreso ACE permite activar y desactivaropciones de compilación de maneraque se pueda compilar en una plata-forma que soporte las capacidadesmínimas requeridas por cada aplica-ción.

� Optimizar el código para obtener lamáxima eficiencia posible.

Compilar ACE con Visual C++Descargar el fichero “ACE-5.4.zip” y extraer sucontenido en un directorio de nuestro disco.Dentro de este directorio se creará automáti-camente uno de nombre “ACE_Wrappers” alcual llamaremos “ACE_ROOT” durante el restode la serie.Para comenzar, en el directorio “ACE_ROOT\ace”, crearemos un fichero llamado“config.h” que contenga:#define ACE_AS_STATIC_LIBS

#define ACE_HAS_STANDARD_CPP_LIBRARY 1

#include “ace/config-win32.h”

ACE provee archivos de proyecto paraVisual Studio 6.0 y .NET. En“ACE_ROOT\ace”, abriremos “ace.sln” paracompilar con Visual Studio.NET. ACE puedecompilarse como una librería dinámica oestática y en nuestro caso lo haremos deforma estática para que en las aplicacionesque no sea necesario distribuir la libreríadinámica junto con los ejecutables. En Visual Studio, en el menú “Proyecto” ->“Propiedades”:� En la sección “General”, en “Tipo de

Configuración” elegir “biblioteca estáti-ca (.lib)”.

� En la sección “C/C++” -> “Generaciónde Código”, seleccionar las librerías

estáticas de depuración multi-hilo parala configuración “Debug” y libreríasestáticas mult-hilo para la configura-ción “Release”. Si por error selecciona-mos las librerías dinámicas (DLL) en estaopción, obtendremos errores bastanteextraños a la hora de compilar nuestrasaplicaciones que utilicen ACE.

Hacer clic en “Aceptar”, activar la configura-ción “Debug” de la solución y presionar F7para compilar ACE. Si todo va bien, estodejará como resultado el fichero “ACE.lib” enel directorio “ACE_ROOT\lib”.Es posible que al compilar la solucióncompleta los resultados sean tener unproyecto (ACE) compilado con éxito yotros dos (RMCast y TMCast) que generanun mensaje de error. El proyecto de ACEpara Visual Studio incluye estas dos libre-rías adicionales que dependen de ACE yque no usaremos. Sus proyectos estánconfigurados de manera predeterminadapara que su configuración Debug intentecompilar con la versión Debug de ACE enuna librería llamada “ACEd.lib” pero enalgunas distribuciones de ACE, al compilaren modo Debug, la librería generada sellama “ACE.lib” en lugar de “ACEd.lib” y deahí el error. No es necesario preocuparsepor esto pues no afecta para nada a nues-tras prácticas.

Usar ACE desde una aplicación conVisual C++Para crear una aplicación que use la libreríaACE ir al menú “Archivo” -> “Nuevo” ->“Proyecto”, seleccionar “Proyectos VisualC++”, elegir la opción “Proyecto de ConsolaWin 32” (no confundir con aplicación deconsole .NET), entrar el nombre “main” parael proyecto, presionar “Aceptar” y “Finalizar”.Esto nos creará un nuevo esqueleto de pro-grama que modificaremos un poco:� Reemplazaremos todo el contenido del

archivo donde se encuentra definida lafunción “_tmain” por el contenido dellistado 1.

� En la ficha de propiedades del proyectoy para todas las configuraciones:� En la entrada “C/C++” -> “General”,

añadir la ruta completa del directo-

rio “ACE_ROOT” en la lista de direc-torios de búsqueda de inclusión(include).

� En “C++” -> “Cabeceras precompila-das”, no usar cabeceras precompiladas.

� En “C/C++” -> “Generación de códi-go”, cambiar las librería de un sólohilo de ejecución por las libreríasmulti-hilo.

� En la opción “Vinculador” ->“Entrada”, añadir la ruta completa delfichero “ACE.lib” como dependenciaadicional.

� En “C/C++” -> “Pre procesador”, aña-dir la definición del preprocesador“ACE_AS_STATIC_LIB”.

Es importante que todos los cambios en laspropiedades del proyecto se hagan tanto enla configuración de Debug como en la deRelease. Ya tenemos listo el esqueleto queutilizaremos como punto de partida paratodas nuestras aplicaciones por lo cual esconveniente hacer una copia de resguardoantes de seguir. A continuación agregare-mos las siguientes líneas al principio delarchivo “main.cpp”:#include <ace/Dirent_Selector.h>

ACE_Dirent_Selector dir;

Por último ejecutaremos el programa presio-nando F5. Si compila y ejecuta sin errores, yatenemos enlazada nuestra aplicación con lalibrería ACE.

Compilar ACE con g++ en LinuxDebemos descargar el archivo “ACE-5.4.tar.gz”, copiarlo en un directorio y a con-tinuación ejecutar los siguientes pasos:$tar -xvzf ACE-5.4.tar.gz

$cd ACE_wrappers/

$export ACE_ROOT=$PWD

$cd ace/

$ln -s config-linux.h config.h

$cd $ACE_ROOT/include/makeinclude

$ln -s platform_linux.GNU platform_

macros.GNU

$cd $ACE_ROOT/ace

$make debug=0 static_libs_only=1

61



LISTADO 1 main.cpp

//main.cpp#include <ace/config.h>#include <ace/OS.h>#include <string>

int main(int argc, char* argv[]){

return 0;}


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 LinuxComo primer paso, crearemos el archivo“main.cpp” con el contenido del listado 1. Eneste punto haremos una copia de resguardode “main.cpp” que luego usaremos comopunto 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;

Para compilar y crear el ejecutable de laaplicació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 elarchivo ejecutable “prueba” que está enla-zado estáticamente con la librería ACE.

Incompatibilidad entre plataformasEl punto de incompatibilidad más impor-tante a nivel de hardware es el de lostamaños de los tipos de datos. Esto esporque el estándar C++ no define estric-

tamente los tipos de datos en cuanto a sulongitud sino en cuanto a qué es lo quepueden contener. ACE define un conjuntode macros que representan tipos de datosde manera portable y otros que permitenobtener información de la plataformaactual. En el cuadro “Definiciones de tiposde datos” podemos ver una lista de éstasdefiniciones y una explicación de cadauna de ellas.

Incompatibilidades del sistema operativo

ACE provee un conjunto de clases llamadasWrapper Façades cuya función consiste enproveer un abstracción genérica sobre elsistema operativo. Para ello provee clasesque encapsulan todos los aspectos quecambian de un sistema operativo a otroque hemos enumerado al comienzo de esteartículo.

Conexiones de red TCP/IPUna conexión de red TCP/IP se crea desdeun programa por medio de la creación deelementos llamados sockets. Un socketes como un descriptor de archivo peroque permite transferir datos por una redTCP/IP como Internet. La lógica sobrecómo crear y utilizar un socket no varíaentre sistemas operativos pero si losnombres de las funciones específicaspara hacerlo. Para demostrar el uso delas conexiones por socket con ACE crea-remos un servidor echo (reenvía al clien-te todo lo que recibe) y un cliente que loutilice.Sin embargo antes, estúdiese el listado 2. Enél, se muestra cómo abrir un socket clientetanto en Unix (arriba) como en Windows(abajo).Dicho código simplemente muestra lamanera de establecer una conexión porsockets en Unix y en Windows, pero nohace uso de la conexión y tampoco haceningún control de errores. Como puedeverse en el listado 2, el código es bastantediferente.La solución para crear una aplicaciónque pueda compilarse en Linux yWindows podría ser en este caso usarcompilación condicional para incluir enel ejecutable el código correspondiente acada plataforma pero esta solución sehace más complicada a medida que eltamaño de la aplicación y los sistemasoperativos a soportar aumentan. Unamejor solución es utilizar ACE y escribircódigo portable sólo una vez con el

62

DISEÑO


Definiciones de tipos de datosACE_INT16, ACE_UINT16 Enteros de 16 bits, con y sin signo.

ACE_INT32, ACE_UINT32 Enteros de 32 bits, con y sin signo.

ACE_UINT64 Entero de 64 bits sin signo. Puede emularlo aúnen plataformas de 32 bits.

ACE_SIZEOF_CHAR Longitud en bytes de un char.

ACE_SIZEOF_SHORT Longitud en bytes de un short.

ACE_SIZEOF_INT Longitud en bytes de un int.

ACE_SIZEOF_LONG Longitud en bytes de un long.

ACE_SIZEOF_LONG_LONG Longitud en bytes de un long long int.

ACE_SIZEOF_VOID_P Longitud en bytes de un puntero.

ACE_SIZEOF_FLOAT Longitud en bytes de un float.

ACE_SIZEOF_DOUBLE Longitud en bytes de un double.

ACE_SIZEOF_LONG_DOUBLE Longitud en bytes de un long double.

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

LISTADO 2 Sockets en Unix y en Windows

//VERSIÓN UNIXstruct 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 WINDOWSnRet = 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);


agregado de que además es mucho másfácil de programar. El código ACE equi-valente a los ejemplos anteriores es elsiguiente:ACE_INET_Addr srvr (80, ACE_LOCALHOST);

ACE_SOCK_Connector connector;

ACE_SOCK_Stream peer;

connector.connect(peer, srvr);

Este código puede compilarse sin pro-blemas en cualquier plataforma en laque ACE esté disponible y como vemoses mucho más simple. En el listado 3podemos ver todo el código necesariopara implementar el cliente echo conACE. Las conexiones por sockets en ACEse efectúan utilizando un patrónConnector/Acceptor en el cual el accep-tor espera peticiones y el connector lasinicia. El objeto connector de clase“ACE_SOCK_Connector” encapsula unsocket cliente y el objeto “peer” de clase“ACE_SOCK_Stream” representa el canalde datos que éste abre hacia el otroextremo de la conexión a través del cuales posible tanto leer como escribir. Lafunción miembro “send_n()” se bloqueahasta que consigue enviar la cantidad debytes indicada como segundo paráme-tro. A continuación, la función “recv()”lee los datos disponibles en el buffer.También hay funciones que permitenbloquear o especificar un tiempo límitede espera para leer datos.Una vez que tenemos listo el cliente creare-mos el código del servidor. En el listado 4

podemos ver la implementación completadel código del servidor echo.Se crea un objeto de tipo“ACE_SOCK_Acceptor” al cual le indica-remos el puerto donde debe escuchar yllamaremos al método “accept()”, que

bloquea la ejecución hasta que llega unapetición de conexión de un cliente. Enese momento la función “accept()”devuelve el control y se procesa la peti-ción. Al igual que en el cliente, se usa unobjeto de clase “ACE_SOCK_Stream” paraleer y escribir en el socket. Todo el códi-go de gestión de peticiones se encuentradentro de un while para que continúeesperando más peticiones una vez quetermina con una. En un caso real un ser-vidor de sockets crea un nuevo threadpara gestionar cada petición y el proce-samiento de cada una procede de mane-ra independiente pero para mantener elcódigo simple, este ejemplo usa un sólothread.

Conclusiones

En esta primera entrega hemos hecho unapresentación de la librería ACE y aprendidoa incluirla en nuestros programas. Tambiénpudimos apreciar la potencia de sus clasesa la hora de simplificar la creación de soc-kets. En las próximas entregas veremos lamanera de realizar tareas como acceder alsistema de archivos o crear aplicacionesmulti-thread.

63



LISTADO 3 Cliente echo usando sockets

#include <ace/config.h>#include <ace/OS.h>#include <ace/INET_Addr.h>#include <ace/SOCK_Stream.h>#include “ace/SOCK_Connector.h”#include <iostream>#include <string>

int main(int argc, char* argv[]) {if (argc<=1) {

std::cout << “Uso: main mensaje” << std::endl;return -1;

}ACE_INET_Addr srvr (7, ACE_LOCALHOST);ACE_SOCK_Connector connector;ACE_SOCK_Stream peer;if (-1 == connector.connect (peer, srvr)){

std::cout << “Error al conectar al servidor” << std::endl;return -1;

}peer.send_n(argv[1], sizeof(argv[1]));char buf[1000];int bc = peer.recv (buf, sizeof(buf));std::cout << std::string(buf,bc) << std::endl;peer.close ();return 0;

}

LISTADO 4 Servidor echo usando sockets

#include <ace/config.h>#include <ace/OS.h>#include <ace/INET_Addr.h>#include <ace/SOCK_Stream.h>#include <ace/SOCK_Acceptor.h>#include <iostream>#include <string>

int main(int argc, char* argv[]){

ACE_INET_Addr port_to_listen(7);ACE_SOCK_Acceptor acceptor;if (acceptor.open (port_to_listen, 1) == -1) {

std::cout << “Error al crear el socket server” << std::endl;

return -1;}ACE_SOCK_Stream peer;ACE_INET_Addr peer_addr;while (true) {

if (acceptor.accept (peer, &peer_addr) == -1) {std::cout << “Error al aceptar una conexión” << std::endl;return -1;

}else {

char buffer[4096];ssize_t bytes_received;while ((bytes_received = peer.recv(buffer, sizeof(buffer))) > 0){

std::cout << std::string(buffer,bytes_received) << std::endl;peer.send_n (buffer, bytes_received);

}peer.close ();

}}return (0);

}


Estoy trabajando con XML/XSLT en elnavegador. Hasta el momento todas laspá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 formade hacer que sean compatibles?

Existen algunas diferencias notables entrelos motores de XML/XSLT de IE y Firefoxpero sí que se pueden crear páginas com-patibles de forma que el comportamientoen ambos navegadores sea prácticamenteel mismo, si bien es necesario complicar unpoco el código Javascript.En primer lugar se requiere un método paradiferenciar entre un navegador y el otro. Haymuchísimas formas de llevar a cabo esta tarea.En Internet se pueden encontrar numerososejemplos, algunos muy diferentes entre sí. Unode los más sencillos es el que se presenta acontinuació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 elscript deba complicarse para detectar máscasos (otros navegadores, otras pequeñasdiferencias entre versiones, etc.) pero parala mayor parte de los casos el código ante-rior es más que suficiente.

Una vez establecidas las variables globales quepermiten diferenciar entre navegadores sepuede empezar a desarrollar el resto del códi-go. La función “InitXMLEngine” es la responsa-ble de inicializar los objetos que se empleanpara trabajar con XML/XSLT (véase el listado 1).Si el navegador es Firefox se crean los objetos“XMLHttpRequest”, “XSLTProcessor”, “XMLSeriali-zer” y “DOMParser”, utilizando directamente losconstructores del mismo nombre. El primero sirvepara realizar llamadas HTTP (también puedeemplearse para leer ficheros XML/XSLT locales,aunque no sea estrictamente una llamada HTTP),obteniendo así un documento XML. El segundo,

“XSLTProcessor”, se emplea para las transforma-ciones con XSLT. El objeto “XMLSerializer” permiteconvertir un documento XML en una cadena detexto. Finalmente, “DOMParser” se emplea parahacer justo lo contrario del objeto anterior, es decir,para obtener un documento XML a partir de unacadena de texto.En el caso de que el navegador sea IE los obje-tos se llaman y obtienen de forma diferenteaunque básicamente sirven para las mismastareas que se han descrito anteriormente. La siguiente función se denomina “LoadData”y como su propio nombre indica se usará paracargar los datos XML (véase el listado 2).

64

DUDAS

Preguntas y respuestasPreguntas y respuestasADOLFO ALADRO GARCÍA


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);}

}

NÚMEROS ANTERIORES

BOLETÍN DE PEDIDORellene o fotocopie el cupón y envielo a REVISTAS PROFESIONALES, S.L.

(Revista SÓLO PROGRAMADORES) C/ Valentín Beato, 42 - 3ª Planta - 28037 MADRIDTel.: 91 304 87 64 - Fax: 91 327 13 03 - www.revistasprofesionales.com - [email protected]

Deseo me envíen los número/s: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .NOMBRE Y APELLIDOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .EDAD.................TELÉFONO................................DOMICILIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C.P.:CIUDAD . . . . . . . . . . . . . . . . . .PROVINCIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

FORMAS DE PAGO� Giro Postal a nombre de REVISTAS PROFESIONALES, S.L. � Talon Bancario a nombre de REVISTAS PROFESIONALES S.L. � 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.

Las interfaces del futuro conXAML, finalizamos nuestrovideojuego con J2ME, integra-ción de Python con Java, XMLe IA, XQuery, Sistemas deGestión de Contenidos, XSL-FOavanzado y la quinta entregadel coleccionable ASP.NET.2 CD-ROMs incluidos.

121 - Enero 2005Introducción a la programaciónde juegos con J2ME, aplicacionesweb con Python, herramientasOpen Source para J2EE, persis-tencia con Hibernate, creaciónde servicios web con Java, diseñode interfaces Swing, profundiza-mos en XSL-FO y la cuarta entre-ga del coleccionable ASP.NET.1 CD-ROM incluido.

120 - Diciembre 2004

Persistencia de datos en J2ME,aplicaciones de escritorio sobre.NET, programación gráfica conPython, Firebird sometido a aná-lisis, optimización de serviciosweb en .NET, diseño de interfacesSwing, conversión de XML a PDFcon XSL-FO y la tercera entregadel coleccionable ASP.NET.1 CD-ROM incluido.

119 - Noviembre 2004

.NET para programadores C++,el modelo transaccional de losEJB, creación de un cliente demensajerí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.

117 - Septiembre 2004

Programación sobre Pocket PC yTablet PC, introducción aPython, creación de un servidorde mensajería instantánea, pro-gramación de servicios web en.NET, patrones J2EE, diseño deinterfaces Swing y la segundaentrega del coleccionableASP.NET.1 CD-ROM incluido.

118 - Octubre 2004

Si te falta algún número de latemporada 04/05, ahora tienesla oportunidad de conseguirlo

Precio Oferta descuentoPrecio 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%


El método “open”, en el caso de que el navega-dor sea Firefox, recibe tres parámetros. El prime-ro es el método correspondiente a la peticiónHTTP. Normalmente éste será GET. El segundoparámetro es la URL donde se encuentra el ori-gen de datos XML. Por último el tercer paráme-tro indica si la carga del documento XML serásíncrona, es decir, si la función esperará a queefectivamente el documento se haya terminadode cargar por completo, o asíncrona, lo que sig-nifica que el código continuará ejecutándosemientras la carga se produce en paralelo. Elmétodo “send” realiza la petición. El parámetroque recibe es “null” porque se trata de una peti-ción GET y por lo tanto no hay datos que man-dar al servidor. Finalmente, cuando la carga haconcluido, la propiedad “responseXML” tiene elobjeto correspondiente al origen de datos XML.El caso de IE es muy similar, aunque en vez dehacer una llamada HTTP se utilizará directa-mente el objeto “DOMDocument”. La propiedad“async” establece si la operación será síncronao asíncrona. El método “load” es el responsableúltimo de obtener el documento y cargarlo.La función “LoadStylesheet” se empleará paracargar las hojas de estilo XSLT. Éstas son tam-bién documentos XML así que el proceso essimilar al descrito para la función “LoadData”(véase el listado 3).La última de las funciones se llama“TransformData” y es la que se emplea paratransformar el origen de datos XML con lahoja de estilo XSLT. El resultado es una cadenade texto que contiene un fragmento de códi-go HTML que posteriormente puede incluirsedentro de la página (véase el listado 4).Así, por ejemplo, si en la página estuvieradefinido el siguiente elemento:<div id="content"></div>

el método “onload” podría ejecutar elsiguiente código:window.onload = Init;

function Init()

{

InitXMLEngine();

LoadData();

LoadStylesheet();

var oContent = document.getElement

ById("content");

if (oContent!=null) {

oContent.innerHTML = TransformData();

}

}

66

DUDAS


LISTADO 3 Cargando la hoja de estilo XSLT

function LoadStylesheet(){

try {if (ns6) {

oXMLHttpRequest.open("GET", "source.xslt", false);oXMLHttpRequest.send(null);oDOMDocumentStylesheet =

oDOMParser.parseFromString(oXMLHttpRequest.responseText, "text/xml");oXSLProcessor.importStylesheet(oDOMDocumentStylesheet);

} else {oXMLHttpRequest = new ActiveXObject("MSXML2.XMLHTTP");oXMLHttpRequest.open("GET", "source.xslt", false);oXMLHttpRequest.send(null);

oDOMDocumentStylesheet.async = false;oDOMDocumentStylesheet.loadXML(oXMLHttpRequest.responseText);oXSLTemplate.stylesheet = oDOMDocumentStylesheet;oXSLProcessor = oXSLTemplate.createProcessor();

}} catch (e) {

alert("LoadStylesheet error: " + e.description);}

}

LISTADO 4 El proceso de transformación

function TransformData(){

var output = null;try {

if (ns6) {oDOMDocumentOutput = oXSLProcessor.transformToDocument(oDOMDocumentData);output = oXMLSerializer.serializeToString(oDOMDocumentOutput);

} else {oXSLProcessor.input = oDOMDocumentData;oXSLProcessor.transform();output = oXSLProcessor.output;

}} catch (e) {

alert("TransformData error: " + e.description);}return output;

}

En http://www.mozilla.org/xmlextras/xmldataislands/ se muestra cómo emplearXML Data Islands que es otra de las formas de trabajar con XML/XSLT en elnavegador, y que también puede emplearse con IE.