Revista Solo Programadores #128

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

GRATIS

CD INCLU

IDO LA PRIMERA REVISTA DE PROGRAMACIÓN EN CASTELLANO

Noticias, javaHispano y Opinión, Libros, Preguntas y Respuestas8 413042 303299

00128

ACTUALIDADTecnologías Grid para la computacióndistribuida

DISPOSITIVOS MÓVILESCreación de un sistema de distribuciónde Midlets según el modelo OTA y basado en IIS

El GPS como “medio de comunicación”

MIDDLEWAREDesarrollos avanzados con Struts

REDESIntegración de elementos Java y C++en ColdFusion MX 7

CANAL PANDA¿Todos para uno? ¡Uno para todos!

Creamos, paso a paso,nuestro primer servicio web con

Número 128

EEddiittaa:: RREEVVIISSTTAASS PPRROOFFEESSIIOONNAALLEESS SS..LL..

[email protected]

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

http://www.revistasprofesionales.com

http://digital.revistasprofesionales.com

EEddiittoorr

Agustín Buelta

••••••••••••••••••••••••••••••••••

CCoooorrddiinnaacciióónn TTééccnniiccaa--RReeddaacccciióónn

Carlos Laparra

••••••••••••••••••••••••••••••••••

MMaaqquueettaacciióónn

Alfonso Sabán Mejías

••••••••••••••••••••••••••••••••••

AAsseessoorrííaa ddee PPuubblliicciiddaadd

Felipe Ribagorda

Tel.: 91 304 87 64

DDeelleeggaacciióónn eenn BBaarrcceelloonnaa

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

Mariano Sánchez

Tel.: 93 322 12 38

••••••••••••••••••••••••••••••••••

SSuussccrriippcciioonneess

Tel: 91 304 87 64

Fax: 91 327 13 03

•••••••••••••••••••••••••••••••••••

IImmpprreessiióónn

Ideas de Impresión

•••••••••••••••••••••••••••••••••••

DDiissttrriibbuucciióónn

Motorpress Ibérica

DDIISSTTRRIIBBUUCCIIOONN EENN MMEEXXIICCOODIMSA - C/ Mariano Escobedo, 218

Col. Anáhuac. 11320 México, D.F.

DDIISSTTRRIIBBUUCCIIOONN EENN AARRGGEENNTTIINNAACapital Federal: Distrimachisa

Interior:York Agencysa - Tlf: (5411) 433 150 51

RREEPPRREESSEENNTTAANNTTEE EENN MMEEXXIICCOOAngel Bosch - [email protected]

Distribución, números atrasados y suscripcionesC/ 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 revistasin su autorización escrita.

Depósito legal: M-26827-1994

PPRRIINNTTEEDD IINN SSPPAAIINN

COPYRIGHT 30-06-2005

P.V.P. 6,00 Euros

Precio en Canarias, Ceuta y Melilla:

6,15 Euros

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

ACTUALIDAD1122 Tecnologías Grid o de computación distribuida

DISPOSITIVOS MÓVILES2200 Creación de un sistema de distribución de Midlets (y II)

2266 El GPS como “medio de comunicación”

MIDDLEWARE3366 Struts práctico (y III)

REDES5500 Pruebas funcionales y de rendimiento con JMeter

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

Y ADEMÁS. . .0044 Noticias

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

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

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

6644 Preguntas y respuestas

6666 Libros: Paralelismo en computadores y C++Asociación Española de Editoriales

de Publicaciones Periódicas

EE DD II TT OO RR II AA LL

SS UU MM AA RR II OO

NOTICIAS

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

MICROSOFT

Microsoft presenta las novedades en su solución de gestiónde relaciones con clientes

Microsoft ha adelantado, en la reciente edición europea de MicrosoftTechEd 2005, algunas de las novedades de su solución de gestión derelaciones 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 retosfundamentales que determinan el éxito o el fracaso de la mayoría de lasiniciativas CRM en una empresa: la adopción por parte del usuario, laadecuación al negocio y el coste total de propiedad. Microsoft CRM 3.0se 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 MicrosoftOutlook. Además Microsoft CRM 3.0 tiene en cuenta los requeri-mientos de movilidad, ofreciendo un cliente mejorado paraMicrosoft Windows Mobile.

� Ofrece un exhaustivo módulo de automatización de marketing parala gestión de listas, campañas y recursos de marketing, cerrando el

ciclo con la gestión de res-puestas. Esta nueva versióntambién incluye un nuevomódulo de planificación deservicio, que gestiona auto-máticamente peticiones deplanificación complejas querequieren personal, recursosy habilidades específicos.

� Amplía las opciones de configuración, personalización e integraciónpara 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 hostingCon el lanzamiento de Microsoft CRM 3.0, la compañía presenta unnuevo licenciamiento basado en suscripción para clientes que prefieranuna oferta en modo hosting, promoviendo el compromiso de Microsoftde proporcionar un CRM flexible y asequible tanto para los modelos on-site como para implementaciones en modo hosting. Dado que ambosmodelos utilizan el mismo código, los clientes pueden cambiar sumodelo de implementación preferido de un modelo hosted a otro on-site y viceversa, según cambien sus necesidades de negocio y de TI.

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

SOLO PROGRAMADORES nº 128

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 porRepsol 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 deestaciones de servicio de gestión propia en España, agrupadas bajos lasmarcas Repsol, Campsa y Petronor.La solución Datawarehouse adquirida incluye el potente motor de basede datos NCR Teradata, el Modelo Lógico de Datos para la industria deDistribución (LDMR), así como servicios profesionales y de mantenimien-

to. El objetivo principal quepersigue Repsol YPF al implan-tar este Datawarehouse esobtener valor de negocio apartir del análisis en detalle dela información de ventas aten-diendo a múltiples factores:

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 delnegocio, facilitando un acceso inmediato y una toma de decisiones rápi-da y precisa sobre aspectos de precios, surtidos, promociones, perfiles decompras, etc.El núcleo de la solución contempla extensiones para cubrir en el futurootros aspectos del negocio tales como la gestión de stocks, análisis deproveedores, logística, márgenes, parámetros financieros, así como laevolución para el desarrollo de herramientas CRM (Gestión de la Relacióncon Clientes). La implantación por parte de Repsol YPF de un sistemaDatawarehouse demuestra cómo un correcto análisis de los datos puedeconducir a una buena estrategia comercial.

SUN MICROSYSTEMS e IBM

Sun e IBM amplían su acuerdo sobre tecnología Java

En un movimiento que renueva sucompromiso para colaborar en eldesarrollo de la plataforma Java, IBM ySun Microsystems anunciaron el pasa-do mes que han extendido diez años suacuerdo para el desarrollo de la tecno-logía Java, con el fin de ofrecer estabi-lidad a largo plazo a los más de 4,5

millones de desarrolladores de la comunidad Java. En virtud delacuerdo, 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 (JavaSE), Java Platform, Micro Edition (Java ME) y Java Card en todossus productos de software, incluida su cartera de servicios web ymiddleware.Sun e IBM también continuarán avanzando y mejorando eldesarrollo de tecnologías Java a través de la cooperación en JavaCommunity Process (JCP). Además, IBM también ampliará supapel para convertirse en un partner de canal para el desarrollode productos compatibles con Java.Por otra parte, y en respuesta a las demandas de los clientes, IBMampliará el soporte a DB2, Rational, Tivoli y WebSphere paraincluir el sistema operativo Solaris 10 sobre plataformas x64basadas en AMD Opteron.

NOTICIAS

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

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 forOperational BI. Esta nueva solución amplía la plataformaBusinessObjects XI y permite multiplicar la utilidad de BI para un mayornúmero de personas dentro de la organización. BusinessObjects XI Built for Operational BI ofrece dos nuevos compo-nentes integrados: BusinessObjects Process Tracker y BusinessObjectsProcess Analysis. La combinación de estos dos componentes proporcio-na el eslabón crítico entre la gestión del rendimiento (PerformanceManagement) y la gestión de operaciones (Business Operations), ya quepermite alinear BI con los procesos de negocio relacionados con la tomade 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 arquitecturamoderna orientada a servicios (SOA), y es la única plataforma de BI defiabilidad certificada para Microsoft Windows Server 2003 Datacenter.Además, la decidida apuesta por los estándares del sector, entre ellos losrelativos a procesos de negocio, y el completo repertorio de serviciosweb, permiten integrar BI con otras aplicaciones de una manera fácil yeconómica. Este tipo de software, pensado para facilitar las prácticas de

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

PROINNOVA

El Parlamento Europeo rechaza la propuesta de directiva sobre patentes de software

El pleno del Parlamento Europeo rechazó, el pasado mes dejulio, la propuesta de directiva sobre patentes de software apo-yada por la Comisión Europea y el Consejo Europeo.El Parlamento Europeo ya pidió hace unos meses que la pro-puesta de directiva fuera retirada y, en su caso, vuelta a plan-tear en términos más cercanos a la postura del Parlamento. Conla votación celebrada el pasado mes, el Parlamento se reafirma

en la posición de no aceptarnuevas propuestas queamplíen el ámbito de lopatentable. De hecho, la deci-sión del Parlamento ha sidohistórica: nunca antes sehabía rechazado una direc-tiva en este momento del

trámite y con un apoyo tan grande. Ahora la situación continuaregida por el Convenio Europeo de Patentes, que en su artículo52 especifica que los programas de ordenador no están en elámbito de lo patentable.

NOTICIAS


TELELOGIC

Telelogic perfecciona su suite de herramientas ALM

Telelogic ha dado a conocer la disponibilidad de las nuevas versio-nes de sus herramientas Telelogic DOORS (para la gestión de requi-sitos), Telelogic SYNERGY (para la gestión de cambio y configura-ción) y Telelogic TAU G2 (para el desarrollo liderado por modelos).Esta nueva suite de componentes integrados, conforma la apuestade soluciones de gestión de ciclo de vida (ALM) de Telelogic.Las novedades incorporadas a la última versión de DOORS puedenresumirse en un mayor soporte de idiomas (ofreciendo un correc-tor ortográfico para 15 idiomas), un proceso de gestión de cambiosmás flexible e integrado con la gestión de cambios de todo el ciclode vida y un seguimiento completo de los cambios para establecerun registro de dependencias históricas.Por su parte, SYNERGY incorpora una nueva interfaz con el objeti-vo de facilitar la asimilación de la herramienta por parte del usua-rio, lo que supuestamente debe reforzar la productividad del usua-rio y del equipo.

