Actualizando una base de datos local desde un servidor remoto - Parte III (final)

En la parte final de este artículo, vamos a crear un mecanismo que permita descargar la base de datos alojada en el servidor remoto y alojarla en una ruta local en nuestro smartphone.

Para ello vamos a utilizar el Framework de desarrollo Titanium Mobile. La ventaja es que prácticamente el mismo código nos va a servir para desplegarlo en plataforma Apple o en plataforma Android con un mínimo o casi ningún cambio.

Estructura de la aplicación

La aplicación en Titanium Mobile está compuesta principalmente por dos archivos:
  • app.js que es la aplicación de pruebas del mecanismo de actualización
  • updatedb.js que es una biblioteca o librería que contiene el mecanismo de actualización
Para ambas se necesita declarar el espacio de nombres (namespace) común myapp:

myapp = {}

Otro aspecto importante es la naturaleza asincrónica de la actualización. La librería comienza la actualización que en dependencia de la conexión a Internet que tengamos, el tamaño de la base datos y la potencia de nuestro smartphone demorará segundos más o menos y nos notificará cuando este proceso termine.

La librería updatedb.js

La librería updatedb.js está compuesta por:
  • Una estructura de datos de configuración que especifica datos como la url del servidor Web donde se va a alojar la base de datos, el nombre de la base de datos, el nombre del archivo de configuración, etc.
  • Una función updatedb que permite la actualización de la base de datos local a partir de la base de datos remota y un conjunto de funciones auxiliares (helper functions)

Datos de configuración de la librería

Dato
Descripción
url
URL del servidor Web donde hemos alojado la base de datos
db
Nombre de la base de datos
cf
Nombre del archivo de configuración que contiene una fecha en formato YYYYMMDD (ejemplo 20130226)
timeout
Tiempo de respuesta para el servidor Web que hemos fijado en unos 10,000 milisegundos o 10 segundos por defecto
android
True indica que vamos a ejecutar la aplicación en un smartphone Android, False indica que vamos a ejecutarla en un smartphone de Apple
debug
En True indica si queremos visualizar mensajes que nos ayuden a la puesta a punto. Una vez lista para desplegar en Producción este campo debería ser False
debugcb
Debug Callback. Llama a esta función cuando se produce una situación de depuración
updatecb
Update Callback. Llama a esta función cuando termina la actualización de la base de datos
errorcb
Error Callback. Llama a esta función cuando se produce un error catastrófico durante la actualización
winx
Ventana principal de la aplicación
olddate
Fecha de la configuración local o última actualización que registramos
newdate
Fecha de la configuración remota

La función updatedb

Básicamente la función de actualización de la base de datos:

myapp.dbu.actind = 
Titanium.UI.createActivityIndicator({ height:25, width:25 });
    
// If the application is running in iOS
if (!myapp.dbu.android){
// Setting the activity indicator style
myapp.dbu.actind.style = 
    Titanium.UI.iPhone.ActivityIndicatorStyle.BIG;
// Adding the indicator to the main window
    myapp.dbu.winx.add(myapp.dbu.actind);
}


Crea un indicador de actividad para darle al usuario feedback de que está ocurriendo el proceso de actualización.

if (Titanium.Network.networkType !== 
    Titanium.Network.NETWORK_NONE){
// Get the remote config file with the date to update  
     myapp.dbu.getremoteconfig();
 }


Si hay conexión a Internet procesa el archivo de configuración remoto que está alojado en el servidor Web para verificar si hay alguna actualización.

var fcf = Ti.Filesystem.getFile(
    Ti.Filesystem.applicationDataDirectory,myapp.dbu.cf);

// if there is not a configuration file 
// in the application directory     

if (!fcf.exists()){
   // It's the first time we need to update 
   // the database and no network connection 
   var alertDialog = Titanium.UI.createAlertDialog({
       title: 'WARNING!',
       message: 'You need an internet connection'+ 
                'to update your application data!',
       buttonNames: ['OK']
       });
   // Show alert dialog
      alertDialog.show();
  // Close application because 
  // there is not information or data to process
      myapp.dbu.winx.close();
}

Si no hay conexión a Internet busca si hay un archivo de configuración local en nuestro smartphone. Si no existe, es la primera vez que se realiza la actualización por lo que terminamos con un mensaje de error ya que no es posible actualizar nuestra aplicación.

if (myapp.dbu.updatecb != null) {
     myapp.dbu.updatecb();
 }


Si a pesar de que no hay conexión, ya teníamos una actualización previa, llama a la función updatecb() para que la aplicación acceda a la base de datos.

Creando la aplicación demo

Creamos una aplicación en Titanium Mobile y añadimos la librería updatedb.js a la carpeta Android en Recursos. A continuación, borramos el contenido de app.js y añadimos lo siguiente:

// Background color
Titanium.UI.setBackgroundColor('#000');

// Global namespace
var myapp = {};

