N-Idea. Nuevas Ideas

Acceder a controles creados dinámicamente desde servidor en ASP.net

2010-11-19T16:14:00.000Z

Un tema que siempre he considerado un inconveniente en asp.net es la dificultad de acceder a los datos de los controles creados dinámicamente. En este pequeño artículo voy a mostrar una pequeña solución para poder crear controles desde javascript y desde servidor y poder obtener los valores introducidos.

Creación de Controles
Vamos a crear una página aspx con tres botones: uno que cree botones vía javascript, otro que cree cajas de texto desde javascript y otro que cree un textbox desde servidor:

La función javascript que crea los controles es la siguiente:

Unicamente creamos, en base al tipo, un input de tipo submit si es boton o un input de tipo text si el tipo es texto. Al ejecutar la página podemos crear tantos controles como queramos pulsando sobre los botones. El código del evento del botón botonCrearTexto se ejecuta en el servidor y crea un textbox dinámicamente:

La idea ahora es poder obtener los valores introducidos en los campos de texto y el botón que se ha pulsado:

Capturar el valor de los controles
El objetivo ahora es que al pulsar sobre cualquier botón podamos acceder a la información del botón pulsado y al contenido de los diferentes textBox que se hayan creado desde el servidor. El quid del meollo es la clase HttpContext, en la que se mantiene la información intercambiada entre el cliente y el servidor:

Dentro de la colección HttpContext.Current.Request.Form.AllKeys se encuentran todos los valores posteados desde el cliente, el control que realiza el post, el valor de los controles que disponen de valor, el viewstate de la página y el eventvalidation en el caso de controles de servidor. Podemos recorrer esta colección y acceder al valor de los input de tipo texto.

No tenemos en cuentra los controles que empiecen por __ porque son propios de asp.net.

El resultado es que al pulsar sobre cualquier botón, en pantalla mostramos los valores introducidos:

Conclusiones
Muchas veces nos vemos en el problema de controles dinámicos y no podemos resolverlo de forma fácil con asp.net. Con este artículo espero facilitaros la vida. Dependerá del desarrollador evolucionar esta solución para repintar los controles y asignarles el valor entre posts para que no desaparezcan.

Como siempre espero que os haya gustado esta pequeña aportación

Control de Usuario "Contador de filas de DataGridView" en C#

2010-10-11T09:49:00.002Z

Hace poco me encontré con el problema de tener un proyecto en c# de ventanas con muchos datagridview al que había que ponerle a cada gridview un contador de filas. La primera opción era poner en cada pantalla un label y programar el evento DataBindingComplete para que se muestre en pantalla. El engorro era que había que tocar muchas pantallas y tocar el código de todas así que me plantee hacer un control de usuario que pudiera insertar en cada página, que tuviera una propiedad en la que le indicará el control gridview y me sirviera para todas las pantallas. Así que, ¡manos a la obra!

Podéis descargar el código de este control aquí.

El código
El quid del control es definir una propiedad pública en la que podamos definir el gridview y enlazar el evento DataBindingComplete.

La parte de diseño del control es la siguiente:

Insertar el control en el Formulario
Una vez creado el control lo insertaremos en el formulario, en la ubicación que queramos y especificaremos la propiedad GRIDVIEW para que el control obtenga el número de filas.

Podemos incluir tantos controles como queramos. En el momento en que se realice el evento databindingcomplete, el control actualizará el número de filas:

Conclusión
Este es un control muy sencillo pero que arregla una situación en la que habría que haber cambiado mucho código. Además, la utilización de controles de usuario permite un código sostenible y mejorable. En cualquier momento podemos asignarle más funcionalidades o cambiarle el aspecto y se aplicará a todas las pantallas sin tener que cambiar nada.

Como siempre, espero que os haya gustado y os sirva de utilidad.

Plugin "Insertar HTML" para FCKEditor

2010-10-05T12:56:00.000Z

Hace ya bastante tiempo que utilizo el editor WYSIWYG FCKEditor y de siempre me ha parecido una herramienta excepcional. En este artículo voy a desarrollar un plugin que utilizo y que me ha venido muy bien para muchos proyectos. Este plugin es muy simple, un botón para que el usuario pueda pegar un HTML y que se inserte donde tenga puesto el cursor. La razón es que para usuarios no acostumbrados a HTML, explicarles que para, p.e. enlazar con un mapa de google, tienen que pulsar sobre el botón Fuente HTML y localizar la ubicación en el código HTML y pegar allí el código de Google Maps es, en muchos casos, imposible.

Puedes descargar los códigos de este post aquí.

1. El Objetivo
El objetivo es conseguir lo siguiente, un botón en el editor que al pulsarse muestre la ventana de insertar HTML:

2. Ficheros necesarios
Lo primero es conocer la estructura para crear un plugin para FCKEditor. En realidad es muy simple, necesitaremos crear una carpeta en el directorio /editor/plugins (en este caso insertarHtml es el nombre de la carpeta) del FCKEditor que contenga los siguientes ficheros:

fckplugin.js: fichero javascript en el que se definen las propiedades del plugin: formato de la ventana a mostrar, icono, nombre del plugin, ...
insertarHtml.png: imagen para el icono del botón en el FCKEditor.
insertarHtml.php: página que se muestra al pulsar el botón. En este caso es PHP pero puede ser perfectamente HTML o ASPX o lo que se quiera.

Finalmente, necesitamos dar de alta el plugin en el fichero fckconfig.js que está en el directorio raiz del FCKEditor. Vamos a ir viendo paso a paso cada uno de los ficheros.

3. fckplugin.js
En este fichero se configuran los datos generales del plugin. Lo primero es registrar el comando:

FCKCommands.RegisterCommand( 'Insertar_Html', new FCKDialogCommand( 'Insertar código HTML', 'Insertar código HTML', FCKConfig.PluginsPath + 'insertarHtml/insertarHtml.php', 400, 400 ) ) ;

Indicamos qué página se abre en la nueva ventana, el tamaño de la ventana, el nombre que aparece en la ventana, etc. Lo siguiente es crear el botón:

var oHTMLItem        = new FCKToolbarButton( 'Insertar_Html', 'Insertar código HTML en la posición del cursor' ) ;
oHTMLItem.IconPath    = FCKConfig.PluginsPath + 'insertarHtml/insertarHtml.png' ;

y finalmente, registramos el elemento:

FCKToolbarItems.RegisterItem( 'Insertar_Html', oHTMLItem ) ;

4. insertarHtml.php
En el fichero insertarHtml.php es donde se genera la acción. Es la pantalla que se llama cuando el usuario pulsa sobre el botón. La página tiene una parte de presentación HTML y otra de código PHP. La primera parte es:

Es importante la parte inicial de javascript que es la que coge la referencia al FCKEditor que ha llamado a esta ventana. La parte de código es la que se ejecuta cuando se pulsa sobre el botón btnInsertar:

Lo que hacemos es generar el código javascript que inserta el código HTML en la posición del cursor y lo pasamos a la variable codigoJavascript, de la que se hace un echo en la parte HTML. Seguidamente, cerramos la ventana y volvemos a la pantalla del FCEditor.

5. fckconfig.js
Lo último es dar de alta el botón en la toolbar de nuestro FCKEditor y utilizarlo. Para ello tenemos que modificar el fichero fckconfig.js que se encuentra en el directorio raiz del FCKEditor. Lo primero que tenemos que hacer es añadir el plugin:

FCKConfig.Plugins.Add( 'insertarHtml' ) ;

y finalmente, incluir el comando en la toolbarset que estemos utilizando. Yo, p.e., he incluido el botón en la toolbarset default, al final:

FCKConfig.ToolbarSets["Default"] = [
    ['Source','DocProps','-','Preview','-','Templates'],
    ['Cut','Copy','Paste','PasteText','PasteWord','-','Print'],
    ['Undo','Redo','-','Find','Replace','-','SelectAll','RemoveFormat'],
    '/',
    ['Bold','Italic','Underline','StrikeThrough','-','Subscript','Superscript'],
    ['OrderedList','UnorderedList','-','Outdent','Indent','Blockquote','CreateDiv'],
    ['JustifyLeft','JustifyCenter','JustifyRight','JustifyFull'],
    ['Link','Unlink','Anchor'],
    ['Image','Flash','Table','Rule','Smiley','SpecialChar'],
    '/',
    ['FontFormat','FontSize'],
    ['TextColor','BGColor'],
    ['FitWindow','ShowBlocks','-','Insertar_Html']
];

6. Conclusión
Este plugin es muy sencillo pero muy útil para aquellos proyectos en los que el usuario del FCKEditor no tiene conocimientos de HTML pero quiere incluir código de otras webs como pueden ser VIMEO, YouTube, Google Maps, Facebook. Cada día es más normal enlazar HTML en nuestras páginas y este plugin nos facilita la tarea.

Ejemplo: copio la localización de mi pueblo en google maps en la pantalla del plugin:

Al pulsar sobre Insertar HTML, se inserta el código donde tengo colocado el cursor:

Espero que os haya gustado este artículo. En breve más...

Control de acceso web "Dinámica de Tecleo"

2010-05-21T04:24:00.000Z

Hace mucho, mucho tiempo que no escribo en el blog porque he estado muy ocupado pero al fin tengo un rato, así que, manos a la obra.

El artículo va sobre la seguridad y el control de acceso a aplicaciones web y quiero exponer un trabajo de investigación que realicé para un postgrado de la UNED, el control de acceso a aplicaciones web utilizando la dinámica de tecleo.

Podéis descargar los códigos y el script de creación de base de datos aquí.

Antecedentes
A la hora de control el acceso a recursos compartidos, se utilizan tres técnicas distintas, basadas en tres premisas:

Algo que el usuario sabe: esta es la premisa para el 99% de sitios, el usuario conoce un login y un password. Lógicamente, si un atacante consigue obtener esa información podrá suplantar la identidad. Este es, por norma general, el método más inseguro puesto que existen numerosas técnicas para robar las claves y, además, los usuarios no suelen usar claves alfanuméricas complejas porque son difíciles de recordar.
Algo que el usuario tiene: esta es la segunda premisa en la que el usuario es poseedor de algo que solo tiene él. Los sistemas que se basan en esto son los que utilizan tarjetas de coordenadas o certificados digitales, por ejemplo. Este sistema es más complicado porque se suele combinar con el primero y el atacante tiene que, o bien obtener una copia de lo que el usuario tiene o robárselo, además de obtener el usuario y la contraseña.
Algo que el usuario es: esta es la última premisa y es en la que se basa la seguridad biométrica. Las personas disponemos de rasgos o de actitudes que nos hacen únicos en el mundo. Usando esos rasgos físicos o esas actitudes o comportamientos que están impresos en nuestro cerebro se pueden generar patrones de seguridad que son mucho más complejos de romper que los dos anteriores. Usando este tipo de técnicas, el atacante, tendrá que copiar rasgos físicos (iris, retina, huella dactilar, forma de mano,...) o comportamientos (firma caligráfica, dinámica de tecleo,...) algo que en algunos casos es imposible y en otros en muy complicado.

Lo ideal es la utilización de forma combinada de las tres técnicas para obtener un sistema de acceso lo más seguro posible. En este artículo voy a exponer una forma práctica de implementar un sistema de control observando la forma de teclear de los usuarios (dinámica de tecleo) para determinar si el usuario ha sido suplantado o no.

Dinámica de Tecleo
La dinámica de tecleo es una técnica que se basa en el principio de que la acción de escribir en el teclado una palabra o frase (contraseña) muy frecuentemente hace que el acto de escribirla se convierta en algo inconsciente y automático. Esto provoca que ese gesto sea característico nuestro porque influyen tanto procesos mentales que se convierte en una especie de huella dactilar. Los parámetros que se tienen en cuenta a la hora de mesurar la dinámica de tecleo son dos, el tiempo de pulsación de cada tecla y el tiempo entre pulsaciones. En base a estos dos parámetros se pueden crear patrones de comportamiento que nos pueden decir si un usuario es o no es quién dice ser, independientemente de que la contraseña sea correcta o no.

Diseño del sistema de control de acceso
Lo que vamos a hacer es un sistema mixto de control. Por un lado, el usuario va a tener que introducir su usuario y contraseña, se validarán las credenciales y además se controlará la dinámica de tecleo de la contraseña. Dicho tecleo se comparará con un patrón del usuario para ver qué probabilidad hay de que sea realmente nuestro usuario y no un suplantador. Hay que tener en cuenta que cuando hablamos de biometría siempre consideramos probabilidades y no certezas. A la hora de configurar el sistema tendremos que elegir cuál es el umbral a partir del cuál consideraremos que el usuario es un suplantador. Cuanto mayor sea ese umbral, mayor será la seguridad pero más falsos negativos dará y cuanto menor sea el umbral, menor la seguridad pero menos falsos negativos. Cada uno modificará este umbral para que se adecue a sus necesidades y pruebas.

En nuestro sistema vamos a tener 3 módulos diferenciados:

Módulo de captura de datos: es el encargado de capturar los datos de pulsación y tiempo entre pulsaciones en el lado del cliente. Este módulo estará implementado en Javascript.
Módulo de entrenamiento: parte del sistema encargada de generar el patrón con el que se comparan las muestras a identificar.
Módulo de autenticación: parte encargada de decidir si un usuario es quién dice ser o no.

Generación del patrón
Lo primero es la generación del patrón para cada usuario. Tomemos por ejemplo, la palabra MANOLO, para la dinámica de tecleo tenemos que tomar las siguientes muestras:

Tomaremos una muestre para el tiempo de pulsación de cada letra y el tiempo entre pulsaciones. Para generar nuestro patrón tomaremos N muestras de la palabra clave MANOLO escritas por nuestro usuario, cada una de las muestras tendrá 2*n-1 posiciones siendo n el número de caracteres de la palabra. En este caso cada muestra o vector que guardamos tendrá 11 posiciones:

Una vez que disponemos de las muestras, tendremos que obtener un vector con las medias de cada posición y otro con las varianzas de cada posición.

El patrón del usuario será, por lo tanto, un vector de 11 posiciones con la media de cada uno de los tiempos de pulsación y tiempo entre pulsaciones y otro con un vector de 11 posiciones con las varianzas de cada uno de los tiempos. Este patrón lo almacenaremos en una base de datos para, posteriormente, poder realizar la comparación en el control de acceso.

Función de Scoring
La función de Scoring es la encargada de determinar el grado de similitud entre la clave introducida por el usuario que se quiere autenticar y el patrón almacenado en la base de datos.

Una vez obtenido el vector de valores SCORE, realizamos una media entre ellos para obtener un solo valor a comparar:

Este valor se comparará con el valor de UMBRAL definido en el sistema y determinará si el usuario es o no es quién dice ser.

Diseño Real del Sistema
Vamos a ver cómo, podemos diseñar en la vida real un sistema de control de acceso de este tipo. El flujo del sistema es el siguiente:

