Page 1

ID O

GR IN AT CL IS U

CD

LA PRIMERA REVISTA DE PROGRAMACIÓN EN CASTELLANO

Precio: 6 € (España) (IVA incluido)

AÑO XI. 2.ª ÉPOCA

• Nº 128 •

ACTUALIDAD Tecnologías Grid para la computación distribuida DISPOSITIVOS MÓVILES Creación de un sistema de distribución de Midlets según el modelo OTA y basado en IIS Creamos, paso a paso, nuestro primer servicio web con

UNA PUBLICACIÓN DE:

REVISTAS PROFESIONALES S.L.

MIDDLEWARE Desarrollos avanzados con Struts REDES Integración de elementos Java y C++ en ColdFusion MX 7 CANAL PANDA ¿Todos para uno? ¡Uno para todos!

El GPS como “medio de comunicación”

00128

Noticias, javaHispano y Opinión, Libros, Preguntas y Respuestas

8

413042 303299


EDITORIAL Número 128 Ed i t a : R EVISTAS PROFESIONALES S.L. solop@revistasprofesionales.com C/ Valentin Beato 42,3ª.28037 - Madrid. http://www.revistasprofesionales.com http://digital.revistasprofesionales.com E d i to r Agustín Buelta •••••••••••••••••••••••••••••••••• Co o r d i n a c i ó n T é c n i c a - R e d a c c i ó n Carlos Laparra •••••••••••••••••••••••••••••••••• Maquetación Alfonso Sabán Mejías •••••••••••••••••••••••••••••••••• As e s o r í a d e Pu b l i c i d a d Felipe Ribagorda Tel.:91 304 87 64 D e l e g a c i ó n e n B a r ce l o n a C/ Rocafort,241/243,5º 1ª Mariano Sánchez Tel.:93 322 12 38 •••••••••••••••••••••••••••••••••• S u s c ri pc i o n e s Tel:91 304 87 64 Fax:91 327 13 03 ••••••••••••••••••••••••••••••••••• I m p re s i ó n Ideas de Impresión ••••••••••••••••••••••••••••••••••• D i s t ri b u c i ó n Motorpress Ibérica

LAS PRUEBAS, CONDICIÓN NECESARIA PARA EL ÉXITO DEL SOFTWARE La industria del software ha buscado, desde siempre, mejorar el proceso de desarrollo de los sistemas de información. Desde que surgió el paradigma de la Orientación a Objetos, se han sucedido importantísimos avances por lo que a las notaciones de modelado se refiere. También los entornos de desarrollo han sido objeto de una intensa investigación, lo que nos conduce a afirmar que actualmente disponemos de grandes herramientas para la codificación. Además, a día de hoy también se reconoce abiertamente la importancia de aplicar una correcta estrategia para la obtención de requisitos. Sin embargo, es imposible asegurar la calidad del software sin realizar sobre él las debidas pruebas, tanto unitarias como funcionales. No vamos a justificar aquí la necesidad de someter al software a un modelo de pruebas para garantizar la calidad del desarrollo. Pero sí queremos hacer notar que en raras ocasiones se dedica el tiempo necesario para la elaboración de un plan de pruebas exhaustivo. Seguramente, en un afán de reducir los tiempos de desarrollo y cumplir los plazos de entrega, se tiende a olvidar esta última fase en cualquier metodología. Hemos creído oportuno destacar, en la portada de este número, el artículo que precisamente tiene como objetivo presentar los fundamentos de las pruebas funcionales y de estrés (en un futuro abordaremos las pruebas unitarias), sobre todo centradas en aplicaciones de carácter distribuido. Gracias a este tipo de pruebas, conseguiremos diagnosticar el comportamiento de nuestras aplicaciones y servicios web en el entorno de producción.

SUMARIO ACTUALIDAD 12

D I S T R I B U C I O N E N M E X I CO DIMSA - C/ Mariano Escobedo,218 Col.Anáhuac.11320 México,D.F.

Tecnologías Grid o de computación distribuida

DISPOSITIVOS MÓVILES

D I S T R I BUCION EN ARG E N T I N A Capital Federal:Distrimachisa Interior:York Agencysa - Tlf:(5411) 433 150 51

20

Creación de un sistema de distribución de Midlets (y II)

26

El GPS como “medio de comunicación”

R E P R E S E N TANTE EN MEXICO Angel Bosch - angelbosch@infosel.net.mx Distribución,números atrasados y suscripciones C/ Renacimiento,180.Col.San Juan Tlihuaca. Azcapotzalco.02400 México D.F. •••••••••••••••••••••••••••••••••• La revista Sólo Programadores no tiene por qué estar de acuerdo con las opiniones escritas por sus colaboradores en los artículos firmados. El editor prohibe expresamente la reproducción total o parcial de los contenidos de la revista sin su autorización escrita. Depósito legal:M-26827-1994 P R I N T E D I N S PA I N COPYRIGHT 30-06-2005 P.V.P.6,00 Euros Precio en Canarias,Ceuta y Melilla: 6,15 Euros

MIDDLEWARE

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

36

Struts práctico (y III)

REDES 50

Pruebas funcionales y de rendimiento con JMeter

58

Creación de aplicaciones web con ColdFusion MX 7 (y III)

Y ADEMÁS. . . 04

Noticias

08

javaHispano: DVDs, JDeveloper 10g, novedades en Dolphin y más

10

Canal Panda: ¿Todos para uno? ¡Uno para todos!

46

Contenido del CD-ROM: Visual Web Developer Express Edition Beta 2

64

Preguntas y respuestas

66

Libros: Paralelismo en computadores y C++


NOTICIAS

MICROSOFT

Microsoft presenta las novedades en su solución de gestión de relaciones con clientes Microsoft ha adelantado, en la reciente edición europea de Microsoft TechEd 2005, algunas de las novedades de su solución de gestión de relaciones con clientes, Microsoft CRM 3.0, la suite que proporcionará funcionalidades de marketing, ventas y servicio al cliente. Microsoft CRM 3.0 se ha diseñado para dar respuesta a los tres retos fundamentales que determinan el éxito o el fracaso de la mayoría de las iniciativas CRM en una empresa: la adopción por parte del usuario, la adecuación al negocio y el coste total de propiedad. Microsoft CRM 3.0 se centra en tres aspectos principales:  Ofrece al usuario una experiencia cómoda y familiar con un entorno muy parecido al de las soluciones Microsoft Office o Microsoft Outlook. Además Microsoft CRM 3.0 tiene en cuenta los requerimientos de movilidad, ofreciendo un cliente mejorado para Microsoft Windows Mobile.  Ofrece un exhaustivo módulo de automatización de marketing para la gestión de listas, campañas y recursos de marketing, cerrando el



ciclo con la gestión de respuestas. Esta nueva versión también incluye un nuevo módulo de planificación de servicio, que gestiona automáticamente peticiones de planificación complejas que requieren personal, recursos y habilidades específicos. Amplía las opciones de configuración, personalización e integración para la arquitectura orientada a servicios (SOA) de Microsoft CRM.

Microsoft presenta las novedades en su solución de gestión Nuevo licenciamiento basado en suscripción para implementaciones en modo hosting

Con el lanzamiento de Microsoft CRM 3.0, la compañía presenta un nuevo licenciamiento basado en suscripción para clientes que prefieran una oferta en modo hosting, promoviendo el compromiso de Microsoft de proporcionar un CRM flexible y asequible tanto para los modelos onsite como para implementaciones en modo hosting. Dado que ambos modelos utilizan el mismo código, los clientes pueden cambiar su modelo de implementación preferido de un modelo hosted a otro onsite y viceversa, según cambien sus necesidades de negocio y de TI.

Disponibilidad del producto Microsoft CRM se lanzó a principios de 2002 y actualmente ayuda a más de 4.000 empresas de todo el mundo a ofrecer mejoras cuantificables en sus procesos de negocio relativos a la relación con sus clientes. Microsoft CRM 3.0 estará disponible para los clientes autorizados a utilizar versiones anteriores de Microsoft CRM en el cuarto trimestre de 2005 y, la disponibilidad general, está prevista para el primer trimestre de 2006. Los clientes que han comprado algún módulo de la edición Professional de las versiones anteriores de Microsoft CRM y tienen un acuerdo activo Software Assurance, tendrán derecho a todos los módulos disponibles de la próxima versión; otras vías de actualización de licencias para otros productos Microsoft CRM se anunciarán a finales de año. Es posible ampliar esta información en http://www.microsoft.com/ spain/BusinessSolutions.

NCR TERADATA

Repsol YPF implanta una solución Datawarehouse que conducirá sus nuevas acciones de marketing Teradata, una división de NCR Corporation, ha sido seleccionada por Repsol YPF para implantar un sistema de información analítico que dará soporte a la gestión de los puntos de venta pertenecientes a la red de estaciones de servicio de gestión propia en España, agrupadas bajos las marcas Repsol, Campsa y Petronor. La solución Datawarehouse adquirida incluye el potente motor de base de datos NCR Teradata, el Modelo Lógico de Datos para la industria de Distribución (LDMR), así como servicios profesionales y de mantenimiento. El objetivo principal que persigue Repsol YPF al implantar este Datawarehouse es obtener valor de negocio a partir del análisis en detalle de la información de ventas atendiendo a múltiples factores:

SOLO PROGRAMADORES nº 128

4

productos, carburantes, servicios, venta cruzada, categorías, márgenes, fechas, formatos, geografía, proveedores y stocks. El modelo de datos de Teradata carga y estructura información sobre los “tickets de compra” y la relaciona con todas las áreas implicadas del negocio, facilitando un acceso inmediato y una toma de decisiones rápida y precisa sobre aspectos de precios, surtidos, promociones, perfiles de compras, etc. El núcleo de la solución contempla extensiones para cubrir en el futuro otros aspectos del negocio tales como la gestión de stocks, análisis de proveedores, logística, márgenes, parámetros financieros, así como la evolución para el desarrollo de herramientas CRM (Gestión de la Relación con Clientes). La implantación por parte de Repsol YPF de un sistema Datawarehouse demuestra cómo un correcto análisis de los datos puede conducir a una buena estrategia comercial.

http://digital.revistasprofesionales.com


NOTICIAS

SUN MICROSYSTEMS e IBM

Sun e IBM amplían su acuerdo sobre tecnología Java En un movimiento que renueva su compromiso para colaborar en el desarrollo de la plataforma Java, IBM y Sun Microsystems anunciaron el pasado mes que han extendido diez años su acuerdo para el desarrollo de la tecnología Java, con el fin de ofrecer estabilidad a largo plazo a los más de 4,5 millones de desarrolladores de la comunidad Java. En virtud del acuerdo, que se extiende hasta 2016, IBM continuará licenciando

y utilizando las tecnologías Java de Sun, incluido: Java Platform, Enterprise Edition (Java EE), Java Platform, Standard Edition (Java SE), Java Platform, Micro Edition (Java ME) y Java Card en todos sus productos de software, incluida su cartera de servicios web y middleware. Sun e IBM también continuarán avanzando y mejorando el desarrollo de tecnologías Java a través de la cooperación en Java Community Process (JCP). Además, IBM también ampliará su papel para convertirse en un partner de canal para el desarrollo de productos compatibles con Java. Por otra parte, y en respuesta a las demandas de los clientes, IBM ampliará el soporte a DB2, Rational, Tivoli y WebSphere para incluir el sistema operativo Solaris 10 sobre plataformas x64 basadas en AMD Opteron.

BUSINESS OBJECTS

Business Objects amplía su oferta de productos Business Objects, proveedor de soluciones de Business Intelligence (BI), ha anunciado la disponibilidad de BusinessObjects XI Built for Operational BI. Esta nueva solución amplía la plataforma BusinessObjects XI y permite multiplicar la utilidad de BI para un mayor número de personas dentro de la organización. BusinessObjects XI Built for Operational BI ofrece dos nuevos componentes integrados: BusinessObjects Process Tracker y BusinessObjects Process Analysis. La combinación de estos dos componentes proporciona el eslabón crítico entre la gestión del rendimiento (Performance Management) y la gestión de operaciones (Business Operations), ya que permite alinear BI con los procesos de negocio relacionados con la toma de decisiones. BusinessObjects XI Built for Operational BI nos ofrece:  Analíticas integradas que proporcionan acceso a la información a muchos más usuarios finales dentro de la organización.  Gestión de rendimiento, relacionando el rendimiento empresarial con las operaciones en tiempo real.  Entorno de trabajo que permite guiar a los usuarios a través de los procesos de toma de decisiones. La plataforma BusinessObjects XI está basada en una arquitectura moderna orientada a servicios (SOA), y es la única plataforma de BI de fiabilidad certificada para Microsoft Windows Server 2003 Datacenter. Además, la decidida apuesta por los estándares del sector, entre ellos los relativos a procesos de negocio, y el completo repertorio de servicios web, permiten integrar BI con otras aplicaciones de una manera fácil y económica. Este tipo de software, pensado para facilitar las prácticas de

PROINNOVA

El Parlamento Europeo rechaza la propuesta de directiva sobre patentes de software El pleno del Parlamento Europeo rechazó, el pasado mes de julio, la propuesta de directiva sobre patentes de software apoyada por la Comisión Europea y el Consejo Europeo. El Parlamento Europeo ya pidió hace unos meses que la propuesta de directiva fuera retirada y, en su caso, vuelta a plantear en términos más cercanos a la postura del Parlamento. Con la votación celebrada el pasado mes, el Parlamento se reafirma

http://digital.revistasprofesionales.com

BI, y en definitiva orientado a dar soporte en el proceso de toma de decisiones, goza de una gran implantación en la industria. Prueba de ellos es que los principales entornos de desarrollo comerciales para las plataformas Java y .NET, producidos por compañías como BEA, Borland, IBM o Microsoft, incluyen las herramientas de Business Objects. El lector podrá encontrar más información sobre BusinessObjects XI Built for Operational BI en la dirección http://www.businessobjects.com/ operationalbi/.

en la posición de no aceptar nuevas propuestas que amplíen el ámbito de lo patentable. De hecho, la decisión del Parlamento ha sido histórica: nunca antes se había rechazado una directiva en este momento del trámite y con un apoyo tan grande. Ahora la situación continua regida por el Convenio Europeo de Patentes, que en su artículo 52 especifica que los programas de ordenador no están en el ámbito de lo patentable.

5

SOLO PROGRAMADORES nº 128


NOTICIAS

TELELOGIC

Telelogic perfecciona su suite de herramientas ALM Telelogic ha dado a conocer la disponibilidad de las nuevas versiones de sus herramientas Telelogic DOORS (para la gestión de requisitos), Telelogic SYNERGY (para la gestión de cambio y configuración) y Telelogic TAU G2 (para el desarrollo liderado por modelos). Esta nueva suite de componentes integrados, conforma la apuesta de soluciones de gestión de ciclo de vida (ALM) de Telelogic. Las novedades incorporadas a la última versión de DOORS pueden resumirse en un mayor soporte de idiomas (ofreciendo un corrector ortográfico para 15 idiomas), un proceso de gestión de cambios más flexible e integrado con la gestión de cambios de todo el ciclo de vida y un seguimiento completo de los cambios para establecer un registro de dependencias históricas. Por su parte, SYNERGY incorpora una nueva interfaz con el objetivo de facilitar la asimilación de la herramienta por parte del usuario, lo que supuestamente debe reforzar la productividad del usuario y del equipo.

SUN MICROSYSTEMS y DYGRA FILMS

“El sueño de una noche de San Juan” se apoya en Java y GNU/Linux La productora española Dygra Films y Sun Microsystems han firmado un acuerdo de colaboración que permite a la primera potenciar espectacularmente sus punteras capacidades de animación por ordenador. Con diecisiete años de experiencia en el mundo de la comunicación y la producción audiovisual, Dygra Films es la principal productora española de películas de animación por ordenador. Su primera producción “El bosque animado” (galardonada con dos Goya, además de obtener numerosos premios internacionales y haber sido preseleccionada para el Oscar 2002 a la categoría de Mejor Película de Animación) fue el mayor éxito de taquilla de la historia española de películas de animación. Tras el éxito de este proyecto, Dygra Films decidió embarcarse en la producción de un nuevo largometraje de animación 3D, “El sueño de una noche de San Juan”, una adaptación libre de la obra “Sueño de una noche de verano”, de William Shakespeare. Esta producción, que puede verse actualmente en los cines de 65 países, representa una clara

SOLO PROGRAMADORES nº 128

6

TAU G2 ofrece soporte a UML 2.0.

Y por último, TAU G2 ofrece la posibilidad de diseñar pruebas y ejecutarlas en los modelos, obteniendo los informes en HTML, y una mayor integración con otros productos de Telelogic, como por ejemplo SYNERGY. apuesta por Java, GNU/Linux y los estándares abiertos. Tras estudiar las necesidades de Dygra Films, Sun y Arcade Consultores (su socio de valor añadido en este proyecto) iniciaron un proceso de evolución de las granjas de servidores de renderización de que disponía Dygra Films tanto a nivel de hardware como de software, con el objetivo de optimizar al máximo las capacidades de producción de la compañía. Para ello, se migró de la plataforma de servidores existente a otra basada en servidores Sun sobre AMD Opteron y sistema operativo Debian GNU/Linux. Esta evolución se pudo realizar gracias a que se desarrolló adhoc una aplicación software basada en Java para la gestión homogénea del proceso de renderización de las imágenes. En una segunda fase, se realizaron pruebas de rendimiento con Solaris 10 para optimizar el proceso de renderización. Para la implantación del proyecto, en concreto, se han utilizado 31 servidores Sun Fire V20z con doble procesador AMD Opteron, cuatro servidores Sun Fire V240, Sun StorEdge 3510 FC Arrays, Sun StorEdge L100 Tape Library. Estos cambios han potenciado espectacularmente las punteras capacidades de animación por ordenador de Dygra Films, prueba de ello es que “El Espíritu del Bosque” es la nueva película que se encuentra en producción (secuela del primer film de Dygra) y que se estrenará en 2006.

http://digital.revistasprofesionales.com


NOTICIAS

BEA SYSTEMS

Lanzamiento de la nueva familia de productos BEA AquaLogic para el desarrollo SOA BEA Systems ha presentado recientemente BEA AquaLogic, una nueva familia de productos diseñada para ofrece una plataforma abierta e independiente que sirva para desplegar, gestionar y manejar una completa Arquitectura Orientada a Servicios (SOA) en entornos de computación heterogéneos, incluyendo Java, .NET u otros sistemas heredados. BEA AquaLogic permite que los servicios de software sean producidos una única vez y utilizados desde cualquier punto, ayudando de este modo a los usuarios a transformar sus activos de TI “congelados” en activos líquidos, para responder de forma más rápida a las nuevas necesidades de los negocios modernos. Hoy en día los entornos de TI están comprometidos con múltiples tecnologías y plataformas de aplicaciones que no permiten compartir información si no es a través de la programación e integración de software. Incluso ahora que las nuevas estrategias de TI incluyen y adaptan la Arquitectura Orientada a Servicios, el escenario empresarial más común contempla una infraestructura distribuida y combinada que hace muy complicada su integración y gestión. Desde BEA se afirma que con BEA AquaLogic es posible construir servicios sobre plataformas heterogéneas para ser descubiertos, asegurados, gestionados y unidos a través de potentes herramientas de composición y gestión. La familia de productos BEA AquaLogic está diseñada para ser la más amplia línea de producto de infraestructura de servicios y la primera suite de producto construida para el campo de SOA.

Las tres principales tecnologías para el desarrollo de SOA De los resultados de una encuesta realizada por BEA Systems entre más de 800 desarrolladores europeos, se desprende el echo de que los servicios web, la partición de mensajes y el bus de servicios son las tecnologías más útiles para el desarrollo, el despliegue y la gestión de Arquitecturas Orientadas a Servicios. Cerca del 90% de los encuestados citaron los servicios web como el factor más importante en el desarrollo de SOA. Sin embargo, la principal preocupación de los desarrolladores encuestados son, en primer lugar los estándares de servicios web, seguidos por la percepción de complejidad que tienen acerca de un despliegue basado en SOA. En este sentido, cerca de la mitad de los desarrolladores encuestados (40%) destacaron que el bus de servicios (service bus) puede reducir dicha complejidad y simplificar la integración. En este sentido, aclararemos que un bus de servicios (ESB) es una tecnología emergente para la integración de aplicaciones. Es la espina dorsal que permite integrar aplicaciones dispares facilitando el flujo de información a través de la empresa. De acuerdo con la encuesta de BEA, más de la mitad de los encuestados (51%) actualmente invierten la mayor parte de sus esfuerzos de integración en la capa de aplicaciones lo que subraya la actual dificultad para la integración de grupos de aplicaciones propietarias o de software a través de silos de aplicaciones verticales.

BEAWorld, a partir del mes que viene BEA Systems anunció el pasado mes las fechas y lugares de celebración de su evento BEAWorld, que tendrá lugar en seis ciudades diferentes. Se espera que asistan desarrolladores de software, arquitectos de negocio y de TI, directores de TI y partners de BEA, además de miles de participantes que se registraran a través de la web, donde podrán encontrar más información sobre los productos de BEA. Las ciudades donde se celebrará BEA World serán Santa Clara, California (del 27 al 29 de septiembre); Londres (11 y 12 de octubre); Paris (13 y 14 de octubre); Praga (18 y 19 de octubre); Tokio (25 y 26 de octubre); y Pekín (7 y 8 de diciembre).

TRANSCEND INFORMATION

Módulos de memoria para satisfacer las necesidades más exigentes Transcend Information ha anunciado recientemente el lanzamiento de sus nuevos módulos de memoria non-stacked DDR400 de 1 GB con chip FBGA de elevada velocidad y capacidad para ordenadores portátiles. Estos módulos de memoria están especialmente diseñados para ordenadores notebook de alta calidad. Además, su velocidad permite ofrecer un magnífico rendimiento para los usuarios de juegos y aplicaciones gráficas. Estos nuevos módulos de memoria, de 200 pines y 1 GB de capaci-

http://digital.revistasprofesionales.com

dad, son sometidos a exámenes rigurosos antes de ser puestos a disposición de los usuarios, y además cuentan con garantía de por vida.

7

SOLO PROGRAMADORES nº 128


JAVAHISPANO

Actualidad Java de la mano de javaHispano Desaparece el "2" en los nombres de las ediciones de la plataforma El departamento de marketing de Sun Microsystems nos ha vuelto sorprender. Después del cambio en la política de versiones que hizo que el tan esperado "J2SE 1.5" pasase a llamarse "J2SE 5.0", el equipo de marketing de Sun ha decidido eliminar el "2" en los nombres de las ediciones de la plataforma Java, eliminando también el segundo dígito de las versiones y enfatizando la palabra "Java". De esta forma, los nombres oficiales de las nuevas versiones, junto con sus acrónimos, pasarán a ser:   

Java Platform, Standard Edition (Java SE) Java Platform, Enterprise Edition (Java EE) Java Platform, Micro Edition (Java ME) Estos cambios no serán retroactivos, por tanto las versiones anteriores de la plataforma conservarán su nombre. Mustang, la siguiente versión del JDK, será el primero en verse afectado, pasando a llamarse "Java SE 6".

Confirmado: Java estará presente en la próxima generación de DVDs Hace unos meses anunciábamos que Sun se había convertido en miembro de la Blu-ray Disk Association, un consorcio de empresas liderado por Sony y Philips que promueve la adopción de la tecnología Blu-ray Disk como sustituto de los actuales DVDs. El propósito de Sun era incorporar la tecnología Java como herramienta para la construcción de contenido interactivo en los DVD Blu-ray. Durante la pasada JavaOne se ha confirmado que Java formará parte del estándar DVD Blu-ray y, en primicia mundial, se mostró las posibilidades de este nuevo estándar a través de la película "I Robot". Para los desarrolladores Java esto abre las puertas a un nuevo mercado relacionado con el entretenimiento y el contenido multimedia. Para el usuario de a pie significará que, en breve, Java dejará de ser algo que sólo tiene su teléfono móvil y pasará a estar presente también en su reproductor de DVDs, ya que éstos incorporarán una máquina virtual para ejecutar el contenido Java de los DVDs.

Apache Gerónimo pasa el test de compatibilidad de J2EE Apache Geronimo, el servidor de aplicaciones de Apache Software Foundation, ha pasado la primera fase del test de compatibilidad de J2EE 1.4.1. Dain Sundstrom, uno de los commiters, ha declarado que el proceso de certificación, que duró 22 meses, fue largo y duro y que no le deseaba a nadie tener que volver a pasar por él, así que se recomienda utilizar su base de código. Dain también comentó que a partir de ahora el objetivo será ofrecer herramientas y facilitar a los desarrolladores el uso de Apache Geronimo. La inminencia de esta noticia seguramente ha influido en la reciente decisión de Sun para liberar Sun Java System Application Server Platform Edition 9.0, el estándar de compatibilidad para los servidores de aplicaciones J2EE. La licencia bajo la cual se distribuye es CDDL (Common Development and Distribution Licence), licencia diseñada por Sun y bajo la cual ya liberó Solaris 10.

SOLO PROGRAMADORES nº 128

8

http://digital.revistasprofesionales.com


JAVAHISPANO

javaHispano

Novedades para Java SE 7, Dolphin Sun ha hecho públicas dos novedades bastante destacables para Dolphin, la versión 7 del JDK. La primera, el integrar el tratamiento de XML en el propio lenguaje, permitiendo códigos como el que aparece a continuación:

OPINIÓN

Trabajar en el extranjero

void addReviewed (Feature aFeature, user, ...) { aFeature.add(<reviewed><who>{user}</who></reviewed>); }

Esta idea no es nueva; existen prototipos de lenguajes que integran XML pero Java será, probablemente, el primer lenguaje de uso habitual en aplicaciones reales en integrarlo. La última novedad, aunque no es completamente seguro que esté lista a tiempo para incorporarse a Dolphin, es la sustitución de los ficheros JAR por un nuevo mecanismo para empaquetar aplicaciones Java. El JSR 277, Java Module System, busca definir este nuevo formato, que será modular, incluirá información sobre dependencias y versiones, y permitirá el descubrimiento, la carga y el chequeo de la integridad de recursos en tiempo de ejecución.

JDeveloper 10g pasará a ser gratuito Oracle anunció durante la JavaOne que su entorno de desarrollo JDeveloper 10g pasará a ser gratuito. Este IDE incluye herramientas de modelado UML, herramientas para la creación y orquestación de servicios web y para la gestión de flujos de negocio. Además, como es de esperar, posee una excelente integración con el resto de las herramientas de la compañía. Con este movimiento, en el que sin duda la creciente expansión de Netbeans y Eclipse ha jugado un papel fundamental, Oracle espera incrementar el interés de los desarrolladores en su familia de productos "Oracle Fusion Middleware", a la cual pertenece el IDE aunque el uso del entorno de desarrollo no fuerza a emplear el resto de los productos.

Irse una temporadita a trabajar al extranjero es una de esas cosas que seguramente a más de uno se le ha pasado por la cabeza. Acto seguido, empiezan a acumularse dudas y miedos a partes iguales, así que acabamos dejándolo para "otro momento". Hace nueve meses yo no lo dejé más y me vine para Londres, desde entonces trabajo, vivo y maldigo el tiempo de esta ciudad. Realmente sólo puedo hablar por mí, pero la experiencia está resultando muy enriquecedora tanto a nivel profesional como personal. Como programador me he encontrado con un trabajo en el que se respetan mucho las horas de entrada y salida (sí, ¡existe vida después del trabajo!), que se valora y reconoce tanto tu trabajo como tu conocimiento, y además, se te paga de acuerdo a eso. Voy a repetirlo... Se te valora, respeta y paga como es debido. Quizás algunos conocéis a alguien que vino y tuvo una mala experiencia, pero en mi caso, y es el de todos los compañeros desarrolladores con los que me he cruzado durante mi estancia aquí, hemos coincidido que es un país ideal para trabajar. ¿Entonces, donde están los problemas? básicamente en el desconocimiento local de pequeñas cosas que se hacen grandes: cómo funcionan los bancos, cómo tratar con la burocracia, y pelearse con los 4.000 acentos diferentes que hay en este país. Si aspiras a llevar una vida digna como desarrollador, si quieres sentirte bien programando, si quieres un sueldo acorde a tus conocimientos, y no lo consigues en tu país... ¡Vente! Iván Pedrazas (ivan.pedrazas@sword-uk.com), Sword UK