Y por último, TAU G2 ofrece la posibilidad de diseñar pruebas y eje-cutarlas en los modelos, obteniendo los informes en HTML, y unamayor integración con otros productos de Telelogic, como porejemplo SYNERGY.

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 ySun Microsystemshan firmado unacuerdo de colabo-ración que permitea la primera poten-ciar espectacular-mente sus punterascapacidades de ani-mación por ordena-dor.Con diecisiete añosde experiencia en elmundo de la comu-nicación y la pro-ducción audiovisual,Dygra Films es laprincipal productoraespañola de películas de animación por ordenador. Su primeraproducción “El bosque animado” (galardonada con dosGoya, además de obtener numerosos premios interna-cionales y haber sido preseleccionada para el Oscar2002 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 deeste proyecto, Dygra Films decidió embar-carse en la producción de un nuevo largo-metraje de animación 3D, “Elsueño de una noche de SanJuan”, una adaptación libre dela obra “Sueño de una nochede verano”, de William Shakespeare.Esta producción, que puede verse actual-mente en los cines de 65 países, representa una clara

apuesta por Java, GNU/Linux y los están-dares abiertos.Tras estudiar las necesidades deDygra Films, Sun y ArcadeConsultores (su socio de valorañadido en este proyecto) inicia-ron un proceso de evoluciónde las granjas de ser-vidores de renderiza-ción de que disponíaDygra Films tanto anivel de hardwarecomo de software, con elobjetivo de optimizar almáximo las capacidades deproducción de la compañía.Para ello, se migró de la pla-taforma de servidores exis-tente a otra basada en servidoresSun sobre AMD Opteron y sistema operativo Debian GNU/Linux.Esta evolución se pudo realizar gracias a que se desarrolló ad-hoc una aplicación software basada en Java para la gestiónhomogénea del proceso de renderización de las imágenes. Enuna 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 dobleprocesador AMD Opteron, cuatro servidores SunFire V240, Sun StorEdge 3510 FC Arrays, SunStorEdge L100 Tape Library.Estos cambios han potenciado espectacular-

mente las punteras capacidades de ani-mación por ordenador de Dygra Films,

prueba de ello es que “ElEspíritu del Bosque” es lanueva película que se

encuentra en producción(secuela del primer film de Dygra) y

que se estrenará en 2006.

TAU G2 ofrece soporte a UML 2.0.

NOTICIAS

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

BEA SYSTEMS

Lanzamiento de la nueva familia de productos BEA AquaLogic para el desarrollo SOA

BEA Systems ha presentado recientemente BEA AquaLogic, una nuevafamilia de productos diseñada para ofrece una plataforma abierta e inde-pendiente que sirva para desplegar, gestionar y manejar una completaArquitectura Orientada a Servicios (SOA) en entornos de computaciónheterogéneos, incluyendo Java, .NET u otros sistemas heredados. BEAAquaLogic permite que los servicios de software sean producidos unaúnica vez y utilizados desde cualquier punto, ayudando de este modo alos usuarios a transformar sus activos de TI “congelados” en activos líqui-dos, para responder de forma más rápida a las nuevas necesidades de losnegocios modernos.Hoy en día los entornos de TI están comprometidos con múltiples tec-nologías y plataformas de aplicaciones que no permiten compartir infor-mació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 laArquitectura Orientada a Servicios, el escenario empresarial más comúncontempla una infraestructura distribuida y combinada que hace muycomplicada su integración y gestión.Desde BEA se afirma que con BEA AquaLogic es posible construir servi-cios sobre plataformas heterogéneas para ser descubiertos, asegurados,gestionados y unidos a través de potentes herramientas de composicióny gestión.La familia de productos BEA AquaLogic está diseñada para ser la másamplia línea de producto de infraestructura de servicios y la primera suitede producto construida para el campo de SOA.

Las tres principales tecnologías parael desarrollo de SOA De los resultados de una encuesta rea-lizada por BEA Systems entre más de800 desarrolladores europeos, se des-prende el echo de que los serviciosweb, la partición de mensajes y el busde servicios son las tecnologías másútiles para el desarrollo, el despliegue yla gestión de Arquitecturas Orientadasa Servicios.Cerca del 90% de los encuestadoscitaron los servicios web como el fac-tor más importante en el desarrollo deSOA. Sin embargo, la principal preocu-pación de los desarrolladores encues-tados son, en primer lugar los estánda-res de servicios web, seguidos por lapercepción de complejidad que tienenacerca de un despliegue basado enSOA. En este sentido, cerca de la mitad

de los desarrolladores encuestados (40%) destacaron que el bus de ser-vicios (service bus) puede reducir dicha complejidad y simplificar la inte-gración. En este sentido, aclararemos que un bus de servicios (ESB) es unatecnología emergente para la integración de aplicaciones. Es la espinadorsal que permite integrar aplicaciones dispares facilitando el flujo deinformació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 lamayor parte de sus esfuerzos de integración en la capa de aplicacioneslo que subraya la actual dificultad para la integración de grupos de apli-caciones propietarias o de software a través de silos de aplicacionesverticales.

BEAWorld, a partir del mes que vieneBEA Systems anunció el pasado mes las fechas y lugares de celebraciónde su evento BEAWorld, que tendrá lugar en seis ciudades diferentes. Seespera que asistan desarrolladores de software, arquitectos de negocio yde TI, directores de TI y partners de BEA, además de miles de participan-tes que se registraran a través de la web, donde podrán encontrar másinformació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 14de octubre); Praga (18 y 19 de octubre); Tokio (25 y 26 de octubre); yPekí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 lanza-miento de sus nuevos módulos de memoria non-stackedDDR400 de 1 GB con chip FBGA de elevada velocidad y capaci-dad para ordenadores portátiles. Estos módulos de memoria están especialmente diseñadospara ordenadores notebook de alta calidad. Además, su velocidad permite ofrecer un magnífico rendimien-to para los usuarios de juegos y aplicaciones gráficas. Estosnuevos módulos de memoria, de 200 pines y 1 GB de capaci-

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

SOLO PROGRAMADORES nº 128 8 http://digital.revistasprofesionales.com

JAVAHISPANO

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

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".

Desaparece el "2" en los nombres de las ediciones de la plataforma

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

tituto 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 forma-

rá parte del estándar DVD Blu-ray y, en primicia mundial, se mostró las posi-

bilidades 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.

Confirmado: Java estará presente en la próxima generación de DVDs

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

dad 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.

Apache Gerónimo pasa el test de compatibilidad de J2EE

SOLO PROGRAMADORES nº 1289http://digital.revistasprofesionales.com SOLO PROGRAMADORES nº 127

JAVAHISPANOjavaHispano

Sobre el autor

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

Sun ha hecho públicas dos novedades bastante destacables paraDolphin, la versión 7 del JDK. La primera, el integrar el tratamiento deXML en el propio lenguaje, permitiendo códigos como el que aparece acontinuación:

void addReviewed (Feature aFeature, user, ...) {

aFeature.add(<reviewed><who>{user}</who></reviewed>);

}

Esta idea no es nueva; existen prototipos de lenguajes que integranXML pero Java será, probablemente, el primer lenguaje de uso habitualen aplicaciones reales en integrarlo.La última novedad, aunque no es completamente seguro que esté listaa tiempo para incorporarse a Dolphin, es la sustitución de los ficherosJAR por un nuevo mecanismo para empaquetar aplicaciones Java. El JSR277, Java Module System, busca definir este nuevo formato, que serámodular, incluirá información sobre dependencias y versiones, y permi-tirá el descubrimiento, la carga y el chequeo de la integridad de recur-sos en tiempo de ejecución.

Novedades para Java SE 7, Dolphin

Oracle anunció durante la JavaOne que su entorno de desarrollo JDeveloper 10g

pasará a ser gratuito. Este IDE incluye herramientas de modelado UML, herramien-

tas 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 cre-

ciente 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.

JDeveloper 10g pasará a ser gratuito

OPINIÓN

Trabajar en el extranjero

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

mularse dudas y miedos a partes iguales, así que aca-

bamos 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 enri-

quecedora tanto a nivel profesional como personal.

Como programador me he encontrado con un traba-

jo 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 conoci-

miento, y además, se te paga de acuerdo a eso. Voy a

repetirlo... Se te valora, respeta y paga como es debi-

do.

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

do 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 acor-

de a tus conocimientos, y no lo consigues en tu país...

¡Vente!

Iván Pedrazas ([email protected]), Sword UK

SOLO PROGRAMADORES nº 128 10

CANAL PANDA

¿Todos para uno? ¡Uno para todos!¿Todos para uno? ¡Uno para todos!


Hace ya unos años, las soluciones ofimáticasque estaban en la mayor parte de los PC noeran suites como las que hoy en día podemosdisfrutar. Cada aplicación estaba desarrolladapor un fabricante distinto, y en muy pocoscasos estaba prevista la exportación de losdatos entre aplicaciones tan distintas.Por ejemplo, una tarea realmente complejaera hacer un mailing (de los de meter en unsobre, lo del e-mailing hace 15 años era, sim-plemente, futurista) con datos de dBase III,en un documento de WordPerfect 4.2 queincorporara un gráfico hecho con HarvardGraphics 3.0 en función de unos datos queestaban en una hoja de cálculo de Lotus 1-2-3 3.0. Todos aquellos que hayan hecho (osimplemente intentado hacer) esta tarea lorecordarán con una relativa angustia.

Hoy en día la integración de los datos esmucho más sencilla, existen las suites ofimá-ticas que manejan datos comunes con unafacilidad asombrosa. Da igual que los datosestén en un formato distinto, los sistemasoperativos facilitan el compartirlos de unamanera muy sencilla. Incluso pueden serdatos remotos, que no va a tener ningún pro-blema.Pero sin embargo, parece que hayamos dadoun paso atrás en la integración de aplicacio-nes. Toda la unificación de la que disponemosen las suites se convierte en una dispersiónabsoluta en el caso de la seguridad contracódigo malicioso. En muchísimas ocasionespodemos encontrar que un usuario disponede una herramienta contra el spyware, otrapara eliminar adware, otra que evita la entra-da de virus, otra que bloquea troyanos, a loque hay que sumarle el firewall personal.Al final, pasa lo mismo que al principio deestas líneas: problemas de operatividad entredistinto software que, en el fondo, deberíaservir para lo mismo: ayudar al usuario. Tenervarias aplicaciones de seguridad implica queel usuario debe aprender a manejar variasaplicaciones para un problema común, elcódigo malicioso. El tiempo de aprendizajepuede que sea pequeño (cada vez se tiende ahacer las aplicaciones con interfaces másamigables), pero tener que alternar entre dis-tintas aplicaciones para tareas que se puedenrealizar en un sólo programa, va en contra decualquier postulado de ergonomía.Añadido al problema ergonómico de usar dis-tintas aplicaciones (y en muchos casosentrando en conflicto) es que se piensa queuna aplicación específica va a llevar a cabouna tarea mucho mejor. Nada más lejos de larealidad: el problema no está en que undeterminado software haga mejor una tarea,sino que hace mal las demás. Y si para com-pensar una carencia instalamos software adi-cional, el consumo de recursos en el sistemase dispara de manera alarmante. Evidentemente, puede argumentarse que eluso de este tipo de herramientas diferencia-das no es más que un simple problema eco-nómico. Generalmente un simple eliminadorde troyanos suele ser gratis, al menos duran-te un cierto periodo de tiempo. Desde un

FERNANDO DE LA CUADRA

Las capacidades de integración que adía de hoy incorporan las solucionessoftware son un activo importante, porlo tanto renunciar a ello nos conduce atrabajar como se hacía 15 años atrás.

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


CANAL PANDA¿Todos para uno? ¡Uno para todos!


punto de vista únicamente económicono cabe duda de que es una buena solu-ción, pero ¿estamos confiando la seguri-dad de nuestra empresa a una herra-mienta freeware? ¿Quién va a responderante un problema de detección en ella?Estamos hablando de seguridad, y unbuen servicio es una parte primordial ala hora de elegir una herramienta deprotección.Además, a la hora de asegurar un siste-ma, la mejor aplicación es la que escapaz de hacer que la menor cantidad decódigo maligno entre en el sistema,independientemente del tipo de códigomaligno que se trate. Por lo general, siuna aplicación no es capaz de detectar,por ejemplo, troyanos, pero sin embargodetecta adware, no quiere decir que seamuy buena protegiendo contra adware.Simplemente significa que no es capazde detectar troyanos. Y por consiguien-te, ni virus, ni spyware, ni gusanos, niningún otro tipo de malware. Susdesarrolladores no tienen capacidadpara eliminar otros tipos de código mali-cioso, ni disponen de un centro deinvestigación del tamaño adecuado nicon recursos suficientes como paraproteger de verdad.Pensemos por un momento cómo sedetecta, por ejemplo, una variante despyware. Basta con tener un sistema demonitorización de la entrada de infor-mación en un sistema, es decir, bastacon vigilar el contenido del tráficoTCP/IP de un sistema. Ahora bien, elcorreo electrónico también “viaja” porTCP/IP, pero con un formato completa-mente distinto a como lo hace un con-trol ActiveX típico del spyware. Si unaaplicación quiere detectar spyware ygusanos de correo electrónico sus des-arrolladores deberán saber cómo anali-zar el correo electrónico (puesto que yasaben buscar spyware) y además, saberqué gusanos deben detectarse, y teneruna velocidad de reacción suficientepara evitar que sus usuarios se infecten.Evidentemente, para eso hace falta unacapacidad que muy pocos desarrollado-res tienen.Si una empresa dispone de capacidad dedetectar virus, gusanos, troyanos,spyware, adware, bots, spam, hoaxes ytodo aquel nombre que se le quiera daral malware, dispone también de capaci-dad para detectar cualquier otro tipo de

código. Basta con conocerlo y aplicar lossistemas de detección adecuados. ¡Y enel tiempo adecuado! Reaccionar tresdías después de la aparición de un códi-go malicioso no les sirve de nada a losusuarios.Como colofón a todo esto, hay que teneren cuenta además que el tiempo dereacción es vital para parar un nuevocódigo malicioso. Si hay una aplicaciónque roba datos de tarjetas de crédito, eltiempo de reacción es muy, muy peque-ño: en cuanto el usuario lo reciba. Mástarde es un desastre, puesto que losdatos ya han sido robados. En la actua-lidad, es necesario no sólo un sistemaque responda plenamente ante amena-zas de cualquier tipo, sino que inclusolos comportamientos peligrosos deben