Para la implementación del sistema vamos a utilizar ASP.net (c#) como lenguaje de servidor, SQL Server como gestor de base de datos y Javascript para el control del tecleo.

Modelo de Base de Datos
En nuestro sistema vamos a tener dos tablas, una para la información de las claves del usuario y otra para almacenar los patrones:

Interfaz Web
Para nuestro ejemplo, se ha unificado en una sola interfaz el entrenamiento del sistema junto con el acceso al mismo:

El usuario tendrá que introducir su usuario y contraseña y, además, la frase de control que se ha utilizado para generar el patrón. En la parte de entrenamiento, el usuario puede ir introduciendo nuevas muestras, cuantas más muestras se tengan mayor será el acierto del sistema.

Cuando se pulsa sobre el botón "Acceder", el sistema devuelve en una pantalla tres valores:

Score Total: valor devuelto por la función de Scoring teniendo en cuenta tanto el tiempo de pulsación como el tiempo entre pulsaciones.
Score Pulsación: valor teniendo en cuenta solamente el tiempo de pulsación.
Score Entre: valor teniendo en cuenta solamente el tiempo entre pulsaciones.

Lógica del Cliente
En el lado del cliente, se ejecuta la lógica necesaria para capturar los datos de las muestras y enviarlos al servidor. Estas funciones se encuentran en Javascript (ver los códigos del proyecto) y preparadas para los exploradores más utilizados. El flujo de llamadas es el siguiente:

Para el caso de la comprobación del acceso al sistema, las llamadas Javascript son las siguientes:

Lógica del Servidor
Toda la lógica de la generación del patrón, la comprobación del usuario y la generación de la función de Scoring se realiza en el servidor. La comunicación entre el cliente y el servidor se realiza mediante llamadas a un servicio web llamado DinamicaTecleo.asmx ell cuál dispone de dos métodos públicos: RecibirMuestras y ComprobarAcceso.

El método RecibirMuestras es el encargado de recibir las muestras, formatearlas y guardarlas en base de datos:

El método ComprobarAcceso es el encargado de comprobar que el usuario es quien dice ser o no. Este método devuelve los tres valores que se muestran por pantalla:

Los datos del patrón se almacenan en la base de datos de la siguiente manera:

Se guardan las muestras de entrenamiento para cada usuario separadas por comas, en una columna los milisegundos de pulsación de cada tecla y en la otra los milisegundos entre pulsaciones.

Conclusión
Las conclusiones que se obtuvieron con los individuos que realizaron las pruebas fueron que, efectivamente, la dinámica de tecleo es una buena técnica complementaria al control mediante usuario y contraseña. Para que el sistema sea efectivo, la fase de entrenamiento debe ser extensa para disponer de muchas muestras. También es bueno eliminar aquellas muestras muy alejadas de la media.
El sistema funciona de forma óptima cuando la frase de control se compone de letras y números sin sentido puesto que es cuando el cerebro tiene que pensar qué teclas pulsar y tiene que mover las manos de su posición natural. En el caso de frases con sentido es más fácil la suplantación porque la posición de las manos y la cadencia es más natural.

Un fallo que no pude resolver en el sistema se produce cuando el usuario escribe tan rápido que antes de soltar una de las teclas ya ha pulsado la siguiente, generando un tiempo de pulsación negativo. Mediante javascript no fui capaz de controlar ese caso y obtenía un error. Si alguien lo corrige le agradecería que lo comentara.

En fin, creo que la dinámica de tecleo es un sistema fácil y barato de control biométrico, no necesitamos aparatos externos ni inversiones en dinero. Puede introducirse de forma transparente en un sistema ya establecido y puede aumentar el nivel de seguridad exponencialmente.

Espero que os haya gustado este artículo.

twitter desde línea de comandos

2009-08-22T13:19:00.005Z

Twitter, ese gran amigo de muchos y mal endémico de la web 2.0 al que yo aún no había sucumbido. El enjuto hermano bastardo del "blogger". La forma de que la web 2.0 convierta tu vida en Tu Vida 2.0, aquí en Mundo Real™.

¿Y qué es lo que le preocupa a un usuario de GNU/Linux cuando conoce Twitter? ¿me quedaré enganchado a ésto por el resto de mis días? ¿seré hallado con 80 años muerto relatando mi propia agonía en 140 caracteres? ...

... pues no ...

... la verdadera pregunta es ... ¿se podrá hacer ésto desde línea de comandos? Y obviamente hay como otras 8000 personas a las que eso ya se les ocurrió antes, así que la respuesta a vuestras plegarias sale con un googleo simple.

Esta es una entrada chorra (tengo algunas más interesantes en mente y proyecto), así que sólo pondré las 2 formas que me han resultado más divertidas.

Fórmula 1 -- postear en twitter usando curl

Gracias al API de twitter, se puede usar curl para hacer un sencillo micro-post con un comando tan chorra como...

curl -u usuario:contraseña -d status="Tu mensaje" http://twitter.com/statuses/update.xml

Fórmula 2 -- Twitter Tools

Esta aplicación escrita en python es la que más me ha gustado para esta tarea (sólo he inspeccionado 4 o 5, tampoco es que tenga mucho criterio). Es sencillita y te permite ver tu twitter con sólo hacer...

twitter

¿Fácil no? Veamos 2 formas de instalarla.

La primera es la más sencilla, y consiste en instalar el paquete apropiado desde línea de comandos. Algo tan fácil como...

sudo aptitude install python-twitter

La otra forma consiste en irse a la página web (http://mike.verdone.ca/twitter/) y descargarse el código fuente (en tar.gz). Luego lo descomprimimos con...

tar -xvzf twitter-.tar.gz

ahora nos intalamos el paquete python-setuptools con...

sudo aptitude install python-setuptools

accedemos a la carpeta twitter dentro de la carpeta descomprimida y desde dentro hacemos...

sudo easy_install twitter

La ventaja de usar la versión descargada es que como es lógico, te descargas la última versión disponible que siempre va a estar por encima de la disponible en los repositorios. La desventaja, que no tienes la actualización automática que te dan los repositorios. Para algo con tan poco calado e importancia, yo personalmente recomiendo usar la instalación desde los repositorios.

La configuración

Para ahorrarnos el tener que poner el usuario y contraseña cada vez que vamos a consultar o escribir en nuestro twitter, podemos crear un fichero en ~/.twitter que tenga un contenido como el siguiente...

[twitter]
email: mi_usuario
password: mi_clave
format: ansi
prompt: '[cyan]twitter[R]'

...que hará que no tengáis que introducir usuario y clave, y además pondrá de colorines el resultado de las lecturas de forma que será más entretenido de leer :).

El resultado

Y ahora el resultado. Un ejemplo...

twitter set "Python Twitter Tools mola, lo recomiendo realmente a todos/as"

produciría un resultado que podríamos ver desde línea de comandos con el comando "twitter" como os pongo a continuación...

Y visto desde la web de twitter...

Y bueno, para quienes finalmente decidáis usar este sistema de microblogging ya iréis descubriendo que desde la Ptt (Python twitter tools) se pueden hacer muchas más cosas. Pero eso ya os lo dejo a vosotros/as.

Un abrazo a todos/as.

Códigos del motor de informes dinámicos en PDF

2009-08-10T09:35:00.002Z

Debido a la demanda de los códigos, he realizado un pequeño proyecto sobre la entrada "Motor de informes dinámicos con iTextSharp(I)" . Os recomiendo leer primero el post para poder entender los códigos correctamente y sacarles el máximo partido.

Podéis descargar el proyecto desde aquí. Espero que os sea de utilidad.

Sistema de plugins en C# usando Reflexión

2009-06-27T17:43:00.001Z

En este post os voy a describir un pequeño sistema de plugins que implementé para un proyecto y que me resultó de mucha utilidad y sobre todo, me permitió aumentar el sistema sin tener que cambiar nada de lo ya establecido (códigos, recompilaciones, etc.).

La idea es disponer de un sistema de plugins para un CMS (gestor de contenidos) de forma que cada plugin sea autogestionado y no haya que tocar nada del sistema a la hora de introducir un nuevo plugin, salvo lógicamente introducir su definición en base de datos. En el proyecto que implementé, los plugins eran elementos visuales que permitían realizar la maquetación de las páginas mostrando el contenido de base de datos de diferentes formas (contenido tabulado, histórico, contenido con scroll, publicidad, etc.).

No voy a entrar en cómo implementar toda la estructura del sistema de elementos visuales (será para un artículo posterior), lo importante es cómo podemos, acceder a clases de c# sin utilizar elementos tipados. Es decir, lo normal para instanciar un objeto es utilizar la siguiente nomenclatura:

TipoObjeto miObjeto = new TipoObjeto(parametros);

En el caso de un sistema dinámico de plugins, no podemos utilizar esa nomenclatura porque no sabemos a priori la clase del objeto a utilizar. En esta situación, la reflexión se nos ofrece como técnica perfecta.

Implementación del sistema de plugins
Los plugins se dan de alta en base de datos, cada proyecto puede utilizar su propia definición de tablas. En mi caso, creé dos tablas, una para guardar la definición del elemento y otra para almacenar las propiedades modificables del elemento. Por ejemplo, uno de los plugins era para introducir un bloque de código HTML directamente en la página. La definición de este elemento es:

y la definición de sus propiedades es:

Lo importante de los datos almacenados para cada elemento es el campo "clase" en el que se guarda la clase de código que implementa la funcionalidad de este elemento. En este caso, la clase es plugins.elementoHtml. Este campo se utiliza luego para la reflexión.

Interfaz de los plugins
Este paso no es necesario pero es bueno que todas las clases que se encarguen de plugin implementen una interfaz obligando a que el método público de acceso sea siempre igual y no haya fallos de parámetros. En mi caso, la interfaz definía los siguientes métodos:

La interfaz define dos métodos, uno para obtener el código html del plugin cuando se debe insertar en el centro de la página y otro para cuando se debe insertar en el lateral de la página. Los parámetros que se pasan son el id particular para cada elemento y un object extras con parámetros extras que hicieran falta en cada caso.

El quid de la cuestión
En cada proyecto, obtendremos referencias a nuestros plugins de la manera que queramos. El quid de la cuestión se encuentra en las líneas que utilizan la reflexión para acceder a los métodos de la clase de cada plugin:

Lo que hacemos es:

Obtener el campo "clase" de la base de datos y llamar al método Type.GetType para obtener el tipo del elemento.
A través de reflexión podemos obtener acceso al constructor e invocarlo pasándole los argumentos necesarios, en este caso null porque no hay argumentos.
Obtener la información del método "Renderizar" que es el que utilizamos de cada clase y que define la interfaz.
Invocamos el método pasándole el objeto inicializado mediante el constructor y le pasamos un vector de objects con los parámetros que el método está esperando.
El resultado del método (en este caso un string), se obtiene haciendo un cast a string.

Conclusión
La reflexión es una herramienta muy potente dentro del lenguaje .net que permite llamar a métodos y objetos sin conocer previamente el tipo. Esto permite generar sistemas como el descrito de una forma eficiente. El problema estriba en que, inicialmente no es un tipo de programación sencilla y requiere un tiempo para acostumbrarse a cómo funciona.

Espero que os haya gustado este artículo y que os sirva esta idea para vuestros desarrollos. En mi caso, me ha sido de mucha utilidad.

Problema de expiración de la sesión en ASP.net

2009-06-14T17:17:00.002Z

Los códigos de este post los podéis descargar desde aquí

Finalmente, por fin he encontrado un rato para escribir un post en el blog. Tenía en mente varios temas pero al fin me he decidido por éste que me parece bastante interesante y útil para aquellos que desarollamos aplicaciones en asp.net. Pongámonos en situación, cuando escribimos aplicaciones, una de las herramientas más utilizadas para mantener la persistencia de los datos es la sesión, almacenamos en sesión tablas con las que trabaja el usuario por pantalla, ids de filas, usuarios, variables, etc. todo ello para que cuando el usuario pulse algún botón y se realice un postback, podamos realizar las acciones correspondientes. Es decir, la sesión nos mantiene conectado con el usuario en un entorno desconectado. El problema viene cuando el tiempo de sesión expira, si el usuario no ha realizado ninguna acción pasados x minutos (5 por defecto), el servidor (IIS) elimina su sesión. En el momento en que el usuario pulse un botón y se vaya al servidor, nos encontraremos con que aquellos datos que habíamos guardado en la sesión ya no existen y (dependiendo de cómo controlemos esta situación) saltará una excepción en algún punto de nuestro código, echándonos fuera de la aplicación, o saltando una fantástica pantalla amarilla o algo parecido.

En aplicaciones en las que las operaciones se realicen en el servidor no vamos a tener problemas con la sesión porque cada vez que el usuario realice un postback, la cuenta de expiración de la sesión se reinicirá. En el caso que hagamos aplicaciones que hagan uso de la lógica del cliente, tipo blogs, editores wysiwyg, o que el usuario realice operaciones largas en el explorador sin tener que ir al servidor, el tiempo de expiración de la sesión se convierte en un gran problema para el programador y en una gran molestia para el cliente. Imaginaos escribiendo un post en un blog y que cuando lleváis 30 minutos escribiendo, habéis acabado el post le dais a guardar y salta una excepción, perdiendo todo el trabajo...

Posibles soluciones a este problema
Existen varias soluciones a este problema, que dependiendo de dónde esté alojada nuestra aplicación nos serán factibles o no.

Solución 1: Web.config
La solución más fácil es incorporar en nuestro web.config la etiqueta "sessionState" con el atributo "timeout" indicándole el número de minutos que deseamos que se mantenga la sesión (dentro de la sección system.web):

En este caso, hemos aumentado el tiempo de sesión a 60 minutos, antes de que el servidor la elimine. Sin embargo, me he encontrado alojamientos en los que, aunque en mi web.config tenga incluido este tag, el tiempo de sesión viene marcado por el servidor sin posibilidad de cambiarlo desde aquí.

Solución 2: Pool de aplicaciones
La segunda solución con la que contamos es la de crear un pool de aplicaciones en el IIS para nuestra aplicación. En dicho pool podemos especificarle el tiempo de sesión que queremos. Además, al crear un pool propio, se lanza un proceso en el sistema para nosotros solos. Esto es bueno en el caso de alojamientos compartidos en los que en el mismo proceso puede haber muchas aplicaciones ejecutándose. Siempre es aconsejable tener nuestro propio pool de aplicaciones, el cual se crea de la siguiente manera:

1. Desde el administrador de IIS, pulsamos con el botón derecho sobre "Grupos de aplicaciones" y seleccionamos un nuevo grupo:

2. Le damos un nombre al nuevo grupo de aplicaciones:

3. Lo siguiente es configurar las opciones de rendimiento para este grupo de aplicaciones, como la cantidad de memoria a asignar, el tiempo de reciclado del proceso o el tiempo de sesión para este grupo, entre otras opciones:

4. Por último, a un sitio o directorio web, le asignaremos este grupo de aplicaciones desde sus propiedades:

Solución 3: Servicio web de Echo
Para implementar las dos soluciones anteriores necesitamos tener control sobre el servidor (cosa que no siempre es así). En el caso que tengamos alojamientos compartidos, podemos utilizar esta opción (es la que utilizo ahora). Normalmente, un portal web dispone de dos partes, la pública (en la que normalmente se puede funcionar con cookies) y la privada en la que trabajaremos con sesiones. Es en la parte privada donde utilizaremos esta opción. La idea es implementar un servicio web que simplemente realice un eco, reciba un parámetro y lo devuelva. Habilitamos la sesión para el servicio web con lo que cada vez que se llame a este servicio, la cuenta de expiración de la sesión se reinicirá. Desde las página de gestión se llama, vía AJAX, periódicamente (yo lo tengo cada 50 segundos) a dicho servicio web para que no reinicie la cuenta. De forma esquemática, la solución es la siguiente:

El código del servicio web es el siguiente:

Tenemos que introducir el using System.Web.Script.Services para poder utilizar este servicio web vía AJAX. Además, la definición del servicio web incluye la sentencia [WebMethod(true)] indicando que se utilizará la sesión en ese método del servicio web. Para llamar a dicho método desde la página maestra (lo normal) o desde cualquier página de nuestra aplicación utilizaremos el siguiente código:

a. Incluir una referencia web al servicio web creado.
b. Dar de alta el servicio web mediante el ScriptManager de la página
En la propiedad Path pondremos la ubicación del fichero .asmx (servicio web). Si, al crear el servicio web, separados el código del fichero, se creará un fichero .asmx con la definición del servicio web donde le hayamos dicho y un fichero .cs con los códigos dentro de la carpeta App_Code.

c. Crear la función Javascript que llama al servicio web

d. Crear el temporizador para que se repita la llamada cada x segundos
Ponemos la función en el onload de la página para que se ejecute al iniciar la página. En este caso esta puesto que se repita la llamada cada 50 segundos (50.000 milisegundos)

Conclusión
Esta última es una solución sencilla que nos puede servir en cualquier entorno en el que trabajemos con aplicaciones asp.net. Utilizando el servicio de echo, nos aseguramos que la sesión del usuario no va a expirar independientemente del tiempo que esté sin hacer ningún postback. En el caso que el usuario cierre la ventana del explorador, se deja de llamar al servicio con lo que la sesión expirará en los 5 minutos correspondientes. Por supuesto, siempre podemos colocar el botón de cerrar que matará la sesión. Como siempre, espero que os sea de utilidad este post y gracias por leer este blog (ya sois un montón).

Traductor de Artilugios en ASP.NET

2009-04-07T17:01:00.013Z

La página de demostración la podéis encontrar aquí.
El comprimido con los códigos del proyecto os lo podéis descargar de aquí.

Hacía tiempo que no escribía un post pero, finalmente, he conseguido un poco de tiempo. En este post lo que os voy a contar es un pequeño pero muy útil, por lo menos para mí, proyecto que hice en su día y que voy mejorando y modificando a medida que lo necesito. El proyecto se llama "Traductor de Artilugios" (un nombre raro, pero es que no tenía y se lo acabo de poner) y es un generador de objetos complejos para gestores de contenido.

Un generador de qué?
La idea la cogí de Wordpress, el cual permite introducir ciertos sinónimos en el editor de post que posteriormente son traducidos a un html más complejo (video y música). Es una forma muy sencilla de poder introducir componentes flash que precisan de etiquetas object o embed o código html elaborado.

Con esta idea me hice una pequeña clase TraductorObjetos.cs que generaba ese código en las páginas de forma dinámica. Inicialmente lo hice para video flash (flv en el servidor) y videos de youtube, luego le metí un reproductor mp3, galeria javascript, ventanas modales, galeria flash. A medida que voy necesitando algo lo voy metiendo.

Sí, muy bien, pero ¿cómo funciona?
El funcionamiento es el siguiente:

a. Desde un editor WYSIWYG (yo utilizo FCKEditor) se introduce el texto de la entrada y se incluye el sinónimo del artilugio. En este caso, voy a meter un video flash por lo que utilizo el sinónimo video. La cadena que utilizo es @video [urlVideo]=[Yeguada1.flv]@ indicando que la url donde se encuentra el video es yeguada1.flv.

b. Ese código se guarda en base de datos. A la hora de renderizar el código en pantalla, se llama a la función Traducir de la clase TraductorObjetos.cs para que rastree el código HTML guardado en base de datos en busca de artilugios. La definición de los artilugios se guarda en una tabla de base de datos con dos campo (nombre y código).

c. Una vez localizado el sinónimo en la cadena de HTML, se sustituye dicha cadena por el valor de base de datos, poniendo los parámetros en su lugar correspondiente. Los parámetros en base de datos se identifican por el símbolo @ (p.e. @urlVideo es un parámetro que será sustituido en tiempo de ejecución).

d. Finalmente, se devuelve el código traducido para que sea renderizado en pantalla.

Extensibilidad

Es muy fácil incluir más elementos en el proyecto, basta con insertar el código a traducir en la tabla con los parámetros correspondientes y listo. Tened en cuenta que todos los ficheros extras utilizados (javascript, flash, hojas de estilo,...) por lo artilugios se localizan en la carpeta "extras" y se deben cargar en la página para que funcionen correctamente.

Conclusión

Espero que este proyecto os sirva tanto como me sirve a mi en mis desarrollos. Con una simple línea, el usuario es capaz de generar códigos muy complejos que de otra forma no podría hacerlo. Os he dejado los códigos del proyecto así como una página de demo donde podéis probar con las diferentes cadenas de sinónimos que tengo puestas.

Artículo en la revista "Solo Programadores"

2009-03-02T11:37:00.004Z

Este mes he publicado un artículo en la revista "Solo Programadores". El artículo se titulo "Aplicaciones multiidioma en ASP.NET" e invito a todo el mundo a que lo lea. Es la primera vez que publico en una revista tecnológica de tirada nacional.

El sumario de la revista es el siguiente:

Encriptación de imágenes/ficheros en servidor con asp.net

2009-02-23T11:47:00.000Z

Las clases Crypto.cs y CryptoProvider.cs las podéis descargar desde aquí.

En este artículo vamos a explorar un aspecto que siempre me ha tenido preocupado a la hora de trabajar con imágenes o ficheros subidos por los usuarios en aplicaciones en internet con asp.net. El problema es la encriptación de esos archivos para evitar que alguna persona pueda linkarlos y acceder a ellos.

La raiz del problema

Cuando programamos una aplicación ASP.NET para que se puedan subir archivos a una carpeta, debemos darle permiso al usuario con el que se ejecuta el proceso ASP.NET para que escriba en esa carpeta y para leer la información (para su poste

rior visionado). Una alternativa es realizar un impersonate sobre el proceso (algo que nunca me ha gustado). Otras alternativas que propone la gente es darles nombres extraños, ubicaciones extrañas, etc. pero no dejan de ser soluciones de ocultación que no solventan el problema. La alternativa que vamos a ver en este post es la de realizar una encriptación del fichero subido con el algoritmo AES-Rijndael de forma que aunque un potencial usuario malintencionado gane acceso al fichero subido, no sea capaz de averiguar su contenido.

Las dos partes del problema

La encriptación de ficheros en servidor tiene dos partes bien diferenciadas que tenemos que solventar:

Encriptación al subir el fichero
Desencriptación al vuelo al visionar/descargar el fichero sin dejar ninguna copia desencriptada en el servidor.

El flujo de información del proyecto es el siguiente:

Vamos al lío, subiendo archivos al servidor...

La primera parte es subir archivos al servidor. Cada uno utilizará el método que quiera, yo he utilizado el componente FileUpload que viene con los controles de servidor. Cuando se pulsa el botón de subir el archivo, se ejecuta el siguiente código, en el que se realizan las siguientes acciones:

Se comprueba que la extensión sea pdf
Se comprueba que el tamaño no exceda los 10MB (estoy hay que configurarlo en el web.config para que el servidor lo admita)
Se sube el fichero con un nuevo nombre único
Se encripta el fichero

La línea clave es objencriptador.EncriptarFichero(), ¿qué es lo que hace esta función? Esta función es la encargada de encriptar el fichero pasado en el primer parámetro, guardarlo con el nombre del segundo parámetro y eliminar el original.

Este método se encuentra en una clase llamada Crypto.cs que utiliza otra llamada CryptoProvider.cs que se encarga de inicializar el proveedor de encriptación. Hay que tener en cuenta que el algoritmo Rijndael se basa en dos cadenas: la clave y el vector de inicialización. Ambos valores se guardan en el app.config de la clase de negocio o se codifican en la clase. Al inicializar el proveedor Rijndael, ambos valores son pasados a su constructor para que pueda encriptar y desencriptar.

En este método, lo que se hace es abrir dos streams, uno para la entrada y otro para la salida. Seguidamente se inicializa el proveedor de servicios de encriptación con la clave (Key) y el vector de inicialización (IV), en modo encriptación. Una vez inicializado, el siguiente paso es crear un stream encriptado para ir pasando del fichero de origen al destino. Pasamos la información de un fichero a otro a través del CryptoStream, cerramos todos los flujos y eliminamos el fichero original.

Ya está encriptado, ¿cómo lo ve el usuario?

Ya tenemos el fichero encriptado en el servidor, por lo que el siguiente paso será desencriptarlo cuando haya que hacerlo sin dejar copia en el servidor. Para ello nos vamos a crear una página aspx que devuelva un flujo desencriptado al explorador del usuario.

En el momento que queramos descargar/visualizar el fichero desencriptado, la página en la que nos encontremos invocará a la página ObtenerPDF.aspx que solicitará el fichero desencriptado a la clase Crypto.cs. Esta clase, devolverá un MemoryStream desencriptado que será devuelto al explorador del cliente (junto con las cabeceras necesarias) para que sea renderizado en pantalla.

En mi caso, miro el fichero a desencriptar de la sesión del usuario. Habría que comprobar la seguridad para evitar accesos indebidos. Una vez obtenido el fichero, invocamos al método DesencriptarFichero() de la clase Crypto, que devuelve un objeto del tipo MemoryStream. Ese objeto es devuelto en el Response de la página para que el cliente lo muestre en pantalla.

El método DesencriptarFichero realiza las operaciones inversas que se realizaron en el método de encriptación.

Con esto tenemos ya listo nuestro sistema de encriptación/desencriptación de ficheros en servidor. Tened en cuenta que esta solución es para entornos de hosting remoto en los que no tenemos capacidad de tocar el sistema de archivos. Si el servidor es nuestro, existen otras alternativas como la reubicación en carpetas fuera del directorio web, u otras.

Conclusión

Como siempre, espero que os haya interesado este post. En este caso, el código que he puesto es solamente el de las clases Crypto y CryptoProvider. Cada caso es particular así que cada uno adaptará la solución a su entorno. En este artículo he intentado dar unas guías para que podáis de una forma "fácil" incluir la encriptación en vuestros desarrollos asp.net.

Diseño de redes inalámbricas con Radio Mobile (III)

2008-12-08T12:00:00.014Z

Bueno, lo primero, mil perdones por tardar tantísimo en seguir escribiendo. Un pico de trabajo...que más bien se podría decir que ha sido una meseta de trabajo, me ha tenido ocupado durante muchísimo tiempo. En otra entrada explicaré tranquilamente en qué (QoS en enlaces WiFi de largo alcance sobre empotrados con GNU/Linux y driver madwifi). Pero ahora vamos a lo que nos ocupaba, ¡al turrón!

En las anteriores entradas (I y II), vimos cómo instalar una máquina virtual sobre una Ubuntu, en la que introdujimos un Windows XP, y que optimizamos para permitirnos instalar nuestro software Radio Mobile. Aprendimos también a descargarnos los mapas SRTM de la región sobre la que queremos diseñar nuestras redes inalámbricas y utilizarlos con Radio Mobile. Hoy trataremos de simular un enlace WiFi de largo alcance y comprobar qué calidad de señal obtendríamos de montar físicamente la red. Es cierto que en este caso jugamos con ventaja, pues la red ya está montada y está claro que funciona, pero aún así, descubriremos en el transcurso de la entrada que en nuestro diseño puede haber errores, y que el diseño no es único, probablemente a cada uno de vosotros os pudiera salir un diseño diferente y puedar ser todos buenos. La selección final vendrá dada también por las condiciones reales que no son emulables con nuestro software (ubicación de las poblaciones, posibilidad de acceso para instalación de repetidores, propiedad colectiva del terreno, negativa de la comunidad...y tantas otras posibilidades que pudieran ser determinantes fuera de lo que es el diseño puro y duro).

Como ya dijimos, vamos a centrar el mapa en un punto de nuestra red que esté situado más o menos a la mitad, para así poder tener una perspectiva de toda nuestra red cuando esté completada. Yo he escogido el Puesto de Salud de Rumi Tuni, así a ojo, cuyas coordenadas son 74º 42' 21.8''O - 1º 47' 39.7''S. Para hacerlo, pinchamos en "Archivo -> Propiedades del mapa", y ahí pulsamos en "Ingresar LAT LON o QRA". Introducimos las coordenadas. Pulsamos sobre la "N" para cambiarla a "S", es decir, en nuestro caso hablaremos de latitud sur, y dejamos la "O" como está pues queremos ingresar una longitud Oeste. Después de introducir las coordenadas, decimos "OK". Ahora introducimos una resolución de 2000 x 2000 pixeles y de altura unos 150 km, aunque ya veremos luego que con ésto no alcanzaremos a cubrir toda la red, pero nos sirve para poder ver la parte central de la red que será la que empecemos diseñando.

Ahora pulsamos "Extraer", y nos debería salir un mapa como éste:

Lo que estáis viendo es el río Napo, al que podéis ver que se le une en la esquina inferior derecha un pequeño afluente que zigzaguea desde muy lejos, ese es el río Curaray, en cuya confluencia con el Napo se encuentra uno de los puntos de la red (San Rafael). El resto de los puntos están en el Napo. Aquí hay que decir que en la realidad, Curaray arriba y muy lejos del resto de la red hay otro punto pero que no está conectado con tecnología WiFi, sino con VHF, y por eso no lo veremos aquí. Si os interesa tener más información de cómo EHAS comunica vía VHF los puntos más aislados, podéis escribirme al correo o buscar vosotros mismos la información en la página de EHAS.

Antes de crear un nodo cliente de la red, vamos a crear las redes y lo que en Radio Mobile se llama "Sistema", que son las propiedades que afectarán a los nodos en general. Para proceder con más limpieza, tenemos que diferenciar entre dos tipos de enlaces, los "Enlaces de distribución", que en la práctica serán los enlaces de los centros y puestos de salud de la región hacia sus torres repetidoras, y los "Enlaces troncales", que serán los enlaces entre las torres con antenas directivas que trasladen los datos entre la red a través de la selva. Para hacernos una idea más real, aquí pongo una foto de una estación cliente típica vista desde su torre y de la parte alta de una estación repetidora (en este caso las fotos son del P.S. de Tempestad, para que le pongáis cara a lo que estáis diseñando).
Estación cliente (la construcción con el techo verde):

Estación repetidora:

Enlace de distribución entre estación cliente y estación repetidora (se puede ver la antena cliente apuntando a la parte alta de la torre, donde está la antena del repetidor apuntando hacia el cliente):

Pues bien, como os imaginaréis, Radio Mobile tiene que tener parametrizadas las antenas que vamos a usar para poder simular los enlaces. El software por defecto trae ya algunas antenas, pero para nuestro caso vamos a usar otras, por lo que necesitaremos de los ficheros *.ant correspondientes a las antenas que queramos probar en nuestros enlaces. En esta red se han usado antenas tipo yagi de 9dBi diseñadas para 2,4GHz para los enlaces entre cliente y repetidor y antenas de grilla de 24dBi que trabajan en la misma frecuencia, pero podéis probar con otras antenas e incluso simular los enlaces en otras frecuencias (para WiFi podéis probar en 5,2 o 5,8GHz que son los otros rangos de frecuencias permitidos) y ver si sería posible establecer los enlaces. Los enlaces en altas frecuencias sufren más atenuación que en bajas frecuencias, y actualmente los drivers inalámbricos para tarjetas que trabajan en esas frecuencias no son del todo estables para largas distancias en linux, pero si queréis probar, ésto es software, haced cuanto os plazca.

En la sección de descargas públicas de la página web de la delegación Carlos III de Ingeniería Sin Fronteras, tenemos unos cuantos de estos ficheros, así que si queréis, podéis descargarlos. Luego los introducís en la carpeta "antenna" de vuestro Radio Mobile (típicamente C:\Radio_Mobile\antenna) y ya podréis usar estas antenas en el programa. Si analizáis el fichero de una antena, veréis que no es muy complejo, es un simple fichero de texto que almacena el diagrama de radiación de la antena escribiendo las ganancias con respecto al azimut y a la elevación haciendo mediciones cada 10º de separación, así que si os habéis fabricado una antena de forma casera y podéis medir su ganancia, ya sabéis que podríais crearos vuestro fichero .ant de la antena personalizada.

Antes de continuar, vamos a terminar de introducir todas las coordenadas de las unidades de nuestras redes. Me he dado cuenta de que en la entrada anterior os puse las coordenadas de las torres repetidoras de cada lugar, pero no de los centros y puestos de salud a los que dan servicio, así que vamos a hacer eso. Os pongo las coordenadas de todas las unidades:

Cabo Pantoja (Torre): 0º58'13,26''S 75º10'29,21''O
Torres Causana (Torre): 1º6'16,53''S 75º0'14,17''O
Tempestad (Torre): 1º17'22,81''S 74º52'27,42''O
Tupac Amaru (Torre): 1º21'46,55''S 74º44'42,89''O
Angoteros (Torre): 1º34'9,54''S 74º36'20,17''O
Campo Serio (Torre): 1º47'35,48''S 74º42'50,09''O
Rumi Tuni (Torre): 2º3'16,22''S 74º26'9,30''O
San Rafael (Torre): 2º22'1,43''S 74º6'42,91''O
Copal Urco (Torre): 2º20'23,41''S 73º47'26,23''O
Santa Clotilde (Torre): 2º29'22,07''S 73º40'41,02''O
Tacsha Curaray (Torre): 2º48'47,46''S 73º32'27,30''O
Cabo Pantoja (CS): 0º58'13,70''S 75º10'29,20''O
Torres Causana (PS): 1º6'16,61''S 75º0'14,48''O
Tempestad (PS): 1º17'21,28''S 74º52'28,94''O
Tupac Amaru (PS): 1º21'46,59''S 74º44'40,85''O
Angoteros (PS): 1º34'11,60''S 74º36'34,51''O
Campo Serio (PS): 1º47'39,70''S 74º42'21,80''O
Rumi Tuni (PS): 2º3'13,40''S 74º26'10,90''O
San Rafael (PS): 2º21'52,39''S 74º6'39,51''O
Copal Urco (PS): 2º20'56,50''S 73º47'23,30''O
Santa Clotilde (CS): 2º29'22,16''S 73º40'39,37''O
Tacsha Curaray (PS): 2º48'48,45''S 73º32'27,26''O

En nuestro esquema sabemos que vamos a tener 2 tipos distintos de estaciones: cliente y repetidor, así que lo primero que vamos a hacer es crear dos sistemas, uno para clientes y otro para repetidores.

Pinchamos en "Archivo -> Propiedades de redes" o directamente sobre el iconito que veis a la izquierda. Os saldrá un diálogo en el que podréis el nombre de vuestra red y demás asuntos, os pego cómo lo he dejado yo...

Canales de 802.11:
Canal 01: 2.412 Ghz.
Canal 02: 2.417 Ghz.
Canal 03: 2.422 Ghz.
Canal 04: 2.427 Ghz.
Canal 05: 2.432 Ghz.
Canal 06: 2.437 Ghz.
Canal 07: 2.442 Ghz.
Canal 08: 2.447 Ghz.
Canal 09: 2.452 Ghz.
Canal 10: 2.457 Ghz.
Canal 11: 2.462 Ghz.

Ahora la explicación de por qué lo he puesto así:
Necesitamos crear 2 tipos de redes, una para la red troncal, que podamos visualizar completa para ver una perspectiva de la red completa, y otra para las redes difusión, para ver cada estación si enlaza con su repetidor. En estas últimas, como luego querremos poder verlas aisladas una a una, y entre ellas no están enlazadas, creamos una subred para cada estación, mientras que en la troncal, también querremos poder ajustar cada enlace, por lo que introducimos también una red por cada enlace de red troncal.
Todas las redes tienen la misma configuración. Son redes de difusión, a las que le he agregado una pérdida adicional de un 20% por bosque (selva) y estamos en un clima continental sub-tropical.
¿Y por qué he puesto las frecuencias entre 2400 y 2474MHz? pues bien, en 802.11, tenemos los canales útiles que os pongo arriba. Las frecuencias que aparecen son las frecuencias centrales de cada canal, pero luego cada canal tiene un ancho de banda aproximado de 22.5MHz, por lo que usa 11.25MHz por abajo y 11.25MHz por arriba, así que redondeando a la alza diremos que usa 12MHz por arriba y 12MHz por abajo. Si restamos a la frecuencia central del primer canal 12MHz nos quedan 2400MHz (o 2.4GHz) y si sumamos 12MHz a la frecuencia central del último canal nos quedan 2474MHz (o 2.474GHz). El lector avisado se habrá percatado ya de que si el ancho de banda de un canal es de 22.5MHz y los canales tienen una separación de sólo 5MHz entre sí, los canales se solapan. ¡Efectivamente! Por eso decimos que en 802.11 (el estándar de WiFi) tenemos 3 canales no interferentes (el 1, 6 y 11). En realidad, serán canales no interferentes dos canales cualquiera que estén separados 5 canales (25MHz) entre sí, pero si escogemos los canales 1,6 y 11 tendremos 3 canales sin interferencias mientras que cualquier otra combinación sólo nos da 2 canales no interferentes. Ésto de escoger canales no interferentes es bastante importante, pues si dos estaciones están transmitiendo en frecuencias solapadas provocarán colisiones e interferencias entre sí que bajarán nuestra tasa de transferencia, y está claro que cuanto mayor tasa de transferencia tengamos, mejor servicio podremos prestar.

La selección del modelo estadístico accidental viene debida a que en este modelo no se nos solicita % de ubicaciones, y dado que nuestra red será fija, no queremos asegurar servicio en un cierto % de ubicaciones, sino un % de tiempo concreto. Los valores que ahí hay que poner en cada caso para optimizar aún están en estudio, así que los he fijado a los que Radio Mobile trae por defecto.

Lo siguiente que vamos a hacer es crear los distintos sistemas que formarán nuestra red. Os voy a ahorrar la búsqueda en los dispositivos del mercado contándoos lo que hay instalado en esta red. Diferenciamos 3 tipos de sistemas:
- Sistema cliente: los clientes enlazan con la torre a través de un router Linksys transmitiendo a 17dBm que dispone de una antena yagi de 9dBi de ganancia.
- Sistema repetidor (enlace de distribución): es la sección del repetidor que se encarga del enlace con el cliente. Dispone de una tarjeta CM9 transmitiendo a 17dBm y una antena yagi de 9dBi de ganancia.
- Sistema repetidor (enlace troncal): es la sección del repetidor que se encarga del enlace con los repetidores adyacentes. Dispone de una tarjeta inalámbrica Ubiquiti SR2, transmitiendo a 26dBm y una antena de grilla Hyperlink de 24dBi de ganancia.

Estos datos son muy importantes puesto que en función del tipo de emisor que tengamos sabremos cuánta potencia estamos suministrando a su antena, y en función de la antena sabremos cuánta ganancia estamos añadiendo al enlace. Para tener todos estos datos, nos vamos a las hojas de características de las tarjetas inalámbricas, antenas y cables coaxiales que usaremos y veremos la potencia que suministramos a nuestro sistema, las pérdidas en los cables y la ganancia de las antenas para nuestra frecuencia de trabajo de (2.4GHz). Aquí podéis ver las hojas de características:
Tarjeta CM9
Tarjeta SR2
Antenas grilla
Cable coaxial de bajas pérdidas LRM-400

En sudamérica, las normas que rigen sobre la potencia radiada equivalente y demás asuntos técnicos son las mismas que en EEUU. Ésto tiene una ventaja en nuestro caso, y es que en Europa, la PIRE (Potencia Radiada Equivalente) máxima es de 100mW mientras que en EEUU es de 1W. Tener un tope máximo de 1W nos permitirá alcanzar distancias mayores. También tenemos que tener en cuenta los canales en los que es capaz de trabajar nuestra tarjeta inalámbrica para el espectro WiFi de América. Por ejemplo, en la hoja de características de la CM9 vemos que trabaja desde los canales 1 al 11, lo que explica el por qué de que arriba sólo os haya puesto los primeros 11 canales de WiFi. Asimismo, también tendremos en cuenta que si queremos alcanzar distancias muy largas, deberemos escoger una modulación para nuestra señal que sea más robusta frente a errores. Si trabajamos a 6Mbps la modulación será tal que se podrán enviar menos bits por símbolo (la velocidad será inferior), pero habrá menor probabilidad de error, lo cual es bueno en un medio con tantos errores como es un clima tropical con mucha humedad, y además, cuando se trabaja en estas modulaciones las tarjetas inalámbricas tienen mayor sensibilidad (son capaces de demodular señales que llegan con menor potencia) y además transmiten con mayor potencia. Todo esto hará que si queremos llegar a distancias muy largas, lo mejor será establecer una tasa de transferencia de 6 Mbps. Para esta tasa, vemos que la tarjeta SR2 tiene una sensibilidad de -94dBm y una potencia de transmisión de 26dBm. Utilizar la más robusta de las modulaciones tendrá sentido para nuestros enlaces largos, pero para nuestros enlaces cortos (los que sirven la señal desde una torre a un puesto de salud) podremos perfectamente utilizar una tasa de transferencia de 54Mbps (máximo de 802.11g). Así pues, para 54Mbps la tarjeta CM9 (es la que usamos en los enlaces de distribución) tendrá una sensibilidad de -74dBm y una potencia de transmisión.

Bien, conocido ésto, nos pasamos a la pestaña de "Topología". En esta pestaña, símplemente tendremos que asegurarnos de que todas nuestras subredes creadas están visibles y tienen seleccionada topología "Red de datos. Topología estrella (Master/Esclavo)", tal como muestro a continuación...

Con todos estos datos ya podemos rellenar nuestra pestaña de "Sistemas". En nuestro sistema estamos usando 3 tipos de sistemas:

Sistema cliente...
formado por un linksys con antena yagi y unos metros de cable coaxial dependientes de la distribución del puesto o centro de salud.

Sistema repetidor (enlace distribución)...
formado por una tarjeta CM9 con antena yagi y un metro de cable coaxial.

Sistema repetidor (enlace troncal)...
formado por una tarjeta SR2 con antena de grilla hyperlink.

Pero para simplificar este ejemplo, vamos a suponer que el sistema del cliente y el del repetidor para el enlace de distribución fueran el mismo, es decir, que abajo en el puesto de salud no tuviéramos un linksys, sino otra tarjeta CM9 recibiendo. En cualquier caso, quede dicho que para un diseño más exaustivo habría que diferenciar estos dos sistemas. Pongo pantallazos de cómo he rellenado esta pestaña en función de los valores que obtenemos de las hojas de características que os puse arriba.

Sistema Troncal...

Sistema de Distribución...

El siguiente paso es la pestaña "Miembros". Ahora agregaremos cada unidad a la red a la que pertenece. Ésta parte es divertida, consiste en ir diciendo, para la red de distribución de tacsha, los miembros serán tachsa y el PS de tacsha, y así para todos los enlaces de distribución. Luego en los enlaces troncales ir añadiendo para tacsha-santa los miembros tacha curaray y santa clotilde, e indicando correctamente que el sistema que utilizarán será en este caso el sistema troncal, mientras en el anterior era el sistema distribución.
Tendremos que ir unidad a unidad ajustando también la altura de la antena, diciendo que no tome el valor del "Sistema", sino seleccionando "Otro" y estableciendo su valor a mano. Para que probéis, os pongo las alturas de las antenas de cada nodo:

Cabo Pantoja (Torre): 42m
Torres Causana (Torre): 45m
Tempestad (Torre): 60m
Tupac Amaru (Torre): 39m
Angoteros (Torre): 66m
Campo Serio (Torre): 66m
Rumi Tuni (Torre): 90m
San Rafael (Torre): 90m
Copal Urco (Torre): 54m
Santa Clotilde (Torre): 72m
Tacsha Curaray (Torre): 72m
Cabo Pantoja (CS): 3m
Torres Causana (PS): 3m
Tempestad (PS): 3m
Tupac Amaru (PS): 3m
Angoteros (PS): 3m
Campo Serio (PS): 3m
Rumi Tuni (PS): 3m
San Rafael (PS): 3m
Copal Urco (PS): 3m
Santa Clotilde (CS): 3m
Tacsha Curaray (PS): 3m

En cuanto al apuntamiento de las antenas, que ajustamos en "Azimut de Antena", tendremos que ir unidad a unidad diciendo que apunte correctamente a la unidad destino del enlace. Es un poco pesado, pero hay que hacerlo, ya que como tenemos antenas directivas, si no apuntamos bien, nuestro balance de enlace será una birria :). Os pego ejemplos de un enlace troncal y de uno de distribución.

