Programar se aprende programando

Muchas veces hemos escuchado la frase “Programar se aprende programando” y personalmente creo que nada más lejos de la realidad. El programar es un juego de estrategia, como el ajedrez, es necesario estudiar. Porque cualquier persona puede mover las piezas de ajedrez pero jugar bien con fundamentos y conociendo las diferentes jugadas, muy pocos.

También es cierto que hay gente que nace con la capacidad de resolver problemas más fácilmente o aprender, pero de igual forma esto no justifica dejar de estudiar.

La experiencia es una gran herramienta del programador pero no la única.

Dejo una frase:
El inteligente aprende de sus errores; el sabio de los errores ajenos.

Frase

La persona inteligente se recupera de un fracaso, la que no lo es nunca se recupera de un éxito.

...Y tampoco del éxito de los demás.

Concurrencia en Erlang

Ya hemos hablado de este tema anteriormente:

http://emanuelpeg.blogspot.com/2010/09/concurrencia-en-erlang.html

Pero vamos a hacer un repaso, Erlang es un lenguaje de programación concurrente y un sistema de ejecución que incluye una máquina virtual y bibliotecas. Fue diseñado en la compañía Ericsson para realizar aplicaciones distribuidas, tolerantes a fallos, soft-real-time y de funcionamiento ininterrumpido. Proporciona el cambio en caliente de código de forma que éste se puede cambiar sin parar el sistema. Originalmente, Erlang era un lenguaje propietario de Ericsson, pero fue cedido como software de código abierto en 1998. La implementación de Ericsson es, principalmente interpretada pero también incluye un compilador HiPE (sólo soportado en algunas plataformas).

Entre los mayores logros de la plataforma podemos destacar que el chat de facebook y la base documental CouchDB.

Sin dudas una cosa que hace muy especial a Erlang es como maneja la concurrencia. Erlang no maneja la concurrencia con thread como nos tiene acostumbrado C, C++ o Java. Erlang soluciona la programación concurente mediante el modelo de actores. El modelo de actores es un modelo de concurrencia computacional que trata a los "actores" como los primitivos universal de la computación digital en paralelo: en respuesta a un mensaje que recibe, un actor puede tomar decisiones locales, crear más actores, envía más mensajes, y determinar cómo responder al siguiente mensaje recibido.

Parece complicado, pero no lo es. Con un ejemplo vamos a aclarar el tema. Supongamos que queremos hacer un actor saludador, pero no muy simpático; que salude solo a los conocidos; en erlang sería así:

-module(saludador).
-export([loop/0]).
loop() ->
receive
% Saluda a un conocido
"conocido" ->
io:format("Hola!! " ),
loop();
% Un desconocido, no lo saluda
_ ->
io:format(" ... " ),
loop()
end.

En la primera linea declaramos el modulo; luego importamos la función loop, con la cual definimos una función vacía y iteramos para siempre. Con receive recibimos un mensaje, es similar al swich, espera a recibir un mensaje y al recibir un mensaje ejecuta la estructura de codigo que corresponde al mensaje enviado y el “_” es como el default en c, c++ o java.

Primero compilamos:

1> c(saludador).
{ok,saludador}

Con spawn se puede generar un proceso, spawn nos devolverá el PID del proceso, que nos servirá para enviarle mensajes.

2> Pid = spawn(fun saludador:loop/0).
<0.38.0>

Ahora le vamos a mandar un mensaje:

4> Pid ! "conocido".
Hola!! "conocido"

5> Pid ! "Pepe".
... "Pepe"

Como era de esperar solo dice hola a los conocidos. Con el operador ! enviamos mensajes a un actor a partir de su Pid.

Este es un pequeño ejemplo de manejo de concurrencia en erlang. La forma en que maneja la concurrencia Scala fue inspirada en Erlang.

UrlRewrite

Una buena practica en publicar nuestras url en formato restful. Donde los datos de la consulta son parte de la url, esto mayor aceptación de parte del usuario y los buscadores. Por ejemplo mi sitio publica el profile de mis usuarios, si quiesiera publicar el profile de Juan su url sería algo así:

http://misitio.com/profile/juan

Esto es más amigable que esto:

http://misitio.com/profile?name=juan

Creo que en esto estamos todos deacuerdo.

Muchas veces en nuestros proyectos java no podemos hacer esto, dado que el framework web no lo permite. Para estos casos existe UrlRewrite, que permite reescribir nuestras url como queramos; ojo no solo se puede usar para url restful sino para cualquier cambio que quisiéramos hacer a nuestras urls.

Primero bajamos el jar o si usamos maven agregamos esto en el pom.xml

 
 
  org.tuckey
  urlrewritefilter
  3.1.0
 