ser detectados sin que un laboratorio ocentro de respuestas, por muy rápidoque 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 eladministrador de una red con cientos omiles de ordenadores) no debe volver alpasado, ya existen soluciones de seguri-dad contra TODO TIPO DE MALWARE, consistemas de detección respaldados porGRANDES DEPARTAMENTOS DEINVESTIGACIÓN y con sistemas deDETECCIÓN INTELIGENTE.¿Está confiando su protección a aplica-ciones shareware enfocadas a una solaamenaza? Entonces, su servidor (o sim-plemente su PC) último modelo está tra-bajando como se hacía 15 años atrás.

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

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 contami-nados con un nuevo malware, utilizando como pretexto una falsa noticia de intento desuicidio de Michael Jackson. Este no es más que un nuevo capítulo de la utilización de lapopularidad de determinados personajes como una técnica de Ingeniería Social paraaumentar la capacidad de propagación de los virus.En ciertas ocasiones, la estrategia usada para la difusión de este malware es muy comple-ja: el correo, que ha sido distribuido manualmente en forma de spam por Internet, con-tiene un link a una página web que, por medio de un malware, aprovecha una vulnerabi-lidad del explorador para, a su vez, introducir una aplicación que será la que finalmentedé 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 propiovirus, 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 instalarmalware en el equipo, sí que es recurrente el uso de los nombres de personajes famo-sos para la distribución de correos que, o bien contienen el malware adjunto en el pro-pio correo (a menudo camuflado como una imagen), o bien contienen una URL dondese accede a dicho malware. La tabla adjunta muestra los nombres de famosos más uti-lizados para este tipo de prácticas.Para evitar la entrada de éstos u otroscódigos maliciosos, Panda Softwarerecomienda mantener actualizado elsoftware antivirus. Para ayudar al mayornúmero de usuarios a analizar y/odesinfectar puntualmente sus equipos,Panda Software ofrece gratuitamentela solución antimalware online PandaActiveScan (http:// www.pandasoftwa-re.es), que ahora también detectaspyware. Además, los webmasterspueden ofrecer este mismo servicio alos visitantes de sus páginas webmediante la inclusión de un código HTMLque pueden obtener gratuitamente(http://www.pandasoftware.es/partners/webmasters/).

Posicion Nombre1 Britney Spears

2 Bill Gates

3 Jennifer Lopez

4 Shakira

5 Osama Bin Laden

6 Michael Jackson

7 Bill Clinton

8 Anna Kournikova

9 Paris Hilton

10 Pamela Anderson


ACTUALIDAD


Tecnologías Grid o de computación distribuidaTecnologías Grid o de computación distribuida

Introducción

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

ciona a la par que lo hacen sus usuarios, deman-

dando 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 conse-

cuencias. Una de las primeras pasa por el agota-

miento 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 con-

troles 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.

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

charnos de toda su potencia se denomina infor-

má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 comuni-

caban 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

La globalización de la red ha dado elpaso al siguiente nivel de laevolución: las tecnologías Grid, conla que todos pasaremos a formar partede una misma entidad, compartiendolos recursos de memoria y CPU denuestras máquinas, creando así unasupermáquina virtual que tendrá lacapacidad de llevar a cabo cálculosque de otra forma llevarían cientos sino miles de años. Seamos testigos dela revolución que se acerca.

NICOLÁS VELÁSQUEZ ESPINEL

La informáticadistribuida

marcará un antesy un después en

nuestra forma depercibir La Red

Aspecto de la consola del Grid Engine N1 deSolaris.


ACTUALIDAD


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

mación. Esto se traduce en una política de

aprovechamiento de los recursos no utiliza-

dos (o infrautilizados) de sistemas distribui-

dos 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 organizacio-

nes 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ín-

crona.

Imaginemos por ejemplo que en una empre-

sa hay 10 ordenadores trabajando durante

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

tividad dedicados a un café a media maña-

na, la rigurosa visita al baño de las 12:30 y

la obligada media hora de relaciones socia-

les 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 poten-

cialmente activo durante toda la noche). La

tecnología Grid pretende utilizar este tiem-

po y los recursos asociados para realizar dis-

tintas 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 asumi-

bles. 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 infe-

rior 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 lle-

varlo 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 informa-

ció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 entor-

nos distribuidos. Este entramado está dota-

do de una serie de funciones de control

capacitadas para comprender las necesida-

des de los recursos, identificar dinámica-

mente 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 “capta-

ción” de los mismos, aunque es fácil hacer-

se una idea de las posibilidades con sólo

pensar en lo vasto de Internet) puesto que

este tipo de redes permite conectar millo-

nes 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 tra-

bajo están trabajando a capacidad máxima

otros se encuentren prácticamente para-

dos. 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 queda-

do atrás, aunque sus objetivos no sean en

principio los mismos. Junto con

Tecnologías Grid o de computación distribuida

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

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


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

go 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 ges-

tión de los recursos distribuidos (DRM).

Entre otras cosas, Sun se encuentra traba-

jando 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 des-

apercibida a la industria privada ya que,

partiendo de la base de que una gran com-

pañí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 apro-

vechar las posibilidades que ofrece la tecno-

logí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 esta-

bilidad 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 apli-

cación se encontraba la posibilidad de alte-

rar dinámicamente la asignación de memo-

ria y procesadores a una partición de recur-

sos, un paso indispensable para la aplica-

ción de la filosofía Grid. Para ello definía

una arquitectura formada por un interfaz y

servicios. El interfaz permitía al administra-

dor 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 proporcio-

naba el mecanismo para alterar dinámica-

mente los recursos de memoria y procesa-

dores reservados. Si las condiciones exter-

nas al servidor cambiaban y un proceso

necesitaba más recursos, el motor de reglas

ejecuta las que habían sido definidas cuan-

do la partición había sido creada.

Por su lado Sun Microsystems