Ejemplo del enlace de distribución de la torre de Tacsha Curaray con su Puesto de Salud:

Torre...

Puesto de Salud...

Ejemplo de enlace troncal entre la torre de Santa Clotilde con la de Copal Urco:

Torre de Santa Clotilde...

Torre de Copal Urco...

Y así a lo tonto, hemos casi llegado al final del diseño de nuestra red, sólo nos queda la pestaña "Estilo", que viene a ser la que nos dice con qué colorines nos pinta las líneas dependiendo de los dBs por encima de la sensibilidad de la tarjeta receptora en cada enlace. Normalmente, y debido a las variaciones que sufre un canal inalámbrico y más en entornos tan húmedos y lluviosos como la selva, diremos a Radio Mobile que nos pinte la línea verde sólo cuando nuestro "Rx Relativo" supere los 20dB, y que se ponga amarilla entre 3 y 20dB, lo que nos hará saber qué enlaces no se pueden conseguir con el diseño actual (línea roja), cuáles se podrían conseguir con ciertos retoques quizás (línea amarilla) y cuáles están bien dimensionados (línea verde). Os pongo un pantallazo de esta configuración...

Finalmente, ya tenemos toda nuestra red configurada, así que pulsamos en "OK" y vemos el resultado. La impresión inicial será...pufffff, ¿aquí no enlaza nada con nada o qué? Jeje, bueno, tranquilos, ésto se debe a que nuestras coordenadas GPS no eran del todo exactas, y habrá que afinarlas, pero no os preocupéis que eso lo haremos en la siguiente entrada. Ya habéis tenido bastante por hoy para llevar tanto tiempo sin currar en Radio Mobile :).

Y nada, a comer muchas verduras. Nos vemos en la siguiente entrada de "Diseño de redes inalámbricas con Radio Mobile".

¡A cuidarse!

Integración con SkypeWeb API desde ASP.net y Mono

2008-12-02T17:02:00.022Z

Todos los códigos de este artículo os los podéis descargar desde:
Proyecto de Visual Web Developer Express 2005, aquí
Solución de Monodevelop, aquí

En este artículo vamos a ver una pequeña integración con el API de Skype para plataformas web. Lo que vamos a hacer es implementar un pequeño control de presencia que podremos utilizar en nuestra web. La idea es que, a través del API Web de Skype, interrogar sobre nuestro estado en Skype y, en base a la respuesta, mostrar un icono de estado.

¿Para qué nos puede servir esto, os preguntareis? Pues, por ejemplo, Skype es una muy buena opción para dar soporte a usuario y siempre queda bien poner un icono de que estamos online o no en nuestra página web. También sirve como base para cuando Skype ofrezca más servicios vía web, en fin, y como curiosidad.

Vamos al lío entonces...
Lo primero que tenemos que hacer es configurar Skype para permitirle que notifique nuestro estado. En Herramientas -> Opciones, en la pestaña Privacidad, marcaremos la opción "Mostrar mi estado de conexión en la web":

Una vez marcada esta opción, el servidor de Skype permitirá que le interroguen sobre el estado de nuestro usuario a través de su API. Skype provee de dos métodos por los que obtener el estado de un usuario: vía consulta DNS, vía petición HTTP. Nosotros vamos a ver la segunda opción. La sintaxis para interrogar es la siguiente:

http://mystatus.skype.com/[nombre_usuario].extension

En [nombre_usuario] pondremos el usuario sobre el que queremos obtener el estado, en este caso, será el nuestro, y en extensión le indicaremos a Skype cómo queremos que nos devuelva la información. Disponemos de cuatro opciones:

Sin extensión: Skype devuelve una imagen con el estado del usuario (en la documentación se muestra las diferentes imágenes de que dispone)
xml: devuelve un XML con el estado del usuario en diferentes idiomas
txt: devuelve el estado del usuario en formato texto en el idioma del explorador
num: devuelve un código equivalente al estado del usuario (ésta es la opción que vamos a utilizar).

Lo que vamos a hacer, por lo tanto, es lanzar una petición http al servidor de Skype, obtener la respuesta y en base al código que nos devuelva, poner una imagen u otra en pantalla. Los posibles códigos de retorno son:

0: desconocido
1: offline
2: online
3: fuera
4: no disponible
5: no molestar
6: invisible
7: skype me

Vamos a codificar el asunto

La página de demo la podéis encontrar pinchando aquí

El proyecto está realizado tanto para Monodevelop (para los de Linux) como para Web Developer Express Edition 2005 (para los de Windows). La única diferencia es que Mono no dispone de soporte para el AJAX de ASP.net y en la versión de Mono está quitado el tema de AJAX.

La pantalla del proyecto es la siguiente:

Introduciremos el nombre del usuario a interrogar y pulsaremos sobre el botón "Buscar desde Servidor". El código que se ejecuta en este botón es:

Lo primero que se hace es realizar un HttpWebRequest hacia el servidor de Skype pasándole el usuario que se ha introducido en el textbox. Obtenemos la respuesta y creamos un Stream para ir leyendo el resultado que nos devuelve Skype.

Al leer el código de la respuesta, ponemos en pantalla una imagen correspondiente al estado del usuario. En la carpeta img disponemos de 8 imágenes llamadas 0.png, 1.png, 2.png,... en función del código devuelto, pondremos una u otra.

El resultado es el siguiente:

En el proyecto de Web Developer, le he puesto un UpdatePanel para que no haya refrescos de pantalla, mientras que en Mono no está puesto.

Control de Presencia
Con esta pequeña integración podemos poner un icono en nuestra página web indicando nuestro estado en Skype. Tenemos dos alternativas:

Poner un timer para que vaya refrescando el estado cada x tiempo.
Realizar esta operación en el Page_Load y actualizar el estado solamente cuando se acceda a la página.

También existe la posibilidad de implementar las llamadas desde Javascript a través de un Proxy y manejar la respuesta directamente desde la página (en Javascript).

En fin, espero que os haya gustado este pequeño post, y que os sirva para investigar más allá y para poner vuestro icono de presencia en vuestras webs.

Gráficos dinámicos con Open Flash Chart en ASP.NET y UpdatePanels

2008-11-03T16:21:00.003Z

Todos los códigos de este post os los podéis descargar desde aquí. Todo el proyecto ha sido realizado con Visual Web Developer 2005 Express Edition.

Buenas, hace tiempo que tenía ganas de escribir este artículo sobre la creación de gráficos sobre ASP.NET utilizando la librería flash OpenFlashChart. Este componente flash nos permite crear gráficos muy versátiles, de muy diversos tipos y totalmente customizables en estilo. Además, es código abierto y libre tanto para uso personal como comercial. Aunque ya ha sido liberada la versión 2 (con cambios sustanciales en la forma de pasar los datos), este artículo está basado en la versión 1.9.7 que fue la que inicialmente me descargué en su momento y con la que trabajé.

Introducción del por qué y el cómo
En la página de OFC podéis encontrar multitud de ejemplos, tutoriales, foros, etc. por lo que no voy a explicar aquí los diferentes tipos de gráficos y las funcionalidades de las que dispone OFC.

Después de leer la documentación y de probar con la librería, me surgió un problema, la necesidad de pasarle datos dinámicamente desde código al gráfico y que se refrescará utilizando UpdatePanels de ASP.net. Es decir, poder generar, actualizar, cambiar el tipo de gráfico, todo ello desde código (entiéndase base de datos) y utilizando el AJAX de ASP.NET. Para conseguir tal propósito, me he apoyado en la librería .NET que viene con la descarga de OFC llamada "OpenFlashChartLibrary.dll". Esta librería trae un control de servidor para renderizar el gráfico, pero en este proyecto no se utiliza, sólo utilizaremos las clases que nos permiten generar el código de los gráficos que entiende el componente flash.

¿Qué es lo que queremos conseguir?

Puedes acceder a las páginas de demo pulsando aquí

Si véis en las páginas de demo, lo que queremos conseguir es un entorno basado en AJAX (UpdatePanels) para la generación y actualización de gráficos. En el ejemplo hay dos páginas:

La primera (Ejemplo de gráfico dinámico): permite generar un gráfico dinámicamente y anexarle dos series más. Además podemos elegir si cada serie la queremos en forma de barras o líneas. Si elegimos el gráfico como tarta sólo se renderiza la primera serie. Además el gráfico recalcula automáticamente los márgenes de valores máximos a mostrar en base a los datos introducidos (hay un error en la demo, sólo recalcula para la primera serie, lo siente).

La segunda (Ejemplo de varios gráficos): nos permite generar dos gráficos simultáneamente y actualizarlos de forma independiente, cada uno con sus controles de tipo de gráfico y la serie a mostrar.

¿Cómo lo hacemos?
Todo el tema se basa en la clase RenderizadorGrafico.cs que se encuentra en la carpeta App_Code del proyecto. Dicha clase se apoya en la libreria OpenFlasChartLibrary para la generación del código del gráfico. El funcionamiento general es el siguiente:

Le pasamos a la clase la primera serie a pintar junto con varios valores generales (título del gráfico, posiciones decimales, etc)
Si tenemos más series le vamos pasando cada una de las series restantes (debe coincidir el número de valores de la serie con los del eje X), con su nombre.
Llamamos al método RenderizarGrafico pasándole el código del gráfico (devuelto por los métodos anteriores), la ubicación del componente flash OFC, el div donde queremos que se coloque el gráfico y la página en la que estamos. Este método se encargará de generar el código javascript necesario para mostrar el gráfico y lo inyectará en la página.

La clase RenderizadorGrafico.cs en detalle
La clase RenderizadorGrafico.cs es la encargada de generar el código que entiende el componente OFC para la generación de los gráficos. Esta clase se apoya en la librería OpenFlashChartLibrary.dll que viene con OFC y que simplifica la generación del código. Los métodos de los que dispone la clase son:

RenderizarGrafico: se le pasa el código del gráfico (obtenido con los otros métodos), la ruta del componente OFC, el div donde colocar el gráfico (uno por cada gráfico) y la página que llama al método. Este método tiene una sobrecarga para cuando tenemos varios gráficos en pantalla en la que le pasamos arrays con los diferentes códigos y los divs donde colocar cada gráfico.
GenerarCodigoGrafico: este método se encarga de generar el código del gráfico que le pasaremos al método RenderizarGrafico. A este método le pasaremos la serie tanto para el eje X como para el eje Y y diferentes parámetros de visualización. Este método dispone de una sobrecarga para la representación de gráficos en forma de tarta que se manejan de forma diferente. En esta sobrecarga se le pasan los valores en formato Object[,], pasando en la primera dimensión el valor y en la segunda la etiqueta.
AnexarGrafico: este método permite anexarle más series a un gráfico.

La clase define al inicio el estilo que se va a aplicar para los gráficos, teniendo varios struct y constantes que se van utilizando a lo largo de los métodos. En cualquier momento se puede modificar dichos valores para cambiar el aspecto de nuestros gráficos.

La clase dispone, al final de un par de métodos que se utilizan para corregir ciertos fallos que me encontré en la librería .net en la generación de gráficos del tipo tarta.

¿Cómo genera la clase el gráfico?
La clase, en el método RenderizarGráfico, genera el código javascript necesario para renderizar el gráfico en pantalla. Utiliza el fichero swfobject.js para la incrustación de elementos flash en páginas web y lo inyecta en la página. Para inyectar el código hace uso del elemento ScriptManager del AJAX de ASP.net.

¿Cómo le pasamos los datos?
Tenemos dos formas de pasarle los datos a la clase dependiendo del tipo de gráfico que vamos a realizar. Si vamos a crear un gráfico que no sea del tipo tarta tendremos que crearnos lo siguiente:

Array de strings con los valores del eje X
Array de doubles con los valores del eje Y
Float con el valor máximo de la gráfica
Float con el valor mínimo

Si vamos a generar un gráfico del tipo tarta tendremos que crearnos lo siguiente:

Array de objects de dos dimensiones (object[2,numero elementos]) que tenga en la dimensión 0 el valor y en la dimensión 1 la etiqueta para ese valor. El componente se encargará de pintarlos en el orden correcto.

Lo último, ¿qué código ponemos en el aspx?
Finalmente, para que nuestro gráfico se vea correctamente tendremos que crearnos en la página un div donde vaya a ser colocado. Para utilizar AJAX en los refrescos del gráfico, pondremos dicho div dentro de una estructura UpdatePanel y le pondremos los triggers pertinentes.

Final
Espero que os haya gustado este artículo y que os pueda servir. Personalmente, esta solución se encuentra en entornos de producción y funciona perfectamente. Como siempre, agradeceré cualquier comentario.

Inscripción al concurso de blogs del 20 minutos

2008-10-06T08:21:00.003Z

He inscrito este blog en el concurso de la revista 20 minutos, en la categoría de mejor blog de tecnología. Si os gusta el contenido que publicamos aquí, os agradeceríamos que nos votaseis en cuanto empiecen las votaciones (15 de Octubre).

La dirección del concurso es http://www.20minutos.es/premios_20_blogs y el nombre con el que se ha inscrito éste es "N-Idea de muchos temas".

Uso de Transacciones en C# con TableAdapters

2008-08-27T08:30:00.026Z

Actualización (10-10-2008): el enlace correcto al artículo de Mike Pagel es http://www.codeproject.com/KB/dotnet/transactionta.aspx. Gracias Diego.
Actualización: ha habido un error con el enlace el artículo de Mike Pagel, podéis descargaros su clase desde la dirección http://www.nidea-soluciones.com/PruebasAJAX/TransactionSupport.zip

En este nuevo artículo voy a abordar el tema de la gestión de transacciones cuando trabajamos con TableAdapters generados por Visual Studio. El trabajo con TableAdapters generados por Visual Studio es muy cómodo, en el sentido que genera toda la lógica de acceso a datos y la representación de los mismos con Datatables, pero en el momento en que queremos utilizar transacciones en nuestros accesos a base de datos, el tema se complica. En determinados entornos, sobre todo a la hora de programar sistemas grandes, el uso de transacciones se vuelve inevitable. En este artículo vamos a ver una forma muy cómoda de usar transacciones con TableAdapters generados por Visual Studio.

Un poquito de teoría
Antes de nada, vamos a ver un poco cómo va el tema de las transacciones. ¿Para qué sirven las transacciones? Una transacción lo que nos permite es controlar un grupo de sentencias a base de datos de forma que podamos o bien dar marcha atrás a todas las sentencias o bien confirmar el bloque completo. El control del grupo de sentencias lo lleva la base de datos, de forma que el programador sólo debe indicar si se confirma (Commit Transaction) o no (Rollback Transaction) el grupo de sentencias. En el siguiente dibujo os pongo un ejemplo:

Como podéis ver, desde el momento en el que iniciamos la transacción, todas las operaciones quedan registradas y si realizamos un rollback deshacemos las hechas y si hacemos un commit, la transacción se termina y los cambios quedan confirmados.
Pero, ¿qué pasa si hacemos un select sobre un campo actualizado en una transacción no confirmada? Buena pregunta, porque se plantea un problema, si la sentencia no está confirmada, el gestor de base de datos no puede asegurar que ese dato sea correcto. En ese caso entran en juego los niveles de aislamiento de transacciones (Isolation Levels) que, básicamente, lo que deciden es cómo se debe comportar el gestor de base de datos en estas situaciones.

Bueno, al lío
Vamos a ir paso a paso, lo primero que vamos a hacer es crearnos una aplicación de Windows Forms en C# (me supongo que sabéis hacerlo). Para todo vamos a utilizar la versión gratuita (Express) de visual studio, en concreto Visual C# 2005 Express Edition.

1. Crearse un proyecto "Aplicación para Windows"
2. En la pantalla principal nos creamos los siguientes controles

3. Nos creamos una nueva base de datos en SQL Server 2005 Express Edition que se llame "PruebaTransacciones" con una tabla llamada "Tabla1" que contenga 2 campos "Id" y "Nombre" y otra llamada "Tabla2" con los mismos campos. La definición es la siguiente:

4. Nos creamos en nuestro proyecto dos TableAdapters, uno para cada una de las tablas que hemos creado en base de datos.

Por ahora, nuestro proyecto y los TableAdapters nos tienen que quedar de la siguiente manera:

Ahora mismo no disponemos de soporte para transacciones porque los tableadapters generados no lo incluyen. Es en este momento cuando le vamos a introducir esa nueva funcionalidad. Vamos a utilizar una clase creada por Mike Pagel y que podéis encontrar en su artículo del CodeProject http://www.codeproject.com/useritems/typed_dataset_transaction.asp. Lo que vamos a hacer es sobreescribir la clase base de los tableadapters con esta que incorpora las funcionalidades de las transacciones. Para ello, incluiremos la clase en nuestro proyecto y en las propiedades de los TableAdapters, pondremos el nombre de la clase en la propiedad BaseClass:

En mi caso le he puesto Transaccion.TransactionSupport porque el namespace de la clase es Transaccion.

Utilizar las transacciones
Ahora que tenemos soporte para transacciones vamos a utilizarlas en nuestra pantalla. Teníamos creados un botón y dos radiobuttons, vamos a programar el evento Click del botón de la siguiente manera:

Lo que hacemos es insertar un registro en la tabla1 y confirmamos o deshacemos la operación en base a los radiobuttons que se pusieron. Ahora vamos a modificar un poco el código para realizar una operación sobre las dos tablas compartiendo la transacción:

En este caso, hemos igualado la transacción secundaria con la principal para poder interactuar con varias tablas a la vez. El último paso es: ¿cómo pasar una transacción por diferentes clases y métodos para actuar sobre múltiples tablas sin tenerlo todo en el mismo método? La pregunta es larga pero la respuesta es corta, veamos la siguiente modificación al método del botón:

En este caso, estamos instanciando la clase ManejadorTabla2 y llamando al método ActualizarTabla para guardar los cambios en la tabla2. A este método, aparte de los registros le estamos pasando la transacción. El código interno del método es el siguiente:

Lo que hacemos en este método es controlar si se pasa como argumento una transacción o no. Si el método falla, lo que hacemos es devolver un false para el método que controla la transacción decida qué hay que hacer. En caso que no se pase transacción, el método se comporta de forma normal.

Conclusión
Ciertamente, el uso de transacciones en entornos grandes es obligatorio. No nos podemos plantear un sistema sin control de transacciones porque antes o después se haría inviable su programación. Creo que esta solución al problema es muy simple, elegante y efectiva y os animo a probarla. Como siguiente paso para el que guste de estos temas queda la modificación de la clase para adaptarlas a entornos no SQLServer como puede ser MySql. El código es muy sencillo y creo que se podría modificar rápidamente.

En fin espero que os haya gustado este articulillo sobre transacciones.

Motor de Informes Dinámicos con itextsharp (II)

2008-07-03T10:15:00.016Z

Hola de nuevo a todos, ha pasado un tiempo desde la primera parte del tutorial, pero ya he encontrado tiempo para escribir esta segunda parte (más interesante que la primera). En la primera parte vimos cómo funcionaba la librería itext# para generar informes PDF al vuelo. En esta segunda parte lo que veremos será cómo crear plantillas XML para juntarlas posteriormente con datos y generar el PDF.

El inicio de todo
Lo que vamos a hacer es por un lado, crearnos una plantilla XML con parámetros, por otro lado, generar nuestros datos en formato XML (para poder guardarlos en base de datos) y finalmente, juntar las dos cosas y obtener, al vuelo, la plantilla con los datos en formato PDF.

El flujo de datos

El funcionamiento del sistema de plantillas es el siguiente.

Desde la página obtenemos los datos en XML y la plantilla, lo cual va en sesión a la página ImpresionPDF.aspx. Esa página se encarga de llamar a la clase ParseadorPDF.cs que es la que contiene la lógica de negocio para generar el PDF al vuelo. Esa clase devuelve un MemoryStream con el PDF a la página, la cual lo renderizará en pantalla.

La plantilla XML
El primer paso es generarnos la plantilla XML con los tags adecuados que entienda la librería. Para un ejemplo de los tags que se pueden utilizar, en la ayuda nos ofrecen algunos ejemplos. Nosotros vamos a trabajar con el siguiente XML que es muy sencillo:

En este informe utilizamos diferentes tags, como: table, row, cell, newline, itext(obligatorio al inicio y al fin) y en medio hemos introducido tags propios:nomAE, numAE, nomAl y dniAl. Estos serán los parámetros que se sustituirán posteriormente por los valores que le digamos. La librería itextsharp tiene un problema a la hora de parsear los XML en PDFs y es que NO PUEDE TENER ESPACIOS EN BLANCO DENTRO DE LOS TAGS TABLES. Es decir, para generar una plantilla XML, no podemos indentarla, sino que tiene que ir como se muestra en la imagen o dará un error de ejecución.

Los datos a parsear
En este paso, lo que vamos a ver es cómo pasarle los datos que queremos que aparezcan en el informe a la librería para que los junte correctamente. Le vamos a pasar un vector con dos dimensiones, en una dimensión irá un esquema XML con los datos a imprimir y en la otra irá la plantilla a utilizar. El esquema XML es como el siguiente:

A la hora de crear el documento veremos cómo crear este esquema XML para guardarlo en base de datos. Una vez recuperado el documento XML, la creación del vector es la siguiente:

En el vector de objetos “datos” guardamos el XML y la plantilla correspondiente. Seguidamente llamamos a la pantalla ImpresionPDF.aspx que se encargará de generar la plantilla XML.

La página ImpresionPDF.aspx

Esta página es la encargada de recibir los datos desde la sesión y llamar a la clase encargada de generar el PDF. Además de esto, obtiene de base de datos los márgenes a aplicar, las dimensiones del PDF y varios datos de formato propios de la plantilla. Una vez recuperados estos datos llama al método GenerarPDF de la clase ParseadorPDF:

El método devuelve un MemoryStream con el fichero PDF para ser renderizado. Veamos ahora cómo se produce el parseo real de los datos.

La clase ParseadorPDF.cs

