10 herramientas de desarrollo y...

Herramientas de desarrollo y simulación utilizadas Página 193

10 HERRAMIENTAS DE DESARROLLO Y SIMULACIÓN UTILIZADAS

En este apartado describo cuales han sido las herramientas y aplicaciones utilizadas para la creación de la aplicación que nos atañe.

Para el desarrollo del código he utilizado el mismo entorno de desarrollo, el Eclipse que con los plugins apropiados facilita la programación en las dos plataformas en que nos movemos.

Para la compilación y simulación se ha optado por las soluciones ofrecidas por Sun: el Wireless Toolkit para la plataforma JAVA ME y el Java Card Kit para la plataforma Java Card. El beneficio de que ambos sean los distribuidos por Sun es que va a permitir establecer la comunicación entre ambos.

10.1 ENTORNO DE DESARROLLO: ECLIPSE

Como entorno de desarrollo he utilizado Eclipse, puesto que es un entorno bastante potente para la programación en Java y porque ya estoy familiarizado con el de haberlo usado en otras ocasiones.

Eclipse es una plataforma de software de Código abierto independiente de plataforma para desarrollar aplicaciones. Esta plataforma, típicamente ha sido usada para desarrollar entornos integrados de desarrollo (del Inglés IDE), como el IDE de Java llamado Java Development Toolkit (JDT) y el compilador (ECJ) que se embarca como parte de Eclipse (y que son usados también para desarrollar el mismo Eclipse).

Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia de herramientas para VisualAge. Eclipse es ahora desarrollado por la Fundación Eclipse, una organización independiente sin ánimo de lucro que fomenta una comunidad de código abierto y un conjunto de productos complementarios, capacidades y servicios.

Las principales características de las que dispone Eclipse son las siguientes:

• Editor de texto en el que escribimos el código de nuestros programas

• Resaltado de sintaxis. El entorno interpreta la sintaxis de Java y nos ofrece ventajas como:

▪ Diferenciación de colores para variables, constantes, métodos, palabras reservadas, etc

▪ Identación de código automática

▪ Autocompletado de nombres de funciones, variables de instancia, etc

▪ Autogeneración de código: bloque de comentarios, constructores, getters y setters, etc.


• Compilación en tiempo real: lo que nos permite saber en cada momento los errores de compilación y los warnings, sin esperar al momento de la compilación

• Pruebas unitarias con JUnit

• Control de versiones con CVS

• Integración con Ant

• Asistentes (wizards): para creación de proyectos, clases, tests, etc.

• Refactorización

Asimismo, a través de "plugins" libremente disponibles se pueden añadir más funcionalidades. De hecho para que el eclipse interprete y compile correctamente el código de la plataforma JAVA ME es necesaria la instalación del plugin EclipseME. Para la plataforma Java Card también podemos instalar el plugin EclipseJCDE.

El entorno de desarrollo de software Eclipse se puede descagar gratuitamente de su web: http://www.eclipse.org/ la versión que he utilizado es la 3.2.

La instalación se efectúa sin más que descomprimir el archivo que nos descargamos en la carpeta que elijamos.

Los plugins se instalan copiendo los archivos .jar que nos descargamos a la carpeta /plugins/ que está dentro de nuestra carpeta del eclipse. Nos podemos descargar los plugins desde:

• EclipseME: http://eclipseme.org/

• EclipseJCDE: http://sourceforge.net/projects/eclipse-jcde/

10.2 HERRAMIENTA DE SIMULACIÓN JAVA ME: WIRELESS TOOLKIT

En esta sección se muestran los pasos a seguir para la instalación y el uso de la herramienta de simulación de la plataforma Java ME ofrecida por Sun, el Wireless Toolkit.

Se verán las capacidades que tiene la herramienta y se describirá como utilizar las que nos conciernen en el contexto de este proyecto.

10.2.1 INSTALACIÓN DEL SOFTWARE

Para poder utilizar el Wireless Toolkit tendremos que haber instalado con anterioridad el Java Development Kit (JDK), que se puede conseguir en la siguiente dirección: http://java.sun.com/j2se/

Podemos descargarnos el software de la aplicación de desarrollo de la página de sun dedicada al Wireless Toolkit: http://java.sun.com/products/sjwtoolkit/

http://www.eclipse.org/

http://eclipseme.org/

http://sourceforge.net/projects/eclipse-jcde/

http://java.sun.com/j2se/

http://java.sun.com/products/sjwtoolkit/


La versión utilizada para el proyecto es la 2.5, la cual puede descargarse desde:

http://java.sun.com/products/sjwtoolkit/download-2_5.html

La aplicación se distribuye con un instalador incorporado, por lo que lo único que tendremos que hacer para completar la instalación es seguir los pasos que nos indica este instalador.

Tras completar la instalación, tendremos una estructura de directorios como la que se muestra en la siguiente tabla

Tabla 29: Directorios de la Herramienta Wireless Toolkit Directorio Descripción

appdb Contiene recursos comunes para la simulación de las aplicaciones. apps Contiene los proyectos del toolkit. Se incluyen tanto las demos como los

proyectos nuevos que creamos. En cada carpeta dentro de apps se incluye todo lo necesario para esa aplicación: su código fuente, sus clases compiladas y sus recursos.

bin Archivos de programa del Wireless Toolkit docs Documentos tales como guia de usuario, guia de customización del entorno… lib Librerías que se utilizan en la compilación. Aparecen tanto las librerías de

Java ME (perfiles y configuraciones) como las librerías de APIs opcionales. sessions Archivos temporales de ejecución. wtklib Librerias propias del Wireless Toolkit, puesto que este está programado en

Java.

10.2.2 INTRODUCCIÓN

El Java Sun Wireless Toolkit para CLDC es un conjunto de herramientas que hace posible crear aplicaciones para teléfonos móviles y otros dispositivos sin cables. Aunque está basado en el Perfil de Dispositivo de Información Móvil (MIDP) 2.1, también soporta diversos paquetes opcionales, haciéndole un conjunto de herramientas de desarrollo ampliamente capaz.

http://java.sun.com/products/sjwtoolkit/download-2_5.html


Ilustración 68: Wireless Toolkit

En la figura se muestra una imagen del programa, en la que aparece la KToolbar, que es el centro de mando de la herramienta.

10.2.2.1 Componentes de Wireless Toolkit

El Wireless Toolkit tiene tres componentes principales:

• KToolbar automatiza muchas de las tareas envueltas en la creación de aplicaciones MIDP.

• El emulador es un teléfono móvil simulado. Esto es útil para testar aplicaciones MIDP.

• Una colección de utilidades provee de otras funcionalidades interesantes, incluyendo una consola de mensajes de texto y utilidades criptográficas.

KToolbar s el centro del toolkit. Puede usarse para construir aplicaciones, lanzar el emulador e iniciar las aplicaciones. Alternativamente, el emulador y las utilidades pueden ser ejecutadas por si mismas, lo que puede ser de utilidad en bastantes situaciones.

10.2.2.2 Capacidades de Wireless Toolkit

El Sun Java Wireless Toolkit para CLDC soporta la creación de aplicaciones MIDP con las siguientes capacidades:

Construcción y empaquetado: Se escribe el código fuente y la herramienta se preocupa de el resto. Con el pulsado de un botón, el toolkit compila el código fuente, preverifica los archivos class y empaqueta un MIDlet suite.

Ejecución y monitorización: Se puede ejecutar un MIDlet suite directamente en el emulador o instalarlo mediante un proceso que se parece a la instalación de la aplicación en un dispositivo real. Un monitor de memoria, monitor de red y perfilador de métodos se proveen para analizar las operaciones de los MIDlets.


Firmado de MIDlet suites: El toolkit contiene herramientas para firmado criptográfico de los MIDlets. Esto es útil para testar la operación de los midlets en diferentes dominios de protección.

10.2.2.3 Tecnologías soportadas

El Sun JavaTM Wireless Toolkit para CLDC soporta varias APIs (Application Programming Interfaces) estandar definidas a través de el programa Java Community Process (JCP). La tabla que sigue muestra las APIs soportadas.

Tabla 30: APIs soportadas por Wireless toolkit JSR API

JSR 248 MSA 1.0 JSR 185 JTWI 1.0 JSR 139 CLDC 1.1 JSR 118 MIDP 2.0 JSR 75 PIM and File JSR 82 Bluetooth and OBEX JSR 135 MMAPI 1.1 JSR 172 JSR 177 SATSA JSR 179 Location JSR 180 SIP JSR 184 3D Graphics JSR 205 WMA 2.0 JSR 211 CHAPI JSR 226 JSR 229 JSR 234 AMMS JSR 238 MIA JSR 239 JSR 248

10.2.3 DESARROLLANDO MIDLET SUITES

Este capítulo describe como puede usarse Sun JavaTM Wireless Toolkit para crear aplicaciones. Este empieza con una descripción de los proyectos del toolkit, entonces se trabaja a través del proceso de desarrollo.

Se deben seguir dos ciclos básicos de desarrollo en la creación de aplicaciones MIDlet suites. El primero es más rápido y simple. Es útil en el desarrollo inicial. El segundo ciclo es más largo pero permite pruebas más comprensibles y realistas.

10.2.3.1 Acerca de los proyectos

En el Sun JavaTM Wireless Toolkit para CLDC, los MIDlet suites se organizan en proyectos, donde el resultado final de un proyecto es un MIDlet suite. Un proyecto contiene todos los archivos que se utilizarán para la construcción de un MIDlet suite, incluyendo los archivos de fuente Java, los archivos de recursos y el descriptor del MIDlet.


El Sun JavaTM Wireless Toolkit trabaja en un proyecto en cada momento. Se puede crear un proyecto nuevo o abrir uno ya existente.

En este capítulo se usa un proyecto muy sencillo de ejemplo.

Para crear un proyecto, arranca la KToolbar. En windows, elijase Inicio > Programas > Sun Java Wireless Toolkit 2.5 > Ktoolbar. Aparecerá la ventana de la KToolbar.

Ilustración 69: KToolbar

Haga click en “New Project”. El toolkit le preguntará por el nombre del proyecto y el nombre de la clase del MIDlet que escribirá. Rellene los nombres y haga click en “Create Project.


Ilustración 70: Creación de un proyecto

La ventana “Settings” es mostrada. Las elecciones afectan al entorno para el proyecto. Las opciones por defecto están bien para este ejemplo. Aparecen mensajes en la consola de la Ktoolbar indicando exactamente donde almacenar el código fuente y los recursos para este proyecto.

Ilustración 71: Mensajes de consola al crear un nuevo proyecto

10.2.3.2 Ciclo de desarrollo simple

El ciclo de desarrollo simple consiste en los siguientes pasos:

• Edición de código fuente. Se crean archivo de fuente Java con el código de la aplicación.

• Construcción (Build): El Sun JavaTM Wireless Toolkit compila y preverifica los archivos de fuente Java

• Ejecución (Run): Las clases compiladas se ejecutan en el emulador

Si ocurre un error cuando el toolktit trata de compilar los archivos de fuente, vuelva y edítelos de nuevo. Si se encuentra un bug cuando se está probando la aplicación en el emulador, edite los archivos de fuente para arreglar el fallo.

Ahora que entiende el ciclo de desarrollo en un nivel alto, el resto de esta sección ilustra como completar cada paso usando el Sun JavaTM Wireless Toolkit para CLDC.

10.2.3.2.1 Edición de código fuente

La edición del código fuente es el único paso en el que el Sun JavaTM Wireless Toolkit no aporta ninguna ayuda. Para la edición de l código fuente se recomienda usar el entorno de desarrollo Eclipse, descrito en la sección 8.1.


10.2.3.2.2 Construcción (Build)

El siguiente paso es la construcción del código fuente. El toolkit hace esta parte muy sencilla.

En la ventana Ktoolbar, pinche en el boton “Build”. Asumiendo que se guardó el archivo de fuente en el sitio correcto, el toolkit la encuentra y la compila. Los errores de compilación se muestran en la consola de la Ktoolbar. Si hay errores, como se muestra en la figuar, edite el código fuente para repararlos. Una vez se eliminen los errores, la consola Ktoolbar informa de que la construcción se completó con éxito.