// Application main windows
var win1 = Titanium.UI.createWindow({
    title:'DemoDB',
    backgroundColor:'#fff',
    exitOnClose: true
});


Lo primero establece el color de fondo de la ventana de aplicación a negro. Luego declaramos el espacio de nombres global y creamos una ventana a la que pondremos el título ‘DemoDB’ con color de fondo blanco y que cuando se cierre termine la ejecución de la aplicación.

Luego escribimos la función que va acceder a nuestros datos una vez que termine la actualización:

// Function to list database content
var showdatabase = function()
{  
   // Open database 
   var db = Ti.Database.open('bestres.sqlite3');
   // Execute a query to get a recordset
   var restaurants = 
   db.execute('select name,area,style from restaurants');
   var s = "";
   // while there are records in the recordset 
   while (restaurants.isValidRow()){
     // Get the fields content     
     s += "NAME= "   + restaurants.fieldByName("name") + 
     ",AREA= "  + restaurants.fieldByName("area") +
     ",STYLE= " + restaurants.fieldByName("style") +  ";";
     // Navigate to the next record     
     restaurants.next();
   }
   // Close the recordset
   restaurants.close();
   // Show the records content 
   alert("DATABASE CONTENT => " + s);
}


La función abre la base de datos local sqlite3 local llamada besares.sqlite3 y ejecuta una consulta que devuelve el nombre, area y estilo de los restaurantes almacenados. Luego realiza un bucle mientras se reciban filas de datos y compone una cadena de caracteres con la información, cierra la conexión y muestra la cadena de caracteres formada en una ventana de alerta (popup window).

En este momento podríamos utilizar el resultado de la consulta para rellenar una lista o un grid de nuestra aplicación con los datos actualizados.

Por último añadimos el siguiente código:

// Including library 
Ti.include('updatedb.js');

// Configuring database access
myapp.dbu.url      = 'http://ayalawilson.com/apps/demodb/';
myapp.dbu.db       = 'bestres.sqlite3';
myapp.dbu.cf       = 'bestrescf';
myapp.dbu.debug    = true;
myapp.dbu.updatecb = showdatabase;
myapp.dbu.winx     = win1;

// Updating database
myapp.dbu.updatedb();

// On resume event show database
Ti.App.addEventListener('resume', function() {
      showdatabase();
});

// Open the application main window
win1.open();


Incluimos la librería updatedb.js y configuramos:
  • La url de la carpeta en el servidor Web donde se encuentra la base de datos
  • El nombre de la base de datos
  • El nombre del archivo de configuración que contiene la fecha de actualización
  • Ponemos a debug en true para ver mensajes de depuración
  • Indicamos que el updatecb (Update Callback) será la función showdatabase() que hemos creado previamente
  • Indicamos que la ventana de la aplicación será win1
A continuación llamamos a la función que actualiza la base de datos e indicamos un par de cosas más:
  • Añadimos al evento ‘resume’ (cuando pase de estar minimizada a tener el foco de ejecución) ejecute la función showdatabase() para mostrarnos los datos
  • Abrimos la ventana principal de la aplicación para comenzar su ejecución

Como actualizar la base de datos remota en el servidor
  • Sustituimos el archivo de la base de datos remota
  • Actualizamos el archivo de configuración con la fecha actual
Como se realiza la actualización local

Los terminales móviles cuando arranca la aplicación van al servidor Web e inspeccionan la fecha del archivo de configuración remoto. Si la fecha remota es mayor que la fecha de configuración local de la última actualización, se actualiza la base de datos local (borra la base de datos local y descarga la base de datos remota) en todos los terminales.


Si no hay conexión a Internet en el momento que arranca la aplicación pueden ocurrir dos cosas:
  • Que exista la base de datos local (descargada en otro momento). En ese caso, la aplicación utiliza los datos locales ya descargados
  • Que no exista la base de datos local (la aplicación nunca se ha iniciado). En esta caso nos presenta un mensaje de error y termina
Terminales probados
  • Apple iPhone 4S
  • Samsung Galaxy SII con Android "Jelly Bean" 4.03
Recomendaciones finales

Este escenario de descarga de la base de datos local desde un servidor remoto funciona muy bien para:
  • Aplicaciones que necesitan operar con bases de datos en modo desconectado (offline), lo que permite que un usuario puede consultar la información deseada viajando por el metro o en el campo o en la carretera o en zonas de difícil o ninguna cobertura
  • Bases de datos relativamente de pequeño tamaño para no consumir mucho ancho de banda con las descargas
  • Bases de datos de solo lectura donde los usuarios solo consumen información, pero no aportan nada (ni comentarios, ni ratings, etc.)
  • Actualizaciones poco frecuentes (los mejores restaurantes de una ciudad no cambian todas las semanas)
  • La base de datos, al ser el núcleo de la información y no estar embebida en una carpeta de recursos de nuestra aplicación, permite que esta pueda actualizarse si tener que actualizar la aplicación completa

