Sistema Web Con Acceso a Bases de Datos Multiplataforma a Través de Teléfonos Celulares.

Universidad Nacional del Nordeste
Facultad de Ciencias Exactas, Naturales y Agrimensura
Trabajo Final de Aplicación
Sistema Web con Acceso a Bases de Datos
Multiplataforma a Través de Teléfonos
Celulares
Sergio Andrés Soto - L.U.: 35406
Prof. Coordinador: Agr. Castor Herrmann
Prof. Orientadores: Mgter. David Luis la Red Martínez y
Lic. Valeria Uribe.
Licenciatura en Sistemas de Información
Corrientes - Argentina
2008
A mis padres por el apoyo incondicional que me brindaron
Prefacio
En los últimos años, la telefonía móvil 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 fenómeno Internet se ha extendido masivamente,
convirtiéndose en la actualidad en un elemento de uso casi imprescindible en
la vida cotidiana. A la unión de las dos tecnologías anteriores es a lo que se
denomina “Internet móvil”.
La potencia de los últimos teléfonos celulares, los hacen adecuados para
la ejecución de aplicaciones, que hasta hace poco sólo podían ser ejecutadas
desde un ordenador conectado a la red.
Con el paso de los años, el ser humano ha demostrado nuevas habilidades
y destrezas en el desarrollo de nuevas tecnologías. 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 telefonía móvil, las personas pueden acceder a cualquier tipo de información en cualquier momento,
en este sentido el comercio y más el comercio electrónico en general, puede
verse beneficiado de este hecho.
La proliferación de nuevos dispositivos móviles con capacidad de comunicación, como teléfonos celulares, crea una nueva demanda de información para
entidades que están presentes en la red.
Las empresas invierten en servicios que automatizan las operaciones de
sus clientes. Uno de los ejemplos más concretos son las entidadas bancarias,
quienes desarrollan sistemas que ayudan a los clientes a la autogestión de sus
operaciones las 24 hs del día con sólo estar conectado a la red “Internet”.
Los clientes desean poder acceder a los mismos servicios que acceden desde
la Internet a través de un ordenador pero con un dispositivo más pequeño como
un teléfono celular.
Para satisfacer lo anteriormente mencionado, en este trabajo se propuso
el desarrollo de una aplicación con software de computación móvil multiplataforma, que permita el acceso a información situada en bases de datos multiplataforma en un servidor Web, a través de dispositivos móviles tales como
teléfonos celulares.
La aplicación contempla el registro y seguimiento de información propia
de una entidad bancaria, es decir la información pertinente de los clientes, sus
vi
cuentas bancarias, los movimientos realizados en una determinada cuenta, y
otras operaciones inherentes de una cuenta.
Esto significa para los clientes la posibilidad de autogestionar sus cuentas
bancarias en cualquier momento y en cualquier lugar sin tener que asistir
fisicamente a las oficinas bancarias y con sólo la ayuda de un teléfono celular
moderno.
A su vez se propuso el desarrollo de la plataforma Web de la aplicación que
sea accesible desde la Intranet como así también desde la Internet, que contemple funciones adicionales como ser: registro de clientes, creación de nuevas
cuentas, poder realizar depósitos y extracciones, y además ciertas funciones
de administración.
Objetivos Logrados
Se han alcanzado plenamente la totalidad de los objetivos planteados para
el presente trabajo:
• Desarrollo de una aplicación utilitaria empleando un software de computación móvil multiplataforma para teléfonos celulares que permita acceder a información remota situada en un base de datos que se encuentra
en un servidor Web.
• Desarrollo de la plataforma web de la aplicación con accesos a base de
datos, que sirva de apoyo a la aplicación móvil.
Clasificación del Trabajo
El trabajo se encuadra en la utilización de software de base que permite el
desarrollo de aplicaciones que permitan el acceso a bases de datos multiplataformas desde dispositivos móviles tales como teléfonos celulares.
Etapas de Desarrollo
• Se ha efectuado una amplia recopilación bibliográfica específica a los
temas pertinentes a la tarea planificada y a los productos de software
que se emplearon para la concreción del trabajo final.
• 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 CD’s 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 realización del presente Trabajo Final
los referentes productos de software como los siguientes:
— WebSphere Studio Application Developer versión 5.0 y 5.1.2.
— DB2 UDB WorkGroup Server Edition versión 8.1.
— IBM Workplace Client Technology Micro Edition 5.7.
— WebSphere Studio Device Developer versión 5.7.1.
• Se realizaron las traducciones de los manuales correspondientes a las herramientas de desarrollo Websphere Studio Application Developer versión 5.1.2 y Websphere Studio Device Developer 5.7.1.
• Se ha efectuado un estudio acerca de las arquitecturas de aplicaciones
móviles.
• Se ha realizado el análisis y diseño de la base de datos que utiliza la
aplicación.
• Se ha realizado el estudio del manejador de bases de datos DB2 UDB
para Windows.
• Se ha realizado un detallado estudio del J2ME (versión de Java para
móviles), para la herramienta de desarrollo WebSphere Studio Device
Developer versión 5.7.1.
• Se ha realizado un detallado estudio del software para el desarrollo de
la plataforma web de la aplicación, WebSphere Studio Application Developer versión 5.1.2.
• Se ha desarrollado el aplicativo móvil con la utilización del lenguaje Java,
versión J2ME.
• En el marco de la herramienta WebSphere Studio Application Developer se desarrolló el módulo web del aplicativo utilizadando páginas
XHTMLs, JSPs y Servlets de Java.
• Una vez finalizada la etapa de desarrollo se realizaron las siguientes actividades:
— Instalación y configuración del WebSphere Application Server, como servidor de aplicaciones y servidor web.
viii
— Empaquetado de la aplicación móvil para su distribución e instalación en los teléfonos celulares.
— Instalación de emuladores de teléfonos celulares que fueron descargados desde los sitios webs de los fabricantes de los mismos.
— Instalación y prueba de la aplicación tanto en los emuladores como
así también en teléfonos celulares reales.
— Testeo del sistema, simulando un escenario real realizando pruebas
de conexión entre el sistema móvil y el servidor web a través de
Internet.
• Finalizada la aplicación se realizó la grabación en DVD de todo el material correspondiente al trabajo final: una versión de la aplicación, otra
referente al libro en formato LaTex y el PDF generado. También 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.
Organización del Informe Final
El trabajo final de aplicación comprende un informe final impreso y un
DVD además de un resúmen y de un resúmen extendido.
El informe final está organizado en capítulos los que se indican a continuación:
• Introducción: Se presenta una vision global acerca de las nuevas tecnologías de información y comunicaciones, como así también las principales
caracteristicas del comercio electronico móvil, computación ubicua y de
la sociedad de la información y el conocimiento.
• El mundo móvil : Se indican las principales caracteristicas de la evolución
de los sistemas de telefonía móvil.
• Aplicaciones móviles: Se explican los requerimientos necesarios para una
aplicación móvil.
• Java: Se presentan los principales aspectos y destacadas características
referidas al lenguaje.
• Java 2 Micro Edition: Se detallan las conceptos y características del
lenguaje Java para dispositivos electronicos con menos recursos.
ix
• Introducción al DB2: Se detallan las más relevantes relevantes características de esta familia de productos de gestión de bases de datos.
• WebSphere Studio: Presenta los principales aspectos de este entorno de
aplicaciones complejas.
• Descripción de la aplicación: Se describen los todos aspectos de la aplicación desarrollada utilizando las herramientas antes mencionas.
• Conclusiones: Se presentan las conclusiones a las que se ha llegado al
finalizar el presente trabajo y las posibles líneas futuras de acción.
El DVD adjunto al informe final impreso, contiene lo siguiente:
• Instaladores del software utilizado.
• Resúmenes del trabajo realizado.
• Informe final en formato digital.
• Presentación para la defensa final.
• Aplicación desarrollada.
Sergio Andrés Soto
Licenciatura en Sistemas de Información
Universidad Nacional del Nordeste
L.U.: 35406
Corrientes; 02 de Diciembre de 2008
x
Índice General
1 Introducción
1.1 Vision Global . . . . . . . . . . . . . . . . . . . . . .
1.2 Comercio Electrónico . . . . . . . . . . . . . . . . . .
1.2.1 Concepto de Comercio Electrónico . . . . . .
1.2.2 Otras Concepciones del Comercio Electrónico
1.3
1.4
1.5
1.6
1.7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
3
3
3
1.2.3 Esquema General . . . . . . . . . . . . . . . . . .
1.2.4 Modelos de Comercio Electrónico . . . . . . . . .
M-Commerce . . . . . . . . . . . . . . . . . . . . . . . .
Computación 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 Visión de Weiser . . . . .
La Sociedad de la Información y el Conocimiento . . . .
1.5.1 Definición de Conocimiento . . . . . . . . . . . .
1.5.2 Proceso de Formación del Conocimiento . . . . .
1.5.3 Clases de Conocimiento . . . . . . . . . . . . . .
1.5.4 Ciclo del Conocimiento . . . . . . . . . . . . . .
1.5.5 Características de la Sociedad del Conocimiento
1.5.6 Gestión del Conocimiento . . . . . . . . . . . . .
1.5.7 Tecnologías de la Gestión del Conocimiento . . .
Comercio Electrónico en la Sociedad del Conocimiento .
Comercio Electrónico Bancario . . . . . . . . . . . . . .
1.7.1 ¿Qué es Banca Electrónica? . . . . . . . . . . . .
1.7.2 Ventajas . . . . . . . . . . . . . . . . . . . . . . .
1.7.3 Desventajas . . . . . . . . . . . . . . . . . . . . .
1.7.4 Banca a Través del Teléfono Móvil . . . . . . . .
1.7.5 Seguridad en Operaciones Electrónicas . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
5
7
8
8
10
11
12
13
13
14
14
15
17
17
18
19
19
20
20
20
22
2 El Mundo Móvil
.
.
.
.
25
xi
xii
ÍNDICE GENERAL
2.1
2.2
2.3
2.4
2.5
2.6
Evolución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Teléfonos Móviles de Primera Generación . . . . . . . . . . . .
2.2.1 Sistema Avanzado de Telefonía Móvil . . . . . . . . . .
Teléfonos Móviles de Segunda Generación . . . . . . . . . . . .
2.3.1 D-AMPS - El Sistema Avanzado de Telefonía Móvil Digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 GSM (Sistema Global Para Comunicaciones Móviles) .
2.3.3 CDMA (Acceso Múltiple por División de Código) . . . .
Teléfonos Móviles de Tercera Generación . . . . . . . . . . . . .
2.4.1 EDGE (Tasa de Datos Mejorada para la Evolución del
GSM) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2 GPRS (Servicio de Radio de Paquetes Generales) . . . .
Servicios Adicionales de las Empresas Telefónicas . . . . . . . .
2.5.1 Servicios Analógicos . . . . . . . . . . . . . . . . . . . .
2.5.2 Recepción y Envío de Mensajes de Texto . . . . . . . .
2.5.3 Servicios de Información . . . . . . . . . . . . . . . . . .
2.5.4 Mensajes Multimedia . . . . . . . . . . . . . . . . . . .
2.5.5 Juegos y Aplicaciones . . . . . . . . . . . . . . . . . . .
2.5.6 Internet Móvil . . . . . . . . . . . . . . . . . . . . . . .
WAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6.1 Introducción a WAP . . . . . . . . . . . . . . . . . . . .
2.6.2 Motivación . . . . . . . . . . . . . . . . . . . . . . . . .
2.6.3 Modelo de WAP . . . . . . . . . . . . . . . . . . . . . .
2.6.4 Tecnología . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6.5 WAP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Aplicaciones Móviles
3.1 Introducción . . . . . . . . . . . . . . .
3.2 Arquitectura de Aplicaciones Móviles .
3.3 Portal Para Aplicaciones Móviles . . .
3.4 Arquitectura de Bases de Datos . . . .
3.5 Aplicaciones Multiplataforma . . . . .
3.5.1 Java y Multiplataforma . . . .
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
4 Java
4.1 Introduccón al Lenguaje . . . . . . . . . . . . . .
4.1.1 Bibliotecas de Clases Estándares de Java
4.1.2 Java es Multiplataforma . . . . . . . . . .
4.1.3 Características del Lenguaje . . . . . . . .
4.2 Estructura de un Programa Java . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
63
63
65
66
67
68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ÍNDICE GENERAL
4.3
4.4
4.5
4.6
4.7
Conceptos Básicos . . . . . . . . . .
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 Aritméticos . . .
4.5.2 Operadores de Asignación . .
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 Programación . . . .
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 Instanciación e Inicialización
4.7.3 Servicio de Demanda . . . . .
4.7.4 Terminación . . . . . . . . . .
4.7.5 Java Server Faces . . . . . . .
4.7.6 Desarrollando Aplicaciones .
xiii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Java 2 Micro Edition
5.1 Introducción . . . . . . . . . . . . . . . . . . . . .
5.1.1 Comparación de Versiones . . . . . . . . .
5.1.2 Algunas Consideraciones al Desarrollar en
5.2 Componentes de J2ME . . . . . . . . . . . . . . .
5.2.1 Máquinas Virtuales J2ME . . . . . . . . .
5.2.2 Configuraciones . . . . . . . . . . . . . . .
5.2.3 Perfiles . . . . . . . . . . . . . . . . . . .
5.3 Cómo Detectar una Aplicación J2ME . . . . . .
5.4 Los MIDlets . . . . . . . . . . . . . . . . . . . .
5.4.1 El Gestor de 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
. . . .
. . . .
J2ME
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
97
97
98
101
102
103
106
109
114
115
116
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 Gráficas 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 Creación de un Record Store . . . . . . . . . . . . . . .
5.6.4 Manipulación de Registros . . . . . . . . . . . . . . . . .
5.6.5 Operaciones con Record Stores . . . . . . . . . . . . . .
5.6.6 Búsqueda 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 Introducción al DB2
169
6.1 Bases de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
6.2
6.3
6.1.1 Objetivos de las Bases de Datos . . . .
6.1.2 Ventajas de las Bases de Datos . . . . .
Sistema de Administración de Bases de Datos
Organización de Bases de Datos . . . . . . . .
6.3.1 Bases de Datos Jerárquicas . . . . . . .
6.3.2 Bases de Datos en Red . . . . . . . . .
6.3.3
6.4
6.5
Bases de Datos Relacional
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
170
170
171
173
173
174
. . . . . . . . . . . . . . . . 174
Introducción a DB2 UDB . . . . . . . . . . . .
6.4.1 Características Generales del DB2 UDB
DB2 UDB Versión 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 Depósito de Datos de DB2 .
6.5.5 Asistentes de DB2 . . . . . . . . . . . .
6.5.6 Centro de Mandatos . . . . . . . . . . .
. .
.
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
176
177
180
180
181
182
182
183
183
ÍNDICE GENERAL
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 Introducción . . . . . . . . . . . . . . . . . . . . . . . .
7.5.2 WebSphere Application Server Como Plataforma Para
el Comercio Electrónico . . . . . . . . . . . . . . . . . .
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 Utilización del IDE . . . . . . . . . . . . . . . . . . . . .
xv
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 Descripción de la Aplicación
217
8.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
xvi
ÍNDICE GENERAL
8.2
8.3
Estructuración . . . . . . . . . . . . . . . . .
8.2.1 La Aplicación Móvil (Mobile Banking)
8.2.2 La Aplicación Web . . . . . . . . . . .
Estructuras de Datos Utilizadas . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
220
220
254
279
9 Conclusiones
285
9.1 Conclusiones Generales . . . . . . . . . . . . . . . . . . . . . . . 285
9.2 Conclusiones Acerca de las Tecnologías y Software Utilizados . 286
9.3 Líneas Futuras de Acción . . . . . . . . . . . . . . . . . . . . . 287
Bibliografía
289
Índice de Materias
291
Índice de Figuras
1.1
1.2
1.3
1.4
Esquema General del Comercio Electrónico. . . . . . . . . . . .
5
Mark Weiser (1952-1999), el Visionario de la Computación Ubicua 12
La Cadena del Conocimiento . . . . . . . . . . . . . . . . . . . 15
La Era de la Información . . . . . . . . . . . . . . . . . . . . . 16
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
Sistema Telefónico Móvil . . . . . . . .
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 Programación Wap. . . . .
Modelo Proxy para WAP 2.0. . . . . .
.
.
.
.
.
.
.
.
28
30
38
42
43
45
48
48
3.1
Arquitectura de un Portal Móvil. . . . . . . . . . . . . . . . . .
58
4.1
4.2
4.3
4.4
4.5
4.6
Mecanismo de Mensajes . . . . . . . . . . . . . . . . . . . . . .
Proceso Compilación y Ejecución . . . . . . . . . . . . . . . . .
Jerarquía y Métodos de las Principales Clases Para Crear Servlets.
Ciclo de Vida de un Servlet. . . . . . . . . . . . . . . . . . . . .
Requerimiento de un Archivo JSP. . . . . . . . . . . . . . . . .
Requerimiento de un Servlet. . . . . . . . . . . . . . . . . . . .
65
67
84
87
93
94
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
Arquitectura de la Plataforma Java
Ubicación de las Tecnologías Java.
Proceso de Verificación. . . . . . .
Entorno de Ejecución de J2ME. . .
Ciclo Vida de un MIDlet. . . . . .
Estados de un MIDlet. . . . . . . .
Jerarquía de Clases. . . . . . . . .
Un MIDlet y el RMS. . . . . . . .
xvii
.
.
.
.
.
.
.
.
2 de
. . .
. . .
. . .
. . .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Sun.
. . .
. . .
. . .
. . .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
99
101
105
110
117
118
124
139
xviii
ÍNDICE DE FIGURAS
5.9
5.10
5.11
5.12
5.13
Acceso a un RMS a Través de un MIDlet Suite.
Esturctura de Un Record Store. . . . . . . . . .
Ejemplo RMS. . . . . . . . . . . . . . . . . . .
Jerarquía de Interfaces. . . . . . . . . . . . . .
Estados de una Conexión HTTP. . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
140
141
151
154
158
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
Estructura de Una Base de Datos . . . . . . .
Sistema de Administracion de Bases de Datos
Modelo de Bases de Datos Jerárquica . . . . .
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 . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
172
172
174
175
176
179
179
181
184
184
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
La familia del WebSphere Studio. . . . .
WebSphere Studio, entorno de desarrollo
Plataforma de Eclipse. . . . . . . . . .
Asistente de Proyecto Java. . . . . . . .
Paquete Java. . . . . . . . . . . . . . . .
Diálogo de Configuración de Ejecución. .
WebSphere para e-bussines. . . . . . . .
Barra de herramientas de WSDD. . . . .
Métodos de un Objeto. . . . . . . . . . .
Nuevo Dispositivo Emulador. . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
191
191
193
198
199
200
201
211
213
215
8.1
8.2
8.3
8.4
8.5
8.6
8.7
8.8
8.9
8.10
8.11
8.12
Casos de Usos del Sistema. . . . . . . . . .
Arquitectura del Sistema. . . . . . . . . . .
Diagrama de Clases de la Aplicación Móvil.
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 . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
219
221
222
224
224
225
226
226
227
228
229
231
.
.
.
.
.
.
.
.
.
.
ÍNDICE DE FIGURAS
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 Conexión. . . . . . . . . . . . . . .
Información del Cliente. . . . . . . . . . . . . . . . . . .
Lista de Cuentas. . . . . . . . . . . . . . . . . . . . . . .
Menú de Operaciones de una Cuenta. . . . . . . . . . .
Información de Saldo de una Cuenta. . . . . . . . . . .
Ingreso de Datos Para una Transferencia. . . . . . . . .
Confirmación 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 Configurar la URL del Servidor. . . . . .
Pantalla de Ayuda del Sistema. . . . . . . . . . . . . . .
RecordStores Utilizados por la Aplicación. . . . . . . . .
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 Modificación 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 Información de Mobile Banking. .
Pantalla de Login de Banking. . . . . . . . . . . . . . .
Pantalla de la Sección Clientes. . . . . . . . . . . . . . .
Pantalla para Ingresar Nuevos Clientes. . . . . . . . . .
Datos del Nuevo Cliente . . . . . . . . . . . . . . . . . .
Listado de Cuentas. . . . . . . . . . . . . . . . . . . . .
Información de una Cuenta . . . . . . . . . . . . . . . .
Movimientos de una Cuenta. . . . . . . . . . . . . . . .
xix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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. . . . . . . . . .
Creación 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
Categorías de Variables. .
Tipos Primitivos de Datos
Operadores de asignación.
Operadores relacionales. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
72
73
75
76
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
Librerías de configuración CDC. . . . . . . .
Librerías de configuración CLDC. . . . . . . .
Librerías del Fondation Profile. . . . . . . . .
Librerías del Personal Profile. . . . . . . . . .
Librerías del MIDP Profile. . . . . . . . . . .
Clases del Paquete javax.microedition.midlet.
Métodos de la Clase Display. . . . . . . . . .
Métodos de la Clase Displayable. . . . . . . .
Tipos de Commands. . . . . . . . . . . . . . .
Métodos de la Clase Command. . . . . . . . .
Tipos de Alerta. . . . . . . . . . . . . . . . .
Métodos de la Clase List. . . . . . . . . . . .
Métodos de la Clase Form. . . . . . . . . . . .
Métodos de la Clase StringItem. . . . . . . .
Métodos de la Clase ImageItem. . . . . . . .
Métodos de la Clase TextField. . . . . . . . .
Métodos Generales de la Clase RecordStore. .
Métodos Para Manejo de Registros. . . . . . .
Métodos de la Clase Connector. . . . . . . . .
Tipos de Permisos. . . . . . . . . . . . . . . .
Métodos en la Etapa de Establecimiento. . .
Tipos de peticiones. . . . . . . . . . . . . . .
Campos de la Cabezera. . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
108
109
111
112
114
119
126
127
127
128
129
131
133
135
137
138
143
144
155
156
159
159
160
xxi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Capítulo 1
Introducción
1.1
Vision Global
La implantación en la sociedad de las denominadas Nuevas Tecnologías de la
Comunicación e Información, está produciendo cambios insospechados respecto a los originados en su momento por otras tecnologías, como fueron la
imprenta, y la electrónica. Sus efectos y alcance, no sólo se sitúan en el terreno de la información y comunicación, sino que lo sobrepasan para llegar a
provocar y proponer cambios en la estructura social, económica, laboral, jurídica y política. Y ello es debido a que no sólo se centran en la captación de
la información, sino también, a las posibilidades que tienen para manipularla,
almacenarla y distribuirla.
Las Nuevas Tecnologías de la Información y la Comunicación no son sólo
invenciones geniales, tienen su justificación social ya que contribuyen a disminuir los costos de producción de bienes de la sociedad al incrementar la
productividad e impulsar la investigación y el desarrollo.
Ha surgido la llamada “supercarretera de la información”: Internet, la red
de redes de computadoras, la gran autopista que conecta todas las redes de
ordenadores del mundo; en ella la información fluye libremente y sin interrupciones, “se comparte y se esparce”, nadie aún ha sido capaz de calcular el
volumen de información que almacena ni tampoco sus límites.
Las Nuevas Tecnologías de la Información y la Comunicación rompen las
barreras geográficas borrando las distancias físicas pero no rompen las barreras
1
2
CAPÍTULO 1. INTRODUCCIÓN
sociales, mantienen e incluso incrementan las distancias sociales entre ricos y
pobres. Una de sus ventajas es que en la actualidad el ritmo de producción
de los conocimientos ha crecido vertiginosamente y se ha reducido el tiempo
necesario para transformar el conocimiento básico en ciencia aplicada y ésta
en tecnología la cual se difunde ampliamente a través de diferentes vías.
Por tanto, las Nuevas Tecnologías de la Información y la Comunicación
a pesar de sus ventajas, no son accesibles a todos por igual; este acceso está
mediado por factores económicos, se tiene información si se dispone de recursos
necesarios para “adquirirla”.
El efecto social de las redes y servicios telemáticos es difícil 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 inalámbricas jugarán un papel muy importante, éstas hoy en
día son una realidad, estamos acostumbrados a ver ordenadores portátiles
conectados a Internet sin necesidad de cables, pequeños ordenadores de mano
conectados con los ordenadores de la oficina, cada día aumenta más la creación
de las redes inalámbricas ciudadanas, en la que voluntariamente y sin buscar
beneficios más allá del uso de las tecnologías disponibles y el afán de aprender
y practicar con ellas, hay ciudadanos que van poniendo a disposición de los
demás puntos de acceso a una red que cada día va creciendo más, y que cada
voluntario ayuda a que ésta crezca.
Y todo este avance tecnológico no es más que el inicio de un mundo de
posibilidades que se abren con este nuevo modelo de computación, denominado
computación pervasiva o computación ubicua.
Este modelo de computación ubicua significa básicamente la omnipresencia
de computadores muy pequeños interconectados sin cables que se incorporan
de forma casi invisible a cualquier objeto de uso cotidiano, y usando pequeños
sensores unidos a estos computadores pueden detectar el entorno que les rodea
y tienen capacidades tanto de procesar información como de comunicación.
Una de las posibilidades es el comercio electrónico, el cual está cambiando
la manera que los consumidores, comerciantes y empresas realizan sus transacciones. El comercio electrónico permite comprar, invertir, realizar operaciones
bancarias, vender, distribuir en cualquier lugar en donde se pueda disponer de
conexión a Internet y con la interconexión con las redes sin hilos con Internet
desde cualquier lugar y cualquier momento que se desee.
1.2. COMERCIO ELECTRÓNICO
3
El uso de teléfonos móviles para el acceso a Internet abre nuevas posibilidades en el comercio electrónico. el m-commerce, involucra tres aspectos
básicos: oferta de los negocios y de servicios en un área circundante al usuario;
información oportuna, georeferenciada mientras el usuario está en movimiento
y posibilidad de completar la transacción en forma inmediata.
1.2
1.2.1
Comercio Electrónico
Concepto de Comercio Electrónico
Existen muchas definiciones de comercio electrónico. Una de la más completas,
es la siguiente:
“Transacciones de negocios efectuadas mediante redes públicas o privadas,
incluyendo transacciones públicas y privadas que utilizan Internet como instrumento de entrega. Estas transacciones incluyen tranferencias financieras,
intercambios en línea, subasta, entrega de productos y servicios, actividades de
la cadena de abastecimiento y redes de negocios integradas” [6].
El concepto de Comercio Electrónico (e-commerce en inglés) hace referencia a una nueva forma de hacer negocios basada en el uso de las nuevas tecnologías capaces de automatizar las transacciones comerciales que deben realizar
las empresas en sus actividades comerciales mediante mecanismos electrónicos, es decir, sin la utilización de los mecanismos tradicionales como son los
documentos basados en papel.
El término Comercio Electrónico se utiliza para referirse a cualquier relación electrónica 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 Electrónico
• El Comercio Electrónico (e-Commerce) es la simple replicación de un
negocio en Internet u otro medio electrónico que permita recoger los
pedidos u ofertar los productos y/o servicios desde o hacia clientes o
proveedores. Por ejemplo vender zapatos en la página web de la empresa,
recibir los pedidos desde la web, por ejemplo, en forma de e-mail o a
4
CAPÍTULO 1. INTRODUCCIÓN
una base de datos y hacer los despachos. Muchas veces esta actividad
puede generar duplicación de tareas o tareas extras para asentar esas
transacciones en los sistemas digitales centrales del negocio.
• El hacer Negocios Electrónicos (e-Business) integra no sólo el e-Commerce
sino también la operativa interna, por ende se accede a la infraestructura informática, los procesos de las ventas electrónicas, en definitiva
toda la administración del negocio está conectada a la página web y las
transacciones que en ella se desencadenen. El sistema organizacional e
informático está por ende unificado con el de la web corporativa, el negocio está realmente en línea (on-line). El sitio web pasa a ser una boca
de expendio más así como lo son los mostradores en las sucursales, en
los intermediarios o la propia casa matriz de la empresa. En términos
realmente simples se puede decir que cuando alguien realiza una compra
en el sitio web, esa transacción se refleja de manera inmediata en los
sistemas informáticos de la empresa, a su vez que dispara los procesos
administrativos, financieros y de despacho necesarios.
1.2.3
Esquema General
El Comercio electrónico se puede definir como un intercambio electrónico 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 electrónico consiste
básicamente en un vendedor que oferta sus productos a través de un catálogo
(preferentemente actualizado) y unos compradores de dicho producto quienes
consultan el catálogo 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 confirma.
1.2. COMERCIO ELECTRÓNICO
5
• Finalmente es necesario realizar la entrega del producto y el pago (ambos
procesos se pueden realizar indistintamente de forma electrónica o no);
ver fig. 1.1 de la pág. 5.
Todos los intercambios entre compradores y vendedores en el escenario
electrónico o virtual se realizan de forma no presencial mediante la utilización
de redes de transmisión como el caso de la red Internet.
Figura 1.1: Esquema General del Comercio Electrónico.
La mayoría de las veces los compradores y vendedores en el escenario electrónico ni siquiera se conocen y en el caso de comportamiento deshonesto de
alguno de ellos no existen evidencias físicas que pueden utilizarse como prueba
en caso de litigio. Por lo tanto es necesario que se pase a un escenario seguro
de comercio electrónico o virtual.
1.2.4
Modelos de Comercio Electrónico
B2C (Bussines to Consumer) (Negocio a Cliente Final)
Es el negocio orientado hacia el consumidor final (internauta particular que
navega por la red).
Las empresas ofrecen sus productos a particulares a través de su portal
web. El único requisito es conectarse a su web y hacer un pedido.
Se considera el original comercio electrónico.
Las estadísticas indican que cada vez se compra más por Internet, pero la
evolución es lenta comparada con las expectativas que se habían creado.
6
CAPÍTULO 1. INTRODUCCIÓN
Tiene el riesgo de que los clientes pueden comparar precios fácilmente, 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 también 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 fijadas.
Es el verdadero impulsor del comercio electrónico.
El volumen de negocio entre empresas es muy superior al negocio dirigido
al cliente final.
C2C (Consumer to Comsumer) (Consumidor a Consumidor)
La negociación se desarrolla entre personas con intereses similares indistintamente de la parte compradora y vendedora. La comunicación se realiza de
forma espontánea y los participantes pueden asumir roles de comprador, vendedor o ambos. Requiere sistema de intermediario para garantizar la confianza
entre los participantes.
Un ejemplo podría 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 podría resumir en dos negocios B2C paralelos.
Otra categoría de comercio electrónico que seguramente impactará en el
futuro es Mobil-Commerce (M-Commerce) o comercio electrónico a través de
teléfonos móviles.
1.3. M-COMMERCE
7
Se fundamenta en lo siguiente:
• La penetracion de la telefonía móvil.
• El acceso gratuito/tarifa plana a Internet.
• La implantación de la tarjeta inteligente. Los móviles inteligentes.
• Telefonía inalámbrica digital.
• La convergencia: Teléfono fijo/móvil/Internet.
El potencial de usuarios de teléfonos móviles es superior al de los internautas.
Los estudios de empresas consultoras de comercio electrónico apuestan por
el comercio electrónico móvil, como el de mayor desarrollo e impacto futuro.
1.3
M-Commerce (Comercio Electrónico a Través
de Dispositivos Móviles)
El comercio electrónico se está transformando lentamente en m-commerce, un
nuevo modelo de comercio on-line en el cual los teléfonos móviles, u otros
artefactos wireless (inalámbricos), jugarán un papel muy importante. Todos
los carriers importantes del mundo están 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 móvil e interactivo a datos, abriendo
nuevas posibilidades para el comercio. Pero esas oportunidades tienen algunas
dificultades como el ancho de banda limitado que aún complica las transmisiones, y la interfaz de usuario de los dispositivos móviles es limitada en tamaño.
Además, los costos de acceso son altos, y el poder de cómputo de estos dispositivos es mucho más pequeño que el de las PCs.
El m-commerce involucra tres aspectos básicos:
• Oferta de los negocios y servicios en un área circundante al usuario.
8
CAPÍTULO 1. INTRODUCCIÓN
• Información oportuna georeferenciada mientras el usuario está en movimiento.
• Posibilidad de completar la transacción de forma inmediata.
Por ello debe ofrecer al usuario las siguientes prestaciones:
• Negociación y entrega inmediata.
• Métodos de micro y macro pagos.
• Facilidades de uso en el contexto móvil.
1.4
Computación Ubicua o Pervasiva
Mark Weiser, en Septiembre de 1991, describió su visión de lo que él llamaba
computación ubicua, hoy llamada computación pervasiva. La esencia de su
visión era la creación de entornos llenos de computación y de capacidad de
comunicación, todo integrado de forma inapreciable junto a las personas. La
visión de Weiser estaba bastante alejada de su época, entre otras razones
porque no existía la tecnología necesaria para llevarla a cabo. Pero después
de más de una década 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 inalámbricas.
• Sensores muy avanzados.
• Computación “vestible”.
1.4.1
Principios
Uno de los principales objetivos de la computación ubicua es hacer desaparecer
a los dispositivos computacionales haciéndolos 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 revolución que
1.4. COMPUTACIÓN UBICUA O PERVASIVA
9
puede hacer cambiar el modo de vida diario. Las personas se centrarán en
las tareas que deben hacer, no en las herramientas que utilizan, porque se
pretende que esas herramientas pasen desapercibidas.
El significado de enviar la computación a un “segundo plano” está referido
a dos conceptos diferentes pero relacionados. El primero es el significado
literal de que la tecnología de la computación se debe integrar en los objetos,
cosas, tareas y entornos cotidianos. Y la segunda es que esta integración se
debe realizar de forma que la introducción de la computación en estas cosas
u objetos no interfieran con las actividades para las que son usadas, y que
siempre proporcionen un uso más cómodo, sencillo y útil de esos objetos.
Estos objetos cotidianos en los que se integra la tecnología de la computación pasan a tener una serie de propiedades que permiten la creación del
entorno ubicuo buscado.
Algunas de esas propiedades son:
• Comunicación entre dispositivos: Todos estos objetos dotados de capacidad de computación también tienen capacidad de comunicación, y no
solo con el usuario, sino con los demás objetos integrados que haya a su
alrededor.
• Poseen memoria: Además de poder comunicarse entre ellos e interactuar con los usuarios, estos dispositivos tienen capacidad de memoria y
pueden utilizar esta memoria para una mejor interacción 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 situación geográfica,
los dispositivos que hay a su alrededor, las preferencias de los usuarios,
y actúan 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 través de la
interacción con otros dispositivos.
El computador personal, Internet y la World-Wide Web han influido ya en
muchos aspectos del mundo de los negocios y hay señales evidentes de una amplia convergencia de industrias enteras como la de los medios de comunicación,
entretenimiento, electrónica de consumo, telecomunicaciones y tecnología de
10
CAPÍTULO 1. INTRODUCCIÓN
la información. La siguiente ola de la revolución tecnológica puede afectar
directamente y en todos los aspectos de la vida cotidiana.
Durante más de 30 años la conocida ley de Moore, según la cual la funcionalidad de un procesador se duplica cada 18 meses, ha demostrado ser cierta.
Una mejora similar en prestaciones se aplica también a algunos otros parámetros importantes de la tecnología. Se afirma que la tendencia actual continuará
durante unos cuantos años más, lo que hace que toda esta área de desarrollo
sea tan intrigante. Ahora parece que el futuro próximo estará caracterizado
por pequeños computadores que se comunican de forma espontánea, que por
su pequeño tamaño y por su bajo precio, se integrarán en casi todos los objetos
cotidianos. La tecnología de la información por lo tanto se volverá ubicua e
invadirá todos los aspectos de la vida de las personas.
Los teléfonos móviles con acceso a Internet y los Asistentes Digitales Personales (Personal Digital Assistants, PDAs) que se comunican sin cables con
otros dispositivos próximos a ellos son los primeros indicios de la era “post-PC ”
venidera.
Al principio, el principal objetivo es permitir el acceso a la información de
cualquier tipo desde cualquier lugar y en cualquier momento, lo que evidencia los esfuerzos actuales de la industria por integrar aparatos de información
móviles y utilizables en procesos de negocios basados en la Web y escenarios
de comercio electrónico. Sin embargo, a largo plazo, esta continua tendencia tecnológica puede dar lugar a la fusión del computador con los objetos
cotidianos típicos 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 tecnológico, se podría describir a la computación ubicua como la
posibilidad de conectar todo lo que hay en el mundo a Internet, para proporcionar información acerca de cualquier cosa, en cualquier momento, en cualquier sitio. Por decirlo de otra forma, el término computación ubicua significa
la omnipresencia de computadores muy pequeños interconectados sin cables
que se incrustan de forma casi invisible en cualquier tipo de objeto cotidiano.
Usando pequeños sensores, estos procesadores incrustados pueden detectar el
entorno que les rodea y equipar a su objeto con capacidades tanto de procesar
información como de comunicación.
1.4. COMPUTACIÓN UBICUA O PERVASIVA
1.4.3
11
La Ley de Moore y la Visión de Weiser
La ley de Moore, formulada en los años sesenta por Gordon Moore, afirma
que la capacidad de computación disponible en un microchip se multiplica por
dos aproximadamente cada 18 meses y, de hecho, esto ha resultado ser un
pronóstico extraordinariamente exacto del desarrollo del chip desde entonces.
Y esta ley se ha venido cumpliendo hasta el día de hoy, la capacidad de
cómputo de los procesadores avanza muy rápidamente. Pero no solo la capacidad de cómputo de los procesadores, sino también la capacidad de almacenamiento, el ancho de banda para las comunicaciones, en resumen, cada poco
tiempo se tiene dispositivos más baratos, más pequeños y más potentes. Y no
parece que se vaya a parar este crecimiento, sino todo lo contrario.
El término computación ubicua , fue acuñado hace más de diez años por
Mark Weiser; ver fig. 1.2 de la pág. 12, un investigador del Palo Alto Research
Center de XEROX.
Weiser ve la tecnología solamente como un medio para un fin y como algo
que debería 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 tecnología de la
información sería un enfoque equivocado, ya que su complejidad absorbería
demasiado la atención del usuario. Según Weiser, el computador como dispositivo dedicado debería desaparecer, mientras que al mismo tiempo debería
poner a disposición sus capacidades de procesamiento de la información. [20]
Weiser ve el término computación ubicua en un sentido más académico e
idealista centrada en la persona, como una visión de tecnología discreta, mientras que la industria ha acuñado por eso el término computación pervasiva, o
ampliamente difundida con un enfoque ligeramente diferente. Aunque su visión siga siendo todavía integrar el procesamiento de la información en objetos
cotidianos de forma casi invisible, su objetivo principal es utilizar tales objetos
en un futuro próximo en el ámbito del comercio electrónico y para técnicas de
negocios basados en la Web. [18]
Mark Weiser fue un principal científico de Xerox Parc y ampliamente considerado como el padre de la computación ubicua (conocida también como
ubicomp).
Weiser nació en Harver, un barrio exterior de Chicago, Illinois; estudió
ciencias de la computación y comunicación en la Universidad de Michingan,
12
CAPÍTULO 1. INTRODUCCIÓN
Figura 1.2: Mark Weiser (1952-1999), el Visionario de la Computación Ubicua
se dedicó a la docencia durante ocho años en ciencias de la computación en la
Universidad de Maryland, Clollege Park.
Mientras Weiser trabajaba para una variedad de compañías relacionadas a
la computación, su trabajo fue en el campo de la computación ubicua mientras
dirigía el laboratorio de ciencias de computación de Parc, al cual se unió en
1987, Se convirtió en la cabeza del laboratorio de ciencias de la computación
en 1988 y el oficial primero de la tecnología en 1996, simultáneamente fue
autor de más de 75 publicaciones.
1.5
La Sociedad de la Información y el Conocimiento
“Es un hecho de la realidad que los vertiginosos avances que presentan las
TICs (Tecnologías de la Información 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 Información y el Conocimiento
o Cibersociedad, en la cual la profusión de redes de datos ha permitido interconectar una diversidad de equipos informáticos de diferentes tecnologías de
hardware y de software constituyendo una enorme red mundial multiplataforma, que ha generado una nueva forma de interacción de las personas y de la
empresas, impactando en la educación, las actividades sociales, el comercio,
etc.
1.5. LA SOCIEDAD DE LA INFORMACIÓN Y EL CONOCIMIENTO 13
1.5.1
Definición de Conocimiento
El conocimiento es materia de estudio de distintas disciplinas, tales como la
filosofía, la gestión empresarial, y más recientemente la informática, por ello
se encuentran distintas definiciones del término conocimiento según el punto
de vista e interés de quienes se pronuncien.
Antes de definir conocimiento algunos autores se apoyan a las definiciones
de otros dos conceptos: dato e información.
• Dato: antecedente necesario para llegar al conocimiento exacto de una
cosa o para deducir las consecuencias legítimas de un hecho.
• Información: acción y efecto de informar e informarse.
• Conocimiento: acción y efecto de conocer. Noción, ciencia, sabiduría.
También se puede definir al conocimiento como:
“Es el conjunto de experiencias valores e informaciones dotadas de significado que facilitan el marco idóneo para evaluar nuevas informaciones e
incorporar nuevas experiencias”. [12]
1.5.2
Proceso de Formación del Conocimiento
Comprende los siguientes pasos:
• Datos: Hechos y expresiones percibidos, por ejemplo una secuencia de
números, letras.
• Información: Datos organizados bajo patrones explicativos; conjunto
coherente de datos que transmite un mensaje.
• Conocimiento: Información elaborada de modo que comporta significado
y puede ser utilizada en la toma de decisiones.
• Sabiduría: Conocimiento reutilizado y proceso de retroalimentación de
los conocimientos.
14
CAPÍTULO 1. INTRODUCCIÓN
1.5.3
Clases de Conocimiento
El conocimiento puede dividirse en:
• Conocimiento tácito
• Conocimiento explícito
El conocimiento tácito es aquel que no está registrado por ningún medio y
que solo se obtiene mediante la adquisición de conocimientos de manera práctica y solo es posible transmitir y recibir consultando directa y específicamente
al poseedor de estos conocimientos.
También el conocimiento tácito es aquel conocimiento que no está registrado (el que se tiene en la cabeza). Es la intuición, opinión, las creencias, la
experiencia.
El conocimiento tácito como la percepción subjetiva o las emociones, no se
puede instrumentalizar y se transmite en determinados contextos y acciones.
El conocimiento tácito 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 explícito se trata del conocimiento basado en datos concretos, con lo que sería suficiente su conocimiento para el aprovechamiento
de los mismos, sin necesidad de interpretación alguna, expresándolo de una
manera simple, es “la teoría”.
El conocimiento explícito es el conocimiento tácito codificado y vertido en
algún soporte de almacenamiento y comunicación. Este conocimiento se puede
expresar mediante palabras y números, y es fácil de transmitir. Es un conocimiento formal que puede plasmarse en documentos de una organización tales
como informes, patentes, manuales, imágenes, esquema, software, productos,
diagramas organizativos, etc.
1.5.4
Ciclo del Conocimiento
Se fundamenta en dos pilares:
— La cadena del conocimiento.
1.5. LA SOCIEDAD DE LA INFORMACIÓN Y EL CONOCIMIENTO 15
— La transformación del conocimiento tácito y explícito.
El conocimiento tácito encauzado de forma correcta, genera conocimiento
explícito (ejemplo almacenándolo en una base de datos).
El ciclo de vida del conocimiento depende de la distinción entre conocimiento tácito y conocimiento explícito; (ver fig. 1.3 de la pág. 15). Ambos
tipos de conocimientos son necesarios y se produce una realimentación continua entre ambos.
Comprende la trasformación de:
— Datos en Información.
— Información en conocimiento.
— Conocimiento en acciones/decisiones.
— La experiencia del conocimiento en sabiduría.
Figura 1.3: La Cadena del Conocimiento
1.5.5
Características de la Sociedad del Conocimiento
Es una realidad que la nueva sociedad está basada en el conocimiento más
que en la información. El conocimiento es información almacenada por las
personas.
La materia prima es la información, el producto es el conocimiento; ver
fig. 1.4 de la pág. 16.
16
CAPÍTULO 1. INTRODUCCIÓN
Figura 1.4: La Era de la Información
Es dificil predecir cómo será la nueva sociedad y, por lo cual, difícil de
definir con precisión sus características básicas. La nueva sociedad plantea
nuevos requisitos para las personas, que deberán adquirir y mantener una
cultura de la información.
Se puede diferenciar entre una economía de la información y una sociedad
del conocimiento. Un país puede entrar en una economía de la información
mediante un esfuerzo de inversión de equipos y sistemas, o con políticas de
fomento de las redes de comunicación, pero estas características no incluyen
necesariamente el desarrollo de la nueva sociedad que dependerá más de la
existencia de una cultura de la información suficientemente desarrollada.
Es preciso fomentar la creación de redes, equipos y sistemas de información
y favorecer el ingreso de la población en la cultura de la información, a partir
de un pacto social. Este nuevo pacto debería ser plural, uniforme y no dirigido,
diseñado desde la realidad más cercana de los ciudadanos. Los requisitos de
la nueva sociedad plantean la necesidad de realizar un esfuerzo permanente de
adaptación individual y colectiva.
La persona instruída (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. LA SOCIEDAD DE LA INFORMACIÓN Y EL CONOCIMIENTO 17
1.5.6
Gestión del Conocimiento
La Gestión del Conocimiento corresponde al conjunto de actividades desarrolladas para utilizar, compartir, desarrollar y administrar los conocimientos que
posee una organización y los individuos que en esta trabajan, de manera de
que estos sean encaminados hacia la mejor consecución de sus objetivos.
Inicialmente la gestión 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 críticamente o de manera inteligente y racional la gran cantidad de
información disponible, con el fin de aprovecharla con el máximo rendimiento
social o personal.
Esta disciplina no es nueva, sino que sus raíces se remontan a la inteligencia artificial, cuyo objetivo final ha sido la sintetización del comportamiento
humano mediante ordenadores.
Las Bases de Conocimiento son depósitos o almacenes de datos (repositorios) del conocimiento del negocio (funciones, reglas, cálculos, informes)
totalmente independiente de la plataforma de ejecución, que mediante tecnologías de inteligencia artificial son capaces de deducir, generar y mantener
automáticamente estructuras normalizadas de bases de datos y programas.
La atención que se está prestando a la gestión del conocimiento está creciendo a una velocidad impresionante. Revistas, diarios de economía y libros
publican innumerable teorías y casos sobre gestión del conocimiento y sus
tópicos.
1.5.7
Tecnologías de la Gestión del Conocimiento
Las tecnologías de GC deben permitir:
• Identificar conocimientos necesarios.
• Identificar dónde y quién tiene el conocimiento o si necesita ser creado.
• Reunir y capturar el conocimiento encontrado.
• Resumir y sintetizar la información.
18
CAPÍTULO 1. INTRODUCCIÓN
• Distribuir la información a distintos niveles.
• Actualizar, eliminar y modificar el conocimiento obsoleto.
La Gestión del Conocimiento es la mezcla de los siguiente factores:
• Personas: Aquellas que producen y aquellas que utilizan conocimiento
que será la base para la acción.
• Contenido: El flujo de datos, información y conocimiento importantes
en el éxito del negocio.
• Tecnología: Se refiere a la infraestructura técnica que se encarga de la
captura, almacenamiento y distribución del contenido a aquellas personas que lo necesitan, en el lugar y momento oportuno.
1.6
Comercio Electrónico en la Sociedad del Conocimiento
A mediados de los noventa se inició la utilización de Internet con fines comerciales, en ese momento nadie pudo predecir su impacto en la economía.
Se puede afirmar que Internet no es solo un canal de transmisión o comunicación de información, sino que lleva implícito un cambio cultural importante.
Por lo tanto la trascendencia de la economía digital permite hablar de un
nuevo marco de actuación, de una génesis parametral que traslada el desarrollo
organizativo a otro nivel. La economía digital es una economía de cambios
importantes, tanto en la forma de entender la gestión dentro y fuera de las
empresas como en la ampliación más allá de los límites nacionales para el
desarrollo de su actividad.
Efectivamente, la personalización de la relación 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 más sólidos
en la relación cliente-empresa, el B2C.
1.7. COMERCIO ELECTRÓNICO BANCARIO
1.7
1.7.1
19
Comercio Electrónico Bancario
¿Qué es Banca Electrónica?
Los sistemas de banca electrónica posibilitan el acceso a una serie de servicios
a partir de una PC con conexión a Internet. La comodidad que brindan es
tanta que una vez que el cliente se acostumbra a usarlos le resulta difícil volver
atrás. Con ello no sólo se ahorra tiempo, sino que también la mayor parte de
las veces el empleo de los cajeros automáticos y la realización de transacciones
por teléfono 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 electrónica), y el de Internet banking (que se refiere directamente
al empleo de la red mundial).
Este servicio no es nuevo, ya que desde hace años existen el acceso telefónico (banca telefónica) y los cajeros automáticos, que ya ofrecían soluciones
tempranas de autoservicio y de gestión de las propias cuentas desde casa. Lo
realmente novedoso de la banca digital y su motor de desarrollo y expansión es
la oferta de nuevos servicios de valor añadido, sólo posibles a través de Internet
u otros medios telemáticos.
En general, las web de bancos y cajas no son sino una réplica virtual de
algunos de los servicios ofrecidos al cliente en la ventanilla, con la comodidad
de estar disponibles las 24 horas del día y desde cualquier lugar. De hecho, en
cuanto a la accesibilidad, la posibilidad de conectarse al banco mediante un
teléfono móvil GSM con mensajes SMS o con protocolo WAP para conocer
el estado del crédito o si ha llegado la transferencia tan esperada, supone un
avance importante hacia la globalización del sector bancario.
Internet, líneas telefónicas, telefonía celular GSM, harán posibles las aplicaciones multimedia en los teléfonos celulares, una gran variedad de tecnologías
despliegan un inmenso abanico de posibilidades para crear nuevas estrategias
que optimicen la relación 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, teóricamente más baratos.
20
1.7.2
CAPÍTULO 1. INTRODUCCIÓN
Ventajas
El cliente del banco puede utilizar una computadora y una conexión a Internet
para acceder a sus cuentas desde cualquier sitio. Este servicio funciona las 24
horas, todos los días de la semana. La confirmación de las transacciones se
realiza con gran rapidez. El tiempo de procesamiento es similar al empleado
por un cajero automático. La variedad de las transacciones es indudablemente
amplia. Se puede desde verificar el balance de una cuenta hasta solicitar un
préstamo.
1.7.3
Desventajas
El tiempo inicial que se puede invirtir es significativo (los diseñadores 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 reduciéndose gracias a la competencia.
1.7.4
Banca a Través del Teléfono Móvil
En una sociedad en la que el número de usuarios de telefonía móvil supera
al de usuarios de Internet e incluso al de abonados de líneas fijas, 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 (España), han lanzado servicios de telebanca móvil, que permiten a los clientes
cada día más exigentes disfrutar de servicios de valor añadido además de los
mismos servicios de telebanca fija convencionales. Los usuarios equipados con
un teléfono móvil GSM capaz de recibir y enviar mensajes cortos de texto
(SMS), pueden acceder cómodamente desde cualquier lugar donde se encuentren y a cualquier hora del día o de la noche a una serie de funciones como:
1.7. COMERCIO ELECTRÓNICO BANCARIO
21
• Consulta de información bancaria: listado de cuentas, saldos y movimientos, gasto acumulado de su tarjeta de crédito, etc. La petición de
información se puede realizar de dos maneras:
— Con mensajes de texto: Se envía un mensaje de texto al número
del banco o caja correspondiente y se recibe otro mensaje de texto
con la información solicitada.
— Con llamada telefónica: Se llama al número del banco o caja correspondiente (desde un teléfono fijo o desde su móvil), se solicita
la recepción de la información y la entidad financiera. Llega la
respuesta en un mensaje de texto.
• Programación para la recepción automática de información bancaria de
interés para el cliente.
• Programación para la recepción automática 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 activación
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 telefónica. Tan sólo se necesita un terminal GSM con capacidad
de recepción y envío de mensajes cortos, característica ofrecida por todas las
operadoras y soportada en la práctica totalidad de modelos.
Internet en el Móvil
Sin embargo, la tecnología de mensajes SMS fue reemplazada. El siguiente
paso en la evolución de la telefonía celular hace uso de la tecnología WAP, que
permite que se pueda acceder a los contenidos de Internet desde un teléfono
móvil en un navegador WAP. Gracias a ésta tecnología, los bancos podrán
ofrecer a sus clientes servicios financieros inalámbricos 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 conexión fija ni de un ordenador, por lo que puede accederlos en el tren o en el coche, mientras espera
22
CAPÍTULO 1. INTRODUCCIÓN
en el aeropuerto o pasea por la montaña. No se requieren conocimientos de
informática ni hay que configurar complicados programas.
La navegación con el móvil es intuitiva y el software necesario ya está
instalado de serie en el teléfono. Por su parte, los bancos y cajas pueden
ofrecer servicios totalmente nuevos y rentables, como la presentación y pago de
facturas a través del teléfono móvil, consulta instantánea a mercados bursátiles
y compra-venta de acciones, además de todos los servicios disponibles para
Internet, sin gastos adicionales importantes para las entidades, puesto que
WAP aprovecha la inversión ya realizada en soluciones bancarias por Internet.
El único límite viene impuesto por la imaginación de los bancos y cajas a la
hora de ofertar servicios novedosos y especialmente atractivos para aumentar
sus ingresos y la fidelidad de sus clientes.
Con la aparición de los móviles de tercera generación, haciendo uso de la
tecnología UMTS (Universal Mobile Telecommunications Standard), es posible velocidades de transmisión de megabits por segundo, abriendo la puerta
a aplicaciones multimedia de gran ancho de banda. Los teléfonos vienen cada vez equipados con pantallas más grandes de mayor resolución y harán del
ordenador portátil una herramienta de la prehistoria informática.
Un teléfono móvil actual puede ejecutar aplicaciones como agenda, juegos
o cualquier otra que emplee la tecnología Java J2ME (Java para móviles),
además de captar imágenes fijas o en movimiento, con conexión a Internet y
características básicas de reconocimiento de voz.
Hoy en día los proveedores de servicios bancarios están desarrollando aplicaciones que corren en el dispositivo móvil y tienen conexión a Internet, permitiendo el acceso a la información que reside en las aplicaciones centrales
de los bancos. Todo gracias a las tecnologías J2ME y GPRS (Servicio de
Radio de Paquetes Generales) que permite tarifar al usuario por volumen de
información transferida y no por tiempo de conexión o tiempo de aire, lo cual
reduce costos para los clientes.
1.7.5
Seguridad en Operaciones Electrónicas
Los mecanismos de seguridad implantados en la mayoría de bancos y cajas no
son completamente satisfactorios para una actividad como la bancaria, en la
que el usuario no sólo consulta saldos y movimientos de sus cuentas y tarjetas,
sino que también puede efectuar transferencias y traspasos, así como comprar
1.7. COMERCIO ELECTRÓNICO BANCARIO
23
y vender acciones. No se puede admitir que los bancos se tarden mucho más en
la implantación de certificados digitales como solución para la identificación
bilateral de las partes implicadas en las transacciones a través de Internet.
Queda por ver hacia qué tipo de soluciones tecnológicas se caminará en otros
medios de acceso que irán volviéndose paulatinamente más populares como la
TV interactiva digital o el teléfono celular con acceso a Internet.
Un banco en Internet se presenta a sus clientes a través de una Web. Esta
es la cara y el interfaz a través del cual éstos interactúan con sus activos,
usando para ello un simple navegador. Como primera medida, la máquina
donde dicho WebSite está situado no es la máquina donde están los datos de
los usuarios. Es el aplicativo Web o WAP (si se trata de telefonía celular) el
que, cuando es necesario, accede a la verdadera máquina o Host en la que se
encuentran los datos reales de los usuarios.
El muro de fuego: Existe un primer nivel de seguridad física que protege
los datos almacenados en el banco.
La red a la que pertenece la máquina donde se halla ubicada este interfaz
o Web del banco, está protegida por lo que se conoce como un muro de fuego
(firewall en inglés). Esto quiere decir que hay una barrera ante ella que va a
rechazar sistemáticamente todo intento de conexión no controlada, basándose
en una política de reglas que se establecen en dicho firewall. Es decir, sólo
se admitirán 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 electrónica son:
Las claves: Clave personal, PYN o clave secreta. Cuando accedemos al
banco en Internet, lo primero que se pedirá es un código de usuario y una
contraseña. Al tercer intento consecutivo erróneo (incluso si cada uno de los
intentos va espaciado en el tiempo) el sistema expulsa al tenedor de la tarjeta,
debiendo identificarse nuevamente ante el banco para reactivarla.
Identificación operativa. Para todas aquellas operaciones que vayan más
allá de las meras consultas, como por ejemplo realizar una transferencia, el
sistema va a solicitar una segunda contraseña con el fin que le se rectifique la
decisión. 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 características, ya que si alguien con malas intenciones
24
CAPÍTULO 1. INTRODUCCIÓN
la llega a conocer, por el motivo que sea, podría hacerse pasar perfectamente
por alguien más.
El certificado digital: Un certificado es un documento electrónico, emitido
por una Entidad Certificadora, que identifica de forma segura al poseedor del
mismo, evitando la suplantación de identidad por terceros. Es el componente
esencial de la firma electrónica.
Es una herramienta que garantiza la identidad de los participantes en una
transacción que requiera altos niveles de seguridad. Mediante él se demuestra
a la máquina que recibe la conexión que se es quien realmente dice ser. Esto
se conoce con el nombre de identificación.
El servidor Web del banco en Internet también es poseedor de su correspondiente certificado 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, aprovechándose de
que no se puede ver dónde está realmente llegando a la conexión.
Servidores seguros: El servidor Web del banco es un servidor seguro, esto
es, establece una conexión con el cliente de manera que la información circula
a través de Internet codificada, mediante algoritmos, lo que asegura que sea
inteligible sólo para el servidor y el navegador que accede al Web, entendiéndose ambos mediante un protocolo que se ha dado en llamar SSL. De este modo,
ninguna persona externa, que eventualmente estuviera espiando ese trasiego
de información, podrá descifrar los datos confidenciales 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 están
enviando al auténtico servidor del banco, al que le ha sido expedido el
correspondiente certificado digital. De igual forma, a través del certificado digital personal, el cliente se puede identificar ante el banco durante
las transacciones delicadas.
• Confidencialidad. Los datos, en el caso de ser capturados por alguien,
no podrán ser interpretados ya que viajan de modo codificado.
• Integridad. Los datos llegan al servidor del banco sin sufrir alteración
alguna por el camino, ya que si ésta se produce, por mínima que sea, el
protocolo SSL se da cuenta.
Capítulo 2
El Mundo Móvil
2.1
Evolución
En 1983, aparecieron en el mercado los primeros teléfonos celulares que podían llevarse a todos lados. Desde esos comienzos, los teléfonos celulares o
móviles han sido vistos como la comunicación del futuro. Se trataba de un
equipo que permitía permanecer comunicado en todo momento y en todo lugar, con amigos, familiares y con la empresa. Además cambiaba radicalmente
el modo de comunicarse: ya la comunicación 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 prácticamente cada integrante de
una familia puede llegar a tener su propio equipo celular.
La primera generación de teléfonos celulares comenzó en 1979 y se trataba
de conexiones estrictamente de voz y analógicas. Estas conexiones no tenían
seguridad y generaban muchos conflictos en las comunicaciones. La tecnología
que ha permitido esta comunicación se llamó AMPS (Advanced Mobile Phone
System) y todavía sigue siendo utilizada en lugares rurales y ciudades alejadas
de América.
Hacia 1990 la tecnología evolucionó a lo que se denominó 2G (Segunda Generación) o PCS (Personal Communication Service). Esta etapa se caracterizó
por ser digital y utilizar algoritmos de compresión y seguridad más sofisticados
en las comunicaciones. Sigue siendo la tecnología más utilizada actualmente
25
26
CAPÍTULO 2. EL MUNDO MÓVIL
en las comunicaciones móviles del mundo.
En esta etapa, se encuentran predominantemente 3 tipos de tecnologías
compitiendo en el mercado: CDMA, TDMA y GSM .
GSM es la tecnología que más ha evolucionado en ésta generación y por
ello, actualmente, posee más del 70% del mercado mundial. Técnicamente es
un derivado de la tecnología TDMA [8].
El sistema 2G trajo consigo nuevas aplicaciones de datos sobre la red celular: fax, módem, SMS; aunque rápidamente su capacidad de ancho de banda
quedó limitada. Por esta limitación de la segunda generación (9,6 Kbps) y, al
darse cuenta que la próxima generación (la 3G) tardaría unos cuantos años
más en venir, los fabricantes crearon un intermedio llamado 2.5G que permitía
conexiones de datos más veloces, como lo es el protocolo GPRS que permite
velocidades de 64 Kbps o superiores.
En pocos países del mundo ya está instalada la 3G (Tercera Generación) de
telefonía celular. Esta tecnología 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 tecnologías más importantes en 3G al momento son: W-CDMA,
TD-SCDMA y CDMA2000. Las velocidades de transmisión de estas tecnologías van de 384 Kbps a 4 Mbps, ya superan a conexiones de banda ancha
hogareñas en ADSL que están entre 1 Mbp y 1 Gbps. Se debe recordar que
estas velocidades se logran en forma inalámbrica y en constante movimiento
del equipo (a mayor velocidad de movimiento, menor ancho de banda). También ya se habla de una 4G que comenzaría a implementarse hacia 2010 y que
traería aparejado velocidades de 100 Mbps, equiparables con las velocidades
actuales de una red local.
2.2
Teléfonos Móviles de Primera Generación
El sistema más antiguo fue el de los radioteléfonos móviles que se utilizaban de
forma esporádica para comunicación marítima y militar durante las primeras
décadas del siglo XX. En 1946 se construyó el primer sistema de teléfonos
instalado en autos. Este sistema utilizaba un solo transmisor grande colocado
en la parte superior de un edificio y tenía un sólo canal que servía para enviar
2.2. TELÉFONOS MÓVILES DE PRIMERA GENERACIÓN
27
y recibir. Para hablar, el usuario tenía que oprimir un botón que habilitaba el
transmisor e inhabilitaba el receptor. Tales sistemas, conocidos como sistemas
de oprimir para hablar, se instalaron en algunas ciudades desde finales de la
década de 1950.
En la década del 60 se instaló el IMTS (Sistema Mejorado de Telefonía
Móvil), también utilizaba un trasmisor de alta potencia (200 watts), en la
cima de una colina, pero tenía dos frecuencias, una para enviar y la otra para
recibir, por lo que el botón de oprimir para hablar no era necesario.
IMTS manejaba 23 canales dispersos desde 150 hasta 450 Mhz. Debido
al número tan pequeño de canales, los usuarios a veces tenían que esperar
bastante tiempo antes de obtener el tono de marcar.
2.2.1
Sistema Avanzado de Telefonía Móvil
La telefonía móvil terrestre utiliza estaciones terrestres. Éstas se encargan de
monitorizar la posición de cada terminal encendida, pasar el control de una
llamada en curso a otra estación, enviar una llamada a un terminal. Cada
estación tiene un área de cobertura, zona dentro de la cuál la comunicación
entre un terminal y ésta se puede hacer en buenas condiciones.
Las zonas de cobertura teóricamente son hexágonos regulares o celdas. En
la práctica, toman distintas formas, debido a la presencia de obstáculos y a
la orografía cambiante de la celda como se puede apreciar en la fig. 2.1 de la
pág. 28. Además se solapan unas con otras. Es por esto, que cuando un móvil
está cerca del límite entre dos celdas, puede pasar de una a otra, en función
de cuál de las dos le ofrezca más nivel de señal, y esto puede suceder incluso
durante el transcurso de una llamada sin que se perciba nada.
En todos los sistemas de telefonía móvil , una región geográfica se divide en
celdas, razón por la cuál los dispositivos se conocen como teléfonos celulares.
En AMPS (Sistema Avanzado de Telefonía Móvil, inventado por los laboratorios Bell e instalado por primera vez en los Estados Unidos) las celdas
normalmente tienen de 10 a 20 km de diámetro; en los sistemas digitales. Cada celda utiliza un conjunto de frecuencias que no es utilizada por ninguna de
sus vecinas.
La idea clave que confiere a los sistemas celulares con más capacidad que
todos lo sistemas anteriores es el uso de celdas relativamente pequeñas y la
28
CAPÍTULO 2. EL MUNDO MÓVIL
Figura 2.1: Sistema Telefónico Móvil
reutilización de las frecuencias de transmisión en celdas cercanas (pero no
adyacentes).
Un sistema IMTS de 100 km de alcance puede tener una llamada en cada
frecuencia, un sistema AMPS podría tener 100 celdas de 10 km en la misma
área con 5 a 10 llamadas en cada frecuencia en celdas muy separadas. El
diseño celular incrementa la capacidad del sistema en un orden de magnitud
conforme las celdas se hacen más pequeñas en su área de cobertura. Además,
al ser las celdas más pequeñas se necesita menor potencia, lo cual conduce a
dispositivos más pequeños y económicos.
En el centro de cada celda se encuentra una estación base a la cuál transmiten todos los teléfonos de la celda. La estación base consiste en una computadora y un transmisor / receptor conectado a una antena. En un sistema
pequeño, todas las estaciones base se conectan a un mismo dispositivo llamado
MTSO (Oficina de Telefonía Móvil) o MSC (Centro de Conmutación Móvil).
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 teléfono móvil está en una celda específica y
bajo el control de la estación base de esa celda. Cuando un teléfono móvil sale
de una celda, ésta le cede el control a otra estación circundante.
Cada estación trabaja con un rango de frecuencias, que delimita el número
máximo de llamadas simultáneas que puede soportar, puesto que a cada lla-
2.3. TELÉFONOS MÓVILES DE SEGUNDA GENERACIÓN
29
mada se le asigna un par de frecuencias diferentes: una para cada sentido de
la comunicación. Esto se denomina FDM, o multiplexación por división en la
frecuencia. Las celdas colindantes no pueden utilizar las mismas frecuencias,
para que no se produzcan interferencias.
Cada teléfono móvil en AMPS tiene un número de serie de 32 bits y un
número telefónico de 10 dígitos en su PROM. Cuando un teléfono se enciende,
examina una lista preprogramada de 21 canales de control para encontrar la
señal más potente.
Luego el teléfono difunde su número de serie de 32 bits y su número de
teléfono de 34 bits [17].
2.3
Teléfonos Móviles de Segunda Generación
La primera generación de teléfonos móviles fue analógica; la segunda fue digital. De igual manera que en la primera generación no hubo una estandarización mundial de tecnologías, tampoco hubo en la segunda generación. Existen
cuatro sistemas en uso: D-AMPS; GSM; CDMA y PDC.
2.3.1
D-AMPS - El Sistema Avanzado de Telefonía Móvil Digital
D-AMPS se describe en el estándar internacional IS-54 y su sucesor IS-136.
D-AMPS se diseñó con mucho cuidado para que pudiera coexistir con AMPS,
a fin de que tanto teléfonos móviles de primera generación como los de segunda
pudieran funcionar de manera simultánea en la misma celda.
D-AMPS utiliza los mismos canales de 30 KHz que AMPS y a las mismas
frecuencias a fin de que un canal pueda ser analógico 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 teléfono móvil D-AMPS, la señal de voz capturada por el micrófono se digitaliza y se comprime. La compresión se crea mediante un circuito
llamado vocoder y se realiza en el teléfono en lugar de en la estación base o
30
CAPÍTULO 2. EL MUNDO MÓVIL
la central, para reducir el número de bits que se envían a través del enlace
de aire. Con la telefonía fija, no hay beneficio de hacer que la compresión se
realice en el teléfono, debido a que la reducción del trafico en el circuito local
no incrementa la capacidad del sistema.
Gracias a que la digitalización y compresión se realiza en el teléfono, tres
usuarios pueden compartir un solo par de frecuencias que utilizan la multiplexión por división de tiempo. Cada par de frecuencias maneja 25 tramas / seg
de 40 mseg cada uno como se puede ver en la fig. 2.2 de la pág. 30. Además
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: configuración del sistema, control en tiempo
real, y en tiempo no real, localización, respuesta de acceso y mensajes cortos.
Cuando se enciende un teléfono móvil, hace contacto con la estación base
para anunciarse y después escucha un canal de control para llamadas entrantes.
La MTSO informa a la base doméstica del usuario dónde está, y las llamadas se pueden enrutar en forma correcta.
2.3.2
GSM (Sistema Global Para Comunicaciones Móviles)
GSM es similar a D-AMPS. Los dos son sistemas celulares. En ambos se
utiliza la multiplexación por división de frecuencia, en el que cada dispositivo
móvil transmite en una frecuencia y recibe en una frecuencia mayor (80 MHz
más arriba para D-AMPS, 55 MHz más arriba para GSM).
2.3. TELÉFONOS MÓVILES DE SEGUNDA GENERACIÓN
31
Ademá, en los dos sistemas, se utiliza multiplexión por división de tiempo
para dividir un solo par de frecuencias en ranuras de tiempo compartidas por
múltiples teléfonos móviles. Sin embargo los canales GSM son mucho más
anchos que los AMPS (200 KHz en comparación de 30 KHz) y almacenan
relativamente pocos usuarios (8 en comparación con 3), lo que le da a GSM
una tasa de datos mucho más 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 multiplexión por
división de tiempo. En cada celda se pueden manejar hasta 992 canales, aunque
muchos de ellos no están disponibles, para evitar conflictos de frecuencias con
las celdas vecinas.
La transmisión y la recepción 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 difusión es flujo continuo de salida de la estación
base que contiene la identidad de la estación base, así como el estado del canal.
Todas las estaciones móviles supervisan su fuerza de señal para ver cuándo se
han movido a una nueva celda.
El canal dedicado de control se utiliza para actualización de localización,
registro y establecimiento de llamada. En particular, cada estación base mantiene una base de datos de la estaciones móviles actualmente bajo su jurisdicción. La información necesaria para mantener esta base de datos se envía en
el canal dedicado de control.
Hay un canal de control común, que se divide en tres subcanales lógicos.
El primero de estos subcanales es el canal de localización, que la estación base
utiliza para anunciar llamadas entrantes. Cada estación móvil 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 más tarde. El tercer subcanal es el canal de otorgamiento de acceso [17].
32
CAPÍTULO 2. EL MUNDO MÓVIL
2.3.3
CDMA (Acceso Múltiple por División de Código)
Se ve como la mejor solución técnica existente y como la base para los sistemas móviles de la tercera generación. También se utiliza ampliamente en
los Estados Unidos en los sistemas móviles de segunda generación 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 estación transmita todo el tiempo a través
de todo el espectro de frecuencia. CDMA no supone que las tramas que colisionan son totalmente distorsionadas. Asume que se agregan múltiples señales
en forma lineal.
Se considera la siguiente analogía: Una sala de espera de un aeropuerto
con muchas parejas de personas conversando. TDM (multiplexión por división
de tiempo) se compara con todas las personas que están en medio de la sala
pero que esperan su turno para hablar. FDM (multiplexión por división de
frecuencias) se compara con el hecho de que todas las personas que están en
grupos separados ampliamente y cada grupo tiene su propia conversación al
mismo tiempo; aunque de manera independiente, que los otros.
CDMA se compara con el hecho de que todas las personas estén en medio
de la sala hablando al mismo tiempo, pero cada pareja hablando en un lenguaje
diferente, la persona que habla francés se concentra con el francés, rechazando
todo lo que no se francés como si hubiera ruido. Por lo tanto la clave de
CDMA es tener la capacidad de extraer la señal deseada y rechazar todo lo
demás como ruido aleatorio.
A cada estación se le asigna un código único de m bits llamado secuencia
de chip.
Cada estación utiliza completamente el megahertzio, por lo que la tasa de
chips es de 1 megachip por segundo.
Cada estación tiene su propia y única secuencia de bits.
Funciona en una banda de 1.25 MHz, pero maneja muchos más usuarios
en esa banda que cualquiera de los otros sistemas.
2.4. TELÉFONOS MÓVILES DE TERCERA GENERACIÓN
2.4
33
Teléfonos Móviles de Tercera Generación
Algunos factores que están impulsando a la industria:
• El tráfico de datos ya exede el tráfico de voz en la red fija y está creciendo
de manera exponencial.
• La industria telefónica de entretenimiento y de cómputo han adoptado
formatos digitales y están convergiendo rápidamente.
La telefonía móvil de tercera generación trata de encontrar un dispositivo
que sea portable y ligero que actúe como teléfono, reproductor de CDs, reproductor de DVDs, terminal de correo electrónico, interfaz para Web, máquina
de juegos, procesador de texto, etc.
La ITU trató de concretar esto y creó un diseño para alcanzarlo, llamado
IMT-2000 (Telecomunicaciones Móviles Internacionales), pero no cumplió con
nada de lo anterior.
Luego, se realizaron varias propuestas, y después 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 diseñado para interactuar con redes GSM
aunque no tiene compatibilidad hacia atrás 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
Móviles).
El CDMA 2000, propuesto por Qualcomm, es un diseño de espectro disperso de secuencia directa, básicamente una extensión de IS-95 y es compatible
hacia atrás con él.
Utiliza un ancho de banda de 5 MHz, pero no ha sido diseñado para interactuar con GSM y no puede entregar llamadas a una celda GSM (ni a una
celda D-AMPS ).
34
CAPÍTULO 2. EL MUNDO MÓVIL
Algunas de la diferencias técnicas 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 sincronización de tiempo se realiza de una manera
diferente.
2.4.1
EDGE (Tasa de Datos Mejorada para la Evolución 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 más bits por
baudio. El problema es que más bits por baudio significan más errores por
baudio, por lo que EDGE tiene nueve esquemas diferentes para modulación
y corrección de errores, que difieren en la cantidad de ancho de banda que se
dedica a arreglar los errores introducidos por la velocidad más 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 móviles envíen y reciban paquetes IP (protocolo de Internet) en
una celda que se ejecuta en un sistema de voz.
Cuando GPRS está en operación, algunas ranuras de tiempo en algunas
frecuencias se reservan para el tráfico de paquetes.
La estación base puede manejar de manera dinámica el número y la ubicación de las ranuras de tiempo, dependiendo de la tasa de voz sobre el tráfico
de datos de la celda.
Las ranuras de tiempo disponibles se dividen en varios canales lógicos utilizados para propósitos diferentes.
La estación base determina qué canales lógicos se asignan en qué ranuras
de tiempo.
Un canal lógico se utiliza para bajar paquetes de la estación base a algunas
estaciones móviles, y cada paquete indica a quién va destinado.
Para enviar un paquete IP, una estación móvil solicita una o más ranuras
2.5. SERVICIOS ADICIONALES DE LAS EMPRESAS TELEFÓNICAS35
de tiempo enviando una petición a la estación base. Si la petición llega sin
daño alguno, la estación base anuncia la frecuencia y las ranuras de tiempo
asignadas al móvil para enviar el paquete. Una vez que el paquete llega a la
estación base, se transfiere a Internet mediante una conexión de cable.
2.5
Servicios Adicionales de las Empresas Telefónicas
Los equipos celulares fueron pensados para transmitir voz. Lo primero que
se piensa cuando se habla de teléfonos móviles es en la comunicación vocal,
en comunicación a través de la voz de un punto a otro. Sin embargo, poco a
poco, se fue conociendo cómo las empresas que proveían el servicio de telefonía
celular han ido incorporando servicios adicionales a lo largo del tiempo de vida
de esta tecnología y, muchos de esos servicios se escapan del estricto uso de la
voz para la comunicación. Desde mensajería de texto, melodías personalizadas,
hasta conexión a Internet. En los siguientes apartados se verá con detalle los
servicios que los teléfonos celulares actuales pueden ofrecer.
2.5.1
Servicios Analógicos
En esta categoría ingresan todos los servicios adicionales que no requieren
un equipo con capacidades digitales. Ni siquiera hace falta un teléfono con
pantalla. Desde los viejos equipos Motorola, hasta los primeros modelos de
teléfonos Motorota Startac (la línea 3000), las empresas de telefonía celular
han provisto de servicios adicionales al uso básico de la línea.
Estos servicios funcionaban a través de la red de voz, es decir la red analógica que ya estaba instaurada. Entre ellos, se puede mencionar contestador
automático, alarmas, llamadas en conferencia, y servicios de información que
se proveían (y todavía se proveen) comunicándose a un número particular que
no pertenecía a la red fija de telefonía.
2.5.2
Recepción y Envío de Mensajes de Texto
Este servicio comenzó a funcionar en los años 90 y requería poseer equipos con
la capacidad de recepción de mensajes de texto en la pantalla del teléfono. Por
36
CAPÍTULO 2. EL MUNDO MÓVIL
ello, requieren equipos con pantalla alfanumérica y señal digital. Las empresas
permiten el envío de mensajes a un equipo celular a través de sus sitios web,
a través 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 también como SMS (Short Message System, Sistema de Mensajes
Cortos). El mensaje es enviado al destinatario instantáneamente, 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 días, para ser enviado
en el momento de restauración de la señal.
Con la gran aceptación que tuvo el Sistema de Mensajes Cortos comenzaron a aparecer equipos con la posibilidad, no sólo de recibir mensajes, sino de
emitirlos y así poder enviar mensajes a otros teléfonos, en un principio, entre
dos teléfonos móviles 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 comunicación no se realiza teléfono a
teléfono directamente.
A través de una pasarela, es común la posibilidad de enviar mensajes, no a
otro teléfono, sino a una dirección de e-mail. Estas pasarelas son simplemente
números de destino donde el teléfono envía el mensaje y este equipo receptor
(provisto por el proveedor del servicio) se encarga de redireccionar el mensaje
vía Internet utilizando el protocolo SMTP.
Con el tiempo este servicio se amplió y las empresas comenzaron a interconectar sus redes de mensajería corta y ya prácticamente, es posible enviar y
recibir mensajes cortos desde cualquier empresa proveedora a cualquier otra
dentro del mismo país y, a veces, a otros países.
2.5.3
Servicios de Información
Basados en el Servicio de Mensajería, las empresas proveedoras de la telefonía
celular comenzaron a ofrecer servicios adicionales de información por ese
medio. Por ejemplo, es posible suscribirse a recibir información sobre: noticias,
deportes, cotizaciones financieras, estados bancarios y otra información que
será enviada a todos los equipos celulares suscriptos.
2.5. SERVICIOS ADICIONALES DE LAS EMPRESAS TELEFÓNICAS37
Otra modalidad es el envío de información mediante SMS bajo demanda.
Este servicio permite enviar cierto mensaje a un número predeterminado y
recibir a cambio alguna información de interés o solicitada. Estos servicios
son provistos por las mismas empresas o por terceros con convenios especiales.
También han surgido salas de chat con la posibilidad de enviar y recibir
mensajes a grupos de personas, comunicación con mensajeros instantáneos
(como ser el Microsoft Messenger o el Yahoo! Messenger ) y juegos interactivos
a través del Servicio de Mensajería. Algunos de estos servicios se ofrecen en
forma gratuita [8].
2.5.4
Mensajes Multimedia
Los equipos móviles evolucionan a grandes pasos y debido a esto se pueden ver
equipos con capacidades multimedia. Por eso, se ha desarrollado una extensión
al servicio SMS, llamado MMS (Multimedia Messaging System).
Este sistema de intercambio de mensajes permite, además de texto (ampliado a 900 caracteres), adjuntar cualquier otro tipo de archivo digital, como
ser fotos, imágenes animadas, sonidos o videos. El equipo receptor deberá soportar también esta tecnología y estar correctamente configurado en el equipo.
Esta tecnología generalmente trabaja enviando un mensaje de texto al
teléfono receptor indicando una URL (dirección 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 configurar su equipo para
no recoger automáticamente sus Mensajes Multimedia.
2.5.5
Juegos y Aplicaciones
Es una característica adicional provista por el fabricante del equipo. Gracias
también al gran uso del SMS, los teléfonos comenzaron a ampliar el tamaño
visual de sus pantallas. De esta forma, algunos equipos comenzaron a incluir
algunos pequeños juegos en sus modelos de celulares, como se puede apreciar
en la fig. 2.3 de la pág. 38.
Tampoco las aplicaciones se habían quedado atrás y ya comenzaban a
aparecer en los equipos aplicaciones como calculadoras, agendas, calendarios,
38
CAPÍTULO 2. EL MUNDO MÓVIL
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 veía como un mero aparato comunicacional, sino como una microcomputadora. Comenzaron a aprovecharse capacidades de procesamiento (mínimas,
pero existentes) y, cuando esta capacidad de proceso se junta con la capacidad de conectividad de la red celular, se produce la revolución del software
móvil [8].
2.5.6
Internet Móvil
Internet Móvil 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 tecnología que permite esta navegación 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 páginas web y la red
2.5. SERVICIOS ADICIONALES DE LAS EMPRESAS TELEFÓNICAS39
celular.
Este protocolo tenía una limitación y es que no soportaban páginas HTML
como sí lo soportan los navegadores para equipos estándar de computación,
como Internet Explorer, Netscape u Opera. Los navegadores WAP de los
equipos celulares soportan solamente páginas en formato WML, que es una
versión reducida de HTML y adaptada a las necesidades de contenido de un
teléfono celular.
El Fracaso y la Vuelta de Internet Móvil
El fracaso se debió a algunas razones, entre ellas:
• Los proveedores de contenido no supieron adaptarse a las necesidades
de un navegante móvil. Sólo ofrecían una versión reducida de su mismo
contenido web.
• Las empresas de telefonía móvil facturaron este servicio por tiempo de
aire consumido, lo que claramente era una bomba de tiempo para el
usuario que se encontraba navegando, o intentándolo.
• La experiencia de navegar por un celular ha sido muy frustrante para muchos usuarios. Una vez que se lograba configurar correctamente
el equipo, la navegabilidad de los equipos que, originalmente no estaban preparados para tal fin (como ser ausencia de teclas, pantallas muy
chicas), hicieron que los usuarios dejaran de lado esta tecnología.
• No existieron gran cantidad de equipos con la capacidad de navegador
WAP.
La vuelta de Internet Móvil se debió a la aparición de nuevas tecnologías
que se ofrecen actualmente (como ser GSM, vía GPRS o CDMA2000x ), ahora
es posible tarifar al usuario por información transferida y no por tiempo de
aire, adicionando que los equipos tienen pantallas más grandes y con altas
resoluciones de colores y sistemas de navegación e introducción de texto más
cómodos [8].
Además de esta mejora tecnológica, el mercado ha ido evolucionando y
ya prácticamente todo equipo nuevo tiene navegador WAP y poco a poco,
comenzaron a surgir nuevos servicios WAP útiles para los usuarios, entre ellos:
40
CAPÍTULO 2. EL MUNDO MÓVIL
Clima, Información Geográfica, Guías Telefónicas para Turistas, Mapas de
Calles y otra información que puede ser de suma utilidad para un usuario que
se encuentra fuera del alcance de una PC con conexión a la web.
2.6
2.6.1
WAP
Introducción a WAP
Wireless Application Protocol o WAP (protocolo de aplicaciones inalámbricas)
es un estándar abierto internacional para aplicaciones que utilizan las comunicaciones inalámbricas, por ejemplo acceso a servicios de Internet desde un
teléfono móvil.
Se trata de la especificación de un entorno de aplicación y de un conjunto de
protocolos de comunicaciones para normalizar el modo en que los dispositivos
inalámbricos, se pueden utilizar para acceder a correo electrónico, grupo de
noticias y otro tipo de aplicaciones disponibles desde Internet.
El organismo que se encarga de desarrollar el estándar WAP fue originalmente el WAP Forum, fundado por cuatro empresas del sector de las comunicaciones móviles, 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 definición de diversas normas
relacionadas con las comunicaciones móviles, entre ellas las normas WAP.
La telefonía móvil e Internet se combinaron y ahora se puede tener Internet
en un terminal móvil (teléfono celular) combinar la capacidad de Internet en
un entorno donde el usuario puede moverse y disponer conexión las 24 horas del
día, en cualquier lugar. De esta idea surge WAP, la arquitectura de protocolos
TCP/IP (protocolo de Internet) presenta una serie de dificultades al momento
de trabajar en entornos inalámbricos móviles.
Estos factores unidos al ancho de bandas limitados a la telefonía móvil condicionan a los fabricantes mundiales a constituir el consorcio WAP Forum para
desarrollar una nueva pila de protocolos adecuada a los entornos inalámbricos
con usuarios en movimientos [7].
Aunque WAP fue diseñado para utilizar cualquier tecnología móvil existente, la más utilizada por WAP es GSM. GSM es una tecnología digital de
acceso aéreo que incluye mecanismos de cifrado de comunicación entre terminal
2.6. WAP
41
móvil y la estación base.
2.6.2
Motivación
Los terminales móviles son más potentes y livianos cada vez, permitiendo que
la comunicación sea cada vez más eficaz. Su gran número 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 móviles.
WAP define un entorno de aplicación y una pila de protocolos para aplicaciones y servicios accesibles a través de terminales móviles. Consiste en un
conjunto de especificaciones, definidas por la Open Mobile Alliance / WAP
Forum, que permiten que los desarrolladores diseñen aplicaciones de interconexión para terminales móviles, típicamente teléfonos.
La tecnología 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 diseñar estos servicios para usuarios móviles,
fundamentalmente debidas a las características de los terminales: pantalla más
pequeña que la de un ordenador personal, teclados más 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 comparación con la memoria y procesador de un ordenador
personal típico.
Las redes de telefonía móvil ofrecen también unas prestaciones por lo general menores que los accesos a Internet, si bien con las redes de tercera
generación como UMTS las prestaciones mejoran de manera importante.
2.6.3
Modelo de WAP
El modelo de aplicación WAP como se puede ver en la fig. 2.4 de la pág. 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 programación
familiar, una arquitectura probada y la habilidad de utilizar herramientas
existentes (servidores web, herramientas XML, estándares de Internet) también debe indicarse que se ha intentado optimizar el modelo para un entorno
42
CAPÍTULO 2. EL MUNDO MÓVIL
inalámbrico [7].
Figura 2.4: Modelo Wap.
Como se puede desprender de la fig. 2.5 de la pág. 43, el modelo opera de
la siguiente manera:
• El usuario teclea la URL en su teléfono móvil.
• El agente usuario envía la petición URL a la pasarela WAP mediante el
protocolo WAP.
• La pasarela WAP genera una petición convencional HTTP para la URL
pedida y la envía al servidor web.
• El servidor web procesa la petición. Si es un fichero estático, toma el
fichero y le añade una cabecera HTTP. Si es CGI ( Common Gateway
Interface) u otra aplicación SCRIPT, lanza la aplicación.
• El servidor Web devuelve la marca WML con la cabecera HTTP añadida, o la salida WML del CGI o SCRIPT.
• La pasarela WAP verifica la cabecera HTTP y el contenido WML y la
codifica a una forma binaria. Crea la respuesta WAP conteniendo el
WML y lo envía 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. Además se dispone
de un Micro-navegador en el terminal móvil que hace de interfaz con el usuario.
WAP define un conjunto de componentes estándares que permiten la comunicación entre el cliente móvil y los servidores que deben incluir:
• Modelo de nomenclatura: se utilizan los URLs estándar.
• Representación del contenido: contenido consistente con el WWW.
• Protocolo estándar: permiten la comunicación entre el navegador del
dispositivo inalámbrico y el servidor.
WAP utiliza la tecnología Proxy para conectar el dominio inalámbrico a
la Internet tradicional. Entre el terminal móvil 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 comunicación [7].
44
CAPÍTULO 2. EL MUNDO MÓVIL
Entorno de Programación WAP
El cliente WAP se comunica con dos servidores en la red inalámbrica. La
pasarela WAP traduce las peticiones WAP en peticiones WWW y también
en dirección 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
sólo proporciona contenido WWW (HTML). Las marcas WML son codificadas
WBXML antes de enviarlas al móvil WAP.
El servidor de Aplicación de Telefonía Inalámbrica WTA (Wirelees Telephony Application) es un ejemplo de servidor que responde peticiones directamente del cliente WAP sin pasar por ningún tipo de intermediarios.
Se utiliza fundamentalmente para aplicaciones propias del entorno inalámbrico.
La Capa de Aplicación WAE
La capa de aplicación (Wireless Application Enviroment) es la capa de propósito general basada en una combinación de Word Wide Web (WWW) y las
tecnologías de telefonía móvil. 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 inalámbricas de manera eficiente 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 móviles. , (WBML) es la versión codificada que se entrega a los dispositivos móviles para reducir el volumen
del tráfico al teléfono móvil.
• WMLScript, un lenguaje de script de baja carga, similar a Javascript.
• Wireless Telephony Application (WTA-WTAI) servicios de telefonía e
interfaces de programación.
• Formatos de contenidos, un conjunto de formatos de datos bien definidos.
2.6. WAP
45
Figura 2.6: Pilas de Protocolos TCP/IP y WAP.
2.6.4
Tecnología
En la versión 1 de WAP, definida en 1999, el lenguaje de presentación 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 fig. 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 móvil que esté usando el terminal. WAP 1 además
define la interfaz de acceso de las aplicaciones a las funciones de telefonía del
terminal con WTAI (Wireless Telephony Application Interface), y también 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 comunicación entre un terminal WAP y un servidor de contenidos WAP
residente en Internet.
46
CAPÍTULO 2. EL MUNDO MÓVIL
WAP ha sido sujeto a diversas críticas en su implementación, como ser el
bajo soporte de gráficos en los terminales móviles, las diferencias de implantación en terminales móviles de distintos fabricantes y un problema muy grave
en cuanto a seguridad debido a que la capa WTLS no es robusta y además
por no ser compatibles con los mecanismos de seguridad que brinda Internet.
La nueva versión de WAP, WAP 2.0, está presente en los teléfonos móviles
de nueva generación (a partir del 2004). Esta versión es una reingeniería de
WAP que utiliza XHTML-MP (XHTML Mobile Profile), un subconjunto de
XHTML que incluye el XHTML básico, y WCSS (WAP CSS), un subconjunto
de CSS más ciertas extensiones específicas para móviles, como lenguajes para
la presentación de contenidos mejorando, por ejemplo el soporte de los gráficos.
De esta forma se consigue que el diseño de contenidos con WAP 2.0 sea muy
similar al diseño de contenidos para la WWW para navegadores en dispositivos
no móviles.
En cuanto a los protocolos usados, en la capa de transporte se usa TCP y
en la de aplicación, HTTP. Así pues, WAP 2.0 ha adoptado los protocolos de
Internet. WAP 2.0 además especifica opciones tanto en TCP como en HTTP
para mejorar las prestaciones de dichos protocolos sobre redes de comunicaciones móviles. 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 próxima generación de un conjunto de especificaciones que a
comparación de versiones previas, marca el actual esfuerzo de WAP Forum
para adoptar los más recientes protocolos y estándares de Internet. WAP 2.0
optimiza el uso de grandes anchos de banda y conexiones basadas en paquetes
en redes inalámbricas. Mientras utiliza y soporta el incremento en las capacidades de los últimos dispositivos inalámbricos, también provee compatibilidad
hacia atrás a contenidos WAP existentes, aplicaciones y servicios que utilizan
versiones previas de WAP.
Algunas características de WAP 2.0:
• Soporte de pila de protocolo: Además de la pila WAP introducida,
2.6. WAP
47
WAP 2.0 añade soporte y servicios basados en la pila común de Internet
incluyendo soporte para TCP, TLS y HTTP. En comparación con ambas
pilas de protocolo, WAP 2.0 provee un modelo de conectividad en un
amplio rango de redes y portadoras inalámbricas.
• Ambiente de aplicación WAP: Normalmente visto como “Navegador WAP”, el ambiente de aplicación de WAP 2.0 ha evolucionado para
aceptar el lenguaje de marca del navegador de Internet como estándar
de desarrollo. Esto ha llevado a la definición 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 número de características disponibles para desarrolladores,
operadores y usuarios.
Modelo de Programación WAP
El modelo de programación WAP está estrechamente alineado con el modelo
de programación Web; ver fig. 2.6 de la pág. 45, usa el modelo Pull (donde el
cliente requiere contenido desde un servidor). De igual modo, WAP 2.0 extiende la arquitectura web añadiendo soporte a telefonía 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
están basados en gran parte en protocolos de comunicación de Internet, y
este comunicado con el servidor origen usando los protocolos estándares de
Internet.
WAP 2.0 no requiere la utilización del WAP proxy puesto que la comunicación 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 comunicación y pueden ofrecer incrementos en los servicios móviles; ver
fig. 2.8 de la pág. 48. Además, un servidor proxy es necesario para ofrecer
funcionalidad Push.
48
CAPÍTULO 2. EL MUNDO MÓVIL
Figura 2.7: Modelo de Programación Wap.
Figura 2.8: Modelo Proxy para WAP 2.0.
2.6. WAP
49
Nuevas Características Añadidas y Servicios Mejorados
Además del ambiente de aplicación y el incremento de la capacidad del microbrowser, WAP 2.0 también soporta otras características para mejorar la experiencia del usuario. Estas características amplían las capacidades de los
dispositivos inalámbricos y mejoran la habilidad para entregar servicios y aplicaciones útiles [9]. Algunas de las características adicionales de WAP 2.0 son
las siguientes:
• WAP push: Este servicio permite enviar contenido a dispositivos mediante aplicaciones basadas en servidor vía 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 envían información a sus usuarios, como ser mensajes, precio de stock, alertas
actulizadas de tráfico.
• User Agent Profile (UAProf ): Este servicio provee la descripción
de las capacidades de los clientes y las preferencias de los usuarios a
un servidor de aplicación. Mejorado por WAP 2.0, esto está basado en
la combinación Capabilities / Preference Profiles (CC/PP) trabajo de la
W3C, UAProf soporta el modelo de transacción cliente-servidor enviando
la información del usuario a servidores con la petición. Esta información
permite a los servidores adaptar su contenido y en consecuencia realizar
la preparación de la respuesta.
• Data Synchronization: En un enfoque que ayuda a asegurar una solución común de marco de trabajo, el WAP Forum buscó una solución para
la sincronización de datos. Como resultado de ello, WAP 2.0 reconoce
la labor de la SyncML mediante la adopción del lenguaje SyncML como su opción para la solución de sincronización 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 solución de envio de mensajes ricas
en características. MMS provee características y funcionalidades que
permiten repartir tipos variados de contenido. Dependiendo del modelo
de servicio, MMS permite un paradigma de entrega rápido (al igual que
SMS) o un método de almacén y reenvío (parecido al correo electrónico)
o debería permitir ambos modos para operar. Esta flexibilidad permite
a operadores ajustar el resultado a la experiencia del usuario.
Capítulo 3
Aplicaciones Móviles
3.1
Introducción
Los dispositivos de computación inalámbrica han crecido rápidamente, requeriendo aplicaciones de software cada vez más potentes que puedan manejar
esta nueva realidad. Los usuarios desean que las aplicaciones que corren en
sus dispositivos móviles 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 eficientemente el problema del roaming.
El rango de dispositivos móviles va desde dispositivos dedicados a tareas
específicas, como los teléfonos celulares, hasta aquellos dispositivos de propósito general, como notebooks. Cada uno de ellos presenta diferentes conjuntos
de desafíos para el diseño de aplicaciones móviles.
Algunos de estos desafíos compartidos por la mayoría de los dispositivos
móviles incluyen:
• La ubicación física del dispositivo y la configuración pueden cambiar en
cualquier momento a medida que el dispositivo está conectado o desconectado de la red o se mueve entre dos puntos de conexión. La arquitectura de aplicación móvil debe soportar una operación consistente
operando tanto online como offline y proveer una conectividad continua
mientas el dispositivo se mueve entre puntos de conexión.
51
52
CAPÍTULO 3. APLICACIONES MÓVILES
• Los dispositivos que se alimentan mediante el uso de baterías pueden
operar por un tiempo limitado sin recargar o reemplazar las mismas. La
arquitectura de una aplicación móvil debe se diseñada para administrar
esa energía limitada de las baterías, mediante el uso de estrategias que
prologuen la vida útil al reducir el consumo sin sacrificar el rendimiento
del sistema.
Una arquitectura de aplicaciones móviles debe proveer soporte para un amplio rango de dispositivos. Debido a que los dispositivos pequeños de propósito
específico, tales como teléfonos celulares, poseen limitaciones de recursos como el tamaño reducido de sus pantallas, limitado almacenamiento y poder de
cómputo [21].
3.2
Requerimientos Para Una Arquitectura de Aplicaciones Móviles
Una aplicación diseñada para ser usada en un dispositivo móvil debe cumplir
con ciertos requerimientos, algunos son propios del ambiente móvil y otros
pueden ser requerimientos de cualquier tipo de aplicación. A continuación se
presentan los más relevantes:
• Operación consistente tanto online como offline: En varias arquitecturas, los datos son almacenados en un sistema compartido accesible
a través de la red, en forma de documentos, registros de datos o archivos
binarios, donde se tiene un acceso coordinado a una copia de la información. Una aplicación móvil debe ser diseñada de forma de que los
usuarios puedan acceder a los datos sin importar si lo hacen en forma
online o en forma offline. Cuando se trabaja offline, el usuario percibe
que la información compartida está disponible para lectura y escritura.
Cuando la conectividad regresa, los cambios en la información local son
integrados a la copia de red y viceversa.
• Conectividad continua: Una aplicación diseñada 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 conexión con la red deben poder ser manejados satisfactoriamente. Así mismo este agente o servicio Proxy debe poder
3.2. ARQUITECTURA DE APLICACIONES MÓVILES
53
seleccionar la red óptima de las disponibles en ese momento, y manejar las tareas propias de la comunicación como autentificación segura o
autorización y direccionamiento lógico.
• Clientes que soporten multiplataformas: Una aplicación móvil debe al menos ajustar su interacción y comportamiento al dispositivo en
el que corre, como por ejemplo tipo de entrada y salida, recursos disponibles y nivel de performance.
• Administración de recursos: Un recurso como la energía, el ancho
de banda o el espacio de almacenamiento puede ser consumido y existe
en una cantidad finita. La administración de recursos debe permitir el
monitoreo de atributos como cantidad o tasa de uso, y soportar notificaciones basadas en disparadores predefinidos por el usuario.
• Administración del contexto: Contexto es cualquier información que
puede se usada para caracterizar la situación de una entidad. Donde
una entidad es una persona, lugar u objeto que es relevante para la
interacción entre un usuario y una aplicación, incluyendo al usuario y
la aplicación. La administración del contexto debe permitir el monitoreo de atributos como ubicación actual o tipo de dispositivo, y proveer
notificación de cambios en el mismo.
• Codificación: La codificación involucra la modificación de los datos
y protocolo en función de los requerimientos del contexto y recursos
disponibles. Ejemplos de codificación son la encriptación, compresión y
transcodificación. Una implementación de la capacidad de codificación
permitirá la enumeración de los encoders y decoders disponibles. Luego
con ésta información disponible junto con la capacidad de administración
del contexto, proveer la habilidad de negociar el uso de uno u otro método
de codificación.
• Almacenamiento duradero: La capacidad de manejar un almacenamiento duradero permite la persistencia de datos de configuración o
información estática.
• Seguridad: Para evitar las consecuencias de ataques maliciosos, aplicaciones con diseños pobres, y errores inadvertidos de usuarios, se deben
tomar ciertas medidas de seguridad como ser: Sistemas y usuarios deben
ser autenticados, autentificación de sistemas, usuarios y acciones deben
ser autorizados, y acciones e interacciones deben ser auditadas.
54
CAPÍTULO 3. APLICACIONES MÓVILES
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 móvil, y relacionada especialmente con aspecto
de hardware.
3.3
Arquitectura de Portal Para Aplicaciones Móviles
La función primaria de un portal es la de agregar e integrar diversas y distribuidas fuentes de información, y presentar el resultado al usuario en una vista
simple concisa y pertinente a través de un navegador Web o Web Browser.
Un portal es típicamente dirigido a un grupo específico o tipo de usuario.
Por ejemplo en la Intranet de una compañía, el sector de atención al cliente
puede acceder a información relacionada con clientes (promociones vigentes,
descuentos, etc.), pero no puede acceder a información financiera, ésta estaría
sólo autorizada para los integrantes del sector de finanzas [21].
Los contenidos que puede tener un portal son:
• Datos relativamente estáticos, como banners, gráficos y estructura general.
• Contenido dinámico, información que cambia con cierta frecuencia, el
caso de las promociones vigentes para el sector de atención al cliente
estaría dentro de este grupo.
• Información nueva o trascendente, como notificaciones o información
incremental. Por ejemplo una notificación 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 Información: Las fuentes de información proveen de datos al
portal. Las fuentes de información incluyen bases de datos, aplicaciones
u otros portales externos al sistema.
• Funciones del Portal: Las funciones de un portal son básicamente las de
agregar y componer la información para luego ser entrada al usuario.
3.3. PORTAL PARA APLICACIONES MÓVILES
55
• Funciones Independientes: Son tecnologías 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
través de Internet, un protocolo Proxy soporta la comunicación con el
usuario y con el portal HTTP y HTML comúnmente mejorado del lado
del cliente con el uso de lenguajes de scripting y/o código ubicado en el
browser como ActiveX o controles Java.
• Servidor de Presentación: Crea e integra vistas de contenido a través de
la interacción con otros componentes.
• Servidor de Aplicación: Ejecuta cualquier código que sea requerido dinámicamente para extraer y reformatear información desde sistema no
basados en Web.
• Administración de Contenido, búsqueda e indexación, y colaboración.
• Servicios de Personalización: Disponible para que cada usuario pueda
configurar la vista y el contenido que quiere tener cada vez que accede
al portal.
• Seguridad: Un requerimiento para toda arquitectura de aplicaciones
móviles, es el de asegurar la integridad de información sensible en sitios remotos.
Un portal Web es completamente dependiente de la conexión de red, ya
que es una arquitectura centrada en el servidor y la conexión de red se hace
un recurso imprescindible.
Una solución simple para aplicaciones móviles es la de permitir el acceso
offline a sitios Web, bases de datos y archivos que han sido previamente descargados en el móvil. El usuario interactúa con los mismos y una vez que la
conexión se reestablece, las copias locales y remotas se sincronican. Esta solución es válida para aquellos portales simples, pero cuando las fuentes de datos
vienen asociadas con otros sistemas o directamente no caben en el dispositivo
móvil, no podrá ser aplicada.
Entonces, sin conexión de red, la creación de contenido dinámico desde
un portal y sus sistemas back-end en tiempo de ejecución es esencialmente
56
CAPÍTULO 3. APLICACIONES MÓVILES
imposible. Sin embargo existen algunas aproximaciones que pueden ser usadas
para proveer una vista offline del contenido:
• Prealmacenado del contenido generado en el portal.
• Replicación en el sistema móvil de los datos y el código 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 interacción del usuario con los datos,
y la frecuencia necesaria de actualización de los mismos.
A continuación se presentará de que forma una arquitectura de portal móvil
puede cubrir los requerimientos planteados para caracterizar una aplicación
móvil:
• Clientes que soporten multiplataformas: Los portales usualmente soportan el acceso desde diferentes plataformas, manejan diferentes
caracterizaciones de dispositivos, y cualquier transcodificación de contenido requerido. Como el contenido comúnmente es dinámico y el tipo de
dispositivo del cliente impredecible, estas actividades ocurren en tiempo
de ejecución. Una aplicación cliente que soporte movilidad no necesita soportar transcodificación dinámica porque el tipo de dispositivo del
cliente es estático. La aplicación no necesita manejar cambios dinámicos en la personalización del dispositivo offline, ya que se supone que el
mismo será usado por una única persona.
• Capacidad de trabajar offline:
— Prealmacenado de Contenido: involucra el prealmacenado del contenido provisto por un portal en respuesta a un requerimiento hecho
por un cliente a través de una URL, como una página Web. El código que genera el contenido no es prealmacenado. Por ejemplo un
link (enlace) puede ser referencia a un script JSP o ASP, el Server
de aplicación corre este script y devuelve al cliente streams HTML.
Estos HTML son los que están prealmacenados, no los scripts. Navegar el portal, siguiendo cada link y almacenar la salida en el
sistema local para luego disponer del mismo offline, es un mecanismo completamente ineficiente. Además todas la páginas 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 configuración local que especifique
las páginas de interés o provea un criterio de selección.
— Replicación de Código: permite que el contenido del portal sea más
dinámico. El portal puede ejecutar código, por ejemplo JAVA, en
el proceso de servir el contenido al usuario o en la recolección y
manejo de datos de otros sistemas. El código es replicado desde el
servidor al cliente. Alguna replicación involucra componentes de la
interfase del usuario, la mayoría esta involucrado con la colección,
manipulación y almacenamiento de datos.
— Replicación 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
implementación se vuelve más simple, sin embargo la implementación que permite esquemas de múltiples copias que pueden ser
actualizadas independientemente, se vuelve más compleja.
— Conectividad Continua: Dos áreas están incluidas dentro de conectividad continua, estas son administración de conectividad de red
y la seguridad desde el punto de vista del usuario. Por ejemplo el
usuario no tendrá físicamente que re-autenticarse cada vez que el
sistema se reconecta. La conectividad continua puede ser soportada
por emulación, la cual provee la apariencia de que el recurso de red
se encuentra disponible.
Una posible arquitectura de portal para aplicaciones móviles es la mostrada
en la fig.
3.1 de la pág. 58, la cual refleja varios tipos de modificaciones: agregado
de nuevos componentes (a los habituales de un portal no móvil).
3.4
Arquitectura de Bases de Datos Para Aplicaciones Móviles
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 físicamente a la red. Los datos se presentan en la máquina 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
CAPÍTULO 3. APLICACIONES MÓVILES
Figura 3.1: Arquitectura de un Portal Móvil.
ver o trabajar con los datos sin una conexión a la red. Todo procesamiento
tiene lugar en el servidor, construido específicamente para tal propósito.
Se puede afirmar que una base de datos es un archivo que contiene varios
registros de datos. En un ambiente cliente / servidor tradicional, más de
un usuario puede utilizar la misma base de datos simultáneamente. RDBMS
(Sistemas Manegadores de Bases de Datos Relacionales) hace esto posible a
través del uso de mecanismo interno de locking que previenen que más de un
usuario modifique un registro al mismo tiempo [21].
Una arquitectura de base de datos preparada para un ambiente móvil,
permite a los usuarios acceder a la información en cualquier momento y desde
cualquier lugar.
En un ambiente móvil, copias de los datos pueden existir en distintos
sistemas clientes. Dado que estos sistemas clientes no están continuamente
conectados a la base de datos central, el RDBMS de dicha base no es capaz
de prevenir cambios simultáneos a los datos por más de un usuario. Por
otra parte, los datos locales en cada sistema cliente deben ser periódicamente
sincronizados con los datos de la base master que reside en el servidor.
Algunos de los desafíos al diseñar 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 estarán disponibles mientras el sistema este desconectado, esto introducirá mas dudas sobre la valides de los datos.
• La resolución de conflictos se volverán más desafiantes y ya no estarán
bajo el control del RDBMS.
• El poder de procesamiento local en los clientes puede ser limitado en
comparación al poder de procesamiento disponible en el servidor.
• Los datos propietarios, deben mantenerse seguros en las ubicaciones remotas.
Un usuario móvil 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
replicación 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 aplicación 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
offline 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 decisión resultante pueda ser actualizada cuando los datos vuelvan a
estar disponibles online nuevamente.
Una arquitectura de base de datos para aplicaciones móviles debe garantizar que las transacciones serán trasmitidas confiablemente. Durante una
transacción normal, una conexión 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 notificación sobre si la
transferencia fue realizada con éxito o no es enviada al que la inició. La falla
o el éxito de la transacción, 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 transacción será trasmitida al servidor inmediatamente.
60
CAPÍTULO 3. APLICACIONES MÓVILES
Si la conexión se pierde durante la transmisión, la transacción será encolada
para ser transmitida cuando la conexión sea reestablecida. Mientras tanto el
usuario debe poder ser capaz de hacer referencia a la actualización aunque la
transmisión no se haya completado.
3.5
Aplicaciones Multiplataforma
Multiplataforma es un término usado para referirse a los programas, sistemas
operativos, lenguajes de programación, u otra clase de software, que puedan
funcionar en diversas plataformas. Por ejemplo, una aplicación multiplataforma podría ejecutarse en Windows en un procesador x86, en GNU/Linux en
un procesador x86, y en Mac OS X en un x86, sin nungún tipo de problemas.
Una plataforma es una combinación de hardware y software usada para
ejecutar aplicaciones, en su forma más simple consiste únicamente de un sistema operativo, una arquitectura, o una combinación de ambos. La plataforma
más 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 características de una plataforma particular; bien sea el hardware, sistema operativo, o
máquina virtual en que se ejecuta. La plataforma Java es una máquina virtual
multiplataforma, tal vez la más 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 años ha sido conseguir programas portables, capaces de ser ejecutados en
diversas plataformas (Macintosh,PC, Unix, Windows), logrando la compatibilidad total.
La aparición del lenguaje Java da la primera solución satisfactoria al problema de la compatibilidad. La idea consiste en crear máquinas virtuales
idénticas en cada una de las diferentes plataformas y encargarles a ellas la
ejecución de programas, obteniendo así la compatibilidad total.
Con el desarrollo de estas máquinas virtuales anteriormente mencionadas
3.5. APLICACIONES MULTIPLATAFORMA
61
se puede lograr que el mismo código binario ejecutable se pueda usar en todos
los sistemas compatibles con el software Java. Además la penetración de Java
en Internet, como lenguaje de acompañamiento al HTML, ha sido todo un
éxito.
Capítulo 4
Java
4.1
Introduccón al Lenguaje
Java es un lenguaje orientado a objetos. Esto significa que posee ciertas
características estándares en los lenguajes OO:
• Objetos.
• Clases.
• Métodos.
• Subclases.
• Herencia simple.
• Enlace dinámico.
• 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 parecía que era el lenguaje de programación perfecto, combinando
los mejores elementos de los lenguajes de bajo y alto nivel en un lenguaje de
programación que se ajustaba a la arquitectura del ordenador y que gustaba
a los programadores.
63
64
CAPÍTULO 4. JAVA
Sin embargo, el lenguaje C tenía limitaciones, al igual que los lenguajes de
programación anteriores. Cuando los programas crecían, los programas C se
hacían inmanejables porque no había una forma fácil de acortarlo. Esto quiere
decir que el código de la primera línea de un programa largo podría interferir
con el código de la última línea y el programador tendría que recordar todo el
código mientras programaba.
La programación orientada a objetos se hizo popular por ser capaz de
dividir programas largos en unidades semi-autónomas. El lema de la programación orientada a objetos es “divide y vencerás”.
Dicho en otras palabras, un programa se puede dividir en partes fácilmente
identificables.
Por ejemplo, se supone que para mantener fresca la comida se utiliza un
sistema complejo.
Debería comprobar la temperatura de la comida usando un termómetro y
cuando la temperatura fuera lo suficientemente alta, se activaría un interruptor
que arrancara el compresor e hiciera funcionar las válvulas para que el frío
circulara; luego arrancaría 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 automáticas, 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 frigorífico.
De esta forma es como funcionan los objetos, ocultan los detalles de la
programación al resto del programa, reduciendo todas las interdependencias
que aparecen en un programa C e inicializando una interfaz bien definida y
controlable que mantiene la conexión entre el objeto y el resto del código.
Resumiendo se puede decir que la programación orientada a objetos consiste en la división de un problema en diferentes partes (objetos) donde:
• Cada objeto posee una funcionalidad específica.
• Los objetos interactúan entre sí enviando y recibiendo mensajes; ver fig.
4.1 de la pág.65.
La tarea del programador es coordinar las acciones de los objetos y la
comunicación entre los mismos.
4.1. INTRODUCCÓN AL LENGUAJE
65
Figura 4.1: Mecanismo de Mensajes
Para programar orientado a objetos es necesario primero diseñar un conjunto de clases. La claridad, eficiencia y mantenibilidad del programa resultante dependerá principalmente de la calidad del diseño de clases. Un buen diseño
de clases significará una gran economía en tiempo de desarrollo y mantención.
Lamentablemente se necesita mucha habilidad y experiencia para lograr
diseños de clases de calidad. Un mal diseño de clases puede llevar a programas
OO de peor calidad y de más 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 aplicación [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 más fácil de usar que una biblioteca de
procedimientos, incluso para programadores sin experiencia en orientación a
objetos. Esto se debe a que las clases ofrecen mecanismos de abstracción más
eficaces que los procedimientos.
4.1.1
Bibliotecas de Clases Estándares de Java
Toda implementación de Java debe tener las siguientes bibliotecas de clases:
• Manejo de archivos.
• Comunicación de datos.
• Acceso a la red Internet..
• Acceso a bases de datos.
66
CAPÍTULO 4. JAVA
• Interfaces gráficas.
La interfaz de programación de estas clases es estándar, 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 están presentes las mismas
bibliotecas estándares.
A nivel del código compilado: el código intermedio que genera el compilador
es el mismo para todas las plataformas. Lo que cambia es el intérprete del
código intermedio, la MVJ (Máquina Virtual Java).
Máquina Virtual Java
Es un programa (software) que maneja la interacción entre las aplicaciones
Java y el Sistema operativo y hardware subyacentes.
Este programa interpreta los bytecodes generados por el compilador de
Java durante la ejecución de un programa Java.
El proceso de compilación y ejecución se pueden observar en la fig. 4.2 de
la pág 67.
4.1. INTRODUCCÓN AL LENGUAJE
67
Figura 4.2: Proceso Compilación y Ejecución
4.1.3
Características 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 compilación (al igual que
C). En una asignación entre punteros el compilador verifica que los
tipos sean compatibles.
— Java realiza chequeo de tipos durante la ejecución (C y C++ no
hacen). Cuando un programa usa un cast para acceder a un objeto
como si fuese de un tipo específico, se verifica durante la ejecución
que el objeto en cuestión sea compatible con el cast que se le aplica.
Si el objeto no es compatible, entonces se levanta una excepción
informando al programador la línea en donde está el error.
— Java posee un recolector de basuras que administra automáticamente la memoria. La MVJ para limpiar o reasignar memoria se lo
denomina “Garbage Collector”.
• Flexibilidad
Java combina flexibilidad, robustez y legibilidad gracias a una mezcla de
chequeo de tipos durante la compilación y durante la ejecución. En Java se
68
CAPÍTULO 4. JAVA
pueden tener punteros a objetos de un tipo específico y también se pueden
tener punteros a objetos de cualquier tipo. Estos punteros se pueden convertir
a punteros de un tipo específico aplicando un cast.
El programador usa entonces punteros de tipo específico en la mayoría de
los casos con el fin de ganar legibilidad y en unos pocos casos usa punteros a
tipos desconocidos cuando necesita tener flexibilidad.
• Administración Automática 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.
Además 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 líneas. Sin embargo, es difícil
hacerlo en un programa de 10000 líneas. Y se puede postular que es imposible
liberar correctamente la memoria en un programa de 100000 líneas.
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 BÁSICOS
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(“Simulación de Redes”);
menus.setVisible(true);
}
}
Aparece una clase que contiene el programa principal Simu (aquel que
contiene la función main()) y algunas clases de usuario (las específicas de
la aplicación que se está desarrollando) que son utilizadas por el programa
principal. La aplicación se ejecuta por medio del nombre de la clase que
contiene la función main(). Las clases de Java se agrupan en packages, que
son librerías de clases. Si las clases no se definen como pertenecientes a un
package, se utiliza un package por defecto (default) que es el directorio activo.
4.3
4.3.1
Conceptos Básicos
Clases
Una clase es una plantilla desde la que se pueden crear objetos. La definición
de una clase incluye especificaciones formales para la clase y cualquier dato y
métodos incluidos en ella. La programación orientada a objetos se basa en la
programación de clases [2]. Un programa se construye a partir de un conjunto
de clases.
Una vez definida e implementada una clase, es posible declarar elementos
de esta clase. Los elementos declarados de una clase se denominan objetos de
70
CAPÍTULO 4. JAVA
la clase. De una única clase se pueden declarar o crear numerosos objetos. La
clase es lo genérico: es el patrón o modelo para crear objetos.
Cada objeto tiene sus propias copias de las variables miembro, con sus
propios valores, en general distintos de los demás 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 programación orientada a objetos que
se ha definido formalmente. Utilizando la herencia, se puede crear una nueva
clase a partir de otra, y la nueva heredará todos los métodos y miembros de
datos de la primera.
La clase nueva se llama subclase y la clase original, clase base o superclase.
La idea es añadir lo que se quiera a la nueva clase para darle más funcionalidad
que a la clase base.
La herencia es un tema importante en Java, ya que se puede usar la gran
librería de clases disponible, derivando de ellas nuestras clases propias.
En Java, a diferencia de otros lenguajes orientados a objetos, una clase sólo
puede derivar de una única clase, con lo cual no es posible realizar herencia
múltiple en base a clases. Sin embargo es posible “simular” la herencia múltiple
en base a las interfaces.
4.3.3
Interfaces
Una interfaz es una clase abstracta que define métodos abstractos y constantes,
pero no implementa los metodos. La clase que implemeta una interfaz hereda
4.4. VARIABLES DE JAVA
71
los métodos y debe implementarlos, es decir se forma un contrato entre la
Interfaz y la clase que implementa la Interfaz.
Una clase puede “implementar” más de una interface y una interface puede
ser implementada por clases que no se encuentran relacionadas.
4.3.4
Package
Un package es una agrupación de clases. Existen una serie de packages incluidos en el lenguaje.
Además 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 finalidades:
1. Para agrupar clases relacionadas.
2. Para evitar conflictos de nombres. En caso de conflicto de nombres
entre clases importadas, el compilador obliga a cualificar en el código 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 Diseño 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 identificador que representa una palabra de memoria que contiene información. El tipo de información almacenado en una
variable sólo puede ser del tipo con que se declaró esa variable. Los diferentes
72
CAPÍTULO 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: Están definidas 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 información más compleja: arrays u objetos de una determinada
clase. Una referencia a un objeto es la dirección de un área en memoria
destinada a representar ese objeto. El área de memoria se solicita con
el operador new. Las variables de referencia también es descripta como
una referencia a una clase.
Por ejemplo si se define: 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 definen en una clase, fuera de cualquier método; pueden ser tipos primitivos o referencias. Son también
llamadas atributos.
• Variables locales: Se definen dentro de un método o más en general
dentro de cualquier bloque entre llaves {}. Se crean en el interior del
bloque y se destruyen al finalizar dicho bloque. Pueden ser también tipos
primitivos o referencias.
En la Tabla 4.1 de la pág. 72 se muestran las dos grandes categorías de
tipos para las variables en Java:
Tipos Primitivos
int, short, byte, long
char, boolean
float, double
Referencias a Objetos
Strings
Arreglos
otros objetos
Tabla 4.1: Categorías de Variables.
4.4. VARIABLES DE JAVA
73
En la Tabla 4.2de la pág. 73 se indica para cada tipo primitivo el número
de bits que se emplea en su representación y el rango de valores que se puede
almacenar en las variables de estos tipos.
Tipo
int
short
byte
long
boolean
char
float
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, métodos.
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 inicialización:
• Integrales (byte, short, int, long): Se inicializan en “0”.
• Flotantes (float, 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 ejecución de un aplicación.
74
CAPÍTULO 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 declaración de un método de clase:
public static void leerURL().
4.5
4.5.1
Operadores del Lenguaje Java
Operadores Aritméticos
Son operadores binarios (requieren siempre dos operandos) que realizan las
operaciones aritméticas habituales: suma (+), resta (-), multiplicación (*),
división (/) y resto de la división (%).
4.5.2
Operadores de Asignación
Los operadores de asignación permiten asignar un valor determinado a una
variable. El operador de asignación por excelencia es el operador igual (=).
La forma general de las sentencias de asignación con este operador es:
variable = expression;
Java dispone de otros operadores de asignación. Se trata de versiones
abreviadas del operador (=) que realizan operaciones “acumulativas” sobre
una variable.
La siguiente Tabla 4.3 de la pág. 75, muestra estos operadores y su equivalencia con el uso del operador igual (=).
4.5. OPERADORES DEL LENGUAJE JAVA
Operador
+=
-=
=*
=/
%=
Utilización
op1 + = op2
op1 - = op2
op1 * = op2
op1 / = op2
op1% = op2
75
ExpresiónEquivalente
op1 = op1 + op2
op1 = op1 - op2
op1 = op1 * op2
op1 = op1 / op2
op1 = op1 % op2
Tabla 4.3: Operadores de asignación.
4.5.3
Operadores Unarios
Los operadores unarios sirven para mantener o cambiar el signo de una variable, constante o expresión numérica. Ellos son el más (+) y menos (-) Su uso
en Java es el estándar 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 según 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
CAPÍTULO 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 expresión
en la que aparece.
• Después de la variable de la forma “++i”. En este caso primero se utiliza
la variable en la expresión (con el valor anterior) y luego se incrementa.
En muchas casos estos operadores se utilizan para incrementar una variable
fuera de una expresión. En este caso ambos operadores son equivalente. Si
se utilizan en una expresión más 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 relación de menor o mayor. El resultado de estos operadores
es siempre un valor boolean (true o false) según se cumpla o no la relación
considerada. La siguiente Tabla 4.4 de la pág. 76 muestra los operadores
relacionales de Java.
Operador
>
>=
<
<=
==
! =
Utilización
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 Concatenación de Caracteres
4.6. ESTRUCTURAS DE PROGRAMACIÓN
77
El operador más (+) también 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 sería:
“Mensaje : Datos ingresados correctamente”.
4.6
Estructuras de Programación
Las estructuras de programación o estructuras de control permiten tomar decisiones y realizar un proceso repetidas veces. Son los denominados bifurcaciones y bucles. En la mayoría de los lenguajes de programación, este tipo de
estructuras son comunes en cuanto a concepto, aunque su sintaxis varía de un
lenguaje a otro. La sintaxis de Java coincide prácticamente con la utilizada
en C/C++, lo que hace que para un programador de C/C++ no suponga
ninguna dificultad adicional.
4.6.1
Sentencias o Expresiones
Una expresión 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 expresión que acaba en punto y coma (;). Se permite
incluir varias sentencias en una línea, aunque lo habitual es utilizar una línea
para cada sentencia. A continuación se muestra un ejemplo de una línea
compuesta de tres sentencias:
i = 0; j = 5; x = i + j;
4.6.2
Comentarios
Existen dos formas diferentes de introducir comentarios entre el código 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
CAPÍTULO 4. JAVA
útiles para poder entender el código utilizado, facilitando de ese modo futuras
revisiones y correcciones. Además permite que cualquier persona distinta al
programador original pueda comprender el código escrito de una forma más
rápida. Se recomienda acostumbrarse a comentar el código desarrollado. De
esta forma se simplifica también la tarea de estudio y revisión posteriores.
Java interpreta que todo lo que aparece a la derecha de dos barras “//
” en una línea cualquiera del código es un comentario del programador y no
lo tiene en cuenta. El comentario puede empezar al comienzo de la línea o
a continuación de una instrucción que debe ser ejecutada. La segunda forma
de incluir comentarios consiste en escribir el texto entre los símbolos “ /* */
”. Este segundo método es válido para comentar más de una línea de código.
Por ejemplo:
// Esta línea es un comentario de una sola línea
int a=1; // Comentario a la derecha de una sentencia
/* Este tipo de comentarios es para comentar más de una sóla línea, sólo
requiere modificar el comienzo y el final. */
En Java existe además una forma especial de introducir los comentarios
(utilizando /***/ más algunos caracteres especiales) que permite generar automáticamente la documentación 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 automática la información de forma similar a la presentada en la propia documentación del JDK. La sintaxis de estos
comentarios y la forma de utilizar el programa javadoc.exe se puede encontrar
en la información que viene con el JDK.
4.6.3
Bifurcaciones
Las bifurcaciones permiten ejecutar una de entre varias acciones en función
del valor de una expresión lógica o relacional. Se tratan de estructuras muy
importantes ya que son las encargadas de controlar el flujo de ejecución de un
programa. Se exponen dos variantes del de tipo if.
4.6. ESTRUCTURAS DE PROGRAMACIÓN
79
Bifurcación if
Esta estructura permite ejecutar un conjunto de sentencias en función del valor
que tenga la expresión de comparación. Ejemplo: se ejecuta si la expresión de
comparación (error < errorMinimo) tiene valor true:
numero = 58;
if (math.abs(numero) < 10)
{
System.out.println(“Número de 1 solo dígito”);
} /* fin del if */
}
Las llaves {} sirven para agrupar en un bloque las sentencias que se han
de ejecutar, y no son necesarias si sólo hay una sentencia dentro del if.
Bifurcación if else
Análoga a la anterior, de la cual es una ampliación. Las sentencias incluidas
en el else se ejecutan en el caso de no cumplirse la expresión de comparación
(false),
Ejemplo:
numero = 58;
if (Math.abs(numero) < 10)
{
System.out.println(“Número de 1 solo dígito”);
} else{
System.out.println(“Número de 2 dígitos”);
}// fin del else
80
4.6.4
CAPÍTULO 4. JAVA
Bucles
Un bucle se utiliza para realizar un proceso repetidas veces. Se denomina
también lazo o loop. El código incluido entre las llaves {} (opcionales si el
proceso repetitivo consta de una sola línea), se ejecutará mientras se cumpla
unas determinadas condiciones. Hay que prestar especial atención a los bucles
infinitos, hecho que ocurre cuando la condición de finalizar el bucle (booleanExpression) no se llega a cumplir nunca. Se trata de un fallo muy típico,
habitual sobre todo entre programadores poco experimentados.
Bucle while
En el siguiente ejemplo se muestra que se ejecutará la sentencia fin++ mientras
la expresión (capas.charAt(fin)!=‘,’ && capas.charAt(fin)!=-1) sea verdadera.
for (int j=0; j < numeroCapas; j++)
{int fin = principio;
try {
while (capas.charAt(fin) != ‘,’ && capas.charAt(fin) != -1)
{fin++;
}
}
}
Bucle for
A continuación se podrá apreciar la utilización del bucle for:
/* calcular el nuevo vector de diseño */
for (int i = 0; i < vectorDis.length; i++)
{vectorDis[i] = vectorDis[i] + learningRate * S[i];
}
4.6. ESTRUCTURAS DE PROGRAMACIÓN
81
La sentencia int i = 0 (inicialización) se ejecuta al comienzo del for, e
i++ (incremento) después de vectorDis[i] = vectorDis[i] + learningRate * S[i]
(sentencia). La expresión booleana (vectorDis.length) se evalúa al comienzo
de cada iteración; el bucle termina cuando la expresión de comparación toma
el valor false.
Bucle do while
Es similar al bucle while pero con la particularidad de que el control está al
final del bucle (lo que hace que el bucle se ejecute al menos una vez, independientemente de que la condición se cumpla o no). Una vez ejecutados las
sentencias, se evalúa la condición: si resulta true se vuelven a ejecutar las
sentencias incluidas en el bucle, mientras que si la condición se evalúa a false
finaliza el bucle.
do{
/* calcular el gradiente del vector fijar el vector de diseño */
problema.fijoVector(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 número de iteraciones pasado como argumento */
problema.fijoVector(vectorDis);
Bloque try{...} catch{...} finally{...}
Java incorpora en el propio lenguaje la gestión de errores. El mejor momento
para detectar los errores es durante la compilación. Sin embargo prácticamente
sólo los errores de sintaxis son detectados en esta operación. El resto de
problemas surgen durante la ejecución de los programas.
82
CAPÍTULO 4. JAVA
En el lenguaje Java, una Exception es un cierto tipo de error o una condición anormal que se ha producido durante la ejecución de un programa.
Algunas excepciones son fatales y provocan que se deba finalizar la ejecución
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 fichero 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 fichero
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 finally.
El código dentro del bloque try está “vigilado”: Si se produce una situación
anormal y se lanza como consecuencia una excepción, el control pasa al bloque
catch que se hace cargo de la situación 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 excepción. Finalmente, si está presente, se ejecuta el bloque finally,
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 código de un método pueda generar una Exception
y no se desee incluir en dicho método la gestión del error (es decir los bucles
try/catch correspondientes), es necesario que el método pase la Exception al
método desde el que ha sido llamado. Esto se consigue mediante la adición de
la palabra throws seguida del nombre de la Exception concreta, después de la
lista de argumentos del método. A su vez el método superior deberá incluir
los bloques try/catch o volver a pasar la Exception. De esta forma se puede ir
pasando la Exception de un método a otro hasta llegar al último método del
programa, el método main().
4.7
Servlet
Los servlets son programas de Java que construyen respuestas dinámicas para
el cliente, tal como páginas Web. Los servlets reciben y responden a las
demandas de los clientes Web, normalmente por HTTP.
4.7. SERVLET
83
Además los servlets son escalables, dando soporte para una multi-aplicación
de configuración del servidor. [11]
Permiten utilizar datos caché, acceso a información 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 codificación con respecto a soluciones dependientes del servidor web y
de la
plataforma.
• Ejecución en paralelo de multiples peticiones por una sola instancia del
servlet.Tradicionalmente en los programas CGI se ejecuta un proceso
distinto para cada petición lo que conlleva una gradual degradación 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 básicamente en dos paquetes:
• javax.servlet
• javax.servlet.http
Todas las clases e interfaces que hay que utilizar en la programación de
Servlets están en estos dos paquetes.
84
CAPÍTULO 4. JAVA
Figura 4.3: Jerarquía y Métodos de las Principales Clases Para Crear Servlets.
Vision General del API de Servlet
La relación entre las clases e interfaces de Java, muy determinada por el concepto de herencia, tal como puede verse en la fig. 4.3 de la pág. 84 se representan con letra normal las clases y las interfaces con cursiva.
La clase GenericServlet es una clase abstracta puesto que su método service() es abstracto. Esta implementa dos interfaces, de las cuales la más
importante es la interface Servlet.
La interface Servlet declara métdos más importantes de cara a la vida de
un servlet: init() que se ejecuta sólo 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á definir el método service(). Este método tiene en su definición 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 envía al
servlet. Si la solicitud de servicio viene de un formulairo HTML, a través 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
método 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 implementación
o definición del método service(). Dicha implementación detecta el tipo de
servicio o método HTTP que le ha sido solicitado desde el browser y llama
al método adecuado de esa misma clase (doPost(), doGet(),etc.), también
aparecen otras interfaces como ser:
• La interfaz ServletConfig define métodos que permiten pasar al servlet
información sobre sus parametros de inicialización.
• La interface ServletContext permite a los servlets acceder a información
sobre el entorno en que se estan ejecutando.
Principios de Codificación de Servlet
Para crear un servlet de HTTP, es necesario extender las clases:
javax.servlet.HttpServlet y sustituir cualquier método que se desee implementar en el servlet. Por ejemplo, un servlet reemplaza el método 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 información 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 podría 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
CAPÍTULO 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 definen métodos tales como:
• Iniciar un servlet.
• Solicitar servicios.
• Quitar un servlet del servidor.
Éstos son conocidos como métodos del ciclo de vida y son llamados en la
siguiente secuencia:
• Se construye el servlet.
• Se inicializa con el método INIT.
• Se manejan llamadas de los clientes al método de servicio.
• Se saca el servlet de servicio.
• Se destruye con el método destruir.
• Se finaliza el servlet y la basura es recolectada.
El ciclo de vida de un Servlet se puede apreciar en la fig. 4.4de la pág 87.
4.7.2
Instanciación e Inicialización
El motor del servlet (la función del Servidor de Aplicaciones que procesa servlets, archivos JSP, y otros tipos de server-side incluyendo codificación) crea
una instancia del servlet. El motor del servlet crea el objeto de configuración
del servlet y lo usa para pasar los parámetros de inicialización del servlet al
método INIT. La inicialización de los parámetros 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
CAPÍTULO 4. JAVA
Si la inicialización tiene éxito, el servlet está disponible para el servicio. Si
la inicialización falla, el motor del servlet descarga el servlet. El administrador
puede inhabilitar una aplicación y el servlet para el servicio. En tales casos,
la aplicación 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 método de servicio del servlet, procesa el requerimiento y usa métodos del
objeto respuesta para crear la respuesta para el cliente.
El método de servicio recibe información sobre el requerimiento del objeto
demanda, procesa el requerimiento, y usa los métodos del objeto respuesta
para crear la contestación para el cliente. El método de servicio puede invocar
otros métodos para procesar el requerimiento, tales como doGet (), doPost (),
o métodos del usuario.
4.7.4
Terminación
El motor del servlet invoca al método destroy () del servlet cuando apropia
y descarga el servlet. La Máquina Virtual de Java realiza la recolección de
basura después de la destrucción del servlet.
Cuando el contenedor Web ya no necesita que el servlet o una nueva instancia del servlet se recarguen, invoca al método destroy () del servlet. El
contenedor Web también puede llamar al método destroy () si el motor necesita conservar recursos o una llamada pendiente a un método service () del
servlet excediendo el timeout. La Máquina Virtual de Java realiza recolección
de basura después del destroy.
4.7.5
Java Server Faces
JavaServer Pages (JSP) combinan HTML con fragmentos de Java para producir páginas web dinámicas.
Cada página es automáticamente compilada a servlet por el motor de JSP
4.7. SERVLET
89
, en primer lugar es recogida y a continuación 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 página JSP es archivo de texto simple que consiste en contenido
HTML o XML con elementos JSP. Cuando un cliente pide una página JSP
del sitio web y no se ha ejecutado antes, la página es inicialmente pasada al
motor de JSP, el cual compila la página convirtiéndola en Servlet, la ejecuta
y devuelve el contenido de los resultados al cliente.
El código fuente de una página JSP incluye:
• Directivas: Dan información global de la página, por ejemplo, importación de
estamentos, página que majena los errores o cuando la página forma parte
de una
sesión.
• Declaraciones: Sirven para declarar métodos y variables.
• Scripts de JSP: Es el código Java embebido en la página.
• Expresiones de JSP: Formatea las expresiones como cadenas para incluirlas en
la página de salida.
Directivas
Una directiva de JSP es una estamento que proporciona la información del
motor de JSP para la
página que la pide. Su sintaxis general es <%@ directiva {atributo =”valor”} %>
dónde la directiva debe tener un número de atributos.
Algunos ejemplos son:
90
CAPÍTULO 4. JAVA
— Page: Información para la página.
— Include: Incluye archivos completos palabra por palabra.
— Taglib: La dirección de la librería de tags que se usará en la página.
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 especificación.
— extends=“package.class”: La variale extends, define 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 especificar los paquetes y clases que se quieran utilizar.
— session=“true|false”: Por defecto session vale true, manteniendo los
datos de las sesión para la página.
— isThreadSafe=“true|false”: Por defecto vale true, le hace señales
al motor de JSP para que multiples pedidos del cliente puedan ser
tomadas como una.
— info=“text”: Información en la página a la que puede accederse a
través del método Servlet.getServletInfo().
— errorPage=”pagina_error”: Página que manejará las excepciones
de errores.
Declaraciones
Una declaración de JSP, puede definirse como una definición de variables
y métodos a nivel de
clase que son usadas en la página.
Un bloque de declaraciones típico sería <%! declaración %>
Un ejemplo de declaración de script sería el siguiente:
<HTML>
<HEAD>
<TITLE>Página 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 código Java residentes entre los tags <% y %>.
Este bloques de código estarán dentro del servlets generado incluídos en
método _jspService(). Los Scripts pueden acceder a cualquier variable o Beans
que haya sido declarado. También hay algunos objetos implícitos disponibles
para los Scripts desde entorno del Servlet.
Algunos de ellos pueden verse a continuación:
• request: Es la petición del cliente. Es normalmente una subclase de la
case HttpServletRequest.
• response: Es la página JSP de respuesta y es una subclase de HttpServletResponse. Los atributos de la página y los objetos implicitos necesitan
ser accesibles a través de API, para permitir al motro de JSP compilar
la página. Pero cada servidor tiene implementaciones específicas
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 página (erropage,session,buffer and autoflush) y facilita los otros objetos implícitos
para la pagina de petición.
• session: El objeto de sesión HTTP asociado a la petición.
• application: Lo que devuelve el servlet cuando se llama a getServletConfig().getContext().
92
CAPÍTULO 4. JAVA
• page: Es la forma que tiene la página para referirse a si misma. Se usa
como alternativa al objeto this.
El siguiente fragmento de código muestra como obtener el valor de una
parámetro 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 magnifica herramienta para insertar código embebido dentro de la
página HTML. Cualquier cosa que este entre los tags <%= y %> será
evaluado, convertido a
cadena y posteriormente mostrado en pantalla. La conversión desde el tipo
inicial a String es
manejada autómaticamente.
Es importante remarcar que que la expresión no termina en punto y coma
(;) . Esto es así porque
motro de JSP, pondrá la expresión automáticamente entre out.println().
Las expresiones JSP te permiten parametrizar las páginas HTML (es parecido a cuando
parametrizas una consulta SQL pero difieren la forma de los valores). Una
y otra vez , en el
código de la página HTML, ser verán bucles o condiciones usando código
Java, simplemente
empezando y acabando las condiciones o bucles entre los tags <% y %>.
Un ejemplo sería:
<% 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 envía un requerimiento para los archivos JSP.
Los archivos JSP acceden a los beans u otros componentes que generan
contenido dinámico para ser enviado al browser como se muestra en la figura
4.5 de la página 93.
Cuando el servidor Web recibe un requerimiento para un archivo JSP, el
servidor envía ese requerimiento al servidor de aplicaciones. El servidor de
aplicaciones analiza el archivo JSP y genera código fuente de Java que se
compila y se ejecuta como un servlet.
El requerimiento se envía a un servlet que genera contenido dinámico y
llama a un archivo JSP para enviar el contenido a un browser, como se muestra
en la figura 4.6 de la página 94.
Este modelo de acceso facilita la generación de contenido separado del
despliegue de contenido.
El servidor de aplicaciones proporciona un juego de métodos en el objeto
HttpServiceRequest object y el objeto HttpServiceResponse. Estos métodos
94
CAPÍTULO 4. JAVA
Figura 4.6: Requerimiento de un Servlet.
permiten una invocación de servlet para colocar un objeto (normalmente un
bean) en un objeto demanda y pasa ese requerimiento a otra página (normalmente un archivo JSP) para el despliegue. La página 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 función de la lógica
comercial. Las aplicaciones Web son grupos de uno o más servlets, más el
contenido estático.
Aplicaciones Web = servlets + archivos JSP + archivos XML + archivos
HTML + gráficos.
El modelo de programación 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.
Capítulo 5
Java 2 Micro Edition
5.1
Introducción
Para empezar se puede decir que Java 2 Micro Edition o J2ME es la versión
del lenguaje Java que está orientada al desarrollo de aplicaciones para dispositivos pequeños con capacidades restringidas tanto en pantalla gráfica, como
de procesamiento y memoria (teléfonos móviles, PDA‘s, Handhelds, Pagers,
etc.).
Esta versión de Java fue presentada en 1999 por Sun Microsystems con el
propósito de habilitar aplicaciones Java para pequeños dispositivos. En esta
presentación lo que realmente se mostró fue una nueva máquina virtual Java
o JVM (Java Virtual Machine) que podía ejecutarse en dispositivos Palm.
La tardía aparición de esta tecnología puede ser debido a que las necesidades de los usuarios de telefonía móvil han cambiado mucho en estos últimos
años y cada vez demandan más servicios y prestaciones por parte tanto de los
terminales como de las compañías. Además el uso de esta tecnología 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 tecnología
del futuro para la industria de los dispositivos móviles.
97
98
CAPÍTULO 5. JAVA 2 MICRO EDITION
5.1.1
Comparación 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 características de cada una de las versiones son:
1. Java 2 Platform, Standard Edition (J2SE): Esta edición de Java es la
que en cierta forma recoge la iniciativa original del lenguaje Java. Tiene
las siguientes Características:
• Inspirado inicialmente en el lenguaje C++, pero con componentes
de alto nivel, como soporte nativo de strings y recolector de basura
(garbage colector ).
• Código 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.
• Abstracción del sistema operativo subyacente mediante un juego
completo de APIs de programación.
• Contiene el conjunto básico de herramientas usadas para desarrollar Java Applets, así cómo las APIs orientadas a la programación
de aplicaciones de usuario final: Interfaz gráfica de usuario, multimedia, redes de comunicación.
2. Java 2 Platform, Enterprise Edition (J2EE): Esta versión está orientada
al entorno empresarial. El software empresarial tiene unas características
propias marcadas:
5.1. INTRODUCCIÓN
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 edición está orientada especialmente al desarrollo de servicios web, servicios de nombres, persistencia de objetos, XML,
autenticación, APIs para la gestión de transacciones, etc.
— El cometido de esta especificación es ampliar la J2SE para dar
soporte a los requisitos de las aplicaciones de empresa.
3. Java 2 Platform, Micro Edition (J2ME): Esta versión de Java está enfocada a la aplicación de la tecnología Java en dispositivos electrónicos
con capacidades computacionales y gráficas muy reducidas, tales como
teléfonos móviles, PDAs o electrodomésticos inteligentes:
— Esta edición tiene unos componentes básicos que la diferencian de
las otras versiones, como el uso de una máquina virtual denominada
KVM (Kilo Virtual Machine, debido a que requiere sólo unos pocos
Kilobytes de memoria para funcionar) en vez del uso de la JVM
clásica.
Figura 5.1: Arquitectura de la Plataforma Java 2 de Sun.
La fig. 5.1 de la pág. 99 muestra la arquitectura de Java2.
100
CAPÍTULO 5. JAVA 2 MICRO EDITION
En la actualidad se puede decir que Java no es sólo un simple lenguaje de
programación sino un conjunto de tecnologías que engloba a todos los aspectos
de la computación con dos elementos en común:
• El código fuente en lenguaje Java es compilado a código intermedio
interpretado por una Java Virtual Machine (JVM ), por lo que el código
ya compilado es independiente de la plataforma.
• Todas las tecnologías comparten un conjunto más o menos amplio de
APIs básicas del lenguaje, agrupadas principalmente en los paquetes
java.lang y java.io.
Debido a que la edición estándar de APIs de Java ocupa 20 MB aproximadamente y los dispositivos pequeños disponen de una cantidad de memoria
mucho más reducida, J2ME contiene una mínima 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
fija forma parte de lo que se denomina “configuración” [14].
Otra diferencia con la plataforma J2SE viene dada por el uso de una
máquina virtual distinta de la clásica JVM denominada KVM. Esta KVM
tiene unas restricciones que hacen que no posea todas las capacidades incluidas
en la JVM clásica.
J2ME representa una versión simplificada de J2SE. Sun separó estas dos
versiones ya que J2ME está pensada para dispositivos con limitaciones de
proceso y capacidad gráfica. También separó J2SE de J2EE porque este
último exigía unas características muy pesadas o especializadas de E/S, trabajo
en red, etc. Por tanto, separó ambos productos por razones de eficiencia.
Hoy, J2EE es un superconjunto de J2SE pues contiene toda la funcionalidad de éste y más características, así como J2ME es un subconjunto de J2SE
(excepto por el paquete javax.microedition) ya que contiene varias limitaciones
con respecto a J2SE.
Sólo de manera muy simplista se puede considerar a J2ME y J2EE como
versiones reducidas y ampliadas de J2SE respectivamente (ver fig. 5.2 de la
pág. 101): en realidad cada una de las ediciones está enfocada a ámbitos de
aplicación muy distintos [14].
5.1. INTRODUCCIÓN
101
Figura 5.2: Ubicación de las Tecnologías Java.
5.1.2
Algunas Consideraciones al Desarrollar en J2ME
Algunas consideraciones son las siguientes:
• Prácticamente los dispositivos móviles y más aún los nuevos teléfonos
celulares ya poseen capacidad de ejecución de aplicaciones desarrolladas
en J2ME. Existen algunas ventajas y restricciones o desventajas respecto
a otras tecnologías [10].
• Algunas ventajas en comparación de J2ME con respecto al lenguaje C son:
∗ Multiplataforma: Significa 1 programa - se puede ejecutar en
n móviles.
∗ Seguridad: El usuario está protegido.
∗ Descarga OTA (Over The Air).
∗ Desarrollo rápido.
— Inconveniente:
∗ Alejamiento del hardware. No puede accederse a ciertos recursos del teléfono si éste no incorpora el API correspondiente.
• Las aplicaciones móviles que poseen conectividad a Internet pueden utilizar la tecnología GPRS, en la cual se tarifa al usuario por Kbytes recibidos y enviados, es por esto que es importante minimizar la cantidad
102
CAPÍTULO 5. JAVA 2 MICRO EDITION
de información intercambiada. Las relaciones que existen de acuerdo
al tipo de información intercambiada y el volumen de la misma son las
siguientes:
— Página html - 10-100Kb.
— Página wml 1-10Kb.
— Información “pura” - 0.1 - 1kb.
• ¿Cuándo interesa desarrollar en J2ME ?:
— Cuando no hay tráfico de información, por ejemplo: juegos, conversores de unidades.
— Cuando el tráfico de información puede minimizarse con J2ME .
— Cuando pueden almacenarse datos localmente en el móvil y sólo
transferir algunos otros como los resultados [10].
5.2
Componentes de J2ME
Los componentes que forman parte de la tecnología J2ME son:
• Máquina virtual: Existe una serie de máquinas virtuales java con diferentes requisitos, cada una para diferentes tipos de pequeños dispositivos.
• Configuraciones: Son un conjunto de clases básicas orientadas a conformar el corazón de las implementaciones para dispositivos de características específicas:
— Connected Limited Device Configuration (CLDC) enfocada a dispositivos con restricciones de procesamiento y memoria.
— Connected Device Configuration (CDC) enfocada a dispositivos con
más recursos [10].
• Perfiles: Son unas bibliotecas Java de clases específicas orientadas a
implementar funcionalidades de más alto nivel para familias específicas
de dispositivos.
5.2. COMPONENTES DE J2ME
5.2.1
103
Máquinas Virtuales J2ME
Una máquina virtual de Java (JVM ) es un programa encargado de interpretar
código intermedio (bytecode) de los programas Java precompilados a código
máquina ejecutable por la plataforma, efectuar las llamadas pertinentes al
sistema operativo subyacente y observar las reglas de seguridad y corrección
de código definidas 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 define
varias JVMs de referencia adecuadas al ámbito de los dispositivos electrónicos
que, en algunos casos, suprimen algunas características con el fin de obtener
una implementación menos exigente.
La tecnología J2ME ha definido dos configuraciones, CDC y CLDC, cada
una de ellas con características propias, en consecuencia para cada tipo de
configuración se definió una máquina virtual distinta. La VM (Virtual Machine) correspondiente a CLDC se denomina KVM y la de la configuración
CDC se denomina CVM.
A continuación se detallan las principales características de cada una de
ellas:
KVM
Se corresponde con la máquina virtual más pequeña. Su nombre KVM
proviene de Kilobyte (que hace referencia a la baja ocupación de memoria).
Se trata de una implementación de máquina virtual reducida y especialmente
orientada a dispositivos con bajas capacidades computacionales y de memoria,
como ser los teléfonos celulares.
La KVM está escrita en el lenguaje de programación C y posee algunas
características particulares como:
• Pequeña, con una carga de memoria entre los 40Kb y los 80 Kb, dependiendo de la plataforma y las opciones de compilación.
• Alta portabilidad.
• Modulable.
104
CAPÍTULO 5. JAVA 2 MICRO EDITION
• Lo más completa y rápida posible y sin sacrificar características para las
que fue diseñada.
Sin embargo, existen algunas limitaciones debido a su bajo consumo de
memoria respecto la maquina virtual clásica:
• No hay soporte para tipos en coma flotante. Esta limitación 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) definidos por el usuario.
• No se permiten los grupos de hilos o hilos daemon. Si se necesita la
utilización de grupos de hilos se tendrán que utilizar los objetos colección
para almacenar cada hilo.
• No existe la finalización de instancias de clases. No existe el método
Object.finalize().
• 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 mayoría de las excepciones.
Otro tema en cuestión que se puede encontrar en ésta maquina virtual
más pequeña es la verificación de clases. El verificador de clases estándar
de Java es demasiado grande para la KVM, De hecho es más grande que la
propia KVM y el consumo de memoria es excesivo, más de 100Kb para las
aplicaciones típicas.
Este verificador de clases es el encargado de rechazar las clases no válidas
en tiempo de ejecución. Este mecanismo verifica los bytecodes de las clases
Java realizando las siguientes comprobaciones:
• Ver que el código no sobrepase los límites de la pila de la VM.
• Comprobar que no se utilizan las variables locales antes de ser inicializadas.
5.2. COMPONENTES DE J2ME
105
• Comprobar que se respetan los campos, métodos y los modificadores de
control de acceso a clases.
Por esta razón los dispositivos que usen la configuración CLDC y KVM
introducen un algoritmo de verificación de clases en dos pasos. Este proceso
puede apreciarse gráficamente en la fig. 5.3 de la pág. 105.
Figura 5.3: Proceso de Verificación.
CVM
• La CVM (Compact Virtual Machine) ha sido tomada como máquina
virtual
Java de referencia para la configuración CDC y soporta las mismas características que la máquina virtual clásica. Está orientada a dispositivos electrónicos con procesadores de 32 bits de gama alta y en torno a 2 Mb o más de
memoria RAM.
Las características que presenta ésta máquina virtual son:
1. Sistema de memoria avanzado.
106
CAPÍTULO 5. JAVA 2 MICRO EDITION
2. Tiempo de espera bajo para el recolector de basura.
3. Separación completa de la VM del sistema de memoria.
4. Recolector de basura modularizado.
5. Portabilidad.
6. Rápida sincronización.
7. Ejecución de las clases Java fuera de la memoria de sólo lectura (ROM).
8. Soporte nativo de hilos.
9. Baja ocupación en memoria de las clases.
10. Proporciona soporte e interfaces para servicios en sistemas operativos de
tiempo real.
11. Conversión de hilos Java a hilos nativos.
12. Soporte para todas las características de Java2 v1.3 y librerías de seguridad, referencias débiles, Interfaz Nativa de Java (JNI ), invocación
remota de métodos (RMI ), Interfaz de depuración de la máquina virtual
(JVMDI).
5.2.2
Configuraciones
Una configuración es el conjunto mínimo de APIs Java que permiten desarrollar aplicaciones para un grupo de dispositivos. Estas APIs describen las
características básicas, comunes a todos los dispositivos:
• Características soportadas del lenguaje de programación Java.
• Características soportadas por la máquina virtual Java.
• Bibliotecas básicas de Java y APIs soportadas.
Como se ha mencionado con anterioridad, existen dos configuraciones, la
que está orientada a dispositivos con limitaciones computacionales y de memoria que se denomina CLDC y la configuración que se encuentra orientada
5.2. COMPONENTES DE J2ME
107
a dispositivos con menos restricciones en cuanto a capacidad de cómputo y
memoria, la cual se denomina CDC .
A continuación se presentan las características más relevantes de cada una:
• Configuración de dispositivos con conexión, CDC (Conected Device Configuration):
— La CDC está orientada a dispositivos con cierta capacidad computacional y de memoria. Por ejemplo, decodificadores de televisión
digital, televisores con Internet, algunos electrodomésticos y sistemas de navegación en automóviles.
— CDC usa una máquina virtual Java similar en sus características
a una de J2SE, pero con limitaciones en el apartado gráfico y de
memoria del dispositivo.
— La CDC está enfocada a dispositivos con las siguientes capacidades:
— Procesador de 32 bits.
— 2 Mb o más de memoria total, incluyendo memoria RAM y
ROM.
— Conectividad a algún tipo de red.
— Poseer la funcionalidad completa de la Máquina Virtual Java
2.
— La CDC está basada en J2SE v1.3 e incluye varios paquetes Java
de la edición estándar. Las peculiaridades de la CDC están 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 pág. 108 muestra las librerías incluidas en la CDC.
• Configuracion de dispositivos limitados con conexión, CLDC (Conected
Limited Device Configuration):
— La CLDC está orientada a dispositivos dotados de conexión y con limitaciones en cuanto a capacidad gráfica, cómputo y memoria. Como por ejemplo teléfonos móviles, buscapersonas (Pagers), PDAs,
organizadores personales, etc.
108
CAPÍTULO 5. JAVA 2 MICRO EDITION
Nombre del paquete
CDC
java.io
java.lang
java.lang.ref
java.lang.reflect
java.math
java.net
java.security
java.security.cert
java.text
java.util
java.util.jar
java.util.zip
javax.microedition.io
Descripción
Clases y paquetes estándar de E/S
Clases e interfaces de la máquina virtual
Clases de referencia
Clases e interfaces de reflectión
Paquete de matemáticas
Clases e interfaces de red
Clases e interfaces de seguridad
Clases de certificados de seguridad
Paquete de texto
Clases de utilidades estándar
Clases y utilidades para archivos JAR
Clases y utilidades para archivos
ZIP y comprimidos
Clases e interfaces para conexión genérica CDC
Tabla 5.1: Librerías de configuración CDC.
— Las restricciones que contiene la configuración CLDC vienen dadas
por la utilización de la máquina 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 mínimo se debe disponer de 128 Kb de memoria no volátil para la máquina virtual Java y las bibliotecas CLDC, y 32
Kb de memoria volátil para la máquina virtual en tiempo de
ejecución.
∗ Procesador de 16 o 32 bits con al menos 25 Mhz de velocidad.
∗ Tener conexión a algún tipo de red, normalmente sin cable, con
conexión intermitente y ancho de banda limitado.
∗ Ofrecer bajo consumo, debido a que éstos dispositivos trabajan con suministro de energía limitado, normalmente baterías
recargables.
— La CLDC aporta las siguientes funcionalidades a los dispositivos:
∗ Un subconjunto del lenguaje Java y todas las restricciones de
su máquina virtual (KVM ).
5.2. COMPONENTES DE J2ME
∗
∗
∗
∗
109
Un subconjunto de las bibliotecas del núcleo de Java.
Soporte para acceso a redes.
Soporte para E/S básica.
Seguridad.
La tabla 5.2 de la pág. 109 muestra las librerías incluidas en la CLDC.
Nombre del paquete CLDC
java.io
java.lang
java.util
javax.microedition.io
Descripción
Clases y paquetes estándar de E/S
Clases e interfaces de la máquina virtual
Clases e interfaces, utilidades estándar
Clases e interfaces de conexión genérica
Tabla 5.2: Librerías de configuración CLDC.
5.2.3
Perfiles
Un perfil es el que define las APIs que controlan el ciclo de vida de la aplicación,
interfaz de usuario, etc. Concretamente, un perfil es un conjunto de APIs
orientado a un ámbito de aplicación determinado.
Los perfiles identifican un grupo de dispositivos por la funcionalidad que
proporcionan (ya sean electrodomésticos, teléfonos móviles, etc.) y el tipo de
aplicaciones que se ejecutarán en ellos.
Las librerías de la interfaz gráfica son un componente muy importante en
la definición de un perfil. Se pueden encontrar grandes diferencias entre las
interfaces, desde el menú textual de los teléfonos móviles hasta los táctiles de
los PDAs.
El perfil establece unas APIs que definen las características de un dispositivo, mientras que la configuración hace lo propio con una familia de ellos.
Esto hace que a la hora de construir una aplicación se cuente tanto con las
APIs del perfil como de la configuración.
Anteriormente se mencionó que para una configuración determinada se
usaba una Máquina Virtual Java específica. Teníamos que con la configura-
110
CAPÍTULO 5. JAVA 2 MICRO EDITION
ción CDC se utilizaba la CVM y que con la configuración CLDC se utilizaba
la KVM. Con los perfiles ocurre lo mismo. Existen unos perfiles que se construirán sobre la configuración CDC y otros que se construirán sobre la CLDC.
Figura 5.4: Entorno de Ejecución de J2ME.
Para la configuración CDC se encuentran los siguientes perfiles:
• Fundation Profile.
• Personal Profile.
• RMI Profile.
Y para la configuración CLDC se encuentran los siguientes:
• PDA Profile.
• Mobile Information Device Profile (MIDP).
En la fig. 5.4 de la pág. 110 se puede ver cómo quedaría el esquema del
entorno de ejecución al completo.
A continuación se describirá con más detenimiento cada uno de estos perfiles:
5.2. COMPONENTES DE J2ME
111
Foundation Profile: Este perfil define una serie de APIs sobre la CDC
orientadas a dispositivos que carecen de interfaz gráfica como, por ejemplo,
decodificadores de televisión digital [14].
Este perfil incluye gran parte de los paquetes de la J2SE, pero excluye
totalmente los paquetes que conforman la interfaz gráfica de usuario (GUI )
de J2SE, concretamente los paquetes “java.awt” Abstract Windows Toolkit
(AWT ) y “java.swing”.
Los paquetes que forman parte del Foundation Profile se muestran en la
tabla 5.3 de la pág. 111.
Paq. del Fundation Profile
java.lang
java.util
java.net
java.io
java.text
java.segurity
Descripción
Soporte del lenguaje Java
Añade soporte completo para
zip y otras funcionalidades
Incluye sockets TCP/IP
y conexiones HTTP
Clases Reader y Writer de J2SE
Incluye soporte para internacionalización
Incluye códigos y certificados
Tabla 5.3: Librerías del Fondation Profile.
Personal Profile: Es un subconjunto de la plataforma J2SE versión 1.3,
proporciona un completo soporte gráfico AWT .
El objetivo es el de dotar a la configuración CDC de una interfaz gráfica
completa, con capacidades web y soporte de applets Java.
Este perfil requiere una implementación del perfil Foundation Profile.
La tabla 5.4 de la pág. 112 muestra los paquete que conforman el perfil.
RMI Profile: Este perfil requiere una implementación del Foundation
Profile. El perfil RMI soporta un subconjunto de las APIs J2SE v1.3 RMI.
Algunas características de estas APIs se han eliminado del perfil RMI debido
a las limitaciones de cómputo y memoria de los dispositivos.
Las siguientes propiedades se han eliminado del J2SE RMI v1.3 :
112
CAPÍTULO 5. JAVA 2 MICRO EDITION
Paq. del Personal
Profile
java.applet
java.awt
java.awt.datatransfer
java.awt.event
java.awt.font
java.awt.im
java.awt.im.spi
java.awt.image
java.beans
javax.microedition.xlet
Descripción
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
manipulación de fuentes
Clases e interfaces para definir
métodos editores de entrada
Interfaces que añ aden el desarrollo de métodos
editores de entrada para cualquier entorno
de ejecución Java
Clases para crear y modificar imágenes
Clases que soportan JavaBeans
Interfaces que usa el Personal Profile
para la comunicación
Tabla 5.4: Librerías del Personal Profile.
5.2. COMPONENTES DE J2ME
113
• Java.rmi.server.disableHTTP.
• Java.rmi.activation.port.
• Java.rmi.loader.packagePrefix.
• Java.rmi.registry.packagePrefix.
• Java.rmi.server.packagePrefix
PDA Profile: Está construido sobre CLDC. Pretende abarcar PDAs de
gama baja, tipo Palm, con una pantalla y algún tipo de puntero (ratón o lápiz)
y una resolución de al menos 20000 pixeles.
En este momento este perfil se encuentra en fase de definición.
Mobile Information Device Profile (MIDP): Este perfil está construido sobre la configuración CLDC. MIDP fue el primer perfil definido para
esta plataforma.
Este perfil está orientado para dispositivos con las siguientes características:
• Reducida capacidad computacional y de memoria.
• Conectividad limitada (en torno a 9600 bps).
• Capacidad gráfica muy reducida (mínimo un display de 96x54 pixels).
• Entrada de datos alfanumérica reducida.
• 128 Kb de memoria no volátil para componentes MIDP.
• 8 Kb de memoria no volátil para datos persistentes de aplicaciones.
• 32 Kb de memoria volátil en tiempo de ejecución para la pila Java.
Los tipos de dispositivos que se adaptan a estas características son: teléfonos móviles, buscapersonas (pagers) o PDAs de gama baja con conectividad.
El perfil MIDP especifica las APIs relacionadas con:
• La aplicación (semántica y control de la aplicación MIDP).
114
CAPÍTULO 5. JAVA 2 MICRO EDITION
• Interfaz de usuario.
• Almacenamiento persistente.
• Trabajo en red.
• Temporizadores.
Las aplicaciones realizadas utilizando MIDP reciben el nombre de MIDlets
(por simpatía con APPlets). Se puede decir que un MIDlet es una aplicación
Java realizada con el perfil MIDP sobre la configuración CLDC.
En la tabla 5.5 de la pág. 114 se pueden apreciar cuáles son los paquetes
que están incluidos en el perfil MIDP.
Paq. del MIDP
javax.microedition.lcdui
javax.microedition.rms
javax.microedition.midlet
javax.microedition.io
java.io
java.lang
java.util
Descripción
Clases e interfaces para GUIs
Soporte para el almacenamiento
persistente del dispositivo
Clases de definición de la aplicación
Clases e interfaces de conexión genérica
Clases e interfaces de E/S básica
Clases e interfaces de la máquina virtual
Clases e interfaces de utilidades estándar
Tabla 5.5: Librerías del MIDP Profile.
5.3
Requerimientos Funcionales Para Detectar una
Aplicación 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 través de un navegador WAP o a través de
una aplicación residente escrita específicamente para identificar 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 especificación 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 contraseña 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 especificación MIDP. Están
diseñados para ser ejecutados en dispositivos con poca capacidad gráfica, de
cómputo y de memoria.
Las clases de un MIDLet, son almacenadas en bytecodes Java, dentro de
un fichero .class. Estas clases deben ser verificadas antes de su “puesta en
marcha”, para garantizar que no realizan ninguna operación no permitida.
Este preverificación, se debe hacer debido a las limitaciones de la máquina
virtual usada en estos dispositivos [14].
Para mantener a la máquina virtual lo más sencilla y pequeña posible, se
elimina esta verificación, y se realiza antes de la entrada en producción.
La preverificación se realiza después de la compilación, y el resultado es
una nueva clase, lista para ser puesta en producción.
Los MIDLets son empaquetados en ficheros “.jar ”.
116
CAPÍTULO 5. JAVA 2 MICRO EDITION
Existen 2 ficheros que contienen información extra dentro del “.jar” para
la puesta en marcha de la aplicación, el fichero “manifiesto”, con extensión
“.mf ” y un fichero “descriptor”, con extensión “.jad”.
Un fichero “.jar ” típico, por tanto, se compondrá de:
• Clases del MIDLet.
• Clases de soporte.
• Recursos (imágenes, sonidos, etc.).
• Manifiesto (fichero “.mf”).
• Descriptor (fichero “.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 ejecución.
5.4.2
Ciclo de Vida de un Midlet
Como puede ilustrarse en la fig. 5.5 de la pág. 117 el ciclo de vida de un MIDlet
pasa por cinco fases: Descubrimiento o localización; instalación; ejecución;
actualización y borrado.
El AMS es el encargado de gestionar cada una de estas fases de la siguiente
manera:
1. Localización: Esta fase es la etapa previa a la instalación del MIDlet y
es donde se selecciona a través del gestor de aplicaciones la aplicación
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 elección 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 conexión inalámbrica.
2. Instalación: En esta fase el gestor de aplicaciones controla todo el proceso de instalación del MIDlet informando al usuario tanto de la evolución
de la instalación como de si existiese algún problema durante ésta.
3. Ejecución: Mediante el gestor de aplicaciones se va a poder iniciar la
ejecución de los MIDlets. En esta fase, el AMS tiene la función de gestionar los estados del MIDlet en función de los eventos que se produzcan
durante esta ejecución.
4. Actualización: El AMS tiene que tener la capacidad de detectar si el MIDlet a instalar es una actualización de alguno ya existente, en cuyo caso
deberá informar de la situación y permitir la actualización del MIDlet.
5. Borrado: Una vez instalado el MIDlet en el dispositivo, este permanece
118
CAPÍTULO 5. JAVA 2 MICRO EDITION
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 confirmación
del proceso antes de continuar.
5.4.3
Estados de un MIDlet
Además de gestionar el ciclo de vida de los MIDlets, el AMS es el encargado de
controlar los estados del MIDlet durante su ejecución. 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
fig. 5.6 de la pág. 118.
Como se puede ver en la fig. 5.6 de la pág. 5.6, un MIDlet puede cambiar de estado mediante una llamada a los métodos MIDlet.startApp(), MIDlet.pauseApp() o MIDlet.destroyApp(). El gestor de aplicaciones cambia el
estado de los MIDlets haciendo una llamada a cualquiera de los métodos anteriores.
Un MIDlet también puede cambiar de estado por sí mismo.
5.4. LOS MIDLETS
5.4.4
119
El paquete javax.microedition.midlet
El paquete javax.microedition.midlet define las aplicaciones MIDP y su comportamiento con respecto al entorno de ejecución.
En la tabla 5.6 de la pág. 119 se puede apreciar cuáles son las clases que
están incluidas en este paquete.
Clases
MIDlet
MIDletstateChangeException
Descripción
Aplicación 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 aplicación realizada usando el perfil MIDP.
La aplicación 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 métodos de los que dispone esta clase son los siguientes:
• protected MIDlet()
Constructor de clase sin argumentos. Si la llamada a este constructor falla,
se lanzaría la excepción SecurityException.
• public final int checkPermission(String permiso)
Con este método se consigue un número que determina el permiso especificado. Este permiso está descrito en el atributo MIDlet-Permission del archivo
JAD.
Los valores que puede arrojar este método son:
120
CAPÍTULO 5. JAVA 2 MICRO EDITION
— 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 terminación 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
método puede ser llamado desde los estados “Pausa” o “Activo”.
• public final String getAppProperty(String key)
Este método 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 parámetro key.
• public final void notifyDestroyed()
Con este método se notifica al AMS que el MIDlet no quiere estar “Activo”
y que ha entrado en el estado de “Pausa”. Este método sólo debe ser invocado
cuando el MIDlet esté en el estado “Activo”.
Si la aplicación es pausada por sí misma, es necesario llamar al método
MIDlet.resumeRequest() para volver al estado “Activo”.
• protected abstract void pauseApp()
Indica al MIDlet que entre en el estado de “Pausa”. Este método sólo debe
ser llamado cuándo el MIDlet esté en estado “Activo”.
• public final boolean platformRequest(String url)
5.4. LOS MIDLETS
121
Establece una conexión entre el MIDlet y la dirección URL. Dependiendo
del contenido de la URL, el dispositivo ejecutará una determinada aplicación
que sea capaz de leer el contenido y dejar al usuario que interactúe con él.
• protected abstract void startApp() throws MIDletstateChangeException
Este método indica al MIDlet que ha entrado en el estado “Activo”. Este método sólo puede ser invocado cuándo 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 lanzaría la
excepción MIDletstateChangeException.
Los métodos anteriormente mencionados se utilizan para la comunicación
entre el MIDlet y el AMS. Por un lado se tiene que los métodos startApp(),
pauseApp() y destroyApp() los utiliza el AMS para comunicarse con el MIDlet,
mientras que los métodos 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 función
main().
Aunque existiese dicha función, el gestor de aplicaciones la ignoraría por
completo. Un MIDlet tampoco puede realizar una llamada a System.exit().
Una llamada a este método lanzaría la excepción 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
CAPÍTULO 5. JAVA 2 MICRO EDITION
/* Aquí se pueden incluir el código que el
* MIDlet ejecute cuándo se active.
*/
}
public pauseApp(){
/* Aquí se puede incluir el código que el
* MIDlet ejecute cuándo entre en el estado de pausa
* es opcional
*/
}
public destroyApp(){
/* Aquí se puede incluir el código que el
* MIDlet ejecute cuándo sea destruido. Normalmente
* aquí se liberaran los recursos ocupados por el
* MIDlet como memoria, etc.
* es opcional
*/
}
}// fin de la clase MiMidlet
Un pequeño ejemplo de una aplicación simple se puede apreciar a continuación.
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 GRÁFICAS DE USUARIO
123
}
public void startApp(){
pantalla.setCurrent(formulario);
}
public void pauseApp(){
}
public void destroyApp(boolean unconditional){
pantalla = null;
formulario = null;
notifyDestroyed();
}
}
Estos métodos 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 métodos abstractos: startApp(), pauseApp()
y destroyApp() que han de ser implementados por cualquier MIDlet.
5.5
Interfaces Gráficas de Usuario
Teniendo en cuenta la diversidad de aplicaciones que se pueden realizar para
los dispositivos MID y los elementos que proporcionan tanto la configuración
CLDC como el perfil MIDP se pueden clasificar 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 finalidad 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 estética
depende exclusivamente del dispositivo donde se ejecute. La ventaja de
la utilización de esta interfaz de usuario de alto nivel es la gran portabilidad que se consigue. Generalmente esta interfaz es utilizada para la
creación de aplicaciones de negocios.
124
CAPÍTULO 5. JAVA 2 MICRO EDITION
Figura 5.7: Jerarquía 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, además
se pueden manejar eventos de bajo nivel, tales como pulsaciones de las
teclas. Esta interfaz es más adecuada para el desarrollo de juegos. El
paquete javax.microedition.lcdui definido en el perfil MIDP incluye las
clases necesarias para crear interfaces de usuario, tanto de alto nivel
como de bajo nivel. En la fig. 5.7 de la pág. 124se puede apreciar la
organización 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 información sobre las características de la pantalla
del dispositivo donde se ejecute el MIDlet.
En la tabla 5.7 de la pág. 126 se puede ver los métodos incluidos en esta
5.5. INTERFACES GRÁFICAS DE USUARIO
125
clase.
5.5.2
La Clase Displayable
La clase Displayable representa a las pantallas de la aplicación.
Como se mencionó anteriormente, cada objeto Display puede contener tantos objetos displayables como se desee.
Mediante los métodos getCurrent y setCurrent se controlan las pantallas
para que sean visibles y accesibles en cada momento.
La clase abstracta Displayable incluye los métodos encargados de manejar
los eventos de pantalla y añadir o eliminar comandos.
Estos métodos aparecen en la tabla 5.8 de la pág. 127.
5.5.3
Las Clases Command y CommandListener
Un objeto de la clase Command mantiene información sobre un evento.
Por establecer una analogía se puede pensar a un objeto Command como
un botón de Windows.
Se implementan en los MIDlets para poder detectar y ejecutar una acción
simple.
Existen tres parámetros que hay que definir al constuir un Command:
• Etiqueta: La etiqueta es la cadena de texto que aparecerá en la pantalla
del dispositivo que identificará a el Command.
• Tipo: La declaración del tipo sirve para que el dispositivo identifique
el Command y le dé una apariencia específica acorde con el resto de
aplicaciones existentes en el dispositivo.
• Prioridades: Esto puede servirle al AMS para establecer un orden de
aparición de los Command en pantalla. A mayor número, menor prioridad.
Los tipos que se pueden asignar aparecen en la tabla 5.9de la pág 127.
126
CAPÍTULO 5. JAVA 2 MICRO EDITION
Métodos
void callSerially
(Runnable r)
boolean flashBacklight
(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)
Descripción
Retrasa la ejecución del método run()
del objeto r
Provoca un efecto de flash
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
parámetro 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 número de niveles
alpha soportados
Devuelve el número de colores
Establece la pantalla d
despues de la alerta a
Establece la pantalla actual
Establece en la pantalla
al item
Realiza la operación de
vibración del dispositivo
Tabla 5.7: Métodos de la Clase Display.
5.5. INTERFACES GRÁFICAS DE USUARIO
Métodos
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)
Descripción
añade el Command cmd
Devuelve el alto de la pantalla
Devuelve el Ticker asignado a la pantalla
Devuelve el título 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 método
cuándo el área disponible
para el objeto Displayable es modificada
Establece un Ticker a la pantalla
Establece un título a la pantalla
Tabla 5.8: Métodos de la Clase Displayable.
Tipo
BACK
CANCEL
EXIT
HELP
ITEM
OK
SCREEN
STOP
127
Descripción
Petición para volver a la pantalla anterior
Petición para cancelar la acción en curso
Petición para salir de la aplicación
Petición para mostrar información de ayuda
Petición para introducir el comando en
un Item en la pantalla
Aceptación de una acción por parte del usuario
Para comandos de propósito más general
Petición para parar una operación
un Listener para la captura de eventos
Tabla 5.9: Tipos de Commands.
128
CAPÍTULO 5. JAVA 2 MICRO EDITION
Ejemplo de un Command con la etiqueta “Atras”:
new Command(“Atras”,Command.BACK,1)
La tabla 5.10 de la pág. 128 muestra los métodos de la clase Command.
Método
public int
getCommandType()
public String getLabel()
public String getLongLabel()
public int getPriority()
Devuelve el tipo del Command
Petición 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: Métodos de la Clase Command.
No solo basta con crear objetos Command, para poder controlar algún
evento de la aplicación. Otra tarea pendiente es implementar la interfaz
CommandListener, la cual define un método abstracto llamado CommandAction(Command d, Displayable d), donde debe ser implentado dicho método,
ya que una interfaz sólo define métodos abstractos, es tarea de la clase que
implementa dicha interfaz tener que implementar los métodos definidos.
A través de la implementación del método CommandAction se podrán
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 especificación MIDP 1.0 esta clase contenía cuatro métodos que le
permitían definir y obtener el título 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 especificación MIDP
2.0, que es la más reciente, estos cuatro métodos han sido incluidos en la clase
Displayable.
5.5. INTERFACES GRÁFICAS DE USUARIO
129
La Clase Alert
El objeto Alert representa una pantalla de aviso. Normalmente se usa cuando
se quiere avisar al usuario de una situación 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 método
Alert. setTimeOut (Alert. FOREVER).
2. No modal : Este tipo de alerta permanecerá por un tiempo definido por el
usuario y luego desaparecerá. Para ello se indica el tiempo en el método
setTimeOut(tiempo), el tiempo expresado en milisegundos.
También 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 definir aparecen
en la tabla 5.11 de la pág. 129.
Método
ALARM
CONFIRMATION
ERROR
INFO
WARNING
Devuelve el tipo del Command
Aviso de una Petición previa
Indica la aceptació de una acció
Indica que ha ocurrido un error
Indica algún tipo de información
Indica que puede ocurrir algún problema
Tabla 5.11: Tipos de Alerta.
130
CAPÍTULO 5. JAVA 2 MICRO EDITION
La Clase List
La clase List hereda de la clase Screen, pero presenta una funcionalidad más
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 define constantes que describen tres tipos
básicos de listas de opciones:
• EXCLUSIVE: Una lista que permite seleccionar un solo elemento a la
vez.
• IMPLICIT: Un lista en la que la selección de un elemento provoca un
evento (se adapta para la creación de menús).
• MÚLTIPLE: Una lista que permite seleccionar uno o más elementos a
la vez.
Existen dos constructores que permiten construir listas: el primero de ellos
crea una lista vacía y el segundo proporciona una lista con un conjunto inicial
de opciones y de imágenes asociadas:
• List(String titulo, int listType).
• List(String titulo, int listType, String[] elementos, Image[] imagenes).
En la siguiente tabla 5.12 de la pág. 131 se puede observar los distintos
métodos de la clase List.
La Clase TextBox
La clase TextBox implementa un componente de edición de texto, que ocupa
toda la pantalla.
El constructor de la clase es:
TextBox(String title, String text, int maxSize, int constraints)
El parámetro title es un texto que aparecerá en la parte superior de la
pantalla, mientras que el parámetro text es usado para inicializar el texto que
contendrá el TextBox.
5.5. INTERFACES GRÁFICAS DE USUARIO
Métodos
int append(String texto,
Image imagen)
void delete(int posición)
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()
131
Descripción
Añade un elemento
al final de la lista
Elimina el elemento de la
posición especificada
Elimina todas las entradas de la lista
Inserta un elemento en la
posición especificada
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
posicióndeterminada
Almacena el estado de selección
en un array
Obtiene el ´(i)ndice del
elemento seleccionado
Obtiene el texto del elemento
indicado por pos
Determina si est´(a) seleccionado
el elemento
Elimina el comando cmd
Reemplaza el elemento de la
posición 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 selección
por el de array
Reemplaza el estado de la selección
Obtiene el número de elementos
Tabla 5.12: Métodos de la Clase List.
132
CAPÍTULO 5. JAVA 2 MICRO EDITION
El parámetro maxSize especifica el número máximo de caracteres de texto
que pueden ser introducidos en el TextBox.
Por último el parámetro constraints describe las limitaciones a aplicar
sobre el texto.
Estas limitaciones son especificadas según las constantes definidas en la
clase TextField:
• ANY: No hay limitaciones en el texto.
• EMAILADDR: Sólo se puede introducir una dirección de correo electrónico.
• NUMERIC: Sólo se puede introducir un valor numérico.
• PASSWORD: El texto es protegido para que no sea visible.
• PHONENUMBER: Sólo se puede introducir un número de teléfono.
• URL: Sólo se puede introducir una URL.
Un ejemplo de uso sería:
TextBox box = new TextBox(“NOTAS”, “Nota:” , 256, TextField.ANY).
La Clase Form
Un formulario (clase Form) es un componente que actúa como contenedor de
un número indeterminado de objetos. Todos los objetos que puede contener
un formulario derivan de la clase Item.
El número de objetos que se pueden insertar en un formulario es variable pero, teniendo en cuenta el tamaño de las pantallas de los dispositivos
MID, se recomienda que el número sea pequeño para evitar así el scroll que se
produciría si se insertan demasiados objetos en un formulario.
Un mismo Item no puede estar en más de un formulario a la vez. Si,
por ejemplo, se desea usar una misma imagen en más de un formulario, se
debe borrar esa imagen de un formulario antes de insertarla en el que se va a
mostrar por pantalla.
5.5. INTERFACES GRÁFICAS DE USUARIO
133
Si no se cumple esta regla, se lanzaría la excepción IllegalStateException.
La tabla 5.13 de la pág.133 muestra los métodos de la clase Form.
Métodos
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()
Descripción
Añade una imagen al formulario
Añade un item al formulario
Añade un String al formulario
Elimina el Item que ocupa
la posición 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 posición num
Reemplaza el Item que ocupa la
posici´(o)n num
Determina si est seleccionado el elemento
Establece un listener
eventos capturar
Devuelve el número de Items
del formulario
Tabla 5.13: Métodos 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 más que para un formulario se
tiene que implementar la interfaz ItemStateListener que contiene un método
abstracto llamado itemStateChanged(Item item).
Cuando se realiza algún tipo de acción en el algún ítem del formulario se
134
CAPÍTULO 5. JAVA 2 MICRO EDITION
ejecuta el código asociado del método itemStateChanged(Item item).
Un ejemplo de su utilización se puede observar a continuación:
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”);
}
}
}
5.5. INTERFACES GRÁFICAS DE USUARIO
135
La Clase StringItem
La clase StringItem es la clase más simple que deriva de Item. Es una cadena
no modificable 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 parámetros:
• 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 métodos que posee la clase StringItem aparecen en la tabla 5.14 de la
pág. 135
Métodos
int getAppearanceMode()
Font getFont()
String getText()
void setFont(Font fuente)
void setText(String texto)
Descripción
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: Métodos de la Clase StringItem.
La Clase ImageItem
La clase ImageItem brinda la posibilidad de incluir imágenes en un formulario.
136
CAPÍTULO 5. JAVA 2 MICRO EDITION
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 parámetro textoalt especifica una cadena de texto alternativa a la imagen
en caso de que ésta exceda la capacidad de la pantalla. Por su parte, el
parámetro layout indica la posición 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 : Posición por defecto.
• LAYOUT_NEWLINE_AFTER: Imagen posicionada tras un salto de
línea.
• LAYOUT_NEWLINE_BEFORE: Imagen posicionada antes de un salto
de línea.
Los métodos de la clase ImageItem se pueden ver en la tabla 5.15 de la
pág. 137.
La Clase TextField
Un texfield es un campo de texto que puede ser insertado en un formulario y
en el cuál se puede editar texto. Tiene similitud con la clase TextBox. Sus
diferencias son:
5.6. RMS (RECORD MANAGEMENT SYSTEM)
Métodos
String getAltText()
Int getAppearanceMode()
Image getImage()
Int getLayout()
void setAltText(String textoalt)
void setImage(Image imagen)
void setLayout(int layout)
137
Descripción
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: Métodos de la Clase ImageItem.
• Un texfield 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 través de Commands. Por
esta razón, los eventos que produce un TextField se controlan a través
del método itemStateChanged(Item item), mientras que en un TextBox
se controlan en el método commandAction(Command c, Displayable d).
Sin embargo ambas clases (TextBox y TextField) comparten las mismas
restricciones de edición que se vieron anteriormente.
Para crear un TextField sólo hay que invocar al constructor con los siguientes parámetros:
TextField(String etiqueta, String texto, int capacidad, int restricciones).
Otros métodos de esta clase pueden verse en la tabla 5.16 de la pág. 138
5.6
RMS (Record Management System)
El sistema de gestión 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 información.
138
CAPÍTULO 5. JAVA 2 MICRO EDITION
Métodos
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()
Descripción
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 tamaño máximo 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 posición 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 tamaño máximo del TextField
Establece el contenido del TextField
Establece el contenido del TextField
Devuelve el número de caracteres
Tabla 5.16: Métodos de la Clase TextField.
5.6. RMS (RECORD MANAGEMENT SYSTEM)
139
El objetivo del RMS es almacenar datos de tal forma que estén disponibles
una vez que el MIDlet pare su ejecución.
La unidad básica de almacenamiento es el registro (record) que será almacenado en un base de datos especial, denominada almacén de registros (record
store ).
Cuando un MIDlet usa un almacén de registros, primero debe crearlo y
luego añadir los registros. Cuando un registro es añadido a un almacén de
registros, se le asigna un identificador ú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 fig. 5.8 de la pág. 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 fig. 5.9 de la
140
CAPÍTULO 5. JAVA 2 MICRO EDITION
pág 140.
Figura 5.9: Acceso a un RMS a Través 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 más registros.
2. El nombre puede tener un máximo de 32 caracteres.
3. Si una suite es borrada, todos los Record Store también 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 almacén de registros,
donde éstos registros son la unidad básica de información.
5.6. RMS (RECORD MANAGEMENT SYSTEM)
141
Figura 5.10: Esturctura de Un Record Store.
Cada uno de estos registros está formado por dos unidades:
• Un número identificador de registro (Record ID) que es un valor entero
que realiza la función de clave primaria en la base de datos.
• Un array de bytes destinados a almacenar la información deseada.
En la fig. 5.10 de la pág. 141 se ilustra la estructura de un Record Store.
5.6.3
Creación 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 características.
Básicamente se dispone de:
• Capacidad para añadir y borrar registros de un almacén.
• Capacidad para compartir almacenes por parte de todos los MIDlets de
una MIDlet suite.
La clase RecordStore no dispone de ningún constructor, pero posee el método estático:
• static RecordStore openRecordStore(String name, Boolean createIfNeccesary).
142
CAPÍTULO 5. JAVA 2 MICRO EDITION
Este método permite la apertura de un Record Store existente o bien la
creación de un almacén si el parámetro createIfNeccesary tiene el valor true.
También existen otras dos alternativas de este método:
• static RecordStore openRecordStore(String name, boolean createIfNeccesary,
int autorización, boolean writable).
• static RecordStore openRecordStore(String name, String vendorName, String
suiteName).
El primero de ello usa los siguientes parámetros:
• autorización:
— AUTHMODE_PRIVATE : Sólo 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 especifica si el Record Store puede ser modificado
por cualquier MIDlet que pueda acceder a el.
El segundo método se utiliza para abrir un Record Store que está asociado a
alguna MIDlet suite especificada por los parámetros vendorName y suiteName.
El acceso vendrá limitado por el tipo de autorización del Record Store
cuando fue creado.
Al finalizar con el uso de un determinado Record Store hay que cerrar la
comunicación con él. Para ello se utiliza el siguiente método:
• public void closeRecordStore() throws RecordStoreNotFoundException, RecordStoreException.
En la tabla 5.17 de la pág. 143 se pueden apreciar los métodos que proporcionan operaciones con los Record Stores.
5.6. RMS (RECORD MANAGEMENT SYSTEM)
Métodos
String getName()
int getVersion()
long getLastModified()
int getNumRecords()
int getSize()
int getSizeAvailable()
String[] listRecordStores()
void deleteRecordStore
(String name)
RecordEnumeration enumerateRecords(RecordFilter
filter, RecordComparator
comparator, boolean
actualizado)
void addRecordListener
(RecordListener listener)
void removeRecordListener
(RecordListener listener)
143
Descripción
Devuelve el nombre del Record Store
Devuelve la versi n del Record Store
Devuelve la marca temporal
Devuelve el número de registros
Devuelve el número de bytes
ocupado por el Record Store
Devuelve el tama˜(n)o disponible
para añadir registros
Devuelve una lista con los
nombres de los Record Stores
Elimina del dispositivo al Record
Store especificado por el
parámetro name
devuelve un objeto
RecordEnumeration
Añade un listener para
detectar cambios en el Record Store
Elimina un listener
Tabla 5.17: Métodos Generales de la Clase RecordStore.
144
CAPÍTULO 5. JAVA 2 MICRO EDITION
5.6.4
Manipulación de Registros
Una vez creado o abierta la comunicación con el Record Store, se puede leer,
escribir, modificar o borrar registros como se desee. Para ello, se usan los
métodos de la clase RecordStore que se ven en la tabla 5.18 de la pág.144.
Métodos
int addRecord(byte[] datos,
int offset, int numBytes)
void deleteRecord(int id)
Int getNextRecordId()
byte[] getRecord(int id)
int getRecord(int id,
byte[] buffer,int offset)
int getRecordSize(int id)
void setRecord(int id,byte[]
datonuevo, int offset,
int tamaño)
Descripción
Añade 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 identificador id
Devuelve el registro con identificador
id en buffer a partir de offset
Devuelve el tama˜(n)o del registro id
Sustituye el registro id
con el valor de datonuevo
Tabla 5.18: Métodos Para Manejo de Registros.
A continuación 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;
5.6. RMS (RECORD MANAGEMENT SYSTEM)
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 flag) throws MIDletStateChangeException {
}
// este método 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
CAPÍTULO 5. JAVA 2 MICRO EDITION
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”);
5.6. RMS (RECORD MANAGEMENT SYSTEM)
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
CAPÍTULO 5. JAVA 2 MICRO EDITION
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();
5.6. RMS (RECORD MANAGEMENT SYSTEM)
dos = new DataOutputStream(baos);
dos.writeUTF(cliente);
dos.writeUTF(doc);
dos.writeUTF(pun);
dos.flush();
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();
}
149
150
CAPÍTULO 5. JAVA 2 MICRO EDITION
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);
}
}
5.6. RMS (RECORD MANAGEMENT SYSTEM)
151
return form2;
}
public void mostrarDatos(){
d.setCurrent(getForm2());
}
}
En la fig. 5.11 de la pág. 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
CAPÍTULO 5. JAVA 2 MICRO EDITION
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
código:
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 navegación por los registros usando RecordEnumeration es mucho más intuitiva y permite realizar acciones como mover hacia
delante o hacia atrás de una manera muy sencilla.
5.6.6
Búsqueda de Registros
Para realizar una búsqueda eficiente de registros, se debe implementar la interfaz RecordFilter, esta interfaz se encarga de devolver sólo los registros que
coincidan con el patrón de búsqueda especificado.
Para usar esta interfaz se debe implementar necesariamente el método:
public boolean matches(byte [] candidato), el cual se encarga de comparar el
registro candidato pasado como parámetro con el valor que se quiere buscar y
devolverá true en caso de que coincidan.
5.7. COMUNICACIONES EN J2ME
5.7
153
Comunicaciones en J2ME
A pesar de la cantidad de restricciones que soportan los dispositivos MID y
también 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 tamaño 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 permitirán crear y
manejar diferentes conexiones de red. Estas conexiones podrán usar
diferentes formas de comunicación: HTTP, datagramas, sockets, etc.
• El paquete java.io se encargará de proporcionar las clases necesarias
para leer y escribir en estas conexiones.
En la fig. 5.12 de la pág. 154 puede verse la jerarquía de clases que reciben
el nombre de Generic Framework Conection (GFC).
En la raíz del árbol se encuentra la interfaz Connection que representa la
conexión más genérica 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 conexión.
Esta clase puede por sí misma crear cualquier tipo de conexión: Archivos,
Http, socket,etc.
154
CAPÍTULO 5. JAVA 2 MICRO EDITION
Figura 5.12: Jerarquía de Interfaces.
Clase Connector
Como se he dicho anteriormente, el GCF proporciona la clase Connector que
esconde los detalles de la conexión. De esta forma se pueden realizar cualquier tipo de conexión usando sólo esta clase y sin preocuparnos de cómo se
implementa el protocolo requerido.
La conexión se realiza de la siguiente manera:
Connector.open(“protocolo:dirección;parámetros”);
Algunos ejemplo de invocación son:
• Connector.open(“http://direccionquesea.es”);
• Connector.open(“file://autoexec.bat”);
• Connector.open(“socket://direccion:0000”);
La clase Connector se encarga de buscar la clase específica que implemente
el protocolo requerido. Si esta clase se encuentra, el método open() devuelve
5.7. COMUNICACIONES EN J2ME
155
un objeto que implementa la interfaz Connection.
En la tabla 5.19 de la pág. 155 se puede apreciar los métodos de la clase
Connector.
Métodos
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)
Descripción
Crea y abre una conexión
Crea y abre una
conexión con permisos
Crea y abre una conexión
especificando el permiso
y tiempo de espera
Crea y abre una conexión de
entrada devolviendo para
ello un DataInputStream
Crea y abre una conexi´[on de
salida a través de
un DataOutputStream
Crea y abre una conexión de
entrada usando un InputStream
Crea y abre una conexión de
salida devolviendo para
ello un OutputStream
Tabla 5.19: Métodos de la Clase Connector.
Los tipos de permisos se pueden ver en la tabla 5.20 de la pág 156.
La Interfaz Connection
La interfaz Connection se encuentra en lo más alto de la jerarquía de interfaces
del Generic Connection Framework, por lo que cualquier otra interfaz deriva
de ésta.
Una conexión de tipo Connection se crea después de que un objeto Connector invoque al método open(). Como se dijo anteriormente, esta interfaz
representa la conexión más genérica posible por lo que define un sólo método:
156
CAPÍTULO 5. JAVA 2 MICRO EDITION
Modo
READ
READ_WRITE
WRITE
Descripción
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 conexión.
Interfaz InputConnection
La interfaz InputConnection representa una conexión basada en streams de
entrada. Esta interfaz sólo posee dos métodos que devuelven objetos de tipo
InputStreams (ver Tabla).
En el siguiente ejemplo se ilustra cómo podría utilizarse este tipo de conexión:
String url = “www.midireccion.com”;
InputConnection conexión = (InputConnection)Connector.open(url);
DataInputStream dis = conexion.openDataInputStream();
Interfaz OutputConnection
La interfaz OutputConnection representa una conexión basada en streams de
salida. Esta interfaz sólo posee dos métodos que devuelven objetos de tipo
OutputStreams (ver Tabla).
La conexión a través de esta interfaz se realiza de la misma forma a la
interfaz
InputConnection.
5.7. COMUNICACIONES EN J2ME
157
Interfaz StreamConnection
Esta interfaz representa una conexión basada en streams tanto de entrada
como de salida. No añade ningún método nuevo, si no que hereda los métodos
de los interfaces que están por encima de él. Su única misión en la jerarquía
del GCF es representar un tipo de conexión cuyos datos pueden ser tratados
como streams de bytes y en la que es posible leer y escribir.
A continuación un ejemplo de cómo podría utilizarse esta conexión:
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 petición / respuesta. El funcionamiento de este protocolo es el siguiente: El cliente realiza una petición al
servidor y espera a que éste le envíe una respuesta. Normalmente, esta comunicación es la que suele realizarse entre un navegador web (cliente) y un
servidor web (servidor). En este caso la comunicación se realiza a través de
un MIDlet(cliente) y un Servlet(servidor) que recibirá peticiones y devolverá
los resultados.
Una conexión HTTP pasa por tres estados que se pueden ver en la fig.
5.13de la pág 158.
Establecimiento de la Conexión
En este estado es donde se van a establecer los parámetros de la comunicación.
158
CAPÍTULO 5. JAVA 2 MICRO EDITION
Establecimiento
de
conexión
Conectado
Sin
Conexión
Figura 5.13: Estados de una Conexión HTTP.
5.7. COMUNICACIONES EN J2ME
159
El cliente prepara la petición que va a realizar al servidor, además de
negociar con él una serie de parámetros como el formato, idioma, etc.
Existen dos métodos que pueden ser invocados. En la tabla 5.21 de la pág.
159 se pueden apreciar estos métodos.
Método
public void setRequestMethod(String tipo)
public void setRequestProperty
(String clave, String valor)
Descripción
Establece el tipo de petición
Establece una propiedad de la
petición
Tabla 5.21: Métodos en la Etapa de Establecimiento.
El primer método establece el tipo de petición que se va a realizar. Esta
petición puede ser de los tipos indicados en la tabla 5.22 de la pág. 5.22.
Tipo
GET
Descripción
Petición de información en la que
los datos se envían como parte del URL
Petición de información en la que
los datos se envían aparte en un stream
Petición de metainformación
POST
HEAD
Tabla 5.22: Tipos de peticiones.
El segundo método permite negociar entre el cliente y el servidor detalles
de la petición como, por ejemplo, idioma, formato, etc. Estos campos forman
parte de la cabecera de la petición. En la tabla 5.23 de la pág. 160 se pueden
ver algunos de los más importantes.
Peticiones GET
A continuación se muestra un ejemplo en el que se prepara una conexión
mediante la interfaz HttpConnection usando una petición de tipo GET.
//se crea la conexión
String url = http://www.midireccion.com/local?opcion=1&us=usuario&pass=1234;
160
CAPÍTULO 5. JAVA 2 MICRO EDITION
Campo
public void setRequestMethod (String tipo)
User-Agent
Content-Language
Content-Length)
Accept
Connection
Cache-Control
Expires
If-Modified-Since
Descripción
Establece el tipo de petición
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 conexión después de
la petición o se quiere dejar abierta
Sirve para controlar el almacenamiento
de información
Tiempo m ximo para respuesta del servidor
Pregunta si el contenido solicitado se ha
modificado desde una fecha dada
Tabla 5.23: Campos de la Cabezera.
HttpConnection hc = (HttpConnection)Connector.open(url);
//se informa el tipo de conexión a realizar
hc.setRequestMethod(HttpConnection.GET);
// se establece algunos campos en la cabezera
hc.setRequestProperty(“User-Agent”,“Profile/MIDP-2.0
Configuration/CLDC-1.0”);
hc.setRequestProperty(“Content-Language”,“es-ES”);
Como puede apreciarse, la información sobre la petición va incluida en la
cabecera de la dirección URL. El cuerpo de la petición lo forma la cadena:
“opcion=1&us=usuario&pass=1234”.
Esta información va detrás del símbolo “?” situado al final de la dirección
URL. Cada parámetro de la petición va separado del siguiente por el símbolo
“&”.
5.7. COMUNICACIONES EN J2ME
161
Peticiones POST
En este tipo de conexión, el cuerpo de la petición se envía en un stream
después de iniciar la conexión. El siguiente ejemplo muestra cómo se realiza
el envío del cuerpo de la petición:
//se crea la conexión
String url = http://www.midireccion.com;
HttpConnection hc = (HttpConnection)Connector.open(url);
// se informa el tipo de petición a realizar
hc.setRequestMethod(HttpConnection.POST);
//se establece algunos campos de la cabezera
hc.setRequestProperty(“User-Agent”,“Profile/MIDP-2.0
Configuration/CLDC-1.0”);
hc.setRequestProperty(“Content-Language”,“es-ES”);
// se envia el cuerpo de la petición
OutputStream os = hc.openOutputStream();
os.write(opcion=1.getBytes());
os.write(&us=usuario.getBytes());
os.write(&pass=1234.getBytes());
os.flush();
Estado de la Conexión
En este estado se realiza el intercambio de información entre el cliente y el
servidor. En los ejemplos anteriores se ha visto la manera de enviar la petición
al servidor. Ahora se verá cómo se realiza la respuesta del servidor hacia el
cliente.
Respuesta del Servidor
162
CAPÍTULO 5. JAVA 2 MICRO EDITION
Al igual que la petición del cliente posee distintas partes, la respuesta del
servidor se compone de:
• Línea de estado.
• Cabecera.
• Cuerpo de la respuesta.
Para conocer la respuesta del servidor, la interfaz HttpConnection proporciona diversos métodos que permiten conocer las distintas partes de ésta.
La interfaz HttpConnection dispone de treinta y cinco códigos de estado
diferentes.
Básicamente se pueden dividir en cinco clases de la siguiente manera:
• 1xx: Código de información.
• 2xx: Código de éxito.
• 3xx: Código de redirección.
• 4xx: Código de error del cliente.
• 5xx: Código de error del servidor.
Por ejemplo, el código 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 código de estado
y de un mensaje de respuesta. Este mensaje es devuelto al invocar el método
getResponseMessage().
5.7. COMUNICACIONES EN J2ME
163
Estado de Cierre
La conexión entra en este estado una vez que se termina la comunicación entre
el cliente y el servidor invocando al método close().
A continuacion se verá un ejemplo donde se produce una petición mediante
una petición POST, se describirán tanto el codigo del MIDlet como del Servlet
que recibe la peticion y devuelve una respuesta.
Código 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
CAPÍTULO 5. JAVA 2 MICRO EDITION
}
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”;
5.7. COMUNICACIONES EN J2ME
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 conexión 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”,”ProfileMIDP-2.0 Configuration/CLDC1.0”);
hc.setRequestProperty(“Content-Type”,“application/octect-stream”);
os = hc.openOutputStream();
os.write(“usuario=qm”.getBytes());
os.write(“&clave=hi”.getBytes());
os.flush();
// 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()));
}
finally {
if (in != null) {
166
CAPÍTULO 5. JAVA 2 MICRO EDITION
try { in.close(); }
catch (IOException ioe) {}
}
if (hc != null) {
try { hc.close(); }
catch (IOException ioe) {}
}
}
mDisplay.setCurrent(resultsForm);
}
Código 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;
5.7. COMUNICACIONES EN J2ME
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.”);
}
}
}
167
Capítulo 6
Introducción 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 generación de los sistemas
de administración de bases de datos relacionales (RDBMS ).
En los últimos tiempos ha surgido una nueva base de datos llamada “Universal”, la cuál es capaz de almacenar y hacer búsquedas no solamente de
datos alfanuméricos sino también de imágenes, audio, video y otros objetos.
Esta ventaja de las bases de datos universales abre un gran número de
oportunidades que permiten mejorar tanto los servicios como las aplicaciones.
Se puede definir 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 modificar 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 información acerca de cómo las
entidades están lógicamente relacionadas entre sí.
Las bases son cualquier conjunto de datos organizados para su almacenamiento en la memoria de un ordenador, diseñado para facilitar su mantenimiento y acceso de una manera estándar. Los datos suelen aparecer en forma
169
170
CAPÍTULO 6. INTRODUCCIÓN AL DB2
de texto, números o gráficos.
Otra definición más completa de bases de datos afirma que es un “conjunto
exhaustivo, no redundante, de datos estructurados, organizados independientemente de su utilización y su implementación en máquina, accesibles en tiempo
real y compatibles con usuarios concurrentes con necesidad de información
diferente y no predecible en tiempo, donde la información 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
Automatización de:
• El mantenimiento.
• Cualquier generación de información.
• Cualquier consulta sobre dicha información.
6.1.2
Ventajas de las Bases de Datos
Algunas ventajas de las bases de datos se describen a continuación:
Ahorro de Espacio: No hacen falta archivos de papeles que pudieran
ocupar mucho espacio.
Velocidad: Con la utilización de las bases de datos se pueden modificar,
consultar datos con una velocidad mucho mayor que realizándolo manualmente.
Ahorro de trabajo: ya que las máquinas son encargadas de manejar estas
bases y no se necesitan manejar archivos a mano, existe un ahorro de trabajo
humano.
Actualización: Se dispone en cualquier momento de información precisa
y al día.
Comodidad: Al tener la información en un mismo sitio, se ahorrará tiempo y trabajo.
6.2.
SISTEMA DE ADMINISTRACIÓN DE BASES DE DATOS
171
Disminución de la Redundancia: La duplicación de los datos implica
mayor trabajo en el mantenimiento. Gracias a que las bases de datos disminiyen la redundancia también se disminuye el trabajo.
Compartición de Datos: Se trata de datos actuales, ya que al estar
centralizados, se puede tener acceso a los datos actualizados en prácticamente
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
acción sobre dicha base de datos.
Posibilidad de Mantener la Integridad: En una base de datos se debe
mantener una coherencia.
Esto se controlará mediante:
• Máscaras.
• Reglas de validación.
6.2
Sistema de Administración de Bases de Datos
Una base de datos es una colección de tablas y objetos relacionados entre sí y
organizados como un grupo. La estructura de una base de datos se muestra
en la fig.6.1 de la pág. 172.
Un DBMS es un conjunto de programas que maneja todos los accesos a
las bases de datos; ver fig. 6.2 de la pág 172.
Funciones de un DBMS:
— Definición de datos.
— Manipulación de datos.
— Seguridad e integridad de los datos.
— Recuperación y concurrencia de los datos.
— Diccionario de datos.
— Desempeño.
172
CAPÍTULO 6. INTRODUCCIÓN AL DB2
Figura 6.1: Estructura de Una Base de Datos
Figura 6.2: Sistema de Administracion de Bases de Datos
6.3. ORGANIZACIÓN DE BASES DE DATOS
6.3
173
Organización de Bases de Datos
Los modelos más comunes de organización de Bases de Datos son:
• Jerárquico.
• En Red.
• Relacional.
• Orientado a Objetos.
6.3.1
Bases de Datos Jerárquicas
Estructura los campos en nodos en una estructura jerárquica. 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 relación 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 raíz, 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 dirección a un nodo hijo.
Por Ejemplo: Un Sistema de Reservaciones de una Línea Aérea (ver fig.
6.3 de la pág. 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 Número de Vuelo. El Número de Vuelo tendrá también Nodos
Hijos, que son los Pasajeros.
Limitaciones de las Base de Datos Jerárquicas
• Al borrar un nodo padre, desaparecen también sus nodos subordinados.
• Sólo podrá añadirse un nodo hijo, si existe el nodo padre.
• Pero lo más significativo es la rigidez de su estructura: sólo un padre
por hijo y ausencia de relaciones entre los nodos hijos.
174
CAPÍTULO 6. INTRODUCCIÓN AL DB2
Figura 6.3: Modelo de Bases de Datos Jerárquica
6.3.2
Bases de Datos en Red
Se trata también de una organización jerárquica de nodos, pero un nodo hijo
puede tener más de un solo nodo padre (relación muchos a muchos). Existen
los punteros, que son conexiones adicionales entre nodos padres y nodos hijos,
que permiten acceder a un nodo por vías distintas accediendo al mismo en
dirección descendente por las diversas ramas.
Representa una mejora al modelo jerárquico.
Por ejemplo:Los vendedores destacados para distribuir determinados productos en algunas ciudades pueden ilustrar este modelo (ver fig. 6.4 de la pág.
175).
Cada Producto puede ser distribuido por más de un Vendedor, así mismo
cada Vendedor puede encargarse de diferentes Ciudades.
6.3.3
Bases de Datos Relacional
Esta organización ofrece la mayor flexibilidad ya que los datos se almacenan en
Tablas diferentes, conformadas así mismo por Filas y Columnas. Una tabla
se denomina relación. En una Tabla las Filas contienen los Registros. Las
Columnas representan los Campos. Las Tablas relacionadas poseen un campo
común, el Campo Clave, mediante el cual la información almacenada en una
tabla puede enlazarse con la información almacenada en otra.
6.3. ORGANIZACIÓN 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 Organización de Bases de Datos Relacional es la
más difundida en la actualidad debido a su sencillez para realizar operaciones
de adición, eliminación y modificación en contraste con la mayor rigidez de las
Organizaciones Jerárquicas y de Red.
Por ejemplo: En un pequeño negocio, se puede contar con una Tabla de
Clientes y Tabla de Pedidos (ver fig. 6.5 de la pág. 176).
Las órdenes que pertenecen a un determinado cliente son identificadas
colocando el campo de identificación 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 semántica.
• No soporta tipos definidos por el ususarios (sólo Dominios).
• No soporta Recursividad.
• Falta de Procesamiento/Disparadores.
• No admite Herencia.
176
CAPÍTULO 6. INTRODUCCIÓN AL DB2
Figura 6.5: Modelo de Bases de Datos Relacional
6.4
Introducción a DB2 UDB
DB2 UDB Universal Database es una Base de Datos Universal. Es completamente escalable, veloz y confiable.
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 flexible para servir a los
medianos y pequeños negocios.
DB2 UDB es un sistema manejador de base de datos relacional fuertemente
escalable. Es suficientemente flexible 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. INTRODUCCIÓN A DB2 UDB
6.4.1
177
Características Generales del DB2 UDB
DB2 UDB es el producto principal de la estrategia de Data Management de
IBM.
DB2 UDB es un sistema para administración de Bases de Datos Relacionales (RDBMS). Es multiplataforma, especialmente diseñada para ambientes
distribuidos, permitiendo que los usuarios locales compartan información con
los recursos centrales. Es el sistema de gestión de datos que entrega una plataforma de base de datos flexible y rentable para construir un sistema robusto
para aplicaciones de gestión.
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 características de Integridad, asegurando la protección
de los datos aún en caso de que los sistemas sufran un colapso, y de Seguridad
permitiendo realizar respaldos en línea con distintos grados de granularidad,
sin que esto afecte la disponibilidad de acceso a los datos por parte de los
usuarios.
Múltiples Usos
Provee la capacidad de hacer frente a múltiples necesidades, desde Procesamiento Transaccional de Misión Crítica (OLTP), hasta análisis exhaustivo de
los datos para el soporte a la toma de decisiones (OLAP).
Escalabilidad
Sus características distintivas de Escalabilidad le permiten almacenar información en un amplio rango de equipos, desde un PC portátil hasta un complejo
ambiente de mainframes procesando en paralelo.
178
CAPÍTULO 6. INTRODUCCIÓN AL DB2
Web Enabled Para e-Business
Incluye tecnología basada en Web que permite generar aplicaciones en las
Intranets y responder a las oportunidades de negocios disponibles en Internet.
Facilidad de Instalación y Uso
La primera versión de DB2 para NT fue reconocida en el mercado como una
base de datos muy poderosa, pero difícil de instalar y usar.
En esta versión (DB2 UDB V. 8.1), IBM agregó muchas herramientas
gráficas para facilitar el uso para los usuarios, como también para los administradores y desarrolladores. Dicha versión incluye guías para operaciones como
instalación, configuración de performance, setup, etc. Además, se agregaron
herramientas para facilitar las tareas de integración con otras bases de datos,
tecnologías de networking y desarrollo de aplicaciones.
Universalidad
DB2 UDB es, además, 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, Imágenes y Video (AIV Extender) (ver fig. 6.6 de la
pág.179) .
• Documentos XML ( XML Extender) (ver fig. 6.7 de la pág.179).
Funciones Complementarias del DB2 UDB
Conectividad
Las herramientas de conectividad permiten acceder a los datos más allá de
donde ellos se encuentren. El slogan cualquier cliente, a cualquier servidor,
6.4. INTRODUCCIÓN A DB2 UDB
Figura 6.6: AIV Extender
Figura 6.7: XML Extender
179
180
CAPÍTULO 6. INTRODUCCIÓN AL DB2
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. Además, 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 Versión 8.1
La versión 8.1 ofrece un soporte más potente para Business Intelligence, Gestión de Datos y Soluciones e-business.
DB2 Universal Database Versión 8.1 contiene muchas características nuevas, que incluyen el Centro de desarrollo, funciones ampliadas de XML Extender, soporte de Linux para DB2 Warehouse Manager, integración de Spatial
Extender con herramientas de IBM Business Intelligence, un nuevo Centro de
duplicación, mejoras de enlace y rendimiento de DB2 Data Links Manager.
Nuevas herramientas de gestión y supervisión de bases de datos, soporte de 64
bits ampliado y nuevos asistentes de Instalación de DB2 y Centro de control
de DB2.
6.5.1
Centro de Desarrollo
En la versión 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 definidas por el usuario como se muestra en la fig.
6.8 de la pág. 181. También es posible correlacionar tipos estructurados de
los Enterprise JavaBeans. Los asistentes simplifican las tareas de desarrollo.
Las nuevas características 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 VERSIÓN 8.1
181
• Depurador de SQL para depurar rutinas; incluye vistas para puntos de
interrupción, variables y pila de llamadas.
• Una interfaz mejorada para controlar el entorno de desarrollo.
• Asistentes para construir funciones definidas por el usuario para MQSeries, fuentes de datos OLE DB y documentos XML.
• Asistentes para exportar, importar y desplegar rutinas e información de
proyectos Productos y Paquetes Nuevos.
Figura 6.8: Centro de Desarrollo
6.5.2
Mejoras en XML Extender
Se han añadido nuevas características 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
CAPÍTULO 6. INTRODUCCIÓN AL DB2
6.5.3
DB2 Warehouse Manager
Se han añadido nuevas características y mejoras a DB2 Warehouse Manager :
Con el soporte de carga paralela nativa para DB2 Universal Database Enterprise Server Edition, es posible cargar grandes volúmenes de datos con más
rapidez.
DB2 Warehouse Manager tiene capacidades ampliadas, por lo que se puede
incrementar y mejorar el rendimiento de las operaciones de depósito, manipular y localizar metadatos más deprisa, y ejecutar el agente de depósito,
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 Depósito de Datos de DB2
Se han añadido nuevas características al Centro de depósito de datos:
El soporte de servidor de depósito se amplía a AIX. El servidor de depósito y el iniciador de sesiones de depósito, que se ejecutan como servicios en
Windows, se ejecutan como daemons en AIX.
Es posible exportar e importar metadatos del lenguaje de código 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
definiendo y habilitando una planificación y un flujo 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 depósito de datos sin sustituir la tabla completa ni grabar
código adicional.
Ahora, la Guía de aprendizaje de Business Intelligence se compone de dos
guías de aprendizaje más cortas: Guía de aprendizaje de Business Intelligence:
6.5. DB2 UDB VERSIÓN 8.1
183
Introducción al Centro de depósito de datos y Guía de aprendizaje de Business
Intelligence: Lecciones ampliadas sobre depósito de datos.
6.5.5
Asistentes de DB2
Asistente para la Configuración de DB2
La instalación de DB2 en plataformas Windows y UNIX resulta más fácil
mediante la utilización del Asistente para la configuración de DB2. Esta interfaz gráfica permite instalar productos DB2 directamente o crear archivos
de respuestas para permitir una instalación posterior. En los sistemas UNIX,
también se puede utilizar el Asistente para la configuración de DB2 para realizar funciones de gestión de instancias.
Asistentes del Centro de Control
En DB2 Versión 8.1, los asistentes que están disponibles en las Herramientas
de administración se han ampliado para abarcar un ámbito más amplio de
funciones, en comparación con las de que se disponía en versiones anteriores
de DB2. Por ejemplo, un asistente de DB2 Versión 8.1 brinda el conjunto
total de opciones disponibles para crear una tabla.
Como se puede observar en la fig.6.9 de la pag.184 el asistente para creación
de tablas, que va guiando paso a paso al usuario a través de una interfaz
amigable, permitiendo crear campos de la tabla, definir una clave, definir 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, modificar indices, etc. Donde un usuario avanzado puede escribir
directamente la sentencia y ejecutarla; ver fig.6.10de la pag.184.
Para usuarios menos avanzados también se dispone de un asistente llamado “SQL ASSIST ” que va ayudando al usuario para la realización de una
consulta.
184
CAPÍTULO 6. INTRODUCCIÓN AL DB2
Figura 6.9: Asistente Para Crear Tabla
Figura 6.10: Centro de Mandatos
Capítulo 7
WebSphere Studio
7.1
¿Que es WebSphere?
• IBM WebSphere es una plataforma de IBM para desarrollo y gestión de
sitios web y aplicaciones destinadas al comercio electrónico.
• 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 estándares abiertos de mercado.
• WebSphere es ideal para todas las fases de un e-business, comenzando
desde pequeños 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. También permite la
diferenciación de niveles de servicio con base en el tipo de cliente.
185
186
CAPÍTULO 7. WEBSPHERE STUDIO
7.2
Plataforma de Software
La creciente complejidad de los aplicativos de e-business crea muchos desafíos.
Los aplicativos deben ser escalables, fiables y se deben integrar completamente con los sistemas back-end para proteger las inversiones existentes. El
equipo de desarrollo debe poseer las más actualizadas habilidades de programación para acompañar el ciclo de vida del e-business.
Se necesita una plataforma completa, escalable y flexible que proporcione
soporte a la construcción y diseminación 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 simplifique
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 rápidos de nuevos aplicativos utilizando un paradigma de desarrollo basado en reglas.
• Proporciona código pre-construido, pre-testeado.
• Proporciona herramientas especializadas para página Web y desarrollo
de módulos migrables.
Adicionalmente, servicios basados en estándares Web permiten mezclar y
combinar componentes funcionales de diferentes orígenes de tal forma que se
puede proveer nuevos procesos y servicios al mercado rápida y eficientemente.
La capacidad de un portal de negocios tiene importancia crítica para permitir que las personas interactúen y transaccionen de forma personalizada con
diversos recursos de negocios. Empieza dejando a la medida los ambientes
de usuarios para sus necesidades específicas, integrándolo entonces con otros
usuarios para permitir colaboración en tiempo real, y con los diversos ambientes de TI.
Todo esto permite que las personas trabajen en conjunto de forma más
productiva mientras actúan sobre la información 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 dificultades en cuanto al tiempo, limitaciones organizacionales o fronteras geográficas.
Con el software With WebSphere Commerce, se establecen relaciones más
estrechas, más 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 continúen mañana.
7.2.2
WebSphere for Commerce - Soluciones B2C
El software WebSphere Commerce le permite ir a la línea de las ventas online
a los consumidores.
Crea campañas de marketing dinámicas, fija como objetivo diferentes segmentos de mercado, elabora promociones de producto personalizadas, y mejora
el servicio a clientes.
Esta solución ayuda a crear rápidamente y mantener eficientemente un
sitio interactivo, de alto volumen.
WebSphere Commerce proporciona:
• Personalización del B2B para ayudar a administrar las relaciones de
negocio.
• Tecnología de ventas asistidas para conducir a los clientes y contratistas
a través de la agrupación de requisitos y del proceso de selección del
producto.
• Herramientas de cooperación online y de formación de equipo virtual
para mejorar la eficacia de contratistas comerciales, canal y clientes.
• Administración de pedidos anticipado resultando en capacidades de optimización de operaciones.
188
CAPÍTULO 7. WEBSPHERE STUDIO
• Capacidades avanzadas de inteligencia de negocios para decisiones fundamentas del e-business.
7.2.3
WebSphere for Commerce-Soluciones de Portal
La integración del WebSphere Commerce y WebSphere Portal permite que las
empresas se dirijan a múltiples sectores con necesidades de personalización positivas de soluciones de comercio tanto para las áreas B2B o B2C. Actualmente,
muchas empresas crean sitios separados para cada división, lo que demanda
mucho tiempo y cuesta caro.
El abordaje racionalizado proporciona rápido retorno de inversión al eliminar la necesidad de que la empresa mantenga múltiples sitios. Las empresas
también aumentan la eficiencia de interacciones con clientes y contratistas, lo
que mejora la retención del cliente.
Los productos IBM WebSphere Commerce y WebSphere Portal proporcionan un único punto de interacción con información dinámica 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 eficientemente información online, servicios
y aplicativos para contratistas de negocio y proveedores a lo largo de
múltiples divisiones en un portal.
• Ambientes B2C o de ventas al por menor: obtener ventas cruzadas e
impulsar los beneficios, mediante la oferta de acceso a productos, información y servicios desde la Web y de dispositivos inalámbricos, así como
acceso consolidado a catálogos múltiples.
Con un portal de e-commerce integrado, se les puede ofrecer a los clientes, contratistas y proveedores acceso 24x7 a los aplicativos online - rápida y
fácilmente.
7.2. PLATAFORMA DE SOFTWARE
7.2.4
189
WebSphere for Commerce-Soluciones Digital Media
Empresas de medios con volúmenes crecientes de activos digitales -fotos, vídeo
clips, archivos en audio, ilustraciones e imágenes animadas- enfrentan nuevas
exigencias reguladoras y el desafío de colocar esos activos disponibles online. El software WebSphere permite administrar estos activos digitales más
eficazmente, alcanzando clientes en todos el mundo a través 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 tecnología 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 márgenes de beneficios.
WebSphere ofrece un amplio portafolio de soluciones clasificadas en tres
áreas críticas:
• 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
CAPÍTULO 7. WEBSPHERE STUDIO
— WebSphere Commerce.
• Integración 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 término se refiere de manera popular a uno de sus productos específicos: 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 estándar APIs
del Workbenchs.
La familia del WebSphere Studio tiene actualmente los siguientes miembros
(ver fig. 7.1 de la pág. 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 común de herramientas, por ejemplo
para el desarrollo Java y Web (ver fig. 7.2 de la pág. 191).
7.3. PRODUCTOS WEBSPHERE STUDIO
Figura 7.1: La familia del WebSphere Studio.
Figura 7.2: WebSphere Studio, entorno de desarrollo .
191
192
CAPÍTULO 7. WEBSPHERE STUDIO
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 diseñada por IBM y lanzada
a la comunidad de open-source (código abierto).
Este Workbench se ha diseñado para proveer la máxima flexibilidad en el
desarrollo de las herramientas y las nuevas tecnologías 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 también proporciona la ayuda
para cada fase del desarrollo del ciclo vida.
Los líderes 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 integración de herramienta cons-
7.4.
WEBSPHERE STUDIO APPLICATION DEVELOPER
193
truida por una comunidad abierta de los abastecedores de la herramienta.
Eclipse se ha diseñado a partir de la necesidad de Construir, Integrar los
desarrollos útiles del uso de las tecnologías.
El valor más importante que tiene esta plataforma es: el rápido desarrollo
de herramienta siendo esta una de las características basadas en un modelo
plug-in (con enchufe) (ver fig. 7.3 de la pág. 193).
Figura 7.3: Plataforma de Eclipse.
7.4.1
Ventajas de Utilizar a WebSphere Studio Application
Developer
La ventaja fundamental consiste en la integración de todos los entornos de
desarrollo Java, Web en una única plataforma de desarrollo.
J2EE:
• Herramientas de importación/exportación, generación de código, edición
de deployment descriptors estandars, extensiones y bindings (mapeos)
específicos para WebSphere Application Server (WAS).
194
CAPÍTULO 7. WEBSPHERE STUDIO
• Herramienta de mapeo EJB-RDB soportanto tanto top-down, como
bottom-up y meet-in-the-middle.
• Herramientas de edición gráfica de esquemas de bases de datos.
• Herramientas para la creación, edición y validación de ficheros EAR.
• Editores para deployment descriptors (ejb-jar.xml y application.xml).
Desarrollo Java:
• Nuevo Editor Visual Java para GUIs (Swing y AWT).
• Nueva generación de JavaDoc.
• Soporte JDK 1.3.
• Capacidad de utilizar diferentes JREs.
• Compilación incremental automática.
• Posibilidad de ejecutar código incluso con errores.
• Protección contra crashs y auto-recovery.
• Error Reporting y corrección.
• Editor Java con asistente contextual.
• Herramientas de refactoring de código.
• Búsquedas inteligentes y herramientas para comparar código y ”merge”.
• Scrapbook para evaluación rápida de código.
Web Services:
• Nuevo soporte UDDI Version 2.
• Soporte UDDI privado.
• Nuevo soporte de WSIL.
• Posibilidad de crear un web service a partir de un fichero ISD.
7.4.
WEBSPHERE STUDIO APPLICATION DEVELOPER
195
• Visualización de UDDI business entry para localización de web services
existentes.
• Creación de web services a partir de código existente (JavaBeans, RLSs,
DB2 XML Extender calls, procedimientos almacenados DB2 y queries
SQL).
• Crear wrappers SOAP y HTTP GET/POST de código existente.
• Generación de proxies desde el Web Services Client/Wizard para tratar
mensajes SOAP.
• Generación de una aplicación 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 menús pop-up para la creación y consumo de web services, además de los típicos wizards.
XML:
• Entorno totalmente visual.
• Editor de XML con posibilidades de validación de documentos.
• Editor de DTD con posibilidades de validación de documentos.
• Editor de XML schemas.
• Editor de XSL.
• Debugger de XSL y herramienta de transformación para aplicar XSL a
XML.
• Editor de mapping XML - XML.
• Wizard de creación de XML a partir de queries SQL.
• Editor de mapping RDB - XML.
196
CAPÍTULO 7. WEBSPHERE STUDIO
Desarrollo web:
• Nuevo soporte para XHTML y Struts.
• Nuevo entorno visual de construcción de aplicaciones basado en struts.
• Editor visual de HTML y JSPs.
• Edición y validación de JavaScript.
• Soporte de JSP Custom tags (taglibs) 1.2.
• Edición de imágenes y animaciones.
• Edición de CSS.
• Importación via HTTP/FTP.
• Exportación vía FTP a un servidor.
• Visualización de links, broken links, etc.
• Wizards para la creación de servlets.
• Wizards para la creación de proyectos J2EE.
• Wizards para la creación de aplicaciones web.
Testing y Deployment:
• Incrementa la productividad de forma muy importante.
• Entorno ligero de carga rápida.
• Permite pruebas unitarias locales.
• Permite debugger de código en el servidor a través del debugger integrado.
• Permite configurar 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.
WEBSPHERE STUDIO APPLICATION DEVELOPER
197
Tracing, Monitoring y Performance:
• Performance Analyzer muestra los tiempos de ejecución y ayuda a detectar memory leaks.
• Muestra información de los objetos existentes.
• Tiene capacidades de “Pattern extraction”.
• Es posible monitorizar varios procesos simultaneamente, incluso corriendo en diferentes máquinas.
• Codificación por colores de las clases.
• Presentación de los resultados en modo gráfico y estadístico.
• Soporte de profiling a nivel de objetos.
• Análisis de los logs de WebSphere Application Server e interacción con
la bases de datos de problemas.
• Edición de items en la base de datos de problemas.
Debugger:
• Muy similar al existente en VisualAge for Java.
• Permite realizar debug tanto a código local como a código 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
CAPÍTULO 7. WEBSPHERE STUDIO
• Ejecutar el programa.
• Localizar errores.
Para crear un proyecto Java se debe seleccionar archivo → Nuevo → Proyecto, de desplegará el cuadro de diálogo de Nuevo Proyecto, se debe seleccionar Java y proyecto Java en el diálogo y hacer click en siguiente para iniciar el
asistente de creación de proyectos. Luego se debe indicar en la primer página
el nombre del proyecto y click en aceptar; (ver fig.7.4 de la pag. 198).
Figura 7.4: Asistente de Proyecto Java.
El proyecto es creado con las opciones que se hayan configurados anteriormente en las preferencias o con las que tiene por defecto. Estas preferencias
puede ser modificadas dirigiendose al menu Ventana → Preferencias y luego
Java → Proyecto Nuevo.
Se pueden agregar paquetes al proyecto para tener una estructura más
ordenada de la aplicación. Para ello se debe seleccionar en la vista de exploración de paquetes Nuevo → Paquete en el menú. En la ventana de diálogo se
tiene que indicar el nombre del paquete y hacer clic en finalizar; ver fig. 7.5
de la pag. 199.
Luego de haber finalizado el código 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 código se abre el diálogo ejecutar
configuraciones. Como se puede ver en la fig. 7.6 de la pág. 200 se puede
seleccionar el tipo de configuración para ejecutar el programa.
7.5
7.5.1
WebSphere Application Server
Introducción
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 tecnologías diferentes preservando las inversiones hechas en tecnología previamente disponible en la organización, soporta normas
abiertas vigentes en las organizaciones, proporciona soporte pleno a la plataforma abierta Java 2 y Java 2 Enterprise Edition (J2EE) y también provee
soporte para servicios bajo normas abiertas en la Web [3].
WebSphere Application Server, es una plataforma de alto desempeño y extrema escalabilidad para diseminar aplicativos dinámicos de e-business, pro-
200
CAPÍTULO 7. WEBSPHERE STUDIO
Figura 7.6: Diálogo de Configuración de Ejecución.
porciona las funciones esenciales de e-business de manipulación de transacciones y ampliación de datos back-end del negocio y aplicativos para la Web.
La plataforma ayuda a construir aplicativos que ejecutan esas funciones
con seguridad sólida, fiabilidad y escalabilidad.
7.5.2
WebSphere Application Server Como Plataforma Para
el Comercio Electrónico
Brinda un soporte amplio para aplicaciones de comercio electrónico. Se caracteriza por su flexibilidad 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 (Tecnología de Información), para aprovechar al
máximo 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 fig. 7.7 de la pág. 201 se puede observar la plataforma del Software
7.5. WEBSPHERE APPLICATION SERVER
201
Figura 7.7: WebSphere para e-bussines.
de WebSphere para e-bussines.
7.5.3
Application Server - Advanced Edition
La Edición Avanzada es la oferta del principal servidor de aplicativo dirigido
a desarrolladores profesionales de tecnología Java que necesitan funcionalidad
de servicios J2EE y Web para aplicativos dinámicos de e-business.
Esta Edición del WebSphere Application Server, está disponible en tres
configuraciones:
• Edición Avanzada:
— Proporciona integración sólida a las bases de datos, middleware
orientado a mensajes, y sistemas preexistentes y aplicativos, en conjunto con soporte de agrupación. Esta configuración se ajusta a la
mayoría 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 administración remota.
• Edición Avanzada del Single Server :
202
CAPÍTULO 7. WEBSPHERE STUDIO
— Proporciona el mismo modelo de programación esencial J2EE y
Web Services con administración simplificada. Esta configuración
interesa a departamentos, negocios de tamaño mediano y aplicativos piloto que necesitan un coste bajo, opción de ejecución rápida,
distribución de carga de trabajo o administración remota asociados
a administración de multi-servidor.
• Edición Avanzada del IBM WebSphere Application Server, para Linux
en zSeries:
— La Edición Avanzada del WebSphere Application Server, para Linux en zSeries continúa cumpliendo el compromiso de IBM en cuanto a mantener cobertura amplia para plataformas para el WebSphere Application Server.
— Este producto WebSphere tiene la combinación potente de un conjunto de dispositivos rico y soporte a estándares abiertos del WebSphere Application Server y el ambiente operacional familiar del sistema operativo Linux.
— También contiene los recursos de administración, alta fiabilidad, y
la intensa velocidad de comunicación de datos internos del hardware
de la plataforma zSeries.
7.5.4
Application Server - Enterprise Edition
La Edición empresarial del IBM WebSphere Application Server, en junto con
IBM WebSphere Studio Application Developer Integration Edition, ofrece una
combinación potente de tiempo de ejecución y herramienta que permite integrar activos IT existentes, mejorar la productividad del desarrollador y crear
y mantener aplicativos de e-business flexibles.
Juntos, el IBM’s WebSphere Application Server Enterprise Edition y el
WebSphere Studio Application Developer Integration Edition permiten a los
desarrolladores la capacidad de:
• Coreografiar visualmente y componer servicios de la Web y componentes
de aplicativo J2EE a través 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.
7.5. WEBSPHERE APPLICATION SERVER
203
• Obtener una infraestructura completa de servicios Web que impulse un
ambiente único, eficaz en cuanto a coste de tiempo de ejecución del
servidor de aplicativo administrativo y operacional.
• Evitar la repetición del desarrollo y diseminación de aplicativos debido a
condiciones cambiantes del mercado, separando las políticas del negocio
de la lógica de aplicativos esenciales.
• Crear una paleta de componentes de aplicativos que puede ser rápidamente montada para desarrollar nuevos aplicativos fácilmente publicada
como servicio Web.
7.5.5
Application Server - Standard Edition
La Edición Estándar para desarrolladores de la web y autores de contenido
incluye mejorías de facilidad de uso en toda su extensión, 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 dinámicos 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 configuración XML de fácil lectura para determinar si la
petición la debe gestionar el servidor Web o el servidor de aplicaciones. Utiliza
el protocolo HTTP estándar 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 definir varios servidores
de aplicaciones, cada uno de ellos ejecutándose en su propia Máquina Virtual
Java (JVM).
204
7.5.8
CAPÍTULO 7. WEBSPHERE STUDIO
Contenedor de EJB
El contenedor de EJB proporciona los servicios de tiempo de ejecución necesarios para desplegar y manejar componentes EJB, conocidos como enterprise
beans. Es un proceso de servidor que maneja peticiones para beans de sesión
y beans de entidad.
Los enterprise beans (dentro de los módulos 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
ejecución 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 recuperación de datos para los
beans que contiene. Un solo contenedor puede gestionar más 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 presentación y el control de
la interacción del usuario con los datos de aplicación subyacentes y la lógica
empresarial.
El contenedor Web procesa servlets, archivos JSP y otros tipos de inclusiones de servidor. Los servlets anteriores a J2EE se ejecutarán en un motor
de servlets. Cada contenedor Web contiene automáticamente un único gestor
de sesiones.
Cuando se manejan los servlets, el contenedor Web crea un objeto de
petición y un objeto de respuesta, e invoca el método de servicio de servlets.
El contenedor Web invoca el método destroy() del servlet cuando corresponda
y descarga el servlet, y después la JVM ejecuta la recolección de basura.
7.5. WEBSPHERE APPLICATION SERVER
7.5.10
205
Contenedor de Clientes de Aplicaciones
Los clientes de aplicaciones son programas Java que se ejecutan normalmente
en un sistema de sobremesa con una interfaz gráfica 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 máquinas cliente.
Este programa sigue el mismo modelo de programación Java que otros
programas Java; no obstante, el cliente de aplicaciones J2EE depende del
tiempo de ejecución del cliente de aplicaciones para configurar su entorno de
ejecución, 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 configuración que permite que una única
máquina de sistema principal parezca varias máquinas 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 máquina física.
Los sistemas principales virtuales permiten al administrador asociar aplicaciones Web con un sistema principal particular configurado para la máquina
que ejecuta la aplicación.
7.5.12
Virtual Hosts (Hosts Virtuales)
Un host virtual es una configuración que permite a una sola máquina host
aparentar ser múltiples máquinas hosts. Permite que una sola máquina física
configure y administre independientemente varias aplicaciones administradas.
No está asociado a un nodo particular (máquina). Es una configuración, diferente de un “objeto vivo”, indicando que puede crearse, pero no arrancarse o
detenerse.
Cada host virtual tiene un nombre lógico y una lista de uno o más seudóni-
206
CAPÍTULO 7. WEBSPHERE STUDIO
mos de DNS por los cuales es conocido. Un seudónimo de DNS es el nombre
TCP/IP del host y el número del puerto que use la petición del servlet, por
ejemplo su nombre Host:80.
El WebSphere Application Server proporciona un host virtual predefinido, denominado “el default_host”, con algunos seudónimos comunes, como
el IP de la máquina, nombre corto del host, y el nombre del host completo. El seudónimo comprende la primera parte del camino para el acceso a un recurso, como un servlet. Por ejemplo, localhost:80 en la petición
http://localhost:80/servlet/snoop.
Los hosts virtuales le permiten al administrador aislar y manejar independientemente los múltiples grupos de recursos en la misma máquina física.
7.6
Workplace Client Technology Micro Edition
Workplace Client Technology Micro Edition (WCTME) es una plataforma intergrada para la extensión de aplicaciones empresariales existentes hacia dispositivos clientes manejados por servidor como ser un computador de escritorio,
sistemas móviles, PDAs, y otros dispositivos móviles 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 teléfonos
celulares, PDAs y otros dispositivos con teclado, móviles 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 programación usando los estándares de la industria y sin tener
que volver a reescribir todo usando estos dispositivos.
La plataforma WCTME está construido como una combinación 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 aplicación más genérica) al igual que el modelo basado en navegador. Eclipse es una plataforma
para la construcción 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 implementación de IBM de
la especificación J2ME que cumple con la autorización y líneas guias funcionales definidas 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 librerías y funciones
para habilitar a clientes y asociados a crear versiones más a medida de la Java
run times específica, sin necesariamente tener que cumplir con estándares
establecidos.
7.6.3
J9
La J9 es una implementación independiente de IBM de la Maquina Virtual
de Java. La combinación de la J9 junto con la configuración y los perfiles
conforman el ambiente de ejecución o run times.
Las configuraciones y perfiles son librerías 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
CAPÍTULO 7. WEBSPHERE STUDIO
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 estándar que entrega el poder y los beneficios
de la tecnología Java a medida para los dispositivos embebidos, incluyendo
interfaces de usuario flexibles, 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, depuración y despliegue de aplicaciones que serán lanzadas en computadoras de mano y otros dispositivos pequeños [5].
Esto ayuda a los desarrolladores a crear aplicaciones que habilitan a los
dipositivos (teléfonos celulares, PDAs, y computadoras de mano) a formar
parte de una solución “e-businnes end-to-end”.
El entorno de desarrollo integrado también 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
7.7.1
209
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 más el SmartLinker
para el preenlazado de archivos class en la aplicación.
J9 Runtimes, Utilidades y Herramientas
El WebSphere Studio Device Developer incluye como componentes a un paquete de J9 runtimes, utilidades y herramientas, para construcción 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 perfilar y analizar la ejecución de los programas
en un dispositivo embebido.
En la vista Analizer se pueden agregar eventos de usuario al código y
ratrear su ejecución en una prueba física corriendo en una maquina virtual J9.
Esta información puede ser usada para optimizar los programas en cuanto a
velocidad, tamaño y eficiencia global.
7.7.2
Herramienta de Desarrollo C (CDT) para Eclipse
Device Developer incluye el CDT (C Development Tooling) de Eclipse que
permite escribir código 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
CAPÍTULO 7. WEBSPHERE STUDIO
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 común, el WebSphere Studio
Workbench (WSWB ), que es la versión de IBM de la plataforma Eclipse.
Eclipse es un IDE de código abierto (open-source). Utiliza un plug-in
diseñado para ampliar su funcionalidad básica, ya que solo hace muy poco.
Debido a que es de código abierto, se podrá contribuir a su desarrollo.
Periódicamente, IBM toma una instantánea de Eclipse y los distribuye
como el WebSphere Studio Workbench, que está diseñado para ser una plataforma de desarrollo para socios de negocio para ampliar la arquitectura básica
y complementos.
Estas herramientas también deben ser capaces de conectar a Eclipse, así
como los miembros de la familia de productos de WebSphere Studio.
7.7.4
Utilización del IDE
WebSphere Studio Device Developer utiliza el concepto de espacio de trabajo
o workspace, un directorio que contiene el código de trabajo (un subdirectorio
por cada proyecto), y un subdirectorio de metadatos que contienen información
sobre el código.
La creación de un acceso directo es importante cuando se desee utilizar
múltiples espacios de trabajo, puesto que se puede usar la bandera “-data”
para poner un específico espacio de trabajo en ejecución, 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 también utiliza el concepto de proyecto, una colección de paquetes que componen la totalidad de una aplicación, 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 actúa como un archivo readme para la versión
de la herramienta, y se muestra automáticamente la primera vez que invoca
7.7. WEBSPHERE STUDIO DEVICE DEVELOPER
211
Figura 7.8: Barra de herramientas de WSDD.
el producto. También 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 colección predefinida 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 fig. 7.8de la pág. 211).
Los asistentes se pueden utilizar para crear aplicaciones, probar código,
crear estructuras Java, crear proyectos, crear dispositivos, configurar dispositivos, generar construcciones de un proyecto para su distrubución.
La barra izquierda de herramientas contiene todas las perspectivas y / o
vistas abiertas.
212
CAPÍTULO 7. WEBSPHERE STUDIO
Perspectiva, Editores y Vistas
Una perspectiva es un grupo de vistas y editores en la ventana del espacio de
trabajo diseñadas 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.
También se puede personalizar perspectivas y guardarlas.
Una vista es un componente visual del espacio de trabajo.
Se suele utilizar para navegar en una jerarquía de información (como los
recursos del espacio de trabajo), abrir un editor o visualizar propiedades del
editor activo.
Las modificaciones efectuadas en una vista se guardan inmediatamente.
Sólo puede existir una instancia de un tipo de vista concreto en una ventana
del espacio de trabajo.
Un editor se utiliza para modificar los archivos, y es específico para el tipo
de archivo que está siendo editado.
Con WebSphere Studio Device Developer, se puede especificar editores externos para determinados tipos de archivo.
Sólo un editor puede estar activo en cualquier momento, varios editores se
podrán abrir, pero todos estarán en la misma ventana, disponible a través de
pestañas.
El editor del código 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 código fuente de la
clase con todos sus elementos. Pero además incluye diversas funcionalidades
para ayudar al desarrollador, entre ellas se tiene:
7.7. WEBSPHERE STUDIO DEVICE DEVELOPER
213
• Utiliza distintos colores para diferenciar entre palabras reservadas, comentarios, cadenas de texto, y nombres de variables. De este modos se
pueden encontrar e identificar más fácilmente una línea de texto o una
instrucción.
• Muestra los campos y métodos pertenecientes al objeto al que se está
haciendo referencia según se va escribiendo (ver fig. 7.9 de la pág. 213).
De esta forma, se puede elegir el que se quiera a través de la lista.
• Además, en la lista de métodos de los objetos, se indican los parámetros
necesarios en la llamada al mismo, y el tipo del valor que devuelve, junto
con una breve descripción del mismo.
• Incluye una función automática para cerrar paréntesis y corchetes.
• En caso de cometer algún error de sintaxis, remarca la parte de código
errónea en rojo.
• Utiliza advertencias que son subrayados amarillos. Las advertencias no
serán causa de error, pero ayudan a mejorar el código; por ejemplo,
importar alguna clase que no se utilice nunca.
Figura 7.9: Métodos de un Objeto.
Dispositivos
Cada dispositivo requiere una configuración separada. Todos los dispositivos se comparten, por lo que cualquier proyecto puede ser desplegados en un
dispositivo específico.
214
CAPÍTULO 7. WEBSPHERE STUDIO
WebSphere Studio Device Developer soporta dispositivos Palm (a través de
HotSync), emulador Palm, y dispositivos PocketPC (a través de ActiveSync)
directamente.
WebSphere Studio Device Developer también ejecutará proyectos a nivel local JVM, y aplicaciones MIDP pueden ser desplegados en un emulador MIDP.
Otros proveedores pueden incluir emuladores soportados a través de plugins Eclipse. Estos deben estar disponibles a través del gestor de actualizaciones, o directamente desde el proveedor.
Añadir Emuladores
Una manera de probar las aplicaciones que se diseñan es añadiendo emuladores
que proveen los fabricantes. Webphere Studio Device Developer permite añadir
emuladores de distintos fabricantes.
Por ejemplo si se desea añadir un emulador de un teléfono celular Nokia
serie 40, se deben seguir los siguientes pasos:
• Descargar el emulador deseado desde el sitio oficial de Nokia.
• Instalar el SDK de Nokia recien descargado.
• Luego a través de la opción dispositivos → configurar 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 fig. 7.10 de la pág 215.
Figura 7.10: Nuevo Dispositivo Emulador.
216
CAPÍTULO 7. WEBSPHERE STUDIO
Capítulo 8
Descripción de la Aplicación
8.1
Introducción
El presente trabajo consiste en la creación de una aplicación con software
de Computación Móvil Multiplataforma, que permita el acceso a información
situada en bases de datos multiplataforma en un servidor Web, a través de
dispositivos móviles tales como teléfonos celulares.
El objetivo de la aplicación es la automatización de servicios orientados al
cliente, para que los mismos sean accesibles a través de teléfonos celulares y
estén disponibles en la Web, ya que los clientes cada vez requieren aplicaciones
de este tipo, que estén siempre disponible en cualquier momento y en cualquier
lugar.
Se trata de un sistema orientado a actividades típicas 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: depósitos, extracciones, transferencias.
217
218
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Para el desarrollo del trabajo se utilizó el lenguaje de programación Java,
debido a que sus características lo hacen adecuado para el propósito planteado:
seguridad, robustez y sobre todo, portabilidad.
La variedad de dispositivos existentes en el mercado condiciona que la aplicación deba ser compatible con todos ellos. Como es conocido, la portabilidad
es una de las características inherentes al lenguaje Java.
Como se ha visto en el capítulo cinco las tecnologías 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 teléfonos móviles 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 continuación se detallan los perfiles usuarios que se manejan:
• Administrador.
• Operador.
• Cliente/móvil.
• Cliente/web.
Cada uno de estos perfiles determina las funciones que están disponibles
para el usuario. En el caso de uso que muestra la fig. 8.1 de la pág. 219
se puede apreciar a grandes rasgos qué funciones del sistema se encuentran
disponibles de acuerdo al tipo de usuario.
8.1. INTRODUCCIÓN
Figura 8.1: Casos de Usos del Sistema.
219
220
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
8.2
Estructuración
La aplicación 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 través de un navegador
de Internet.
• La parte móvil que se encuentra desarrollada también en el lenguaje
Java, específicamente en J2ME (Java 2 Micro Edition), ésta corre en el
dispositivo móvil (celular ) y por lo tanto debe descargarse e instalarse
en el dispositivo en cuestión.
8.2.1
La Aplicación Móvil (Mobile Banking)
Para el desarrollo móvil se optó por usar el modelo cliente / servidor como se
ve en la fig. 8.2 de la pág. 221.
En donde:
Gestión de datos: Comprende la parte de la aplicación encargada del acceso
a la base de datos para recuperar la información solicitada desde el dispositivo
móvil.
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á modificaciones en la aplicación, sino que sólo será
necesario sustituir el driver JDBC por otro apropiado para el nuevo gestor.
Lógica 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 información solicitada.
Capa presentación: incluye el código Java 2ME ejecutado en el dispositivo
móvil.
El diagrama de clases de la fig. 8.3 de la pág. 222 muestra cómo se
estructura internamente el sistema móvil.
Como se ve, se estructura en ocho clases (Pantalla, Mprincipal, Cuenta,
Comunicación, Balance, Tranferencia, MenuCuenta, Movimiento). La clase
8.2. ESTRUCTURACIÓN
Figura 8.2: Arquitectura del Sistema.
221
222
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.3: Diagrama de Clases de la Aplicación Móvil.
8.2. ESTRUCTURACIÓN
223
MIDlet es la clase general de toda aplicación móvil, como se desarrolla con
la configuración CLDC y el perfil MIDP. La aplicación 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 aplicación, iniciar la aplicación, pausar la aplicación, destruir la
aplicación y gestionar las pantallas que se muestran.
A continuación se describen cada una de las clases con sus atributos y
métodos.
Pantalla
Esta clase extiende de la clase MIDlet como se puede ver en el gráfico 8.3
de la pág. 222, por lo tanto hereda sus métodos.
La clase MIDlet del paquete javax.microedition, como se vió en el capítulo
en cuestión, posee tres métodos abstractos, éstos son heredados e implementados por la clase Pantalla.
La siguiente fig. 8.4 de la pág. 224 muestra los atributos y métodos que
corresponden a la clase Pantalla.
MPrincipal
Esta clase está destinada a manejar el menú principal de la aplicación. La
fig. 8.5 de la pág. 224 muestra los atributos y métodos de la clase MPrincipal.
MenuCuenta
Clase que muestra la interfaz sobre el menú de operaciones disponibles
para una cuenta determinada. En la fig. 8.6 de la pág. 225 se puede ver la
estructuración de la misma.
Comunicacion
Es la clase principal para la realización de todas las comunicaciones con
el servidor, ya que posee métodos que permiten enviar peticiones y recibir las
respuestas del servidor.
Esta clase implementa la interfaz Runnable para la utilización de Thread
(hilos de Java) que permite hacer una petición y a la vez seguir operando en
la aplicación hasta recibir la respuesta del servidor. Mobile Banking muestra
pantallas de aviso al usuario cuando se está realizando una petición al servidor.
224
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.4: La Clase Pantalla .
Figura 8.5: La Clase MPrincipal.
8.2. ESTRUCTURACIÓN
225
Figura 8.6: La Clase MenuCuenta.
En la fig. 8.7 de la pág. 226 se describen los métodos y atributos de la
clase Comunicacion.
Transferencia
Esta clase maneja toda la interfaz e información acerca del módulo de
transferencia de fondos. En la fig. 8.8 de la pág. 226 se puede apreciar el
detalle de la clase.
Balance
Esta clase mantiene un formulario que contiene información de una cuenta
(saldo actual, tipo de cuenta, identificación de la cuenta).
Los métodos y atributos de la clase balance se pueden ver en la fig. 8.9 de
la pág. 227.
Movimiento
La clase Movimiento se encarga de manejar la interfaz y la información
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
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.7: La Clase Comunicacion.
Figura 8.8: La Clase Transferencia
8.2. ESTRUCTURACIÓN
227
Figura 8.9: La Clase Balance.
movimiento específico.
La fig. 8.10 de la pág. 228 muestra sus métodos y atributos.
Además realiza operaciones de alta de registros y búsqueda de movimientos
almacenados en el celular.
Cuenta
Gestiona la información a cerca de las cuentas bancarias que se encuentran
almacenadas en la base de datos del celular.
Posee métodos que realizan las siguientes operaciones:
• Búsqueda de una cuenta determinada.
• Inserción de una cuenta.
• Actualización de una cuenta.
En la fig. 8.11 de la pág. 229 se puede apreciar el contenido de esta clase.
228
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.10: La Clase Movimiento.
8.2. ESTRUCTURACIÓN
229
Figura 8.11: La Clase Cuenta.
La Aplicación Móvil en Funcionamiento
El interfaz gráfico de Mobile Banking es una interfaz simple, permite una fácil
interacción con el usuario, es estándar para todos los terminales móviles que
soportan J2ME.
Por razones de que se trata de una aplicación 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 estética depende exclusivamente del dispositivo donde se
ejecute. Para más información a cerca de interfaces gráficas ver capítulo cinco
(J2ME ).
Otro aspecto muy interesante a la hora de desarrollar una aplicación móvil
utilizando J2ME es poder almacenar localmente cierta información útil en el
teléfono celular para no tener que volver a realizar una petición al servidor
sobre datos solicitados anteriormente.
Mobile Banking proporciona la posibilidad de almacenar cierto tipo de información (como ser cuentas, saldos de cuentas, movimientos de una cuenta, y
ciertas configuraciones) en la zona de almacenamiento persistente del teléfono
230
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
móvil.
Para implementar esta funcionalidad, utiliza el sistema de gestión de registros, conocido como Record Management System (RMS). Más adelante se
describirá con más detalle la estructura de estos registros.
Mobile Banking posee conectividad con un servidor Web, para lograr esto
utiliza Internet móvil y la tecnología GPRS (General Packet Ratio Service)
donde no se factura al usuario por tiempo de conexión, sino por datos enviados
y recibidos.
Por lo tanto la aplicación minimiza el intercambio de datos, intercambiando solamente datos puros y los almacena en el celular para poder trabajar de
manera off-line. Esto quiere decir que el terminal móvil 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 capítulo cinco (J2ME ) las aplicaciones que
se desarrollan bajo la configuración CLDC (Conected Limited Device Configuration) y el perfil MIDP (Mobile Information Device Profile) se denominan
MIDlets. Por lo tanto Mobile Banking como se desarrolló bajo la configuración
CLDC 1.1 y el perfil MIDP 2.0 es un MIDlet.
La fig. 8.12 de la pág. 231 representa la pantalla principal de la aplicación
móvil, 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 SESIÓN.
• MODO OFF-LINE.
• CONFIGURACIÓN.
• AYUDA.
• SALIR.
Iniciar sesión: En este ítem la aplicación trabajará en modo “on-line”, solicitando previamente autenticación del usuario a través de un nombre usuario
8.2. ESTRUCTURACIÓN
Figura 8.12: Pantalla Principal Mobile Banking .
231
232
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
y clave, donde éstos son entregados al usuario al registrarse en el sistema banking.
Modo off-line: Al elegir esta instancia, la aplicación 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 aplicación, el
usuario por lo menos una vez tuvo que haber iniciado sesión 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.
Configuración: Esta opción es útil para poder configurar la url única donde
reside el servidor por ejemplo, http://www.servidorBanking.com , esta información se guarda en el almacenamiento persistente del móvil.
Antes de utilizar cualquier opción se debe primeramente cargar este valor.
Ayuda: Como su nombre lo indica, esta opción brinda información acerca
de la utilización de Mobile Banking.
Salir : Esta opción permite al usuario salir de la aplicación.
Lo anteriormente mencionado se puede observar en la fig. 8.13 de la pág.
233.
Iniciar Sesión
Para acceder o iniciar sesión se debe completar un “usuario” y “clave” e
intentar conectarse. Para ello se le muestra al usuario la siguiente pantalla de
la fig. 8.14 de la pág. 234, donde antes de ser enviados los datos son validados
localmente, por ejemplo si se intenta enviar usuario y clave vacíos o si la clave
posee menos de ocho caracteres.
La aplicación le avisará al usuario a través de alertas en caso de que ocurran
algunos de los casos mencionados.
La fig. 8.14 de la pág. 234 muestra la pantalla de ingreso y cómo la
aplicación avisa al usuario de determinados errores.
Una vez que los datos sean ingresados correctamente serán enviados al servidor, donde también son validados por el mismo, se puede decir que existe una
validación 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 informándole al usuario que se está realizando la
8.2. ESTRUCTURACIÓN
Figura 8.13: Menú Principal.
233
234
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.14: Pantallas de Ingreso al Sistema.
8.2. ESTRUCTURACIÓN
235
conexión. En la fig. 8.15 de la pág. 235 se puede ver la pantalla mencionada.
Figura 8.15: Pantalla de Aviso de Conexión.
La clase Servlet es la encargada de realizar la conexión 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 búsqueda y verificación el Servlet
envía al celular un error o bien la información del cliente más sus cuentas
correspondientes si el resultado de la verificación resulta satisfactoria.
Luego de realizar la autenticación del usuario, si resulta satisfactoria se
recibe la información del cliente con los siguientes datos:
• Número de cliente.
• Número de documento.
• Nombre.
• Apellido.
236
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
En una pantalla se muestra esta información del cliente, la misma se puede
apreciar en la fig. 8.16 de la pág. 236.
Figura 8.16: Información del Cliente.
En una pantalla posterior el usuario puede visualizar las cuentas que dispone para operar (ver fig. 8.17 de la pág. 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 fig. 8.18 de la pág. 238.
8.2. ESTRUCTURACIÓN
Figura 8.17: Lista de Cuentas.
237
238
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.18: Menú de Operaciones de una Cuenta.
8.2. ESTRUCTURACIÓN
239
Operaciones Sobre una Cuenta Determinada
Consultar saldo: Este ítem del menú permite conocer el saldo actual que
contiene la cuenta.
A continuación se detalla la información de la cuenta del usuario que se
puede visualizar:
• Identificación única de la cuenta.
• Tipo de cuenta pudiendo ser una de las siguientes: Caja ahorro, cuenta
corriente, plazo fijo.
• Saldo actual de la cuenta.
Toda esta información una vez descargada en el celular quedará almacenada en el almacenamiento persistente del dispositivo, para poder consultar a
posteriori sin necesidad de realizar una petición al servidor.
En la fig. 8.19 de la pág. 240 se puede visualizar esta información.
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 algún otro cliente, siempre y cuando la cuenta origen disponga de dinero
suficiente o bien si es una cuenta corriente posea un sobregiro que lo permita.
Los datos que se deben ingresar son la identificación de la cuenta destino
más el monto a transferir (ver fig. 8.20 de la pág. 241) y a continuación
se presenta una pantalla de confirmación de la transferencia a realizar, si el
usuario acepta se envían los datos para poder realizar la transacción (ver fig.
8.21 de la pág. 242).
La aplicación valida si se ingresa algún monto igual a “cero” o bien si no
se ingresa el monto.
Del lado del servidor también existe un proceso de verificación de saldo de
la cuenta origen y si la cuenta destino ingresada es válida para que se pueda
realizar un depósito en la misma.
Si la transacción se realiza satisfactoriamente se enviará al usuario un
número de transacción (ver fig. 8.22 de la pág. 243). O bien se enviará un
mensaje que la transacción no pudo realizarse y el motivo; (ver fig. 8.23 de la
pág. 8.23).
240
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.19: Información de Saldo de una Cuenta.
8.2. ESTRUCTURACIÓN
Figura 8.20: Ingreso de Datos Para una Transferencia.
241
242
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.21: Confirmación de la Transferencia.
8.2. ESTRUCTURACIÓN
Figura 8.22: Resultado Satisfactorio de una Transferencia.
243
244
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.23: Error en una Transferencia.
8.2. ESTRUCTURACIÓN
245
Figura 8.24: Lista de Movimientos de una Cuenta por Fecha y Hora.
Consultar movimientos: La aplicación posee la opción de poder consultar
los últimos movimientos (hasta tres) realizados en una cuenta determinada,
ya sean (extracciones, depósitos o transferencias realizadas).
Para realizar esta funcionalidad primeramente se realiza la petición al servidor, en ese momento se produce el proceso de sincronización de los datos
(movimientos) desde el servidor al cliente y se almacenan en la memoria permanente del celular .
Como se puede apreciar en la fig. 8.24 de la pág. 8.24 la aplicación muestra
un listado de movimientos donde se indica la fecha y la hora, al seleccionar
un movimiento particular se podrán visualizar en detalle el movimiento seleccionado (ver fig. 8.25 de la pág. 246).
La próxima 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 sincronización. Esta adver-
246
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.25: Detalle de un Movimientos en Particular.
8.2. ESTRUCTURACIÓN
247
tencia se nota en la fig. 8.26 de la pág. 247.
Figura 8.26: Pantalla de Advertencia al Usuario.
Off-line
Esta funcionalidad de la aplicación de trabajar en modo “off-line” permite
acceder a información ya solicitada, sin tener que realizar una petición al
servidor. Es decir el aplicativo sólo intenta mostrar la información almacenada,
no intenta realizar una ninguna conexión con el servidor.
En este modo se pasa por alto la pantalla de login o identificación del
usuario, ya que para poder utilizar el modo off-line se tuvo que haber operado
on-line anteriormente. Si no existen datos almacenados localmente el usuario
será avisado de la cuestión. Esta advertencia se puede apreciar en la fig. 8.27
de la pág. 248.
La ventaja que brinda hacia los clientes es la minimización de costos, al no
tener que intercambiar datos con el servidor sobre datos ya solicitados. Por
ejemplo un cliente desea ver sus movimientos del día, entonces se conecta una
vez, los puede mirar y los mantiene en el celular para próximas consultas sin
248
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.27: Advertencia al Usuario.
8.2. ESTRUCTURACIÓN
249
tener que volver a conectarse.
La función de transferir fondos no está disponible en modo off-line.
Configuración
Como se mencionó anteriormente lo primero que debe hacer el usuario del
sistema para poder utilizar Mobile Banking es configurar la dirección (url)
del servidor para lograr una comunicación 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 información y verificar si es un
cliente válido.
Para poder realizar esta tarea el usuario debe seleccionar la opción “configuración”, en ese instante se mostrará la siguiente pantalla del sistema que
se ve en la fig. 8.28 de la pág. 8.28.
Figura 8.28: Pantallas Para Configurar la URL del Servidor.
Esta información quedará guardada en la base de datos del celular y podrá
ser modificada en cualquier momento que se desee.
250
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Una vez que se tiene configurado correctamente la dirección del servidor
se puede lograr la comunicación con el mismo. Se debe proporcionar los datos
de acceso (usuario y clave).
Ayuda
Este módulo está destinado a brindarle al usuario un texto informativo
sintético acerca de cómo utilizar la aplicación móvil. En la fig. 8.29 de la pág.
250 se puede observar la pantalla de ayuda.
Básicamente brinda información introductoria al sistema, e instrucciones
para operar el aplicativo, como ser:
• La configuración del URL del servidor.
• Cómo iniciar sesión en el sistema.
• Cuáles son los tipos de operaciones disponibles para una cuenta.
Figura 8.29: Pantalla de Ayuda del Sistema.
8.2. ESTRUCTURACIÓN
251
Estructura de Registros Almacenados en el Teléfono
Gracias a la implementación del sistema de gestión de registros (RMS ) se
pueden guardar información en el teléfono celular.
En la fig. 8.30 de la pág. 251 se pueden ver los RecordStores que utiliza
Mobile Banking, siendo un RecordStore un almacén de registros.
Figura 8.30: RecordStores Utilizados por la Aplicación.
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: identificación 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 modificar el valor del
URL cuando se requiera.
• RecordStore: Cuentas:
252
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
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 flujos de
bytes antes de ser
insertado al RecorStore “Cuentas”.
• RecordStore: Movimientos
Guarda la siguiente información:
—
—
—
—
—
—
idMovimiento.
idcuenta.
fecha.
hora.
tipoMovimiento.
monto.
En donde también se estructura de la misma manera que los registros del
almacén “cuentas” con el delimitador de campo “@”.
La aplicación utiliza algoritmos de parseo para poder mostrar correctamente la información guardada.
Las operaciones que realiza Mobile Banking sobre RMSs son:
• Creación de los RecordStores.
• Inserción de registros.
• Búsqueda de algún registro.
• Consulta de registros.
8.2. ESTRUCTURACIÓN
253
Figura 8.31: Proceso del Mensaje Calculado.
Autenticación en Mobile Banking
Para la realización de la autenticación 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 pública, tiene la desventaja
que es una red insegura.
Mobile Banking soluciona este problema a través de la utilización de un
paquete llamado “bouncy castle cryptography” que es un paquete “open source”, es decir de código 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 criptográficos. Además su código es liviano y apto para
ejecutarse en teléfonos celulares.
Sun Microsystem brinda soluciones criptográficas para la tecnología J2SE a
través del JCA (Java Cryptography Architecture) y la JCE (Java Criptography
Extensión), el problema es que estas implementaciones son muy pesadas para
la plataforma J2ME.
Gracias a el paquete “bouncy castle cryptography” se pueden obtener algoritmos criptográficos más 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 envía éste.
En la fig. 8.31 de la pág. 253 se puede observar el proceso.
254
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
En donde:
• El midlet crea un número aleatorio y un número tipo timestamp, ambos
números junto con el usuario y la clave generan el valor del mensaje
comprendido.
• El midlet envía el usuario, el número timestamp, el número aleatorio y
el valor cifrado calculado al servidor, la clave no se envía 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, también 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 Aplicación Web
Se desarrolló con el lenguaje Java, utilizando las tecnologías de Servlet y JSP,
la misma posee acceso a una base de datos que contiene la información que
maneja la aplicación.
Esta base de datos se encuentra manejada por el motor DB2 UDB 8.1 de
IBM. Para más información acerca de DB2 remitirse al capítulo seis.
Para mejor estructuración del sistema y a fin de incursionar en patrones
de diseño, la aplicación se basa en el patrón MVC (model view controller ) o
modelo vista controlador.
El Patrón Modelo-Vista-Controlador
MVC (Model View Controller ) es un patrón de diseño aportado originalmente
por el lenguaje de programación SmalkTalk a la ingeniería de software.
Consiste principalmente en dividir las aplicaciones en tres partes o capas:
• Modelo.
• Vista.
8.2. ESTRUCTURACIÓN
255
Figura 8.32: Modelo-Vista-Controlador.
• Controlador.
El controlador es el encargado de redirigir o asignar una aplicación a cada
petición; el controlador debe poseer de algún modo, un mapa de correspondencias entre peticiones y respuestas que se le asignan.
El modelo es la lógica de negocios.
Una vez realizadas las operaciones necesarias el flujo vuelve al controlador
y éste devuelve los resultados a una vista adecuada.
El siguiente gráfico 8.32 de la pág. 255 muestra la interacción entre el
modelo, la vista y el controlador.
Implementación del MVC en la Aplicación
La aplicación está formada por archivos de clases Java, Servlets, JSPs y
HTMLs, donde cada uno se encuentra en una de las tres capas.
Estructura
La aplicación se estructura básicamente en tres paquetes bien diferenciados:
• Presentación: Contiene la interfaz gráfica, páginas JSPs o HTMLs que
permiten al usuario tener una vista de los datos e ingresar nuevos datos.
256
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
• Control: Contiene las clases que realizan el control de flujo de la aplicación, se encargan de atender a las peticiones que provienen de la capa
de presentación.
• Modelo de negocios: Se puede decir que es el paquete base de la aplicación, ya que contiene clases que manejan el modelo de negocios, como
ser:
— Clientes.
— Cuentas.
— Movimientos.
La fig. 8.33 de la pág. 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 fig. 8.34 de la pág. 257
contiene las siguientes clases:
• Cliente: Mantiene información de clientes del banco.
• Cuenta: Mantiene información de una cuenta bancaria, un cliente puede
tener más de una cuenta.
8.2. ESTRUCTURACIÓN
257
Figura 8.34: Diagrama de Clases.
• Movimiento: Corresponde a objetos que contienen información acerca
de las transacciones que ocurren sobre una cuenta.
• Usuario: Refiere a los usuarios del sistema.
• Acceso: Contiene información de acceso de clientes al sistema.
• Banco: Clase principal, actúa como coordinador, encapsulando los otros
objetos y cómo ellos interactúan.
258
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Funcionamiento
El navegador genera una petición 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 flujo vuelve
al controlador y éste analiza a cuál JSPs derivará la generación de la interfaz, dónde éstos podrán consultar los objetos del modelo para poder mostrar
información de los mismos. En la fig. 8.35 de la pág. 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 flujo de control, clases Java que forman la lógica
de negocio y la archivos JSPs que forman la vista o interfaz gráfica y que
contienen tanto porciones de código Java, como también código HTML.
Pantallas de la Aplicación Web
El sistema Banking está dividido en dos perspectivas:
8.2. ESTRUCTURACIÓN
259
• La perspectiva orientada al cliente que pueden acceder los mismos a
través de la Internet.
• La perspectiva orientada al operador / Administrador donde se accede
a través de la Intranet.
Del Lado del Cliente (Home Banking)
En esta parte de la aplicación el usuario tiene disponibles casi las mismas
opciones que se utilizan en la aplicación móvil, con algunas opciones adicionales como por ejemplo poder visualizar en qué consiste la aplicación móvil
(Mobile Banking) y la posibilidad de poder descargarla e instalarla en el teléfono celular.
Esta porción de la aplicación automatiza la gestión de cuentas bancarias,
brindándole al cliente una alternativa para realizar sus operaciones, sin la
necesidad de recurrir a la entidad bancaria y además el cliente puede acceder
al sistema las 24 hs. del día.
A continuación se muestra en la fig. 8.36 de la pág. 260 la página 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 aplicación del lado del cliente valida si se presionó el botón ingresar y
los campos del usuario y/o la clave están vacíos mediante el uso del lenguaje
JavaScritpt.
Si los datos del cliente no son correctos se presentará la pantalla que se
muestra en la fig. 8.37 de la pág. 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
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.36: Pantalla Principal de Home Banking.
8.2. ESTRUCTURACIÓN
Figura 8.37: Mensaje de Error.
261
262
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
• Movimientos.
• Mobile Banking.
• Salir.
Cambiar clave: A través de esta sección del sistema, el cliente puede realizar el cambio de su clave de acceso periódicamente. Home Banking muestra
una leyenda de recomendación de cambio de clave cada sesenta días 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 fig. 8.38 de la pág. 262.
Figura 8.38: Pantalla de Modificación de Claves.
8.2. ESTRUCTURACIÓN
263
Salir : A través de este ítem el cliente puede salir del sistema y el navegador
será reenviado a la página principal.
Cuentas: Con esta opción el cliente puede ver las cuentas bancarias que
tiene.
La página muestra un listado de cuentas.
Esta página se muestra inmediatamente luego del proceso de verificación
de ingreso al sistema.
En cualquier momento el usuario puede utilizar esta opción para la elección
de otra cuenta disponible y operar sobre ella.
Esto se puede visualizar en la fig. 8.39 de la pág. 263.
Figura 8.39: Pantalla de Listado de Cuentas.
Luego al seleccionar una cuenta disponible es posible ver la información de
la cuenta como ser:
264
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
• Identificación de la cuenta.
• No DNI/LC/LE del titular.
• Nombre del titular.
• Saldo disponible.
• Tipo de cuenta.
• Tasa de interés de la cuenta.
• Monto sobregiro (si posee).
Esta información se puede visualizar en la fig. 8.40 de la pág. 264.
Figura 8.40: Detalle de una Cuenta Determinada.
Transferir : Desde esta parte de la aplicación se pueden realizar transferencias de fondos hacia otras cuentas bancarias del mismo cliente o de algún
otro cliente.
8.2. ESTRUCTURACIÓN
265
Para la realización exitosa de esta funcionalidad se debe ingresar la identificación de la cuenta destinataria de la operación, también se tiene que ingresar
el monto a transferir; ver fig. 8.41 de la pág. 265.
Figura 8.41: Transferencia de Fondos Hacia Otra Cuenta.
Todos los datos, tanto la identificación de la cuenta o Id cuenta así como
también 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 suficientes, entonces no se podrá realizar la transacción. Home Banking avisa al usuario de estos fallos; ver fig.
8.42 de la pág. 266.
Movimientos: Por medio de este módulo del sistema el cliente tiene la
posibilidad de poder visualizar todos los movimientos (depósitos, extracciones)
asociados a su cuenta bancaria.
La aplicación solicita el ingreso de un rango de fechas, fecha desde y una
fecha hasta.
266
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.42: Mensajes de Estado del Proceso de Transferencia.
8.2. ESTRUCTURACIÓN
267
Esta petición la recibe un Servlet y valida si son rangos de fechas válidos
y luego realiza la consulta a la base de datos. Posteriormente se muestra una
página con la siguiente información:
• Id de la transacción.
• Fecha del movimiento.
• Hora del movimiento.
• Tipo movimiento (depósito, extracción).
• Monto.
En la fig. 8.24 de la pág. 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 página de la aplicación se puede obtener información acerca de Mobile Banking (aplicativo móvil), como ser en qué consiste,
268
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.44: Pantalla que Muestra Información de Mobile Banking.
requisitos de los dispositivos para poder lanzar la aplicación, qué operaciones se pueden realizar y también brinda un enlace que permite descargar el
aplicativo en la PC para luego a través de una conexión con el celular, ya
sea bluetooth, cable usb o infrarrojos, se pueda instalar la aplicación en el
dispositivo celular en cuestión.
Otra alternativa de descarga de Mobile Banking es ingresando directamente en el navegador WAP del celular la dirección URL que muestra esta página,
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 aplicación.
En la fig. 8.44 de la pág. 268 se muestra la ventana correspondiente a
Mobile Banking.
Del Lado del Operador / Administrador
8.2. ESTRUCTURACIÓN
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 gestión y también por administradores para tareas similares y además gestionar y auditar los movimientos
diarios y también realizar tareas de mantenimiento del sistema.
Se puede decir que es la base de las demás perspectivas, a partir de esta se
crean las demás, ya que los clientes se deben dar de alta, crear sus cuentas en
esta perspectiva.
Los usuarios que utilizarán esta parte del sistema deben existir como usuarios reales, esto quiere decir que algún administrador deberá insertarlo a la base
de datos de usuarios para poder operar en el sistema.
En la fig. 8.45 de la pág. 269 se puede observar la ventana que corresponde
a la página 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
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.46: Pantalla de la Sección Clientes.
• Consultas.
• Operaciones.
• Cambiar clave.
• Administración.
A continuación se detalla las funciones que se pueden realizar en cada uno
de los ítems anteriormente mencionados.
Clientes
En la sección “clientes” en primera instancia la aplicación solicita el número
de cliente a buscar en la base de datos, también muestra datos personales del
cliente y un listado de cuentas bancarias que posea. En la fig. 8.46 de la pág
270 se puede observar la página correspondiente a la sección clientes.
En esta sección, se puede dar de alta a clientes nuevos ingresando a la
opción “nuevo” o modificar los datos del mismo ingresando a la opción “mo-
8.2. ESTRUCTURACIÓN
271
Figura 8.47: Pantalla para Ingresar Nuevos Clientes.
dificar”. Es decir esta sección maneja todo lo relativo con clientes, alta, modificación, búsqueda.
En la opción nuevo cliente el usuario deberá ingresar ciertos datos personales a cerca del cliente, los datos requeridos si no son rellenados la aplicación
marcará con un color rojo o bien si se intenta dar de alta le avisará al usuario
con mensajes de alerta.
En la fig. 8.47 de la pág. 271 se muestra la página correspondiente al alta
de clientes y como se puede ver la aplicación marca con color rojo las cajas de
texto que se encuentran vacías.
En un paso posterior después de haber ingresado todos los datos solicitados
se muestra una pantalla confirmando los datos del nuevo cliente más el número
del mismo. Esto se puede ver en la fig. 8.48 de la pág. 272.
Consultas
272
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.48: Datos del Nuevo Cliente
En la sección consultas se puede visualizar el saldo actual, más otra información de la cuenta seleccionada. Por lo cual se subdivide en dos subitems:
• Saldo.
• Movimientos.
En el ítem “saldo” también se puede ver otro tipo de información como
ser: tipo de cuenta, interés, fecha de alta de la cuenta, limite de sobregiro si
posee, etc.
La fig. 8.50 pág. 274 muestra esta información.
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 fig. 8.51 de la pág. 275.
Operaciones
8.2. ESTRUCTURACIÓN
Figura 8.49: Listado de Cuentas.
273
274
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.50: Información de una Cuenta
8.2. ESTRUCTURACIÓN
Figura 8.51: Movimientos de una Cuenta.
275
276
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Esta sección como se puede ver en la fig. 8.18de la pág. 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.
• Depósitos de dinero.
• Transferencia de fondos.
• Ver movimientos (igual que consulta → movimientos).
Este módulo de “operaciones” maneja una serie de excepciones que pueden
ocurrir al momento de realizar alguna operación. Ellas pueden ser:
• Si se intenta depositar o extraer un monto igual a cero.
• Si se intenta extraer más dinero del disponible en el saldo actual.
8.2. ESTRUCTURACIÓN
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 ejecución y son mostradas al usuario mediante mensajes de error; en la fig. 8.53 de la pag. 277 se ilustra cómo
la aplicación informa estos errores.
Cambiar Clave
Esta sección permite a los usuario (administradores u operadores) cambiar
periódicamente la clave de acceso al sistema, para ello se deben ingresar tanto
la clave actual y la nueva clave dos veces a fin de confirmar el cambio. La
pantalla que permite ingresar estos datos se puede apreciar en la fig. 8.54 de
la pág. 278.
Administración
Este módulo del sistema sólo podrá ser accedido por los usuarios “Administradores”. Es decir el sistema valida el usuario, si el usuario está registrado
278
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.54: Pantalla para el Cambio de Clave.
como administrador esta opción se muestra, caso contrario no estará disponible.
Las tareas que permite realizar este módulos son:
• Crear Usuarios.
• Acceder a una lista de accesos.
El sistema permite a los usuarios administradores la posibilidad de crear
otros usuarios para la utilización 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á modificar esta clave.
La fig. 8.55 de la pág. 279 muestra la pantalla de creación de nuevos usuarios
del sistema banking.
A fin de llevar un control y poder realizar seguimientos de las operaciones
por parte de los clientes, tanto éstos accedan a través del “Home Banking”
como así también de la aplicación móvil “Mobile Banking”, el sistema genera
unos registros de accesos de los clientes.
8.3. ESTRUCTURAS DE DATOS UTILIZADAS
279
Figura 8.55: Creación de Usuarios
Los usuarios administradores pueden consultar estos registros que determinan información relevante como:
• Fecha y hora de la operación (consulta saldo, consulta movimientos,
transferencia).
• Número de cliente que accedió.
• Número de cuenta origen (y también destino en caso de que sea una
transferencia).
• Origen de punto de acceso (si es a través del Móvil o Web).
• Monto (en el caso de que haya realizado una transferencia).
En la fig. 8.56 de la pág. 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
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.56: Listado de Accesos
A continuación se describirán las tablas que conforman la base de datos.
Tanto la aplicación móvil como la aplicación Web utilizan la misma base de
datos, por lo tanto el manejador debe manejar correctamente la concurrencia.
En el gráfico 8.57 de la pág. 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 información referente a los clientes registrados del banco.
Esta compuesta por los siguientes campos de datos:
— CLIENTEID: Contiene el número único del cliente, es un número
generado por la aplicación.
— NOMBRES : Contiene el / los nombres del cliente.
— APELLIDO: Contiene el apellido del cliente.
— DOCUMENTO: Almacena la información del número de documento del cliente.
8.3. ESTRUCTURAS DE DATOS UTILIZADAS
Figura 8.57: Tablas que Integran la Base de Datos del Sistema.
281
282
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
— DIRECCION : Contiene la dirección real del cliente.
— EMAIL: Contiene la dirección de correo electrónico del cliente.
— USUARIOID: Almacena la información del usuario para ingreso al
sistema.
— PASSWORD: Amacena la información 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 teléfono del cliente.
— TRABAJA: Contiene información a cerca de si trabaja o no el cliente.
— LUGAR: Contiene el nombre del lugar de trabajo del cliente.
— ESTUDIA: Contiene información 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 información de las cuentas
que posee el cliente.
La tabla posee los siguientes campos de datos:
— CUENTAID: Contiene la identificación única de la cuenta.
— SALDO: Contiene el saldo actual que posee la cuenta.
— INTERES : Contiene la tasa de interés de la cuenta.
— DISCRIMINADOR: Contiene un carácter que identifica el tipo de
cuenta (A=caja ahorro; I= inversión; C= cuenta corriente).
— TIPOCUENTA: Contiene la leyenda del tipo de cuenta.
— SOBREGIRO: Contiene el monto máximo de sobregiro que corresponde a la cuenta.
— MONTOMIN : Contiene el monto mínimo que debe tener la cuenta.
— TINVERSION : Contiene el termino de tiempo expresado en meses
del capital invertido.
— FAPERTURA: Contiene la fecha de creación de la cuenta.
— CLIENTEID: Contiene la identificación del cliente, es un campo
relacional a la tabla cliente.
8.3. ESTRUCTURAS DE DATOS UTILIZADAS
283
— MONEDA: Contiene el tipo de moneda que opera la cuenta.
— SIMBOLO: Contiene el símbolo 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 número autogenerado que identifica a la
transacción.
— CUENTAID: Contiene la identificación de la cuenta, es un campo
relacional a la tabla cuenta.
— TIPO: Contiene información del tipo de transacción (extracción,
depósito, transferencia.)
— MONTO: Contiene el monto de la transacción.
— FECHA: Contiene la fecha que se realizó la transacción.
— HORA: Contiene la hora que se llevó a cabo la transacción.
— CUENTADESTINO: Contiene información del numero de cuenta
de destino de la transacción.
• USUARIO: La tabla “usuario” contiene información de los usuario del
sistema back-end.
Esta tabla dispone de los siguientes campos:
— USUARIOID: Número autogenerado para identificación ú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 identificador del perfil del usuario. Es
un campo referencial a la tabla Perfil.
• PERFIL: La tabla “perfil” mantiene los perfiles que maneja la aplicación.
Posee dos campos:
284
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
— ID_PERFIL: Contiene un numero autogenerado que identifica al
perfil.
— DESCRIPCION : Contiene la descripción del perfil.
• ACCESO:
— ID_ACCESO: Número autogenerado para identificación único del
acceso.
— FECHA: Contiene la fecha que se realizó el acceso.
— HORA: Contiene la hora que se realizó el acceso.
— USUARIOID: Contiene el número de cliente quien realizó el acceso.
— OPERACION : Contiene información del tipo de operacion.
— MONTO: Contiene el monto de la transacción.
— ORIGEN : Contiene si el acceso fue realizado desde el móvil o Web.
— CUENTA_ORIG: Contiene la identificación de la cuenta origen.
— CUENTA_DEST : Contine la identificación de la cuenta destino en
una transferencia.
Capítulo 9
Conclusiones
9.1
Conclusiones Generales
Los dispositivos móviles y particularmente los teléfonos celulares, hoy en día
no son un lujo sino una necesidad.
Prácticamente cada integrante de una familia ya dispone de un teléfono
celular con buenas capacidades gráficas y de cómputo. Es por ésto que las
empresas están trabajando para brindarles a sus clientes nuevos servicios para
este tipo dispositivos.
Los desarrollos de las nuevas tecnologías de la información y las comunicaciones (NTICS ) en los últimos años impulsan la implantación de sistemas
distribuidos que puedan ser accedidos a través de los teléfonos celulares. Cuando se habla de tecnologías se refiere a GSM, GPRS, WAP que permiten que
un teléfono celular pueda mantener conexiones de datos y poder consultar
cualquier tipo de información que se encuentre en Internet, o interactuar con
el servidor Web o aplicación Web de la empresa. Como por ejemplo un banco.
Las soluciones móviles están mostrando sus beneficios para la gestión de las
empresas en la mejora de la productividad, en la creación de nuevos servicios.
En este trabajo se ha cumplido con el objetivo propuesto de desarrollar una
aplicación móvil que acceda a bases de datos multiplataforma, adicionalmente
se desarrolló también la aplicación web a fin de tener un sistema completo
desarrollado.
285
286
CAPÍTULO 9. CONCLUSIONES
Se ha optado por emplear una tecnología ampliamente extendida en la actualidad, y de la que cada vez aparecen un mayor número de dispositivos, de
gama media-baja a un costo razonable. No se ha empleado ninguna característica propia de ninguna de las marcas del mercado (Nokia, Motorola, Sony
Ericsson), por lo que la aplicación desarrollada es compatible con cualquier
terminal que soporte la tecnología Java.
Se ha probado la aplicación móvil desarrollada en distintos emuladores.
Los mismos se detallan a continuación:
• Emulador estándar 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.
También a lo largo del presente trabajo se ha probado la ejecución del
aplicativo en terminales reales. A continuación 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 Tecnologías y Software Utilizados
Se ha podido comprobar las grandes ventajas de la utilización de tecnologías
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 creación 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 número de ventajas, al disponer de numerosas vistas,
perspectivas y un editor de código fuente inteligente apto para el desarrollo
de este tipo de aplicaciones, también cabe destacar el editor gráfico MIDP
del Device Developer que utiliza el concepto de Drag and Drop para insertar
elementos gráficos en el móvil y las facilidades de este entorno para añadir
nuevos dispositivos para las distintas pruebas del sistema.
También se puede decir que Websphere puede ser usado desde la Intranet
de una organización y/o desde la Internet, con lo cual el sistema resulta más
eficiente, más flexible y adaptable al cambio. Al ser accesible desde la Internet
se pudo realizar la comunicación real de la aplicación móvil con el servidor sin
ningún tipo de inconvenientes.
Con la utilización del lenguaje Java (J2ME ) se comprobó la gran portabilidad que brinda al poder lanzar la aplicación en distintos modelos y marcas
de teléfonos celulares.
9.3
Líneas Futuras de Acción
A continuación se detallan las principales líneas futuras de acción del presente
trabajo:
• Desarrollar un esquema de seguridad para el almacenamiento de claves
en la base de datos incorporando criptografía.
• Incorporar el uso del protocolo HTTPS que permite conexiones de redes
seguras, con la utilización de certificados 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 fijo
no permitir una extracción de fondos si no se ha cumplido con el período
de tiempo pactado.
• Incorporar otro tipo de funcionalidad en la aplicación móvil como ser:
— Cargar crédito a un teléfono celular.
— Poder consultar información relevante como la cotización del dólar.
288
CAPÍTULO 9. CONCLUSIONES
Bibliografía
[1] L. Joyanes Aguilar. Cibersociedad. Mac Graw-Hill, 1997.
[2] L. Joyanes Aguilar. Programación Orientada a Objetos - Segunda Edición. Mc Graw Hill/Interamericana de España, S.A.U., España, 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
Electrónico. Pearson Educación, México, 2001.
[7] Isabel Gallego Fernández. Tesis doctoral:Modelo para comercio electrónico
basados en sistemas intermediarios. Universidad Politécnica de Catalunya, 2001.
[8] Maximiliano R. Firtman. Programación 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 Agustín. 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 Diseño y
Administración de Datos. Universidad Nacional del Nordeste, Corrientes,
Argentina, 2006.
289
290
BIBLIOGRAFÍA
[13] L. Joyanes Aguilar; I. Zahonero Martínez. Estructura de Datos - Algoritmos, Abstracción y Objetos. Mc Graw Hill/Interamericana de España,
S.A.U., España, 1998.
[14] Lucas Ortega Díaz Sergio Gálvez Rojas. Java a Tope: J2ME. Universidad
de Málaga, Málaga, España, 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. Gómez; C. Solares. JAVA - Un Lenguaje de
Programación Multiplataforma para Internet. Paraninfo, España, 1997.
[17] Andrew S. Tanenbaum. Redes de Computadoras. Pearson Educación,
Mexico, 2003.
[18] M.Ñicklous T.Stober U. Hansmann, L. Merk. Pervasive Computing HandBook. Springer,Verlag, 2001.
[19] VV.AA. Introducción a las Bases de Datos. THOMSON PARANINFO,
S.A., USA, 2005.
[20] Mark Weiser. The computer for the 21st century. Scientific American,
San Francisco, CA, USA, 1991.
[21] Ing. Dario Yorio. Tesis de Magistratura:Identificación y clasificación de
patrones en el diseño de aplicaciones móviles. Universidad Nacinal de la
Plata.
Índice de Materias
2.5G, 34
2G, 25
3G, 26, 34
if, 79
if else, 79
bloque try, catch, finally, 81
bucles, 80
do while, 81
for, 80
while, 80
AIV Extender, 178
AMPS, 29
Advanced Mobile Phone System,
25
Sistema Avanzado de Telefonía
Móvil, 27
AMS, 115, 116
API, 253
aplicación, 217
Aplicaciones
Móviles, 51
AWT, 111
C/C++, 77
C2C
Consumidor a Consumidor, 6
caso de uso, 218
CDC, 110
Conected Device Configuration,
107
CDMA, 26
Acceso Múltiple Por División de
Código, 32
celular, 245, 249
Centro de Desarrollo, 180
Ciclo del Conocimiento, 14
Clases de Conocimientos, 14
CLDC, 110
Conected Limited Device Configuration, 106
comentarios, 77
Comercio Electrónico, 3
comercio electrónico, 18
bancario, 19
cominicaciones inalámbricas, 40
computación pervasiva, 8
Computacion Ubicua, 8
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 Jerárquicas
Modelo, 173
Bases de Datos Relacional
Modelo, 174
bibliotecas
de clases, 65
bifurcaciones, 78
291
292
comunicaciones en J2ME, 153
comunicaciones HTTP, 157
comunicaciones móviles, 26
configuración, 106, 109
conocieminto tácito, 14
conocimiento explícito, 14
contenedor
cliente de aplicaciones de, 205
EJB de, 204
Web, 204
Content-Type, 85
D-AMPS
Sistema Avanzado de Telefonía
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 Administración 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
Introduccíon y Conceptos, 192
EDGE
ÍNDICE DE MATERIAS
Tasa de Datos Mejorada para
la Evolución del GSM, 34
ejemplo de
bifurcación if, 79
bifurcación if else, 79
bucle for, 80
bucle while, 80
clase, 70
comentario, 78
do while, 81
línea compuesta por tres sentencias, 77
enterprise beans, 204
Esquema General, 4
estructuras de programación, 77
expresión, 77
FDM
multiplexión por división de frecuencias, 32
Gestión 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 Móviles, 30
GUI, 205
herencia, 70
hosts virtuales, 205
HTML, 39
HTTP, 38
HttpServletRequest, 85
HttpServletResponse, 85
IMTS, 28
ÍNDICE DE MATERIAS
Sistema Mejorado de Telefonía
Móvil, 27
INIT, 86
instanciación e inicialización, 86
interfaz
Connection, 155
InputConnection, 156
OutputConnection, 156
StreamConnection, 157
Internet, 1, 19, 35, 38
móvil, 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 Electrónico a Través
de Dispositivos Móviles, 7
m-commerce, 3
293
memoria
administrador automático 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 Electrónico,
5
MSC
Centro de Conmutación Móvil,
28
MTSO
Oficina de Telefonía Móvil, 28
multi servidor, 202
mundo móvil, 25
MVC, 254
NTICs
Nuevas Tecnologías de Informática y Comunicaciones, 1
nuevas tecnologias, 1
OMA
Open Mobile Alliance, 40
OOP, 68
operadores
aritméticos, 74
de asignación, 74
de concatenación de cadenas de
caracteres, 76
package, 71
packages, 69
PCS
Personal Communications Services, 25
PDA, 206
294
perfil, 109
plataforma
de software, 186
plug-in, 203
proceso de formación 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 información, 36
servidor
de aplicaciones, 203
HTTP, 203
servlet
ciclo de vida del, 86
codificación de, 85
motor del, 86
servlets, 204
Set-Cookie, 85
sincronización, 245
sinronización, 245
sistema avanzado de telefonía móvil,
27
sistemas móviles de segunda generación, 32
SMS, 7, 19, 37
Short Message System, 36
ÍNDICE DE MATERIAS
SMTP, 36
Sociedad de la Informacion y el Conocimiento
definición, 12
software, 71
software móvil, 38
Spatial Extender, 180
TCP/IP, 40
TDM
multiplexión por división de tiempo, 32
TDMA, 26
teléfonos
móviles, 3
teléfonos celulares, 27, 51, 103, 206
teléfonos móviles, 35
teléfonos móviles de primera generación, 26
teléfonos móviles de segunda generación, 29
teléfonos móviles de tercera generación, 33
telefonía celular, 26, 36
telefonía móvil, 27
UMTS
Sistema Universal de Telecomunicaciones Móviles, 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
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-
295
tion, 190
WSED
WebSphere Studio Enterprise Developer, 190
WSSDA
WebSphere Studio Site Developer Advanced, 190
XHTML-MP, 46
XML Extender, 178, 180