Sobre el autor Abraham Otero (abraham.otero@javahispano.org) es responsable de calidad y miembro de la junta de javaHispano. http://digital.revistasprofesionales.com

9

SOLO PROGRAMADORES nº 127 128


CANAL PANDA

¿Todos para uno? ¡Uno para todos! FERNANDO DE LA CUADRA

Las capacidades de integración que a día de hoy incorporan las soluciones software son un activo importante, por lo tanto renunciar a ello nos conduce a trabajar como se hacía 15 años atrás. Hace ya unos años, las soluciones ofimáticas que estaban en la mayor parte de los PC no eran suites como las que hoy en día podemos disfrutar. Cada aplicación estaba desarrollada por un fabricante distinto, y en muy pocos casos estaba prevista la exportación de los datos entre aplicaciones tan distintas. Por ejemplo, una tarea realmente compleja era hacer un mailing (de los de meter en un sobre, lo del e-mailing hace 15 años era, simplemente, futurista) con datos de dBase III, en un documento de WordPerfect 4.2 que incorporara un gráfico hecho con Harvard Graphics 3.0 en función de unos datos que estaban en una hoja de cálculo de Lotus 1-23 3.0. Todos aquellos que hayan hecho (o simplemente intentado hacer) esta tarea lo recordarán con una relativa angustia.

Panda Software ofrece soluciones de seguridad contra todo tipo de malware con sistemas de detección inteligente.

SOLO PROGRAMADORES nº 128

10

Hoy en día la integración de los datos es mucho más sencilla, existen las suites ofimáticas que manejan datos comunes con una facilidad asombrosa. Da igual que los datos estén en un formato distinto, los sistemas operativos facilitan el compartirlos de una manera muy sencilla. Incluso pueden ser datos remotos, que no va a tener ningún problema. Pero sin embargo, parece que hayamos dado un paso atrás en la integración de aplicaciones. Toda la unificación de la que disponemos en las suites se convierte en una dispersión absoluta en el caso de la seguridad contra código malicioso. En muchísimas ocasiones podemos encontrar que un usuario dispone de una herramienta contra el spyware, otra para eliminar adware, otra que evita la entrada de virus, otra que bloquea troyanos, a lo que hay que sumarle el firewall personal. Al final, pasa lo mismo que al principio de estas líneas: problemas de operatividad entre distinto software que, en el fondo, debería servir para lo mismo: ayudar al usuario. Tener varias aplicaciones de seguridad implica que el usuario debe aprender a manejar varias aplicaciones para un problema común, el código malicioso. El tiempo de aprendizaje puede que sea pequeño (cada vez se tiende a hacer las aplicaciones con interfaces más amigables), pero tener que alternar entre distintas aplicaciones para tareas que se pueden realizar en un sólo programa, va en contra de cualquier postulado de ergonomía. Añadido al problema ergonómico de usar distintas aplicaciones (y en muchos casos entrando en conflicto) es que se piensa que una aplicación específica va a llevar a cabo una tarea mucho mejor. Nada más lejos de la realidad: el problema no está en que un determinado software haga mejor una tarea, sino que hace mal las demás. Y si para compensar una carencia instalamos software adicional, el consumo de recursos en el sistema se dispara de manera alarmante. Evidentemente, puede argumentarse que el uso de este tipo de herramientas diferenciadas no es más que un simple problema económico. Generalmente un simple eliminador de troyanos suele ser gratis, al menos durante un cierto periodo de tiempo. Desde un

http://digital.revistasprofesionales.com


CANAL PANDA

¿Todos para uno? ¡Uno para todos! punto de vista únicamente económico no cabe duda de que es una buena solución, pero ¿estamos confiando la seguridad de nuestra empresa a una herramienta freeware? ¿Quién va a responder ante un problema de detección en ella? Estamos hablando de seguridad, y un buen servicio es una parte primordial a la hora de elegir una herramienta de protección. Además, a la hora de asegurar un sistema, la mejor aplicación es la que es capaz de hacer que la menor cantidad de código maligno entre en el sistema, independientemente del tipo de código maligno que se trate. Por lo general, si una aplicación no es capaz de detectar, por ejemplo, troyanos, pero sin embargo detecta adware, no quiere decir que sea muy buena protegiendo contra adware. Simplemente significa que no es capaz de detectar troyanos. Y por consiguiente, ni virus, ni spyware, ni gusanos, ni ningún otro tipo de malware. Sus desarrolladores no tienen capacidad para eliminar otros tipos de código malicioso, ni disponen de un centro de investigación del tamaño adecuado ni con recursos suficientes como para proteger de verdad. Pensemos por un momento cómo se detecta, por ejemplo, una variante de spyware. Basta con tener un sistema de monitorización de la entrada de información en un sistema, es decir, basta con vigilar el contenido del tráfico TCP/IP de un sistema. Ahora bien, el correo electrónico también “viaja” por TCP/IP, pero con un formato completamente distinto a como lo hace un control ActiveX típico del spyware. Si una aplicación quiere detectar spyware y gusanos de correo electrónico sus desarrolladores deberán saber cómo analizar el correo electrónico (puesto que ya saben buscar spyware) y además, saber qué gusanos deben detectarse, y tener una velocidad de reacción suficiente para evitar que sus usuarios se infecten. Evidentemente, para eso hace falta una capacidad que muy pocos desarrolladores tienen. Si una empresa dispone de capacidad de detectar virus, gusanos, troyanos, spyware, adware, bots, spam, hoaxes y todo aquel nombre que se le quiera dar al malware, dispone también de capacidad para detectar cualquier otro tipo de