El código del proyecto

El proyecto está alojado en Google Code en http://code.google.com/p/local-database-updates-from-remote-http-server/. Sois totalmente libres de modificarlo y adaptarlo a vuestro gusto y necesidades.



Ubuntu Server - Administración de paquetes con aptitude

Introducción

En este artículo vamos a ver como administrar actualizaciones de paquetes en nuestro Ubuntu Server utilizando la herramienta aptitude. En un artículo anterior vimos como realizar actualizaciones en nuestro Ubuntu Server.

La herramienta aptitude no es más que una interfaz de APT o Advanced Packaging Tool (Herramienta de Empaquetado Avanzada) del sistema operativo Ubuntu. Es apropiada para tareas de administración de paquetes en servidores sin interfaz gráfica de usuario.













Si ejecutamos aptitude sin opciones, nos mostrará una interfaz con menús y diferentes opciones desde donde podemos administrar las siguientes categorías de paquetes:

  • Actualizaciones de seguridad. Paquetes que reciben actualizaciones de seguridad desde el repositorio security.ubuntu.com
  • Paquetes actualizables. Paquetes que tienen una nueva versión disponible en los repositorios
  • Nuevos Paquetes. Paquetes añadidos a Ubuntu desde la última vez que se borró la lista "Nuevos paquetes"
  • Paquetes instalados. Listado de paquetes instalados en el servidor
  • Paquetes no instalados. Listado de paquetes disponibles no instalados en el servidor
  • Paquetes virtuales. Estos paquetes no existen, solo son nombres que otros paquetes suelen requerir o proporcionan alguna funcionalidad
  • Tareas. Son grupos de paquetes que son instalados de forma conjunta para cumplir alguna funcionalidad, por ejemplo: dns-server, lamp-server o kubuntu-desktop












Muchas de las funciones más comunes a la hora de administrar los paquetes de Ubuntu Server están presentes en los menús de aptitude (instalación, eliminación y actualización pueden realizarse con tan solo presionar una tecla, típicamente letras minúsculas).

Primera columna de información cuando se muestra un paquete

  • i: paquete instalado
  • c: paquete no instalado pero cuya configuración permanece en el sistema
  • p: paquete purgado del sistema
  • v: paquete virtual
  • B: paquete roto
  • u: archivos desempacados, pero aún sin configurar
  • C:configuración fallida, por lo que el paquete requiere un arreglo (fix)
  • H:medio instalado. Fallo en la desinstalación que requiere un arreglo (fix)
Actualizar las listas de paquetes

Solo tenemos que presionar la tecla u en el menú principal y Ubuntu Server actualizará todas las listas de los repositorios.

Actualizar en conjunto todos los paquetes

Si queremos actualizar todos los paquetes de Ubuntu Server, primero presionamos u (minúscula) para actualizar las listas de paquetes y luego U (mayúscula) para marcar todos los paquetes que el sistema necesita actualizar.

















En este punto comenzará la descarga de todos los paquetes y luego comenzará el proceso de instalación. 

















El proceso de instalación y configuración de los paquetes descargados termina en una pantalla donde tenemos que dar ENTER para volver al menú principal de aptitude.

















Al volver al menú principal, veremos que habrán desaparecido las categorías de actualizaciones de seguridad y paquetes actualizables:

















Instalación o actualización selectiva de paquetes

Comenzamos por las actualizaciones se seguridad porque son los paquetes que tienen una alta criticidad para el funcionamiento y estabilidad de nuestro servidor. 

Vamos a actualizar dos paquetes del servidor Web Apache como ejemplo.

Lo primero es localizar el paquete usando las teclas de movimiento del cursor y la tecla ENTER. Una vez encima del paquete, lo seleccionamos con la tecla +.  

Los paquetes podemos encontrarlos dentro de Security Updates -> httpd - Webservers and their modules.

















Tenemos dos paquetes para actualizar: apache2.2-bin y libapache2-mod-php5.  Seleccionamos cada uno y con + quedan en una cola para actualizarse. La letra i en el margen izquierdo indica que el paquete está instalado en una versión anterior a la que vamos a actualizar.


















Una vez seleccionados para actualizarse aparece una u al lado de la i indicando que están seleccionados para ser actualizados.

















Una vez encolados para actualizarse presionamos la tecla g que nos lleva a una pantalla informativa intermedia. En ocasiones nos advierte de problemas de instalación de los paquetes por procesos de instalación/actualización incompletos o interrumpidos:

















Una vez en esta pantalla, si presionamos nuevamente g comienza el proceso verdadero de instalación, que consiste básicamente en descargar los paquetes actualizados, desinstalar los paquetes antiguos e instalar los nuevos.

















Una vez instalados los paquetes volvemos al menú principal de aptitude presionando ENTER.

















Eliminar un paquete