Ilustración 72: Construcción (Build)

Tras las escenas, el Sun JavaTM Wireless Toolkit además preverifica los archivos de clase compilada. Los archivos class de los MIDlets deben ser preverificados antes de poder ejecutarse en un dispositivo MIDP o un emulador. El toolkit silenciosamente maneja este detalle.

10.2.3.2.3 Ejecución (Run)

Una vez el proyecto se construye exitosamente, estamos preparados para ejecutarlo en el emulador. Pinche en el botón “Run”. El emulador muestra una lista de los MIDlets en el proyecto.


Ilustración 73: Emulador, selección del applet del proyecto

Elija el MIDlet que quiera y seleccione “Launch”. Comienza la ejecución de la aplicación.

10.2.3.3 Ciclo de desarrollo completo

El segundo ciclo de desarrollo es considerablemente más complicado. Consiste en los siguientes pasos a nivel alto.

• Edición de código fuente. Este paso es el mismo que el del ciclo simple.

• Empaquetado. En este paso, el Sun JavaTM Wireless Toolkit compila y preverifica los archivos de fuente (esencialmente lo mismo que el paso de construcción de antes). Entonces se ensamblan los archivos class y los archivos de recursos en un Archivo Java MIDlet suite (JAR) y un descriptor del MIDlet suite.

• Instalación. Los MIDlet suites necesitan ser instalados antes de poder ejecutarse. Puede instalar el MIDlet suite en el emulador del Sun JavaTM Wireless Toolkit para CLDC o en un dispositivo real.

• Ejecución. Como en el ciclo de desarrollo, ejecute la aplicación y pruébela en busca de bugs.

El ciclo de desarrollo completo incluye dos nuevos pasos, empaquetado e instalación. Finalmente, la ejecución de una aplicación instalada es diferente en aspectos importantes a la ejecución de una aplicación en el ciclo de desarrollo simple.


10.2.3.3.1 Empaquetado

El Sun JavaTM Wireless Toolkit para CLDC automatiza la tarea del empaquetado de un MIDlet suite. El resultado final del empaquetado son dos ficheros, un descriptor de MIDlet y un archivo JAR de MIDlet suite. El descriptor es un pequeño archivo de texto que contiene información acerca del MIDlet suite. El archivo JAR contiene los archivos class y los recursos que componen el MIDlet suite. Los dispositivos pueden usar el descriptor para aprender acerca de la aplicación antes de descargar el archivo JAR completo, una consideración importante en el mundo sin cables de memory-lean, bandwidth-starved.

Para pedir al toolkit que empaquete el MIDlet suite, elija en el menu Ktoolbar.

Project > Package > Create Package

El descriptor del MIDlet suite y el archivo JAR se generan y se sitúan en el directorio bin del proyecto.

El empaquetado puede envolver pasos adicionales. Se puede usar un ofuscador de código para reducir el tamaño del archivo JAR del MIDlet suite, técnica que se describe posteriormente en este capítulo. Adicionalmente, el Sun JavaTM Wireless Toolkit provee de herramientas que permiten establecer firma digital a los MIDlet suites.

10.2.3.3.2 Instalación

Para testar apropiadamente un MIDlet suite, instálelo en el emulador del toolkit o en un dispositivo real. Cuando pulsa el botón “Run” en la Ktoolbar, el MIDlet suite no es instalado en el emulador. En vez de esto, el emulador ejecuta las clases del MIDlet directamente.

El emulador también tiene la capacidad de instalar aplicaciones en su memoria en un proceso que se parece a como las aplicaciones son transmitidas e instaladas en dispositivos reales. Para instalar aplicaciones en el emulador del Sun JavaTM Wireless Toolkit para CLDC, elija:

Project > Run via OTA

La ventana del emulador se abre, pero en vez de ejecutar las clases del MIDlet directamente, esta vez el emulador muestra una pantalla de bienvenida al software de gestión de aplicación (AMS, Application Management Software). El software del emultador es un ejemplo del tipo de software que los dispositivos reales deben tener para gestionar sus MIDlet suites.


Ilustración 74: Bienvenida al software de gestión de aplicación

Elíjase “Apps” para ir a la lista principal de aplicaciones instaladas. Seleccione “Install Application” y pulse el botón “select” en el emulador. El emulador te solicita la localización URL de la aplicación que desea instalar. Esta URL ya aparece completada.

Ilustración 75: URL de instalación

Elija “Go” en el menú para iniciar la instalación. El emulador muestra una lista de las aplicaciones que encuentra en la URL. Elija la correcta y selecciones “Install” desde el menú. El emulador da una última oportunidad para confirmar sus intenciones.


Ilustración 76: confirmar la instalación

Elija “Install” de nuevo para finalizar la instalación. Usted será devuelto a la lista de las aplicaciones instaladas en el emulador, la cual incluye ahora la aplicación que se acaba de instalar.

Ilustración 77: lista de aplicaciones instaladas

La ejecución via OTA es un mecanismo extremadamente útil que hace sencillo instalar el MIDlet suite en el emulador del toolkit. Algunas características deben de ser probadas usando esta técnica, incluyendo la instalación de MIDlet suites firmados y el apilado en registro.

Si desea probar su MIDlet suite en un dispositivo real, debe instalarlo primero. Como se hace esto depende fuertemente del dispositivo que esté usando. Las siguientes posibilidades son las más probables.


Puede desplegar la aplicación en un servidor web, entonces transmitir la aplicación desde el servidor al dispositivo usando el protocolo Over the Air (OTA). Este es probablemente el mismo mecanismo que los usuarios seguirán cuando ellos pretendan instalarse la aplicación.

Podría transferirse el MIDlet suite al dispositivo usando una conexión Bluetooth, de infrarrojos o serie. Esto es bastante más simple que usar un servidor web, y aunque no le dará pistas sobre el proceso de instalación de la aplicación usando OTA, le permite ver como funciona la aplicación en el dispositivo.

10.2.3.3.3 Ejecución

Una vez que la aplicación está instalada, ejecutarla es sencillo. Elija la aplicación de la lista y elija “Launch” de el menú.

Ilustración 78: ejecutando una aplicación instalada

La ejecución de una aplicación en un dispositivo real depende del mismo dispositivo. Consulte la documentación del dispositivo para obtener información.

10.2.4 TRABAJANDO CON PROYECTOS

En el apartado anterior, vimos como el Sun JavaTM Wireless Toolkit para CLDC ayuda en el ciclo de desarrollo del MIDP. Éste apartado profundiza en los detalles de trabajar con proyectos, incluyendo lo siguiente:

• Selección de las APIs para un proyecto.

• Manipulación de los atributos del MIDlet suite, incluyendo la lista de MIDlets.


• Entendimiento de la estructura de directorios del proyecto.

• Incluyendo librerías de una tercera parte en nuestro proyecto.

10.2.4.1 Selección de APIs

Cada proyecto se construye contra algún conjunto de APIs. El Sun JavaTM Wireless Toolkit para CLDC soporta varias APIs. La lista completa la tenemos en el apartado 8.1. El toolkit le permite desarrollar aplicaciones para algún subconjunto de APIs basado en el tipo de dispositivo al que se dirije la aplicación.

Por ejemplo, aunque el toolkit soporta JSR 184, la API de gráficos 3D, usted puede querer desarrollar aplicaciones que no hacen uso de esa API. La selección de APIs del proyecto hace posible elegir sólo las APIs que desee usar.

Para ver cómo esto trabaja, lance Ktoolbar y abra un proyecto. Entonces pinche en “Settings” para abrir la siguiente ventana: En el panel “API Selection”, la plataforma objeto (Target Platform) controla la apariencia del resto del panel. Elija la configuración que mejor se ajuste a sus necesidades, y confirme su selección con el control mostrado. Por ejemplo, si usted está desarrollando aplicaciones para dispositivos que cumplen la JSR de tecnología Java para la industria sin cables, elija JTWI de la caja de combo. Entonces especifique una versión de CLDC y elija las APIs opcionales.

Ilustración 79: selección de APIs

El toolkit aplica su selección cuando se compila el código fuente.


10.2.4.2 Cambio de los atributos del MIDlet Suite

La ventana de ajuste del proyecto permite también controlar los atributos del MIDlet suite, que están almacenados en el descriptor como el archivo manifest del archivo JAR del MIDlet suite.

Para ver los atributos, abra un proyecto, entonces pinche en el botón “Settings”. La barra de iconos de la izquierda tiene tres iconos para los atributos: Requeridos “Required”, Opcionales “Optional”, y Definidos por el Usuario “User Defined”.

Consulte la especificación de MIDP 2.0 para las definiciones de los atributos requeridos y opcionales. El Sun JavaTM Wireless Toolkit para CLDC se encarga de la mayoría de los detalles. En las fases tempranas del desarrollo no necesitará preocuparse de los atributos en absoluto. Una vez que su aplicación es estable y quiere empezar a pensar acerca de implantarla en dispositivos reales y entrar en el mercado, ajuste los valores.

Para ajustar un valor en los paneles de Requeridos u Opcionales, haga click en la celda junto a la clave del atributo que desea cambiar y escriba el nuevo valor.

Ilustración 80: cambiando los atributos de un proyecto

Para crear nuevos atributos definidos por el usuario, pinche en el icono de Definidos por el Usuario. Haga click ene l botón añadir “Add” y rellene apropiadamente


nombre y valor, luego pinche OK. Para modificar valores de los atributos definidos, pinche en la celda correspondiente, así como en los atributos requeridos y opcionales.

Para eliminar un atributo, selecciónelo y pinche eliminar “Remove”.

10.2.4.3 Manipulando MIDlets

Los ajustes del proyecto también proveen de un medio de añadir o modificar Los MIDlets que están contenidos en el proyecto MIDlet suite. Para ver como funciona esto, arranque la Ktoolbar y abra un proyecto existente. Pinche en ajustes “Settings” y elija el icono MIDlets. Verá una lista de todos los MIDlets en el proyecto. Si simplemente acaba de crear un nuevo proyecto, el toolkit automáticamente rellena la primera entrada de MIDlet.

Ilustración 81: MIDlets en un proyecto

Para añadir un MIDlet nuevo, pinche en añadir “Add”. Rellene el nombre, nombre del archivo de icono y nombre de la clase. El nombre de icono puede dejarse en blanco si lo desea. Para cambiar valores o quitar entradas de MIDlet, use los botones Editar “Edit” y Eliminar “Remove”.

Los nombres de MIDlet se representan al usuario en el orden mostrado cuando el MIDlet suite es ejecutado. Puede modificarse el orden seleccionando un MIDlet y pinchando en los botones de mover arriba y abajo, “Move Up, Move Down” respectivamente..


10.2.4.4 Usando el registro de pila

También se pueden usar los ajustes del proyecto para trabajar con los ajustes de registro de pila de un MIDlet suite. Pinche en “Settings” y escoja el icono de registro de pila ”Push Registry”.

Ilustración 82: registro de pila

Para añadir una entrada al registro de pila, pulse añadir “Add” y rellene los valores para la URL de la conexión, clase del MIDlet y emisor permitido, entonces pulse OK. Para editar una entrada, seleccione una entrada y pulse el botón “Edit”. Para eliminarla pulse el botón “Remove”.

Si usted hace entradas al registro de pila para su aplicación, asegúrese que también introduce los permisos adecuados.

10.2.4.5 Ajustando los manejadores de contenido

El Sun JavaTM Wireless Toolkit para CLDC soporta el API de manejador de contenido (CHAPI, Content Handler API), la cual se define en el JSR 211. El concepto básico de CHAPI es que los MIDlets pueden ser lanzados en respuesta a contenidos (archivos) entrantes. Los móviles modernos pueden recibir contenidos usando sms, infrearojos, bluetooth e-mail y otros métodos. La mayoría de los contenidos tienen un


tipo asociado. CHAPI especifica un sistema por el que los MIDlets pueden ser lanzados en respuesta a un tipo determinado de contenidos.

Para modificar los ajustes del manejador de contenidos en el proyecto, pinche en ajustes “Settings” y elija el panel “Content Handlers”.