(http://www.sun.com/grid/) anunció a prin-

cipios de 2002 el N1, una estrategia de vir-

tualización de redes y sistemas con el obje-

tivo de renovar y redefinir el concepto de

conectividad entre los diferentes recursos

de una red. Para ello comercializó un pro-

ducto 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 centra-

lizada. Por otro lado también anunció que

utilizaría su tecnología Jini y Jxta para

conectar los diferentes dispositivos y usua-

rios 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 distribu-

yeran 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 des-

arrollar un modelo estándar de diseño e

implantación de infraestructuras de com-

putación de informática distribuida. Las

cuatro compañías combinarán sus principa-

les tecnologías y recursos técnicos para

ofrecer a sus clientes una solución corpora-

tiva integrada y completa a menor coste y

así enfrentarse con garantías a los produc-

tos de gama alta de IBM y HP. Dell aporta

sus soluciones servidor en red mediante

equipos PowerEdge basados en procesado-

res 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 optimiza-

ción. Finalmente F5 Networks aporta sus

switches BIG-IP y Cramer colabora con una

aplicación que permite ficheros a gran esca-

la 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 clien-

tes 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 destina-

do 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 mode-

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

14

ACTUALIDAD


Según se afirma desde Sun, la tecnologíaGrid mejorará la calidad y disminuirá lostiempos de mercado.

La aplicación WorldCommunityGrid dicehaber logrado procesar el equivalente a10.000 años gracias a su programa Gris.


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

zar 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 socia-

les 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 pre-

sentado 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 sus-

tituir la compra de superordenadores para

investigación por la apuesta de la tecnolo-

gía Grid. Por un lado, Ford aprovecha todo

el potencial de los ordenadores de sobre-

mesa 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 inves-

tigació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 permiti-

rán aumentar su rendimiento. Pretende

lograr la primera aplicación comercial de

escritorio. Para ello, Adobe incluirá un plu-

gin 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 renderi-

zación de forma efectiva, uno de los proce-

sos que más tiempo y CPU requieren.

Una de marcianos

Ya están funcionando muchas aplicaciones

que se han convertido en la avanzadilla de

lo que ha de llegar en un futuro muy cerca-

no. Como ya se ha comentado, esta tecno-

logí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 extra-

terrestre (http://setiathome.ssl.berkeley.edu

y http://www.querysoft.es/seti/). En concre-

to 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ús-

queda, convirtiendo así a cualquier usuario

que tenga funcionando el programa en

protagonista activo de esta fascinante bús-

queda. Cualquiera que tenga un PC y una

conexión a Internet puede participar y no

es necesario tener conocimientos científi-

cos de ningún tipo ni pagar nada. Lo único

que hay que hacer es descargarse un pro-

grama gratuito e instalarlo. La aplicación

que se instala es un salvapantallas que sólo

se activará durante los momentos de inac-

tividad 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áme-

tro 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 redis-

tribuye 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 trans-

fiere los datos automáticamente al ordena-

dor 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 apro-

ximada 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 pro-

rrogado. 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ña-

les 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 prestigio-

sa revista New Scientist que se había cap-

16

ACTUALIDAD


El proyecto SETI de búsqueda deinteligencia extraterrestre es posiblementela aplicación Grid más extendida.

Observatorio de Arecibo desde el que secaptan las señales a analizar por elprograma SETI.


tado una señal de radio del espacio exterior

sin explicación. Los responsables del pro-

yecto SETI fueron concluyentes al atajar

esta noticia y declarar que se había exage-

rado 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 resulta-

dos tendrán una aplicación y resultados más

prácticos, sobre todo en lo referente a estu-

dios y diseño de nuevos agentes terapéuticos

para tratar distinto tipo de enfermedades.

Una de las pioneras, pero que desafortuna-

damente 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.

En septiembre del año 2000, y de manos de

Entropia (http://www.entropia.com) y los

laboratorios Olson (http://www.scripps.

edu/pub/olson-web/) se lanzó el proyecto

FIGHTAIDS@HOME (http://www.fightaid

sathome.com) con el claro objetivo de con-

seguir 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 HIV-

1 que es básica en la replicación del retro-

virus de la inmunodeficiencia adquirida. Su

programa cliente llamado “AutoDock”, des-

arrollado a principios de la década de los 90

por David S. Goodsell y modificado poste-

riormente 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 momen-

to cuenta con la colaboración de casi

30.000 máquinas en las que se han adelan-

tado 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 apoya-

da 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 tera-

pé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 bioin-

genierí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 produ-

ce 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 dis-

tribuida”, 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 descar-

gado 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 natu-

raleza y que ayudarán a poder desarrollar nue-

vos 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 conoci-

miento de los factores involucrados en la

evolución de las especies y que está dividi-

17

ACTUALIDADTecnologías Grid o de computación distribuida


Popular Power fue una de las pioneras encausas altruistas aunque ha cesado suactividad.

United Devices propone desde su web unaaplicación Grid para la investigación deCáncer llamada Think.

FIGHTAIDS@HOME es una aplicación queusa la computación distribuida parainvestigar sobre el SIDA.


da en varios subproyectos (simula-

dores) 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 for-

mas de vida robóticas (Genetically Organized

Lifelike Electro Mechanics) desarrollando

simulaciones de organismos artificiales con

las que se pretendía entender mejor los prin-

cipios 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 recopi-

lados 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 simu-

lació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 proyec-

to está de momento clausurada).

En otro orden de cosas, vale la pena des-

tacar el proyecto Distributed.net

(http://www.distributed.net) que ha llega-

do 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 pro-

yectos (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 pri-

mera formaban un grupo de trabajo den-

tro de la segunda).

El panorama español

En España cabe destacar el proyecto inicia-

do por Banesto que está realizando prue-

bas para conseguir unir unos 15.000 orde-

nadores 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 inves-

tigació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 coordi-

nar 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 posibili-

te 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 Com-

putacional 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

importantes cifras de hasta 52 millones de

euros repartidas en 12 proyectos, se pre-

tende extender entre las empresas el uso

de la tecnología Grid. De esta manera,

desde Bruselas se desea estimular la com-

petitividad 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 investiga-

ciones para procesos relacionados con la

industria automovilística y farmacéutica y

en el que se ha dedicado la nada desdeña-

ble cifra de 11 millones de euros. El resto

de proyectos busca aumentar la competi-

tividad en el ámbito de la industria del

motor, las telecomunicaciones o la inves-

tigación. De momento existen diversas

aplicaciones en el campo de la seguridad

vial que permiten realizar cálculos avanza-

dos 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 organizacio-

nes 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, apare-

ciendo 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 organi-

zaciones dinámicas virtuales creadas a

partir de la conexión de sistemas dispersos

geográficamente. El objetivo puede con-

sistir en definitiva en trasladar las bonda-

des de esta tecnología del campo científi-

co al empresarial y convertirla en el sopor-

te de las aplicaciones e-business para

todos los sectores industriales.

18

ACTUALIDAD


IRISGrid pretende fomentar la inves-tigación sobre Grid en España.


DISPOSITIVOS MÓVILES

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


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

mentos necesarios para programar una exten-

sión para IIS. En el presente artículo nos centra-

remos en la teoría que nos falta y en la imple-

mentación e implantación del sistema.

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

ga, instalación, actualización, desinstalación y

ejecución de los Midlets.

A través del software AMS incorporado, un dis-

positivo MIDP puede descargar suites de Midlets

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

positivos móviles deben integrar un software que

ayude a localizar aplicaciones en un determinado

portal en la red. Este software (“discovery applica-

tion”) suele ser un navegador WAP o HTML, aun-

que 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 comuni-

carse 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 inte-

gra como especificación. OTA soporta HTTP 1.1

Las especificaciones OTA (Over TheAir) definen los mecanismos por loscuales podemos distribuir nuestrassuites de Midlets a través de Internet.En este artículo completaremos la serieconstruyendo un sistema dedistribución de Midlets basado en IIS.

JOSÉ ANTONIO PÉREZ

MIME TYPES 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

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

Material complementarioEl lector encontrará en http://

digital.revistasprofesionales.com el

material complementario de este

artículo.

Mime types usados en la aplicación


Creación de un sistema de distribución de Midlets (y II)DISPOSITIVOS MÓVILES


incluyendo el sistema básico de autentica-

ción. En nuestra aplicación no haremos uso

de dicho mecanismo, pudiendo ser una posi-

ble mejora para un futuro.

Ciclo de vida de una instalaciónPara la obtención de una suite de Midlets

desde Internet se han de seguir un número

reducido de pasos. Cada paso implica la des-

carga 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 disposi-

tivo 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 soft-

ware 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 des-

ventajas.

Si una versión de software que se quiere des-

cargar se encuentra ya instalada en el dispo-

sitivo móvil, el archivo JAD proporcionará

información al software AMS para que nos lo

notifique y proceder, si se quiere, a la actua-

lización. El archivo de descriptores permite al

software AMS proporcionar información por

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

dad “MIDlet-Jar-URL” del archivo de descrip-

tores para solicitar la descarga.

Códigos de estado del AMSUna vez finalizada la descarga, y siempre

que el archivo JAD tenga definido el des-

criptor “MIDlet-Intall-Notify”, el AMS

enviará un código de estado a la URL defi-

nida. 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-Delete-

Notify” (sólo MIDP 2.0) se enviará una noti-

ficación cuando se elimine el Midlet (siem-

pre 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 enorme-

mente. Podemos distinguir tres tipos de

propiedades:

� PPrrooppiieeddaaddeess oobbll iiggaattoorriiaass ..

� PPrrooppiieeddaaddeess ooppcciioonnaalleess ..

� PPrrooppiieeddaaddeess ddee uussuuaarriioo..

El orden de las propiedades no es impor-

tante pero sí es fundamental que aquellas

propiedades que son necesarias estén

correctamente descritas, de lo contrario el

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

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 atributoobligatorio en el fichero JAD.

906 Invalid descriptor. Descriptor no válido.

Códigos de estado AMS exclusivos de MIDP 2.0 CÓDIGO MENSAJE DESCRIPCIÓN

907 Invalid JAR. El fichero JAR no es válido.

908Incompatible configuration or profile.

La configuración o profile sonincompatibles.

909 Application authenticationfailure.

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 procesode 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 packagejava necesario.

El software AMS usa la informacióncontenida en el archivo JAD parainteraccionar con el usuario.


software AMS, al igual que ocurría con el

caso mime types incorrectos, invalidará el

proceso.

Propiedades obligatorias� MMIIDDlleett--JJaarr--SSiizzee: Tamaño en bytes del

fichero JAR a descargar.

� MMIIDDlleett--JJaarr--UURRLL: La URL usada para

descargar el fichero JAR. En los ejemplos

de prueba suministrados con la aplica-

ció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.

� MMIIDDlleett--NNaammee: El nombre de la suite

de Midlets a mostrar al usuario.

� MMIIDDlleett--VVeennddoorr: El texto que identifi-

ca al proveedor del Midlet.

� MMIIDDlleett--VVeerrssiioonn: El número de versión

de la suite. Son tres cifras separadas

entre sí por un punto (por ejemplo

1.0.0).

� MMiicc rrooEEdd ii tt iioonn--CCoonnff iigguurraatt iioonn: La

configuración J2ME necesaria (CLDC-1.0

o CLDC-2.0).

� MMiiccrrooEEddiitt iioonn--PPrrooff ii llee: 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 separa-

dos 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� MMIIDDlleett--DDaattaa--SSiizzee: Es la cantidad de

memoria mínima en bytes del área del

almacenamiento necesaria para la suite.

� MMIIDDlleett--DDeelleettee--CCoonnffii rrmm: Es el texto

del mensaje que se muestra al usuario

cuando se le pide que confirme la elimi-

nación de la suite.

� MMIIDDlleett--DDeelleettee--NNoottii ffyy: Es la URL a la

que se envía un mensaje HTTP (usando el

método POST) para indicar que el borra-

do de la suite se realizó.

� MMIIDDlleett--DDeessccrr iipptt iioonn: Es un texto libre

para incluir una descripción de la suite.

� MMIIDDlleett--IIccoonn: Es el nombre del archivo

PNG para identificar a la suite de

Midlets.

� MMIIDDlleett--IInnffoo--UURRLL: Es una URL desde

la que se puede obtener una descripción

opcional de la suite.

� MMIIDDlleett--IInnttaall ll--NNoottii ffyy: 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 empaque-

tado desde la aplicación KToolbar se

incluye el archivo “MANIFEST.MF”. Este

archivo puede contener toda la informa-

ción de los descriptores obligatorios del

fichero JAD, a excepción de la URL y

opcionalmente puede incluir los descrip-

tores “MIDlet-Permissions” y “MIDlet-

Permissions-Opt”.

Un Midlet puede necesitar ciertos permi-

sos 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 inclu-

sió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 apli-

cación OTA Provisioning que nos permite

probar la descarga, actualización, ejecu-

ció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 identifi-

cador 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 emula-

dor producirá la carga del archivo HTML o

WML que contiene los Midlets que quere-

mos 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 inclu-

yen el dar de alta, baja o modificar las sui-

tes de Midlets. La aplicación y los archivos

de datos se reparten en tres directorios de

los cuales destacaremos 2:

bb iinn: Contiene la extensión (“MidSvr.dll”) y

todos los archivo HTML usados para la

administración.

ddddbbbb: en este directorio se encuentra la

base de datos, creada en formato access

(“middbb.mdb”). Esta base de datos contie-

ne 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 licen-

cias). “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 des-

cargas usan un único identificador de

licencia.

22




� 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 pul-

sar 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 nave-

gador. Sólo se generan licencias en los

casos en que esté habilitado el tratamiento

adecuado.

Las clases del aplicativoEl 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 trata-

miento 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 admi-

nistración de la aplicación y a la comunica-

ción por parte del software AMS del código

de estado después de una operación.

Las peticiones GET son las que usaremos

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

nados 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 impli-

cadas tres clases.

Las clases “DataBase”, “ResultSetContainer”

actúan como una capa para gestionar base

de datos con ADO. La clase

“MidletDataBase” contiene las funcionali-

dades 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

Creación de un sistema de distribución de Midlets (y II)DISPOSITIVOS MÓVILES


LISTADO 1 Ejemplo de archivo JAD usado

MIDlet-1: solop, solop.png, spMidletMIDlet-Jar-Size: 11187MIDlet-Jar-URL:http://localhost/midlets/MidSvr.dll?jar=solop.jar&m=test&k=##k##&b=##b##&cmd=dwlMIDlet-Name: solopMIDlet-Vendor: Banshee Software (JAPM)MIDlet-Version: 1.0MicroEdition-Configuration: CLDC-1.0MicroEdition-Profile: MIDP-1.0MIDlet-Delete-Notify:http://localhost/midlets/MidSvr.dll?jar=solop.jar&m=test&k=##k##&b=##b##&cmd=dltMIDlet-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);

}::

}elseif (!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 lasextensiones es fundamental.


Finalmente para extraer los parámetros de

las peticiones se usa la clase “Http

RequestParameters”.

Instalación del sistema de distribuciónde Midlets

La instalación de una extensión en IIS

es realmente trivial. Aunque las capaci-

dades 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 com-

plementario 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”, selec-

cionaremos “Añadir o quitar compo-

nentes de Windows” que nos permitirá

incluir IIS en el sistema operativo.

Para acceder a la consola de

administrador del IIS, y siempre par-

tiendo 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 per-

misos 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 servi-

cio 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 directo-

rio “C:\logs” donde se crearán los archi-

vos 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 datosUn 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 pro-

porciona 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 escri-

tura para el usuario que ejecuta la apli-

cación IIS. Si estos permisos no están

bien configurados la ejecución de que-

ries 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 concurren-

te (por ejemplo cuando se haya accedido

a la extensión cuando la teníamos abier-

ta desde Access) lo mejor es descargar la

extensión y volver a cargarla.

Conclusiones

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

cación de ejemplo desarrollada contiene

todos los ingrediente para crear nuevas

extensiones mejoradas orientadas a OTA

u otros ámbitos con cambios muy senci-

llos. Entre las mejoras posibles del siste-

ma está la posibilidad de añadir funcio-

nalidades para generar automáticamen-

te las páginas WML o HTML, el procesa-

miento de las peticiones de forma asín-

crona, 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.

24



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



El GPS como “medio de comunicación”El GPS como “medio decomunicación”


Introducción

Limitándonos tan sólo a los GPS más usuales y

asequibles, la variedad de sus funciones y apa-

riencia 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 necesida-

des. En una segunda parte estudiaremos con

más detalle la poderosa herramienta que consti-

tuyen para intercambiar información, y su utili-

zación práctica.

El GPS

Un GPS es un receptor de radiofrecuencia, que

en combinación con los componentes de hard-

ware 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.

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

sió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 dis-

tancia 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 gra-

cias al “ordenador” fijar el rumbo y establecer

distancias hasta puntos cuyas coordenadas

conozcamos.

Dejando a un lado los GPS de alto costo dedica-

dos 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 cuadra-

dos, 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 órde-

nes. 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 sis-

temas 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 campoLos de este tipo son los que requieren mayor

participación por parte del usuario que con fre-

El mes de agosto es para muchos elmes de las vacaciones. Ello conllevavivir nuevas experiencias, muchasveces basadas en el viaje a lodesconocido. Es por esto que,aprovechando la ocasión, hemosquerido ofrecer este artículo. Sin duda,una forma divertida pero apasionantede aprender a usar la tecnología GPS.

LUIS GARCÍA ARRANZ

ApunteEn http://www.elgps.com existe información sobre pro-

gramas y receptores de GPS, con foros de discusión y

listas de correo. Uno de los sites más veteranos y com-

pletos en español.




artículo.


El GPS como “medio de comunicación”DISPOSITIVOS MÓVILES


cuencia se encarga de suministrar la infor-

mación pertinente para la realización de un

determinado recorrido.

Para utilizarlos correctamente conviene

tener claros los siguientes conceptos:

� WWaayyppooiinntt: Se trata de un lugar defini-

do por sus coordenadas, que tiene un

nombre propio y al que dependiendo de

los diferentes modelos se le puede asig-

nar un símbolo, y en ocasiones una des-

cripción.

� TTrraacckk: Una sucesión de puntos, defini-

dos por sus coordenadas, lo suficiente-

mente próximos como para a partir de

ellos poder seguir un camino.

� RRoouuttee: Una secuencia ordenada de

waypoints que refleja un proyecto de iti-

nerario a seguir. Aunque puedan apa-

rentar 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.

Caminando con el GPS podemos generar

automáticamente “tracks” que serán el

reflejo de nuestro recorrido, y marcar “way-

points” cada vez que estemos en algún

lugar que consideremos de especial rele-

vancia, y todos esos datos los podemos

almacenar para utilizarlos durante esa jor-

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

tro 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 pro-

grama adecuado y después enviarlos al GPS

para poder utilizarlos. En este caso tendre-

mos que escanear un mapa de papel y cali-

brar 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á trata-

do al final de este texto) al que está referi-

do. Para que la operación resulte satisfac-

toria es conveniente tener algunos conoci-

mientos geográficos y alguna experiencia

en el tipo de recorrido que estamos plane-

ando.

Otra forma de conseguirlos es que alguien

nos los regale o venda, cosa para la que

además de los amigos y conocidos pode-

mos recurrir a las numerosas webs que, a

través de Internet, los ponen a disposición

del público, generalmente con carácter gra-

tuito. Sean realizados por nosotros o adqui-

ridos 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 siem-

pre 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 nues-

tro 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ñalar-

nos el nuevo rumbo a seguir. Si lo que tene-

mos cargado es un “track”, junto a él pode-

mos 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 dis-

tancia 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 intere-

sa al excursionista.

GPS para cocheLa 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 opor-

tunos propone el recorrido que le parece

adecuado, que como es lógico no es nece-

sariamente 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 roda-

do. 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 indicacio-

nes 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 regis-

trar acontecimientos circunstanciales tan

efímeros como puede ser un atasco.

Figura 1. La gama de receptores Etrex, deGarmin, es una de las más usadas por losexcursionistas. En la imagen, puede verseel Etrex Summit.

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


Lo habitual es que, una vez dadas las ins-

trucciones, 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, espe-

cialmente 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 dis-

torsión que surge cuando la señal proce-

dente de los satélites se está recibiendo en

un entorno urbano.

GPS para PDAsEn 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 cual-

quiera” y algo así viene a suceder con las

PDAs, que siendo ordenadores no orienta-

dos 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 aseme-

jará más a los que hemos considerado “para

campo”, y podremos con facilidad cargar en

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.

Para que las PDAs funcionen como GPS, lo

que hay que añadirles, además del progra-

ma 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 siste-

ma que no implica la utilización de cables.

En la utilización de una PDA en la modali-

dad “para coche” la principal dificultad es la

derivada de la captación de las señales

desde el interior del vehículo, y en la moda-

lidad “para campo” la derivada de su fragi-

lidad 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

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

ta, 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 pro-

vocará los consiguientes errores.

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

28



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

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

ApuntePara informase y descargar diferentes versiones

de OziExplorer, programa especialmente valorado

por excursionistas y montañeros, existe

http://www.oziexplorer.com.

ApunteTom Tom es una herramienta especialmente valo-

rada por los que se desplazan en automóvil por

carretera y ciudades (http://www.tomtom.com).

ApunteCompeGPS es un programa especialmente valora-

do por los que practican parapente, y recorren

grandes distancias en automóvil por zonas

sin carreteras. Puede descargarse desde

http://www.compegps.com.

Figura 5. Receptor Haicom HI-405BT paraPDA.


que realiza las mediciones, otro fijo coloca-

do en una posición de coordenadas conoci-

das. 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” mane-

jan 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 contrapo-

sición estos últimos son más abiertos que los

primeros y es fácil añadirles nueva informa-

ció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 abier-

tas todas las vías para intercambio de informa-

ción que facilita Internet, de forma que los

recorridos y los puntos captados por una per-

sona 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 deter-

minado 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 imagi-

nable, aunque en estos momentos no tenemos

noticia de que existan los programas adecua-

dos, el siguiente escenario: una PDA con telé-

fono móvil conectada a un GPS, que reciba los

waypoints mediante SMS. De lo que sí tene-

mos 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

en caso de emergencia pueden enviar un SMS

pidiendo socorro, en el que además de la soli-

citud 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 con-

ceptos demasiado difíciles de utilizar en la

práctica, aunque para su completa compren-

sión sí que se requieran conocimientos com-

plejos.

La diferencia entre las coordenadas geográfi-

cas 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 considera-

bles. 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 geoi-

de) 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 pre-

senten 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 alema-

na 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 puer-

to serie, o USB, del ordenador. Las caracte-

rí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 pro-

grama que realiza el intercambio y posibi-

lita la conversión entre diferentes forma-

tos y datos de referencia. Hay varios, entre

los que quizá el más popular sea

OziExplorer. En cualquier caso un progra-

ma para comunicar el ordenador y el GPS

debe permitir, al menos, el intercambio de

“tracks”, “routes” y “waypoints”, la conver-

sió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áfi-

co 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 coor-

denadas conoce, asignar otras a los pun-

tos de las que no las conoce, pero que

guardan con ellos una relación de posición

en la imagen. Para calibrar un mapa reco-

mendamos 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 aque-

llos que se corresponden con las intersec-

ciones de la malla de coordenadas de

nuestro mapa de papel, por tanto a la hora

de comprar nuestros mapas debemos bus-

carlos con una malla lo más tupida y clara

posible.

29




Lo habitual en los scanners de sobremesa

es que la zona de barrido sea de tamaño A-

4 (297x210 mm), si nuestro mapa no tiene

la malla lo suficientemente tupida es posi-

ble que una vez seleccionada la zona de

nuestro interés no haya en ella esas cuatro

intersecciones recomendables. Para solu-

cionarlo 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 aprove-

chables por nuestro GPS, y los “tracks” y

“waypoints” generados en el PC los podre-

mos utilizar en el GPS, bien sea para seguir

el recorrido ideado o para obtener la direc-

ció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óvilEl “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 conjuntamen-

te. Por eso el protocolo NMEA (el primero

que posibilitó esta función) fue diseñado

pensando en la navegación marítima, aun-

que pronto se vio que también se podía uti-

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

siado 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 inte-

rior 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 tecnolo-

gí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éndo-

los 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 lla-

mado “para campo” y no permite la fun-

ció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 “way-

points”, de modo que en ese papel, que

cómodamente podréis llevar en cual-

quier bolsillo, quedará a vuestra disposi-

ció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 podero-

sa herramienta para procesar, elaborar e

intercambiar información. A continua-

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

30



ApunteNo 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.

ApunteEn http://www.andarines.com/gps podemos en-

contrar nociones sobre GPS y descarga de ficheros

con wayponts y tracks.

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

Grandes proyectos de software

¡Ya en tu quisoko!

Grandes proyectos de software

¡Ya en tu quisoko!

Gestionar un proyecto de software en el que se encuentreninvolucradas varias personas y haya decenas de miles de

líneas de código puede ser muy difícil si no se usan los pro-gramas y estrategias adecuadas. Este mes abordaremos losproblemas relacionados con la sincronización entre varios

programadores y con la depuración del código.


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á situa-

da en la Casa de Campo, y vamos a uti-

lizar sólo las funciones comunes a casi

todos los GPS al uso.

En el interior del vagón, nuestro recep-

tor no capta de las señales de los satéli-

tes, de modo que podemos aprovechar

una parte del tiempo del trayecto para

borrar “waypoints” y “tracks” que tenga-

mos almacenados en nuestro GPS, esto

evitará la posible mezcla entre los datos

de nuestro recorrido y otros almacena-

dos con anterioridad. Pondremos espe-

cial 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 reco-

rrido. Una vez que hemos borrado todos

los datos que pudieran inducir a confu-

sión apagamos nuestro receptor.

Recogida de datosEn 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 recep-

tor va generando un nuevo “track acti-

vo” y almacenando un rosario de coor-

denadas 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 per-

mitimos marcar un “waypoint”, por si

acaso el destinatario de nuestra infor-

mación estuviera interesado en la botá-

nica (los tarays son frecuentes en terre-

nos arenosos, y suelen adornar los pase-

os 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

en una pequeña libreta “001 un buen

ejemplar de taray”. Continuamos nuestro

paseo y tras cruzar una pequeña carre-

tera vemos la escalera que asciende por

la colina, marcamos con un nuevo “way-

point” 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 vegeta-

ción. De todos modos marcamos un

32



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

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


“waypoint” y anotamos en nuestra libre-

ta “004 punto más alto de la colina”.

Hemos llegado al final del recorrido y

guardamos el “track activo” con el nom-

bre que nos propone el receptor que es

la fecha del día. Tras ello apagamos

nuestro receptor.

Recuperación de la informaciónEn 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 uti-

lizando, 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 informa-

ció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 debe-

mos 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 nue-

vos 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 debida-

mente 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 pro-

cedemos 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 contie-

ne esas coordenadas no aparecerán en

pantalla; pero estarán igualmente carga-

dos 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 con-

fundirnos. En nuestro caso concreto el

ordenador nos ha traído los cuatro “way-

points” 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 recorri-

do 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 pode-

mos 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 adjun-

tos 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 “way-

points” 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 exten-

so 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érdi-

das de información, como explicaremos

más adelante.

Edición de los waypointsComo ya hemos dicho nuestros ficheros ya

están listos para la entrega a segundas

personas; pero será mejor que nos tome-

mos algún pequeño trabajo. Haciendo

doble clic sobre el pequeño círculo con que

se representan los “waypoints” en la pan-

talla nos aparecerá una ventana en los que

podremos cambiarles el nombre y añadir-

les 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 perma-

33



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


nezcan agrupados cuando los volquemos a

un GPS, el número los mantendrá ordena-

dos según la secuencia del recorrido, y el

resto de las letras hace referencia al obje-

to. 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 haya-

mos 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 “way-

ponts”, 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 ladoUna 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 anali-

zarlos. Por ejemplo podrá ver la distancia

recorrida, los desniveles, el perfil del itinera-

rio 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, puer-

to de comunicación, etc. Y luego acuda a la

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

res 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 ten-

drá todos los datos, en un papel que podrá

llevar cómodamente y le será de gran utili-

dad.

La pérdida de información puede ser real-

mente grave cuando se trata de “tracks”. Si

volcamos un fichero que desborda la capa-

cidad de almacenaje de nuestro receptor de

GPS, a medida que vayan entrando los pun-

tos que rebasan esa capacidad iremos per-

diendo 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, admi-

tirá en torno a los 10.000 puntos que luego

reducirá de forma selectiva a 500, o los que

sea capaz de almacenar como track guarda-

do. También el OziExplorer tiene un función

denominada “filtrado de tracks” con la que

podemos reducir el número de puntos utili-

zando criterios similares a “eliminar todos

los puntos que estén a menos de 20 metros

del siguiente”. Elegir reflexivamente esos cri-

terios es fundamental para la obtención de

un “track” simplificado, pero útil.

Con la cartografía tradiccionalDe la cartografía impresa sobre papel tam-

bién podemos obtener datos para introdu-

cirlos en nuestro GPS. La forma más cómo-

da 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 simul-

tá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 debe-

ría ser capaz de distinguir los tipos de GPS

que existen y, mediante uno de estos dispo-

sitivos, obtener la información de la ruta y

transmitirla al ordenador, para poder com-

partirla, 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 consegui-

do acercar al lector al mundo del GPS,

damos nuestro objetivo por cumplido.

34



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


MIDDLEWARE

Struts práctico (y III)Struts práctico (y III)


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

madas por equipos de desarrollo más o menos

grandes. En este artículo veremos dos de las

soluciones que nos aporta Struts en este sen-

tido (uso de action forms dinámicos o

DynaActionForms y la división de las aplica-

ciones en módulos). Además veremos una

alternativa al uso de los dataSources gestiona-

dos 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 com-

parativa 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

En el primer artículo de este curso, presentá-

bamos los componentes esenciales que debía-

mos desarrollar en una aplicación bajo Struts.

Uno de estos componentes eran los denomi-

nados 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 pri-

meras versiones de Struts, fue que se conside-

raba 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ñado-

res de JSP como los programadores de los

Actions, debían ponerse de acuerdo en los

campos de los formularios, pues si no se pro-

ducirían errores. Los desarrolladores demanda-

ron 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 imple-

mentar una clase Java por cada formulario de

nuestra aplicación. A cambio deberemos espe-

cificar en el fichero “struts-config.xml” los

campos y los tipos de datos de cada

ActionForm. La forma de declarar cada formu-

lario es muy sencilla, el lector puede compro-

barlo observando el listado 1.

Como se puede ver, la diferencia con la defini-

ción de un ActionForm tradicional reside en

que se añaden las etiquetas “<form-property>”

para definir cada uno de los campos del for-

mulario. 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.) aun-

que internamente se convertirán a las corres-

pondientes clases del paquete “java.lang”.

A la hora de acceder a los valores del formula-

rio desde los Actions, dispondremos de un

único método “get()”, al que indicaremos como

argumento el nombre del campo del que que-

remos obtener el valor. Podemos pensar en los

DynaActionForms como si fuesen HashMaps

(de hecho, los DynaActionForms almacenan

los valores en una instancia de “java.

En esta última entrega del curso quehemos dedicado a Struts,conoceremos algunos de los aspectosmás avanzados que ofrece esteframework, centrándonos sobre todoen aquellos orientados al desarrolloen equipo.

ÓSCAR ARANDA CRESPO(Arquitecto J2EE)




artículo.


MIDDLEWAREStruts práctico (y III)


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

da en el fichero “struts-config.xml” (exac-

tamente igual que ocurre cuando utiliza-

mos un objeto “HashMap” o cualquier

otra colección).

Lo mejor será ver un ejemplo en la aplica-

ción Sp.Shop. Hemos sustituido el

ActionForm “datosRegistro” (implementa-

do 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 =

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

DynaActionForms con validación

Hasta ahora hemos visto la forma de evi-

tar 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 “vali-

date()” y por tanto efectuar la validación

de los datos enviados. Esto tiene una pri-

mera 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.

Hay que tener en cuenta que cada for-

mulario tiene unos campos y unas reglas

de validación distintas, por lo que pare-

ce poco realista el tener un único méto-

do “validate()” para todos los formula-

rios dinámicos. Mediante esta solución

tendríamos que crear una clase hija de

“DynaActionForm” con un método dis-

tinto 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 princi-

pal 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 cum-

plir los campos de un formulario para

considerarse válido. La solución más

sencilla para permitir validación con el

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>

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 parala implementación de formularios web.


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

dación del formulario de registro, por lo

que simplemente tenemos que cambiar

el atributo “type”. Finalmente el form-

bean quedará como muestra el listado 2.

Utilidad de los DynaActionForms

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

to de las aplicaciones pues se considera-

ba bastante tedioso tener que escribir

las clases ActionForms tradicionales. Sin

embargo con los DynaActionForms tene-

mos que declarar los campos de cada

formulario en el fichero “struts-

config.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 compila-

ción que errores de ejecución). Otro tipo

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

fig.xml”. De nuevo este error no se

detectaría hasta la ejecución de la apli-

cació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 apli-

caciones 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”.

Problema del doble clic

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

do el usuario pulsa por ejemplo sobre un

botón o un enlace para enviar un formu-

lario. 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 ser-

vidor. 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 apli-

cació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 cre-

ación de un mismo pedido y la aplica-

ción puede acabar generando dos pedi-

dos iguales. El mismo problema se puede

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 tokensLa 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 transac-

ció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 navega-

dor), 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:

� ss aa vv ee TT oo kk ee nn (( )). 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 comen-

zado la transacción y las próximas

peticiones que lance el navegador

sólo serán procesadas una vez.

� ii ss TT oo kk ee nn VV aa ll ii dd (( )). Sirve para pregun-

tar 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 peti-

ción actual es la primera vez que ha

sido enviada.

38

MIDDLEWARE



� rr ee ss ee tt TT oo kk ee nn (( )) . Elimina el token

actual de la sesión y debe invocarse

cuando damos por terminada la

transacción. De esta manera indica-

remos que las próximas peticiones

que se reciban con el mismo identi-

ficador 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áti-

camente si el token es válido.

� ggeennee rraa tt eeTTookkeenn (( )). Este método nos

devolverá un nuevo token de trans-

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



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>


MIDDLEWARE


El diagrama de secuencia de la figura 2

muestra el funcionamiento de dos peti-

ciones iguales lanzadas en paralelo. Se

puede observar cómo la segunda peti-

ció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 posi-

bilidad 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”, invo-

quen 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 eje-

cutar el método “isTokenValid()”. En

el Action “TramitarPedidoAction” pode-

mos ver un ejemplo (véase el listado 3).

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

ción, cuando el administrador del servi-

dor de aplicaciones debe crear y confi-

gurar estas fuentes de datos (indicar

ubicación del driver JDBC, usuario/con-

traseña de conexión, configuración de

tamaño de pools, etc). A pesar de esto,

Struts nos proporciona una forma alter-

nativa de definir y acceder a estos recur-

sos. Y el lector se preguntará, ¿Y por qué

permite Struts hacer de forma distinta lo

mismo que ya se contempla en la espe-

cificación? Pues la respuesta está en que

el uso de los dataSources proporciona-

dos 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 espe-

cífico de cada fabricante de servido-

res J2EE).