Esta es la clase que se encarga de juntar las plantillas con sus respectivos datos. El flujo es el siguiente:

1. Crear el PDF global que va a ser devuelto y ponerle las dimensiones precisas:

2. Recorrer los datos y plantillas pasadas para ir tratando a cada una de ellas. Este método permite que se pasen a la vez varios XML de datos con varias plantillas en el mismo vector de objetos, por lo que lo primero es ir recorriendo las diferentes plantillas. Para cada XML de datos realizamos una conversión a un vector de objects con los datos que es lo que entiende el método:

3. Para cada plantilla con sus datos los juntamos en un PDF temporal que es guardado en una ruta temporal y posteriormente anexado al PDF global que se creó al inicio. En esta parte es donde se realiza la unión real de los datos, creando un hashtable que enlaza cada parámetro con su valor y llamando al método Parse de la librería PDF:

4. Una vez realizado el parseo, lo que tenemos que hacer es eliminar los ficheros temporales que hemos ido creando en el proceso. Estos ficheros se encuentran guardados en la variable subFicheros.

El método ParsearDatos

Este método es el encargado de crear un hashtable que enlace cada parámetro con su valor. Lo primero es crear el hashtable y asignarle los primeros valores fijos:

Seguidamente, para cada parámetro, tendremos que unirlo con su parámetro y asignarle un XMLPeer correcto:

Dependiendo del tipo de parámetro que sea será tratado de una forma o de otra, lo que rellenamos en el método es la propiedad peer.Content con el valor del parámetro y si le queremos incluir más atributos rellenamos la propiedad peer.AddValue.

El método ConcatenarPaginas

Este método se encarga de unir las páginas de los PDF temporales que creamos con la del PDF global que será devuelto a la capa de presentación. El código de este método es el siguiente:

El final

Bueno, con esto termino el artículo. Espero haberos dado una idea inicial de cómo realizar un motor de plantillas basado en XML para la librería itextsharp. No he podido explicar el funcionamiento completo porque eso exigiría muchísimo tiempo pero creo haber ahondado bastante para que podáis seguir vosotros.

Como siempre, para cualquier duda que os surja aquí estoy.

Diseño de redes inalámbricas con Radio Mobile (II)

2008-05-27T13:00:00.004Z

Actualización (30/05/07): Si alguien instaló en su Ubuntu VirtualBox cuando escribí la entrada, es posible que unos días después, tras actualizar su distribución notara que VirtualBox dejaba de funcionar dando un error de que el driver no estaba presente. Se debía a que hubo una actualización del kernel a la versión 2.6.24-17, para la que los módulos de VirtualBox ya no valían (se podía arreglar simplemente arrancando con el kernel anterior). Pues bien, a quienes les haya pasado ésto les recomiendo que vuelvan a actualizar, pues a partir de hoy ya están disponibles los módulos de VirtualBox para el nuevo kernel, veréis que ya os funcionará sin problemas en su última versión.

En la anterior entrada ya vimos cómo instalar una máquina virtual VirtualBox sobre la que instalaremos ahora nuestro software de Radio Mobile, pero antes de ello vamos a depurar un poquito más nuestra máquina virtual para no tener que andar pulsando el "botón de anfitrión" cada vez que queremos usar el ratón sobre nuestro linux, y para permitir la compartición de carpetas entre el sistema host y el sistema anfitrión, que trabajar en la misma máquina y tener que andar con una memoria usb para pasar ficheros dentro de la misma máquina es un poco triste :).

Abrimos nuevamente nuestra máquina virtual (Aplicaciones -> Herramientas del Sistema -> VirtualBox OSE), la iniciamos (botón "Iniciar"). Cuando la máquina se haya iniciado, pinchamos en el menú "Dispositivos" y pulsamos sobre "Instalar aplicaciones del huésped". Os dirá que no se puede encontrar la imágen .iso de las aplicaciones del huésped, que si queréis descargarla, así que le decimos que la descargue, y luego cuando nos pregunte si queremos montarla, le decimos que sí. Ahora se nos abrirá la pantallita de instalación típica de windows:

Y cuando se nos haya instalado (necesita reiniciar), lo primero que notaréis es que ya no es necesario que pulsemos el CTRL DRCHO para sacar el ratón de la máquina virtual, sino que la ventana se comporta como una más de nuestro Linux y símplemente cuando pasamos el ratón por encima de ella, el ratón se pasa a comportar como si fuera el ratón del sistema Windows, permitiéndonos pulsar sobre sus menús y demás, ésto lo hace todo más cómodo. Además, también hemos instalado en el huésped la aplicación que nos permite la compartición de carpetas entre la máquina y nuestro sistema, pero para ésto aún tendremos que hacer un retoque chiquitín en nuestro sistema anfitrión, que explico a continuación.

Lo primero es crear la carpeta que vamos a usar para intercambiar ficheros entre los dos sistemas (ej: /home/tu_usuario/Intercambio). Una vez creada, la compartimos, que es tan fácil como irse con el Nautilus hasta la carpeta, darle al botón derecho sobre ella y decir "Opciones de Compartición". Os dirá, si es la primera vez que compartís archivos, que tiene que instalar la compartición de ficheros por samba, pero no os preocupéis, le dais a que lo instale y después de instalarlo será necesario que cerréis sesión y volváis a abrirla para que funcione. Una vez hecho esto volvéis a la carpeta a su "Opciones de Compartición" y pincháis en compartirla, quedando así:

Le decís "Crear compartición" y os dirá...

Pues bien, pulsad en "Añadir los permisos automáticamente", y listo, la carpeta se os debería mostrar en el nautilus de esta guisa...

...lo que os hará saber que está todo en orden.

Ahora ya para poder compartir ficheros desde uno al otro lado, nos vamos a la máquina virtual (Windows XP) y ahí pinchamos en "Inicio -> ejecutar". Escribimos "cmd" y pulsamos "enter". Lo que nos saldrá es un interprete de comandos de windows. Ahí escribiremos "net use Z: \\127.0.0.1\Intercambio". Nos dirá que se ha terminado la operación con éxito. Ahora ya podremos ver nuestra carpeta en windows como si se tratase de una unidad distinta (que hemos llamado Z:) mientras en GNU/Linux sigue siendo nuestra carpeta /home/tu_usuario/Intercambio. ¿A que mola?

Bien, una vez configurado todo esto, llegó la hora de instalar el Radio Mobile, nos vamos a la página de descarga, lo descargamos y seguimos los pasos que ahí nos pone, que son pocos y fáciles, y los cuento a continuación:
1. Descargamos el fichero que se enlaza en el paso 1 (step 1) y que viene a ser una librería. Después pinchamos, decimos un sitio donde queremos que se descombrima y luego vamos ahí y lo ejecutamos para que se instale en nuestro sistema.
2. Creamos la carpeta C:\Radio_Mobile
3. Descargamos el fichero que pone en "step 3" y lo descomprimimos dentro de la carpeta Radio_Mobile que creamos en el paso anterior.
4. Hacemos lo mismo con el fichero que se enlaza en "step 4".
5. Descargamos el fichero que se enlaza para el caso de lengua castellana (spanish language), y lo descomprimimos dentro, como en los pasos anteriores.
6. Creamos una carpeta que se llame por ejemplo "mapas" donde meteremos los mapas que nos descarguemos.
7. Descargamos y descomprimimos, como antes, el fichero que está enlazado en "File wmap.zip".
8. Ejecutamos el fichero "rmUpdatespa.exe" dentro de nuestra carpeta Radio_Mobile (veréis una pantallita como la que sigue).

Le damos a Siguiente, actualizamos y listo.

¡Bien! Ya tenemos instalado el software. De hecho, si queréis podéis probarlo ejecutando el fichero "rmwspa.exe", os saldrá algo como...

Pero aquí no acaba todo, porque ahora hay que descargarse los mapas SRTM (mapas topográficos). En realidad Radio Mobile admite varios tipos distintos de formatos de mapas, pero los SRTM son los que para la región de latinoamérica que queremos tratar ofrecen mayor precisión, y para nosotros que el mapa sea preciso será extremadamente vital, pensad que si uno diseña una red perfectamente, se va a la selva, instala equipos, antenas y torres y resulta que luego la señal no llega al otro extremo, el problema es bastante serio (obviamente en la realidad no son estas las únicas pruebas que se hacen antes de instalar los equipos), pero está claro que el software no nos sirve si no usamos mapas medianamente precisos.

Estos mapas SRTM se pueden conseguir de varios sitios, yo os contaré el proceso descargándolos del servidor ftp de la NASA, para lo que os recomiendo que os descarguéis e instaléis el filezilla en vuestra máquina virtual de windows (a nosotros nos interesará el "Filezilla Client" puesto que lo que queremos es un cliente FTP, no un servidor).

Ahora abrimos el Radio Mobile (para agilizar el proceso os recomiendo que creéis un acceso directo al fichero "rmwspa.exe" en el escritorio). Y buscamos las coordenadas aproximadas de nuestra zona de trabajo. Para ello pinchamos en "Archivo -> Propiedades del mapa", y ahí le damos a "Seleccionar un nombre de ciudad". Buscamos la ciudad de Iquitos, que es la ciudad más grande de la selva peruana y que está bastante cerca de nuestra zona de actuación. así, se colocarán automáticamente las coordenadas de esta ciudad (Latitud: -3,85 ; Longitud: -73,22). Así ya nos podemos hacer una idea de que si la región del Napo está ligeramente al noroeste de Iquitos, necesitaremos los mapas correspondientes latitudes más o menos de entre 0 y 5 grados sur y de longitudes entre 68 y 78 grados oeste (para todo esto google earth os puede ayudar bastante, yo he elegido un cuadrante amplio que más o menos encuadra todo lo que podríamos necesitar para nuestro diseño).

Y bien, ahora que ya tenemos eso claro abrimos el Filezilla que antes habíamos instalado. En el campo de servidor copiaremos...
ftp://e0srp01u.ecs.nasa.gov/srtm/version2/SRTM3/South_America
...y le damos a conexión rápida.
Como véis lo que vamos a hacer es buscar dentro de la sección que se ha abierto a la derecha los mapas que corresponden a las latitudes y longitudes que buscamos y copiarlos a nuestra carpeta de "mapas" que nos creamos antes. Para ello simplemente buscamos desde el fichero S01W068.hgt.zip al fichero S01W078.hgt.zip y los arrastramos a nuestra carpeta mapas que tendremos abierta en la sección de la izquierda, luego hacemos los propio con los que van de S02W068.hgt.zip a S02W078.hgt.zip, con los de S03W068.hgt.zip a S03W078.hgt.zip, con los de S04W068.hgt.zip a S04078.hgt.zip y finalmente con los que van de S05W068.hgt.zip a S05W078.hgt.zip y así habremos cubierto el cuadrante que necesitábamos.

Nota: Cuando lo que queramos sea descargar mapas de otra zona, podéis acceder al servidor entrando con el Filezilla en la dirección ftp://e0srp01u.ecs.nasa.gov/srtm/version2/SRTM3/ y buscando por la región que queráis acceder

Ahora en el Radio Mobile pinchamos en "Archivo -> Propiedades del mapa", volvemos a establecer Iquitos como centro del mapa, en Ancho y Alto pondremos 800 x 600, seleccionamos la ubicación de los mapas y establecemos que son de tipo SRTM, ponemos una altitud de 200 km para tener bastante plano y pinchamos en "Extraer".

El mapa resultante...

...está centrado en la ciudad de Iquitos y abarca hasta la unión del Napo con el Amazonas, así que vemos que realmente, si nuestra red está en el río napo, tendremos que subir nuestro mapa más hacia arriba, pero bueno, empezaremos centrando el mapa en uno de los puntos y ya iremos afinando. Claro que eso será ya en la siguiente entrega de esta saga de entradas, que pa una entrada ésto ya se está convirtiendo en demasiao largo :).

De toas formas, las coordenadas de nuestros puntos, por si alguno/a quiere ir probando a averiguar como funciona la cosa, son:

Cabo Pantoja: 0º58'13,26''S 75º10'29,21''O
Torres Causana: 1º6'16,53''S 75º0'14,17''O
Tempestad: 1º17'22,81''S 74º52'27,42''O
Tupac Amaru: 1º21'46,55''S 74º44'42,89''O
Angoteros: 1º34'9,54''S 74º36'20,17''O
Campo Serio: 1º47'35,48''S 74º42'50,09''O
Rumi Tuni: 2º3'16,22''S 74º26'9,30''O
San Rafael: 2º22'1,43''S 74º6'42,91''O
Copal Urco: 2º20'23,41''S 73º47'26,23''O
Santa Clotilde: 2º29'22,07''S 73º40'41,02''O
Tacsha Curaray: 2º48'47,46''S 73º32'27,30''O

Saludetes chavalinos y chavalinas y hasta dentro de poquito.

Diseño de redes inalámbricas con Radio Mobile (I)

2008-05-23T00:00:00.000Z

¡Buenas de nuevo!

Como lo prometido es deuda, y después de las entradas "facilonas" en las que sólo colgaba 2 libros para su descarga (que son muy buenos, de veras); ahora me voy a mojar un poquillo más y en esta entrada me he propuesto diseñar una red con Radio Mobile. Para demostrar su aplicación, vamos a hacer como ejemplo una red ya existente que se diseñó con este software, y que viene a ser la red que la Fundación EHAS instaló en marzo del año pasado a lo largo del río Napo, en los distritos de Napo y Torres Causana, provincia de Maynas, región de Loreto, en el Perú amazónico. Se trata de una red orientada a salud que se pretende (y de hecho lo está haciendo desde ya hace un año) que de los servicios de telefonía, correo electrónico, internet y diversos de telemedicina (en esto último la red aún no está lo suficientemente explotada y se está trabajando en buscar soluciones de telemedicina útiles y aplicables en estos entornos) para los centros de salud de una región aislada del planeta. Los beneficiarios directos del proyecto serán por tanto los centros de salud, que si tuviéramos delante el árbol de soluciones de El Marco Lógico de nuestro proyecto, nos daríamos cuenta de que repercuten directamente en la mejora de las condiciones de la población local.

Para situarnos un poco más, os pongo el mapa de direccionamiento de la red del que nosotros nos encargaríamos de diseñar todos los enlaces inalámbricos.

Llegado este punto, alguno pensará "...y si se trata de enlaces inalámbricos WiFi, ¿para qué #$%/& hay que usar un software de diseño? yo en mi casa pongo mi router a funcionar y a ¡ale! ¡a correr!". Pues bien, eso está genial para enlaces cortos típicos de redes locales WiFi, que no superan los 300m en el mejor de los casos, pero los enlaces que vemos en el mapa que arriba pongo, llegan a tener hasta 42km entre nodos, en una región tropical selvática con la atenuación de señal que humedad, selva y demás asuntos introducen en nuestros balances de enlace, y todo ello sin dejar de ser WiFi (aunque como ya veremos en futuras entradas, para el correcto funcionamiento de estos enlaces hace falta hacer algunos truquillos con el driver Madwifi para tarjetas con chipsets atheros sobre linux que rompen ligeramente el estándar WiFi sin abandonar la interoperabilidad con cualquier otro dispositivo que cumpla el estándar 802.11).

Por otras entradas del blog, muchos/as ya sabréis que soy un linuxero empedernido, así que usar software diseñado para windows habitualmente me produce urticaria, pero dado el buen uso que puede tener este software y para que me duela menos, explicaré el proceso sobre una "Ubuntu 8.04", la última versión disponible, instalando una máquina virtual "VirtualBox" sobre la que se instalará a su vez un Windows XP. Si me da el venazo, igual os explico también cómo hacerlo directamente sobre Linux usando el emulador "Wine".

Lo primero que vamos a hacer es descargarnos la máquina virtual "VirtualBox" y para ello nos vamos a su página web y nos descargamos el software (decir que Sun Microsystems anunció en febrero de este año la adquisición de la empresa responsable de VirtualBox, que es Innotek GmbH, por lo que el software ha pasado de llamarse "Innotek VirtualBox" a ser ahora "Sun xVM VirtualBox 1.6", ya sabéis, chorradas empresariales de nomenclatura. Los que tengáis la antigua máquina virtual, os vale lo mismo, pero probablemente la página sea alojada dentro de poco en los servidores de Sun). Para la descarga seleccionamos nuestra plataforma (Ubuntu 8.04 x86), marcamos el tradicional cuadro de aceptar licencia "I agree" (cualquier día me da el venazo y me leo una de estas licencias pa saber lo que estoy aceptando :) ) y pinchamos en el botón "Continue". La cosa no podía ser más sencillica. Nos sale un paquete .deb para descargar. Lo descargamos corriendo antes de que nadie nos lo quite :D. Para instalarlo, nos bastará un "sudo dpkg -i nombre_paquete.deb" en un terminal.

Pero para quien eso de abrir una consola le de urticaria, siempre está la opción de nuestro amigo el synaptics (gestor de paquetes). Se abre, se busca por virtualbox, se marca el paquete para su instalación y luego se pulsa en "Aplicar". No tiene pérdida.

Después de la instalación de VirtualBox, ya lo tenemos en Aplicaciones -> Herramientas del sistema -> VirtualBox OSE. Pues bien, pulsamos en él para abrirlo. Como se podía intuir, nuestra intención será crear una nueva máquina virtual, así que pinchamos en el botón de "Nueva" y comenzamos a configurarla.

Lo primero es un típico "Siguiente". Luego damos un nombre a nuestra máquina y seleccionamos el tipo de sistema operativo que instalaremos en ella (en nuestro caso un Windows XP...¡uy! ¡qué dolor ver esas letras juntas!). Como parece que le he pillado el gustillo a esto del botón "impr pant" del teclado.

Pulsamos en "Siguiente" y nos preguntará la memoria base que queremos destinar a la máquina virtual. La mínima son 192MB, pero para darle más soltura a la cosa, yo le he puesto 512MB, dependerá de cuánta tengáis. Si le ponéis muy poca irá más lento, pero por contra no os comerá terreno a vuestro preciado GNU/Linux. Pulsamos en "Siguiente", y ahora nos toca crear un disco duro para nuestra máquina virtual. Bueno, aquí tenemos la opción de que el disco duro tenga un tamaño estático o un tamaño dinámico (que crecerá cuando se vaya agotando). Ésto se traducirá en un fichero .vdi, que luego podremos borrar o copiar a nuestro antojo para trasladar nuestra máquina virtual a otro sitio. Yo he decidido usarlo de 10GB iniciales y dinámico...
Ya sabéis..."Siguiente" y "Finalizar" cuando os lo pida.

De vuelta al proceso de creación de la máquina, ahora seleccionamos el disco duro que acabamos de crear como primario de nuestra nueva máquina y pinchamos en "Terminar". Y ahí está, ya tenemos a nuestra pequeña creada, a la espera de ser configurada y luego instalada.

Hagamos antes de la instalación algunos retoques de configuración, son poquitos. Con la máquina seleccionada, pinchamos en el botón de "Configuración". Primero, si disponemos de suficiente memoria de vídeo, le daremos un poco más de holgura a la máquina, para que nuestro Radio Mobile se mueva agusto.

Ahora es buen momento para introducir en vuestra lectora de CD o DVD el disco de instalación de un Windows XP (no seré yo quien os diga si el disco ha de ser original o pirata :) ). Nos vamos a la sección de "CD/DVD-ROM" y marcamos la casilla de "Monta la unidad de CD/DVD".

Lo siguiente será activar el audio. Nos vamos a la sección "Audio" y marcamos "Habilitar Audio". Finalmente pincharemos en "Ok" y ya está, ya estamos listos para instalar un sistema operativo peor que el anfitrión, pero que nos dará la posibilidad de diseñar nuestra red inalámbrica mediante el software de Radio Mobile. Para arrancar la máquina, ahora ya sí, pinchamos en el botón "Iniciar" con nuestra máquina seleccionada.

Al darle a "Iniciar", nos sale un cuadrito que nos familiariza con el funcionamiento de VirtualBox. Se nos recuerda que cuando pulsemos sobre la ventana de la máquina virtual (mientras no esté instalado algo que haremos más tarde), la máquina huésped (Windows) se hará con el control de nuestro teclado hasta que pulsemos la "Tecla anfitrión", que viene a ser por defecto el CTRL DRCHO. Cuando pulsemos esa tecla, nuestro teclado y ratón actuarán sobre nuestro sistema anfitrión (GNU/Linux Ubuntu).

...y hecho ésto...

¡¡ALARM, ALARM!!

La maquinilla nos chilla que nanai, pero afortunadamente el mensaje de error contiene la solución del problema así que no tendréis mucho problema en solucionarlo. Sólo tenemos que instalar el paquete que nos pide. Lo hacemos con "sudo aptitude install virtualbox-ose-modules-2.6.24-16-generic" en un terminal. Lo siguiente será introducir a nuestro usuario dentro del grupo "vboxusers", y para ello nos vamos a "Sistema -> Administración -> Usuarios y Grupos". Ahí pinchamos en "Gestionar Grupos", luego seleccionamos el grupo vboxusers y marcamos nuestro usuario para que se agregue al grupo. Cerramos y ya lo tenemos, pero para que el usuario sea efectivamente agregado, tendremos que reiniciar. Para quien prefiera hacer las cosas desde un terminal, se puede agregar un usuario al grupo vboxusers sólo escribiendo "sudo adduser vboxusers" (mucho más rápido, ¿eh?).

Luego pulsamos en "Iniciar" y como tenemos introducido el cd de instalación de Windows, el resto podemos decir que ya es historia, la vieja historia de la instalación de un Windows y que resumiré en capturas:

Y ... ¡voilà! Ya tenemos el windows sobre el que instalaremos nuestro Radio Mobile, pero la instalación del software os la contaré en la siguiente entrada. Ni que decir tiene que lo que tenemos ya instalado es un windows plenamente funcional, así que se le puede instalar cualquier cosa que se pudiera instalar sobre un sistema no virtualizado (aunque parece ser que algunas cosas como la aceleración gráfica aún no está muy conseguida).

¡Hasta la próxima entrada!

Libro "Redes Inalámbricas en los Países en Desarrollo"

2008-05-17T08:37:00.005Z

Buenas a todos de nuevo, aquí os dejo otro libro más sobre redes inalámbricas, éste un poco más antiguo, surge del proyecto WNDW (Wireless Networking in the Developing World) y os puede ayudar a informaros más a fondo sobre estos temas. Espero que os sea de utilidad. Lo podéis descargar igual que el anterior porque también está licenciado bajo Creative Commons. Si preferís descargaros la segunda edición en inglés, también la tenéis aquí disponible.

Libro "Redes Inalámbricas para Zonas Rurales"

2008-05-12T16:50:00.004Z

El Grupo de Telecomunicaciones Rurales de la PUCP (Universidad que es contraparte local de los proyectos que la Fundación EHAS desarrolla en Perú, como el que os relataba en el blog "Cooperante no hay camino..."), ha publicado un libro que trata en profundidad el despliegue de redes inalámbricas para zonas rurales de países en desarrollo. Podéis descargar el libro si lo deseáis ya que está licenciado bajo Creative Commons. Os lo recomiendo, hay mucho conocimiento ahí condensado.

Motor de informes dinámicos con iTextSharp (I)

2008-03-28T16:11:00.019Z

Actualización: he colgado los códigos del proyecto para que podáis jugar con ellos y utilizarlos en vuestros proyectos. Los podéis descargar desde aquí

Buenas de nuevo a todo el mundo que lee este blog (cada día sois más, lo que es de agradecer). He estado muy ocupado últimamente montando mi propio motor de informes dinámicos utilizando la librería iTextSharp para generación de documentos PDF.

La idea inicial era poder disponer (dentro de una aplicación ASP.NET) de un sistema de impresión de informes con tres características principales:

Impresión de informes al vuelo en PDF
Disponer de plantillas en XML para mezclar datos de base de datos y mostrarlos en PDF (también al vuelo).
Poder modificar las plantillas XML desde un editor

Con estos requisitos me puse manos a la obra con iText# (una librería excelente) y os explico cómo lo plantee por si os sirve para vuestros desarrollos o como punto de partida para otras cosas.

Impresión de Informes al vuelo en PDF
Ésta fue la parte más fácil y más complicada a la vez. La más complicada porque me pegué de lleno con la librería y la más fácil cuando aprendí los entresijos de la misma. Para imprimir informes en PDF al vuelo basta con seguir el siguiente ciclo:

La idea consiste en generar los datos a imprimir en la pagina aspx donde esté el usuario. Esos datos los guardamos en la sesión y llamamos a la pantalla MostrarInforme.aspx. Esta pantalla recupera los datos de la sesión y se los pasa a la clase GeneradorPDF.cs que se encarga de crear el PDF (en memoria) en base a los datos pasados. El método que genera el PDF devuelve un objeto del tipo MemoryStream a la página MostrarInforme.aspx, el cual es renderizado en pantalla mediante un Response.OutputStream.Write().

Dicho así, la verdad es que no aclaro demasiado el tema, así que vamos a ver el código que siempre ayuda más.

El Código
Lo primero fue plantearme el alcance de esta parte del motor de informes. Lo que queríamos era poder imprimir cualquier tabla de cualquier pantalla con cualquier tipo de campos y número de una forma común y fácil. Con este objetivo en mente, lo inicial fue definir las variables de sesión en las que se iban a pasar los datos desde las páginas a la pantalla MostrarInforme.aspx:

DataTable con los datos
DataTable con los nombres de las columnas de la tabla que se quieren imprimir y el nombre que se le pone a cada una de ellas en el informe.
Orientación de la página para poder imprimir en apaisado y en vertical
Anchos (en porcentaje) de las columnas que se van a imprimir
Nombre del listado que aparecerá en la cabecera

1. Preparar la Impresión
Con estas variables de sesión tenemos información suficiente para poder imprimir el informe. Un ejemplo de cómo se preparan las variables de sesión en una pantalla es el siguiente:

En este método lo que hago es crear las variables de sesión necesarias (casi todo está con enumerados y struct).

TABLA_DATOS: Para el Datatable con todos los datos.
ORIENTACION_PAGINA: para decirle si queremos imprimir en vertical o en horizontal.
CAMPOS_A_IMPRIMIR: para indicar aquellas columnas del datatable de datos que queremos imprimir y el nombre que queremos que aparezca en la cabecera de dicha columna en el informe. Aquí utilizo un datatable tipado DtCamposListadoPDF.
ANCHOS_DE_COLUMNA: array de enteros con los anchos de cada una de las columnas (en el mismo orden) que he introducido en CAMPOS_A_IMPRIMIR.
TITULO_LISTADO: Título que va a llevar el informe.

2. Llamar a MostrarInforme.aspx
Una vez que tenemos las variables de sesión, llamaremos a la pantalla MostrarInforme.aspx desde nuestra aplicación. Para abrirla hay varias opciones (Javascript, inyectando código). A mi lo que me interesaba era que se mostrará el PDF en una nueva ventana, así que llamo a la página desde Javascript, con un window.open.

También se puede hacer con:

El código de MostrarInforme.aspx es el siguiente:

Todo se realiza en el Page_Load() porque vamos a devolver un Stream al navegador. Lo primero que hacemos es recuperar las variables de sesion que la página ha creado. Obtengo también la ruta de una imagen que va a aparecer en plan logo en los informes para pasarla al método.
Una vez obtenidos los datos llamo al método estático GenerarListado que va a devolver un MemoryStream con el PDF.

Con el MemoryStream lo que hago es renderizarlo en la pantalla mediante el objeto Response. Vamos a ver cómo genero el PDF al vuelo.

3. Generar el PDF
El método GenerarListado de la clase GeneradorPDF es el que realmente se encarga de crear dinámicamente el informe PDF.

Los using que tenemos que utilizar son:

En la primera parte del método definimos el objeto Document que va a contener el PDF, la orientación y enlazamos el objeto MemoryStream con el objeto Document para indicarle que vamos a realizar las operaciones en memoria.

En segundo lugar llamamos al método IncluirElementosComunes para crear la cabecera del informe, el título y para que incluya el logo:

El código de este método es el siguiente:

En este método creamos la cabecera del informe, una tabla con el logo en una celda y con el título del listado y la fecha de impresión en la otra. Además, en este método abrimos la escritura en el documento con la instrucción docPdf.Open().

Volviendo al método general, las siguientes instrucciones lo que van a hacer es ir creando una tabla, con tantas columnas como le hemos pasado en sesión y la vamos rellenando con los datos del Datatable de datos.

Vamos iterando sobre los datatables e incluyendo la información. En esta parte, cada uno dará al informe el aspecto que más le guste. Al final incluimos la tabla en el documento PDF.

Para finalizar lo que tenemos que hacer es capturar los errores, cerrar el PDF y devolver el stream.

Una muestra de un informe en PDF generado por esta función es el siguiente:

Final
En la próxima entrega veremos como realizar las plantillas XML con parámetros y cómo mezclarlas con datos de bases de datos de una forma dinámica. Finalmente, en la tercera entrega veremos como editar las plantillas y cómo crearnos traductores XML y HTML para dichas plantillas.

Espero que os haya interesado este primer artículo y que lo aprovechéis para vuestros desarrollos.

Firmar una llamada SOAP con C# y ASP.NET

2008-03-04T19:40:00.018Z

En este artículo voy a intentar explicar cómo firmar una llamada SOAP utilizando la extensión para servicios web WS 3.0 de Microsoft. Como siempre, lo primero es un poco de teoría y luego veremos cómo pasar esta teoría a la práctica.

Es recomendable que os leáis el artículo anterior a este sobre certificados digitales de la FNMT puesto que haremos uso de lo que en él comentaba.

1. Teoría
La idea es poder realizar una llamada a un servicio web externo (una administración, por ejemplo) asegurando que el contenido de la misma no ha sido manipulado en el camino. El ejemplo más claro es el de una aplicación web que se integra con la administración, por lo que tiene que firmar las peticiones con el certificado de la FNMT del cliente que en ese momento este usando la aplicación.

La idea es que nosotros seamos una especie de pasarela de certificados de nuestros clientes a los servicios web de la administración o de otro sitio. Para realizar esto tendremos que firmar las llamadas SOAP con el certificado usando el estándar XMLSignature.

2. ¿Cómo lo hacemos?
Para hacerlo, lo primero que tenemos que hacer es descargarnos las extensiones de Servicios Web de Microsoft (WSE 3.0) que podéis encontrar en la dirección:

http://www.microsoft.com/downloads/details.aspx?FamilyID=018a09fd-3a74-43c5-8ec1-8d789091255d&displaylang=en

Una vez instalado en nuestro equipo, tendremos una nueva opción en Visual Studio para el trabajo con las extensiones de Web Services.

¿Cómo funciona WSE 3.0?
El centro del tema este son las políticas y los filtros. Cuando realizamos una llamada a un servicio web, ésta es interceptada por una clase que define lo que hay que realizar con dicha llamada antes de que salga. Cuando recibimos una respuesta, la respuesta es interceptada igualmente, y lo mismo pasa cuando definimos los servicios web.

Donde nosotros vamos a trabajar es en la clase de políticas de seguridad, que será donde se firme la petición.

Paso 1: Habilitar nuestro web para WSE3.0
Lo primero es habilitar nuestro sitio web para que utilice WSE3.0. Al habilitarlo, las clases proxy que se creen estarán preparadas para las extensiones de WSE. Tendremos que crearnos un sitio web en el Visual Studio y en las propiedades del sitio web veremos cómo aparece una nueva opción "WSE Settings 3.0". Al pinchar se abre la ventana:

Marcamos la primera opción para habilitar las opciones del cliente. La segunda opción es para habilitar las opciones cuando nosotros somos el servicio web.

Paso 2: Agregar la referencia a WSE
Agregar una referencia a la librería Microsoft.Web.Services3 a nuestro proyecto.

Paso 3: Agregar la referencia web
Agregaremos la referencia web al servicio con el que nos queramos comunicar.

Paso 4: Crear la política de seguridad
Vamos a crear la clase que controla la entrada y salida de mensajes SOAP desde el cliente. Esta clase tiene que heredar de SecurityPolicyAssertion

La clase tiene cuatro métodos, uno para cada situación: salida/entrada para el cliente y salida/entrada para el servicio. A nosotros el que nos interesa es el de la salida para el cliente, el resto lo ponemos a null.

La sección de imports es la siguiente:

En el constructor le pasamos el certificado del cliente (luego veremos cómo llamamos a esta clase) para poder utilizarlo en el método de salida del cliente. En este método lo que hacemos es instanciar una nueva clase que hereda de SendSecurityFilter que es la que realmente firma la petición:

En esta clase lo que hacemos es obtener el token del certificado y añadirle la firma al mensaje SOAP, haciendo override del método SecureMessage. Con esto tenemos prácticamente hecho todo.

Paso 5: Realizar la llamada
Nos creamos una página aspx desde la que vamos a realizar la llamada. Lo primero será obtener el certificado del cliente (ver el artículo anterior), una vez obtenido tendremos que asociar la política que hemos definido con la llamada al servicio web:

En este caso, he creado un servicio web con un método llamado "CalculaSuma" el cual suma dos números que se le pasan. En un botón llamado "btnInvocar" de la página le asocio el código para llamar al servicio web. Lo que hacemos es instanciar la clase proxy que se creó al agregar la referencia web y le asociamos la política que hemos creado.

Al realizar la llamada, la política intercepta el mensaje de salida, ejecuta el método "SecureMessage()" y firma la petición. Podemos activar el modo Trace con el asistente de WSE y ver la salida para comprobar que se ha firmado la petición, incluyéndose un nuevo elemento en la llamada SOAP llamado .

3. Fin
Espero que os haya gustado y servido este post. No ha sido muy exhaustivo pero como punto de partida para la utilización de XMLSignature en SOAP puede ser bueno.

Documental EHAS

2008-01-27T17:50:00.000Z

Buenas de nuevo a todos/as

De nuevo estoy aquí ya de vuelta de la selva pa daros el coñazo con nuevas entradas. Por el momento estoy en un momento muy liado hasta finales de febrero, pero quería dejar constancia de que a partir de ahora retomaré el hábito de escribir alguna entrada cada cierto tiempo. Y para que no sea una entrada vacía, aquí os dejo un documental sobre la Fundación EHAS (Enlace Hispano-Americano de Salud) que lleva ya 10 años trabajando en proyectos de cooperación para el desarrollo en Perú, Colombia y Cuba, aplicando para ello su investigación en Tecnologías de la Información y la Comunicación adaptadas a estos entornos. Ellos son los culpables de que haya dejado de escribir este tiempo :). Espero que os guste.

Saludos de nuevo.

Usar certificados de cliente de la FNMT en una Aplicación Web

2008-01-16T19:49:00.000Z

Mucho tiempo ha pasado desde la última entrada, pero entre que hemos estado muy ocupados y la pereza que da ponerse de nuevo a escribir, pues, han pasado tres meses (o más). Sin embargo, un nuevo reto se me planteó y tras sudar sangre para resolverlo lo comparto con vosotros. El tema de este post es: ¿Cómo usar certificados de la FNMT (Fábrica Nacional de Moneda y Timbre) en nuestra web?

Existe poquísima información al respecto en Internet, muchos posts de gente, mucha historieta pero nada concreto. Voy a intentar, por lo tanto, dar las instrucciones para configurar un servidor de internet (en mi caso IIS, aunque la configuración es similar para el resto) para poder pedir al usuario que utilice un certificado emitido por la FNMT.

Paso I: La Seguridad
Si no tenemos una conexión https con SSL, GAME OVER, fin de la partida. Es requisito indispensable comunicarnos con el cliente mediante una conexión cifrada para poder interactuar con los certificados. Pero, ¿cómo lo hacemos para conseguir un certificado?. En desarrollo podemos seguir los siguientes pasos (en producción necesitareis un certificado emitido por una CA Root reconocida):

Existen muchos sitios en internet donde se describe este proceso, os pongo esta url donde explican como generar nuestro propio certificado con OpenSSL:
http://www.locualo.net/programacion/activar-ssl-iis-certificado-digital-prueba/00000079.aspx

Paso II: La Teoría
Vamos a ver un poco de la teoría para saber cómo funciona el tema de los certificados. Una vez que sepamos como funciona, entenderemos los pasos a dar. El circuito de los certificados es el siguiente:

1. El cliente accede a la url https://.... (para la cual es necesario un certificado de cliente)
2. El servidor envía su certificado al cliente para establecer el canal seguro. El cliente debe confiar en la entidad que ha generado ese certificado y comprobar que es válido. En caso de no confiar aparecerá un mensaje en el explorador indicándonoslo (la mayoría de la gente no lo lee).
3. Una vez que el cliente ha confiado en el servidor, se establece el canal seguro.
4. El servidor tiene configurado que para el recurso que intenta ver el cliente es necesario que presente un certificado de cliente, emitido por una entidad certificadora en la que él confíe y además que está en la lista de los certificados admitidos para el recurso en cuestión.
5. El explorador del cliente recibe estas condiciones del servidor y muestra una ventana con los certificados instalados que cumplan los requisitos del servidor.
6. El usuario elige su certificado y éste es mandado al servidor.
7. El servidor comprueba la lista de revocación de certificados de la entidad que emitió el certificado para ver si sigue siendo válido.
8. En caso que el certificado sea válido, podremos acceder al recurso y en la sesión tendremos guardado el certificado para usarlo.

En la siguiente imagen os muestro el flujo:

Paso III: La Confianza
Como habéis podido observar, la clave del asunto es la confianza entre los diferentes elementos (cliente y servidor). Vamos a ver cómo configurar nuestro servidor para: 1) requerir el certificado del cliente y 2)confiar en la fnmt para que acepte sus certificados.

Para requerir el certificado del cliente iremos al "Administrador de Servicios de IIS", buscaremos el recurso, sitio web o directorio virtual que necesitará certificado y pulsamos en "Propiedades" del menú contextual. En la pestaña "Seguridad de Directorios" pulsamos sobre el botón "Modificar" de la parte inferior. Nos aparecerá la siguiente pantalla:

Marcaremos la opción "Requerir Canal Seguro" y "Requerir Certificados de Cliente". Pulsamos sobre Aceptar y hemos terminado. Ahora el IIS espera un certificado del cliente para acceder al recurso, sin embargo, todavía no le hemos dicho que debe confiar en la FNMT como entidad certificadora.

Para confiar en la FNMT, tendremos que abrir una consola mmc (Ejecutar--> mmc), Archivo-->Agregar o Quitar Complemento. En la pantalla que aparece pulsaremos de nuevo sobre Agregar y seleccionaremos el complemento "Certificados":

Pulsamos sobre "Agregar", seleccionamos la opción "Mi Cuenta de usuario" y cerramos la pantalla de agregar complementos. En la consola mmc, expandimos "Entidades emisoras raíz de confianza-->Certificados" y buscamos a la FNMT:

En caso que no esté, tendremos que importarlo. Lo primero será conseguir la definición del certificado de la FNMT. La podéis conseguir desde aquí:

http://www.cert.fnmt.es/content/pages_std/certificados/FNMTClase2CA.cer

Guardamos el fichero .cer en nuestro servidor y en la consola mmc pulsamos con el botón derecho sobre "Certificados" y elegimos "Todas las tareas-->Importar". Saltará un asistente para importar un certificado, seleccionaremos el fichero que nos acabamos de descargar y siguiente hasta el final.

Una vez importado, veremos las propiedades del certificado y habilitaremos la opción "Autenticación del Cliente". De esta forma habilitamos a los certificados de la FNMT para que sirvan como certificados de cliente.

Con esto hemos dado nuestra confianza a la FNMT como CA Root, sin embargo, todavía no funciona porque tenemos que incluir a la FNMT como entidad válida para nuestro recurso, en la CTL (Certificate Trusted List). Para ello, volvemos a la consola del IIS y nos vamos a las propiedades del sitio web en el que esté el recurso del certificado. Seleccionamos la pestaña "Seguridad de Directorios" y pulsamos sobre el botón "Modificar" de la parte inferior. Aparecerá la pantalla siguiente:

En la parte inferior tenemos la lista de certificados de confianza, pulsamos sobre "Modificar" y en la lista que aparece, pulsamos sobre "Agregar desde el almacén" e incluimos el de la FNMT. Pulsamos "Siguiente" hasta el final y ya tenemos todo hecho.

Paso IV: Final
Ya tenemos nuestro entorno habilitado para utilizar certificados de cliente. En producción tendremos que tener un certificado emitido por una entidad reconocida, pero el resto es igual.

Espero que os haya aclarado las ideas y os haya servido.

Cooperante no hay camino...

2007-09-06T22:13:00.000Z

¡Buenas chavalucos!

Esta entrada es solo pa informar de que me viajo este mes de Octubre a realizar un proyecto de cooperación para el desarrollo en la región de Loreto, Perú, provincia del Alto Amazonas .Mi misión allí será junto con otros/as ingenieros/as realizar el mantenimiento y puesta a punto de una red telemática que intercomunica los centros de salud de los pueblos de la selva amazónica de aquella región, a orillas del río Napo, uno de los principales afluentes del Amazonas.

Con motivo de este proyecto y de otros tantos que se realizarán financiados con fondos de la Oficina de Cooperación para el Desarrollo de Universidad Carlos III de Madrid, hemos abierto un blog donde trataremos de informar del estado de cada proyecto así como de las vivencias que se nos vayan ofreciendo en el camino. El blog se llama "Cooperante no hay camino..." y espero que a más de uno le sirva para animarse a poner al servicio del desarrollo humano sus conocimientos técnicos.

Durante ese periodo no podré poner entradas en este blog, pero prometo volver con ánimos para seguir colaborando con este blog tanto como me sea posible, aunque con Manolo ya tenéis información interesante para dar y regalar.

Por el momento, me despido temporalmente de vosotros y espero que os parezca interesante la información que podáis leer sobre los proyectos de cooperación al desarrollo. ¡¡Hasta pronto!!

YA SAN CASAOOOO, YA SAN CASAAAOOOO...

2007-08-15T12:30:00.000Z

Pos eso, que Marivi y Manolo, socios de N-Idea Soluciones y colaboradores de este blog ya han hecho su roce oficial y se casaron el sábado pasao. Dentro de poco editaré esta entrada con alguna foto ilustrativa de la efeméride.

La fiesta insuperable, la novia guapísima y el novio mu elegante, la comida insuperable (por lo menos la mía), y hasta las mil y pico de la madrugá bebiendo, cantando, bailando y gritando "¡¡Vivan los novios!!" y demás alaridos propios del casamiento. Especialmente gracioso era el gesto de Manolo cada vez que gritaban "¡Viva el novio!" que se rodeaba y hacía el gesto de la "v" con los dedos a tol mundo.

Pos eso, que pa bodas la de Marivi y Manolo. De lo único que nos quedamos con ganas es de haber escuchao cantar más a la madre de Marivi, que ya tendrá ocasión de deleitarnos más si cabe en alguna otra ocasión.

Por mi parte, me levanté al día siguiente con un pestazo a bizcocho de chocolate que algún desalmao me restregó por la cara y que esperaré a la siguiente boda familiar pa devolvérsela ;).

Y ná más, ¡¡¡¡VIVAN LOS NOVIOS!!!! ...y a ver si montáis más fiestones como ese que estaremos esperándolos con muchas ganas.

Frameworks para RIAs

2007-07-12T17:11:00.001Z

En esta cuarta entrega del desarrollo basado en Ajax, nos vamos a centrar en los diferentes frameworks existentes que nos pueden ayudar en nuestros desarrollos. Si no os habéis leído los posts anteriores, os recomiendo que os los leáis para entender mejor este:

¿Qué es eso del AJAX?: Introducción a ajax, a su funcionamiento y al objeto XMLHttpRequest.
AJAX para CAMPEONES o ¿Qué es eso del AJAX? (Segunda Parte): en este segundo post, nos adentramos un poco más en la implementación práctica a través de ejemplos de las llamadas asíncronas.
AJAX PARA SUPERCA MPEONES o ¿Sabremos alguna vez qué es AJAX? (III): en la tercera entrega vimos cómo hacer múltiples llamadas de forma simultánea y cómo enlazar múltiples llamadas secuenciales.

En este post vamos a ver diferentes alternativas de las que disponemos para agilizar nuestra tarea (otra gente se ha pegado con el teclado por nosotros). Vamos a ver, aunque existen muchísimos más, los siguientes:

YUI: Yahoo User Interface, framework de Yahoo (que listo soy) para aplicaciones ricas de internet (RIA: Rich Internet Application). Muy completo y con un montón de ejemplos y documentación.
Dojo: Framework de la Dojo Foundation. Es también muy completo, quizás un poco más sencillo de utilizar que el de Yahoo y menos pesado para el explorador, aunque con menos documentación.
GWT: Google Web Toolkit. Es la implementación que da Google para Ajax sobre Java. En realidad, la filosofía de GWT es la de programar en Java y él interpreta el código Java para generar las páginas con los controles AJAX.
AJAX ASP.NET: La implementación para asp.net de AJAX. Incluye, aparte del core de librerías de comunicación una librería de controles llamada Atlas Control Toolkit. Se puede utilizar aunque no se utilice asp.net.

Todas estas librerías son de libre distribución. Por supuesto, existen muchas librerías de pago con controles flipantes que casi te programan la aplicación solas, pero los currelas de a pié, nos conformaremos con éstas (de hecho son muy buenas todas). Personalmente, la que más uso (todos los días) es la de ASP.NET, que hace cosas muy chulas. Tened en cuenta que en lo que más dan estos frameworks son controles para hacer nuestras aplicaciones más interactivas. Pero, vamos al tajo:

Yahoo User Interface:
Esta fue la primera librería que utilicé en mis pruebas. Tiene varias cosas muy buenas a tener en cuenta:

Una documentación muy buena con unas cheatsheets muy curradas.
Un mogollón de ejemplos con el código bien puesto.
Muchos controles
El respaldo de una gran empresa que soporta el proyecto (no te van a dejar tirado).

Cosas negativas que he visto y comprobado:

Puede llegar a ser bastante pesado para el cliente (las librerías javascript)
Es el framework más complejo con el que trabajar debido a que puedes hacer lo que quieras con él.

Este conjunto de librerías las puedes utilizar donde quieras porque son Javascript puro. De hecho, puedes mezclar diferentes librerías. ¿Os acordáis del ejemplo que puse en una de las entregas en el que se ponía el nombre y el servidor devolvía "Te devuelvo tu nombre: " y el nombre? Os acordéis o no, aquí tenéis ese mismo ejemplo pero implementado con YUI:

http://www.nidea-soluciones.com/PruebasAjax/YUI/yui1.html

El código javascript utilizado se divide en dos partes: primero tenemos que importar los scripts de YUI que vayamos a utilizar (lo miramos en su web para saberlo) y después realizamos nuestros propios scritps:

Los scripts a importar dependerán de qué es lo que vamos a utilizar de la librería de controles de Yahoo. En la página web se indica para cada caso cuáles son necesarios. La parte de programación es la siguiente:

El meollo se encuentra en la línea YAHOO.util.Connect.AsyncRequest() que es la que crea el objeto XMLHttpRequest y realiza la llamada. Se le pasa el método, la url y una variable que contiene toda la información relativa a la función si va todo bien, la función si no va bien, los argumentos, etc. Es muy importante el orden, no podemos definir la variable callback antes de las funciones que manejarán las respuestas, ni podemos definir la variable callback después de la llamada al servidor.

Utilizamos también uno de los controles de YUI, el container en su versión panel. La programación con YUI se puede realizar de dos maneras distintas, por marcación o por Javascript. Todos los controles se pueden definir directamente en Javascript (caso del ejemplo) o definir en HTML (Markup). Al definir por HTML, cuando se llama al método render, la librería busca determinadas clases css y las convierte en controles. El mismo panel que se define en el ejemplo con HTML sería:

La librería lee las clases y las renderiza en pantalla en forma de panel.

Framework Dojo:
Este es el siguiente framework con el que trabajé. Tiene otras ventajas e inconvenientes que el YUI. Los que encontré fueron los siguientes:

Cosas buenas:

Un montón de controles
Definición en la programación más intuitiva que la de YUI.
Menos importaciones a nuestras páginas

Cosas malas:

La documentación es mucho peor.
Existen menos ejemplos en la utilización de los diferentes controles.

Veamos un ejemplo. Os he puesto el mismo ejemplo que con YUI pero programado con Dojo. Lo podéis ver en:

http://www.nidea-soluciones.com/PruebasAjax/Dojo/dojo1.html

El estilo de programación varía ligeramente entre ambos frameworks. En ambos disponemos de una parte de inicialización de dependencias que en el caso de YUI es mediante la incorporación de scripts y mediante Dojo se realiza más al estilo Java o C#:

Lo primero es importar la librería base dojo.js y después utilizamos la sentencia para importar aquellas partes que vayamos a utilizar. Podemos utilizar una sintaxis del tipo dojo.require() dojo.require("dojo.widget.*"); para importar todos los widgets. En este caso, como sólo vamos a utilizar el tipo Dialog pues lo importamos. La sentencia djConfig = {isDebug:true}; nos permite sacar mensajes de debug o de error en la librería por pantalla.

Dojo se diferencia de YUI en que al definir los elementos HTML, introducimos un nuevo parámetro llamado dojotype en el que le indicamos qué tipo de elemento dojo va a ser. De esta forma al inicializar el elemento en Javascript, la mayoría de la definición se encuentra en el elemento HTML. Vayamos por pasos: paso 1, el código HTML:

En el código definimos tres divs a los que les decimos que son dojotype="dialog". De esta forma, Dojo sabe que tiene que renderizarlos como diálogos. Además les definimos una serie de características propias de Dojo (las subrayadas en rojo): bgcolor(color de fondo de la pantalla no del div), bgOpacity(opacidad del fondo de la pantalla), toogle (forma en la que aparece o desaparece la pantalla) y toogleDuration (duración del efecto de aparecer y desaparecer).

El resto del código es html normal. Veamos cómo se definen los diálogos y las funciones (ved que llamo a dos funciones Javascript CargarNombre() y Empezar()).

He dividido el Javascript en trozos. En la primera parte tenemos las definiciones de las variables que vamos a utilizar después, los tres diálogos, y las dos funciones manejadoras de los eventos de respuesta correcta y respuesta incorrecta, hasta aquí todo igual que antes. Tenemos también la función init, que se ejecuta al cargar la página que define el primer diálogo que aparece en pantalla. La definición es muy simple, solamente utilizamos la sentencia dojo.widget.byId() y le pasamos el id del div que va a ser el diálogo (ese div tiene que tener el dojotype="dialog"). Le definimos el botón que va a ocultar el diálogo con la sentencia setCloseControl(). Ved que podemos utilizar con los diálogos las sentencias show() y hide() para mostrarlos u ocultarlos desde cualquier parte del código. ¿Y las llamadas a servidor cómo se hacen? Pues veamos el resto del código:

Tenemos la función CargarNombre() que muestra el diálogo de espera y llama al servidor. Con Dojo, las llamadas se realizan utilizando el método dojo.io.bind al que le pasamos parámetros. Los más comunes y necesarios (algunos) son: url (dirección a la que llamar), load (método que controlará la respuesta correcta del servidor), error (método que manejará la respuesta de error del servidor), mimetype (mimetype de los datos de la llamada).

Dojo también permite realizar llamadas cross-domain mediante el método bind(), pero hay que importar el espacio dojo.require("dojo.io.XhrIframeProxy"), proque la llamada se realiza mediante un iFrame Proxy. Esto está aún en pruebas así que os aconsejo que vayáis a la documentación y os lo leáis.

Conclusión (hasta la próxima):
Como se me está haciendo demasiado largo el post, dejaremos los dos frameworks restantes para el siguiente. Sólo comentaros mi experiencia con ambos: personalmente prefiero el framework de Dojo que es bastante más intuitivo de utilizar, aunque YUI tenga más documentación (es realmente buena), cuando empiezas a trabajar con Dojo y te empiezas a enterar de cómo funciona, es más liviano. De todas formas, al ser frameworks completamente independientes de plataformas, siempre podéis conjugarlos y utilizar aquellas partes que más os gusten de uno y de otro.

Proximamente: GWT y ASP.NET AJAX

Noticiones Varios

2007-07-11T08:18:00.000Z

Actualización:
Ya he arreglado el bug del mapa, así que podéis disfrutar de él todo lo que queráis. ¿Qué os parece?

Bueno chavales, hemos cambiado nuestra página web, dándole un nuevo aspecto. La podéis visitar en http://www.nidea-soluciones.com.

Aunque todavía tenemos que darle un último retoque, os recomiendo visitar la parte de contacto y abrid el mapa. Nos hemos integrado con el API de Google MAPS y ha quedado resultón. He detectado un pequeño bug que corregiré en breve.

Por otro lado, SUPER NOTICIA, Producciones Porunbujero ha empezado su actividad como estudio de grabación y productora de vídeos. Estamos trabajando en su página web, podéis visitarla (sólamente está la portada) para obtener los datos de contacto. Su dirección es: http://www.porunbujero.com

Os doy sus datos de todas maneras:

Producciones Porunbujero
Tejuela 25, Alcalá la Real
605978242

Creación de un EJB(I): Session Bean

2007-07-08T22:19:00.000Z

Bueno, después de este pequeño traspiés con la nueva versión de J2EE, voy a ir contándoos lo que voy haciendo para crear un bean de sesión desde donde lo dejé. Recordemos que en el primer post hablamos sobre la tecnología J2EE y en el segundo post habíamos instalao nuestro servidor de aplicaciones de Sun. Por lo que me comentó Manolo, existe también otro servidor de aplicaciones llamado JBOSS que parece ser que es más eficiente, pero como yo ya había trabajao con una versión previa de éste, os voy a contar cómo se hace ésto. También he visto por ahí que hay un proyecto open source llamado GlashFish que creo que también es un servidor de aplicaciones y tiene buena pinta pero eso es arena de otro costal que ya urgaremos cuando proceda. Yo voy a lo mío.