Ilustración 83: Ajustes de manejadores de contenido

Cada línea en la lista representa los ajustes para un manejador de contenido. En este ejemplo, se han configurado dos manejadores, uno para visor de texto y otro para visor de imágenes. Para crear un manejador de contenido, pulse añadir “Add”, o para editar pulse editar “Edit”. Puede Ajustarse el orden de los manejadores de contenido con los botones de mover arriba y abajo “Moce Up, Move Down”.

Cuando se añade o edita un manejador de contenido, la ventana de detalles aparece: en el campo de clase, rellene el nombre de un MIDlet. ID es una cadena de identificación que puede usarse para invocar un manejador de contenido y para control de acceso.


Ilustración 84: detalle en la creación de un manejador de contenido

Tipos de contenido “Content types” es una lista de los tipos de contenidos de los que el manejador de contenido se hace responsable. Use añadir “Add” y eliminar “Remive” para gestionar la lista. Cadenas de sufijo “Suffix strings” es una lista de sufijos URL que son usualmente un sustituto para un tipo de contenido explicito. Finalmente, Permiso permitido a “Access allowed to” es una lista de manejadores de contenido. Si la lista está vacía, el acceso a este manejador de contenido está asegurado a cualquier otro manejador de contenido.

Los manejadores de contenido tienen acciones asociadas, que dan a las aplicaciones invocantes una elección para elegir un manejador de contenido. Un manejador de contenido visor de imágenes, por ejemplo, podría incluir una acción para ver la imagen a tamaño real y otra para verla ajustada a la pantalla. Pinche en la pestaña de acciones “Actions” para editar las acciones de un manejador de contenido.


Ilustración 85: acciones de un manejador de contenido

La lista de acciones “Actions” contiene los nombres internos de las acciones para este manejador de contenido. “Locales” es una lista de todas las locales para las que los nombres de acción legibles serán provistos. ”Localized Actions” es una cuadrícula que contiene los nombres legibles de acción legibles para varias locales.

10.2.4.6 Estructura de directorios del proyecto

Los proyectos poseen una estructura de directorios estándar. El proyecto en sí mismo se representa por una carpeta en el directorio toolkit\apps.

La siguiente tabla describe la estructura de directorios del proyecto.

Tabla 31: estructura de directorios de un proyecto Directorio Descripción

bin El descriptor del MIDlet suite y el archivo JAR se ubican en este directorio cuando se empaqueta el proyecto. Este directorio también contiene la información del manifest desempaquetada y puede incluir un archivo HTML que se usa internamente si se usa la ejecución via OTA

classes Este directorio es usado por el toolkit para almacenar los archivos de clases compiladas lib Situe una librería de tercera parte en esta carpeta para incluirla en este proyecto. res Imágenes, sonidos y otros archivos de recursos van en este directorio. Estos son

empaquetados en el raiz del archivo JAR del MIDlet suite. src Aquí van los archivos de fuente. tmpclasses Este directorio es usado por el toolkit. tmpsrc Este directorio es usado por el toolkit.

Adicionalmente, el directorio del proyecto contiene un archivo project.properties que contiene información sobre el proyecto.

Para eliminar los archivos y directorios temporales del proyecto, elija


Project > Clean

10.2.4.7 Usando librerias de una tercera parte

El Sun JavaTM Wireless Toolkit para CLDC permite incorporar librerías de una tercera parte a las aplicaciones. El uso de librerias de una tercera parte puede reducir su tiempo de desarrollo proveyendo de funcionalidades que usted no quiere construir por sí mismo, pero guarde atención al tamaño del archivo JAR del MIDlet suite.

Cuando se usa una librería de una tercera parte en una aplicación, el archivo JAR se expande en el tamaño de la librería incorporada. Puede usarse un ofuscador para reducir el tamaño del archivo, y un buen ofuscador puede incluso eliminar partes del código que no se utilizan. Incluso con el uso de un ofuscador, una librería de tercera parte es probablemente mayor que su código escrito desde cero. Hay que evaluar el sacrificar una cosa por otra entre reducir el tiempo de desarrollo y el tamaño del archivo JAR.

El Sun JavaTM Wireless Toolkit para CLDC aporta dos métodos para incorporar librerías de terceras partes. El panel de APIs externas “External APIs” en los ajustes del proyecto hace sencillo incluir o excluir librerías a un proyecto. Adicionalmente pueden incluirse librerías en ubicaciones especiales para tenerlas disponibles en este u otro proyecto.

10.2.4.7.1 Usando APIs esxternas

Para especificar cuales APIs deben ser incluidas, pinche en ajustes “Settings” y en el panel de APIs externas “External APIs”. Aparece una lista de las APIs externas disponibles.

Ilustración 86: APIs externas

Para añadir la API al classpath en el momento de la construcción, marque la casilla de uso “Use”. Si quiere la API atada a su aplicación, marque la casilla


“Bundled”. Si usted sabe que usará su aplicación en dispositivos en los que su API externa seleccionada no está presente, necesita atar esa API a su aplicación.

10.2.4.7.2 Librerías de tercera parte para un proyecto

Cualquier archivo de librería ubicado en el directorio lib de su proyecto es incluido en la construcción y empaquetado de su proyecto. Las librerías deben ser archivos JAR o Zip de clases de tecnología Java.

Por ejemplo, si usted instaló el Sun JavaTM Wireless Toolkit en C:\WTK25 y su aplicación se llama Tiny, la librería de clases va en C:\WTK25\apps\Tiny\lib. Cuando usted construye, ejecute, depura y empaqueta su proyecto, se usan los archivos de clase de la carpeta lib.

10.2.4.7.3 Librerías de tercera parte para todos los proyectos

Algunos dispositivos tienen librerías disponibles a todos los MIDlet suites instalados. Un fabricante, por ejemplo, puede poner disponible APIs adicionales en todos sus dispositivos. En este caso, usted quiere ser capaz de usar estas librerías cuando construye y testa su aplicación. Usted no quiere que las librerías se incluyan en el MIDlet suite empaquetado, puesto que usted está instalándolo en dispositivos que ya disponen de esas librerías.

Usted puede completar esto colocando librerías en el directorio toolkit\apps\lib. Por ejemplo, si usted instaló el Sun JavaTM Wireless Toolkit for CLDC en C:\WTK25, coloque todas la librerías de clase en C:\WTK25\apps\lib. Las librerías en este directorio están disponibles para todos los proyectos.

10.2.4.8 Configuración de la KToolbar

La Ktoolbar incluye algunas opciones avanzadas de configuración. Puede usar estas opciones editando el archivo de propiedades toolkit\wtklib\platform\ktools.properties. Para notar los efectos de los cambios, reinicie la Ktoolbar.

10.2.4.8.1 Cambio de la fuente de la consola

Puede cambiarse la fuente que se usa en la consola de la Ktoolbar (y en las otras áreas de texto) editando dos propiedades. Aquí hay un ejemplo que cambia la fuente a Times New Roman 20 puntos: font.JtextArea = Times New Roman font.size.JtextArea = 20

Para restablecer los valores por defecto, elimine ambas propiedades.

10.2.4.8.2 Ajustando el directorio de Aplicación

Por defecto, el Sun JavaTM Wireless Toolkit para CLDC almacena las aplicaciones en directorios dentro de toolkit\apps. Esto puede cambiarse añadiendo una línea al archivo ktools.properties:


kvem.apps.dir: directorio_de_aplicación

Cualquier barra (\) en la ruta del directorio debe estar precedida por otra barra. Además la ruta no puede contener espacios.

Por ejemplo: kvem.apps.dir: C:\\dev\\midlets

10.2.4.8.3 Ajustando la propiedad de codificación de javac

Por defecto, el javac usa el conjunto de codificación en la plataforma J2SE que esté ejecutandose. Para información sobre cómo sobreescribir la codificación de archivos de fuente, acuda al apéndice C de la documentación del Sun JavaTM Wireless Toolkit para CLDC.

10.2.4.8.4 Trabajando con sistemas de contros de revisión

Usando la propiedad filterRevisionControl, puede configurarse la Ktoolbar para reconocer e ignorar archivos auxiliares creados por los sistemas de control de revisión SCCS, RCS y CVS.

Para reconocer e ignorar los archivos auxiliares, incluya la línea siguiente en el archivo ktools.properties: kvem.filterRevisionControl: true

Como resultado, se previene a la Ktoolbar de tratar los archivos de control de revisión como archivos de fuente o de recurso.

10.2.5 USANDO EL EMULADOR

El emulador del Sun JavaTM Wireless Toolkit para CLDC simula un dispositivo MIDP en su ordenador de escritorio. Éste es un medio conveniente de ver cómo sus aplicaciones funcionan en un entorno MIDP y le da un ajustado ciclo de desarrollo que es contenido enteramente en su ordenador de escritorio.

El emulador no representa un dispositivo específico, pero provee de implementaciones correctas de sus APIs soportadas.

10.2.5.1 Pieles (skins) del emulador

Una piel es una delgada capa encima de la implementación del emulador que le provee de una cierta apariencia, características de pantalla y controles de entrada. El Sun JavaTM Wireless Toolkit para CLDC viene con pieles que representan diferentes tipos de dispositivos.

Tabla 32: Pieles del emulador Name Screen size Canvas size Colors Input

DefaultColorPhone 240 x 320 240 x 289 4096 ITU-T DefaultGrayPhone 180 x 208 180 x 177 4096 ITU-T


MediaControlSkin 180 x 208 180 x 177 4096 ITU-T QwertyDevice 636 x 235 540 x 204 4096 Qwerty

Usted puede crear sus propias pieles de emulador si lo desea. Para más información acuda la la guía básica de customización de la documentación del Sun JavaTM Wireless Toolkit para CLDC.

10.2.5.2 Controles del emulador

El emulador es parecido y actúa como un teléfono móvil dentro de una ventana del escritorio. Esta sección describe cómo controlar el emulador. La descripción y las figuras están basadas en la piel DefaultColorPhone, pero todas las pieles operan de un modo similar.

Ilustración 87: pantalla del emulador

Puede usar el ratón para hacer click en los botones y pulsarlos. La mayoría de botones tienen además atajos de teclado, que suelen ser más fáciles de usar. Los números del teclado del 0 al 9 se corresponden con los botones del emulador del 0 al 9. Algunos atajos menos obvios se muestran en la siguiente tabla.


Tabla 33: atajos de teclado Botón del emulador Botón del teclado

Botón de acción izquierdo F1 Botón de acción derecho F2 Botón de encendido / apagado Esc Botón de selección Enter