� Para obtener el dataSource lo hare-

mos 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).

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

<servlet>……<init-param>

<param-name>config</param-name><param-value>

/WEB-INF/struts-config.xml, /WEB-INF/struts-config2.xml, /WEB-INF/struts-config3.xml

</param-value></init-param>……

</servlet>

Figura 3. Módulos de Sp.Shop.

LISTADO 6 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>

NÚMEROS ANTERIORES

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

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

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

FORMAS DE PAGO� Giro Postal a nombre de REVISTAS PROFESIONALES, S.L. � Talon Bancario a nombre de REVISTAS PROFESIONALES S.L. � Domiciliación Bancaria � Contra Reembolso (5€ de gastos de envio por paquete)

Banco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domicilio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Firma:Numero de cuenta: _ _ _ _/ _ _ _ _/ _ _ / _ _ _ _ _ _ _ _ _ _ _ _Titular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

� Tarjeta 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,...)

Presente y futuro de IPv6, Java

Expo 2005, Inteligencia Ambiental,

desarrollo de un servicio de distri-

bució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.

127 - Julio 2005Un integrante del equipo de desarro-

llo 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 nove-

dades 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.

126 - Junio 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, progra-

mació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.

125 - Mayo 2005El 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 entre-

ga del coleccionable ASP.NET.

