Tfsoto

Universidad Nacional del Nordeste Facultad de Ciencias Exactas, Naturales y Agrimensura Trabajo Final de Aplicacin
Sistema Web con Acceso a Bases de Datos Multiplataforma a Travs de Telfonos Celulares
Sergio Andrs Soto - L.U.: 35406 Prof. Coordinador: Agr. Castor Herrmann Prof. Orientadores: Mgter. David Luis la Red Martnez y Lic. Valeria Uribe. Licenciatura en Sistemas de Informacin Corrientes - Argentina 2008
A mis padres por el apoyo incondicional que me brindaron
Prefacio
En los ltimos aos, la telefona mvil ha evolucionado considerablemente, la cual ha entrado de lleno en la sociedad y de la que hoy por hoy no se puede prescindir. A la par, el fenmeno Internet se ha extendido masivamente, convirtindose en la actualidad en un elemento de uso casi imprescindible en la vida cotidiana. A la unin de las dos tecnologas anteriores es a lo que se denomina Internet mvil. La potencia de los ltimos telfonos celulares, los hacen adecuados para la ejecucin de aplicaciones, que hasta hace poco slo podan ser ejecutadas desde un ordenador conectado a la red. Con el paso de los aos, el ser humano ha demostrado nuevas habilidades y destrezas en el desarrollo de nuevas tecnologas. La red Internet juega un papel fundamental en todos los mbitos: Profesionales, culturales, educativos, comerciales y otros. Gracias a ella y a los avances en telefona mvil, las personas pueden acceder a cualquier tipo de informacin en cualquier momento, en este sentido el comercio y ms el comercio electrnico en general, puede verse beneciado de este hecho. La proliferacin de nuevos dispositivos mviles con capacidad de comunicacin, como telfonos celulares, crea una nueva demanda de informacin para entidades que estn presentes en la red. Las empresas invierten en servicios que automatizan las operaciones de sus clientes. Uno de los ejemplos ms concretos son las entidadas bancarias, quienes desarrollan sistemas que ayudan a los clientes a la autogestin de sus operaciones las 24 hs del da con slo estar conectado a la red Internet. Los clientes desean poder acceder a los mismos servicios que acceden desde la Internet a travs de un ordenador pero con un dispositivo ms pequeo como un telfono celular. Para satisfacer lo anteriormente mencionado, en este trabajo se propuso el desarrollo de una aplicacin con software de computacin mvil multiplataforma, que permita el acceso a informacin situada en bases de datos multiplataforma en un servidor Web, a travs de dispositivos mviles tales como telfonos celulares. La aplicacin contempla el registro y seguimiento de informacin propia de una entidad bancaria, es decir la informacin pertinente de los clientes, sus
vi
cuentas bancarias, los movimientos realizados en una determinada cuenta, y otras operaciones inherentes de una cuenta. Esto signica para los clientes la posibilidad de autogestionar sus cuentas bancarias en cualquier momento y en cualquier lugar sin tener que asistir sicamente a las ocinas bancarias y con slo la ayuda de un telfono celular moderno. A su vez se propuso el desarrollo de la plataforma Web de la aplicacin que sea accesible desde la Intranet como as tambin desde la Internet, que contemple funciones adicionales como ser: registro de clientes, creacin de nuevas cuentas, poder realizar depsitos y extracciones, y adems ciertas funciones de administracin. Objetivos Logrados Se han alcanzado plenamente la totalidad de los objetivos planteados para el presente trabajo: Desarrollo de una aplicacin utilitaria empleando un software de computacin mvil multiplataforma para telfonos celulares que permita acceder a informacin remota situada en un base de datos que se encuentra en un servidor Web. Desarrollo de la plataforma web de la aplicacin con accesos a base de datos, que sirva de apoyo a la aplicacin mvil. Clasicacin del Trabajo El trabajo se encuadra en la utilizacin de software de base que permite el desarrollo de aplicaciones que permitan el acceso a bases de datos multiplataformas desde dispositivos mviles tales como telfonos celulares. Etapas de Desarrollo Se ha efectuado una amplia recopilacin bibliogrca especca a los temas pertinentes a la tarea planicada y a los productos de software que se emplearon para la concrecin del trabajo nal. Gracias a las gestiones realizadas por el Profesor Orientador Mgter. David Luis la Red Martinez ante IBM Argentina se han recibido materiales
vii
tanto en CDs como en libros de dicha empresa, en el marco de Scholars Program de la misma, destinado a Universidades de todo el mundo; se destacan por ser necesarios para la realizacin del presente Trabajo Final los referentes productos de software como los siguientes: WebSphere Studio Application Developer versin 5.0 y 5.1.2. DB2 UDB WorkGroup Server Edition versin 8.1. IBM Workplace Client Technology Micro Edition 5.7. WebSphere Studio Device Developer versin 5.7.1. Se realizaron las traducciones de los manuales correspondientes a las herramientas de desarrollo Websphere Studio Application Developer versin 5.1.2 y Websphere Studio Device Developer 5.7.1. Se ha efectuado un estudio acerca de las arquitecturas de aplicaciones mviles. Se ha realizado el anlisis y diseo de la base de datos que utiliza la aplicacin. Se ha realizado el estudio del manejador de bases de datos DB2 UDB para Windows. Se ha realizado un detallado estudio del J2ME (versin de Java para mviles), para la herramienta de desarrollo WebSphere Studio Device Developer versin 5.7.1. Se ha realizado un detallado estudio del software para el desarrollo de la plataforma web de la aplicacin, WebSphere Studio Application Developer versin 5.1.2. Se ha desarrollado el aplicativo mvil con la utilizacin del lenguaje Java, versin J2ME. En el marco de la herramienta WebSphere Studio Application Developer se desarroll el mdulo web del aplicativo utilizadando pginas XHTMLs, JSPs y Servlets de Java. Una vez nalizada la etapa de desarrollo se realizaron las siguientes actividades: Instalacin y conguracin del WebSphere Application Server, como servidor de aplicaciones y servidor web.
viii
Empaquetado de la aplicacin mvil para su distribucin e instalacin en los telfonos celulares. Instalacin de emuladores de telfonos celulares que fueron descargados desde los sitios webs de los fabricantes de los mismos. Instalacin y prueba de la aplicacin tanto en los emuladores como as tambin en telfonos celulares reales. Testeo del sistema, simulando un escenario real realizando pruebas de conexin entre el sistema mvil y el servidor web a travs de Internet. Finalizada la aplicacin se realiz la grabacin en DVD de todo el material correspondiente al trabajo nal: una versin de la aplicacin, otra referente al libro en formato LaTex y el PDF generado. Tambin se incluy los instaladores de los productos utilizados para el desarrollo, es decir DB2 UDB, WebSphere Studio Application Developer, WebSphere Studio Device Developer y emuladores. Organizacin del Informe Final El trabajo nal de aplicacin comprende un informe nal impreso y un DVD adems de un resmen y de un resmen extendido. El informe nal est organizado en captulos los que se indican a continuacin: Introduccin: Se presenta una vision global acerca de las nuevas tecnologas de informacin y comunicaciones, como as tambin las principales caracteristicas del comercio electronico mvil, computacin ubicua y de la sociedad de la informacin y el conocimiento. El mundo mvil : Se indican las principales caracteristicas de la evolucin de los sistemas de telefona mvil. Aplicaciones mviles: Se explican los requerimientos necesarios para una aplicacin mvil. Java: Se presentan los principales aspectos y destacadas caractersticas referidas al lenguaje. Java 2 Micro Edition: Se detallan las conceptos y caractersticas del lenguaje Java para dispositivos electronicos con menos recursos.
ix
Introduccin al DB2: Se detallan las ms relevantes relevantes caractersticas de esta familia de productos de gestin de bases de datos. WebSphere Studio: Presenta los principales aspectos de este entorno de aplicaciones complejas. Descripcin de la aplicacin: Se describen los todos aspectos de la aplicacin desarrollada utilizando las herramientas antes mencionas. Conclusiones: Se presentan las conclusiones a las que se ha llegado al nalizar el presente trabajo y las posibles lneas futuras de accin. El DVD adjunto al informe nal impreso, contiene lo siguiente: Instaladores del software utilizado. Resmenes del trabajo realizado. Informe nal en formato digital. Presentacin para la defensa nal. Aplicacin desarrollada. Sergio Andrs Soto Licenciatura en Sistemas de Informacin Universidad Nacional del Nordeste L.U.: 35406 Corrientes; 02 de Diciembre de 2008
ndice General
1 Introduccin 1.1 Vision Global . . . . . . . . . . . . . . . . . . . . . . 1.2 Comercio Electrnico . . . . . . . . . . . . . . . . . . 1.2.1 Concepto de Comercio Electrnico . . . . . . 1.2.2 Otras Concepciones del Comercio Electrnico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 3 3 3 4 5 7 8 8 10 11 12 13 13 14 14 15 17 17 18 19 19 20 20 20 22 25 xi
1.3 1.4
1.5
1.6 1.7
1.2.3 Esquema General . . . . . . . . . . . . . . . . . . 1.2.4 Modelos de Comercio Electrnico . . . . . . . . . M-Commerce . . . . . . . . . . . . . . . . . . . . . . . . Computacin Ubicua o Pervasiva . . . . . . . . . . . . . 1.4.1 Principios . . . . . . . . . . . . . . . . . . . . . . 1.4.2 Hacia las Cosas Inteligentes e Interconectadas . . 1.4.3 La Ley de Moore y la Visin de Weiser . . . . . La Sociedad de la Informacin y el Conocimiento . . . . 1.5.1 Denicin de Conocimiento . . . . . . . . . . . . 1.5.2 Proceso de Formacin del Conocimiento . . . . . 1.5.3 Clases de Conocimiento . . . . . . . . . . . . . . 1.5.4 Ciclo del Conocimiento . . . . . . . . . . . . . . 1.5.5 Caractersticas de la Sociedad del Conocimiento 1.5.6 Gestin del Conocimiento . . . . . . . . . . . . . 1.5.7 Tecnologas de la Gestin del Conocimiento . . . Comercio Electrnico en la Sociedad del Conocimiento . Comercio Electrnico Bancario . . . . . . . . . . . . . . 1.7.1 Qu es Banca Electrnica? . . . . . . . . . . . . 1.7.2 Ventajas . . . . . . . . . . . . . . . . . . . . . . . 1.7.3 Desventajas . . . . . . . . . . . . . . . . . . . . . 1.7.4 Banca a Travs del Telfono Mvil . . . . . . . . 1.7.5 Seguridad en Operaciones Electrnicas . . . . . .
2 El Mundo Mvil
xii
NDICE GENERAL
2.1 2.2 2.3
2.4
2.5
2.6
Evolucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Telfonos Mviles de Primera Generacin . . . . . . . . . . . . 2.2.1 Sistema Avanzado de Telefona Mvil . . . . . . . . . . Telfonos Mviles de Segunda Generacin . . . . . . . . . . . . 2.3.1 D-AMPS - El Sistema Avanzado de Telefona Mvil Digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 GSM (Sistema Global Para Comunicaciones Mviles) . 2.3.3 CDMA (Acceso Mltiple por Divisin de Cdigo) . . . . Telfonos Mviles de Tercera Generacin . . . . . . . . . . . . . 2.4.1 EDGE (Tasa de Datos Mejorada para la Evolucin del GSM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 GPRS (Servicio de Radio de Paquetes Generales) . . . . Servicios Adicionales de las Empresas Telefnicas . . . . . . . . 2.5.1 Servicios Analgicos . . . . . . . . . . . . . . . . . . . . 2.5.2 Recepcin y Envo de Mensajes de Texto . . . . . . . . 2.5.3 Servicios de Informacin . . . . . . . . . . . . . . . . . . 2.5.4 Mensajes Multimedia . . . . . . . . . . . . . . . . . . . 2.5.5 Juegos y Aplicaciones . . . . . . . . . . . . . . . . . . . 2.5.6 Internet Mvil . . . . . . . . . . . . . . . . . . . . . . . WAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.1 Introduccin a WAP . . . . . . . . . . . . . . . . . . . . 2.6.2 Motivacin . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.3 Modelo de WAP . . . . . . . . . . . . . . . . . . . . . . 2.6.4 Tecnologa . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.5 WAP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25 26 27 29 29 30 32 33 34 34 35 35 35 36 37 37 38 40 40 41 41 45 46 51 51 52 54 57 60 60 63 63 65 66 67 68
3 Aplicaciones Mviles 3.1 Introduccin . . . . . . . . . . . . . . . 3.2 Arquitectura de Aplicaciones Mviles . 3.3 Portal Para Aplicaciones Mviles . . . 3.4 Arquitectura de Bases de Datos . . . . 3.5 Aplicaciones Multiplataforma . . . . . 3.5.1 Java y Multiplataforma . . . .
4 Java 4.1 Introduccn al Lenguaje . . . . . . . . . . . . . . 4.1.1 Bibliotecas de Clases Estndares de Java 4.1.2 Java es Multiplataforma . . . . . . . . . . 4.1.3 Caractersticas del Lenguaje . . . . . . . . 4.2 Estructura de un Programa Java . . . . . . . . .
NDICE GENERAL
xiii
4.3
4.4
4.5
4.6
4.7
Conceptos Bsicos . . . . . . . . . . 4.3.1 Clases . . . . . . . . . . . . . 4.3.2 Herencia . . . . . . . . . . . . 4.3.3 Interfaces . . . . . . . . . . . 4.3.4 Package . . . . . . . . . . . . Variables de Java . . . . . . . . . . . 4.4.1 Datos de Objetos o Instancia 4.4.2 Datos de Clase . . . . . . . . Operadores del Lenguaje Java . . . . 4.5.1 Operadores Aritmticos . . . 4.5.2 Operadores de Asignacin . . 4.5.3 Operadores Unarios . . . . . 4.5.4 Operador Instanceof . . . . . 4.5.5 Operador Condicional . . . . 4.5.6 Operadores Incrementales . . 4.5.7 Operadores Relacionales . . . Estructuras de Programacin . . . . 4.6.1 Sentencias o Expresiones . . . 4.6.2 Comentarios . . . . . . . . . 4.6.3 Bifurcaciones . . . . . . . . . 4.6.4 Bucles . . . . . . . . . . . . . Servlet . . . . . . . . . . . . . . . . . 4.7.1 Estructura de un Servlet . . . 4.7.2 Instanciacin e Inicializacin 4.7.3 Servicio de Demanda . . . . . 4.7.4 Terminacin . . . . . . . . . . 4.7.5 Java Server Faces . . . . . . . 4.7.6 Desarrollando Aplicaciones .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69 69 70 70 71 71 73 73 74 74 74 75 75 75 76 76 77 77 77 78 80 82 83 86 88 88 88 94 97 97 98 101 102 103 106 109 114 115 116
5 Java 2 Micro Edition 5.1 Introduccin . . . . . . . . . . . . . . . . . . . . . 5.1.1 Comparacin de Versiones . . . . . . . . . 5.1.2 Algunas Consideraciones al Desarrollar en 5.2 Componentes de J2ME . . . . . . . . . . . . . . . 5.2.1 Mquinas Virtuales J2ME . . . . . . . . . 5.2.2 Conguraciones . . . . . . . . . . . . . . . 5.2.3 Perles . . . . . . . . . . . . . . . . . . . 5.3 Cmo Detectar una Aplicacin J2ME . . . . . . 5.4 Los MIDlets . . . . . . . . . . . . . . . . . . . . 5.4.1 El Gestor de Aplicaciones . . . . . . . . .
. . . . . . . . J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xiv
NDICE GENERAL
5.5
5.6
5.7
5.4.2 Ciclo de Vida de un Midlet . . . . . . . . . . . . . . . . 5.4.3 Estados de un MIDlet . . . . . . . . . . . . . . . . . . . 5.4.4 El paquete javax.microedition.midlet . . . . . . . . . . . 5.4.5 La Clase MIDlet . . . . . . . . . . . . . . . . . . . . . . 5.4.6 Estructura de los MIDlets . . . . . . . . . . . . . . . . . Interfaces Grcas de Usuario . . . . . . . . . . . . . . . . . . . 5.5.1 La Clase Display . . . . . . . . . . . . . . . . . . . . . . 5.5.2 La Clase Displayable . . . . . . . . . . . . . . . . . . . . 5.5.3 Las Clases Command y CommandListener . . . . . . . . 5.5.4 Interfaz de Usuario de Alto Nivel . . . . . . . . . . . . . RMS (Record Management System) . . . . . . . . . . . . . . . 5.6.1 Modelo de Datos . . . . . . . . . . . . . . . . . . . . . . 5.6.2 Record Stores . . . . . . . . . . . . . . . . . . . . . . . 5.6.3 Creacin de un Record Store . . . . . . . . . . . . . . . 5.6.4 Manipulacin de Registros . . . . . . . . . . . . . . . . . 5.6.5 Operaciones con Record Stores . . . . . . . . . . . . . . 5.6.6 Bsqueda de Registros . . . . . . . . . . . . . . . . . . . Comunicaciones en J2ME . . . . . . . . . . . . . . . . . . . . . 5.7.1 Clases y Conexiones del Generic Connection Framework 5.7.2 Comunicaciones HTTP . . . . . . . . . . . . . . . . . .
116 118 119 119 121 123 124 125 125 128 137 139 140 141 144 151 152 153 153 157
6 Introduccin al DB2 169 6.1 Bases de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 6.1.1 Objetivos de las Bases de Datos . . . . 6.1.2 Ventajas de las Bases de Datos . . . . . Sistema de Administracin de Bases de Datos Organizacin de Bases de Datos . . . . . . . . 6.3.1 Bases de Datos Jerrquicas . . . . . . . 6.3.2 Bases de Datos en Red . . . . . . . . . 6.3.3 6.4 6.5 Bases de Datos Relacional Introduccin a DB2 UDB . . . . . . . . . . . . 6.4.1 Caractersticas Generales del DB2 UDB DB2 UDB Versin 8.1 . . . . . . . . . . . . . . 6.5.1 Centro de Desarrollo . . . . . . . . . . . 6.5.2 Mejoras en XML Extender . . . . . . . 6.5.3 DB2 Warehouse Manager . . . . . . . . 6.5.4 Centro de Depsito de Datos de DB2 . 6.5.5 Asistentes de DB2 . . . . . . . . . . . . 6.5.6 Centro de Mandatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 170 171 173 173 174 176 177 180 180 181 182 182 183 183
6.2 6.3
. . . . . . . . . . . . . . . . 174 . . . . . . . . . . . . . . . . .
NDICE GENERAL
xv
7 WebSphere Studio 7.1 Que es WebSphere? . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Plataforma de Software . . . . . . . . . . . . . . . . . . . . . . 7.2.1 WebSphere for Commerce - Soluciones B2B . . . . . . . 7.2.2 WebSphere for Commerce - Soluciones B2C . . . . . . . 7.2.3 WebSphere for Commerce-Soluciones de Portal . . . . . 7.2.4 WebSphere for Commerce-Soluciones Digital Media . . . 7.3 Productos WebSphere Studio . . . . . . . . . . . . . . . . . . . 7.4 WebSphere Studio Application Developer . . . . . . . . . . . 7.4.1 Ventajas de Utilizar a WebSphere Studio Application Developer . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.2 Desarrollando Aplicaciones Java . . . . . . . . . . . . . 7.5 WebSphere Application Server . . . . . . . . . . . . . . . . . . 7.5.1 Introduccin . . . . . . . . . . . . . . . . . . . . . . . . 7.5.2 WebSphere Application Server Como Plataforma Para el Comercio Electrnico . . . . . . . . . . . . . . . . . . 7.5.3 Application Server - Advanced Edition . . . . . . . . . . 7.5.4 Application Server - Enterprise Edition . . . . . . . . . 7.5.5 Application Server - Standard Edition . . . . . . . . . . 7.5.6 Servidor HTTP . . . . . . . . . . . . . . . . . . . . . . . 7.5.7 Servidor de Aplicaciones . . . . . . . . . . . . . . . . . . 7.5.8 Contenedor de EJB . . . . . . . . . . . . . . . . . . . . 7.5.9 Contenedor Web . . . . . . . . . . . . . . . . . . . . . . 7.5.10 Contenedor de Clientes de Aplicaciones . . . . . . . . . 7.5.11 Sistema Principal Virtual . . . . . . . . . . . . . . . . . 7.5.12 Virtual Hosts (Hosts Virtuales) . . . . . . . . . . . . . 7.6 WCTME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.1 WebSphere Everyplace Micro Environment . . . . . . . 7.6.2 WebSphere Everyplace Custom Environment . . . . . . 7.6.3 J9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.4 WebSphere Studio Device Developer . . . . . . . . . . . 7.6.5 Java 2 Micro Edition (J2ME) . . . . . . . . . . . . . . . 7.7 WebSphere Studio Device Developer . . . . . . . . . . . . . . . 7.7.1 Componentes de WebSphere Studio Device Developer . 7.7.2 Herramienta de Desarrollo C (CDT) para Eclipse . . . . 7.7.3 Arquitectura de Device Developer . . . . . . . . . . . . 7.7.4 Utilizacin del IDE . . . . . . . . . . . . . . . . . . . . .
185 185 186 187 187 188 189 190 192 193 197 199 199 200 201 202 203 203 203 204 204 205 205 205 206 207 207 207 207 208 208 209 209 210 210
8 Descripcin de la Aplicacin 217 8.1 Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
xvi
NDICE GENERAL
8.2
8.3
Estructuracin . . . . . . . . . . . . . . . . . 8.2.1 La Aplicacin Mvil (Mobile Banking) 8.2.2 La Aplicacin Web . . . . . . . . . . . Estructuras de Datos Utilizadas . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
220 220 254 279
9 Conclusiones 285 9.1 Conclusiones Generales . . . . . . . . . . . . . . . . . . . . . . . 285 9.2 Conclusiones Acerca de las Tecnologas y Software Utilizados . 286 9.3 Lneas Futuras de Accin . . . . . . . . . . . . . . . . . . . . . 287
Bibliografa ndice de Materias
289 291
ndice de Figuras
1.1 1.2 1.3 1.4 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 3.1 4.1 4.2 4.3 4.4 4.5 4.6 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 Esquema General del Comercio Electrnico. . . . . . . . . . . . 5 Mark Weiser (1952-1999), el Visionario de la Computacin Ubicua 12 La Cadena del Conocimiento . . . . . . . . . . . . . . . . . . . 15 La Era de la Informacin . . . . . . . . . . . . . . . . . . . . . 16 Sistema Telefnico Mvil . . . . . . . . Un canal D-AMPS con 3 y 6 usuarios. Algunos Juegos Conocidos. . . . . . . Modelo Wap. . . . . . . . . . . . . . . Modelo de la Red Wap. . . . . . . . . Pilas de Protocolos TCP/IP y WAP. . Modelo de Programacin Wap. . . . . Modelo Proxy para WAP 2.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 30 38 42 43 45 48 48 58 65 67 84 87 93 94 99 101 105 110 117 118 124 139
Arquitectura de un Portal Mvil. . . . . . . . . . . . . . . . . . Mecanismo de Mensajes . . . . . . . . . . . . . . . . . . . . . . Proceso Compilacin y Ejecucin . . . . . . . . . . . . . . . . . Jerarqua y Mtodos de las Principales Clases Para Crear Servlets. Ciclo de Vida de un Servlet. . . . . . . . . . . . . . . . . . . . . Requerimiento de un Archivo JSP. . . . . . . . . . . . . . . . . Requerimiento de un Servlet. . . . . . . . . . . . . . . . . . . . Arquitectura de la Plataforma Java Ubicacin de las Tecnologas Java. Proceso de Vericacin. . . . . . . Entorno de Ejecucin de J2ME. . . Ciclo Vida de un MIDlet. . . . . . Estados de un MIDlet. . . . . . . . Jerarqua de Clases. . . . . . . . . Un MIDlet y el RMS. . . . . . . . xvii 2 de . . . . . . . . . . . . . . . . . . . . . Sun. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xviii
NDICE DE FIGURAS
5.9 5.10 5.11 5.12 5.13 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 8.12
Acceso a un RMS a Travs de un MIDlet Suite. Esturctura de Un Record Store. . . . . . . . . . Ejemplo RMS. . . . . . . . . . . . . . . . . . . Jerarqua de Interfaces. . . . . . . . . . . . . . Estados de una Conexin HTTP. . . . . . . . . Estructura de Una Base de Datos . . . . . . . Sistema de Administracion de Bases de Datos Modelo de Bases de Datos Jerrquica . . . . . Modelo de Bases de Datos en Red . . . . . . Modelo de Bases de Datos Relacional . . . . . AIV Extender . . . . . . . . . . . . . . . . . . XML Extender . . . . . . . . . . . . . . . . . Centro de Desarrollo . . . . . . . . . . . . . . Asistente Para Crear Tabla . . . . . . . . . . Centro de Mandatos . . . . . . . . . . . . . . La familia del WebSphere Studio. . . . . WebSphere Studio, entorno de desarrollo Plataforma de Eclipse. . . . . . . . . . Asistente de Proyecto Java. . . . . . . . Paquete Java. . . . . . . . . . . . . . . . Dilogo de Conguracin de Ejecucin. . WebSphere para e-bussines. . . . . . . . Barra de herramientas de WSDD. . . . . Mtodos de un Objeto. . . . . . . . . . . Nuevo Dispositivo Emulador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
140 141 151 154 158 172 172 174 175 176 179 179 181 184 184 191 191 193 198 199 200 201 211 213 215 219 221 222 224 224 225 226 226 227 228 229 231
Casos de Usos del Sistema. . . . . . . . . . Arquitectura del Sistema. . . . . . . . . . . Diagrama de Clases de la Aplicacin Mvil. La Clase Pantalla . . . . . . . . . . . . . . . La Clase MPrincipal. . . . . . . . . . . . . . La Clase MenuCuenta. . . . . . . . . . . . . La Clase Comunicacion. . . . . . . . . . . . La Clase Transferencia . . . . . . . . . . . . La Clase Balance. . . . . . . . . . . . . . . . La Clase Movimiento. . . . . . . . . . . . . La Clase Cuenta. . . . . . . . . . . . . . . . Pantalla Principal Mobile Banking . . . . .
NDICE DE FIGURAS
xix
8.13 8.14 8.15 8.16 8.17 8.18 8.19 8.20 8.21 8.22 8.23 8.24 8.25 8.26 8.27 8.28 8.29 8.30 8.31 8.32 8.33 8.34 8.35 8.36 8.37 8.38 8.39 8.40 8.41 8.42 8.43 8.44 8.45 8.46 8.47 8.48 8.49 8.50 8.51
Men Principal. . . . . . . . . . . . . . . . . . . . . . . . Pantallas de Ingreso al Sistema. . . . . . . . . . . . . . . Pantalla de Aviso de Conexin. . . . . . . . . . . . . . . Informacin del Cliente. . . . . . . . . . . . . . . . . . . Lista de Cuentas. . . . . . . . . . . . . . . . . . . . . . . Men de Operaciones de una Cuenta. . . . . . . . . . . Informacin de Saldo de una Cuenta. . . . . . . . . . . Ingreso de Datos Para una Transferencia. . . . . . . . . Conrmacin de la Transferencia. . . . . . . . . . . . . . Resultado Satisfactorio de una Transferencia. . . . . . . Error en una Transferencia. . . . . . . . . . . . . . . . . Lista de Movimientos de una Cuenta por Fecha y Hora. Detalle de un Movimientos en Particular. . . . . . . . . Pantalla de Advertencia al Usuario. . . . . . . . . . . . . Advertencia al Usuario. . . . . . . . . . . . . . . . . . . Pantallas Para Congurar la URL del Servidor. . . . . . Pantalla de Ayuda del Sistema. . . . . . . . . . . . . . . RecordStores Utilizados por la Aplicacin. . . . . . . . . Proceso del Mensaje Calculado. . . . . . . . . . . . . . . Modelo-Vista-Controlador. . . . . . . . . . . . . . . . . . Diagrama de Paquetes. . . . . . . . . . . . . . . . . . . . Diagrama de Clases. . . . . . . . . . . . . . . . . . . . . Funciomamiento del Sistema. . . . . . . . . . . . . . . . Pantalla Principal de Home Banking. . . . . . . . . . . . Mensaje de Error. . . . . . . . . . . . . . . . . . . . . . Pantalla de Modicacin de Claves. . . . . . . . . . . . . Pantalla de Listado de Cuentas. . . . . . . . . . . . . . . Detalle de una Cuenta Determinada. . . . . . . . . . . . Transferencia de Fondos Hacia Otra Cuenta. . . . . . . . Mensajes de Estado del Proceso de Transferencia. . . . . Pantalla de Listado de Movimientos. . . . . . . . . . . . Pantalla que Muestra Informacin de Mobile Banking. . Pantalla de Login de Banking. . . . . . . . . . . . . . . Pantalla de la Seccin Clientes. . . . . . . . . . . . . . . Pantalla para Ingresar Nuevos Clientes. . . . . . . . . . Datos del Nuevo Cliente . . . . . . . . . . . . . . . . . . Listado de Cuentas. . . . . . . . . . . . . . . . . . . . . Informacin de una Cuenta . . . . . . . . . . . . . . . . Movimientos de una Cuenta. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
233 234 235 236 237 238 240 241 242 243 244 245 246 247 248 249 250 251 253 255 256 257 258 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275
xx
NDICE DE FIGURAS
8.52 8.53 8.54 8.55 8.56 8.57
Operaciones Sobre una Cuenta. . . . . . . . . . . . Mensajes de Error que Maneja el Sistema. . . . . . Pantalla para el Cambio de Clave. . . . . . . . . . Creacin de Usuarios . . . . . . . . . . . . . . . . . Listado de Accesos . . . . . . . . . . . . . . . . . . Tablas que Integran la Base de Datos del Sistema.
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
276 277 278 279 280 281
ndice de Tablas
4.1 4.2 4.3 4.4 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20 5.21 5.22 5.23 Categoras de Variables. . Tipos Primitivos de Datos Operadores de asignacin. Operadores relacionales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 73 75 76 108 109 111 112 114 119 126 127 127 128 129 131 133 135 137 138 143 144 155 156 159 159 160
Libreras de conguracin CDC. . . . . . . . Libreras de conguracin CLDC. . . . . . . . Libreras del Fondation Prole. . . . . . . . . Libreras del Personal Prole. . . . . . . . . . Libreras del MIDP Prole. . . . . . . . . . . Clases del Paquete javax.microedition.midlet. Mtodos de la Clase Display. . . . . . . . . . Mtodos de la Clase Displayable. . . . . . . . Tipos de Commands. . . . . . . . . . . . . . . Mtodos de la Clase Command. . . . . . . . . Tipos de Alerta. . . . . . . . . . . . . . . . . Mtodos de la Clase List. . . . . . . . . . . . Mtodos de la Clase Form. . . . . . . . . . . . Mtodos de la Clase StringItem. . . . . . . . Mtodos de la Clase ImageItem. . . . . . . . Mtodos de la Clase TextField. . . . . . . . . Mtodos Generales de la Clase RecordStore. . Mtodos Para Manejo de Registros. . . . . . . Mtodos de la Clase Connector. . . . . . . . . Tipos de Permisos. . . . . . . . . . . . . . . . Mtodos en la Etapa de Establecimiento. . . Tipos de peticiones. . . . . . . . . . . . . . . Campos de la Cabezera. . . . . . . . . . . . .
xxi
Captulo 1
Introduccin
1.1 Vision Global
La implantacin en la sociedad de las denominadas Nuevas Tecnologas de la Comunicacin e Informacin, est produciendo cambios insospechados respecto a los originados en su momento por otras tecnologas, como fueron la imprenta, y la electrnica. Sus efectos y alcance, no slo se sitan en el terreno de la informacin y comunicacin, sino que lo sobrepasan para llegar a provocar y proponer cambios en la estructura social, econmica, laboral, jurdica y poltica. Y ello es debido a que no slo se centran en la captacin de la informacin, sino tambin, a las posibilidades que tienen para manipularla, almacenarla y distribuirla. Las Nuevas Tecnologas de la Informacin y la Comunicacin no son slo invenciones geniales, tienen su justicacin social ya que contribuyen a disminuir los costos de produccin de bienes de la sociedad al incrementar la productividad e impulsar la investigacin y el desarrollo. Ha surgido la llamada supercarretera de la informacin: Internet, la red de redes de computadoras, la gran autopista que conecta todas las redes de ordenadores del mundo; en ella la informacin uye libremente y sin interrupciones, se comparte y se esparce, nadie an ha sido capaz de calcular el volumen de informacin que almacena ni tampoco sus lmites. Las Nuevas Tecnologas de la Informacin y la Comunicacin rompen las barreras geogrcas borrando las distancias fsicas pero no rompen las barreras 1
CAPTULO 1. INTRODUCCIN
sociales, mantienen e incluso incrementan las distancias sociales entre ricos y pobres. Una de sus ventajas es que en la actualidad el ritmo de produccin de los conocimientos ha crecido vertiginosamente y se ha reducido el tiempo necesario para transformar el conocimiento bsico en ciencia aplicada y sta en tecnologa la cual se difunde ampliamente a travs de diferentes vas. Por tanto, las Nuevas Tecnologas de la Informacin y la Comunicacin a pesar de sus ventajas, no son accesibles a todos por igual; este acceso est mediado por factores econmicos, se tiene informacin si se dispone de recursos necesarios para adquirirla. El efecto social de las redes y servicios telemticos es difcil de predecir. El aumento del ancho de banda disponible ser la base de las futuras innovaciones que pueden afectar profundamente a la sociedad humana. Las redes inalmbricas jugarn un papel muy importante, stas hoy en da son una realidad, estamos acostumbrados a ver ordenadores porttiles conectados a Internet sin necesidad de cables, pequeos ordenadores de mano conectados con los ordenadores de la ocina, cada da aumenta ms la creacin de las redes inalmbricas ciudadanas, en la que voluntariamente y sin buscar benecios ms all del uso de las tecnologas disponibles y el afn de aprender y practicar con ellas, hay ciudadanos que van poniendo a disposicin de los dems puntos de acceso a una red que cada da va creciendo ms, y que cada voluntario ayuda a que sta crezca. Y todo este avance tecnolgico no es ms que el inicio de un mundo de posibilidades que se abren con este nuevo modelo de computacin, denominado computacin pervasiva o computacin ubicua. Este modelo de computacin ubicua signica bsicamente la omnipresencia de computadores muy pequeos interconectados sin cables que se incorporan de forma casi invisible a cualquier objeto de uso cotidiano, y usando pequeos sensores unidos a estos computadores pueden detectar el entorno que les rodea y tienen capacidades tanto de procesar informacin como de comunicacin. Una de las posibilidades es el comercio electrnico, el cual est cambiando la manera que los consumidores, comerciantes y empresas realizan sus transacciones. El comercio electrnico permite comprar, invertir, realizar operaciones bancarias, vender, distribuir en cualquier lugar en donde se pueda disponer de conexin a Internet y con la interconexin con las redes sin hilos con Internet desde cualquier lugar y cualquier momento que se desee.
1.2. COMERCIO ELECTRNICO
El uso de telfonos mviles para el acceso a Internet abre nuevas posibilidades en el comercio electrnico. el m-commerce, involucra tres aspectos bsicos: oferta de los negocios y de servicios en un rea circundante al usuario; informacin oportuna, georeferenciada mientras el usuario est en movimiento y posibilidad de completar la transaccin en forma inmediata.
1.2
1.2.1
Comercio Electrnico
Concepto de Comercio Electrnico
Existen muchas deniciones de comercio electrnico. Una de la ms completas, es la siguiente: Transacciones de negocios efectuadas mediante redes pblicas o privadas, incluyendo transacciones pblicas y privadas que utilizan Internet como instrumento de entrega. Estas transacciones incluyen tranferencias nancieras, intercambios en lnea, subasta, entrega de productos y servicios, actividades de la cadena de abastecimiento y redes de negocios integradas [6]. El concepto de Comercio Electrnico (e-commerce en ingls) hace referencia a una nueva forma de hacer negocios basada en el uso de las nuevas tecnologas capaces de automatizar las transacciones comerciales que deben realizar las empresas en sus actividades comerciales mediante mecanismos electrnicos, es decir, sin la utilizacin de los mecanismos tradicionales como son los documentos basados en papel. El trmino Comercio Electrnico se utiliza para referirse a cualquier relacin electrnica o digital que lleve asociada un intercambio de valor, ya sea un bien o un servicio, entre varias entidades comerciales (generalmente dos o tres).
1.2.2
Otras Concepciones del Comercio Electrnico
El Comercio Electrnico (e-Commerce) es la simple replicacin de un negocio en Internet u otro medio electrnico que permita recoger los pedidos u ofertar los productos y/o servicios desde o hacia clientes o proveedores. Por ejemplo vender zapatos en la pgina web de la empresa, recibir los pedidos desde la web, por ejemplo, en forma de e-mail o a
una base de datos y hacer los despachos. Muchas veces esta actividad puede generar duplicacin de tareas o tareas extras para asentar esas transacciones en los sistemas digitales centrales del negocio. El hacer Negocios Electrnicos (e-Business) integra no slo el e-Commerce sino tambin la operativa interna, por ende se accede a la infraestructura informtica, los procesos de las ventas electrnicas, en denitiva toda la administracin del negocio est conectada a la pgina web y las transacciones que en ella se desencadenen. El sistema organizacional e informtico est por ende unicado con el de la web corporativa, el negocio est realmente en lnea (on-line). El sitio web pasa a ser una boca de expendio ms as como lo son los mostradores en las sucursales, en los intermediarios o la propia casa matriz de la empresa. En trminos realmente simples se puede decir que cuando alguien realiza una compra en el sitio web, esa transaccin se reeja de manera inmediata en los sistemas informticos de la empresa, a su vez que dispara los procesos administrativos, nancieros y de despacho necesarios.
1.2.3
Esquema General
El Comercio electrnico se puede denir como un intercambio electrnico de datos que se utilizan para dar soporte a transacciones comerciales, es decir, un intercambio de valores entre un vendedor o comerciante (ofertante de bienes y servicios) y un comprador (demandante de bienes y servicios). [7] La mayor parte de los sistemas actuales de comercio electrnico consiste bsicamente en un vendedor que oferta sus productos a travs de un catlogo (preferentemente actualizado) y unos compradores de dicho producto quienes consultan el catlogo ofrecido por el vendedor y a su vez tienen la posibilidad de comprar dichos productos. Se puede sintetizar el ciclo de compra en las siguientes etapas: La entidad vendedora (ofertante) oferta sus productos mediante un catalogo actualizado. La entidad compradora (demandante) consulta los productos ofertados. La entidad compradora (demandante) realiza el pedido. La entidad vendedora (ofertante) acepta el pedido y lo conrma.
1.2. COMERCIO ELECTRNICO
Finalmente es necesario realizar la entrega del producto y el pago (ambos procesos se pueden realizar indistintamente de forma electrnica o no); ver g. 1.1 de la pg. 5. Todos los intercambios entre compradores y vendedores en el escenario electrnico o virtual se realizan de forma no presencial mediante la utilizacin de redes de transmisin como el caso de la red Internet.
Figura 1.1: Esquema General del Comercio Electrnico. La mayora de las veces los compradores y vendedores en el escenario electrnico ni siquiera se conocen y en el caso de comportamiento deshonesto de alguno de ellos no existen evidencias fsicas que pueden utilizarse como prueba en caso de litigio. Por lo tanto es necesario que se pase a un escenario seguro de comercio electrnico o virtual.
1.2.4
Modelos de Comercio Electrnico
B2C (Bussines to Consumer) (Negocio a Cliente Final) Es el negocio orientado hacia el consumidor nal (internauta particular que navega por la red). Las empresas ofrecen sus productos a particulares a travs de su portal web. El nico requisito es conectarse a su web y hacer un pedido. Se considera el original comercio electrnico. Las estadsticas indican que cada vez se compra ms por Internet, pero la evolucin es lenta comparada con las expectativas que se haban creado.
Tiene el riesgo de que los clientes pueden comparar precios fcilmente, con lo que el marketing y el posicionamiento de la marca son muy importantes. Gran parte de su xito depende de: La originalidad del negocio. La comodidad para el comprador. La rapidez de la entrega. El precio (ahora con respecto al comercio tradicional). B2B (Bussines to Bussines) (Negocio a Negocio) A este tipo de comercio tambin se lo conoce como comercio mayorista. En este caso las entidades comerciales son empresas. Congrega a proveedores, compradores e intermediarios que se ofrecen mutuamente sus productos en base a unas reglas de negocios jadas. Es el verdadero impulsor del comercio electrnico. El volumen de negocio entre empresas es muy superior al negocio dirigido al cliente nal. C2C (Consumer to Comsumer) (Consumidor a Consumidor) La negociacin se desarrolla entre personas con intereses similares indistintamente de la parte compradora y vendedora. La comunicacin se realiza de forma espontnea y los participantes pueden asumir roles de comprador, vendedor o ambos. Requiere sistema de intermediario para garantizar la conanza entre los participantes. Un ejemplo podra ser un sitio de subastas, donde un particular ofrece un producto y otro lo compra. Es necesario pasar por un intermediario, que es la subasta, con lo que se podra resumir en dos negocios B2C paralelos. Otra categora de comercio electrnico que seguramente impactar en el futuro es Mobil-Commerce (M-Commerce) o comercio electrnico a travs de telfonos mviles.
1.3. M-COMMERCE
Se fundamenta en lo siguiente: La penetracion de la telefona mvil. El acceso gratuito/tarifa plana a Internet. La implantacin de la tarjeta inteligente. Los mviles inteligentes. Telefona inalmbrica digital. La convergencia: Telfono jo/mvil/Internet. El potencial de usuarios de telfonos mviles es superior al de los internautas. Los estudios de empresas consultoras de comercio electrnico apuestan por el comercio electrnico mvil, como el de mayor desarrollo e impacto futuro.
1.3
M-Commerce (Comercio Electrnico a Travs de Dispositivos Mviles)
El comercio electrnico se est transformando lentamente en m-commerce, un nuevo modelo de comercio on-line en el cual los telfonos mviles, u otros artefactos wireless (inalmbricos), jugarn un papel muy importante. Todos los carriers importantes del mundo estn desarrollando planes sobre este paradigma. El fuerte desarrollo de la norma GSM en Europa, el sistema de SMS, y especialmente el WAP, facilitaron el acceso mvil e interactivo a datos, abriendo nuevas posibilidades para el comercio. Pero esas oportunidades tienen algunas dicultades como el ancho de banda limitado que an complica las transmisiones, y la interfaz de usuario de los dispositivos mviles es limitada en tamao. Adems, los costos de acceso son altos, y el poder de cmputo de estos dispositivos es mucho ms pequeo que el de las PCs. El m-commerce involucra tres aspectos bsicos: Oferta de los negocios y servicios en un rea circundante al usuario.
Informacin oportuna georeferenciada mientras el usuario est en movimiento. Posibilidad de completar la transaccin de forma inmediata. Por ello debe ofrecer al usuario las siguientes prestaciones: Negociacin y entrega inmediata. Mtodos de micro y macro pagos. Facilidades de uso en el contexto mvil.
1.4
Computacin Ubicua o Pervasiva
Mark Weiser, en Septiembre de 1991, describi su visin de lo que l llamaba computacin ubicua, hoy llamada computacin pervasiva. La esencia de su visin era la creacin de entornos llenos de computacin y de capacidad de comunicacin, todo integrado de forma inapreciable junto a las personas. La visin de Weiser estaba bastante alejada de su poca, entre otras razones porque no exista la tecnologa necesaria para llevarla a cabo. Pero despus de ms de una dcada de progreso en el campo de los dispositivos hardware, las criticadas ideas de Weiser en 1991 ahora son productos comercialmente viables: Ordenadores de bolsillo. Redes inalmbricas. Sensores muy avanzados. Computacin vestible.
1.4.1
Principios
Uno de los principales objetivos de la computacin ubicua es hacer desaparecer a los dispositivos computacionales hacindolos situarse en un segundo plano. Este objetivo de crear dispositivos que se mezclen en la vida cotidiana hasta que lleguen a ser indistinguibles supone una potencial revolucin que
1.4. COMPUTACIN UBICUA O PERVASIVA
puede hacer cambiar el modo de vida diario. Las personas se centrarn en las tareas que deben hacer, no en las herramientas que utilizan, porque se pretende que esas herramientas pasen desapercibidas. El signicado de enviar la computacin a un segundo plano est referido a dos conceptos diferentes pero relacionados. El primero es el signicado literal de que la tecnologa de la computacin se debe integrar en los objetos, cosas, tareas y entornos cotidianos. Y la segunda es que esta integracin se debe realizar de forma que la introduccin de la computacin en estas cosas u objetos no intereran con las actividades para las que son usadas, y que siempre proporcionen un uso ms cmodo, sencillo y til de esos objetos. Estos objetos cotidianos en los que se integra la tecnologa de la computacin pasan a tener una serie de propiedades que permiten la creacin del entorno ubicuo buscado. Algunas de esas propiedades son: Comunicacin entre dispositivos: Todos estos objetos dotados de capacidad de computacin tambin tienen capacidad de comunicacin, y no solo con el usuario, sino con los dems objetos integrados que haya a su alrededor. Poseen memoria: Adems de poder comunicarse entre ellos e interactuar con los usuarios, estos dispositivos tienen capacidad de memoria y pueden utilizar esta memoria para una mejor interaccin con el resto de dispositivos. Son sensibles al contexto: Estos objetos son sensibles al contexto, es decir, se adaptan a las posibles situaciones, como la situacin geogrca, los dispositivos que hay a su alrededor, las preferencias de los usuarios, y actan dependiendo de ese entorno que los rodea. Son reactivos: Estos objetos reaccionan al ocurrir determinados eventos, que pueden percibir en su entorno mediante sensores o a travs de la interaccin con otros dispositivos. El computador personal, Internet y la World-Wide Web han inuido ya en muchos aspectos del mundo de los negocios y hay seales evidentes de una amplia convergencia de industrias enteras como la de los medios de comunicacin, entretenimiento, electrnica de consumo, telecomunicaciones y tecnologa de
10
la informacin. La siguiente ola de la revolucin tecnolgica puede afectar directamente y en todos los aspectos de la vida cotidiana. Durante ms de 30 aos la conocida ley de Moore, segn la cual la funcionalidad de un procesador se duplica cada 18 meses, ha demostrado ser cierta. Una mejora similar en prestaciones se aplica tambin a algunos otros parmetros importantes de la tecnologa. Se arma que la tendencia actual continuar durante unos cuantos aos ms, lo que hace que toda esta rea de desarrollo sea tan intrigante. Ahora parece que el futuro prximo estar caracterizado por pequeos computadores que se comunican de forma espontnea, que por su pequeo tamao y por su bajo precio, se integrarn en casi todos los objetos cotidianos. La tecnologa de la informacin por lo tanto se volver ubicua e invadir todos los aspectos de la vida de las personas. Los telfonos mviles con acceso a Internet y los Asistentes Digitales Personales (Personal Digital Assistants, PDAs) que se comunican sin cables con otros dispositivos prximos a ellos son los primeros indicios de la era post-PC venidera. Al principio, el principal objetivo es permitir el acceso a la informacin de cualquier tipo desde cualquier lugar y en cualquier momento, lo que evidencia los esfuerzos actuales de la industria por integrar aparatos de informacin mviles y utilizables en procesos de negocios basados en la Web y escenarios de comercio electrnico. Sin embargo, a largo plazo, esta continua tendencia tecnolgica puede dar lugar a la fusin del computador con los objetos cotidianos tpicos para que se vuelva literalmente invisible.
1.4.2
Hacia las Cosas Inteligentes e Interconectadas
Hoy, Internet conecta casi todos los computadores del mundo. Desde un punto de vista tecnolgico, se podra describir a la computacin ubicua como la posibilidad de conectar todo lo que hay en el mundo a Internet, para proporcionar informacin acerca de cualquier cosa, en cualquier momento, en cualquier sitio. Por decirlo de otra forma, el trmino computacin ubicua signica la omnipresencia de computadores muy pequeos interconectados sin cables que se incrustan de forma casi invisible en cualquier tipo de objeto cotidiano. Usando pequeos sensores, estos procesadores incrustados pueden detectar el entorno que les rodea y equipar a su objeto con capacidades tanto de procesar informacin como de comunicacin.
1.4. COMPUTACIN UBICUA O PERVASIVA
11
1.4.3
La Ley de Moore y la Visin de Weiser
La ley de Moore, formulada en los aos sesenta por Gordon Moore, arma que la capacidad de computacin disponible en un microchip se multiplica por dos aproximadamente cada 18 meses y, de hecho, esto ha resultado ser un pronstico extraordinariamente exacto del desarrollo del chip desde entonces. Y esta ley se ha venido cumpliendo hasta el da de hoy, la capacidad de cmputo de los procesadores avanza muy rpidamente. Pero no solo la capacidad de cmputo de los procesadores, sino tambin la capacidad de almacenamiento, el ancho de banda para las comunicaciones, en resumen, cada poco tiempo se tiene dispositivos ms baratos, ms pequeos y ms potentes. Y no parece que se vaya a parar este crecimiento, sino todo lo contrario. El trmino computacin ubicua , fue acuado hace ms de diez aos por Mark Weiser; ver g. 1.2 de la pg. 12, un investigador del Palo Alto Research Center de XEROX. Weiser ve la tecnologa solamente como un medio para un n y como algo que debera quedar en segundo plano para permitir al usuario concentrarse completamente en la tarea que est realizando. En este sentido, considerar el computador personal como herramienta universal para la tecnologa de la informacin sera un enfoque equivocado, ya que su complejidad absorbera demasiado la atencin del usuario. Segn Weiser, el computador como dispositivo dedicado debera desaparecer, mientras que al mismo tiempo debera poner a disposicin sus capacidades de procesamiento de la informacin. [20] Weiser ve el trmino computacin ubicua en un sentido ms acadmico e idealista centrada en la persona, como una visin de tecnologa discreta, mientras que la industria ha acuado por eso el trmino computacin pervasiva, o ampliamente difundida con un enfoque ligeramente diferente. Aunque su visin siga siendo todava integrar el procesamiento de la informacin en objetos cotidianos de forma casi invisible, su objetivo principal es utilizar tales objetos en un futuro prximo en el mbito del comercio electrnico y para tcnicas de negocios basados en la Web. [18] Mark Weiser fue un principal cientco de Xerox Parc y ampliamente considerado como el padre de la computacin ubicua (conocida tambin como ubicomp). Weiser naci en Harver, un barrio exterior de Chicago, Illinois; estudi ciencias de la computacin y comunicacin en la Universidad de Michingan,
12
Figura 1.2: Mark Weiser (1952-1999), el Visionario de la Computacin Ubicua se dedic a la docencia durante ocho aos en ciencias de la computacin en la Universidad de Maryland, Clollege Park. Mientras Weiser trabajaba para una variedad de compaas relacionadas a la computacin, su trabajo fue en el campo de la computacin ubicua mientras diriga el laboratorio de ciencias de computacin de Parc, al cual se uni en 1987, Se convirti en la cabeza del laboratorio de ciencias de la computacin en 1988 y el ocial primero de la tecnologa en 1996, simultneamente fue autor de ms de 75 publicaciones.
1.5
La Sociedad de la Informacin y el Conocimiento
Es un hecho de la realidad que los vertiginosos avances que presentan las TICs (Tecnologas de la Informacin y de las Comunicaciones) han convertido al planeta en lo que se ha de llamar la aldea global . [1], permitiendo que la sociedad sea conocida como la Sociedad de la Informacin y el Conocimiento o Cibersociedad, en la cual la profusin de redes de datos ha permitido interconectar una diversidad de equipos informticos de diferentes tecnologas de hardware y de software constituyendo una enorme red mundial multiplataforma, que ha generado una nueva forma de interaccin de las personas y de la empresas, impactando en la educacin, las actividades sociales, el comercio, etc.
1.5. LA SOCIEDAD DE LA INFORMACIN Y EL CONOCIMIENTO 13
1.5.1
Denicin de Conocimiento
El conocimiento es materia de estudio de distintas disciplinas, tales como la losofa, la gestin empresarial, y ms recientemente la informtica, por ello se encuentran distintas deniciones del trmino conocimiento segn el punto de vista e inters de quienes se pronuncien. Antes de denir conocimiento algunos autores se apoyan a las deniciones de otros dos conceptos: dato e informacin. Dato: antecedente necesario para llegar al conocimiento exacto de una cosa o para deducir las consecuencias legtimas de un hecho. Informacin: accin y efecto de informar e informarse. Conocimiento: accin y efecto de conocer. Nocin, ciencia, sabidura. Tambin se puede denir al conocimiento como: Es el conjunto de experiencias valores e informaciones dotadas de signicado que facilitan el marco idneo para evaluar nuevas informaciones e incorporar nuevas experiencias. [12]
1.5.2
Proceso de Formacin del Conocimiento
Comprende los siguientes pasos: Datos: Hechos y expresiones percibidos, por ejemplo una secuencia de nmeros, letras. Informacin: Datos organizados bajo patrones explicativos; conjunto coherente de datos que transmite un mensaje. Conocimiento: Informacin elaborada de modo que comporta signicado y puede ser utilizada en la toma de decisiones. Sabidura: Conocimiento reutilizado y proceso de retroalimentacin de los conocimientos.
14
1.5.3
Clases de Conocimiento
El conocimiento puede dividirse en: Conocimiento tcito Conocimiento explcito El conocimiento tcito es aquel que no est registrado por ningn medio y que solo se obtiene mediante la adquisicin de conocimientos de manera prctica y solo es posible transmitir y recibir consultando directa y especcamente al poseedor de estos conocimientos. Tambin el conocimiento tcito es aquel conocimiento que no est registrado (el que se tiene en la cabeza). Es la intuicin, opinin, las creencias, la experiencia. El conocimiento tcito como la percepcin subjetiva o las emociones, no se puede instrumentalizar y se transmite en determinados contextos y acciones. El conocimiento tcito es el conocimiento que poseen las personas y que es inseparable de su experiencia y puede ser compartido o intercambiado, mediante contactos directos. El conocimiento explcito se trata del conocimiento basado en datos concretos, con lo que sera suciente su conocimiento para el aprovechamiento de los mismos, sin necesidad de interpretacin alguna, expresndolo de una manera simple, es la teora. El conocimiento explcito es el conocimiento tcito codicado y vertido en algn soporte de almacenamiento y comunicacin. Este conocimiento se puede expresar mediante palabras y nmeros, y es fcil de transmitir. Es un conocimiento formal que puede plasmarse en documentos de una organizacin tales como informes, patentes, manuales, imgenes, esquema, software, productos, diagramas organizativos, etc.
1.5.4
Ciclo del Conocimiento
Se fundamenta en dos pilares: La cadena del conocimiento.
La transformacin del conocimiento tcito y explcito. El conocimiento tcito encauzado de forma correcta, genera conocimiento explcito (ejemplo almacenndolo en una base de datos). El ciclo de vida del conocimiento depende de la distincin entre conocimiento tcito y conocimiento explcito; (ver g. 1.3 de la pg. 15). Ambos tipos de conocimientos son necesarios y se produce una realimentacin continua entre ambos. Comprende la trasformacin de: Datos en Informacin. Informacin en conocimiento. Conocimiento en acciones/decisiones. La experiencia del conocimiento en sabidura.
Figura 1.3: La Cadena del Conocimiento
1.5.5
Caractersticas de la Sociedad del Conocimiento
Es una realidad que la nueva sociedad est basada en el conocimiento ms que en la informacin. El conocimiento es informacin almacenada por las personas. La materia prima es la informacin, el producto es el conocimiento; ver g. 1.4 de la pg. 16.
16
Figura 1.4: La Era de la Informacin
Es dicil predecir cmo ser la nueva sociedad y, por lo cual, difcil de denir con precisin sus caractersticas bsicas. La nueva sociedad plantea nuevos requisitos para las personas, que debern adquirir y mantener una cultura de la informacin. Se puede diferenciar entre una economa de la informacin y una sociedad del conocimiento. Un pas puede entrar en una economa de la informacin mediante un esfuerzo de inversin de equipos y sistemas, o con polticas de fomento de las redes de comunicacin, pero estas caractersticas no incluyen necesariamente el desarrollo de la nueva sociedad que depender ms de la existencia de una cultura de la informacin sucientemente desarrollada. Es preciso fomentar la creacin de redes, equipos y sistemas de informacin y favorecer el ingreso de la poblacin en la cultura de la informacin, a partir de un pacto social. Este nuevo pacto debera ser plural, uniforme y no dirigido, diseado desde la realidad ms cercana de los ciudadanos. Los requisitos de la nueva sociedad plantean la necesidad de realizar un esfuerzo permanente de adaptacin individual y colectiva. La persona instruda (persona con conocimiento) pasar a ser el nuevo protagonista de la sociedad del conocimiento, que aplica su saber a los problemas presentes y ayuda a asentar las bases del futuro.
1.5.6
Gestin del Conocimiento
La Gestin del Conocimiento corresponde al conjunto de actividades desarrolladas para utilizar, compartir, desarrollar y administrar los conocimientos que posee una organizacin y los individuos que en esta trabajan, de manera de que estos sean encaminados hacia la mejor consecucin de sus objetivos. Inicialmente la gestin del conocimiento se centr exclusivamente en el tratamiento del documento como unidad primaria, pero actualmente se han producido grandes avances. Hoy es necesario buscar, seleccionar, analizar y sintetizar crticamente o de manera inteligente y racional la gran cantidad de informacin disponible, con el n de aprovecharla con el mximo rendimiento social o personal. Esta disciplina no es nueva, sino que sus races se remontan a la inteligencia articial, cuyo objetivo nal ha sido la sintetizacin del comportamiento humano mediante ordenadores. Las Bases de Conocimiento son depsitos o almacenes de datos (repositorios) del conocimiento del negocio (funciones, reglas, clculos, informes) totalmente independiente de la plataforma de ejecucin, que mediante tecnologas de inteligencia articial son capaces de deducir, generar y mantener automticamente estructuras normalizadas de bases de datos y programas. La atencin que se est prestando a la gestin del conocimiento est creciendo a una velocidad impresionante. Revistas, diarios de economa y libros publican innumerable teoras y casos sobre gestin del conocimiento y sus tpicos.
1.5.7
Tecnologas de la Gestin del Conocimiento
Las tecnologas de GC deben permitir: Identicar conocimientos necesarios. Identicar dnde y quin tiene el conocimiento o si necesita ser creado. Reunir y capturar el conocimiento encontrado. Resumir y sintetizar la informacin.
18
Distribuir la informacin a distintos niveles. Actualizar, eliminar y modicar el conocimiento obsoleto.
La Gestin del Conocimiento es la mezcla de los siguiente factores:
Personas: Aquellas que producen y aquellas que utilizan conocimiento que ser la base para la accin. Contenido: El ujo de datos, informacin y conocimiento importantes en el xito del negocio. Tecnologa: Se reere a la infraestructura tcnica que se encarga de la captura, almacenamiento y distribucin del contenido a aquellas personas que lo necesitan, en el lugar y momento oportuno.
1.6
Comercio Electrnico en la Sociedad del Conocimiento
A mediados de los noventa se inici la utilizacin de Internet con nes comerciales, en ese momento nadie pudo predecir su impacto en la economa. Se puede armar que Internet no es solo un canal de transmisin o comunicacin de informacin, sino que lleva implcito un cambio cultural importante. Por lo tanto la trascendencia de la economa digital permite hablar de un nuevo marco de actuacin, de una gnesis parametral que traslada el desarrollo organizativo a otro nivel. La economa digital es una economa de cambios importantes, tanto en la forma de entender la gestin dentro y fuera de las empresas como en la ampliacin ms all de los lmites nacionales para el desarrollo de su actividad. Efectivamente, la personalizacin de la relacin con el cliente como la necesidad de ofrecer valor, interactividad y el trato directo e inmediato constituyen elementos diferenciados de primer nivel, siendo uno de los ejemplos ms slidos en la relacin cliente-empresa, el B2C.
1.7. COMERCIO ELECTRNICO BANCARIO
19
1.7
Comercio Electrnico Bancario
1.7.1
Qu es Banca Electrnica?
Los sistemas de banca electrnica posibilitan el acceso a una serie de servicios a partir de una PC con conexin a Internet. La comodidad que brindan es tanta que una vez que el cliente se acostumbra a usarlos le resulta difcil volver atrs. Con ello no slo se ahorra tiempo, sino que tambin la mayor parte de las veces el empleo de los cajeros automticos y la realizacin de transacciones por telfono o mediante el correo son innecesarios. La banca emplea diversos nombres para referirse a estos servicios como PC banking (que resalta el uso de las computadoras personales); home banking (o lo que es lo mismo, banca desde el hogar); electronic banking (porque se trata de una banca electrnica), y el de Internet banking (que se reere directamente al empleo de la red mundial). Este servicio no es nuevo, ya que desde hace aos existen el acceso telefnico (banca telefnica) y los cajeros automticos, que ya ofrecan soluciones tempranas de autoservicio y de gestin de las propias cuentas desde casa. Lo realmente novedoso de la banca digital y su motor de desarrollo y expansin es la oferta de nuevos servicios de valor aadido, slo posibles a travs de Internet u otros medios telemticos. En general, las web de bancos y cajas no son sino una rplica virtual de algunos de los servicios ofrecidos al cliente en la ventanilla, con la comodidad de estar disponibles las 24 horas del da y desde cualquier lugar. De hecho, en cuanto a la accesibilidad, la posibilidad de conectarse al banco mediante un telfono mvil GSM con mensajes SMS o con protocolo WAP para conocer el estado del crdito o si ha llegado la transferencia tan esperada, supone un avance importante hacia la globalizacin del sector bancario. Internet, lneas telefnicas, telefona celular GSM, harn posibles las aplicaciones multimedia en los telfonos celulares, una gran variedad de tecnologas despliegan un inmenso abanico de posibilidades para crear nuevas estrategias que optimicen la relacin de las grandes empresas, entre ellas los bancos y la bolsa de valores, con sus clientes, buscando ofrecer nuevos productos y servicios mejorados y personalizados, tericamente ms baratos.
20
1.7.2
Ventajas
El cliente del banco puede utilizar una computadora y una conexin a Internet para acceder a sus cuentas desde cualquier sitio. Este servicio funciona las 24 horas, todos los das de la semana. La conrmacin de las transacciones se realiza con gran rapidez. El tiempo de procesamiento es similar al empleado por un cajero automtico. La variedad de las transacciones es indudablemente amplia. Se puede desde vericar el balance de una cuenta hasta solicitar un prstamo.
1.7.3
Desventajas
El tiempo inicial que se puede invirtir es signicativo (los diseadores de estos portales trabajan en acortar estos pasos). Primero es necesario proporcionarle ciertos datos al sistema antes de que las operaciones puedan realizarse con xito. Cada vez que se cambie de banco o de programa se tendr que introducir nuevamente los datos al sistema, salvo que el sistema est operando sobre Internet. Este inconveniente parece ir reducindose gracias a la competencia.
1.7.4
Banca a Travs del Telfono Mvil
En una sociedad en la que el nmero de usuarios de telefona mvil supera al de usuarios de Internet e incluso al de abonados de lneas jas, este canal est cobrando cada vez mayor importancia para el xito de los proveedores de servicios bancarios.
Mensajes Cortos Algunos bancos y cajas como Banco Sabadell, Banesto, Banco Santander (Espaa), han lanzado servicios de telebanca mvil, que permiten a los clientes cada da ms exigentes disfrutar de servicios de valor aadido adems de los mismos servicios de telebanca ja convencionales. Los usuarios equipados con un telfono mvil GSM capaz de recibir y enviar mensajes cortos de texto (SMS), pueden acceder cmodamente desde cualquier lugar donde se encuentren y a cualquier hora del da o de la noche a una serie de funciones como:
21
Consulta de informacin bancaria: listado de cuentas, saldos y movimientos, gasto acumulado de su tarjeta de crdito, etc. La peticin de informacin se puede realizar de dos maneras: Con mensajes de texto: Se enva un mensaje de texto al nmero del banco o caja correspondiente y se recibe otro mensaje de texto con la informacin solicitada. Con llamada telefnica: Se llama al nmero del banco o caja correspondiente (desde un telfono jo o desde su mvil), se solicita la recepcin de la informacin y la entidad nanciera. Llega la respuesta en un mensaje de texto. Programacin para la recepcin automtica de informacin bancaria de inters para el cliente. Programacin para la recepcin automtica de alarmas cuando los saldos de sus cuentas rebasen a la alza o a la baja las cantidades que el cliente determine. Este servicio de telebanca GSM no lleva asociados gastos de activacin ni cuotas mensuales adicionales. El precio de las llamadas y de los mensajes es el habitual, sujeto a las variaciones horarias, que deber consultar con la operadora telefnica. Tan slo se necesita un terminal GSM con capacidad de recepcin y envo de mensajes cortos, caracterstica ofrecida por todas las operadoras y soportada en la prctica totalidad de modelos. Internet en el Mvil Sin embargo, la tecnologa de mensajes SMS fue reemplazada. El siguiente paso en la evolucin de la telefona celular hace uso de la tecnologa WAP, que permite que se pueda acceder a los contenidos de Internet desde un telfono mvil en un navegador WAP. Gracias a sta tecnologa, los bancos podrn ofrecer a sus clientes servicios nancieros inalmbricos seguros y altamente personalizados. El cliente obtiene todas las ventajas del acceso a servicios de banca en Internet, pero sin necesidad de disponer de una conexin ja ni de un ordenador, por lo que puede accederlos en el tren o en el coche, mientras espera
22
en el aeropuerto o pasea por la montaa. No se requieren conocimientos de informtica ni hay que congurar complicados programas. La navegacin con el mvil es intuitiva y el software necesario ya est instalado de serie en el telfono. Por su parte, los bancos y cajas pueden ofrecer servicios totalmente nuevos y rentables, como la presentacin y pago de facturas a travs del telfono mvil, consulta instantnea a mercados burstiles y compra-venta de acciones, adems de todos los servicios disponibles para Internet, sin gastos adicionales importantes para las entidades, puesto que WAP aprovecha la inversin ya realizada en soluciones bancarias por Internet. El nico lmite viene impuesto por la imaginacin de los bancos y cajas a la hora de ofertar servicios novedosos y especialmente atractivos para aumentar sus ingresos y la delidad de sus clientes. Con la aparicin de los mviles de tercera generacin, haciendo uso de la tecnologa UMTS (Universal Mobile Telecommunications Standard), es posible velocidades de transmisin de megabits por segundo, abriendo la puerta a aplicaciones multimedia de gran ancho de banda. Los telfonos vienen cada vez equipados con pantallas ms grandes de mayor resolucin y harn del ordenador porttil una herramienta de la prehistoria informtica. Un telfono mvil actual puede ejecutar aplicaciones como agenda, juegos o cualquier otra que emplee la tecnologa Java J2ME (Java para mviles), adems de captar imgenes jas o en movimiento, con conexin a Internet y caractersticas bsicas de reconocimiento de voz. Hoy en da los proveedores de servicios bancarios estn desarrollando aplicaciones que corren en el dispositivo mvil y tienen conexin a Internet, permitiendo el acceso a la informacin que reside en las aplicaciones centrales de los bancos. Todo gracias a las tecnologas J2ME y GPRS (Servicio de Radio de Paquetes Generales) que permite tarifar al usuario por volumen de informacin transferida y no por tiempo de conexin o tiempo de aire, lo cual reduce costos para los clientes.
1.7.5
Seguridad en Operaciones Electrnicas
Los mecanismos de seguridad implantados en la mayora de bancos y cajas no son completamente satisfactorios para una actividad como la bancaria, en la que el usuario no slo consulta saldos y movimientos de sus cuentas y tarjetas, sino que tambin puede efectuar transferencias y traspasos, as como comprar
23
y vender acciones. No se puede admitir que los bancos se tarden mucho ms en la implantacin de certicados digitales como solucin para la identicacin bilateral de las partes implicadas en las transacciones a travs de Internet. Queda por ver hacia qu tipo de soluciones tecnolgicas se caminar en otros medios de acceso que irn volvindose paulatinamente ms populares como la TV interactiva digital o el telfono celular con acceso a Internet. Un banco en Internet se presenta a sus clientes a travs de una Web. Esta es la cara y el interfaz a travs del cual stos interactan con sus activos, usando para ello un simple navegador. Como primera medida, la mquina donde dicho WebSite est situado no es la mquina donde estn los datos de los usuarios. Es el aplicativo Web o WAP (si se trata de telefona celular) el que, cuando es necesario, accede a la verdadera mquina o Host en la que se encuentran los datos reales de los usuarios. El muro de fuego: Existe un primer nivel de seguridad fsica que protege los datos almacenados en el banco. La red a la que pertenece la mquina donde se halla ubicada este interfaz o Web del banco, est protegida por lo que se conoce como un muro de fuego (rewall en ingls). Esto quiere decir que hay una barrera ante ella que va a rechazar sistemticamente todo intento de conexin no controlada, basndose en una poltica de reglas que se establecen en dicho rewall. Es decir, slo se admitirn conexiones a ciertos puertos, de determinadas procedencias, con determinados protocolos, etc. Los principales elementos en los que se basa el sistema de seguridad de la banca electrnica son: Las claves: Clave personal, PYN o clave secreta. Cuando accedemos al banco en Internet, lo primero que se pedir es un cdigo de usuario y una contrasea. Al tercer intento consecutivo errneo (incluso si cada uno de los intentos va espaciado en el tiempo) el sistema expulsa al tenedor de la tarjeta, debiendo identicarse nuevamente ante el banco para reactivarla. Identicacin operativa. Para todas aquellas operaciones que vayan ms all de las meras consultas, como por ejemplo realizar una transferencia, el sistema va a solicitar una segunda contrasea con el n que le se rectique la decisin. Se ofrece la posibilidad de cambiar esta clave siempre que se desee. No obstante, el uso de claves puede no ser todo lo seguro que es deseable en un negocio de estas caractersticas, ya que si alguien con malas intenciones
24
la llega a conocer, por el motivo que sea, podra hacerse pasar perfectamente por alguien ms. El certicado digital: Un certicado es un documento electrnico, emitido por una Entidad Certicadora, que identica de forma segura al poseedor del mismo, evitando la suplantacin de identidad por terceros. Es el componente esencial de la rma electrnica. Es una herramienta que garantiza la identidad de los participantes en una transaccin que requiera altos niveles de seguridad. Mediante l se demuestra a la mquina que recibe la conexin que se es quien realmente dice ser. Esto se conoce con el nombre de identicacin. El servidor Web del banco en Internet tambin es poseedor de su correspondiente certicado digital y demuestra con ello que el Banco X es realmente el Banco X y no se est enviando los datos a un impostor que se ha metido por medio y pretende suplantarle con malas intenciones, aprovechndose de que no se puede ver dnde est realmente llegando a la conexin. Servidores seguros: El servidor Web del banco es un servidor seguro, esto es, establece una conexin con el cliente de manera que la informacin circula a travs de Internet codicada, mediante algoritmos, lo que asegura que sea inteligible slo para el servidor y el navegador que accede al Web, entendindose ambos mediante un protocolo que se ha dado en llamar SSL. De este modo, ninguna persona externa, que eventualmente estuviera espiando ese trasiego de informacin, podr descifrar los datos condenciales mientras viajan hacia y desde la red del banco. Un servidor seguro proporciona tres elementos de seguridad: Autenticidad. Se puede tener la seguridad de que los datos se estn enviando al autntico servidor del banco, al que le ha sido expedido el correspondiente certicado digital. De igual forma, a travs del certicado digital personal, el cliente se puede identicar ante el banco durante las transacciones delicadas. Condencialidad. Los datos, en el caso de ser capturados por alguien, no podrn ser interpretados ya que viajan de modo codicado. Integridad. Los datos llegan al servidor del banco sin sufrir alteracin alguna por el camino, ya que si sta se produce, por mnima que sea, el protocolo SSL se da cuenta.
Captulo 2
El Mundo Mvil
2.1 Evolucin
En 1983, aparecieron en el mercado los primeros telfonos celulares que podan llevarse a todos lados. Desde esos comienzos, los telfonos celulares o mviles han sido vistos como la comunicacin del futuro. Se trataba de un equipo que permita permanecer comunicado en todo momento y en todo lugar, con amigos, familiares y con la empresa. Adems cambiaba radicalmente el modo de comunicarse: ya la comunicacin no se realizaba con un lugar, sino directamente con una persona. En seguida fue adoptado por empresarios, corredores de bolsa, transportistas, hasta llegar a la poca actual donde prcticamente cada integrante de una familia puede llegar a tener su propio equipo celular. La primera generacin de telfonos celulares comenz en 1979 y se trataba de conexiones estrictamente de voz y analgicas. Estas conexiones no tenan seguridad y generaban muchos conictos en las comunicaciones. La tecnologa que ha permitido esta comunicacin se llam AMPS (Advanced Mobile Phone System) y todava sigue siendo utilizada en lugares rurales y ciudades alejadas de Amrica. Hacia 1990 la tecnologa evolucion a lo que se denomin 2G (Segunda Generacin) o PCS (Personal Communication Service). Esta etapa se caracteriz por ser digital y utilizar algoritmos de compresin y seguridad ms sosticados en las comunicaciones. Sigue siendo la tecnologa ms utilizada actualmente 25
26
CAPTULO 2. EL MUNDO MVIL
en las comunicaciones mviles del mundo. En esta etapa, se encuentran predominantemente 3 tipos de tecnologas compitiendo en el mercado: CDMA, TDMA y GSM . GSM es la tecnologa que ms ha evolucionado en sta generacin y por ello, actualmente, posee ms del 70% del mercado mundial. Tcnicamente es un derivado de la tecnologa TDMA [8]. El sistema 2G trajo consigo nuevas aplicaciones de datos sobre la red celular: fax, mdem, SMS; aunque rpidamente su capacidad de ancho de banda qued limitada. Por esta limitacin de la segunda generacin (9,6 Kbps) y, al darse cuenta que la prxima generacin (la 3G) tardara unos cuantos aos ms en venir, los fabricantes crearon un intermedio llamado 2.5G que permita conexiones de datos ms veloces, como lo es el protocolo GPRS que permite velocidades de 64 Kbps o superiores. En pocos pases del mundo ya est instalada la 3G (Tercera Generacin) de telefona celular. Esta tecnologa tiene un mayor ancho de banda en las transmisiones de datos que permite, por ejemplo, video streaming, videoconferencias y otras aplicaciones de alta performance. Las velocidades son superiores a los 144 Kbps. Tres de las tecnologas ms importantes en 3G al momento son: W-CDMA, TD-SCDMA y CDMA2000. Las velocidades de transmisin de estas tecnologas van de 384 Kbps a 4 Mbps, ya superan a conexiones de banda ancha hogareas en ADSL que estn entre 1 Mbp y 1 Gbps. Se debe recordar que estas velocidades se logran en forma inalmbrica y en constante movimiento del equipo (a mayor velocidad de movimiento, menor ancho de banda). Tambin ya se habla de una 4G que comenzara a implementarse hacia 2010 y que traera aparejado velocidades de 100 Mbps, equiparables con las velocidades actuales de una red local.
2.2
Telfonos Mviles de Primera Generacin
El sistema ms antiguo fue el de los radiotelfonos mviles que se utilizaban de forma espordica para comunicacin martima y militar durante las primeras dcadas del siglo XX. En 1946 se construy el primer sistema de telfonos instalado en autos. Este sistema utilizaba un solo transmisor grande colocado en la parte superior de un edicio y tena un slo canal que serva para enviar
2.2. TELFONOS MVILES DE PRIMERA GENERACIN
27
y recibir. Para hablar, el usuario tena que oprimir un botn que habilitaba el transmisor e inhabilitaba el receptor. Tales sistemas, conocidos como sistemas de oprimir para hablar, se instalaron en algunas ciudades desde nales de la dcada de 1950. En la dcada del 60 se instal el IMTS (Sistema Mejorado de Telefona Mvil), tambin utilizaba un trasmisor de alta potencia (200 watts), en la cima de una colina, pero tena dos frecuencias, una para enviar y la otra para recibir, por lo que el botn de oprimir para hablar no era necesario. IMTS manejaba 23 canales dispersos desde 150 hasta 450 Mhz. Debido al nmero tan pequeo de canales, los usuarios a veces tenan que esperar bastante tiempo antes de obtener el tono de marcar.
2.2.1
Sistema Avanzado de Telefona Mvil
La telefona mvil terrestre utiliza estaciones terrestres. stas se encargan de monitorizar la posicin de cada terminal encendida, pasar el control de una llamada en curso a otra estacin, enviar una llamada a un terminal. Cada estacin tiene un rea de cobertura, zona dentro de la cul la comunicacin entre un terminal y sta se puede hacer en buenas condiciones. Las zonas de cobertura tericamente son hexgonos regulares o celdas. En la prctica, toman distintas formas, debido a la presencia de obstculos y a la orografa cambiante de la celda como se puede apreciar en la g. 2.1 de la pg. 28. Adems se solapan unas con otras. Es por esto, que cuando un mvil est cerca del lmite entre dos celdas, puede pasar de una a otra, en funcin de cul de las dos le ofrezca ms nivel de seal, y esto puede suceder incluso durante el transcurso de una llamada sin que se perciba nada. En todos los sistemas de telefona mvil , una regin geogrca se divide en celdas, razn por la cul los dispositivos se conocen como telfonos celulares. En AMPS (Sistema Avanzado de Telefona Mvil, inventado por los laboratorios Bell e instalado por primera vez en los Estados Unidos) las celdas normalmente tienen de 10 a 20 km de dimetro; en los sistemas digitales. Cada celda utiliza un conjunto de frecuencias que no es utilizada por ninguna de sus vecinas. La idea clave que conere a los sistemas celulares con ms capacidad que todos lo sistemas anteriores es el uso de celdas relativamente pequeas y la
28
Figura 2.1: Sistema Telefnico Mvil reutilizacin de las frecuencias de transmisin en celdas cercanas (pero no adyacentes). Un sistema IMTS de 100 km de alcance puede tener una llamada en cada frecuencia, un sistema AMPS podra tener 100 celdas de 10 km en la misma rea con 5 a 10 llamadas en cada frecuencia en celdas muy separadas. El diseo celular incrementa la capacidad del sistema en un orden de magnitud conforme las celdas se hacen ms pequeas en su rea de cobertura. Adems, al ser las celdas ms pequeas se necesita menor potencia, lo cual conduce a dispositivos ms pequeos y econmicos. En el centro de cada celda se encuentra una estacin base a la cul transmiten todos los telfonos de la celda. La estacin base consiste en una computadora y un transmisor / receptor conectado a una antena. En un sistema pequeo, todas las estaciones base se conectan a un mismo dispositivo llamado MTSO (Ocina de Telefona Mvil) o MSC (Centro de Conmutacin Mvil). En un sistema grande pueden ser necesarias varias MTSOs, las cuales se conectan a una MTSO de segundo nivel y as sucesivamente. En cualquier instante cada telfono mvil est en una celda especca y bajo el control de la estacin base de esa celda. Cuando un telfono mvil sale de una celda, sta le cede el control a otra estacin circundante. Cada estacin trabaja con un rango de frecuencias, que delimita el nmero mximo de llamadas simultneas que puede soportar, puesto que a cada lla-
2.3. TELFONOS MVILES DE SEGUNDA GENERACIN
29
mada se le asigna un par de frecuencias diferentes: una para cada sentido de la comunicacin. Esto se denomina FDM, o multiplexacin por divisin en la frecuencia. Las celdas colindantes no pueden utilizar las mismas frecuencias, para que no se produzcan interferencias. Cada telfono mvil en AMPS tiene un nmero de serie de 32 bits y un nmero telefnico de 10 dgitos en su PROM. Cuando un telfono se enciende, examina una lista preprogramada de 21 canales de control para encontrar la seal ms potente. Luego el telfono difunde su nmero de serie de 32 bits y su nmero de telfono de 34 bits [17].
2.3
Telfonos Mviles de Segunda Generacin
La primera generacin de telfonos mviles fue analgica; la segunda fue digital. De igual manera que en la primera generacin no hubo una estandarizacin mundial de tecnologas, tampoco hubo en la segunda generacin. Existen cuatro sistemas en uso: D-AMPS; GSM; CDMA y PDC.
2.3.1
D-AMPS - El Sistema Avanzado de Telefona Mvil Digital
D-AMPS se describe en el estndar internacional IS-54 y su sucesor IS-136. D-AMPS se dise con mucho cuidado para que pudiera coexistir con AMPS, a n de que tanto telfonos mviles de primera generacin como los de segunda pudieran funcionar de manera simultnea en la misma celda. D-AMPS utiliza los mismos canales de 30 KHz que AMPS y a las mismas frecuencias a n de que un canal pueda ser analgico y los adyacentes digitales. Cuando D-AMPS se introdujo como un servicio, se puso disponible una nueva banda de frecuencia para manejar la carga esperada creciente. Los canales ascendentes estaban en el rango de 1850-1910 MHz y los canales descendentes correspondientes estaban en el rango de 1930-1990 MHz. En un telfono mvil D-AMPS, la seal de voz capturada por el micrfono se digitaliza y se comprime. La compresin se crea mediante un circuito llamado vocoder y se realiza en el telfono en lugar de en la estacin base o
30
la central, para reducir el nmero de bits que se envan a travs del enlace de aire. Con la telefona ja, no hay benecio de hacer que la compresin se realice en el telfono, debido a que la reduccin del traco en el circuito local no incrementa la capacidad del sistema. Gracias a que la digitalizacin y compresin se realiza en el telfono, tres usuarios pueden compartir un solo par de frecuencias que utilizan la multiplexin por divisin de tiempo. Cada par de frecuencias maneja 25 tramas / seg de 40 mseg cada uno como se puede ver en la g. 2.2 de la pg. 30. Adems cada trama se divide en seis ranuras de tiempo de 6.67 mseg cada una [17].
Figura 2.2: Un canal D-AMPS con 3 y 6 usuarios. La estructura de control de D-AMPS es bastante complicada. En resumen, se utilizan seis canales de control: conguracin del sistema, control en tiempo real, y en tiempo no real, localizacin, respuesta de acceso y mensajes cortos. Cuando se enciende un telfono mvil, hace contacto con la estacin base para anunciarse y despus escucha un canal de control para llamadas entrantes. La MTSO informa a la base domstica del usuario dnde est, y las llamadas se pueden enrutar en forma correcta.
2.3.2
GSM (Sistema Global Para Comunicaciones Mviles)
GSM es similar a D-AMPS. Los dos son sistemas celulares. En ambos se utiliza la multiplexacin por divisin de frecuencia, en el que cada dispositivo mvil transmite en una frecuencia y recibe en una frecuencia mayor (80 MHz ms arriba para D-AMPS, 55 MHz ms arriba para GSM).
2.3. TELFONOS MVILES DE SEGUNDA GENERACIN
31
Adem, en los dos sistemas, se utiliza multiplexin por divisin de tiempo para dividir un solo par de frecuencias en ranuras de tiempo compartidas por mltiples telfonos mviles. Sin embargo los canales GSM son mucho ms anchos que los AMPS (200 KHz en comparacin de 30 KHz) y almacenan relativamente pocos usuarios (8 en comparacin con 3), lo que le da a GSM una tasa de datos mucho ms grande por usuario que D-AMPS. Cada banda de frecuencia tiene una longitud de 200 KHz. Un sistema GSM tiene 124 pares de canales simplex. Cada uno de ellos tiene una longitud de 200 KHz y maneja ocho conexiones por separado, mediante la multiplexin por divisin de tiempo. En cada celda se pueden manejar hasta 992 canales, aunque muchos de ellos no estn disponibles, para evitar conictos de frecuencias con las celdas vecinas. La transmisin y la recepcin no suceden en la misma ranura de tiempo porque los radios GSM no pueden transmitir y recibir al mismo tiempo. Algunas de estas ranuras se utilizan para almacenar algunos canales de control utilizados para manejar el sistema. El canal de control de difusin es ujo continuo de salida de la estacin base que contiene la identidad de la estacin base, as como el estado del canal. Todas las estaciones mviles supervisan su fuerza de seal para ver cundo se han movido a una nueva celda. El canal dedicado de control se utiliza para actualizacin de localizacin, registro y establecimiento de llamada. En particular, cada estacin base mantiene una base de datos de la estaciones mviles actualmente bajo su jurisdiccin. La informacin necesaria para mantener esta base de datos se enva en el canal dedicado de control. Hay un canal de control comn, que se divide en tres subcanales lgicos. El primero de estos subcanales es el canal de localizacin, que la estacin base utiliza para anunciar llamadas entrantes. Cada estacin mvil los supervisa continuamente en busca de llamadas. El segundo es el canal de acceso aleatorio, que permite que los usuarios soliciten una ranura del canal dedicado de control. Si dos peticiones chocan, se distorsionan y se tienen que volver a realizar ms tarde. El tercer subcanal es el canal de otorgamiento de acceso [17].
32
2.3.3
CDMA (Acceso Mltiple por Divisin de Cdigo)
Se ve como la mejor solucin tcnica existente y como la base para los sistemas mviles de la tercera generacin. Tambin se utiliza ampliamente en los Estados Unidos en los sistemas mviles de segunda generacin y compite frente a D-AMPS. CDMA es completamente diferente de AMPS, D-AMPS y GSM. En lugar de dividir el rango de frecuencia permitida en algunos cientos de canales estrechos, CDMA permite que cada estacin transmita todo el tiempo a travs de todo el espectro de frecuencia. CDMA no supone que las tramas que colisionan son totalmente distorsionadas. Asume que se agregan mltiples seales en forma lineal. Se considera la siguiente analoga: Una sala de espera de un aeropuerto con muchas parejas de personas conversando. TDM (multiplexin por divisin de tiempo) se compara con todas las personas que estn en medio de la sala pero que esperan su turno para hablar. FDM (multiplexin por divisin de frecuencias) se compara con el hecho de que todas las personas que estn en grupos separados ampliamente y cada grupo tiene su propia conversacin al mismo tiempo; aunque de manera independiente, que los otros. CDMA se compara con el hecho de que todas las personas estn en medio de la sala hablando al mismo tiempo, pero cada pareja hablando en un lenguaje diferente, la persona que habla francs se concentra con el francs, rechazando todo lo que no se francs como si hubiera ruido. Por lo tanto la clave de CDMA es tener la capacidad de extraer la seal deseada y rechazar todo lo dems como ruido aleatorio. A cada estacin se le asigna un cdigo nico de m bits llamado secuencia de chip. Cada estacin utiliza completamente el megahertzio, por lo que la tasa de chips es de 1 megachip por segundo. Cada estacin tiene su propia y nica secuencia de bits. Funciona en una banda de 1.25 MHz, pero maneja muchos ms usuarios en esa banda que cualquiera de los otros sistemas.
2.4. TELFONOS MVILES DE TERCERA GENERACIN
33
2.4
Telfonos Mviles de Tercera Generacin
Algunos factores que estn impulsando a la industria: El trco de datos ya exede el trco de voz en la red ja y est creciendo de manera exponencial. La industria telefnica de entretenimiento y de cmputo han adoptado formatos digitales y estn convergiendo rpidamente. La telefona mvil de tercera generacin trata de encontrar un dispositivo que sea portable y ligero que acte como telfono, reproductor de CDs, reproductor de DVDs, terminal de correo electrnico, interfaz para Web, mquina de juegos, procesador de texto, etc. La ITU trat de concretar esto y cre un diseo para alcanzarlo, llamado IMT-2000 (Telecomunicaciones Mviles Internacionales), pero no cumpli con nada de lo anterior. Luego, se realizaron varias propuestas, y despus de varias selecciones, aparecieron las dos principales. La primera, W-CDMA (CDMA de Banda Ancha), fue propuesta por Ericsson. Este sistema utiliza espectro disperso de secuencia directa. Se ejecuta en una banda ancha de 5 MHz y se ha diseado para interactuar con redes GSM aunque no tiene compatibilidad hacia atrs con GSM. Tiene la propiedad de que el invocador puede salir de una celda W-CDMA y entrar a una celda GSM sin perder la llamada. Este sistema se llam UMTS (Sistema Universal de Telecomunicaciones Mviles). El CDMA 2000, propuesto por Qualcomm, es un diseo de espectro disperso de secuencia directa, bsicamente una extensin de IS-95 y es compatible hacia atrs con l. Utiliza un ancho de banda de 5 MHz, pero no ha sido diseado para interactuar con GSM y no puede entregar llamadas a una celda GSM (ni a una celda D-AMPS ).
34
Algunas de la diferencias tcnicas con respecto a W-CDMA son las siguientes: una tasa de chip diferente, un tiempo de trama diferente, se utiliza un espectro diferente y la sincronizacin de tiempo se realiza de una manera diferente.
2.4.1
EDGE (Tasa de Datos Mejorada para la Evolucin del GSM)
Mientras se espera la venida del 3G, algunos fabricantes dieron un paso intermedio que se llama 2.5G. Uno de los sistemas es EDGE. Es simplemente GSM con ms bits por baudio. El problema es que ms bits por baudio signican ms errores por baudio, por lo que EDGE tiene nueve esquemas diferentes para modulacin y correccin de errores, que dieren en la cantidad de ancho de banda que se dedica a arreglar los errores introducidos por la velocidad ms alta [17].
2.4.2
GPRS (Servicio de Radio de Paquetes Generales)
Es una red de paquetes superpuestos encima de D-AMPS o GSM. Permite que las estaciones mviles enven y reciban paquetes IP (protocolo de Internet) en una celda que se ejecuta en un sistema de voz. Cuando GPRS est en operacin, algunas ranuras de tiempo en algunas frecuencias se reservan para el trco de paquetes. La estacin base puede manejar de manera dinmica el nmero y la ubicacin de las ranuras de tiempo, dependiendo de la tasa de voz sobre el trco de datos de la celda. Las ranuras de tiempo disponibles se dividen en varios canales lgicos utilizados para propsitos diferentes. La estacin base determina qu canales lgicos se asignan en qu ranuras de tiempo. Un canal lgico se utiliza para bajar paquetes de la estacin base a algunas estaciones mviles, y cada paquete indica a quin va destinado. Para enviar un paquete IP, una estacin mvil solicita una o ms ranuras
2.5. SERVICIOS ADICIONALES DE LAS EMPRESAS TELEFNICAS35
de tiempo enviando una peticin a la estacin base. Si la peticin llega sin dao alguno, la estacin base anuncia la frecuencia y las ranuras de tiempo asignadas al mvil para enviar el paquete. Una vez que el paquete llega a la estacin base, se transere a Internet mediante una conexin de cable.
2.5
Servicios Adicionales de las Empresas Telefnicas
Los equipos celulares fueron pensados para transmitir voz. Lo primero que se piensa cuando se habla de telfonos mviles es en la comunicacin vocal, en comunicacin a travs de la voz de un punto a otro. Sin embargo, poco a poco, se fue conociendo cmo las empresas que provean el servicio de telefona celular han ido incorporando servicios adicionales a lo largo del tiempo de vida de esta tecnologa y, muchos de esos servicios se escapan del estricto uso de la voz para la comunicacin. Desde mensajera de texto, melodas personalizadas, hasta conexin a Internet. En los siguientes apartados se ver con detalle los servicios que los telfonos celulares actuales pueden ofrecer.
2.5.1
Servicios Analgicos
En esta categora ingresan todos los servicios adicionales que no requieren un equipo con capacidades digitales. Ni siquiera hace falta un telfono con pantalla. Desde los viejos equipos Motorola, hasta los primeros modelos de telfonos Motorota Startac (la lnea 3000), las empresas de telefona celular han provisto de servicios adicionales al uso bsico de la lnea. Estos servicios funcionaban a travs de la red de voz, es decir la red analgica que ya estaba instaurada. Entre ellos, se puede mencionar contestador automtico, alarmas, llamadas en conferencia, y servicios de informacin que se provean (y todava se proveen) comunicndose a un nmero particular que no perteneca a la red ja de telefona.
2.5.2
Recepcin y Envo de Mensajes de Texto
Este servicio comenz a funcionar en los aos 90 y requera poseer equipos con la capacidad de recepcin de mensajes de texto en la pantalla del telfono. Por
36
ello, requieren equipos con pantalla alfanumrica y seal digital. Las empresas permiten el envo de mensajes a un equipo celular a travs de sus sitios web, a travs de una casilla de e-mail o desde otros equipos celulares. El mensaje viaja por la red digital de la empresa y llega al equipo celular donde podr ser visualizado completamente en pantalla. Estos mensajes tienen generalmente una longitud de 150 caracteres y son conocidos tambin como SMS (Short Message System, Sistema de Mensajes Cortos). El mensaje es enviado al destinatario instantneamente, salvo que el equipo receptor no est encendido o est fuera del rea de cobertura. En este caso, el mensaje queda latente, generalmente por unos das, para ser enviado en el momento de restauracin de la seal. Con la gran aceptacin que tuvo el Sistema de Mensajes Cortos comenzaron a aparecer equipos con la posibilidad, no slo de recibir mensajes, sino de emitirlos y as poder enviar mensajes a otros telfonos, en un principio, entre dos telfonos mviles que utilizaban una misma empresa proveedora. Los mensajes son transferidos al nodo central de la empresa y de ah dirigidos al equipo destino. Es decir, la comunicacin no se realiza telfono a telfono directamente. A travs de una pasarela, es comn la posibilidad de enviar mensajes, no a otro telfono, sino a una direccin de e-mail. Estas pasarelas son simplemente nmeros de destino donde el telfono enva el mensaje y este equipo receptor (provisto por el proveedor del servicio) se encarga de redireccionar el mensaje va Internet utilizando el protocolo SMTP. Con el tiempo este servicio se ampli y las empresas comenzaron a interconectar sus redes de mensajera corta y ya prcticamente, es posible enviar y recibir mensajes cortos desde cualquier empresa proveedora a cualquier otra dentro del mismo pas y, a veces, a otros pases.
2.5.3
Servicios de Informacin
Basados en el Servicio de Mensajera, las empresas proveedoras de la telefona celular comenzaron a ofrecer servicios adicionales de informacin por ese medio. Por ejemplo, es posible suscribirse a recibir informacin sobre: noticias, deportes, cotizaciones nancieras, estados bancarios y otra informacin que ser enviada a todos los equipos celulares suscriptos.
Otra modalidad es el envo de informacin mediante SMS bajo demanda. Este servicio permite enviar cierto mensaje a un nmero predeterminado y recibir a cambio alguna informacin de inters o solicitada. Estos servicios son provistos por las mismas empresas o por terceros con convenios especiales. Tambin han surgido salas de chat con la posibilidad de enviar y recibir mensajes a grupos de personas, comunicacin con mensajeros instantneos (como ser el Microsoft Messenger o el Yahoo! Messenger ) y juegos interactivos a travs del Servicio de Mensajera. Algunos de estos servicios se ofrecen en forma gratuita [8].
2.5.4
Mensajes Multimedia
Los equipos mviles evolucionan a grandes pasos y debido a esto se pueden ver equipos con capacidades multimedia. Por eso, se ha desarrollado una extensin al servicio SMS, llamado MMS (Multimedia Messaging System). Este sistema de intercambio de mensajes permite, adems de texto (ampliado a 900 caracteres), adjuntar cualquier otro tipo de archivo digital, como ser fotos, imgenes animadas, sonidos o videos. El equipo receptor deber soportar tambin esta tecnologa y estar correctamente congurado en el equipo. Esta tecnologa generalmente trabaja enviando un mensaje de texto al telfono receptor indicando una URL (direccin de la red) donde el equipo podr descargar el contenido completo del mensaje. Estos mensajes no son enviados en forma completa al equipo receptor. Es por eso por lo que, si el usuario no quiere recibir este tipo de mensajes puede congurar su equipo para no recoger automticamente sus Mensajes Multimedia.
2.5.5
Juegos y Aplicaciones
Es una caracterstica adicional provista por el fabricante del equipo. Gracias tambin al gran uso del SMS, los telfonos comenzaron a ampliar el tamao visual de sus pantallas. De esta forma, algunos equipos comenzaron a incluir algunos pequeos juegos en sus modelos de celulares, como se puede apreciar en la g. 2.3 de la pg. 38. Tampoco las aplicaciones se haban quedado atrs y ya comenzaban a aparecer en los equipos aplicaciones como calculadoras, agendas, calendarios,
38
Figura 2.3: Algunos Juegos Conocidos. conversores de medidas y monedas y otros aplicativos que se consideraban tiles para el usuario. De esta forma comenzaba una nueva era en los equipos celulares. Ya no se los vea como un mero aparato comunicacional, sino como una microcomputadora. Comenzaron a aprovecharse capacidades de procesamiento (mnimas, pero existentes) y, cuando esta capacidad de proceso se junta con la capacidad de conectividad de la red celular, se produce la revolucin del software mvil [8].
2.5.6
Internet Mvil
Internet Mvil es la capacidad que tiene un equipo celular de navegar por la red Internet. Si bien, con ciertas limitaciones, es posible leer e-mails, noticias y ciertos sitios de Internet. La tecnologa que permite esta navegacin por Internet es la llamada WAP (Wireless Application Protocol) que hace de interfaz o pasarela entre la red Internet y el protocolo HTTP con el que se reciben las pginas web y la red
celular. Este protocolo tena una limitacin y es que no soportaban pginas HTML como s lo soportan los navegadores para equipos estndar de computacin, como Internet Explorer, Netscape u Opera. Los navegadores WAP de los equipos celulares soportan solamente pginas en formato WML, que es una versin reducida de HTML y adaptada a las necesidades de contenido de un telfono celular. El Fracaso y la Vuelta de Internet Mvil El fracaso se debi a algunas razones, entre ellas: Los proveedores de contenido no supieron adaptarse a las necesidades de un navegante mvil. Slo ofrecan una versin reducida de su mismo contenido web. Las empresas de telefona mvil facturaron este servicio por tiempo de aire consumido, lo que claramente era una bomba de tiempo para el usuario que se encontraba navegando, o intentndolo. La experiencia de navegar por un celular ha sido muy frustrante para muchos usuarios. Una vez que se lograba congurar correctamente el equipo, la navegabilidad de los equipos que, originalmente no estaban preparados para tal n (como ser ausencia de teclas, pantallas muy chicas), hicieron que los usuarios dejaran de lado esta tecnologa. No existieron gran cantidad de equipos con la capacidad de navegador WAP. La vuelta de Internet Mvil se debi a la aparicin de nuevas tecnologas que se ofrecen actualmente (como ser GSM, va GPRS o CDMA2000x ), ahora es posible tarifar al usuario por informacin transferida y no por tiempo de aire, adicionando que los equipos tienen pantallas ms grandes y con altas resoluciones de colores y sistemas de navegacin e introduccin de texto ms cmodos [8]. Adems de esta mejora tecnolgica, el mercado ha ido evolucionando y ya prcticamente todo equipo nuevo tiene navegador WAP y poco a poco, comenzaron a surgir nuevos servicios WAP tiles para los usuarios, entre ellos:
40
Clima, Informacin Geogrca, Guas Telefnicas para Turistas, Mapas de Calles y otra informacin que puede ser de suma utilidad para un usuario que se encuentra fuera del alcance de una PC con conexin a la web.
2.6
2.6.1
WAP
Introduccin a WAP
Wireless Application Protocol o WAP (protocolo de aplicaciones inalmbricas) es un estndar abierto internacional para aplicaciones que utilizan las comunicaciones inalmbricas, por ejemplo acceso a servicios de Internet desde un telfono mvil. Se trata de la especicacin de un entorno de aplicacin y de un conjunto de protocolos de comunicaciones para normalizar el modo en que los dispositivos inalmbricos, se pueden utilizar para acceder a correo electrnico, grupo de noticias y otro tipo de aplicaciones disponibles desde Internet. El organismo que se encarga de desarrollar el estndar WAP fue originalmente el WAP Forum, fundado por cuatro empresas del sector de las comunicaciones mviles, Sony-Ericsson, Nokia, Motorola y Openwave (originalmente Unwired Planet). Desde 2002 el WAP Forum es parte de la Open Mobile Alliance (OMA), consorcio que se ocupa de la denicin de diversas normas relacionadas con las comunicaciones mviles, entre ellas las normas WAP. La telefona mvil e Internet se combinaron y ahora se puede tener Internet en un terminal mvil (telfono celular) combinar la capacidad de Internet en un entorno donde el usuario puede moverse y disponer conexin las 24 horas del da, en cualquier lugar. De esta idea surge WAP, la arquitectura de protocolos TCP/IP (protocolo de Internet) presenta una serie de dicultades al momento de trabajar en entornos inalmbricos mviles. Estos factores unidos al ancho de bandas limitados a la telefona mvil condicionan a los fabricantes mundiales a constituir el consorcio WAP Forum para desarrollar una nueva pila de protocolos adecuada a los entornos inalmbricos con usuarios en movimientos [7]. Aunque WAP fue diseado para utilizar cualquier tecnologa mvil existente, la ms utilizada por WAP es GSM. GSM es una tecnologa digital de acceso areo que incluye mecanismos de cifrado de comunicacin entre terminal
2.6. WAP
41
mvil y la estacin base.
2.6.2
Motivacin
Los terminales mviles son ms potentes y livianos cada vez, permitiendo que la comunicacin sea cada vez ms ecaz. Su gran nmero y sus capacidades hacen muy interesante para los proveedores de servicios y contenidos disponer de un entorno normalizado que permita ofrecer sus servicios a los usuarios de las redes mviles. WAP dene un entorno de aplicacin y una pila de protocolos para aplicaciones y servicios accesibles a travs de terminales mviles. Consiste en un conjunto de especicaciones, denidas por la Open Mobile Alliance / WAP Forum, que permiten que los desarrolladores diseen aplicaciones de interconexin para terminales mviles, tpicamente telfonos. La tecnologa WAP permite que los usuarios de estos dispositivos puedan acceder a servicios disponibles en Internet. Sin embargo, existen algunas consideraciones a tener en cuenta al disear estos servicios para usuarios mviles, fundamentalmente debidas a las caractersticas de los terminales: pantalla ms pequea que la de un ordenador personal, teclados ms limitados que los de un ordenador, limitaciones en la memoria disponible, tanto memoria RAM como memoria para almacenamiento persistente, y limitaciones en la capacidad del procesador, en comparacin con la memoria y procesador de un ordenador personal tpico. Las redes de telefona mvil ofrecen tambin unas prestaciones por lo general menores que los accesos a Internet, si bien con las redes de tercera generacin como UMTS las prestaciones mejoran de manera importante.
2.6.3
Modelo de WAP
El modelo de aplicacin WAP como se puede ver en la g. 2.4 de la pg. 42, es bastante similar al WWW, ya que todo el sistema WAP est en el anterior. Este parecido permite facilidades tales como un modelo de programacin familiar, una arquitectura probada y la habilidad de utilizar herramientas existentes (servidores web, herramientas XML, estndares de Internet) tambin debe indicarse que se ha intentado optimizar el modelo para un entorno
42
inalmbrico [7].
Figura 2.4: Modelo Wap. Como se puede desprender de la g. 2.5 de la pg. 43, el modelo opera de la siguiente manera: El usuario teclea la URL en su telfono mvil. El agente usuario enva la peticin URL a la pasarela WAP mediante el protocolo WAP. La pasarela WAP genera una peticin convencional HTTP para la URL pedida y la enva al servidor web. El servidor web procesa la peticin. Si es un chero esttico, toma el chero y le aade una cabecera HTTP. Si es CGI ( Common Gateway Interface) u otra aplicacin SCRIPT, lanza la aplicacin. El servidor Web devuelve la marca WML con la cabecera HTTP aadida, o la salida WML del CGI o SCRIPT. La pasarela WAP verica la cabecera HTTP y el contenido WML y la codica a una forma binaria. Crea la respuesta WAP conteniendo el WML y lo enva al usuario.
2.6. WAP
43
Figura 2.5: Modelo de la Red Wap. El usuario recibe la respuesta WAP y muestra por pantalla el contenido WML o SCRIPT. El contenido se transporta usando la pila de protocolos. Adems se dispone de un Micro-navegador en el terminal mvil que hace de interfaz con el usuario. WAP dene un conjunto de componentes estndares que permiten la comunicacin entre el cliente mvil y los servidores que deben incluir: Modelo de nomenclatura: se utilizan los URLs estndar. Representacin del contenido: contenido consistente con el WWW. Protocolo estndar: permiten la comunicacin entre el navegador del dispositivo inalmbrico y el servidor. WAP utiliza la tecnologa Proxy para conectar el dominio inalmbrico a la Internet tradicional. Entre el terminal mvil y el servidor web existe una pasarela. En este nodo se traducen los datagrama del protocolo WAP al protocolo HTTP- TCP/IP. Por tanto el cliente, desde su terminal con capacidad WAP ve esta pasarela como el extremo de la comunicacin [7].
44
Entorno de Programacin WAP El cliente WAP se comunica con dos servidores en la red inalmbrica. La pasarela WAP traduce las peticiones WAP en peticiones WWW y tambin en direccin contraria (respuestas WWW en respuestas WAP). Si el servidor web proporciona directamente contenido WAP (WML), la pasarela WAP lo toma directamente del servidor. Sin embargo si el servidor slo proporciona contenido WWW (HTML). Las marcas WML son codicadas WBXML antes de enviarlas al mvil WAP. El servidor de Aplicacin de Telefona Inalmbrica WTA (Wirelees Telephony Application) es un ejemplo de servidor que responde peticiones directamente del cliente WAP sin pasar por ningn tipo de intermediarios. Se utiliza fundamentalmente para aplicaciones propias del entorno inalmbrico. La Capa de Aplicacin WAE La capa de aplicacin (Wireless Application Enviroment) es la capa de propsito general basada en una combinacin de Word Wide Web (WWW) y las tecnologas de telefona mvil. Su principal objetivo es establecer un entorno de interoperabilidad que permitir a los usuarios y los proveedores de contenido construir aplicaciones y servicios que puedan alcanzar una gran variedad de plataformas inalmbricas de manera eciente y til. WAE incluye un mini-navegador que tiene las siguientes funcionalidades: Wireless Mark-up Language (WML) un lenguaje liviano, similar a HTML pero optimizado para terminales mviles. , (WBML) es la versin codicada que se entrega a los dispositivos mviles para reducir el volumen del trco al telfono mvil. WMLScript, un lenguaje de script de baja carga, similar a Javascript. Wireless Telephony Application (WTA-WTAI) servicios de telefona e interfaces de programacin. Formatos de contenidos, un conjunto de formatos de datos bien denidos.
2.6. WAP
45
Figura 2.6: Pilas de Protocolos TCP/IP y WAP.
2.6.4
Tecnologa
En la versin 1 de WAP, denida en 1999, el lenguaje de presentacin de contenidos es el WML, o Wireless Markup Language. La pila de protocolos de WAP 1 no es compatible directamente con la de Internet como se puede ver en la g. 2.6 de la pag. 45: WSP (Wireless Session Protocol), WTP (Wireless Transaction Protocol), WTLS (Wireless Transport Layer Security), y WDP (Wireless Datagram Protocol). WDP corresponde a la capa de transporte, con funcionalidad equivalente al protocolo UDP de Internet, y se apoya en los servicios de la portadora WAP, que depende de la red mvil que est usando el terminal. WAP 1 adems dene la interfaz de acceso de las aplicaciones a las funciones de telefona del terminal con WTAI (Wireless Telephony Application Interface), y tambin un sencillo lenguaje de scripting, WMLScript, basado en JavaScript. La incompatibilidad que existe en la pila de protocolos WAP 1 con la de Internet exige la presencia de un nodo pasarela para hacer de intermediario en la comunicacin entre un terminal WAP y un servidor de contenidos WAP residente en Internet.
46
WAP ha sido sujeto a diversas crticas en su implementacin, como ser el bajo soporte de grcos en los terminales mviles, las diferencias de implantacin en terminales mviles de distintos fabricantes y un problema muy grave en cuanto a seguridad debido a que la capa WTLS no es robusta y adems por no ser compatibles con los mecanismos de seguridad que brinda Internet. La nueva versin de WAP, WAP 2.0, est presente en los telfonos mviles de nueva generacin (a partir del 2004). Esta versin es una reingeniera de WAP que utiliza XHTML-MP (XHTML Mobile Prole), un subconjunto de XHTML que incluye el XHTML bsico, y WCSS (WAP CSS), un subconjunto de CSS ms ciertas extensiones especcas para mviles, como lenguajes para la presentacin de contenidos mejorando, por ejemplo el soporte de los grcos. De esta forma se consigue que el diseo de contenidos con WAP 2.0 sea muy similar al diseo de contenidos para la WWW para navegadores en dispositivos no mviles. En cuanto a los protocolos usados, en la capa de transporte se usa TCP y en la de aplicacin, HTTP. As pues, WAP 2.0 ha adoptado los protocolos de Internet. WAP 2.0 adems especica opciones tanto en TCP como en HTTP para mejorar las prestaciones de dichos protocolos sobre redes de comunicaciones mviles. Los mecanismos de seguridad usados ya son compatibles con los de Internet por lo que los problemas de seguridad de WAP 1 se resuelven. La pasarela WAP no es estrictamente necesaria en WAP 2.0, pero su presencia puede tener funciones tiles, como cache web y para dar soporte a las opciones de TCP y HTTP antes mencionadas.
2.6.5
WAP 2.0
WAP 2.0 es la prxima generacin de un conjunto de especicaciones que a comparacin de versiones previas, marca el actual esfuerzo de WAP Forum para adoptar los ms recientes protocolos y estndares de Internet. WAP 2.0 optimiza el uso de grandes anchos de banda y conexiones basadas en paquetes en redes inalmbricas. Mientras utiliza y soporta el incremento en las capacidades de los ltimos dispositivos inalmbricos, tambin provee compatibilidad hacia atrs a contenidos WAP existentes, aplicaciones y servicios que utilizan versiones previas de WAP. Algunas caractersticas de WAP 2.0: Soporte de pila de protocolo: Adems de la pila WAP introducida,
2.6. WAP
47
WAP 2.0 aade soporte y servicios basados en la pila comn de Internet incluyendo soporte para TCP, TLS y HTTP. En comparacin con ambas pilas de protocolo, WAP 2.0 provee un modelo de conectividad en un amplio rango de redes y portadoras inalmbricas. Ambiente de aplicacin WAP: Normalmente visto como Navegador WAP, el ambiente de aplicacin de WAP 2.0 ha evolucionado para aceptar el lenguaje de marca del navegador de Internet como estndar de desarrollo. Esto ha llevado a la denicin de un nuevo lenguaje llamado XHTML-MP . XHTML-MP est basado en la modularidad del marco de trabajo del eXtensible HyperText Markup (XHTML) lenguaje desarrollado por la W3C para reemplazar e incrementar el lenguaje HTML usado actualmente. Capacidades y servicios adicionales: Con WAP 2.0 existe un incremento en el nmero de caractersticas disponibles para desarrolladores, operadores y usuarios. Modelo de Programacin WAP El modelo de programacin WAP est estrechamente alineado con el modelo de programacin Web; ver g. 2.6 de la pg. 45, usa el modelo Pull (donde el cliente requiere contenido desde un servidor). De igual modo, WAP 2.0 extiende la arquitectura web aadiendo soporte a telefona con WTA y habilitando un modelo Push, donde el servidor puede enviar con iniciativa contenido al cliente [9]. En versiones previas de WAP, WAP Proxy (referido como WAP gateway) fue requerido para manipular los protocolos entre el cliente y el servidor origen. WAP proxy comunicado con el cliente usando los protocolos WAP que estn basados en gran parte en protocolos de comunicacin de Internet, y este comunicado con el servidor origen usando los protocolos estndares de Internet. WAP 2.0 no requiere la utilizacin del WAP proxy puesto que la comunicacin entre el cliente y el servidor origen puede ser conducido usando HTTP. De igual manera, colocando un WAP proxy se pueden optimizar los procesos de comunicacin y pueden ofrecer incrementos en los servicios mviles; ver g. 2.8 de la pg. 48. Adems, un servidor proxy es necesario para ofrecer funcionalidad Push.
48
Figura 2.7: Modelo de Programacin Wap.
Figura 2.8: Modelo Proxy para WAP 2.0.
2.6. WAP
49
Nuevas Caractersticas Aadidas y Servicios Mejorados Adems del ambiente de aplicacin y el incremento de la capacidad del microbrowser, WAP 2.0 tambin soporta otras caractersticas para mejorar la experiencia del usuario. Estas caractersticas amplan las capacidades de los dispositivos inalmbricos y mejoran la habilidad para entregar servicios y aplicaciones tiles [9]. Algunas de las caractersticas adicionales de WAP 2.0 son las siguientes: WAP push: Este servicio permite enviar contenido a dispositivos mediante aplicaciones basadas en servidor va un push proxy. Esta funcionalidad ha sido mejorada por WAP 2.0. La funcionalidad de push es especialmente relevante en aplicaciones de tiempo real que envan informacin a sus usuarios, como ser mensajes, precio de stock, alertas actulizadas de trco. User Agent Prole (UAProf ): Este servicio provee la descripcin de las capacidades de los clientes y las preferencias de los usuarios a un servidor de aplicacin. Mejorado por WAP 2.0, esto est basado en la combinacin Capabilities / Preference Proles (CC/PP) trabajo de la W3C, UAProf soporta el modelo de transaccin cliente-servidor enviando la informacin del usuario a servidores con la peticin. Esta informacin permite a los servidores adaptar su contenido y en consecuencia realizar la preparacin de la respuesta. Data Synchronization: En un enfoque que ayuda a asegurar una solucin comn de marco de trabajo, el WAP Forum busc una solucin para la sincronizacin de datos. Como resultado de ello, WAP 2.0 reconoce la labor de la SyncML mediante la adopcin del lenguaje SyncML como su opcin para la solucin de sincronizacin de datos. Los mensajes SyncML se apoyan tanto con los protocolos WSP y HTTP/1.1 Multimedia Messaging Service (MMS): Este servicio prevee el marco de trabajo para implementar una solucin de envio de mensajes ricas en caractersticas. MMS provee caractersticas y funcionalidades que permiten repartir tipos variados de contenido. Dependiendo del modelo de servicio, MMS permite un paradigma de entrega rpido (al igual que SMS) o un mtodo de almacn y reenvo (parecido al correo electrnico) o debera permitir ambos modos para operar. Esta exibilidad permite a operadores ajustar el resultado a la experiencia del usuario.
Captulo 3
Aplicaciones Mviles
3.1 Introduccin
Los dispositivos de computacin inalmbrica han crecido rpidamente, requeriendo aplicaciones de software cada vez ms potentes que puedan manejar esta nueva realidad. Los usuarios desean que las aplicaciones que corren en sus dispositivos mviles tengan la misma funcionalidad estando conectados o desconectados de la red. Esperan aplicaciones que puedan soportar conexiones intermitentes, anchos de banda cambiantes y que manejen ecientemente el problema del roaming. El rango de dispositivos mviles va desde dispositivos dedicados a tareas especcas, como los telfonos celulares, hasta aquellos dispositivos de propsito general, como notebooks. Cada uno de ellos presenta diferentes conjuntos de desafos para el diseo de aplicaciones mviles. Algunos de estos desafos compartidos por la mayora de los dispositivos mviles incluyen: La ubicacin fsica del dispositivo y la conguracin pueden cambiar en cualquier momento a medida que el dispositivo est conectado o desconectado de la red o se mueve entre dos puntos de conexin. La arquitectura de aplicacin mvil debe soportar una operacin consistente operando tanto online como oine y proveer una conectividad continua mientas el dispositivo se mueve entre puntos de conexin. 51
52
CAPTULO 3. APLICACIONES MVILES
Los dispositivos que se alimentan mediante el uso de bateras pueden operar por un tiempo limitado sin recargar o reemplazar las mismas. La arquitectura de una aplicacin mvil debe se diseada para administrar esa energa limitada de las bateras, mediante el uso de estrategias que prologuen la vida til al reducir el consumo sin sacricar el rendimiento del sistema. Una arquitectura de aplicaciones mviles debe proveer soporte para un amplio rango de dispositivos. Debido a que los dispositivos pequeos de propsito especco, tales como telfonos celulares, poseen limitaciones de recursos como el tamao reducido de sus pantallas, limitado almacenamiento y poder de cmputo [21].
3.2
Requerimientos Para Una Arquitectura de Aplicaciones Mviles
Una aplicacin diseada para ser usada en un dispositivo mvil debe cumplir con ciertos requerimientos, algunos son propios del ambiente mvil y otros pueden ser requerimientos de cualquier tipo de aplicacin. A continuacin se presentan los ms relevantes: Operacin consistente tanto online como oine: En varias arquitecturas, los datos son almacenados en un sistema compartido accesible a travs de la red, en forma de documentos, registros de datos o archivos binarios, donde se tiene un acceso coordinado a una copia de la informacin. Una aplicacin mvil debe ser diseada de forma de que los usuarios puedan acceder a los datos sin importar si lo hacen en forma online o en forma oine. Cuando se trabaja oine, el usuario percibe que la informacin compartida est disponible para lectura y escritura. Cuando la conectividad regresa, los cambios en la informacin local son integrados a la copia de red y viceversa. Conectividad continua: Una aplicacin diseada para movilidad debe trabajar con un agente o servicio Proxy para permitir un manejo transparente de los cambios en la conectividad. La conectividad no tiene que ser un requerimiento para la funcionalidad y cortes intermitentes e inesperados en la conexin con la red deben poder ser manejados satisfactoriamente. As mismo este agente o servicio Proxy debe poder
3.2. ARQUITECTURA DE APLICACIONES MVILES
53
seleccionar la red ptima de las disponibles en ese momento, y manejar las tareas propias de la comunicacin como autenticacin segura o autorizacin y direccionamiento lgico. Clientes que soporten multiplataformas: Una aplicacin mvil debe al menos ajustar su interaccin y comportamiento al dispositivo en el que corre, como por ejemplo tipo de entrada y salida, recursos disponibles y nivel de performance. Administracin de recursos: Un recurso como la energa, el ancho de banda o el espacio de almacenamiento puede ser consumido y existe en una cantidad nita. La administracin de recursos debe permitir el monitoreo de atributos como cantidad o tasa de uso, y soportar noticaciones basadas en disparadores predenidos por el usuario. Administracin del contexto: Contexto es cualquier informacin que puede se usada para caracterizar la situacin de una entidad. Donde una entidad es una persona, lugar u objeto que es relevante para la interaccin entre un usuario y una aplicacin, incluyendo al usuario y la aplicacin. La administracin del contexto debe permitir el monitoreo de atributos como ubicacin actual o tipo de dispositivo, y proveer noticacin de cambios en el mismo. Codicacin: La codicacin involucra la modicacin de los datos y protocolo en funcin de los requerimientos del contexto y recursos disponibles. Ejemplos de codicacin son la encriptacin, compresin y transcodicacin. Una implementacin de la capacidad de codicacin permitir la enumeracin de los encoders y decoders disponibles. Luego con sta informacin disponible junto con la capacidad de administracin del contexto, proveer la habilidad de negociar el uso de uno u otro mtodo de codicacin. Almacenamiento duradero: La capacidad de manejar un almacenamiento duradero permite la persistencia de datos de conguracin o informacin esttica. Seguridad: Para evitar las consecuencias de ataques maliciosos, aplicaciones con diseos pobres, y errores inadvertidos de usuarios, se deben tomar ciertas medidas de seguridad como ser: Sistemas y usuarios deben ser autenticados, autenticacin de sistemas, usuarios y acciones deben ser autorizados, y acciones e interacciones deben ser auditadas.
54
Se puede observar que los requerimientos planteados son en gran medida requerimientos no funcionales, esto se debe a la naturaleza sumamente restrictiva implicada en un escenario mvil, y relacionada especialmente con aspecto de hardware.
3.3
Arquitectura de Portal Para Aplicaciones Mviles
La funcin primaria de un portal es la de agregar e integrar diversas y distribuidas fuentes de informacin, y presentar el resultado al usuario en una vista simple concisa y pertinente a travs de un navegador Web o Web Browser. Un portal es tpicamente dirigido a un grupo especco o tipo de usuario. Por ejemplo en la Intranet de una compaa, el sector de atencin al cliente puede acceder a informacin relacionada con clientes (promociones vigentes, descuentos, etc.), pero no puede acceder a informacin nanciera, sta estara slo autorizada para los integrantes del sector de nanzas [21]. Los contenidos que puede tener un portal son: Datos relativamente estticos, como banners, grcos y estructura general. Contenido dinmico, informacin que cambia con cierta frecuencia, el caso de las promociones vigentes para el sector de atencin al cliente estara dentro de este grupo. Informacin nueva o trascendente, como noticaciones o informacin incremental. Por ejemplo una noticacin para el grupo de ventas de un determinado producto que indique que el stock se ha terminado. La arquitectura de un portal abarca tres tipos de funciones: Fuentes de Informacin: Las fuentes de informacin proveen de datos al portal. Las fuentes de informacin incluyen bases de datos, aplicaciones u otros portales externos al sistema. Funciones del Portal: Las funciones de un portal son bsicamente las de agregar y componer la informacin para luego ser entrada al usuario.
3.3. PORTAL PARA APLICACIONES MVILES
55
Funciones Independientes: Son tecnologas persistentes o componentes, como el Web Browser. Los componentes incluidos en un portal son los siguientes: Web browser: Provee una interfase del portal al usuario, si se accede a travs de Internet, un protocolo Proxy soporta la comunicacin con el usuario y con el portal HTTP y HTML comnmente mejorado del lado del cliente con el uso de lenguajes de scripting y/o cdigo ubicado en el browser como ActiveX o controles Java. Servidor de Presentacin: Crea e integra vistas de contenido a travs de la interaccin con otros componentes. Servidor de Aplicacin: Ejecuta cualquier cdigo que sea requerido dinmicamente para extraer y reformatear informacin desde sistema no basados en Web. Administracin de Contenido, bsqueda e indexacin, y colaboracin. Servicios de Personalizacin: Disponible para que cada usuario pueda congurar la vista y el contenido que quiere tener cada vez que accede al portal. Seguridad: Un requerimiento para toda arquitectura de aplicaciones mviles, es el de asegurar la integridad de informacin sensible en sitios remotos. Un portal Web es completamente dependiente de la conexin de red, ya que es una arquitectura centrada en el servidor y la conexin de red se hace un recurso imprescindible. Una solucin simple para aplicaciones mviles es la de permitir el acceso oine a sitios Web, bases de datos y archivos que han sido previamente descargados en el mvil. El usuario interacta con los mismos y una vez que la conexin se reestablece, las copias locales y remotas se sincronican. Esta solucin es vlida para aquellos portales simples, pero cuando las fuentes de datos vienen asociadas con otros sistemas o directamente no caben en el dispositivo mvil, no podr ser aplicada. Entonces, sin conexin de red, la creacin de contenido dinmico desde un portal y sus sistemas back-end en tiempo de ejecucin es esencialmente
56
imposible. Sin embargo existen algunas aproximaciones que pueden ser usadas para proveer una vista oine del contenido: Prealmacenado del contenido generado en el portal. Replicacin en el sistema mvil de los datos y el cdigo usado para generar el portal y su sistema back-end. La apropiada estrategia a utilizar depender de factores como cantidad de datos involucrados, la complejidad de la interaccin del usuario con los datos, y la frecuencia necesaria de actualizacin de los mismos. A continuacin se presentar de que forma una arquitectura de portal mvil puede cubrir los requerimientos planteados para caracterizar una aplicacin mvil: Clientes que soporten multiplataformas: Los portales usualmente soportan el acceso desde diferentes plataformas, manejan diferentes caracterizaciones de dispositivos, y cualquier transcodicacin de contenido requerido. Como el contenido comnmente es dinmico y el tipo de dispositivo del cliente impredecible, estas actividades ocurren en tiempo de ejecucin. Una aplicacin cliente que soporte movilidad no necesita soportar transcodicacin dinmica porque el tipo de dispositivo del cliente es esttico. La aplicacin no necesita manejar cambios dinmicos en la personalizacin del dispositivo oine, ya que se supone que el mismo ser usado por una nica persona. Capacidad de trabajar oine: Prealmacenado de Contenido: involucra el prealmacenado del contenido provisto por un portal en respuesta a un requerimiento hecho por un cliente a travs de una URL, como una pgina Web. El cdigo que genera el contenido no es prealmacenado. Por ejemplo un link (enlace) puede ser referencia a un script JSP o ASP, el Server de aplicacin corre este script y devuelve al cliente streams HTML. Estos HTML son los que estn prealmacenados, no los scripts. Navegar el portal, siguiendo cada link y almacenar la salida en el sistema local para luego disponer del mismo oine, es un mecanismo completamente ineciente. Adems todas la pginas pueden no ser requeridas, por lo tanto el prealmacenado de contenido debe
3.4. ARQUITECTURA DE BASES DE DATOS
57
realizarse bajo el control de la conguracin local que especique las pginas de inters o provea un criterio de seleccin. Replicacin de Cdigo: permite que el contenido del portal sea ms dinmico. El portal puede ejecutar cdigo, por ejemplo JAVA, en el proceso de servir el contenido al usuario o en la recoleccin y manejo de datos de otros sistemas. El cdigo es replicado desde el servidor al cliente. Alguna replicacin involucra componentes de la interfase del usuario, la mayora esta involucrado con la coleccin, manipulacin y almacenamiento de datos. Replicacin de Datos: los datos pueden ser replicados del portal al cliente, del cliente al portal o en ambas direcciones. Si los datos solo puede tener permiso de escritura en el lado del cliente, la implementacin se vuelve ms simple, sin embargo la implementacin que permite esquemas de mltiples copias que pueden ser actualizadas independientemente, se vuelve ms compleja. Conectividad Continua: Dos reas estn incluidas dentro de conectividad continua, estas son administracin de conectividad de red y la seguridad desde el punto de vista del usuario. Por ejemplo el usuario no tendr fsicamente que re-autenticarse cada vez que el sistema se reconecta. La conectividad continua puede ser soportada por emulacin, la cual provee la apariencia de que el recurso de red se encuentra disponible. Una posible arquitectura de portal para aplicaciones mviles es la mostrada en la g. 3.1 de la pg. 58, la cual reeja varios tipos de modicaciones: agregado de nuevos componentes (a los habituales de un portal no mvil).
3.4
Arquitectura de Bases de Datos Para Aplicaciones Mviles
Los usuarios tradicionales de una base de datos acceden a los datos residentes en el servidor de bases de datos desde sus equipos clientes conectados fsicamente a la red. Los datos se presentan en la mquina cliente como una simple vista de los datos residentes en el servidor. Esta particular arquitectura es segura pero al mismo tiempo limitada en el hecho de que los usuario no pueden
58
Figura 3.1: Arquitectura de un Portal Mvil. ver o trabajar con los datos sin una conexin a la red. Todo procesamiento tiene lugar en el servidor, construido especcamente para tal propsito. Se puede armar que una base de datos es un archivo que contiene varios registros de datos. En un ambiente cliente / servidor tradicional, ms de un usuario puede utilizar la misma base de datos simultneamente. RDBMS (Sistemas Manegadores de Bases de Datos Relacionales) hace esto posible a travs del uso de mecanismo interno de locking que previenen que ms de un usuario modique un registro al mismo tiempo [21]. Una arquitectura de base de datos preparada para un ambiente mvil, permite a los usuarios acceder a la informacin en cualquier momento y desde cualquier lugar. En un ambiente mvil, copias de los datos pueden existir en distintos sistemas clientes. Dado que estos sistemas clientes no estn continuamente conectados a la base de datos central, el RDBMS de dicha base no es capaz de prevenir cambios simultneos a los datos por ms de un usuario. Por otra parte, los datos locales en cada sistema cliente deben ser peridicamente sincronizados con los datos de la base master que reside en el servidor. Algunos de los desafos al disear una arquitectura de bases de datos son
3.4. ARQUITECTURA DE BASES DE DATOS
59
las siguientes: Los datos en los sistemas cliente se desactualizan durante los periodos en que el cliente no est conectado. Los mensajes referentes a actualizaciones pendientes no estarn disponibles mientras el sistema este desconectado, esto introducir mas dudas sobre la valides de los datos. La resolucin de conictos se volvern ms desaantes y ya no estarn bajo el control del RDBMS. El poder de procesamiento local en los clientes puede ser limitado en comparacin al poder de procesamiento disponible en el servidor. Los datos propietarios, deben mantenerse seguros en las ubicaciones remotas. Un usuario mvil debe ser capaz de seleccionar los datos a replicar en el sistema cliente para su uso cuando el sistema este desconectado de la red. La replicacin de la base de datos completa no debe ser permitida, se debe limitar al usuario aun arbitrario conjunto de datos. Las desconexiones cliente / servidor deben ser transparentes al usuario. La aplicacin cliente debe continuar teniendo un buen comportamiento y los datos continuar disponibles para el usuario. Un usuario necesita saber si los datos que va a utilizar en un ambiente oine son viejos, irrelevantes o transitorios. El usuario debe ser capaz de basar sus decisiones en estos datos, pero los mismos deben ser marcados de forma que la decisin resultante pueda ser actualizada cuando los datos vuelvan a estar disponibles online nuevamente. Una arquitectura de base de datos para aplicaciones mviles debe garantizar que las transacciones sern trasmitidas conablemente. Durante una transaccin normal, una conexin de red es establecida entre el cliente y el servidor y la transferencia de datos es iniciada. Cuando la transferencia de datos se completa, una noticacin sobre si la transferencia fue realizada con xito o no es enviada al que la inici. La falla o el xito de la transaccin, no debe limitar el trabajo que el usuario puede hacer. Por ejemplo, si el dispositivo est conectado a la red y actualiza un campo de datos, la transaccin ser trasmitida al servidor inmediatamente.
60
Si la conexin se pierde durante la transmisin, la transaccin ser encolada para ser transmitida cuando la conexin sea reestablecida. Mientras tanto el usuario debe poder ser capaz de hacer referencia a la actualizacin aunque la transmisin no se haya completado.
3.5
Aplicaciones Multiplataforma
Multiplataforma es un trmino usado para referirse a los programas, sistemas operativos, lenguajes de programacin, u otra clase de software, que puedan funcionar en diversas plataformas. Por ejemplo, una aplicacin multiplataforma podra ejecutarse en Windows en un procesador x86, en GNU/Linux en un procesador x86, y en Mac OS X en un x86, sin nungn tipo de problemas. Una plataforma es una combinacin de hardware y software usada para ejecutar aplicaciones, en su forma ms simple consiste nicamente de un sistema operativo, una arquitectura, o una combinacin de ambos. La plataforma ms conocida es probablemente Microsoft Windows en una arquitectura x86, otras plataformas conocidas son GNU/Linux y Mac OS X (que ya de por s son multiplataforma). El software en general est escrito de modo que dependa de las caractersticas de una plataforma particular; bien sea el hardware, sistema operativo, o mquina virtual en que se ejecuta. La plataforma Java es una mquina virtual multiplataforma, tal vez la ms conocida de este tipo, as como una plataforma popular para hacer software.
3.5.1
Java y Multiplataforma
Uno de los principales objetivos de los desarrolladores de software en los ltimos aos ha sido conseguir programas portables, capaces de ser ejecutados en diversas plataformas (Macintosh,PC, Unix, Windows), logrando la compatibilidad total. La aparicin del lenguaje Java da la primera solucin satisfactoria al problema de la compatibilidad. La idea consiste en crear mquinas virtuales idnticas en cada una de las diferentes plataformas y encargarles a ellas la ejecucin de programas, obteniendo as la compatibilidad total. Con el desarrollo de estas mquinas virtuales anteriormente mencionadas
3.5. APLICACIONES MULTIPLATAFORMA
61
se puede lograr que el mismo cdigo binario ejecutable se pueda usar en todos los sistemas compatibles con el software Java. Adems la penetracin de Java en Internet, como lenguaje de acompaamiento al HTML, ha sido todo un xito.
Captulo 4
Java
4.1 Introduccn al Lenguaje
Java es un lenguaje orientado a objetos. Esto signica que posee ciertas caractersticas estndares en los lenguajes OO: Objetos. Clases. Mtodos. Subclases. Herencia simple. Enlace dinmico. Encapsulamiento. Java se volvi en un lenguaje muy popular. Antes de que Java apareciera, por ejemplo, C era un lenguaje extremadamente popular entre los programadores y pareca que era el lenguaje de programacin perfecto, combinando los mejores elementos de los lenguajes de bajo y alto nivel en un lenguaje de programacin que se ajustaba a la arquitectura del ordenador y que gustaba a los programadores. 63
64
CAPTULO 4. JAVA
Sin embargo, el lenguaje C tena limitaciones, al igual que los lenguajes de programacin anteriores. Cuando los programas crecan, los programas C se hacan inmanejables porque no haba una forma fcil de acortarlo. Esto quiere decir que el cdigo de la primera lnea de un programa largo podra interferir con el cdigo de la ltima lnea y el programador tendra que recordar todo el cdigo mientras programaba. La programacin orientada a objetos se hizo popular por ser capaz de dividir programas largos en unidades semi-autnomas. El lema de la programacin orientada a objetos es divide y vencers. Dicho en otras palabras, un programa se puede dividir en partes fcilmente identicables. Por ejemplo, se supone que para mantener fresca la comida se utiliza un sistema complejo. Debera comprobar la temperatura de la comida usando un termmetro y cuando la temperatura fuera lo sucientemente alta, se activara un interruptor que arrancara el compresor e hiciera funcionar las vlvulas para que el fro circulara; luego arrancara un ventilador que moviera el aire. Esa es una forma de hacerlo. Sin embargo, otra consiste en coordinar todas esas operaciones de forma que sean automticas, cubriendo todo con una unidad sencilla, un refrigerador. Ahora las interioridades no se ven y lo nico que hay que hacer es introducir o sacar comida del frigorco. De esta forma es como funcionan los objetos, ocultan los detalles de la programacin al resto del programa, reduciendo todas las interdependencias que aparecen en un programa C e inicializando una interfaz bien denida y controlable que mantiene la conexin entre el objeto y el resto del cdigo. Resumiendo se puede decir que la programacin orientada a objetos consiste en la divisin de un problema en diferentes partes (objetos) donde: Cada objeto posee una funcionalidad especca. Los objetos interactan entre s enviando y recibiendo mensajes; ver g. 4.1 de la pg.65. La tarea del programador es coordinar las acciones de los objetos y la comunicacin entre los mismos.
4.1. INTRODUCCN AL LENGUAJE
65
Figura 4.1: Mecanismo de Mensajes Para programar orientado a objetos es necesario primero disear un conjunto de clases. La claridad, eciencia y mantenibilidad del programa resultante depender principalmente de la calidad del diseo de clases. Un buen diseo de clases signicar una gran economa en tiempo de desarrollo y mantencin. Lamentablemente se necesita mucha habilidad y experiencia para lograr diseos de clases de calidad. Un mal diseo de clases puede llevar a programas OO de peor calidad y de ms alto costo que el programa equivalente no OO [16]. Una la gran ventaja de un lenguaje OO, que son las bibliotecas de clases que se pueden construir para la aplicacin [13]. Una biblioteca de clases cumple el mismo objetivo de una biblioteca de procedimientos en una lenguaje como C. Sin embargo: Una biblioteca de clases es mucho ms fcil de usar que una biblioteca de procedimientos, incluso para programadores sin experiencia en orientacin a objetos. Esto se debe a que las clases ofrecen mecanismos de abstraccin ms ecaces que los procedimientos.
4.1.1
Bibliotecas de Clases Estndares de Java
Toda implementacin de Java debe tener las siguientes bibliotecas de clases: Manejo de archivos. Comunicacin de datos. Acceso a la red Internet.. Acceso a bases de datos.
66
CAPTULO 4. JAVA
Interfaces grcas. La interfaz de programacin de estas clases es estndar, esto quiere decir que en todas ellas las operaciones se invocan con el mismo nombre y los mismos argumentos.
4.1.2
Java es Multiplataforma
Los programas en Java pueden ejecutarse en cualquiera de las siguientes plataformas, sin necesidad de hacer cambios: Windows/95 y /NT. Power/Mac. Unix (Solaris, Silicon Graphics, ...). La compatibilidad es total: A nivel de fuentes: el lenguaje es exactamente el mismo en todas las plataformas. A nivel de bibliotecas: en todas las plataformas estn presentes las mismas bibliotecas estndares. A nivel del cdigo compilado: el cdigo intermedio que genera el compilador es el mismo para todas las plataformas. Lo que cambia es el intrprete del cdigo intermedio, la MVJ (Mquina Virtual Java).
Mquina Virtual Java Es un programa (software) que maneja la interaccin entre las aplicaciones Java y el Sistema operativo y hardware subyacentes. Este programa interpreta los bytecodes generados por el compilador de Java durante la ejecucin de un programa Java. El proceso de compilacin y ejecucin se pueden observar en la g. 4.2 de la pg 67.
4.1. INTRODUCCN AL LENGUAJE
67
Figura 4.2: Proceso Compilacin y Ejecucin
4.1.3
Caractersticas del Lenguaje
Robustez Los siguientes errores no se pueden cometer en Java: Java siempre chequea los ndices al acceder a un arreglo. Java realiza chequeo de tipos durante la compilacin (al igual que C). En una asignacin entre punteros el compilador verica que los tipos sean compatibles. Java realiza chequeo de tipos durante la ejecucin (C y C++ no hacen). Cuando un programa usa un cast para acceder a un objeto como si fuese de un tipo especco, se verica durante la ejecucin que el objeto en cuestin sea compatible con el cast que se le aplica. Si el objeto no es compatible, entonces se levanta una excepcin informando al programador la lnea en donde est el error. Java posee un recolector de basuras que administra automticamente la memoria. La MVJ para limpiar o reasignar memoria se lo denomina Garbage Collector. Flexibilidad Java combina exibilidad, robustez y legibilidad gracias a una mezcla de chequeo de tipos durante la compilacin y durante la ejecucin. En Java se
68
CAPTULO 4. JAVA
pueden tener punteros a objetos de un tipo especco y tambin se pueden tener punteros a objetos de cualquier tipo. Estos punteros se pueden convertir a punteros de un tipo especco aplicando un cast. El programador usa entonces punteros de tipo especco en la mayora de los casos con el n de ganar legibilidad y en unos pocos casos usa punteros a tipos desconocidos cuando necesita tener exibilidad. Administracin Automtica de la Memoria En Java los programadores no necesitan preocuparse de liberar un trozo de memoria cuando ya no lo necesitan. Es el recolector de basuras el que determina cuando se puede liberar la memoria ocupada por un objeto. Un recolector de basuras es un gran aporte a la productividad. Se ha estudiado en casos concretos que los programadores han dedicado un 40% del tiempo de desarrollo a determinar en qu momento se puede liberar un trozo de memoria. Adems este porcentaje de tiempo aumenta a medida que aumenta la complejidad del software en desarrollo. Es relativamente sencillo liberar correctamente la memoria en un programa de 1000 lneas. Sin embargo, es difcil hacerlo en un programa de 10000 lneas. Y se puede postular que es imposible liberar correctamente la memoria en un programa de 100000 lneas.
4.2
Estructura de un Programa Java
En el siguiente ejemplo se presenta la estructura general de un programa realizado en cualquier lenguaje orientado a objetos u OOP (Object Oriented Programming), y en particular en el lenguaje Java:
import java.awt.*; import java.lang.String; import java.lang.Integer; import java.awt.event.WindowEvent; import java.util.*;
4.3. CONCEPTOS BSICOS
69
import java.awt.TextField; public class Simu extends Frame implements ActionListener,ItemListener{ MenuBar barra; m1 =new Menu(Archivo); barra.add(m1); m2 =new Menu(Ver); barra.add(m2); .... public static void main(String argv [ ]){ Simu menus = new Simu(); menus.setTitle(Simulacin de Redes); menus.setVisible(true); } }
Aparece una clase que contiene el programa principal Simu (aquel que contiene la funcin main()) y algunas clases de usuario (las especcas de la aplicacin que se est desarrollando) que son utilizadas por el programa principal. La aplicacin se ejecuta por medio del nombre de la clase que contiene la funcin main(). Las clases de Java se agrupan en packages, que son libreras de clases. Si las clases no se denen como pertenecientes a un package, se utiliza un package por defecto (default) que es el directorio activo.
4.3
4.3.1
Conceptos Bsicos
Clases
Una clase es una plantilla desde la que se pueden crear objetos. La denicin de una clase incluye especicaciones formales para la clase y cualquier dato y mtodos incluidos en ella. La programacin orientada a objetos se basa en la programacin de clases [2]. Un programa se construye a partir de un conjunto de clases. Una vez denida e implementada una clase, es posible declarar elementos de esta clase. Los elementos declarados de una clase se denominan objetos de
70
CAPTULO 4. JAVA
la clase. De una nica clase se pueden declarar o crear numerosos objetos. La clase es lo genrico: es el patrn o modelo para crear objetos. Cada objeto tiene sus propias copias de las variables miembro, con sus propios valores, en general distintos de los dems objetos de la clase. Ejemplo:
public abstract class FuncionActivacion implements Cloneable,Serializable{ /*constructor sin argumentos que permite la herencia */ public FuncionActivacion () { } }
4.3.2
Herencia
La herencia es uno de los aspectos de la programacin orientada a objetos que se ha denido formalmente. Utilizando la herencia, se puede crear una nueva clase a partir de otra, y la nueva heredar todos los mtodos y miembros de datos de la primera. La clase nueva se llama subclase y la clase original, clase base o superclase. La idea es aadir lo que se quiera a la nueva clase para darle ms funcionalidad que a la clase base. La herencia es un tema importante en Java, ya que se puede usar la gran librera de clases disponible, derivando de ellas nuestras clases propias. En Java, a diferencia de otros lenguajes orientados a objetos, una clase slo puede derivar de una nica clase, con lo cual no es posible realizar herencia mltiple en base a clases. Sin embargo es posible simular la herencia mltiple en base a las interfaces.
4.3.3
Interfaces
Una interfaz es una clase abstracta que dene mtodos abstractos y constantes, pero no implementa los metodos. La clase que implemeta una interfaz hereda
4.4. VARIABLES DE JAVA
71
los mtodos y debe implementarlos, es decir se forma un contrato entre la Interfaz y la clase que implementa la Interfaz. Una clase puede implementar ms de una interface y una interface puede ser implementada por clases que no se encuentran relacionadas.
4.3.4
Package
Un package es una agrupacin de clases. Existen una serie de packages incluidos en el lenguaje. Adems el programador puede crear sus propios packages. Todas las clases que formen parte de un package deben estar en el mismo directorio. Los packages se utilizan con las siguientes nalidades: 1. Para agrupar clases relacionadas. 2. Para evitar conictos de nombres. En caso de conicto de nombres entre clases importadas, el compilador obliga a cualicar en el cdigo los nombres de dichas clases con el nombre del package. 3. Para ayudar en el control de la accesibilidad de clases y miembros. Por las razones citadas, durante la etapa de Diseo del Software desarrollado, se ha decido crear dos paquetes, calculos e interface, utilizando la sentencia package.
package myprojects.simu; import myprojects.calculos.*; import myprojects.interfase.*;
4.4
Variables de Java
Una variable en Java es un identicador que representa una palabra de memoria que contiene informacin. El tipo de informacin almacenado en una variable slo puede ser del tipo con que se declar esa variable. Los diferentes
72
CAPTULO 4. JAVA
tipos tienen que ver con el formato de los datos que se almacenan en ella, as como con la memoria que es necesaria para gestionar ese dato. Hay dos tipos principales de variables: Variables de tipos primitivos: Estn denidas mediante un valor nico y almacenan directamente ese valor siempre que pertenezca al rango de ese tipo. Por ejemplo una variable int almacena un valor entero como 1, 2, 0, -1, etc. Variables referencia: Las variables referencia son referencias o nombres de una informacin ms compleja: arrays u objetos de una determinada clase. Una referencia a un objeto es la direccin de un rea en memoria destinada a representar ese objeto. El rea de memoria se solicita con el operador new. Las variables de referencia tambin es descripta como una referencia a una clase. Por ejemplo si se dene: Estudiante e1. e1 es una referencia a una instancia de Estudiante. Se puede decir que dentro de un programa las variables pueden ser: Variables miembro de una clase: Se denen en una clase, fuera de cualquier mtodo; pueden ser tipos primitivos o referencias. Son tambin llamadas atributos. Variables locales: Se denen dentro de un mtodo o ms en general dentro de cualquier bloque entre llaves {}. Se crean en el interior del bloque y se destruyen al nalizar dicho bloque. Pueden ser tambin tipos primitivos o referencias. En la Tabla 4.1 de la pg. 72 se muestran las dos grandes categoras de tipos para las variables en Java: Tipos Primitivos int, short, byte, long char, boolean oat, double Referencias a Objetos Strings Arreglos otros objetos
Tabla 4.1: Categoras de Variables.
4.4. VARIABLES DE JAVA
73
En la Tabla 4.2de la pg. 73 se indica para cada tipo primitivo el nmero de bits que se emplea en su representacin y el rango de valores que se puede almacenar en las variables de estos tipos. Tipo int short byte long boolean char oat double Bits 32 16 8 64 1 16 32 64 Rango 231 ..231 1 215 ..215 1 27 ..27 1 263 ..263 1 n/a n/a IEEE IEEE Ejemplos 0,1,5,-120,... 0,1,5,-120,... 0,1,5,-120,... 0,1,5,-120,... false, true a,A,0,*,... 1.2 1.2
Tabla 4.2: Tipos Primitivos de Datos
4.4.1
Datos de Objetos o Instancia
Son datos propios de cada instancia (objeto) de una clase determinada. Cada objeto tiene una copia de sus datos. Estos pueden ser variables, mtodos. Se inicializan con el valor por defecto dependiendo del tipo de dato de la variable. Cada tipo de dato tiene asociado un valor por defecto de inicializacin: Integrales (byte, short, int, long): Se inicializan en 0. Flotantes (oat, double): Se inicializan en 0,0. Boolean: se inicializan en false. Char: se inicializan en /u0000 en formato UNICODE.
4.4.2
Datos de Clase
Son datos generales o globales a la ejecucin de un aplicacin.
74
CAPTULO 4. JAVA
Representan datos que son compartidos por todas las instancias de una clase y son cargados en memoria antes que una instancia de la clase se creada. Es decir antes de que se instancien nuevos objetos de la clase. Se declaran con la palabra reservada static. Por ejemplo una variable de clase seria:
public static String mensaje.
Y un ejemplo de la declaracin de un mtodo de clase:

public static void leerURL().
4.5
4.5.1
Operadores del Lenguaje Java

Operadores Aritmticos
Son operadores binarios (requieren siempre dos operandos) que realizan las operaciones aritmticas habituales: suma (+), resta (-), multiplicacin (*), divisin (/) y resto de la divisin (%).
4.5.2
Operadores de Asignacin
Los operadores de asignacin permiten asignar un valor determinado a una variable. El operador de asignacin por excelencia es el operador igual (=). La forma general de las sentencias de asignacin con este operador es:
variable = expression;
Java dispone de otros operadores de asignacin. Se trata de versiones abreviadas del operador (=) que realizan operaciones acumulativas sobre una variable. La siguiente Tabla 4.3 de la pg. 75, muestra estos operadores y su equivalencia con el uso del operador igual (=).
4.5. OPERADORES DEL LENGUAJE JAVA
75
Operador += -= =* =/ %=
Utilizacin op1 + = op2 op1 - = op2 op1 * = op2 op1 / = op2 op1% = op2
ExpresinEquivalente op1 = op1 + op2 op1 = op1 - op2 op1 = op1 * op2 op1 = op1 / op2 op1 = op1 % op2
Tabla 4.3: Operadores de asignacin.
4.5.3
Operadores Unarios
Los operadores unarios sirven para mantener o cambiar el signo de una variable, constante o expresin numrica. Ellos son el ms (+) y menos (-) Su uso en Java es el estndar de estos operadores.
4.5.4
Operador Instanceof
El operador Instanceof permite saber si un objeto es una instancia o no de una clase determinada y se utiliza de la siguiente manera:
objectName instanceof className.
Devuelve true o false segn el objeto pertenezca o no a la clase.
4.5.5
Operador Condicional
Este operador permite realizar bifurcaciones sencillas, su forma general es la siguiente:

boolean expresion? res1: res2
donde se evalua la expresion booleana y si es true devuelve res1, si es false devuelve res2. Es el nico operador ternario de Java.
76
CAPTULO 4. JAVA
4.5.6
Operadores Incrementales
Java dispone del operador incremento (++) y decremento (). El operador (++) incrementa en una unidad la variable a la que se aplica, mientras que () la reduce en una unidad. Se pueden utilizar de dos formas: Precediendo a la variable de la forma ++i. En este caso primero se incrementa la variable y luego se utiliza (ya incrementada) en la expresin en la que aparece. Despus de la variable de la forma ++i. En este caso primero se utiliza la variable en la expresin (con el valor anterior) y luego se incrementa. En muchas casos estos operadores se utilizan para incrementar una variable fuera de una expresin. En este caso ambos operadores son equivalente. Si se utilizan en una expresin ms complicada, el resultado de utilizar estos operadores en una u otra de sus formas ser diferente.
4.5.7
Operadores Relacionales
Los operadores relacionales sirven para realizar comparaciones de igualdad, desigualdad y relacin de menor o mayor. El resultado de estos operadores es siempre un valor boolean (true o false) segn se cumpla o no la relacin considerada. La siguiente Tabla 4.4 de la pg. 76 muestra los operadores relacionales de Java. Operador > >= < <= == ! = Utilizacin op1 > op2 op1 >= op2 op1 < op2 op1 <= op2 op1 == op2 op1 != op2 El resultado es true si op1 es mayor que op2 si op1 es mayor o igual que op2 si op1 es menor que op 2 si op1 es menor o igual que op2 si op1 y op2 son iguales sio p1 y op2 son diferentes
Tabla 4.4: Operadores relacionales. Operadores de Concatenacin de Caracteres
4.6. ESTRUCTURAS DE PROGRAMACIN
77
El operador ms (+) tambin se utiliza para concatenar cadenas de caracteres. Por ejemplo, para concatenar cadenas puede utilizarse la sentencia:
String msj = Datos ingresados correctamente; System.out.println(Mensaje: + msj);
en donde la leyenda que aparecer en la consola sera: Mensaje : Datos ingresados correctamente.
4.6
Estructuras de Programacin
Las estructuras de programacin o estructuras de control permiten tomar decisiones y realizar un proceso repetidas veces. Son los denominados bifurcaciones y bucles. En la mayora de los lenguajes de programacin, este tipo de estructuras son comunes en cuanto a concepto, aunque su sintaxis vara de un lenguaje a otro. La sintaxis de Java coincide prcticamente con la utilizada en C/C++, lo que hace que para un programador de C/C++ no suponga ninguna dicultad adicional.
4.6.1
Sentencias o Expresiones
Una expresin es un conjunto variables unidos por operadores. Son rdenes que se le dan al computador para que realice una tarea determinada. Una sentencia es una expresin que acaba en punto y coma (;). Se permite incluir varias sentencias en una lnea, aunque lo habitual es utilizar una lnea para cada sentencia. A continuacin se muestra un ejemplo de una lnea compuesta de tres sentencias:
i = 0; j = 5; x = i + j;
4.6.2
Comentarios
Existen dos formas diferentes de introducir comentarios entre el cdigo de Java (en realidad son tres, como pronto se ver). Son similares a la forma de realizar comentarios en el lenguaje C/C++. Los comentarios son tremendamente
78
CAPTULO 4. JAVA
tiles para poder entender el cdigo utilizado, facilitando de ese modo futuras revisiones y correcciones. Adems permite que cualquier persona distinta al programador original pueda comprender el cdigo escrito de una forma ms rpida. Se recomienda acostumbrarse a comentar el cdigo desarrollado. De esta forma se simplica tambin la tarea de estudio y revisin posteriores. Java interpreta que todo lo que aparece a la derecha de dos barras // en una lnea cualquiera del cdigo es un comentario del programador y no lo tiene en cuenta. El comentario puede empezar al comienzo de la lnea o a continuacin de una instruccin que debe ser ejecutada. La segunda forma de incluir comentarios consiste en escribir el texto entre los smbolos /* */ . Este segundo mtodo es vlido para comentar ms de una lnea de cdigo. Por ejemplo:
// Esta lnea es un comentario de una sola lnea int a=1; // Comentario a la derecha de una sentencia /* Este tipo de comentarios es para comentar ms de una sla lnea, slo requiere modicar el comienzo y el nal. */
En Java existe adems una forma especial de introducir los comentarios (utilizando /***/ ms algunos caracteres especiales) que permite generar automticamente la documentacin sobre las clases y packages desarrollados por el programador. Una vez introducidos los comentarios, el programa javadoc.exe (incluido en el JDK) genera de forma automtica la informacin de forma similar a la presentada en la propia documentacin del JDK. La sintaxis de estos comentarios y la forma de utilizar el programa javadoc.exe se puede encontrar en la informacin que viene con el JDK.
4.6.3
Bifurcaciones
Las bifurcaciones permiten ejecutar una de entre varias acciones en funcin del valor de una expresin lgica o relacional. Se tratan de estructuras muy importantes ya que son las encargadas de controlar el ujo de ejecucin de un programa. Se exponen dos variantes del de tipo if.
79
Bifurcacin if Esta estructura permite ejecutar un conjunto de sentencias en funcin del valor que tenga la expresin de comparacin. Ejemplo: se ejecuta si la expresin de comparacin (error < errorMinimo) tiene valor true:
numero = 58; if (math.abs(numero) < 10) { System.out.println(Nmero de 1 solo dgito); } /* n del if */ }
Las llaves {} sirven para agrupar en un bloque las sentencias que se han de ejecutar, y no son necesarias si slo hay una sentencia dentro del if.
Bifurcacin if else Anloga a la anterior, de la cual es una ampliacin. Las sentencias incluidas en el else se ejecutan en el caso de no cumplirse la expresin de comparacin (false), Ejemplo:
numero = 58; if (Math.abs(numero) < 10) { System.out.println(Nmero de 1 solo dgito); } else{ System.out.println(Nmero de 2 dgitos); }// n del else
80
CAPTULO 4. JAVA
4.6.4
Bucles
Un bucle se utiliza para realizar un proceso repetidas veces. Se denomina tambin lazo o loop. El cdigo incluido entre las llaves {} (opcionales si el proceso repetitivo consta de una sola lnea), se ejecutar mientras se cumpla unas determinadas condiciones. Hay que prestar especial atencin a los bucles innitos, hecho que ocurre cuando la condicin de nalizar el bucle (booleanExpression) no se llega a cumplir nunca. Se trata de un fallo muy tpico, habitual sobre todo entre programadores poco experimentados. Bucle while En el siguiente ejemplo se muestra que se ejecutar la sentencia n++ mientras la expresin (capas.charAt(n)!=, && capas.charAt(n)!=-1) sea verdadera.
for (int j=0; j < numeroCapas; j++) {int n = principio; try { while (capas.charAt(n) != , && capas.charAt(n) != -1) {n++; } } }
Bucle for A continuacin se podr apreciar la utilizacin del bucle for:

/* calcular el nuevo vector de diseo */ for (int i = 0; i < vectorDis.length; i++) {vectorDis[i] = vectorDis[i] + learningRate * S[i]; }
81
La sentencia int i = 0 (inicializacin) se ejecuta al comienzo del for, e i++ (incremento) despus de vectorDis[i] = vectorDis[i] + learningRate * S[i] (sentencia). La expresin booleana (vectorDis.length) se evala al comienzo de cada iteracin; el bucle termina cuando la expresin de comparacin toma el valor false. Bucle do while Es similar al bucle while pero con la particularidad de que el control est al nal del bucle (lo que hace que el bucle se ejecute al menos una vez, independientemente de que la condicin se cumpla o no). Una vez ejecutados las sentencias, se evala la condicin: si resulta true se vuelven a ejecutar las sentencias incluidas en el bucle, mientras que si la condicin se evala a false naliza el bucle.
do{ /* calcular el gradiente del vector jar el vector de diseo */ problema.joVector(vectorDis); /* incrementar el contador de iteraciones*/ step++; } while (error > errorDeseado && step < iteracionesMaximas); /* ... hasta que el error sea menor o igual que el deseado o */ /* se alcance el nmero de iteraciones pasado como argumento */ problema.joVector(vectorDis);
Bloque try{...} catch{...} nally{...} Java incorpora en el propio lenguaje la gestin de errores. El mejor momento para detectar los errores es durante la compilacin. Sin embargo prcticamente slo los errores de sintaxis son detectados en esta operacin. El resto de problemas surgen durante la ejecucin de los programas.
82
CAPTULO 4. JAVA
En el lenguaje Java, una Exception es un cierto tipo de error o una condicin anormal que se ha producido durante la ejecucin de un programa. Algunas excepciones son fatales y provocan que se deba nalizar la ejecucin del programa. En este caso conviene terminar ordenadamente y dar un mensaje explicando el tipo de error que se ha producido. Otras excepciones, como por ejemplo no encontrar un chero en el que hay que leer o escribir algo, pueden ser recuperables. En este caso el programa debe dar al usuario la oportunidad de corregir el error (dando por ejemplo un nuevo path del chero no encontrado). Los errores se representan mediante clases derivadas de la clase Throwable, pero los que tiene que chequear un programador derivan de Exception (java.lang.Exception que a su vez deriva de Throwable). Existen algunos tipos de excepciones que Java obliga a tener en cuenta. Esto se hace mediante el uso de bloques try, catch y nally. El cdigo dentro del bloque try est vigilado: Si se produce una situacin anormal y se lanza como consecuencia una excepcin, el control pasa al bloque catch que se hace cargo de la situacin y decide lo que hay que hacer. Se pueden incluir tantos bloques catch como se desee, cada uno de los cuales tratar un tipo de excepcin. Finalmente, si est presente, se ejecuta el bloque nally, que es opcional, pero que en caso de existir se ejecuta siempre, sea cual sea el tipo de error. En el caso en que el cdigo de un mtodo pueda generar una Exception y no se desee incluir en dicho mtodo la gestin del error (es decir los bucles try/catch correspondientes), es necesario que el mtodo pase la Exception al mtodo desde el que ha sido llamado. Esto se consigue mediante la adicin de la palabra throws seguida del nombre de la Exception concreta, despus de la lista de argumentos del mtodo. A su vez el mtodo superior deber incluir los bloques try/catch o volver a pasar la Exception. De esta forma se puede ir pasando la Exception de un mtodo a otro hasta llegar al ltimo mtodo del programa, el mtodo main().
4.7
Servlet
Los servlets son programas de Java que construyen respuestas dinmicas para el cliente, tal como pginas Web. Los servlets reciben y responden a las demandas de los clientes Web, normalmente por HTTP.
4.7. SERVLET
83
Adems los servlets son escalables, dando soporte para una multi-aplicacin de conguracin del servidor. [11] Permiten utilizar datos cach, acceso a informacin de base de datos, y compartir datos con otro servlets, archivos JSP y (en algunos ambientes) con los bean empresariales. Poseen algunas ventajas respecto a los tradicionales programas CGI:
Independencia de la plataforma. Esto proporciona un menor esfuerzo
de codicacin con respecto a soluciones dependientes del servidor web y de la plataforma.
Ejecucin en paralelo de multiples peticiones por una sola instancia del servlet.Tradicionalmente en los programas CGI se ejecuta un proceso distinto para cada peticin lo que conlleva una gradual degradacin del rendimiento y una necesidad de recursos muy elevada.En un servlet todas las peticiones se atienden en el mismo proceso por distintos hilos y una vez que se ha cargado el servlet este permanece en memoria hasta que se reinicie el servidor.
4.7.1
Estructura de un Servlet
El API Servlet consiste bsicamente en dos paquetes:
javax.servlet javax.servlet.http
Todas las clases e interfaces que hay que utilizar en la programacin de Servlets estn en estos dos paquetes.
84
CAPTULO 4. JAVA
Figura 4.3: Jerarqua y Mtodos de las Principales Clases Para Crear Servlets. Vision General del API de Servlet La relacin entre las clases e interfaces de Java, muy determinada por el concepto de herencia, tal como puede verse en la g. 4.3 de la pg. 84 se representan con letra normal las clases y las interfaces con cursiva. La clase GenericServlet es una clase abstracta puesto que su mtodo service() es abstracto. Esta implementa dos interfaces, de las cuales la ms importante es la interface Servlet. La interface Servlet declara mtdos ms importantes de cara a la vida de un servlet: init() que se ejecuta slo al arrancar el servlet; destroy() que se ejecuta cuando va a ser destruido y service() que se ejecutar cada vez que el servlet debe atender una solicitud de servicio. Cualquier clase que derive de GenericServlet deber denir el mtodo service(). Este mtodo tiene en su denicin dos argumentos correspondientes a las interfaces ServletRequest y ServletResponse. La primera referencia a un objeto que describe por completo la solicitud de servicio que se le enva al servlet. Si la solicitud de servicio viene de un formulairo HTML, a travs de ese objeto se puede acceder a los nombres de los campos y a los valores introducidos por el usuario. El segundo argumento es un objeto con la referencia a la interface ServletResponse que constituye el camino mediante el cual el mtodo service() se conecta de nuevo con el cliente y le comunica el resultado de su solicitud.
4.7. SERVLET
85
La clase HttpServlet ya no es abstracta y dispone de una implementacin o denicin del mtodo service(). Dicha implementacin detecta el tipo de servicio o mtodo HTTP que le ha sido solicitado desde el browser y llama al mtodo adecuado de esa misma clase (doPost(), doGet(),etc.), tambin aparecen otras interfaces como ser: La interfaz ServletCong dene mtodos que permiten pasar al servlet informacin sobre sus parametros de inicializacin. La interface ServletContext permite a los servlets acceder a informacin sobre el entorno en que se estan ejecutando. Principios de Codicacin de Servlet Para crear un servlet de HTTP, es necesario extender las clases: javax.servlet.HttpServlet y sustituir cualquier mtodo que se desee implementar en el servlet. Por ejemplo, un servlet reemplaza el mtodo doGet para manejar las demandas Get de los clientes. El HttpServletRequest representa los requerimientos de un cliente. Este objeto da acceso al servlet, a la informacin incluida como datos en formato HTML, encabezados HTTP, etc. El HttpServletResponse representa la respuesta del servlet. El servlet usa este objeto para devolverle datos al cliente como errores de HTTP (200, 404, y otros), encabezados de respuesta (Content-Type, SetCookie, y otros), y datos de salida para escribir cadenas de salida de respuesta o salida impresa. El principio de un servlet podra parecerse al siguiente ejemplo:
import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class ServletPrueba extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException{
86
CAPTULO 4. JAVA
Ciclo de Vida del Servlet Un Servlet de Java tiene un ciclo de vida que determina como el servlet es cargado e inicializado, como recibe y responde a las peticiones y como sale fuera de servicio. Las clases javax.servlet.http.HttpServlet denen mtodos tales como: Iniciar un servlet. Solicitar servicios. Quitar un servlet del servidor. stos son conocidos como mtodos del ciclo de vida y son llamados en la siguiente secuencia: Se construye el servlet. Se inicializa con el mtodo INIT. Se manejan llamadas de los clientes al mtodo de servicio. Se saca el servlet de servicio. Se destruye con el mtodo destruir. Se naliza el servlet y la basura es recolectada. El ciclo de vida de un Servlet se puede apreciar en la g. 4.4de la pg 87.
4.7.2
Instanciacin e Inicializacin
El motor del servlet (la funcin del Servidor de Aplicaciones que procesa servlets, archivos JSP, y otros tipos de server-side incluyendo codicacin) crea una instancia del servlet. El motor del servlet crea el objeto de conguracin del servlet y lo usa para pasar los parmetros de inicializacin del servlet al mtodo INIT. La inicializacin de los parmetros persiste hasta que el servlet se destruye y es aplicada a todas las invocaciones de ese servlet hasta destruirse.
4.7. SERVLET
87
Figura 4.4: Ciclo de Vida de un Servlet.
88
CAPTULO 4. JAVA
Si la inicializacin tiene xito, el servlet est disponible para el servicio. Si la inicializacin falla, el motor del servlet descarga el servlet. El administrador puede inhabilitar una aplicacin y el servlet para el servicio. En tales casos, la aplicacin y el servlet permanecen inhabilitados hasta que el administrador los habilite.
4.7.3
Servicio de Demanda
Una demanda del cliente llega al servidor de aplicaciones. El motor del servlet crea un objeto demanda y un objeto respuesta. El motor del servlet invoca al mtodo de servicio del servlet, procesa el requerimiento y usa mtodos del objeto respuesta para crear la respuesta para el cliente. El mtodo de servicio recibe informacin sobre el requerimiento del objeto demanda, procesa el requerimiento, y usa los mtodos del objeto respuesta para crear la contestacin para el cliente. El mtodo de servicio puede invocar otros mtodos para procesar el requerimiento, tales como doGet (), doPost (), o mtodos del usuario.
4.7.4
Terminacin
El motor del servlet invoca al mtodo destroy () del servlet cuando apropia y descarga el servlet. La Mquina Virtual de Java realiza la recoleccin de basura despus de la destruccin del servlet. Cuando el contenedor Web ya no necesita que el servlet o una nueva instancia del servlet se recarguen, invoca al mtodo destroy () del servlet. El contenedor Web tambin puede llamar al mtodo destroy () si el motor necesita conservar recursos o una llamada pendiente a un mtodo service () del servlet excediendo el timeout. La Mquina Virtual de Java realiza recoleccin de basura despus del destroy.
4.7.5
Java Server Faces
JavaServer Pages (JSP) combinan HTML con fragmentos de Java para producir pginas web dinmicas. Cada pgina es automticamente compilada a servlet por el motor de JSP
4.7. SERVLET
89
, en primer lugar es recogida y a continuacin ejecutada. JSP tiene gran variedad de formas para comunicarse con las clases de Java, servlets, applets y el servidor web; por esto se puede aplicar una funcionalidad a nuestra web a base de componentes. Una pgina JSP es archivo de texto simple que consiste en contenido HTML o XML con elementos JSP. Cuando un cliente pide una pgina JSP del sitio web y no se ha ejecutado antes, la pgina es inicialmente pasada al motor de JSP, el cual compila la pgina convirtindola en Servlet, la ejecuta y devuelve el contenido de los resultados al cliente. El cdigo fuente de una pgina JSP incluye: Directivas: Dan informacin global de la pgina, por ejemplo, importacin de estamentos, pgina que majena los errores o cuando la pgina forma parte de una sesin. Declaraciones: Sirven para declarar mtodos y variables. Scripts de JSP: Es el cdigo Java embebido en la pgina. Expresiones de JSP: Formatea las expresiones como cadenas para incluirlas en la pgina de salida. Directivas Una directiva de JSP es una estamento que proporciona la informacin del motor de JSP para la pgina que la pide. Su sintaxis general es <%@ directiva {atributo =valor} %> dnde la directiva debe tener un nmero de atributos. Algunos ejemplos son:
90
CAPTULO 4. JAVA
Page: Informacin para la pgina. Include: Incluye archivos completos palabra por palabra. Taglib: La direccin de la librera de tags que se usar en la pgina. La directiva Page posee varios atributos: language=java: Comunica al servidor el lenguaje que va a ser utilizado en el archivo. Java es el nico posible es esta especicacin. extends=package.class: La variale extends, dene la clase padre del servlet generado. Normalmente no es necesario utilizar otras que no sean las clases base del proveedor. import=package.*,package.class: Sirve para especicar los paquetes y clases que se quieran utilizar. session=true|false: Por defecto session vale true, manteniendo los datos de las sesin para la pgina. isThreadSafe=true|false: Por defecto vale true, le hace seales al motor de JSP para que multiples pedidos del cliente puedan ser tomadas como una. info=text: Informacin en la pgina a la que puede accederse a travs del mtodo Servlet.getServletInfo(). errorPage=pagina_error: Pgina que manejar las excepciones de errores. Declaraciones Una declaracin de JSP, puede denirse como una denicin de variables y mtodos a nivel de clase que son usadas en la pgina. Un bloque de declaraciones tpico sera <%! declaracin %> Un ejemplo de declaracin de script sera el siguiente:
<HTML> <HEAD> <TITLE>Pgina simple JSP</TITLE>
4.7. SERVLET
91
</HEAD> <BODY> <%! String strCadena = x; int intContador = 0; %> </BODY> </HTML>
Scripts de JSP Los Scripts son bloques de cdigo Java residentes entre los tags <% y %>. Este bloques de cdigo estarn dentro del servlets generado includos en mtodo _jspService(). Los Scripts pueden acceder a cualquier variable o Beans que haya sido declarado. Tambin hay algunos objetos implcitos disponibles para los Scripts desde entorno del Servlet. Algunos de ellos pueden verse a continuacin: request: Es la peticin del cliente. Es normalmente una subclase de la case HttpServletRequest. response: Es la pgina JSP de respuesta y es una subclase de HttpServletResponse. Los atributos de la pgina y los objetos implicitos necesitan ser accesibles a travs de API, para permitir al motro de JSP compilar la pgina. Pero cada servidor tiene implementaciones especcas de cada uno de esos atributos y objetos. pageContext: Esta clase PageContext es inicializadacon los objetos response y request y algunos atributos de la directiva de la pgina (erropage,session,buer and autoush) y facilita los otros objetos implcitos para la pagina de peticin. session: El objeto de sesin HTTP asociado a la peticin. application: Lo que devuelve el servlet cuando se llama a getServletCong().getContext().
92
CAPTULO 4. JAVA
page: Es la forma que tiene la pgina para referirse a si misma. Se usa como alternativa al objeto this. El siguiente fragmento de cdigo muestra como obtener el valor de una parmetro mediante el objeto request, y como pasarlo a una cadena para mostrarlo en pantalla.
<% String strNombre = request.getParameter(nombre); out.println(strNombre); %>
Expresiones JSP Las expresiones son una magnica herramienta para insertar cdigo embebido dentro de la pgina HTML. Cualquier cosa que este entre los tags <%= y %> ser evaluado, convertido a cadena y posteriormente mostrado en pantalla. La conversin desde el tipo inicial a String es manejada autmaticamente. Es importante remarcar que que la expresin no termina en punto y coma (;) . Esto es as porque motro de JSP, pondr la expresin automticamente entre out.println(). Las expresiones JSP te permiten parametrizar las pginas HTML (es parecido a cuando parametrizas una consulta SQL pero dieren la forma de los valores). Una y otra vez , en el cdigo de la pgina HTML, ser vern bucles o condiciones usando cdigo Java, simplemente empezando y acabando las condiciones o bucles entre los tags <% y %>. Un ejemplo sera:
<% for (int i=0;i<5;i++) { %>
4.7. SERVLET
93
Figura 4.5: Requerimiento de un Archivo JSP.

<BR>El valor del contador es <%=i%> <% } %>
Modelos de Acceso JSP Se puede acceder a los archivos JSP de dos maneras: El browser enva un requerimiento para los archivos JSP. Los archivos JSP acceden a los beans u otros componentes que generan contenido dinmico para ser enviado al browser como se muestra en la gura 4.5 de la pgina 93. Cuando el servidor Web recibe un requerimiento para un archivo JSP, el servidor enva ese requerimiento al servidor de aplicaciones. El servidor de aplicaciones analiza el archivo JSP y genera cdigo fuente de Java que se compila y se ejecuta como un servlet. El requerimiento se enva a un servlet que genera contenido dinmico y llama a un archivo JSP para enviar el contenido a un browser, como se muestra en la gura 4.6 de la pgina 94. Este modelo de acceso facilita la generacin de contenido separado del despliegue de contenido. El servidor de aplicaciones proporciona un juego de mtodos en el objeto HttpServiceRequest object y el objeto HttpServiceResponse. Estos mtodos
94
CAPTULO 4. JAVA
Figura 4.6: Requerimiento de un Servlet. permiten una invocacin de servlet para colocar un objeto (normalmente un bean) en un objeto demanda y pasa ese requerimiento a otra pgina (normalmente un archivo JSP) para el despliegue. La pgina invocada recupera el beans del objeto demanda y genera el HTML que recibe el cliente.
4.7.6
Desarrollando Aplicaciones
Para WebSphere Application Server, las aplicaciones son combinaciones de bloques que trabajan conjuntamente para el logro de una funcin de la lgica comercial. Las aplicaciones Web son grupos de uno o ms servlets, ms el contenido esttico. Aplicaciones Web = servlets + archivos JSP + archivos XML + archivos HTML + grcos. El modelo de programacin de WebSphere Application Server est basado en la plataforma Java de Sun (J2SE). El ambiente J2SE soporta la base para construir redes centrales de aplicaciones empresariales para correr sobre una
4.7. SERVLET
95
variedad de sistemas. El software J2SE consiste en los Java SDK Standard Edition y el Java Runtime Environment (JRE ) Standard Edition.
Captulo 5
Java 2 Micro Edition

5.1 Introduccin
Para empezar se puede decir que Java 2 Micro Edition o J2ME es la versin del lenguaje Java que est orientada al desarrollo de aplicaciones para dispositivos pequeos con capacidades restringidas tanto en pantalla grca, como de procesamiento y memoria (telfonos mviles, PDAs, Handhelds, Pagers, etc.). Esta versin de Java fue presentada en 1999 por Sun Microsystems con el propsito de habilitar aplicaciones Java para pequeos dispositivos. En esta presentacin lo que realmente se mostr fue una nueva mquina virtual Java o JVM (Java Virtual Machine) que poda ejecutarse en dispositivos Palm. La tarda aparicin de esta tecnologa puede ser debido a que las necesidades de los usuarios de telefona mvil han cambiado mucho en estos ltimos aos y cada vez demandan ms servicios y prestaciones por parte tanto de los terminales como de las compaas. Adems el uso de esta tecnologa depende del asentamiento en el mercado de otras, como GPRS, ntimamente asociada a J2ME y que no ha estado al alcance hasta hace poco. J2ME es la tecnologa del futuro para la industria de los dispositivos mviles. 97
98
CAPTULO 5. JAVA 2 MICRO EDITION
5.1.1
Comparacin de Versiones
Sun Microsystems, con el objetivo de cubrir las necesidades de todos los usuarios cre distintas versiones de Java de acuerdo a las necesidades de cada uno, por lo cual existe el paquete Java 2 que se puede dividir en 3 ediciones distintas: J2SE (Java Standard Edition) orientada al desarrollo de aplicaciones independientes de la plataforma. J2EE (Java Enterprise Edition) orientada al entorno empresarial. J2ME (Java Micro Edition) orientada a dispositivos con capacidades restringidas. Algunas de las caractersticas de cada una de las versiones son: 1. Java 2 Platform, Standard Edition (J2SE): Esta edicin de Java es la que en cierta forma recoge la iniciativa original del lenguaje Java. Tiene las siguientes Caractersticas: Inspirado inicialmente en el lenguaje C++, pero con componentes de alto nivel, como soporte nativo de strings y recolector de basura (garbage colector ). Cdigo independiente de la plataforma, precompilado a bytecodes intermedio y ejecutado en el cliente por una JVM (Java Virtual Machine). Modelo de seguridad tipo sandbox proporcionado por la JVM. Abstraccin del sistema operativo subyacente mediante un juego completo de APIs de programacin. Contiene el conjunto bsico de herramientas usadas para desarrollar Java Applets, as cmo las APIs orientadas a la programacin de aplicaciones de usuario nal: Interfaz grca de usuario, multimedia, redes de comunicacin. 2. Java 2 Platform, Enterprise Edition (J2EE): Esta versin est orientada al entorno empresarial. El software empresarial tiene unas caractersticas propias marcadas:
5.1. INTRODUCCIN
99
Est pensado no para ser ejecutado en un equipo, sino para ejecutarse sobre una red de ordenadores de manera distribuida y remota mediante EJBs (Enterprise Java Beans). Esta edicin est orientada especialmente al desarrollo de servicios web, servicios de nombres, persistencia de objetos, XML, autenticacin, APIs para la gestin de transacciones, etc. El cometido de esta especicacin es ampliar la J2SE para dar soporte a los requisitos de las aplicaciones de empresa. 3. Java 2 Platform, Micro Edition (J2ME): Esta versin de Java est enfocada a la aplicacin de la tecnologa Java en dispositivos electrnicos con capacidades computacionales y grcas muy reducidas, tales como telfonos mviles, PDAs o electrodomsticos inteligentes: Esta edicin tiene unos componentes bsicos que la diferencian de las otras versiones, como el uso de una mquina virtual denominada KVM (Kilo Virtual Machine, debido a que requiere slo unos pocos Kilobytes de memoria para funcionar) en vez del uso de la JVM clsica.
Figura 5.1: Arquitectura de la Plataforma Java 2 de Sun. La g. 5.1 de la pg. 99 muestra la arquitectura de Java2.
100
En la actualidad se puede decir que Java no es slo un simple lenguaje de programacin sino un conjunto de tecnologas que engloba a todos los aspectos de la computacin con dos elementos en comn:
El cdigo fuente en lenguaje Java es compilado a cdigo intermedio interpretado por una Java Virtual Machine (JVM ), por lo que el cdigo ya compilado es independiente de la plataforma. Todas las tecnologas comparten un conjunto ms o menos amplio de APIs bsicas del lenguaje, agrupadas principalmente en los paquetes java.lang y java.io.
Debido a que la edicin estndar de APIs de Java ocupa 20 MB aproximadamente y los dispositivos pequeos disponen de una cantidad de memoria mucho ms reducida, J2ME contiene una mnima parte de las APIs de Java. Concretamente, J2ME usa 37 clases de la plataforma J2SE provenientes de los paquetes java.lang, java.io, java.util. Esta parte de la API que se mantiene ja forma parte de lo que se denomina conguracin [14]. Otra diferencia con la plataforma J2SE viene dada por el uso de una mquina virtual distinta de la clsica JVM denominada KVM. Esta KVM tiene unas restricciones que hacen que no posea todas las capacidades incluidas en la JVM clsica. J2ME representa una versin simplicada de J2SE. Sun separ estas dos versiones ya que J2ME est pensada para dispositivos con limitaciones de proceso y capacidad grca. Tambin separ J2SE de J2EE porque este ltimo exiga unas caractersticas muy pesadas o especializadas de E/S, trabajo en red, etc. Por tanto, separ ambos productos por razones de eciencia. Hoy, J2EE es un superconjunto de J2SE pues contiene toda la funcionalidad de ste y ms caractersticas, as como J2ME es un subconjunto de J2SE (excepto por el paquete javax.microedition) ya que contiene varias limitaciones con respecto a J2SE. Slo de manera muy simplista se puede considerar a J2ME y J2EE como versiones reducidas y ampliadas de J2SE respectivamente (ver g. 5.2 de la pg. 101): en realidad cada una de las ediciones est enfocada a mbitos de aplicacin muy distintos [14].
5.1. INTRODUCCIN
101
Figura 5.2: Ubicacin de las Tecnologas Java.
5.1.2
Algunas Consideraciones al Desarrollar en J2ME
Algunas consideraciones son las siguientes: Prcticamente los dispositivos mviles y ms an los nuevos telfonos celulares ya poseen capacidad de ejecucin de aplicaciones desarrolladas en J2ME. Existen algunas ventajas y restricciones o desventajas respecto a otras tecnologas [10]. Algunas ventajas en comparacin de J2ME con respecto al lenguaje C son: Multiplataforma: Signica 1 programa - se puede ejecutar en n mviles. Seguridad: El usuario est protegido. Descarga OTA (Over The Air). Desarrollo rpido. Inconveniente: Alejamiento del hardware. No puede accederse a ciertos recursos del telfono si ste no incorpora el API correspondiente. Las aplicaciones mviles que poseen conectividad a Internet pueden utilizar la tecnologa GPRS, en la cual se tarifa al usuario por Kbytes recibidos y enviados, es por esto que es importante minimizar la cantidad
102
de informacin intercambiada. Las relaciones que existen de acuerdo al tipo de informacin intercambiada y el volumen de la misma son las siguientes: Pgina html - 10-100Kb. Pgina wml 1-10Kb. Informacin pura - 0.1 - 1kb. Cundo interesa desarrollar en J2ME ?: Cuando no hay trco de informacin, por ejemplo: juegos, conversores de unidades. Cuando el trco de informacin puede minimizarse con J2ME . Cuando pueden almacenarse datos localmente en el mvil y slo transferir algunos otros como los resultados [10].
5.2
Componentes de J2ME
Los componentes que forman parte de la tecnologa J2ME son: Mquina virtual: Existe una serie de mquinas virtuales java con diferentes requisitos, cada una para diferentes tipos de pequeos dispositivos. Conguraciones: Son un conjunto de clases bsicas orientadas a conformar el corazn de las implementaciones para dispositivos de caractersticas especcas: Connected Limited Device Conguration (CLDC) enfocada a dispositivos con restricciones de procesamiento y memoria. Connected Device Conguration (CDC) enfocada a dispositivos con ms recursos [10]. Perles: Son unas bibliotecas Java de clases especcas orientadas a implementar funcionalidades de ms alto nivel para familias especcas de dispositivos.
5.2. COMPONENTES DE J2ME
103
5.2.1
Mquinas Virtuales J2ME
Una mquina virtual de Java (JVM ) es un programa encargado de interpretar cdigo intermedio (bytecode) de los programas Java precompilados a cdigo mquina ejecutable por la plataforma, efectuar las llamadas pertinentes al sistema operativo subyacente y observar las reglas de seguridad y correccin de cdigo denidas para el lenguaje Java. De esta forma, la JVM proporciona al programa Java independencia de la plataforma con respecto al hardware y al sistema operativo subyacente. Las implementaciones tradicionales de JVM son, en general, muy pesadas en cuanto a memoria ocupada y requerimientos computacionales. J2ME dene varias JVMs de referencia adecuadas al mbito de los dispositivos electrnicos que, en algunos casos, suprimen algunas caractersticas con el n de obtener una implementacin menos exigente. La tecnologa J2ME ha denido dos conguraciones, CDC y CLDC, cada una de ellas con caractersticas propias, en consecuencia para cada tipo de conguracin se deni una mquina virtual distinta. La VM (Virtual Machine) correspondiente a CLDC se denomina KVM y la de la conguracin CDC se denomina CVM. A continuacin se detallan las principales caractersticas de cada una de ellas: KVM Se corresponde con la mquina virtual ms pequea. Su nombre KVM proviene de Kilobyte (que hace referencia a la baja ocupacin de memoria). Se trata de una implementacin de mquina virtual reducida y especialmente orientada a dispositivos con bajas capacidades computacionales y de memoria, como ser los telfonos celulares. La KVM est escrita en el lenguaje de programacin C y posee algunas caractersticas particulares como: Pequea, con una carga de memoria entre los 40Kb y los 80 Kb, dependiendo de la plataforma y las opciones de compilacin. Alta portabilidad. Modulable.
104
Lo ms completa y rpida posible y sin sacricar caractersticas para las que fue diseada. Sin embargo, existen algunas limitaciones debido a su bajo consumo de memoria respecto la maquina virtual clsica: No hay soporte para tipos en coma otante. Esta limitacin est presente porque los dispositivos carecen del hardware necesario para estas operaciones. No existe soporte para JNI (Java Native Interface) debido a los recursos limitados de memoria. No existen cargadores de clases (class loaders) denidos por el usuario. No se permiten los grupos de hilos o hilos daemon. Si se necesita la utilizacin de grupos de hilos se tendrn que utilizar los objetos coleccin para almacenar cada hilo. No existe la nalizacin de instancias de clases. No existe el mtodo Object.nalize(). Limitada capacidad para el manejo de excepciones debido a que el manejo de stas depende en gran parte de las APIs de cada dispositivo por lo que son stos los que controlan la mayora de las excepciones. Otro tema en cuestin que se puede encontrar en sta maquina virtual ms pequea es la vericacin de clases. El vericador de clases estndar de Java es demasiado grande para la KVM, De hecho es ms grande que la propia KVM y el consumo de memoria es excesivo, ms de 100Kb para las aplicaciones tpicas. Este vericador de clases es el encargado de rechazar las clases no vlidas en tiempo de ejecucin. Este mecanismo verica los bytecodes de las clases Java realizando las siguientes comprobaciones: Ver que el cdigo no sobrepase los lmites de la pila de la VM. Comprobar que no se utilizan las variables locales antes de ser inicializadas.
105
Comprobar que se respetan los campos, mtodos y los modicadores de control de acceso a clases. Por esta razn los dispositivos que usen la conguracin CLDC y KVM introducen un algoritmo de vericacin de clases en dos pasos. Este proceso puede apreciarse grcamente en la g. 5.3 de la pg. 105.
Figura 5.3: Proceso de Vericacin. CVM La CVM (Compact Virtual Machine) ha sido tomada como mquina virtual Java de referencia para la conguracin CDC y soporta las mismas caractersticas que la mquina virtual clsica. Est orientada a dispositivos electrnicos con procesadores de 32 bits de gama alta y en torno a 2 Mb o ms de memoria RAM. Las caractersticas que presenta sta mquina virtual son: 1. Sistema de memoria avanzado.
106
2. Tiempo de espera bajo para el recolector de basura. 3. Separacin completa de la VM del sistema de memoria. 4. Recolector de basura modularizado. 5. Portabilidad. 6. Rpida sincronizacin. 7. Ejecucin de las clases Java fuera de la memoria de slo lectura (ROM). 8. Soporte nativo de hilos. 9. Baja ocupacin en memoria de las clases. 10. Proporciona soporte e interfaces para servicios en sistemas operativos de tiempo real. 11. Conversin de hilos Java a hilos nativos. 12. Soporte para todas las caractersticas de Java2 v1.3 y libreras de seguridad, referencias dbiles, Interfaz Nativa de Java (JNI ), invocacin remota de mtodos (RMI ), Interfaz de depuracin de la mquina virtual (JVMDI).
5.2.2
Conguraciones
Una conguracin es el conjunto mnimo de APIs Java que permiten desarrollar aplicaciones para un grupo de dispositivos. Estas APIs describen las caractersticas bsicas, comunes a todos los dispositivos: Caractersticas soportadas del lenguaje de programacin Java. Caractersticas soportadas por la mquina virtual Java. Bibliotecas bsicas de Java y APIs soportadas. Como se ha mencionado con anterioridad, existen dos conguraciones, la que est orientada a dispositivos con limitaciones computacionales y de memoria que se denomina CLDC y la conguracin que se encuentra orientada
107
a dispositivos con menos restricciones en cuanto a capacidad de cmputo y memoria, la cual se denomina CDC . A continuacin se presentan las caractersticas ms relevantes de cada una: Conguracin de dispositivos con conexin, CDC (Conected Device Conguration): La CDC est orientada a dispositivos con cierta capacidad computacional y de memoria. Por ejemplo, decodicadores de televisin digital, televisores con Internet, algunos electrodomsticos y sistemas de navegacin en automviles. CDC usa una mquina virtual Java similar en sus caractersticas a una de J2SE, pero con limitaciones en el apartado grco y de memoria del dispositivo. La CDC est enfocada a dispositivos con las siguientes capacidades: Procesador de 32 bits. 2 Mb o ms de memoria total, incluyendo memoria RAM y ROM. Conectividad a algn tipo de red. Poseer la funcionalidad completa de la Mquina Virtual Java 2. La CDC est basada en J2SE v1.3 e incluye varios paquetes Java de la edicin estndar. Las peculiaridades de la CDC estn contenidas principalmente en el paquete javax.microedition.io, que incluye soporte para comunicaciones http y basadas en datagramas [14]. La tabla 5.1 de la pg. 108 muestra las libreras incluidas en la CDC. Conguracion de dispositivos limitados con conexin, CLDC (Conected Limited Device Conguration): La CLDC est orientada a dispositivos dotados de conexin y con limitaciones en cuanto a capacidad grca, cmputo y memoria. Como por ejemplo telfonos mviles, buscapersonas (Pagers), PDAs, organizadores personales, etc.
108
Nombre del paquete CDC java.io java.lang java.lang.ref java.lang.reect java.math java.net java.security java.security.cert java.text java.util java.util.jar java.util.zip javax.microedition.io
Descripcin Clases y paquetes estndar de E/S Clases e interfaces de la mquina virtual Clases de referencia Clases e interfaces de reectin Paquete de matemticas Clases e interfaces de red Clases e interfaces de seguridad Clases de certicados de seguridad Paquete de texto Clases de utilidades estndar Clases y utilidades para archivos JAR Clases y utilidades para archivos ZIP y comprimidos Clases e interfaces para conexin genrica CDC
Tabla 5.1: Libreras de conguracin CDC. Las restricciones que contiene la conguracin CLDC vienen dadas por la utilizacin de la mquina virtual o KVM. Los dispositivos que usan CLDC deben cumplir los siguientes requisitos: Disponer entre 160 Kb y 512 Kb de memoria total disponible. Como mnimo se debe disponer de 128 Kb de memoria no voltil para la mquina virtual Java y las bibliotecas CLDC, y 32 Kb de memoria voltil para la mquina virtual en tiempo de ejecucin. Procesador de 16 o 32 bits con al menos 25 Mhz de velocidad. Tener conexin a algn tipo de red, normalmente sin cable, con conexin intermitente y ancho de banda limitado. Ofrecer bajo consumo, debido a que stos dispositivos trabajan con suministro de energa limitado, normalmente bateras recargables. La CLDC aporta las siguientes funcionalidades a los dispositivos: Un subconjunto del lenguaje Java y todas las restricciones de su mquina virtual (KVM ).
109
Un subconjunto de las bibliotecas del ncleo de Java. Soporte para acceso a redes. Soporte para E/S bsica. Seguridad.
La tabla 5.2 de la pg. 109 muestra las libreras incluidas en la CLDC. Nombre del paquete CLDC java.io java.lang java.util javax.microedition.io Descripcin Clases y paquetes estndar de E/S Clases e interfaces de la mquina virtual Clases e interfaces, utilidades estndar Clases e interfaces de conexin genrica
Tabla 5.2: Libreras de conguracin CLDC.
5.2.3
Perles
Un perl es el que dene las APIs que controlan el ciclo de vida de la aplicacin, interfaz de usuario, etc. Concretamente, un perl es un conjunto de APIs orientado a un mbito de aplicacin determinado. Los perles identican un grupo de dispositivos por la funcionalidad que proporcionan (ya sean electrodomsticos, telfonos mviles, etc.) y el tipo de aplicaciones que se ejecutarn en ellos. Las libreras de la interfaz grca son un componente muy importante en la denicin de un perl. Se pueden encontrar grandes diferencias entre las interfaces, desde el men textual de los telfonos mviles hasta los tctiles de los PDAs. El perl establece unas APIs que denen las caractersticas de un dispositivo, mientras que la conguracin hace lo propio con una familia de ellos. Esto hace que a la hora de construir una aplicacin se cuente tanto con las APIs del perl como de la conguracin. Anteriormente se mencion que para una conguracin determinada se usaba una Mquina Virtual Java especca. Tenamos que con la congura-
110
cin CDC se utilizaba la CVM y que con la conguracin CLDC se utilizaba la KVM. Con los perles ocurre lo mismo. Existen unos perles que se construirn sobre la conguracin CDC y otros que se construirn sobre la CLDC.
Figura 5.4: Entorno de Ejecucin de J2ME. Para la conguracin CDC se encuentran los siguientes perles: Fundation Prole. Personal Prole. RMI Prole. Y para la conguracin CLDC se encuentran los siguientes: PDA Prole. Mobile Information Device Prole (MIDP). En la g. 5.4 de la pg. 110 se puede ver cmo quedara el esquema del entorno de ejecucin al completo. A continuacin se describir con ms detenimiento cada uno de estos perles:
111
Foundation Prole: Este perl dene una serie de APIs sobre la CDC orientadas a dispositivos que carecen de interfaz grca como, por ejemplo, decodicadores de televisin digital [14]. Este perl incluye gran parte de los paquetes de la J2SE, pero excluye totalmente los paquetes que conforman la interfaz grca de usuario (GUI ) de J2SE, concretamente los paquetes java.awt Abstract Windows Toolkit (AWT ) y java.swing. Los paquetes que forman parte del Foundation Prole se muestran en la tabla 5.3 de la pg. 111. Paq. del Fundation Prole java.lang java.util java.net java.io java.text java.segurity Descripcin Soporte del lenguaje Java Aade soporte completo para zip y otras funcionalidades Incluye sockets TCP/IP y conexiones HTTP Clases Reader y Writer de J2SE Incluye soporte para internacionalizacin Incluye cdigos y certicados
Tabla 5.3: Libreras del Fondation Prole. Personal Prole: Es un subconjunto de la plataforma J2SE versin 1.3, proporciona un completo soporte grco AWT . El objetivo es el de dotar a la conguracin CDC de una interfaz grca completa, con capacidades web y soporte de applets Java. Este perl requiere una implementacin del perl Foundation Prole. La tabla 5.4 de la pg. 112 muestra los paquete que conforman el perl. RMI Prole: Este perl requiere una implementacin del Foundation Prole. El perl RMI soporta un subconjunto de las APIs J2SE v1.3 RMI. Algunas caractersticas de estas APIs se han eliminado del perl RMI debido a las limitaciones de cmputo y memoria de los dispositivos. Las siguientes propiedades se han eliminado del J2SE RMI v1.3 :
112
Paq. del Personal Prole java.applet java.awt java.awt.datatransfer java.awt.event java.awt.font java.awt.im java.awt.im.spi
Descripcin Clases necesarias para crear applets Clases para crear GUIs con AWT Clases e interfaces para transmitir datos entre aplicaciones Clases e interfaces para manejar eventos AWT Clases e interfaces para la manipulacin de fuentes Clases e interfaces para denir mtodos editores de entrada Interfaces que a aden el desarrollo de mtodos editores de entrada para cualquier entorno de ejecucin Java Clases para crear y modicar imgenes Clases que soportan JavaBeans Interfaces que usa el Personal Prole para la comunicacin
java.awt.image java.beans javax.microedition.xlet
Tabla 5.4: Libreras del Personal Prole.
113
Java.rmi.server.disableHTTP. Java.rmi.activation.port. Java.rmi.loader.packagePrex. Java.rmi.registry.packagePrex. Java.rmi.server.packagePrex PDA Prole: Est construido sobre CLDC. Pretende abarcar PDAs de gama baja, tipo Palm, con una pantalla y algn tipo de puntero (ratn o lpiz) y una resolucin de al menos 20000 pixeles. En este momento este perl se encuentra en fase de denicin. Mobile Information Device Prole (MIDP): Este perl est construido sobre la conguracin CLDC. MIDP fue el primer perl denido para esta plataforma. Este perl est orientado para dispositivos con las siguientes caractersticas: Reducida capacidad computacional y de memoria. Conectividad limitada (en torno a 9600 bps). Capacidad grca muy reducida (mnimo un display de 96x54 pixels). Entrada de datos alfanumrica reducida. 128 Kb de memoria no voltil para componentes MIDP. 8 Kb de memoria no voltil para datos persistentes de aplicaciones. 32 Kb de memoria voltil en tiempo de ejecucin para la pila Java. Los tipos de dispositivos que se adaptan a estas caractersticas son: telfonos mviles, buscapersonas (pagers) o PDAs de gama baja con conectividad. El perl MIDP especica las APIs relacionadas con: La aplicacin (semntica y control de la aplicacin MIDP).
114
Interfaz de usuario. Almacenamiento persistente. Trabajo en red. Temporizadores. Las aplicaciones realizadas utilizando MIDP reciben el nombre de MIDlets (por simpata con APPlets). Se puede decir que un MIDlet es una aplicacin Java realizada con el perl MIDP sobre la conguracin CLDC. En la tabla 5.5 de la pg. 114 se pueden apreciar cules son los paquetes que estn incluidos en el perl MIDP. Paq. del MIDP javax.microedition.lcdui javax.microedition.rms javax.microedition.midlet javax.microedition.io java.io java.lang java.util Descripcin Clases e interfaces para GUIs Soporte para el almacenamiento persistente del dispositivo Clases de denicin de la aplicacin Clases e interfaces de conexin genrica Clases e interfaces de E/S bsica Clases e interfaces de la mquina virtual Clases e interfaces de utilidades estndar
Tabla 5.5: Libreras del MIDP Prole.
5.3
Requerimientos Funcionales Para Detectar una Aplicacin J2ME
Los dispositivos deben proporcionar mecanismos mediante los cuales se puedan encontrar los MIDlets que se desean descargar. En algunos casos, se pueden encontrar los MIDlets a travs de un navegador WAP o a travs de una aplicacin residente escrita especcamente para identicar MIDlets. Otros mecanismos como Bluetooth, cable serie, etc, pueden ser soportados por el dispositivo y a partir de estas conexiones se pueden instalar aplicaciones (MIDlets).
5.4. LOS MIDLETS
115
El programa encargado de manejar la descarga y ciclo de vida de los MIDlets en el dispositivo se llama Gestor de Aplicaciones o AMS (Application Management Software). Un dispositivo que posea la especicacin MIDP debe ser capaz de: Localizar archivos JAD vinculados a un MIDlet en la red. Descargar el MIDlet y el archivo JAD al dispositivo desde un servidor usando el protocolo HTTP 1.1 u otro que posea su funcionalidad. Enviar el nombre de usuario y contrasea cuando se produzca una respuesta HTTP por parte del servidor 401 (Unauthorized) o 407 (Proxy Authentication Required). Instalar el MIDlet en el dispositivo. Ejecutar MIDlets. Permitir al usuario borrar MIDlets instalados.
5.4
Los MIDlets
Los MIDlets son aplicaciones creadas usando la especicacin MIDP. Estn diseados para ser ejecutados en dispositivos con poca capacidad grca, de cmputo y de memoria. Las clases de un MIDLet, son almacenadas en bytecodes Java, dentro de un chero .class. Estas clases deben ser vericadas antes de su puesta en marcha, para garantizar que no realizan ninguna operacin no permitida. Este prevericacin, se debe hacer debido a las limitaciones de la mquina virtual usada en estos dispositivos [14]. Para mantener a la mquina virtual lo ms sencilla y pequea posible, se elimina esta vericacin, y se realiza antes de la entrada en produccin. La prevericacin se realiza despus de la compilacin, y el resultado es una nueva clase, lista para ser puesta en produccin. Los MIDLets son empaquetados en cheros .jar .
116
Existen 2 cheros que contienen informacin extra dentro del .jar para la puesta en marcha de la aplicacin, el chero maniesto, con extensin .mf y un chero descriptor, con extensin .jad. Un chero .jar tpico, por tanto, se compondr de: Clases del MIDLet. Clases de soporte. Recursos (imgenes, sonidos, etc.). Maniesto (chero .mf). Descriptor (chero .jad).
5.4.1
El Gestor de Aplicaciones
El gestor de aplicaciones o AMS (Application Management System) es el software encargado de gestionar los MIDlets. Este software reside en el dispositivo y es el que permite ejecutar, pausar o destruir aplicaciones J2ME. El AMS realiza dos grandes funciones: Por un lado gestiona el ciclo de vida de los MIDlets. Por otro, es el encargado de controlar los estados por los que pasa el MIDlet mientras est en ejecucin.
5.4.2
Ciclo de Vida de un Midlet
Como puede ilustrarse en la g. 5.5 de la pg. 117 el ciclo de vida de un MIDlet pasa por cinco fases: Descubrimiento o localizacin; instalacin; ejecucin; actualizacin y borrado. El AMS es el encargado de gestionar cada una de estas fases de la siguiente manera: 1. Localizacin: Esta fase es la etapa previa a la instalacin del MIDlet y es donde se selecciona a travs del gestor de aplicaciones la aplicacin
5.4. LOS MIDLETS
117
Figura 5.5: Ciclo Vida de un MIDlet. a descargar. Por tanto, el gestor de aplicaciones tiene que proporcionar los mecanismos necesarios para realizar la eleccin del MIDlet a descargar. El AMS puede ser capaz de realizar la descarga de aplicaciones de diferentes maneras, dependiendo de las capacidades del dispositivo. Por ejemplo, esta descarga se debe poder realizar mediante un cable conectado a un ordenador o mediante una conexin inalmbrica. 2. Instalacin: En esta fase el gestor de aplicaciones controla todo el proceso de instalacin del MIDlet informando al usuario tanto de la evolucin de la instalacin como de si existiese algn problema durante sta. 3. Ejecucin: Mediante el gestor de aplicaciones se va a poder iniciar la ejecucin de los MIDlets. En esta fase, el AMS tiene la funcin de gestionar los estados del MIDlet en funcin de los eventos que se produzcan durante esta ejecucin. 4. Actualizacin: El AMS tiene que tener la capacidad de detectar si el MIDlet a instalar es una actualizacin de alguno ya existente, en cuyo caso deber informar de la situacin y permitir la actualizacin del MIDlet. 5. Borrado: Una vez instalado el MIDlet en el dispositivo, este permanece
118
Figura 5.6: Estados de un MIDlet.
almacenado en la memoria persistente todo el tiempo hasta que el usuario decida borrarlo.
El AMS es el encargado de eliminar el MIDlet pidiendo una conrmacin del proceso antes de continuar.
5.4.3
Estados de un MIDlet
Adems de gestionar el ciclo de vida de los MIDlets, el AMS es el encargado de controlar los estados del MIDlet durante su ejecucin. Durante sta el MIDlet es cargado en la memoria del dispositivo y es aqu donde puede transitar entre 3 estados diferentes: activo, en pausa y destruido como puede apreciarse en la g. 5.6 de la pg. 118. Como se puede ver en la g. 5.6 de la pg. 5.6, un MIDlet puede cambiar de estado mediante una llamada a los mtodos MIDlet.startApp(), MIDlet.pauseApp() o MIDlet.destroyApp(). El gestor de aplicaciones cambia el estado de los MIDlets haciendo una llamada a cualquiera de los mtodos anteriores. Un MIDlet tambin puede cambiar de estado por s mismo.
5.4. LOS MIDLETS
119
5.4.4
El paquete javax.microedition.midlet
El paquete javax.microedition.midlet dene las aplicaciones MIDP y su comportamiento con respecto al entorno de ejecucin. En la tabla 5.6 de la pg. 119 se puede apreciar cules son las clases que estn incluidas en este paquete. Clases MIDlet MIDletstateChangeException Descripcin Aplicacin MIDP Indica que el cambio de estado ha fallado
Tabla 5.6: Clases del Paquete javax.microedition.midlet.
5.4.5
La Clase MIDlet
Como se ha mencionado con anterioridad, un MIDlet es una aplicacin realizada usando el perl MIDP. La aplicacin desarrollada debe extender o heredar de esta clase para que el gestor de aplicaciones o AMS pueda gestionar sus estados y tener acceso a sus propiedades. Los mtodos de los que dispone esta clase son los siguientes: protected MIDlet() Constructor de clase sin argumentos. Si la llamada a este constructor falla, se lanzara la excepcin SecurityException. public nal int checkPermission(String permiso) Con este mtodo se consigue un nmero que determina el permiso especicado. Este permiso est descrito en el atributo MIDlet-Permission del archivo JAD. Los valores que puede arrojar este mtodo son:
120
0 si el permiso es denegado. 1 si el permiso es permitido. -1 si el estado es desconocido. protected abstract void destroyApp(boolean incondicional) throws MIDletstateChangeException Indica la terminacin del MIDlet y su paso al estado de Destruido. En el estado de Destruido el MIDlet debe liberar todos los recursos y salvar cualquier dato en el almacenamiento persistente que deba ser guardado. Este mtodo puede ser llamado desde los estados Pausa o Activo. public nal String getAppProperty(String key) Este mtodo proporciona al MIDlet un mecanismo que le permite recuperar el valor de las propiedades desde el AMS. Las propiedades se consiguen por medio de los archivos manifest y JAD. El nombre de la propiedad a recuperar debe ir indicado en el parmetro key. public nal void notifyDestroyed() Con este mtodo se notica al AMS que el MIDlet no quiere estar Activo y que ha entrado en el estado de Pausa. Este mtodo slo debe ser invocado cuando el MIDlet est en el estado Activo. Si la aplicacin es pausada por s misma, es necesario llamar al mtodo MIDlet.resumeRequest() para volver al estado Activo. protected abstract void pauseApp() Indica al MIDlet que entre en el estado de Pausa. Este mtodo slo debe ser llamado cundo el MIDlet est en estado Activo. public nal boolean platformRequest(String url)
5.4. LOS MIDLETS
121
Establece una conexin entre el MIDlet y la direccin URL. Dependiendo del contenido de la URL, el dispositivo ejecutar una determinada aplicacin que sea capaz de leer el contenido y dejar al usuario que interacte con l. protected abstract void startApp() throws MIDletstateChangeException Este mtodo indica al MIDlet que ha entrado en el estado Activo. Este mtodo slo puede ser invocado cundo el MIDlet est en el estado de Pausa. En el caso de que el MIDlet no pueda pasar al estado Activo en este momento pero s pueda hacerlo en un momento posterior, se lanzara la excepcin MIDletstateChangeException. Los mtodos anteriormente mencionados se utilizan para la comunicacin entre el MIDlet y el AMS. Por un lado se tiene que los mtodos startApp(), pauseApp() y destroyApp() los utiliza el AMS para comunicarse con el MIDlet, mientras que los mtodos resumeRequest(), notifyPaused() y notifyDestroyed() los utiliza el MIDlet para comunicarse con el AMS.
5.4.6
Estructura de los MIDlets
Es posible decir que los MIDlets, al igual que los applets carecen de la funcin main(). Aunque existiese dicha funcin, el gestor de aplicaciones la ignorara por completo. Un MIDlet tampoco puede realizar una llamada a System.exit(). Una llamada a este mtodo lanzara la excepcin SecurityException. Los MIDlets tienen la siguiente estructura:
import javax.microedition.midlet.*; public class MiMidlet extends MIDlet{ public MiMidlet() { /* ste es el constructor de clase. Aqu se deben * inicializar las variables. */ } public startApp(){
122
/* Aqu se pueden incluir el cdigo que el * MIDlet ejecute cundo se active. */ } public pauseApp(){ /* Aqu se puede incluir el cdigo que el * MIDlet ejecute cundo entre en el estado de pausa * es opcional */ } public destroyApp(){ /* Aqu se puede incluir el cdigo que el * MIDlet ejecute cundo sea destruido. Normalmente * aqu se liberaran los recursos ocupados por el * MIDlet como memoria, etc. * es opcional */ } }// n de la clase MiMidlet
Un pequeo ejemplo de una aplicacin simple se puede apreciar a continuacin.

import javax.microedition.midlet.*; import javax.microedition.lcdui.*; public class HolaMundo extends MIDlet{ private Display pantalla; private Form formulario = null; public HolaMundo(){ pantalla = Display.getDisplay(this); formulario = new Form(Hola Mundo);
5.5. INTERFACES GRFICAS DE USUARIO
123
} public void startApp(){ pantalla.setCurrent(formulario); } public void pauseApp(){ } public void destroyApp(boolean unconditional){ pantalla = null; formulario = null; notifyDestroyed(); } }
Estos mtodos son los que obligatoriamente tienen que poseer todos los MIDlets ya que, como se ha visto, la clase que se ha creado tiene que heredar de la clase MIDlet y sta posee tres mtodos abstractos: startApp(), pauseApp() y destroyApp() que han de ser implementados por cualquier MIDlet.
5.5
Interfaces Grcas de Usuario
Teniendo en cuenta la diversidad de aplicaciones que se pueden realizar para los dispositivos MID y los elementos que proporcionan tanto la conguracin CLDC como el perl MIDP se pueden clasicar a los elementos en dos grandes grupos: Por un lado existen los elementos que corresponden a la interfaz de usuario de alto nivel. Esta interfaz usa componentes tales como botones, cajas de texto, formularios, etc. La nalidad de usar estas APIs de alto nivel es su portabilidad. Al utilizar esta interfaz de usuario se pierde el control del aspecto de las aplicaciones desarrolladas, ya que la esttica depende exclusivamente del dispositivo donde se ejecute. La ventaja de la utilizacin de esta interfaz de usuario de alto nivel es la gran portabilidad que se consigue. Generalmente esta interfaz es utilizada para la creacin de aplicaciones de negocios.
124
Figura 5.7: Jerarqua de Clases. Por otro lado existen los elementos que forman parte de la interfaz de usuario de bajo nivel. Al utilizar las APIs de bajo nivel se puede tener un control total de todo lo que est dibujado en la pantalla, adems se pueden manejar eventos de bajo nivel, tales como pulsaciones de las teclas. Esta interfaz es ms adecuada para el desarrollo de juegos. El paquete javax.microedition.lcdui denido en el perl MIDP incluye las clases necesarias para crear interfaces de usuario, tanto de alto nivel como de bajo nivel. En la g. 5.7 de la pg. 124se puede apreciar la organizacin de estas clases.
5.5.1
La Clase Display
La clase Display representa el manejador de la pantalla y los dispositivos de entrada. Todo MIDlet debe poseer por lo menos un objeto Display. En este objeto Display se puede incluir tantos objetos Displayable como se desee. La clase Display puede obtener informacin sobre las caractersticas de la pantalla del dispositivo donde se ejecute el MIDlet. En la tabla 5.7 de la pg. 126 se puede ver los mtodos incluidos en esta
125
clase.
5.5.2
La Clase Displayable
La clase Displayable representa a las pantallas de la aplicacin. Como se mencion anteriormente, cada objeto Display puede contener tantos objetos displayables como se desee. Mediante los mtodos getCurrent y setCurrent se controlan las pantallas para que sean visibles y accesibles en cada momento. La clase abstracta Displayable incluye los mtodos encargados de manejar los eventos de pantalla y aadir o eliminar comandos. Estos mtodos aparecen en la tabla 5.8 de la pg. 127.
5.5.3
Las Clases Command y CommandListener
Un objeto de la clase Command mantiene informacin sobre un evento. Por establecer una analoga se puede pensar a un objeto Command como un botn de Windows. Se implementan en los MIDlets para poder detectar y ejecutar una accin simple. Existen tres parmetros que hay que denir al constuir un Command: Etiqueta: La etiqueta es la cadena de texto que aparecer en la pantalla del dispositivo que identicar a el Command. Tipo: La declaracin del tipo sirve para que el dispositivo identique el Command y le d una apariencia especca acorde con el resto de aplicaciones existentes en el dispositivo. Prioridades: Esto puede servirle al AMS para establecer un orden de aparicin de los Command en pantalla. A mayor nmero, menor prioridad. Los tipos que se pueden asignar aparecen en la tabla 5.9de la pg 127.
126
Mtodos void callSerially (Runnable r) boolean ashBacklight (int duracion) int getBestImageHeight (int imagen) int getBestImageWidth (int imagen) int getBorderStyle (bolean luminosidad) int getColor (int color) Displayable getCurrent() static Display getDisplay (MIDlet m) boolean isColor() int numAlphaLevels() int numColors() void setCurrent (Alert a, Displayable d) void setCurrent (Displayable d) void setCurrent (Item item) boolean vibrate (int duracion)
Descripcin Retrasa la ejecucin del mtodo run() del objeto r Provoca un efecto de ash en la pantalla Devuelve el mejor alto de imagen Devuelve el mejor ancho de imagen Devuelve el estilo de borde actual Devuelve un color basado en el parmetro pasado Devuelve la pantalla actual Devuelve una referencia a la pantalla del MIDlet m Devuelve true o false si la pantalla es de color o b/n Devuelve el nmero de niveles alpha soportados Devuelve el nmero de colores Establece la pantalla d despues de la alerta a Establece la pantalla actual Establece en la pantalla al item Realiza la operacin de vibracin del dispositivo
Tabla 5.7: Mtodos de la Clase Display.
127
Mtodos void addCommand (Command cmd) int getHeight() Ticker getTicker() String getTitle() int getWidth() bolean isShown() void removeCommand (Command cmd) void setCommandListener (CommandListener l) protected void sizeChanged (int w, int h) void setTicker(Ticker ticker) void setTitle(String title)
Descripcin aade el Command cmd Devuelve el alto de la pantalla Devuelve el Ticker asignado a la pantalla Devuelve el ttulo de la pantalla Devuelve el ancho de la pantalla Devuelve true si la pantalla est activa Elimina el Commando cmd de la pantalla Establece un Listener para la captura de eventos El AMS llama a este mtodo cundo el rea disponible para el objeto Displayable es modicada Establece un Ticker a la pantalla Establece un ttulo a la pantalla
Tabla 5.8: Mtodos de la Clase Displayable.
Tipo BACK CANCEL EXIT HELP ITEM OK SCREEN STOP
Descripcin Peticin para volver a la pantalla anterior Peticin para cancelar la accin en curso Peticin para salir de la aplicacin Peticin para mostrar informacin de ayuda Peticin para introducir el comando en un Item en la pantalla Aceptacin de una accin por parte del usuario Para comandos de propsito ms general Peticin para parar una operacin un Listener para la captura de eventos
Tabla 5.9: Tipos de Commands.
128
Ejemplo de un Command con la etiqueta Atras:

new Command(Atras,Command.BACK,1)
La tabla 5.10 de la pg. 128 muestra los mtodos de la clase Command. Mtodo public int getCommandType() public String getLabel() public String getLongLabel() public int getPriority() Devuelve el tipo del Command Peticin para volver a la pantalla anterior Devuelva la etiqueta del Command Devuelve la etiqueta larga del Command Devuelve la prioridad del Command
Tabla 5.10: Mtodos de la Clase Command. No solo basta con crear objetos Command, para poder controlar algn evento de la aplicacin. Otra tarea pendiente es implementar la interfaz CommandListener, la cual dene un mtodo abstracto llamado CommandAction(Command d, Displayable d), donde debe ser implentado dicho mtodo, ya que una interfaz slo dene mtodos abstractos, es tarea de la clase que implementa dicha interfaz tener que implementar los mtodos denidos. A travs de la implementacin del mtodo CommandAction se podrn manejar los eventos que lanza el Command c que se encuentran en el objeto Displayable d.
5.5.4
Interfaz de Usuario de Alto Nivel
Para comenzar se ver la clase Screen que es la superclase de todas las clases que conforman la interfaz de usuario de alto nivel:
public abstract class Screen extends Displayable
En la especicacin MIDP 1.0 esta clase contena cuatro mtodos que le permitan denir y obtener el ttulo y el ticker: setTitle(String s), getTitle(), setTicker(Ticket ticker) y getTicker(). El ticker es una cadena de texto que se desplaza por la pantalla de derecha a izquierda. En la especicacin MIDP 2.0, que es la ms reciente, estos cuatro mtodos han sido incluidos en la clase Displayable.
129
La Clase Alert El objeto Alert representa una pantalla de aviso. Normalmente se usa cuando se quiere avisar al usuario de una situacin especial como, por ejemplo, un error. Para crear Alert se dispone de 2 constructores de acuerdo a su apariencia: Alert(String titulo). Alert(String titulo, String textoalerta, Image imagen, AlertType tipo). Existen dos tipos de alertas: 1. Modal : Este tipo de alerta permanece un tiempo indeterminado en la pantalla hasta que el usuario la cancela. Se obtiene llamando al mtodo Alert. setTimeOut (Alert. FOREVER). 2. No modal : Este tipo de alerta permanecer por un tiempo denido por el usuario y luego desaparecer. Para ello se indica el tiempo en el mtodo setTimeOut(tiempo), el tiempo expresado en milisegundos. Tambin se puede elegir el tipo de alerta que se va a mostrar. Cada tipo de alerta tiene asociado un sonido. Los tipos que se pueden denir aparecen en la tabla 5.11 de la pg. 129. Mtodo ALARM CONFIRMATION ERROR INFO WARNING Devuelve el tipo del Command Aviso de una Peticin previa Indica la aceptaci de una acci Indica que ha ocurrido un error Indica algn tipo de informacin Indica que puede ocurrir algn problema
Tabla 5.11: Tipos de Alerta.
130
La Clase List La clase List hereda de la clase Screen, pero presenta una funcionalidad ms amplia que la clase Alert. La clase List proporciona una pantalla que contiene una lista de elementos sobre los que el usuario puede seleccionar. Esta clase implementa la interfaz Choice, que dene constantes que describen tres tipos bsicos de listas de opciones: EXCLUSIVE: Una lista que permite seleccionar un solo elemento a la vez. IMPLICIT: Un lista en la que la seleccin de un elemento provoca un evento (se adapta para la creacin de mens). MLTIPLE: Una lista que permite seleccionar uno o ms elementos a la vez. Existen dos constructores que permiten construir listas: el primero de ellos crea una lista vaca y el segundo proporciona una lista con un conjunto inicial de opciones y de imgenes asociadas: List(String titulo, int listType). List(String titulo, int listType, String[] elementos, Image[] imagenes). En la siguiente tabla 5.12 de la pg. 131 se puede observar los distintos mtodos de la clase List. La Clase TextBox La clase TextBox implementa un componente de edicin de texto, que ocupa toda la pantalla. El constructor de la clase es: TextBox(String title, String text, int maxSize, int constraints) El parmetro title es un texto que aparecer en la parte superior de la pantalla, mientras que el parmetro text es usado para inicializar el texto que contendr el TextBox.
131
Mtodos int append(String texto, Image imagen) void delete(int posicin) void deleteAll() void insert(int pos, String texto, Image im) int getFitPolicy() Font getFont(int pos) Image getImage(int pos) int getSelectedFlags (bolean[] array) int getSelectedIndex() String getString(int pos) boolean isSelected(int pos) void removeCommand (Command cmd) void set(int pos, String texto, Image im) void setFitPolicy(int modo) void setFont (int pos, Font fuente) void setSelectCommand (Command cmd) int setSelectedFlags (bolean[] array) int setSelectedIndex(int pos, boolean selec) int size()
Descripcin Aade un elemento al nal de la lista Elimina el elemento de la posicin especicada Elimina todas las entradas de la lista Inserta un elemento en la posicin especicada Devuelve el modo en el que se muestran las entradas de la lista por pantalla Devuelve la fuente del elemento pos Obtiene la imagen de una posicindeterminada Almacena el estado de seleccin en un array Obtiene el (i)ndice del elemento seleccionado Obtiene el texto del elemento indicado por pos Determina si est seleccionado (a) el elemento Elimina el comando cmd Reemplaza el elemento de la posicin pos Establece el modo de posicionar las entradas de la lista por pantalla Establece la fuente de la entrada indicada en pos Selecciona el Command a usar Reemplaza el estado de seleccin por el de array Reemplaza el estado de la seleccin Obtiene el nmero de elementos
Tabla 5.12: Mtodos de la Clase List.
132
El parmetro maxSize especica el nmero mximo de caracteres de texto que pueden ser introducidos en el TextBox. Por ltimo el parmetro constraints describe las limitaciones a aplicar sobre el texto. Estas limitaciones son especicadas segn las constantes denidas en la clase TextField: ANY: No hay limitaciones en el texto. EMAILADDR: Slo se puede introducir una direccin de correo electrnico. NUMERIC: Slo se puede introducir un valor numrico. PASSWORD: El texto es protegido para que no sea visible. PHONENUMBER: Slo se puede introducir un nmero de telfono. URL: Slo se puede introducir una URL. Un ejemplo de uso sera: TextBox box = new TextBox(NOTAS, Nota: , 256, TextField.ANY). La Clase Form Un formulario (clase Form) es un componente que acta como contenedor de un nmero indeterminado de objetos. Todos los objetos que puede contener un formulario derivan de la clase Item. El nmero de objetos que se pueden insertar en un formulario es variable pero, teniendo en cuenta el tamao de las pantallas de los dispositivos MID, se recomienda que el nmero sea pequeo para evitar as el scroll que se producira si se insertan demasiados objetos en un formulario. Un mismo Item no puede estar en ms de un formulario a la vez. Si, por ejemplo, se desea usar una misma imagen en ms de un formulario, se debe borrar esa imagen de un formulario antes de insertarla en el que se va a mostrar por pantalla.
133
Si no se cumple esta regla, se lanzara la excepcin IllegalStateException. La tabla 5.13 de la pg.133 muestra los mtodos de la clase Form. Mtodos int append(Image imagen) int append(Item item) int append(String texto) void delete(int num) void deleteAll() Item get(int num) int getHeight() int getWidth() void insert(int num, Item item) void set(int num, Item item) boolean isSelected(int pos) void setItemStateListener (ItemStateListener listener int size() Descripcin Aade una imagen al formulario Aade un item al formulario Aade un String al formulario Elimina el Item que ocupa la posicin num Elimina todos los Items del formulario Devuelve el Item que se encuentra en la posici (o)n num Devuelve la altura del rea disponible para los Items Devuelve la anchura del rea disponible para los Items Inserta un Item justo antes del que ocupa la posicin num Reemplaza el Item que ocupa la posici (o)n num Determina si est seleccionado el elemento Establece un listener eventos capturar Devuelve el nmero de Items del formulario
Tabla 5.13: Mtodos de la Clase Form.
Manejo de Eventos El manejo de eventos en un formulario es muy similar al manejo de eventos de los Command vistos anteriormente. Nada ms que para un formulario se tiene que implementar la interfaz ItemStateListener que contiene un mtodo abstracto llamado itemStateChanged(Item item). Cuando se realiza algn tipo de accin en el algn tem del formulario se
134
ejecuta el cdigo asociado del mtodo itemStateChanged(Item item). Un ejemplo de su utilizacin se puede observar a continuacin:
import javax.microedition.midlet.*; import javax.microedition.lcdui.*; public class ManejoItems extends MIDlet implements ItemStateListener, CommandListener{ Display pantalla; Form formulario; TextField txt; Command salir; public ManejoItems(){ pantalla = Display.getDisplay(this); formulario = new Form(); txt = new TextField(Introduce datos,,70,TextField.ANY); salir = new Command(Salir,Command.EXIT,1); formulario.append(txt); formulario.addCommand(salir); formulario.setItemStateListener(this); formulario.setCommandListener(this); public void startApp() { pantalla.setCurrent(formulario); } public void pauseApp() { } public void destroyApp(boolean unconditional) { } public void commandAction(Command c, Displayable d){ if (i == txt){ System.out.println(Evento detectado en el TextBox); } } }
135
La Clase StringItem La clase StringItem es la clase ms simple que deriva de Item. Es una cadena no modicable de texto, es decir, una cadena de texto con la que el usuario no puede interactuar de ninguna manera. Para construir un StringItem se hace uso de cualquiera de sus dos constructores: StringItem(String etiqueta, String texto). StringItem(String etiqueta, String texto, int apariencia). Los parmetros: etiqueta: Es la etiqueta del tem. texto: Es el texto que contiene el tem. apariencia: Es la apariencia del texto: Item.PLAIN, Item.HYPERLINK, Item.BUTTON. Los mtodos que posee la clase StringItem aparecen en la tabla 5.14 de la pg. 135 Mtodos int getAppearanceMode() Font getFont() String getText() void setFont(Font fuente) void setText(String texto) Descripcin devuelve la apariencia del texto devuelve la Fuente del texto devuelve el texto del StringItem Establece la Fuente del texto Establece el texto del StringItem
Tabla 5.14: Mtodos de la Clase StringItem.
La Clase ImageItem La clase ImageItem brinda la posibilidad de incluir imgenes en un formulario.
136
Al igual que la clase StringItem, el usuario no podr interactuar con la imagen. Para crear un objeto ImageItem se pueden usar uno de sus dos constructores: ImageItem(String etiqueta, Image imagen, int layout, String textoalt). ImageItem(String etiqueta, Image imagen, int layout, String textoalt, int apariencia). El parmetro textoalt especica una cadena de texto alternativa a la imagen en caso de que sta exceda la capacidad de la pantalla. Por su parte, el parmetro layout indica la posicin de la imagen en la pantalla. Los valores que puede tomar son: LAYOUT_LEFT: Imagen posicionada a la izquierda. LAYOUT_RIGHT: Imagen posicionada a la derecha. LAYOUT_CENTER: Imagen centrada. LAYOUT_DEFAULT : Posicin por defecto. LAYOUT_NEWLINE_AFTER: Imagen posicionada tras un salto de lnea. LAYOUT_NEWLINE_BEFORE: Imagen posicionada antes de un salto de lnea. Los mtodos de la clase ImageItem se pueden ver en la tabla 5.15 de la pg. 137. La Clase TextField Un texeld es un campo de texto que puede ser insertado en un formulario y en el cul se puede editar texto. Tiene similitud con la clase TextBox. Sus diferencias son:
5.6. RMS (RECORD MANAGEMENT SYSTEM)
137
Mtodos String getAltText() Int getAppearanceMode() Image getImage() Int getLayout() void setAltText(String textoalt) void setImage(Image imagen) void setLayout(int layout)
Descripcin devuelve la cadena de texto alternativa devuelve la apariencia devuelve la imagen devuelve el posicionado de la imagen Establece un texto alternativo Establece una nueva imagen Establece un nuevo posicionado en pantalla
Tabla 5.15: Mtodos de la Clase ImageItem. Un texeld tiene que ser insertado en un formulario, a diferencia de un textbox puede existir por s mismo. TextField deriva de la clase Item, mientras que TextBox deriva directamente de Screen, y sus eventos se controlan a travs de Commands. Por esta razn, los eventos que produce un TextField se controlan a travs del mtodo itemStateChanged(Item item), mientras que en un TextBox se controlan en el mtodo commandAction(Command c, Displayable d). Sin embargo ambas clases (TextBox y TextField) comparten las mismas restricciones de edicin que se vieron anteriormente. Para crear un TextField slo hay que invocar al constructor con los siguientes parmetros: TextField(String etiqueta, String texto, int capacidad, int restricciones). Otros mtodos de esta clase pueden verse en la tabla 5.16 de la pg. 138
5.6
RMS (Record Management System)
El sistema de gestin de registros (Record Management System, RMS ) se compone de una serie de clases e interfaces que proporcionan soporte a un sistema simple de base de datos que es usado para almacenar informacin.
138
Mtodos void delete(int desplazamiento, int longitud) int getCaretPosition() Image getImage() int getChars(char[] datos) int getConstraints() int getMaxSize() String getString() void insert(char[] datos, int des, int long, int pos) void insert(char[] datos, int pos) void setChars(char[] datos, int des, int long) void setConstraints (int restricciones) void setInitialInputMode (String caracteres) int setMaxSize(int capacidad) void setString(String texto) void setString(String texto) int size()
Descripcin Borra caracteres del TextField Devuelve la posici n del cursor en pantalla devuelve la imagen Copia el contenido del TextField en datos Devuelve las restricciones de entrada Devuelve el tamao mximo del TextField. Devuelve el contenido del TextField Inserta un subrango de caracteres de datos en el TextField Inserta la cadena de caracteres datos en una posicin determinada Reemplaza el contenido del TextField por un subconjunto de caracteres de datos Establece las restricciones de entrada Establece un tipo de entrada inicial Establece el tamao mximo del TextField Establece el contenido del TextField Establece el contenido del TextField Devuelve el nmero de caracteres
Tabla 5.16: Mtodos de la Clase TextField.
139
El objetivo del RMS es almacenar datos de tal forma que estn disponibles una vez que el MIDlet pare su ejecucin. La unidad bsica de almacenamiento es el registro (record) que ser almacenado en un base de datos especial, denominada almacn de registros (record store ). Cuando un MIDlet usa un almacn de registros, primero debe crearlo y luego aadir los registros. Cuando un registro es aadido a un almacn de registros, se le asigna un identicador nico (id) [14].
5.6.1
Modelo de Datos
Como ya se ha dicho, el RMS est implementado en una base de datos basada en registros; ver g. 5.8 de la pg. 139.
Figura 5.8: Un MIDlet y el RMS. Los MIDlets son los encargados de crear los Record Stores para poder comunicarse con ellos. Estos Record Stores quedan almacenados en el dispositivo y pueden ser accedidos por cualquier MIDlet que pertenezca a la misma suite, es decir pertenezcan al mismo grupo, como se puede ver en la g. 5.9 de la
140
pg 140.
Figura 5.9: Acceso a un RMS a Travs de un MIDlet Suite.
5.6.2
Record Stores
Las propiedades de estos almacenes de registros son: 1. Cada Record Store est compuesto por cero o ms registros. 2. El nombre puede tener un mximo de 32 caracteres. 3. Si una suite es borrada, todos los Record Store tambin se borran. 4. Un Midlet no perteneciente a la suite puede acceder al Record Store, siempre que ste lo permita. 5. No pueden coexistir dos Record Stores con el mismo nombre dentro de una MIDlet suite. Entonces se puede decir que un Record Store es un almacn de registros, donde stos registros son la unidad bsica de informacin.
141
Figura 5.10: Esturctura de Un Record Store. Cada uno de estos registros est formado por dos unidades: Un nmero identicador de registro (Record ID) que es un valor entero que realiza la funcin de clave primaria en la base de datos. Un array de bytes destinados a almacenar la informacin deseada. En la g. 5.10 de la pg. 141 se ilustra la estructura de un Record Store.
5.6.3
Creacin de un Record Store
El API de MIDP incluye un paquete para el RMS , llamado javax.microedition.rms. Este paquete incluye clases e interfaces que proporcionan un marco de trabajo para los registros, los almacenes y otras caractersticas. Bsicamente se dispone de: Capacidad para aadir y borrar registros de un almacn. Capacidad para compartir almacenes por parte de todos los MIDlets de una MIDlet suite. La clase RecordStore no dispone de ningn constructor, pero posee el mtodo esttico: static RecordStore openRecordStore(String name, Boolean createIfNeccesary).
142
Este mtodo permite la apertura de un Record Store existente o bien la creacin de un almacn si el parmetro createIfNeccesary tiene el valor true. Tambin existen otras dos alternativas de este mtodo: static RecordStore openRecordStore(String name, boolean createIfNeccesary,
int autorizacin, boolean writable).
static RecordStore openRecordStore(String name, String vendorName, String

suiteName).
El primero de ello usa los siguientes parmetros: autorizacin: AUTHMODE_PRIVATE : Slo permite el acceso al Record Store a la MIDlet suite que lo cre AUTHMODE_ANY : Permite el acceso a cualquier MIDlet del dispositivo. writable: Este modo especica si el Record Store puede ser modicado por cualquier MIDlet que pueda acceder a el. El segundo mtodo se utiliza para abrir un Record Store que est asociado a alguna MIDlet suite especicada por los parmetros vendorName y suiteName. El acceso vendr limitado por el tipo de autorizacin del Record Store cuando fue creado. Al nalizar con el uso de un determinado Record Store hay que cerrar la comunicacin con l. Para ello se utiliza el siguiente mtodo: public void closeRecordStore() throws RecordStoreNotFoundException, RecordStoreException.
En la tabla 5.17 de la pg. 143 se pueden apreciar los mtodos que proporcionan operaciones con los Record Stores.
143
Mtodos String getName() int getVersion() long getLastModied() int getNumRecords() int getSize() int getSizeAvailable() String[] listRecordStores() void deleteRecordStore (String name) RecordEnumeration enumerateRecords(RecordFilter lter, RecordComparator comparator, boolean actualizado) void addRecordListener (RecordListener listener) void removeRecordListener (RecordListener listener)
Descripcin Devuelve el nombre del Record Store Devuelve la versi n del Record Store Devuelve la marca temporal Devuelve el nmero de registros Devuelve el nmero de bytes ocupado por el Record Store Devuelve el tama (n)o disponible para aadir registros Devuelve una lista con los nombres de los Record Stores Elimina del dispositivo al Record Store especicado por el parmetro name devuelve un objeto RecordEnumeration
Aade un listener para detectar cambios en el Record Store Elimina un listener
Tabla 5.17: Mtodos Generales de la Clase RecordStore.
144
5.6.4
Manipulacin de Registros
Una vez creado o abierta la comunicacin con el Record Store, se puede leer, escribir, modicar o borrar registros como se desee. Para ello, se usan los mtodos de la clase RecordStore que se ven en la tabla 5.18 de la pg.144. Mtodos int addRecord(byte[] datos, int oset, int numBytes) void deleteRecord(int id) Int getNextRecordId() byte[] getRecord(int id) int getRecord(int id, byte[] buer,int oset) int getRecordSize(int id) void setRecord(int id,byte[] datonuevo, int oset, int tamao) Descripcin Aade un registro al Record Store Borra el registro id del Record Store Devuelve el siguiente id del registro que se vaya a insertar Devuelve el registro con identicador id Devuelve el registro con identicador id en buer a partir de oset Devuelve el tama (n)o del registro id Sustituye el registro id con el valor de datonuevo
Tabla 5.18: Mtodos Para Manejo de Registros. A continuacin se mostrar un ejemplo que utiliza un Record Store de jugadores, donde se pueden ingresar nuevos jugadores y su puntaje obtenido.
import javax.microedition.midlet.MIDlet; import javax.microedition.midlet.MIDletStateChangeException; import javax.microedition.lcdui.*; import javax.microedition.rms.*; import java.io.*; public class Rms extends MIDlet implements CommandListener{ protected Display d; protected Form form; protected TextField textField;
145
protected TextField textField1; protected Command ingresar, volver; protected Alert alert; protected TextField textField2; private RecordStore rs; protected List list; protected Form form2; protected String[] respuesta; // metodo para iniciar la aplicacion, aqui se inicializa el objeto display y se // muestra primeramente el menu como pantalla principal protected void startApp() throws MIDletStateChangeException { d = Display.getDisplay(this); d.setCurrent(getList()); } protected void pauseApp() { } protected void destroyApp(boolean ag) throws MIDletStateChangeException { } // este mtodo arma el formulario y retorna para poder ser mostrado protected Form getForm() { if (form == null) { form = new Form(Nuevo Puntaje); form.append(getTextField()); form.append(getTextField1()); form.append(getTextField2()); form.addCommand(getCommand()); form.addCommand(getBack()); form.setCommandListener(this); } return form; }
146
public TextField getTextField() { if (textField == null) { textField = new TextField(Nombre jugador, , 255, TextField.ANY); } return textField; } public TextField getTextField1() { if (textField1 == null) { textField1 = new TextField(documento,, 255, TextField.ANY); } return textField1; } public Command getCommand(){ if (ingresar == null){ ingresar = new Command(Cargar,Command.OK,1); } return ingresar; } public Command getBack(){ if (volver == null){ volver = new Command(Volver,Command.BACK,1); } return volver; } public void commandAction(Command c, Displayable dis){ if (c==list.SELECT_COMMAND){ if (list.getSelectedIndex()==0){ d.setCurrent(getForm()); }else{ //se llama al formulario de lectura .. form2 System.out.println(ok);
147
abrirRecordStore(); leerRegistro(); cerrarRecordStore(); } } if (c==ingresar){ cargarDatos(); d.setCurrent(getAlert()); textField.setString(); textField1.setString(); textField2.setString(); } if (c==volver){ d.setCurrent(getList()); } } public Alert getAlert() { if (alert == null) { alert = new Alert(informacion, Los datos se estan cargando espere..., null, AlertType.INFO); alert.setTimeout(3000); } return alert; public TextField getTextField2() { if (textField2 == null) { textField2 = new TextField(Puntaje, , 2, TextField.NUMERIC); } return textField2; }
148
private void cargarDatos(){ abrirRecordStore(); // luego se graban los datos y despues cierra la conexion escribirRegistro(textField.getString(), textField1.getString(),textField2.getString()); cerrarRecordStore(); } private void abrirRecordStore(){ try{ rs = RecordStore.openRecordStore(Clientes,true); }catch(RecordStoreException e){ System.out.println(Error al abrir el record store); } } private void cerrarRecordStore(){ try{ rs.closeRecordStore(); }catch(RecordStoreException e){ System.out.println(error al cerrar el recordstore); } } private void escribirRegistro(String cliente, String doc, String pun){ byte[] registro; ByteArrayOutputStream baos; DataOutputStream dos; try{ baos = new ByteArrayOutputStream();
149
dos = new DataOutputStream(baos); dos.writeUTF(cliente); dos.writeUTF(doc); dos.writeUTF(pun); dos.ush(); registro = baos.toByteArray(); rs.addRecord(registro,0,registro.length); baos.close(); dos.close(); }catch(Exception e){ System.out.println(error al insertar el registro); } } private void leerRegistro(){ ByteArrayInputStream bais; DataInputStream dis; byte[] registro = new byte[200]; try{ bais = new ByteArrayInputStream(registro); dis = new DataInputStream(bais); respuesta = new String[rs.getNumRecords()+ 1]; for (int i=1;i<=rs.getNumRecords();i++) {
rs.getRecord(i,registro,0); System.out.println(Registro: + i); respuesta[i]= Nombre: + dis.readUTF() + documento: + dis.readUTF()+ puntaje + dis.readUTF(); bais.reset(); }
150
bais.close(); dis.close(); }catch(Exception e){ System.out.println(error al leer registros); } registro = null; mostrarDatos(); } public List getList() { if (list == null) { list = new List(Menu, Choice.IMPLICIT); list.append(Cargar Datos,null); list.append(Leer Datos,null); list.setCommandListener(this); } return list; public Form getForm2() { if (form2 == null) { form2 = new Form(Lectura de Datos); for (int i=1;i<respuesta.length;i++) { form2.append(respuesta[i]); form2.addCommand(getBack()); form2.setCommandListener(this); }
151
return form2; } public void mostrarDatos(){ d.setCurrent(getForm2()); } }
En la g. 5.11 de la pg. 151 se puede apreciar las pantallas del ejemplo en un emulador de Nokia.
Figura 5.11: Ejemplo RMS.
5.6.5
Operaciones con Record Stores
En el ejemplo anteriormente visto se ha usado un simple bucle para recorrer los distintos registros del Record Store. El bucle es el siguiente:
for (int i=1;i<=rs.getNumRecords();i++){
152
longitud = rs.getRecordSize(i); registro = rs.getRecord(i); System.out.println(Registro +i+: + new String(registro,0,longitud));
Sin embargo, la clase RecordStore proporciona la interfaz RecordEnumeration que facilita sta tarea. Utilizando esta interfaz se puede sustituir el bucle anterior por el siguiente cdigo:
RecordEnumeration re = rs.enumerateRecords(null,null,false); while (re.hasNextElement()){ registro = re.nextRecord(); //se realizan las operaciones que se desean ... }
Como se puede ver, la navegacin por los registros usando RecordEnumeration es mucho ms intuitiva y permite realizar acciones como mover hacia delante o hacia atrs de una manera muy sencilla.
5.6.6
Bsqueda de Registros
Para realizar una bsqueda eciente de registros, se debe implementar la interfaz RecordFilter, esta interfaz se encarga de devolver slo los registros que coincidan con el patrn de bsqueda especicado. Para usar esta interfaz se debe implementar necesariamente el mtodo:
public boolean matches(byte [] candidato), el cual se encarga de comparar el registro candidato pasado como parmetro con el valor que se quiere buscar y devolver true en caso de que coincidan.
5.7. COMUNICACIONES EN J2ME
153
5.7
Comunicaciones en J2ME
A pesar de la cantidad de restricciones que soportan los dispositivos MID y tambin restricciones propias del lenguaje Java, la gran ventaja que posee este tipo de dispositivos es la posibilidad de estar siempre conectados. La posibilidad de llevar un dispositivo con poco tamao y que permita comunicarse en cualquier momento y lugar abre un abanico de posibilidades en el desarrollo de aplicaciones [14]. Las aplicaciones MIDP para trabajar en red utilizan las clases contenidas en los paquetes javax.microedition.io y java.io de la siguiente manera:
El primer paquete contiene numerosas clases que permitirn crear y manejar diferentes conexiones de red. Estas conexiones podrn usar diferentes formas de comunicacin: HTTP, datagramas, sockets, etc. El paquete java.io se encargar de proporcionar las clases necesarias para leer y escribir en estas conexiones.
En la g. 5.12 de la pg. 154 puede verse la jerarqua de clases que reciben el nombre de Generic Framework Conection (GFC). En la raz del rbol se encuentra la interfaz Connection que representa la conexin ms genrica y abstracta que se puede crear. El resto de interfaces que derivan de Connection representan los distintos tipos de conexiones que se pueden crear.
5.7.1
Clases y Conexiones del Generic Connection Framework
Lo que proporciona el Generic Connection Framework es una sola clase Connector que esconde los detalles de la conexin. Esta clase puede por s misma crear cualquier tipo de conexin: Archivos, Http, socket,etc.
154
Figura 5.12: Jerarqua de Interfaces. Clase Connector Como se he dicho anteriormente, el GCF proporciona la clase Connector que esconde los detalles de la conexin. De esta forma se pueden realizar cualquier tipo de conexin usando slo esta clase y sin preocuparnos de cmo se implementa el protocolo requerido. La conexin se realiza de la siguiente manera:
Connector.open(protocolo:direccin;parmetros);
Algunos ejemplo de invocacin son: Connector.open(http://direccionquesea.es); Connector.open(le://autoexec.bat); Connector.open(socket://direccion:0000); La clase Connector se encarga de buscar la clase especca que implemente el protocolo requerido. Si esta clase se encuentra, el mtodo open() devuelve
155
un objeto que implementa la interfaz Connection. En la tabla 5.19 de la pg. 155 se puede apreciar los mtodos de la clase Connector. Mtodos public static Connection open(String dir) public static Connection open(String dir,int modo public static Connection open( String dir, int mode, boolean tespera) public static DataInputStream openDataInputStream(String dir) public static DataOutputStream openDataOutputStream(String dir) public static InputStream openInputStream(String dir) public static OutputStream openOutputStream(String dir) Descripcin Crea y abre una conexin Crea y abre una conexin con permisos Crea y abre una conexin especicando el permiso y tiempo de espera Crea y abre una conexin de entrada devolviendo para ello un DataInputStream Crea y abre una conexi de [on salida a travs de un DataOutputStream Crea y abre una conexin de entrada usando un InputStream Crea y abre una conexin de salida devolviendo para ello un OutputStream
Tabla 5.19: Mtodos de la Clase Connector. Los tipos de permisos se pueden ver en la tabla 5.20 de la pg 156.
La Interfaz Connection La interfaz Connection se encuentra en lo ms alto de la jerarqua de interfaces del Generic Connection Framework, por lo que cualquier otra interfaz deriva de sta. Una conexin de tipo Connection se crea despus de que un objeto Connector invoque al mtodo open(). Como se dijo anteriormente, esta interfaz representa la conexin ms genrica posible por lo que dene un slo mtodo:
156
Modo READ READ_WRITE WRITE
Descripcin Permiso de solo lectura Permiso de lectura y escritura Permiso de solo escritura
Tabla 5.20: Tipos de Permisos.
public void close(), que realiza el cierre de la conexin.
Interfaz InputConnection La interfaz InputConnection representa una conexin basada en streams de entrada. Esta interfaz slo posee dos mtodos que devuelven objetos de tipo InputStreams (ver Tabla). En el siguiente ejemplo se ilustra cmo podra utilizarse este tipo de conexin: String url = www.midireccion.com; InputConnection conexin = (InputConnection)Connector.open(url); DataInputStream dis = conexion.openDataInputStream();
Interfaz OutputConnection La interfaz OutputConnection representa una conexin basada en streams de salida. Esta interfaz slo posee dos mtodos que devuelven objetos de tipo OutputStreams (ver Tabla). La conexin a travs de esta interfaz se realiza de la misma forma a la interfaz InputConnection.
157
Interfaz StreamConnection Esta interfaz representa una conexin basada en streams tanto de entrada como de salida. No aade ningn mtodo nuevo, si no que hereda los mtodos de los interfaces que estn por encima de l. Su nica misin en la jerarqua del GCF es representar un tipo de conexin cuyos datos pueden ser tratados como streams de bytes y en la que es posible leer y escribir. A continuacin un ejemplo de cmo podra utilizarse esta conexin:
StreamConnection sc = (StreamConnection)Connector.open(url); InputStream is = sc.openInputStream(); ByteArrayOutputStream baos = new ByteArrayOutputStream(); int c; while((c = is.read()) != -1){ baos.write(c); }
5.7.2
Comunicaciones HTTP
El protocolo HTTP es un protocolo de tipo peticin / respuesta. El funcionamiento de este protocolo es el siguiente: El cliente realiza una peticin al servidor y espera a que ste le enve una respuesta. Normalmente, esta comunicacin es la que suele realizarse entre un navegador web (cliente) y un servidor web (servidor). En este caso la comunicacin se realiza a travs de un MIDlet(cliente) y un Servlet(servidor) que recibir peticiones y devolver los resultados. Una conexin HTTP pasa por tres estados que se pueden ver en la g. 5.13de la pg 158.
Establecimiento de la Conexin En este estado es donde se van a establecer los parmetros de la comunicacin.
158
Establecimiento de conexin
Conectado
Sin Conexin
Figura 5.13: Estados de una Conexin HTTP.
159
El cliente prepara la peticin que va a realizar al servidor, adems de negociar con l una serie de parmetros como el formato, idioma, etc. Existen dos mtodos que pueden ser invocados. En la tabla 5.21 de la pg. 159 se pueden apreciar estos mtodos. Mtodo public void setRequestMethod(String tipo) public void setRequestProperty (String clave, String valor) Descripcin Establece el tipo de peticin Establece una propiedad de la peticin
Tabla 5.21: Mtodos en la Etapa de Establecimiento. El primer mtodo establece el tipo de peticin que se va a realizar. Esta peticin puede ser de los tipos indicados en la tabla 5.22 de la pg. 5.22. Tipo GET POST HEAD Descripcin Peticin de informacin en la que los datos se envan como parte del URL Peticin de informacin en la que los datos se envan aparte en un stream Peticin de metainformacin
Tabla 5.22: Tipos de peticiones. El segundo mtodo permite negociar entre el cliente y el servidor detalles de la peticin como, por ejemplo, idioma, formato, etc. Estos campos forman parte de la cabecera de la peticin. En la tabla 5.23 de la pg. 160 se pueden ver algunos de los ms importantes. Peticiones GET A continuacin se muestra un ejemplo en el que se prepara una conexin mediante la interfaz HttpConnection usando una peticin de tipo GET.
//se crea la conexin String url = http://www.midireccion.com/local?opcion=1&us=usuario&pass=1234;
160
Campo public void setRequestMethod (String tipo) User-Agent Content-Language Content-Length) Accept Connection
Descripcin Establece el tipo de peticin Tipo de contenido que devuelve el servidor Pais e idioma que usa el cliente Longitud de la petici n Formatos que acepta el cliente Indica al servidor si se quiere cerrar la conexin despus de la peticin o se quiere dejar abierta Sirve para controlar el almacenamiento de informacin Tiempo m ximo para respuesta del servidor Pregunta si el contenido solicitado se ha modicado desde una fecha dada
Cache-Control Expires If-Modied-Since
Tabla 5.23: Campos de la Cabezera.

HttpConnection hc = (HttpConnection)Connector.open(url); //se informa el tipo de conexin a realizar hc.setRequestMethod(HttpConnection.GET); // se establece algunos campos en la cabezera hc.setRequestProperty(User-Agent,Prole/MIDP-2.0 Conguration/CLDC-1.0); hc.setRequestProperty(Content-Language,es-ES);
Como puede apreciarse, la informacin sobre la peticin va incluida en la cabecera de la direccin URL. El cuerpo de la peticin lo forma la cadena: opcion=1&us=usuario&pass=1234. Esta informacin va detrs del smbolo ? situado al nal de la direccin URL. Cada parmetro de la peticin va separado del siguiente por el smbolo &.
161
Peticiones POST En este tipo de conexin, el cuerpo de la peticin se enva en un stream despus de iniciar la conexin. El siguiente ejemplo muestra cmo se realiza el envo del cuerpo de la peticin:
//se crea la conexin String url = http://www.midireccion.com; HttpConnection hc = (HttpConnection)Connector.open(url); // se informa el tipo de peticin a realizar hc.setRequestMethod(HttpConnection.POST); //se establece algunos campos de la cabezera hc.setRequestProperty(User-Agent,Prole/MIDP-2.0 Conguration/CLDC-1.0); hc.setRequestProperty(Content-Language,es-ES); // se envia el cuerpo de la peticin OutputStream os = hc.openOutputStream(); os.write(opcion=1.getBytes()); os.write(&us=usuario.getBytes()); os.write(&pass=1234.getBytes()); os.ush();
Estado de la Conexin En este estado se realiza el intercambio de informacin entre el cliente y el servidor. En los ejemplos anteriores se ha visto la manera de enviar la peticin al servidor. Ahora se ver cmo se realiza la respuesta del servidor hacia el cliente. Respuesta del Servidor
162
Al igual que la peticin del cliente posee distintas partes, la respuesta del servidor se compone de: Lnea de estado. Cabecera. Cuerpo de la respuesta. Para conocer la respuesta del servidor, la interfaz HttpConnection proporciona diversos mtodos que permiten conocer las distintas partes de sta. La interfaz HttpConnection dispone de treinta y cinco cdigos de estado diferentes. Bsicamente se pueden dividir en cinco clases de la siguiente manera: 1xx: Cdigo de informacin. 2xx: Cdigo de xito. 3xx: Cdigo de redireccin. 4xx: Cdigo de error del cliente. 5xx: Cdigo de error del servidor. Por ejemplo, el cdigo 400 corresponde a la constante HTTP_BAD_REQUEST. En realidad la respuesta del servidor posee el siguiente formato: HTTP/1.1 400 Bad Request. HTTP/1.1 200 OK. En la respuesta se incluye el protocolo usado, seguido del cdigo de estado y de un mensaje de respuesta. Este mensaje es devuelto al invocar el mtodo getResponseMessage().
163
Estado de Cierre La conexin entra en este estado una vez que se termina la comunicacin entre el cliente y el servidor invocando al mtodo close(). A continuacion se ver un ejemplo donde se produce una peticin mediante una peticin POST, se describirn tanto el codigo del MIDlet como del Servlet que recibe la peticion y devuelve una respuesta. Cdigo del MIDlet
import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; import javax.microedition.io.Connector; import javax.microedition.io.HttpConnection; import javx.microedition.lcdui.*; import javax.microedition.midlet.MIDlet; public class HiloConexionMidlet extends MIDlet implements CommandListener, Runnable{ private Display mDisplay; private Form mMainScreen; public HiloConexionMidlet() { mMainScreen = new Form(HTTPMIDlet); mMainScreen.append( Press OK to create an HTTP connection.); Command exitCommand = new Command(Exit, Command.EXIT, 0); Command okCommand = new Command(OK, Command.OK, 0); mMainScreen.addCommand(exitCommand); mMainScreen.addCommand(okCommand); mMainScreen.setCommandListener(this);
164
} public void startApp() { if (mDisplay == null) mDisplay = Display.getDisplay(this); mDisplay.setCurrent(mMainScreen); }
} public void pauseApp() { } public void destroyApp(boolean unconditional) {} public void commandAction(Command c, Displayable s) { if (c.getCommandType() == Command.EXIT) notifyDestroyed(); else if (c.getCommandType() == Command.BACK) mDisplay.setCurrent(mMainScreen); else if (c.getCommandType() == Command.OK) { // Put up a wait screen. Form waitForm = new Form(Connecting...); mDisplay.setCurrent(waitForm); Thread t = new Thread(this); t.start(); } }
// metodo Runnable public void run() { String url = http://localhost:9080/hiloServer/ServerHilo;
165
Form resultsForm = new Form(Results); Command backCommand = new Command(Back, Command.BACK, 0); resultsForm.addCommand(backCommand); resultsForm.setCommandListener(this); HttpConnection hc = null; InputStream in = null; OutputStream os = null; try { // aqui se realiza la conexin al servidor. hc = (HttpConnection)Connector.open(url); // se envia el cuerpo de la peticion hc.setRequestMethod(HttpConnection.POST); hc.setRequestProperty(Content-Language,es-ES); hc.setRequestProperty(User-Agent,ProleMIDP-2.0 Conguration/CLDC1.0); hc.setRequestProperty(Content-Type,application/octect-stream); os = hc.openOutputStream(); os.write(usuario=qm.getBytes()); os.write(&clave=hi.getBytes()); os.ush(); // se toma la respuesta. in = hc.openInputStream(); int length = 256; byte[] raw = new byte[length]; int readLength = in.read(raw); String message = new String(raw, 0, readLength); resultsForm.append(message); } catch (Exception e) { resultsForm.append( new StringItem(Exception: , e.toString())); } nally { if (in != null) {
166
try { in.close(); } catch (IOException ioe) {} } if (hc != null) { try { hc.close(); } catch (IOException ioe) {} } } mDisplay.setCurrent(resultsForm); }
Cdigo del Servlet

import java.io.IOException; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import java.io.*; public class ServerHilo extends HttpServlet { public void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { } public void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { InputStream in = req.getInputStream(); int length = 256;
167
byte[] raw = new byte[length]; int readLength = in.read(raw); String query= new String(raw, 0, readLength); int index = query.indexOf(&); String usuarioaux = query.substring(0,index); index = usuarioaux.indexOf(=); String userid = usuarioaux.substring(index+1,usuarioaux.length()); String claveaux = query.substring(index + 1, query.length()); index = claveaux.indexOf(=); String password = claveaux.substring(index+1,claveaux.length()); resp.setContentType(text/plain); PrintWriter out = resp.getWriter(); if(userid.equals(qm) && password.equals(hi)) { out.println(Login successful.); } else { out.println(Login failed.); } } }
Captulo 6
Introduccin al DB2
6.1 Bases de Datos
La necesidad de mejorar la manera de acceder y manejar los datos ha evolucionado con el transcurso del tiempo hasta llegar a la generacin de los sistemas de administracin de bases de datos relacionales (RDBMS ). En los ltimos tiempos ha surgido una nueva base de datos llamada Universal, la cul es capaz de almacenar y hacer bsquedas no solamente de datos alfanumricos sino tambin de imgenes, audio, video y otros objetos. Esta ventaja de las bases de datos universales abre un gran nmero de oportunidades que permiten mejorar tanto los servicios como las aplicaciones. Se puede denir una Base de Datos como una serie de datos organizados y relacionados entre s, y un conjunto de programas que permitan a los usuarios acceder y modicar esos datos [15]. Mientras que un archivo normalmente contiene datos acerca de un tipo de entidad (ej.: personal, rdenes, clientes, ventas), una base de datos contiene datos acerca de muchos tipos de entidades e informacin acerca de cmo las entidades estn lgicamente relacionadas entre s. Las bases son cualquier conjunto de datos organizados para su almacenamiento en la memoria de un ordenador, diseado para facilitar su mantenimiento y acceso de una manera estndar. Los datos suelen aparecer en forma 169
170
CAPTULO 6. INTRODUCCIN AL DB2
de texto, nmeros o grcos. Otra denicin ms completa de bases de datos arma que es un conjunto exhaustivo, no redundante, de datos estructurados, organizados independientemente de su utilizacin y su implementacin en mquina, accesibles en tiempo real y compatibles con usuarios concurrentes con necesidad de informacin diferente y no predecible en tiempo, donde la informacin se encuentra almacenada en una memoria auxiliar que permite el acceso directo a un conjunto de programas que manipulan esos datos [19].
6.1.1
Objetivos de las Bases de Datos
Automatizacin de: El mantenimiento. Cualquier generacin de informacin. Cualquier consulta sobre dicha informacin.
6.1.2
Ventajas de las Bases de Datos
Algunas ventajas de las bases de datos se describen a continuacin: Ahorro de Espacio: No hacen falta archivos de papeles que pudieran ocupar mucho espacio. Velocidad: Con la utilizacin de las bases de datos se pueden modicar, consultar datos con una velocidad mucho mayor que realizndolo manualmente. Ahorro de trabajo: ya que las mquinas son encargadas de manejar estas bases y no se necesitan manejar archivos a mano, existe un ahorro de trabajo humano. Actualizacin: Se dispone en cualquier momento de informacin precisa y al da. Comodidad: Al tener la informacin en un mismo sitio, se ahorrar tiempo y trabajo.
6.2.
SISTEMA DE ADMINISTRACIN DE BASES DE DATOS
171
Disminucin de la Redundancia: La duplicacin de los datos implica mayor trabajo en el mantenimiento. Gracias a que las bases de datos disminiyen la redundancia tambin se disminuye el trabajo. Comparticin de Datos: Se trata de datos actuales, ya que al estar centralizados, se puede tener acceso a los datos actualizados en prcticamente tiempo real. Restricciones de Seguridad: Para mantener la seguridad acerca del mantenimiento de los datos, los administradores de la Base de Datos, crean un nivel de acceso, que permitir o prohibir a los usuarios hacer una u otra accin sobre dicha base de datos. Posibilidad de Mantener la Integridad: En una base de datos se debe mantener una coherencia. Esto se controlar mediante: Mscaras. Reglas de validacin.
6.2
Sistema de Administracin de Bases de Datos
Una base de datos es una coleccin de tablas y objetos relacionados entre s y organizados como un grupo. La estructura de una base de datos se muestra en la g.6.1 de la pg. 172. Un DBMS es un conjunto de programas que maneja todos los accesos a las bases de datos; ver g. 6.2 de la pg 172. Funciones de un DBMS: Denicin de datos. Manipulacin de datos. Seguridad e integridad de los datos. Recuperacin y concurrencia de los datos. Diccionario de datos. Desempeo.
172
Figura 6.1: Estructura de Una Base de Datos
Figura 6.2: Sistema de Administracion de Bases de Datos
6.3. ORGANIZACIN DE BASES DE DATOS
173
6.3
Organizacin de Bases de Datos
Los modelos ms comunes de organizacin de Bases de Datos son: Jerrquico. En Red. Relacional. Orientado a Objetos.
6.3.1
Bases de Datos Jerrquicas
Estructura los campos en nodos en una estructura jerrquica. Los nodos son puntos conectados entre s formando una especie de rbol invertido. Cada entrada tiene un nodo padre, que puede tener varios nodos hijos; esto suele denominarse relacin uno a muchos. Los nodos inferiores se subordinan a los que se hallan a su nivel inmediato superior. Un nodo que no tiene padre es llamado raz, en tanto que los que no tienen hijos son conocidos como hojas. Cuando se desea hallar un campo en particular, se empieza por el tope, con un nodo padre, descendiendo por el rbol en direccin a un nodo hijo. Por Ejemplo: Un Sistema de Reservaciones de una Lnea Area (ver g. 6.3 de la pg. 174). El Nodo Padre es la Ciudad de Salida en este caso es (Caracas), Nodos Hijos representando las Ciudades Destino que tiene a su vez Nodos Hijos, que son el Nmero de Vuelo. El Nmero de Vuelo tendr tambin Nodos Hijos, que son los Pasajeros. Limitaciones de las Base de Datos Jerrquicas Al borrar un nodo padre, desaparecen tambin sus nodos subordinados. Slo podr aadirse un nodo hijo, si existe el nodo padre. Pero lo ms signicativo es la rigidez de su estructura: slo un padre por hijo y ausencia de relaciones entre los nodos hijos.
174
Figura 6.3: Modelo de Bases de Datos Jerrquica
6.3.2
Bases de Datos en Red
Se trata tambin de una organizacin jerrquica de nodos, pero un nodo hijo puede tener ms de un solo nodo padre (relacin muchos a muchos). Existen los punteros, que son conexiones adicionales entre nodos padres y nodos hijos, que permiten acceder a un nodo por vas distintas accediendo al mismo en direccin descendente por las diversas ramas. Representa una mejora al modelo jerrquico. Por ejemplo:Los vendedores destacados para distribuir determinados productos en algunas ciudades pueden ilustrar este modelo (ver g. 6.4 de la pg. 175). Cada Producto puede ser distribuido por ms de un Vendedor, as mismo cada Vendedor puede encargarse de diferentes Ciudades.
6.3.3
Bases de Datos Relacional
Esta organizacin ofrece la mayor exibilidad ya que los datos se almacenan en Tablas diferentes, conformadas as mismo por Filas y Columnas. Una tabla se denomina relacin. En una Tabla las Filas contienen los Registros. Las Columnas representan los Campos. Las Tablas relacionadas poseen un campo comn, el Campo Clave, mediante el cual la informacin almacenada en una tabla puede enlazarse con la informacin almacenada en otra.
6.3. ORGANIZACIN DE BASES DE DATOS
175
Figura 6.4: Modelo de Bases de Datos en Red El acceso a los datos se realiza mediante consultas escritas en SQL (Structured Query Language). La Organizacin de Bases de Datos Relacional es la ms difundida en la actualidad debido a su sencillez para realizar operaciones de adicin, eliminacin y modicacin en contraste con la mayor rigidez de las Organizaciones Jerrquicas y de Red. Por ejemplo: En un pequeo negocio, se puede contar con una Tabla de Clientes y Tabla de Pedidos (ver g. 6.5 de la pg. 176). Las rdenes que pertenecen a un determinado cliente son identicadas colocando el campo de identicacin del cliente en la orden (campo clave de la tabla de clientes), lo cual permite enlazar las dos tablas. Limitaciones de las Base de Datos Relacionales
Estructuras muy simples. Poca riqueza semntica. No soporta tipos denidos por el ususarios (slo Dominios). No soporta Recursividad. Falta de Procesamiento/Disparadores. No admite Herencia.
176
Figura 6.5: Modelo de Bases de Datos Relacional
6.4
Introduccin a DB2 UDB
DB2 UDB Universal Database es una Base de Datos Universal. Es completamente escalable, veloz y conable. Corre en modo nativo en casi todas las plataformas como ser: Windows Vista, NT, Sun Solaris, HP-UX, AIX U, OS/2 entre otros. DB2 es un software de base de datos relacional. Es completamente multimedia, disponible para su uso en la Web, muy bueno para satisfacer las demandas de las grandes corporaciones y bastante exible para servir a los medianos y pequeos negocios. DB2 UDB es un sistema manejador de base de datos relacional fuertemente escalable. Es sucientemente exible para atender estructuras e inestructuras manejadoras de datos necesarias para usuarios simples de grandes empresas. Es conveniente para una gama amplia de aplicaciones de los clientes, quienes pueden desplegar una variedad de plataformas de hardware y software desde dispositivos manuales a los sistemas multiprocesador paralelos masivos.
6.4. INTRODUCCIN A DB2 UDB
177
6.4.1
Caractersticas Generales del DB2 UDB
DB2 UDB es el producto principal de la estrategia de Data Management de IBM. DB2 UDB es un sistema para administracin de Bases de Datos Relacionales (RDBMS). Es multiplataforma, especialmente diseada para ambientes distribuidos, permitiendo que los usuarios locales compartan informacin con los recursos centrales. Es el sistema de gestin de datos que entrega una plataforma de base de datos exible y rentable para construir un sistema robusto para aplicaciones de gestin. DB2 UDB libera los recursos con amplio apoyo al open source (fuente abierta) y plataformas de desarrollo populares como J2EE y Microsoft .NET.
Integridad El DB2 UDB incluye caractersticas de Integridad, asegurando la proteccin de los datos an en caso de que los sistemas sufran un colapso, y de Seguridad permitiendo realizar respaldos en lnea con distintos grados de granularidad, sin que esto afecte la disponibilidad de acceso a los datos por parte de los usuarios.
Mltiples Usos Provee la capacidad de hacer frente a mltiples necesidades, desde Procesamiento Transaccional de Misin Crtica (OLTP), hasta anlisis exhaustivo de los datos para el soporte a la toma de decisiones (OLAP).
Escalabilidad Sus caractersticas distintivas de Escalabilidad le permiten almacenar informacin en un amplio rango de equipos, desde un PC porttil hasta un complejo ambiente de mainframes procesando en paralelo.
178
Web Enabled Para e-Business Incluye tecnologa basada en Web que permite generar aplicaciones en las Intranets y responder a las oportunidades de negocios disponibles en Internet. Facilidad de Instalacin y Uso La primera versin de DB2 para NT fue reconocida en el mercado como una base de datos muy poderosa, pero difcil de instalar y usar. En esta versin (DB2 UDB V. 8.1), IBM agreg muchas herramientas grcas para facilitar el uso para los usuarios, como tambin para los administradores y desarrolladores. Dicha versin incluye guas para operaciones como instalacin, conguracin de performance, setup, etc. Adems, se agregaron herramientas para facilitar las tareas de integracin con otras bases de datos, tecnologas de networking y desarrollo de aplicaciones. Universalidad DB2 UDB es, adems, la nica base de datos realmente universal; es multiplataforma (16 plataformas - de las cuales 10 no son de IBM), brinda soporte a un amplio rango de clientes, soporta el acceso de los datos desde Internet y permite almacenar todo tipo de datos: Texto, Audio, Imgenes y Video (AIV Extender) (ver g. 6.6 de la pg.179) . Documentos XML ( XML Extender) (ver g. 6.7 de la pg.179).
Funciones Complementarias del DB2 UDB Conectividad Las herramientas de conectividad permiten acceder a los datos ms all de donde ellos se encuentren. El slogan cualquier cliente, a cualquier servidor,
6.4. INTRODUCCIN A DB2 UDB
179
Figura 6.6: AIV Extender
Figura 6.7: XML Extender
180
en cualquier red est completamente sustentado por la funcionalidad que sus herramientas ofrecen. DB2 permite acceder a los datos de DB2 en mainframe o AS/400, desde Windows Vista, NT, Windows 95/98, OS/2 o cualquiera de los Unix soportados. Adems, el producto Datajoiner posibilita acceder de forma nica y transparente a los datos residentes en Oracle, Sybase, Informix, Microsoft SQL Server, IMS, VSAM y otros.
6.5
DB2 UDB Versin 8.1
La versin 8.1 ofrece un soporte ms potente para Business Intelligence, Gestin de Datos y Soluciones e-business. DB2 Universal Database Versin 8.1 contiene muchas caractersticas nuevas, que incluyen el Centro de desarrollo, funciones ampliadas de XML Extender, soporte de Linux para DB2 Warehouse Manager, integracin de Spatial Extender con herramientas de IBM Business Intelligence, un nuevo Centro de duplicacin, mejoras de enlace y rendimiento de DB2 Data Links Manager. Nuevas herramientas de gestin y supervisin de bases de datos, soporte de 64 bits ampliado y nuevos asistentes de Instalacin de DB2 y Centro de control de DB2.
6.5.1
Centro de Desarrollo
En la versin 8.1, el Centro de desarrollo sustituye al Stored Procedure Builder de anteriores versiones y proporciona un funcionamiento incrementado. Mediante el Centro de desarrollo, el usuario puede desarrollar procedimientos almacenados y funciones denidas por el usuario como se muestra en la g. 6.8 de la pg. 181. Tambin es posible correlacionar tipos estructurados de los Enterprise JavaBeans. Los asistentes simplican las tareas de desarrollo. Las nuevas caractersticas incluyen: Soporte de varios proyectos y conexiones de base de datos. La Vista de servidor para examinar los objetos de desarrollo en el servidor.
6.5. DB2 UDB VERSIN 8.1
181
Depurador de SQL para depurar rutinas; incluye vistas para puntos de interrupcin, variables y pila de llamadas. Una interfaz mejorada para controlar el entorno de desarrollo. Asistentes para construir funciones denidas por el usuario para MQSeries, fuentes de datos OLE DB y documentos XML. Asistentes para exportar, importar y desplegar rutinas e informacin de proyectos Productos y Paquetes Nuevos.
Figura 6.8: Centro de Desarrollo
6.5.2
Mejoras en XML Extender
Se han aadido nuevas caractersticas a XML Extender : ahora, XML Extender soporta servicios de Web con los servicios Web Object Runtime Framework (WORF), conjunto de herramientas para implantar servicios de Web con DB2. Asimismo, XML Extender soporta ahora MQSeries, de forma que es posible enviar documentos XML a las colas de mensajes de MQSeries, y recuperarlos de las mismas.
182
6.5.3
DB2 Warehouse Manager
Se han aadido nuevas caractersticas y mejoras a DB2 Warehouse Manager : Con el soporte de carga paralela nativa para DB2 Universal Database Enterprise Server Edition, es posible cargar grandes volmenes de datos con ms rapidez. DB2 Warehouse Manager tiene capacidades ampliadas, por lo que se puede incrementar y mejorar el rendimiento de las operaciones de depsito, manipular y localizar metadatos ms deprisa, y ejecutar el agente de depsito, programas y transformadores en Linux. Los conectores para la Web y SAP se han mejorado en el paquete de DB2 Warehouse Manager.
6.5.4
Centro de Depsito de Datos de DB2
Se han aadido nuevas caractersticas al Centro de depsito de datos: El soporte de servidor de depsito se ampla a AIX. El servidor de depsito y el iniciador de sesiones de depsito, que se ejecutan como servicios en Windows, se ejecutan como daemons en AIX. Es posible exportar e importar metadatos del lenguaje de cdigo y exportar estos objetos: Tablas, archivos y vistas de origen. Tablas y archivos de destino. El proceso en cascada (varios intervalos) permite gestionar varios pasos deniendo y habilitando una planicacin y un ujo de tareas para los procesos que contienen los pasos. Con el nuevo paso Select and Update de SQL, se puede actualizar una tabla de destino del depsito de datos sin sustituir la tabla completa ni grabar cdigo adicional. Ahora, la Gua de aprendizaje de Business Intelligence se compone de dos guas de aprendizaje ms cortas: Gua de aprendizaje de Business Intelligence:
6.5. DB2 UDB VERSIN 8.1
183
Introduccin al Centro de depsito de datos y Gua de aprendizaje de Business Intelligence: Lecciones ampliadas sobre depsito de datos.
6.5.5
Asistentes de DB2
Asistente para la Conguracin de DB2 La instalacin de DB2 en plataformas Windows y UNIX resulta ms fcil mediante la utilizacin del Asistente para la conguracin de DB2. Esta interfaz grca permite instalar productos DB2 directamente o crear archivos de respuestas para permitir una instalacin posterior. En los sistemas UNIX, tambin se puede utilizar el Asistente para la conguracin de DB2 para realizar funciones de gestin de instancias. Asistentes del Centro de Control En DB2 Versin 8.1, los asistentes que estn disponibles en las Herramientas de administracin se han ampliado para abarcar un mbito ms amplio de funciones, en comparacin con las de que se dispona en versiones anteriores de DB2. Por ejemplo, un asistente de DB2 Versin 8.1 brinda el conjunto total de opciones disponibles para crear una tabla. Como se puede observar en la g.6.9 de la pag.184 el asistente para creacin de tablas, que va guiando paso a paso al usuario a travs de una interfaz amigable, permitiendo crear campos de la tabla, denir una clave, denir un ndice y tambien restricciones a la tabla.
6.5.6
Centro de Mandatos
El centro de mandatos permite realizar funciones sobre la base de datos como realizar consultas SQL (insert, delete, update, select), crear estructuras de tablas, modicar indices, etc. Donde un usuario avanzado puede escribir directamente la sentencia y ejecutarla; ver g.6.10de la pag.184. Para usuarios menos avanzados tambin se dispone de un asistente llamado SQL ASSIST que va ayudando al usuario para la realizacin de una consulta.
184
Figura 6.9: Asistente Para Crear Tabla
Figura 6.10: Centro de Mandatos
Captulo 7
WebSphere Studio
7.1 Que es WebSphere?
IBM WebSphere es una plataforma de IBM para desarrollo y gestin de sitios web y aplicaciones destinadas al comercio electrnico. WebSphere es una plataforma de Software para e-business. WebSphere posee una amplia gama de servidores y aplicaciones para brindar cualquier tipo de capacidades de negocio y ayuda al desarrollo de las aplicaciones. La Plataforma de Software WebSphere est compuesta por un conjunto de herramientas de e-business integradas y basadas en estndares abiertos de mercado. WebSphere es ideal para todas las fases de un e-business, comenzando desde pequeos sitios Web a mega sitios. La plataforma de software WebSphere proporciona una completa gama de habilidades que permiten a los clientes la entrega de altos niveles de servicio a todos los visitantes del sitio en la web. Administra cargas pico en los servidores web, mantiene la disponibilidad del sitio en la web, y reconoce contenido de solicitudes de la web para calidad-de-servicio mejor. Tambin permite la diferenciacin de niveles de servicio con base en el tipo de cliente. 185
186
CAPTULO 7. WEBSPHERE STUDIO
7.2
Plataforma de Software
La creciente complejidad de los aplicativos de e-business crea muchos desafos. Los aplicativos deben ser escalables, ables y se deben integrar completamente con los sistemas back-end para proteger las inversiones existentes. El equipo de desarrollo debe poseer las ms actualizadas habilidades de programacin para acompaar el ciclo de vida del e-business. Se necesita una plataforma completa, escalable y exible que proporcione soporte a la construccin y diseminacin de aplicativos de e-business. Las soluciones de software WebSphere ofrecen las herramientas necesarias para alcanzar los objetivos de e-business. Al proporcionar un banco de trabajo abierto que integre y simplique diferentes tareas, roles y herramientas, el software WebSphere ayuda a que el equipo desarrolle, entregue y administre los aplicativos de e-business [11]. El ambiente de desarrollo del software WebSphere: Da soporte al desarrollo y cambios rpidos de nuevos aplicativos utilizando un paradigma de desarrollo basado en reglas. Proporciona cdigo pre-construido, pre-testeado. Proporciona herramientas especializadas para pgina Web y desarrollo de mdulos migrables. Adicionalmente, servicios basados en estndares Web permiten mezclar y combinar componentes funcionales de diferentes orgenes de tal forma que se puede proveer nuevos procesos y servicios al mercado rpida y ecientemente. La capacidad de un portal de negocios tiene importancia crtica para permitir que las personas interacten y transaccionen de forma personalizada con diversos recursos de negocios. Empieza dejando a la medida los ambientes de usuarios para sus necesidades especcas, integrndolo entonces con otros usuarios para permitir colaboracin en tiempo real, y con los diversos ambientes de TI. Todo esto permite que las personas trabajen en conjunto de forma ms productiva mientras actan sobre la informacin que necesitan. La capacidad
7.2. PLATAFORMA DE SOFTWARE
187
del portal de negocios es proporcionada por la familia WebSphere Portal y la familia WebSphere Commerce .
7.2.1
WebSphere for Commerce - Soluciones B2B
El e-commerce consiste en realizar negocios con sus clientes, proveedores y contratistas comerciales sin dicultades en cuanto al tiempo, limitaciones organizacionales o fronteras geogrcas. Con el software With WebSphere Commerce, se establecen relaciones ms estrechas, ms productivas con sus clientes y contratistas comerciales en todos los puntos de contacto. Facilita que sus clientes y contratistas comerciales hagan negocios hoy y que continen maana.
7.2.2
WebSphere for Commerce - Soluciones B2C
El software WebSphere Commerce le permite ir a la lnea de las ventas online a los consumidores. Crea campaas de marketing dinmicas, ja como objetivo diferentes segmentos de mercado, elabora promociones de producto personalizadas, y mejora el servicio a clientes. Esta solucin ayuda a crear rpidamente y mantener ecientemente un sitio interactivo, de alto volumen. WebSphere Commerce proporciona: Personalizacin del B2B para ayudar a administrar las relaciones de negocio. Tecnologa de ventas asistidas para conducir a los clientes y contratistas a travs de la agrupacin de requisitos y del proceso de seleccin del producto. Herramientas de cooperacin online y de formacin de equipo virtual para mejorar la ecacia de contratistas comerciales, canal y clientes. Administracin de pedidos anticipado resultando en capacidades de optimizacin de operaciones.
188
Capacidades avanzadas de inteligencia de negocios para decisiones fundamentas del e-business.
7.2.3
WebSphere for Commerce-Soluciones de Portal
La integracin del WebSphere Commerce y WebSphere Portal permite que las empresas se dirijan a mltiples sectores con necesidades de personalizacin positivas de soluciones de comercio tanto para las reas B2B o B2C. Actualmente, muchas empresas crean sitios separados para cada divisin, lo que demanda mucho tiempo y cuesta caro. El abordaje racionalizado proporciona rpido retorno de inversin al eliminar la necesidad de que la empresa mantenga mltiples sitios. Las empresas tambin aumentan la eciencia de interacciones con clientes y contratistas, lo que mejora la retencin del cliente. Los productos IBM WebSphere Commerce y WebSphere Portal proporcionan un nico punto de interaccin con informacin dinmica y personalizada, aplicativos, procesos y personas, que son esenciales para construir portales exitosos para el B2B y B2C. Con el portal habilitado para el comercio, se puede crear un ambiente personalizado de comercio provechoso para ambos ambientes, B2B y B2C:
Ambientes B2B: organizar ecientemente informacin online, servicios y aplicativos para contratistas de negocio y proveedores a lo largo de mltiples divisiones en un portal. Ambientes B2C o de ventas al por menor: obtener ventas cruzadas e impulsar los benecios, mediante la oferta de acceso a productos, informacin y servicios desde la Web y de dispositivos inalmbricos, as como acceso consolidado a catlogos mltiples.
Con un portal de e-commerce integrado, se les puede ofrecer a los clientes, contratistas y proveedores acceso 24x7 a los aplicativos online - rpida y fcilmente.
7.2. PLATAFORMA DE SOFTWARE
189
7.2.4
WebSphere for Commerce-Soluciones Digital Media
Empresas de medios con volmenes crecientes de activos digitales -fotos, vdeo clips, archivos en audio, ilustraciones e imgenes animadas- enfrentan nuevas exigencias reguladoras y el desafo de colocar esos activos disponibles online. El software WebSphere permite administrar estos activos digitales ms ecazmente, alcanzando clientes en todos el mundo a travs de la Web. WebSphere Commerce para Medios Digitales permite almacenar, buscar, ver, administrar, colaborar, comprar, vender y hacer download de activos digitales, alcanzando clientes en todo el mundo por la Web. Esta nueva oferta de servicio de e-commerce combina el software WebSphere Commerce aprobado por la industria con las capacidades del IBM Content Manager, reforzado por la tecnologa Java. WebSphere Commerce para Medios Digitales permite enriquecer la experiencia del consumidor y la interfase de compra B2B, creando nuevas relaciones con clientes al mismo tiempo en que fortalece las existentes y ayudando a generar y aumentar ganancias as como sus mrgenes de benecios. WebSphere ofrece un amplio portafolio de soluciones clasicadas en tres reas crticas: Infraestructura y herramientas de Desarrollo (Fundation & Tools): Application server. WebSphere studio: IBM WebSphere Studio Site Developer. IBM WebSphere Studio Application Developer. IBM WebSphere Studio Application Developer Integration Edition. IBM WebSphere Studio Enterprise Developer. IBM WebSphere Studio Homepage Builder. Host Access. Alcance y experiencia con el usuario (Business Portals): WebSphere Portal. WebSphere Everyplace.
190
WebSphere Commerce. Integracin de negocio (Business Integration): WebSphere Business Integrator. WebSphere MQ Integrator.
7.3
Productos WebSphere Studio
WebSphere Studio es una familia de productos de software propietario de IBM, aunque el trmino se reere de manera popular a uno de sus productos especcos: WebSphere Application Server (WAS). Todos los productos del WebSphere Studio fueron construidos sobre el Workbench de Eclipse como un sistema de plug-ins conforme al estndar APIs del Workbenchs. La familia del WebSphere Studio tiene actualmente los siguientes miembros (ver g. 7.1 de la pg. 191):
WebSphere Studio Site Developer Advanced . WebSphere Studio Application Developer . WebSphere Studio Application Developer Integration Edition . WebSphere Studio Enterprise Developer .
Cada producto de la familia WebSphere Studio presenta el mismo entorno de desarrollo integrado (IDE) y una base comn de herramientas, por ejemplo para el desarrollo Java y Web (ver g. 7.2 de la pg. 191).
7.3. PRODUCTOS WEBSPHERE STUDIO
191
Figura 7.1: La familia del WebSphere Studio.
Figura 7.2: WebSphere Studio, entorno de desarrollo .
192
7.4
WebSphere Studio Application Developer
WebSphere Studio Application Developer es un producto que se ha desarrollado basado en el Workbench (banco de trabajo) de Eclipse. La plataforma del Workbench de Eclipse fue diseada por IBM y lanzada a la comunidad de open-source (cdigo abierto). Este Workbench se ha diseado para proveer la mxima exibilidad en el desarrollo de las herramientas y las nuevas tecnologas que pueden emerger en el futuro. La familia del WebSphere Studio Application Developer se basa en un ambiente integrado de desarrollo (IDE), donde este permite desarrollar, probar, eliminar errores y desplegar su usos. Donde tambin proporciona la ayuda para cada fase del desarrollo del ciclo vida. Los lderes de la industria de software como: IBM, Borland, Merant, QNX Software Systems, Rational Software, RedHat, SuSE, TogetherSoft y WebGain formaron inicialmente la eclipse.org que actualmente administra los directores del Eclipse open source project. Eclipse es una plataforma abierta para la integracin de herramienta cons-
7.4.
WEBSPHERE STUDIO APPLICATION DEVELOPER
193
truida por una comunidad abierta de los abastecedores de la herramienta. Eclipse se ha diseado a partir de la necesidad de Construir, Integrar los desarrollos tiles del uso de las tecnologas. El valor ms importante que tiene esta plataforma es: el rpido desarrollo de herramienta siendo esta una de las caractersticas basadas en un modelo plug-in (con enchufe) (ver g. 7.3 de la pg. 193).
Figura 7.3: Plataforma de Eclipse.
7.4.1
Ventajas de Utilizar a WebSphere Studio Application Developer
La ventaja fundamental consiste en la integracin de todos los entornos de desarrollo Java, Web en una nica plataforma de desarrollo. J2EE: Herramientas de importacin/exportacin, generacin de cdigo, edicin de deployment descriptors estandars, extensiones y bindings (mapeos) especcos para WebSphere Application Server (WAS).
194
Herramienta de mapeo EJB-RDB soportanto tanto top-down, como bottom-up y meet-in-the-middle. Herramientas de edicin grca de esquemas de bases de datos. Herramientas para la creacin, edicin y validacin de cheros EAR. Editores para deployment descriptors (ejb-jar.xml y application.xml). Desarrollo Java: Nuevo Editor Visual Java para GUIs (Swing y AWT). Nueva generacin de JavaDoc. Soporte JDK 1.3. Capacidad de utilizar diferentes JREs. Compilacin incremental automtica. Posibilidad de ejecutar cdigo incluso con errores. Proteccin contra crashs y auto-recovery. Error Reporting y correccin. Editor Java con asistente contextual. Herramientas de refactoring de cdigo. Bsquedas inteligentes y herramientas para comparar cdigo y merge. Scrapbook para evaluacin rpida de cdigo. Web Services: Nuevo soporte UDDI Version 2. Soporte UDDI privado. Nuevo soporte de WSIL. Posibilidad de crear un web service a partir de un chero ISD.
7.4.
195
Visualizacin de UDDI business entry para localizacin de web services existentes. Creacin de web services a partir de cdigo existente (JavaBeans, RLSs, DB2 XML Extender calls, procedimientos almacenados DB2 y queries SQL). Crear wrappers SOAP y HTTP GET/POST de cdigo existente. Generacin de proxies desde el Web Services Client/Wizard para tratar mensajes SOAP. Generacin de una aplicacin de ejemplo, a partir de la cual crear el resto. Realizar el test de un web service local o remoto. Deployment de un web service sobre el entorno de test de tanto WebSphere Application Server como Tomcat. Publicar web services en un UDDI business registry. Nuevos mens pop-up para la creacin y consumo de web services, adems de los tpicos wizards. XML: Entorno totalmente visual. Editor de XML con posibilidades de validacin de documentos. Editor de DTD con posibilidades de validacin de documentos. Editor de XML schemas. Editor de XSL. Debugger de XSL y herramienta de transformacin para aplicar XSL a XML. Editor de mapping XML - XML. Wizard de creacin de XML a partir de queries SQL. Editor de mapping RDB - XML.
196
Desarrollo web: Nuevo soporte para XHTML y Struts. Nuevo entorno visual de construccin de aplicaciones basado en struts. Editor visual de HTML y JSPs. Edicin y validacin de JavaScript. Soporte de JSP Custom tags (taglibs) 1.2. Edicin de imgenes y animaciones. Edicin de CSS. Importacin via HTTP/FTP. Exportacin va FTP a un servidor. Visualizacin de links, broken links, etc. Wizards para la creacin de servlets. Wizards para la creacin de proyectos J2EE. Wizards para la creacin de aplicaciones web. Testing y Deployment: Incrementa la productividad de forma muy importante. Entorno ligero de carga rpida. Permite pruebas unitarias locales. Permite debugger de cdigo en el servidor a travs del debugger integrado. Permite congurar deiferentes aplicaciones web. TCP/IP monitoring server. Permite instalar los siguientes entornos, tanto locales como remotos: (WebSphere Application Server AEs Version 4.0.3 and Version 5, WebSphere Application Server - Express Version 5, Apache Tomcat).
7.4.
197
Tracing, Monitoring y Performance: Performance Analyzer muestra los tiempos de ejecucin y ayuda a detectar memory leaks. Muestra informacin de los objetos existentes. Tiene capacidades de Pattern extraction. Es posible monitorizar varios procesos simultaneamente, incluso corriendo en diferentes mquinas. Codicacin por colores de las clases. Presentacin de los resultados en modo grco y estadstico. Soporte de proling a nivel de objetos. Anlisis de los logs de WebSphere Application Server e interaccin con la bases de datos de problemas. Edicin de items en la base de datos de problemas. Debugger: Muy similar al existente en VisualAge for Java. Permite realizar debug tanto a cdigo local como a cdigo residente en el servidor.
7.4.2
Desarrollando Aplicaciones Java
Los lineamientos que se deben seguis para crear una aplicacion Java en WebSphere Application Developer son los siguientes: Crear un proyecto Java. Crear paquetes dentro del proyecto. Crear clases.
198
Ejecutar el programa. Localizar errores. Para crear un proyecto Java se debe seleccionar archivo Nuevo Proyecto, de desplegar el cuadro de dilogo de Nuevo Proyecto, se debe seleccionar Java y proyecto Java en el dilogo y hacer click en siguiente para iniciar el asistente de creacin de proyectos. Luego se debe indicar en la primer pgina el nombre del proyecto y click en aceptar; (ver g.7.4 de la pag. 198).
Figura 7.4: Asistente de Proyecto Java. El proyecto es creado con las opciones que se hayan congurados anteriormente en las preferencias o con las que tiene por defecto. Estas preferencias puede ser modicadas dirigiendose al menu Ventana Preferencias y luego Java Proyecto Nuevo. Se pueden agregar paquetes al proyecto para tener una estructura ms ordenada de la aplicacin. Para ello se debe seleccionar en la vista de exploracin de paquetes Nuevo Paquete en el men. En la ventana de dilogo se tiene que indicar el nombre del paquete y hacer clic en nalizar; ver g. 7.5 de la pag. 199. Luego de haber nalizado el cdigo y compilado los errores, se puede ejecutar el programa. Se tiene que seleccionar la opcion ejecutar de la barra de
7.5. WEBSPHERE APPLICATION SERVER
199
Figura 7.5: Paquete Java. herramientas. Si es la primera vez que se ejecuta ese cdigo se abre el dilogo ejecutar conguraciones. Como se puede ver en la g. 7.6 de la pg. 200 se puede seleccionar el tipo de conguracin para ejecutar el programa.
7.5
7.5.1
WebSphere Application Server

Introduccin
El WebSphere Application Server representa una familia de software para servidores de aplicaciones. Permite a las empresas responder a los mercados cambiantes sin migrar a tecnologas diferentes preservando las inversiones hechas en tecnologa previamente disponible en la organizacin, soporta normas abiertas vigentes en las organizaciones, proporciona soporte pleno a la plataforma abierta Java 2 y Java 2 Enterprise Edition (J2EE) y tambin provee soporte para servicios bajo normas abiertas en la Web [3]. WebSphere Application Server, es una plataforma de alto desempeo y extrema escalabilidad para diseminar aplicativos dinmicos de e-business, pro-
200
Figura 7.6: Dilogo de Conguracin de Ejecucin. porciona las funciones esenciales de e-business de manipulacin de transacciones y ampliacin de datos back-end del negocio y aplicativos para la Web. La plataforma ayuda a construir aplicativos que ejecutan esas funciones con seguridad slida, abilidad y escalabilidad.
7.5.2
WebSphere Application Server Como Plataforma Para el Comercio Electrnico
Brinda un soporte amplio para aplicaciones de comercio electrnico. Se caracteriza por su exibilidad para adaptarse a cambios en los mercados y en los objetivos comerciales. Construyendo aplicaciones en esta robusta plataforma, se pueden integrar diversos ambientes de las IT (Tecnologa de Informacin), para aprovechar al mximo las inversiones existentes. Se pueden instalar aplicaciones comerciales existentes para su acceso desde la Web y escalar estas aplicaciones para adecuarlas a las necesidades de los cambios y de la demanda. En la g. 7.7 de la pg. 201 se puede observar la plataforma del Software
201
Figura 7.7: WebSphere para e-bussines. de WebSphere para e-bussines.
7.5.3
Application Server - Advanced Edition
La Edicin Avanzada es la oferta del principal servidor de aplicativo dirigido a desarrolladores profesionales de tecnologa Java que necesitan funcionalidad de servicios J2EE y Web para aplicativos dinmicos de e-business. Esta Edicin del WebSphere Application Server, est disponible en tres conguraciones: Edicin Avanzada: Proporciona integracin slida a las bases de datos, middleware orientado a mensajes, y sistemas preexistentes y aplicativos, en conjunto con soporte de agrupacin. Esta conguracin se ajusta a la mayora de los escenarios de la empresa e interesa a los negocios que necesitan construir aplicativos altamente transaccionales, administrables, disponibles y escalables que ofrecen seguridad distribuida y administracin remota. Edicin Avanzada del Single Server :
202
Proporciona el mismo modelo de programacin esencial J2EE y Web Services con administracin simplicada. Esta conguracin interesa a departamentos, negocios de tamao mediano y aplicativos piloto que necesitan un coste bajo, opcin de ejecucin rpida, distribucin de carga de trabajo o administracin remota asociados a administracin de multi-servidor. Edicin Avanzada del IBM WebSphere Application Server, para Linux en zSeries: La Edicin Avanzada del WebSphere Application Server, para Linux en zSeries contina cumpliendo el compromiso de IBM en cuanto a mantener cobertura amplia para plataformas para el WebSphere Application Server. Este producto WebSphere tiene la combinacin potente de un conjunto de dispositivos rico y soporte a estndares abiertos del WebSphere Application Server y el ambiente operacional familiar del sistema operativo Linux. Tambin contiene los recursos de administracin, alta abilidad, y la intensa velocidad de comunicacin de datos internos del hardware de la plataforma zSeries.
7.5.4
Application Server - Enterprise Edition
La Edicin empresarial del IBM WebSphere Application Server, en junto con IBM WebSphere Studio Application Developer Integration Edition, ofrece una combinacin potente de tiempo de ejecucin y herramienta que permite integrar activos IT existentes, mejorar la productividad del desarrollador y crear y mantener aplicativos de e-business exibles. Juntos, el IBMs WebSphere Application Server Enterprise Edition y el WebSphere Studio Application Developer Integration Edition permiten a los desarrolladores la capacidad de: Coreograar visualmente y componer servicios de la Web y componentes de aplicativo J2EE a travs de una interfase de simple drag-and-drop. Construir potentes adaptadores de aplicativo basados en J2EE Connector Architecture (JCA) para integrar sistemas back-end con servicios Web y aplicativos J2EE.
203
Obtener una infraestructura completa de servicios Web que impulse un ambiente nico, ecaz en cuanto a coste de tiempo de ejecucin del servidor de aplicativo administrativo y operacional. Evitar la repeticin del desarrollo y diseminacin de aplicativos debido a condiciones cambiantes del mercado, separando las polticas del negocio de la lgica de aplicativos esenciales. Crear una paleta de componentes de aplicativos que puede ser rpidamente montada para desarrollar nuevos aplicativos fcilmente publicada como servicio Web.
7.5.5
Application Server - Standard Edition
La Edicin Estndar para desarrolladores de la web y autores de contenido incluye mejoras de facilidad de uso en toda su extensin, comprendiendo un Quick Installation que elimina conjeturas en cuanto al Enhanced Java, impulsando el Software Development Kit del Java 2 V1.2.2 en todos los sistemas operativos soportados.
7.5.6
Servidor HTTP
IBM WebSphere Application Server trabaja con un servidor HTTP para manejar las peticiones de servlets y otros contenidos dinmicos desde las aplicaciones Web. El servidor HTTP y el servidor de aplicaciones se comunican utilizando el plug-in HTTP de WebSphere para el servidor HTTP. El plug-in HTTP utiliza un archivo de conguracin XML de fcil lectura para determinar si la peticin la debe gestionar el servidor Web o el servidor de aplicaciones. Utiliza el protocolo HTTP estndar para comunicarse con el servidor de aplicaciones.
7.5.7
Servidor de Aplicaciones
El servidor de aplicaciones colabora con el servidor Web intercambiando peticiones de clientes y respuestas de aplicaciones. Puede denir varios servidores de aplicaciones, cada uno de ellos ejecutndose en su propia Mquina Virtual Java (JVM).
204
7.5.8
Contenedor de EJB
El contenedor de EJB proporciona los servicios de tiempo de ejecucin necesarios para desplegar y manejar componentes EJB, conocidos como enterprise beans. Es un proceso de servidor que maneja peticiones para beans de sesin y beans de entidad. Los enterprise beans (dentro de los mdulos EJB) instalados en un servidor de aplicaciones no se comunican directamente con el servidor; en su lugar, el contenedor de EJB ofrece una interfaz entre los enterprise beans y el servidor. Juntos, el contenedor y el servidor proporcionan el entorno de tiempo de ejecucin del bean. El contenedor proporciona muchos servicios de bajo nivel, incluido el soporte de hebras y transacciones. Desde un punto de vista administrativo, el contenedor gestiona el almacenamiento y la recuperacin de datos para los beans que contiene. Un solo contenedor puede gestionar ms de un archivo JAR de EJB.
7.5.9
Contenedor Web
Los servlets y los archivos JSP (Java Server Pages) son componentes del servidor que se utilizan para procesar peticiones de clientes HTTP como, por ejemplo, navegadores Web. Se encargan de la presentacin y el control de la interaccin del usuario con los datos de aplicacin subyacentes y la lgica empresarial. El contenedor Web procesa servlets, archivos JSP y otros tipos de inclusiones de servidor. Los servlets anteriores a J2EE se ejecutarn en un motor de servlets. Cada contenedor Web contiene automticamente un nico gestor de sesiones. Cuando se manejan los servlets, el contenedor Web crea un objeto de peticin y un objeto de respuesta, e invoca el mtodo de servicio de servlets. El contenedor Web invoca el mtodo destroy() del servlet cuando corresponda y descarga el servlet, y despus la JVM ejecuta la recoleccin de basura.
205
7.5.10
Contenedor de Clientes de Aplicaciones
Los clientes de aplicaciones son programas Java que se ejecutan normalmente en un sistema de sobremesa con una interfaz grca de usuario (GUI) . Tienen acceso a toda la gama de componentes y servicios de servidor J2EE. El contenedor de clientes de aplicaciones maneja programas de aplicaciones de Java que acceden a los beans enterprise, Java Database Connectivity (JDBC) y las colas de mensajes de Java Message Service. El programa Cliente de aplicaciones J2EE se ejecuta en las mquinas cliente. Este programa sigue el mismo modelo de programacin Java que otros programas Java; no obstante, el cliente de aplicaciones J2EE depende del tiempo de ejecucin del cliente de aplicaciones para congurar su entorno de ejecucin, y utiliza el espacio de nombres JNDI (Java Naming and Directory Interface) para acceder a los recursos.
7.5.11
Sistema Principal Virtual
Un sistema principal virtual es una conguracin que permite que una nica mquina de sistema principal parezca varias mquinas de sistema principal. Los recursos asociados con un sistema principal virtual no pueden compartir datos con recursos asociados con otro sistema principal virtual, incluso si los sistemas principales virtuales comparten la misma mquina fsica. Los sistemas principales virtuales permiten al administrador asociar aplicaciones Web con un sistema principal particular congurado para la mquina que ejecuta la aplicacin.
7.5.12
Virtual Hosts (Hosts Virtuales)
Un host virtual es una conguracin que permite a una sola mquina host aparentar ser mltiples mquinas hosts. Permite que una sola mquina fsica congure y administre independientemente varias aplicaciones administradas. No est asociado a un nodo particular (mquina). Es una conguracin, diferente de un objeto vivo, indicando que puede crearse, pero no arrancarse o detenerse. Cada host virtual tiene un nombre lgico y una lista de uno o ms seudni-
206
mos de DNS por los cuales es conocido. Un seudnimo de DNS es el nombre TCP/IP del host y el nmero del puerto que use la peticin del servlet, por ejemplo su nombre Host:80. El WebSphere Application Server proporciona un host virtual predenido, denominado el default_host, con algunos seudnimos comunes, como el IP de la mquina, nombre corto del host, y el nombre del host completo. El seudnimo comprende la primera parte del camino para el acceso a un recurso, como un servlet. Por ejemplo, localhost:80 en la peticin http://localhost:80/servlet/snoop. Los hosts virtuales le permiten al administrador aislar y manejar independientemente los mltiples grupos de recursos en la misma mquina fsica.
7.6
Workplace Client Technology Micro Edition
Workplace Client Technology Micro Edition (WCTME) es una plataforma intergrada para la extensin de aplicaciones empresariales existentes hacia dispositivos clientes manejados por servidor como ser un computador de escritorio, sistemas mviles, PDAs, y otros dispositivos mviles y pervasivos. El paquete integrado combina las herramientas WebSphere Studio Device Developer y Micro Environment Toolkit for WebSphere Studio, con los tiempos de ejecucion de WebSphere Everyplace Micro Environment, Service Management Framework (SMF), y WebSphere Everyplace Custom Environment, y el middleware (DB2e, MQe, Web Services), para construir, testear y lanzar software cliente manejado por servidor en dispositivos pervasivos. En escencia WCTME es la plataforma base para la familia WCT que ofrece IBM y provee una plataforma robusta que soporta dispositivos desde telfonos celulares, PDAs y otros dispositivos con teclado, mviles y hasta sistemas de escritorio. Independientemente de que si la computadora est siempre, ocasionalmente o rara vez conectada, el modelo WCTME permite extender las aplicaciones y modelos de programacin usando los estndares de la industria y sin tener que volver a reescribir todo usando estos dispositivos. La plataforma WCTME est construido como una combinacin de una plataforma cliente rica basado en el modelo de Eclipse (originalmente ideado
7.6. WCTME
207
para herramientas, y motivado para ser una plataforma de aplicacin ms genrica) al igual que el modelo basado en navegador. Eclipse es una plataforma para la construccin de herramientas de desarrollo de software potentes y ricas aplicaciones de escritorio [5].
7.6.1
WebSphere Everyplace Micro Environment
WebSphere Everyplace Micro Environment es una implementacin de IBM de la especicacin J2ME que cumple con la autorizacin y lneas guias funcionales denidas por Sun Microsystem para obtener Java Powered Logos.
7.6.2
WebSphere Everyplace Custom Environment
Similar a Websphere Everyplace Micro Enviroment, WebSphere Everyplace Custom Environment provee un conjunto mayor de libreras y funciones para habilitar a clientes y asociados a crear versiones ms a medida de la Java run times especca, sin necesariamente tener que cumplir con estndares establecidos.
7.6.3
J9
La J9 es una implementacin independiente de IBM de la Maquina Virtual de Java. La combinacin de la J9 junto con la conguracin y los perles conforman el ambiente de ejecucin o run times. Las conguraciones y perles son libreras de clases en Java.
7.6.4
WebSphere Studio Device Developer
WebSphere Studio Device Developer es un IDE de IBM para J2ME que extiende Eclipse para el desarrollo de aplicaciones Java o C/C++ que corren en dispositivos pervasivos, y forma el nucleo de el WCTME.
208
7.6.5
Java 2 Micro Edition (J2ME)
J2ME es un plataforma Java para dispositivos embebidos. Al igual que las plataformas Enterprise J2EE y escritorio J2SE, J2ME es un conjunto de APIs Java estndar que entrega el poder y los benecios de la tecnologa Java a medida para los dispositivos embebidos, incluyendo interfaces de usuario exibles, modelo de seguridad robusto, gran rango de protocolos de red y soporte para aplicaciones conectadas y desconectadas a la red.
7.7
WebSphere Studio Device Developer
Device developer es un IDE (Integraded Development Enviroment) para el desarrollo, depuracin y despliegue de aplicaciones que sern lanzadas en computadoras de mano y otros dispositivos pequeos [5]. Esto ayuda a los desarrolladores a crear aplicaciones que habilitan a los dipositivos (telfonos celulares, PDAs, y computadoras de mano) a formar parte de una solucin e-businnes end-to-end. El entorno de desarrollo integrado tambin viene con una copia del WebSphere Micro Environment (IBM-compatible con J2ME JVM), con licencia para el desarrollo. Con WebSphere Studio Device Developer se extiende las capacidades del banco de trabajo o workbench permitiendo:
Crear aplicaciones WebSphere Studio Device Developer y correrlas localmente. Crear una Suite de MIDlet y correla localmente (en un emulador de MIDlet). Lanzar y depurar aplicaciones en varios dispositivos.
7.7. WEBSPHERE STUDIO DEVICE DEVELOPER
209
7.7.1
Componentes de WebSphere Studio Device Developer
El Workbrenck de Device Developer incluye como componetes a una J9, utilidades, y un paquete de herramientas para el desarrollo ms el SmartLinker para el preenlazado de archivos class en la aplicacin. J9 Runtimes, Utilidades y Herramientas El WebSphere Studio Device Developer incluye como componentes a un paquete de J9 runtimes, utilidades y herramientas, para construccin y lanzamiento de aplicaciones Java en el ambiente de desarrollo. Actualmente, los ambientes de desarrollos soportados son: Windows XP/2000. Red Hat Linux 8. MicroAnalyzer MicroAnalyzer es usado para perlar y analizar la ejecucin de los programas en un dispositivo embebido. En la vista Analizer se pueden agregar eventos de usuario al cdigo y ratrear su ejecucin en una prueba fsica corriendo en una maquina virtual J9. Esta informacin puede ser usada para optimizar los programas en cuanto a velocidad, tamao y eciencia global.
7.7.2
Herramienta de Desarrollo C (CDT) para Eclipse
Device Developer incluye el CDT (C Development Tooling) de Eclipse que permite escribir cdigo C e integrar con aplicaciones Java. Se pueden crear proyectos en lenguaje C en el espacio de trabajo, construir y compilar estos proyectos y enlazarlos a otros proyectos (estos son, WebSphere Studio Device Developer o otros proyectos Java) en el espacio de trabajo o WorkSpace.
210
7.7.3
Arquitectura de Device Developer
WebSphere Studio Device Developer forma parte de la familia WebSphere. Todo producto WebSphere Studio tiene un apecto en comn, el WebSphere Studio Workbench (WSWB ), que es la versin de IBM de la plataforma Eclipse. Eclipse es un IDE de cdigo abierto (open-source). Utiliza un plug-in diseado para ampliar su funcionalidad bsica, ya que solo hace muy poco. Debido a que es de cdigo abierto, se podr contribuir a su desarrollo. Peridicamente, IBM toma una instantnea de Eclipse y los distribuye como el WebSphere Studio Workbench, que est diseado para ser una plataforma de desarrollo para socios de negocio para ampliar la arquitectura bsica y complementos. Estas herramientas tambin deben ser capaces de conectar a Eclipse, as como los miembros de la familia de productos de WebSphere Studio.
7.7.4
Utilizacin del IDE
WebSphere Studio Device Developer utiliza el concepto de espacio de trabajo o workspace, un directorio que contiene el cdigo de trabajo (un subdirectorio por cada proyecto), y un subdirectorio de metadatos que contienen informacin sobre el cdigo. La creacin de un acceso directo es importante cuando se desee utilizar mltiples espacios de trabajo, puesto que se puede usar la bandera -data para poner un especco espacio de trabajo en ejecucin, por ejemplo, wsdd.exe -data C:\user_workspace\project, se utilizar el subdirectorio project en el directorio user_workspace como su espacio de trabajo. WebSphere Studio Device Developer tambin utiliza el concepto de proyecto, una coleccin de paquetes que componen la totalidad de una aplicacin, ya sea Java u otra. Por ejemplo, se podr crear un proyecto Java, J2ME, MIDlet, C u otro tipo. Se puede pensar a un proyecto como un super-paquete. La pantalla de bienvenida acta como un archivo readme para la versin de la herramienta, y se muestra automticamente la primera vez que invoca
211
Figura 7.8: Barra de herramientas de WSDD.
el producto. Tambin se encuentra en el men Ayuda. La herramienta se divide en Perspectivas, barras de herramientas, vista, y editores. La pantalla entera es a veces llamado el Workbench. Una perspectiva es una coleccin predenida de barras de herramientas, vistas y editores [4].
Barra de Herramientas La barra de herramientas superior que se encuentra bajo el menu principal, contiene a todos los asistentes disponibles de WebSphere Studio Device Developer (ver g. 7.8de la pg. 211). Los asistentes se pueden utilizar para crear aplicaciones, probar cdigo, crear estructuras Java, crear proyectos, crear dispositivos, congurar dispositivos, generar construcciones de un proyecto para su distrubucin. La barra izquierda de herramientas contiene todas las perspectivas y / o vistas abiertas.
212
Perspectiva, Editores y Vistas
Una perspectiva es un grupo de vistas y editores en la ventana del espacio de trabajo diseadas para centrarse en una determinada tarea. En una ventana del espacio de trabajo pueden existir una o varias perspectivas. Cada perspectiva contiene una o varias vistas y editores. Dentro de una ventana, cada perspectiva puede tener un conjunto distinto de vistas, pero todas las perspectivas comparten el mismo conjunto de editores. Tambin se puede personalizar perspectivas y guardarlas. Una vista es un componente visual del espacio de trabajo. Se suele utilizar para navegar en una jerarqua de informacin (como los recursos del espacio de trabajo), abrir un editor o visualizar propiedades del editor activo. Las modicaciones efectuadas en una vista se guardan inmediatamente. Slo puede existir una instancia de un tipo de vista concreto en una ventana del espacio de trabajo. Un editor se utiliza para modicar los archivos, y es especco para el tipo de archivo que est siendo editado. Con WebSphere Studio Device Developer, se puede especicar editores externos para determinados tipos de archivo. Slo un editor puede estar activo en cualquier momento, varios editores se podrn abrir, pero todos estarn en la misma ventana, disponible a travs de pestaas. El editor del cdigo fuente es una de las ventanas principales del WSDD. Este editor est siempre presente, aunque cambiemos entre las distintas perspectivas. Como su nombre lo indica, en este editor se muestra el cdigo fuente de la clase con todos sus elementos. Pero adems incluye diversas funcionalidades para ayudar al desarrollador, entre ellas se tiene:
213
Utiliza distintos colores para diferenciar entre palabras reservadas, comentarios, cadenas de texto, y nombres de variables. De este modos se pueden encontrar e identicar ms fcilmente una lnea de texto o una instruccin. Muestra los campos y mtodos pertenecientes al objeto al que se est haciendo referencia segn se va escribiendo (ver g. 7.9 de la pg. 213). De esta forma, se puede elegir el que se quiera a travs de la lista. Adems, en la lista de mtodos de los objetos, se indican los parmetros necesarios en la llamada al mismo, y el tipo del valor que devuelve, junto con una breve descripcin del mismo. Incluye una funcin automtica para cerrar parntesis y corchetes. En caso de cometer algn error de sintaxis, remarca la parte de cdigo errnea en rojo. Utiliza advertencias que son subrayados amarillos. Las advertencias no sern causa de error, pero ayudan a mejorar el cdigo; por ejemplo, importar alguna clase que no se utilice nunca.
Figura 7.9: Mtodos de un Objeto.
Dispositivos Cada dispositivo requiere una conguracin separada. Todos los dispositivos se comparten, por lo que cualquier proyecto puede ser desplegados en un dispositivo especco.
214
WebSphere Studio Device Developer soporta dispositivos Palm (a travs de HotSync), emulador Palm, y dispositivos PocketPC (a travs de ActiveSync) directamente. WebSphere Studio Device Developer tambin ejecutar proyectos a nivel local JVM, y aplicaciones MIDP pueden ser desplegados en un emulador MIDP. Otros proveedores pueden incluir emuladores soportados a travs de plugins Eclipse. Estos deben estar disponibles a travs del gestor de actualizaciones, o directamente desde el proveedor. Aadir Emuladores Una manera de probar las aplicaciones que se disean es aadiendo emuladores que proveen los fabricantes. Webphere Studio Device Developer permite aadir emuladores de distintos fabricantes. Por ejemplo si se desea aadir un emulador de un telfono celular Nokia serie 40, se deben seguir los siguientes pasos: Descargar el emulador deseado desde el sitio ocial de Nokia. Instalar el SDK de Nokia recien descargado. Luego a travs de la opcin dispositivos congurar y luego hacer click en Dispositivo Emulador de UEI . Luego se tiene que indicar la ruta donde se encuentra instalado el emulador para que Websphere Studio Device Developer pueda invocarlo. Por ltimo se debe asignar un nombre al nuevo dispositivo. Los pasos anteriormente se pueden ver en la g. 7.10 de la pg 215.
Figura 7.10: Nuevo Dispositivo Emulador.
216
Captulo 8
Descripcin de la Aplicacin
8.1 Introduccin
El presente trabajo consiste en la creacin de una aplicacin con software de Computacin Mvil Multiplataforma, que permita el acceso a informacin situada en bases de datos multiplataforma en un servidor Web, a travs de dispositivos mviles tales como telfonos celulares. El objetivo de la aplicacin es la automatizacin de servicios orientados al cliente, para que los mismos sean accesibles a travs de telfonos celulares y estn disponibles en la Web, ya que los clientes cada vez requieren aplicaciones de este tipo, que estn siempre disponible en cualquier momento y en cualquier lugar. Se trata de un sistema orientado a actividades tpicas de una entidad bancaria, donde se pueden realizar todo tipo de operaciones tales como: Dar de alta a un cliente y administrar sus datos. Crear cuentas bancarias para un cliente determinado. Conocer el saldo actual de una cuenta. Conocer los movimientos asociados una cuenta bancaria determinada. Realizar operaciones como: depsitos, extracciones, transferencias. 217
218
CAPTULO 8. DESCRIPCIN DE LA APLICACIN
Para el desarrollo del trabajo se utiliz el lenguaje de programacin Java, debido a que sus caractersticas lo hacen adecuado para el propsito planteado: seguridad, robustez y sobre todo, portabilidad. La variedad de dispositivos existentes en el mercado condiciona que la aplicacin deba ser compatible con todos ellos. Como es conocido, la portabilidad es una de las caractersticas inherentes al lenguaje Java. Como se ha visto en el captulo cinco las tecnologas Java se agrupan en varias familias, cada una de ellas adecuada para el desarrollo de distintos tipos de aplicaciones: Java 2 Standard Edition (J2SE): Orientada a ordenadores de sobremesa (aplicaciones de usuario, applets, etc.). Java 2 Enterprise Edition (J2EE): Orientada al desarrollo de aplicaciones para servidores utilizados en un entorno empresarial. Incluye la clase Servlet para el desarrollo de aplicaciones en el servidor. Java 2 Micro Edition (J2ME : Es un subconjunto de J2SE orientado al desarrollo de aplicaciones Java destinadas a dispositivos con pocos recursos y capacidades restringidas, como telfonos mviles o asistentes personales digitales (PDAs). Incluye la clase MIDlet para el desarrollo de aplicaciones en el cliente. El sistema est pensado de forma tal que pueda ser utilizado por distintos usuarios con distintos privilegios. A continuacin se detallan los perles usuarios que se manejan: Administrador. Operador. Cliente/mvil. Cliente/web. Cada uno de estos perles determina las funciones que estn disponibles para el usuario. En el caso de uso que muestra la g. 8.1 de la pg. 219 se puede apreciar a grandes rasgos qu funciones del sistema se encuentran disponibles de acuerdo al tipo de usuario.
8.1. INTRODUCCIN
219
Figura 8.1: Casos de Usos del Sistema.
220
8.2
Estructuracin
La aplicacin est estructurada en dos partes: La parte Web que est desarrollada en el lenguaje Java concretamente J2EE que corre en un servidor Web y se accede a travs de un navegador de Internet. La parte mvil que se encuentra desarrollada tambin en el lenguaje Java, especcamente en J2ME (Java 2 Micro Edition), sta corre en el dispositivo mvil (celular ) y por lo tanto debe descargarse e instalarse en el dispositivo en cuestin.
8.2.1
La Aplicacin Mvil (Mobile Banking)
Para el desarrollo mvil se opt por usar el modelo cliente / servidor como se ve en la g. 8.2 de la pg. 221. En donde: Gestin de datos: Comprende la parte de la aplicacin encargada del acceso a la base de datos para recuperar la informacin solicitada desde el dispositivo mvil. Emplea JDBC (Java Database Connectivity) como nivel intermedio entre esta capa y la siguiente. De esta forma, un cambio en el gestor de la base de datos empleado no requerir modicaciones en la aplicacin, sino que slo ser necesario sustituir el driver JDBC por otro apropiado para el nuevo gestor. Lgica de negocio: Esta capa contiene los servlets de Java que recibe e interpreta las peticiones del cliente y genera las consultas a la base de datos, devolviendo la informacin solicitada. Capa presentacin: incluye el cdigo Java 2ME ejecutado en el dispositivo mvil. El diagrama de clases de la g. 8.3 de la pg. 222 muestra cmo se estructura internamente el sistema mvil. Como se ve, se estructura en ocho clases (Pantalla, Mprincipal, Cuenta, Comunicacin, Balance, Tranferencia, MenuCuenta, Movimiento). La clase
8.2. ESTRUCTURACIN
221
Figura 8.2: Arquitectura del Sistema.
222
Figura 8.3: Diagrama de Clases de la Aplicacin Mvil.
8.2. ESTRUCTURACIN
223
MIDlet es la clase general de toda aplicacin mvil, como se desarrolla con la conguracin CLDC y el perl MIDP. La aplicacin contiene a la clase Pantalla que hereda de MIDlet, por lo tanto es un Midlet. Esta clase Pantalla es la clase principal que maneja todo el comportamiento de la aplicacin, iniciar la aplicacin, pausar la aplicacin, destruir la aplicacin y gestionar las pantallas que se muestran. A continuacin se describen cada una de las clases con sus atributos y mtodos. Pantalla Esta clase extiende de la clase MIDlet como se puede ver en el grco 8.3 de la pg. 222, por lo tanto hereda sus mtodos. La clase MIDlet del paquete javax.microedition, como se vi en el captulo en cuestin, posee tres mtodos abstractos, stos son heredados e implementados por la clase Pantalla. La siguiente g. 8.4 de la pg. 224 muestra los atributos y mtodos que corresponden a la clase Pantalla. MPrincipal Esta clase est destinada a manejar el men principal de la aplicacin. La g. 8.5 de la pg. 224 muestra los atributos y mtodos de la clase MPrincipal. MenuCuenta Clase que muestra la interfaz sobre el men de operaciones disponibles para una cuenta determinada. En la g. 8.6 de la pg. 225 se puede ver la estructuracin de la misma. Comunicacion Es la clase principal para la realizacin de todas las comunicaciones con el servidor, ya que posee mtodos que permiten enviar peticiones y recibir las respuestas del servidor. Esta clase implementa la interfaz Runnable para la utilizacin de Thread (hilos de Java) que permite hacer una peticin y a la vez seguir operando en la aplicacin hasta recibir la respuesta del servidor. Mobile Banking muestra pantallas de aviso al usuario cuando se est realizando una peticin al servidor.
224
Figura 8.4: La Clase Pantalla .
Figura 8.5: La Clase MPrincipal.
8.2. ESTRUCTURACIN
225
Figura 8.6: La Clase MenuCuenta. En la g. 8.7 de la pg. 226 se describen los mtodos y atributos de la clase Comunicacion. Transferencia Esta clase maneja toda la interfaz e informacin acerca del mdulo de transferencia de fondos. En la g. 8.8 de la pg. 226 se puede apreciar el detalle de la clase. Balance Esta clase mantiene un formulario que contiene informacin de una cuenta (saldo actual, tipo de cuenta, identicacin de la cuenta). Los mtodos y atributos de la clase balance se pueden ver en la g. 8.9 de la pg. 227. Movimiento La clase Movimiento se encarga de manejar la interfaz y la informacin de los movimientos realizados en la cuentas, contiene un objeto List para mostrar la lista de movimientos y un formulario para mostrar el detalle de un
226
Figura 8.7: La Clase Comunicacion.
Figura 8.8: La Clase Transferencia
8.2. ESTRUCTURACIN
227
Figura 8.9: La Clase Balance. movimiento especco. La g. 8.10 de la pg. 228 muestra sus mtodos y atributos. Adems realiza operaciones de alta de registros y bsqueda de movimientos almacenados en el celular. Cuenta Gestiona la informacin a cerca de las cuentas bancarias que se encuentran almacenadas en la base de datos del celular. Posee mtodos que realizan las siguientes operaciones:
Bsqueda de una cuenta determinada. Insercin de una cuenta. Actualizacin de una cuenta.
En la g. 8.11 de la pg. 229 se puede apreciar el contenido de esta clase.
228
Figura 8.10: La Clase Movimiento.
8.2. ESTRUCTURACIN
229
Figura 8.11: La Clase Cuenta. La Aplicacin Mvil en Funcionamiento El interfaz grco de Mobile Banking es una interfaz simple, permite una fcil interaccin con el usuario, es estndar para todos los terminales mviles que soportan J2ME. Por razones de que se trata de una aplicacin de negocios y para lograr la mayor portabilidad posible del aplicativo se eligi para desarrollar la interface de usuario las APIs de alto nivel, donde no se tiene un control total del aspecto de los controles, su esttica depende exclusivamente del dispositivo donde se ejecute. Para ms informacin a cerca de interfaces grcas ver captulo cinco (J2ME ). Otro aspecto muy interesante a la hora de desarrollar una aplicacin mvil utilizando J2ME es poder almacenar localmente cierta informacin til en el telfono celular para no tener que volver a realizar una peticin al servidor sobre datos solicitados anteriormente. Mobile Banking proporciona la posibilidad de almacenar cierto tipo de informacin (como ser cuentas, saldos de cuentas, movimientos de una cuenta, y ciertas conguraciones) en la zona de almacenamiento persistente del telfono
230
mvil. Para implementar esta funcionalidad, utiliza el sistema de gestin de registros, conocido como Record Management System (RMS). Ms adelante se describir con ms detalle la estructura de estos registros. Mobile Banking posee conectividad con un servidor Web, para lograr esto utiliza Internet mvil y la tecnologa GPRS (General Packet Ratio Service) donde no se factura al usuario por tiempo de conexin, sino por datos enviados y recibidos. Por lo tanto la aplicacin minimiza el intercambio de datos, intercambiando solamente datos puros y los almacena en el celular para poder trabajar de manera o-line. Esto quiere decir que el terminal mvil debe poseer conectividad a Internet como requisito para poder utilizar el sistema y por supuesto poder ejecutar aplicaciones Java. Como se ha mencionado en el captulo cinco (J2ME ) las aplicaciones que se desarrollan bajo la conguracin CLDC (Conected Limited Device Conguration) y el perl MIDP (Mobile Information Device Prole) se denominan MIDlets. Por lo tanto Mobile Banking como se desarroll bajo la conguracin CLDC 1.1 y el perl MIDP 2.0 es un MIDlet. La g. 8.12 de la pg. 231 representa la pantalla principal de la aplicacin mvil, Mobile Banking. Esta pantalla (pantalla principal ) permanece activa hasta que el usuario presione el comando iniciar. Al presionar el comando iniciar inmediatamente se presenta al usuario el men principal del sistema que cuenta con los siguientes tems: INICIAR SESIN. MODO OFF-LINE. CONFIGURACIN. AYUDA. SALIR. Iniciar sesin: En este tem la aplicacin trabajar en modo on-line, solicitando previamente autenticacin del usuario a travs de un nombre usuario
8.2. ESTRUCTURACIN
231
Figura 8.12: Pantalla Principal Mobile Banking .
232
y clave, donde stos son entregados al usuario al registrarse en el sistema banking. Modo o-line: Al elegir esta instancia, la aplicacin buscar si existen datos almacenados localmente en el celular, para poder mostrar al usuario los mismos. Es decir para que pueda ser operativa esta parte de la aplicacin, el usuario por lo menos una vez tuvo que haber iniciado sesin y realizado algunas operaciones, caso contrario se avisar que no existen datos almacenados localmente y por lo tanto no se puede operar en este modo. Conguracin: Esta opcin es til para poder congurar la url nica donde reside el servidor por ejemplo, http://www.servidorBanking.com , esta informacin se guarda en el almacenamiento persistente del mvil. Antes de utilizar cualquier opcin se debe primeramente cargar este valor. Ayuda: Como su nombre lo indica, esta opcin brinda informacin acerca de la utilizacin de Mobile Banking. Salir : Esta opcin permite al usuario salir de la aplicacin. Lo anteriormente mencionado se puede observar en la g. 8.13 de la pg. 233. Iniciar Sesin Para acceder o iniciar sesin se debe completar un usuario y clave e intentar conectarse. Para ello se le muestra al usuario la siguiente pantalla de la g. 8.14 de la pg. 234, donde antes de ser enviados los datos son validados localmente, por ejemplo si se intenta enviar usuario y clave vacos o si la clave posee menos de ocho caracteres. La aplicacin le avisar al usuario a travs de alertas en caso de que ocurran algunos de los casos mencionados. La g. 8.14 de la pg. 234 muestra la pantalla de ingreso y cmo la aplicacin avisa al usuario de determinados errores. Una vez que los datos sean ingresados correctamente sern enviados al servidor, donde tambin son validados por el mismo, se puede decir que existe una validacin en las dos partes, en el cliente (MIDlet) y en el servidor (Servlet). Mientras los datos son enviados y procesados por el servidor, el aplicactivo muestra una pantalla informndole al usuario que se est realizando la
8.2. ESTRUCTURACIN
233
Figura 8.13: Men Principal.
234
Figura 8.14: Pantallas de Ingreso al Sistema.
8.2. ESTRUCTURACIN
235
conexin. En la g. 8.15 de la pg. 235 se puede ver la pantalla mencionada.
Figura 8.15: Pantalla de Aviso de Conexin. La clase Servlet es la encargada de realizar la conexin a la base de datos y corroborar que los datos recibidos son realmente iguales a los datos almacenados en la base. Luego del proceso de bsqueda y vericacin el Servlet enva al celular un error o bien la informacin del cliente ms sus cuentas correspondientes si el resultado de la vericacin resulta satisfactoria. Luego de realizar la autenticacin del usuario, si resulta satisfactoria se recibe la informacin del cliente con los siguientes datos: Nmero de cliente. Nmero de documento. Nombre. Apellido.
236
En una pantalla se muestra esta informacin del cliente, la misma se puede apreciar en la g. 8.16 de la pg. 236.
Figura 8.16: Informacin del Cliente. En una pantalla posterior el usuario puede visualizar las cuentas que dispone para operar (ver g. 8.17 de la pg. 237) en una lista y al seleccionar una de ellas se presenta una nueva pantalla con las distintas operaciones que se pueden realizar en una determinada cuenta. Las opciones disponibles son: Consultar Saldo. Transferencia. Consultar movimientos. El men de opciones se puede apreciar en la g. 8.18 de la pg. 238.
8.2. ESTRUCTURACIN
237
Figura 8.17: Lista de Cuentas.
238
Figura 8.18: Men de Operaciones de una Cuenta.
8.2. ESTRUCTURACIN
239
Operaciones Sobre una Cuenta Determinada Consultar saldo: Este tem del men permite conocer el saldo actual que contiene la cuenta. A continuacin se detalla la informacin de la cuenta del usuario que se puede visualizar: Identicacin nica de la cuenta. Tipo de cuenta pudiendo ser una de las siguientes: Caja ahorro, cuenta corriente, plazo jo. Saldo actual de la cuenta. Toda esta informacin una vez descargada en el celular quedar almacenada en el almacenamiento persistente del dispositivo, para poder consultar a posteriori sin necesidad de realizar una peticin al servidor. En la g. 8.19 de la pg. 240 se puede visualizar esta informacin. Transferencia: Mobile banking brinda la posibilidad de poder realizar transferencias de fondos a otra cuenta que posea el cliente o bien a una cuenta de algn otro cliente, siempre y cuando la cuenta origen disponga de dinero suciente o bien si es una cuenta corriente posea un sobregiro que lo permita. Los datos que se deben ingresar son la identicacin de la cuenta destino ms el monto a transferir (ver g. 8.20 de la pg. 241) y a continuacin se presenta una pantalla de conrmacin de la transferencia a realizar, si el usuario acepta se envan los datos para poder realizar la transaccin (ver g. 8.21 de la pg. 242). La aplicacin valida si se ingresa algn monto igual a cero o bien si no se ingresa el monto. Del lado del servidor tambin existe un proceso de vericacin de saldo de la cuenta origen y si la cuenta destino ingresada es vlida para que se pueda realizar un depsito en la misma. Si la transaccin se realiza satisfactoriamente se enviar al usuario un nmero de transaccin (ver g. 8.22 de la pg. 243). O bien se enviar un mensaje que la transaccin no pudo realizarse y el motivo; (ver g. 8.23 de la pg. 8.23).
240
Figura 8.19: Informacin de Saldo de una Cuenta.
8.2. ESTRUCTURACIN
241
Figura 8.20: Ingreso de Datos Para una Transferencia.
242
Figura 8.21: Conrmacin de la Transferencia.
8.2. ESTRUCTURACIN
243
Figura 8.22: Resultado Satisfactorio de una Transferencia.
244
Figura 8.23: Error en una Transferencia.
8.2. ESTRUCTURACIN
245
Figura 8.24: Lista de Movimientos de una Cuenta por Fecha y Hora.
Consultar movimientos: La aplicacin posee la opcin de poder consultar los ltimos movimientos (hasta tres) realizados en una cuenta determinada, ya sean (extracciones, depsitos o transferencias realizadas). Para realizar esta funcionalidad primeramente se realiza la peticin al servidor, en ese momento se produce el proceso de sincronizacin de los datos (movimientos) desde el servidor al cliente y se almacenan en la memoria permanente del celular . Como se puede apreciar en la g. 8.24 de la pg. 8.24 la aplicacin muestra un listado de movimientos donde se indica la fecha y la hora, al seleccionar un movimiento particular se podrn visualizar en detalle el movimiento seleccionado (ver g. 8.25 de la pg. 246). La prxima vez que el cliente desee consultar por movimientos de la misma cuenta el aplicativo le preguntar si desea visualizar los movimientos almacenados localmente o desea realizar el proceso de sincronizacin. Esta adver-
246
Figura 8.25: Detalle de un Movimientos en Particular.
8.2. ESTRUCTURACIN
247
tencia se nota en la g. 8.26 de la pg. 247.
Figura 8.26: Pantalla de Advertencia al Usuario. O-line Esta funcionalidad de la aplicacin de trabajar en modo o-line permite acceder a informacin ya solicitada, sin tener que realizar una peticin al servidor. Es decir el aplicativo slo intenta mostrar la informacin almacenada, no intenta realizar una ninguna conexin con el servidor. En este modo se pasa por alto la pantalla de login o identicacin del usuario, ya que para poder utilizar el modo o-line se tuvo que haber operado on-line anteriormente. Si no existen datos almacenados localmente el usuario ser avisado de la cuestin. Esta advertencia se puede apreciar en la g. 8.27 de la pg. 248. La ventaja que brinda hacia los clientes es la minimizacin de costos, al no tener que intercambiar datos con el servidor sobre datos ya solicitados. Por ejemplo un cliente desea ver sus movimientos del da, entonces se conecta una vez, los puede mirar y los mantiene en el celular para prximas consultas sin
248
Figura 8.27: Advertencia al Usuario.
8.2. ESTRUCTURACIN
249
tener que volver a conectarse. La funcin de transferir fondos no est disponible en modo o-line. Conguracin Como se mencion anteriormente lo primero que debe hacer el usuario del sistema para poder utilizar Mobile Banking es congurar la direccin (url) del servidor para lograr una comunicacin satisfactoria, ya que el servidor alberga a los servlets de Java que reciben las peticiones y hacen el proceso real de conectarse a la base de datos, solicitar informacin y vericar si es un cliente vlido. Para poder realizar esta tarea el usuario debe seleccionar la opcin conguracin, en ese instante se mostrar la siguiente pantalla del sistema que se ve en la g. 8.28 de la pg. 8.28.
Figura 8.28: Pantallas Para Congurar la URL del Servidor. Esta informacin quedar guardada en la base de datos del celular y podr ser modicada en cualquier momento que se desee.
250
Una vez que se tiene congurado correctamente la direccin del servidor se puede lograr la comunicacin con el mismo. Se debe proporcionar los datos de acceso (usuario y clave). Ayuda Este mdulo est destinado a brindarle al usuario un texto informativo sinttico acerca de cmo utilizar la aplicacin mvil. En la g. 8.29 de la pg. 250 se puede observar la pantalla de ayuda. Bsicamente brinda informacin introductoria al sistema, e instrucciones para operar el aplicativo, como ser: La conguracin del URL del servidor. Cmo iniciar sesin en el sistema. Cules son los tipos de operaciones disponibles para una cuenta.
Figura 8.29: Pantalla de Ayuda del Sistema.
8.2. ESTRUCTURACIN
251
Estructura de Registros Almacenados en el Telfono Gracias a la implementacin del sistema de gestin de registros (RMS ) se pueden guardar informacin en el telfono celular. En la g. 8.30 de la pg. 251 se pueden ver los RecordStores que utiliza Mobile Banking, siendo un RecordStore un almacn de registros.
Figura 8.30: RecordStores Utilizados por la Aplicacin. Sabiendo que los registros de un RecordStore pueden guardar en un formato de tipo bytes se presenta la estructura de los mismos: RecordStore: servidor: Id: identicacin del registro dentro del RecordStore. Url: Campo de tipo String que debe transformarse a bytes antes de grabarlo. Generalmente este RecordStore mantiene un solo registro en donde se puede modicar el valor del URL cuando se requiera. RecordStore: Cuentas:
252
Los campos que maneja son los siguientes: idcuenta. tipocuenta. saldo. Para delimitar un campo de otro se utiliza @, de la siguiente manera: registro = idCuenta_valor@tipoCuenta_valor@saldo_valor donde registro es una cadena String y debe ser transformado a ujos de bytes antes de ser insertado al RecorStore Cuentas. RecordStore: Movimientos Guarda la siguiente informacin: idMovimiento. idcuenta. fecha. hora. tipoMovimiento. monto.
En donde tambin se estructura de la misma manera que los registros del almacn cuentas con el delimitador de campo @. La aplicacin utiliza algoritmos de parseo para poder mostrar correctamente la informacin guardada. Las operaciones que realiza Mobile Banking sobre RMSs son: Creacin de los RecordStores. Insercin de registros. Bsqueda de algn registro. Consulta de registros.
8.2. ESTRUCTURACIN
253
Figura 8.31: Proceso del Mensaje Calculado. Autenticacin en Mobile Banking Para la realizacin de la autenticacin el sistema solicita al cliente un usuario y una clave. Estos datos mencionados son enviados al servidor por medio de Internet, y como se sabe que Internet es una inmensa red pblica, tiene la desventaja que es una red insegura. Mobile Banking soluciona este problema a travs de la utilizacin de un paquete llamado bouncy castle cryptography que es un paquete open source, es decir de cdigo abierto y libre, realizado en Australia. Es una potente pieza de trabajo, que presenta un API limpio y una gran caja de herramientas sobre algoritmos criptogrcos. Adems su cdigo es liviano y apto para ejecutarse en telfonos celulares. Sun Microsystem brinda soluciones criptogrcas para la tecnologa J2SE a travs del JCA (Java Cryptography Architecture) y la JCE (Java Criptography Extensin), el problema es que estas implementaciones son muy pesadas para la plataforma J2ME. Gracias a el paquete bouncy castle cryptography se pueden obtener algoritmos criptogrcos ms livianos aptos para la plataforma J2ME. Mobile Banking utiliza el concepto de mensaje cifrado para enviar la clave ocultada. En lugar de enviar la clave como texto plano, se crea un mensaje comprendido o cifrado a partir de la clave y se enva ste. En la g. 8.31 de la pg. 253 se puede observar el proceso.
254
En donde: El midlet crea un nmero aleatorio y un nmero tipo timestamp, ambos nmeros junto con el usuario y la clave generan el valor del mensaje comprendido. El midlet enva el usuario, el nmero timestamp, el nmero aleatorio y el valor cifrado calculado al servidor, la clave no se enva como texto claro, es utilizada para calcular el valor cifrado. El servidor toma el usuario y busca la correspondiente clave en la base de datos, tambin toma el numero aleatorio y el timestamp, luego calcula el valor cifrado. Si el valor cifrado calculado en el servidor es igual al valor cifrado enviado por el midlet (cliente) entonces el cliente existe en la base.
8.2.2
La Aplicacin Web
Se desarroll con el lenguaje Java, utilizando las tecnologas de Servlet y JSP, la misma posee acceso a una base de datos que contiene la informacin que maneja la aplicacin. Esta base de datos se encuentra manejada por el motor DB2 UDB 8.1 de IBM. Para ms informacin acerca de DB2 remitirse al captulo seis. Para mejor estructuracin del sistema y a n de incursionar en patrones de diseo, la aplicacin se basa en el patrn MVC (model view controller ) o modelo vista controlador. El Patrn Modelo-Vista-Controlador MVC (Model View Controller ) es un patrn de diseo aportado originalmente por el lenguaje de programacin SmalkTalk a la ingeniera de software. Consiste principalmente en dividir las aplicaciones en tres partes o capas: Modelo. Vista.
8.2. ESTRUCTURACIN
255
Figura 8.32: Modelo-Vista-Controlador. Controlador. El controlador es el encargado de redirigir o asignar una aplicacin a cada peticin; el controlador debe poseer de algn modo, un mapa de correspondencias entre peticiones y respuestas que se le asignan. El modelo es la lgica de negocios. Una vez realizadas las operaciones necesarias el ujo vuelve al controlador y ste devuelve los resultados a una vista adecuada. El siguiente grco 8.32 de la pg. 255 muestra la interaccin entre el modelo, la vista y el controlador. Implementacin del MVC en la Aplicacin La aplicacin est formada por archivos de clases Java, Servlets, JSPs y HTMLs, donde cada uno se encuentra en una de las tres capas. Estructura La aplicacin se estructura bsicamente en tres paquetes bien diferenciados: Presentacin: Contiene la interfaz grca, pginas JSPs o HTMLs que permiten al usuario tener una vista de los datos e ingresar nuevos datos.
256
Control: Contiene las clases que realizan el control de ujo de la aplicacin, se encargan de atender a las peticiones que provienen de la capa de presentacin. Modelo de negocios: Se puede decir que es el paquete base de la aplicacin, ya que contiene clases que manejan el modelo de negocios, como ser: Clientes. Cuentas. Movimientos. La g. 8.33 de la pg. 256 muestra un diagrama de la estructura de paquetes mencionada.
Figura 8.33: Diagrama de Paquetes. El modelo de negocios que se puede apreciar en la g. 8.34 de la pg. 257 contiene las siguientes clases: Cliente: Mantiene informacin de clientes del banco. Cuenta: Mantiene informacin de una cuenta bancaria, un cliente puede tener ms de una cuenta.
8.2. ESTRUCTURACIN
257
Figura 8.34: Diagrama de Clases. Movimiento: Corresponde a objetos que contienen informacin acerca de las transacciones que ocurren sobre una cuenta. Usuario: Reere a los usuarios del sistema. Acceso: Contiene informacin de acceso de clientes al sistema. Banco: Clase principal, acta como coordinador, encapsulando los otros objetos y cmo ellos interactan.
258
Funcionamiento El navegador genera una peticin que es atendida por un controlador (un Servlet especializado), el cual se encarga de analizar la solicitud y utiliza objetos del modelo para concretar la tarea. Dependiendo del resultado, el ujo vuelve al controlador y ste analiza a cul JSPs derivar la generacin de la interfaz, dnde stos podrn consultar los objetos del modelo para poder mostrar informacin de los mismos. En la g. 8.35 de la pg. 258 se puede apreciar el funcionamiento mencionado.
Figura 8.35: Funciomamiento del Sistema. Entonces se puede decir que el sistema internamente est estructurado en clases Java que manejan el ujo de control, clases Java que forman la lgica de negocio y la archivos JSPs que forman la vista o interfaz grca y que contienen tanto porciones de cdigo Java, como tambin cdigo HTML.
Pantallas de la Aplicacin Web El sistema Banking est dividido en dos perspectivas:
8.2. ESTRUCTURACIN
259
La perspectiva orientada al cliente que pueden acceder los mismos a travs de la Internet. La perspectiva orientada al operador / Administrador donde se accede a travs de la Intranet. Del Lado del Cliente (Home Banking) En esta parte de la aplicacin el usuario tiene disponibles casi las mismas opciones que se utilizan en la aplicacin mvil, con algunas opciones adicionales como por ejemplo poder visualizar en qu consiste la aplicacin mvil (Mobile Banking) y la posibilidad de poder descargarla e instalarla en el telfono celular. Esta porcin de la aplicacin automatiza la gestin de cuentas bancarias, brindndole al cliente una alternativa para realizar sus operaciones, sin la necesidad de recurrir a la entidad bancaria y adems el cliente puede acceder al sistema las 24 hs. del da. A continuacin se muestra en la g. 8.36 de la pg. 260 la pgina principal del portal. Para poder acceder a las opciones brindadas por el sistema Home Banking el usuario debe ingresar sus datos de acceso, ingresando el usuario y una clave. La aplicacin del lado del cliente valida si se presion el botn ingresar y los campos del usuario y/o la clave estn vacos mediante el uso del lenguaje JavaScritpt. Si los datos del cliente no son correctos se presentar la pantalla que se muestra en la g. 8.37 de la pg. 261, donde sta avisa al usuario del error de ingreso. Una vez que el usuario se haya validado en el sistema, dispone de un men con las siguientes opciones: Cambiar clave. Cuentas. Transferir.
260
Figura 8.36: Pantalla Principal de Home Banking.
8.2. ESTRUCTURACIN
261
Figura 8.37: Mensaje de Error.
262
Movimientos. Mobile Banking. Salir. Cambiar clave: A travs de esta seccin del sistema, el cliente puede realizar el cambio de su clave de acceso peridicamente. Home Banking muestra una leyenda de recomendacin de cambio de clave cada sesenta das aproximadamente para aumentar la seguridad. En el momento del cambio de clave, el cliente deber ingresar su clave actual y la nueva clave, sta ltima tendr que ingresar nuevamente y ser validado por el sistema si ambas claves son iguales. El sistema no permite el ingreso de una clave cuya longitud sea menor a ocho caracteres. La pantalla que corresponde al formulario que permite el cambio de clave del cliente se puede apreciar en la g. 8.38 de la pg. 262.
Figura 8.38: Pantalla de Modicacin de Claves.
8.2. ESTRUCTURACIN
263
Salir : A travs de este tem el cliente puede salir del sistema y el navegador ser reenviado a la pgina principal. Cuentas: Con esta opcin el cliente puede ver las cuentas bancarias que tiene. La pgina muestra un listado de cuentas. Esta pgina se muestra inmediatamente luego del proceso de vericacin de ingreso al sistema. En cualquier momento el usuario puede utilizar esta opcin para la eleccin de otra cuenta disponible y operar sobre ella. Esto se puede visualizar en la g. 8.39 de la pg. 263.
Figura 8.39: Pantalla de Listado de Cuentas. Luego al seleccionar una cuenta disponible es posible ver la informacin de la cuenta como ser:
264
Identicacin de la cuenta. No DNI/LC/LE del titular. Nombre del titular. Saldo disponible. Tipo de cuenta. Tasa de inters de la cuenta. Monto sobregiro (si posee). Esta informacin se puede visualizar en la g. 8.40 de la pg. 264.
Figura 8.40: Detalle de una Cuenta Determinada. Transferir : Desde esta parte de la aplicacin se pueden realizar transferencias de fondos hacia otras cuentas bancarias del mismo cliente o de algn otro cliente.
8.2. ESTRUCTURACIN
265
Para la realizacin exitosa de esta funcionalidad se debe ingresar la identicacin de la cuenta destinataria de la operacin, tambin se tiene que ingresar el monto a transferir; ver g. 8.41 de la pg. 265.
Figura 8.41: Transferencia de Fondos Hacia Otra Cuenta. Todos los datos, tanto la identicacin de la cuenta o Id cuenta as como tambin el monto a transferir son validados antes de producir el movimiento. Por ejemplo si el usuario ingresa un monto y su cuenta desde donde quiere realizar la transferencia no posee fondos sucientes, entonces no se podr realizar la transaccin. Home Banking avisa al usuario de estos fallos; ver g. 8.42 de la pg. 266. Movimientos: Por medio de este mdulo del sistema el cliente tiene la posibilidad de poder visualizar todos los movimientos (depsitos, extracciones) asociados a su cuenta bancaria. La aplicacin solicita el ingreso de un rango de fechas, fecha desde y una fecha hasta.
266
Figura 8.42: Mensajes de Estado del Proceso de Transferencia.
8.2. ESTRUCTURACIN
267
Esta peticin la recibe un Servlet y valida si son rangos de fechas vlidos y luego realiza la consulta a la base de datos. Posteriormente se muestra una pgina con la siguiente informacin: Id de la transaccin. Fecha del movimiento. Hora del movimiento. Tipo movimiento (depsito, extraccin). Monto. En la g. 8.24 de la pg. 245 se puede observar la pantalla que muestra el listado de movimientos realizados.
Figura 8.43: Pantalla de Listado de Movimientos. Mobile Banking: En esta pgina de la aplicacin se puede obtener informacin acerca de Mobile Banking (aplicativo mvil), como ser en qu consiste,
268
Figura 8.44: Pantalla que Muestra Informacin de Mobile Banking.
requisitos de los dispositivos para poder lanzar la aplicacin, qu operaciones se pueden realizar y tambin brinda un enlace que permite descargar el aplicativo en la PC para luego a travs de una conexin con el celular, ya sea bluetooth, cable usb o infrarrojos, se pueda instalar la aplicacin en el dispositivo celular en cuestin. Otra alternativa de descarga de Mobile Banking es ingresando directamente en el navegador WAP del celular la direccin URL que muestra esta pgina, descargando as directamente el aplicativo en el celular sin tener que bajarlo en una PC. Este proceso demandar al usuario el costo por bytes recibidos de la aplicacin. En la g. 8.44 de la pg. 268 se muestra la ventana correspondiente a Mobile Banking. Del Lado del Operador / Administrador
8.2. ESTRUCTURACIN
269
Esta perspectiva del sistema Banking funciona como back-end, est orientada a ser operada dentro de la Intranet para que pueda ser accedida por operadores para realizar tareas rutinarias de gestin y tambin por administradores para tareas similares y adems gestionar y auditar los movimientos diarios y tambin realizar tareas de mantenimiento del sistema. Se puede decir que es la base de las dems perspectivas, a partir de esta se crean las dems, ya que los clientes se deben dar de alta, crear sus cuentas en esta perspectiva. Los usuarios que utilizarn esta parte del sistema deben existir como usuarios reales, esto quiere decir que algn administrador deber insertarlo a la base de datos de usuarios para poder operar en el sistema. En la g. 8.45 de la pg. 269 se puede observar la ventana que corresponde a la pgina principal donde se solicitan datos de usuario y password para ingresar al sistema Banking.
Figura 8.45: Pantalla de Login de Banking. El men de opciones que brinda Banking es el siguiente: Clientes.
270
Figura 8.46: Pantalla de la Seccin Clientes. Consultas. Operaciones. Cambiar clave. Administracin. A continuacin se detalla las funciones que se pueden realizar en cada uno de los tems anteriormente mencionados. Clientes En la seccin clientes en primera instancia la aplicacin solicita el nmero de cliente a buscar en la base de datos, tambin muestra datos personales del cliente y un listado de cuentas bancarias que posea. En la g. 8.46 de la pg 270 se puede observar la pgina correspondiente a la seccin clientes. En esta seccin, se puede dar de alta a clientes nuevos ingresando a la opcin nuevo o modicar los datos del mismo ingresando a la opcin mo-
8.2. ESTRUCTURACIN
271
Figura 8.47: Pantalla para Ingresar Nuevos Clientes.
dicar. Es decir esta seccin maneja todo lo relativo con clientes, alta, modicacin, bsqueda. En la opcin nuevo cliente el usuario deber ingresar ciertos datos personales a cerca del cliente, los datos requeridos si no son rellenados la aplicacin marcar con un color rojo o bien si se intenta dar de alta le avisar al usuario con mensajes de alerta. En la g. 8.47 de la pg. 271 se muestra la pgina correspondiente al alta de clientes y como se puede ver la aplicacin marca con color rojo las cajas de texto que se encuentran vacas. En un paso posterior despus de haber ingresado todos los datos solicitados se muestra una pantalla conrmando los datos del nuevo cliente ms el nmero del mismo. Esto se puede ver en la g. 8.48 de la pg. 272. Consultas
272
Figura 8.48: Datos del Nuevo Cliente En la seccin consultas se puede visualizar el saldo actual, ms otra informacin de la cuenta seleccionada. Por lo cual se subdivide en dos subitems: Saldo. Movimientos. En el tem saldo tambin se puede ver otro tipo de informacin como ser: tipo de cuenta, inters, fecha de alta de la cuenta, limite de sobregiro si posee, etc. La g. 8.50 pg. 274 muestra esta informacin. En el tem movimientos el cliente puede visualizar en la pantalla todos los movimientos realizados desde el primero hasta el ltimo movimiento de la cuenta. Primeramente se solicita el ingreso de un rango de fechas para que el sistema busque en su base de datos los movimientos realizados entre las fechas ingresadas; ver g. 8.51 de la pg. 275. Operaciones
8.2. ESTRUCTURACIN
273
Figura 8.49: Listado de Cuentas.
274
Figura 8.50: Informacin de una Cuenta
8.2. ESTRUCTURACIN
275
Figura 8.51: Movimientos de una Cuenta.
276
Esta seccin como se puede ver en la g. 8.18de la pg. 238 est destinada a poder ingresar las operaciones que el cliente quiere realizar sobre la cuenta, estas operaciones pueden ser:
Figura 8.52: Operaciones Sobre una Cuenta. Extracciones de dinero. Depsitos de dinero. Transferencia de fondos. Ver movimientos (igual que consulta movimientos). Este mdulo de operaciones maneja una serie de excepciones que pueden ocurrir al momento de realizar alguna operacin. Ellas pueden ser: Si se intenta depositar o extraer un monto igual a cero. Si se intenta extraer ms dinero del disponible en el saldo actual.
8.2. ESTRUCTURACIN
277
Figura 8.53: Mensajes de Error que Maneja el Sistema. Si se intenta transferir fondo a una cuenta no existente. Estas excepciones ocurren en tiempo de ejecucin y son mostradas al usuario mediante mensajes de error; en la g. 8.53 de la pag. 277 se ilustra cmo la aplicacin informa estos errores. Cambiar Clave Esta seccin permite a los usuario (administradores u operadores) cambiar peridicamente la clave de acceso al sistema, para ello se deben ingresar tanto la clave actual y la nueva clave dos veces a n de conrmar el cambio. La pantalla que permite ingresar estos datos se puede apreciar en la g. 8.54 de la pg. 278. Administracin Este mdulo del sistema slo podr ser accedido por los usuarios Administradores. Es decir el sistema valida el usuario, si el usuario est registrado
278
Figura 8.54: Pantalla para el Cambio de Clave. como administrador esta opcin se muestra, caso contrario no estar disponible. Las tareas que permite realizar este mdulos son: Crear Usuarios. Acceder a una lista de accesos. El sistema permite a los usuarios administradores la posibilidad de crear otros usuarios para la utilizacin del sistema. Al momento de crear un usuario en particular se debe seleccionar el tipo de usuario (operador o administrador) y brindarle una clave temporal. El nuevo usuario podr modicar esta clave. La g. 8.55 de la pg. 279 muestra la pantalla de creacin de nuevos usuarios del sistema banking. A n de llevar un control y poder realizar seguimientos de las operaciones por parte de los clientes, tanto stos accedan a travs del Home Banking como as tambin de la aplicacin mvil Mobile Banking, el sistema genera unos registros de accesos de los clientes.
8.3. ESTRUCTURAS DE DATOS UTILIZADAS
279
Figura 8.55: Creacin de Usuarios Los usuarios administradores pueden consultar estos registros que determinan informacin relevante como: Fecha y hora de la operacin (consulta saldo, consulta movimientos, transferencia). Nmero de cliente que accedi. Nmero de cuenta origen (y tambin destino en caso de que sea una transferencia). Origen de punto de acceso (si es a travs del Mvil o Web). Monto (en el caso de que haya realizado una transferencia). En la g. 8.56 de la pg. 280 se puede observar lo anteriormente mencionado.
8.3
Estructuras de Datos Utilizadas
El manejador de base de datos que utiliza el sistema es el DB2 UDB V. 8.1.
280
Figura 8.56: Listado de Accesos A continuacin se describirn las tablas que conforman la base de datos. Tanto la aplicacin mvil como la aplicacin Web utilizan la misma base de datos, por lo tanto el manejador debe manejar correctamente la concurrencia. En el grco 8.57 de la pg. 281 que corresponde a la ventana del centro de control de DB2 se puede apreciar la estructura de base que se utiliza. Las tablas que integran la base de datos son las siguientes: CLIENTE : Contiene toda la informacin referente a los clientes registrados del banco. Esta compuesta por los siguientes campos de datos: CLIENTEID: Contiene el nmero nico del cliente, es un nmero generado por la aplicacin. NOMBRES : Contiene el / los nombres del cliente. APELLIDO: Contiene el apellido del cliente. DOCUMENTO: Almacena la informacin del nmero de documento del cliente.
281
Figura 8.57: Tablas que Integran la Base de Datos del Sistema.
282
DIRECCION : Contiene la direccin real del cliente. EMAIL: Contiene la direccin de correo electrnico del cliente. USUARIOID: Almacena la informacin del usuario para ingreso al sistema. PASSWORD: Amacena la informacin de la clave secreta del cliente para ingreso al sistema. NACIONALIDAD: Contiene la nacionalidad del cliente. FECHANAC : Contiene la fecha exacta de nacimiento del cliente. TELEFONO: Contiene el telfono del cliente. TRABAJA: Contiene informacin a cerca de si trabaja o no el cliente. LUGAR: Contiene el nombre del lugar de trabajo del cliente. ESTUDIA: Contiene informacin a cerca de si estudia o no el cliente. CARRERA: Contiene el nombre de la carrera que estudia el cliente. CUENTA: La tabla cuenta contiene toda la informacin de las cuentas que posee el cliente. La tabla posee los siguientes campos de datos: CUENTAID: Contiene la identicacin nica de la cuenta. SALDO: Contiene el saldo actual que posee la cuenta. INTERES : Contiene la tasa de inters de la cuenta. DISCRIMINADOR: Contiene un carcter que identica el tipo de cuenta (A=caja ahorro; I= inversin; C= cuenta corriente). TIPOCUENTA: Contiene la leyenda del tipo de cuenta. SOBREGIRO: Contiene el monto mximo de sobregiro que corresponde a la cuenta. MONTOMIN : Contiene el monto mnimo que debe tener la cuenta. TINVERSION : Contiene el termino de tiempo expresado en meses del capital invertido. FAPERTURA: Contiene la fecha de creacin de la cuenta. CLIENTEID: Contiene la identicacin del cliente, es un campo relacional a la tabla cliente.
283
MONEDA: Contiene el tipo de moneda que opera la cuenta. SIMBOLO: Contiene el smbolo de acuerdo al tipo de moneda de la cuenta. MOVIMIENTOS : La tabla movimientos alberga los datos de las operaciones que se generan sobre las cuentas bancarias. La tabla contiene los siguientes campos de datos: TRANSID: Contiene un nmero autogenerado que identica a la transaccin. CUENTAID: Contiene la identicacin de la cuenta, es un campo relacional a la tabla cuenta. TIPO: Contiene informacin del tipo de transaccin (extraccin, depsito, transferencia.) MONTO: Contiene el monto de la transaccin. FECHA: Contiene la fecha que se realiz la transaccin. HORA: Contiene la hora que se llev a cabo la transaccin. CUENTADESTINO: Contiene informacin del numero de cuenta de destino de la transaccin. USUARIO: La tabla usuario contiene informacin de los usuario del sistema back-end. Esta tabla dispone de los siguientes campos: USUARIOID: Nmero autogenerado para identicacin nica del usuario. AP_Y_NOM : Contiene el apellido y nombre del usuario. USUARIO: Contiene el nombre de usuario para ingreso al sistema. CLAVE : Contiene la clave del usuario para el acceso. PERFIL_ID: Contiene un identicador del perl del usuario. Es un campo referencial a la tabla Perl. PERFIL: La tabla perl mantiene los perles que maneja la aplicacin. Posee dos campos:
284
ID_PERFIL: Contiene un numero autogenerado que identica al perl. DESCRIPCION : Contiene la descripcin del perl. ACCESO: ID_ACCESO: Nmero autogenerado para identicacin nico del acceso. FECHA: Contiene la fecha que se realiz el acceso. HORA: Contiene la hora que se realiz el acceso. USUARIOID: Contiene el nmero de cliente quien realiz el acceso. OPERACION : Contiene informacin del tipo de operacion. MONTO: Contiene el monto de la transaccin. ORIGEN : Contiene si el acceso fue realizado desde el mvil o Web. CUENTA_ORIG: Contiene la identicacin de la cuenta origen. CUENTA_DEST : Contine la identicacin de la cuenta destino en una transferencia.
Captulo 9
Conclusiones
9.1 Conclusiones Generales
Los dispositivos mviles y particularmente los telfonos celulares, hoy en da no son un lujo sino una necesidad. Prcticamente cada integrante de una familia ya dispone de un telfono celular con buenas capacidades grcas y de cmputo. Es por sto que las empresas estn trabajando para brindarles a sus clientes nuevos servicios para este tipo dispositivos. Los desarrollos de las nuevas tecnologas de la informacin y las comunicaciones (NTICS ) en los ltimos aos impulsan la implantacin de sistemas distribuidos que puedan ser accedidos a travs de los telfonos celulares. Cuando se habla de tecnologas se reere a GSM, GPRS, WAP que permiten que un telfono celular pueda mantener conexiones de datos y poder consultar cualquier tipo de informacin que se encuentre en Internet, o interactuar con el servidor Web o aplicacin Web de la empresa. Como por ejemplo un banco. Las soluciones mviles estn mostrando sus benecios para la gestin de las empresas en la mejora de la productividad, en la creacin de nuevos servicios. En este trabajo se ha cumplido con el objetivo propuesto de desarrollar una aplicacin mvil que acceda a bases de datos multiplataforma, adicionalmente se desarroll tambin la aplicacin web a n de tener un sistema completo desarrollado. 285
286
CAPTULO 9. CONCLUSIONES
Se ha optado por emplear una tecnologa ampliamente extendida en la actualidad, y de la que cada vez aparecen un mayor nmero de dispositivos, de gama media-baja a un costo razonable. No se ha empleado ninguna caracterstica propia de ninguna de las marcas del mercado (Nokia, Motorola, Sony Ericsson), por lo que la aplicacin desarrollada es compatible con cualquier terminal que soporte la tecnologa Java. Se ha probado la aplicacin mvil desarrollada en distintos emuladores. Los mismos se detallan a continuacin: Emulador estndar de Websphere Application Device Developer. Nokia Prototype SDK 4.0 for Java (TM) ME. Nokia Series 40 5th Edition SDK, Feature Pack 1. Motorola Java (TM) ME SDK V. 6.4 for Motorola OS Products. Tambin a lo largo del presente trabajo se ha probado la ejecucin del aplicativo en terminales reales. A continuacin se detallan los modelos: Nokia 6103. Nokia 6131. El resultado de las pruebas en los distintos emuladores y terminales reales di satisfactorio.
9.2
Conclusiones Acerca de las Tecnologas y Software Utilizados
Se ha podido comprobar las grandes ventajas de la utilizacin de tecnologas y software, tanto de base de datos como del ambiente de desarrollo de aplicaciones. Con respecto al motor de bases de datos DB2, se debe destacar la escalabilidad, integridad y su facilidad de uso, disponiendo de intuitivos asistentes para la creacin de bases de datos, de tablas y la gran utilidad sql asist que brinda un apoyo para realizar todo tipo de consultas SQL hacia las tablas.
En cuanto a las facilidades en el entorno de desarrollo, se pudo apreciar que WebSphere posee un gran nmero de ventajas, al disponer de numerosas vistas, perspectivas y un editor de cdigo fuente inteligente apto para el desarrollo de este tipo de aplicaciones, tambin cabe destacar el editor grco MIDP del Device Developer que utiliza el concepto de Drag and Drop para insertar elementos grcos en el mvil y las facilidades de este entorno para aadir nuevos dispositivos para las distintas pruebas del sistema. Tambin se puede decir que Websphere puede ser usado desde la Intranet de una organizacin y/o desde la Internet, con lo cual el sistema resulta ms eciente, ms exible y adaptable al cambio. Al ser accesible desde la Internet se pudo realizar la comunicacin real de la aplicacin mvil con el servidor sin ningn tipo de inconvenientes. Con la utilizacin del lenguaje Java (J2ME ) se comprob la gran portabilidad que brinda al poder lanzar la aplicacin en distintos modelos y marcas de telfonos celulares.
9.3
Lneas Futuras de Accin
A continuacin se detallan las principales lneas futuras de accin del presente trabajo: Desarrollar un esquema de seguridad para el almacenamiento de claves en la base de datos incorporando criptografa. Incorporar el uso del protocolo HTTPS que permite conexiones de redes seguras, con la utilizacin de certicados de seguridad, para todas las conexiones entre el cliente y el servidor. Implemetar restricciones en los distintos tipos de cuentas que se pueden crear para los clientes, como por ejemplo en un cuenta de tipo plazo jo no permitir una extraccin de fondos si no se ha cumplido con el perodo de tiempo pactado. Incorporar otro tipo de funcionalidad en la aplicacin mvil como ser: Cargar crdito a un telfono celular. Poder consultar informacin relevante como la cotizacin del dlar.
288
CAPTULO 9. CONCLUSIONES
Bibliografa
[1] L. Joyanes Aguilar. Cibersociedad. Mac Graw-Hill, 1997. [2] L. Joyanes Aguilar. Programacin Orientada a Objetos - Segunda Edicin. Mc Graw Hill/Interamericana de Espaa, S.A.U., Espaa, 1998. [3] Bart Jacob Carla Sadtler, John Ganci. WebSphere Product Family Overview and Architecture. IBM Press, USA, 2004. [4] IBM Corp. WebSphere Studio Device Developer Product Documentation. IBM, 2004. [5] IBM Corp. IBM Workplace Client Technology Micro Edition Version 5.7.1. IBM, 2005. [6] Michael J. Cunningham. Como Desarrollar una Estrategia de Comercio Electrnico. Pearson Educacin, Mxico, 2001. [7] Isabel Gallego Fernndez. Tesis doctoral:Modelo para comercio electrnico basados en sistemas intermediarios. Universidad Politcnica de Catalunya, 2001. [8] Maximiliano R. Firtman. Programacin para celulares. Mp Ediciones, Buenos Aires, Argentina, 2005. [9] WAP forum. WAP 2.0 Technical White Paper. WAP forum, 2002. [10] Jorge Cardenes Patricia Froufe Quintas Agustn. J2ME Java 2 Micro Edition Manual De Usuario y Tutorial. Alfaomega Grupo Editor Argentino S.A., 2004. [11] IBM. WebSphere Comerse V5.5 Architecture. IBM Press, USA, 2003. [12] David Luis La Red Martinez. Material de apoyo de la catedra Diseo y Administracin de Datos. Universidad Nacional del Nordeste, Corrientes, Argentina, 2006. 289
290
BIBLIOGRAFA
[13] L. Joyanes Aguilar; I. Zahonero Martnez. Estructura de Datos - Algoritmos, Abstraccin y Objetos. Mc Graw Hill/Interamericana de Espaa, S.A.U., Espaa, 1998. [14] Lucas Ortega Daz Sergio Glvez Rojas. Java a Tope: J2ME. Universidad de Mlaga, Mlaga, Espaa, 2004. [15] Korth Henry F. & Susarshan S. Silberschatz, Abraham. Aprenda Servlets de Java como si estuviera en Segundo. Editorial McGraw-Hill, USA, 1993. [16] E. Castillo; A. Cobo; P. Gmez; C. Solares. JAVA - Un Lenguaje de Programacin Multiplataforma para Internet. Paraninfo, Espaa, 1997. [17] Andrew S. Tanenbaum. Redes de Computadoras. Pearson Educacin, Mexico, 2003. [18] M.icklous T.Stober U. Hansmann, L. Merk. Pervasive Computing HandBook. Springer,Verlag, 2001. [19] VV.AA. Introduccin a las Bases de Datos. THOMSON PARANINFO, S.A., USA, 2005. [20] Mark Weiser. The computer for the 21st century. Scientic American, San Francisco, CA, USA, 1991. [21] Ing. Dario Yorio. Tesis de Magistratura:Identicacin y clasicacin de patrones en el diseo de aplicaciones mviles. Universidad Nacinal de la Plata.
ndice de Materias
2.5G, 34 2G, 25 3G, 26, 34 AIV Extender, 178 AMPS, 29 Advanced Mobile Phone System, 25 Sistema Avanzado de Telefona Mvil, 27 AMS, 115, 116 API, 253 aplicacin, 217 Aplicaciones Mviles, 51 AWT, 111 B2B, 188 Negocio a Negocio, 6 B2C, 188 Negocio a Cliente Final, 5 Bases de Datos Introduccion, 169 Bases de Datos en Red Modelo, 174 Bases de Datos Jerrquicas Modelo, 173 Bases de Datos Relacional Modelo, 174 bibliotecas de clases, 65 bifurcaciones, 78 291 if, 79 if else, 79 bloque try, catch, nally, 81 bucles, 80 do while, 81 for, 80 while, 80 C/C++, 77 C2C Consumidor a Consumidor, 6 caso de uso, 218 CDC, 110 Conected Device Conguration, 107 CDMA, 26 Acceso Mltiple Por Divisin de Cdigo, 32 celular, 245, 249 Centro de Desarrollo, 180 Ciclo del Conocimiento, 14 Clases de Conocimientos, 14 CLDC, 110 Conected Limited Device Conguration, 106 comentarios, 77 Comercio Electrnico, 3 comercio electrnico, 18 bancario, 19 cominicaciones inalmbricas, 40 computacin pervasiva, 8 Computacion Ubicua, 8
292
NDICE DE MATERIAS
comunicaciones en J2ME, 153 comunicaciones HTTP, 157 comunicaciones mviles, 26 conguracin, 106, 109 conocieminto tcito, 14 conocimiento explcito, 14 contenedor cliente de aplicaciones de, 205 EJB de, 204 Web, 204 Content-Type, 85 D-AMPS Sistema Avanzado de Telefona Digital, 29 DB2 Introduccion, 169 db2 Data Links Manager, 180 DB2 UDB Caracteristicas Generales, 177 Funciones Complementarias, 178 DB2 Warehouse Manager, 180 DBMS Sistema de Administracin de Bases de Datos, 171 destroy, 88 digitales activos, 189 Dispositivos, 213 DNS, 206 doGet, 85 doGet (), 88 doPost (), 88 download, 189 e-commerce, 187 Eclipse, 210 Introduccon y Conceptos, 192 EDGE
Tasa de Datos Mejorada para la Evolucin del GSM, 34 ejemplo de bifurcacin if, 79 bifurcacin if else, 79 bucle for, 80 bucle while, 80 clase, 70 comentario, 78 do while, 81 lnea compuesta por tres sentencias, 77 enterprise beans, 204 Esquema General, 4 estructuras de programacin, 77 expresin, 77 FDM multiplexin por divisin de frecuencias, 32 Gestin del Conocimiento, 17 GFC, 153, 155, 157 Generic Framework Conection, 153, 154 GPRS, 22, 26, 97, 230 Servicio de Radio de Paquetes Generales, 34 GSM, 7, 19, 26, 34, 40 Sistema Global Para Comunicaciones Mviles, 30 GUI, 205 herencia, 70 hosts virtuales, 205 HTML, 39 HTTP, 38 HttpServletRequest, 85 HttpServletResponse, 85 IMTS, 28
NDICE DE MATERIAS
293
Sistema Mejorado de Telefona Mvil, 27 INIT, 86 instanciacin e inicializacin, 86 interfaz Connection, 155 InputConnection, 156 OutputConnection, 156 StreamConnection, 157 Internet, 1, 19, 35, 38 mvil, 230 IT, 202 J2EE, 201 Java 2 Enterprise Edition, 98 J2ME, 22, 97 Java 2 Micro Edition, 97, 98, 102 J2SE Java 2 Standard Edition, 98 Java, 63, 65, 66, 97 estructura general de un programa, 68 javax.servlet.HttpServlet, 85 JCA, 202 JDBC, 205 JDK, 78 JNDI, 205 JSP, 204 modelos de, 93 juegos y aplicaciones, 37 JVM, 203 Java Virtual Machine, 98 Ley de Moore y la Vision de Weiser, 11 M-Commerce Comercio Electrnico a Travs de Dispositivos Mviles, 7 m-commerce, 3
memoria administrador automtico de la, 68 mensajes multimedia, 37 middleware, 201 MIDlet, 115, 118, 119, 139 MIDP, 110, 153 MMS, 49 Multimedia Messaging System, 37 Modelos de Comercio Electrnico, 5 MSC Centro de Conmutacin Mvil, 28 MTSO Ocina de Telefona Mvil, 28 multi servidor, 202 mundo mvil, 25 MVC, 254 NTICs Nuevas Tecnologas de Informtica y Comunicaciones, 1 nuevas tecnologias, 1 OMA Open Mobile Alliance, 40 OOP, 68 operadores aritmticos, 74 de asignacin, 74 de concatenacin de cadenas de caracteres, 76 package, 71 packages, 69 PCS Personal Communications Services, 25 PDA, 206
294
NDICE DE MATERIAS
perl, 109 plataforma de software, 186 plug-in, 203 proceso de formacin del conocimiento, 13 Quick Installation, 203 record, 139 store, 139, 140, 251 stores, 151, 152 RMS, 137, 139, 141, 251 sentencia, 77 Server Application Advanced Edition, 201 Enterprise Edition, 202 Standard Edition, 203 server-side, 86 servicio de demanda, 88 servicios de informacin, 36 servidor de aplicaciones, 203 HTTP, 203 servlet ciclo de vida del, 86 codicacin de, 85 motor del, 86 servlets, 204 Set-Cookie, 85 sincronizacin, 245 sinronizacin, 245 sistema avanzado de telefona mvil, 27 sistemas mviles de segunda generacin, 32 SMS, 7, 19, 37 Short Message System, 36
SMTP, 36 Sociedad de la Informacion y el Conocimiento denicin, 12 software, 71 software mvil, 38 Spatial Extender, 180 TCP/IP, 40 TDM multiplexin por divisin de tiempo, 32 TDMA, 26 telfonos mviles, 3 telfonos celulares, 27, 51, 103, 206 telfonos mviles, 35 telfonos mviles de primera generacin, 26 telfonos mviles de segunda generacin, 29 telfonos mviles de tercera generacin, 33 telefona celular, 26, 36 telefona mvil, 27 UMTS Sistema Universal de Telecomunicaciones Mviles, 33 variable local, 72 miembro de una clase, 72 referencia, 72 variables tipo primitivo, 72 virtual sistema principal, 205 W-CDMA, 33 CDMA de Banda Ancha, 33
NDICE DE MATERIAS
295
WAP, 7, 19, 38 wireless application protocol, 40 WAS WebSphere Application Server, 190, 199 WBML Wireless Binary mark-up Language, 44 WCTME Workplace Client Technology Micro Edition, 206 Web aplicaciones, 94 Web Services, 202 WebSphere Application Server, 199 Studio, 185 WebSphere Commerce, 187 WebSphere for Commerce soluciones de portal, 188 soluciones digital media, 189 WebSphere for commerce soluciones B2B, 187 soluciones B2C, 187 WebSphere Portal, 187 WebSphere Studio Productos, 190 WML, 39 Wireless Mark-up Language, 44 Workbench banco de trabajo, 192 WSAD Entorno de Desarrollo de WebSphere Studio, 192 WebSphere Studio Application Developer, 190 WSADIE WebSphere Studio Application Developer Integration Edi-
tion, 190 WSED WebSphere Studio Enterprise Developer, 190 WSSDA WebSphere Studio Site Developer Advanced, 190 XHTML-MP, 46 XML Extender, 178, 180

Tfsoto

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tfsoto

Uploaded by

Copyright:

Available Formats

Universidad Nacional del Nordeste Facultad de Ciencias Exactas, Naturales y Agrimensura Trabajo Final de Aplicacin

A mis padres por el apoyo incondicional que me brindaron

2.1 2.2 2.3

69 69 70 70 71 71 73 73 74 74 74 75 75 75 76 76 77 77 77 78 80 82 83 86 88 88 88 94 97 97 98 101 102 103 106 109 114 115 116

8 Descripcin de la Aplicacin 217 8.1 Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

220 220 254 279

Bibliografa ndice de Materias

8.52 8.53 8.54 8.55 8.56 8.57

276 277 278 279 280 281

1.2. COMERCIO ELECTRNICO

Otras Concepciones del Comercio Electrnico

1.2. COMERCIO ELECTRNICO

Modelos de Comercio Electrnico

M-Commerce (Comercio Electrnico a Travs de Dispositivos Mviles)

Computacin Ubicua o Pervasiva

1.4. COMPUTACIN UBICUA O PERVASIVA

Hacia las Cosas Inteligentes e Interconectadas

1.4. COMPUTACIN UBICUA O PERVASIVA

La Ley de Moore y la Visin de Weiser

La Sociedad de la Informacin y el Conocimiento

1.5. LA SOCIEDAD DE LA INFORMACIN Y EL CONOCIMIENTO 13

Proceso de Formacin del Conocimiento

Ciclo del Conocimiento

Se fundamenta en dos pilares: La cadena del conocimiento.

1.5. LA SOCIEDAD DE LA INFORMACIN Y EL CONOCIMIENTO 15

Figura 1.3: La Cadena del Conocimiento

Caractersticas de la Sociedad del Conocimiento

Figura 1.4: La Era de la Informacin

1.5. LA SOCIEDAD DE LA INFORMACIN Y EL CONOCIMIENTO 17

Gestin del Conocimiento

Tecnologas de la Gestin del Conocimiento

Distribuir la informacin a distintos niveles. Actualizar, eliminar y modicar el conocimiento obsoleto.

La Gestin del Conocimiento es la mezcla de los siguiente factores:

Comercio Electrnico en la Sociedad del Conocimiento

1.7. COMERCIO ELECTRNICO BANCARIO

Comercio Electrnico Bancario

Banca a Travs del Telfono Mvil

1.7. COMERCIO ELECTRNICO BANCARIO

Seguridad en Operaciones Electrnicas

1.7. COMERCIO ELECTRNICO BANCARIO

CAPTULO 2. EL MUNDO MVIL

Telfonos Mviles de Primera Generacin

2.2. TELFONOS MVILES DE PRIMERA GENERACIN

Sistema Avanzado de Telefona Mvil

CAPTULO 2. EL MUNDO MVIL

2.3. TELFONOS MVILES DE SEGUNDA GENERACIN

Telfonos Mviles de Segunda Generacin

D-AMPS - El Sistema Avanzado de Telefona Mvil Digital

CAPTULO 2. EL MUNDO MVIL

GSM (Sistema Global Para Comunicaciones Mviles)

2.3. TELFONOS MVILES DE SEGUNDA GENERACIN

CAPTULO 2. EL MUNDO MVIL

CDMA (Acceso Mltiple por Divisin de Cdigo)

2.4. TELFONOS MVILES DE TERCERA GENERACIN

Telfonos Mviles de Tercera Generacin

CAPTULO 2. EL MUNDO MVIL

EDGE (Tasa de Datos Mejorada para la Evolucin del GSM)

GPRS (Servicio de Radio de Paquetes Generales)

2.5. SERVICIOS ADICIONALES DE LAS EMPRESAS TELEFNICAS35

Servicios Adicionales de las Empresas Telefnicas

Recepcin y Envo de Mensajes de Texto

CAPTULO 2. EL MUNDO MVIL

2.5. SERVICIOS ADICIONALES DE LAS EMPRESAS TELEFNICAS37