Vamos a desinstalar por ejemplo el paquete tomcat6-docs de nuestro servidor. El proceso es muy similar a la instalación de un paquete excepto que en vez de seleccionar los paquetes con + los seleccionamos con -.

















El paquete quedará marcado con una d al lado de la i de instalado. Si presionamos g nos lleva a una pantalla informativo y nuevamente g desinstala los paquetes seleccionados.

Salir de aptitude

Para salir de aptitude simplemente hay que presionar la tecla q en el menú principal y aptitude confirmará si realmente quiere abandonar o no.

















posted under , | 0 Comments

Arquitectura de Aplicaciones Web - Capa de Acceso a Datos


Introducción

La capa de acceso a datos contiene la lógica principal de acceso y persistencia de datos dentro de nuestra aplicación Web. Dado a que las aplicaciones empresariales están centradas en los datos (data centric), la capa de acceso a datos tiene una importancia crucial dentro de la arquitectura de nuestra aplicación Web. La capa de acceso a datos tiene que soportar no solo el almacenamiento de datos, sino la recuperación de información de formas complejas y la concurrencia de múltiples usuarios accediendo a la información.

Componentes de la capa de acceso a datos






















La capa de acceso a datos tiene dos tipos fundamentales de componentes:

  • Componentes de lógica de acceso a datos. Estos presentan una interfaz a la capa de negocio que abstrae de la forma en que se acceden a los datos almacenados, haciendo a la aplicación más fácil de configurar y mantener
  • Componentes utilitarios y auxiliares. Consisten en librerías especializadas o APIs que permiten acceder, manipular o transformar los datos dentro de los componentes de de lógica de acceso a datos. Por lo general son suministrados por el fabricante del gestor de base de datos (Oracle, IBM, etc.)
 Factores a considerar al desarrollar la capa de acceso a datos

  • Cree un diseño general de su capa de acceso a datos

    1. Identifique los requerimientos de las fuentes de datos (data sources)
    2. Determine el enfoque de acceso a los datos
    3. Elija como mapear estructuras de datos a los resultados de las fuentes de datos (data sources)
    4. Determine como conectarse a las fuentes de datos
    5. Elija la estrategia para tratar errores de conexión con las fuentes de datos

  • Diseñe sus componentes de acceso a datos

    1. Enumere las fuentes de datos a las que va a acceder
    2. Decida el método de acceso para cada fuente de datos
    3. Determine que componentes auxiliares o librerías son necesarios para facilitar el acceso el acceso a los datos así como las tareas de desarrollo y mantenimiento
    4. Estudie si puede aplicar patrones de diseño en el acceso a los datos (Table Data Gateway, Query Object, Repository, etc.)

  • Diseñe sus componentes auxiliares

    1. Identifique que funcionalidades pueden moverse fuera de los componentes de acceso a datos y crear un componente auxiliar para su reutilización
    2. Busque librerías de componentes auxiliares disponibles
    3. Considere componentes auxiliares para solucionar problemas como conexiones, autenticación, monitorización o tratamiento de excepciones
    4. Considere añadir logging a sus componentes auxiliares
 Consideraciones de diseño de la capa de acceso a datos

  • Seleccione la tecnología adecuada de acceso a datos. La tecnología de acceso a datos depende del tipo y volumen de los datos que necesitamos. Determinadas tecnologías son mejores en determinados escenarios. Por ejemplo, la recuperación de miles de registros por una única clave y si no hay necesidad de consultas complejas, podría llevarnos a utilizar un gestor de base de datos NOSQL en vez de un gestor SQL relacional clásico.
  • Utilice la abstracción para implementar componentes de acceso a datos débilmente acoplados al sistema de gestión de base de datos. Esto nos permite no solo desarrollar cómodamente y mantener nuestra capa de acceso a datos, sino incluso migrar todos los datos de un gestor a otro con el mínimo o ningún impacto en nuestra aplicación Web
  • Considere la mapear los datos obtenidos en objetos o estructuras de datos que son más simples de procesar en la capa de negocio
  • Encapsule todas las funcionalidades de acceso a bases de datos dentro de la capa de acceso a datos. Esta capa tiene que ocultar a la capa de negocio todo lo relacionado con conexiones, mapeos y transformaciones básicas de datos, generar consultas, etc.
  • Decida como manejar las conexiones. Como regla, la capa de acceso a datos tiene que manejar todas las conexiones a todas las fuentes de datos requeridas por la aplicación. Estudie como almacenar y proteger acorde a sus requerimientos de seguridad, la información que describe a estas conexiones.
  • Determine como tratar las excepciones de datos. La capa de acceso a datos debe capturar todas las excepciones relacionadas con las fuentes de datos y las operaciones CRUD (Create, Read, Update & Delete – Crear, Leer, Actualizar y Borrar) relacionadas con la base de datos. Las excepciones producidas por los datos solo deben pasarse a la capa de negocio si afectan la funcionalidad o la respuesta de usuario de la aplicación
  • Considere los riesgos de seguridad. La capa de acceso a datos debe de protegerse contra mecanismos de ataque que traten de borrar, corromper, alterar los datos o tomar control de la fuente de datos.
  • Reducir el tráfico de datos siempre que sea posible.
  • Considere el desempeño y la escalabilidad de la base de datos. Estudie los límites de acceso a datos de su aplicación. Realice pruebas de estrés y pruebas de carga que permitan encontrar esos límites acorde a las capacidades del entorno de Producción de su instalación. Recuerde que lo que en un entorno de test o de desarrollo es factible en términos de concurrencia, volumen de datos o respuesta de usuario no tiene nada que ver en un entorno de Internet con diferentes conexiones a diferentes velocidades, cientos o miles de usuario accediendo al mismo tiempo y miles de MB o GB transfiriéndose entre los servidores y los clientes en navegador que ejecutan nuestra aplicación
 Problemas comunes en el diseño de la capa de acceso a datos