1 CD-ROM incluido.

124 - Abril 2005

Longhorn desde la óptica del

desarrollador, juegos de calidad

comercial para Nokia, personali-

zación de IGUs con XAML, intro-

ducción a la programación distri-

buida sobre .NET, los secretos de

SQL Injection, Servlets filters,

ingeniería del software vs.

“desarrollo ágil”, código C++ mul-

tiplataforma y la séptima entrega

del coleccionable ASP.NET.

1 CD-ROM incluido.

123 - Marzo 2005Si te falta algún número de la

temporada 04/05, ahora tienesla oportunidad de conseguirlo

Precio Oferta descuentoPrecio por ejemplar: 6€

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

+40 = 50%


En definitiva, ganamos en simplicidad

pero sin embargo, si nuestro contenedor

nos proporciona características adiciona-

les que queramos usar en nuestras aplica-

ciones (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 usa-

mos esta característica de Struts debemos

añadir las librerías “commons-dbcp-

1.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 aplica-

ción Sp.Shop (HSQLDB).

Como podemos ver la etiqueta “data-

source” 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 interna-

mente un pool de conexiones con lo cual

nos servirá para dar servicio a un entorno

concurrente como es un servidor de apli-

caciones. Opcionalmente, daremos un

nombre al dataSource que estamos defi-

niendo (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 propie-

dades necesarias para que la clase indica-

da en el atributo “type” pueda crear el

objeto “javax.sql.DataSource”. En el caso

de usar el “BasicDataSource” de DBCP, es

necesario indicar al menos las propieda-

des:

� dd rr ii vv ee rr CC ll aa ss ss NN aa mm ee: Nombre de la

clase que implementará el driver

JDBC. Esta clase suele encontrarse

en el .JAR del driver JDBC proporcio-

nado 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 directo-

rio de librerías comunes de Tomcat).

� uu rr ll: URL para identificar la base de

datos a la que queremos acceder.

� uu ss ee rr nn aa mm ee: Usuario con el que se

realizarán las conexiones a la base

de datos.

� pp aa ss ss ww oo rr dd: Contraseña del usuario

para la conexión.

Módulos

Ya hemos visto que una de las principa-

les 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 mantenimien-

to) pero también implica algunos pro-

blemas a la hora de plantear el desarro-

llo 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 pue-

den existir dependencias entre los dis-

tintos ficheros (un ActionForm definido

en un fichero puede ser referenciado sin

problemas desde algún ActionMapping

de otro fichero de configuración distin-

to). 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 apli-

cación Sp.Shop. Podríamos dividir la

aplicación en tres módulos independien-

42

MIDDLEWARE


Comparativa de frameworks MVC2Struts JSF SpringMVC WebWork Tapestry

UURRLL struts.apache.orgjava.sun.com/j2ee/javaserverfaces

www.springframework.org

opensymphony.com/webwork

jakarta.apache.org/tapestry

TTeeccnnoollooggííaaVViissttaa

JSP (otras) JSP JSP (otras) JSP,Velocity, XML/XSLT Tapestry templates

VVaalliiddaacciióónn commons validator En componente commons validator XWorks Tapestry

TTeesstt uunniittaarriiooss

Media (Junit +StrutsTestCase)

Media Fácil (Junit+jMock) Fácil (Junit+jMock) Difícil

HHeerrrraammiieennttaass Muchas (gratuitas) Muchas (comerciales) Algunas EclipseWork Spindle

DDooccuummeennttaacciióónn Abundante Abundante Creciendo Muy escasa Escasa

PPooppuullaarriiddaadd Muy extendido Creciendo Creciendo Poco extendido Poco extendido

DDiiffiiccuullttaadd ddee UUssoo

Muy baja Media Baja Media Muy Alta


tes. Un primer módulo para el subsiste-

ma responsable del catálogo (al que lla-

maremos “cat”). Otro para la gestión de

los pedidos (“ped”) y el resto de funcio-

nalidades (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 dis-

tribució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 “WEB-

INF/web.xml” (véase el listado 6).

Como se puede ver, simplemente tene-

mos 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 real-

mente 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 for-

ward a “/homeCatalogo.jsp”, dado que

estamos en el módulo “/cat”, Struts bus-

cará en la ubicación física “/cat/

homeCatalogo.jsp” dentro del modulo

WAR (cuidado, en el fichero “struts-con-

fig.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 distin-

tas carpetas logrando así un mayor grado

de independencia entre las distintas par-

tes de la aplicación.

Interacción entre módulosComo hemos visto los módulos están

diseñados para dividir las aplicaciones

en zonas independientes donde cada

módulo tiene su propio fichero de confi-

guració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” dis-

ponible 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



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


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á median-

te 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 for-

ward:

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

yá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 pro-

yectos Open Source que se desarrollan

actualmente existe un gran número de

ellos destinados al desarrollo de frame-

works 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 des-

ventajas 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 apren-

der 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 argu-

mentando que es para “dummies” (tontos)

lo que demuestra que cumple perfecta-

mente con este primer requisito. En el

lado opuesto tenemos a Tapestry. Tapestry

define una arquitectura completamente

distinta a la propuesta por J2EE y por

tanto requiere aprender un nuevo para-

digma de programación con nuevos com-

ponentes, etc. Por otro lado proporciona

un potente mecanismo de reutilización de

estos componentes y por ello sí es acon-

sejable para el desarrollo de grandes apli-

caciones.

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, tam-

bién es líder, pues es con diferencia el fra-

mework más extendido. También su

popularidad hace que disponga de múlti-

ples herramientas de desarrollo (tanto

comerciales como Open Source). Sin duda

estos dos últimos puntos son un inconve-

niente 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 especifica-

ción J2EE aunque la comunidad de des-

arrolladores lo ve más como un buen sis-

tema 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 últi-

mamente es la facilidad de automatizar

las pruebas unitarias. Esto en aplicaciones

web no suele ser sencillo pues las aplica-

ciones 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 des-

arrolladores apuestan por un nuevo fra-

mework de propósito más general, llama-

do 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ónSp.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 correc-

tamente la nueva base de datos.

Conclusiones

En este artículo hemos visto las facilida-

des que nos brinda Struts para resolver

los aspectos más avanzados del desarro-

llo J2EE, tales como la gestión de la

transaccionalidad y la gestión de oríge-

nes de datos (dataSources). También

hemos visto cómo facilitar el trabajo en

equipo mediante la definición de módu-

los así como la mejora de la mantenibi-

lidad 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 esta-

do actual de esta y otras tecnologías en

la plataforma J2EE.

44

MIDDLEWARE



Microsoft ha anunciadorecientemente las versionesBeta 2 del Framework .NET,SQL Server y Visual Studio2005. Muchas de las novedadesincluidas en estas nuevasversiones ya han sido objeto deestudio en números anterioresde Sólo Programadores, sinembargo hemos creídooportuno aprovechar estenúmero para ofrecer, en el CD-ROM, Visual Web DeveloperExpress Edition Beta 2.

Visual Web Developer Express

Visual Web Developer Express es un produc-

to de Microsoft que contiene todo lo necesa-

rio 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 pro-

ductos (Express) formada por herramientas

un poco más ligeras y sencillas de aprender y

utilizar para aficionados, entusiastas y apren-

dices que quieran crear sitios web y aplica-

ciones 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.

Instalación de Visual Web Developer Express

El proceso de instalación es extremada-

mente 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 cum-

pla los requisitos necesarios para insta-

lar Visual Web Developer Express, el pro-

pio 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.

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

ciar el pequeño formulario que hay que

46

CD-ROM


Desarrollo de aplicaciones y servicios web conASP.NET

Desarrollo de aplicaciones y servicios web conASP.NET

Figura 1. La instalación de Visual WebDeveloper Express incluye todos lospaquetes de software adicionales.

Figura 2. El proceso de registro para laobtención de la clave de activación esrápido y simple.

Figura 3. Después de cumplimentar elformulario de la figura 2, Microsoft nosmostrará la clave con la que podremosactivar Visual Web Developer Express.

Figura 4. En esta ventana se nos indicaque Visual Web Developer Express se haactivado correctamente y que por lo tantopodemos empezar a disfrutar de él.


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

tado. 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 tendre-

mos instalado Visual Web Developer sin

límites de tiempo para su uso.

Primeros pasos con Visual Web Developer Express: creación de unservicio 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 servi-

cios web. A continuación, vamos a

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

cer las funcionalidades de una calcula-

dora. El ejemplo es básico, pero sufi-

ciente 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 ten-

dremos 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 debe-

rí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 compleji-

dad 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

47

CD-ROMDesarrollo de aplicaciones y servicios web con ASP.NET


Figura 5. Creando el proyecto quealbergará nuestro servicio web.

Figura 6. Aspecto del “Explorador desoluciones”.

LISTADO 1 Contenido del fichero Service.cs

using System;using System.Web;using System.Web.Services;using 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;}

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

return a - b;}

}

Figura 7. El menú contextual del archivoASMX nos permite visualizar dicho ficheroen el cliente web.


nos interesa en este caso es “Service.cs”.

En este punto merece la pena aclarar

que los nombres de estos ficheros pue-

den 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 imple-

mentación de nuestra calculadora. El lis-

tado 1 muestra el código que deberá

contener el fichero “Service.cs”.

El código del listado 1 es altamente com-

prensible. 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 fal-

tará 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 aparece-

ría expuesto en la página “Service.asmx”.

Para probar la ejecución de ambos méto-

dos, bastará con hacer clic en el enlace,

introducir dos valores enteros en el for-

mulario y pulsar en “Invocar”. Esto gene-

rará un documento XML con el resultado

de la operación (véase la figura 9).

Pero hay más

Lo expuesto en este corto espacio es

simplemente un pequeño y rápido ejer-

cicio que debe servir para demostrar la

potencia de un entorno de desarrollo

como Visual Web Developer Express. El

mundo de las aplicaciones y los servi-

cios web es infinitamente amplio, por lo

que en ningún caso aquí se ha preten-

dido 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.

48

CD-ROM


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

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


REDES

Pruebas funcionales y de rendimiento con JMeterPruebas funcionales y de rendimiento con JMeter


Qué es JMeter

En un principio, JMeter sólo podía probar aplica-

ciones web, pero en la actualidad puede utilizar-

se 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 can-

tidad de usuarios en concurrencia y porque pre-

senta 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á exclu-

sivamente sobre pruebas de rendimiento y fun-

cionalidad 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

JMeter es una aplicación Java: para su funciona-

miento, 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 vir-

tual 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 eje-

cutando el fichero “jre-1_5_0_02-windows-

i586-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 obte-

ner 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 ubica-

do en un directorio cualquiera del sistema. El

fichero “jmeter.bat”, del directorio “bin”, lan-

zará JMeter.

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”.

Toda aplicación pasa por una fase depruebas. JMeter es una utilidadescrita en Java que sirve pararealizar pruebas de rendimiento y defuncionalidad sobre aplicaciones tipocliente/servidor escritas en cualquierlenguaje.

PABLO OLMOS

La fundación ApacheJMeter 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.




artículo.


REDESPruebas funcionales y de rendimiento con 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 usua-

rios), el intervalo de tiempo entre las peti-

ciones (en nuestro caso cero, porque simu-

lamos que se lanzan todas a la vez), y el

número de veces que se ejecutará la prue-

ba (en nuestro caso una).

En la parte derecha de la pantalla introdu-

ciremos los valores que se muestran en la

figura 2:

� NNaammee: Es opcional

� NNuummbbeerr ooff tthhrreeaaddss: 5

� RRaammpp--UUpp PPeerr iioodd (( iinn sseeccoonnddss)): 0

� LLoooopp CCoouunntt: “Forever” deshabilitado

(en caso contrario la prueba itera inde-

finidamente hasta que se pare manual-

mente) e introducimos el valor 1.

El siguiente paso es añadir un “sampler”. Un

“sampler” es un objeto que realiza una peti-

ció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:

� NNaammee: Es opcional

� SSeerrvveerr NNaammee oorr IIPP: digital.revistas-

profesionales.com

� PPoorrtt NNuummeerr: 80 (es el puerto por

defecto, por tanto es omitible)