Luego tenemos que agregar el siguiente filtro en el archivo web.xml :

 UrlRewriteFilter
 org.tuckey.web.filters.urlrewrite.UrlRewriteFilter


 UrlRewriteFilter
 /*

Ahora debemos escribir un archivo que contenga el cambio de las urls, el archivo se debe llamar urlrewrite.xml:

    
       /profile/([a-z]+)$
       /misitio/profile/index.htm?name=$1
    

En el archivo podemos ver que existe un from (la url que escribe el usuario) y un to(la url real de nuestro sistema) con $1 estamos indicando que el primer parámetro va a la variable de la url destino.

De esta foma armamos nuestras url para que queden más bonitas.

Dejo links:

http://www.tuckey.org/urlrewrite/
http://urlrewritefilter.googlecode.com/svn/trunk/src/doc/manual/3.2/index.html

Ceylon

Ceylon es el nuevo lenguaje que corre sobre jvm. Es un lenguaje hecho por Jboss/Red Hat ; el principal impulsor es ni más, ni menos Gavin King el creador de Hibernate.

Fue creado para correr sobre JVM, utiliza escritura estática e incluye soporte para funciones de alto orden, manteniendo un fuerte enfoque sobre la facilidad para aprenderlo y para leerlo. La principal premisa que se tuvo en cuenta para su diseño fue: Como sería Java si se escribiera hoy?

Prometo hacer un post decente de este lenguaje, por ahora solo dejo una serie de tutoriales que hizo su creador en su blog:

http://in.relation.to/tag/Introduction+to+Ceylon

Procedimientos almacenados y funciones en MySQL

Una de las grandes novedades de la versión 5 de MySQL es sin dudas la inclusión de soporte para procesos almacenados. A continuación veremos los fundamentos teóricos y este tema más algunos ejemplos básicos.

Si ya usamos bases de datos como Oracle, Interbase / Firebird, PostgreSQL, seguro escuchamos hablar de procedimientos almacenados. Sin embargo, en MySQL esto es toda una novedad y un paso enorme para que esta base de datos se convierta en un verdadero sistema gestor de bases de datos.

Ahora bien, ¿qué son en realidad los procedimientos almacenados? Luego de sumergirnos en este tema veremos que el nombre es plenamente identificatorio y casi explica lo que es un procedimiento almacenado.

Los procedimientos almacenados son un conjunto de instrucciones SQL más una serie de estructuras de control que nos permiten dotar de cierta lógica al procedimiento. Estos procedimientos están guardados en el servidor y pueden ser accedidos a través de llamadas, como veremos más adelante.

Para crear un procedimiento, MySQL nos ofrece la directiva CREATE PROCEDURE. Al crearlo éste es ligado o relacionado con la base de datos que se está usando, tal como cuando creamos una tabla, por ejemplo.

Para llamar a un procedimiento lo hacemos mediante la instrucción CALL. Desde un procedimiento podemos invocar a su vez a otros procedimientos o funciones.

Un procedimiento almacenado, al igual cualquiera de los procedimientos que podamos programar en nuestras aplicaciones utilizando cualquier lenguaje, tiene:

• Un nombre.
• Puede tener una lista de parámetros.
• Tiene un contenido (sección también llamada definición del procedimiento: aquí
• se especifica qué es lo que va a hacer y cómo).
• Ese contenido puede estar compuesto por instrucciones sql, estructuras de control, declaración de variables locales, control de errores, etcétera.

MySQL sigue la sintaxis SQL:2003 para procedimientos almacenados, que también usa IBM DB2.

En resumen, la sintaxis de un procedimiento almacenado es la siguiente:

  CREATE PROCEDURE nombre (parámetro)
      [características] definición

Puede haber más de un parámetro (se separan con comas) o puede no haber ninguno (en este caso deben seguir presentes los paréntesis, aunque no haya nada dentro).

Los parámetros tienen la siguiente estructura: modo nombre tipo

Donde:

• modo: es opcional y puede ser IN (el valor por defecto, son los parámetros que el procedimiento recibirá), OUT (son los parámetros que el procedimiento podrá modificar) INOUT (mezcla de los dos anteriores).
• nombre: es el nombre del parámetro.
• tipo: es cualquier tipo de dato de los provistos por MySQL.
• Dentro de características es posible incluir comentarios o definir si el procedimiento obtendrá los mismos resultados ante entradas iguales, entre otras cosas.
• definición: es el cuerpo del procedimiento y está compuesto por el procedimiento en sí: aquí se define qué hace, cómo lo hace y bajo qué circunstancias lo hace.

Así como existen los procedimientos, también existen las funciones. Para crear una función, MySQL nos ofrece la directiva CREATE FUNCTION.

La diferencia entre una función y un procedimiento es que la función devuelve valores. Estos valores pueden ser utilizados como argumentos para instrucciones SQL, tal como lo hacemos normalmente con otras funciones como son, por ejemplo, MAX() o COUNT().

Utilizar la cláusula RETURNS es obligatorio al momento de definir una función y sirve para especificar el tipo de dato que será devuelto (sólo el tipo de dato, no el dato).

Su sintaxis es:

  CREATE FUNCTION nombre (parámetro)
RETURNS tipo
[características] definición

Puede haber más de un parámetro (se separan con comas) o puede no haber ninguno (en este caso deben seguir presentes los paréntesis, aunque no haya nada dentro). Los parámetros tienen la siguiente estructura:nombre tipo

Donde:

• nombre: es el nombre del parámetro.
• tipo: es cualquier tipo de dato de los provistos por MySQL.
• Dentro de características es posible incluir comentarios o definir si la función devolverá los mismos resultados ante entradas iguales, entre otras cosas.
• definición: es el cuerpo del procedimiento y está compuesto por el procedimiento en sí: aquí se define qué hace, cómo lo hace y cuándo lo hace.

Para llamar a una función lo hacemos simplemente invocando su nombre, como se hace en muchos lenguajes de programación.

Desde una función podemos invocar a su vez a otras funciones o procedimientos.

  mysql> delimiter //
mysql> CREATE PROCEDURE procedimiento (IN cod INT)
     -> BEGIN
     ->    SELECT * FROM tabla WHERE cod_t = cod;
     -> END
     -> //
Query OK, 0 rows affected (0.00 sec)
mysql> delimiter ;
mysql> CALL procedimento(4);

En el código anterior lo primero que hacemos es fijar un delimitador. Al utilizar la línea de comandos de MySQL vimos que el delimitador por defecto es el punto y coma (;): en los procedimientos almacenados podemos definirlo nosotros.

Lo interesante de esto es que podemos escribir el delimitador anterior; sin que el procedimiento termine. Más adelante, en este mismo código volveremos al delimitador clásico. Luego creamos el procedimiento con la sintaxis vista anteriormente y ubicamos el contenido entre las palabras reservadas BEGIN y END.

El procedimiento recibe un parámetro para luego trabajar con él, por eso ese parámetro es de tipo IN. Definimos el parámetro como OUT cuando en él se va aguardar la salida del procedimiento. Si el parámetro hubiera sido de entrada y salida a la vez, sería de tipo denominado INOUT.

El procedimiento termina y es llamado luego mediante la siguiente instrucción:

  mysql> CALL procedimento(4);

Otro ejemplo:

  CREATE PROCEDURE procedimiento2 (IN a INTEGER)
BEGIN
DECLARE variable CHAR(20);
IF a > 10 THEN
SET variable = ‘mayor a 10’;
ELSE
SET variable = ‘menor o igual a 10’;
END IF;
INSERT INTO tabla VALUES (variable);
END

• El procedimiento recibe un parámetro llamado a que es de tipo entero.
• Se declara una variable para uso interno que se llama variable y es de tipo char.
• Se implementa una estructura de control y si a es mayor a 10 se asigna a variable un valor. Si no lo es se le asigna otro.
• Se utiliza el valor final de variable en una instrucción SQL.

Recordemos que para implementar el ultimo ejemplo se deberán usar nuevos delimitadores, como se vio anteriormente.

Observemos ahora un ejemplo de funciones:

  mysql> delimiter //
mysql> CREATE FUNCTION cuadrado (s SMALLINT) RETURNS SMALLINT
    -> RETURN s*s;
    -> //
Query OK, 0 rows affected (0.00 sec)
mysql> delimiter ;
mysql> SELECT cuadrado(2);

Otras bases de datos como PostgreSQL implementan procedimientos almacenados y brindan la posibilidad de programarlos utilizando lenguajes como PHP o Java.

En MySQL hay intenciones de implementar lo mismo y seguramente en las próximas versiones lo veremos, pero más importante que utilizar un lenguaje u otro es entender para qué podrían servirnos los procedimientos almacenados.

En definitiva hemos dado un recorrido por el mundo de la programación de procedimientos almacenados en MySQL. Es importante que se trata de un mundo que está en pleno desarrollo y que promete evolucionar.

Dejo Link:

http://dev.mysql.com/doc/refman/5.0/es/stored-procedures.html

Tipos de Tablas en MySQL

Cuando se trabaja con MySQL, existe la opción de variar el tipo de tabla después de creada (salvo con las tablas del sistema llamadas MySQL y test , que por defecto son MyISAM y no se recomienda modificarlas).

Para indicar el tipo de tabla al crearla usamos la siguiente sintaxis:

CREATE TABLE tabla1 (
campo1 INT(4) UNSIGNED,
campo2 VARCHAR(25) NOT NULL
) ENGINE=MYISAM;

Si se omite la opción ENGINE=... por defecto se crea una tabla MyISAM.

Importante: según MySQL, la opción TYPE (similar a ENGINE) es soportada hasta la versión 4.x de MySQL (dejará de usarse a partir de la 5). La opción ENGINE fue añadida en la versión 4.0.18 del lenguaje (para las series 4.x) y en la versión 4.1.2 (correspondiente a las versiones 4.1).

Si se intenta crear un tipo de tabla no disponible en nuestra versión, MySQL optará por crear una tabla tipo MyISAM.

A continuación, haremos una reseña de los tipos de tablas soportados.

ISAM

En un principio, el gestor de bases de datos MySQL empezó utilizando este tipo de tablas y, actualmente, se las considera en desuso. Entre sus desventajas figura el hecho de no poder transportar archivos entre máquinas con distinta arquitectura (tiene un formato diferente para cada arquitectura / sistema operativo, lo cual resulta más rápido, pero presenta el problema de la incompatibilidad) y el de no manejar archivos de tablas superiores a 4 GB.

Los índices se guardan en archivos .ISM y los datos, en archivos .ISD. MySQL recomienda actualizar este tipo de tablas hacia las de tipo MyISAM. Esto puede hacerse con la siguiente instrucción SQL:

ALTER TABLE nombre_de_la_tabla ENGINE = MYISAM;

MyISAM

Es el tipo de tabla por defecto en MySQL desde la versión 3.23 y está basada sobre las tablas ISAM, por supuesto que ofreciendo más opciones que éstas. Cuando se usan estas tablas, los datos se almacenan físicamente en dos archivos: uno que tiene la extensión .MYI (MYISAM INDEX), en donde se almacenan los índices, y otro .MYD (MYISAM DATA), donde se almacenan los datos.

Se encargan de proveer un almacenamiento independiente: esto significa que se pueden copiar tablas de una máquina a otra de distinta plataforma.

Si estamos trabajando con MySQL en forma local, normalmente, se podrá ver en el propio equipo que estos archivos se almacenan en una carpeta que tiene por nombre una base de datos (estas carpetas están en el directorio data dentro del directorio en donde se instaló MySQL, y allí hay una carpeta por cada base de datos). Esto vale también para otros tipos de tablas.

Además:
• Soportan archivos de gran tamaño (63 bits, archivos de tablas superiores a 4 GB)
en comparación con los que soportaban las ISAM.
• Están optimizadas para sistemas operativos de 64 bits.
• Posibilidad de indexar campos BLOB y TEXT.
• Se permiten valores NULL en columnas indexadas.
• Cada tabla guarda un registro que indica si fue cerrada correctamente o no, y al iniciar MySQL existe la opción de indicarle que se verifique ese registro, y se repare la tabla de ser necesario, de forma automática. Esto se logra iniciando MySQL con la opción:

--myisam-recover

Si se encontró un error, trata de repararlo de forma rápida ordenando los registros de la tabla. Si éste persiste, se vuelve a crear el archivo que contiene la tabla. Y si continúa existiendo, se intenta repararlo escribiendo los registros sin un ordenamiento.
• Inserts concurrentes (se pueden insertar varios registros al mismo tiempo).

MERGE

Este tipo de tabla es muy utilizada en los casos en que se precise tratar un número N de tablas MyISAM (de idéntica estructura y pertenecientes a la misma base de datos, de la que también deberá formar parte la tabla MERGE) como si fuera una sola.

Esto podría aplicarse si la tabla MyISAM original es de gran tamaño, y acceder a su contenido llevará una cantidad considerable de tiempo y recursos. Obviamente, estamos hablando de una tabla realmente muy grande.

Otras características:
• Sólo se pueden aplicar instrucciones SELECT, DELETE y UPDATE.
• La definición de la tabla se almacena en un archivo .FRM, y el listado de las tablas MyISAM, en un archivo .MRG (aquí hay en realidad un índice de los archivos .MYI usados. Ver tablas MYISAM).
• Permiten de alguna forma burlar el tamaño máximo de una tabla y el tamaño máximo de un archivo en un sistema operativo específico.
• Debemos saber que si queremos borrar una de las tablas MyISAM que forma parte de la tabla MERGE, no podremos hacerlo bajo el sistema operativo Windows, ya que éste no permite borrar archivos que estén abiertos, y la tabla, al formar parte de la tabla MERGE, se considera abierta. Por la misma razón se producen inconvenientes al aplicar instrucciones tales como DROP TABLE, ALTER TABLE, DELETE FROM sin WHERE, REPAIR TABLE, TRUNCATE TABLE, OPTIMIZE TABLE y ANALYZE TABLE. Una forma de solucionar esto es borrar el contenido de la tabla MERGE (aplicando la instrucción DELETE sin WHERE a una tabla MERGE, no se borra el contenido de las tablas MyISAM sino que se las quita del listado de componentes de la tabla MERGE). Así estas tablas se considerarán no abiertas.

Cuando se crea una tabla de este tipo hay que especificar (con la instrucción UNION) la lista de tablas asociadas. Veamos un ejemplo.

CREATE TABLE t1 (a INT AUTO_INCREMENT PRIMARY KEY, mensaje CHAR(20));
CREATE TABLE t2 (a INT AUTO_INCREMENT PRIMARY KEY, mensaje CHAR(20));

INSERT INTO t1 (mensaje) VALUES ("uno");
INSERT INTO t1 (mensaje) VALUES ("dos");
INSERT INTO t1 (mensaje) VALUES ("tres");
INSERT INTO t2 (mensaje) VALUES ("cuatro");
INSERT INTO t2 (mensaje) VALUES ("cinco");
INSERT INTO t2 (mensaje) VALUES ("seis");

CREATE TABLE total (
a INT AUTO_INCREMENT PRIMARY KEY,
mensaje CHAR(20)
)
ENGINE=MERGE UNION=(t1,t2) INSERT_METHOD=LAST;

SELECT * FROM total;

Devolvería algo como:

1 uno
2 dos
3 tres
1 cuatro
2 cinco
3 seis

El parámetro INSERT_METHOD especifica en qué tabla se realizarán los INSERTS; si en la primera de la lista (poniendo INSERT_METHOD=FIRST) o en la última (poniendo INSERT_METHOD=LAST). En nuestro caso la tabla t1 es la primera y t2 es la última.

HEAP

Este tipo de tablas tienen una particularidad que las hace diferentes del resto: son tablas en memoria, son temporales y desaparecen cuando el servidor se cierra.

Es importante saber que esto las hace realmente rápidas y que, a diferencia de una tabla TEMPORARY, que sólo puede ser accedida por el usuario que la crea, una tabla HEAP puede ser utilizada por diversas personas.

Algunas otras particularidades:
• No soportan columnas de tipo BLOB o TEXT.
• No soportan columnas de tipo AUTO_INCREMENT.
• No se permiten valores NULL en las columnas que han sido indexadas (antes de MySQL en la versión correspondiente a la 4.0.2).
• Siempre conviene especificar el número máximo de filas (MAX_ROWS) cuando se crea la tabla, para no usar toda la memoria disponible.

InnoDB

Debemos saber que estas tablas, al igual que las BerkeleyDB, son TST: este término significa Transactions Safe Tables, o tablas para transacciones seguras. Las tablas tipo TST son menos rápidas y ocupan más memoria, pero a cambio ofrecen mayor seguridad frente a fallos durante la consulta.

Además, las tablas InnoDB tienen las siguientes características:
• Proveen la posibilidad de transacciones seguras. ACID (Atomicidad; Consistencia; Separación, en inglés Isolation y Durabilidad).
• Recuperación ante fallos.
• Soporta FOREIGN KEY (Claves foráneas). Primera vez que se da esto en MySQL.
• Bloqueo a nivel de fila.
• Permite realizar copias de seguridad mientras la base está funcionando.
• Gran eficacia en el procesamiento de grandes volúmenes de información.
• No permite crear claves sobre columnas de tipo BLOB o TEXT.
• Una tabla no puede tener más de 1000 columnas.
• Al borrar todas las filas de una tabla las borra una por una –lo que produce problemas relacionados a la velocidad. Hasta ahora puede truncar tablas.

Fueron agregadas en la versión 4.0 de MySQL.

BerkeleyDB

Estas tablas pueden ser usadas independientemente de MySQL: están desarrolladas por otra empresa (Sleepycat) y el gestor de bases de datos MySQL ofrece una interfaz para trabajar con ellas como una posibilidad más.
• Soportan operaciones COMMIT y ROLLBACK.
• Es de tipo denominado TST (Transactions Safe Tables). Podemos ver tablas INNODB para obtener más información acerca de este tema.
• Normalmente, para instalarlas hay que buscar una versión de MySQL que incluya soporte para este tipo de tablas, y habilitar la opción al momento de la instalación (––with*berkeley–dboption).
• En el archivo en donde se guardan los datos también se guarda la ruta a ese mismo archivo, de modo que no es posible cambiar la base de directorio.

¿En qué casos usar cada una?

Como siempre, la respuesta depende de lo que tengamos que hacer. Las tablas que normalmente se usan hoy en día son las MyISAM, pero pronto (quizás muy pronto) se comenzarán a usar las INNODB, especialmente por la posibilidad de crear relaciones entre tablas (fundamental en el modelo relacional) y ofrecer mayores prestaciones respecto de la seguridad, además de las transacciones.

Las ISAM están prácticamente en desuso (incluso la empresa que desarrolla MySQL admite la posibilidad de que en su versión 5 ya no estén disponibles), y las demás tienen usos muy específicos e incluso compatibles con otros tipos: la clave está en estudiar los problemas que se necesita solucionar, y ver en cada caso qué conviene.

Envío de datos con PHP

En PHP es posible generar script para imitar el envío de datos a través de formularios que utilizan el método POST usando las cabeceras necesarias para que el navegador reconozca la petición. Veamos un ejemplo:

//Lleno los datos a enviar.
$contenido[] = “x=$x”;
$contenido[] = “y=$y”;
$contenido[] = “z=$z”;

$contenido = implode(“&”,$contenido);

$logitud = strlen($contenido);

$peticion .= “POST /pagina.php HTTP/1.1\r\n”;
$peticion .= “Host: xservidor.com\r\n”;
$peticion .= “Content-Type: application/x-www-form-urlencoded\r\n”;
$peticion .= “Content-Length: $logitud\r\n”;
$peticion .= “Connection close\r\n”;
$peticion .= “\r\n”;
$peticion .= $contenido;

if ($manejador = fsockopen(“servidor.com”, 80)) {

  fputs($manejador, $peticion);

  while (!feof($manejador)) {
     $respuesta .= fgets($manejador, 1024);
  }

  fclose($manejador);
}

Con este script podremos testear nuestros formularios o se podría usar para ingreso de datos masivos. Pero también para ataque a nuestro sitios por lo que deberíamos usar un captcha para prevenir estos ataques.

Autenticación en JSF

Como todos sabemos la seguridad se puede dividir en 3 aspectos:

• Autenticación: que el usuario sea realmente quien dice ser.
• Autorización: que el usuario pueda hacer solo lo que el tenga permiso de hacer.
• Seguridad de Datos: que el usuario vea los datos que el realmente puede ver.

No todas las aplicaciones necesitan todas estos aspectos, por ejemplo una aplicación menor de una intranet no necesariamente necesita la seguridad de datos.

Vamos a atacar la autenticación. Con JSF podemos autenticar a nuestros usuarios de diferentes maneras.

Una forma es por medio del contenedor, todos los contenedores web manejan el concepto de seguridad y la posibilidad de autenticar a un usuario. Muchas aplicaciones solo necesitan la autenticación; por lo tanto lo podemos hacer a nivel contenedor. Este provee tres formas: basic, form-based, y client certificate. Veamos un ejemplo de autenticación basic, agregando las siguientes lineas al web.xml :

 

 

   

 

 

   BASIC

   UserDatabase

 

 

La autenticación básica trajo con sigo el concepto de realm. Un realm es un objeto que representa al usuario y su autenticación. Realm no es un concepto estándar y se implementa de forma diferente en los contenedores. Por ejemplo en Apache Tomcat es un simple archivo xml:

Otra posible autenticación es basado en formularios, esta solución fue creada antes de JSF y no es recomendada si la autenticación debe estar integrada a la aplicación:

 FORM

 UserDatabase

 

   /faces/login.jsp

   /faces/loginError.jsp

 

Otra posibilidad es integrar el login a nuestra aplicación. Vamos a profundizar esta opción que es la más utilizada.

Lo que deberíamos hacer es una aplicación la cual no se pueda acceder a ninguna pagina sin antes logearse, y si alguien intenta acceder a la pagina esta lo redireccionara a la pagina de login. En el login el usuario podrá logearse y así poder realizar sus tareas.

El concepto de servler filter, implementado en la versión 2.3 de servlet y redefinido en 2.4 permite operar sobre una request antes que esta sea procesada. Esto nos permite chequear si el usuario esta logueado cuando quiere acceder a alguna pagina. Entonces declaremos nuestro filtro en el web.xml:

 Require that the user log in before accessing any page

   other than the entry pages 

 ForcedLoginFilter

 org.assembly.util.ForcedLoginFilter 







 ForcedLoginFilter

 *.jsp

 REQUEST

 FORWARD

Y la clase ForcedLoginFilter es la siguiente:

package org.assembly.util;



import java.io.IOException;

import java.util.Arrays;

import java.util.Iterator;



import javax.servlet.Filter;

import javax.servlet.FilterChain;

import javax.servlet.FilterConfig;

import javax.servlet.RequestDispatcher;

import javax.servlet.ServletException;

import javax.servlet.ServletRequest;

import javax.servlet.ServletResponse;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpSession;



public class ForcedLoginFilter implements Filter {

	private static final String LOGIN_JSP = "login.jsp";



	public ForcedLoginFilter() {

	}



	private static boolean checkLoginState(ServletRequest request,

			ServletResponse response) throws IOException, ServletException {

		boolean isLoggedIn = false;

		HttpSession session = ((HttpServletRequest) request).getSession(false);

		UserBean managedUserBean = null;

		// If there is a UserBean in the session, and it has

		// the isLoggedIn property set to true.

		if (null != session

				&& (null != (managedUserBean = (UserBean) session

						.getAttribute("UserBean")))) {

			if (managedUserBean.isIsLoggedIn()) {

				isLoggedIn = true;

			}

		}

		return isLoggedIn;

	}



	public void doFilter(ServletRequest request, ServletResponse response,

			FilterChain chain) throws IOException, ServletException {



		boolean isLoggedIn = checkLoginState(request, response);



		if (isRedirect((HttpServletRequest) request) && !isLoggedIn) {

			String loginURI = LOGIN_JSP;



			RequestDispatcher requestDispatcher = request

					.getRequestDispatcher(loginURI);



			// Force the login

			requestDispatcher.forward(request, response);

			return;

		} else {

			try {

				chain.doFilter(request, response);

			} catch (Throwable t) {

				// A production quality implementation will

				// deal with this exception.

			}

		}

	}



	private boolean isRedirect(HttpServletRequest request) {

		String requestURI = request.getRequestURI();



		return (!requestURI.contains(LOGIN_JSP));

	}



	@Override

	public void destroy() {

		// TODO Auto-generated method stub



	}



	@Override

	public void init(FilterConfig arg0) throws ServletException {

		// TODO Auto-generated method stub



	}

}

Las clases que son filtros deben implementar la interfaz Filter. En este caso lo que hace el filtro es verificar que existe el usuario en la session y si la url es redirecciónable, dado que si al ir a login redireccionamos se formara un bucle infinito.

El objeto UserBean es el encargado de representar un usuario.

package org.assembly.util;



public class UserBean {



	private String userName;

	

	private String userPassword;

	

	public UserBean(String userName, String userPassword) {

		this.userName = userName;

		this.userPassword = userPassword;

	}



	public boolean isIsLoggedIn() {

		return true;

	}



	public String getUserName() {

		return userName;

	}



	public void setUserName(String userName) {

		this.userName = userName;

	}



	public String getUserPassword() {

		return userPassword;

	}



	public void setUserPassword(String userPassword) {

		this.userPassword = userPassword;

	}

	

}

Entonces ahora debemos crear la pagina login.jsp que sera como la siguientes

<%@ page language="java" contentType="text/html; charset=UTF-8"

	pageEncoding="UTF-8"%>

<%@ taglib prefix="f" uri="http://java.sun.com/jsf/core"%>

<%@ taglib prefix="h" uri="http://java.sun.com/jsf/html"%>



< html>

	< head>

		< meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

		

		

		

		

		

	< /head>

	< body background="black">

	

		

			

				


					


					

					

					


					

			

					
						action="#{loginBean.validate}" />

			

					

				

			

		

		

	< /body>



< /html>

Y luego debemos crear el managed bean que sera como este:

package org.assembly.util.login;



import javax.faces.context.FacesContext;

import org.assembly.util.UserBean;



public class LoginBean {



	private String userName;



	private String userPassword;



	public String validate() {



		// Validar si la contraseña y pass son correctas.

		// si hay un error return null;



		UserBean user = new UserBean(userName, userPassword);



		FacesContext.getCurrentInstance().getExternalContext().getSessionMap()

				.put("UserBean", user);



		return "index";

	}



	public String getUserName() {

		return userName;

	}



	public void setUserName(String userName) {

		this.userName = userName;

	}



	public String getUserPassword() {

		return userPassword;

	}



	public void setUserPassword(String userPassword) {

		this.userPassword = userPassword;

	}



}

Luego debemos declarar en el face-config.xml nuestro bean y la url login.

        

		loginBean

		org.assembly.util.login.LoginBean

		request

	

...



        

	       login

	       /login.jsp

	

Este fue un pequeño ejemplo de login en jsf.

Pese al avance de los sistemas libres, el 78% de las computadoras usa Windows

Publico esta noticia de clarin, que la verdad no me gusta nada:

A pesar del avance del software libre, el Windows de Microsoft continuó dominando en 2010 el mundo de las computadoras con una cuota del 78,6% en el sector de los sistemas operativos, según el analista de mercado Gartner.

El porcentaje supera al de 2009, cuando Microsoft tenía un 77,9%. En total, el sistema operativo Windows permitió facturar a la compañía US$ 30.400 millones, lo que supone un incremento interanual del 7,8%.

Por su parte, Apple pudo elevar los aportes de sus sistemas operativos a la facturación total de 1,6 a 1,7 por ciento. Actualmente las computadoras Mac están experimentando un "boom", según Gartner, mientras que Microsoft se benefició del cambio del impopular Vista al nuevo Windows 7.

De acuerdo con Gartner, además de PCs y Mac, para su estudio tuvo también en cuenta las grandes computadoras corporativas, los llamados "servidores", donde IBM, HP o Oracle tienen mayor presencia. Entre los operadores de servidores el más popular resultó ser Linux.

Por que no cambiar a Linux?

Dejo link:

http://www.ieco.clarin.com/economia/Pese-sistemas-libres-computadoras-Windows_0_235200025.html

Encriptar password con MySQL

Quien no tuvo que encriptar una password antes de guardarla en la base de datos? Como sabrán es una muy buena práctica guardar las password encriptadas dado que esto permite minimizar los daños a nuestros usuarios en caso que que un intruso consiga la forma de consultar la base y a la vez permite que los administradores del sistema no tengan conocimiento de las mismas, ni forma de saberlas.

Cuando trabajamos con MySQL, podemos usar las funciones md5 o sha1. Para probarlas podemos hacerlo de la siguiente forma:

> select md5('Holass');

> select sha1('Holass');

Recordemos que los algoritmos de encriptación md5 y sha1 son los más usados.

Para insertas un usuario con su password encriptado usando md5 podremos hacer lo siguiente:

> insert into usuario (nombre, clave) values ('nombre', md5('password'));

y si queremos verificar el usuario:

> select * from usuario where nombre = 'nombre' and clave = md5('password');

Además MySQL trae su propia función para encriptar llamade password:

> select password('Holass');

Dejo links:

http://dev.mysql.com/doc/refman/5.1/en/password-hashing.html

http://dev.mysql.com/doc/refman/5.0/es/encryption-functions.html

Soy Yeta

Soy Yeta o debo ser lo, por que en este blog comente que el browser flock era el futuro de los browsers, o por lo menos era lo que pensaba. Hoy me llego un mail que flock se discontinuo, que el soporte para este browser cesara el 26 de Abril y me invita a migrar a otros browsers como firefox o chrome.

Voy a intentar no predecir el futuro de otros productos; simplemente para que no cierren.

NoSQL vs NewSQL

Antes de empezar vamos a definir que es NoSQL y NewSQL.

Nos dice la wikipedia: NoSQL es un término usado en informática para agrupar una serie de almacenes de datos no relacionales que no proporcionan garantías ACID. Normalmente no tienen esquemas fijos de tablas ni sentencias "join".

"NewSQL" es la forma abreviada que nos referimos a los diversos nuevos vendedores de base de datos de alto rendimiento. Anteriormente se referian a estos productos como “ScalableSQL” para diferenciarlos de los productos de bases de datos relacionales tradicionales. Dado que esto implica escalabilidad horizontal, que no es necesariamente una característica de todos los productos.

Y para aclarar, como NoSQL, NewSQL no debe ser tomado demasiado literalmente: lo nuevo acerca de los vendedores NewSQL es el vendedor, no el SQL.

Entonces, ¿quiénes serían considerados vendedores NewSQL? Al igual que NoSQL, NewSQL se utiliza para describir un grupo de empresas o productos, lo que tienen en común es el desarrollo de nuevos productos y servicios de base de datos relacionales, diseñados para llevar los beneficios del modelo relacional a arquitecturas distribuidas, o para mejorar el rendimiento de bases de datos relacionales en la medida en que la escalabilidad es una necesidad.

Para nombrar algunas productos/empresas NewSQL: Clustrix, GenieDB, ScalArc, Goleta, VoltDB, RethinkDB, ScaleDB, Akiban, CodeFutures, ScaleBase, Translattice y NimbusDB...

Estos nuevos productos NewSQL solapan su funcionalidad con el NoSQL, permitiendo gran escalabilidad sin perder el modelo relacional y algunos productos se confunden con los productos NoSQL, haciendo la linea muy delgada.

Cual es el futuro de las bases de dato? NewSQL le ganara el puesto que gano NoSQL?

EL tiempo lo dirá...

Dejo links:

http://www.readwriteweb.com/cloud/2011/04/the-newsql-movement.php

Publican Libro Gratuito de Scala

Es la primera edición de Programming in Scala, es buenisimo este aporte.

Dejo el link:

http://www.artima.com/pins1ed/

Seguridad con JEE

JEE y EJB proveen un conjunto de servicios que los desarrolladores pueden integrar de forma declarativa o programática. Estos servicios incluyen autorización y autenticación.

Autenticación e identificación

La autenticación es comprobar que el usuario sea quien dice ser. En un sistema EJB un usuario es asociado con una identidad segurizada, esta esta lista para ser usada por los EJB. Cuando un cliente invoca un método de un EJB, el servidor pasa la identidad del cliente con la invocación del método. Cuando el contenedor de EJB recibe la invocación valida la identidad del usuario y si este puede invocar el método invocado.

La especificación EJB no indica como se autentica. Aunque esta definido como la seguridad se propaga del cliente al servidor, no esta definido como el cliente obtiene la identidad y la credencial con una invocación EJB, tampoco define como el servidor guarda y obtiene las autenticaciones.

Cuando accedemos a un EJB muchas aplicaciones utilizan la JNDI API, por ejemplo podemos autenticar el acceso a un EJB de este modo:

properties.put(Context.SECURITY_PRINCIPAL, "username");
properties.put(Context.SECURITY_CREDENTIALS, "password");
Context ctx = new InitialContext(properties);
Object ref = jndiContext.lookup("SecureBean/remote");
SecureRemoteBusiness remote = (SecureRemoteBusiness)ref;

En el ejemplo, el usuario es autenticado con la conexión a el “JNDI InitialContext”

Autorización.

Como sabemos en las aplicaciones no todos somos iguales, cada usuario tiene un rol ante una aplicación por ejemplo “administrador”, “empleado”, etc. y cada rol puede hacer o no determinadas acciones, es decir tiene o no tiene permiso para.

En EJB existen diferentes tipos de granularidad de permisos, puede ser por usuario o por rol. Esto permite que la autenticación sea un proceso separado de la autorización.

Los roles son definidos de forma logica y pueden representar roles, grupos de usuarios, o cualquier otro sistema de identificación. Los roles del los EJB son mapeados a los usuarios y grupos reales cuando el bean es deployado.

La autorización esta bien definida en la especificación EJB. Se declaran los roles de forma programática y luego se indican los permisos a los beans por medio de anotaciones o declararlos en ejb-jar.xml

Vimos de forma teoría la seguridad en EJB, en un próximo post vamos a hace algo más práctico.

Por que no EJB 3?

Soy un promovedor del uso de Spring pero por X motivo estoy estudiando un poco JEE 5 y la verdad estoy sorprendido por su simpleza, cambio mucho. Lo único que critico es que el tiempo de levantar jboss o glassfish o otro servidor JEE es mayor que usar solo tomcat o jetty (obviamente).

La especificación EJB 3 deja atrás el mal sabor que tenían las anteriores versiones de EJB a la hora de desarrollar. El paso más importante ahora los EJB son pojos, que por medio de anotaciones se infiere el comportamiento. No es necesario heredar de ningún objeto, ni hacer interfaces (gracias a Dios).

Veamos los tipos de beans que existen:

Session EJB: Son los beans que tienen las acciones; son los que tienen la lógica del negocio. Este tipo de bean viene en 2 sabores Stateless (no mantiene el estado en el servidor) o Statefull (mantiene el estado en el servidor). Además se agrego un Sigleton Beans, para cuando necesitamos solo una instancia de nuestro objeto de negocio.

Message-Driven Beans: La mensajería asíncrona es un paradigma en el cual dos o más aplicaciones se se comunican mediante un mensaje que describe un evento de negocio. Estos beans pueden generar mensajes asíncronos y consumirlos.

Entity Beans: Son objetos que modelan nuestros datos (Pojos) y son persistidos por medio del javax.persistence.EntityManager. Usando JPA (descripto en JSR-317) podemos persistir nuestros entity beans como si usáramos un ORM común.

Este es un pequeño resumen de la que nos brinda EJB 3. En próximos post ampliaremos!!

Java Magazine is Coming!

La idea es que en fines de julio va salir la revista oficial de Java gratuita. Es una interesante propuesta de oracle.

Todavía no se encuentra un nro publicado pero ya nos podemos registrar.

Dejo el link:

http://blogs.oracle.com/java/2011/04/java_magazine_is_coming.html

java.util.Objects la nueva librería de java 7!

La verdad es que mucho no me gusta (sera resistencia al cambio), yo pienso que le roba trabajo a los objetos, para mi debería estar esta funcionalidad en Object o de otra forma, no lo se.

Más allá de mi humilde opinión era necesaria, siempre teníamos que escribir un util que haga cosas que hora hace esta librería.

Veamos unos ejemplos:

public void showFoo(Foo foo) {  Foo foo2 = new Foo();
  
     //lot of code

     if(foo.equals(foo2)) {
             System.out.println("Two Men");
     } else {
             System.out.println("And a Half");
     }
}

Esto puede dar NullPointer veamos como lo resolvemos con Objects:

public void showFoo(Foo foo) {
 
     Foo foo2 = new Foo();
  
     //lot of code

     if(Objects.equals(foo,foo2)) {
             System.out.println("Two Men");
     } else {
             System.out.println("And a Half");
     }
}

Podemos hacer el hash con Objects, que sera de org.apache.commons.lang.builder.HashCodeBuilder

@Override public int hashCode() {
  return Objects.hash(name, age, job);
}

Podemos chequear que un objeto no sea null

public void showFoo(Foo foo) {
  this.bar = Objects.requireNonNull(foo);
}

Podemos tomar tomar el toString si no es nulo, y de lo contrario devolver un valor:

return Objects.toString(foo, “Foo is Empty”);

Interesante no? que les parece la nueva librería?

Fuente: http://alexsotob.blogspot.com/2011/04/another-shot-of-whiskey-cant-stop.html

La historia de linux

Con motivo de los 20 años de Linux se realizo el siguiente vídeo que explica la historia del sistema operativo.

GO

...no voy a cambiar, no voy a cambiar mi modo
ellos me dicen : "nena,
nena vos lo tenes todo."
Oh, negro go...

Rara forma de empezar un post del no tan famoso lenguaje de google Go!

El pequeño párrafo de la canción de los piojos “go negro go” resume un poco mi sensación con respecto a este lenguaje, es como que tiene todo pero hecho como le gusta a google. Que no digo que este mal, pero por ahí tantas vueltas de rosca no son muy buenas a veces.

El lenguaje de programación Go es un proyecto de código abierto con el objetivo de la productividad en los programadores.

Go es expresivo, conciso, limpio y eficiente. Sus mecanismos de concurrencia hace fácil escribir programas que sacan el máximo provecho a múltiples núcleos y las máquinas en red, mientras su novedoso sistema de tipado permite la construcción de programas flexibles y modulares. Compila rápidamente a código de máquina, pero tiene la comodidad del garbage collection y el poder de reflexión en tiempo de ejecución.

Veamos un ejemplo:

package main

// fib returns a function that returns
// successive Fibonacci numbers.
func fib() func() int {
a, b := 0, 1
return func() int {
a, b = b, a+b
return b
}
}

func main() {
f := fib()
// Function calls are evaluated left-to-right.
println(f(), f(), f(), f(), f())
}

La salida de este programa es: 1 2 3 5 8

Se puede ver fácilmente la influencia de python y c++

Veamos un hola mundo:

package main

import fmt "fmt" // Package implementing formatted I/O.

func main() {
fmt.Printf("Hello, world; or Καλημέρα κόσμε; or こんにちは 世界\n")
}

Go es un lenguaje compilado. Para compilar este programa podemos utilizar Gccgo que utiliza GCC. También hay una serie de compiladores para diferentes arquitecturas por ejemplo: 6g para 64-bit x86, 8g para 32-bit x86, etc. Estos compiladores corren más rapido que Gccgo pero generan codigo menos eficiente. Veamos como compilar y correr go:

$ 6g helloworld.go # compile; object goes into helloworld.6
$ 6l helloworld.6 # link; output goes into 6.out
$ 6.out
Hello, world; or Καλημέρα κόσμε; or こんにちは 世界
o
$ gccgo helloworld.go
$ a.out
Hello, world; or Καλημέρα κόσμε; or こんにちは 世界


Dejo links como siempre:
http://golang.org/
http://wh3rd.net/practical-go/

Recursos sobre Rails

Estoy estudiando un poco rails y encontré unos links de la apis de Rails.

Si quieren ver el código de rails:

git clone http://github.com/rails/rails.git
cd rails

Para ver la api de rails

http://api.rubyonrails.org
http://apidock.com/rails
http://railsapi.com

Espero que les sirva.

Aprendiendo SOA

Dejo una serie de libros y links para la persona que quiere empezar con SOA

Libros:

Open Source SOA.

Autor: Jeff Davis

Publicado por Manning Publications corp.

ISBN: 1933988541

Java SOA cookbook

Autor: Eben Hewitt

Publicado por O’Reilly Media, Inc.

ISBN: 978-0-596-52072-4

Service-Oriented Architecture: Concepts, Technology, and Design

Autor: Thomas Erl

Publicado por Prentice Hall PTR

ISBN: 0-13-185858-0

Service-Oriented Architecture Governance for the Services Driven Enterprise

Autor: Eric E. Marks

Publicado por Wiley Publishing.

ISBN 978-0-470-17125-7

Adopción de SOA para Dummies.

Autores:Miko Matsumura, Bjoern Brauel y Jignesh Shah

ISBN: 978-0-470-48334-3

Publicado por Wiley Publishing.

Introducción a BPM para Dummies.

Autores: Kiran Garimella, Michael Lees y Bruce Williams

ISBN: 978-0-470-37359-0

Publicado por Wiley Publishing.

Papers:

Introducing SCA

autor: David Chappell

Url: http://www.davidchappell.com/articles/introducing_sca.pdf

BPM and SOA

Autor: Mike Rosen

Url:http://www.bptrends.com/publicationfiles/04-08-COL-BPMandSOA-OrchestrationorChoreography-%200804-Rosen%20v01%20_MR_final.doc.pdf

Oracle SCA – The Power of the Composite

Autor: Pat Shepherd

Url: http://www.oracle.com/technetwork/topics/entarch/whatsnew/oracle-sca-the-power-of-the-composi-134500.pdf

Fabric3 Reference
 Guide

Url: http://dist.codehaus.org/fabric3/releases/doc/1.6/fabric3-reference-1-6.pdf

Sitios Web:

http://msdn.microsoft.com/webservices/

http://complexevents.com/

http://www.soapatterns.org

http://www.osoa.org/

http://tuscany.apache.org/

http://wso2.com/

http://www.oasis-opencsa.org/

http://blogs.tecsisa.com/

¿Que herramienta de registro utilizar?

El objetivo de tener un registro de las funcionalidades desarrolladas es que todos los desarrolladores conozcan las funcionalidades y no exista duplicidad de servicios. Para esto se podría utilizar diferentes herramientas de propósito más general, como una wiki o una base LDAP, pero es mejor utilizar una herramienta de propósito particular. En el mercado existen herramientas open source para el registro de servicios. Entre los más importantes podemos mencionar a MuleSource Galaxy y Registro de WSO2.

MuleSource Galaxy: Esta basado en un diseñador de repositorios para la gestión de artefactos de software basados en SOA. Entre ellos se incluye la configuración del ESB Mule, WSDL, archivos xml y configuración de Spring. Es una perfecta herramienta de registro cuando se utiliza ESB mule ya que se integra totalmente con ese producto.

Registro de WSO2: Esta diseñado para almacenar, catalogar, indexar y gestionar metadatos de empresa relacionados con artefactos SOA. Incluye el control de versiones y su rapidez lo hace un buen candidato para sistemas empotrados.

El producto Galaxy tiene soporte para las mismas funcionalidades generales que el registro de WSO2, como puede ser la categorización de recursos, la monitorización y la gestión de ciclo de vida y de la dependencia. Además, su versión 1.5 incluye nuevas funcionalidades como la replicación (disponible solo la versión de pago) tiene soporte para scritps y una API de eventos.

El producto de registro WSO2 es muy sencillo de utilizar y en este punto supera a Galaxy gracias a su mejor infraestructura para Atom/Rss y sus funcionalidades de control de versiones y de restauración de versiones anteriores.

Las funcionalidades más atractivas de Galaxy se encuentran en la versión de pago mientras que la herramienta de registro de WSO2 es 100% libre y gratuita. Por esta razón y la facilidad de uso, optamos por la herramienta de registro de WSO2.

¿Cómo se desarrolla sobre una arquitectura SOA?

El desarrollo sobre una arquitectura SOA debe siempre tener en cuenta las funcionalidades desarrolladas y debe consumir estos servicios y exponer las nuevas funcionalidades. Por lo tanto es importante tener un registro actualizado donde se registran los servicios desarrollados y si la empresa cuenta con sistemas heredados con servicios expuestos se debe realizar un relevamiento de los servicios desarrollados y reflejarlos en el registro. Que el registro esté actualizado y sea visual para todos los desarrolladores es vital para que no exista comportamiento replicado.

El desarrollador esta obligado a pensar los servicios de forma atómica y desacoplada. Un servicio nunca debe depender de una implementación sino de una interfaz que describe a dicha dependencia, agregando más complejidad a la tarea de diseñar pero disminuyendo el esfuerzo de mantenimiento ante un cambio. Promoviendo el desacoplamiento y la mantenibilidad.

El estilo arquitectónico SOA no es intrusivo, no nos obliga a utilizar una forma propia de SOA para desarrollo, ni un Paradigma de programación, ni un lenguaje, ni plataforma. Pero si nos obliga a no repetir funcionalidad publicada y publicar los servicios de tal forma sean útiles a otros sistemas. Por ejemplo podríamos programar con POO y publicar la funcionalidad por medio de servicios o utilizar el patrón facade. En este esquema los servicios van a seguir la arquitectura SOA, dando la libertad de diseñar nuestros objetos independientes de la arquitectura SOA. Lo más recomendado es utilizar una arquitectura en Capas sumado a la arquitectura SOA.

Una arquitectura en capas nos permite separar de forma lógica las incumbencias generales en capas. El objetivo de separar las incumbencias en capas, es el desacoplamiento. De esta forma podríamos cambiar ciertas capas si necesidad de modificar las demás.

Sumado a la arquitectura SOA con la arquitectura en Capas, aprovechamos lo mejor de los dos mundos.
En la actualidad existen gran cantidad de framework que nos permiten desarrollar servicios web (CXF, Spring WS, Apache AXIS 1 y 2, Metro, etc.) y a la vez existen muchas formas de exponer estos servicios REST, SOAP, Mensajería, etc. y también existen diferentes formatos de datos JSON, SOAP, RSS, ATOM, etc. Todas estas tecnologías pueden conformar mis sistemas lo cual dificulta la comunicación ya que diferentes aplicaciones hablan diferentes idiomas.

Dada esta problemática surgió del mercado un estándar llamado Service Component Architecture (SCA), que propone una forma de desarrollo SOA. Basándose en el concepto de componentes promueve que un componente publica servicios que le permiten hablar idiomas diferentes (más usados) y entender la mayoría de los formatos de datos.

También a raíz de la diversidad de tecnologías para exponer servicios nace el ESB, que como dijimos anteriormente es un adaptador de diferentes “lenguajes”. Por lo tanto podríamos decidir utilizar un framework para exponer servicios y un ESB con su adaptador, o desarrollar con SCA. Dependiendo de los requerimientos se debe realizar una elección.

EAI (Enterprise Application Integration)

EAI (Enterprise Application Integration, traducido al español como integración de aplicaciones empresariales) es definido como el uso de software y sistemas de computadora para integrar un conjunto de aplicaciones.
El propósito de la EAI es lograr la interoperabilidad y organización del flujo de información entre aplicaciones heterogéneas, es decir, asegurar la comunicación entre las distintas aplicaciones y formar el sistema de información de la empresa, incluso de los clientes, socios o proveedores.

Por lo tanto, y en primer lugar, un proyecto de EAI implica implementar una arquitectura bajo la cual las distintas aplicaciones se comuniquen entre sí. En consecuencia, esto conlleva el desarrollo de conectores (middleware) que posibilitan la interfaz de aplicaciones mediante el uso de distintos protocolos de comunicación (por lo general exclusivos).

Sin embargo, el proyecto de EAI va más allá de la interoperabilidad de las aplicaciones: ofrece la posibilidad de definir un workflow entre las aplicaciones; así, representa una alternativa a la ERP1 con un enfoque más modular.
No obstante, la EAI todavía presenta limitaciones relacionadas con la rigidez de los sistemas heredados (en inglés legacy), porque se debe modificar el middleware cuando hay cambios importantes en las aplicaciones.

Cuando los sistemas no pueden compartir su información efectivamente se crean cuellos de botella que requieren de la intervención humana en la forma de toma de decisiones o en el ingreso mismo de la información. Con una arquitectura EAI correctamente implementada, las organizaciones pueden enfocar la mayoría de sus esfuerzos en la creación de competencias que generen valor en lugar de enfocarse en la coordinación de labores operativas.

Durante varias generaciones, los sistemas de las empresas han servido para un propósito especifico a un único usuario o grupo de usuarios, los cuales actúan como la interfaz de dicho sistema con el resto de la organización, con lo cual se ha limitado su conexión con otros sistemas modernos o más amplios en la empresa, más aún por la creciente demanda de las empresas por compartir datos y usarlos en sus procesos sin tener que realizar cambios en sus aplicaciones o en sus estructuras de datos.

Uno de los retos que encaran las organizaciones modernas es darles a sus empleados información completa en tiempo real. Muchas de las aplicaciones en uso actualmente se apoyan en tecnologías antiguas, por lo cual esos sistemas enfrentan dificultades a la hora de mover esta información entre las aplicaciones.

EAI, como una disciplina, busca solventar muchos de esos problemas, así como crear nuevos paradigmas para ciertamente mejorar las organizaciones, tratando de trascender el objetivo de conectar las aplicaciones individuales para buscar ser un mecanismo de incrementar el conocimiento de la organización y crear ventajas competitivas futuras a la empresa.

La integración de aplicaciones de empresa ha incrementado su importancia porque la computación en las empresas frecuentemente toma la forma de islas de información. Esto ocasiona que el valor de los sistemas individuales no sea aprovechado al máximo debido a su mismo aislamiento.

Si la integración se aplica sin seguir un enfoque estructurado de EAI, las conexiones punto a punto crecen al interior de la organización resultando en una masa imberbe que es difícil de mantener. Esto se denota normalmente como el espagueti, en alusión al equivalente en programación: el código espagueti.
EAI puede ser usado con diferentes fines:

• Integración de datos (información): asegurando que la información en varios sistemas es consistente. Esto también se conoce como EII (Enterprise Information Integration).
• Integración de procesos: enlace de los procesos de negocios entre diferentes aplicaciones.
• Independencia de proveedor: extrayendo las políticas o reglas del negocio de las aplicaciones e implementándolas en un sistema EAI, de forma que cualquiera de las aplicaciones usadas pueda ser cambiada sin que dichas reglas de negocio deban ser reimplementadas.
• Facade común: Un sistema EAI puede actuar como el front-end de un cúmulo de aplicaciones, proporcionando una interfaz de acceso única y consistente a esas aplicaciones y aislando a los usuarios sobre la interacción con distintas aplicaciones.

CEP (Complex Event Processing) y ESP (Event Stream Processing)

Las tecnologías emergentes como el Procesamiento de Eventos Complejos (Complex Event Processing o CEP) y el Procesamiento de Flujos de Eventos (Event Stream Processing o ESP) han comenzado a ocuparse de problemas de mayor complejidad que no podían resolverse con el procesamiento de eventos tradicional. Por ejemplo, con CEP se puede analizar, correlacionar y resumir eventos de bajo nivel en eventos de más alto nivel adecuados para informar a las personas en términos humanos o para desencadenar procesos automáticos. CEP y ESP emplean técnicas como la detección de patrones complejos en numerosos eventos, utilizando algoritmos de procesamiento de reglas para la correlación y abstracción de eventos, empleando jerarquías de eventos y relaciones entre los eventos. Los análisis de causalidad, membrecía, oportunidad y procesos impulsados por eventos son capacidades centrales de estas tecnologías.

ESP y CEP se consideran parte de una tendencia más extensa llamada EDA (event-Driven Architecture) EDA es un estilo arquitectónico, que esta centrado en comunicaciones asíncronas basadas en eventos. Es totalmente complementario a SOA y utiliza mensajes asíncronos en lugar de llamadas a funciones al estilo RPC, para realizar computación distribuida. Un evento es simplemente la acción de algo que está ocurriendo, bien sea un pedido, un aviso de entrega o la finalización del trabajo de un empleado. El sistema que registra el evento (también llamado sensor) genera un objeto de eventos que se envía mediante una notificación. El consumidor de la notificación o receptor puede ser otro sistema que por su parte, utilice el evento para iniciar alguna acción como respuesta. Aquí es donde el concepto de ESP entra en juego.

ESP permite analizar los procesos e identificar eventos inusuales, lo que permite a raíz de estos eventos informarlos o ejecutar algún proceso. Por ejemplo una persona que saca del cajero un monto inusual de dinero el sistema podría enviar un e-mail al cliente notificando la extracción. Otro ejemplo podría ser: un servicio demora más de lo normal esto puede generar un evento el cual sea notificado a un servicio que informe al administrador.

Implementar ESP en una arquitectura SOA nos facilita su mantenimiento y permite manejar eventos complejos de una forma fácil.

BPEL

Business Process Execution Language (lenguaje de ejecución de procesos de negocio), se trata de un lenguaje XML para la especificación de procesos de negocio ejecutables, aplicado principalmente a la orquestación de los servicios web. BPEL es un subconjunto de BPM. Definido para representar workflows de servicios web.

La interacción entre servicios web puede ser descripta de dos formas: procesos de negocio ejecutable y procesos de negocio abstracto.

• Proceso de negocio ejecutable: es el comportamiento real de un participante de una interacción.
• Proceso de negocio abstracto: es el proceso que no está destinados a ser ejecutados, puede ocultar algunos de los detalles necesarios de las operaciones concretas. Los Procesos abstractos desempeñan una función descriptiva, con más de un caso de uso posible, incluyendo el comportamiento observable y plantilla de proceso. Un proceso abstracto que incluye información como cuándo es mejor esperar para mensajes, cuándo enviar mensajes, cuándo compensar las transacciones fallidas, etc.

BPEL provee un lenguaje para la especificación de Procesos de negocios Ejecutables y Abstractos. De este modo, se extiende el modelo de servicios Web y la posibilidad de interacción para apoyar las transacciones comerciales. WS-BPEL define un modelo de integración interoperable que debería facilitar la expansión de la integración de procesos automatizados, tanto dentro como entre las empresas.

Bpel fue diseñado con los siguientes objetivos:

1. Definir procesos de negocio que interactúan con entidades externas a través de operaciones de Web services definidas en archivos WSDL, y que se manifiestan en los servicios Web definen utilizando WSDL.
2. Esta basado en xml. No define una representación gráfica de procesos, ni provee algún particular metodología de diseño.
3. Definir una serie de conceptos de orquestación de servicios Web que pretenden ser usados por vistas internas o externas de un proceso de negocio.
4. Proveer sistemas de control jerárquicos y de estilo grafo, que permitan que su uso sea lo más fusionado e inconsútil posible. Esto reduciría la fragmentación del espacio del modelado de procesos.
5. Proveer funciones de manipulación simple de datos, requeridas para definir datos de procesos y flujos de control.
6. Soportar un método de identificación de instancias de procesos que permita la definición de identificadores de instancias a nivel de mensajes de aplicaciones. Los identificadores de instancias deben ser definidos por socios y pueden cambiar.
7. Brindar la posibilidad de la creación y terminación implícitas de instancias de procesos, como un mecanismo básico de ciclo de vida. Operaciones avanzadas de ciclo de vida como por ejemplo "suspender" y "continuar" pueden agregarse en futuras versiones para mejorar el manejo del ciclo de vida.
8. Definir un modelo de transacción de largo plazo que se base en técnicas probadas tales como acciones de compensación y ámbito, de tal manera a brindar recuperación a fallos para partes de procesos de negocios de largo plazo.
9. Usar servicios Web como modelo para la descomposición y ensamblaje de procesos.
10. Construir sobre estándares de servicios Web (aprobados y propuestos) tanto como sea posible, de manera modular y extensible.

BPEL es una herramienta concebida para diseñar workflows basados en web services, esto lo hace una herramienta más apta que BPM para la orquestación de servicios SOA. BPM es más amplio y menos específico para SOA por estas razones nace BPEL. Un lenguaje más específico que suple las deficiencias que tiene BPM.

BPM

BPM (Business Process Management) podría ser definido como un Flujo de trabajo o workflow1, es una forma de representar los procesos, los cuales son seguidos por el sistema. Permitiendo en tiempo de ejecución modificar el workflow y que se aplique estos cambios sin volver a compilar ni a bajar o subir la aplicación.

BPM marca al sistema el orden de ejecución de procesos dando la flexibilidad para poder modificar este orden cuando se lo desee. Esto permite centrarse en la lógica de negocio dando el poder de decisión al usuario final el cual por medio de un editor puede modificar el workflow como crea más conveniente. Se centra en el negocio.
BPM es un concepto muy sencillo. Es un conjunto de métodos, herramientas y tecnologías utilizados para diseñar, representar, analizar y controlar procesos de negocio operacionales; un enfoque centrado en los procesos para mejorar el rendimiento que combina las tecnologías de la información con metodologías de proceso y gobierno.

El objetivo de una solución para la gestión de procesos de negocio es proporcionar, dentro de las TI, implementaciones automatizadas de procesos de negocio de la vida real, como por ejemplo los procesos de pedidos y cobros, o de gestión de reclamaciones. Combinada con una SOA, esta forma de proporcionar funcionalidades de TI, con una visión orientada a procesos.

La tecnología BPM incluye lo necesario para diseñar, representar, analizar y controlar los procesos de negocio operacionales:

• El diseño y modelado de procesos posibilitan que, de forma fácil y rigurosa, pueda definir procesos que abarcan cadenas de valor y coordinar los roles y comportamientos de todas las personas, sistemas y otros recursos necesarios.
• La integración le permite incluir en los procesos de negocio cualquier sistema de información, sistema de control, fuente de datos o cualquier otra tecnología. La arquitectura orientada a servicios (SOA) lo hace más rápido y fácil.
• La ejecución convierte de forma directa los modelos en acción del mundo real, coordinando los procesos en tiempo real.
• La supervisión de la actividad de negocio (BAM) realiza el seguimiento del rendimiento de los procesos mientras suceden, controlando muchos indicadores, mostrando las métricas de los procesos y tendencias clave y prediciendo futuros comportamientos.
• El control le permite responder a eventos en los procesos de acuerdo a las circunstancias, como cambio en las reglas, notificaciones, excepciones y transferencia de incidentes a un nivel superior.

Para soportar esta estrategia es necesario contar con un conjunto de herramientas que den el soporte necesario para cumplir con el ciclo de vida de BPM. Este conjunto de herramientas son llamadas Business Process Management System y con ellas se construyen aplicaciones BPM.

BPM no esta acoplado al mundo SOA, se puede controlar procesos de una aplicación usando BPM sin tener servicios web. Pero BPM se puede utilizar para modelar flujo de trabajo llamando servicios web. Permitiendo una gran flexibilidad el flujo de trabajo no depende de una aplicación sino que esta constituido por servicios referenciados por una URI. El motor BPM no esta acoplado a implementaciones sino que conoce solo interfaces dadas por WSDLs o otros descriptores desacoplando el motor BPM de los servicios. Además se puede extender el motor BPM para que ofrezca información del workflow por servicios web. Proporcionando funcionalidades completas por servicios web.

WS-CDL

Cuando hablamos de coreografía de Servicios Web se debe mencionar a WS- CDL (Web Services Choreography Description Language) y por tanto de colaboración entre actores; es decir, de interacciones entre servicios web. Este lenguaje, basado en XML, permite lograr interacción entre servicios Web. Dicha interacción es independiente del lenguaje o de la plataforma utilizada.

La coreografía es una visión más abstracta y descriptiva de los actores que intercambian mensajes para ejecutar varios procesos particulares (varios flujos de control). WS-CDL tiene como propósito definir la interoperabilidad necesaria para crear un sistema compuesto por servicios web.

Orquestación y Coreografía

La integración se debe llevar a cabo mediante un mecanismo que permita que los servicios cooperen entre ellos. Para ello comúnmente se utilizan dos términos: La orquestación y la coreografía. Hablamos de orquestación de servicios cuando es controlado por una única unidad, es decir un cliente y un servicio establecen un acuerdo con respecto al transporte de mensajes y al contenido. Un proceso es una coreografía de servicios cuando las colaboraciones son definidas entre cualquier tipo de aplicaciones.

La coreografía brinda reglas que revelan como múltiples componentes pueden colaborar entre pares, lo que denominamos peer-to-peer, y de que forma o en que secuencia. Esta colaboración se realiza mediante el intercambio de mensajes. Una coreografía describe la colaboración entre más de un servicio para lograr un objetivo común. Por lo tanto no se centra en un servicio en particular, pero si en un objetivo que tiene que cumplir el flujo de proceso. Para ello, la lógica de control es distribuida sobre los servicios participantes. Para diseñar una coreografía, se debe describir primero las interacciones que los servicios tienen que realizar entre sí para cumplir el objetivo y las relaciones que existen entre estas interacciones. Una coreografía no describe las acciones que son realizadas internamente por el servicio principal para realizar el flujo de procesos.

Si usted alguna vez pudo apreciar una presentación de ballet, puede haberse percatado como cada integrante del equipo (servicios) inicia y finaliza un conjunto de movimientos (flujo de proceso), estos movimientos siguen una trilla (interacciones entre los servicios) musical determinada.

Una orquestación describe el comportamiento que el servicio principal implementa para realizar un flujo de proceso. Esto quiere decir, que el enfoque se centra sobre un servicio en particular, y la lógica de control es centralizada sobre el servicio principal el cual implementa el comportamiento. Para diseñar una orquestación, se describe las interacciones que el servicio principal tiene con las otras partes (servicios, adaptadores, interfaces, etc.) y las acciones que el servicio principal realiza internamente para realizar el flujo de proceso. Una orquestación es ejecutada por una máquina de orquestación. Por lo que es llamado proceso ejecutable.

Para entender mejor la definición de orquestación, imagine como un maestro de una orquesta sinfónica dirige y controla a cada uno de los integrantes (servicios) de la orquesta con el fin de poder lograr un objetivo común (un flujo de proceso), que es el de poder establecer una melodía armoniosa basada en un conjunto de especificaciones (objetivo principal y interrelaciones entre servicios) que contienen las notas, que instrumentos deben tocarse, que notas deben tocar cada uno de esos instrumentos y cuando deben iniciar o detener sus melodías.

Coreografía nos permite especificar las reglas de unión y trabajo colaborativo (entendiendo por colaboración, una función/es de negocio surgidas de la interacción cooperativa de múltiples actores). Es lo que normalmente se entiende por un proceso de negocio global donde se modela el estado de negocio de diversos servicios web.
La orquestación es un mecanismo para el intercambio de mensajes desde una visión más detallada a través de un proceso (un flujo de control). La Orquestación podría verse como la ejecución de un proceso de negocio definido en BPM o BPEL y que puede ser ejecutado por un motor BPM o BPEL.

La coreografía se define mediante WS-CDL y la orquestación puede definirse con BPM o BPEL.

Herramienta SOA: Registro o repositorio

Sólo se puede gobernar lo que se ve, por lo tanto, el primer paso es crear un único catálogo maestro en el que estén visibles, para todas las partes interesadas, los elementos más importantes de su SOA. El registro/repositorio se ha erigido en el estándar para la creación de este tipo de sistema de registros.

El registro es donde se publican los servicios y es donde se debe consultar los servicios existentes para poder consumirlos.

El registro puede ser desde una base de datos LDAP a una entrada en wiki de la empresa, dependiendo de los requerimientos de la empresa. Pero siempre debe tener al menos esta información:

• Punto final del servicio (donde esta publicado).
• Descripción del servicio.
• Ubicación WSDL si usamos servicios SOAP o como se utiliza el servicio.
• Numero de revisión y versión.