Categoría
Problemas comunes
BLOB
  • Almacenamiento incorrecto de objetos binarios de gran tamaño como videos, fotos o archivos de datos en la base de datos en vez de en el sistema de archivos
  • Uso incorrecto del tipo BLOB en la base de datos
  • Búsqueda y manipulación de datos BLOB
Ejecución por lotes
  • Fallos al utilizar la ejecución por lotes para reducir el tráfico en la base de datos
  • Tratamiento de los bloqueos cuando se ejecutan procesos por lotes durante mucho tiempo
  • Fallo al elegir las ventanas horarias para tratar la base de datos con procesos por lotes
Conexiones
  • Configuración incorrecta del pool de conexiones
  • Fallos a la hora de manejar timeouts de conexiones y desconexiones
  • Ejecutar transacciones que abren múltiples conexiones
  • Mantener las conexiones abiertas durante períodos de tiempo excesivos
Formato de datos
  • Elección del formato incorrecto para los datos
  • Error al elegir el tipo de serialización
  • No mapear objetos contra las tablas del gestor de base de datos
Tratamiento de excepciones/ errores
  • No tratar las excepciones de datos
  • Fallo al no grabar en el log las excepciones críticas de acceso a datos
Consultas
  • Usar concatenación de cadenas a la hora de construir consultas
  • Mezclar las consultas con la lógica de negocio
  • No optimizar la base de datos para ejecutar consultas (no crear por ejemplo los índices necesarios o acceder por columnas que no son índice)
Procedimientos almacenados
  • No pasar correctamente los parámetros a los procedimientos almacenados
  • Implementar lógica de negocio en procedimientos almacenados
  • No considerar el impacto de sentencias SQL dinámicas en cuanto a rendimiento, seguridad y mantenimiento de la aplicación
Transacciones
  • Usar el nivel correcto de aislamiento
  • Utilizar bloqueos exclusivos que pueden provocar contención y dead-locks
  • Permitir que transacciones de larga duración bloqueen el acceso a los datos
Validación
  • Fallo al no validar los datos contra los tipos de campo
  • No tratar valores tipo NULL
  • No filtrar caracteres inválidos
XML
  • No considerar como tratar datos XML muy grandes
  • Fallo al validar entradas XML utilizando esquemas

posted under | 1 Comments

Arquitectura de Aplicaciones Web - Capa de Negocio


Introducción

La capa de negocio contiene la lógica principal de procesamiento de datos dentro de nuestra aplicación Web. Se comunica con la capa de presentación para obtener las entradas del usuario y presentar la información resultante, así como la capa de acceso a datos o directamente con servicios para realizar sus operaciones.