� PPrroottooccooll: http (es el protocolo por

defecto, por tanto es omitible)

� MMeetthhoodd: Elegir GET o POST (no influye

en esta prueba concreta)

� PPaatthh: /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 peti-

ció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 res-

puesta para verla tal como la presentaría

un navegador.

Podemos guardar la prueba (menú “File”),

pero al hacerlo no se guardarán los resulta-

dos. Es decir, si guardamos la prueba podre-

mos recuperar su configuración, pero al

reabrirla el “listener” se mostrará vacío.

Para conservar los resultados de una prue-

ba es necesario indicar, en el campo “filena-

El proyecto JakartaEl 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.

Figura 1. Pantalla de inicio de JMeter.

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


REDES


me” del “listener”, el nombre del fichero

donde se almacenarán los datos. Este fiche-

ro 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 nues-

tro “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 resulta-

dos queramos mantener. Pero hay que tener

en cuenta que al guardar el plan de pruebas

el contenido del “Workbench” no se guarda-

rá. 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 pul-

sando 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.

ThreadGroupComo 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 peti-

ciones 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 peticio-

nes.

SamplerLos “sampler” sirven para hacer peticiones

al servidor. Como peticiones de distintos

tipos van a requerir propiedades diferentes,

hay “sampler” específicos para los distintos

tipos de peticiones (http, ftp, tcp, ldap, etc.).

Las peticiones se realizarán ordenadamen-

te, 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 valo-

res por defecto (“Add” -> “Config Element”).

Logic ControllerLos “logic controller” permiten introducir

decisiones en el árbol de pruebas. Por ejemplo,

realizar una petición sólo si antes se ha obte-

nido tal resultado. Estos nodos sólo pueden

tener como hijos “sampler”, elementos de

configuración y otros controladores lógicos.

ListenerSon las vistas con las que se muestran los

resultados. Existen distintos tipos de “liste-

ner”: 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 mos-

trar distintas vistas sobre los mismos datos.

AssertionSe utilizan para realizar pruebas sobre las

respuestas dadas por el servidor, por lo que

sólo pueden agregarse a nodos que devuel-

van una respuesta, tales como los “listener”.

Por ejemplo, se puede probar que una res-

puesta se ha obtenido en un tiempo deter-

minado, que un fichero tiene unas determi-

nadas propiedades, o que el HTML de la res-

puesta no contiene la palabra “error”.

Otros elementosAdemás de los elementos indicados, dispone-

mos de “timer”, que introducen tiempos de

espera entre una petición y la siguiente; “con-

figuration 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 pre-

procesador puede actualizar el valor de una

variable que se acaba de obtener en una peti-

ción anterior y un post procesador puede

almacenar datos en un fichero.

El árbol de pruebas

Como ya se ha comentado, algunos ele-

mentos del árbol de pruebas son jerárqui-

cos, mientras que otros están ordenados.Figura 3. Resultado de una prueba de rendimiento sencilla.


Los elementos ordenados son los

“Controller” y los “Sampler”. “Listener”,

“Config Element”, “Post Processors”, “Pre

Processors”, “Assertion” y “Timer” son jerár-

quicos.

Consideremos el árbol que muestra la figura

4. La tabla adjunta presenta los elementos

que forman este árbol y sus respectivas fun-

cionalidades. La figura 5 muestra el orden en

el que se han ejecutado las peticiones para:

Threads=1

Ramp-Up=0

Loop Count=2

Los resultados en rojo indican que se pro-

dujo un error (que en este caso hemos pro-

ducido deliberadamente) tipo “página no

encontrada” o similar.

¿Qué novedades aporta este plan de prue-

bas, respecto al de la primera prueba senci-

lla? En primer lugar hemos añadido “HTTP

Request Defaults”, configuraciones por

defecto, que se aplican a todas las peticio-

nes que cuelguen del mismo nodo que la

configuración. Como se muestra en la figu-

ra 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 concate-

nará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 controlado-

53



Figura 4. Ejemplo de árbol.

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

Nombre 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úmerode veces indicado en el nodo ini-cial (Loop Count), lo que cuelguede este controlador sólo se ejecu-tará la primera vez.

SoloProgramadores

HTTP Request Petición HTTP.

Mundo Linux HTTP Request Petición HTTP.

Uno cada vez Interleave ControllerCada vez (Loop Count) se ejecuta-rá por orden una de las peticionesque cuelguen de este controlador.

Petición 1 HTTP RequestPetición HTTP afectada por losvalores por defecto establecidosen Config 2.

Petición 2 HTTP RequestPetición HTTP afectada por losvalores por defecto establecidosen Config 2.

Resultado 2 View Results Tree Vista del resultado de Petición 2.

Config 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 TreeVista del resultado total de la

prueba, incluyendo Petición 2.


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-

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

tar ya un caso más complicado: el alta de

usuarios en un sistema.

Alta de un usuario

Por regla general, las aplicaciones web sue-

len 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 lista-

do 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”

(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 “lis-

tener” tipo “View Results Tree”, la pestaña

“Request JMeter” muestra la petición exac-

ta que ha enviado al servidor.

Naturalmente, si el lector intenta reprodu-

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”).

Alta de muchos usuarios

Una solución para que los valores de los

parámetros sean distintos para cada usua-

rio (thread) consiste en la utilización de

funciones. Son dos las funciones disponi-

bles para esto: “__threadNum” y “__coun-

ter”. 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áme-

tro “true” cada usuario (thread) mantendrá

un contador independiente y con el pará-

metro “false” todos los usuarios comparti-

rán el mismo contador. Ejemplos de funcio-

nes son:

${__threadNum}

${__counter(TRUE)}

54

REDES


Buenas prácticasAplicaciones como JMeter permiten hacer peticio-

nes masivas sobre un servidor. Las buenas prácti-

cas 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.

LISTADO 1 Alta de un usuario

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

...

Figura 6. Configuración por defecto.

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


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

ció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 sig-

nifica que entre la primera y la última

transcurren n segundos).

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

da con la que ha generado el servidor, lo

que nos conduce al caso general de que

para cada thread haya que enviar al ser-

vidor una serie de parámetros con valo-

res determinados y conocidos.

El listado 2 muestra un fragmento del

formulario de login y la tabla adjunta

muestra los datos de los usuarios (valo-

res ficticios).

La solución para estos supuestos es uti-

lizar el fichero “users.xml”. En el directo-

rio “bin” hay un ejemplo de “users.xml”.

Se puede hacer una copia y sobrescribir-

lo, siguiendo el ejemplo, con algo pare-

cido a lo que muestra el listado 3 (nóte-

se 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 ten-

drí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 indi-

ca 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

55



Condiciones de las pruebasEs recomendable que JMeter funcione en un

ordenador distinto al del servidor que se está pro-

bando para que la carga de JMeter no influya en

el resultado de las pruebas. También se debe pro-

curar que la red esté lo más aislada posible, para

que las pruebas se realicen sin interferencias

incontroladas.

LISTADO 2 Login de un usuario

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

...

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

Datos de los usuariosUUsseerr PPaasssswwoorrddusuario1 husow4usuario2 4jn28ousuario3 zxcyui

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


Modifier”. La figura 10 muestra el aspec-

to 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 funcionali-

dad 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 impres-

cindibles 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án-

to 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 resulta-

do 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.

56

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>[email protected]</paramvalue>


<paramname>peticion</paramname><paramvalue>Autenticacion</paramvalue>


<paramname>password</paramname><paramvalue>husow4</paramvalue>

</parameter></thread><thread>







<paramname>password</paramname><paramvalue>4jn28o</paramvalue>

</parameter></thread><thread>







<paramname>password</paramname><paramvalue>zxcyui</paramvalue>

</parameter></thread>

</allthreads>

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

PlanificaciónNo 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 res-

puesta 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 aplica-

ción funciona “bien” o “mal”, sino si funciona tal

como se espera que lo haga conforme a su espe-

cificación.


REDES

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


Introducción

En las dos primeras entregas de la serie se mos-

traron todas las ventajas de Coldfusion para el

desarrollo web, su instalación y el uso de su len-

guaje de programación (CFML), desarrollando

ejemplos de las etiquetas y las funciones prede-

finidas más importantes. También se desarrolla-

ron 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 pro-

gramación, como Java y C++.

También se mostrará cómo crear etiquetas y fun-

ciones 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 configu-

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

Además de todas las etiquetas que nos proporcio-

na 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 necesariopoder recoger los parámetros que se envíen.Para ello, simplemente se puede referenciar elparámetro como:

Attributes.NombreParametro

También es necesario poder devolver resultados

en alguna variable. En este caso, basta con utili-

zar el objeto “Caller” de la siguiente manera:

<cfset Caller.Resultado=”Este es el resultado”>

Esta etiqueta insertará el contenido en unavariable llamada “Resultado” en el programa quellame a la etiqueta. Si esta variable no existe, lacrea. Hay que ser cuidadoso para no sobrescribirvariables ya existentes si no se desea hacerlo.

A continuación se muestra un pequeño ejemplodel posible código de una etiqueta muy simple,que recibe dos números como parámetros, lossuma y devuelve el resultado:

<cfparam name=”Attributes.numero1”

default=”0”>

<cfparam name=”Attributes.numero2”

default=”0”>

<cfset Caller.Resultado=Attributes.

numero1+Attributes.numero2>

Coldfusion ofrece mecanismos parala reutilización de código, además depermitir una integración total conelementos Java o C++. En estaúltima entrega analizaremos estos yotros aspectos centrados en laadministración del servidor.

RICARDO DÍEZ FERREIRA




artículo.


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


Si guardamos este código en un fichero lla-mado “suma.cfm” en el directorio deCustom Tags, desde cualquier página delservidor de Coldfusion se puede utilizar laetiqueta de la siguiente manera:

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

<cfoutput>

El resultado de la suma es:

#Resultado#

</cfoutput>

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

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

bié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 con-

trario que las etiquetas, las funciones hay que

definirlas en cada lugar que se vayan a utilizar,

y no es necesario definirlas en un fichero inde-

pendiente. 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 lla-

mada a la misma:

<cffunction name="suma" >

<cfargument name="numero1"

required="true" type="numeric">

<cfargument name="numero2"

required="true" type="numeric">

<cfreturn numero1+numero2>

</cffunction>

…

<cfoutput>El resultado es:

#suma(“15”,”23”)#</cfoutput>

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

be la función. Los posibles tipos son “numeric”,

“array”, “query”, “date”, etc. Finalmente, la eti-

queta “<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ági-

nas 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

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

Como se puede observar, los parámetros que sequieran pasar a la JSP o Servlet, debe hacerse através de la URL. También se puede hacer la ope-ración contraria, es decir, incluir un fichero deCFML desde una página JSP. Se hace de lasiguiente manera:

<jsp:include page=”ejemplo.cfm”>

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

</jsp:include>

Además, es posible utilizar objetos Java, con

sus métodos y sus propiedades, para encap-

sular 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 lla-

madas a métodos con un tipo de datos con-

creto. 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 utili-

zar un objeto java. Primero, veamos en el lis-

tado 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 CLASS-

PATH es configurable desde el administrador

de Coldfusion, donde se pueden incluir todos

los directorios que se desee para que la aplica-

ción coja las clases de ellos. Los archivos pue-

den 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 utili-

za 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,

LISTADO 1 Una clase Java

public class Persona {public String nombre;public int edad;

public Persona() {nombre=””;edad=0;

}

public Persona(String nom, int ed) {nombre = nom;edad = ed;

}

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

}

public void setEdad(String ed) {edad = Integer.parseInt(ed);

}

public void setEdad(int ed) {edad = ed;

}}

La arquitectura interna de Coldfusionpermite que haya gran compatibilidadcon Java.

LISTADO 2 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>


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

ga 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 explica-

das en el siguiente apartado.

Compatibilidad con C++

La compatibilidad entre Coldfusion y C++, aun-

que 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 nece-

sarias 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 resulta-

do. Existen algunas clases de ayuda más.

Una vez hecho esto, hay que registrar la eti-

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

traseña introducida en el proceso de instala-

ción. Una vez dentro, sólo hay que ir a la sec-

ción “Extensions” -> “CFX Tags”, ponerle un

nombre, y seleccionar el fichero .DLL genera-

do. Después, ya se puede llamar normalmen-

te 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 escri-

be 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 servi-

dor 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 Cold-

fusion se puede realizar íntegramente en

un cómodo interfaz web, que permite con-

figurar todos los posibles atributos del

servidor.

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

}}

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


Este administrador, tal como se explicó en

la primera entrega del curso (Sólo

Programadores 126) y tal como se ha recor-

dado anteriormente, está accesible en la

siguiente dirección:

http://nombre_servidor:8500/CFIDE/

administrator/index.cfm

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

dos más importantes de este administrador,

para poder configurar todo lo que se necesi-

te, así como los valores adecuados para cier-

tos parámetros de configuración que serán

vitales para que el rendimiento del servidor

sea el adecuado.

Server SettingsEste es el apartado fundamental de la con-

figuración, donde se definen los paráme-

tros que afectarán al rendimiento del servi-

dor. Entre sus subapartados, los más desta-

cables son:

� SSeetttt iinnggss: En este subapartado hay pa-

rá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 rechazar-

las para no saturar el servidor. Otro

parámetro importante de este subapar-

tado 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.

� CCaacchhiinngg: 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úme-