La introducción de texto funciona mucho más como se hace en los dispositivos reales. Pulse una tecla de número múltiples veces para obtener la letra que desee. Por ejemplo pulse el 5 dos veces para la letra “K”. Cuando se está introduciendo texto, la tecla asterisco (*) cambia entre los modos mayúsculas, minúsculas, números y símbolos. El indicador en la parte superior de la pantalla muestra el modo actual. La tecla de almohadilla (#) introduce un espacio.

Alternativamente, usted puede simplemente escribir usando el teclado. Aunque esto es conveniente para la introducción de texto, debe recordar que sus usuarios no dispondrán de esta facilidad.

Otra conveniencia es la capacidad de copiar y pegar información en áreas de texto.

10.2.5.3 Estableciendo las preferencias del emulador

Usted puede establecer los ajustes del emulador para parecerse de una manera más cerrada a un dispositivo específico o para testear una aplicación bajo diferentes condiciones de recursos.

10.2.5.3.1 Proxies de red

El emulador usa su conexión de red de escritorio. Por ejemplo, si el emulador ejecuta un MIDlet que crea una conexión HTTP, el emulador trata de crear la conexión usando la configuración de la red del escritorio.

Si su ordenador de desarrollo está detrás de un cortafuegos, debería usar un servidor proxy para crear conexiones HTTP. Si no está seguro, intente examinar los ajustes de su navegador para ver si éste utiliza servidores proxy.

Si usted está usando servidores proxy, necesita configurar el emulador para usar los mismos servidores proxy. Para hacer esto, elija

Edit > Preferences.

En el panel de configuración de red “Network Configuration”, rellene los nombres y números de puertos del servidor que desea utilizar. También puede elegirse la versión de HTTP que se desea utilizar.

Si sus servidores proxy usan autentificación HTTP Básica (RFC 2617), marque autentificación “Authentication” y rellene nombre de usuario y contraseña.


10.2.5.3.2 Tamaño de la pila

La pila es la memoria donde sus objetos de aplicación se almacenan. Bastantes dispositivos reales tienen un tamaño de pila limitado. Puedes ajustar un tamaño máximo de pila para simular con mayor fidelidad las condiciones en un dispositivo real. Elija

Edit > Preferences > Storage

Rellene el tamaño máximo de pila. Si no de especifica un tamaño de pila, por defecto es un megabyte.

Ilustración 88: Configuración del almacenamiento

El emulador tiene almacenamiento persistente, que por defecto se almacena en toolkit\appdb\skin en archivos con extensión .db. Por ejemplo, el almacenamiento persistente para el skin del emulador DefaultColorPhone se almacena en toolkit\appdb\DefaultColorPhone. No hay límite en el tamaño del almacenamiento persistente.

El toolkit te permite elegir una ubicación diferente para los archivos de almacenamiento, y se puede limitar el tamaño del almacenamiento. Esto es útil si desea probar el comportamiento de su aplicación cuando se tiene disponible una pequeña cantidad de almacenamiento persistente.

Para ajustar la configuración del almacenamiento persistente, elija

Edit > Preferences > Storage


Introduzca el nombre del directorio que desea usar para el almacenamiento persistente. Sólo puede introducirse una ruta relativa, y el directorio que especifique se crea dentro de toolkit\appdb.

Si lo desea, puede introducir un límite en kilobytes para el tamaño del almacenamiento persistente. Tenga en cuenta que la implementación del almacenamiento introduce una sobrecarga adicional al espacio que su aplicación usa. Por ejemplo, si introduce 8 kilobytes para el tamaño de almacenamiento persistente, 8192 bytes están disponibles para ambos: datos de la aplicación y sobrecarga de almacenamiento.

Si desea borrar el almacenamiento persistente del emulador, elija en el menú:

File > Utilities > Clean Database

10.2.5.3.3 Ajustando el rendimiento del emulador

El emulador usa muchos de los recursos de su ordenador de escritorio, incluyendo su display y su conexión de red. Comparado con el emulador basado en escritorio, un dispositivo MIDP real suele tener un procesador más lento, menos memoria y una conexión de red más lenta, y puede tener un tipo diferente de display.

El Sun JavaTM Wireless Toolkit para CLDC le permite simular el entorno obligado de un dispositivo real. Aunque el emulador no represente un dispositivo real, el ajuste de la configuración de rendimiento le da información útil sobre el comportamiento de su aplicación bajo diferentes condiciones de ejecución.

Elija: Edit > Preferences > Performance

Ilustración 89: Ajustes del rendimiento del emulador

Ajuste “Graphics primitives latency” para tener efecto en la cantidad de tiempo que transcurre entre las llamadas de la aplicación a los métodos de dibujado en la clase Graphics y cuando realmente tiene lugar el dibujado.


Para cambiar las características de pantalla, elija uno de los tipos de refresco de pantalla, si elige tipo periódico, también necesita especificar la tasa de refresco.

Para simular menor velocidad de un dispositivo real, marque permitir emulación de la máquina virtual “Enable VM speed emulation” y elija la velocidad que desee.

Para ajustar la velocidad de la red simulada, marque “Enable network throughput emulation”, y elija una velocidad en bits/seg.

10.2.5.4 Pausando y Reanudando

Los MIDlets tienen un ciclo de vida que se define en la especificación MIDP. Los MIDlets pueden ser arrancados y detenidos por el dispositivo. Más aún, eventos externos como una llamada entrante pueden causar que el dispositivo pause un MIDlet.

El emulador provee un mecanismo simple para pausar y reanudar la ejecución de MIDlets. Esto es muy útil para probar el comportamiento de la aplicación cuando es pausada.

Cuando el emulador está corriendo, elija en el menú de la ventana del emulador:

MIDlet > Pause

El MIDlet en ejecución se pausa y la pantalla muestra un mensaje “Llamada entrante…”.

Para reanudar la operación, elija en el menú:

MIDlet > Resume

10.2.5.5 Ejecución del emulador sólo

Durante el desarrollo, usted más frecuentemente ejecutará el emulador directamente desde la Ktoolbar presionando el botón “Run” o “Run via OTA”. Para el testeo o las demostraciones, podría querer ejecutar el emulador por sí mismo. Se describen varias propuestas en esta sección. El grupo de programas que el instalador del Sun JavaTM Wireless Toolkit para CLDC crea incluye varias opciones para ejecutar el emulador por sí mismo.

Para ejecutar una aplicación directamente, lo que es análogo a presionar el botón “Run” de la Ktoolbar, elija el item Ejecutar Aplicación MIDP… “Run MIDP Application...”, dentro del grupo de programas del menú de inicio de Windows. El toolkit le pide que localice un archivo descriptor de MIDlet en su disco local. Nótese que el archivo JAR correspondiente también debe estar presente.

Para ejecutar el Software de Gestión de Aplicación del emulador (AMS, Application Management Software), elija el item Aprovisionamiento de OTA ”OTA Provisioning”, que es análogo a la capacidad de la Ktoolbar Ejecución via OTA. El emulador muestra la pantalla de bienvenida AMS, y usted puede instalar aplicaciones escribiendo una url.


Para cambiar los ajustes del emulador, elija el item Preferencias “Preferences” del grupo de programas del toolkit. Esto nos permite configurar las mismas opciones que a través de la Ktoolbar.

10.2.6 MONITORIZANDO APLICACIONES

El Sun JavaTM Wireless Toolkit para CLDC provee de varias herramientas para monitorizar el comportamiento de sus aplicaciones. Estas herramientas son de ayuda depurando y optimizando su código:

• El Analizador “Profiler” lista la frecuencia de uso y el tiempo de ejecución para cada método de la aplicación

• El monitor de memoria muestra el uso de memoria mientras su aplicación se ejecuta.

• El monitor de red muestra datos de red transmitidos y recibidos por la aplicación. Soporta varios protocolos de red incluyendo HTTP, HTTPS, SMS y CBS.

• El trazador muestra información de bajo nivel en la consola de la Ktoolbar.

10.2.6.1 Usando el analizador “Profiler“

El analizador guarda el rastro de cada método en su aplicación. Para una ejecución en particular, este analiza cuanto tiempo se tardó en cada método y cuantas veces se ejecutó. Después de finalizar la ejecución y cerrar el emulador, el Analizador salta, permitiéndole navegar entre los métodos para obtener la información.

Ilustración 90: Activación del Analizador "Profiler"

Para activar el “Profiler”, elija en el menú de la Ktoolbar:


Edit > Preferences > Monitor

Marque la casilla Permitir Analizador “Enable Profiling”. Si está interesado en ver información para todos los métodos de la implementación del sistema, marque Mostrar Clases del Sistema “Show System Classes”. De otro modo, el Analizador muestra sólo métodos del sistema que contienen llamadas a métodos de su aplicación.

Ahora haga click en el botón de ejecución “Run” para arrancar su aplicación. Interactúe con la aplicación como lo haría normalmente. Cuando acabe, apague el emulador. El “Profiler” aparece con información sobre todas las llamadas a métodos en la aplicación.

Ilustración 91: pantalla del "Profiler"

El analizador muestra dos tipos de información:

• Las relaciones entre métodos se muestran en lista jerárquica, la gráfica de llamadas “Call Graph”.

• La parte derecha del analizador muestra el tiempo de ejecución y el número de llamadas para cada método y sus descendientes.

10.2.6.1.1 Gráfica de llamadas “Call Graph“

El gráfico de llamadas muestra una jerarquía de las llamadas a métodos. Métodos que llaman a otros métodos se muestran como carpetas. Haga doble click en un método para abrirlo y ver los métodos a los que este llama. Los métodos que no llaman a ningún otro método se muestran como círculos grises.

Usted puede buscar una clase en particular o un nombre de método. Pinche en Encontrar “Find” y rellene un nombre. La búsqueda se efectúa desde la selección actual en el gráfico de llamadas hasta el final. Si desea buscar en todo el gráfico de llamadas, marque Envolver “Wrap” antes de pinchar el botón “Find” .

Cuando hace click en diferentes nodos del gráfico de llamadas, la parte derecha del analizador muestra detalles sobre los métodos para ese nodo.


10.2.6.1.2 Tiempo de ejecución y número de llamadas

La parte derecha de la ventana del analizador muestra información detallada sobre los métodos. Puede verse el nombre del método, el número de veces que fue llamado, y la cantidad de tiempo que el emulador gastó en el método. El tiempo de ejecución se describe de cuatro formas distintas:

• Ciclos “Cycles” muestra la cantidad de tiempo de procesador gastado en el método por el mismo.

• %Ciclos ”%Cycles” es el porcentaje del total del tiempo de ejecución que se gastó en el método por éste mismo.

• Ciclos con hijos “Cycles with Children” es la cantidad de tiempo gastado en el método y los métodos llamados por este.

• % Ciclos con hijos “%Cycles with Children” muestra el tiempo gastado en el método y sus métodos llamados en comparación con el tiempo total de ejecución.

Pinche en cualquier columna para ordenar por esa columna. Haga click una vez más para alternar entre orden ascendente o descendente.

El panel derecho muestra los métodos contenidos en el nodo seleccionado en el gráfico de llamadas. Si usted desea ver todos los métodos, pinche en el nodo <root> del gráfico de llamadas.

10.2.6.1.3 Guardando y cargando la información del analizador

Para guardar su sesión del analizador, pinche en el botón guardar “Save” de la ventana del “Profiler”. Elija un nombre de archivo.

Para cargar una sesión de analizador, elija en el menú de la Ktoolbar:

File > Utilities > Profiler > Launch

Cuando selecciona un archivo, la ventana del analizador aparece con toda la información de la sesión.

10.2.6.2 Usando el monitor de memoria

La memoria es escasa en muchos dispositivos MIDP. El Sun JavaTM Wireless Toolkit para CLDC incluye un monitor de memoria para facilitar la tarea de examinar el uso de memoria de la aplicación. Usted puede ver la memoria total usada cpor su aplicación y una lista detallada del uso de memoria por objeto.

Para activar el monitor de memoria, elija del menú de la Ktoolbar:

Edit > Preferences... > Monitor

Marque el monitor de memoria “Memory Monitor”.


La próxima vez que arranque el emulador, el monitor de memoria apraecerá mostrando un gráfico del uso de memoria de la aplicación en función del tiempo. El monitor de memoria ralentiza el inicio de su aplicación porque se guarda cada objeto que se crea.

Ilustración 92: monitor de memoria

El gráfico del monitor de memoria muestra la siguiente información:

• Current: Cantidad de memoria actual usada por la aplicación.

• Maximum: Máxima cantidad de memoria usada desde que la ejecución del programa comienza, mostrado en el gráfico por una línea roja.

• Objects: Número de objetos en la pila.

• Used: Cantidad de memoria usada.

• Free: Cantidad de memoria disponible sin usar.

• Total: Cantidad total de memoria al inicio.

Recuerde que usted puede modificar el tamaño de la pila usando la configuración del almacenamiento en los ajustes de la Ktoolbar.

Para pedir al sistema que efectúe una recolección de basura, pinche “Run GC”.

Para ver detalles sobre los objetos en la aplicación, haga click en la pestaña de objetos “Objects” en la ventana del monitor de memoria.


Ilustración 93: detalles del uso de memoria de los objetos

Aparece una tabla con las siguientes columnas:

• Name: Nombre de la clase de los objetos

• Live: Número de instancias. Algunas de estas pueden seleccionarse para una recolección de basura.

• Total: Número total de objetos que se han ubicado en memoria desde que la aplicación comenzó.

• Total Size: Cantidad total de memoria usada por los objetos.

• Average Size: Tamaño medio de objeto, calculado dividiendo el tamaño total entre el número de instancias.

Haga click en cualquiera de las cabeceras de las columnas para ordenar por esa columna.

Usted puede buscar un nombre de clase específico eligiendo del menú de la venta del monitor de memoria:

View > Find...

10.2.6.2.1 Guardando y cargando la información del monitor de memoria

Para guardar la sesión del monitor de memoria, pinche en el botón guardar. Elija un nombre de archivo.

Para cargar una sesión del monitor de memoria, elija del menú de la Ktoolbar:

File > Utilities > Memory Monitor > Launch


Cuando seleccionas un archivo, el monitor de memoria aparece con la información de la sesión.

10.2.6.3 Usando el Monitor de Red

Las aplicaciones MIDP, como mínimo, son capaces de establecer conexiones de red HTTP, pero son también posibles muchos otros tipos de conexiones de red. El monitor de red provee de un método conveniente para ver la información que la aplicación está enviando y recibiendo en la red. Esto es útil si usted está depurando interacciones con la red o buscando algún modo de optimizar el tráfico de red.

Para activar el monitor de red, elija del menú de la Ktoolbar:

Edit > Preferences > Monitor

Marque Activar Monitor de Red “Enable Network Monitoring”.

La próxima vez que arranque el emulador, el monitor de red aparecerá.

Ilustración 94: monitor de red

Cuando la aplicación hace cualquier tipo de conexión de red, se captura información sobre la conexión y se muestra. La figura anterior muestra solicitudes HTTP y respuestas.

El display en la parte izquierda muestra una jerarquía de mensajes y piezas de mensajes. Haga click en un mensaje o una porción de mensaje para ver detalles en la parte derecha del monitor de red. Haga doble click en los mensajes o en las porciones para expandirlos o contraerlos.


Los cuerpos del mensaje se muestran como hileras de valores hexadecimales y su texto equivalente.

Nota - pueden examinarse los mensajes que aún están en el proceso de ser enviados. Los mensajes incompletos se indican por un resaltado en negrita en el árbol de mensajes.

10.2.6.3.1 Filtrando mensajes

Los filtros son útiles para examinar algún subconjunto del tráfico total de red. Los ajustes de filtro son específicos para cada protocolo de red usado.

Pulse el botón de ajustes de filtro “Filter Settings” para usar el filtro. Cambie los ajustes para ajustarlos a sus necesidades.

Tabla 34: ajustes de filtro por protocolo Red Protocolo Ajustes de Filtro

HTTP/HTTPS Introduzca texto para coincidir en las varias partes de los mensajes HTTP: URL, status line, cabeceras o cuerpo.

SMS/CBS Usted puede especificar un protocolo, tipo de mensaje y dirección para coincidir. Incluso puede añadir texto a coincidir en el emisor, receptor y contenido del mensaje.

MMS Introduzca texto para coincidencia en la dirección, emisor, receptor y receptores de copia y copia ciega. Además puede filtrarse por el tema, ID del contenido, MIME type y codificación.

OBEX, SPP/L2CAP Puede filtrar por la URL o el contenido de la cabecera. APDU, JCRMI Filtra en la URL o en el contenido del mensaje SIP No permitido Socket, SSL, Datagram, Comm Introduzca texto para coincidencia en la URL o en el contenido.

Cuando ya has introducido los ajustes de filtro, pulse OK para volver al monitor de red. El checkbox de filtro está activo, indicando que el filtro está en uso. Para desactivar el filtro, desmarque el checkbox.

10.2.6.3.2 Ordenando mensajes

Para mostrar los mensajes en un determinado orden, pinche en Ordenar Por “Sort By” y elija un criterio.

• Time: Los mensajes se ordenan en orden cronológico de tiempo de envio o recepción

• URL: Los mensajes se ordenan por dirección URL. Mensajes con la misma URL se ordenan por tiempo.

• Connection: Los mensajes se ordenan por conexión de comunicación. Los mensajes que usan la misma conexión de comunicación se ordenan por tiempo.

Los parámetros de ordenado son dependientes del protocolo de mensaje que usted eligió.


10.2.6.3.3 Guardando y cargando Información del Monitor de Red

Para guardar la sesión del monitor de red, elija del menú de la ventana del monitor de red:

File > Save ó

File > Save As

Para cargar una sesión de monitor de red elija del menú de la Ktoolbar:

File > Utilities > Network Monitor > Launch

Cuando seleccione un archivo, la ventana del monitor de red aparece con toda la información de la sesión.

10.2.6.3.4 Limpiando el arbol de mensajes

Para eliminar todos los mensajes del monitor de red, elija del menú del monitor de red:

Edit > Clear

10.2.7 USANDO SATSA

Las APIs de seguridad y servicios de confianza (SATSA) proveen acceso a smart card y capacidades criptográficas a aplicaciones que se ejecutan en pequeños dispositivos. La JSR 177 (la especificación de SATSA) define cuatro APIs diferentes como paquetes opcionales:

• SATSA-APDU: Permite a las aplicaciones comunicarse con la smart card usando un protocolo de bajo nivel.

• SATSA-JCRMI: Provee de un método alternativo para la comunicación con la smart card a través de llamadas a objetos remotos.

• SATSA-PKI: Permite a las aplicaciones usar una smart card para firmar datos digitalmente y gestionar certificados de usuario.

• SATSA-CRYPTO: Una API criptográfica de propósito general que soporta resúmenes de mensaje, firmas digitales y cifrados.

El emulador del Sun JavaTM Wireless Toolkit para CLDC da soporte completo para SATSA. Éste capítulo describe cómo puede usarse el toolkit para trabajar con SATSA en sus propias aplicaciones.

Para más información sobre SATSA, acúdase al apartado 6.7.


10.2.7.1 Ranuras de Tarjeta en el Emulador

Los dispositivos SATSA reales pueden tener una o más ranuras que almacenan smart cards. Las aplicaciones que usan SATSA para comunicarse con las smart cards necesitan especificar una ranura y una aplicación de la tarjeta.

El emulador del Sun JavaTM Wireless Toolkit para CLDC no es un dispositivo real, por lo tanto no tiene ranuras físicas donde introducir las smart cards. En vez de esto, se comunica con la aplicación de la smart card usando un protocolo socket. El otro extremo del socket ha de ser un simulador de smart card o podría ser un proxy que hablara con un hardware smart card real.

El emulador del Sun JavaTM Wireless Toolkit para CLDC incluye dos ranuras para smart card simuladas. Cada ranura tiene un socket asociado que representa un extremo del protocolo que se usa para comunicarse con las aplicaciones de la smart card. Puede especificarse el número de puerto del socket para cada ranura. Elija del menú de la Ktoolbar:

Edit > Preferences > SATSA

Los puertos por defecto son 9025 para la ranura 0 y 9026 para la ranura 1.

Ilustración 95: ranuras para smart card

10.2.7.2 Usando el simulador de la plataforma Java Card

El procedimiento básico para testar aplicaciones SATSA con el Sun JavaTM Wireless Toolkit es como sigue:


1.- Arranque cref con una aplicación de la plataforma Java Card

2.- Arranque el emulador del Sun JavaTM Wireless Toolkit para CLDC

Cuando una aplicación SATSA trata de comunicarse con una smart card, usa una conexión socket con cref.

Para más información sobre el entorno de simulación de la pataforma Java Card, lea el apartado 8.3.

10.2.7.3 Usando el Monitor de Red con SATSA

El Sun JavaTM Wireless Toolkit para CLDC puede mostrar los datos intercambiados con las aplicaciones smart card simuladas en el monitor de red. El monitor de red muestra las Unidades de Datos de Protocolo de Aplicación (APDUs) que son intercambiadas entre el emulador y el simulador de la smart card. Puede además mostrar los datos intercambiados usando el protocolo de invocación remota de métodos Java Card (Java Card RMI). Las pestañas de APDU y JCRMI en el monitor de red son las que nos muestran los datos intercambiados con la tarjeta.

El monitor de red parsea cada APDU y muestra los campos en la solicitud y la respuesta apropiadamente.

Ilustración 96: monitorización de datos intercambiados con la smart card


10.2.7.4 Ajustando el Control de Acceso

Los percmisos de Control de Acceso y las propiedades de PIN pueden especificarse en archivos de texto. Cuando la primera conexión APDU o JCRMI se establece, la implementación lee los datos ACL y PIN desde acl_numeroDeRanura en el directorio toolkit\appdb. Por ejemplo, un archivo de control de acceso para la ranura 0 es toolkit\appdb\acl_0. Si el archivo está ausente o contiene errores, el control de acceso se desactiva.

El archivo puede contener información sobre propiedades del PIN y permisos de la aplicación.

10.2.7.4.1 Especificando propiedades del PIN

Las propiedades de PIN se representan mediante una entrada pin_data en el archivo de control de acceso. pin_data { label string id number type bcd | ascii | utf | half-nibble | iso min minLength - stored storedLength max maxLength reference byte pad byte - optional flag case-sensitive | change-disabled | unblock-disabled | needs-padding | disable-allowed | unblockingPIN }

10.2.7.4.2 Especificando Permisos de la aplicación

Los permisos de la aplicación se definen en entradas al archivo de control de acceso (acf). acf AID numbers separated by blanks { ace { root CA name ... apdu { eight numbers separated by blanks ... } ... jcrmi { classes { classname ... } hashModifier string methods { method name and signatiure


... } } ... pin_apdu { id number verify | change | disable | enable | unblock four hexadecimal numbers ... } ... pin_jcrmi { id number verify | change | disable | enable | unblock method name and signature ... } ... } ... }

La entrada acf es un archivo de control de accesp. El AID que sigue a acf identifica la aplicación. Si no hay AID la entrada se aplica a todas las aplicaciones. La entrada acf puede contener entradas ace. Si no hay entradas ace, el acceso a una aplicación está restringido por este acf.

La entrada ace es una entrada de control de acceso. Puede contener entradas root, apdu, jcrmi, pin_apdu, y pin_jcrmi.

La entrada root contiene un nombre de CA. Si el MIDlet suite fue desautorizado usando un certificado emitido por este CA, este ace concede acceso a este MIDlet. Un campo root inexistente indica que el ace se aplica a todas las partes identificadas. Una capital se describe en una sola línea. Esta línea tiene sólo que contener la palabra root y el nombre de la capital, por ejemplo: root CN=thehost; OU=JCT; O=dummy CA; L=Santa Clara; ST=CA; C=US

La entrada apdu o jcrmi describe un permiso APDU o JCRMI. Una entrada de permiso sin especificar indica que se permiten todas las operaciones.

Un permiso APDU contiene una o más secuencias de ocho valores hexadecimales, separados por espacios. Los primeros cuatro bytes describen el comando APDU y los otros cuatro son la máscara, por ejemplo: apdu { 0 20 0 82 0 20 0 82 80 20 0 0 ff ff 0 0 }


El permiso JCRMI contiene información sobre el modificador hash (opcional), lista de clases, y lista de métodos (opcional). Si la lista de métodos está vacia, una aplicación tiene permiso para invocar todos los métodos remotos de interfaces en la lista de clases, por ejemplo: jcrmi { classes { com.sun.javacard.samples.RMIDemo.Purse } hashModifier zzz methods { debit(S)V setAccountNumber([B)V getAccountNumber()[B } }

Todos los números son hexadecimales. Los símbolos tabulación, espacio, retorno de carro y avance de línea se usan como separadores.

Las entradas pin_apdu y pin_jcrmi contienen información necesaria para métodos de introducción de PIN, que es el identificador PIN y la cabecera del comando APDU o los nombres de los métodos remotos.

10.2.7.4.3 Ejemplo de archivo de Control de Acceso pin_data { label Unblock pin id 44 type utf min 4 stored 8 max 8 reference 33 pad ff flag needs-padding flag unblockingPIN } pin_data { label Main pin id 55 type half-nibble min 4 stored 8 max 8 reference 12 pad ff flag disable-allowed flag needs-padding } acf a0 0 0 0 62 ff 1 { ace {


root CN=thehost;OU=JCT;O=dummy CA;L=Santa Clara;ST=CA;C=US pin_jcrmi { id 55 verify enterPIN([B)S change changePIN([B[B)S disable disablePIN([B)S enable enablePIN([B)S unblock unblockPIN([B[B)S } } } acf a0 0 0 0 62 ee 1 { ace { root CN=thehost;OU=JCT;O=dummy CA;L=Santa Clara;ST=CA;C=US pin_apdu { id 55 verify 1 2 3 1 change 4 3 2 2 disable 1 1 1 3 enable 5 5 5 4 unblock 7 7 7 5 } } } acf a0 0 0 0 62 3 1 c 8 1 { ace { root CN=thehost;OU=JCT;O=dummy CA;L=Santa Clara;ST=CA;C=US jcrmi { classes { com.sun.javacard.samples.RMIDemo.Purse } hashModifier xxx methods { setAccountNumber([B)V getBalance()S credit(S)V } } } ace { jcrmi { classes { com.sun.javacard.samples.RMIDemo.Purse } methods { debit(S)V getAccountNumber()[B } } } }

acf a0 00 00 00 62 03 01 0c 02 01 {


ace { root CN=thehost;OU=JCT;O=dummy CA;L=Santa Clara;ST=CA;C=US apdu { 0 20 0 82 0 20 0 82 80 20 0 0 ff ff 0 0 } apdu { 80 22 0 0 ff ff 0 0 } } } acf a0 00 00 00 62 03 01 0c 02 01 { ace { apdu { 0 20 0 82 ff ff ff ff } } } acf a0 00 00 00 62 03 01 0c 06 01 { ace { apdu { 0 20 0 82 ff ff ff ff } } }

10.3 HERRAMIENTA DE SIMULACIÓN JAVA CARD: JAVA CARD KIT

En esta sección se explica como instalar y utilizar la herramienta estándar (de Sun) para desarrollar aplicaciones basadas en la plataforma Java Card, el Java Card Development Kit.

Primero se verá detalladamente el proceso de instalación de los paquetes y herramientas necesarias para desarrollar las aplicaciones, en plataformas Windows.

En segundo lugar, tras una introducción al entorno, se explicará como se utilizan las herramientas de simulación que se incluyen, y como las he utilizado en el caso concreto de este proyecto.

10.3.1 INSTALACIÓN DEL SOFTWARE

10.3.1.1 Descarga del software necesario

Para desarrollar una aplicación usando la plataforma Java Card y OpenCard Framework, se necesitan los siguientes paquetes:

• Obtenga el Java Development Kit (JDK), que se puede conseguir en la siguiente dirección: http://java.sun.com/j2se/.


• Obtenga el Java Card 2.2.1 Development Kit, en la dirección: http://java.sun.com/products/javacard/.

• Obtenga javax.comm. No hace falta si no se va a trabajar con un lector de tarjetas. Se puede conseguir en: http://java.sun.com/products/javacomm. Para instalarlo solo hay que seguir las instrucciones que se incluyen en fichero Readme.html. Hay que asegurarse de que el fichero comm.jar se añade a la variable CLASSPATH.

• Obtenga OpenCard Framework (OCF) Versión 1.2., de la dirección http://www.opencard.org/index-downloads.html

10.3.1.2 Instalación del software

A continuación se explica como instalar el software anteriormente mencionado, según el tipo de sistema operativo (plataformas Windows).

1.- Ejecutar el programa de instalación del JDK

Este programa tendrá un nombre parecido al siguiente j2sdk-1_5_0_11-windows-i586.exe. Después de guardar el fichero, se debe ejecutar y aceptar las condiciones de la licencia. A continuación, el proceso de instalación pedirá que se le especifique el directorio de instalación, por ejemplo: C:\java\jdk1.5.0_11. Luego preguntará si se desea que Internet Explorer o Netscape utilicen la máquina virtual de Java que se está instalando. Lo siguiente es escoger los componentes que se quieran instalar (se recomienda que se instale lo que ya viene seleccionado por defecto). Tras este paso, termina el proceso de instalación de este software.

2.- Descomprimir el paquete de desarrollo de Java Card

Desde el explorador de Windows se puede ver el archivo java_card_kit-2_2_1-win-dom.zip como una carpeta con una cremallera (si no se ha instalado anteriormente alguna utilidad para descomprimir). Se debe entrar en esa carpeta y llevar el directorio java_card_kit-2_2_1 al directorio que se elija, por ejemplo en: C:\proyecto\java. La estructura de directorios que se obtendría, sería parecida a esta: C:\proyecto\java\java_card_kit-2_2_1.

3.- Establecer las variables de entorno.

Para ajustar las variables de entorno se debe desplegar el menú Inicio ► Configuración ► Panel de control ► Sistema. En la pestaña de Opciones avanzadas hay que pulsar el botón Variables de entorno. Como se podrá observar, se pueden incluir las variables de entorno para un usuario (el actual) o para todos los usuarios (si el usuario es un administrador del sistema). Las variables de entorno que se deben crear y sus valores, son los siguientes:

Nombre de la variable Valor de la variable JAVA_HOME C:\java\jdk1.5.0_11 JC_HOME C:\proyecto\java_card_kit-2_2_1 CLASSPATH %JAVA_HOME%\src.jar


Donde JAVA_HOME y JC_HOME son los directorios donde se encuentran el JDK y el entorno de desarrollo de Java Card, respectivamente. Por último, se puede modificar la variable PATH, añadiendo lo siguiente a su valor: ;%JC_HOME%\bin;%JAVA_HOME%\bin . Así se pueden ejecutar los programas que se encuentran en el directorio especificado, desde cualquier otro directorio. Para salir del menú de Variables de entorno, se debe pulsar el botón de Aceptar.

Para comprobar que todo funciona correctamente hay que dirigirse a Inicio ► Programas ► Accesorios ► Símbolo del sistema y ejecutar lo siguiente:

javac

java

Deberían aparecer mensajes de ayuda del compilador y del intérprete de Java.

10.3.1.3 Ficheros instalados

En la siguiente tabla se presenta una relación de archivos y directorios que se encuentran en el directorio java_card_kit-2_2_1 instalado anteriormente:

Directorio/Archivo Descripción api_export_files Directorio que contiene los ficheros de exportación para los paquetes de la

API de Java Card 2.2. bin Directorio que contiene shell scripts o archivos de procesos por lotes para

ejecutar las herramientas y el ejecutable cref. doc En el directorio doc/en/guides se encuentran el Java Card 2.2

Development Kit User’s Guide y el Java Card 2.2 Application Programming Notes. En el directorio doc/en/whitepapers se encuentran las siguientes hojas blancas “white papers”: Java Card 2.2 Off-Card Verifier y el Java Card 2.2 RMI Client Application Programming Interface.

lib Este directorio contiene todos los archivos .jar de Java, necesarios para las herramientas. A continuación se especifica la utilidad de cada uno de los ficheros que se encuentran en este directorio. El fichero api.jar es necesario para escribir los applets y las librerias de los applets de Java Card. El compilador RMIC de Java usa el fichero javacardframework.jar, que se encuentra en dicho directorio. Este compilador se usa para generar stubs para las aplicaciones JCRMI (RMI para Java Card). El archivo apduio.jar lo utiliza apdutool. El jcwde.jar lo utiliza el JCWDE (Java Card Workstation Development Environment. El archivo jcclientsamples.jar contiene la parte del cliente de los ejemplos de RMI de Java Card. El fichero jcrmiclientframework.jar contiene las clases de las API’s de RMI de Java Card.

samples Este directorio contiene los applets de ejemplo y los programas de demostración.

COPYRIGHT_gl ó COPYRIGHT_gl.txt (en Windows)

Contiene el aviso del copyright de Java Card Kit 2.2.

README.html Contiene información general acerca de esa versión de Java Card Kit. RELEASENOTES.html Contiene información importante acerca de esa versión. LICENSE.html Contiene el texto de acuerdo.


Todos los ejemplos se encuentran en el directorio samples ($JC_HOME/samples). La siguiente tabla describe el contenido del directorio samples:

Directorio/Archivo Descripción classes Directorio que contiene las clases de ejemplo. build_samples ó build_samples.bat

Es un script o archivo de proceso por lotes para construir los ejemplos automáticamente.

src Directorio que contiene los códigos fuente de los applets de ejemplo que pertenecen a los paquetes com.sun.javacard.samples.*.

src/demo Este directorio contiene los scripts de las APDU’s y los archivos de salida esperados para las demostraciones. Este directorio también contiene los archivos jcwde.app, opencard.properties, y los ficheros de procesos por lotes para las demostraciones de RMI de Java Card y Secure RMI de Java Card.

src_client Directorio que contiene programas cliente de los dispositivos de aceptación de tarjetas (CAD), para las demostraciones de RMI de Java Card y Secure RMI de Java Card.

10.3.2 INTRODUCCIÓN

El kit de desarrollo para la plataforma Java Cars (“Java Card Development Kit”) es un conjunto de herramientas para el diseño de implementaciones basadas en la tecnología Java Card y para el desarrollo de applets basados en la API para la plataforma Java Card versión 2.2.1.

Flujo del archivo CAP:

Ilustración 97: Arquitectura del kit de desarrollo Java Card

Como se ilustra en la figura, el flujo de datos empieza con código fuente Java siendo compilado e introducido al converter. La herramienta converter convierte clases que comprenden un paquete Java a un applet convertido (CAP) o a un archivo de


montaje basado en tecnología Java Card (“Java Card Assembly”). Un archivo CAP es una representación binaria de un paquete Java convertido.

Un archivo de montaje es una representación en texto legible de un paquete convertido el cual puede ser usado para el testado y la corrección de errores. Un archivo de montaje Java Card puede usarse también como entrada para la herramienta capgen, para crear un archivo CAP.

No se muestra en la figura una utilidad llamada capdump, que produce una versión ASCII simple del archivo CAP para ayudar a la corrección de errores.

Los archivos CAP se procesan por un instalador “externo a la tarjeta” (scriptgen). Este produce un script APDU que sirve de entrada a la herramienta apdutool, la cual envía APDUs a una implementación de un entorno de ejecución Java Card.

10.3.3 CONVERSIÓN DE CLASES A ARCHIVO CAP: HERRAMIENTA converter

La herramienta converter procesa los archivos class que componen un paquete Java. Además de los archivos class, el converter puede procesar archivos export. Dependiendo de las opciones de la línea de comandos, el converter genera como salida un archivo CAP, un archivo de montaje Java Card, y un archivo export.

El archivo CAP es un archivo con formato JAR que contiene la representación binaria ejecutable de las clases en un paquete Java. El archivo CAP también contiene un archivo manifest que provee de información legible respecto al paquete que el archivo CAP representa.

La herramienta converter verifica que los archivos class cumplen las especificaciones de la máquina virtual Java Card. También verifica los archivos export.

El programador es el responsable de la consistencia de los datos de entrada, esto significa que:

• Todos los archivos de entrada son compatibles entre ellos

• Los archivos export de los paquetes importados son consistentes con los archivos class que fueron usados para compilar el paquete que estamos convirtiendo.

Si el paquete a ser convertido contiene clases o interfaces remotas, el converter genera un archive CAP para la versión 2.2.x de la plataforma Java Card, un archivo de montaje Java Card y un archivo export. Si el paquete no contiene clases remotas o interfaces, el converter genera archivos que pueden usarse por la versión 2.1 de la plataforma Java Card.

10.3.3.1 Ejecutando la herramienta converter

La usanza de la línea de comandos de la herramienta converter es la siguiente: converter [options] <package_name> <package_aid>


<major_version>.<minor_version>

El archive para invocar al converter es un shell script (converter) en plataformas Linux, y un archive batch (converter.bat) en plataformas Windows.

10.3.3.2 Argumentos de la línea de comandos

Los argumentos en la línea de comandos son los siguientes:

Tabla 35: argumentos de la línea de comandos en el converter Opción Descripción

<package_name> Nombre completamente cualificado del paquete a convertir.

<package_aid> De 5 a 16 números decimales, octales o hexadecimals separados por ‘:’.

<major_version>.<minor_version> Versión del paquete, definido por el usuario.

10.3.3.3 Opciones en la línea de comandos

Las opciones en la línea de comandos son las siguientes:

Tabla 36: opciones de converter en línea de comandos Opción Descripción

-applet <AID> <class_name>

Asigna el applet AID por defecto y el nombre de la clase que define el applet. Si el paquete contiene varias clases applet, esta opción debe especificarse para cada clase

-classdir <directorio raiz de la jerarquía de clases>

Asigna el directorio raiz donde la herramienta converter búscara clases. Si no se especifica esta opción, se usa el directorio actual como el raiz.

-d <directorio raiz para la salida>

Asigna el directorio raiz para la salida.

-debug Genera la componente opcional debug de un archivo CAP. Si la opción –mask también se especifica, se generará el archivo debug.msk en el directorio de salida.

-exportmap Usa el mapeado de el archivo export predefinido del paquete que se está convirtiendo. El converter buscará el archivo export en el exportpath

-exportpath <lista de directorios>

Especifica los directorios raices en los que el converter buscará archivos export. El carácter separador es ‘;’ en Windows ó ‘:’ en Linux. Si no se especifica, se asigna el exportpath a el classpath de Java.

-help Imprime un mensaje de ayuda -i Indica al converter que soporte el tipo de datos entero de 32 bits -mask Indica si este paquete es para una máscara, de modo que se relajan las

restricciones en los métodos nativos. -nobanner Suprime los mensajes de banner -noverify Suprime la verificación de archivos de entrada y salida -nowarn Indica al converter que no reporte mensajes de warning -out [CAP][EXP][JCA] Indica al converter que genere un archivo CAP, y/o un archivo export,

y/o un archivo Java Card de montaje. -v, -verbose Activa salida verbosa. Incluye abundantes mensjes de proceso . -V, -version Imprime la versión del converter


10.3.3.4 Uso de un archivo de configuración

En vez de introducir todos los argumentos y las opciones por la línea de comandos, podemos incluirlos en un archivo de configuración en formato de texto. Esto resulta conveniente si vamos a usar frecuentemente el mismo conjunto de argumentos y opciones.

La sintaxis para especificar un archivo de configuración es: converter –config <nombre del archivo de configuración>

El argumento <nombre del archivo de configuración> contiene la ruta y el nombre del archivo de configuración.

10.3.4 GENERACIÓN DE LAS APDUS PARA LA INSTALACIÓN: HERRAMIENTA scriptgen

El Kit de Desarrollo puede usarse para descargar un paquete Java Card a una smart card que cumpla la tecnología Java Card. Durante el desarrollo, el archivo CAP puede instalarse en el Entorno de Ejecución Java Card en vez de en la tarjeta.

El instalador es una aplicación multiseleccionable. En el inicio, el instalador es el applet por defecto en el canal lógico 0. El applet por defecto en el resto de canales lógicos es “applet no seleccionado”.

En la siguiente figura se ilustran los componentes del instalador y como se relacionan con el resto de la tecnología Java Card.

Ilustración 98: componentes del instalador

El flujo de datos del proceso de instalación es como sigue:

Un instalador fuera de la tarjeta coge un archivo CAP, producido por la herramienta converter, como la entrada, y produce un archivo de texto que contiene una secuencia de comandos APDU.


Este conjunto de APDU es leído por la herramienta APDUTool y enviado al instalador dentro de la tarjeta

El instalador de la tarjeta procesa los contenidos del archivo CAP contenido en los comandos APDU.

Las APDUs de respuesta del instalador de la tarjeta contienen estados y opcionales datos de respuesta

El instalador fuera de tarjeta es el scriptgen, y es la herramienta que se describe en este apartado.

El archivo de script generado guarda una estructura como la del siguiente ejemplo: powerup; // Select the installer applet 0x00 0xA4 0x04 0x00 0x09 0xa0 0x00 0x00 0x00 0x62 0x03 0x01 0x08 0x01 0x7F; // CAP Begin 0x80 0xB0 0x00 0x00 0x00 0x7F; // component begin 0x80 0xB2 0x01 0x00 0x00 0x7F; // component data 0x80 0xB4 0x01 0x00 0x16 0x01 0x00 0x13 0xDE 0xCA 0xFF 0xED 0x01 0x020x04 0x00 0x01 0x09 0xA0 0x00 0x00 0x00 0x62 0x03 0x01 0x0C 0x01 0x7F; // component end 0x80 0xBC 0x01 0x00 0x00 0x7F; // com/sun/javacard/samples/HelloWorld/javacard/Directory.cap 0x80 0xB2 0x02 0x00 0x00 0x7F; 0x80 0xB4 0x02 0x00 0x20 0x02 0x00 0x1F 0x00 0x13 0x00 0x1F 0x00 0x0E 0x00 0x0B 0x00 0x36 0x00 0x0C 0x00 0x65 0x00 0x0A 0x00 0x13 0x00 0x00 0x00 0x6C 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x7F; 0x80 0xB4 0x02 0x00 0x02 0x01 0x00 0x7F; 0x80 0xBC 0x02 0x00 0x00 0x7F; // com/sun/javacard/samples/HelloWorld/javacard/Import.cap 0x80 0xB2 0x04 0x00 0x00 0x7F; 0x80 0xB4 0x04 0x00 0x0E 0x04 0x00 0x0B 0x01 0x00 0x01 0x07 0xA0 0x00 0x00 0x00 0x62 0x01 0x01 0x7F; 0x80 0xBC 0x04 0x00 0x00 0x7F; // com/sun/javacard/samples/HelloWorld/javacard/Applet.cap 0x80 0xB2 0x03 0x00 0x00 0x7F; 0x80 0xB4 0x03 0x00 0x11 0x03 0x00 0x0E 0x01 0x0A 0xA0 0x00 0x00 0x00 0x62 0x03 0x01 0x0C 0x01 0x01 0x00 0x14 0x7F; 0x80 0xBC 0x03 0x00 0x00 0x7F; // com/sun/javacard/samples/HelloWorld/javacard/Class.cap 0x80 0xB2 0x06 0x00 0x00 0x7F; 0x80 0xB4 0x06 0x00 0x0F 0x06 0x00 0x0C 0x00 0x80 0x03 0x01 0x00 0x01 0x07 0x01 0x00 0x00 0x00 0x1D 0x7F;


0x80 0xBC 0x06 0x00 0x00 0x7F; // com/sun/javacard/samples/HelloWorld/javacard/Method.cap 0x80 0xB2 0x07 0x00 0x00 0x7F; 0x80 0xB4 0x07 0x00 0x20 0x07 0x00 0x65 0x00 0x02 0x10 0x18 0x8C 0x000x01 0x18 0x11 0x01 0x00 0x90 0x0B 0x87 0x00 0x18 0x8B 0x00 0x02 0x7A 0x01 0x30 0x8F 0x00 0x03 0x8C 0x00 0x04 0x7A 0x7F; 0x80 0xB4 0x07 0x00 0x20 0x05 0x23 0x19 0x8B 0x00 0x05 0x2D 0x19 0x8B 0x00 0x06 0x32 0x03 0x29 0x04 0x70 0x19 0x1A 0x08 0xAD 0x00 0x16 0x04 0x1F 0x8D 0x00 0x0B 0x3B 0x16 0x04 0x1F 0x41 0x7F; 0x80 0xB4 0x07 0x00 0x20 0x29 0x04 0x19 0x08 0x8B 0x00 0x0C 0x32 0x1F0x64 0xE8 0x19 0x8B 0x00 0x07 0x3B 0x19 0x16 0x04 0x08 0x41 0x8B 0x00 0x08 0x19 0x03 0x08 0x8B 0x00 0x09 0x19 0xAD 0x7F; 0x80 0xB4 0x07 0x00 0x08 0x00 0x03 0x16 0x04 0x8B 0x00 0x0A 0x7A 0x7F; 0x80 0xBC 0x07 0x00 0x00 0x7F; // com/sun/javacard/samples/HelloWorld/javacard/StaticField.cap 0x80 0xB2 0x08 0x00 0x00 0x7F; 0x80 0xB4 0x08 0x00 0x0D 0x08 0x00 0x0A 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x7F; 0x80 0xBC 0x08 0x00 0x00 0x7F; // com/sun/javacard/samples/HelloWorld/javacard/ConstantPool.cap 0x80 0xB2 0x05 0x00 0x00 0x7F; 0x80 0xB4 0x05 0x00 0x20 0x05 0x00 0x36 0x00 0x0D 0x02 0x00 0x00 0x000x06 0x80 0x03 0x00 0x03 0x80 0x03 0x01 0x01 0x00 0x00 0x00 0x06 0x00 0x00 0x01 0x03 0x80 0x0A 0x01 0x03 0x80 0x0A 0x7F; 0x80 0xB4 0x05 0x00 0x19 0x06 0x03 0x80 0x0A 0x07 0x03 0x80 0x0A 0x090x03 0x80 0x0A 0x04 0x03 0x80 0x0A 0x05 0x06 0x80 0x10 0x02 0x03 0x80 0x0A 0x03 0x7F; 0x80 0xBC 0x05 0x00 0x00 0x7F; // com/sun/javacard/samples/HelloWorld/javacard/RefLocation.cap 0x80 0xB2 0x09 0x00 0x00 0x7F; 0x80 0xB4 0x09 0x00 0x16 0x09 0x00 0x13 0x00 0x03 0x0E 0x23 0x2C 0x00 0x0C 0x05 0x0C 0x06 0x03 0x07 0x05 0x10 0x0C 0x08 0x09 0x06 0x09 0x7F;0x80 0xBC 0x09 0x00 0x00 0x7F; // CAP End 0x80 0xBA 0x00 0x00 0x00 0x7F; // create HelloWorld 0x80 0xB8 0x00 0x00 0x0b 0x09 0xa0 0x00 0x00 0x00 0x62 0x03 0x01 0x03; 0x01 0x00 0x7F; // Select HelloWorld 0x00 0xA4 0x04 0x00 9 0xA0 0x00 0x00 0x00 0x62 0x03 0x01 0x03 0x01 0x7F; powerdown;

10.3.4.1 Ejecutando sciptgen

La herramienta scriptgen convierte un paquete contenido en un archivo CAP en un archivo de script. El archivo de script contiene una secuencia de APDUs en formato ASCII apta para el uso por otra herramienta, como será apdutool, para enviarse al CAD.


El comando de scriptgen en la línea de comandos es el siguiente scriptgen [opciones] <RutaDelArchivoCAP>

Las opciones incluyen:

Tabla 37: opciones de la línea de comandos scriptgen Opción Descripción -help Imprime un mensaje de ayuda y termina -nobanner Suprime la impresión del número de versión -nobeginend Suprime la salida de los comandos “CAP begin” y “CAP end” -o <nombreArchivo> Especifica un nombre de archivo para la salida (por defecto stdout) -package <nombre_paquete> Especifica el nombre del paquete contenido en el archivo CAP -version Imprime el número de versión y termina

Nota: Si el archivo CAP contiene componentes de varios paquetes, es obligatorio el uso de la opción –package <nombre> para especificar el paquete a procesar.

Nota: Los comandos para APDUTool powerup; y powerdown; no se incluyen en la salida de scriptgen. Será necesario incorporarlos posteriormente. AL INCICIO DEL ARCHIVO powerup; // Select the installer applet 0x00 0xA4 0x04 0x00 0x09 0xa0 0x00 0x00 0x00 0x62 0x03 0x01 0x08 0x01 0x7F; AL FINAL DEL ARCHIVO powerdown;

10.3.4.2 Formato del archivo de script

Un archivo script de APDU es un archivo independiente de protocolo que contiene comentarios, comandos de archivo de script y APDUs de comando. Los comandos de archivo script y los comandos APDU terminan en punto y coma (;). Los comentarios tienen el formato de Java (//, /* */ o /**).

Las APDUs se representan por dígitos decimales, hexadecimales u octales,

La sintaxis de las C-APDUs (APDUs de comando) es como sigue: <CLA> <INS> <P1> <P2> <LC> [<byte 0> <byte 1> ... <byte LC-1>] <LE> ;

donde:

• <CLA> :: byte de clase ISO 7816-4.

• <INS> :: byte de instrucción ISO 7816-4.

• <P1> :: byte de parámetro P1 ISO 7816-4.

• <P2> :: byte de parámetro P2 ISO 7816-4.


• <LC> :: Contador de bytes de entrada ISO 7816-4.

• <byte 0> ... <byte LC-1> :: bytes de datos de entrada.

• <LE> :: bytes de longitud esperada a la salida ISO 7816-4. 0 implica 256.

Se soportan los siguientes comandos de scripts:

Tabla 38: comandos de archivo de script Comando Descripción

delay <Integer>; Pausa la ejecución del script por el número de milisegundos indicados. echo "string"; Hace eco de la cadena al archivo de salida. output off; Suprime la impresión de la salida. output on; Restaura la impresión de la salida powerdown; Envía un comando de apagado al lector. powerup; Envía un comando de encendido al lector. Debe enviarse antes del envío de

cualquier C-APDU.

10.3.5 ENVIO DE LAS APDUS DE INSTALACIÓN: HERRAMIENTA apdutool

Como describimos con anterioridad, el flujo de datos del proceso de instalación es como sigue:

Un instalador fuera de la tarjeta coge un archivo CAP, producido por la herramienta converter, como la entrada, y produce un archivo de texto que contiene una secuencia de comandos APDU.

Este conjunto de APDU es leído por la herramienta APDUTool y enviado al instalador dentro de la tarjeta

El instalador de la tarjeta procesa los contenidos del archivo CAP contenido en los comandos APDU.

Las APDUs de respuesta del instalador de la tarjeta contienen estados y opcionales datos de respuesta

En este apartado se describe el uso de la herramienta apdutool que se encarga del envío de la secuencia de APDUs que contiene el archivo CAP a instalar.

Como respuesta a la ejecución de la herramienta apdutool obtendremos un archivo de imagen EEPROM, en el que estará almacenado nuestro Applet, y el cual podremos usar para la ejecución en el en entorno de ejecución de referencia.

El instalador de la tarjeta se invoca mediante el uso de la herramienta apdutool, para cuyo uso hemos de tener en cuenta que el AID del Applet instalador es el siguiente: 0xa0,0x00,0x00,0x00,0x62,0x03,0x01,0x08,0x01


En el escenario descrito, el archivo CAP es descargado y la creación del applet (instanciación) se postpone hasta el último momento.

10.3.5.1 Ejecutando apduool

El archivo para invocar apdutool es un archivo bat (apdutool.bat) en la plataforma Windows.

El uso de apdutool en línea de comandos es apdutool [-h hostname] [-nobanner] [-noatr] [-o <outputFile>] [-p port] [-s serialPort] [-version] <inputFile> [<inputFile> ...]

Los valores de las opciones y sus acciones son:

Tabla 39: opciones en línea de comandos de apdutool Opción Descripción

-h Especifica el nombre de la máquina en que se encuentra el socket TCP/IP. -help Muestra documentación online para este comando -noatr Suprime el mostrado del ATR (Answer To Reset – respuesta al reset) -nobanner Suprime mensajes de banner -o Especifica un archivo de salida. Si no se especifica, la salida es la estándar. -p Especifica un puerto de soket TCP/IP distinto al puerto por defecto -s serialPort Especifica el puerto serie a usar en la comunicación, en vez de un puerto de

socket TCP/IP. Por ejemplo, serialPort puede ser COM1. Para usar esta opción, se ha de instalar el paquete javax.comm

-version Muestra la información de versión <inputFile> Permite la especificación de un script de entrada.

10.3.5.2 Protocolo APDU del instalador

El protocolo APDU del instalador sigue una secuencia temporal específica de eventos en la transmisión de las APDUs como se muestra en la siguiente figura.


Ilustración 99: secuencia de APDUs en el instalador

Los tipos de APDU que se envían son los siguientes:

Select: se utiliza para invocar al instalador dentro de la tarjeta: 0x0x, 0xa4, 0x04, 0x00 Campo Lc AID del instalador Campo Le

Response: una APDU de respuesta es enviada por el instalador dentro de la tarjeta después de cada APDU que este recibe. La APDU de respuesta puede ser un asentimiento (ACK: SW1SW2 = 9000) indicando transmisión correcta o un asentimiento negativo (NAK: SW1SW2 = 6XXX) indicando que ha sucedido algún error. [datos opcionales de respuesta] SW1SW2

CAP Begin: se envía al instalador dentro de la tarjeta para indicar que las componentes del archivo CAP se van a enviar a continuación, en APDUs numeradas secuencialmente. 0x8x, 0xb0, 0x00, 0x00 Campo Lc [datos opcionales] Campo Le


CAP End: se envía para enviar al instalador dentro de la tarjeta que se han enviado todas las componentes del archivo CAP. 0x8x, 0xba, 0x00, 0x00 Campo Lc [datos opcionales] Campo Le

Component ## Begin: se envía para indicar al instalador dentro de la tarjeta que se va a enviar una componente. La doble almohadilla indica el token de la componente que es enviada. 0x8x, 0xb2, 0x##, 0x00 Campo Lc [datos opcionales] Campo Le

Component ## End: se envía para indicar al instalador dentro de la tarjeta que se ha terminado de enviar una componente. La doble almohadilla indica el token de la componente que es enviada. 0x8x, 0xbc, 0x##, 0x00 Campo Lc [datos opcionales] Campo Le

Component ## Data: se envía al instalador dentro de la tarjeta y contiene los datos de la componente ## del archivo CAP. 0x8x, 0xb4, 0x##, 0x00 Campo Lc Campo de datos Campo Le

Create Applet: se envía al instalador dentro de la tarjeta y le dice que cree una instancia de applet desde las componentes del archivo CAP ya transmitidas secuencialmente. 0x8x, 0xb8, 0x00, 0x00 Campo Lc Campo

longitud del AID

Campo AID

Campo longitud de parametros

[parámetros] Campo Le

Abort: indica que la transmisión del archivo CAP se ha parado, y que la transmisión no está completa y debe empezarse desde el principio para completarse correctamente. 0x8x, 0xbe, 0x00, 0x00 Campo Lc [Datos opcionales] Campo Le

Respuestas APDU a solicitudes de la instalación: El instalador envía un código de respuesta de 0x9000 para indicar que un comando se ha completado correctamente. La tabla de los códigos de error se puede consultar en la documentación de la versión 2.2.1 de la implementación de referencia de Java Card.

10.3.5.3 Protocolo APDU para borrado de paquetes y applets

El instalador de la implementación de referencia versión 2.2.1 incorpora la habilidad de borrar paquetes e instancias de applets de la memoria de la tarjeta. Una vez que el instalador está seleccionado, puede recibir solicitudes de borrado del terminal en


forma de comandos APDU. Las solicitudes de borrado de un applet o un paquete no pueden ser enviadas desde un applet en la tarjeta.

Las APDU que se envían son las siguientes:

Delete Package: se envía para borrar el paquete que indicamos con el AID en el campo de datos. 0x8x, 0xc0, 0xXX, 0xXX Campo Lc Campo de Datos Campo Le

Delete Package and Applets: se borran el paquete y las applets simultáneamente. El campo de datos contendrá el AID del paquete que es borrado. 0x8x, 0xc2, 0xXX, 0xXX Campo Lc Campo de Datos Campo Le

Delete Applets: En esta solicitud, el símbolo # en el byte P1 indica el número de applets a ser borrados, hasta un máximo de ocho. El campo Lc contiene el tamaño de del campo de datos. El campo de datos contiene una lista de pares tamaño de AID y AID. 0x8x, 0xc2, 0x0#, 0xXX Campo Lc Campo de Datos Campo Le

10.3.6 EJECUCIÓN DE APPLETS EN LA IMPLEMENTACIÓN DE REFERENCIA: cref

La implementación de referencia está escrita en el lenguaje de programación C, y se llama Entorno de Ejecución Java Card en lenguaje C (C-language Java Card RE). Es un simulador que puede construirse con una máscara ROM, muy parecido a una implementación real basada en tecnología Java Card. Tiene la habilidad de simular memoria persistente (EEPROM), y de guardar y restaurar los contenidos de la EEPROM a y desde un archivo de disco. Los Applets pueden instalarse en el entorno de ejecución Java Card en lenguaje C. Este entorno de ejecución efectúa la entrada/salida mediante interfaz socket, usando el protocolo TLP-224, simulando una tarjeta inteligente en un lector de tarjeta (CAD) acorde a la tecnología Java Card.

El entorno de ejecución Java Card en lenguaje C soporta lo siguiente:

Uso de hasta 4 canales lógicos

• Tipo de datos entero.

• Borrado de objetos

• Reseteado de tarjeta en caso de localización de objeto durante una transacción abortada

En la versión 2.2.1 del Kit de Desarrollo Java Card, el entorno de ejecución Java Card de lenguaje C se encuentra como implementación de 32 bits. La implementación de 32 bits da la habilidad de ir más allá de la limitación de acceso a memoria de 64KB que estaba presente en las antiguas entregas.


10.3.6.1 Ejecutando el Entorno de Ejecución Java Card

La implementación de 32 bits del entorno de ejecución Java Card de lenguaje C se suministra en ejecutables preconstruidos.

En el caso de Windows lo tenemos en %JC_HOME%/bin/cref.exe

El instalador del Kit de Desarrollo, el intérprete de la máquina virtual Java Card y el framework de la plataforma Java Card se construyen en la máscara de instalación. Puede usarse para cargar y ejecutar applets. Aparte del instalador, no contiene más applets.

El entorno de ejecución Java Card de lenguaje C no requiere otros archivos para iniciar la apropiada interpretación y ejecución del bytecode Java Carde de la imagen de la máscara.

10.3.6.2 Línea de comandos del entorno de ejecución

La sintaxis de la línea de comandos del entorno de ejecución Java Card de lenguaje C es la siguiente: Cref [opciones]

La salida de la simulación se muestra por salida estándar, la cual puede redirigirse a algún archivo deseado. El flujo de salida puede ser desde nada hasta muy extenso, dependiendo de las opciones seleccionadas.

Tabla 40: Opciones en línea de comandos de cref Opción Descripción

-b Vierte un histograma de bytecode al final de la ejecución. -e Muestra el contador de programa y la pila cuando ocurre una excepción. -h, -help Imprime una pantalla de ayuda. -i <archivo de entrada> Especifica un archivo para inicializar la EEPROM. -n Muestra una traza de los métodos nativos que son invocados. -nobanner Suprime la impresión de un banner de programa.

-nomeminfo Suprime la impresión de las estadísticas de memoria cuando comienza la ejecución.

-o <archivo de salida> Salva los contenidos de la EEPROM en el archivo nombrado. -p <puerto> Conecta al puerto TCP/IP indicado.

-s Suprime la salida. No crea ninguna salida a no ser que le sigan otras banderas de opción.

-t Muestra una traza línea a línea de la ejecución de la máscara. -version Imprime sólo el número de versión del programa, no ejecuta. -z Imprime las estadísticas de consumo de recursos.


10.3.6.3 Trabajando con Archivos de Imagen EEPROM

Se puede salvar el estado de los contenidos de la EEPROM, y después cargarlos en una invocación posterior del entorno de ejecución Java Card de lenguaje C. Para hacer esto, hay que especificar un archivo de imagen EEPROM o “almacén” para guardar los contenidos de la EEPROM.

Usando las banderas –i y –o manipulamos los archivos de imagen EEPROM en la línea de comandos de cref:

La bandera –i, seguida de un nombre de archivo, especifica un archivo de imagen EEPROM que inicializa la porción de EEPROM de la máquina virtual antes de que la máquina virtual Java Card comience la ejecución.

La bandera –o, seguida de un nombre de archivo, guarda actualizada la porción de EEPROM de la máquina virtual en el archivo nombrado, sobreescribiendo cualquier archivo existente con el mismo nombre.

Un ejemplo de ejecución en el que recibimos un archivo de imagen EEPROM inicial y almacenamos el estado final en otro archivo distinto es el siguiente: cref -i e2save_in -o e2save_out

10 herramientas de desarrollo y...

Documents