Componentes de la capa de negocio

























  • Componentes de negocio. Encapsulan las reglas de negocio o la forma en que los datos adquiridos desde la capa de presentación deben ser manipulados o transformados acorde al problema que tenemos que resolver. Estos componentes pueden cambiar o evolucionar con los requerimientos de negocio.
  • Entidades de negocio. Se utilizan para pasar o intercambiar datos entre componentes de negocio. Ejemplos típicos pueden ser las facturas, productos, contratos o clientes. Internamente están formados por estructuras de datos o clases de lenguajes orientados a objetos serializables.
  • Flujo de trabajo. Muchos procesos de negocio son tratados como un conjunto de pasos dependientes unos de otros que deben ejecutarse coordinados y en un orden determinado. Un ejemplo clásico es la aprobación de un contrato que implica la aprobación de los términos y condiciones así como las firmas de los intervinientes. En muchas ocasiones estos flujos de trabajo son procesos de negocio de múltiples pasos que requieren intervención del usuario y por lo tanto pueden ser de larga duración.
  • Fachada de aplicación. Una fachada de aplicación combina múltiples operaciones de negocio dentro de un único mensaje. Existen varias formas de enviar este mensaje desde una capa de presentación para que las operaciones de negocio puedan ser tratadas. Este es un componente opcional que proporciona otra facilidad de proceso a nuestra capa de negocio

 Factores a considerar al desarrollar la capa de negocio
  
  • Crear un diseño general de la capa de negocio

    1. Identificar los consumidores de la capa de negocio
    2. Determinar como se va a exponer la capa de negocio
    3. Determinar los requerimientos de seguridad de la capa de negocio
    4. Determinar los requerimientos de validación de la capa de negocio
    5. Determinar los requerimientos de caché de la capa de negocio
    6. Determinar la estrategia de tratamiento de excepciones de la capa de negocio

  • Diseñar los componentes de negocio

    1. Identificar los componentes de negocio que la aplicación va a utilizar
    2. Determinar las interacciones, acoplamiento y ubicación de los componentes de negocio
    3. Seleccionar el soporte transaccional adecuado
    4. Identificar como se van a tratar las reglas de negocio
    5. Identificar los patrones que se ajusten a los requerimientos de negocio

  • Diseñar las entidades de negocio

    1. Identificar los formatos de datos comunes de las entidades de negocio
    2. Seleccionar el formato de datos adecuado
    3. Seleccionar el diseño correcto de la entidad de negocio
    4. Seleccionar el tipo de serialización que vamos a necesitar

  • Diseñar los componentes de flujos de trabajo

    1. Identificar los escenarios de uso de flujos de trabajo
    2. Determinar cuantas reglas van a ser tratadas
    3. Determinar como van a ser tratadas las reglas
    4. Seleccionar una solución de flujo de trabajo para nuestra aplicación
    5. Crear componentes de negocio que soporten flujos de trabajo
  
Consideraciones de diseño de la capa de negocio

  • Decidir cuantas capas de negocio vamos a tener en nuestra aplicación Web. El uso de varias capas de negocio simplifica el mantenimiento de nuestra aplicación. Solo modificamos o evolucionamos la capa de negocio que sea necesario y no toda la capa de negocio lo cuál tendría un impacto mucho mayor
  • Identificar las responsabilidades de nuestra capa de negocio.  Debemos crear una capa de negocio para procesar reglas de negocio complejas, transformaciones de datos y realizar validaciones.
  • No mezclar diferentes tipos de componentes en la capa de negocio. Una de las misiones fundamentales de la capa de negocio es desacoplar la lógica de negocio de la capa de presentación y de la capa de acceso a datos
  •  Reutilizar lógica de negocio común. Otra de las misiones fundamentales de la capa de negocio es la de crear en un espacio común, lógica de negocio que pueda ser reutilizable, simplificando el mantenimiento y reduciendo el tamaño de nuestra aplicación Web
  • Identificar los consumidores de la capa de negocio. Esto nos va a ayudar a determinar como vamos a exponer nuestra capa de negocio (como otras capas de la aplicación van a interactuar con ella). Por ejemplo, si una aplicación externa va a interactuar con la capa de negocio, deberíamos exponerla como un servicio
  • Reducir el tráfico (idas y vueltas) cuando accedemos a una capa de negocios remota. Esto de consigue con el uso de una interfaz basada en mensajes y con la implementación de una fachada de aplicación en nuestra capa de negocio. De esta forma con un solo mensaje podrían realizarse varias operaciones, en vez de realizar múltiples llamadas a diferentes métodos u operaciones de un servicio
  • Evite al máximo el acoplamiento con la capa de presentación. Considere el uso interfaces basadas en mensajes, entre la capa de presentación y la de negocio. En la propia capa de negocio, utilice interfaces de objetos públicas, definiciones comunes de interfaces, clases abstractas o mensajes.
 Problemas comunes en el diseño de la capa de negocios

A continuación se enumeran un conjunto de problemas comunes que se presentan a la hora de diseñar la capa de negocio de una aplicación Web y que deben ser revisados por los arquitectos y los desarrolladores.

Categoría
Problemas comunes
Cache
  • Guardar en cache datos que no se van a reutilizar
  • Guardar datos sensibles sin encriptar
  • Selección incorrecta del almacenamiento para caché
  • Selección de un mecanismo de caché incorrecto cuando la aplicación está desplegada en una granja de servidores Web
  • Asumir que un dato está en caché cuando realmente no lo está
  • Almacenar grandes cantidades de datos en caché
Autenticación
  • Aplicar autenticación a la capa de negocios cuando no lo requiere
  • Diseñar un mecanismo de autenticación personalizado (siempre que podamos deberíamos basarnos en estándares)
  • No utilizar mecanismos de single sign-on cuando lo requiera
Autorización
  • Granularidad incorrecta para los roles (alguien hace más de lo que debe hacer o menos de lo que debe hacer)
  • Uso de delegación o impersonación (hacemos algo identificándonos como otro usuario) cuando no hace falta
  • Mezclar el código de autorización con la propia lógica de negocio