Después de instalar el servidor de aplicaciones, en la nueva versión, necesitamos para desplegar nuestras aplicaciones un pack para Netbeans o un plugin para eclipse que se ofrecen junto con el servidor de aplicaciones en la página de Sun. Ésas eran las herramientas que se descargaban si en vez de pulsar en Download with JDK pulsábamos en Download with Tools. Como por entonces no tenía ni idea de que ya no existía la herramienta de despliegue deploytool, pues yo ya tengo mi servidor de aplicaciones instalao en mi máquina. No todo está perdido. Yo he escogido hacerlo con NetBeans como reto personal porque ya conocía Eclipse y tenía ganas de ver qué tal era NetBeans, pero vosotros podéis hacerlo con lo que elijáis.

Bien, para empezar nos vamos a la página de descarga de Sun y pinchamos en un link que hay a la derecha en un div azul titulado Related Resources y que se llama NetBeans. Ahí podemos descargarnos tanto el propio IDE NetBeans como el Enterprise Pack. Descargad agusto. Luego la instalación es bastante simple. Hacemos un chmod +x fichero_binario y luego un ./fichero_binario. Con ésto se nos abre un instalador gráfico bastante intuitivo al que la máxima información que tendremos que aportarle será el sitio donde queremos que lo instale cuando se trate del IDE o del sitio donde hemos instalao el IDE cuando se trate del Enterprise Pack. Habrá un momento de la instalación que nos preguntará si queremos instalar un servidor de aplicaciones o si queremos usar una instalación preexistente. Obviamente aquí usaremos el servidor que habíamos instalao en el post anterior y para ello tendremos que darle el nombre de usuario y la contraseña de administrador que nos creamos en su momento.

Aparte de ésto, lo demás no os creará problemas. Y bien, ahora tenemos nuestro servidor de aplicaciones perfectamente sincronizao con nuestro IDE NetBeans que hemos instalao para el desarrollo de nuestros beans y sólo nos queda desarrollar las aplicaciones.

Creación de un Bean de Sesión - El meollo.

Vamos a crearnos un Bean de Sesión que a partir de un día, mes y año de nacimiento calcule la edad que debe tener la persona. Además posteriormente y para ver la funcionalidad de ésto, nos vamos a crear una página JSP que haga uso de este Bean para recoger la información introducida por un usuario, mandársela al bean, recoger el resultado y mostrarlo por pantalla. Al lío pues.

Arrancamos NetBeans si no lo hemos hecho ya y pinchamos en Archivo -> Nuevo Proyecto -> Nueva Aplicación Empresarial. Rellenamos los campos necesarios. En nuestro caso le vamos a poner de nombre CalculadorEdad. Ponemos la carpeta donde queremos que se guarde y seleccionamos la versión de J2EE que queremos usar. En este primer post vamos a usar J2EE 1.4 que es la versión que yo había trabajado, pero a ver si más adelante os puedo escribir cómo hacerlo con J2EE 5 para que veáis la diferencia. Aseguráos antes de darle a "Terminar" de que marcáis las casillas de "Crear módulo EJB" y "Crear módulo de aplicación Web" y dejad sin marcar la de "Crear módulo de aplicación Web" de abajo que se refiere a un cliente de aplicación web que nosotros no necesitaremos, sólo los dos primeros. Debería quedar parecido a lo que sigue:

Pinchad en "Terminar".

Ahora creamos el nuevo Session Bean. Para ello le damos al botón derecho en CalculadorEdad-ejb -> Nuevo -> Bean de sesión.
Introducimos el nombre que será CalculadorEdad, ponemos el nombre de un paquete, que será por ejemplo "calculadoredad". Marcamos "sin estado" puesto que vamos a hacer un Stateless Session Bean, ponemos el tick en las dos interfaces, remota y local y pinchamos en Terminar. En realidad podríamos valernos sólo con la Remota, ya que la local es para optimizar accesos desde local pero vamos a ponerlo todo y así vemos todas las interfaces en pleno rendimiento. El resultado será que nos creará automáticamente las clases que necesitamos e implementará él sólo el código aburrido de los métodos de ciclo de vida y demás asuntos escabrosos. A nosotros nos tocará entonces implementar los métodos de negocio que son los específicos de nuestro bean. La intención es crear una aplicación que introduciendo una fecha de nacimiento calcule los años que tiene la persona dada. Así pues, nuestro método de negocio lo llamaremos edad y recibirá como parámetros 3 int representando el día, mes y año de nacimiento. Además le diremos que lanza una excepción que llamaremos PeroQueInventoEsEsteException y que extiende de Exception para indicar cuando alguien ha introducido una fecha no válida (ya se que aún no la hemos creado, lo haremos a continuación).

Si le damos al botón derecho en la clase CalculadorEdadBean , y seleccionamos métodos EJB -> Agregar método Business podremos añadir nuestro método de negocio que os describía arriba y el código se implementa sólo. Jurch, estos IDEs...dentro de poco no habrá que saber programar para programar :).

Justo después de haber puesto todo lo que arriba decíamos vamos a crearnos nuestra excepción especial. Para eso nos vamos dentro de CalculadorEdad-ejb al apartado de "Paquetes de orígen". Le damos al botón derecho encima y decimos Nuevo -> Clase java. Como nombre le damos PeroQueInventoEsEsteException y le decimos que la cree. A continuación la abrimos haciendo doble click en ella y añadimos a su declaración de clase el código "extends Exception" para que tenga las propiedades de una excepción normal y corriente. Luego en el constructor por defecto metemos como código "super();" y nos creamos un constructor con un String como parámetro que tenga por código "super(motivo);" siendo motivo el nombre del String del parámetro. Ya tenemos nuestra excepción.

Ahora vamos a implementar el código de nuestro método de negocio. Para ello nos vamos a la clase CalculadorEdadBean que es quien tiene que implementar el código de nuestro bean y picamos código. Mi implementación to perrillera del método que calcula la edad es la que os pongo aquí.

public int edad(int dia, int mes, int anho) throws PeroQueInventoEsEsteException{
//Obtenemos un objeto java.util.Date con la fecha actual y un objeto java.sql.Date con la fecha que ha introducido el usuario
java.sql.Date fecha = java.sql.Date.valueOf(new Integer(anho).toString()+"-"+new Integer(mes).toString()+"-"+new Integer(dia).toString());
hoy = new Date();
//Para compararlos obtengo el número de milisegundos desde "The Epoch"
long nacimiento = fecha.getTime();
long actual = hoy.getTime();

//Si se ha introducido una fecha futura...
if(nacimiento>actual){
throw new PeroQueInventoEsEsteException("¿Tu tas creído que somos unos pardillos o qué? ¿usease que aún no has nacío no?");
}

//Calculamos el tiempo en milisegundos que la persona lleva viviendo y hayamos su edad averiguando cuántos años son esos milisegundos. Hay un error obvio debido a los años bisiestos pero no lo contemplaremos aquí.
long tiempoDeVida = actual-nacimiento;
int edad = (int)(((tiempoDeVida/1000)/3600)/24)/365;

return edad;
}

Hago uso de java.util.Date (que está importada en el inicio de la clase con un simple "import java.util.Date") y de java.sql.Date por la facilidad de uno para crear objetos Date a partir de Strings y la facilidad del otro para crear objetos Date representando la fecha actual. Como ambos tienen un método getTime() que devuelve el número de milisegundos desde "The Epoch" que es como se conoce a las 00:00h del 1 de enero de 1970, mediante una simple resta puedo tener los milisegundos de vida de la persona que ha introducido su fecha de nacimiento. Paso los milisegundos a años y voilà, ya tenemos su edad. Está claro que no estoy contemplando los bisiestos y ésto sería un problema, pero como la propia implementación es bastante perrillera no me voy a centrar en que el código sea bonito o que cumpla bien con su cometido, sino en que veáis una implementación de un EJB. Además la aproximación es bastante cercana, y sólo fallará en días próximos a nuestro cumpleaños así que lo podemos considerar aceptable para un ejemplo :). De toas formas sí, ya se que es un código un tanto perrillero, pero weno, qué le vamos a hacer.

Lo único que nos queda por hacer con el Bean es darle un nombre de referencia en el servidor para que pueda ser encontrado por nuestra página web (que crearemos a continuación) cuando vaya a buscarlo. Ésto es fácil. Nos vamos al menú de la izquierda, donde está nuestro CalculadorEdad-ejb. Desplegamos el submenú "Archivos de configuración" y hacemos doble click encima de "sun-ejb-jar.xml". Ese fichero es en realidad un xml, pero nuestro querido IDE NetBeans nos lo mostrará como cajitas y menús tó wapos (si es que vivimos en una puta metáfora con las interfaces gráficas ;) ). Veréis que debajo de "Configuración Sun" tenéis un submenú llamado CalculadorEdadBean, pues pinchad en él, y veréis algo como ésto:

Rellenadlo como véis en la imágen, poniendo "ejb/CalculadorEdadBean" en el campo de "Nombre JNDI". Ya tenemos nuestro bean programado y reconocido por el servidor para que pueda ser llamado por otras aplicaciones, servlets, beans o JSPs.

Ahora nos vamos a crear una página JSP. En realidad esta página ya está creada. Se creó automáticamente cuando marcamos la casilla de "Crear módulo de aplicación Web" cuando creamos el proyecto. Para verla, id en el menú de la izquierda a "CalculadorEdad-war" y desplegad su submenú. De ahí nos vamos a páginas web y veréis que hay una que se llama "index.jsp". Ésta es la que nuestro servidor de aplicaciones mostrará cuando ejecutemos la aplicación y entremos en localhost:8080/CalculadorEdad-war. Pinchad dos veces sobre ella y se os abrirá a la derecha. Ahora la vamos a editar. Os voy a enseñar el código en dos trozos pa ir explicándooslo poco a poco. Primer cacho:

De lo que veis, llamaros la atención sobre unas pocas cosas:

No os olvidéis de importar las clases necesarias para el funcionamiento de vuestra página JSP, además de las clases de las interfaces del Bean que váis a usar.
Cread un contexto inicial como se ve en el código.
Fijáos en la forma de obtener una referencia a nuestro Bean. Primero se obtiene una referencia al interfaz de inicio o interfaz Home de nuestro Bean sobre la que llamaremos a su método create(). Lo hacemos con el método lookup(String) sobre nuestro contexto inicial y le preguntaremos por "java:comp/env/" + el nombre que le dimos a la referencia del EJB. ¿Os acordáis? Lo que sí recordaréis seguro es que en los Session Beans el bean nace y muere con el cliente, así que aquí no tendría mucho sentido obtener la referencia de otra forma. La creamos cada vez y punto.

Ahora pasamos al segundo cacho:

Aquí está la chicha de nuestra página. Quitando el código que es meramente HTML, lo más importante quizás sea lo que está a partir de la línea 47. Tened en cuenta que cuando llamemos a nuestra página JSP lo podremos hacer pasándole parámetros en la propia URL del tipo dia=4&mes=5&anho=1984. Ésta es la forma de funcionar de una petición "GET". Para recuperar esos parámetros en nuestro JSP tendremos siempre el objeto request siempre inicializado y que indica la petición, y si llamamos a su método getParameter("parametro"), éste nos podrá devolver o el valor del parámetro, o bien null, y debemos contemplar esa posibilidad. También contemplamos la posibilidad de que el usuario pinche sobre el botón sin haber introducido nada (se hace en las comprobaciones noseque.length()>0) por lo que se estará enviando una cadena vacía. Una vez capturados los parámetros con los que se ha llamado a nuestra página JSP mediante nuestro formulario que generaba peticiones "GET" sobre la propia página, los transformamos en el tipo de dato que necesitábamos, para ello apoyándonos en la clase java.lang.Integer y llamamos al método de negocio edad(int,int,int) que nos habíamos creado usando la referencia que obtuvimos en el primer cacho de código. Al realizar la llamada tenemos que encapsularla por un try-catch que recoja las excepciones que se puedan producir, que en nuestro caso será la excepción especial cachonda que nos habíamos creao. Y finalmente, si la excepción no se ha producido sólo tenemos que mostrar el mensaje con el resultado de la llamada a nuestro bean. ¿A que no es complicao?

Por último, vamos a crear una referencia al EJB en nuestro módulo de aplicación web. Cosa sencillica. Nos vamos al menú de la izquierda de NetBeans. Desplegamos el menú de "CalculadorEdad-war" y dentro de él el submenú de "Archivos de configuración". Hacemos doble click sobre web.xml. Aquí pasa como antes, que pese a que es un fichero xml, nuestro IDE nos lo muestra de forma bonica (si queréis ver su forma real podéis pinchar en el botón "XML" que os lo enseñará perfectamente). Ya trastearéis un poquillo por este fichero para descubrir que se pueden configurar muchísimas cosas, como por ejemplo el tiempo que dura una sesión o temas de seguridad y demás, pero lo que a nosotros nos importa lo conseguimos pinchando en el botón de "Referencias". Ahí desplegaremos "Referencias EJB" y pincharemos sobre "Agregar". Ahí se os mostrará algo como:

Rellenadlo como ahí pongo. Aquí fijáos que en el nombre de la referencia tiene que haber una coherencia con el nombre que configuramos antes en el servidor al EJB. Luego, dado que hemos metido las distintas clases de nuestro EJB en un paquete llamado calculadoredad, fijáos en que al indicar las interfaces de inicio y remota hemos puesto delante calculadoredad.*, es importante. Una vez que hayáis hecho ésto, pinchamos en guardar y tocad la madera más cercana porque se supone que ya lo tenemos todo listo para desplegar nuestra aplicación. Lo que sigue es fácil. Le damos al botón derecho encima de "CalculadorEdad", que es la raíz de nuestro menú de la izquierda y seleccionamos "Ejecutar Proyecto". Nos saldrán un chorro de letras por abajo, os pedirá el nombre de usuario y contraseña de administrador y parecerá que nuestra máquina esté intentando calcular todos los números de pi, pero cuando lleve un rato leeréis algo así como "GENERACIÓN CORRECTA" y sabréis que todo este tiempo habrá merecido la pena :). Que no os lleve a engaños, este mensaje aparece también cuando la mayoría de las cosas fallan. Depende del tipo de fallo que se produzca. Si las referencias las habéis puesto mal o el código no rula como debería de rular, el mensaje os aparecerá, pero cuando intentéis entrar en vuestra página lo que salga o cómo funcione la aplicación...eso ya será otro rollo.

Para comprobar que la cosa rula abrimos un navegador y metemos la dirección
http://localhost:8080/CalculadorEdad-war/
Si todo ha ido medianamente bien debería de mostrársenos algo como ésto...

Ahora introducimos un día de nacimiento, mes y año correctos, por ejemplo Día: 4, Mes: 5, Año: 1984, y pinchamos en "Submit". Nos debería salir algo como...

Es correcto. Pero, ¿qué pasa si introducimos una fecha en el futuro? ¿cómo manejará nuestra página aquella PeroQueInventoEsEsteException que nos inventamos? ¡Probémoslo! El resultado debería parecerse a éste...

Wapo ¿verdad?. En realidad, seguramente no queráis hacer una aplicación de un servidor de aplicaciones que maneje una página que te calcula tu edad con un cierto márgen de error de días según bisiestos...es mu probable que no, pero hacer un calculador de edad es lo mismo que hacer cualquier otra cosa, sólo cambiad el código y número de los métodos de negocio y fenómeno. Se que es un poco tedioso, pero también hay que tener en cuenta que en este ejemplo nosotros hemos hecho todo el trabajo. En un servidor de aplicaciones real seguramente no tuviéramos que hacerlo. Ahí es donde entra el reparto de roles que contempla este tipo de programación. El desarrollador no tiene por qué ser el mismo que el desplegador, que a su vez no hace falta ni que conozca a quien montó el servidor de aplicaciones. Por eso os enseñé en el anterior post cómo arrancar y parar el servidor desde línea de comandos, pues puede que os toque símplemente hacer ésto y no desarrollar nada encima. Una vez montado el sistema, ya es sólo cuestión de hacer correr distintas aplicaciones sobre él y si somos listos al cliente le cambiaremos muy poco la interfaz para no hacerle la picha un lío, como al fin y al cabo lo que va por debajo no le importa, sólo tenemos que añadir métodos de negocio y añadir nuevas funcionalidades en nuestra interfaz que nunca cambia :). Todo ventajas. Inconveniente: ésto es java, así que ya se sabe, el procesador echando humo y la memoria derrochándose. Pero weno, dejemos eso para otro momento.

El desarrollo de un EJB de sesión con estado es bastante similar al del sin estado que hemos desarrollado así que el siguiente post lo dedicaré a crear un EJB de entidad (con una bonita base de datos derby). Espero no haberos aburrido mucho y que ésto os pueda servir para introduciros en cómo hacer lo que ya sabéis que queréis hacer.

AJAX PARA SUPERCAMPEONES o ¿Sabremos alguna vez qué es AJAX? (III)

2007-07-03T16:25:00.000Z

Hala, de vuelta con el tema Ajax (la verdad es que da mucho juego el tema...). En esta tercera entrega de esta serie nos vamos a centrar en los siguientes dos temas:

Llamadas simultáneas: es decir, realizar múltiples llamadas a diferentes sitios a la vez.
Llamadas asíncronas secuenciales: este es un tema importante, saber cómo hacer llamadas asíncronas de forma ordenada.

Si no os habéis leído los posts anteriores, os recomiendo que lo hagáis:

Como sé que ya te los has leído, Nacho, puedes seguir con el siguiente punto ;P. En este post, terminamos la serie de AJAX PARA CAMPEONES o AJAX A PELO o AJAX KAMIKAZE, es decir, ajax para frikies.

Llamadas simultáneas
Una de los beneficios más importantes de trabajar con hebras de ejecución es que podemos crear tantas como nos permita el entorno (hardware, línea de comunicación, etc.) y el objeto XMLHttpRequest no es menos. Trabajando con AJAX podremos, por lo tanto, lanzar mútliples hilos de comunicación de forma simultánea que ejecutarán tareas distintas. Tendremos que tener cuidado de manejar correctamente las respuestas, de forma que sepamos siempre de quién es cada una.

En el ejemplo que os pongo aquí, podéis realizar tres llamadas simultáneas para que se carguen en los divs inferiores la página web que hayáis puesto. No es que esté demasiado currado pero menos es nada.

Ejemplo: http://www.nidea-soluciones.com/PruebasAjax/PruebaAjax5.html

Existen ciertas peculiaridades para que este ejemplo funcione:

Se ha creado una nueva función EnviarPeticionConParametro que además de realizar la petición le pasa un parámetro a la función que maneja la respuesta (aparte del objeto XMLHttpRequest).
Se ha implementado un Proxy al que llama la página para que se puedan hacer llamadas asíncronas CROSS-DOMAIN. Ésto lo explicaré otro día.

El código de la nueva función es el siguiente:

Como veis, introducimos un nuevo argumento llamado "parametro" que se le pasará a la función callback. Con este parámetro podremos decirle a la función callback qué objeto es el que ha realizado la llamada y ha respondido. Lo marco porque es muy importante ya que cada llamada tardará el tiempo que sea y devolverá el resultado en orden aleatorio. Tenemos que disponer de algún método que asocie la llamada con la respuesta.

Para entenderlo mejor, veamos el código de la página y cómo se realiza la llamada:

En este caso, tenemos la función CargaURL(posicion), donde en posición se le pasa un 1, un 2 o un 3, dependiendo de qué botón es el pulsado. En base a ese número, se leerá el input correspondiente y se mostrará el panel de espera asociado. Finalmente se llama a la función EnviaPeticionConParametro y se le pasa la posición como parámetro final.

A la función que maneja la respuesta le llega el parámetro de la posición por lo que es capaz de poner la respuesta en el div correcto y oculta el div de espera correspondiente. De esta forma podemos tener una sola función que gestiona todas las llamadas y otra función que gestiona todas las respuestas. Si no lo hiciésemos así tendríamos que asociarle una función diferente a cada respuesta.

Os pongo un dibujo que como sabéis me molan y en el post anterior no tuve oportunidad de poner ninguno:

Las peticiones se envían al servidor, el cual las gestionará y tardará un tiempo x. Al ser asíncronas, las peticiones se evaluarán de forma simultánea y a medida que las vaya resolviendo irá mandando la respuesta. El orden de evaluación y respuesta no es fijo por lo que el orden de llegada de las peticiones no tiene por qué tener relación con el de salida. Es muy típico equivocarse con este concepto y escribir lo siguiente:

function MiFuncionQueRealizaMuchasCosas(){
// Primera accion asíncrona
ActualizaDatos();
MuestraDatosActualizados();
}

Error, al ser la función ActualizaDatos una llamada asíncrona a servidor, perderemos ese hilo de ejecución hasta que lo recoja el manejador de la respuesta. Por esto, la función MuestraDatosActualizados() no mostrará esos datos.

Llamadas asíncronas secuenciales
Por fin, el último ejemplo, lo último del AJAX PARA CAMPEONES. Este ejemplo se lo dedico con mucho cariño a Nacho porque sé que es tela de friki del Linux y en especial de Kubuntu y Ubuntu. Espero que te guste.

Como ya estaba harto de páginas html guarras con el texto a pelote decidí currarme un poquillo más este último ejemplo del post. En este ejemplo se realizan seis llamadas a servidor secuenciales, hasta que no se recibe la contestación de una no se realiza la siguiente. Podéis ver el ejemplo en la siguiente dirección (funciona mejor con Firefox porque el IE, a partir de la segunda vez, se pasa por el forro el delay que le tengo puesto en servidor):

http://www.nidea-soluciones.com/PruebasAjax/PruebaAjax6.html

Mola cantidad, eh? Por lo menos le damos un poco de aqué al tema. En fin, vamos al lío. ¿Cómo se hace esto? Aparte del tema gráfico (cada uno lo pone como más le gusta), la secuenciación de llamadas se realiza de la siguiente manera (os lo pongo en tres imágenes porque no me cabía en una):

Lo que hacemos es lo siguiente:

Cuando el usuario pulsa sobre el botón, mostramos el divProgreso y le ponemos la primera imagen grande y su texto. Llamamos a la url Codigos/PruebaAjax6.aspx para ir a servidor.
Cuando se recibe la respuesta, se pone la imagen en pequeño, se pone en grande la siguiente y la descripción de la acción y se realiza la llamada a la página con el parámetro del siguiente paso.
Así sucesivamente hasta que en la última llamada, invocamos a la página redireccion.html. Obtenemos su código html y lo metemos dentro del div wrapper que engloba a toda la página.

Viéndolo en un dibujillo:

Es en las funciones callback donde realizamos la siguiente llamada.

El finaaaal deeeel veraaanooooo, llegoooo.....
Como todo, en algún momento hemos de llegar al final e igual que el verano todo acaba. Creo que con esta serie de ejemplos cubrimos la base de la comunicación asíncrona y del AJAX PARA CAMPEONES. Como os habréis percatado, el manejo del Javascript es fundamental (por Dios, nooooo), aunque, como veremos en posts posteriores, existen frameworks que nos ayudarán en nuestro cometido (un poco). Es importante que os deis cuenta que es indiferente el lenguaje de programación que utilicéis (yo lo he hecho todo en html plano), simplemente debe permitir hacer llamadas a funciones Javascript.

En próximos capítulos:

Frameworks Ajax
Llamadas Cross-Domain

Se me está ocurriendo hacer también algún post con el tema de los Mash-Ups.

Instalación del Servidor de Aplicaciones

2007-07-02T22:08:00.000Z

Actualización 04/07/07: Tras escribir este post, me he dao cuenta que la última versión del servidor de aplicaciones de Sun y de los EJB presentan algunas diferencias clave con respecto a la versión que yo había manejado y de la que os iba a hablar. Para empezar, hasta la versión anterior a la que os he indicao como instalar, se proporcionaba con ella una herramienta de despliegue llamada "deploytool" que en la nueva versión ha sido sustituída por un pack para NetBeans 5.5 u opcionalmente un pluguin para Eclipse, trastearé con ellos antes de escribir cómo hacerlo. También, la programación de los EJB 3.0 presenta algunas diferencias con respecto a su versión anterior en cuanto al número de interfaces a implementar por el/la programador/a y alguna notación específica a utilizar. Dejadme un tiempecillo que lo trastee todo y ya os escribo más adelante.

Y vamos al lío. Ya vimos en el anterior post la teoría mínima sobre J2EE y EJB's que nos iba a hacer falta para saber qué tenemos entre manos, pero sólo con la teoría, y más aún en este caso, no se puede saber de qué se está hablando concretamente, hace falta algo de código, así que en este post la intención era que desarrolláramos y desplegaremos un bean de sesión...peeeeeero, cuando me he puesto a escribir este post me he dao cuenta que ya se hacía demasiao largo sólo con la instalación y configuración del servidor de aplicaciones así que he decidío pasar al siguiente post el desarrollo de nuestro primer bean.

Lo primero de todo será pues arrancar nuestro servidor de aplicaciones. Pero...¿qué servidor es ese?
Bien, vamos a descargárnoslo de la página de Sun. Yo voy a hacer todo el proceso bajo GNU/Linux, concretamente sobre una Kubuntu 7.04, pero ésto es extrapolable de forma inmediata a cualquier otro sistema Linux y descargándose la versión correcta, también a cualquier sistema Windows. No os recomiendo usar Windows, pero allá vosotros/as :).

Entramos en http://java.sun.com y vamos hasta la página de descarga de la última versión de Java EE SDK disponible, junto con el JDK. Para ahorraros la tarea, aquí tenéis un link http://java.sun.com/javaee/downloads/index.jsp. Ahí pincháis en Download with JDK, luego en Accept License Agreement y finalmente sobre la versión de nuestro SO, lo que descargará un fichero autoinstalable donde elijamos. Este fichero contiene entre otras cosas el Java EE SDK y el servidor de aplicaciones de Sun, que son los dos elementos que nos hacen falta.

Una vez lo tenemos en nuestro sistema de ficheros, le damos permisos de ejecución con un simple chmod +x nombre_del_ejecutable. Para ejecutarlo hacemos ./nombre_del_ejecutable y se lanzará un instalador gráfico muy intuitivo. Ya sabéis, siguiente, siguiente, siguiente, meto el sitio donde quiero instalarlo, acepto lincencia, siguiente, siguiente... :). Haciendo eso llegaremos a una pantalla donde tenemos que meter el nombre de usuario del administrador y su contraseña. Importante que os acordéis de este nombre y contraseña. Como siempre, no lo apuntéis en ningún lao salvo que estéis pensando en comeros el papel donde se apunte en breves o que se trate de una región cifrada de vuestro sistema de ficheros. La cosa se vería tal que así:

Como veis, también tendréis que meter los puertos en los que escuchará nuestro servidor de aplicaciones. Si los puertos por defecto los tenéis ocupados por otra aplicación cambiadlos a vuestro gusto o símplemente por el hecho de añadir un poco más de seguridad al asunto colocándolos en puertos que no sean los habituales (sí, ya se que herramientas como nmap permiten escanear alegremente los puertos activos de una máquina, pero está bien poner las cosas un poco más complicás siempre). Yo como voy a instalarlo y desinstalarlo hoy mismo, voy a dejarlo por defecto. El siguiente paso, pulsar en Install now. Lo siguiente ya lo conocéis, una barra de progreso de 0% a 100%, algo como...

y que cuando acabe nos mostrará la página final que además contiene información útil...

La información que ahí aparece es especialmente útil porque indica cuál es la orden para arrancar el servidor, que vendrá a ser algo así como...
/sitio/donde/lo/hayais/instalao/bin/asadmin start-domain domain1 (por defecto se crea el dominio llamado domain1)
...pero antes deberíamos establecer una variable de entorno llamada JAVA_HOME que apuntara al sitio donde tengamos instalao un JDK (Java Development Kit). Si hemos escogío la opción de descarga que os dije tenéis uno en el subdirectorio jdk dentro de la nueva instalación. A continuación incluiremos la subcarpeta JAVA_HOME/bin dentro de la variable PATH de nuestro sistema. Dependiendo del tipo de intérprete que usemos ésto se hará escribiendo en un terminal:
export JAVA_HOME=/sitio/donde/lo/hayais/instalao/jdk
export PATH=${PATH}:${JAVA_HOME}/bin
...ó...
setenv JAVA_HOME /sitio/donde/lo/hayais/instalao/jdk
setenv PATH ${PATH}:${JAVA_HOME}/bin

Además también deberíamos de introducir en el PATH una variable que apunte a la localización de los scripts de nuestro servidor, que se habrán instalado en una subcarpeta /bin de nuestra instalación, algo así como...
export J2EE_HOME=/sitio/donde/lo/hayais/instalao
export PATH=${PATH}:${J2EE_HOME}/bin
...ó...
setenv JAVA_HOME /sitio/donde/lo/hayais/instalao
setenv PATH ${PATH}:${JAVA_HOME}/bin

Y finalmente dado que nuestro servidor de aplicaciones necesitará de una base de datos, vamos a establecer la variable CLASSPATH apuntando a un fichero *.jar que permite manejar la BBDD Derby que viene con la instalación de nuestro servidor. Lo tendréis en una subcarpeta llamada /javadb o similar. Ésta variable también tendrá que apuntar al fichero *.jar de J2EE así como al fichero *.jar que apunte a las utilidades de derby. Ésto lo hacemos con un...

export CLASSPATH=${J2EE_HOME}/lib/j2ee.jar:${J2EE_HOME}/javadb/lib/derbyclient.jar:${J2EE_HOME}/javadb/lib/derbytools.jar

...ó...

setenv CLASSPATH ${J2EE_HOME}/lib/j2ee.jar:${J2EE_HOME}/javadb/lib/derbyclient.jar:${J2EE_HOME}/javadb/lib/derbytools.jar

Personalmente os recomiendo que para no tengáis que hacer ésto siempre que queráis arrancarlo, os creéis un pequeño script que os lo haga automáticamente, de hecho, ya que ésto lo haréis cuando vayáis a arrancar el servidor de aplicaciones, lo mejor es que en el mismo script también arranquéis el servidor con la orden que ya vimos anteriormente. Éste script podría lucir algo así como...

Con ésto establecer las variables necesarias y arrancar o parar nuestro servidor sería tan fácil como llamar a nuestro script de la forma adecuada. Imaginemos que nuestro script lo hemos llamao servidor.sh.
Para arrancar nuestro servidor de aplicaciones haríamos...
source servidor.sh arrancar
...y para pararlo haríamos...
source servidor.sh parar
¿fácil no?

Si nuestra máquina fuese a funcionar de servidor de aplicaciones de forma permanente podríamos introducir este script en el runlevel adecuado del arranque de nuestro sistema GNU/Linux para que siempre que arranque la máquina se llame a este script y de forma automática se arranque el servidor. Si lo vamos a usar en un PC de escritorio para pruebas, podríamos crear un lanzador en nuestro entorno gráfico para que con un click se arrancase. Si lo vamos a arrancar y parar de forma periódica a determinadas horas se puede colocar una llamada al script en el cron de la máquina, etc, etc, etc...y así podéis buscar mil formas para facilitar la tarea y no tener que hacer ésto ná más que una vez.

El pantallazo de arranque podía ser éste que os muestro a continuación.

Para comprobar que hemos arrancado bien nuestro servidor, abrimos un navegador y entramos en http://localhost:8080. Deberíamos ver algo como ésto.

Por último, para entrar en la herramienta de administración, entraremos desde nuestro navegador en la dirección http://localhost:4848 y veremos algo como ésto.

Aquí es donde entra en juego el nombre de usuario y la contraseña que escribisteis en un papel para ahora coméroslo. Metéis nombre de usuario de administrador, que en mi caso era admin, contraseña, y os saldrá la página de administración del servidor de aplicaciones, que tendrá una pinta parecida a ésta.

Por supuesto, si hemos cambiado los puertos de administración o web al instalar el servidor, tendremos que coherentemente cambiar las URLs a las que accedemos para ello.

Por último, vamos a parar el servidor porque ya nos hemos hartao de tenerlo encendío y no lo vamos a usar más. El resultado de llamar a nuestro script con el parámetro "parar" será tan escueto como éste que sigue.

Y nada más. Espero que después de ésto tengáis en vuestra máquina un bonito servidor de aplicaciones J2EE activo y preparao pal desarrollo de vuestros beans. Ahora sólo nos falta configurarlo a nuestro gusto, pero eso es algo que haremos en el siguiente post para el desarrollo de nuestro primer bean.

A descansar chavalinos/as que ya os estamos dando mucho curro entre Manolo y yo (como si no supiera que el único que va a leer ésto vas a ser tú, Manolo ;) ).

AJAX para CAMPEONES o ¿Qué es eso del AJAX? (Segunda Parte)

2007-07-02T08:37:00.000Z

Como su nombre indica, en este post continuo con el anterior de ¿Qué es eso del AJAX?. Si no lo habéis leido, leedlo para cogerle el hilo a este. En este post vamos a tratar el tema del que denominé como AJAX PARA CAMPEONES, es decir, la programación a pelo, vía Javascript, de las llamadas asíncronas y de toda nuestra lógica del lado de cliente. Empecemos pues.

Lo primero: las herramientas
Si empezasteis a trastear un poco con el ejemplo del post anterior, os daríais cuenta que la programación con Javascript es muy puñetera, cualquier mínimo fallo en una letra y nada funciona y a ver quién es el guapo que sabe dónde está el fallo. Javascript adolece de falta de herramientas para trabajar con él y nos podemos tirar horas delante de un código sin saber que leñe falla y sin la menor ayuda. Sin embargo (aquí vengo en plan salvador de los programadores) existen varias herramientas que nos pueden ayudar en nuestra ardua tarea:

Firebug: extraordinario complemento de Firefox que nos permite inspeccionar todo el HTML, el Javascript, el DOM, las hojas de estilo. Podemos depurar el código Javascript, ponerle puntos de interrupción, etc. Una herramienta indispensable para los campeones del AJAX.
Aptana IDE: un entorno de desarrollo, aunque también existe como plugin de Eclipse para el desarrollo de Javascript. Es magnífico y tiene un puñado de funcionalidades buenísimas: autocompletado, ayuda dinámica, nos dice la compatibilidad de exploradores para cada método, depuración, etc. También incluye las librerías YUI, Dojo, Mochikit, Rico y AFLAX listas para trabajar con ellas (de esto hablaremos en un post posterior).

Por supuesto, antes de empezar, tened dispuesto Internet para consultar las múltiples dudas que os vayan saliendo.

En fin, no queda más remedio, vamos al lío
En el post anterior vimos un pequeño ejemplo de una llamada básica a servidor para obtener un fichero de texto. En ese caso, lo único que hacíamos era llamar al servidor y poner el texto en un div. Vamos a extender un poco este concepto con otro ejemplo. En este caso ponemos una caja de texto donde el usuario introduce el nombre, pulsa el botón y se realiza una llamada a servidor que devuelve "Te devuelvo tu nombre:" seguido del nombre. Este ejemplo tiene tres particularidades:

Cuando el usuario pulsa el botón aparece un cartel de espera, indicando al usuario que se está cargando la página
He introducido un delay en servidor de 2 segundos para que se aprecie el cartel de espera.
Se han mejorado las funciones de creación del objeto XMLHttpRequest y la de envio de la petición (ahora veremos en qué).

El ejemplo lo podéis ver aquí:
http://www.nidea-solucio nes.com/PruebasAJAX/PruebaAjax2.html

En este caso he llevado las funciones generales (la de creación del objeto y envío de la petición) a un fichero javascript independiente llamado FuncionesAJAX.js. Veamos en primer lugar este fichero y cómo han cambiado las funciones:

La función ObjetoAjax() la hemos cambiado en el sentido de que ahora contempla todas las posibles inicializaciones que existen. La función EnviarPetición acepta ahora 5 argumentos:

objetoAjax: será el objeto que inicialicemos con la función anterior. Se inicializa fuera de esta función para que podamos lanzar múltiples comunicaciones a la vez a través de objetos distintos.
método: tendremos que poner si queremos hacer un "GET" o un "POST".
url: dirección del servicio web o página o recurso con el que queremos comunicarnos.
async: true si queremos que la llamada sea asíncrona o false en el caso que no. Si es asíncrona tendremos que definir un método que maneje la vuelta.
callback: nombre del método que manejará la vuelta. La función EnviarPetición se encargará de enganchar la petición con este manejador y pasarle como parámetro el objeto XMLHttpRequest utilizado.

Como veis, esta función es mucho más general que la anterior y con ella podremos hacer mejor las cosas.

Veamos ahora el código de la página PruebaAjax2.html, la primera parte, dentro de la etiqueta HEAD es:

En esta parte incluimos el script FuncionesAJAX.js y seguidamente definimos dos funciones:

CargaURL(): esta función es la que inicializa el objeto Ajax, pone visible el panel de espera y llama al método EnviarPeticion. Como veis, llamamos a una página .aspx pasándole como parámetro el nombre. La página devuelve un flujo con el texto. Esta llamada se podría realizar a cualquier página o servicio web que hubiésemos programado nosotros en cualquier lenguaje. Cuidado con intentar llamar directamente a páginas de otro dominio diferente de donde tengáis las páginas u os saltará un error al abrir la conexión. Esto se llama LLAMADAS CROSS-DOMAIN, y no se pueden hacer directamente, hay que utilizar un proxy o elementos intermedios.
FinCargaURL(objeto): es la función que maneja la respuesta del servidor. Cuando nos responde el servidor, esconderemos el panel de espera y pondremos el texto en el div correspondiente. Ved cómo se pasa como argumento el objeto Ajax encargado de la comunicación.

La parte del BODY de la página es:

En esta parte definimos únicamente la disposición de los elementos. Tenemos el div pnlEspera que contiene la etiqueta de espera, al que le ponemos en el estilo display:none para que inicialmente no se vea. Este ejemplo está bien porque, por lo menos, le ponemos un cartel al usuario diciéndole que algo estamos haciendo (sin demasiada información, pero bueno). Por supuesto esto es muy mejorable y remarco los siguientes aspectos:

El usuario puede volver a pulsar sobre el botón mientras se está haciendo la llamada. En determinadas circunstancias esto no debe poderse hacer. Imaginad una operación crítica que se realiza varias veces porque el usuario le ha dado al botón sin parar.
La información proporcionada en el cartel no es demasiado explícita. Habrá determinados momentos en los que se realicen operaciones largas, de varios pasos, y haya que informar al usuario de por donde va el tema.

Por esto, pasamos al siguiente ejemplo.

Por Dios, más no, por favor
Pues si, un poco más de Javascript a pelo. En este ejemplo (el tercero del total si no me falla la cuenta), deshabilitamos el botón que realiza la llamada mientras estamos en ello. Podéis ver el ejemplo en la siguiente url:

http://www.nidea-soluciones.com/PruebasAjax/PruebaAjax3.html

Mola, verdad? Lo único que hacemos es deshabilitar el botón en la función CargaURL y habilitarlo en la función FinCargaURL. Veamos el código:

Le ponemos la propiedad "disabled" a true y luego la volvemos a cambiar a false. Ya empezamos a darle un poquillo de forma al tema, cuidando un poco los detalles, aunque, pequeños saltamontes, el camino aún no ha terminado y es largo y duro.

En el siguiente ejemplo, le hemos incluido un contador de tiempo, que se inicia de forma que el usuario sabe cuánto tiempo tarda en volver la información. Lo podéis ver en:

http://www.nidea-soluciones.com/PruebasAjax/PruebaAjax4.html

Aunque no tiene mucha utilidad si que sirve para ilustrar que podemos mostrar información en pantalla mientras se realiza la llamada, de verdad es asíncrona. En este caso hemos puesto un contador, pero podría ser cualquier tipo de información. En un ejemplo posterior veremos cómo ir diciéndole al usuario en qué estado se encuentra la operación (para poder darle más información). El código Javascript de esta página se complica un poco más:

Jugamos en este caso con la función setInterval de Javascript que ejecuta cada x milisegundos la función que le pasemos como argumento. La función clearInterval para este ciclo.

Final, por ahora...
Como, otra vez, se me está haciendo demasiado largo el post, finalizo aquí. En posteriores post trataremos los siguientes casos:

Múltiples llamadas a la vez
Información del estado al usuario
Llamadas Cross-Domain
Utilización de Frameworks que nos ayuden en nuestro camino con AJAX.

J2EE, programación de servidores de aplicaciones

2007-07-01T22:29:00.000Z

¿Qué? ¿cómo andamos?

Se que dije que el siguiente post sería de XMLSchema pero voy a dejarlo pa más tarde y me dedicaré hoy a hablar un poquillo por encima de la tecnología J2EE (Java 2, Enterprise Edition). Haré una introducción teórica en este primer post de una serie de 4 post en los que trataré lo que os quiero presentar de la siguiente forma:

Introducción teórica a vista de pájaro de Java 2, Enterprise Edition (J2EE) y sus Enterprise Java Beans (EJB).
Creación de un EJB (I): Session Bean.
Creación de un EJB (II): Entity Bean.
Creación de un EJB (III): Message-Driven Bean.

J2EE

Si tuviéramos que, como en el colegio, hacer teoría de conjuntos y ver qué conjuntos es menor que cuál o está contenido en o chorrás desas, tendríamos que decir que:

J2ME < J2SE < J2EE

Y es que si bien J2ME no es exactamente un subconjunto de J2SE o J2EE puesto que puede tener elementos que no aparecen en éstos, sí que cuanto menos es una edición mucho más reducida del entorno de desarrollo.

Los objetivos básicos con los que surge J2EE son:

Abstraer las tareas críticas y repetitivas mediante servicios con una interfaz uniforme.
Preparar una infraestructura uniforme y de una arquitectura software basada en ella para aplicaciones empresariales.

La tecnología de J2EE utiliza la filosofía de la programación basada en componentes, más que la orientada a objetos. En este tipo de programación, un componente es algo más amplio que un mero objeto, y más asociado a la aplicación.

Además, una aplicación compleja basada en componentes a su vez se subdivide en niveles lógicos, de forma que cada nivel cubra un área de tareas y que pueden componer una o varias partes. Así obtenemos "Thin Clients", frente a los "Fat Clients" de la arquitectura Cliente/Servidor, ya que en los niveles intermedios se delega parte de la responsabilidad del servidor. Cada nivel se comunica sólo con los niveles contiguos mediante interfaces bien definidas.

EJB's

Pero pasemos de to este movidón teórico y metámonos en más teoría pero por lo menos un poco más próxima a la práctica. Veamos el concepto de beans. Los beans son nuestros colegas, nuestras "habichuelas", las entidades mínimas de nuestro diseño de aplicaciones...y de servidores de aplicaciones. En esencia son clases java con unas ciertas propiedades que permitirán darnos algunas prestaciones en función de nuestras necesidades, o más técnicamente son componentes que pueden ser usados para construcción de aplicaciones distribuídas y que encapsulan una parte de la lógica de negocio de una aplicación. Un EJB accede a otros gestores de recursos como bases de datos u otros EJB's y puede ser accedido por otros EJB's, aplicaciones, servlets y aplicaciones cliente. el EJB reside en un contenedor que le provee de servicios de seguridad, transacciones, gestión del ciclo de vida, gestión de concurrencia y despliegue.

Un EJB (salvo en el especial caso de los Message-Driven Beans) tiene varias partes:

La interfaz cliente. Permite el uso síncrono por parte de los clientes de los procesos de negocio que modela el EJB. Consta de dos clases de tipo interface. La Home Interface que debe extender la clase EJBHome y controla los métodos del ciclo de vida y la Remote Interface que debe extender la clase EJBObject y controla el acceso a los métodos de negocio remotamente.
La clase Enterprise Bean. Implementa el Bean en sí, su funcionamiento interno, las llamadas a las BBDD necesarias, los métodos de negocio, ciclo de vida, etc.
El descriptor de despliegue. Proporciona al contenedor toda la información que éste necesita sobre el EJB (nombre, nombre de sus interfaces, tipo de EJB, servicios que se esperan del contenedor, etc). Se trata de un fichero XML, y debido a su complejidad y su extensión se suelen utilizar herramientas de despliegue que lo creen a partir de la selección de opciones en un interfaz gráfico por parte del desplegador.

Lo que nuestros coleguitas beans pretenden ayudarnos a modelar son lo que llamamos "entidades de negocio" y "procesos de negocio", que viene a ser una forma empresarial de llamar a información de nuestra aplicación y métodos de acceso y modificación de esa información. Para que nos entendamos, las entidades de negocio son las bases de datos donde los procesos de negocio son los métodos/funciones/procedimientos que acceden a esas bases de datos y leen o modifican lo que en ellas hay.

Y para eso, ¿en qué nos ayudan los beans? Pues bien, tenemos beans para cada una de nuestras necesidades en una apliación...beans a la carta. En esencia tenemos:

Beans de Sesión (Session Beans):
Se encargan de la parte del lado servidor de la lógica de negocio de una aplicación.
Se crean instancias de un Session Bean cuando se produce una petición de un cliente y su tiempo de vida es el de el proceso abierto. Podemos tenerlos de dos tipos:

Beans de sesión sin estado (Stateless Session Beans)
No guardan información del cliente. Todos los Stateless Session Beans instanciados tienen la misma identidad.

Beans de sesión con estado (Statefull Session Beans)
Presentan diferentes estados en función del cliente, estado que se pierde cuando se deja de usar el Session Bean. Como consecuencia, cada objeto Session Bean tiene distinta identidad.

Algunas propiedades

Su estado se mantiene en memoria principal durante una transacción pero pasa a almacenamiento secundario tras desactivarse. Además su estado es inaccesible para otros programas, aunque pueda ser sincronizado para las transacciones.
Sólo puede usarse por un mismo cliente, no puede ser compartida su referencia.
Frente a fallos no se garantiza que una referencia a un objeto Session Bean siga valiendo.

Los Session Beans son especialmente adecuados para encargarse...
...de la lógica de sesión de una aplicación web...

...o también para encargarse de la lógica de sesión de una aplicación de tres capas.

Beans de Entidad (Entity Beans):
Este tipo de beans son los que nos modelan aquéllos conceptos u objetos de negocio cuyos datos deben ser persistentes, para lo que se suele usar una base de datos. Se pueden usar por varios clientes de forma conjunta y simultánea. Su identidad es tan simple como la clave primaria de la base de datos usada. Son tan persistentes que incluso llegan a sobrevivir a caídas de la máquina o de la máquina virtual de Java. En función de quién controle esta persistencia, se clasifican en dos tipos distintos:

Persistencia manejada por el bean (Bean Managed Persistence)
El programador del bean debe programar los métodos que aseguran la persistencia, que vienen a ser los métodos que guardan los datos en la base de datos, así como crear la base de datos y mapear variables con columnas de la base de datos.

Persistencia manejada por el contenedor (Container Managed Persistence)
El programador queda liberado de la tarea de programar la persistencia teniendo únicamente que indicar al contenedor qué variables van a asociadas a qué columnas de la base de datos para que éste controle la persistencia. Todo este mapeo se reflejará en el fichero xml descriptor del bean.

Algunas propiedades:

El estado de un Entity Bean es mantenido en una BBDD, con caché en memoria durante una transacción. Por consiguiente, cualquier programa externo puede acceder a él mediante queries SQL. Además su estado se cambia con transacciones y se puede recuperar en cualquier momento.
Un objeto Entity Bean puede ser compartido por múltiples clientes pasándose la referencia sin problemas.
Frente a fallos, caídas del contenedor o de la máquina, las referencias a los objetos siguen siendo válidas.

Beans controlados por mensajes (Message-driven Beans):
Este tipo de beans permiten a las aplicaciones J2EE procesar mensajes asíncronos, lo que los diferencia de los anteriores cuya llamada era síncrona. En última instancia no son más que escuchadores de mensajes JMS. Su estructura de hecho es similar a la de los escuchadores de eventos de java, sólo que éstos lo que escuchan son mensajes.
La principal diferencia a nivel de uso de éste tipo de bean con los anteriores es que el acceso a ellos no se realiza mediante interfaces, sino por:

Mensajes enviados por algún componente J2EE (una aplicación cliente, otro EJB o un componente web).
Mensajes enviados por una aplicación o sistema JMS que no use la tecnología J2EE.

También a diferencia de los demás beans, los MDB sólo se componen de una clase java, ya que no tienen interfaces.
describamos entonces algunas de las propiedades de este tipo de EJB's:

Una instancia a un MDB no almacena datos o estado conversacional de ningún cliente.
Todas las instancias de MDB tienen la misma identidad, por lo que la asignación de una instancia a un cliente es indiferente de qué instancia sea.
Un único MDB puede procesar mensajes procedentes de múltiples clientes.

Cuando un mensaje llega, el contenedor de nuestro EJB llama a su método onMessage(), que típicamente lo primero que debe tener programado es la clasificación de este mensaje según pertenezca a cada uno de los 5 tipos de mensajes JMS, para luego procesarlo según la lógica de negocio de nuestra aplicación.

Y bueno, yo creo que como introducción a J2EE y EJB's ya se ha hecho demasiao larga, pero weno, espero haberos ayudao en familiarizaros en esta tecnología. El siguiente post irá dedicao a programar y desplegar un Session Bean pa que le echéis un ojo a su código y veáis que hacerlo es más o menos sencillico aunque un poco coñazo. Además usaremos alguna herramienta de despliegue de EJBs que provee Sun. ya os contaré.

+info:
http://java.sun.com/javaee/5/docs/tutorial/doc/
http://java.sun.com/javaee/5/docs/firstcup/doc/toc.html
http://java.sun.com/javaee/index.jsp

¿Qué es eso del AJAX?

2007-06-27T15:18:00.000Z

Algunos pensarán que el AJAX es un equipo de fútbol holandés, otros pensarán que les da igual qué es lo que es, otros pensarán que tiene algo que ver con internet (nos vamos acercando al tema). En este post voy a intentar dar una primera idea que, si puedo iré extendiendo en sucesivos posts, de qué es realmente AJAX y qué podemos hacer con él.

La definición es:

AJAX: Asynchronous Javascript and XML

muy bien, y esto ¿qué significa?

Empezaré contando mi pequeña historia con AJAX, mi experiencia con AJAX comenzó cuando un conocido me comentó que estaban haciendo un sistema web con ATLAS. Yo pensé "¿para qué meter un atlas en un sistema web?", luego me enteré que ATLAS es una implementación de ASP.NET para AJAX. A estas alturas aún no sabía qué era AJAX. Con el tiempo empecé a investigar por mi cuenta y a jugar con diferentes lenguajes de programación y frameworks javascript: programé con PHP, utilicé el GWT (Google Web Toolkit) para Java, enredé con el framework Dojo y Rico, programé con ASP.NET, etc. En fin que me mareé viendo herramientas y programando con ellas, pero, realmente ¿QUÉ ES AJAX?