Ranking de los personajes famosos más utilizados para difundir virus en Internet Panda Software detectó, el pasado mes, el envío masivo de correos electrónicos contaminados con un nuevo malware, utilizando como pretexto una falsa noticia de intento de suicidio de Michael Jackson. Este no es más que un nuevo capítulo de la utilización de la popularidad de determinados personajes como una técnica de Ingeniería Social para aumentar la capacidad de propagación de los virus. En ciertas ocasiones, la estrategia usada para la difusión de este malware es muy compleja: el correo, que ha sido distribuido manualmente en forma de spam por Internet, contiene un link a una página web que, por medio de un malware, aprovecha una vulnerabilidad del explorador para, a su vez, introducir una aplicación que será la que finalmente dé acceso para instalar en el ordenador del usuario el troyano. No acaba aquí la cadena, ya que éste, una vez distribuido en los ordenadores, descarga otra variante del propio virus, que será quien lleve a cabo las acciones maliciosas sobre el ordenador afectado. Pese a que no es habitual el uso de técnicas coordinadas tan complejas para instalar malware en el equipo, sí que es recurrente el uso de los nombres de personajes famosos para la distribución de correos que, o bien contienen el malware adjunto en el propio correo (a menudo camuflado como una imagen), o bien contienen una URL donde se accede a dicho malware. La tabla adjunta muestra los nombres de famosos más utilizados para este tipo de prácticas. Para evitar la entrada de éstos u otros Posicion Nombre códigos maliciosos, Panda Software 1 Britney Spears recomienda mantener actualizado el software antivirus. Para ayudar al mayor 2 Bill Gates número de usuarios a analizar y/o 3 Jennifer Lopez desinfectar puntualmente sus equipos, 4 Shakira Panda Software ofrece gratuitamente 5 Osama Bin Laden la solución antimalware online Panda ActiveScan (http:// www.pandasoftwa6 Michael Jackson re.es), que ahora también detecta 7 Bill Clinton spyware. Además, los webmasters 8 Anna Kournikova pueden ofrecer este mismo servicio a 9 Paris Hilton los visitantes de sus páginas web mediante la inclusión de un código HTML 10 Pamela Anderson que pueden obtener gratuitamente (http://www.pandasoftware.es/partners/webmasters/). código. Basta con conocerlo y aplicar los sistemas de detección adecuados. ¡Y en el tiempo adecuado! Reaccionar tres días después de la aparición de un código malicioso no les sirve de nada a los usuarios. Como colofón a todo esto, hay que tener en cuenta además que el tiempo de reacción es vital para parar un nuevo código malicioso. Si hay una aplicación que roba datos de tarjetas de crédito, el tiempo de reacción es muy, muy pequeño: en cuanto el usuario lo reciba. Más tarde es un desastre, puesto que los datos ya han sido robados. En la actualidad, es necesario no sólo un sistema que responda plenamente ante amenazas de cualquier tipo, sino que incluso los comportamientos peligrosos deben

ser detectados sin que un laboratorio o centro de respuestas, por muy rápido que sea, necesite analizarlo. La tecnología ha llegado ya a este punto, y cualquier usuario de un ordenador (bien sea un usuario doméstico o el administrador de una red con cientos o miles de ordenadores) no debe volver al pasado, ya existen soluciones de seguridad contra TODO TIPO DE MALWARE, con sistemas de detección respaldados por GRANDES DEPARTAMENTOS DE INVESTIGACIÓN y con sistemas de DETECCIÓN INTELIGENTE. ¿Está confiando su protección a aplicaciones shareware enfocadas a una sola amenaza? Entonces, su servidor (o simplemente su PC) último modelo está trabajando como se hacía 15 años atrás.

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

http://digital.revistasprofesionales.com

11

SOLO PROGRAMADORES nº 128


ACTUALIDAD

Tecnologías Grid o de computación distribuida NICOLÁS VELÁSQUEZ ESPINEL

La globalización de la red ha dado el paso al siguiente nivel de la evolución: las tecnologías Grid, con la que todos pasaremos a formar parte de una misma entidad, compartiendo los recursos de memoria y CPU de nuestras máquinas, creando así una supermáquina virtual que tendrá la capacidad de llevar a cabo cálculos que de otra forma llevarían cientos si no miles de años. Seamos testigos de la revolución que se acerca. Introducción

La informática distribuida marcará un antes y un después en nuestra forma de percibir La Red

SOLO PROGRAMADORES nº 128

12

La red hoy conocida como Internet tiene muchas características que la hacen parecerse a un ente vivo que evoluciona, que palpita de información y que interactúa con su entorno (o que sirve de medio para interactuar). Internet crece y evoluciona a la par que lo hacen sus usuarios, demandando nuevos servicios y especificaciones que la mejoran a cada día que pasa y la llevan a crecer, hasta ahora, de forma relativamente controlada. Todo ello orientado a las redes, a la virtualización de los recursos, la gestión del almacenamiento y la movilidad. Este crecimiento también ha traído otras consecuencias. Una de las primeras pasa por el agotamiento de direcciones IP en la red según el estándar aceptado como pilar del sistema, el IPv4. Para ello, se está orientando Internet hacia lo que ya se ha bautizado como “Internet 2”, basada en el protocolo de comunicaciones IPv6, que proveerá la red de la amplitud necesaria para que quepan en su interior todas las direcciones necesarias. Todo ello acompañado de unos controles de paquetes más adecuados a los tiempos que corren que permitirán pasar a un estatus superior en todo lo relacionado con transacciones electrónicas o seguridad en las comunicaciones.

Aspecto de la consola del Grid Engine N1 de Solaris.

Pero estas no son las únicas iniciativas que se están llevando a cabo para acondicionar la red a las nuevas necesidades que se han ido gestando en los últimos tiempos. El otro punto de mira que promete ser, según muchos gurús de Internet, el que marque un antes y un después en nuestra forma de percibir la red para aprovecharnos de toda su potencia se denomina informática distribuida o, lo que muchos conocen ya como tecnologías Grid. La próxima generación de infraestructuras TI.

Informática distribuida Los expertos coinciden en la afirmación de que las redes Grid (rejilla) o de informática distribuida transformarán el mundo de las redes de la misma forma que en su momento Internet cambió el modo en que las personas y empresas se comunicaban y compartían la información. La idea nació en los ámbitos científicos y universitarios (como ya es algo habitual) y, sus máximos exponentes son proyectos relacionados con la biotecnología y el análisis de datos. Esta nueva técnica surge del nuevo paradigma de computación distribuida propuesto por Ian Foster y Carl Kesselman a mediados de los 90. La tecnología de computación distribuida está basada en un tipo de conectividad de redes que se diferencia de las convencionales en la posibilidad http://digital.revistasprofesionales.com


ACTUALIDAD

Tecnologías Grid o de computación distribuida

La tecnología Grid permitirá aprovechar recursos alojados en cualquier rincón del planeta con acceso a La Red.

de aprovechar los ciclos de proceso que no usan los diferentes dispositivos informáticos para llevar a cabo operaciones que requieren de una gran potencia de procesamiento e involucran una ingente cantidad de información. Esto se traduce en una política de aprovechamiento de los recursos no utilizados (o infrautilizados) de sistemas distribuidos en una red. La virtualización de los recursos permite asignar procesadores y memoria a las diferentes tareas que realiza el servidor para así asegurar el rendimiento adecuado de las funciones más críticas del sistema. Para ser más claro y en pocas palabras, las redes Grid intentan conectar varios sistemas heterogéneos de forma que los recursos e información almacenada en los mismos puedan ser compartidos. Se trata así de optimizar los recursos al ponerlos en común para cargas de trabajo de gran capacidad y facilitar la colaboración de empresas con socios comerciales y proveedores, así como la participación de diferentes organizaciones dispersas geográficamente en un mismo proyecto. Grid se diferencia de los sistemas cliente-servidor y otras tecnologías actuales (CORBA, EJB o .NET), en que está orientada a los recursos computacionales y no a la información, la seguridad no está en un segundo plano y la comunicación es asíncrona. Imaginemos por ejemplo que en una empresa hay 10 ordenadores trabajando durante http://digital.revistasprofesionales.com

un período de 8 horas en dos turnos de 4 (con hora y media de tiempo para comer) y con pequeños intervalos de tiempo de inactividad dedicados a un café a media mañana, la rigurosa visita al baño de las 12:30 y la obligada media hora de relaciones sociales con los compañeros de la oficina. Sumando todos estos tiempos podemos suponer que de 9:30 horas de trabajo hay 2:30 horas en las que el ordenador está “no atendido”. Si multiplicamos los tiempos de las 10 máquinas esto hace un total de 25 horas desaprovechadas (eso si no contamos que el ordenador siga encendido y potencialmente activo durante toda la noche). La tecnología Grid pretende utilizar este tiempo y los recursos asociados para realizar distintas tareas que de otra manera requerirían seguramente de potentes servidores con requisitos que incrementarían los costes hasta niveles hoy en día difícilmente asumibles. Lo cierto es que hace ya tiempo que consultores, profesionales y especialistas en la gestión del tiempo y optimización de recursos observaron que el tiempo efectivo de trabajo de un PC era infinitivamente inferior al rendimiento que este era capaz de ofrecer en su plenitud; que los recursos de los mismos, por norma general, estaban infrautilizados y que lo ideal sería poder sacar partido de ellos, aunque técnicamente nadie sabía realmente cómo hacerlo, no había una tecnología real que pudiera llevarlo a cabo… hasta ahora.

Las redes Grid se presentan como la nueva generación de Internet donde los recursos estarán siempre disponibles y la información se puede intercambiar en tiempo real gracias a la interconexión de múltiples máquinas utilizando los tiempos muertos de los PC y servidores de una red privada, para ejecutar procesos que requieren de mucha potencia de cálculo. Las redes Grid se conciben como un cluster distribuido a gran escala que actúa como una nueva forma de informática paralela para entornos distribuidos. Este entramado está dotado de una serie de funciones de control capacitadas para comprender las necesidades de los recursos, identificar dinámicamente aquellos que están disponibles y localizarlos dentro de la red. La indudable ventaja resultante consistirá en alcanzar una potencia de procesamiento casi ilimitada (dependerá de los recursos disponibles y de su capacidad de “captación” de los mismos, aunque es fácil hacerse una idea de las posibilidades con sólo pensar en lo vasto de Internet) puesto que este tipo de redes permite conectar millones de ordenadores (¿una red de red de redes?). Con este tipo de tecnología las organizaciones podrán agregar recursos a su infraestructura independientemente del lugar donde estos se encuentren con lo que se conseguirá balancear la carga de trabajo y evitar que mientras unos centros de trabajo están trabajando a capacidad máxima otros se encuentren prácticamente parados. El resultado inmediato se traducirá en la reducción de costes totales, un término que cualquier consultor disfruta oyendo.

Los grandes toman la iniciativa Empresas tan importantes como lo son Sun o IBM, normalmente pioneras en nuevos conceptos de tecnología, no se han quedado atrás, aunque sus objetivos no sean en principio los mismos. Junto con

Hoy en día la informática distribuida ya tiene aplicaciones prácticas.

13

SOLO PROGRAMADORES nº 128


ACTUALIDAD

Según se afirma desde Sun, la tecnología Grid mejorará la calidad y disminuirá los tiempos de mercado.

HP/Compaq y Microsoft forman parte del “Global Grid Forum”, un foro que tiene por misión promocionar y crear tecnologías y aplicaciones Grid a través del desarrollo y la documentación de las mejores prácticas, instrucciones de implementación y de los estándares, con especial énfasis en el código de ejecución. Sun forma parte de este foro, al igual que IBM, con el fin de impulsar los estándares para la crucial e importante capa de la gestión de los recursos distribuidos (DRM). Entre otras cosas, Sun se encuentra trabajando en un proyecto llamado DRAMA (Distributed Resource Management Application API) para crear una interfaz estándar para el DRM que permitirá a los vendedores de software independientes (ISV) crear aplicaciones para Grid. Y es que la capacidad de cálculo que ha demostrado esta técnica, no ha pasado desapercibida a la industria privada ya que, partiendo de la base de que una gran compañía puede tener repartidos miles de PCs entre sus empleados, trabajando bajo esa filosofía, se puede ahorrar por ejemplo la compra de un gran servidor de miles o millones de dólares. Entre otras aplicaciones orientadas a aprovechar las posibilidades que ofrece la tecnología Grid, HP/Compaq desarrolló en el 2002 una herramienta para la gestión de los recursos que permitía la consolidación de la carga de trabajo sobre servidores ProLiant de Compaq y Compaq Workload Management Pack, incrementando la estabilidad y disponibilidad de las aplicaciones bajo Windows 2000, además de permitir a los clientes implantar múltiples aplicaciones de forma fiable en un único servidor. Como característica más destacable de esta aplicación se encontraba la posibilidad de alterar dinámicamente la asignación de memoria y procesadores a una partición de recur-

SOLO PROGRAMADORES nº 128

14

sos, un paso indispensable para la aplicación de la filosofía Grid. Para ello definía una arquitectura formada por un interfaz y servicios. El interfaz permitía al administrador crear y activar fácilmente una partición de recursos definiendo los procesadores requeridos, las propiedades asociadas y las reglas de la partición de recursos. El motor de reglas incluido en el servicio proporcionaba el mecanismo para alterar dinámicamente los recursos de memoria y procesadores reservados. Si las condiciones externas al servidor cambiaban y un proceso necesitaba más recursos, el motor de reglas ejecuta las que habían sido definidas cuando la partición había sido creada. Por su lado Sun Microsystems (http://www.sun.com/grid/) anunció a principios de 2002 el N1, una estrategia de virtualización de redes y sistemas con el objetivo de renovar y redefinir el concepto de conectividad entre los diferentes recursos de una red. Para ello comercializó un producto denominado Grid Engine (en Solaris 9) dedicado a ofrecer a los administradores de sistemas una solución para la gestión de numerosos servidores de una forma centralizada. Por otro lado también anunció que utilizaría su tecnología Jini y Jxta para conectar los diferentes dispositivos y usuarios en una red N1. Según el CTO de Sun, Greg Papadopoulos, N1 también podría ayudar, entre otras cosas, al desarrollo de software. Un programador podría diseñar un nuevo programa y luego hacer que numerosas copias del software se distribuyeran en todo el mundo. Idealmente, la nueva aplicación sentiría la presencia de otro software que ya estuviera en la red y se vincularía con facilidad a esas aplicaciones existentes. Sun ha empezado a alquilar sus propias TI con tecnología de informática distribuida para permitir a toda empresa que necesite realizar operaciones computacionales y no disponga de la infraestructura necesaria, recurrir a los centros de Sun pagando una cuota de un dólar por hora de CPU. Todo esto ha sido posible gracias a la tecnología Grid resultante de combinar Solaris sobre procesadores tanto Sparc como AMD Opteron (inicialmente se han dejado fuera las operaciones transaccionales). Oracle, ha desarrollado Oracle 10g, una solución que permite hacer posible que las empresas, grandes y pequeñas, apliquen la tecnología Grid a su actividad diaria. Junto

a Intel, Dell y EMC Corporation se han unido para desarrollar conjuntamente el Proyecto MegaGrid, una iniciativa que pretende desarrollar un modelo estándar de diseño e implantación de infraestructuras de computación de informática distribuida. Las cuatro compañías combinarán sus principales tecnologías y recursos técnicos para ofrecer a sus clientes una solución corporativa integrada y completa a menor coste y así enfrentarse con garantías a los productos de gama alta de IBM y HP. Dell aporta sus soluciones servidor en red mediante equipos PowerEdge basados en procesadores Xeon dual e Itanium de cuatro vías; EMC dispondrá de sus arrays CLARiiON CX, Symmetrix y sistemas NAS de la Serie Celerra junto a herramientas software de gestión, mientras Intel contribuye con su experiencia en la gestión de procesadores y servidores con herramientas de optimización. Finalmente F5 Networks aporta sus switches BIG-IP y Cramer colabora con una aplicación que permite ficheros a gran escala y proceso de transacciones comerciales del mundo real. IBM, por otro lado, sitúa a la tecnología de computación distribuida entre los siete motivos más poderosos para que sus clientes efectúen inversiones en tecnología. Este gigante de la informática afirma tener ya disponibles 19 soluciones Grid dirigidas a nueve sectores de negocio y haber destinado 2.000 personas a su desarrollo. De la misma forma, dice tener interesados a un centenar de clientes en proyectos tan variados como un análisis financieros para Morgan Stanley, o los cálculos de los modelos de planes de pensiones para Hewitt Associates. Asegura que clientes como Charles Schwab, han conseguido con esta tecnología, reducir el tiempo de respuesta de análisis y valoración de carteras de bolsa de 14 minutos a una respuesta práctica-

La aplicación WorldCommunityGrid dice haber logrado procesar el equivalente a 10.000 años gracias a su programa Gris.

http://digital.revistasprofesionales.com


ACTUALIDAD

mente inmediata. ¡El tiempo real al poder! IBM también es el artífice de The World Community Grid (http://www.worldcom munitygrid.org), un proyecto para optimizar el sector científico, médico y ambiental a partir de PCs empresariales y personales. Se basa en el uso de un programa gratuito a modo de salvapantallas y pretende servir para solucionar algunos de los males sociales más complejos, como las alteraciones genéticas, o algunas enfermedades como el cáncer, el Alzheimer, o el virus del SIDA. También podría favorecer la desaparición de las catástrofes medioambientales o naturales, o favorecer proyectos de ayuda humanitaria en torno a la comida o el agua, algo que nos ha sensibilizado mucho tras la catástrofe del Tsunami en Indonesia. Este proyecto comunitario y voluntario fue presentado por Sam Palmisano, CEO de IBM, con el apoyo de investigadores de la Clínica Mayo, la Universidad de Oxford, la Universidad de Sudáfrica y otras entidades científicas. Otros de los grandes que se han lanzado a la aventura de la computación distribuida son Ford y Novartis que han decidido sustituir la compra de superordenadores para investigación por la apuesta de la tecnología Grid. Por un lado, Ford aprovecha todo el potencial de los ordenadores de sobremesa de sus empleados resolviendo en pocos minutos lo que antes les llevaba días, mientras que Novartis está utilizando los 2.700 PCs de sus empleados para la investigación de nuevos medicamentos, una buena causa. Por su lado, Adobe ha estado preparado una actualización de su programa After Effects Professional para poder utilizar varios ordenadores a la vez que le permitirán aumentar su rendimiento. Pretende lograr la primera aplicación comercial de escritorio. Para ello, Adobe incluirá un plugin de la compañía GridIron Software (efectos especiales a vídeo y gráficos en movimientos) que tiene la capacidad de realizar funciones similares en varias máquinas a la vez, unidas en una misma red, reduciendo así los tiempos de renderización de forma efectiva, uno de los procesos que más tiempo y CPU requieren.

Una de marcianos Ya están funcionando muchas aplicaciones que se han convertido en la avanzadilla de

SOLO PROGRAMADORES nº 128

16

El proyecto SETI de búsqueda de inteligencia extraterrestre es posiblemente la aplicación Grid más extendida.

lo que ha de llegar en un futuro muy cercano. Como ya se ha comentado, esta tecnología ha surgido en un entorno académico (como ya lo hiciera en su momento Internet, con el permiso de los militares americanos y Arpanet) y por ello lo más lógico es que las primeras aplicaciones prácticas hayan sido creadas para fines de investigación, ya sea en campos como la biotecnología, medicina o las matemáticas avanzadas. La aplicación que más impacto ha tenido mediáticamente ha sido el proyecto científico SETI de búsqueda de inteligencia extraterrestre (http://setiathome.ssl.berkeley.edu y http://www.querysoft.es/seti/). En concreto se denomina SETI@home (Search for Extraterrestrial Intelligence at home, un juego de palabras que literalmente quiere decir “Búsqueda de Inteligencia Extraterrestre desde casa” ya que la arroba en inglés se traduce como “at”). La idea fue concebida originalmente en el año 1996 por David Gedye en colaboración con Craig Kasnoff, aunque no sería hasta tres años más tarde cuando se haría el lanzamiento definitivo, logrando realizar cálculos que de otra forma habrían llevado décadas. Esta iniciativa científica utiliza ordenadores conectados a Internet para realizar la búsqueda, convirtiendo así a cualquier usuario que tenga funcionando el programa en protagonista activo de esta fascinante búsqueda. Cualquiera que tenga un PC y una conexión a Internet puede participar y no es necesario tener conocimientos científicos de ningún tipo ni pagar nada. Lo único que hay que hacer es descargarse un programa gratuito e instalarlo. La aplicación que se instala es un salvapantallas que sólo se activará durante los momentos de inactividad del PC y que muestra cómo se están analizando determinadas ondas de radio procedentes del espacio exterior. Estas señales son recogidas por el radiotelesco-

pio más grande del mundo con un diámetro de 305 metros y situado en Arecibo, Puerto Rico (¡el mismo por el que James Bond se deslizaba en la película “Golden Eye”!) y luego son enviadas a la Universidad de Berkeley (California, EEUU) que las redistribuye entre los más de cinco millones de voluntarios con los que cuenta el proyecto SETI, distribuidos por todo el mundo, y de los más de 100.000 son españoles. Una vez se han completado los cálculos, el PC transfiere los datos automáticamente al ordenador principal de Berkeley (esperando a que el usuario se conecte a Internet) y se inicia de nuevo el proceso con la transmisión de nuevos datos. Para hacernos una idea aproximada se dice que hasta el momento con esta técnica se han conseguido utilizar, según algunas estimaciones, 2.068.815 años de tiempo de CPU, tiempo donado voluntariamente por particulares a través de Internet que de otra forma hubiera resultado absolutamente desperdiciado en horas muertas. Hasta ahora el proyecto ha logrado una notoriedad y un éxito sin precedentes que ha provocado que la duración original del proyecto estimada en 2 años se haya prorrogado. Actualmente se está trabajando el SETI@home II que, como novedad más destacable, pretende, además de contar con el radiotelescopio de Arecibo, utilizar las señales recibidas desde el observatorio de Parkes situado en Australia. De lo que se trata es de conseguir abarcar el máximo espacio posible, cubriendo el cielo del hemisferio sur (hasta ahora se limitaba al hemisferio norte). De momento no se han captado aún señales lo suficientemente relevantes que nos den indicios de que nos estamos solos, aunque se haya producido alguna falsa alarma como la ocurrida en septiembre del 2004 cuando se aseguró desde la prestigiosa revista New Scientist que se había cap-

Observatorio de Arecibo desde el que se captan las señales a analizar por el programa SETI.

http://digital.revistasprofesionales.com


ACTUALIDAD

Tecnologías Grid o de computación distribuida

tado una señal de radio del espacio exterior sin explicación. Los responsables del proyecto SETI fueron concluyentes al atajar esta noticia y declarar que se había exagerado ya que, aunque sus parámetros eran inusuales, la señal también había podido ser causada por algún fenómeno astronómico desconocido y hasta por el propio telescopio de Arecibo.

La salud es lo primero Actualmente muchos son los campos de investigación en los que ya se está aplicando de una forma u otra la tecnología Grid. La medicina es posiblemente donde los resultados tendrán una aplicación y resultados más prácticos, sobre todo en lo referente a estudios y diseño de nuevos agentes terapéuticos para tratar distinto tipo de enfermedades. Una de las pioneras, pero que desafortunadamente ya ha cesado en su actividad, fue la altruista “Popular Power” (http://www.popu larpower.com) que lanzó un programa, con versiones para Mac, GNU/Linux y Windows, orientado a trabajar en diversos proyectos comerciales y no comerciales. Posteriormente centró su actividad en la investigación en la vacuna de la gripe, hasta su definitivo cierre.

Popular Power fue una de las pioneras en causas altruistas aunque ha cesado su actividad.

United Devices propone desde su web una aplicación Grid para la investigación de Cáncer llamada Think.

En septiembre del año 2000, y de manos de Entropia (http://www.entropia.com) y los laboratorios Olson (http://www.scripps. http://digital.revistasprofesionales.com

FIGHTAIDS@HOME es una aplicación que usa la computación distribuida para investigar sobre el SIDA.

edu/pub/olson-web/) se lanzó el proyecto FIGHTAIDS@HOME (http://www.fightaid sathome.com) con el claro objetivo de conseguir resultados que ayudaran a terminar con la gran epidemia de este siglo: el virus del SIDA. Para ello, se intenta analizar la existencia de posibles sitios de unión para compuestos inhibidores de la proteasa HIV1 que es básica en la replicación del retrovirus de la inmunodeficiencia adquirida. Su programa cliente llamado “AutoDock”, desarrollado a principios de la década de los 90 por David S. Goodsell y modificado posteriormente por Garret Morris, intenta servir de herramienta para la predicción de cómo pequeñas moléculas, candidatas a servir como medicamentos, se unen a un receptor de la estructura tridimensional proteica y la mutabilidad de la misma. Hasta el momento cuenta con la colaboración de casi 30.000 máquinas en las que se han adelantado más de 4.200.000 horas de CPU. Y sigue subiendo. La lucha contra el cáncer está liderada por el proyecto de United Devices (http://www.ud.com), una iniciativa apoyada por la Intel Corporation, la Fundación Nacional para la Investigación sobre el Cáncer, el Departamento de Química y el Centro sobre Investigación Computacional para la obtención de nuevas drogas terapéuticas, ambas adscritas a la Universidad de Oxford en el Reino Unido, junto con otras organizaciones. Ha conseguido hasta el momento la colaboración de más de 460.000 usuarios con los que se ha podido aprovechar más de 185.000.000 horas de CPU, logrando así acceder al podio de popularidad junto con el proyecto SETI. La

aplicación distribuida, y respondiendo al nombre clave “THINK”, ha sido desarrollada por el investigador de Oxford y fundador de Treweren Consultants Ltd. Keith Davies, y su principal meta consiste en la creación de modelos tridimensionales de las moléculas a investigar y analizar sus interacciones con la proteína diana ya que actualmente se buscan moléculas que inhiban enzimas que estimulen el aporte sanguíneo de tumores y que afecten a proteínas responsables tanto del crecimiento celular como del daño celular. Desde “Computer Against Cancer” (http://www.computeagainstcancer.org) Parabon Computation Inc. ofrece desde el año 2000 una aplicación llamada Pioneer, descargada ya por más de 16.000 usuarios, que está apoyada por varias instituciones como lo son, entre otras, el Cancer Treatment Research, la Association of Cancer Online Resources, el National Cancer Institute, la Universidad de Maryland o la Universidad de West Virginia. Su objetivo más inmediato es la obtención de nuevos medicamentos anticancerosos. Por otro lado la biología molecular y la bioingeniería están presentes en Folding@home (http://www.stanford.edu/group/pandegroup/f olding/), proyecto dependiente del Panda Group, desde donde se analiza cómo se produce el plegamiento que da lugar a la estructura terciaria proteica que será la responsable de sus funciones bioquímicas. Gracias a una nueva técnica de simulación de plegamiento de proteínas bautizada como de “dinámica distribuida”, se ha conseguido simular con éxito el plegamiento de diversos fragmentos proteicos y polímeros sintéticos proteicos. La aplicación que utiliza se denomina TINKER (http://das her.wustl.edu/tinker/), y que ya ha sido descargado por más de 17.000 usuarios, funciona también como un salvapantallas. Desde el Panda Group se presenta el Genome@home (http://genomeathome.stan ford.edu) como una aplicación en busca de nuevos genes que puedan formar proteínas funcionales en la célula, es decir, construyendo genomas “virtuales” no existentes en la naturaleza y que ayudarán a poder desarrollar nuevos fármacos (utilizando para ello el Algoritmo de Predicción de Secuencia o SPA). Evolution@home es una iniciativa que tiene por misión profundizar en el conocimiento de los factores involucrados en la evolución de las especies y que está dividi17

SOLO PROGRAMADORES nº 128


ACTUALIDAD

da en varios subproyectos (simuladores) dada su complejidad global (http://www.evolutionary-research.org y http://www.evolutionary-research.net). Desafortunadamente la transparencia de esta aplicación de cara al usuario no está tan lograda ya que el envío de resultados no está automatizado y es necesario enviarlos por correo electrónico lo que implica cierta dosis añadida de trabajo para el que quiera colaborar. La web de Golem@home se encargaba del estudio y la investigación dentro de las formas de vida robóticas (Genetically Organized Lifelike Electro Mechanics) desarrollando simulaciones de organismos artificiales con las que se pretendía entender mejor los principios que rigen la biología real (http://demo.cs.brandeis.edu/golem). Desafortunadamente se ha anunciado recientemente el fin del proyecto (habiendo logrado la colaboración de más de 30.000 participantes) llegando a la conclusión de que incluso con la dedicación de miles de horas de CPU, la complejidad del proceso evolutivo es demasiado elevado para ser cuantificado. El proyecto Folderol pretendía ofrecer una plataforma de código abierto para la exploración y análisis de los datos recopilados por el Proyecto Genoma Humano en lo concerniente al plegamiento de proteínas derivadas de los genes analizados y la búsqueda de las secuencias en el genoma humano, aunque debido a que se trataba de un proyecto modesto y a que la simulación contaba con la participación de unas 500 personas está en un más que probable proceso de desaparición (de hecho la página: http://www.folderol.org, que hasta hace poco albergaba el proyecto está de momento clausurada). En otro orden de cosas, vale la pena destacar el proyecto Distributed.net (http://www.distributed.net) que ha llegado a contar con el equivalente a 160.000 ordenadores PII 266MHz trabajando las 24 horas del día dedicados a la rotura de códigos de encriptación. Varios de sus integrantes han asesorado a otros proyectos (como SETI@home) o han pasado a formar parte de los mismos (el 27 de noviembre del 2000, distributed.net y United Devices Inc. firmaron un acuerdo por el que 14 de los integrantes de la primera formaban un grupo de trabajo dentro de la segunda).

SOLO PROGRAMADORES nº 128

18

El panorama español En España cabe destacar el proyecto iniciado por Banesto que está realizando pruebas para conseguir unir unos 15.000 ordenadores y pequeños servidores, toda una apuesta que bien merece la pena seguir. Por su parte, los investigadores españoles de la rama se han unido bajo las siglas IRISGRID (http://irisgrid.rediris.es) en una iniciativa que pretende fomentar la investigación en este sector. IRISGrid, evolución de la Red basada en Grid, fue lanzada en el año 2002. Surgió con el objetivo de coordinar a nivel académico y científico a los grupos de investigación interesados en esta tecnología, tanto en su desarrollo e implantación como para aplicaciones. De la misma forma pretende crear una infraestructura Grid nacional que posibilite el uso de esta tecnología en nuestro país. Empezó como un llamamiento a los grupos de trabajo de RedIRIS por parte del Instituto de Física de Cantabria y del Centro de Comunicaciones CSIC RedIRIS que pretendía recoger las opiniones de cara a futuras colaboraciones. Hoy en día cualquiera puede acercarse desde su web a documentación acerca de las posibles aplicaciones de la computación distribuida orientada a la Bioinformática, Meteorología, Astrofísica, Sistemas Complejos, Middleware, Química Computacional o Física Experimental de Partículas, entre otras disciplinas. A principios de 2004 saltaba la noticia del acuerdo al que habían llegado la Fundación Telefónica y Sun Microsystems Ibérica para desarrollar el proyecto Portal Grid Computing, una iniciativa conjunta con el objetivo de crear un sistema en red para la comunidad investigadora española, además de impulsar cursos de formación e-learning. Gracias a aportaciones de capital llegadas desde la Comisión Europea y que alcanzan

IRISGrid pretende fomentar la investigación sobre Grid en España.

importantes cifras de hasta 52 millones de euros repartidas en 12 proyectos, se pretende extender entre las empresas el uso de la tecnología Grid. De esta manera, desde Bruselas se desea estimular la competitividad de las empresas y la creación de nuevos mercados y servicios. De entre los proyectos financiados por la Comunidad Europea destaca el SIMDAT, dedicado al desarrollo de tecnologías orientadas a resolver complejas investigaciones para procesos relacionados con la industria automovilística y farmacéutica y en el que se ha dedicado la nada desdeñable cifra de 11 millones de euros. El resto de proyectos busca aumentar la competitividad en el ámbito de la industria del motor, las telecomunicaciones o la investigación. De momento existen diversas aplicaciones en el campo de la seguridad vial que permiten realizar cálculos avanzados en la resistencia de los parachoques (las ayudas concedidas se inscriben dentro del Sexto Programa Marco Europeo de Investigación, para el periodo 2004-2007, que trata de combinar la investigación tecnológica con la demanda de aplicación).

Conclusiones En el momento en el que las organizaciones sean conscientes de las posibilidades reales que este tipo de tecnología ofrecen a sus negocios, las redes Grid tendrán el salto cualitativo que se merecen, apareciendo lo que, según un informe de la organización Grid Technology Partners, será un cambio en la productividad empresarial tan grande como el generado en su momento por Internet, aunque hoy en día exista el debate en cuanto al rumbo a tomar ya que otra de las posibilidades consiste en derivar los esfuerzos hacia la tecnología de 64 bits. El tiempo lo dirá. Está claro que la computación distribuida se constituye como una alternativa clara en el despliegue de infraestructuras de TI. El futuro se presenta alrededor de organizaciones dinámicas virtuales creadas a partir de la conexión de sistemas dispersos geográficamente. El objetivo puede consistir en definitiva en trasladar las bondades de esta tecnología del campo científico al empresarial y convertirla en el soporte de las aplicaciones e-business para todos los sectores industriales. http://digital.revistasprofesionales.com


DISPOSITIVOS MÓVILES

Creación de un sistema de distribución de Midlets (y II) JOSÉ ANTONIO PÉREZ

Las especificaciones OTA (Over The Air) definen los mecanismos por los cuales podemos distribuir nuestras suites de Midlets a través de Internet. En este artículo completaremos la serie construyendo un sistema de distribución de Midlets basado en IIS. Introducción En el anterior artículo de la serie se trataron las bases teóricas del protocolo HTTP sobre el que funciona la distribución OTA, así como los elementos necesarios para programar una extensión para IIS. En el presente artículo nos centraremos en la teoría que nos falta y en la implementación e implantación del sistema.

desde un ordenador al que esté conectado por USB, infrarrojos o bluetooth pero también puede instalar aplicaciones vía Internet. A la descarga desde Internet se la conoce como OTA o Over The Air Provisioning. Para descargar aplicaciones desde la red, los dispositivos móviles deben integrar un software que ayude a localizar aplicaciones en un determinado portal en la red. Este software (“discovery application”) suele ser un navegador WAP o HTML, aunque también puede ser otra aplicación nativa del móvil. Los dispositivos de información móvil tiene un perfil específico (MIDP). La especificación MIDP OTA define cómo los dispositivos deben comunicarse con los servidores y cómo deben descargar las aplicaciones. La primera versión de MIDP OTA apareció después de la especificación MIDP 1.0, aunque realmente era una recomendación. Con la aparición del MIDP 2.0, OTA paso a formar parte del estándar. La especificación 2.0 mejora las recomendaciones de la anterior versión y la integra como especificación. OTA soporta HTTP 1.1

El software AMS Todos los dispositivos móviles con soporte Java vienen con un software gestor de aplicaciones conocido con el nombre de AMS acrónimo de Application Management Software. Otro nombre usado para este software en dispositivos J2ME es el de JAM (Java Application Manager) El AMS es el responsable de gestionar la descarga, instalación, actualización, desinstalación y ejecución de los Midlets. A través del software AMS incorporado, un dispositivo MIDP puede descargar suites de Midlets

Ejemplo de una petición y su respuesta a nivel de HTTP, en el que se puede ver el contenido del archivo WML devuelto.

Mime types usados en la aplicación MIME TYPES

Material complementario El lector encontrará en http:// digital.revistasprofesionales.com el material complementario de este artículo.

SOLO PROGRAMADORES nº 128

20

DESCRIPCIÓN

application/vnd.wap.wml

Mime type para archivos WML

text/x-wap.wml

Mime type para archivos WML

text/vnd.wap.wml

Mime type para archivos WML

text/vnd.sun.j2me.app-descriptor

Mime type para archivos JAD

application/java-archive

Mime type para archivos JAR

text/html

Mime type para archivos HTML

http://digital.revistasprofesionales.com


DISPOSITIVOS MÓVILES

Creación de un sistema de distribución de Midlets (y II)

incluyendo el sistema básico de autenticación. En nuestra aplicación no haremos uso de dicho mecanismo, pudiendo ser una posible mejora para un futuro.

Ciclo de vida de una instalación Para la obtención de una suite de Midlets desde Internet se han de seguir un número reducido de pasos. Cada paso implica la descarga de un tipo determinado de archivos que poseen un mime type asociado (véase la tabla “Mime types usados por la aplicación”) y que el servidor debe suministrar al dispositivo móvil para ayudar a realizar la descarga. Si el mime type asociado al elemento que se quiere descargar no se corresponde con el esperado, la descarga será invalidada por el software del dispositivo móvil. Como primer paso un usuario emplea el software de localización de aplicaciones para acceder al portal de suministro gestionado por el servidor de descargas. Este software nos permite acceder a una página HTML o WML donde podremos encontrar los links relativos a los archivos descriptores de la suites de Midlets (ficheros JAD). Los archivos JAD contienen elementos fundamentales para que el usuario, a través del software AMS, pueda realizar la descarga de los ficheros JAR, que contienen las suites. En la más reciente especificación el uso de los fichero JAD es opcional con lo que el link que aparece en las paginas HTML o WML puede apuntar directamente a la suite de Midlets, esto como veremos tiene sus desventajas. Si una versión de software que se quiere descargar se encuentra ya instalada en el dispositivo móvil, el archivo JAD proporcionará información al software AMS para que nos lo notifique y proceder, si se quiere, a la actualización. El archivo de descriptores permite al software AMS proporcionar información por

Códigos de estado AMS MIDP 1.0 y MIDP 2.0 CÓDIGO

MENSAJE

900

Success.

La operación resultó exitosa.

901

Insufficient memory.

Memoria insuficiente.

902

User cancelled.

Operación cancelada por el usuario.

903

Loss of service.

Pérdida de servicio.

904

JAR size mismatch

En el fichero JAD es errónea la especificación del tamaño del fichero JAR.

905

Attribute mismatch.

No se ha especificado un atributo obligatorio en el fichero JAD.

906

Invalid descriptor.

Descriptor no válido.

Códigos de estado AMS exclusivos de MIDP 2.0 CÓDIGO 907

MENSAJE

http://digital.revistasprofesionales.com

DESCRIPCIÓN

Invalid JAR.

El fichero JAR no es válido.

Incompatible configuration or profile. Application authentication failure.

La configuración o profile son incompatibles. Se produjo un error en la autenticación.

910

Application authorization.

Se produjo un error de autorización.

911

Push registration failure.

Se produjo un error en el proceso de registro de la aplicación.

912

Deletion notificación.

Notificación de borrado.

913

Required package no supported by the device.

El dispositivo no posee un package java necesario.

908 909

adelantado referente a la aplicación antes de que se proceda a la descarga e instalación de la misma. Si el usuario decide instalar la suite, el software AMS utilizará la URL de la propiedad “MIDlet-Jar-URL” del archivo de descriptores para solicitar la descarga.

Códigos de estado del AMS

El software AMS usa la información contenida en el archivo JAD para interaccionar con el usuario.

DESCRIPCIÓN

Una vez finalizada la descarga, y siempre que el archivo JAD tenga definido el descriptor “MIDlet-Intall-Notify”, el AMS enviará un código de estado a la URL definida. Los códigos posibles se recogen en las tablas qua acompañan a este texto. De la misma manera si el archivo JAD tiene definido el descriptor “MIDlet-DeleteNotify” (sólo MIDP 2.0) se enviará una notificación cuando se elimine el Midlet (siempre que las conexiones lo permitan).

Descripción del contenido de los ficheros JAD El archivo JAD (Java Application Descriptor) es un archivo de texto en el que se definen propiedades. Con la herramienta KToolbar del J2ME Wireless Toolkit de Sun (http://java.sun.com/products/sjwtoolkit/) la inclusión y modificación de propiedades del archivo JAD se automatiza enormemente. Podemos distinguir tres tipos de propiedades:  Propiedades obligatorias.  Propiedades opcionales.  Propiedades de usuario. El orden de las propiedades no es importante pero sí es fundamental que aquellas propiedades que son necesarias estén correctamente descritas, de lo contrario el 21

SOLO PROGRAMADORES nº 128


DISPOSITIVOS MÓVILES

software AMS, al igual que ocurría con el caso mime types incorrectos, invalidará el proceso.

 

Propiedades obligatorias 

M I D l e t - J a r - S i z e: Tamaño en bytes del fichero JAR a descargar.  M I D l e t - J a r - U R L: La URL usada para descargar el fichero JAR. En los ejemplos de prueba suministrados con la aplicación, todas las URL tienen como host la propia máquina. Para probarse en Internet, se debe especificar una IP o nombre de host adecuado.  M I D l e t - N a m e: El nombre de la suite de Midlets a mostrar al usuario.  M I D l e t - V e n d o r: El texto que identifica al proveedor del Midlet.  M I D l e t - V e r s i o n: El número de versión de la suite. Son tres cifras separadas entre sí por un punto (por ejemplo 1.0.0).  M i c r o E d i t i o n - C o n f i g u r a t i o n : La configuración J2ME necesaria (CLDC-1.0 o CLDC-2.0).  M i c r o E d i t i o n - P r o f i l e: El Perfil J2ME necesario (MIDP-1.0 o MIDP-2.0). Adicionalmente, por cada Midlet que se incluya en el fichero JAR se debe añadir una propiedad con el siguiente formato: MIDlet-n: valores_del_descriptor

Donde “n” es un valor numérico siempre consecutivo que comienza en 1 (MIDlet-1, MIDlet-2, etc.). En la descripción de esta propiedad se especifican tres datos separados por comas:  El nombre con el que se identifica el Midlet.  El icono que identifica al Midlet (un archivo dentro del fichero JAR de tipo PNG).  La clase que constituye el punto de entrada del Midlet.

Propiedades opcionales 





M I D l e t - D a t a - S i z e: Es la cantidad de memoria mínima en bytes del área del almacenamiento necesaria para la suite. M I D l e t - D e l e t e - C o n f i r m: Es el texto del mensaje que se muestra al usuario cuando se le pide que confirme la eliminación de la suite. M I D l e t - D e l e t e - N o t i f y: Es la URL a la que se envía un mensaje HTTP (usando el método POST) para indicar que el borrado de la suite se realizó.

SOLO PROGRAMADORES nº 128

22





M I D l e t - D e s c r i p t i o n: Es un texto libre para incluir una descripción de la suite. M I D l e t - I c o n: Es el nombre del archivo PNG para identificar a la suite de Midlets. M I D l e t - I n f o - U R L: Es una URL desde la que se puede obtener una descripción opcional de la suite. M I D l e t - I n t a l l - N o t i f y: Es la URL a la que se envía un mensaje HTTP (usando el método POST) para indicar el resultado de la instalación.

El fichero MANIFEST.MF Al igual que en las aplicaciones creadas con J2SE, en el fichero JAR podemos empaquetar todas las clases que integran la suite, archivos de imágenes, textos, y cualquier tipo de recurso que podamos necesitar. Cuando se realiza el empaquetado desde la aplicación KToolbar se incluye el archivo “MANIFEST.MF”. Este archivo puede contener toda la información de los descriptores obligatorios del fichero JAD, a excepción de la URL y opcionalmente puede incluir los descriptores “MIDlet-Permissions” y “MIDletPermissions-Opt”. Un Midlet puede necesitar ciertos permisos para realizar algunas operaciones que son sensibles desde el punto de vista de la seguridad. Estos descriptores propios del archivo “MANIFEST.MF” indican las operaciones de las que se necesitan se tengan permisos completos y de las que serían deseables tener permisos. La inclusión de los valores adecuados se hace de forma transparente con KToolbar.

La aplicación OTA Provisioning del J2ME Toolkit El J2ME Wireless Toolkit viene con la aplicación OTA Provisioning que nos permite probar la descarga, actualización, ejecución y borrado de suites de Midlets antes de ponerlas en un servidor de explotación. El emulador nos permite introducir una URL igual a como lo haríamos en un navegador. En nuestro caso las URLs que proporcionemos incluirán el nombre del archivo HTML o WML donde se tiene las lista de Midlets a descargar y el identificador de la licencia (que como veremos no siempre tiene que ser obligatorio). Veamos un par de ejemplos:



Un navegador WAP

http://localhost/midlets/MidSvr.dll?w =test.wml&k=5uu_TX 

Un navegador HTML

http://localhost/midlets/MidSvr.dll?h =test.htm&k=5uu_TX

El mime type que debe usar el servidor para responder al móvil esta indicado con el uso del parámetro “w” para WAP y el parámetro “h” para HTML. La clave que se suministra al usuario se debe indicar como valor del parámetro “k”. Una vez se tiene instalado el servidor, la ejecución de esta URL por parte del emulador producirá la carga del archivo HTML o WML que contiene los Midlets que queremos bajar. Tras seleccionar una de las suites bastará con seguir las indicaciones que el emulador nos haga.

La extensión desarrollada Las funcionalidades de la extensión incluyen el dar de alta, baja o modificar las suites de Midlets. La aplicación y los archivos de datos se reparten en tres directorios de los cuales destacaremos 2: b i n: Contiene la extensión (“MidSvr.dll”) y todos los archivo HTML usados para la administración. d d b b: en este directorio se encuentra la base de datos, creada en formato access (“middbb.mdb”). Esta base de datos contiene las tablas “T_MIDLETS”, “T_VARIABLES” y “T_LICENSES”. “T_VARIABLES” guarda las variables de entorno de la aplicación. “T_MIDLETS” define las características de cada Midlet (nombre, fichero JAR, JAD, el tipo de licencia a usar y número de licencias). “T_LICENSES” nos permite controlar el uso único de las licencias. Cada Midlet puede definir el tipo de tratamiento que se quiera aplicar. Hay cuatro tratamientos para un Midlet:  Totalmente deshabilitado: el Midlet no está disponible aunque esté dado de alta.  Acceso libre sin licencia: el usuario puede descargar un Midlet libremente (no se tiene en cuenta el identificador de licencia aunque se proporcione).  Acceso con licencia única: todas las descargas usan un único identificador de licencia. http://digital.revistasprofesionales.com


DISPOSITIVOS MÓVILES

Creación de un sistema de distribución de Midlets (y II)



Acceso con licencia personalizado: en cada descarga el identificador es único. Para crear la licencia de forma aleatoria se usa una palabra clave. Si queremos que un usuario pueda acceder a varias suites con un identificador de licencia común, las palabras claves deben ser idénticas en todos los casos (dos palabras clave distintas generan dos licencias distintas). Para ver la lista de identificadores válidos basta con seleccionar un Midlet para modificar y pulsar el botón de “Crear lista de códigos de licencia” y ver el contenido de la página generada con el menú contextual del navegador. Sólo se generan licencias en los casos en que esté habilitado el tratamiento adecuado.

Las clases del aplicativo El punto de entrada de cualquier petición es la función “HttpExtensionProc” que encontraremos en el archivo “startup.cpp”. Dentro de ella se ejecuta la función “DoRequest” en la que haremos el tratamiento de las peticiones. Lo primero que se hace es cargar las variables del entorno desde la base de datos en la memoria de la aplicación. Las peticiones que vienen por el método POST están reservadas a la administración de la aplicación y a la comunicación por parte del software AMS del código de estado después de una operación. Las peticiones GET son las que usaremos

LISTADO 1

Ejemplo de archivo JAD usado

MIDlet-1: solop, solop.png, spMidlet MIDlet-Jar-Size: 11187 MIDlet-Jar-URL: http://localhost/midlets/MidSvr.dll?jar=solop.jar&m=test&k=##k##&b=##b##&cmd=dwl MIDlet-Name: solop MIDlet-Vendor: Banshee Software (JAPM) MIDlet-Version: 1.0 MicroEdition-Configuration: CLDC-1.0 MicroEdition-Profile: MIDP-1.0 MIDlet-Delete-Notify: http://localhost/midlets/MidSvr.dll?jar=solop.jar&m=test&k=##k##&b=##b##&cmd=dlt MIDlet-Install-Notify: http://localhost/midlets/MidSvr.dll?jar=solop.jar&m=testt&k=##k##&b=##b##&cmd=ntf

LISTADO 2

Extracción de los valores de una petición HTTP

DWORD DoRequest (EXTENSION_CONTROL_BLOCK * inRequest) { LoadEnviromentVariables(inRequest); if (!stricmp(inRequest->lpszMethod, “GET”)){ HttpRequestParameters theParameters(inRequest->lpszQueryString); std::string theValue; if (theParameters.GetParameter(“jad”, theValue)) { LogQuery(inRequest); std::string theBrowser; theParameters.GetParameter(“b”, theBrowser); std::string theKey; theParameters.GetParameter(“k”, theKey); std::string theFileName = GetMidletsPath(inRequest); theFileName += theValue; return SendModifiedFile(inRequest, JAD_MIME_TYPE, theFileName, theKey, theBrowser); } : : }else if (!stricmp(inRequest->lpszMethod, “POST”) ) return DoPost (inRequest); return HSE_STATUS_ERROR; }

La correcta configuración de los permisos de usuario en las bases de datos usadas en las extensiones es fundamental.

http://digital.revistasprofesionales.com

para las peticiones de ficheros WML, HTML, JAD y JAR. Todos los archivo excepto los ficheros JAD pueden contener unos tags para ser sustituidos por valores proporcionados en la URL inicial del usuario, el tag “##b##” indica el tipo de navegador (WML o HTML) y el tag “##k##” es sustituido por identificador de la licencia (véase el listado 1). La clase “CLog” es la encargada de escribir los logs de la aplicación. Los métodos del namespace “CMD” nos permiten crear las páginas dinámicas HTML usadas en el interfaz del administrador. Para gestionar la base de datos hay implicadas tres clases. Las clases “DataBase”, “ResultSetContainer” actúan como una capa para gestionar base de datos con ADO. La clase “MidletDataBase” contiene las funcionalidades específicas para trabajar con la base de datos de la aplicación (“middbb.mdb”). Para generar los códigos de licencia se ha usado la clase “Cripto”. 23

SOLO PROGRAMADORES nº 128


DISPOSITIVOS MÓVILES

Finalmente para extraer los parámetros de las peticiones se usa la clase “Http RequestParameters”.

Instalación del sistema de distribución de Midlets La instalación de una extensión en IIS es realmente trivial. Aunque las capacidades y localización de las opciones varían dependiendo de la versión de IIS que usemos, en general contemplan las mismas funcionalidades básicas. El lector encontrará en el material complementario una explicación detallada de cómo desplegar nuestro servidor de Midlets en IIS, sin embargo vamos a introducir en las próximas líneas cómo habría que llevar a cabo dicho proceso. En Windows XP profesional primero debemos instalar el IIS desde el “Panel de Control”. Desde aquí, con la opción de “Agregar o quitar programas”, seleccionaremos “Añadir o quitar componentes de Windows” que nos permitirá incluir IIS en el sistema operativo. Para acceder a la consola de administrador del IIS, y siempre partiendo desde el “Panel de Control”, seleccionaremos el icono “Herramientas Administrativas” que nos llevará a una

pantalla en la que veremos el icono de la aplicación gestora bajo el nombre “Servicios de Internet Information Server”. Desde aquí podremos instalar nuestra extensión. Para ello debemos crear un directorio virtual en el sitio Web que decidamos utilizar (por ejemplo el “Sitio Web Predeterminado”). Abriremos el menú contextual y rellenaremos los datos que el asistente nos solicita. En nuestro caso introduciremos como alias el texto “midlets”. A continuación nos pedirá que elijamos el directorio en el que tengamos la extensión a ejecutar, en este punto habrá que introducir la senda del directorio “bin” que contiene el fichero “MidSvr.dll”. Seguidamente nos aparecerá un nuevo dialogo donde se pedirá que especifiquemos los permisos del directorio de ejecución. Debemos añadir a los existentes por defecto el permiso de ejecución. Para invocar a nuestra extensión en modo administrador desde la propia máquina podremos hacerlo con la URL “http://localhost/midlets/admin.htm”. Para poder explotar el servidor en Internet, éste debe tener una IP fija o si se tiene una IP dinámica usar un servicio como el proporcionado por webs

como “www.no-ip.com” que nos dé la posibilidad de tener una “IP fija”. Por defecto deberemos crear el directorio “C:\logs” donde se crearán los archivos de log de la aplicación. La carga de la extensión desde XP se hace cuando se invoca por primera vez alguno de los servicios referidos a la DLL (sea vía administración o desde un dispositivo móvil).

Gestión de base de datos Un elemento importante en extensiones como la desarrollada para los artículos de la serie lo constituye el tratamiento de base de datos. Las APIs que nos proporciona ADO se pueden utilizar de igual manera a como lo haríamos con una aplicación que no fuese una extensión del IIS. La precaución más importante a tener, es la cuestión de los permisos de usuario para el acceso a la base de datos, que deben ser de lectura y escritura para el usuario que ejecuta la aplicación IIS. Si estos permisos no están bien configurados la ejecución de queries SQL en las que debemos insertar o modificar información en la base de datos, fallará. Si se quedase bloqueada la base de datos, por un uso concurrente (por ejemplo cuando se haya accedido a la extensión cuando la teníamos abierta desde Access) lo mejor es descargar la extensión y volver a cargarla.

Conclusiones

Finalizada la instalación, el emulador del J2ME Wireless Toolkit nos permitirá comprobar la descarga de Midlets.

SOLO PROGRAMADORES nº 128

24

En estas dos entregas de la serie hemos visto las bases teóricas y prácticas para implementar una extensión IIS y crear un sistema de distribución OTA. La aplicación de ejemplo desarrollada contiene todos los ingrediente para crear nuevas extensiones mejoradas orientadas a OTA u otros ámbitos con cambios muy sencillos. Entre las mejoras posibles del sistema está la posibilidad de añadir funcionalidades para generar automáticamente las páginas WML o HTML, el procesamiento de las peticiones de forma asíncrona, o el tratamiento estadístico a partir del análisis de los logs. Se puede forzar que los settings usados por la aplicación se carguen del registro de Windows y a partir de ahí poder hacer configurable el path donde se generan los ficheros de log. http://digital.revistasprofesionales.com


DISPOSITIVOS MÓVILES

El GPS como “medio de comunicación” LUIS GARCÍA ARRANZ

El mes de agosto es para muchos el mes de las vacaciones. Ello conlleva vivir nuevas experiencias, muchas veces basadas en el viaje a lo desconocido. Es por esto que, aprovechando la ocasión, hemos querido ofrecer este artículo. Sin duda, una forma divertida pero apasionante de aprender a usar la tecnología GPS. Introducción Limitándonos tan sólo a los GPS más usuales y asequibles, la variedad de sus funciones y apariencia es muy grande. Expondremos una serie de conceptos básicos comunes a todos ellos y describiremos las tipologías más corrientes, de modo que el lector podrá hacerse una idea de cuál podría ser la más adecuada a sus necesidades. En una segunda parte estudiaremos con más detalle la poderosa herramienta que constituyen para intercambiar información, y su utilización práctica.

El GPS Un GPS es un receptor de radiofrecuencia, que en combinación con los componentes de hardware y software adecuados nos permite calcular nuestra posición sobre la esfera terrestre, y fijar rumbos y distancias horizontales a otros puntos cuyas coordenadas conozcamos.

Apunte En http://www.elgps.com existe información sobre programas y receptores de GPS, con foros de discusión y listas de correo. Uno de los sites más veteranos y completos en español.

Material complementario El lector encontrará en http:// digital.revistasprofesionales.com el material complementario de este artículo.

SOLO PROGRAMADORES nº 128

26

Los receptores de GPS captan la señal de unos satélites colocados en orbita con ese fin, y en función de la diferencia de tiempo entre la emisión de la señal y el momento en que ha sido captada calculan la distancia a ese satélite.

Una vez que han establecido contacto con un número suficiente de satélites y calculado la distancia hasta ellos, determinan su posición sobre la esfera terrestre, mediante un proceso en parte similar a la “triangulación”, y con ese nombre se le designa a veces, aunque difiera de ella en gran medida. Conocida la propia posición puede gracias al “ordenador” fijar el rumbo y establecer distancias hasta puntos cuyas coordenadas conozcamos. Dejando a un lado los GPS de alto costo dedicados a tareas muy específicas y las relacionadas con la navegación aérea y marítima, aunque la clasificación no sea muy técnica, en busca de una mayor claridad expositiva vamos a dividir el resto en tres apartados: “para campo”, “para coche”, y “para PDAs”, que son los diferentes tipos de los que nos vamos a ocupar. Los utilizados por excursionistas y montañeros son los que hemos denominado “para campo”. Estos GPS tienen unos circuitos informáticos y un programa para realizar cálculos y mostrarlos por medio de una pantalla, cuyas dimensiones no suele sobrepasar los 20 centímetros cuadrados, y un número reducido de teclas con los que el usuario activa las diferentes funciones. Los pensados “para coche” están constituidos por un ordenador concebido especialmente para soportar un determinado tipo de programa y base de datos, la pantalla es unas cuatro veces mayor que la de los anteriores, y con frecuencia es sensible al tacto y permite introducir las órdenes. Por lo general disponen de algún sistema de voz de modo que el conductor pueda recibir la información sin necesidad de mirar la pantalla. Los receptores de GPS “para PDAs” no tienen pantalla ni teclas y se limitan a transmitir los datos a la PDA para que allí sean procesados. Por su diseño y características físicas externas el conjunto de GPS más PDA constituye un híbrido entre los dos anteriores, y al tener las PDAs sistemas operativos abiertos y admitir diferentes tipos de programas, sus funciones y forma de utilización se parecerá más a los unos o los otros según el programa que elija el usuario.

GPS para campo Los de este tipo son los que requieren mayor participación por parte del usuario que con frehttp://digital.revistasprofesionales.com


DISPOSITIVOS MÓVILES

El GPS como “medio de comunicación”

cuencia se encarga de suministrar la información pertinente para la realización de un determinado recorrido. Para utilizarlos correctamente conviene tener claros los siguientes conceptos:  W a y p o i n t: Se trata de un lugar definido por sus coordenadas, que tiene un nombre propio y al que dependiendo de los diferentes modelos se le puede asignar un símbolo, y en ocasiones una descripción.  T r a c k: Una sucesión de puntos, definidos por sus coordenadas, lo suficientemente próximos como para a partir de ellos poder seguir un camino.  R o u t e : Una secuencia ordenada de waypoints que refleja un proyecto de itinerario a seguir. Aunque puedan aparentar alguna similitud debemos evitar confundir este concepto con el de “track”, ya que la “route” es mucho más esquemática, y las rectas que unen sus “waypoints”, en la práctica es probable que no se puedan seguir, ya que en la realidad pueden surgir obstáculos que nos lo impidan.

Figura 1. La gama de receptores Etrex, de Garmin, es una de las más usadas por los excursionistas. En la imagen, puede verse el Etrex Summit.

Caminando con el GPS podemos generar automáticamente “tracks” que serán el reflejo de nuestro recorrido, y marcar “waypoints” cada vez que estemos en algún lugar que consideremos de especial relevancia, y todos esos datos los podemos almacenar para utilizarlos durante esa jorhttp://digital.revistasprofesionales.com

nada u otras posteriores. También a partir de los “waypoints” podremos idear “routes” que son independientes del orden en que los hayamos obtenido; es decir que si nuestro recorrido ha sido ABCDE, podemos crear “routes” tan diferentes como BCEA, o CAEBCDEA, independientemente de que éstas sean viables, o no. También podemos generar estos elementos en un ordenador de sobremesa con el programa adecuado y después enviarlos al GPS para poder utilizarlos. En este caso tendremos que escanear un mapa de papel y calibrar la imagen obtenida, operación para la que hay que prestar atención a aspectos tales como el tipo de coordenadas del mapa, y el datum (concepto que será tratado al final de este texto) al que está referido. Para que la operación resulte satisfactoria es conveniente tener algunos conocimientos geográficos y alguna experiencia en el tipo de recorrido que estamos planeando. Otra forma de conseguirlos es que alguien nos los regale o venda, cosa para la que además de los amigos y conocidos podemos recurrir a las numerosas webs que, a través de Internet, los ponen a disposición del público, generalmente con carácter gratuito. Sean realizados por nosotros o adquiridos de otro modo, los generados in situ por el GPS son más fiables y precisos que los “ideados” y marcados ante la pantalla del ordenador, del mismo modo que siempre es mejor el conocimiento directo de un camino, que el trazado que imaginamos ante el mapa de una zona desconocida. Si tenemos “waypoints” cargados en nuestro GPS, podemos aplicar la función “go to” y nos marcará la distancia horizontal y el rumbo a seguir para llegar hasta ellos, con la ventaja en relación con la brújula de que si al desplazarnos nos salimos del rumbo, se harán los cálculos necesarios para señalarnos el nuevo rumbo a seguir. Si lo que tenemos cargado es un “track”, junto a él podemos ver el “track” que estamos generando con nuestro movimiento y en qué medida están siendo coincidentes, o presentan diferencias, de modo que podamos regresar al buen camino. Y si es una “route” lo que hemos generado, el GPS nos indicará la distancia horizontal y el rumbo que debemos seguir para llegar al primer “waypoint” que la integra, y una vez que hayamos llegado a él nos indicará el rumbo hasta el siguiente, y así sucesivamente.

Algunos GPS de este tipo permiten la carga de mapas, de modo que podemos ver el “track” de nuestro recorrido sobre él; pero la mayoría de los mapas disponibles para cargar en ellos si bien contienen buena información sobre carreteras y ciudades no ofrecen información topográfica de mucho interés, que es la que por lo general interesa al excursionista.

Figura 2. Haciendo “go to” la flecha nos señala la dirección a seguir en línea recta para llegar hasta un determinado “waypoint”.

GPS para coche La comunicación entre el usuario y este tipo de GPS se suele realizar por medio de conceptos habituales en la vida cotidiana, tales como “quiero ir a la calle C número N”, y el aparato tras realizar los cálculos oportunos propone el recorrido que le parece adecuado, que como es lógico no es necesariamente la línea recta, ni el más corto, sino aquel que transcurre por las carreteras y calles más adecuadas para el tráfico rodado. Además a lo largo del recorrido el GPS da las indicaciones oportunas al conductor y si este no cumple sus propuestas realiza nuevos cálculos para dar nuevas indicaciones sin perder el objetivo como destino. Para tan colosal tarea disponen de mapas y bases de datos elaboradas directamente sobre el terreno por equipos especializados. La eficacia de nuestro GPS dependerá de lo actualizados que estén sus mapas, por este motivo los hay que incluso se mantienen en comunicación telefónica, o por radio, con una base de datos central, que puede registrar acontecimientos circunstanciales tan efímeros como puede ser un atasco. 27

SOLO PROGRAMADORES nº 128


DISPOSITIVOS MÓVILES

ella imágenes de mapas de modo que los “tracks” y “waypoints” se tracen sobre el mapa de la zona. La razón es clara; el Tom Tom es un programa pensado para los que recorren grandes distancias en automóvil y dispone de una amplia información sobre ciudades y carreteras, y el OziExplorer es un programa desarrollado para su utilización por caminantes y similares.

Figura 3. Equipo Tom Tom go 500, un típico GPS “para coche”.

Lo habitual es que, una vez dadas las instrucciones, en pantalla aparezca un icono del vehículo desplazándose sobre el mapa de calles o carreteras, mientras que por medio de voz se dan indicaciones del tipo: “... próxima rotonda a 500 metros... está usted llegando a la rotonda... debe tomar la segunda salida a la derecha....”. Se trata de un mercado en el que hay muchas expectativas económicas y grandes empresas interesadas en él, por lo que es previsible que se produzcan importantes cambios en un plazo de tiempo breve, especialmente en lo referido a la actualización de los datos, y terminales que no capten la señal directamente de los satélites, sino que conectadas con la central reciban todos los datos de forma que se pueda evitar la distorsión que surge cuando la señal procedente de los satélites se está recibiendo en un entorno urbano.

GPS para PDAs En sus especulaciones sobre el ser y el no ser dice el filósofo Agustín García Calvo que el que “no es ninguno puede ser cualquiera” y algo así viene a suceder con las PDAs, que siendo ordenadores no orientados a una finalidad específica pueden admitir diferentes programas y mostrar comportamientos diferentes. En este sentido, podemos afirmar que en función del programa cargado en nuestro dispositivo PDA, su funcionalidad será una u otra. Por ejemplo, si cargamos en nuestro PDA el Tom Tom (con sus bases de datos) obtendremos un comportamiento similar a los que hemos denominado “para coche”, mientras que si lo que cargamos es el OziExplorer su comportamiento se asemejará más a los que hemos considerado “para campo”, y podremos con facilidad cargar en

SOLO PROGRAMADORES nº 128

28

Apunte Tom Tom es una herramienta especialmente valorada por los que se desplazan en automóvil por carretera y ciudades (http://www.tomtom.com).

desde el interior del vehículo, y en la modalidad “para campo” la derivada de su fragilidad y un diseño no pensado para soportar lluvias, nevadas y otras circunstancias meteorológicas extremas, así como la poca duración de sus baterías.

Recepción de las señales

Figura 4. GPS con una PDA en la que se ha instalado el programa Tom Tom.

Apunte Para informase y descargar diferentes versiones de OziExplorer, programa especialmente valorado por excursionistas y montañeros, existe http://www.oziexplorer.com.

Para que las PDAs funcionen como GPS, lo que hay que añadirles, además del programa adecuado, es precisamente un receptor GPS. La mayoría son pequeños, sin pantalla ni teclas y por razones de comodidad se comunican con la PDA mediante un sistema que no implica la utilización de cables. En la utilización de una PDA en la modalidad “para coche” la principal dificultad es la derivada de la captación de las señales

Figura 5. Receptor Haicom HI-405BT para PDA.

Las señales que emiten los satélites son similares a las de frecuencia modulada y para su recepción es necesario que no haya obstáculos físicos que lo impidan. En los “para coche” se puede colocar una antena en el exterior, en los GPS “para campo” se intenta ponerlos en lugar adecuado (fuera de la mochila y sin que nuestro propio cuerpo haga de pantalla) y en el caso de las PDAs se busca una posición en la que el receptor pueda comunicarse tanto con los satélites como con la propia PDA. Quizá peor que no recibir las señales sea el recibirlas rebotadas ya que en este caso se pueden producir errores difíciles corregir. Como hemos dicho los cálculos de posición se realizan en base a la distancia que se estima que existe a los satélites; pero si la señal llega al GPS después de rebotar en un edificio, o la pared de un desfiladero, se considerará como distancia al satélite la distancia entre éste y el punto en que rebota, más la distancia desde el punto en que rebota hasta el receptor, es decir una línea quebrada en lugar de una recta, y ello provocará los consiguientes errores.

Apunte CompeGPS es un programa especialmente valorado por los que practican parapente, y recorren grandes distancias en automóvil por zonas sin carreteras. Puede descargarse desde http://www.compegps.com.

Lo peor de la mencionada distorsión es que no es detectable, y por tanto no es fácil de corregir como sucede con las intrínsecas al sistema que están en torno a los 5 metros. En estos últimos casos si se necesita una precisión mayor, por ejemplo en trabajos de topografía, se suele utilizar además del GPS http://digital.revistasprofesionales.com


DISPOSITIVOS MÓVILES

El GPS como “medio de comunicación”

que realiza las mediciones, otro fijo colocado en una posición de coordenadas conocidas. De ese modo como la distorsión en una determinada zona es la misma en un mismo instante de tiempo, se establecen los errores para el punto de coordenadas conocidas y se aplican las correcciones oportunas a las mediciones efectuadas.

Bases de datos e información Los que hemos calificado “para coche” manejan bases de datos de gran tamaño mientras que los “para campo” no suelen disponer de ellas o son de pequeño tamaño, en contraposición estos últimos son más abiertos que los primeros y es fácil añadirles nueva información, aunque por sus limitaciones de memoria no se pueda tener almacenada mucha al mismo tiempo. Aun así la información que puede almacenar uno de tipo medio puede ser el equivalente a 10 recorridos a pie de 20 kilómetros (“tracks”) y 500 puntos de interés (“waypoints”). Estos recorridos y puntos de interés se guardan en formato de texto por lo que se pueden intercambiar fácilmente con un ordenador de sobremesa, de modo que los obtenidos con el receptor GPS los podemos almacenar en el PC y los elaborados a partir del PC los podemos enviar al receptor de GPS. Y una vez que los podemos tener en un ordenador quedan abiertas todas las vías para intercambio de información que facilita Internet, de forma que los recorridos y los puntos captados por una persona en un lugar de la geografía pueden ser utilizados por otra. En la mayoría de los GPS “para campo” los datos relativos a los “wayponts” también se pueden introducir directamente de forma manual aunque es más cómodo hacerlo desde el PC dada la mayor abundancia y tamaño de las teclas. Pero la introducción manual permite que una persona queriendo ir a un lugar determinado cuya posición desconoce, llame por teléfono a un conocido para que le facilite las coordenadas y una vez introducidas en su GPS pueda dirigirse hacia él. A partir de lo anterior también resulta imaginable, aunque en estos momentos no tenemos noticia de que existan los programas adecuados, el siguiente escenario: una PDA con teléfono móvil conectada a un GPS, que reciba los waypoints mediante SMS. De lo que sí tenemos constancia es de la existencia de una combinación de GPS y telefonía que utilizan los pastores de renos de Laponia, de modo que http://digital.revistasprofesionales.com

en caso de emergencia pueden enviar un SMS pidiendo socorro, en el que además de la solicitud de ayuda se muestran las coordenadas del lugar desde donde ha sido enviado.

Coordenadas y datum Cuando se realiza intercambio de información entre particulares, o se utilizan diferentes fuentes de información como datos captados con el GPS y mapas de papel, hay una serie de conceptos que conviene tener claros para transformarlos adecuadamente. No son conceptos demasiado difíciles de utilizar en la práctica, aunque para su completa comprensión sí que se requieran conocimientos complejos. La diferencia entre las coordenadas geográficas y las UTM es algo que salta a la vista, pues mientras las unas se expresan en medidas angulares (grados) las últimas se expresan en unidades métricas. Menos perceptible para el profano es la posible diversidad de los datum, pero ésta puede originar errores considerables. Aunque para transformar la información referida de uno a otro no haga falta entender en toda su complejidad el concepto de datum, sí que debemos saber que en estos momentos los GPS trabajan internamente con el datum WGS84, y que los mapas españoles en su mayoría están referidos al Europeo 1950, y que utilizar uno y otro como si fueran iguales puede originar errores próximos a los 300 metros. El empleo de diferentes datum surge del hecho de que La Tierra es irregular (un geoide) pero necesitamos de un modelo matemático (un elipsoide) sobre el que realizar las proyecciones cartográficas, de este modo cada país, o grupo de ellos, elige un elipsoide concreto y considera que este tiene un punto en común con La Tierra, de forma que las proyecciones cartográficas de su zona presenten la menor distorsión posible. En el caso del datum Europeo 1950, se supone que el elipsoide y el geoide “se tocan” en la torre del observatorio astronómico de la ciudad alemana de Postdam.

Conexión entre GPS y PC La forma habitual de realizar la conexión es mediante un cable que une un puerto específico en el receptor GPS con un puerto serie, o USB, del ordenador. Las características del puerto en el receptor GPS las determina el fabricante y suelen ser tales

que con frecuencia será también a él a quien debamos acudir para comprar esos cables cuyo precio sobrepasa muy de largo los materiales empleados. También hay conexiones inalámbricas; pero por lo general éstas son más empleadas en las conexiones a ordenadores de bolsillo (PDAs). A la conexión física se debe añadir el programa que realiza el intercambio y posibilita la conversión entre diferentes formatos y datos de referencia. Hay varios, entre los que quizá el más popular sea OziExplorer. En cualquier caso un programa para comunicar el ordenador y el GPS debe permitir, al menos, el intercambio de “tracks”, “routes” y “waypoints”, la conversión entre diferentes referencias cartográficas, la inclusión y calibrado de imágenes digitales de mapas y representar sobre ellas los elementos antes enumerados.

Calibrado de mapas Una vez establecida la comunicación entre el PC y el GPS una de las operaciones que tendréis que realizar es la calibración de un mapa, ya que un mapa escaneado sólo es un conjunto de bits que forman una imagen. Estos bits en un primer momento no tienen asignado ningún valor geográfico y por eso debemos “calibrar el mapa” de modo que cada uno de esos puntos quede ligado a unas coordenadas geográficas concretas. Para eso debemos conocer el valor de esas coordenadas en algunos de ellos, marcar esos puntos e introducirlas, de modo que el programa en cuestión pueda a partir de esos puntos cuyas coordenadas conoce, asignar otras a los puntos de las que no las conoce, pero que guardan con ellos una relación de posición en la imagen. Para calibrar un mapa recomendamos el empleo de al menos cuatro puntos no alineados y tan distantes entre sí como nos sea posible. Las proximidades de las cuatro esquinas es algo deseable, pero no siempre nos será posible ya que como hemos dicho los cuatro puntos deben ser de coordenadas conocidas y con frecuencia sólo conoceremos las de aquellos que se corresponden con las intersecciones de la malla de coordenadas de nuestro mapa de papel, por tanto a la hora de comprar nuestros mapas debemos buscarlos con una malla lo más tupida y clara posible. 29

SOLO PROGRAMADORES nº 128


DISPOSITIVOS MÓVILES

Apunte No conviene apurar la zona escaneada hasta el límite, pues la imagen del mapa es muy probable que presente distorsiones en la proximidad de sus bordes, ya que al ser mayor que la pantalla del scanner de sobremesa, el mapa se “arruga” en esa zona al bajar la tapa.

Lo habitual en los scanners de sobremesa es que la zona de barrido sea de tamaño A4 (297x210 mm), si nuestro mapa no tiene la malla lo suficientemente tupida es posible que una vez seleccionada la zona de nuestro interés no haya en ella esas cuatro intersecciones recomendables. Para solucionarlo podemos buscar otros puntos como picos, o vértices geodésicos de los que podamos averiguar las coordenadas. En un proceso muy similar a cuando sobre un mapa de papel trazamos nuestro posible recorrido y marcamos aquellos puntos que nos son de especial interés, sobre el mapa ya calibrado podremos hacer otro tanto; en lugar de lápiz utilizaremos el ratón, y para las anotaciones el teclado. Como ventaja tendremos que esos datos serán aprovechables por nuestro GPS, y los “tracks” y “waypoints” generados en el PC los podremos utilizar en el GPS, bien sea para seguir el recorrido ideado o para obtener la dirección a seguir para llegar a un determinado punto. Sobre el mapa calibrado también podremos ver los datos que se hayan obtenido con el GPS, y podremos analizar las excursiones realizadas.

Mapa móvil El “Moving Mapp” o “mapa móvil” es una de las aplicaciones más vistosas, y cuando no se puede realizar tal función muchos de los que se acercan al mundo del GPS de modo superficial se sienten defraudados, como si todo lo demás careciera de importancia. Consiste en la comunicación entre el GPS y el ordenador de modo que éste represente sobre un mapa de la zona, la posición y desplazamientos del receptor GPS. Es obvio que poco se puede mover nuestro GPS cuando lo tenemos conectado con un cable de poca longitud a nuestro ordenador de sobremesa, salvo que... estemos en una nave en la que se desplazan conjuntamente. Por eso el protocolo NMEA (el primero que posibilitó esta función) fue diseñado pensando en la navegación marítima, aunque pronto se vio que también se podía uti-

SOLO PROGRAMADORES nº 128

30

Figura 6. Conjunto integrado por una PDA, y un receptor GPS con cable para alimentarlo desde la salida del mechero del coche, y una pequeña antena con un imán para colocarla en el exterior del vehículo.

Apunte En http://www.andarines.com/gps podemos encontrar nociones sobre GPS y descarga de ficheros con wayponts y tracks.

lizar en vehículos terrestres, pues una vez que existían programas que lo permitían funcionando sobre sistemas operativos convencionales, muy bien se podían cargar en un PC portátil y alimentar éste con la batería del coche. Aún así los portátiles resultaban demasiado voluminosos, especialmente si se iba caminando, y en muchos casos han sido sustituidos por las PDAs. En las PDAs el GPS puede ir alojado en su interior o ser externo, en este último caso se necesita de algún tipo de conexión, se están imponiendo, por razones de comodidad, las que se realizan sin cables, y entre ellas sobresale la tecnología Bluetooth basada en señales de radiofrecuencia. De este modo podemos llevar una PDA en nuestro bolsillo para cuando queramos consultar los datos recibidos desde el receptor, añadiéndolos a los que ella contiene (por ejemplo el mapa de la zona), y el receptor GPS colocado de modo que pueda captar adecuadamente las señales de los satélites.

Si vuestro GPS es de los que hemos llamado “para campo” y no permite la función “mapa movil”, conviene que desde el PC imprimáis la imagen del mapa con el trazado del “track” y los “waypoints” sobre él, y además el listado de “waypoints”, de modo que en ese papel, que cómodamente podréis llevar en cualquier bolsillo, quedará a vuestra disposición la descripción de cada uno de ellos, y así, aunque por razones de memoria vuestro GPS sólo os permita un nombre breve del tipo “XXXXXX”, también podáis saber que tal punto corresponde con “cruce de caminos donde se debe tomar el de la ...”.

Un caso práctico En combinación con un ordenador, tal como se ha venido describiendo, los receptores GPS constituyen una poderosa herramienta para procesar, elaborar e intercambiar información. A continuación desarrollamos un caso concreto, en el que las acciones que se describen serían comunes a otros casos prácticos en los que los propósitos fueran muy diferentes. Suponemos que queremos informar a una persona sobre cómo, desde una http://digital.revistasprofesionales.com


Grandes proyectos de software

Gestionar un proyecto de software en el que se encuentren involucradas varias personas y haya decenas de miles de líneas de código puede ser muy difícil si no se usan los programas y estrategias adecuadas. Este mes abordaremos los problemas relacionados con la sincronización entre varios programadores y con la depuración del código.

¡Ya en tu quisoko!


DISPOSITIVOS MÓVILES

estación de metro, puede acudir a una pequeña colina desde donde tener una vista sobre una ciudad. En nuestro caso la ciudad es Madrid, la estación de metro la de “Lago”, la colina está situada en la Casa de Campo, y vamos a utilizar sólo las funciones comunes a casi todos los GPS al uso. En el interior del vagón, nuestro receptor no capta de las señales de los satélites, de modo que podemos aprovechar una parte del tiempo del trayecto para borrar “waypoints” y “tracks” que tengamos almacenados en nuestro GPS, esto evitará la posible mezcla entre los datos de nuestro recorrido y otros almacenados con anterioridad. Pondremos especial cuidado en borrar el “Track Log” o “track activo” ya que de no hacerlo, éste quedaría unido al “track” que vamos a generar durante nuestro próximo recorrido. Una vez que hemos borrado todos los datos que pudieran inducir a confusión apagamos nuestro receptor.

Recogida de datos En la plazoleta que hay a la salida del metro encendemos de nuevo nuestro receptor. El terreno es despejado y la captación de los satélites se realiza con facilidad. Pronto nos da el aviso de “listo para navegar” tras lo cual dirigimos nuestros pasos hacia la pequeña colina. Mientras nosotros caminamos el receptor va generando un nuevo “track activo” y almacenando un rosario de coordenadas correspondientes a puntos de nuestro recorrido poco distanciados entre sí. La imagen de ese “track activo” la podemos ver en nuestra pantalla como una línea que va quedando tras un icono, probablemente antropomorfo. Al pasar junto a un añoso taray, nos permitimos marcar un “waypoint”, por si acaso el destinatario de nuestra información estuviera interesado en la botánica (los tarays son frecuentes en terrenos arenosos, y suelen adornar los paseos marítimos de muchas ciudades españolas. La humedad del aire precipita sobre sus hojas filiformes y el reflejo de la luz de las farolas produce vistosos efectos). El GPS nos propone designar a ese “wayponint” como 001, y nosotros, aunque podríamos darle otro nombre lo aceptamos por pura comodidad, pero sí que nos tomamos la molestia de anotar

SOLO PROGRAMADORES nº 128

32

Figura 7. A partir del track generado “in situ” el OziExplorer puede trazar el perfil del recorrido. Será más fiable si el GPS tiene un altímetro pues las coordenadas de altura a partir de los satélites presentan con frecuencia importantes imprecisiones.

en una pequeña libreta “001 un buen ejemplar de taray”. Continuamos nuestro paseo y tras cruzar una pequeña carretera vemos la escalera que asciende por la colina, marcamos con un nuevo “waypoint” y anotamos “002 arranque de la escalera”. Subiendo por ella llegamos a

un mirador que de nuevo marcamos y anotamos “003 mirador de la colina”. Desde el mirador la escalera continúa y nosotros subimos por ella hasta alcanzar el punto más alto de la colina donde las vistas se ven dificultadas por la vegetación. De todos modos marcamos un

Figura 8. Los “tracks” y “waypoints” aparecen sobre el mapa ya calibrado. Tal y como se puede apreciar en la parte inferior de la imagen, una vez que hemos calibrado un mapa a cada píxel de la imagen se le asignan unas coordenadas, y es irrelevante para el OziExplorer que en esas zonas esté representado el terreno, o se trate de los mágenes.

http://digital.revistasprofesionales.com


DISPOSITIVOS MÓVILES

El GPS como “medio de comunicación”

“waypoint” y anotamos en nuestra libreta “004 punto más alto de la colina”. Hemos llegado al final del recorrido y guardamos el “track activo” con el nombre que nos propone el receptor que es la fecha del día. Tras ello apagamos nuestro receptor.

Recuperación de la información En la oficina o la casa, conectamos nuestro GPS al PC, bien al puerto USB o al puerto serie. Arrancamos el programa OziExplorer, y ajustamos su configuración indicando cuál es el modelo de GPS que estamos utilizando, el puerto por el que se comunica, etc. En este mismo menú también aparece una opción para indicar a qué datum están referidas las coordenadas de la información que vamos a intercambiar, debemos tener en cuenta que independientemente del datum que utilice para mostrar las coordenadas, o el del mapa que utilicemos, actualmente tanto el receptor GPS como el programa trabajan internamente con el datum WGS84. Esta es la opción que debemos elegir. Como estamos en un interior el GPS no capta señales de los satélites de modo que podemos encenderlo sin temor a que nuevos datos se añadan a los captados en nuestro recorrido. Cargamos un mapa calibardo en el OziExplorer, puede ser el “mapa en blanco”, o incluso uno que no sea de la zona, pero lo mejor es que sea uno de la zona debidamente calibrado. Y en la pestaña en la que aparece la marca de nuestro GPS elegimos la opción “Obtener waypoints del GPS” y cuando la operación se haya realizado procedemos a “Obtener tracks del GPS”. Si lo que hemos cargado es el mapa de la zona en que están esas coordenadas, o el “mapa en blanco” que contiene una amplia zona del globo terráqueo, los “waypoints” y los “tracks” aparecerán en nuestra pantalla. Si el mapa fuera de una zona que no contiene esas coordenadas no aparecerán en pantalla; pero estarán igualmente cargados en la memoria de nuestro ordenador. En estas operaciones el ordenador ha copiado todos los “waypoints” y “trakcs” que contenía nuestro GPS, y por eso antes de iniciar nuestro paseo borramos todos los datos que no fueran pertinentes, pues de otro modo ahora también los habría arrastrado y no serviría más que para confundirnos. En nuestro caso concreto el http://digital.revistasprofesionales.com

Figura 9. En la ventana de “control de tracks” podemos ver cómo el “track” guardado tiene menos puntos que el “activo”, en consecuencia el trazado es menos sinuoso y en la casilla de “distancia” ésta tiene un valor menor que la del “activo”.

ordenador nos ha traído los cuatro “waypoints” que marcamos en su momento y dos “tracks” muy similares. El que nos haya traído dos tracks puede sorprendernos en un primer momento; pero debemos tener en cuenta que al finalizar nuestro recorrido guardamos el “track”, con lo que quedó como “guardado” a la par que se mantuvo como “track activo”, aunque apagáramos el receptor. Estos dos “tracks” son muy similares pero el guardado tiene menos puntos; se trata de una simplificación del activo, y en nuestro caso se trata de 16 puntos y 132 respectivamente como podemos ver el la ventana de “control de tracks” Los ficheros de “tracks” y “waypoints” ya están listos para poderlos guardar en el PC. Y así conviene que lo hagamos. Una vez que lo hayamos hecho tendremos unos ficheros que podremos enviar como adjuntos en cualquier e-mail o ponerlos en una página web para que se puedan descargar. Al guardarlos les tendremos que asignar un nombre y el OziExplorer se encargará de añadir la extensión “.wpt” a los de “waypoints” y la “.plt” a los “tracks”. En cualquier caso se trata de ficheros que podremos abrir con un procesador de textos (y obviamente, también con el OziExplorer). Por lo que se refiere a los dos ficheros de

“tracks” que reflejan un mismo recorrido, lo mejor es optar por sólo uno de ellos, y probablemente lo mejor es decidirnos por utilizar el más pequeño. En nuestro caso concreto ninguno de los dos es muy extenso dada la brevedad de nuestro recorrido, pero si se tratara de una caminata de 20 kilómetros el correspondiente al del “tracks activo” podría rondar los 10.000 puntos y esto no sólo hará más lenta su transmisión si no que también podría ocasionar pérdidas de información, como explicaremos más adelante.

Edición de los waypoints Como ya hemos dicho nuestros ficheros ya están listos para la entrega a segundas personas; pero será mejor que nos tomemos algún pequeño trabajo. Haciendo doble clic sobre el pequeño círculo con que se representan los “waypoints” en la pantalla nos aparecerá una ventana en los que podremos cambiarles el nombre y añadirles alguna información complementaria. En nuestro caso el nombre de los wapoints, 001, 002, 003 y 004, lo cambiamos por A1TARAY, A2ESCALERA, A3MIRADOR y A4ALTO. Explicamos la razón de porque hemos puesto semejantes nombres: La “A” común a todos ellos permitirá que perma33

SOLO PROGRAMADORES nº 128


DISPOSITIVOS MÓVILES

Figura 10. Si enviamos el “track” desde el ordenador como “activo” el GPS admitirá una mayor cantidad de puntos. Si lo enviamos como “guardado” debemos tener muy en cuenta la capacidad de almacenaje para este tipo de “track” pues de lo contrario podríamos perder información. Si lo enviamos como “track activo” no hay posibilidad de darle un determinado nombre ya que lo que hará es instalarse como “activo” en el GPS y “activo” sólo hay uno; pero si lo hacemos como “guardado” sí que podemos hacerlo.

nezcan agrupados cuando los volquemos a un GPS, el número los mantendrá ordenados según la secuencia del recorrido, y el resto de las letras hace referencia al objeto. Al volcarlos a un GPS y dependiendo del modelo, es posible que se pierdan algunas letras (algunos modelos sólo permiten 6) pero a nuestro modo de ver siempre será preferible “A2ESCA” para designar una escalera que “002”, y la razón de que hayamos esperado hasta ahora para hacerlo es que es mucho más cómodo hacerlo con el teclado del ordenador, que con las pocas y pequeñas teclas de que disponemos en un receptor de GPS. A cada un de los “wayponts”, también le podremos asignar una breve descripción similar a las anotaciones que hicimos en nuestra libreta y de ese modo el “A2ESCALERA” quedará descrito como “cominezo de la escalera para subir a la colina”.

Desde el otro lado Una vez hayamos hecho llegar los ficheros a la persona con la que queremos compartir la información, ella podrá verlos reflejados sobre el mapa calibrado de la zona y analizarlos. Por ejemplo podrá ver la distancia recorrida, los desniveles, el perfil del itinerario y dispondrá también de la información complementaria que hayamos incluido. También podrá modificar los ficheros; pero está claro que si lo que quiere es servirse de una información tomada “in situ” deberá respetarla en lo fundamental. Y desde luego que esos ficheros podrá pasarlos a su GPS. Teniéndolos cargados en el OziExplorer basta con que en el menú de configuración elija su modelo de GPS, puerto de comunicación, etc. Y luego acuda a la

SOLO PROGRAMADORES nº 128

34

pestaña en la que aparece la marca de su receptor y elija sucesivamente las opciones “Enviar wayponts al GPS” y “Enviar tracks al GPS”. Hecho esto deberá comprobar cuál es la información que ha grabado y cuál es la que ha perdido. Si su modelo es gama baja lo más probable es que los nombres de los “waypoints” queden reducidos a 6 caracteres y que pierda las descripciones. Pero esto tiene un arreglo relativamente sencillo, desde el menú de impresión puede imprimir el listado de los “waypoints” y ahí sí que tendrá todos los datos, en un papel que podrá llevar cómodamente y le será de gran utilidad. La pérdida de información puede ser realmente grave cuando se trata de “tracks”. Si volcamos un fichero que desborda la capacidad de almacenaje de nuestro receptor de GPS, a medida que vayan entrando los puntos que rebasan esa capacidad iremos perdiendo los primeros que hemos introducido. Por ejemplo, si nuestro fichero de “track” consta de 700 puntos y nuestro GPS sólo es capaz de almacenar 500, al final del proceso sólo tendremos almacenados del 201 al 700, y todo ello ocurrirá de forma silenciosa y sin que recibamos ningún tipo de aviso. Cuando tenemos un track muy voluminoso en nuestro ordenador podemos volcarlo al GPS como “track activo” y luego guardarlo. De ese modo el GPS, de gama media, admitirá en torno a los 10.000 puntos que luego reducirá de forma selectiva a 500, o los que sea capaz de almacenar como track guardado. También el OziExplorer tiene un función denominada “filtrado de tracks” con la que podemos reducir el número de puntos utilizando criterios similares a “eliminar todos los puntos que estén a menos de 20 metros

del siguiente”. Elegir reflexivamente esos criterios es fundamental para la obtención de un “track” simplificado, pero útil.

Con la cartografía tradiccional De la cartografía impresa sobre papel también podemos obtener datos para introducirlos en nuestro GPS. La forma más cómoda de hacerlo es escanear y calibrar con el OziExplorer, la imagen de un mapa. Sobre ella podremos idear recorridos y marcar “waypoints” que posteriormente pasaremos al GPS. De este modo, y aplicando esto al ejemplo que se ha propuesto, podríamos haber comenzado escaneando y calibrando un mapa de la zona para luego trazar sobre él el “track” y los “waypoints” que consideráramos convenientes para luego cargarlos en el GPS. Una vez hubiéramos llegado al punto de inicio de nuestra exploración, podríamos servirnos de nuestro dispositivo GPS para ir siguiendo el recorrido, mientras que simultáneamente podríamos estar recogiendo nuevos “waypoints” más precisos y fiables que los anteriores.

Conclusiones Después de leer este artículo, el lector debería ser capaz de distinguir los tipos de GPS que existen y, mediante uno de estos dispositivos, obtener la información de la ruta y transmitirla al ordenador, para poder compartirla, a la vez que debería ser capaz de adquirir información de rutas en forma de “waypoints”, transmitirla al dispositivo GPS para disponer de una gran ayuda a la hora de iniciar una excursión. Si hemos conseguido acercar al lector al mundo del GPS, damos nuestro objetivo por cumplido. http://digital.revistasprofesionales.com


MIDDLEWARE

Struts práctico (y III) ÓSCAR ARANDA CRESPO (Arquitecto J2EE)

En esta última entrega del curso que hemos dedicado a Struts, conoceremos algunos de los aspectos más avanzados que ofrece este framework, centrándonos sobre todo en aquellos orientados al desarrollo en equipo. Introducción Un aspecto muy importante a tener en cuenta a la hora de seleccionar un framework es su facilidad para el desarrollo y mantenimiento de aplicaciones de cierto volumen y programadas por equipos de desarrollo más o menos grandes. En este artículo veremos dos de las soluciones que nos aporta Struts en este sentido (uso de action forms dinámicos o DynaActionForms y la división de las aplicaciones en módulos). Además veremos una alternativa al uso de los dataSources gestionados por el contenedor y una sencilla solución al famoso problema del doble clic (o doble POST) que siempre hay que tener en cuenta en el desarrollo de aplicaciones basadas en un cliente HTML (navegador web). Para terminar la serie haremos una breve comparativa de Struts frente a otros frameworks MVC2 que a día de hoy, también tienen su hueco dentro de la comunidad Open Source.

DynaActionForms

Material complementario El lector encontrará en http:// digital.revistasprofesionales.com el material complementario de este artículo.

SOLO PROGRAMADORES nº 128

36

En el primer artículo de este curso, presentábamos los componentes esenciales que debíamos desarrollar en una aplicación bajo Struts. Uno de estos componentes eran los denominados ActionForms que, si recordamos, eran esencialmente clases JavaBean que contenían los datos enviados en un formulario HTTP. Si además estos JavaBeans implementaban el método “validate()”, estos objetos actuaban de firewall ya que se impediría la ejecución del Action correspondiente si los datos enviados no se consideran válidos.

Una de las pocas críticas que recibieron las primeras versiones de Struts, fue que se consideraba que era tedioso tener que crear una clase ActionForm por cada formulario (clase sencilla pero que suponía tener los correspondientes métodos “get()” y “set()” de cada dato). Esto además suponía un problema en la teórica separación de roles, ya que tanto los diseñadores de JSP como los programadores de los Actions, debían ponerse de acuerdo en los campos de los formularios, pues si no se producirían errores. Los desarrolladores demandaron alguna forma más ágil y dinámica de declarar estos componentes por lo que desde la versión 1.1 de Struts se cuenta con los DynaActionForms. Como se ha comentado, mediante los DynaActionForms evitamos tener que implementar una clase Java por cada formulario de nuestra aplicación. A cambio deberemos especificar en el fichero “struts-config.xml” los campos y los tipos de datos de cada ActionForm. La forma de declarar cada formulario es muy sencilla, el lector puede comprobarlo observando el listado 1. Como se puede ver, la diferencia con la definición de un ActionForm tradicional reside en que se añaden las etiquetas “<form-property>” para definir cada uno de los campos del formulario. Para cada campo hay de declarar su nombre (“name”), el tipo de dato (“type”) y opcionalmente un valor inicial (“initial”). Los tipos de datos aceptados por los ActionForms de tipo DynaActionForm son: “BigDecimal”, “BigInteger”, “Boolean”, “Byte”, “Character”, “Double”, “Float”, “Integer”, “Short”, “Long”, “String” (del paquete “java.lang”) y los tipos “Date”, “Time” y “Timestamp” de “java.sql”. También se pueden declarar los campos con un tipo primitivo (“int”, “char”, “float”, etc.) aunque internamente se convertirán a las correspondientes clases del paquete “java.lang”. A la hora de acceder a los valores del formulario desde los Actions, dispondremos de un único método “get()”, al que indicaremos como argumento el nombre del campo del que queremos obtener el valor. Podemos pensar en los DynaActionForms como si fuesen HashMaps (de hecho, los DynaActionForms almacenan los valores en una instancia de “java. http://digital.revistasprofesionales.com


MIDDLEWARE

Struts práctico (y III)

LISTADO 1

Declaración de un formulario en struts-config.xml

<form-bean name=”userForm” type=”org.apache.struts.action.DynaActionForm” > <form-property name=”<propiedad1>” type=”java.lang.String” initial=”valor1”/> <form-property name=”<propiedad2>” type=”java.lang.Integer” initial=”valor2”/> …… <form-property name=”<propiedadN>” type=”java.lang.Double” initial=”valor3”/> </form-bean>

util.HashMap”). Debido a que el método “get()” devuelve un objeto de tipo “Object”, debemos hacer casting del valor devuelto a la clase con la que fue declarada en el fichero “struts-config.xml” (exactamente igual que ocurre cuando utilizamos un objeto “HashMap” o cualquier otra colección). Lo mejor será ver un ejemplo en la aplicación Sp.Shop. Hemos sustituido el ActionForm “datosRegistro” (implementado en la clase “RegistrarAction”) por un nuevo ActionForm denominado “dynaDatos Registro”. En el fichero “struts-config.xml” hemos declarado el nuevo ActionForm con todos los campos del formulario. A continuación tenemos un ejemplo del Action “RegistrarAction” que recoge los datos del ActionForm para luego invocar el comando “UsuarioCmd” y efectuar así el alta del nuevo usuario registrado:

DynaActionForm datos = (DynaActionForm) form; String usuario = (String)datos.get(“usuario”); String nombre = (String)datos.get(“nombre”); String apellido1 =

Hasta ahora hemos visto la forma de evitar programar una clase Java por cada ActionForm que declaremos en el fichero “struts-config.xml”. Sin embargo hemos perdido la opción de poder sobrescribir en cada una de estas clases el método “validate()” y por tanto efectuar la validación de los datos enviados. Esto tiene una primera solución si creamos una clase que herede de “org.apache.struts.action. DynaActionForm” y que sobrescriba dicho método “validate()”. Pero bien pensado esta solución no es demasiado buena.

(String)datos.get(“apellido1”);

LISTADO 2

DynaActionForms con validación

<form-bean name=”dynaDatosRegistro” type=”org.apache.struts.validator.DynaValidatorForm”> <form-property name=”nombre” type=”java.lang.String” /> <form-property name=”apellido1” type=”java.lang.String” /> <form-property name=”apellido2” type=”java.lang.String” /> <form-property name=”direccion” type=”java.lang.String” /> <form-property name=”localidad” type=”java.lang.String” /> <form-property name=”cp” type=”java.lang.String” /> <form-property name=”provincia” type=”java.lang.String” /> <form-property name=”pais” type=”java.lang.String” /> <form-property name=”telefono” type=”java.lang.String” /> <form-property name=”email” type=”java.lang.String” /> <form-property name=”usuario” type=”java.lang.String” /> <form-property name=”contrasena” type=”java.lang.String” /> <form-property name=”contrasena2” type=”java.lang.String” /> </form-bean>

Figura 1. Los DynaActionForms suponen, en algunos casos, una buena alternativa para la implementación de formularios web. http://digital.revistasprofesionales.com

DynaActionForms con validación

Hay que tener en cuenta que cada formulario tiene unos campos y unas reglas de validación distintas, por lo que parece poco realista el tener un único método “validate()” para todos los formularios dinámicos. Mediante esta solución tendríamos que crear una clase hija de “DynaActionForm” con un método distinto de validación por cada ActionForm dinámico que usásemos, por lo que ya estamos teniendo que codificar una clase Java por cada formulario, cosa que queríamos evitar y era el motivo principal por el que usar los ActionForms dinámicos. Afortunadamente contamos con una segunda opción que no contiene los inconvenientes de la primera. En el segundo artículo sobre Struts hablamos del componente Validator de Struts. Esencialmente este componente nos permitía declarar en un fichero XML las reglas de validación que debían de cumplir los campos de un formulario para considerarse válido. La solución más sencilla para permitir validación con el 37

SOLO PROGRAMADORES nº 128


MIDDLEWARE

uso de DynaActionForms es usarlo en combinación con el componente Commons Validator. Para que dicha combinación sea posible, únicamente necesitaremos indicar que la clase que implementará nuestro form-bean será “org.apache.struts.validator.DynaValidat orForm”. Simplemente con este cambio (y por supuesto, habiendo definido las reglas de validación oportunas en el fichero “validations.xml”) conseguimos que antes de invocar a nuestro Action, se realice la validación de los datos enviados. Recordemos que en el artículo anterior ya habíamos definido las reglas de validación del formulario de registro, por lo que simplemente tenemos que cambiar el atributo “type”. Finalmente el formbean quedará como muestra el listado 2.

de error en el que fácilmente podríamos incurrir sería hacer el casting al obtener el valor de un campo a un tipo distinto del indicado en el fichero “struts-config.xml”. De nuevo este error no se detectaría hasta la ejecución de la aplicación. Un inconveniente adicional para el uso de DynaActionForms es que la definición de los campos de los formularios se debe hacer en un único fichero XML. En aplicaciones grandes esto puede causar un grave problema pues se supone que múltiples desarrolladores deben editar el mismo fichero, con los problemas que todos sabemos que puede conllevar eso. Más adelante veremos cómo resolver este problema mediante “módulos”.

Utilidad de los DynaActionForms

Cualquiera que haya participado en el desarrollo de alguna aplicación web, tarde o temprano se habrá encontrado con el famoso problema del doble clic. El problema del doble clic (o en general, del multi clic) se produce cuando el usuario de la aplicación web envía la misma petición al servidor múltiples veces. Esto, en muchos casos, se produce cuando el usuario pulsa por ejemplo sobre un botón o un enlace para enviar un formulario. Sí no se obtiene una respuesta en un corto espacio de tiempo, el usuario es probable que vuelva a pulsar el mismo botón, lo que resultará en el envío de la misma petición por segunda vez. Esto normalmente no supondrá un problema, simplemente se procesará la misma petición dos veces con el consiguiente aumento innecesario de la carga del servidor. Pero en aquellos casos en los que el procesamiento de la petición suponga realizar una transacción, el procesar varias veces la misma petición puede ocasionar problemas de consistencia de datos. En el caso de, por ejemplo, una tienda por Internet (como nuestra aplicación de ejemplo Sp.Shop) pensemos en la operación de efectuar un pedido. Si una vez rellenados los datos de pago y de envío el usuario pulsa dos veces sobre el botón de aceptar, se ejecutará dos veces en paralelo el proceso de creación de un mismo pedido y la aplicación puede acabar generando dos pedidos iguales. El mismo problema se puede

Una vez vistos los denominados DynaActionForms, nos queda responder a la pregunta ¿Qué hemos ganado? Dentro de la comunidad de usuarios de Struts, existen muchos detractores de este tipo de ActionForms. Se supone que el motivo principal por el que surgió este tipo de formularios está en la necesidad de facilitar el desarrollo y mantenimiento de las aplicaciones pues se consideraba bastante tedioso tener que escribir las clases ActionForms tradicionales. Sin embargo con los DynaActionForms tenemos que declarar los campos de cada formulario en el fichero “strutsconfig.xml”, por lo que hemos cambiado el tener que desarrollar/mantener clases Java por ficheros XML. Por el contrario, hemos perdido un control de tipos más fuerte, ya que por ejemplo si desde un Action se solicita el valor de un campo y no se indica su nombre correctamente (por ejemplo “datos.get(“monbre”)” en lugar de “datos.get(“nombre”)”) el error no se detectará hasta que ejecutemos la aplicación. Mientras que si hubiésemos usado los ActionForms tradicionales, cada campo tendría un método (“getNombre()”) por lo que si nos hubiésemos confundido al teclear el nombre del método, el compilador de Java nos hubiese avisado del error (siempre es preferible obtener errores de compilación que errores de ejecución). Otro tipo

SOLO PROGRAMADORES nº 128

38

Problema del doble clic

llegar a producir si una vez confirmado el pedido, el usuario pulsa el botón de “volver” del navegador y vuelve a pulsar el botón de tramitar un nuevo pedido. Struts de nuevo nos ayuda a resolver de forma sencilla este problema mediante la gestión de tokens.

Gestión de tokens La solución que nos propone Struts se basa en el concepto de token. Un token consiste en un identificador único de transacción. La idea consiste en que generaremos un token cuando iniciemos una transacción (por ejemplo, cuando el usuario pulse sobre el botón de tramitar pedido). Este token se guarda en la sesión de usuario mientras dure la transacción. Si hemos usado la etiqueta “<html:form>” de la librería de etiquetas JSP de Struts, el formulario incluirá automáticamente un campo oculto con el token que se encuentre en sesión. Cuando vayamos a cerrar la transacción (en nuestro caso, cuando el Action “TramitarPedidoAction” invoque a la lógica de negocio para insertar un nuevo pedido) se comprobará que el token es válido, esto es, que el valor del campo oculto recibido coincide con el valor almacenado en la sesión. Si estos valores son iguales, la transacción es válida y se elimina el token de la sesión de modo que, si volviese a llegar una petición con el mismo número de token (por algún caso de doble clic, o pulsación del botón “volver” del navegador), este se detectaría, pues el token se eliminó de la sesión y por lo tanto la transacción se dio por terminada en alguna petición anterior. A través de la clase Action tenemos varios métodos disponibles:  s a v e T o k e n ( ) . Este método genera un nuevo token y lo almacena en sesión. A partir de la llamada a este método, se considera que ha comenzado la transacción y las próximas peticiones que lance el navegador sólo serán procesadas una vez.  i s T o k e n V a l i d ( ) . Sirve para preguntar si el token sigue siendo válido. Este método será invocado antes de realizar la llamada a la lógica de negocio para comprobar que la petición actual es la primera vez que ha sido enviada. http://digital.revistasprofesionales.com


MIDDLEWARE

Struts práctico (y III)

Figura 2. Diagrama de secuencia de un doble clic.

LISTADO 3



Sincronizando el acceso a isTokenValid()

HttpSession session= request.getSession(); synchronized (session) { if (isTokenValid(request,true)== false ) { errors.add(“error”, new ActionMessage( “error.comun.dobleclick”)); saveErrors(request, errors); return mapping.findForward(“error”); } // resto de codigo }

LISTADO 4

DataSource para Sp.Shop

<data-sources> <data-source type=”org.apache.commons.dbcp.BasicDataSource” key=”spshopDB”> <set-property property=”driverClassName” value=”org.hsqldb.jdbcDriver” /> <set-property property=”url” value=”jdbc:hsqldb:/db/spshop” /> <set-property property=”username” value=”sa” /> <set-property property=”password” value=”” /> </data-source> </data-sources>

http://digital.revistasprofesionales.com



r e s e t T o k e n ( ) . Elimina el token actual de la sesión y debe invocarse cuando damos por terminada la transacción. De esta manera indicaremos que las próximas peticiones que se reciban con el mismo identificador de transacción se consideren no válidas. Si el método “isTokenValid()” se invoca con el argumento “reset” a true, el método “resetToken()” se ejecuta automáticamente si el token es válido. g e n e r a t e T o k e n ( ) . Este método nos devolverá un nuevo token de transacción pero no se almacenará en sesión. Este método sólo se usa en caso de que queramos hacer una gestión manual de tokens distinta a la proporcionada por defecto por Struts. 39

SOLO PROGRAMADORES nº 128


MIDDLEWARE

El diagrama de secuencia de la figura 2 muestra el funcionamiento de dos peticiones iguales lanzadas en paralelo. Se puede observar cómo la segunda petición no llega a procesar el pedido pues se detecta que es inválida. Hay una consideración adicional que debemos tener en cuenta. Cabe la posibilidad de que se envíen dos o más peticiones iguales prácticamente al mismo tiempo (por ejemplo, haciendo rápidamente dos clics sobre el botón de tramitar pedido). En estos casos, podría darse el caso en el que los dos threads que ejecuten concurrentemente el Action “TramitarPedidoAction”, invoquen a la vez al método “isTokenValid()” y cabría la posibilidad de que ambos devolviesen “true” ya que dicho método no está sincronizado. Para evitar este caso, en dicho Action sincronizaremos la llamada al método “isTokenValid()” sobre el objeto “sesion” para que dos threads con peticiones de un mismo usuario no puedan entrar a la vez a ejecutar el método “isTokenValid()”. En el Action “TramitarPedidoAction” podemos ver un ejemplo (véase el listado 3).

Figura 3. Módulos de Sp.Shop.

ubicación del driver JDBC, usuario/contraseña de conexión, configuración de tamaño de pools, etc). A pesar de esto, Struts nos proporciona una forma alternativa de definir y acceder a estos recursos. Y el lector se preguntará, ¿Y por qué permite Struts hacer de forma distinta lo

Declarando varios ficheros de configuración en el descriptor de despliegue

LISTADO 5

<servlet> …… <init-param> <param-name>config</param-name> <param-value> /WEB-INF/struts-config.xml, /WEB-INF/struts-config2.xml, /WEBINF/struts-config3.xml </param-value> </init-param> …… </servlet>

DataSources con Struts Un recurso muy común que suelen requerir las aplicaciones es lo que se conoce como fuente de datos o dataSources para poder conectarse a una base de datos mediante JDBC. Según la especificación J2EE estos recursos deben ser proporcionados por el contenedor web y deben ser accedidos por las aplicaciones mediante JNDI. Es en el tiempo de despliegue de la aplicación, cuando el administrador del servidor de aplicaciones debe crear y configurar estas fuentes de datos (indicar

SOLO PROGRAMADORES nº 128

40

LISTADO 6

mismo que ya se contempla en la especificación? Pues la respuesta está en que el uso de los dataSources proporcionados por Struts tiene algunas ventajas que los hacen aconsejables en ciertas circunstancias:  La definición del datasource se hace dentro de la aplicación por lo que no requerimos definir los dataSources en el contenedor (paso que es específico de cada fabricante de servidores J2EE).  Para obtener el dataSource lo haremos mediante el método heredado de Action, “getDataSource()”. No es necesario obtener los objetos desde un contexto JNDI (cosa que a veces también es dependiente del servidor de aplicaciones).

Definiendo los tres módulos de la figura 3 en web.xml

<servlet> <servlet-name>action</servlet-name> <display-name>ActionServlet</display-name> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class> <init-param> <param-name>config</param-name> <param-value>/WEB-INF/struts-config.xml</param-value> </init-param> <init-param> <param-name>config/cat</param-name> <param-value>/WEB-INF/struts-config-cat.xml</param-value> </init-param> <init-param> <param-name>config/ped</param-name> <param-value>/WEB-INF/struts-config-ped.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet>

http://digital.revistasprofesionales.com


NÚMEROS ANTERIORES 127 - Julio 2005

126 - Junio 2005

Presente y futuro de IPv6, Java Expo 2005, Inteligencia Ambiental, desarrollo de un servicio de distribución de Midlets según el modelo OTA y basado en IIS, tipos Generics en .NET 2.0 para C# y VB, Struts, programación web ágil con ColdFusion MX 7, generación de código a partir de modelos con EMF, programación avanzada con el API Win32 y C. 1 CD-ROM incluido.

Un integrante del equipo de desarrollo de NetBeans nos cuenta algunos de los secretos de la futura versión 4.2, desarrollo de un juego de calidad comercial con J2ME, algunas novedades en .NET 2.0, curso práctico sobre programación J2EE con Struts, aplicaciones web con ColdFusion, programación de una aplicación JMS y acceso al corazón de Windows con el API Win32. 1 CD-ROM incluido.

125 - Mayo 2005

124 - Abril 2005

Configuración de un entorno de desarrollo para programar con J2ME sobre teléfonos NOKIA, Construyendo J2EE con Ant, Servicios web con .NET Remoting, MSMQ y Enterprise Services, animaciones y 3D en XAML, sistemas de mensajería con JMS, luchando contra los problemas de rendimiento, programación eficaz con el API Win32 y C, las novedades de los lenguajes de .NET 2.0 y la novena entrega del coleccionable ASP.NET. 2 CD-ROMs incluidos.

El proceso de certificación como arquitecto J2EE al detalle, J2ME y APIs adicionales, .NET Remoting práctico, acceso a datos desde XAML, sistemas de mensajería con JMS, Together Architect como enlace entre el problema y la solución, patones de diseño con C++ y ACE, y la octava entrega del coleccionable ASP.NET. 1 CD-ROM incluido.

123 - Marzo 2005 Longhorn desde la óptica del desarrollador, juegos de calidad comercial para Nokia, personalización de IGUs con XAML, introducción a la programación distribuida sobre .NET, los secretos de SQL Injection, Servlets filters, ingeniería del software vs. “desarrollo ágil”, código C++ multiplataforma y la séptima entrega del coleccionable ASP.NET. 1 CD-ROM incluido.

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

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

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

 

FORMAS DE PAGO

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


MIDDLEWARE

Comparativa de frameworks MVC2 Struts

JSF

SpringMVC

WebWork

Tapestry

URL

struts.apache.org

java.sun.com/j2ee/ javaserverfaces

www.spring framework.org

opensymphony.com/we jakarta.apache.org/ bwork tapestry

Tecnología Vista

JSP (otras)

JSP

JSP (otras)

JSP,Velocity, XML/XSLT

Tapestry templates

Validación

commons validator

En componente

commons validator

XWorks

Tapestry

Test unitarios

Media (Junit + StrutsTestCase)

Media

Fácil (Junit+jMock)

Fácil (Junit+jMock)

Difícil

H e r r a m i e n t a s Muchas (gratuitas)

Muchas (comerciales)

Algunas

EclipseWork

Spindle

Documentación Abundante

Abundante

Creciendo

Muy escasa

Escasa

Popularidad

Muy extendido

Creciendo

Creciendo

Poco extendido

Poco extendido

Dificultad de Uso

Muy baja

Media

Baja

Media

Muy Alta

En definitiva, ganamos en simplicidad pero sin embargo, si nuestro contenedor nos proporciona características adicionales que queramos usar en nuestras aplicaciones (configuración especial de pools, etc) recomendamos usar las fuentes de datos gestionadas por el contenedor. Struts implementa un pool de dataSources sencillo basado en el también proyecto de Jakarta commons DBCP. Por esto, si usamos esta característica de Struts debemos añadir las librerías “commons-dbcp1.2.1.jar” y “commons-pool-1.2.jar” al directorio “WEB-INF/lib” de la aplicación web. Para definir una fuente de datos en Struts, lo haremos en el fichero de configuración “struts-config.xml”. El listado 4 muestra el dataSource que utilizaremos en la aplicación Sp.Shop (HSQLDB). Como podemos ver la etiqueta “datasource” define mediante el atributo “type” la clase que implementará la interfaz “javax.sql.DataSource”. En nuestro caso usaremos la clase “BasicDataSource” de DBCP, que además implementa internamente un pool de conexiones con lo cual nos servirá para dar servicio a un entorno concurrente como es un servidor de aplicaciones. Opcionalmente, daremos un nombre al dataSource que estamos definiendo (atributo “key”) para luego poder referirnos a él, ya que podemos requerir conexiones a más de una fuente de datos. A continuación se establecen las propiedades necesarias para que la clase indicada en el atributo “type” pueda crear el

SOLO PROGRAMADORES nº 128

42

objeto “javax.sql.DataSource”. En el caso de usar el “BasicDataSource” de DBCP, es necesario indicar al menos las propiedades:  d r i v e r C l a s s N a m e : Nombre de la clase que implementará el driver JDBC. Esta clase suele encontrarse en el .JAR del driver JDBC proporcionado por el fabricante de la base de datos a la que accedemos y por supuesto, debe ser incluida en el CLASSPATH de ejecución (razón por la que nosotros tenemos que copiar el fichero “hsqldb.jar” en el directorio de librerías comunes de Tomcat).  u r l : URL para identificar la base de datos a la que queremos acceder.  u s e r n a m e : Usuario con el que se realizarán las conexiones a la base de datos.  p a s s w o r d : Contraseña del usuario para la conexión.

Módulos Ya hemos visto que una de las principales características de Struts reside en su capacidad de poder declarar una parte muy importante de la funcionalidad de las aplicaciones en ficheros XML. Esto sin duda conlleva muchas ventajas (especialmente de cara al mantenimiento) pero también implica algunos problemas a la hora de plantear el desarrollo en equipo. El hecho de que la mayor parte de esta configuración declarativa resida en un único fichero (“struts-con-

fig.xml”) puede llegar a ser una fuente de problemas importante en equipos de desarrollo que pasen de cuatro o cinco personas. Por este motivo, Struts fue criticado en sus primeras versiones y rápidamente se ofrecieron un par de soluciones a este problema. La primera solución es muy sencilla y consiste en indicar una lista de ficheros (separada por comas) en el parámetro “config” que asignábamos al Servlet controlador de Struts (“WEB-INF/ web.xml”). Esta solución es equivalente a “pegar” los ficheros uno detrás de otro según el orden indicado. El ejemplo del listado 5 muestra el trozo del descriptor de despliegue de una aplicación Struts con varios ficheros de configuración. Esta solución no es completa, pues pueden existir dependencias entre los distintos ficheros (un ActionForm definido en un fichero puede ser referenciado sin problemas desde algún ActionMapping de otro fichero de configuración distinto). Lo ideal en estos casos para evitar estos problemas de dependencias es dividir las aplicaciones en módulos con cierto grado de independencia, y que cada uno de estos módulos tenga su propio fichero de configuración. Esto quiere decir que cada módulo definirá sus propios ActionForms y ActionMappings y un módulo no podrá de forma directa usar objetos definidos en otros módulos. Pensemos en la aplicación Sp.Shop. Podríamos dividir la aplicación en tres módulos independienhttp://digital.revistasprofesionales.com


MIDDLEWARE

Struts práctico (y III)

tes. Un primer módulo para el subsistema responsable del catálogo (al que llamaremos “cat”). Otro para la gestión de los pedidos (“ped”) y el resto de funcionalidades (login, registro de usuarios y menús) lo dejaremos en el módulo por defecto (“/”). La figura 3 nos muestra la aplicación Sp.Shop con esta nueva distribución. Para configurar Struts de forma que se definan los tres módulos comentados (cada uno con su fichero XML de configuración), es necesario modificar los parámetros de inicialización del servlet controlador de Struts (“Action Servlet”) en el fichero “WEBINF/web.xml” (véase el listado 6). Como se puede ver, simplemente tenemos que añadir un parámetro por cada módulo que queramos configurar. El nombre del parámetro será “config” seguido del nombre del módulo (en blanco para el módulo por defecto). Como valor se indicará la ubicación del fichero XML de configuración. Esto realmente lo que significa es que las URLs o URIs necesarias para invocar a los Actions de cada uno de los módulos deben incluir el nombre del módulo antes del nombre del Action. Así, por ejemplo, para invocar al Action “mostrarCategoria” ahora la URL será: http://<servidor>:<puerto>/spshop/cat /mostrarCategoria.do

Lo mismo ocurre con las referencias en los elementos forward a páginas JSP. Se entiende que cada vez que se indique una JSP se le antepondrá el nombre del módulo. Por lo que si un action hace forward a “/homeCatalogo.jsp”, dado que estamos en el módulo “/cat”, Struts buscará en la ubicación física “/cat/ homeCatalogo.jsp” dentro del modulo WAR (cuidado, en el fichero “struts-config.xml” no tenemos que incluir el prefijo del módulo, Struts lo antepone por defecto). De esta manera se nos obliga a separar las JSP de cada módulo en distintas carpetas logrando así un mayor grado de independencia entre las distintas partes de la aplicación.

Interacción entre módulos Como hemos visto los módulos están diseñados para dividir las aplicaciones http://digital.revistasprofesionales.com

Figura 4. Gracias a la aplicación Sp.Shop, a lo largo del curso hemos podido experimentar con Struts de un modo totalmente práctico.

en zonas independientes donde cada módulo tiene su propio fichero de configuración, sus propios “ActionsForms”, “ActionMappings” y páginas JSPs. Pero, ¿Qué pasa si una página de un módulo muestra un link a un Action de otro módulo? ¿Y si un Action quiere redirigir a una JSP de otro módulo? Volvamos a la figura 3. Ahí representábamos la separación que hemos hecho de los Actions que forman Sp.Shop en tres módulos. Las flechas simbolizan las relaciones entre los distintos módulos. Normalmente estas flechas deberían ser entre elementos del mismo módulo, pero muchas veces estas relaciones son entre componentes de distintos módulos. Si nos fijamos el módulo de pedidos (“/ped”) vemos que está muy relacionado con el action y la pagina del login. Posiblemente lo lógico hubiese sido incluir la funcionalidad del login en el módulo “/ped”, pero a modo de ejemplo queremos mostrar cómo se resuelven

estas dependencias entre componentes de distintos módulos. Si en una página JSP hemos incluido un link a algún elemento de otro módulo, basta con usar el atributo “module” disponible en las etiquetas HTML de Struts. Por ejemplo, para añadir un enlace al Action que muestra el catálogo desde el menú de opciones (“arbol.jsp”) bastaría con poner: <html:link action=”mostrarCategoria” module=”/cat”>

Mediante esta sencilla solución hemos resuelto el caso de las flechas que salen desde una JSP y apuntan a elementos de módulos externos. Para resolver los casos en los que desde un Action se hace forward a un elemento (Action o JSP) de otro módulo, necesitaremos modificar la declaración de dichos forwards. En el elemento “path” donde se indica el path del elemento al que queremos hacer forward indicaremos el path incluyendo el nombre 43

SOLO PROGRAMADORES nº 128


MIDDLEWARE

del módulo como prefijo. Para indicar que este path debe ser entendido como relativo al contexto de aplicación (y no de módulo) se indicará “contextRelative=”true””. Por último indicaremos que el forward se hará mediante un “sendRedirect” (redirect=”true”). El siguiente ejemplo muestra el forward que realiza el Action “HacerLogin” después de haber autenticado a un usuario. Si el usuario pretendía ver sus pedidos, después del login se le redirigirá de nuevo al Action de “verPedidos”. Esto se hará mediante este forward: <forward name=”verPedidos” redirect=”true” path=”/ped/verPedidos.do” contextRelative=”true” />

Otros frameworks MVC En estos tres artículos hemos visto las ventajas que nos ofrece desarrollar apoyándonos en un framework como Struts. Pero Struts no es ni mucho menos el único framework con el que contamos para el entorno J2EE. Dentro de los proyectos Open Source que se desarrollan actualmente existe un gran número de ellos destinados al desarrollo de frameworks MVC2. De todos los que existen en la actualidad, y basándonos en el grado de implantación que tienen en el mundo profesional, hemos elegido cuatro (al margen de Struts): JSF, Spring/MVC, WebWork y Tapestry. Sin pretender analizar exhaustivamente cada uno de ellos, vamos a ver por encima sus características y las ventajas o desventajas con respecto a Struts. Una de las primeras características que debemos evaluar es la facilidad de uso. Un framework muy bueno técnicamente o que ofrezca mucha funcionalidad no puede ser bueno si es complejo de aprender y usar (recordemos que uno de los principales objetivos de un framework debe ser facilitar el desarrollo y aumentar la productividad de los desarrolladores). Aquí principalmente reside el éxito de Struts. Existen críticas hacia Struts argumentando que es para “dummies” (tontos) lo que demuestra que cumple perfectamente con este primer requisito. En el lado opuesto tenemos a Tapestry. Tapestry define una arquitectura completamente distinta a la propuesta por J2EE y por

SOLO PROGRAMADORES nº 128

44

tanto requiere aprender un nuevo paradigma de programación con nuevos componentes, etc. Por otro lado proporciona un potente mecanismo de reutilización de estos componentes y por ello sí es aconsejable para el desarrollo de grandes aplicaciones. Otro aspecto importante en proyectos Open Source es la cantidad de material de que disponga (documentación, artículos, libros, foros). Struts, en este aspecto, también es líder, pues es con diferencia el framework más extendido. También su popularidad hace que disponga de múltiples herramientas de desarrollo (tanto comerciales como Open Source). Sin duda estos dos últimos puntos son un inconveniente para frameworks más recientes o menos extendidos como WebWork o Tapestry. Uno de los últimos frameworks en llegar ha sido JavaServer Faces (JSF). JSF es el único que está incluido en la especificación J2EE aunque la comunidad de desarrolladores lo ve más como un buen sistema de componentes visuales (similar a .NET), pero se ve muy limitado en la parte controladora del modelo MVC2. Aun así, su popularidad esta creciendo y está muy soportado en la industria. Otro aspecto muy tenido en cuenta últimamente es la facilidad de automatizar las pruebas unitarias. Esto en aplicaciones web no suele ser sencillo pues las aplicaciones están muy atadas al contenedor J2EE (lo que dificulta el uso de JUnit). En este sentido, las aplicaciones basadas en Spring MVC o WebWork tienen más fácil esta tarea pues implementan la idea de “contenedores ligeros” basándose en el patrón de diseño IoC (Inversion of Control o Dependency Injection), lo cual facilita enormemente la ejecución de pruebas unitarias fuera del contenedor. Con respecto a los componentes de Vista, decir que la mayoría son independientes de la tecnología elegida (JSP, Velocity, XML/XSLT), si bien, parece que WebWork es el que ofrece más facilidades para el uso de tecnologías distintas de JSP (mayor integración con Velocity y XML/XSLT). El resto suele proporcionar librerías de etiquetas que se pueden usar exclusivamente en páginas JSP y con las que no contaríamos en caso de elegir otras tecnologías.

Hemos visto que Struts pese a ser de los primeros en aparecer y quizás menos sofisticado que otros, sigue siendo una buena opción. En su contra se puede decir que recientemente se anunció que no va a salir una versión 2.0 de Struts ya que se considera que Struts actualmente cumple el propósito con el que se creó y sus desarrolladores apuestan por un nuevo framework de propósito más general, llamado Beehive (el “Page Flow” de Beehive está basado en Struts). Los lectores de Sólo Programadores pudieron leer una pequeña introducción a Beehive en el número 121.

Instalación de la aplicación Sp.Shop En la web de Solo Programadores se encuentra el código fuente completo de la aplicación Sp.Shop. El instalador de Tomcat 5.5 para Windows y el motor HSQLDB pueden descargarse de Internet. El fichero “leeme.txt” contiene las instrucciones paso a paso del proceso de instalación. En esta entrega, al contrario que en las anteriores, la aplicación no utiliza la base de datos en modo memoria, sino que se usa una base de datos con persistencia en ficheros. Se recomienda seguir los pasos de la instalación para configurar correctamente la nueva base de datos.

Conclusiones En este artículo hemos visto las facilidades que nos brinda Struts para resolver los aspectos más avanzados del desarrollo J2EE, tales como la gestión de la transaccionalidad y la gestión de orígenes de datos (dataSources). También hemos visto cómo facilitar el trabajo en equipo mediante la definición de módulos así como la mejora de la mantenibilidad de los ActionForms. Estos tres artículos dedicados a Struts nos han mostrado cómo, sin duda, el uso de frameworks facilita enormemente el desarrollo de aplicaciones J2EE. En el próximo número, conoceremos un nuevo paradigma de presentación de aplicaciones web y conoceremos el estado actual de esta y otras tecnologías en la plataforma J2EE. http://digital.revistasprofesionales.com


CD-ROM

Desarrollo de aplicaciones y servicios web con ASP.NET Microsoft ha anunciado recientemente las versiones Beta 2 del Framework .NET, SQL Server y Visual Studio 2005. Muchas de las novedades incluidas en estas nuevas versiones ya han sido objeto de estudio en números anteriores de Sólo Programadores, sin embargo hemos creído oportuno aprovechar este número para ofrecer, en el CDROM, Visual Web Developer Express Edition Beta 2.

Instalación de Visual Web Developer Express El proceso de instalación es extremadamente sencillo, puesto que basta con introducir el CD-ROM y seguir los pasos indicados por el asistente de instalación. En caso de que nuestro equipo no cumpla los requisitos necesarios para instalar Visual Web Developer Express, el propio asistente se encargará de instalarlos, tal como se aprecia en la figura 1. Por lo tanto no debería haber ningún problema con el proceso de instalación.

Visual Web Developer Express Visual Web Developer Express es un producto de Microsoft que contiene todo lo necesario para la creación de aplicaciones web y servicios web con la tecnología ASP.NET 2.0. Una de las novedades más importantes en los nuevos productos Visual Studio 2005 es la incorporación de una nueva línea de productos (Express) formada por herramientas un poco más ligeras y sencillas de aprender y utilizar para aficionados, entusiastas y aprendices que quieran crear sitios web y aplicaciones para Windows. En este sentido, uno de los productos de la línea Express es Visual Web Developer Express, un entorno de desarrollo orientado exclusivamente al desarrollo web con ASP.NET 2.0 utilizando Visual Basic, C# o J# como lenguajes de programación.

SOLO PROGRAMADORES nº 128

46

Figura 2. El proceso de registro para la obtención de la clave de activación es rápido y simple.

Figura 3. Después de cumplimentar el formulario de la figura 2, Microsoft nos mostrará la clave con la que podremos activar Visual Web Developer Express.

Figura 1. La instalación de Visual Web Developer Express incluye todos los paquetes de software adicionales.

Una vez concluida la instalación, el asistente nos indicará que la versión instalada expirará en un periodo de 30 días. En caso que sea nuestra intención usar el producto por un tiempo mayor, será necesario cumplimentar un rapidísimo proceso de registro en el site de Microsoft. En la figura 2 se puede apreciar el pequeño formulario que hay que

Figura 4. En esta ventana se nos indica que Visual Web Developer Express se ha activado correctamente y que por lo tanto podemos empezar a disfrutar de él.

http://digital.revistasprofesionales.com


CD-ROM

Desarrollo de aplicaciones y servicios web con ASP.NET

cumplimentar para obtener la clave de activación del producto. Después de cumplimentar el proceso de registro, se nos mostrará la clave que nos permitirá disfrutar de Visual Web Developer Express por un tiempo ilimitado. Tal como se indica en la propia figura 3, para introducir la clave en Visual Web Developer Express habrá que dirigirse al menú “Ayuda” -> “Activar Producto”. Al fin, después de introducir dicha clave, veremos la ventana de la figura 4. En este momento ya tendremos instalado Visual Web Developer sin límites de tiempo para su uso.

LISTADO 1 using using using using

Figura 5. Creando el proyecto que albergará nuestro servicio web.

Figura 6. Aspecto del “Explorador de soluciones”. http://digital.revistasprofesionales.com

System; System.Web; System.Web.Services; System.Web.Services.Protocols;

[WebService(Namespace = “SoloProgramadores.com”, Description = “Mi primer servicio web con ASP.NET y Visual Web Developer Express Edition Beta 2”)] [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)] public class Service : System.Web.Services.WebService { [WebMethod(Description = “Este método efectua una suma de números enteros”)] public int Suma(int a, int b) { return a + b; }

Primeros pasos con Visual Web Developer Express: creación de un servicio web A lo largo de su historia, los productos de la familia Visual Studio se han caracterizado por su alta capacidad de convertir en “sencillo” algo realmente complejo. Este poder de simplificación cobra mucha importancia cuando se está desarrollando con tecnologías complejas, como puedan ser los servicios web. A continuación, vamos a

Contenido del fichero Service.cs

[WebMethod(Description = “Este método efectua una resta de números enteros”)] public int Resta(int a, int b) { return a - b; } }

hacer una pequeña demostración de hasta qué punto esto puede ser cierto, implementando nuestro primer servicio web con Visual Web Developer Express. En efecto, nuestro objetivo será crear un servicio web sencillo capaz de ofrecer las funcionalidades de una calculadora. El ejemplo es básico, pero suficiente para comprobar hasta qué punto Visual Web Developer Express puede facilitarnos la tarea. Obviamente, el primer paso será abrir el entorno de desarrollo y pulsar en “Archivo” -> “Nuevo sitio Web…”, lo cual abrirá una ventana en la que tendremos que elegir como plantilla para el poryecto “Servicio web ASP.NET”, dar nombre a nuestro proyecto (“Ejemplo”) y elegir el lenguaje de programación (“C#”). La figura 5 muestra cómo debería quedar finalmente esta ventana. Después de pulsar en “Aceptar”, el “Explorador de soluciones” de Visual Web Developer mostrará la estructura de ficheros y directorios que luce la figura 6. Como se puede observar, Visual Web Developer Express reduce la complejidad del desarrollo de un servicio web a tan sólo dos ficheros fuente, “Service.cs” y “Service.asmx”, aunque veremos que el fichero que realmente

Figura 7. El menú contextual del archivo ASMX nos permite visualizar dicho fichero en el cliente web.

47

SOLO PROGRAMADORES nº 128


CD-ROM

Figura 8. Aspecto de la página “Service.asmx” desde un cliente web.

nos interesa en este caso es “Service.cs”. En este punto merece la pena aclarar que los nombres de estos ficheros pueden modificarse sin problema alguno, como no podía ser de otra manera. Observemos el contenido por defecto del fichero “Service.asmx”:

<%@ WebService Language=”C#” CodeBehind=”~/App_Code/Service.cs” Class=”Service” %>

En este fichero, simplemente indicamos que estamos implementando un servicio web (palabra “WebService”) con el len-

guaje C# y cuya implementación se encuentra en la clase “Service.cs”. Centrémonos ahora en el fichero “Service.cs”. Como se acaba de decir, este fichero contendrá la implementación de nuestro servicio web, es decir, la implementación de nuestra calculadora. El listado 1 muestra el código que deberá contener el fichero “Service.cs”. El código del listado 1 es altamente comprensible. Tan sólo comentaremos que (aunque no es imprescindible) es muy recomendable que esta clase derive de “WebService”, y que aquellos métodos de la clase que deban quedar expuestos a los clientes de la aplicación deberán ir precedidos del atributo “WebMethod”. Después de escribir este código, sólo faltará probar nuestro servicio. Para ello, bastará con dirigirse al “Explorador de soluciones” y pulsar sobre el archivo “Service.asmx” con el botón derecho del ratón, para luego elegir la opción “Ver en el explorador”. (véase la figura 7). Esto provocará la ejecución de nuestro navegador. Tal como se aprecia en la figura 8, nuestro servicio web expone dos métodos, “Suma” y “Resta”. En caso de que la implementación de alguno de estos dos métodos no tuviera el atributo “WebMethod”, dicho método no aparecería expuesto en la página “Service.asmx”. Para probar la ejecución de ambos métodos, bastará con hacer clic en el enlace, introducir dos valores enteros en el formulario y pulsar en “Invocar”. Esto generará un documento XML con el resultado de la operación (véase la figura 9).

Pero hay más

Figura 9. Ejecución del método “Suma”.

SOLO PROGRAMADORES nº 126

48

Lo expuesto en este corto espacio es simplemente un pequeño y rápido ejercicio que debe servir para demostrar la potencia de un entorno de desarrollo como Visual Web Developer Express. El mundo de las aplicaciones y los servicios web es infinitamente amplio, por lo que en ningún caso aquí se ha pretendido explicar los fundamentos de este tipo de desarrollos. Esperemos que este pequeño ejemplo sirva como punto de partida para futuros desarrollos con Visual Web Developer Express sobre la plataforma .NET. http://digital.revistasprofesionales.com


REDES

Pruebas funcionales y de rendimiento con JMeter PABLO OLMOS

Toda aplicación pasa por una fase de pruebas. JMeter es una utilidad escrita en Java que sirve para realizar pruebas de rendimiento y de funcionalidad sobre aplicaciones tipo cliente/servidor escritas en cualquier lenguaje. Qué es JMeter En un principio, JMeter sólo podía probar aplicaciones web, pero en la actualidad puede utilizarse para probar una gran variedad de recursos tanto estáticos como dinámicos: servlets, scripts de Perl, objetos Java, consultas sobre bases de datos, servidores FTP... Sobre estos recursos, JMeter puede simular una elevada carga para comprobar el rendimiento, o bien verificar si funcionan de modo estable y devuelven los resultados esperados y correctos. JMeter prueba la aplicación servidora lanzando peticiones, igual que lo harían las aplicaciones cliente. Por tanto, todo lo que JMeter puede obtener se puede obtener también por otros medios. Pero JMeter simplifica las cosas, porque puede simular el comportamiento una gran cantidad de usuarios en concurrencia y porque presenta los resultados de las pruebas de modo que éstos son fáciles de interpretar. Aunque el abanico de posibilidades con JMeter es realmente amplio, este artículo tratará exclusivamente sobre pruebas de rendimiento y funcionalidad en una aplicación web, sin importar el lenguaje en el que esta aplicación haya sido escrita (Java, PHP, ASP.NET, etc.).

Instalación Material complementario El lector encontrará en http:// digital.revistasprofesionales.com el material complementario de este artículo.

SOLO PROGRAMADORES nº 128

50

JMeter es una aplicación Java: para su funcionamiento, requiere de una máquina virtual de Java. Con este requerimiento puede ejecutarse sobre Windows (98, NT, 2000, XP) y sobre sistemas Unix (Solaris, Linux, etc.).

Los lectores que no tengan una máquina virtual instalada pueden obtenerla descargando el Java 2 Runtime Environment (J2RE) del sitio web de Sun (http://www.sun.org). Podemos verificar que la máquina virtual está bien instalada ejecutando, desde cualquier directorio: java -version

Si no está instalada, podremos obtenerla ejecutando el fichero “jre-1_5_0_02-windowsi586-p.exe”. Teniendo disponible la máquina virtual Java ya podemos instalar JMeter. La instalación consiste en descomprimir el archivo “jakarta-jmeter-2.0.3.zip”, que podemos obtener del sitio web de JMeter (http:// jakarta.apache.org/jmeter), y extraer todos sus ficheros, con lo que se creará el directorio “jakarta-jmeter-2.0.3”, que puede estar ubicado en un directorio cualquiera del sistema. El fichero “jmeter.bat”, del directorio “bin”, lanzará JMeter.

La fundación Apache JMeter forma parte del proyecto Jakarta, de la fundación Apache. La fundación Apache se creó en 1999 y da soporte a proyectos de software de código abierto tan importantes como, por ejemplo, su servidor web. Este software se licencia bajo la licencia Apache que, de entre las licencias para código abierto, es de las menos restrictivas.

Aproximación a un plan de pruebas En realidad, para JMeter un plan de pruebas no es más que una lista de peticiones a realizar al servidor, peticiones que a menudo deberán estar ordenadas. Estas peticiones estarán organizadas jerárquicamente, por lo que el plan de pruebas va a ser, en realidad, un árbol de pruebas algunos de cuyos nodos serán listas ordenadas. Al iniciar JMeter (véase la figura 1), en la parte izquierda vemos cómo el árbol de pruebas contiene dos nodos vacíos: “Test Plan” y “Workbench”. http://digital.revistasprofesionales.com


REDES

Pruebas funcionales y de rendimiento con JMeter

Figura 1. Pantalla de inicio de JMeter.

El proyecto Jakarta El proyecto Jakarta reúne los desarrollos Java auspiciados por la fundación Apache. Jakarta se organiza en subproyectos, entre los que se encuentran el conocido contenedor de servlets Tomcat y, por supuesto, JMeter.

”Test Plan” debe contener las peticiones que conformen la prueba, mientras que “Workbench” puede servir como borrador o como espacio de almacenamiento temporal donde dejar componentes que de momento no se quieren activos, pues el contenido de “Workbench” no va a influir en la prueba. Veamos el proceso completo para una prueba sencilla de rendimiento. Supongamos que queremos saber el tiempo de respuesta cuando cinco usuarios lanzan simultáneamente una misma petición. Mediante el menú contextual, añadimos a “Test Plain” un “Thread Group”. Los “Thread Group” son los puntos de inicio del plan de pruebas, y todos los elementos del plan han de colgar de algún ”ThreadGroup”. El “Thread Group” permite fijar el número de hilos (en nuestro caso cinco, puesto que simulamos cinco usuarios), el intervalo de tiempo entre las peticiones (en nuestro caso cero, porque simulamos que se lanzan todas a la vez), y el número de veces que se ejecutará la prueba (en nuestro caso una). http://digital.revistasprofesionales.com

En la parte derecha de la pantalla introduciremos los valores que se muestran en la figura 2:  N a m e: Es opcional  N u m b e r o f t h r e a d s: 5  R a m p - U p P e r i o d ( i n s e c o n d s ): 0  L o o p C o u n t: “Forever” deshabilitado (en caso contrario la prueba itera indefinidamente hasta que se pare manualmente) e introducimos el valor 1. El siguiente paso es añadir un “sampler”. Un “sampler” es un objeto que realiza una petición. En nuestro caso el tipo de “sampler” debe ser “HTTP Request”. Por tanto, desde en menú contextual del “Thread Group”, hacemos: “Add” -> “Sampler” -> “HTTP Request”. En la parte de la derecha añadiremos, para este “sampler”, los siguientes valores correspondientes a la aplicación cuyo ren-

dimiento queremos probar. Para nuestro ejemplo asumiremos que vamos a probar la web de Sólo Programadores:  N a m e: Es opcional  S e r v e r N a m e o r I P: digital.revistasprofesionales.com  P o r t N u m e r: 80 (es el puerto por defecto, por tanto es omitible)  P r o t o c o l: http (es el protocolo por defecto, por tanto es omitible)  M e t h o d: Elegir GET o POST (no influye en esta prueba concreta)  P a t h: /soloprogramadores/ Aparentemente la prueba está lista para ser realizada, pero todavía falta un elemento imprescindible: un “listener”. Los “listener” proporcionan vistas sobre los resultados de la prueba. Si se realiza la prueba sin ningún “listener”, no habrá manera de conocer los resultados. Para esta primera prueba vamos a elegir un “listener” tipo “Wiew Results Tree”. Desde el menú contextual del “Thread Group” hacemos: “Add” -> “Listener” -> “View Results Tree”. Iniciamos la prueba pulsando Ctrl+R y miramos los resultados en el listener (véase figura 3). Ahí podemos ver cómo cada petición se duplica, puesto que en nuestro ejemplo concreto la página se redirecciona, y también podemos ver diversos datos tales como el tiempo de carga, la petición que se ha realizado y cuál ha sido la respuesta del servidor, pudiendo incluso renderizar la respuesta para verla tal como la presentaría un navegador. Podemos guardar la prueba (menú “File”), pero al hacerlo no se guardarán los resultados. Es decir, si guardamos la prueba podremos recuperar su configuración, pero al reabrirla el “listener” se mostrará vacío. Para conservar los resultados de una prueba es necesario indicar, en el campo “filena-

Figura 2. Valores para el grupo de hilos de una prueba sencilla.

51

SOLO PROGRAMADORES nº 128


REDES

me” del “listener”, el nombre del fichero donde se almacenarán los datos. Este fichero es independiente del “listener” con el que se creó, pero hay que tener en cuenta que el nombre del fichero hay que indicarlo antes de iniciar la prueba. Por ejemplo, si en nuestro “listener”, antes de iniciar la prueba, hubiéramos indicado el “filename”, después podríamos agregar otro tipo de “listener” y, si indicamos el mismo “filename”, veremos los datos de la misma prueba pero con otra vista. Otra cuestión a tener en cuenta es que si repetimos la prueba el “listener” agregará los datos, pero no eliminará los de la prueba anterior. No obstante, disponemos del nodo “WorkBench” como espacio donde colgar otros nodos que no se verán influidos por la prueba, y ahí podemos arrastrar y soltar (“Add as Child”) los “listener” cuyos resultados queramos mantener. Pero hay que tener en cuenta que al guardar el plan de pruebas el contenido del “Workbench” no se guardará. Para guardarlo se puede usar el menú contextual (botón derecho del ratón). Evidentemente, una prueba de rendimiento requerirá valores mucho más altos para “Number of threads”. Además, es posible que queramos aumentar el “Ramp-Up Period” para que las peticiones no se lancen todas a la vez, y también es posible que queramos repetir las prueba varias veces (“Loop Count”). En todo momento, una prueba puede detenerse desde el menú “Run” o pulsando Ctrl+,.

Elementos del plan de pruebas Antes de seguir con un plan de pruebas más complicado debemos familiarizarnos con los elementos que lo pueden llegar a componer.

ThreadGroup Como ya se ha mencionado, el “ThreadGroup” es el nodo de inicio del plan. Define el número de threads (número de usuarios de la simulación); el periodo de tiempo ramp-up (tiempo que transcurrirá entre el primer thread y el último, y el número de veces que se ejecutará la prueba. Por ejemplo, los valores: Number of Threads = 8 Ramp-Up = 5 Loop Count = 2

Significan repetir 2 veces el lanzar 8 peticiones a unos intervalos tales que entre la primera y la última transcurran 5 segundos. Es decir, JMeter empleará 5 segundos en enviar las primeras 8 peticiones y otros 5 segundos en enviar las segundas 8 peticiones.

tipos de peticiones (http, ftp, tcp, ldap, etc.). Las peticiones se realizarán ordenadamente, lo que significa que el orden de los “sampler” es relevante. Si se van a realizar varias peticiones del mismo tipo sobre el mismo servidor, entonces se puede agregar un elemento de configuración con los valores por defecto (“Add” -> “Config Element”).

Logic Controller Los “logic controller” permiten introducir decisiones en el árbol de pruebas. Por ejemplo, realizar una petición sólo si antes se ha obtenido tal resultado. Estos nodos sólo pueden tener como hijos “sampler”, elementos de configuración y otros controladores lógicos.

Listener Son las vistas con las que se muestran los resultados. Existen distintos tipos de “listener”: gráficos, tablas, etcétera. Si se quiere guardar el resultado de la prueba, antes de iniciarla, en el “listener” se debe indicar el nombre del fichero donde se guardará. Dado un fichero con el resultado de una prueba, diferentes “listener” podrán mostrar distintas vistas sobre los mismos datos.

Assertion Sampler Los “sampler” sirven para hacer peticiones al servidor. Como peticiones de distintos tipos van a requerir propiedades diferentes, hay “sampler” específicos para los distintos

Se utilizan para realizar pruebas sobre las respuestas dadas por el servidor, por lo que sólo pueden agregarse a nodos que devuelvan una respuesta, tales como los “listener”. Por ejemplo, se puede probar que una respuesta se ha obtenido en un tiempo determinado, que un fichero tiene unas determinadas propiedades, o que el HTML de la respuesta no contiene la palabra “error”.

Otros elementos Además de los elementos indicados, disponemos de “timer”, que introducen tiempos de espera entre una petición y la siguiente; “configuration elements”, de los que ya hemos hablado antes, y “Pre Processors” y “Post Processors” que realizarán acciones antes y después de las peticiones. Por ejemplo, un preprocesador puede actualizar el valor de una variable que se acaba de obtener en una petición anterior y un post procesador puede almacenar datos en un fichero.

El árbol de pruebas

Figura 3. Resultado de una prueba de rendimiento sencilla.

SOLO PROGRAMADORES nº 128

52

Como ya se ha comentado, algunos elementos del árbol de pruebas son jerárquicos, mientras que otros están ordenados. http://digital.revistasprofesionales.com


REDES

Pruebas funcionales y de rendimiento con JMeter

Nombre

Figura 4. Ejemplo de árbol.

Los elementos ordenados son los “Controller” y los “Sampler”. “Listener”, “Config Element”, “Post Processors”, “Pre Processors”, “Assertion” y “Timer” son jerárquicos. Consideremos el árbol que muestra la figura 4. La tabla adjunta presenta los elementos que forman este árbol y sus respectivas funcionalidades. La figura 5 muestra el orden en el que se han ejecutado las peticiones para:

Tipo de elemento

Funcionalidad

Árbol 1

Test Plan

Plan de pruebas.

Hilos

Thread Group

Nodo inicial.

Solo una vez

Once Only Controller

Independientemente del número de veces indicado en el nodo inicial (Loop Count), lo que cuelgue de este controlador sólo se ejecutará la primera vez.

Solo Programadores

HTTP Request

Petición HTTP.

Mundo Linux

HTTP Request

Petición HTTP.

Uno cada vez

Interleave Controller

Cada vez (Loop Count) se ejecutará por orden una de las peticiones que cuelguen de este controlador.

Petición 1

HTTP Request

Petición HTTP afectada por los valores por defecto establecidos en Config 2.

Petición 2

HTTP Request

Petición HTTP afectada por los valores por defecto establecidos en Config 2.

Resultado 2

View Results Tree

Vista del resultado de Petición 2.

HTTP Request Defaults

Configuración por defecto para las peticiones que cuelgan del padre de este nodo: Petición 1 y Petición 2.

Digital

HTTP Request Defaults

Configuración por defecto para las peticiones que cuelgan del padre de este nodo, o sea, todos. Para Petición 1 y Petición 2 tiene prioridad la configuración Config 2.

Resultado total

View Results Tree

Vista del resultado total de la prueba, incluyendo Petición 2.

Config 2

Threads=1 Ramp-Up=0 Loop Count=2

Los resultados en rojo indican que se produjo un error (que en este caso hemos producido deliberadamente) tipo “página no encontrada” o similar. ¿Qué novedades aporta este plan de pruebas, respecto al de la primera prueba sencilla? En primer lugar hemos añadido “HTTP Request Defaults”, configuraciones por

Figura 5. Resultado de la ejecución del árbol de la figura 4.

http://digital.revistasprofesionales.com

defecto, que se aplican a todas las peticiones que cuelguen del mismo nodo que la configuración. Como se muestra en la figura 6, en este caso lo único que tienen en común todas las peticiones es el protocolo, el servidor y el puerto. Hay que notar que si estos valores se vuelven a especificar en una petición HTTP, como es de esperar éstos dominarán sobre los valores por defecto. Además si, por ejemplo, en la configuración por defecto hay una path y en la petición HTTP hay otra path, ambas no se concatenarán, sino que sólo se tendrá en cuenta de la petición HTTP. Además, a este árbol le hemos añadido una cierta lógica, con la ayuda de controlado53

SOLO PROGRAMADORES nº 128


REDES

cir este ejemplo se producirá un error, puesto que los datos son ficticios, pero eso ahora no es lo importante. Lo importante es darse cuenta de que hemos ilustrado cómo pasar parámetros, pero ¿y si queremos simular cien usuarios dándose de alta? ¿Cómo hacer para que cada prueba tenga valores distintos en los parámetros? (es de suponer que el sistema no acepte el registro de dos usuarios con el mismo “user” y “mail”). Figura 6. Configuración por defecto.

Alta de muchos usuarios

LISTADO 1

Alta de un usuario

<form METHOD=”post” ACTION=”/Servlet”> <input name=”user”> <input name=”mail”> <input TYPE=”hidden” NAME=”peticion” VALUE=”Alta”> ...

res. La petición “Solo Programadores” sólo se lanzará una vez. A continuación siempre se ejecutará la petición “Mundo Linux”. Y luego, la primera vez (Loop Count)) se pedi-

Buenas prácticas Aplicaciones como JMeter permiten hacer peticiones masivas sobre un servidor. Las buenas prácticas obligan a utilizar este tipo de aplicaciones sólo para realizar pruebas sobre desarrollos propios. La realización de pruebas sobre un servidor ajeno puede considerarse un acto muy hostil.

(cuyo valor “Alta” indicará al Servlet que la acción a realizar es una alta de usuario). Supongamos, también, que esta aplicación web utiliza cookies para mantener las sesiones. La figura 7 muestra cómo, mediante el botón “Add”, se han ido añadiendo los tres parámetros que se deben enviar al servidor junto con la URL de la petición. Con un “listener” tipo “View Results Tree”, la pestaña “Request JMeter” muestra la petición exacta que ha enviado al servidor. Naturalmente, si el lector intenta reprodu-

Una solución para que los valores de los parámetros sean distintos para cada usuario (thread) consiste en la utilización de funciones. Son dos las funciones disponibles para esto: “__threadNum” y “__counter”. La sintaxis de las funciones es: ${__nombreFuncion(var1,var2,var3)}

La función “__threadNum” no tiene parámetros y devuelve el número de thread. La función “__counter” es un contador que se incrementa a cada llamada; con el parámetro “true” cada usuario (thread) mantendrá un contador independiente y con el parámetro “false” todos los usuarios compartirán el mismo contador. Ejemplos de funciones son: ${__threadNum} ${__counter(TRUE)}

rá Usuario 1 y en la segunda vez Usuario 2. O, más brevemente, este ejemplo significa: “probar dos veces (Loop Count) un usuario (Thread) cada vez”. Aún no hemos utilizado temporizadores, aserciones... Sin embargo, podemos afrontar ya un caso más complicado: el alta de usuarios en un sistema.

Alta de un usuario Por regla general, las aplicaciones web suelen sugerir a sus usuarios que se registren. El registro se suele realizar a través de un formulario HTML. Para empezar, vamos a ver cómo se podría realizar la prueba de funcionalidad del alta de un sólo usuario. Supongamos una aplicación web escrita en Java que presenta al usuario un formulario con el contenido que se muestra en el listado 1, donde se aprecia que se le pide un “user” y un “mail”, que se enviarán al Servlet junto con el parámetro “peticion”

SOLO PROGRAMADORES nº 128

54

Figura 7. Envío de parámetros junto con la petición.

http://digital.revistasprofesionales.com


REDES

Pruebas funcionales y de rendimiento con JMeter

Figura 8. Utilización de funciones para generar los valores de los parámetros.

La figura 8 muestra cómo podríamos adaptar el registro de un sólo usuario con valores fijos a una prueba para registrar varios usuarios, usando la función “${__threadNum}”. Elevando el número de thread se podrá probar el registro de muchos usuarios de forma más o menos concurrente dependiendo del valor “Ramp-Up Period” (recordemos que si vale 0 eso significa que todas las thread se lanzan a la vez y si vale n significa que entre la primera y la última transcurren n segundos).

Datos de los usuarios User usuario1 usuario2 usuario3

Password husow4 4jn28o zxcyui

vidor una serie de parámetros con valores determinados y conocidos. El listado 2 muestra un fragmento del formulario de login y la tabla adjunta muestra los datos de los usuarios (valores ficticios). La solución para estos supuestos es utilizar el fichero “users.xml”. En el directorio “bin” hay un ejemplo de “users.xml”. Se puede hacer una copia y sobrescribirlo, siguiendo el ejemplo, con algo parecido a lo que muestra el listado 3 (nótese que en “users.xml” se ha añadido el parámetro mail, aunque éste no se va a utilizar en las pruebas de login). La figura 9 muestra el aspecto que tendría la petición HTTP. Observemos cómo se indica el nombre de los parámetros (“user”, “password” y “peticion”) pero dejando en blanco la columna “Value”. (Como el ejemplo es ficticio, no se indica el servidor, puerto, etc.). Observemos también, en el árbol, cómo de la petición login cuelga un elemento tipo “HTTP User Parameter Modifier” que se ha añadido haciendo “Add” -> “Pre Processors” -> “HTTP User Parameter

LISTADO 2

Login de un usuario

<form METHOD=”post” ACTION=”/Servlet”> <input name=”user”> <input name=”password”> <input type=”hidden” name=”peticion” value=”Autenticacion”> ...

Condiciones de las pruebas Es recomendable que JMeter funcione en un ordenador distinto al del servidor que se está probando para que la carga de JMeter no influya en el resultado de las pruebas. También se debe procurar que la red esté lo más aislada posible, para que las pruebas se realicen sin interferencias incontroladas.

Supongamos que ya hemos probado cómo funciona el alta de usuarios y que ahora queremos probar el login de todos ellos. Vamos a suponer también que, en el proceso de registro, la aplicación web les ha asignado una password aleatoria. En este caso, ya no podremos generar la password de cada usuario usando una función de JMeter y esperar que coincida con la que ha generado el servidor, lo que nos conduce al caso general de que para cada thread haya que enviar al serhttp://digital.revistasprofesionales.com

Figura 9. Parámetros que usan “users.xml”.

55

SOLO PROGRAMADORES nº 128


REDES

LISTADO 3

Contenido del fichero users.xml

<?xml version=”1.0”?> <!DOCTYPE allthreads SYSTEM “users.dtd”> <!— all users, uses round robin selection —> <allthreads> <!— unique parameters for each individual thread (ie user) —> <thread> <parameter> <paramname>user</paramname> <paramvalue>usuario1</paramvalue> </parameter> <parameter> <paramname>mail</paramname> <paramvalue>usuario1@internet.es</paramvalue> </parameter> <parameter> <paramname>peticion</paramname> <paramvalue>Autenticacion</paramvalue> </parameter> <parameter> <paramname>password</paramname> <paramvalue>husow4</paramvalue> </parameter> </thread> <thread> <parameter> <paramname>user</paramname> <paramvalue>usuario2</paramvalue> </parameter> <parameter> <paramname>mail</paramname> <paramvalue>usuario2@internet.es</paramvalue> </parameter> <parameter> <paramname>peticion</paramname> <paramvalue>Autenticacion</paramvalue> </parameter> <parameter> <paramname>password</paramname> <paramvalue>4jn28o</paramvalue> </parameter> </thread> <thread> <parameter> <paramname>user</paramname> <paramvalue>usuario3</paramvalue> </parameter> <parameter> <paramname>mail</paramname> <paramvalue>usuario3@internet.es</paramvalue> </parameter> <parameter> <paramname>peticion</paramname> <paramvalue>Autenticacion</paramvalue> </parameter> <parameter> <paramname>password</paramname> <paramvalue>zxcyui</paramvalue> </parameter> </thread> </allthreads>

Figura 10. “HTTP User Parameter Modifier” para usar “users.xml”.

SOLO PROGRAMADORES nº 128

56

Planificación No sirve de nada realizar pruebas si antes no se han fijado unos objetivos detallados. Las pruebas indicarán, en el mejor de los casos, cuál es la respuesta del servidor en condiciones extremas, pero son los requerimientos especificados en la fase de definición los que nos dirán si esa respuesta es aceptable, y eso debe saberse antes de empezar a probar. Porque no se trata de probar si una aplicación funciona “bien” o “mal”, sino si funciona tal como se espera que lo haga conforme a su especificación.

Modifier”. La figura 10 muestra el aspecto del “HTTP User Parameter Modifier”. Pues bien, ahora, para mantener la coherencia del ejemplo, sólo restaría ejecutar esta prueba para 3 threads.

Conclusiones Hemos realizado una aproximación a cómo JMeter realiza pruebas de carga y pruebas de funcionalidad. La diferencia entre pruebas de carga y de funcionalidad no está tan clara como a primera vista pueda parecer. Una aplicación puede ofrecer buenos resultados con una carga baja y malos con una carga alta. O buenos con poca concurrencia y malos con mucha. O buenos cuando se inicia y malos cuando ha transcurrido mucho tiempo desde que se inició (por los consabidos problemas de liberación de memoria, etc.). Esto nos da una idea de que las pruebas no sólo son imprescindibles para aplicaciones en “fase de pruebas”. También lo son para conocer, por ejemplo, la escalabilidad de una aplicación consolidada, y saber cómo se comportaría ante un considerable aumento de carga. O para conocer cuánto va a mejorar el rendimiento de una aplicación ante mejoras en el hardware del ordenador o de la red. Por problemas de espacio muchas cosas se han quedado en el tintero: no hemos comprobado, con aserciones, el resultado de las peticiones; no hemos realizado peticiones HTTPS, y la lógica de nuestras pruebas ha sido muy sencilla. Tampoco hemos visto la amplia gama de “listener” que ofrece JMeter y no hemos usado ningún post procesador. A pesar de ello, esperamos que lo expuesto sirva de guía al lector y lo acompañe en sus primeros pasos con JMeter. http://digital.revistasprofesionales.com


REDES

Creación de aplicaciones web con ColdFusion MX 7 (y III) RICARDO DÍEZ FERREIRA

Coldfusion ofrece mecanismos para la reutilización de código, además de permitir una integración total con elementos Java o C++. En esta última entrega analizaremos estos y otros aspectos centrados en la administración del servidor. Introducción En las dos primeras entregas de la serie se mostraron todas las ventajas de Coldfusion para el desarrollo web, su instalación y el uso de su lenguaje de programación (CFML), desarrollando ejemplos de las etiquetas y las funciones predefinidas más importantes. También se desarrollaron ejemplos más avanzados, de tratamiento de XML y XSLT, tratamiento de errores, etc. En esta tercera y última entrega, se mostrará la forma de integrar en una aplicación Coldfusion objetos programados en otros lenguajes de programación, como Java y C++. También se mostrará cómo crear etiquetas y funciones propias, para encapsular el código más repetitivo de las aplicaciones, y utilizarlas como cualquier otra etiqueta o función de CFML. Finalmente, se verán ciertos temas de la configuración del servidor de Coldfusion, para que las aplicaciones funcionen correctamente, e intentar sacarle el máximo partido al servidor.

Creación de etiquetas propias

Material complementario El lector encontrará en http:// digital.revistasprofesionales.com el material complementario de este artículo.

SOLO PROGRAMADORES nº 128

58

Además de todas las etiquetas que nos proporciona CFML, existe la posibilidad de crear etiquetas propias (Custom Tags) en el mismo lenguaje para que hagan lo que nosotros queramos. Esta es una buena manera de encapsular código que se repita muchas veces en una aplicación web, para tenerlo en un único sitio. Antes de decidir desarrollar una etiqueta propia, es aconsejable buscar en la web, ya que es posible que algún otro desarrollador de Coldfusion ya

haya desarrollado lo que nosotros necesitamos. En los sitios web centrados en la tecnología Coldfusion pueden encontrarse desde sencillos contadores de visitas, hasta complicadas etiquetas de seguridad para aplicaciones. Para crear una nueva etiqueta, simplemente hay que crear un fichero .CFM, con el nombre que deseamos para nuestra etiqueta, y copiarlo al directorio de los Custom Tags. Este directorio es configurable desde el administrador de Coldfusion, pero por defecto, si no se cambia explícitamente, suele estar en el directorio “CustomTags” dentro del directorio base de instalación de Coldfusion. Una vez esté copiado allí el fichero “mietiqueta.cfm” se podrá utilizar esta etiqueta de esta manera: <cf_mietiqueta parametro1=”Valor1” parametro2=”Valor2”>

En el fichero “mietiqueta.cfm”, es necesario poder recoger los parámetros que se envíen. Para ello, simplemente se puede referenciar el parámetro como: Attributes.NombreParametro

También es necesario poder devolver resultados en alguna variable. En este caso, basta con utilizar el objeto “Caller” de la siguiente manera: <cfset Caller.Resultado=”Este es el resultado”>

Esta etiqueta insertará el contenido en una variable llamada “Resultado” en el programa que llame a la etiqueta. Si esta variable no existe, la crea. Hay que ser cuidadoso para no sobrescribir variables ya existentes si no se desea hacerlo. A continuación se muestra un pequeño ejemplo del posible código de una etiqueta muy simple, que recibe dos números como parámetros, los suma y devuelve el resultado: <cfparam name=”Attributes.numero1” default=”0”> <cfparam name=”Attributes.numero2” default=”0”> <cfset Caller.Resultado=Attributes. numero1+Attributes.numero2>

http://digital.revistasprofesionales.com


REDES

Creación de aplicaciones web con ColdFusion MX 7 (y III)

Si guardamos este código en un fichero llamado “suma.cfm” en el directorio de Custom Tags, desde cualquier página del servidor de Coldfusion se puede utilizar la etiqueta de la siguiente manera:

LISTADO 1

Una clase Java

public class Persona { public String nombre; public int edad; public Persona() { nombre=””; edad=0; }

<cf_suma numero1=”15” numero2=”23”> <cfoutput>

podrán ejecutar páginas JSP o Servlets. Incluso, dentro de páginas con código CFML se pueden incluir llamadas a ficheros JSP o Servlets. Por ejemplo, para hacer un “include” de un JSP en CFML se pondría este código: GetPageContext().include(“ejemplo.jsp ?param1=25”);

El resultado de la suma es: public Persona(String nom, int ed) { nombre = nom; edad = ed; }

#Resultado# </cfoutput>

Con este sencillo ejemplo, se ha mostrado cómo se pueden crear etiquetas propias, y cómo se intercambia la información entre el fichero que hace la petición y la etiqueta en sí. Pero sin embargo, para este tipo de cálculos tan simples, las etiquetas no son lo adecuado, sino la creación de funciones propias, que se explica en el siguiente apartado. Las etiquetas están pensadas para cosas más complejas.

public boolean mayorEdad() { if (edad >= 18) return true; return false; }

<jsp:include page=”ejemplo.cfm”> public void setEdad(String ed) { edad = Integer.parseInt(ed); } public void setEdad(int ed) { edad = ed; } } <cfoutput>El resultado es: #suma(“15”,”23”)#</cfoutput>

La arquitectura interna de Coldfusion permite que haya gran compatibilidad con Java.

Creación de funciones propias Como ya se ha adelantado en el apartado anterior, también se pueden crear funciones propias en Coldfusion. Estas funciones también están pensadas para la reutilización de código, pero para pequeños algoritmos. Un ejemplo podría ser un cálculo matemático, un tratamiento de cadenas de texto, etc. Al contrario que las etiquetas, las funciones hay que definirlas en cada lugar que se vayan a utilizar, y no es necesario definirlas en un fichero independiente. La definición se hace con el tag “<cffunction>”. A continuación, se muestra un ejemplo de la definición del ejemplo anterior de la suma en una función, y después una llamada a la misma: <cffunction name="suma" > <cfargument name="numero1" required="true" type="numeric"> <cfargument name="numero2" required="true" type="numeric"> <cfreturn numero1+numero2> </cffunction> …

http://digital.revistasprofesionales.com

Como se puede observar, los parámetros que se quieran pasar a la JSP o Servlet, debe hacerse a través de la URL. También se puede hacer la operación contraria, es decir, incluir un fichero de CFML desde una página JSP. Se hace de la siguiente manera:

Como se puede observar, el único atributo necesario para la etiqueta “<cffunction>” es “name”, que indica el nombre de la función, y dentro de la etiqueta, se utilizan dos etiquetas más. “<cfargument>” sirve para definir los nombres y los tipos de los parámetros que recibe la función. Los posibles tipos son “numeric”, “array”, “query”, “date”, etc. Finalmente, la etiqueta “<cfreturn>” se usa para devolver el resultado y salir de la función, como el “return” de otros lenguajes de programación. Si las funciones que se definen se van a utilizar en muchas páginas de la web, es conveniente meterlas en un fichero .CFM y usar la etiqueta “<cfinclude>” para incluirlas en todas las páginas que sea necesario, y no tener la misma función definida en varios sitios.

Compatibilidad con Java Coldfusion es internamente un servidor de aplicaciones Java, con lo cual no es extraño que la compatibilidad con Java sea alta. Desde cualquier servidor de ColdFusion se

LISTADO 2

<jsp:param name=”param1” value=”25” /> </jsp:include>

Además, es posible utilizar objetos Java, con sus métodos y sus propiedades, para encapsular datos. Como Coldfusion no tiene una definición de tipos tan rígida como la de Java, hay un problema a la hora de hacer llamadas a métodos con un tipo de datos concreto. Para ello, la función “JavaCast” de Coldfusion, se encarga de convertir los tipos de Coldfusion a Java. A continuación se muestra un ejemplo de cómo se puede utilizar un objeto java. Primero, veamos en el listado 1 el código de una clase Java sencilla. Una vez escrita la clase del listado 1 hay que compilarla, y poner el fichero .CLASS generado en el CLASSPATH de ColdFusion. Este CLASSPATH es configurable desde el administrador de Coldfusion, donde se pueden incluir todos los directorios que se desee para que la aplicación coja las clases de ellos. Los archivos pueden ser .CLASS o también archivos .JAR (Java Archive). Una vez hecho esto, ya se pueden utilizar las clases Java desde Coldfusion. Para ello se utiliza la etiqueta “<cfobject>”, que permite crear una instancia de un objeto Java, para hacerlo accesible con CFML. Véase cómo en el listado 2. Como se puede observar en dicho listado, la etiqueta “<cfobject>” tiene varios atributos, y uno de ellos es “type”, que es el tipo de objeto,

Trabajando con la clase Java desde Coldfusion

<cfobject action=”create” type=”java” class=”Persona” name=”objeto”> <cfset objeto.nombre=”Estela Rejado”> <cfset objeto.setEdad(JavaCast(“int”, “31”))> <html> <body> <cfoutput> Nombre: #objeto.nombre#<br> Edad: #objeto.edad#<br> Mayor de edad: #objeto.mayorEdad()# </cfoutput> </body> </html>

59

SOLO PROGRAMADORES nº 128


REDES

en este caso con el valor “Java”. Esto es porque esta etiqueta se puede utilizar tanto para crear una instancia de un objeto Java, como para objetos COM, CORBA, etc. Una vez creada la instancia, se puede observar que los atributos y los métodos de la clase están accesibles a través de la variable “objeto”. En la tercera línea, se muestra un ejemplo de la función “JavaCast”, que en este caso se encarga de convertir el valor de Coldfusion en un tipo “int” de Java. Existe otra forma de integración con Java, basada en las etiquetas CFX, que serán explicadas en el siguiente apartado.

Compatibilidad con C++ La compatibilidad entre Coldfusion y C++, aunque es menor que la compatibilidad con Java, también permite desarrollar código reutilizable en este lenguaje de programación. La utilización de código C++ se hace a través de las etiquetas CFX (ColdFusion eXtensions). Estas etiquetas, realmente son como las etiquetas propias, pero escritas contra el CFX API. Normalmente, las CFX se suelen utilizar para realizar tareas que no se puedan hacer con Coldfusion, o para mejorar el funcionamiento de algún proceso repetitivo en la aplicación. Estas etiquetas pueden reutilizar tanto código C++ como Java, y pueden realizar cualquier tarea, manejando todo tipo de atributos o variables de Coldfusion, o incluso lanzando sus excepciones a un mensaje de error de Coldfusion. Para poder implementar estas etiquetas, se necesita una definición de clases que permita comunicarse con Coldfusion, y que serán necesarias para compilar los programas, tanto en C++ como en Java. Con la distribución de Coldfusion se proporcionan dos ficheros para esta labor, llamados “cfx.h” para C++ y “cfx.jar” para Java. También se proporcionan varios ejemplos de etiquetas CFX hechas en C++. La clase más importante para implementar una etiqueta CFX en C++ es “CCFXRequest”, que permitirá leer y escribir variables, lanzar excepciones, consultas, y devolver un resultado. Existen algunas clases de ayuda más. Una vez hecho esto, hay que registrar la etiqueta CFX desde el administrador de Coldfusion. Recordamos al lector que el administrador es accesible desde http://nom bre_servidor:8500/CFIDE/administrator/index .cfm, donde “nombre_servidor” será 127.0.0.1 si Coldfusion se ha instalado en la propia máquina. El administrador nos pedirá la con-

SOLO PROGRAMADORES nº 128

60

LISTADO 3

La clase sumadora

public class SumaCFX implements CustomTag { public void processRequest(Request request, Response response) throws Exception { String num1 = request.getAttribute( “NUM1” ); String num2 = request.getAttribute( “NUM2” ); int suma = Integer.parseInt(num1) + Integer.parseInt(num2); response.write( “La suma es:” + suma); } }

traseña introducida en el proceso de instalación. Una vez dentro, sólo hay que ir a la sección “Extensions” -> “CFX Tags”, ponerle un nombre, y seleccionar el fichero .DLL generado. Después, ya se puede llamar normalmente a la etiqueta como si fuera una más.

Ejemplo de una etiqueta CFX Para ilustrar la creación de etiquetas CFX se va a realizar un sencillo ejemplo, implementado en Java por su mayor claridad y sencillez. Para utilizar una clase Java como etiqueta, es necesario que ésta implemente la interfaz “CustomTag” y en concreto su método “processRequest”. Se va a implementar una sencilla clase que recibe dos números, y escribe la suma de ellos. El código de esta clase sumadora puede verse en el listado 3. Una vez escrita la clase, hay que compilarla incluyendo el fichero “cfx.jar”, que contiene la interfaz y las clases necesarias. Este fichero viene en la instalación de Coldfusion. El comando de compilación sería: javac -classpath cf_root\wwwroot\ WEB-INF\lib\cfx.jar SumaCFX.java

Donde “cf_root” es el directorio raíz del servidor web donde se ejecuta Coldfusion. El fichero .CLASS generado, se debe copiar a un directorio que esté en el CLASSPATH de Coldfusion, tal y como se ha explicado en el apartado de compatibilidad con Java. A continuación, se debe ir al administrador de Coldfusion para registrar la nueva etiqueta, en el apartado “Extensions” -> “CFX tags”. Aquí, hay que hacer clic en “Register Java CFX”, e introducir los datos que se piden. Estos datos son el nombre de la etiqueta (“cfx_suma” por ejemplo), el nombre de la clase Java (sin la extensión .CLASS) y una descripción opcional. Una vez hecho todo esto, ya se puede utilizar la etiqueta desde cualquier aplicación en CFML de la siguiente manera: <cfx_suma NUM1=”11” NUM2=”24”>

El administrador de Coldfusion Como ya se adelantó en la primera entrega, la administración del servidor de Coldfusion se puede realizar íntegramente en un cómodo interfaz web, que permite configurar todos los posibles atributos del servidor.

El apartado “Server Settings” del administrador de Coldfusion contiene los principales parámetros que afectarán al rendimiento.

http://digital.revistasprofesionales.com


REDES

Creación de aplicaciones web con ColdFusion MX 7 (y III)





Con las “System Probes” de Coldfusion se pueden realizar tareas de monitorización. 

Este administrador, tal como se explicó en la primera entrega del curso (Sólo Programadores 126) y tal como se ha recordado anteriormente, está accesible en la siguiente dirección: http://nombre_servidor:8500/CFIDE/ administrator/index.cfm

las para no saturar el servidor. Otro parámetro importante de este subapartado es “Timeout Request Alter”, que indicará el tiempo de espera para una petición al servidor. Debería estar fijado para que alguna petición muy pesada no afecte al rendimiento de todo el sistema.



C a c h i n g: En este subapartado se define todo lo que tiene que ver con el cacheo. Coldfusion puede cachear plantillas CFML, ficheros .CLASS o incluso consultas a la base de datos. Es bastante importante el parámetro “Maximum number of cached queries”, que precisamente indica el número máximo de consultas que puede tener cacheadas. Si las consultas son normalmente de muchos datos, no conviene tener un número muy alto, pues el consumo de memoria se puede disparar. En general, con todas las opciones de este apartado, hay que ser cuidadoso, pues consiguen que la aplicación vaya más rápida, pero para ello es necesario tener bastante memoria libre en el servidor. M a p p i n g s: los mappings de Coldfusion son “atajos” a los directorios accesibles desde el servidor que se quiera. En vez de tener que poner en el código las rutas completas de un fichero que se necesite, se le asigna un alias en este subapartado. M a i l: Si queremos que el servidor envíe correos, es necesario configurarlo en este apartado, poniéndole el servidor SMTP. J a v a a n d J V M: En este subapartado se configura la Java Virtual Machine que se quiere utilizar, el CLASSPATH donde se podrán buscar clases Java, etc. Aparte del CLASSPATH, no es conveniente tocar demasiado estos parámetros.

El acceso está restringido por una contraseña que se introduce durante la instalación del servidor. A continuación, se van a explicar los apartados más importantes de este administrador, para poder configurar todo lo que se necesite, así como los valores adecuados para ciertos parámetros de configuración que serán vitales para que el rendimiento del servidor sea el adecuado.

Server Settings Este es el apartado fundamental de la configuración, donde se definen los parámetros que afectarán al rendimiento del servidor. Entre sus subapartados, los más destacables son:  S e t t i n g s: En este subapartado hay parámetros generales como “Maximum number of simultaneous requests”, que es el número de peticiones simultáneas que puede recibir el servidor. No porque pongamos un número muy grande se van a atender más peticiones. Cuando se llega a un límite, es mejor rechazarhttp://digital.revistasprofesionales.com

Coldfusion tiene varias opciones de cacheo, de plantillas, consultas a bases de datos, etc. que mejoran el rendimiento.

61

SOLO PROGRAMADORES nº 128


REDES

Data & Services Aquí se configura todo lo que tiene que ver con el acceso a datos externos, y sus subapartados destacables son:  D a t a S o u r c e s: Este subapartado ya se introdujo en la primera entrega, y es donde se pueden configurar los accesos a las bases de datos. Es muy sencillo, pues simplemente hay que poner el nombre que le queremos dar (el que se usará después en la etiqueta “<cfquery>”), y el tipo de base de datos que es (SQL Server, MySql, Oracle, etc.), y el sistema pide los datos que necesita para cada una. Desde aquí mismo se podrá probar el correcto funcionamiento de la conexión.  W e b S e r v i c e s: De este subapartado también se habló en la entrega anterior, y es donde se publican los servicios web alojados en el servidor. Se introduce la URL del fichero de definición (WSDL), se le da un nombre, y ya estará accesible sin necesidad de tener que recordar la URL cada vez que se invoque. También permite guardar el usuario y contraseña de acceso al servicio web.

que hemos explicado en esta misma entrega. Los subapartados son:  C F X T a g s : Aquí se pueden registrar las etiquetas de Coldfusion eXtensions, tanto las desarrolladas en Java, como las desarrolladas en C++.  C u s t o m T a g P a t h s : En este subapartado se define de qué directorios se pueden coger los ficheros .CFM de las etiquetas propias. C o n n e c t o r s : Desde  CORBA Coldfusion también se puede conectar con CORBA. Se puede registrar un conector CORBA, de manera que Coldfusion cargue dinámicamente las ORB Java Libraries.

Event Gateways Las Event Gateways de Coldfusion son unos componentes que pueden generar o reaccionar a eventos de una forma asíncrona. Además la información no tiene por qué llegar vía HTTP. Normalmente se utiliza para paso de mensajes. En esta apartado, se pueden configurar este tipo de elementos.

Debugging & Logging

Security

Como su propio nombre indica, este apartado está dedicado a la configuración de los temas de depuración y los logs del sistema. Se pueden definir los ficheros, formatos, tamaños o rotaciones de los ficheros de log del servidor. Los apartados más interesantes, y menos evidentes son:  S c h e d u l e d T a s k s: En este subapartado se pueden crear tareas programadas. Es decir, se puede llamar a una URL, en un día y hora concretos, o llamar diariamente, mensualmente, etc. Esto es útil para tareas periódicas de administración.  S y s t e m P r o b e s: Esta herramienta, es parecida a la anterior, en la medida que se puede lanzar una llamada a una URL definiendo la periodicidad, pero en este caso, el servidor analiza la respuesta, y si difiere de la que se haya definido como correcta, puede enviar un email, o ejecutar un script. Esto es ideal para tareas de monitorización, pues puede dar la alarma del fallo de algún sistema.

En este apartado se permite cambiar la contraseña de acceso al propio administrador y la contraseña de acceso RDS, que se usa para el acceso a elementos de Coldfusion desde otras aplicaciones de Macromedia, como DreamWeaver o HomeSite.

Extensions En este apartado, se podrán registrar y configurar las extensiones de Coldfusion

SOLO PROGRAMADORES nº 128

62

Packaging & Deployment El empaquetamiento y posterior despliegue de aplicaciones utilizando ficheros, se puede realizar desde este apartado. Sus subapartados son:  C o l d f u s i o n A r c h i v e s ( . c a r ) : Los ficheros .CAR permiten empaquetar y posteriormente desplegar en un sitio web, la configuración, los ficheros y las aplicaciones. Desde este subapartado se pueden empaquetar los ficheros o aplicaciones existentes en el servidor o desplegar en él los ficheros .CAR generados previamente.  J 2 E E A r c h i v e s ( . e a r / . w a r ) : En este subapartado se pueden empaquetar las aplicaciones en ficheros J2EE para desplegarlos en otro servidor.

Conclusiones Después de mostrar, en las dos entregas anteriores, todos los elementos que Coldfusion proporciona a los programadores web, en esta tercera y última entrega nos hemos centrado en la creación de elementos propios que faciliten la reutilización de código, y en cómo compatibilizar Coldfusion con otros lenguajes de programación. Una gran ayuda para la reutilización de código es la creación de etiquetas propias, que se crean en el mismo lenguaje CFML, y que una vez creadas, pueden ser accedidas desde cualquier fichero .CFM del servidor de Coldfusion. La creación de funciones propias, aunque menos potente que las etiquetas, pues hay que incluirlas explícitamente en cada lugar que se vayan a utilizar, también sirve para no tener que repetir código igual en varias páginas. El hecho de que Coldfusion sea internamente un servidor de aplicaciones Java, permite que el lenguaje CFML tenga gran compatibilidad con cualquier elemento de Java, tanto JSP como clases Java, pueden ser referenciadas desde Coldfusion, e incluso se puedan crear etiquetas propias hechas exclusivamente en Java. También es posible crear este tipo de etiquetas en C++. Finalmente, se han mostrado los principales elementos del administrador vía web de Coldfusion, que permite configurar todos los parámetros del servidor. Es muy importante una buena configuración del servidor, principalmente cuando se crean páginas de muy alta disponibilidad, y con gran cantidad de contenido dinámico. De esto dependerá la velocidad de respuesta al usuario final. Como conclusión final de las tres entregas, se puede afirmar que, hoy en día, Coldfusion es una opción perfectamente válida para el desarrollo de cualquier aplicación web, que tiene un lenguaje de programación muy sencillo, cuyo aprendizaje es prácticamente inmediato para cualquier persona con conocimientos de programación básicos y que, con todas las facilidades que proporciona, permite disminuir los tiempos de desarrollo drásticamente. http://digital.revistasprofesionales.com


DUDAS

Preguntas y respuestas ADOLFO ALADRO GARCÍA

Estoy utilizando el JDK 1.5 y quiero trabajar con ficheros XML. He estado mirando la documentación del API pero no consigo encontrar un ejemplo c l a r o y s e n c i l l o a c e r c a d e c ó m o p a r s ea r u n X M L , o p o r e j e m p l o c ó m o a p l icarle una hoja de estilo XSL. ¿Podéis mostrarme algunos ejemplos sencillos para empezar a trabajar con XML? El siguiente ejemplo muestra un típico fichero XML de datos: <?xml version=”1.0” encoding

“newDocumentBuilder”. El objeto “Document Builder” es el que se emplea tanto para parsear un documento ya existente como para crear uno nuevo desde cero. En el ejemplo anterior se parsea el documento “books.xml” empleando el método “parse”, el cual admite distintos tipos de parámetros tal y como puede verse en la documentación del API (véase la figura 1). A veces puede ocurrir que el documento XML emplee un DTD a fin de que se pueda verificar que el documento es válido: <?xml version=”1.0” encoding= ”ISO-8859-1”?> <!DOCTYPE links SYSTEM “books.dtd”>

=”ISO-8859-1”?> <books>

<books>

...

<book id=”123”> <title><![CDATA[Nunca te acostarás sin saber dos o tres cosas más]]></title> <autor><![CDATA[H.Cortijo]]></author> </book>

</books>

En ese caso hay que indicar al objeto “DocumentBuilderFactory” explícitamente que se desea validar el documento antes de obtener el objeto “DocumentBuilder”: docBuilderFactory.setValidating(true);

</books>

Existen dos formas básicas de parsear este documento: mediante DOM o mediante SAX. En el primer caso se crea en memoria una estructura arborescente que representa al documento y que viene dada en forma de objeto Document:

Figura 1. El paquete “javax.xml.parsers” contiene todas las clases necesarias para parsear documentos XML.

En este caso si el documento no es válido se lanza una excepción durante la ejecución del método parse. Antes de pasar a ver cómo se puede parsear un documento con SAX, vamos a mostrar un par de ejemplos básicos de transformaciones XSLT.

La transformación más sencilla es aquella que se emplea para obtener una cadena de texto con el documento XML, o lo que es lo mismo, la que se utiliza por ejemplo para salvar un objeto de tipo “Document”, o sea, un fichero XML (véase el listado 1). En primer lugar se obtiene un objeto de tipo “TransformerFactory” mediante el método “newInstance”. Con este objeto se puede obtener otro de tipo “Transformer” que es en realidad el responsable de realizar la transformación. El método “transform” recibe dos parámetros: el primero es la entrada y el segundo es la salida. En este ejemplo la entrada es un objeto de tipo “DOMSource” que se construye a partir del objeto “Document” que representa al fichero XML. La salida es un objeto de tipo “StreamResult”. Éste se construye a partir de un

try { DocumentBuilderFactory docBuilderFactory = DocumentBuilderFactory.newInstance(); DocumentBuilder docBuilder = docBuilderFactory.newDocumentBuilder (); Document doc = docBuilder.parse (new File(“C:\\books.xml”)); } catch (Exception e) { e.printStackTrace(); }

En primer lugar se obtiene una nueva instancia de la clase “DocumentBuilderFactory” empleando para ello el método “newInstance”. Después se crea una instancia de la clase “DocumentBuilder” con el método

SOLO PROGRAMADORES nº 128

64

LISTADO 1

Transformación XSLT (I)

StringWriter sw = null; BufferedWriter bw = null; try { TransformerFactory transFactory = TransformerFactory.newInstance(); Transformer transPlainText = transFactory.newTransformer(); sw = new StringWriter(); StreamResult streamResult = new StreamResult(sw); DOMSource domSource = new DOMSource(doc.getDocumentElement()); transPlainText.transform(domSource, streamResult); sw.flush(); String sXmlString = sw.toString(); bw = new BufferedWriter(new FileWriter(new File(sFilePath))); bw.write(sXmlString); bw.flush(); } catch (Exception e) { e.printStackTrace(); } finally { try {if (sw!=null) sw.close();} catch (Exception e) {} try {if (bw!=null) bw.close();} catch (Exception e) {} }

http://digital.revistasprofesionales.com


DUDAS

Preguntas y respuestas

LISTADO 2

Transformación XSLT (II)

BufferedInputStream bis = null; StringWriter sw = null; try { ... bis = new BufferedInputStream(new FileReader(“C:\\books.xslt”)); StreamSource streamSource = new StreamSource(bis); Transformer transHTML = transFactory.newTransformer(streamSource); DOMSource domSrc = new DOMSource(doc.getDocumentElement()); transHTML.transform(domSrc, sw); ... } catch (Exception e) { e.printStackTrace(); } finally { try {if (bis!=null) bis.close();} catch (Exception e) {} }

Lo único que indicas es que el contenido de la capa se ha de centrar con respecto a la capa misma, pero nada sobre la propia capa con respecto a la página. Existen varios métodos para centrar capas con CSS. Dos de los más conocidos son los que se muestran seguidamente: .mylayer { position: relative; width: 772px; left: 50%; padding: 0px 0px 0px 0px;

canal de escritura de tipo “StringWriter” y permite “volcar” el XML en forma de cadena de texto. Cuando se emplea una hoja XSLT el proceso es similar si bien el objeto “Transformer” se obtiene a partir de una fuente dada (véase el listado 2). Por último, cuando se desea parsear un documento empleando para ello SAX hay que construir una clase que extienda a la clase “DefaultHandler”. El listado 3 muestra una versión muy simple para el fichero XML del ejemplo de partida. Dicha clase se emplea para parsear el documento haciendo: SAXParserFactory saxParserFactory = SAXParserFactory.newInstance(); SAXParser saxParser = saxParserFactory.newSAXParser();

br = new BufferedReader(new

margin: 0px 0px 0px -386px;

FileReader(“C:\\books.xml”)); } InputSource inputSource = new InputSource(br); saxParser.parse(inputSource, new Reader());

¿De qué forma se pueden centrar las capas con CSS dentro de la página HTML en función de su contenido? Haciendo “align=”center”” no parece que funcione. Efectivamente cuando haces algo del tipo: <div class=”mylayer” align=”center”>...</div>

En este caso la capa tiene posicionamiento relativo, es decir, se coloca en la página siguiendo el flujo “normal” teniendo en cuenta los elementos adyacentes. La anchura de la capa se fija mediante el atributo “width”. El truco consiste en desplazar la capa un 50% a la izquierda y luego darle un margen negativo exactamente igual a la mitad de su anchura. El principal inconveniente de este método es que la anchura de la capa tiene que estar definida con antelación, es decir, no se centra en función de los contenidos. Veamos otro método, similar al anterior, aunque algo más sencillo: .mylayer {

LISTADO 3

La clase Reader

width: 772px; margin-left: auto;

public class Reader extends DefaultHandler { private CharArrayWriter contents = new CharArrayWriter();

margin-right: auto; }

public void startElement(String sUri, String sLocalName, String sQName, Attributes attrs) throws SAXException { contents.reset(); if (sQName.equals(“book”)) { if (attrs!=null) { int iLength = attrs.getLength(); for(int i=0; i<iLength; i++) { if (attrs.getQName(i).equals(“id”)) { // attrs.getValue(i) es el valor del atributo } } } } else if ... { ... } } public void endElement(String sUri, String sLocalName, String sQName) throws SAXException { if (sQName.equals(“title”)) { // contents.toString() tiene el contenido del elemento } else if ... { ... } } public void characters(char[] ch, int start, int length) throws SAXException { contents.write(ch, start, length); } }

http://digital.revistasprofesionales.com

Figura 2. El valor “auto” de los atributos “margin-left” y “margin-right” puede emplearse para centrar una capa.

La anchura de la capa también está definida. El valor “auto” de los atributos “margin-left” y “margin-right” indican que la página se centrará respecto a su contenedor. Estos dos métodos funcionan igualmente en Internet Explorer y Mozilla Firefox.

65

SOLO PROGRAMADORES nº 128


LIBROS

Paralelismo en computadores y C++ Arquitectura de computadores AUTORES: Julio Ortega, Mancia Anguita, Alberto Prieto EDITORIAL: Thomson Paraninfo ISBN: 84-9732-274-6 PÁGINAS: 637 LUGAR Y AÑO DE PUBLICACIÓN: Madrid, 2005 IDIOMA: Castellano

Este texto aborda, a través del estudio del paralelismo en sus distintos niveles, los conceptos y las técnicas de la arquitectura de computadores que permiten aprovechar las posibilidades de la tecnología para lograr mayores capacidades de procesamiento. A pesar de la importancia creciente que tiene el paralelismo en computadores hay una gran escasez de libros (en cualquier lengua) que aborden el tema en toda su extensión. La obra de los profesores Julio Ortega, Mancia Anguita y Alberto Prieto cubre brillantemente este objetivo, resultando, además, su lectura muy didáctica y amena, incluyendo gran cantidad de ejemplos reales. Se presentan los contenidos desde los principios de una ingeniería, estudiando las distintas alternativas de diseño de las arquitecturas actuales y sus prestaciones y eficiencia. Desde esta perspectiva,

Aprenda C++ AUTORES: Jesse Liberty, David B. Horvath EDITORIAL: ANAYA ISBN: 84-415-1814-9 PÁGINAS: 544 LUGAR Y AÑO DE PUBLICACIÓN: Madrid, 2005 IDIOMA: Castellano

La versatilidad, potencia y uso generalizado han convertido a C++ en el lenguaje más utilizado por los programadores y profesionales para la creación y desarrollo de aplicaciones. Manteniendo la riqueza y eficiencia de C pero eliminando sus limitaciones, C++ ha evolucionado hacia otros lenguajes como Java o C#, los cuales comparten sintaxis con C++, pero cuya comprensión y aplicación práctica resultan más complejas. Esta obra está pensada y diseñada para ayudarle a que aprenda por sí mismo cómo programar con C++. A través de una clara organización y con capítulos bien estructurados y fáciles de

SOLO PROGRAMADORES nº 128

66

el libro abarca el paralelismo en todos los niveles en los que está presente en los computadores actuales: paralelismo de datos (procesadores vectoriales y arquitecturas SIMD); entre instrucciones (procesadores segmentados, superescalares, VLIW); entre hebras o entre procesos que aprovechan las arquitecturas multihebra y sistemas multiprocesador (SMP, NUMA, multicomputadores, cluster). Otros tópicos que se consideran son redes de altas prestaciones, redes SAN, jerarquía de memoria, coherencia y consistencia en el sistema de memoria, computación de altas prestaciones, programación paralela, optimización de código. Desde un punto de vista didáctico, se presenta la información unificada y estructurada, con numerosos ejemplos de apoyo y datos de procesadores y computadores actuales y disponibles comercialmente. El libro está pensado tanto para la docencia de asignaturas de las materias de arquitectura e ingeniería de computadores del segundo ciclo de la titulación de ingeniero en informática, como para su uso en cursos que aborden tópicos de ingeniería de computadores o de altas prestaciones en otras titulaciones relacionadas con las tecnologías de la información y las comunicaciones.

seguir aprenderá fundamentos tales como gestión de E/S, bucles y matrices, programación orientada a objetos, plantillas y creación de aplicaciones C++. Los numerosos ejemplos de sintaxis y el análisis detallado del código que complementan al texto son una excelente guía para facilitar e ilustrar cada capítulo y conseguir que dominar C++ le resulte una tarea sencilla y rápida:  Cree de forma sencilla y rápida programas orientados a objetos en C++.  Domine los conceptos fundamentales de C++ como funciones, clases, matrices y punteros.  Añada funcionalidad y eficiencia a sus aplicaciones con listas y plantillas vinculadas.  Depure los programas para conseguir un código impecable.  Utilice técnicas de manipulación de excepciones y errores.  Desarrolle código conforme al estándar ANSI para facilitar su reutilización.

http://digital.revistasprofesionales.com

Revista Solo Programadores #128  

Noticias, javaHispano y Opinión, Libros, Preguntas y Respuestas 8 413042303299 LA PRIMERA REVISTA DE PROGRAMACIÓN EN CASTELLANO MIDDLEWARE D...