Componentes de negocio
  • Mezclar lógica de negocio con lógica de acceso a datos
  • No considerar el uso de interfaces basadas en mensaje para exponer componentes de negocio
Entidades de negocio
  • Uso de un dominio de negocio inapropiado para modelar una entidad
  • Selección de formatos de datos incorrectos
  • No considerar los requerimientos de serialización
Acoplamiento y cohesión
  • Fuerte acoplamiento entre capas
  • Falta de una separación clara de responsabilidades en la capa de negocio
  • Fallo al utilizar una interfaz basada en mensajes entre capas de la aplicación Web
Concurrencia y transacciones
  • No seleccionar el modelo correcto de concurrencia de datos
  • Permitir que transacciones de larga duración bloqueen los datos
Acceso a datos
  • Acceso a la base de datos directamente desde la capa de negocio
  • Mezclar lógica de acceso a datos con lógica de negocio dentro de componentes de negocio
Tratamiento de excepciones/errores
  • Mostrar al usuario datos sensibles como parte de mensajes de error
  • No hacer log detallados cuando se producen excepciones
Logging e Instrumentación
  • Fallo al no instrumentar correctamente los componentes de negocio
  • Fallo al no registrar en el log los problemas o errores de componentes críticos de sistema y de negocio
  • No eliminar fallos del sistema de log
Validación
  • Asumir que los datos están validados correctamente en la capa de presentación
  • Fallo en el tratamiento de errores de validación
  • No identificar las reglas de negocio apropiadas para las validaciones
  • No reutilizar la lógica de validación
  • No validar todos los aspectos de un parámetro tales como rango, tipo y formato
Interfaz del servicio
  • Dividir la interfaz de un servicio
  • Implementar reglas de negocio en la interfaz de un servicio
  • Fallo al no considerar lo estándares para intercambiar información que hacen al servicio interoperable
Flujos de trabajo
  • Selección incorrecta de patrones de flujo de trabajo
  • No considerar como tratar errores y excepciones en todos los estados del flujo
  • Seleccionar un tecnología incorrecta de flujo de trabajo

posted under | 3 Comments

Arquitectura de Aplicaciones Web - Capa de Presentación

Introducción


La capa de presentación esta formada por un conjunto de componentes que implementan la interfaz de nuestra aplicación, mostrando información y manejando las interacciones del usuario.

La base de la interfaz de usuario de una aplicación Web es el lenguaje de marcado de hipertextos (HTML o Hypertext Markup Language). Este lenguaje, derivado del XML, permite mostrar texto, imágenes, vídeos y otras formas de interacción con el usuario desde un programa denominado navegador Web (Web browser). El navegador Web se encarga de interpretar este lenguaje descargado desde el servidor Web y mostrarlo en la pantalla del ordenador de una forma coherente, funcional y atractiva para los usuarios.

Componentes de la capa de presentación






















Los componentes que forman la capa de presentación se pueden clasificar en dos grandes grupos:

  • Componentes de presentación: Componentes de la interfaz que permiten a los usuarios interactuar con la aplicación Web. Renderizan (dibujan) y formatean la información que se quiere presentar así como capturan y validan las entradas de datos. Ejemplos clásicos son los botones, las etiquetas, los hipervínculos, los cuadros de texto, las tablas, etc. La mayoría de estos componentes vienen incluidos dentro del propio lenguaje HTML y otros se implementan en lenguajes de scripting para el navegador como Javascript.
  • Componentes de proceso. Los componentes de proceso sincronizan y orquestan interacciones de usuario complejas. Estos componentes por lo general se implantan utilizando un Framework de JavaScript como Sencha o jQuery y pueden contener patrones de interacción embebidos (como el vista controlador) que simplifiquen el desarrollo y mantenimiento de interacciones complicadas por parte del usuario.

Factores a considerar al desarrollar la capa de presentación

  • Determinar como se van a presentar los datos. Seleccione el formato de su capa de presentación y decida como presentar los datos en su interfaz de usuario (en una columna, en dos columnas, con banners, con galerías de imágenes, etc.)
  • Elija una estrategia de validación de datos. Apóyese en las facilidades que ofrecen tanto el HTML como JavaScript para proteger su aplicación Web de entradas de datos no deseadas
  • Determine su estrategia de lógica de negocio. Teniendo claro que es lógica de negocio o proceso de datos y que es presentación de datos, podemos desacoplar (separar) las capas
  • Establezca una estrategia de comunicación con otras capas. Si su aplicación tiene una arquitectura multicapas, elija como la capa de presentación se va a comunicar con la capa de negocios o con la capa de datos. Un patrón o modelo vista controlador puede simplificar este diseño.

