View
357
Download
28
Category
Preview:
DESCRIPTION
Noticias, javaHispano y Opinión, Libros, Preguntas y Respuestas 8 413042303299 LA PRIMERA REVISTA DE PROGRAMACIÓN EN CASTELLANO MIDDLEWARE Desarrollos avanzados con Struts REDES Integración de elementos Java y C++ en ColdFusion MX 7 CANAL PANDA ¿Todos para uno? ¡Uno para todos! ACTUALIDAD Tecnologías Grid para la computación distribuida DISPOSITIVOS MÓVILES Creación de un sistema de distribución de Midlets según el modelo OTA y basado en IIS El GPS como “medio de comunicación”
Citation preview
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..
solop@revistasprofesionales.com
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 - angelbosch@infosel.net.mx
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
http://digital.revistasprofesionales.comSOLO PROGRAMADORES nº 128 6
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 (abraham.otero@javahispano.org) 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 (ivan.pedrazas@sword-uk.com), Sword UK
SOLO PROGRAMADORES nº 128 10
CANAL PANDA
¿Todos para uno? ¡Uno para todos!¿Todos para uno? ¡Uno para todos!
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 12811
CANAL PANDA¿Todos para uno? ¡Uno para todos!
http://digital.revistasprofesionales.com
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 (Fdelacuadra@pandasoftware.com) 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
SOLO PROGRAMADORES nº 128 12
ACTUALIDAD
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 12813
ACTUALIDAD
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 128
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
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 128
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
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 128
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
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 128
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
http://digital.revistasprofesionales.com
IRISGrid pretende fomentar la inves-tigación sobre Grid en España.
SOLO PROGRAMADORES nº 128 20
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)
http://digital.revistasprofesionales.com
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
SOLO PROGRAMADORES nº 12821
Creación de un sistema de distribución de Midlets (y II)DISPOSITIVOS MÓVILES
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 128
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
DISPOSITIVOS MÓVILES
http://digital.revistasprofesionales.com
SOLO PROGRAMADORES nº 128
� 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
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 128
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
DISPOSITIVOS MÓVILES
http://digital.revistasprofesionales.com
Finalizada la instalación, el emulador del J2ME Wireless Toolkit nos permitirácomprobar la descarga de Midlets.
SOLO PROGRAMADORES nº 128 26
DISPOSITIVOS MÓVILES
El GPS como “medio de comunicación”El GPS como “medio decomunicación”
http://digital.revistasprofesionales.com
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.
Material complementarioEl lector encontrará en http://
digital.revistasprofesionales.com el
material complementario de este
artículo.
SOLO PROGRAMADORES nº 12827
El GPS como “medio de comunicación”DISPOSITIVOS MÓVILES
http://digital.revistasprofesionales.com
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”.
SOLO PROGRAMADORES nº 128
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
DISPOSITIVOS MÓVILES
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 128
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
El GPS como “medio de comunicación”DISPOSITIVOS MÓVILES
http://digital.revistasprofesionales.com
SOLO PROGRAMADORES nº 128
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
DISPOSITIVOS MÓVILES
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 128
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
DISPOSITIVOS MÓVILES
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 128
“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
El GPS como “medio de comunicación”DISPOSITIVOS MÓVILES
http://digital.revistasprofesionales.com
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”.
SOLO PROGRAMADORES nº 128
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
DISPOSITIVOS MÓVILES
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 128 36
MIDDLEWARE
Struts práctico (y III)Struts práctico (y III)
http://digital.revistasprofesionales.com
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)
Material complementarioEl lector encontrará en http://
digital.revistasprofesionales.com el
material complementario de este
artículo.
SOLO PROGRAMADORES nº 12837
MIDDLEWAREStruts práctico (y III)
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 128
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
http://digital.revistasprofesionales.com
SOLO PROGRAMADORES nº 128
� 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
MIDDLEWAREStruts práctico (y III)
http://digital.revistasprofesionales.com
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>
SOLO PROGRAMADORES nº 128 40
MIDDLEWARE
http://digital.revistasprofesionales.com
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 - rpsuscripciones@revistasprofesionales.com
Deseo me envíen los número/s: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .NOMBRE Y APELLIDOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .EDAD . . . . . . . . TELÉFONO . . . . . . . . . . . . . . . .DOMICILIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C.P.: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .CIUDAD . . . . . . . . . . . . . . . . . .PROVINCIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FORMAS DE PAGO� Giro Postal a nombre de REVISTAS PROFESIONALES, S.L. � Talon Bancario a nombre de REVISTAS PROFESIONALES S.L. � Domiciliación Bancaria � Contra Reembolso (5€ de gastos de envio por paquete)
Banco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domicilio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Firma:Numero de cuenta: _ _ _ _/ _ _ _ _/ _ _ / _ _ _ _ _ _ _ _ _ _ _ _Titular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
� Tarjeta de crédito _ _ _ _/ _ _ _ _/ _ _ _ _/ _ _ _ _/ Fecha de caducidad: Extranjero: Gastos de envio 5€ por paquete. Unica forma de pago tarjeta de crédito (VISA, Mastercard, American Express,...)
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%
SOLO PROGRAMADORES nº 128
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
http://digital.revistasprofesionales.com
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
SOLO PROGRAMADORES nº 128
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
MIDDLEWAREStruts práctico (y III)
http://digital.revistasprofesionales.com
Figura 4. Gracias a la aplicación Sp.Shop, a lo largo del curso hemos podidoexperimentar con Struts de un modo totalmente práctico.
SOLO PROGRAMADORES nº 128
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
http://digital.revistasprofesionales.com
SOLO PROGRAMADORES nº 128
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
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 128
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
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 126
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
http://digital.revistasprofesionales.com
Figura 8. Aspecto de la página “Service.asmx” desde un cliente web.
Figura 9. Ejecución del método “Suma”.
SOLO PROGRAMADORES nº 128 50
REDES
Pruebas funcionales y de rendimiento con JMeterPruebas funcionales y de rendimiento con JMeter
http://digital.revistasprofesionales.com
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.
Material complementarioEl lector encontrará en http://
digital.revistasprofesionales.com el
material complementario de este
artículo.
SOLO PROGRAMADORES nº 12851
REDESPruebas funcionales y de rendimiento con JMeter
http://digital.revistasprofesionales.com
”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.
SOLO PROGRAMADORES nº 128 52
REDES
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 128
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
REDESPruebas funcionales y de rendimiento con JMeter
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 128
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
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 128
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
REDESPruebas funcionales y de rendimiento con JMeter
http://digital.revistasprofesionales.com
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”.
SOLO PROGRAMADORES nº 128
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
http://digital.revistasprofesionales.com
LISTADO 3 Contenido del fichero users.xml
<?xml version=”1.0”?><!DOCTYPE allthreads SYSTEM “users.dtd”>
<!— all users, uses round robin selection —><allthreads>
<!— unique parameters for each individual thread (ie user) —><thread>
<parameter><paramname>user</paramname><paramvalue>usuario1</paramvalue>
</parameter><parameter>
<paramname>mail</paramname><paramvalue>usuario1@internet.es</paramvalue>
</parameter><parameter>
<paramname>peticion</paramname><paramvalue>Autenticacion</paramvalue>
</parameter><parameter>
<paramname>password</paramname><paramvalue>husow4</paramvalue>
</parameter></thread><thread>
<parameter><paramname>user</paramname><paramvalue>usuario2</paramvalue>
</parameter><parameter>
<paramname>mail</paramname><paramvalue>usuario2@internet.es</paramvalue>
</parameter><parameter>
<paramname>peticion</paramname><paramvalue>Autenticacion</paramvalue>
</parameter><parameter>
<paramname>password</paramname><paramvalue>4jn28o</paramvalue>
</parameter></thread><thread>
<parameter><paramname>user</paramname><paramvalue>usuario3</paramvalue>
</parameter><parameter>
<paramname>mail</paramname><paramvalue>usuario3@internet.es</paramvalue>
</parameter><parameter>
<paramname>peticion</paramname><paramvalue>Autenticacion</paramvalue>
</parameter><parameter>
<paramname>password</paramname><paramvalue>zxcyui</paramvalue>
</parameter></thread>
</allthreads>
Figura 10. “HTTP User Parameter Modifier” para usar “users.xml”.
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.
SOLO PROGRAMADORES nº 128 58
REDES
Creación de aplicaciones webcon ColdFusion MX 7 (y III)Creación de aplicaciones webcon ColdFusion MX 7 (y III)
http://digital.revistasprofesionales.com
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
Material complementarioEl lector encontrará en http://
digital.revistasprofesionales.com el
material complementario de este
artículo.
SOLO PROGRAMADORES nº 12859
REDESCreación de aplicaciones web con ColdFusion MX 7 (y III)
http://digital.revistasprofesionales.com
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>
SOLO PROGRAMADORES nº 128 60
REDES
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 128
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)
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 128
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
http://digital.revistasprofesionales.com
SOLO PROGRAMADORES nº 128 64
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
http://digital.revistasprofesionales.com
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.
SOLO PROGRAMADORES nº 12865
DUDASPreguntas y respuestas
http://digital.revistasprofesionales.com
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
http://digital.revistasprofesionales.comSOLO PROGRAMADORES nº 128 66
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++
Recommended