ro máximo de consultas que puede tener

cacheadas. Si las consultas son normal-

mente 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.

� MMaappppiinnggss: 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.

� MMaaii ll: Si queremos que el servidor envíe

correos, es necesario configurarlo en este

apartado, poniéndole el servidor SMTP.

� JJaavvaa aanndd JJVVMM: 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.

61

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


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

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


Data & ServicesAquí se configura todo lo que tiene que ver

con el acceso a datos externos, y sus sub-

apartados destacables son:

� DDaattaa SSoouurrcceess: 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 funcionamien-

to de la conexión.

� WWeebb SSeerrvviicceess: 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 per-

mite guardar el usuario y contraseña de

acceso al servicio web.

Debugging & LoggingComo su propio nombre indica, este aparta-

do 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:

� SScchheedduulleedd TTaasskkss: En este subaparta-

do se pueden crear tareas programadas.

Es decir, se puede llamar a una URL, en

un día y hora concretos, o llamar diaria-

mente, mensualmente, etc. Esto es útil

para tareas periódicas de administra-

ción.

� SSyysstteemm PPrroobbeess: 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 ejecu-

tar un script. Esto es ideal para tareas de

monitorización, pues puede dar la alar-

ma del fallo de algún sistema.

ExtensionsEn este apartado, se podrán registrar y

configurar las extensiones de Coldfusion

que hemos explicado en esta misma

entrega. Los subapartados son:

� CCFFXX TTaaggss: Aquí se pueden registrar

las etiquetas de Coldfusion eXten-

sions, tanto las desarrolladas en

Java, como las desarrolladas en

C++.

� CCuuss ttoomm TTaagg PPaa tthhss: En este sub-

apartado se define de qué directorios

se pueden coger los ficheros .CFM de

las etiquetas propias.

� CC OO RR BB AA CC oo nn nn ee cc tt oo rr ss: Desde

Coldfusion también se puede conec-

tar con CORBA. Se puede registrar un

conector CORBA, de manera que

Coldfusion cargue dinámicamente

las ORB Java Libraries.

Event GatewaysLas 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. Normal-

mente se utiliza para paso de mensajes.

En esta apartado, se pueden configurar

este tipo de elementos.

SecurityEn este apartado se permite cambiar la

contraseña de acceso al propio adminis-

trador 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.

Packaging & DeploymentEl empaquetamiento y posterior desplie-

gue de aplicaciones utilizando ficheros,

se puede realizar desde este apartado.

Sus subapartados son:

� CCoo lldd ffuuss ii oonn AArrcchh ii vveess (( .. ccaa rr )): Los

ficheros .CAR permiten empaquetar y

posteriormente desplegar en un sitio

web, la configuración, los ficheros

y las aplicaciones. Desde este sub-

apartado se pueden empaquetar

los ficheros o aplicaciones existentes

en el servidor o desplegar en él

los ficheros .CAR generados previa-

mente.

� JJ 22 EE EE AA rr cc hh ii vv ee ss (( .. ee aa rr // .. ww aa rr )): En

este subapartado se pueden empa-

quetar 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 progra-

madores web, en esta tercera y última

entrega nos hemos centrado en la cre-

ación de elementos propios que facili-

ten 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 pro-

pias, que se crean en el mismo lengua-

je CFML, y que una vez creadas, pueden

ser accedidas desde cualquier fichero

.CFM del servidor de Coldfusion.

La creación de funciones propias, aun-

que 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 interna-

mente un servidor de aplicaciones Java,

permite que el lenguaje CFML tenga

gran compatibilidad con cualquier ele-

mento de Java, tanto JSP como clases

Java, pueden ser referenciadas desde

Coldfusion, e incluso se puedan crear

etiquetas propias hechas exclusivamen-

te en Java. También es posible crear

este tipo de etiquetas en C++.

Finalmente, se han mostrado los princi-

pales elementos del administrador vía

web de Coldfusion, que permite confi-

gurar todos los parámetros del servidor.

Es muy importante una buena configu-

ració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 perfecta-

mente válida para el desarrollo de

cualquier aplicación web, que tiene

un lenguaje de programación muy

sencillo, cuyo aprendizaje es práctica-

mente inmediato para cualquier

persona con conocimientos de progra-

mación básicos y que, con todas las

facilidades que proporciona, permite

disminuir los tiempos de desarrollo

drásticamente.

62

REDES



EEssttooyy uuttiilliizzaannddoo eell JJDDKK 11..55 yy qquuiieerroottrraabbaajjaarr ccoonn ffiicchheerrooss XXMMLL.. HHee eessttaaddoommiirraannddoo llaa ddooccuummeennttaacciióónn ddeell AAPPIIppeerroo nnoo ccoonnssiiggoo eennccoonnttrraarr uunn eejjeemmppllooccllaarroo yy sseenncciilllloo aacceerrccaa ddee ccóómmoo ppaarrssee--aarr uunn XXMMLL,, oo ppoorr eejjeemmpplloo ccóómmoo aappllii--ccaarrllee uunnaa hhoojjaa ddee eessttiilloo XXSSLL.. ¿¿PPooddééiissmmoossttrraarrmmee aallgguunnooss eejjeemmppllooss sseenncciilllloossppaarraa eemmppeezzaarr aa ttrraabbaajjaarr ccoonn XXMMLL??

El siguiente ejemplo muestra un típico ficheroXML de datos:

<?xml version=”1.0” encoding

=”ISO-8859-1”?>

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

Existen dos formas básicas de parsear estedocumento: mediante DOM o mediante SAX.En el primer caso se crea en memoria unaestructura arborescente que representa aldocumento y que viene dada en forma deobjeto Document:

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 instanciade la clase “DocumentBuilderFactory” emple-ando para ello el método “newInstance”.Después se crea una instancia de la clase“DocumentBuilder” con el método

“newDocumentBuilder”. El objeto “DocumentBuilder” es el que se emplea tanto para parse-ar un documento ya existente como para crearuno nuevo desde cero. En el ejemplo anteriorse parsea el documento “books.xml” emplean-do el método “parse”, el cual admite distintostipos de parámetros tal y como puede verse enla documentación del API (véase la figura 1).A veces puede ocurrir que el documento XMLemplee un DTD a fin de que se pueda verificarque el documento es válido:

<?xml version=”1.0” encoding=

”ISO-8859-1”?>

<!DOCTYPE links SYSTEM “books.dtd”>

<books>

...

</books>

En ese caso hay que indicar al objeto“DocumentBuilderFactory” explícitamente quese desea validar el documento antes de obte-ner el objeto “DocumentBuilder”:

docBuilderFactory.setValidating(true);

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

La transformación más sencilla es aquella quese emplea para obtener una cadena de textocon el documento XML, o lo que es lo mismo,la que se utiliza por ejemplo para salvar unobjeto de tipo “Document”, o sea, un ficheroXML (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 obte-ner otro de tipo “Transformer” que es en reali-dad el responsable de realizar la transforma-ción. El método “transform” recibe dos pará-metros: el primero es la entrada y el segundoes la salida. En este ejemplo la entrada es unobjeto de tipo “DOMSource” que se construyea partir del objeto “Document” que representaal fichero XML. La salida es un objeto de tipo“StreamResult”. Éste se construye a partir de un

DUDAS


Preguntas y respuestasPreguntas y respuestasADOLFO ALADRO GARCÍA

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

}

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

canal de escritura de tipo “StringWriter” y per-mite “volcar” el XML en forma de cadena detexto. Cuando se emplea una hoja XSLT el pro-ceso es similar si bien el objeto “Transformer”se obtiene a partir de una fuente dada (véase ellistado 2). Por último, cuando se desea parsearun documento empleando para ello SAX hayque construir una clase que extienda a la clase“DefaultHandler”. El listado 3 muestra una ver-sión muy simple para el fichero XML del ejem-plo de partida. Dicha clase se emplea para par-sear el documento haciendo:

SAXParserFactory saxParserFactory

= SAXParserFactory.newInstance();

SAXParser saxParser =

saxParserFactory.newSAXParser();

br = new BufferedReader(new

FileReader(“C:\\books.xml”));

InputSource inputSource = new

InputSource(br);

saxParser.parse(inputSource, new

Reader());

¿¿DDee qquuéé ffoorrmmaa ssee ppuueeddeenn cceennttrraarr llaassccaappaass ccoonn CCSSSS ddeennttrroo ddee llaa ppáággiinnaa HHTTMMLLeenn ffuunncciióónn ddee ssuu ccoonntteenniiddoo?? HHaacciieennddoo““aalliiggnn==””cceenntteerr”””” nnoo ppaarreeccee qquuee ffuunncciioonnee..

Efectivamente cuando haces algo del tipo:

<div class=”mylayer”

align=”center”>...</div>

Lo único que indicas es que el contenido de lacapa se ha de centrar con respecto a la capamisma, pero nada sobre la propia capa con res-pecto a la página.Existen varios métodos para centrar capas conCSS. Dos de los más conocidos son los que semuestran seguidamente:

.mylayer {

position: relative;

width: 772px;

left: 50%;

padding: 0px 0px 0px 0px;

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

}

En este caso la capa tiene posicionamientorelativo, es decir, se coloca en la páginasiguiendo el flujo “normal” teniendo en cuentalos elementos adyacentes. La anchura de lacapa se fija mediante el atributo “width”. Eltruco consiste en desplazar la capa un 50% ala izquierda y luego darle un margen negativoexactamente igual a la mitad de su anchura. Elprincipal inconveniente de este método es quela anchura de la capa tiene que estar definidacon antelación, es decir, no se centra en fun-ción de los contenidos. Veamos otro método,similar al anterior, aunque algo más sencillo:

.mylayer {

width: 772px;

margin-left: auto;

margin-right: auto;

}

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


DUDASPreguntas 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) {}

}

LISTADO 3 La clase Reader

public class Readerextends DefaultHandler{

private CharArrayWriter contents = new CharArrayWriter();

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

}

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

LIBROS


Este texto aborda, a través del estudio del parale-lismo en sus distintos niveles, los conceptos y lastécnicas de la arquitectura de computadores quepermiten aprovechar las posibilidades de la tecno-logía para lograr mayores capacidades de procesa-miento.A pesar de la importancia creciente que tiene elparalelismo en computadores hay una gran esca-sez de libros (en cualquier lengua) que aborden eltema en toda su extensión. La obra de los profeso-res Julio Ortega, Mancia Anguita y Alberto Prietocubre brillantemente este objetivo, resultando,además, su lectura muy didáctica y amena, inclu-yendo gran cantidad de ejemplos reales.Se presentan los contenidos desde los principiosde una ingeniería, estudiando las distintas alterna-tivas de diseño de las arquitecturas actuales y susprestaciones y eficiencia. Desde esta perspectiva,

el libro abarca el paralelismo en todos los nivelesen los que está presente en los computadoresactuales: paralelismo de datos (procesadores vec-toriales y arquitecturas SIMD); entre instrucciones(procesadores segmentados, superescalares,VLIW); entre hebras o entre procesos que aprove-chan las arquitecturas multihebra y sistemas mul-tiprocesador (SMP, NUMA, multicomputadores,cluster). Otros tópicos que se consideran son redesde altas prestaciones, redes SAN, jerarquía dememoria, coherencia y consistencia en el sistemade memoria, computación de altas prestaciones,programación paralela, optimización de código.Desde un punto de vista didáctico, se presenta lainformación unificada y estructurada, con nume-rosos ejemplos de apoyo y datos de procesadoresy computadores actuales y disponibles comercial-mente.El libro está pensado tanto para la docencia deasignaturas de las materias de arquitectura e inge-niería de computadores del segundo ciclo de latitulación de ingeniero en informática, como parasu uso en cursos que aborden tópicos de ingenie-ría de computadores o de altas prestaciones enotras titulaciones relacionadas con las tecnologíasde la información y las comunicaciones.

Arquitectura de computadoresAUTORES: 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

La versatilidad, potencia y uso generalizadohan convertido a C++ en el lenguaje más utili-zado por los programadores y profesionalespara la creación y desarrollo de aplicaciones.Manteniendo la riqueza y eficiencia de C peroeliminando sus limitaciones, C++ ha evolucio-nado hacia otros lenguajes como Java o C#, loscuales comparten sintaxis con C++, pero cuyacomprensión y aplicación práctica resultan máscomplejas.Esta obra está pensada y diseñada para ayudar-le a que aprenda por sí mismo cómo programarcon C++. A través de una clara organización ycon capítulos bien estructurados y fáciles de

seguir aprenderá fundamentos tales como ges-tión de E/S, bucles y matrices, programaciónorientada a objetos, plantillas y creación deaplicaciones C++. Los numerosos ejemplos desintaxis y el análisis detallado del código quecomplementan al texto son una excelente guíapara facilitar e ilustrar cada capítulo y conseguirque dominar C++ le resulte una tarea sencilla yrá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 pun-teros.

� Añada funcionalidad y eficiencia a sus apli-caciones con listas y plantillas vinculadas.

� Depure los programas para conseguir uncódigo impecable.

� Utilice técnicas de manipulación de excep-ciones y errores.

� Desarrolle código conforme al estándar ANSIpara facilitar su reutilización.

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

Paralelismo en computadores y C++ Paralelismo en computadores y C++

Revista Solo Programadores #128

Documents