Mi último proyecto, con el que estoy ahora mismo (aprovecho para comentarlo) es un portal libre para compartir cursos de formación (http://learning.nidea-soluciones.com) es donde más he trabajado con AJAX y todas las técnicas relacionadas, así que, vamos al lío de verdad.

¿Qué es AJAX?

AJAX no es ni más ni menos que un mecanismo que nos permite realizar llamadas asíncronas al servidor desde un página web. Así suena muy poca cosa, pero en realidad abre todo un mundo de posibilidades (y problemas...).

¿Cómo eran las cosas antes de AJAX? Antes de AJAX, una página web se componía de etiquetas HTML y de etiquetas de servidor (utilizadas por el lenguaje de programación). Cada vez que un usuario realizaba cualquier acción en una página web que requiriese de la actualización de su contenido, se ponía la pantalla en blanco (mientras se realizaba la comunicación con el servidor) y luego volvía a aparecer con la actualización puesta. ¿Por qué pasaba esto? porque lo que los navegadores entienden es el HTML, y las etiquetas de servidor las debe sustituir el servidor por HTML con los datos correctos. Veamos el siguiente ejemplo:

Tenemos una página simple programada en ASP.NET (es lo que tengo más manío):

Lo único que hace esta página es pedir un nombre y al pulsar sobre el botón, pone el nombre que se ha escrito en una etiqueta. Sin embargo, éste lenguaje no es entendido por el navegador, por lo que el servidor web, lo que hace es sustituir las etiquetas por lo que corresponda en HTML. La primera vez que se ve la página, el código enviado es:

Todas las etiquetas han sido sustituidas por sus correspondientes etiquetas HTML. Si el usuario introduce un nombre y pulsa sobre el botón "btnBoton" que pone Púlsame, la página se tendrá que recargar para que aparezca el nombre en la etiqueta "lblNombre". El servidor (porque se le indica así en el fichero de código que acompaña a esta página) devolverá la siguiente página:

La página devuelta tiene en la caja de texto el nombre "Manolo" y en el span también. Al pulsar el botón, hemos tenido que ir al servidor para que recompusiese el HTML y lo enviase de vuelta al navegador. El tiempo que tarde en llegar la petición al servidor, en que éste evalúe las acciones, obtenga los resultados, rehaga el HTML y llegue de vuelta al navegador, será el tiempo que esté nuestro explorador en blanco. Esto es así porque las operaciones son SÍNCRONAS (lo remarco porque este es el quid de la cuestión).

Lo que nos permite AJAX es lanzar una llamada asíncrona al servidor para que nos envíe la información que requiramos de vuelta, sin que el usuario pierda el control de la interfaz de usuario. Como me gustan mucho los dibujos, veámoslo en uno de ellos:

En el primer caso, se realiza una llamada a http://www.nidea-soluciones.com (os la marco por si queréis visitarla). El servidor web devuelve el HTML de la página, el explorador lo lee y lo pinta en la pantalla. Si el usuario pulsa algún botón o realiza alguna acción que requiera una respuesta del servidor (actualización de una parte de la página), se enviará una petición de actualización al servidor y perderemos el control en el explorador, la página se quedará en blanco esperando que el servidor recomponga todo el HTML y se lo envíe de vuelta. Este tiempo variará dependiendo del servidor, de las líneas de comunicación y de lo que queramos actualizar. En ocasiones puede llegar a ser muy frustrante puesto que no sabemos si se ha colgado el sistema, si la línea se ha caído, por dónde va el proceso, etc. y actualizamos la página para volver a darle o nos salimos del sitio.

En el segundo caso utilizamos AJAX en nuestra página web y el proceso varía ligeramente. La primera llamada al servidor nos devuelve la página web, igual que el ejemplo anterior. Sin embargo, a partir de ese momento, todas las peticiones de actualización de partes de la página se realizan con llamadas asíncronas a servidor. Esto lo que hace es lanzar una hebra de ejecución diferente de la que tiene el control de la página y, esta hebra, contacta con el servidor y le pide la información. En Javascript, habremos implementado un manejador para el evento de recepción de la respuesta. Cuando llegue la respuesta se ejecutará el código de ese manejador, donde le diremos qué tiene que hacer con los datos que nos envía el servidor. Durante el tiempo de ida y venida al servidor, la hebra principal mantiene el control de la página, posibilitando que el usuario siga haciendo cosas con ella. Podría realizar más peticiones a servidor y se lanzarían nuevas hebras.

Hasta aquí muy bien pero, ¿y eso cómo leñe se hace?

La primera alternativa para trabajar con AJAX es la que denomino, AJAX PARA CAMPEONES. La pongo en mayúsculas y coloreado porque esta opción es la de trabajar a pelo con Javascript y con el objeto XmlHttpRequest (que veremos ahora). Esta alternativa es un poco sádica pero creo que es necesario que sepáis realmente cómo funciona. Una vez superado este nivel podremos trabajar con la opción AJAX COMODO, en la que utilizaremos algún framework de los existentes.

Vamos a ver un ejemplo práctico (aquí iba a poner un ejemplo pero Blogger me bloquea las llamadas asíncronas), por lo que podéis ver el ejemplo en:
http://www.nidea-soluciones.com/PruebasAJAX/PruebaAJAX1.html.

En este ejemplo, al pinchar en el enlace lo que se hace es inicializar el objeto xmlHttpRequest (encargado de realizar la llamada asíncrona) y hacer un GET asíncrono a http://www.nidea-soluciones.com/PruebasAJAX/prueba.txt El texto de respuesta lo coloca en una etiqueta que está justo debajo del enlace. Veamos el código:

Si nos fijamos en la parte BODY, tenemos un hipervínculo que al pulsarlo lanza la función CargaTexto(), hecha en Javascript, y tenemos un SPAN llamado textoAjax. Vamos a ver las tres funciones Javascript que hemos definido:

Función ObjetoAjax(): función encargada de inicializar el objeto XMLHttpRequest para poder realizar llamadas asíncronas a servidor. Esta función comprueba el tipo de explorador porque Firefox e Internet Explorer utilizan diferentes inicializaciones para este objeto (como siempre...).

Función CargaTexto(): esta es la función que se invoca cuando el usuario hace clic sobre el enlace. Esta función realiza tres cosas distintas:

Utiliza el objeto Ajax para abrir una conexión GET con la URL http://www.nidea-soluciones.com/PruebasAJAX/prueba.txt.
Declara cuál va a ser la función que se ejecute cuando llegue la respuesta a la llamada al servidor. En este caso, dicha función va a ser capturaPeticion.
Lanza la llamada.

Función CapturaPeticion(): cuando se recibe la respuesta se lanza esta función que lo que hace es poner el texto de la respuesta en la etiqueta SPAN definida.

Este ejemplo es muy básico pero ilustra bastante bien el ciclo de llamada y respuesta de AJAX. Siempre tendremos estas tres funciones: una que inicializa el objeto, una que realiza la llamada y otra que recibe la respuesta. En sucesivos posts iremos viendo cómo podemos mejorar este ejemplo (ya está siendo muy largo este), como por ejemplo:

Etiquetas de espera para que el usuario sepa que algo se está haciendo.
Control de la concurrencia en servidor.
Deshabilitar controles a la hora de ir a servidor.
Informe del estado de la operación
...

Estas son cosas importantes que hay que tener en cuenta a la hora de programar con AJAX, porque al introducir el elemento asíncrono, se incrementa la complejidad en nuestros desarrollos.

Finalmente, ¿qué NO es AJAX?
También es importante saber qué no es AJAX. AJAX es, simplemente, la posibilidad de realizar llamadas asíncronas a servidor. De ésto se pueden derivar muchas herramientas y controles, los llamados rich-controls, que utilizan AJAX. Podremos implementar grids que carguen los datos dinámicamente utilizando el objeto XMLHttpRequest y funciones Javascript, ventanas modales que carguen información, etc. Todos estos controles utilizan AJAX y CSS para ayudarnos en nuestros desarrollos, pero AJAX sólamente es el objeto XMLHttpRequest.

¿Otro post no? XML for Mayor!

2007-06-22T00:57:00.000Z

Como veo que la cosa está más muerta que un cordero la noche después del fin del Ramadán digo...¿voy a escribir no? ... pero ... ¿qué coño escribo?

Pues como últimamente he estao aprendiendo cosillas sobre XML, RDF, RDFa, JDOM, DOM, SAX, XML-RPC, SOAP, XSLT, SNMP, J2EE, J2ME, BGP, IPv6, y demás parafernalias (cómo mola escribir siglas, no importa que no tengas puta idea, quedas como un señor poniéndolas ;) ), pos me he decidío a contaros un poquillo de estas tecnologías en diferentes post por entregas. Si os aburro no tenéis más que decirlo.

Y pa empezar, vamos a introducirnos levemente en el maravilloso mundillo del XML.

Actualización(23/06/07):
Como los feeds (orígenes, RSS, como los queráis llamar) se envían mediante XML, paradojas de la vida, quien lea este post recibiéndolo desde un agregador probablemente no lo lea bien porque interpretará el código XML y el resultado será que no se le mostrarán las etiquetas, sólo su contenido. Por ello, por el momento y a estas alturas de la noche no se me ocurre más que entrar vía web para leerlo sin problemas. Mil perdones. ¿A alguien se le ocurre una solución?

XML

Mi descubrimiento de XML como metalenguaje para "casi todo" ha sido como encontrarse con un hermano perdido. Uno se pregunta...¿cómo coño no lo vi antes? ¿he estao tirando to este tiempo a la basura?

¿De ande ha salío ésto?

XML surge más o menos como una simplificación de SGML, que viene a ser un lenguaje un tanto más ambíguo pero mucho más extenso y rico. SGML se lo inventaron por allá por los "unites estates" cuando un grupo de editoriales decidieron que los autores tenían que definir el contenido de forma lógica mientras los editores se dedicaran a la presentación física que es pa lo que al fin y al cabo les pagan :). Así después de unos cuantos quebraderos de cabeza se llega a un estándar ISO con una especificación muuuuy compleja. Pero claro, esto pa los libros y un grupo reducido de gente dispuesta a andarse con rodeos está mu bien, pero pa Internet digamos que la cosa estaba chunga. Así surge una simplificación que aprovechaba la experiencia previa de SGML para orientarlo a Internet y que permitía fácilmente la definición de nuevos lenguajes (de ahí el eXtensible de "eXtensible Markup Language"). Sobre todo, lo que se buscaba era un lenguaje que fuese fácil de procesar, y a la vista está que lo consiguieron. Podíamos decir que con XML se consiguió un 80% de la funcionalidad de SGML con sólo un 20% de su complejidad. Todo un logro, ¿verdad?

Pa no confundirnos, y como a alguno ésto le puede sonar a HTML aclaremos que
XML == SGML--
pero...
XML != HTML++

Aunque la sintaxis XML pueda recordarnos a HTML (de hecho las versiones actuales de HTML son ya XML, más concretamente se le llama XHTML), XML presenta algunas diferencias con el tradicional HTML de to la vida. Algunos ejemplos son:

En HTML podíamos alegremente cerrar y abrir las etiquetas donde nos diese la gana, e incluso algunas ni cerrarlas, por lo que se suponía  por defecto. En XML ni de coña. Cada etiqueta que se abra debe ser cerrada adecuadamente, e importando y mucho el orden. Así mientras en HTML podíamos escribir jeje, en XML no se puede en aras de un procesamiento más simple y de más claridad.
Mientras en HTML los valores de los atributos podían o no ir entre "", en XML es estrictamente obligatorio que lo hagamos.
En HTML podíamos dejar un atributo vacío sin cerrar, pero en XML todo elemento se cierra. Por ejemplo:
(HTML) <img src="http://www.blogger.com/...">
(XML) <img src="http://www.blogger.com/..." /> (nótese que pa ahorrarse el curro de volver a poner la etiqueta con "/" delante, si el elemento es vacío se puede poner el símbolo "/" antes de cerrarlo).

Dicho ésto vamos a ver un ejemplo sencillico XML y sobre él ya vamos trabajando.

Veamos qué pinta tiene

<?xml version="1.0" encoding="UTF-8">
<!DOCTYPE empresa SYSTEM "empresa.dtd">

<!-- Definición de una empresa emprendedora, "así tó wapa" podíamos definirla-->
<empresa clase="wenaquetecagas" contacto="nidea@nidea-soluciones.com">
<nombre>N-IDEA. Nuevas Ideas</nombre>
<url tipo="web">http://www.nidea-soluciones.com</url>
<url tipo="blog">http://nidea-soluciones.blogspot.com</url>
<direccionpostal>C/ Tejuela, 25. Alcalá la Real (Jaén). CP: 23680</direccionpostal>
</empresa>

Como véis, es bastante intuitivo. Yo defino lo que quiero y con la lógica que yo quiero imprimiéndole semántica a lo que escribo. De hecho sin saber programar una persona que leyera el código de arriba muy probablemente comprendería el mensaje. Ésa es la idea.

Pero vamos a lo que nos ocupa. Bueno, aquí tenemos varias cosas. Primero tenemos
<?xml version="1.0" encoding="UTF-8">
Ésta es lo que se llama una "processing instruction", pero además es una especial. Es la que debe contener todo documento XML al principio. Ántes de ella no se puede escribir nada, ni siquiera comentarios, para que el documento sea válido. Las processing instruction sirven para pasarle información a la aplicación que usa el documento XML. Normalmente su sintaxis es:
<?Programa Instrucciones?>
Como por ej: <?JAVA_OBJECT JAR_FILE="/nidea/mijar.jar"?>
Por supuesto, para no confundir al bicho, está prohibido empezar la processing instruction con "xml" ya que este nombre está reservado para el principio del documento como habéis visto.
Lo que sigue a "xml" son dos atributos de nombre version y encoding, y de valores 1.0 y UTF-8 respectivamente. Aunque os lo podéis imaginar, son la versión y la codificación del documento. La version es obligatoria que sea 1.0 (creo), y que aparezca siempre, pero la codificación puede no aparecer o puede ser distinta. Por ejemplo, un tipo de codificación muy típica es la ISO-8859-1 que viene a ser la que define los caracteres españoles específicamente. La UTF-8 es también llamada Unicode-8 y es la que he usao en este caso.

Siguiente cosa rara que vemos es...
<!DOCTYPE empresa SYSTEM "empresa.dtd">

Es una etiqueta especial ya que como se puede observar no sigue la sintaxis de xml para las etiquetas. No va cerrada, el nombre de la etiqueta comienza por ! en lugar de por letra o "_" y tiene espacios. Entonces...¿qué #!*+ es? Pues se trata de la definición del tipo de documento. Como ésto es sólo una breve introducción no entraré en detalles, pero es necesario saber que debe apuntar al elemento raiz del documento xml (lo que sigue a !DOCTYPE, en nuestro caso empresa) y al DTD del documento, que viene a ser un fichero que especifica la estructura de nuestro documento xml, qué elementos pueden ir dentro de otros, qué tipo de datos se acepta en cada elemento, cuántas veces puede aparecer un elemento, etc. Pero eso ya lo veremos luego. En nuestro caso, el DTD está en la misma carpeta del documento xml y se llama "empresa.dtd".

Después vemos un comentario. Es eso de...

Pos eso, se trata de un comentario. Algo que el/la programador/a escribe para que no sea interpretado por los programas que hagan uso del documento, pero que puede servir para hacer más legible el mismo o para explicar algunos detalles específicos a otros/as programadores/as que puedan leer nuestro xml. En ocasiones también se usa para ocultar elementos a los programas. En fin, usarlos mola, pero no usarlos no hace tu documento no válido.

Y luego viene el documento en sí, con sus etiquetas, sus atributos y demás. De eso creo que poco hay que explicar. La cosa está en imaginar de forma lógica la información que queremos representar y luego escribirla con coherencia. Si queremos representar en un documento una empresa que puede ser de varias clases y que tendrá un único e-mail de contacto, una forma de representarlo sería con la que escogí arriba:
<empresa clase="wenaquetecagas" contacto="nidea@nidea-soluciones.com"></empresa>
pero ahí ya está vuestra imaginación y el tipo de datos que queráis representar. Si además sabemos que una empresa tiene un nombre, nos podemos inventar un nuevo elemento que esté dentro de "empresa" y cuya etiqueta sea "nombre". Si sabemos que la empresa tendrá urls de varios tipos y múltiples, una fórmula puede ser crear otros tantos elementos también dentro de "empresa" de etiqueta "url" y con un atributo "tipo" que defina el tipo de url que es (página web, blog, wiki...). Si por último sabemos que las empresas representadas por este tipo de documento pueden tener una dirección postal que queramos representar, nos podemos imaginar un último elemento "direccionPostal" que almacene esta información. Pero lo que os dije antes, todo es imaginar e inventar. Ahí los creadores sois vosotros/as.

Bueno, visto un ejemplo práctico sobre el que habremos visto la dinámica de XML, vamos a ver algunas cuestiones específicas de los elementos y los atributos.

Elementos y Atributos

Los elementos deben comenzar su nombre por letra o underscore (_) seguido de alguna combinación de letra, underscore, números, puntos, dos puntos o guiones. No puede contener espacios en blanco y no puede comenzar por "xml" en ninguna de sus variantes (xml, xmL, xMl, xML, Xml, XmL, XMl o XML). En principio no existe longitud máxima para el nombre aunque hay que tener cuidado con algunos parsers de nivel superior que puedan tenerlo.

Los atributos se definen en la etiqueta de comienzo de un elemento. Definen pares nombre="valor". No pueden estar duplicados dentro de la misma etiqueta, usan para su nombre las mismas reglas que los elementos y son obligatorias las comillas para determinar el valor. Como es lógico, el símbolo de las comillas (") no puede aparecer en el valor del atributo, para lo cual se utilizará la entidad predefinida & quot; (sin el espacio entre & y quot;. No lo junto porque entonces vuestro navegador os lo mostraría como " y entonces habríamos hecho un pan con unas hostias).

DTD

Veamos lo último que nos falta para poder definirnos nuestro lenguaje XML a nuestro gusto. Pongamos que vamos a definir un nuevo lenguaje que llamaremos NideaML.
Como hemos visto antes, NideaML es un lenguaje sencillico y que sirve para definir una empresa dado su nombre, clase, correo-e de contacto, urls de varios tipos y dirección postal. Si dejáramos nuestro documento anterior tal cual eliminando la sentencia de !DOCTYPE, ya no sería NideaML, sería XML normalico y corriente porque no existirían restricciones que impidieran a nadie meter otros atributos en el documento o inventarse nuevos elementos, o no colocarlos en su debido orden. Si no hay DTD, se asume que cualquier cosa puede ir dentro de cualquier cosa y se admite cualquier tipo de elemento. ¿Pero cómo podemos añadir estas restricciones? Como ya os dije antes, para eso está aquí nuestro amigo el DTD.

Como antes, no hay mejor forma de aprender algo en cualquier tipo de programación que viendo algo programado, así que os mostraré cómo quedaría el DTD llamado empresa.dtd, que quedaría como sigue...


<!ELEMENT empresa (nombre, url*, direccionPostal?)>
<!ATTLIST empresa
clase CDATA #REQUIRED
contacto CDATA #REQUIRED>
<!ELEMENT nombre (#PCDATA)>
<!ELEMENT url (#PCDATA)>
<!ATTLIST url
tipo (web | blog | wiki | proyecto) "web">
<!ELEMENT direccionPostal (#PCDATA)>

¿Qué? ¿Cómo lo veis? ¿Bonito no? :).
Se puede intuir más o menos la sitaxis, pero vayamos poco a poco. De lo primero que ya os habréis percatao es que no se trata de XML, se parece más a nuestro querido !DOCTYPE que al resto de lo que hemos visto.

Bien, queremos definir qué elementos se permiten, cuáles están dentro de cuáles, qué atributos tienen, si son o no obligatorios y de qué tipo son.

Empecemos por los elementos. Los elementos se declaran con !ELEMENT seguido de su nombre y entre paréntesis el tipo de datos que van a contener indicando cuántas veces van a ocurrir. El nombre del elemento sigue las reglas que ya citamos antes, y el tipo de datos que van a contener pueden ser otros elementos (se pone el nombre de éstos), texto normal (#PCDATA), una combinación con expresiones regulares de las anteriores (ej: nombre | #PCDATA | (otroNombre, otroMas) ), cualquier cosa (ANY) o nada (EMPTY).
El número de ocurrencias de cada cosa que puede entrar en nuestro elemento lo definen unos caracteres que se añaden al final del nombre del elemento/expresión regular. Veamos nuestros símbolos para las expresiones regulares:
si no ponemos nada implica que ocurre sólo una vez
+ indica una o más veces
* indica cero o más veces
? indica cero o una vez
() indica agrupamiento
| indica disyunción
, indica secuencia ordenada
Vamos pues a echarle un vistazo a nuestro ejemplo para ver eso qué implica.

<!ELEMENT empresa (nombre, url*, direccionPostal?)>
Según lo dicho antes, esta declaración define un elemento de nombre "empresa" que puede contener a su vez otros elementos, y sólo otros elementos, no puede tener texto plano; y además estos elementos tienen que ser de tipo "nombre","url" y "direccionPostal"; y además tienen que aparecer en este orden; y además ocurrirá que,
"nombre" aparecerá sólo una vez,
"url" puede aparecer cuantas veces quiera o no aparecer,
"direccionPostal" puede aparecer una vez o no aparecer

¿Fácil no? Ahora vamos con los atributos
Los atributos se declaran con !ATTLIST seguido del nombre del elemento al que pertenecen y seguido de la lista de atributos que puede contener este elemento.
La lista de atributos se escribe siguiendo triplas del siguiente modo
nombre_atributo tipo_atributo valor_por_defecto
Ocasionalmente puede ir entre el tipo de atributo y su valor por defecto la obligatoriedad o no de que aparezca el atributo, de modo que
#REQUIRED significa que el atributo es obligatorio
#IMPLIED significa que el atributo no es obligatorio
#FIXED significa que el atributo está fijo al valor que ponemos por defecto y el programador del documento xml no puede modificarlo. Si lo hiciera esta valor es ignorado prevaleciendo el del DTD.
El valor por defecto sólo tiene sentido cuando el atributo es #FIXED o #IMPLIED. En el caso concreto de #FIXED además es obligatorio. La cosa es que si ponemos a un atributo #REQUIRED se supone que es obligatorio, luego el programador pondrá un valor sí o sí, ¿para qué íbamos a darle un valor por defecto si siempre sería machacado por el del programador XML?
Los tipos de datos pueden ser:
CDATA -> Similar al #PCDATA de los elementos.
Enumerated -> Tienen su sintaxis especial, es el que hemos usado en el ejemplo para el atributo "tipo" del elemento "url". Consiste en una expresión de posibles valores separados por (|) donde el programador/a elegirá uno de ellos.
ID -> Asocia al elemento un identificador único.
IDREF -> Referencia a un ID.
IDREFS -> Lista de IDREF separados por espacio.
NMTOKEN -> Especifican identificadores.
NMTOKENS -> Especifican listas de identificadores.

Si todo esto lo aplicamos a nuestro ejemplo particular...

<!ATTLIST empresa
clase CDATA #REQUIRED
contacto CDATA #REQUIRED>

...implica que estamos tratando con la lista de atributos del elemento "empresa"; que además puede tener atributos tipo clase o tipo contacto; que además clase son datos normales y corrientes y es obligatoria su aparición; y que además contacto también tendrá como valores datos normales y será obligatoria su especificación en el documento XML.

<!ATTLIST url
tipo (web | blog | wiki | proyecto) "web">

...implica que estamos tratando con la lista de atributos del elemento "url"; que además sólo tendrá el atributo "tipo"; que éste podrá ser igual a "web" o "blog" o "wiki" o "proyecto" y que en caso de no encontrarse el valor por defecto será de "web".

Y bien, yo creo que como introducción a lo que puede ser XML y su definición mediante DTDs, ésto ya está. Ya podéis haceros vuestro lenguaje MiracomomoloML para definir todo lo que se os ocurra. ¿Y para qué? Pues por ejemplo una utilidad muy buena es la de pasarle al documento una hoja de estilo XSLT y transformarlo directamente en una página web con un formato determinado, que puede servirnos para crear páginas web dinámicamente en una máquina a partir de una aplicación que recoja unos datos de un formulario web, o para utilizar sistemas como DOM o JDOM para recorrer la información recogida en el formulario web y convertida a XML y usarla para hacer otra cosa, o para crear apliciones...¡yo qué se! yo ya os he contao como funciona, ahora ¡a buscarle utilidades propias, coño! :).

Espero que os sea de utilidad. Si así es, prometo volver para contaros un poco de XMLSchema, que vienen a ser los sucesores de los DTD y que permiten más versatilidad y especificidad en las definiciones.

+info:
http://www.w3.org
http://www.xml.com
http://www.xmlinfo.com

Subversion: Colaboración en el Software

2007-03-29T09:39:00.000Z

En este artículo vamos a ver el funcionamiento de Subversion, una herramienta libre que sirve como repositorio de código en los proyectos de desarollo software. La utilización de un repositorio de código, un sitio central donde se vayan juntando todas las partes desarrolladas por las diferentes personas involucradas, es obligado. Sin embargo, Subversion nos ofrece una serie de funcionalidades que la convierten en una de las herramientas colaborativas más utilizadas.

¿Qué es un repositorio?
Un repositorio de código es, en esencia, un programa que sirve para juntar las partes de código que los desarrolladores programan por separado. Las funcionalidades básicas (aunque no todos las cumplen) son las siguientes:

Mantener revisiones de código, es decir, si yo cambio algo en el repositorio, el gestor de código debe mantener puntos de restauración, de forma que cualquiera pueda descargarse el código con mis modificaciones o sin ellas.
Seguimiento de Cambios, debo poder realizar comentarios cuando actualice algo, indicando qué es lo que he cambiado, qué es lo que he arreglado, etc. de forma que el resto de desarrolladores puedan consultar mi comentario y saber qué es lo que he hecho antes de descargarselo.
Copias de seguridad de los códigos y las revisiones.
Etiquetas de versiones y revisiones, para poder localizar rápidamente la versión a descargar o la revisión específica.

¿Por qué utilizar un repositorio de código?
Cuando nos encontramos involucrados dentro de proyectos de desarrollo donde trabajan diversas personas cada una de ellas conocerá una parte del desarrollo y se centrará en ella. Sin embargo, aunque cada uno lleve su parte, necesita la de los demás para que funcione correctamente. Sin un repositorio, tendríamos que enviarnos constantemente todas las partes unos a otros con el consiguiente caos, o que una persona se dedicase a recibir todas las modificaciones y mandarlas al resto de desarrolladores. En el siguiente diagrama se muestra un poco esta situación:

En el caso que tengamos un repositorio de código, la situación sería diferente. Cada desarrollador estaría conectado con el repositorio y enviaría sus modificaciones al mismo. Este se encargaría de conjugar las diferentes partes y mostrar a los desarrolladores la versión completa.

Operaciones con los repositorios:
Existen dos operaciones básicas que se realizan en todos los respositorios y luego algunas funcionalidades avanzadas de algunos mejor preparados, caso de Subversion.

Confirmar: subir los cambios que hemos realizado al repositorio. Únicamente se enviarán los cambios realizados con respecto a la versión existente en el repositorio.
Actualizar: recibir la versión existente en el repositorio con los cambios que hayan realizado el resto de desarrolladores.

Las operaciones especiales que tenemos en los repositorios y que le dan un valor añadido son:

Creación de etiquetas y versiones: nos permite marcar con una etiqueta una confirmación de cambios o crear una versión, de forma que se pueden localizar rápidamente las revisiones o versiones.
Creación de ramas de desarrollo: esta opción permite crear líneas independiente de desarrollo. Esto se utiliza para el desarrollo de partes de las aplicaciones que no queremos que interfieran en la rama principal hasta que estén acabadas. Una vez terminadas, se fusiona la rama de desarrollo con la principal.
Bloqueo de ficheros: habrá veces que estemos modificando un fichero y no queramos que nadie lo toque mientras lo tengamos nosotros. En ese caso, bloquearemos el fichero y el repositorio no dejará que nadie lo utilice.
Fusión de ficheros: esta es una de las herramientas más potentes de Subversion ya que permite que varias personas trabajen simultáneamente sobre el mismo fichero, encargándose él de fusionar los cambios. En caso de surgir un conflicto porque varias personas han modificado la misma parte del fichero, tendrá que ser el usuario el que diga cual es la modificación que prevalece.

Utilización del repositorio:
Como en todas las fases de un proyecto, es necesario plantearse una estrategia para la utilización del repositorio. Subversion se basa en carpetas dentro de las cuales se organiza la información. Para acceder al repositorio se puede hacer vía un servidor Apache (utilizando http) o mediante el servidor subversion (protocolo svn). Dentro del servidor accederemos a una carpeta o subcarpeta para actualizar nuestra información. Se aconseja siempre que los ficheros que se mantengan controlados por el repositorio sean los de código fuente, excluyendo ficheros binarios, compilados, librerías, etc. La estructura de carpetas aconsejable es la siguiente:

Carpeta TRUNK: rama principal de desarrollo, aquí irá el desarrollo principal y se irán fusionando las diferentes ramas.
Carpeta TAGS: carpeta donde se almacenarán las diferentes versiones y revisiones con nombre del desarrollo. Cuando queramos descargarnos una versión la buscaremos en esta carpeta
Carpeta BRANCHES: carpeta donde se almacenan las ramas de desarrollo de nuestro sistema.

Manteniendo esta simple jerarquía de carpetas será mucho más fácil gestionar nuestro repositorio de código y realizar las copias de seguridad.

Conclusión:
La utilización de un repositorio de código es obligado en proyectos que cuenten con más de dos o tres personas trabajando. No solo nos sirven como controlador de los cambios, sino también como copia de respaldo del código. Es muy aconsejable utilizarlos y sacarles el máximo de provecho.