Consideraciones de diseño de la capa de presentación

  • Utilice patrones relevantes en el diseño de la capa de presentación. Los patrones de diseño simplifican la implementación y mantenimiento de la capa de presentación y aportan la robustez de soluciones probadas y de éxito en la industria
  • Diseñe siempre separando entre componentes de presentación y componentes de proceso. Cree componentes para renderizar y mostrar los datos y cree componentes para orquestar y sincronizar las interacciones complejas del usuario
  • Considere las buenas prácticas en el diseño de interfaces de usuario (Human Interface guidelines). Aplique y ajuste estas prácticas generales a como se realizan en su organización e incluso en su propio país. No es lo mismo una página en chino mandarían que una página en alemán o en árabe. La información se lee de forma diferente, propia del lenguaje en que la estamos presentando. Un alemán leerá como todos los occidentales de izquierda a derecha, mientras que un árabe lo hará al revés. Considere los logotipos, eslóganes y colores corporativos propios de su organización, así como los colores adecuados para el texto y los controles en dependencia de la frecuencia de uso y destino de la aplicación Web a crear. No son los mismos colores ni imágenes los de una página Web para un casino o venta de juegos de PlayStation que los de Wikipedia, por ejemplo, donde quizás tenemos que pasar horas consultando información.
  • Apóyese en encuestas, cuestionarios y entrevistas para conocer el tipo de presentación que el usuario de negocio demanda y ajuste el diseño lo más posible a sus requerimientos, necesidades y gustos
 Problemas comunes en el diseño de la capa de presentación

A continuación se enumeran un conjunto de problemas comunes que se presentan a la hora de diseñar la capa de presentación de una aplicación Web y que deben ser revisados por los arquitectos y los desarrolladores.

Categoría
Problemas comunes
Cache
  • Guardar en cache datos que no se van a reutilizar
  • Guardar datos sensibles sin encriptar
  • Selección incorrecta del almacenamiento para caché
  • Selección de un mecanismo de caché incorrecto cuando la aplicación está desplegada en una granja de servidores Web
  • Asumir que un dato está en caché cuando realmente no lo está
Composición de la interfaz Web
  • No considerar el uso de patrones de diseño y frameworks que soporten vistas y páginas dinámicas en tiempo de ejecución
  • Uso de componentes que tengan dependencias de servicios o clases auxiliares
  • Fallo al no tratar correctamente los eventos entre componentes (patrón de publicación/suscripción)
  • Fallo al no desacoplar correctamente los módulos que conforman la aplicación
Tratamiento de excepciones/errores
  • Fallo al no tratar excepciones no manejadas
  • Fallo al eliminar recursos o el estado de la aplicación después de una excepción
  • Mostrar información sensible al usuario como parte de un mensaje de error
  • Uso de excepciones personalizadas cuando no son necesarias
  • Captura de excepciones que no vamos a tratar
Entrada de datos
  • Fallo al no diseñar una entrada de datos intuitiva
  • Fallo al implementar una entrada de datos muy compleja en una misma página
  • Fallo al diseñar para accesibilidad
  • Fallo al diseñar para diferentes pantallas y resoluciones (pueden no mostrarse controles)
  • Fallo al diseñar para diferentes tipos de pantallas y dispositivos (pantallas táctiles, lápiz o ratón)
Disposición de componentes en la página
  • Utilizar una disposición de elementos inapropiada para una página Web
  • Fallo al utilizar componentes y tecnologías
  • Implementar una interfaz inapropiada para un flujo de trabajo (workflow)
  • Fallo al soportar localización
  • Fallo al soportar globalización
Navegación
  • Navegación inconsistente
  • Lógica duplicada a la hora de tratar eventos de navegación
  • Fallo al manejar estado en un asistente (wizard)
Tratamiento de peticiones de usuario
  • Bloquear la interfaz de usuario durante largos períodos de tiempo
  • Mezclar lógica de proceso con lógica de presentación
  • Selección de un patrón incorrecto a la hora de tratar las peticiones de usuario
Experiencia de usuario
  • Mostrar mensajes al usuario que no le ayudan con el problema que tiene
  • Falta de respuesta o feedback al usuario cuando ejecuta una acción
  • Interfaces de usuario muy complejas
  • Falta de personalización de la interfaz de usuario
  • Diseño de una interfaz ineficiente
Componentes de presentación
  • Crear componentes a mediad que no son necesarios
  • Fallo al mantener el estado en un patrón vista controlador
  • Selección inadecuada de componentes de la capa de presentación
Componentes de proceso
  • Implementar componentes de proceso innecesarios
  • Implementación de patrones de diseño incorrectos
  • Mezclar lógica de presentación con lógica de proceso de la interfaz de usuario
Validación
  • Error al validar las entradas de datos
  • Hay que validar en el servidor y en la capa de presentación, no solo en esta última
  • Fallo en el tratamiento de errores de validación
  • No identificar las reglas de negocio apropiadas para las validaciones
  • Fallo al no guardar en un log los errores de validación

posted under | 2 Comments
Entradas antiguas