Duke Chile

JQuery

noreply@blogger.com (José Luis Coronel Cortés) — Sun, 24 Aug 2008 23:47:00 +0000

Cada vez que pienso en desarrollar una aplicación RIA lo primero que se me viene a la mente es Flex. Pero siempre existen los casos en los cuales el cliente no desea que su aplicación dependa de si sus usuarios tengan o no instalado alguna versión determinada del "Flash Player" en sus navegadores. Para estos casos, mi segunda opción es ZK, pero nuevamente existe el problema de que a algunos cliente nos les gusta aventurarse en frameworks no muy conocidos (no muy conocidos por el) y prefieren más bien que sus sistema sea desarrollado utilizando algún otro framework o estándar mas conocido por la industria.

Es en estos escenarios donde recurro a mi querido (y también odiado) JSF. Hace ya bastante tiempo que no volvía a meter las manos con JSF, pero gracias a dios, hoy en día todo es mucho más fácil, si es que utilizamos “Facelets” y todo el poder que nos entrega “Spring Faces”.

Hasta el momento todo está bien, pero en este último caso, me vuelvo a encontrar con el mismo problema de siempre. El cliente quiere un sistema de ensueños!!!. Que todo sea “Drag-and-Drop”, full Ajax, mucho efecto visual, etc…..

Claro, si hablamos de JSF, podría utilizar RichFaces, IceFaces, MyFaces o alguna otra batería de componentes. Pero que pasa en los casos en que necesito alguna funcionalidad especial que no esté implementada dentro de este conjunto de componentes?.

Buscando una opción, recordé haber leído que hoy en día, muchos consideran a JQuery como una de las mejores librerías Javascript del momento. Así que decidí ver que tanta maravilla es esta tan bullada librería, y aunque no me considero un fanático de Javascritp (muy por el contrario), la única palabra que se me ocurre para expresar el sentimiento que me produjo es GUUUUAAAAAUUUUUUU!!!!!!!.

Mi objetivo es compartir algunos conceptos básicos que he podido desarrollar gracias al libro “Learning Jquery - Better Interaction Design And Web Development With Simple Javascript Techniques”.

Si alguien está interesado en aprender Javascript, le recomiendo el libro gratuito de Javier Eguíluz Pérez que pueden descargar desde aquí.

JQuery es una librería JavaScript rápida y concisa, que simplifica la tediosa tarea de recorrer documentos HTML (DOM), manejar eventos, ejecutar animaciones y agregar interacciones con Ajax.

Para utilizar JQuery, solo necesitamos descargar la librería y en cada página que necesitemos utilizarla, simplemente definir:

Una de las principales ventajas, además de ahorrarnos la escritura de bastante código (principalmente útil para los que no somos muy expertos en Javascript), es que nos permite manipular la página apenas se haya construido el árbol DOM de esta, en comparación con las funciones de Javascript, las cuales esperan a que se carguen todos los elementos de la página (incluyendo todas las imágenes).

Algunas de las principales ventajas que nos aporta esta librería son:

Nos ahorra muchas líneas de código.

Nos hace transparente el soporte de nuestra aplicación para los principales navegadores web.

Nos provee de un mecanismo para la captura de eventos.

Provee un conjunto de funciones para animar el contenido de la página en forma muy sencilla.

Integra funcionalidades para trabajar con AJAX.

El primer paso será descargarnos la última versión de JQuery desde aquí y dejarla dentro de nuestro proyecto.

Para los siguientes ejemplos he renombrado el archivo a “jquery.js” y lo he dejado guardado dentro de la carpeta “js” de mi aplicación web.

Para entender mejor como nos puede ayudar JQuery a ahorrar muchas líneas de código, nada mejor que un ejemplo comparativo “Sin JQuery” y “Con Jquery”.

Ya a simple vista podemos ver que a diferencia de la forma tradicional, con JQuery nos basto simplemente un par d líneas de código para lograr la misma funcionalidad. Pero, como trabaja JQuery?.

La función principal de esta librería se llama “$”, a la cual le podemos pasar distintos valores, y la que a su vez retorna un objeto del tipo JQuery .

Si vemos el código del archivo “ejemploBasicoJQuery.js”, podremos observa que el primer método que estamos llamando es a “ready”:

Este método recibe como parámetro el nombre de una función, la que se ejecutara cuando todos los elementos de la página estén cargados.

Dentro de la función “inicializarEventos”, nuevamente utilizamos la función “$” para crea un objeto de la clase JQuery asociada a un botón de la pagina HTML. Para lograr esto, a la función “$” le pasamos el “id” del botón al cual la queremos asociar precediéndolo por el caracter "#".

Por último, llamamos al método click, pasándole como parámetro el nombre de la función que se ejecutará al presionar ese botón.

En el caso de que queramos asociar algún elemento de una página HTML a la función “$”, simplemente seguimos la sintaxis:

$(“nombre_elemento_HTML”)

El único problema con este tipo de función, es que estaremos referenciando a los de este tipo contenidos en nuestra página HTML. Entonces, como podemos discriminar sobre que elemento de la pagina se efectuó alguna acción?. Simplemente llamando a la función "$(this)".

Otra característica muy importante de JQuery, es que nos permite tener acceso a los selectores CSS de los elementos contenidos dentro del árbol DOM.

Veamos un ejemplo que muestre todos los tópicos mencionados hasta el momento:

Además de tener acceso a los selectores CSS, también podemos tener acceso a las clases que tengamos definidas dentro de nuestra página CSSHTML simplemente llamando a la función:

$(“.nombre_clase_css”)

Si queremos obtener el texto de un elemento, simplemente llamamos al método "text()". Por ejemplo, si tenemos el párrafo:

Para obtener el texto llamaremos a la función "text()" del elemento “p”:

En cambio, si queremos modificar el texto contenido dentro del elemento, llamaremos nuevamente al método "text()", pasándole como parámetro el nuevo texto:

Otros métodos importantes dentro de JQuery, son aquellos que nos permiten manipular los atributos de los elementos de nuestra página HTML. Estos son:

attr(nombre_atributo)

attr(nombre_ atributo, valor)

removeAttr(nombre_ atributo)

Por ejemplo:

Eventos

Algunos de los eventos más importantes dentro de JQuery son:

mouseover/mouseout: Estos eventos son equivalentes a los eventos onmouseover y onmouseout de Javascript. El primero de estos se ejecuta cuando ponemos la flecha del mouse sobre un elemento HTML y el segundo cuando sacamos la flecha del elemento.

hover: Como los eventos mouseover y mouseout son comúnmente usados, existe el evento hover que recibe dos parámetros:

$(elemento).hover([función de ingreso del mouse],[función de salida del mouse])

La primera función se ejecuta cuando ponemos la flecha del mouse sobre un elemento HTML y el segundo cuando sacamos la flecha del elemento.

mousemove: Este evento se ejecuta cuando se mueve la flecha del mouse dentro del elemento HTML respectivo.

mousedown/mouseup: El primer evento se ejecuta cuando presionamos alguno de los botones del mouse y el segundo cuando dejamos de presionar el botón.

dblclick: Este evento se ejecuta cuando se presiona dos veces seguidas el botón izquierdo del mouse sobre un elemento HTML.

focus: Este evento ejecuta cuando se activa el control. Podemos capturar el evento focus de un control de tipo text, textarea, button, checkbox, fileupload, password, radio, reset y submit.

blur: Este evento se ejecuta cuando se pierde el foco el control. Podemos capturar el evento blur de un control de tipo text, textarea, button, checkbox, fileupload, password, radio, reset y submit.

Efectos

Otro concepto importante son los efectos, entre los que destacan:

show/hide: Permiten ocultar y mostrar elementos HTML, asociándoles una pequeña animación (que se oculte o muestre lentamente).

fadeIn/fadeOut: El primer efecto hace aparecer los elementos HTML con opacidad y el segundo lo decolora hasta hacerlo desaparecer (reduce la opacidad del elemento en forma progresiva).

fadeTo: Permite modificar la opacidad de un elemento, llevando la opacidad actual hasta el valor que le pasamos como parámetro. Tambien se le puede la velocidad de la transición (en milisegundos).

toggle: Permite cambiar de estado la visibilidad del elemento HTML; es decir si está visible pasa a oculto y si se encuentra oculto pasa a visible.

Si quieren ver todas las funcionalidades de JQuery, les recomiendo visitar esta página.

Además, como toda buena librería, esta ya cuenta con un conjunto de plugins que extienden y facilitan aun más el uso de JQuery. En esta página encontraran un listado de los 10 plugins más populares, entre los que destaca JQuery UI.

Después de todo lo visto, creo que me quedare con “RichFaces” en el en mundo JSF, debido a que se integra fácilmente con JQuery.

Inyección de SQL (SQL Injection)

noreply@blogger.com (José Luis Coronel Cortés) — Sat, 23 Aug 2008 20:59:00 +0000

Uno de los temas a los cuales puede asistir en las “Primeras Jornadas Latinoamericanas de Arquitectura de Software” fue “Seguridad y Arquitectura de Software”, el cual fue presentado por Juan Carlos Herrera.

Dentro de los tópicos de la presentación, se menciono la "Inyección de SQL", como uno de los problemas que comúnmente se presentan en la seguridad del desarrollo de software. Pero….. que es la inyección de SLQ?.

Se define la inyección de SQL, como el proceso de insertar código SQL dentro de otro código SQL, con el objetivo de alterar el funcionamiento normal de una sentencia SQL.

Este problema no se debe a que el lenguaje de programación que estemos utilizando presente este problema de seguridad, sino mas bien, gracias a nosotros, los desarrolladores, que en la mayoría de los casos, tenemos un escaso o nulo filtrado de los datos en el proceso de validación de estos dentro de nuestras aplicaciones, lo que permite a un atacante, insertar (o mejor dicho “inyectar”) código SQL dentro de las variables de nuestra aplicación, las que utilizamos para realizar consultas SQL.

Pero como sucede esto? Por qué sucede esto? Donde está el problema?

Imaginemos que estamos desarrollando un software para una institución financiera (reconozco que no soy muy original para mis ejemplos), en donde la seguridad es vital. Como todo sistema bancario, este dispone de una base de datos donde almacena la información de sus clientes, sus cuentas, las transacciones bancarias, etc. Entonces, si quisiéramos consultar la información de los tipos de cliente (persona o empresa), podríamos utilizar una sentencia SQL como esta:

SELECT * FROM cliente WHERE tipoCliente=’tipoCliente’;

Donde la variable ‘tipoCliente’ contiene el tipo de cliente que es para el banco (persona o empresa).

Con esta simple consulta podríamos obtener todos los clientes de tipo “persona” que tenga el banco.

Imaginemos que además de consultar la información de un cliente por su tipo, queremos filtrar la información por comuna. Es decir, queremos ofrecerle al usuario la posibilidad de elegir, el tipo de cliente que quiere ver asociado a una determinada comuna.

Para esto, podríamos construir un servlet que procese esta información y cuyo resultado se despliegue en la página “consultaCliente.jsp”. Entonces, si el usuario realizaría una petición HTTP a nuestra JSP, pasándole los valores de la consulta por GET:

http://www.mibanco.cl/consultaCliente.jsp? tipoCliente =persona&comuna=macul

El servlet que procese esta petición, tomara los parámetros enviados por el usuario y ejecutaría la siguiente consulta SQL sobre la base de datos:

SELECT * FROM cliente WHERE tipoCliente=’persona’ AND comuna='macul';

Una vez ejecutada la consulta, los resultados obtenidos serian desplegados en la página “consultaCliente.jsp”.

Lo importante de todo esto, es que en algún punto de nuestro código, nosotros construimos la sentencia SQL en base a los valores enviados por el usuario. Es decir, si por algún motivo, al usuario se le ocurre enviarnos el valor “cualquiercosa” como comuna, nada se lo impedirá, y nuestra aplicación construirá la siguiente sentencia SQL:

SELECT * FROM cliente WHERE tipoCliente=’persona’ AND comuna='cualquiercosa';

La pregunta es, donde está el problema en todo esto?......al parecer, no existe ningún problema, porque en el peor de los caso, esta consulta no devolverá nada, ya que la comuna “cualquiercosa” no existe. Pero…….¿qué pasaría ahora si en vez de ingresar un valor cualquiera, el usuario se le ocurriera ingresar como comuna parte de una sentencia SQL?.

Por ejemplo, que sucedería en el caso de que el usuario enviara la siguiente consulta HTTP:

http://www.mibanco.cl/consultaCliente.jsp? tipoCliente =persona&comuna= %20OR%20%22=

Ahora nuestra aplicación construiría la siguiente consulta SQL:

SELECT * FROM cliente WHERE tipoCliente=’persona’ AND comuna =’’ OR ''=’’;

Estos si es un problema!!!! Estamos permitiendo que el usuario pueda manipular la sentencia SQL. Nuestra sentencia estaría diciéndole a la base de datos que le entregue todos los clientes de tipo persona y cuya comuna sea igual a ‘ ” ‘ o la expresión ‘=’ sea verdadera. Que en pocas palabras, le está diciendo a la base de datos que le entregue todos los clientes no importando cual sea la comuna.

Como podemos ver, el usuario está logrando alterar nuestra consulta para obtener un resultado no esperado por la aplicación. En este caso, mostrar todos los clientes de nuestro banco sin importar su comuna.

A este proceso se le conoce como”Inyección de SQL”. Si bien este pequeño ejemplo no implica un mayor “peligro” para nuestro sistema, no podemos pasar por alto que hay una vulnerabilidad grave en nuestro sistema, que podría permitir a un atacante con un poco más de conocimiento hacer otro tipo de inyecciones más perjudiciales para nuestra aplicación.

Qué pasaría con un usuario más astuto? Imaginemos que ahora nuestro usuario tiene un alto conocimiento de SQL (algún miembro del JUG Chile), y quiere validar si nuestro sistema presenta algún problema de seguridad frente a ataques de tipo “Inyección de SQL”. Entonces, no haya nada mejor, que enviar ciertos parámetros por la URL que le permitan obtener los datos de otra tabla, como por ejemplo, la tabla “cuentas”, que contiene toda la información de las cuentas bancarias de nuestros clientes.

Entonces, esta vez nuestro usuario realiza la siguiente consulta:

http://www.mibanco.cl/consultaCliente.jsp? tipoCliente =persona&comuna=%20UNION%20SELECT%20*%20FROM%20cuentas%20WHERE%20%22=

Entonces, nuevamente nuestro servlet que procesa esta petición, tomara los parámetros enviados por el usuario y ejecutara la siguiente consulta SQL sobre la base de datos:

SELECT * FROM clientes WHERE tipoCliente='persona' AND comuna='' UNION SELECT * FROM cuentas WHERE ''='';

Ahora si estamos en serios problemas!!!!!. El usuario a logrado obtener a través de esta consulta, todos los datos de las cuentas bancarias registradas en nuestra base de datos.

Entonces, nuevamente volvemos al punto inicial. Sera que el lenguaje que estamos utilizando para programa nuestro sistema presenta este tipo de problemas de seguridad? O será acaso un problema de nuestra base de datos?; y la pregunta principal….¿Puedo yo, como desarrollador de este sistema, evitar de alguna manera este tipo de ataques?.

Si analizamos nuestra aplicación, nos encontraremos que el principal problema radica en la nula verificación de los datos enviados por el usuario antes de realizar la consulta SQL a la base de datos.

Pero qué tipo de verificación?....bueno, simplemente validar que dentro de los valores enviados por el usuario, estos no contengan código SQL que permitan la manipulación de nuestra sentencia SQL.

Si analizamos nuestro ejemplo, los valores que tendríamos que verificar, son “tipoCliente” y “comuna”. Son estos valores, los que tendríamos que validar, verificando que no contengan caracteres especiales, como por ejemplo comillas, que puedan servir al usuario para inyectar código SQL en la consulta.

En este caso, nos bastaría con verificar que el “tipoCliente” y la “comuna”, sólo contengan letras, sin ningún carácter especial.

Lo importante de todo esto, es que el problema de la seguridad de nuestro sistema (debido a la inyección de SLQ), radica principalmente en la verificación de datos dentro de nuestro sistema. Por lo tanto, una solución, es filtrar siempre la entrada del usuario, de manera que atacante, nunca pueda inyectar código SQL en ningún lado dentro de nuestra aplicación.

Algunas técnicas, comúnmente recomendadas para la filtración de los valores enviados por el usuario son:

Limitar, siempre que se pueda, el tamaño del valor ingresado. De esta manera, limitamos la cantidad de código SQL que un atacante puede inyectar. En especial si se trata de una consulta anidada.

No permitir, o en su defecto escapar, todos los caracteres que puedan llegar a ser usados como parte de una inyección SQL: comilla simple (’), punto y coma (;) y caracteres de comentario (/* */ y –).

Filtrar con expresiones regulares todo lo que ingrese el usuario. Por ejemplo, en un formulario de registro, el campo mail sólo debería aceptar letras en minúsculas, números y un arroba. Al igual que en un número de teléfono sólo deberían aceptarse números.

Otros consejos, que no se encuentran relacionados con al verificación de los valores son:

Realizar las consultas de la aplicación, utilizando un usuario, con la menor cantidad de privilegios posible dentro de la base de datos. De modo que si un atacante, pudiera saltarse de algún modo la verificación de los valores e inyectar código en alguna de nuestras consultas, los daños se reduzcan al no tener suficientes privilegios.

Realizar la verificación de los valores ingresados por el usuario, en todas las capas de la aplicación. Algunos desarrolladores por ejemplo, hacen una sola verificación dentro de la capa de presentación, utilizando JavaScript. Esto, puede ser fácilmente evitado, enviado los valores directamente a través del navegador.

No mostrar los mensajes de error devueltos por la base de datos. Para un atacante podría serle muy útil esta información, en especial para hacer “Blind Injection”.

Usar Prepared Statements: Esta es una de las mejores soluciones que se pueden utilizar para evitar este tipo de ataques, ya que prácticamente son inmunes a las inyecciones SQL.

Una explicación más detalla de la inyección de SQL y artículos relacionados con el tema, la pueden encontrar aquí.

Pero como todo problema en el mundo Java, siempre existe alguien con una solución. Para este tipo de ataques tenemos el framework HDIV (HTTP Data Integrity Validator).

Patrones de diseño GoF (Gang of Four)

noreply@blogger.com (José Luis Coronel Cortés) — Fri, 22 Aug 2008 23:31:00 +0000

En anteriores post, hemos visto algunos de los patrones que son parte del GOF. Pero como una imagen vale más que mil palabras, aquí les dejo este link en donde podrán encontrar un excelente PDF con los diagramas UML de los principales patrones.

Esta no es la única opción, ya que también existe el poster de Head Fisrt Design Patterns, pero que a diferencia de la opción anterior, esta utlima es pagada.

Este es un poster que Cerebro no puede dejar de tener!!

SCWCD - El descriptor de despliegue web.xml

noreply@blogger.com (José Luis Coronel Cortés) — Thu, 21 Aug 2008 17:47:00 +0000

El archivo web.xml proporciona la configuración y el despliegue de información para los componentes web que conforman una aplicación.

Este archivo debe residir en el directorio WEB-INF dentro del contexto de la jerarquía de directorios que existen para una aplicación Web. Por ejemplo, si la aplicación esta empaquetada en el archivo WAR "dukechile.war", el archivo web.xml se debe colocar en el directorio “dukechile/ WEB-INF”.

Como todos los archivos de configuración xml, este contiene un esquema que describe el contenido del fichero xml y la descripción de las propiedades que va a utilizar. Dentro de este archivo definiremos la configuración de la aplicación web que estemos desarrollando.

Los elementos del web.xml son:

<web-app>: Es el elemento raíz del fichero xml.

<icon>: Define la ruta para las imágenes asociadas a los iconos pequeño y grande que representan a la aplicación.

<display-name>: Es el nombre que representará a la aplicación dentro de las herramientas del servidor de aplicaciones, no es un nombre funcional.

<description>: Texto descriptivo de la aplicación, que al igual que las dos anteriores propiedades, sólo es representativo.

<context-param>: Permite configurar parámetros de inicialización del contexto de nuestra aplicación web.

<filter>: Permite definir un filtro en la aplicación.

<filter-mapping>: Define un mapeo para aplicar las reglas de un determinado filtro a una URL.

<listener>: Permite definir una clase oyente, la que puede escuchar eventos relacionados al clico de vida de la aplicación o modificaciones de un objeto.

<servlet>: Permite definir la configuración de nuestros servlets.

<servlet-mapping>: Permite relacionar los servlets que hemos declarado con las URL que van a escuchar.

<session-config>: Permite definir el timeout de la sesión en minutos.

<mime-mapping>: Permite definir una relación entre las extensiones y los tipos mime.

<welcome-file-list>: Permite definir los ficheros de bienvenida de la aplicacion.

<tag-lib>: Permite definir las librerías de etiquetas de los ficheros JSP.

<jsp-property-group<: Permite definir propiedades para un conjunto de JSP que cumplan un patrón.

<error-page<: Permite asociar errores HTML y excepciones lanzadas por nuestra aplicación a páginas de error personalizadas para la aplicación.

<resource-ref<: Permite declarar recursos externos que nuestra aplicación va a utilizar. Por ejemplo, una conexión a una base de datos.

<resource-env-ref<: Permite declarar recursos externos que nuestra aplicación va a utilizar. Este elemento es una nueva variación del elemento añadido en Servlet 2.4 que es más simple de configurar para recursos que no necesitan información de autenticación.

<security-constraint<: Permite proteger áreas de la aplicación (o la aplicación completa), asociándolas a roles que deben tener los usuarios para poder acceder. Estos usuarios y roles son los declarados en tomcat-users.xml (para el caso de Tomcat).

<login-config<: Permite configurar el tipo de login que se requerirá al entrar en un área protegida previamente declarada.

<security-role<: Permite definir los roles de usuarios que se van a utilizar en la aplicación.

<env-entry<: Permite declarar una posible entrada al entorno (environment) de la aplicación.

<ejb-ref<: Permite definir una referencia a un EJB.

<ejb-local-ref<: Permite definir una referencia a un EJB Local.

<distributable<: Permite definir que la aplicación puede correr en un ambiente cluster.

SCWCD - Seguridad en aplicaciones Web

noreply@blogger.com (José Luis Coronel Cortés) — Wed, 20 Aug 2008 17:22:00 +0000

Uno de los tópicos que se debe estudiar para la certificación SCWCD (Sun Certified Web Component Developer) son los mecanismos de seguridad en las aplicaciones Web.

Mecanismos de seguridad

La seguridad en los servlets se reduce a cuatro conceptos principales:

authentication: El proceso de autenticación es el encargado de determinar que el interesado en acceder los recursos es realmente quien dice que es. Lo más común es hacer que el usuario o la aplicación envié un password que lo identifica.

authorization: Es el proceso por el cual se restringe el acceso a ciertos recursos a un conjunto de clientes. En realidad, lo que se define es un conjunto de roles que pueden acceder a ciertos recursos y se asocia cada usuario a uno o más roles.

data integrity: Es el proceso que asegura que los datos que se reciben (tanto el cliente como el servidor) no han sido corrompidos. Generalmente se usan algoritmos de encriptación para lograr esto.

confidentiality: Es el proceso que intenta asegurar que solamente los clientes autorizados reciban la información. La manera de lograr esto puede ser a través del uso de claves públicas/privadas.

Tipos de autentificación definidos

La especificación de servlet ofrece cuatro tipos de autentificación:

BASIC: Este es el método más simple, pero el más inseguro. Cuando usamos este tipo de autenticación, se abre una ventana en el browser del cliente para que este ingrese el usuario y el password. El password se envía al servidor codificado en Base64.

FORM: Este método es similar a BASIC, pero utiliza un formulario provisto por el programador. Este formulario tiene que cumplir los siguientes requisitos:

El atributo “action” debe ser “j_security_check”
El casillero de ingreso del usuario debe llamarse “j_username”
El casillero de ingreso del password debe llamarse “j_password”

CLIENT-CERT: En este método se usan certificados digitales. El browser debe tener instalado el certificado para que la comunicación se pueda establecer.

DIGEST: La autenticación también es hecha utilizando usuario y password, pero el password es enviado encriptado de una forma mucho más segura (por ejemplo, utilizando HTTPS client authentication).

Autorización

El primero paso es definir los roles que se encontraran definidos dentro de nuestro sistema. Para el caso de Tomcat, estos se definen en el archivo tomcat-users.xml. Dentro de este archivo, cada usuario tiene asignado un usuario y password; y puede estar asociado a uno o más roles.

El siguiente paso es relacionar los roles definidos en el archivo tomcat-users.xml, con los roles a utilizar dentro del sistema. Para esto deberemos utilizar los elementos <security-role> y <role-name> dentro del archivo web.xml.

Una vez definidos los roles, se procede a establecer “declarativamente” el acceso a un conjunto de recursos en combinación con los métodos, a los cuales tendrán accesos determinados roles. El elemento principal es el <security-constraint>.

Donde:

El elemento <web-resource-name> es obligatorio y utilizado principalmente por los IDEs.

El elemento <url-pattern> define el recurso al cual se limitara el acceso. Al menos se debe definir a lo menos un <url-pattern>.

El elemento <http-method> describe el método HTTP que será restringido para acceder al recurso definido en los <url-pattern>. Si no se define ningún <http-method>, entonces se restringirá el acceso a todos los métodos HTTP.

El elemento <auth-constraint> es opcional y permite definir cuales roles pueden llamar a los métodos HTTP restringidos por los elementos <http-method>

Para permitir el acceso a todos los roles, se debe definir el elemento <auth-constraint> de la siguiente forma:

O también de la forma:

En el caso de que se quiera bloquear el acceso a todos los roles, se deberá definir el <auth-constraint> de la siguiente forma:

Es importante tener en cuenta que se puede tener más de un elemento <web-resource-collection> dentro de un <security-constraint>. En este caso, el elemento <auth-constraint> se aplica a todos los <web-resource-collection> definidos dentro de un <security-constraint>.

Autentificacion

Anteriormente mencionamos que la especificación de servlet ofrece cuatro tipos de autentificación: BASIC, FORM, CLIENT-CERT y DIGEST.

Cada uno de estos tipos se puede definir en el web.xml de siguiente forma:

Un punto importante es que de los cuatro tipos de autentificación, el tipo DIGEST es el único que es opcional para los contenedores JEE.

Modos de transporte

La especificación también define tres modos para indicar la seguridad del transporte de los datos a través de la Web.

NONE: Ningún tipo de cifrado, simplemente HTTP.

CONFIDENTIAL: Define la confidencialidad de los datos. Es decir, que nadie pueda ver ni modificar los datos que se envían.

INTEGRAL: Define la integridad de los datos. Es decir, que aunque alguien pueda ver lo que se envía, se garantice que los datos no se modifiquen por el camino.

El metodo isUserInRole()

La clase “HTTPServletRequest” tiene tres métodos que están asociados al manejo de la seguridad de manera “programática”, uno de estos es el método “isUserInRole”.

A través del método “isUserInRole()”, en vez de manejar el acceso a nivel de método HTTP, ahora podremos autorizar el acceso a una parte del código de nuestro método basados en los roles del usuario.

Antes de que se llame al método “isUserInRole()”, el usuario necesita estar autenticado. En el caso de que llame al método sobre un usuario que no ha autenticado, el contenedor retornara “false”.

En el caso de que este autenticado, el contenedor toma el argumento del método y compara este con los roles definidos para el usuario en el “request”.

Si el usuario es mapeado a este rol, el contenedor retornara “true”.

Por ejemplo, dentro del código en el servlet:

El elemento <security-role-ref> permite relacionar un <role-name> definido “programáticamente” (en el servlet) con uno que existe en el web.xml.

JMesa

noreply@blogger.com (José Luis Coronel Cortés) — Tue, 19 Aug 2008 14:01:00 +0000

Muchos desarrolladores Web, alguna vez hemos utilizado DisplayTag para la creación de tablas con exportación y paginación automática. DisplayTag es un tag lib que nos permite ahorrar muchas líneas de código.

Ahora disponemos de una alternativa mucho más actualizada y potente llamada JMesa.

Los pasos para agregar JMesa a sus aplicaciones son muy simples.

Descargan JMesa desde aquí y agregan el tld que se encuentra bajo el directorio /jmesa-2.3.3/dist del zip al directorio /WEB-INF/tld de la aplicación.

También deberan agregar los ficheros css, javascript, las imágenes y por supuesto los jar en sus directorios correspondientes. Como JMesa requiere de JQuery, también deberán agregarlo al directorio js ( JQuery lo pueden obtener desde aquí). No importa donde se coloquen los css ni los javascript dado que se configuraran posteriormente. Las imágenes sin embargo tienen que estar en una ruta determinada que ha de coincidir con la del valor de la clave html.imagesPath especificada en el fichero jmesa.properties.

Este último fichero hay que crearlo y referenciarlo en el web.xml:

A continuación, deberán crear el archivo jmesa.properties en el directorio WEB-INF de la aplicación.

html.table.component.theme=jmesa html.table.renderer.styleClass=table html.row.renderer.highlightClass=highlight html.row.renderer.evenClass=even html.row.renderer.oddClass=odd html.column.header.renderer.image.sortAsc=sortAsc.gif html.column.header.renderer.image.sortDesc=sortDesc.gif html.column.filter.renderer.image.droplistHandle=droplistHandle.gif html.tbodyClass=tbody html.titleClass=title html.filterClass=filter html.headerClass=header html.toolbarClass=toolbar html.statusBarClass=statusBar html.imagesPath=/images/table/ html.rowcount.includePagination=false html.toolbar.maxRowsDroplist.increments=15,50,100 html.toolbar.image.csv=csv.png html.toolbar.image.pdf=pdf.gif html.toolbar.image.excel=excel.gif html.toolbar.image.clear=clear.png html.toolbar.image.firstPage=firstPage.png html.toolbar.image.firstPageDisabled=firstPageDisabled.png html.toolbar.image.lastPage=lastPage.png html.toolbar.image.lastPageDisabled=lastPageDisabled.png html.toolbar.image.nextPage=nextPage.png html.toolbar.image.nextPageDisabled=nextPageDisabled.png html.toolbar.image.prevPage=prevPage.png html.toolbar.image.prevPageDisabled=prevPageDisabled.png html.toolbar.image.filter=filter.png html.toolbar.image.separator=separator.gif

Con estos pasos, ya se encuentra listo y configurado. Para utilizarlo hay que definir el namespace de JMesa en nuestra página:

Ahora simplemente definiremos la siguiente línea:

Con estos simples pasos, ya podremos utilizar JMesa dentro de nuestros proyectos.

El patrón “Cadena de Responsabilidad” (Chain of Responsibility) - Parte VI

noreply@blogger.com (José Luis Coronel Cortés) — Sun, 17 Aug 2008 23:00:00 +0000

Los últimos ataques han sido todo un éxito, cada día se logran nuevas conquistas!!!. Debido a esto, Cerebro se ha visto en la necesidad de aumentar el número de robots dentro de sus tropas. Ahora su ejército se encuentra organizado en una estructura jerárquica, para lo cual ascendió a sus mejores solados a rangos como “General” o “Coronel”.

Con esta nueva estructura será mucho fácil dar órdenes a su ejército, el simplemente dará la orden a su “General Mazinger Z” quien al leer el comunicado decidirá si debe ejecutarla el o deberá derivarla a un sub-alterno; y así sucesivamente en la jerarquía hasta llegar al “Soldado El Galactico”.

Genial…..como siempre este plan es simple……es magnífico……es perfecto…….pero!!!!!!!

Cerebro se ha dado cuenta nuevamente que ha olvidado algo muy importante, su mecanismo de comunicación (implementado con el patrón “Observador”) ya no le sirve. Ahora tiene una estructura jerárquica, y necesita que la orden pase a través de esta estructura hasta el sub-alterno al que se le desee enviar este mensaje. Por lo tanto necesita un mecanismo en el cual el receptor del mensaje pueda no solo ejecutar la orden, sino también poder comunicar esta a su sub-alterno en el caso de que no fuera dirigida a él.

Una solución sería ir replicando el patrón “Observador” en cada uno de sus niveles jerárquicos, pero esta no es la solución más optima..

Debido a todos estos problemas, recurre nuevamente a su gurú “Martin Fowler” y encuentra la solución perfecta!!!!. Cerebro ha visto que el patrón “Cadena de Responsabilidad” (Chain of Responsibility) es ideal para solucionar su problema.

Primero necesitara definir la clase “Mensaje”, la cual contendrá a quien esta dirigida la orden y cuáles son las instrucciones a ejecutar.

Luego, deberá definir la clase abstracta “EjecutarOrdenAltoMando”, la cual deberán extender cada uno de los elementos de su ejército.

Ahora, cada sub-alterno que extienda la clase abstracta, deberá definir un mecanismo que permita discriminar si la orden enviada la debe ejecutar el, o en caso contrario, enviar la orden a su sub-alterno.

Finalmente, será muy fácil para Cerebro enviar un mensaje a su ejército, el simplemente dará la orden a su “General” y listo!!

package cadena.de.responsabilidad; public class Cerebro { public static Mensaje[] generarMensajes(){ Mensaje mensajes [] = { new Mensaje("OrdenGeneral", "Ejecutar Orden General Mazinger Z"), new Mensaje("OrdenCoronel", "Ejecutar Orden Coronel El Vengador"), new Mensaje("OrdenSoldado", "Ejecutar Orden Soldado El Galatico"), new Mensaje("OrdenCoronel", "Ejecutar Orden Coronel El Vengador"), new Mensaje("OrdenGeneral", "Ejecutar Orden General Mazinger Z"), new Mensaje("OrdenSoldado", "Ejecutar Orden Soldado El Galatico") }; return mensajes; } public static EjecutarOrdenAltoMando configurarCadena(){ EjecutarOrdenAltoMando generalMazingerZ = new GeneralMazingerZ(); EjecutarOrdenAltoMando coronelElVengador = new CoronelElVengador(); EjecutarOrdenAltoMando soldadoElGalatico = new SoldadoElGalatico(); generalMazingerZ.setSubAlterno(coronelElVengador); coronelElVengador.setSubAlterno(soldadoElGalatico); return generalMazingerZ; } public static void main(String[] args) { EjecutarOrdenAltoMando generalMazingerZ = configurarCadena(); for(Mensaje mensaje : generarMensajes()){ generalMazingerZ.ejecutarOrden(mensaje); } } }

Cerebro lo ha conseguido nuevamente, ha logrado diseñar un nuevo mecanismo de comunicación para su ejército, continuando su malvado plan………“TRATAR DE CONQUISTAR AL MUNDO!!!!”

Introducción a Spring Framework

noreply@blogger.com (José Luis Coronel Cortés) — Sun, 20 Jul 2008 21:13:00 +0000

Spring es un framework open source creado por Rod Johnson, el cual fue inicialmente descrito en su libro “Expert One-on-One: J2EE Design and Development”. El objetivo de Rod Johnson era implementar un framework que permitiese desarrollar aplicaciones empresariales de manera más fácil y rápida, utilizando POJOs (Plain Old Java Object) para lograr cosas que antes eran solamente posibles con EJBs.

Uno de los principales objetivos de Spring es no ser intrusito. Esto quiere decir, que aquellas aplicaciones configuradas para utilizar “Beans” mediante Spring no necesitan depender de interfaces o clases de Spring, obteniendo su configuración a través de las propiedades de sus "Beans".

Este concepto puede ser aplicado a cualquier entorno, desde una aplicación J2EE hasta un applet.

Spring está compuesto por un conjunto características, las cuales están agrupadas en seis módulos principales:

El paquete “Core” es la parte más fundamental del framework ya que provee a este, las características de Inversión de Control (IoC) y Inyección de dependencias (ID). El concepto básico dentro del “Core” es el “BeanFactory”, el cual provee una sofisticada implementación del “Patrón Factory”, que remueve la necesidad generalizada de “Singletons” y nos permite desacoplar la configuración y especificación de las dependencias de nuestra lógica de programación.

El paquete “Context” está construido sobre una solida base provista por el paquete “Core”, el cual proporciona un medio de acceso a los objetos contenidos en el framework de forma tal, que recuerda en cierta medida a la manera en cómo trabaja el registro JNDI. Este paquete hereda algunas características del paquete “Beans” y añade soporte para internacionalización (I18N), propagación de eventos, carga de recursos y la transparente creación de contextos, como por ejemplo, un “Servlet Container”.

El paquete “DAO” provee una capa de abstracción a JDBC, eliminando la tediosa codificación propia de JDBC y el parseo de los códigos de errores específicos de cada proveedor de base de datos. Así también, este paquete proporciona mecanismos de manejo de transacciones tanto programáticamente como declarativamente, cuyo manejo no está restringido a clases que implementen algún tipo de interfaz especial, sino que también está pensado para cualquiera de nuestros POJOs.

El paquete “ORM” provee una capa de integración con las APIs más populares de “Mapeo Objeto-Relacional”, tales como JPA, JDO, Hibernate y iBatis. Usando este paquete nosotros pidremos utilizara cualquiera de estos ORM en combinación con todas las otras características que Spring ofrece.

El paquete “AOP” de Spring, provee una implementación para la programación “Orientada a Aspectos” compatible con el “AOP Alliance” que nos permite definir, por ejemplo, interceptores a un método (method-interceptors) y puntos de corte (pointcuts) para desacoplar limpiamente algunas funcionalidades implementadas en el código que lógicamente deberían conversar por separado.

El paquete “Web” de Spring provee características de integración orientadas a la Web, tales como funcionalidades para la carga de archivos, la inicialización del contenedor IoC usando “Servlet Listeners” y un contexto de aplicación orientado a la web.

El paquete “MVC” de Spring, provee una implementación del patrón MVC (Moldeo-Vista-Controlador) para las aplicaciones web. Spring MVC provee una limpia separación entre el código del modelo de dominio y los formularios web, integrándose a todas las otras características que este framework entrega.

Ejemplo Basico

Para poder comenzar a desarrollar en Spring lo primero que necesitamos es descargarnos la versión 2.5.5 desde www.springframework.org.

En la sección de “download” encontraran tres tipo de archivos a descargar: Spring 2.5.5 (spring-framework-2.5.5.zip), Spring 2.5.5 incluyendo la documentación (spring-framework-2.5.5-with-docs.zip) y Spring 2.5.5 incluyendo todas las dependencias (spring-framework-2.5.5-with-dependencies.zip). Para este ejemplo y los futuros ejemplos, necesitaremos la última de estas tres opciones.

Una vez descargados los archivos, procedemos a crear el proyecto. Para este caso, tenemos varias opciones: podemos utilizar Netbeans 6.x el cual ya incluye soporte para Spring, Eclipse 3.x al cual se le debe instalar Spring IDE o IntelliJ el cual también incluye soporte para Spring.

En este caso utilizare IntelliJ para los ejemplos.

Primero creamos el proyecto seleccionado la opción “File --> New Project…”. Luego seleccionamos la opción “Create Project from scratch” y presionamos el botón “Next”.

A continuación, ingresamos el nombre del proyecto, que para nuestro caso será “SpringBasico” y presionamos el botón “Next”.

Luego, seleccionamos la opción “Create source Directory” y presionamos el botón “Next”.

Por último, seleccionamos que la tecnología deseada para utilizar en el proyecto es “Spring” y presionamos el botón “Finish”. Con lo que se nos construirá la estructura básica de nuestro proyecto.

El único problema, es que la última versión de IntelliJ IDEA solamente tiene soporte hasta la versión 2.0.7 de Spring, razón por la cual necesitaremos cambiar la librería “Spring.jar” por la versión que nosotros descargamos.

Para esto, nos posicionamos sobre el proyecto, presionamos el botón derecho del mouse y seleccionamos la opción “Module Settings”.

Luego, en las opciones de “Project Settings” seleccionamos “Libraries”. Es aquí donde cambiaremos el nombre de nuestro paquete de librerías y modificaremos el “Spring.jar”.

El primer paso será cambiar el nombre del paquete “Spring-2.0.7” por “Spring-2.5.5”. Luego, seleccionamos la ruta del archivo “Spring.jar” y presionamos el botón “Detach”. Por último, presionamos el botón “Attach Classes…”, seleccionamos el archivo “Spring.jar” que se encuentra en la carpeta “dist” de la versión que descargamos anteriormente y presionamos el botón “Ok”.

Para finalizar, presionamos el botón “Apply” para que confirme y actualice todos los cambios, y presionamos el botón “OK”.

El último cambio lo deberemos realizar sobre el archivo “spring-config.xml”. Como IntelliJ solamente tiene soporta para Spring 2.0.7, la definición XSD de este archivo es para la versión 2 de Spring. Por esta razón, deberemos cambiar esta por la versión 2.5.

Para nuestro primer ejemplo, desarrollaremos una idea simple que nos permita ver algunos de los beneficios básicos de Spring.

Imaginemos que necesitamos construir un robot, al cual le ensamblaremos un par de piernas, un par de brazos y una cabeza. Una primera propuesta a nuestro problema sería la siguiente:

El problema con esta implementación es que el código esta “Altamente Acoplado”. Que sucedería si decidimos cambiar la implementación de un brazo? No solamente tendríamos que modificar la clase “BrazoImpl”, sino también la clase “RobotImpl”. Es aquí donde la inversión de control “IoC” y la inyección de dependencias “ID” nos ayudan (más información de IoC y ID la pueden encontrar aquí).

El primer cambio que tendremos que realizar al código, es que cada pieza del robot deberá implementar una interfaz, con lo cual estaremos definiendo un contrato para cada una de estas piezas, y en el caso de que necesitemos diseñar un nuevo brazo o una nueva pierna, simplemente deberemos implementar la interfaz asociada al tipo de pieza.

Pero quien se encargara de ensamblar el robot? Aquí es donde Spring entra en acción. En el archivo “spring-config.xml” definiremos cada una de estas piezas como “Beans” de Spring.

<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xsi="http://www.w3.org/2001/XMLSchema-instance" p="http://www.springframework.org/schema/p" context="http://www.springframework.org/schema/context" schemalocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd"> <bean id="brazoD" class="cl.jug.spring.basico.paso2.BrazoImpl"> <property name="tipo" value="derecho"> </bean> <bean id="brazoI" class="cl.jug.spring.basico.paso2.BrazoImpl"> <property name="tipo" value="izquierdo"> </bean> <bean id="piernaD" class="cl.jug.spring.basico.paso2.PiernaImpl"> <property name="tipo" value="derecha"> </bean> <bean id="piernaI" class="cl.jug.spring.basico.paso2.PiernaImpl"> <property name="tipo" value="izquierda"> </bean> <bean id="cabeza" class="cl.jug.spring.basico.paso2.CabezaImpl"> <bean id="robot" class="cl.jug.spring.basico.paso2.RobotImpl"> <property name="brazoD" ref="brazoD"> <property name="brazoI" ref="brazoI"> <property name="piernaD" ref="piernaD"> <property name="piernaI" ref="piernaI"> <property name="cabeza" ref="cabeza"> </bean> </beans>

Como podemos observar, para definir un bean en Spring se utiliza el tag “bean”, al cual se le asigna un “id” único y la clase que define al bean.

Utilizando el tag “property” se puede inyectar un valor al bean. El atributo “name” es el nombre del atributo de la clase que tiene definido un método set en el bean, y el atributo “value”, es el valor que se le inyectara a este bean a través del método set.

Ahora, nuestra clase Test es mucho más simple:

Hasta aquí todo bien, pero.....……que sucedería si tuviéramos que definir 60 beans que representen a algunos objetos del dominio de nuestra aplicación, los que a su vez dependen de 15 objetos de servicios o cualquier otra cosa. Lo único que conseguiríamos sería un gran archivo XML con muchas definiciones de beans.

Una solución sería dividir este XML, en XMLs más pequeños, pero igual seguiríamos con el problema de que en la medida que se necesiten nuevos bean se seguirán definiendo nuevos archivos XML.

Con la versión de Spring 2.5 tenemos una mejor opción, el uso de anotaciones!!. En esta versión, Spring provee un conjunto de anotaciones que resuelven la dependencia de los objetos sin tener que utilizar XML.

Veamos un ejemplo de esto:

package cl.jug.spring.basico.paso3; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.beans.factory.annotation.Qualifier; import org.springframework.stereotype.Component; import javax.annotation.PostConstruct; @Component("robot") public class RobotImpl implements Robot{ @Autowired(required=true) @Qualifier("cabeza") private Cabeza cabeza; @Autowired(required=true) @Qualifier("brazo") private Brazo brazoD; @Autowired(required=true) @Qualifier("brazo") private Brazo brazoI; @Autowired(required=true) @Qualifier("pierna") private Pierna piernaD; @Autowired(required=true) @Qualifier("pierna") private Pierna piernaI; @PostConstruct public void inicializarTipos(){ brazoD.setTipo("derecho"); brazoI.setTipo("izquierdo"); piernaD.setTipo("derecha"); piernaI.setTipo("izquierda"); } public void moverRobot(){ cabeza.mover(); brazoD.mover(); brazoI.mover(); piernaD.correr(); piernaI.correr(); } public void setCabeza(Cabeza cabeza) { this.cabeza = cabeza; } public void setBrazoD(Brazo brazoD) { this.brazoD = brazoD; } public void setBrazoI(Brazo brazoI) { this.brazoI = brazoI; } public void setPiernaD(Pierna piernaD) { this.piernaD = piernaD; } public void setPiernaI(Pierna piernaI) { this.piernaI = piernaI; } }

La anotación "@ Autowired" le informa a Spring, que deberá inyectar automáticamente la dependencia, basado en el tipo definido como Autowired (para nuestro caso, las piezas del robot).

Spring también nos permite definir que objeto será inyectado basándose no solamente en su tipo, sino también utilizando el nombre del bean, a través de la anotación "@ Qualifier".

Pero como le definimos un nombre a los beans? Utilizando la anotación "@Component". Con esta anotación, registramos un nuevo bean que se encuentra disponible para ser inyectado por el contenedor de Spring.

Con estas anotaciones, ya no es necesario definir los "Beans" en un XML.

Ahora, solamente nos queda decirle a Spring, que los bean se encuentran definidos utilizando anotaciones, para lo cual nuestro XML de configuración se reduce a esto:

Para nuestro test utilizaremos JUnit integrado a Spring:

Con este simple ejemplo ya podemos ver algunos de los conceptos básicos de Spring.

En el próximo post veremos las diversas opciones de configuración de los Beans utilizando XML y algunos conceptos básicos del “Core” como el "BeanFactory".

Si alguien quiere mas información sobre el paquete “JDBC”, José Miguel Selman está desarrollando una excelente serie de artículos introductorios que pueden encontrar aquí.

El patrón "Memento" - Parte V

noreply@blogger.com (José Luis Coronel Cortés) — Tue, 08 Jul 2008 17:18:00 +0000

Cerebro se siente preparado para llevar a cabo su malvado plan. Tiene los conocimientos teóricos, tiene los conocimientos prácticos, pero hay tantos detalles que pulir antes de lanzarse a la conquista del mundo!.

En los ejemplos anteriores, hemos visto como Cerebro ha implementado el “Patron Prototype” (para crear su ejército de robots clones), el “Patron Extension Objects” (para asignarles sus roles), el “Patron Command” (para asignarles las ordenes), y el ”Patron Observer” (para implementar el sistema de comunicaciones). Parece que Cerebro ha estado bastante ocupado implementando patrones, pero ha sido suficiente?. NO!!.

Si recuerdan el “Patron Observer”, dejamos a los robots “Mazinger Z” y “El Vengador” en el instante previo al ataque final. Están esperando a recibir la orden de ataque. Cada robot esta alerta, escuchando la radio, esperando escuchar la señal secreta, para abandonar su posición y lanzarse a cumplir las órdenes recibidas.

Cerebro está a punto de presionar el botón de "Atacar", cuando de repente se da cuenta de que algo no está bien. Qué pasa si me veo obligado a dar la orden de retirada a mis tropas?. No es que mi plan vaya a fallar (después de todo soy un genio del mal), pero ya se sabe, no se puede confiar en los subordinados, y que pasa si tengo que cancelar el ataque cuando mis huestes ya han comenzado a avanzar?.

Ciertamente, Cerebro es un genio. Se ha dado cuenta de un sutil error en su plan. Qué pasaría si tiene que dar la orden de cancelar el ataque cuando sus tropas ya han abandonado su posición inicial?. Bueno, ha implementado un mecanismo de comunicaciones, así que puede mandar la señal secreta de retirada, no?. Pero hay un problema; los robots “Mazinger Z” y “El Vengador” no implementan un buen sistema del manejo de la memoria (sabía que no tenía que instalarles Windows!!!!).

La cuestión es complicada. Un robot “Mazinger Z” y “El Vengador” no tienen buen manejo de la memoria. Solo pueden recordar una cosa a la vez. Por tanto, pueden recordar que tienen que atacar, que tienen que moverse hacia algún lugar, pero en cuanto se meten esa información en la memoria no son capaces de recordar nada más.

Dicho de otra forma, Cerebro les puede decir que vuelvan a su posición original, pero eso no va a servir de nada, porque no se acuerdan de cuál era su posición original.

Peeeeeero, Cerebro recuerda vagamente, como entre una nebulosa, haber leído algo del “Patron Memento” de su gurú “Martin Fowler”.

Qué pasaría si cada robot “Mazinger Z” y “El Vengador” fuera capaz de escribir en un cuaderno su posición inicial, y entregara ese cuaderno a su Sargento?. Y si el Sargento guardara esos cuadernos, y se los entregara a sus propietarios en el caso de que necesitasen volver a las posiciones iníciales?. Problema resuelto!. Es perfecto!. Las ovejas y las vacas solo tendrán que recordar una posición (la posición hacia la que se supone que tiene que ir, sin importar si están atacando o están en retirada), mientras una entidad externa les guardara la información que necesitaran para retirarse.

Pero cómo puede un robot “Mazinger Z” o “El Vengador” guardar su información relevante en un cuaderno?. Fácil, cada robot será responsable de crear una instancia de la clase en la que se va a guardar su información interna, y la entregara a su sargento.

Un momento!. Cerebro se ha dado cuenta de que hay un punto débil en su plan. Si el Sargento guarda los cuadernos con las posiciones iníciales de los robots, hay riesgos de seguridad. Qué pasa si los enemigos roban esa información?. O incluso peor!!. Y si los enemigos no roban esa información, pero la sustituyen por información falsa?. Pero……un momento!. Si la información contenida en los cuadernos estuviera encriptado, o solo fuera accesible por los robots, el problema estaría resuelto, nadie podría cambiarla!.

Por tanto, para evitar posibles cambios en esa información, Cerebro va a tomar dos medidas drásticas. Por un lado, todos los valores guardados en la clase MazingerZMemento solo se podrán asignar a través del constructor. De ese modo, Cerebro se asegura que solo se podrán asignar al crear la clase, y nunca después.

Pero desgraciadamente, no es suficiente (es tan difícil conseguir un buen plan…uffff). Cerebro quiere evitar que la información guardada en el “Memento” sea modificada. De hecho, quiere que solo sea el robot “Mazinger Z” o “El Vengador”, el que pueda crear su memento correspondiente, y asignar sus valores. De esa forma, puede asegurarse de que nadie modifique esa información.

Hacer eso en Java es bastante fácil. Basta con colocar la clase MazingerZMemento en el mismo package que la clase "MazingerZ", y hacer tanto su constructor como sus variables de clase protected. De esa forma, solo pueden crear instancias de esa clase otras clases que estén en su mismo paquete.

Por tanto la clase “MazingerZ” es:

Cerebro lo ha conseguido de nuevo!!. Ha sido capaz de encapsular el estado interno de un objeto en otro objeto distinto, y encapsularlo tan bien que ese segundo objeto solo puede ser utilizado por el objeto que lo creo.

Ya está todo listo para conquistar al mundo!!!!!!!!

Parte 6

El patrón "Observer" (Observador) - Parte IV

noreply@blogger.com (José Luis Coronel Cortés) — Sat, 05 Jul 2008 18:55:00 +0000

Esta desencadenado!!!!! El primer ataque ha sido lanzado. Cerebro ha dado las órdenes a sus tropas para dominar el mundo.

En los ejemplos anteriores hemos visto como Cerebro ha conseguido clonar cualquier robot utilizando un “Patron Prototype”, ha conseguido darles un rol dinámicamente con el “Patron Extension Objects”, y ha repartido las ordenes con un “Patron command”.

Pero como ya sabemos, Cerebro está loco, pero no es tonto. Sabe, que algo puede salir mal, que un pequeño detalle puede destruir sus planes de dominar el mundo. Pero también sabe que una retirada a tiempo es una victoria.

Por lo tanto, ha equipado a sus tropas de una radio de comunicaciones. Pero, porque ha hecho esto?. Sencillo, en el fragor de la batalla, las comunicaciones directas se hacen complicadas. Es difícil hacer llegar las ordenes, y muchas veces no se tiene claro a quien le estamos dando esas órdenes ( será a “Mazinger Z” o “El Vengador”? ). Conquistar el mundo no es fácil, de hecho muchos lo han intentado pero no lo han conseguido.

Cerebro ha estudiado con detenimiento todos los intentos anteriores para no reproducir los mismos errores que otros han cometido. Qué pasaría si para dar nuevas órdenes, necesitase que el sargento “Mazinger Z” tuviese que recorrer la trinchera indicando uno por uno a todos los robots que se retirasen?. Desde que le diese la orden al primer robot, hasta que se la diese al último, pasaría un tiempo precioso. Además, y si ocurre algo por el camino?. Las posibilidades de que las órdenes no lleguen a todos los integrantes de la tropa son amplias.

Sabiendo esto, Cerebro recurre nuevamente a su gurú “Marin Fowler” y decide hacer un cambio fácil y rápido el comportamiento de sus tropas, utilizando el “Patron Observer”.

Como Cerebro no es tonto, ha encontrado una malvada forma de enviar las órdenes a sus tropas. Los robots “Mazinger Z” y “El Vengador”, estarán equipados con una radio que sintoniza “La señal del mal”. Sus tropas estarán atentas a la radio, y cuando esta emita una canción de “Metallica” les indicara que acción deben tomar.

El código sería algo así:

package observer.paso1; import java.util.ArrayList; public class Cerebro implements Sujeto { private ArrayList misObservadores; private Mensaje mensaje; public Cerebro(){ mostrar("Creando a Cerebro"); misObservadores = new ArrayList(); } public void mostrar(String arg){ System.out.println("Cerebro : "+arg); } public void addObservador(Observador observador){ mostrar("Anadido un nuevo Observador"); misObservadores.add(observador); mostrar("Ya tengo : " + misObservadores.size() + " observadores "); } public void removerObservador(Observador observador){ mostrar("Eliminando un observador"); misObservadores.remove(observador); mostrar("ahora me quedan : " + misObservadores.size() + " observadores "); } public void notificarObservador(){ mostrar("notificar observador"); mensaje = new Mensaje(); mensaje.setMensaje("En la nave"); for( int i = 0; i < misObservadores.size(); i++ ){ Observador observador = (Observador) misObservadores.get(i); observador.actualizar(mensaje); } } }

De este modo, Cerebro se puede comunicar rápidamente con todas sus tropas. Es brillante, es genial, es maravilloso, es.........perfecto?. Bueno, la verdad es que está muy bien, pero imaginemos por un momento, una situación en la que un robot consigue infiltrarse en el alto mando enemigo, y descubre que el enemigo está a punto de ser derrotado, y justo en ese momento de éxtasis, la radio emite “The Call of Ktulu" (la canción que indica a las tropas que hay que retirarse).

NOOOOOOOOO (bueno, esto está traducido, claramente, un robot diría algo así como BEP-BEP-BEP). Nuestro robot espía, tiene una información valiosísima, pero que no puede comunicar a su alto mando, porque la forma de transmisión es únicamente de tipo “Push” (desde Cerebro a sus tropas), por lo que no hay retorno.

Qué situación, el robot necesita transmitir que el ataque debe continuar pero......jajajajajajajaja, Cerebro ha pensado en ello, y ha decidido implementar un “Patron observer” que permita la transmisión tipo “Push” (del sujeto emisor a todos los sujetos receptores) y tipo “Pull” (uno de los objetos receptores, puede solicitar una información al objeto emisor para que este la envié a todos los demás). Así, nuestro robot espía, estará equipado con un número de teléfono al que podrá llamar y solicitar que emitan "Master of Puppets", y cuando esta canción sea emitida por la radio, los robots “Mazinger Z” y “El Vengador” que la escuchen, sabrán que ha llegado el momento de la ofensiva final!!!. Para ello, Cerebro deberá modificar ligeramente su código.

El primer paso será que nuestro sujeto, implementara un nuevo método que hemos añadido a la interfaz Sujeto( solicitarInformacion ), que permitirá recibir las llamadas telefónicas del robot espía. Veremos también que el constructor de los robots “Mazinger Z” y “El Vengador” también ha cambiado un poco. Ahora estos robots, almacenaran una referencia al constructor. También modificaremos el código de nuestro robot “Mazinger Z” (suponemos que este será el robot espía en el momento en que decide que pese a lo que emite la radio, hay que atacar y pide que se emita “Master of Puppets” que es otra señal de ataque ).

El código final sería algo así:

package observer.paso2; import java.util.ArrayList; import observer.paso1.Mensaje; import observer.paso1.Observador; public class Cerebro implements Sujeto{ private ArrayList misObservadores; public Cerebro(){ mostrar("Creando un nuevo Cerebro"); misObservadores = new ArrayList(); } public void mostrar(String arg){ System.out.println("Cerebro : "+arg); } public void addObservador(Observador obs){ mostrar("Anadido un nuevo observador"); misObservadores.add(obs); mostrar("Ya tengo : " + misObservadores.size() + " observadores "); } public void removerObservador(Observador obs){ mostrar("Eliminando observador"); misObservadores.remove(misObservadores.indexOf(obs)); mostrar("ahora me quedan : " + misObservadores.size() + " observadores "); } public void notificarObservador(Mensaje msg ){ mostrar("notificar observadores"); for( int i = 0; i < misObservadores.size(); i++ ){ Observador obs = (Observador) misObservadores.get(i); obs.actualizar(msg); } } public void solicitarInformacion(String arg){ mostrar("recibiendo una peticion"); Mensaje mensaje = new Mensaje(); mensaje.setMensaje(arg); this.notificarObservador(mensaje); } }

Evidentemente, Cerebro que ha estudiado la API de JAVA y sabe que existe la clase java.util.Observable y la interface java.util.Observer. La primera no la ha utilizado, pues eso implicaría que Cerebro extienda o herede de “Observable”. Esto podría ser posible, pero en realidad Cerebro extiende de una larga extirpe de profesores diabólicos empeñados en conquistar el mundo, y ni quiere ni puede extender de Observable. ( class Cerebro extends ExtirpeDeProfesoresDiabolicos, Observable --> esto no es posible ). Por eso ha decidido construirse su propia interface “Sujeto”.

Con respecto a la interface java.util.Observer, si la podría haber utilizado para que sus robots “Mazinger Z” y “El Vengador” la implementasen en lugar de implementar “Observador”, pero ya saben, los genios del mal les gusta hacer las cosas a su manera.

Esta historia continuara……

PARTE 5

El patrón "Command" - Parte III

noreply@blogger.com (José Luis Coronel Cortés) — Thu, 03 Jul 2008 23:40:00 +0000

Todo está preparado. Cerebro ya cuenta con un gran número de copias de los robots “Mazinger Z” y “El Vengador”. Además, ha asignado los roles a cada uno de estos. Es el momento perfecto para que Cerebro lance su ataque final. Ha llegado el momento de conquistar el mundo!!!!

Pero como dará Cerebro la orden de atacar a sus tropas?.

Cerebro está loco, pero no es idiota. Quiere conquistar el mundo, para lo cual ha ideado un plan malvado perfecto!!!. Pero sabe que tener un buen plan (aunque sea malvado) no es una garantía para el éxito. Necesita un plan de emergencia.

Cerebro quiere que algunos de sus robots soldados participen en el primer (y por tanto, glorioso) ataque. Pero también quiere reservar unos cuantos robots soldados y dejarlos descansando, mientras sus colegas son masacrados en el campo de batalla, para que puedan ser utilizados como refuerzos.

Pero, como podrá hacerlo?. Cerebro es un genio muuuuuy ocupado, por lo tanto el ataque debe poder ser lanzado sin mucha intervención de su parte. Algo tan simple como apretar el botón de "Dominar el Mundo" sería perfecto. Es rápido, es fácil, y Cerebro puede delegar la tarea incluso a Pinky.

Eso sería perfecto, pero para conseguirlo tiene que encontrar la forma de poderle decir a cada robot que es lo que se supone que debe hacer cuando el "glorioso momento del ataque" llegue.

Pero cómo ?. El unico conocimiento que tiene Cerebro de los robots soldados es su interfaz, porque sabe que cada robot soldado implementa la interfaz AccionSoldado.

Resumiendo, lo que en realidad necesita es que algunos robots ejecuten uno de los métodos de AccionSoldado, y otros robots ejecuten uno distinto cuando reciban la orden de atacar.

Tanto la interfaz AccionSoldado como la clase RolSoldado no han cambiado.

Cerebro ha logrado crear diez mil robots soldados, y diez mil robots fabricantes, utilizando dos arrays para almacenar una referencia a todos ellos.

Por tanto, al apretar el botón de "Al ataqueeeeeeeeeeeeeee" podría hacer algo así…..

Cerebro está loco, pero no es un tonto. No le gusta la solución que ha encontrado. Por que?. Bueno, no es exactamente lo que quería. Cerebro simplemente quiere poder decir "Al ataqueeeeeeeee", y comenzar a reírse histéricamente mientras los robots se lanzan ciegamente a cumplir sus órdenes.

Cerebro sospecha que todo podría ser mucho más fácil si pudiera darle a cada uno de los robots un sobre conteniendo sus órdenes. Cuando el "Momento de gloria" llegue, simplemente le tendría que decirle a cada robot que habrá el sobre y obedezca las ordenes contenidas en el. Pero él no quiere saber de qué forma tienen que cumplir esas órdenes los robots, de hecho, ni siquiera quiere saber si le está mandando algo a un robot “Mazinger Z” o “El Vengador”, o a lo que sea.

Pero justo en ese momento, comienza a reírse con más fuerza que nunca. Porque ha recordado el patrón Command.

Cerebro quiere dar cuatro órdenes diferentes. Dos para ser obedecidas por los robots soldado ("ataca", y "espera hasta recibir nuevas órdenes"), y las otras dos dirigidas a los robots fabricantes ( "comienza a construir la fortaleza", y "diseña armas" ).

Para esto, va a encapsular la orden y el receptor de dicha orden, en un paquete ( el sobre ). Cómo?....

En primer lugar, escribirá la siguiente interfaz:

Y los distintos comandos serán…..

Por tanto, cuando Cerebro presione el botón de "al ataqueeeeeeeeee", tendrá que hacer un método algo así:

Este método recibe como parámetro un array conteniendo todos los comandos. Ese array se podría construir con un código similar a este…..

package command.paso4; import command.paso1.AccionSoldado; import command.paso1.RolSoldado; import extensionobject.paso1.AccionFabricante; import extensionobject.paso1.RolFabricante; import command.paso3.SoldadoAtacar; import command.paso3.SoldadoEsperar; import command.paso3.CommandActions; import command.paso3.FabricanteConstruir; import command.paso3.FabricanteDisenar; import extensionobject.paso2.MazingerZ; public class Disparar { public Disparar() { } public void atacar(CommandActions aLasArmas[]) { int contRobots = aLasArmas.length; for (int idx = 0; idx < contRobots; idx++) { aLasArmas[idx].ejecutar(); } } public static void main(String[] args) { MazingerZ mazingerZ = null; CommandActions aLasArmas[] = new CommandActions[20]; AccionSoldado accionSoldado = null; AccionFabricante accionFabricante = null; SoldadoAtacar soldadoAtacar = null; SoldadoEsperar soldadoEsperar = null; FabricanteConstruir fabricanteConstruir = null; FabricanteDisenar fabricanteDisenar = null; for (int i = 0; i < 5; i++) { mazingerZ = new MazingerZ(); mazingerZ.addExtension("RolSoldado", new RolSoldado(mazingerZ)); accionSoldado = (AccionSoldado) mazingerZ.getExtension("RolSoldado"); soldadoAtacar = new SoldadoAtacar(accionSoldado); aLasArmas[i] = soldadoAtacar; } for (int i = 5; i < 10; i++) { mazingerZ = new MazingerZ(); mazingerZ.addExtension("RolSoldado", new RolSoldado(mazingerZ)); accionSoldado = (AccionSoldado) mazingerZ.getExtension("RolSoldado"); soldadoEsperar = new SoldadoEsperar(accionSoldado); aLasArmas[i] = soldadoEsperar; } for (int i = 10; i < 15; i++) { mazingerZ = new MazingerZ(); mazingerZ.addExtension("RolCampesino", new RolFabricante(mazingerZ)); accionFabricante = (AccionFabricante) mazingerZ.getExtension("RolCampesino"); fabricanteConstruir = new FabricanteConstruir(accionFabricante); aLasArmas[i] = fabricanteConstruir; } for (int i = 15; i < 20; i++) { mazingerZ = new MazingerZ(); mazingerZ.addExtension("RolCampesino", new RolFabricante(mazingerZ)); accionFabricante = (AccionFabricante) mazingerZ.getExtension("RolCampesino"); fabricanteDisenar = new FabricanteDisenar(accionFabricante); aLasArmas[i] = fabricanteDisenar; } //A LA TAQUE!!!! System.out.println("*******************************************"); Disparar cerebro = new Disparar(); cerebro.atacar(aLasArmas); } }

El código es horrible, pero sirve para ilustrar como Cerebro ha creado una colección de objetos, cada uno de los cuales encapsula un comando y el receptor de dicho comando.

Ahora, Cerebro no necesita saber nada acerca de esos comandos, ni del receptor de los mismos. Simplemente tiene que decir "ejecutar el comando!!", y el comando hará el resto.

De hecho, Cerebro ha conseguido desacoplar tres procesos diferentes: la creación de los objetos (implementando el patrón Prototype ), la asignación de roles a esos objetos ( con el patrón Extension Objects ), y la forma en que esos roles pasan a la acción ( el patron Command ).

Con esto, ha dado un paso más en su malvado plan de CONQUISTAR AL MUNDO!!!!!

PARTE 4

Tutorial de Tomcat en Cluster

noreply@blogger.com (José Luis Coronel Cortés) — Tue, 24 Jun 2008 01:30:00 +0000

Lo primero que necesitaremos será descargar el servidor Web Apache para poder hacer el balanceo de carga (Load Balancing) y la compartición de carga (Load Sharing).

Para esto, descargaremos el archivo apache_2.2.9-win32-x86-no_ssl-r2.msi desde aquí. Una vez descargado, procedemos a la instalación.

Ya instalado el servidor Web Apache, deberemos proceder a instalar Tomcat y definir el tipo de cluster a implementar.

Existen dos tipos de cluster que podemos construir en Tomcat: cluster vertical (en una sola maquina) o cluster horizontal (en muchas maquinas).

Cluster vertical

El primer paso será la instalación de Tomcat, para lo que deberemos bajar el archivo apache-tomcat-6.0.9.exe desde aquí.

Una vez descargado el archivo, procederemos instalar Tomcat. Para este ejemplo, vamos a simular que el cluster está compuesto por tres nodos, por lo tanto, necesitaremos instalar tres instancias de Tomcat las cuales llamaremos: TomcatNodo1, TomcatNodo2 y TomcatNodo3.

El paso que realizaremos a continuación deberemos repetirlo para cada nodo.

Una vez instalado los tres nodos, deberemos realizar una pequeña modificación al archivo server.xml de cada uno de los nodos. Este archivo se encuentra en la carpeta "conf" de cada uno de los nodos.

Para cada uno de los server.xml deberemos realizar los siguientes cambios:

Cambiar los puertos

 <server port="XXXX" shutdown="SHUTDOWN"> <connector port="XXXX" protocol="HTTP/1.1" connectiontimeout="20000" redirectport="8443"> <connector port="XXXX" protocol="AJP/1.3" redirectport="8443">

Agregamos el “jvmRoute” para cada caso.

 <engine name="Catalina" defaulthost="localhost" jvmroute="tomcatNodoX"> 

Descomentamos el tag “cluster”

 <cluster classname="org.apache.catalina.ha.tcp.SimpleTcpCluster"> 

Nodo1

  <server port="8015" shutdown="SHUTDOWN">  <listener classname="org.apache.catalina.core.AprLifecycleListener" sslengine="on">  <listener classname="org.apache.catalina.core.JasperListener">  <listener classname="org.apache.catalina.mbeans.ServerLifecycleListener"> <listener classname="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener">  <globalnamingresources>  <resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" pathname="conf/tomcat-users.xml"> </globalnamingresources>  <service name="Catalina">  <connector port="8081" protocol="HTTP/1.1" maxthreads="150" connectiontimeout="20000" redirectport="8443">    <connector port="8109" protocol="AJP/1.3" redirectport="8443">   <engine name="Standalone" defaulthost="localhost" jvmroute="tomcatNodo1"> <engine name="Catalina" defaulthost="localhost">  <cluster classname="org.apache.catalina.ha.tcp.SimpleTcpCluster">    <realm classname="org.apache.catalina.realm.UserDatabaseRealm" resourcename="UserDatabase">  <host name="localhost" appbase="webapps" unpackwars="true" autodeploy="true" xmlvalidation="false" xmlnamespaceaware="false">     </host> </engine> </service> </server> 

Nodo2

  <server port="8205" shutdown="SHUTDOWN">  <listener classname="org.apache.catalina.core.AprLifecycleListener" sslengine="on">  <listener classname="org.apache.catalina.core.JasperListener">  <listener classname="org.apache.catalina.mbeans.ServerLifecycleListener"> <listener classname="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener">  <globalnamingresources>  <resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" pathname="conf/tomcat-users.xml"> </globalnamingresources>  <service name="Catalina">  <connector port="8082" protocol="HTTP/1.1" maxthreads="150" connectiontimeout="20000" redirectport="8443">    <connector port="8209" protocol="AJP/1.3" redirectport="8443">   <engine name="Standalone" defaulthost="localhost" jvmroute="tomcatNodo2"> <engine name="Catalina" defaulthost="localhost">  <cluster classname="org.apache.catalina.ha.tcp.SimpleTcpCluster">    <realm classname="org.apache.catalina.realm.UserDatabaseRealm" resourcename="UserDatabase">  <host name="localhost" appbase="webapps" unpackwars="true" autodeploy="true" xmlvalidation="false" xmlnamespaceaware="false">     </host> </engine> </service> </server> 

Nodo3

  <server port="8305" shutdown="SHUTDOWN">  <listener classname="org.apache.catalina.core.AprLifecycleListener" sslengine="on">  <listener classname="org.apache.catalina.core.JasperListener">  <listener classname="org.apache.catalina.mbeans.ServerLifecycleListener"> <listener classname="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener">  <globalnamingresources>  <resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" pathname="conf/tomcat-users.xml"> </globalnamingresources>  <service name="Catalina">  <connector port="8083" protocol="HTTP/1.1" maxthreads="150" connectiontimeout="20000" redirectport="8443">    <connector port="8309" protocol="AJP/1.3" redirectport="8443">   <engine name="Standalone" defaulthost="localhost" jvmroute="tomcatNodo3"> <engine name="Catalina" defaulthost="localhost">  <cluster classname="org.apache.catalina.ha.tcp.SimpleTcpCluster">    <realm classname="org.apache.catalina.realm.UserDatabaseRealm" resourcename="UserDatabase">  <host name="localhost" appbase="webapps" unpackwars="true" autodeploy="true" xmlvalidation="false" xmlnamespaceaware="false">     </host> </engine> </service> </server> 

Con estos cambios ya tenemos configurado nuestro cluster vertical.

Cluster Horizontal

La configuración de un cluster horizontal es un poco más fácil ya que no es necesario realizar cambios a los puertos.

Para cada uno de los archivos server.xml se debe realizar los siguientes cambios:

Agregamos el “jvmRoute” para cada caso (igual que para el cluster vertical)

 <engine name="Catalina" defaulthost="localhost" jvmroute="tomcatNodoX"> 

Descomentamos el tag “cluster” (igual que para el cluster vertical)

 <cluster classname="org.apache.catalina.ha.tcp.SimpleTcpCluster"> 

Configuración del cluster con Apache

Una vez configurado el tipo de cluster (Horizontal o Vertical), vamos a construir una pequeña aplicación de ejemplo.

El primer paso será definir en el web.xml de la aplicación el tag <distributable /> para activar el intercambio de la sesión a través de la instancia del cluster.

 <?xml version="1.0" encoding="ISO-8859-1"?> <web-app xmlns="http://java.sun.com/xml/ns/javaee" xsi="http://www.w3.org/2001/XMLSchema-instance" schemalocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5"> <distributable> </web-app> 

Ahora necesitaremos integrar el servidor web Apache con Tomcat instalando el modulo mod_jk. Para esto, deberemos descargar el archivo mod_jk-1.2.26-httpd-2.2.4.so desde aquí y dejarlo en la carpeta “modules” de Apache.

Ya instalado el mod_jk, deberemos editar el archivo httpd.conf que está en la carpeta “conf” con las siguientes líneas:

 LoadModule jk_module modules/mod_jk-1.2.26-httpd-2.2.4.so JkWorkersFile "C:\Archivos de programa\Apache Software Foundation\Apache2.2\conf\workers.properties" JkLogFile "logs/mod_jk.log" JkLogLevel error JkMount /cluster loadbalancer JkMount /cluster/* loadbalancer 

Ahora deberemos crear el archivo workers.properties dentro de la carpeta “conf” del Apache. En este archivo definiremos las propiedades para cada una de las instancias de Tomcat a ejecutar.

En el caso de que nuestro cluster sea vertical, el archivo de propiedades deberá contener lo siguiente:

 workers.tomcat_home=/tomcatNodo1 workers.java_home=$JAVA_HOME ps=/ worker.list=tomcatNodo1,tomcatNodo2,tomcatNodo3,loadbalancer worker.tomcatNodo1.port=8109 worker.tomcatNodo1.host=localhost worker.tomcatNodo1.type=ajp13 worker.tomcatNodo1.lbfactor=1 worker.tomcatNodo2.port=8209 worker.tomcatNodo2.host=localhost worker.tomcatNodo2.type=ajp13 worker.tomcatNodo2.lbfactor=1 worker.tomcatNodo3.port=8309 worker.tomcatNodo3.host=localhost worker.tomcatNodo3.type=ajp13 worker.tomcatNodo3.lbfactor=1 worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=tomcatNodo1,tomcatNodo2,tomcatNodo3 worker.loadbalancer.sticky_session=1 

Para el caso de que el cluster sea horizontal deberemos definir el host para cada uno de los nodos del cluster:

 workers.tomcat_home=/tomcatNodo1 workers.java_home=$JAVA_HOME ps=/ worker.list=tomcatNodo1,tomcatNodo2,tomcatNodo3,loadbalancer worker.tomcatNodo1.port=8009 worker.tomcatNodo1.host=192.168.1.1 worker.tomcatNodo1.type=ajp13 worker.tomcatNodo1.lbfactor=1 worker.tomcatNodo2.port=8009 worker.tomcatNodo2.host=192.168.1.2 worker.tomcatNodo2.type=ajp13 worker.tomcatNodo2.lbfactor=1 worker.tomcatNodo3.port=8009 worker.tomcatNodo3.host=192.168.1.3 worker.tomcatNodo3.type=ajp13 worker.tomcatNodo3.lbfactor=1 worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=tomcatNodo1,tomcatNodo2,tomcatNodo3 worker.loadbalancer.sticky_session=1 

Uno de los atributos más importantes es “Ibfactor”, el cual define el factor para el balanceo de carga, restringiendo el numero de “request” a enviar a una instancia particular de Tomcat.

Por último, crearemos unas páginas JSP para cada uno de los nodos, con los cuales validaremos que el cluster este funcionado correctamente.

TomcatNodo1

 <% session.setAttribute("dukechile","dukechile"); %> <html> <head> <title>DukeChile - Culster</title> </head> <body> <table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr bgcolor="#CCCCCC"> <td width="13%">Tomcat Nodo 1</td> <td width="87%"> </td> </tr> <tr> <td>Session ID :</td> <td><%=session.getId()%></td> </tr> </table> </body> </html> 

TomcatNodo2

 <% session.setAttribute("dukechile","dukechile"); %> <html> <head> <title>DukeChile - Culster</title> </head> <body> <table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr bgcolor="#CCCCCC"> <td width="13%">Tomcat Nodo 2</td> <td width="87%"> </td> </tr> <tr> <td>Session ID :</td> <td><%=session.getId()%></td> </tr> </table> </body> </html> 

TomcatNodo3

 <% session.setAttribute("dukechile","dukechile"); %> <html> <head> <title>DukeChile - Culster</title> </head> <body> <table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr bgcolor="#CCCCCC"> <td width="13%">Tomcat Nodo 3</td> <td width="87%"> </td> </tr> <tr> <td>Session ID :</td> <td><%=session.getId()%></td> </tr> </table> </body> </html> 

Por último, se debe reiniciar el Apache y luego iniciar cada una de las instancias del Tomcat.

Una vez los nodos estén iniciados, ejecutaremos la página cluster.jsp y validaremos el ID de la sesión asignada además del nombre del nodo que atendió la petición.

Recargamos nuevamente la pagina, y validamos que el ID de la sesión siga siendo la misma, con esto, validamos que el cluster este funcionado correctamente.

Si necesitan ajustar mejor la configuración del cluster, les recomiendo el libro “PROFESIONAL APACHE TOMCAT 6”.

El patrón “Extension Objects” - Parte II

noreply@blogger.com (José Luis Coronel Cortés) — Sun, 22 Jun 2008 00:14:00 +0000

En el episodio anterior, Cerebro logro programar una máquina capaz de crear muchas copias de robots, logrando construir un gran ejército para CONQUISTAR AL MUNDO!!!.

Pero de repente, se dio cuenta que va a necesitar muchos robots del tipo “Mazinger Z” y también del tipo “El Vengador”, pero no todos los robots deberían tener el mismo rol. Por qué?. Bueno, dominar el mundo no es fácil. Hace falta organización. Hace falta un malvado plan!.

Entonces Cerebro ideo un plan. Quiere entrenar a algunos de sus robots como soldados para crear maquinas de matar sin misericordia!!!!.

Pero también quiere que otros robots trabajen en las fábricas haciendo armas, y también necesita que otro grupo de robots trabaje en la construcción de una fortaleza…….ufff.

Por lo tanto, se puede decir que necesita poder asignar distintos roles a los robots que ha construido.

Entonces, Cerebro comienza a pensar…….muy bien, ya tengo una clase que representa un robot “Mazinger Z”, pero ahora necesito tener un “Mazinger Z” que se comporte como un soldado, otro que se comporte como un fabricante, otro como constructor y lo mismo para “El Vengador”. Eso suena a "extender la funcionalidad de una clase", o no?....Brillante!!.

Escribiré una clase “MazingerZSoldado” que extienda a “MazingerZ”, y otra clase, “MazingerZFabricante”, que también extienda a “MazingerZ”.

Pero antes de ponerse a escribir código, Cerebro se da cuenta que probablemente esa no sea la mejor solución, porque cada vez que quiera asignar un nuevo rol a una robot, tendrá que escribir una nueva subclase (por ejemplo, una “MazingerZIngeniero”, o una “MazingerZConstructor”).

Además, el no sabe a priori cuantos roles va a necesitar asignar a un robot. Todo depende de lo que necesite en el futuro. Necesita dar soporte a la adición de interfaces desconocidas a la clase “MazingerZ”.

También se da cuenta que su primera forma de atacar el problema tiene otro punto débil, y es que no podrá re-asignar un rol. Si crea un “MazingerZSoldado”, tendrá esta para siempre, aunque la necesite para construir nuevos robots.

Pero también se da cuenta de otro punto débil, este es mucho más sutil. Una clase “MazingerZSoldado” y una “MazingerZ” son exactamente lo mismo. La única diferencia es que una de ellas tiene un comportamiento particular, pero en esencia, son lo mismo. Por tanto, no es muy apropiado representarlas utilizando clases distintas.

Cerebro está loco, pero no es tonto. Por tanto, decide que ha encontrado demasiados puntos débiles para su idea inicial, y que por tanto, es el momento de acudir al patrón “Extension Objects”.

Este patrón intenta anticipar la extensión de la interfaz de un objeto en el futuro (eso quiere decir: se pueden añadir interfaces a una clase en tiempo de ejecución). Así que empieza a leer, y a reírse. Y cuanto más lee, mas se ríe.

La idea es muy sencilla. Una clase (MazingerZ) será capaz de cambiar la interfaz que implementa en tiempo de ejecución, seleccionando esa interfaz de entre una colección de objetos ( los Extension Objects ). Cada uno de esos objetos encapsularan uno de los roles (MazingerZSoldado, MazingerZFabricante,... ).

Pero como será capaz la clase “MazingerZ“ de seleccionar la interfaz a implementar? Y de igual manera la clase “ElVengador”?. Bien, ambas clases implementaran la siguiente interfaz.

La clase “MazingerZ” implementa una interfaz para encapsular las acciones que implementa por ser un robot (mover la cabeza, mover las piernas, los brazos).

package extensionobject.paso1; public class MazingerZ implements Sujeto, AccionesBasicas{ private RolSoldado rolSoldado; private RolFabricante rolFabricante; public MazingerZ() { System.out.println("Creada la plantilla de Mazinger Z"); } public Rol getExtension(String nombreExt) { Rol retornarValor = null; if( nombreExt.equals("RolSoldado") ){ if( rolSoldado == null ){ retornarValor = new RolSoldado(this); } else{ retornarValor = rolSoldado; } } else if( nombreExt.equals("RolFabricante") ){ if( rolFabricante == null ){ retornarValor = new RolFabricante(this); } else{ retornarValor = rolFabricante; } } return retornarValor; } public void moverBrazos() { System.out.println("Mazinger Z mueve los brazos"); } public void moverPiernas() { System.out.println("Mazinger Z mueve las piernas"); } public void moverCabeza() { System.out.println("Mazinger Z mueve la cabeza"); } }

Fíjense como la clase “MazingerZ” implementa el método “getExtension”, que elige la clase que debe devolver de entre una colección de roles (que son variables de la clase). Y los roles ?.

Para ese caso está la clase abstracta Rol (no he implementado nada en el, pero cualquier funcionalidad común a los roles debería implementarse aquí).

Pero Cerebro no es tonto, y sabe que en algún momento necesitara cambiar los roles de sus Robots. En algún momento puede llegar a necesitar que los robots que tienen el rol fabricante deban pasar a tener el rol soldado. Sería posible construir un “MazingerZ” con distintos tipos de roles, y que estos puedan ser modificados en cualquier momento?.

Entonces Cerebro luego de estudiar mejor el patrón “Extension Objects” decide refactorizar su código.

package extensionobject.paso2; import extensionobject.paso1.AccionesBasicas; import extensionobject.paso1.Rol; import java.util.HashMap; public class MazingerZ implements Sujeto, AccionesBasicas { private HashMap rolesCol; public MazingerZ(){ System.out.println("Creada la plantilla de Mazinger Z"); rolesCol = new HashMap(); } public Rol getExtension(String nombreExt) { return (Rol) rolesCol.get(nombreExt); } public void addExtension(String nombreExt, Rol extension) { rolesCol.put(nombreExt, extension); } public void removerExtension(String nombreExt) { rolesCol.remove(nombreExt); } public void moverBrazos() { System.out.println("Mazinger Z mueve los brazos"); } public void moverPiernas() { System.out.println("Mazinger Z mueve las piernas"); } public void moverCabeza() { System.out.println("Mazinger Z mueve la cabeza"); } }

Ahora, los robots construidos por su máquina podrán cambiar su rol en tiempo de ejecución primero pueden ser soldados, luego fabricantes, mas tarde lo que a Cerebro le dé la gana).

Cerebro ha conseguido mantener la abstracción “MazingerZ” limpia de operaciones específicas para un robot. Eso también lo podría haber conseguido gracias a la herencia, definiendo las operaciones para los robots en las subclases, pero eso habría generado una jerarquía difícil de manejar.

Cerebro a dado un paso más en su plan de CONQUISTAR AL MUNDO!!!!!.

PARTE 3

El patron prototype (prototipo) - Parte I

noreply@blogger.com (José Luis Coronel Cortés) — Sun, 15 Jun 2008 17:03:00 +0000

De la literatura relacionada con patrones de diseño, hay dos libros que recuerdo haber leído con mucho agrado (esos libros que cuesta dejar de leerlos). Uno de ellos es el “Head First Design Patterns”, el cual realmente me rompió los esquemas de los libros que hasta el momento había leído por la forma en que presenta cada uno de los patrones. El otro libro es el “Design Patterns for Dummies”, que para este caso su título lo dice todo.

Hace un tiempo atrás, necesitaba hacer una clase de patrones de diseño en una universidad, y fue del primer libro, de donde saque muchas ideas para enseñar algunos patrones básicos.

El primer patrón que veremos será el “Prototype”, pero siguiendo la filosofía del “Head First Design Patterns” en la simpleza de enseñar patrones.

Para lograr esto, el protagonista principal de estos post sera…..

Como todos sabemos, Cerebros es un ratón cuyo único deseo es llevar a cabo su malvado plan para…..DOMINAR AL MUNDO!!!!.

Una mañana, ideo un plan malévolo pero perfecto!!!. Recordando su niñez cuando veía el “Show de los Robots” o “Pipiripao” (uff……que viejo), decidió construir un ejercicito de robots y así dominar el mundo!!!!. Para lograr su objetivo, debía construir una máquina capaz de construir cualquier tipo de robot y que fuera programada en Java.

Así que comenzó a programar su máquina para construir su primer robot:

package prototipo.paso1; public class MazingerZ { public MazingerZ(){ System.out.println("Construyendo robot Mazinger Z"); } }

package prototipo.paso1; public class MaquinaGeneradora { public MazingerZ construirMazingerZ() { return new MazingerZ(); } public MazingerZ[] cosntruirMuchosMZ(int numeroRobots){ MazingerZ[] mazingerZ = new MazingerZ[numeroRobots]; for (int k = 0; k < numeroRobots; k++) { mazingerZ[k] = new MazingerZ(); } return mazingerZ; } }

package prototipo.paso1; public class ConquistarAlMundo{ public static void main(String[] args){ MaquinaGeneradora mg = new MaquinaGeneradora(); mg.construirMazingerZ(); mg.cosntruirMuchosMZ(20); } }

Tras construir un ejército de robots, Cerebro de dio cuenta que construir un ejército de robots tipo “El Vengador” unidos a los “Mazinger Z” le ayudaría a dominar el mundo más rápido.

Pero aquí se le presento el primer problema. Su máquina no fue programada para construir “El Vengador”, sino solamente para construir “Mazinger Z”.

Así que Cerebro, como buen programador, decide refactorizar su código para añadir a su máquina la funcionalidad necesaria para construir “El Vengador”.

package prototipo.paso2; public class ElVengador { public ElVengador(){ System.out.println("Construyendo robot El Vengador"); } }

package prototipo.paso2; import prototipo.paso1.MazingerZ; public class MaquinaGeneradora { public MazingerZ construirMazingerZ() { return new MazingerZ(); } public ElVengador construirElVengador() { return new ElVengador(); } public MazingerZ[] cosntruirMuchosMZ(int numeroRobots) { MazingerZ[] mazingerZ = new MazingerZ[numeroRobots]; for (int k = 0; k < numeroRobots; k++) { mazingerZ[k] = new MazingerZ(); } return mazingerZ; } public ElVengador[] cosntruirMuchosEV(int numeroRobots) { ElVengador[] elVengador = new ElVengador[numeroRobots]; for (int k = 0; k < numeroRobots; k++) { elVengador[k] = new ElVengador(); } return elVengador; } }

package prototipo.paso2; public class ConquistarAlMundo{ public static void main(String[] args){ MaquinaGeneradora mg = new MaquinaGeneradora(); mg.construirMazingerZ(); mg.cosntruirMuchosMZ(20); mg.construirElVengador(); mg.cosntruirMuchosEV(18); } }

Cerebro está loco, pero no es tonto. Por tanto, enseguida se da cuenta de que puede encontrarse con problemas si decide construir otro tipo de robots como “El Gran Dragón del Espacio” o “Afrodita A”.

Tras pensar cuidadosamente sobre su problema, decide hacer una nueva refactorización a su código.

package prototipo.paso3; import prototipo.paso1.MazingerZ; import prototipo.paso2.ElVengador; public class MaquinaGeneradora { public Object construirRobot(String tipo){ if( tipo.equals("MazingerZ") ){ return new MazingerZ(); } else if( tipo.equals("ElVengador") ){ return new ElVengador(); } return null; } public Object[] construirMuchosRobots(String tipo, int numero){ Object robots[] = new Object[numero]; if( tipo.equals("MazingerZ") ){ for( int k=0; k< numero; k++ ){ robots[ k ] = new MazingerZ(); } } else if( tipo.equals("ElVengador") ){ for( int k=0; k< numero; k++ ){ robots[ k ] = new ElVengador(); } } return robots; } }
package prototipo.paso3; public class ConquistarAlMundo { public static void main(String[] args) { MaquinaGeneradora mg = new MaquinaGeneradora(); mg.construirRobot("MazingerZ"); mg.construirMuchosRobots("MazingerZ", 12); mg.construirRobot("ElVengador"); mg.construirMuchosRobots("ElVengador", 8); } }

Tras varios minutos de las típicas risas histéricas de Pinky, Cerebro comienza a darse cuenta que la forma en que ha programado su máquina tiene bastantes puntos débiles.

En primer lugar, el método “construirRobot” devuelve un Object, no un “Mazinger Z” o un “El Vengador”. Por qué?....porque ese método no sabe lo que va a crear a priori. Cerebro se da cuenta que esta no es la mejor solución.

También se da cuenta que si en algún momento quisiera construir algún otro tipo de robot, debería programar nuevamente su máquina, lo cual la transforma, en una maquina difícil de mantener.

Pero entonces, una idea empieza a abrirse paso en su malvado cerebro. Aun no sabe exactamente cómo hacerlo, pero que pasaría si pudiera darle algo a la maquina (un robot del tipo Mazinger Z, El Vengador, Afrodita A, etc…) y pedirle a la misma que le entrege 800 copias del mismo?....brillante!!!. Así, no tendría que preocuparse de cómo funciona la maquina, simplemente esta devolvería tantas copias como necesite del original.

Entonces cerebro recuerda haber estudiado el patrón “Prototype”. Para lograr esto, la maquina no puede saber que tiene que construir ni cómo debe construirlo (la creación de la copia), y tampoco puede ser una responsabilidad de cada uno de los robots (o cosas a copiar). La maquina, simplemente debe recibir un robot y le dirá a este que produzca tantas copias de el mismo como se necesiten y luego las devolverá.

De hecho, Cerebro se ha dado cuenta de que la forma en la que deben crearse las nuevas copias de los robots no ha de ser la misma para todos, sino que en algunos casos le va a interesar utilizar el mecanismo de clonado de Java, y en otros tener un control más fino del mismo.

Así que, la primera tarea de Cerebro será crear una interfaz (que extiende Cloneable, implementando de este modo el método clone()), que será el que implemente cada uno de los robots.

public interface ClonarRobot extends Cloneable { public ClonarRobot duplicar( ); }

También sería posible que todos los robots extendieran de una clase base, y que por lo tanto el tipo que devuelve el método duplicar() fuera esa clase base. Pero de la manera anteriormente comentada el diseño es mucho más flexible.

El método duplicar() será el encargado de crear y devolver una nueva copia de cada robot que lo implemente.

package prototipo.paso4; public interface ClonarRobot extends Cloneable { ClonarRobot duplicar( ); }

package prototipo.paso4; public class ElVengador implements ClonarRobot{ public ElVengador() { System.out.println("Creada la plantilla de El Vengador"); } public ClonarRobot duplicar() { System.out.println("El Vengador se va a clonar a si mismo"); ElVengador elVengador = null; try { elVengador = (ElVengador) super.clone(); } catch (Exception e) { System.out.println("error al clonar El Vengador"); } return elVengador; } public String toString() { return "El Vengador - Ya estoy listo para la batalla!!!"; } }

package prototipo.paso4; public class MazingerZ implements ClonarRobot{ public MazingerZ() { System.out.println("Creada la plantilla de Mazinger Z"); } public ClonarRobot duplicar() { System.out.println("Mazinger Z se va a clonar a si mismo"); MazingerZ mazingerZ = null; try { mazingerZ = (MazingerZ) super.clone(); } catch (Exception e) { System.out.println("error al clonar Mazinger Z"); } return mazingerZ; } public String toString() { return "Mazinger Z - Ya estoy listo para la batalla!!!"; } }

package prototipo.paso4; public class MaquinaGeneradora { public Cloneable crearCopia(ClonarRobot plantilla) { return plantilla.duplicar(); } public Cloneable[] crearMuchasCopias(int numeroCopias, ClonarRobot plantilla) { Cloneable[] copias = new Cloneable[numeroCopias]; for (int i = 0; i < numeroCopias; i++) { copias[i] = plantilla.duplicar(); } return copias; } }

package prototipo.paso4; public class ConquistarAlMundo { public static void mostrar(String texto){ System.out.println(""); System.out.println(texto); System.out.println(""); } public static void main(String[] args) { MaquinaGeneradora mg = new MaquinaGeneradora(); mostrar("Creando plantilla de Mazinger Z y El Vengador"); MazingerZ plantillaMazingerZ = new MazingerZ(); ElVengador plantillaElVengador = new ElVengador(); MazingerZ mazingerZClonado = (MazingerZ) mg.crearCopia(plantillaMazingerZ); mostrar("Primera Mazinger Z clonado"); System.out.println(mazingerZClonado); ElVengador elVengadorClonado = (ElVengador) mg.crearCopia(plantillaElVengador); mostrar("Primer El Vengador clonado"); System.out.println(elVengadorClonado); mostrar("Creando 10 nuevos Mazinger Z"); Cloneable nuevosMazingerZ[] = mg.crearMuchasCopias(10, plantillaMazingerZ); mostrar("Creando 10 nuevos El Vengador"); Cloneable nuevosElVengador[] = mg.crearMuchasCopias(10, plantillaElVengador); mostrar("Inicializando los Mazinger Z"); for(int i=0; i<> System.out.println(nuevosMazingerZ[i]); } mostrar("Inicializando los El Vengador"); for(int i=0; i<> System.out.println(nuevosElVengador[i]); } } }

Ahora, Cerebro puede seguir construyendo su ejército para conquistar el mundo el mundo con los clones creados por su máquina, sabiendo que puede crear copias de todo lo que le dé la gana, porque le ha dado a su máquina el “don” de crear objetos sin saber de qué tipo deben ser.

Pero Cerebro es un hombre de ciencia, y en su afán por alcanzar el conocimiento absoluto, sigue leyendo la documentación sobre el patrón prototype, y entonces se da cuenta de que también ha separado el código que crea los objetos del código que maneja los detalles de la creación de nuevos objetos.

Esta historia continuara……

Parte 2

Inversion de Control (IoC)

noreply@blogger.com (José Luis Coronel Cortés) — Thu, 12 Jun 2008 18:01:00 +0000

Hace un tiempo atrás convencí a un amigo de que aprendiera Spring, contándole de todas las ventajas que podría lograr utilizando este framework. El comenzó a estudiarlo y como a todos nos ha pasado, le sorprendió la facilidad con la que puede desarrollar aplicaciones.

Hasta ahí todo iba muy bien, pero cuando le pregunte que le pareció la “inversión de control” y la “inyección de dependencia”, me dijo que lo único que entendía era que Spring utilizaba estos patrones…...pero de que se trataba……ni idea!!!!

Así que mi querido amigo XXX (no te voy a echar al agua)…...este post es para ti.

Imaginemos que tenemos una clase “Componente” que necesita usar la clase “Servicio”. Una solución para esto podría ser :

El problema de esto es que estamos acoplando las clases. Qué pasaría si por algún requerimiento, el desarrollador modifica el código, solicitando ahora algún parámetro en el constructor de la clase “Servicio”?. Esto nos llevaría no solo a modificar el código de la clase “Servicio”, sino también el de la clase “Componente”.

O pero aun, tu jefe te dice que no le gusta como esta implementada la clase “Servicio”, así que él, en un acto de iluminación divina, desarrollo la clase “Servicio2” la cual (supuestamente) es mejor a la anterior. Por lo tanto, nuevamente tendremos que modificar nuestra clase “Componente”:

…..y mejor ni pensemos si alguien se pone original (nunca faltan!!!!) y comience a modificar el constructor de la clase “Servicio2”.

Pero como nada es tan terrible, una solución para estos casos es la “Inversión de control”.

El primer cambio que tendremos que hacer a nuestro código, es olvidarnos de usar “new XXX()”, para lo cual definiremos un método “setXXX” que nos pase una referencia de una instancia de la clase “Servicio2” :

Hasta aquí todo va bien, pero que pasaría si nuestro jefe, en un acto de arrepentimiento te dice “evaluando la situación, pienso que debemos volver a usar la clase “Servicio” hasta que nuevo aviso (por no decir, hasta que arregle los errores en mi código)”, y nosotros que ya pensábamos que teníamos casi todo controlado, nuevamente tendremos que volver a cambiar el código de la clase “Componente”, modificando el atributo y el método “setXXX”.

Pero como buenos programadores, sabemos que no va a faltar el jefe original que se le ocurra volver a cambiar el servicio, así que, para evitar problemas a futuro, definiremos una interfaz para el servicio. De ahora en adelante, cualquier clase servicio que se le pase a la clase “Componente”, deberá implementar esta interfaz (ufff….ya no deberemos tocar el código de la clase “Componente”).

Como vemos, cambiar el tipo de servicio en la clase “Componente” ya no tiene impacto en nuestro código!!!! (Obviamente..…hasta que no falte el original que cambie la interfaz!!!).

Hasta aquí toda esta correcto, pero nos falta un pequeño elemento, el “Ensamblador”, cuya tarea principal es obtener la información de cómo cada uno de los elementos debe ser inyectado en otros elementos.

Para estos casos, es donde frameworks como PicoContainer o Spring utilizan el patrón “Inversión de Control”, los cuales se encargan de realizar la inyección de los elementos. El como lo hacen, puede ser a través de código o en un archivo de configuración.

Para el caso de la “Inyección de dependencias” existen tres mecanismos:

Inyección de Interfaz (IoC tipo 1)
Inyección de Setter (IoC tipo 2)
Inyección de Constructor (IoC 3)

Que diferencias existen entre los distintos tipos de inyección, va mas allá de este post, pero el señor Martin Fowler lo explica muy bien en este articulo.

La inversión de control no es la única forma de solucionar este problema, también existe el patrón “Service Locator”, pero eso es tema para otro post.

Tutorial de BlazeDS – Parte 1

noreply@blogger.com (José Luis Coronel Cortés) — Fri, 06 Jun 2008 03:32:00 +0000

Hace poco vimos en una pequeña introducción a BlazeDS en el JUG DAY, pero como el tiempo es corto, es muy difícil poder explicar todas las ventajas que este “Data Services” nos ofrece. Por esta razón, comenzare a explicar en una serie de post cuales son las partes que componen BlazeDS a través de pequeños ejemplos.

BlazeDS está construido como una aplicación web, cuyo corazón es una infraestructura de mensajería que permite integrar un “Back-End” desarrollado en Java con un “Front-End” en Flex. Esta infraestructura de mensajería nos permite el intercambio de datos a través de dos tipos de servicios: Mensajería y RPC (Remote Procedure Call).

Servicios RPC

Los servicios RPC están diseñados para aplicaciones en la cuales el modelo “Llamada / Respuesta” es una buena opción para acceder a datos externos. Este servicio permite hacer llamadas asincrónicas a un servicio remoto que procesara esta solicitud y retornara el resultado a la aplicación Flex.

Un componente RPC que reside en el cliente, puede ser creado con MXML o ActionScript. Este es el encargado de hacer la llamada remota al servicio y almacenar los datos de respuesta del servicio en un objeto ActionScript, desde el cual la aplicación pueda obtener los datos fácilmente. La implementación de un servicio RPC puede ser un HTTP URL, el cual usara http POST o GET; un servicio web SOAP compatible o un objeto Java en una aplicación web Java. Los componentes RPC que residen en el cliente pueden ser del tipo: HTTPService, WebService y RemoteObject.

El siguiente diagrama provee una visión de cómo los componentes RPC interactúan con servicios RPC.

Mensajeria

La capacidad de mensajería en BlazeDS está construida sobre la misma infraestructura de mensajería de los servicios RPC. Utilizando un componente de mensajería se puede desarrollar aplicaciones colaborativas y en tiempo real. Estos componentes proveen una API a las aplicaciones cliente para enviar texto y objetos dentro de un mensaje, permitiendo configurar el destino de este en un archivo de configuración que reside en el servidor de aplicaciones.

Es posible crear un componente de mensajería a través de MXML o ActionScript, el cual define el destino de los mensajes a enviar al servidor, envía los mensajes a estos destinos y recibe mensajes de otros clientes de mensajería. Los componentes que envían mensajes son llamados “Producidores”, y los que reciben mensajes son llamados “Consumidores”. Los mensajes enviados son transportados a través de “Canales”, los cuales utilizan un protocolo de transporte especifico, como por ejemplo el Action Message Format (AMF).

Los clientes de mensajería pueden ser una aplicación Flex u otro tipo de aplicaciones, como por ejemplo una aplicación JMS. JMS es una API en Java que permite desarrollar aplicación para crear, enviar, recibir y leer mensajes. Las aplicaciones JMS pueden publicar y suscribirse al mismo destino de mensajería que las aplicaciones Flex. Sin embargo, se puede crear una variedad de aplicaciones de mensajería solo utilizando el servicio de mensajería de BlazeDS.

Instalación

BlazeDS puede ser descargado desde http://opensource.adobe.com/wiki/display/blazeds/BlazeDS, existiendo la opción de descargar el código fuente del proyecto, la opción binaria (la cual contiene un archivo WAR) y la opción “Turnkey”, la cual es una versión lista para utilizar, ya que incluye un Tomcat 6.0.14, un archivo WAR y el SDK de Flex 3.0. Para efectos de los ejemplos a desarrollar a lo largo de los post, necesitaremos descarga la versión “Turnkey”.

Una vez descargado el archivo, descomprímanlo en la carpeta “C:\blazeds_turnkey”, el cual contendrá la siguiente estructura:

Para validar que todo funciona correctamente, ejecuten el archivo “startup.bat” que se encuentra en la carpeta “C:\blazeds_turnkey\tomcat\bin” (es necesario tener correctamente configurada la variable de entorno JAVA_HOME).

Una vez que Tomcat se encuentre listo, podrán acceder a la página de administración de BlazeDS en http://localhost:8400/ds-console/index.html.

Creación de un proyecto

Tenemos dos opciones de crear un proyecto Flex integrado a BlazeDS. La primera opción es dejar ambos códigos fuentes integrados en un solo proyecto, o en caso contrario, construir dos proyectos por separado.

Proyecto integrado

El primer paso será crear un proyecto Flex que llamaremos “DukeFlex”, seleccionaremos que el tipo de servidor de aplicaciones es “J2EE”, y por último la opción de creación de un proyecto Java/Flex usando WPT.

Seguidamente deberemos definir el servidor de aplicaciones (para este ejemplo utilizare Tomcat 6.x), indicarle donde se encuentra el archivo WAR de BlazeDS, en la opción “Output Folder” borrar el texto “bin-debug” y presionar el botón “Finish”.

Ahora crearemos una clase Java que retorne el mensaje “Duke Chile - JUG”, para lo cual deberán cambiar la perspectiva de “Flex” a “Java”.

Una vez creada la clase Java, necesitaremos registrarla como destino en el archivo remoting-config.xml.

Una vez que tenemos configurado el servicio, el siguiente paso será crear una pequeña página en Flex que llame al método “mensaje”, obtenga el texto del servicio y lo muestre en una ventana de mensajes.

Para esto, volveremos a la perspectiva “Flex” y abriremos el archivo DukeFlex.mxml que está en la carpeta “flex_src” del proyecto.

Dentro de este archivo deberemos crear un objeto “RemoteObject” y definirle el “destination” con “servicioDukeChile”. También deberemos construir un objeto “Button” que llame al servicio y que muestre el mensaje en una ventana de “Alerta”.

Por último, deberemos realizar un cambio en el “Context Root” del proyecto, cambiando la definición de “WebContent” por “DukeFlex” que es el nombre del proyecto. Para esto deberán presionar el botón derecho del mouse sobre la carpeta del proyecto y seleccionar la opción “Properties”. Dentro de la ventana de propiedades seleccionar la opción “Flex Server” y realizar el cambio.

Por último, botón derecho sobre el archivo “DukeFlex.mxml” y seleccionar la opción “Run as --> Flex Application”, con lo cual se iniciara Tomcat y mostrara la página Flex con el botón de prueba.

Al presionar el botón “Llamar servicio”, se llamará al método “mensaje”.

Proyectos separados

Lo primero que tendremos que hacer es crear la carpeta “dukechile” en “C:\blazeds_turnkey\tomcat\webapps” y dentro de esta copiar el contenido que está en la carpeta “C:\blazeds_turnkey\blazeds”. Con esto tendremos la estructura básica de un proyecto web para BlazeDS.

El siguiente paso será crear un proyecto “Java” al cual llamaremos “DukeFlexServidor”, seleccionaremos la opción “Create project from existing source”, en la opción “Directory” le indicamos la ruta completa hasta la carpeta “WEB-INF” del proyecto “dukechile” y presionamos el botón “Next”.

En la siguiente opción, deberemos definir la carpeta “src” como nuestro “source foulder”, definiremos la carpeta “classes” como el lugar donde quedaran las clases compiladas y presionamos el botón “Finish”.

El siguiente paso será crear la clase “ServicioDukeChile” igual a la detallada en “Proyecto Integrado”.

Una vez creada la clase Java, necesitaremos registrarla como destino en el archivo remoting-config.xml.

Con esto ya tendremos listo la parte del lado del servidor. Ahora construiremos la aplicación cliente para cual deberemos crear un proyecto Flex que llamaremos “DukeFlexCliente”, pero que a diferencia de la versión “Proyecto integrado”, en este caso solo seleccionaremos que el servidor de aplicación a utilizar es “J2EE”. Una vez definido esto, presionamos el botón “Next”.

En esta opción deberemos definir que el “Root folder” es la carpeta “dukechile” definida anteriormente dentro del “blazeds_turnkey”. Además deberemos modificar el “Root URL” y el “ContextRoot” como se muestra en la imagen.

Una vez que los datos son modificados, será necesario validar la nueva configuración, para lo cual presionaremos el botón “Validate Configuration”.

Por último, presionamos el botón “Finish” para crear el proyecto Flex.

En el archivo “DukeFlexCliente” construiremos el mismo ejemplo que realizamos en la opción “Proyecto integrado”.

Para probar la aplicación deberemos iniciar Tomcat, para lo cual ejecutaremos el archivo “C:\blazeds_turnkey\tomcat\bin\startup.bat”.

Por último, botón derecho sobre el archivo “DukeFlexCliente.mxml” y seleccionar la opción “Run as --> Flex Application”, con lo cual se mostrara la página Flex con el botón de prueba.

Al presionar el botón “Llamar servicio”, se llamará al método “mensaje”.

Con estos pasos ya podemos comenzar a crear nuestros primeros proyectos utilizando BlazeDS. Además, como vimos anteriormente, tenemos la posibilidad de integrar todo en un mismo proyecto, o tener por separado el proyecto Flex del Java.

En el siguiente post comenzaremos a analizar los servicios RPC, cuales son los canales definidos para este tipo de servicios, su configuración en BalzeDS y un pequeño ejemplo que involucre estos tópicos.

Primeros pasos con Spring Batch

noreply@blogger.com (José Luis Coronel Cortés) — Sat, 24 May 2008 23:50:00 +0000

Hace un tiempo atrás José Miguel Selman publico en su blog el lanzamiento oficial de la versión 1.0 de Spring Batch y desde aquella vez que he querido poder programar un simple ejemplo para meter mis manos en esta nueva funcionalidad que nos ofrece la gente de “SpringSource”, pero por motivos de tiempo (trabajo, clases, JUG, proyectos de investigación,…..etc) nunca he podido darme un tiempo, hasta hoy que me decidí a como de lugar programar mis primeras líneas en” Spring Batch” (mas bien no jugar PS3 :-( …....pero bueno….Lost Planet puede esperar).

En “Spring Batch” un Job es un proceso que se encuentra compuesto por uno o más Step. Para construir un Job utilizaremos una JobInstance, la cual nos permitirá definir un Job, asociándole un conjunto de propiedades llamadas JobParameters. Cada ejecución de una JobInstance será una JobExcecution.

Por ejemplo, supongamos que necesitamos cada cierto periodo de tiempo leer un información de un repositorio de datos (una base de datos, un chache, etc…), generar un archivo XML que represente a esa información e insertar este una cola de mensajería JMS. Este conjunto de tareas sería un Job el cual estaría compuesto de tres Step. Si además, parametrizamos este Job para que se ejecute cada cierto periodo de tiempo (una hora por ejemplo), cada periodo de tiempo seria una JobInstance y cada vez que se ejecute esta instancia (depende de la hora), sería una JobExecution. Este modelo propuesto por “Spring Batch” permite a los desarrolladores una gran flexibilidad respecto a cómo nuestros Job serán lanzados y ejecutados.

El responsable de ejecutar cada uno de los Job definidos, además del grupo de parámetros asociados a este será el JobLauncher. Por último, en muchos casos, necesitaremos algún lugar donde poder almacenar información en tiempo de ejecución relacionada con el proceso batch, para lo cual se utiliza un JobRepository.

Para cada Job es recomendable utilizar un archivo XML de contexto diferente (ya veo un modulo de procesos batch definido con Impala….full!!!). Sin embargo, necesitaremos un conjunto de beans que serán utilizados por cada uno de estos Job. Estos objetos los agruparemos en el applicationContext.xml, los cuales serán importados desde cada una de las definiciones de los Job.

Es Los objetos comunes son:

JobLauncher: El cual será el responsable de iniciar un Job cargando cada uno de sus parámetros asociados. La implementación más básica se encuentra proveida por la clase SimpleJobLauncher, la cual se soporta en un TaskExecutor para iniciar cada uno de los Job. Si no se especifica el tipo de TaskExecutor se configurara un SyncTaskExecutor por defecto.
JobRepository: Para el manejo del repositorio utilizaremos un SimpleJobRepository, la cual requerirá un conjunto de DAOs para almacenar la información.
JobInstanceDAO, JobExecutionDAO y StepExecutionDAO: Estos DAO serán usados por el SimpleJobRepository para almacenar información relacionada con la ejecución de los Job. Para esto, “Spring Batch” provee dos tipos de implementación: basados en Map (se almacenan los datos en memoria) y en JDBC.

En el archivo applicactionContext.xml quedaria asi:

Para programar nuestro ejemplo, la clase deberá implementar la interfaz Tasklet. Dentro de esta clase programaremos la lógica que deberá ejecutar un Job, que en nuestro caso será un mensaje por consola.

Fíjense que el método “execute” retorna un ExitStatus para indicar el estado de ejecución del Tasklet.

Ahora solo nos queda definir nuestro primer Job en un archivo de contexto que llamaremos EjemploBasicoJob.xml. Dentro de este, utilizaremos la implementación de un SimpleJob la cual ejecutara todos los Step secuencialmente. Para poder definir un Tasklet dentro de un Job, deberemos utilizar un TaskletStep.

“Spring Batch” provee muchas formas de ejecutar un Job. La más simple es utilizando la clase CommandLineJobRunner, al cual se puede ejecutar desde línea de comandos y recibe como parámetros iniciales el nombe del archivo de contexto XML donde está definido el Job y el nombre del bean del Job. En mi caso lo estoy ejecutando desde Eclipse, así que solo necesitao crear una nueva “Java Application” y en el “Main class” definir la clase CommandLineJobRunner.

Por último, se le debe pasar por parámetro el nombre del archivo XML de contexto donde se encuentra definido el Job y el nombre del bean del Job.

El codigo fuente desde este ejemplo lo pueden descargar desde aqui

Más información respecto a ejemplo más complejos lo pueden consultar en http://static.springframework.org/spring-batch/spring-batch-docs/reference/html/execution.html.

Nos vemos en el JUG DAY!!!!

Mensajeria en JADE

noreply@blogger.com (José Luis Coronel Cortés) — Tue, 01 Apr 2008 18:46:00 +0000

JADE se encuentra basado en las especificaciones FIPA en cuanto al formato de los mensajes, los cuales están divididos en diferentes slots que contiene la información (lenguaje, protocolo, contenido. . . ), y sobre estos se definen funciones de creación (set) y consulta (get).

Los métodos básicos de los que se dispone para el manejo de los mensajes entre agentes son:

send(ACLMessage): Se usa para enviar un mensaje una vez ingresados todos los parametros de este. El mensaje es enviado desde el agente que invoca el método a todos los destinatarios que contienen el campo :receiver.

ACLMessage receive( ): Recibe un mensaje de la cola de mensajes del agente. Se puede especificar que tipo de mensaje se quiere recibir mediante una plantilla de mensaje (MessageTemplate).

ACLMessage blockingReceive( ): Bloquea el agente mientras no se reciba un mensaje. Al igual que en el método anterior, se puede especificar el tipo de mensaje a recibir, con lo que se desecharía el resto, y el agente permanecería bloqueado hasta recibir el mensaje deseado.

La siguiente figura muestra la secuencia de envió de un mensaje en JADE:

Como se aprecia en la figura anterior el agente A1 prepara el mensaje configurando como receptor de este al agente A2 y lo envía a través del canal de distribución de mensajes de JADE, el cual guarda el mensaje en la cola de recepción del agente A2. Una vez guardado el mensaje en la cola de recepción, el agente A2 puede proceder en cualquier momento a retirar este.

El lenguaje que se utiliza comúnmente para escribir los mensajes es el FIPA-SL (Semantic Lenguaje), el cual contiene un ámbito mas general ya que permite: formar expresiones lógicas, intercambiar información entre agentes y expresar acciones a realizar.

Agent Communication Language (ACL)

En una sociedad multiagente, los agentes deben cooperar para realizar sus tareas y alcanzar sus objetivos. Los mecanismos de comunicación tradicionales permiten que dos agentes se transfieran información, pero eso es insuficiente cuando el objetivo es conseguir un comportamiento social. Es decir, son necesarios otros mecanismos que permitan dotar a los mensajes intercambiados de un contenido semantico.

Para definir el modelo de comunicación, FIPA parte de la idea que los agentes poseen capacidad de razonamiento. Esta capacidad viene dada por una serie de actitudes mentales que se definen como:

Creencias: Conjunto de proposiciones que el agente acepta como verdaderas. Lo que el agente conoce del mundo.

Objetivos: Conjunto de propiedades que el agente quiere que sean verdaderas aunque actualmente no están entre sus creencias.

Intenciones: Conjunto de acciones planificadas por el agente que le permiten llegar a un estado deseado.

Mediante sus acciones, un agente puede contribuir a cambiar el estado de su entorno y así satisfacer sus objetivos. Un agente influye en el conocimiento y acciones de otros agentes mediante un acto de comunicación (speech act), que se realiza mediante el envió de un mensaje desde el origen al destino. Ambos extremos de la comunicación deben entender el mensaje, y este debe ser algo mas que un intercambio de datos: debe tener asociado un contenido semantico accesible por ambas partes.

La solución adoptada por FIPA se basa en la utilización de mensajes ACL que tienen que ser comprendidos por cualquier agente del sistema. El uso de mensajes ACL permite el envió de información junto a su contenido semantico.

El lenguaje ACL (Agent Communication Language) desarrollado por FIPA es una evolución del lenguaje KQML (Knowledge Query Manipulation Language). La definición semántica formal de los mensajes ACL ha sido uno de los esfuerzos mayores dentro del estándar FIPA, y otorga a este lenguaje de una gran aceptación como estándar dentro del mundo de los agentes.

Desde este punto de vista, hay que entender un agente como una entidad que entiende el lenguaje ACL y es capaz de intercambiar conocimiento con otros agentes mediante el uso del mismo. Ya no se habla de que la interfaz de un agente (objeto) ofrezca una serie de servicios que se puedan invocar o instanciar, sino que un agente va a proporcionar ciertos servicios que se le pueden solicitar mediante un mensaje ACL que incluya dicha solicitud. Se pasa de un modelo de objetos a un modelo de agentes inteligentes basados en actos de comunicación.

Niveles de un mensaje ACL

Contenido: Contenido real del mensaje en el lenguaje de representación propio.

Mensaje: El nivel de mensaje conforma la esencia del mensaje. Determina el tipo de interacciones que se pueden tener con un agente que habla ACL. La función principal del nivel de mensaje es identificar el protocolo a ser utilizado para enviar el mensaje y proporciona al emisor una preformativa para que añada el contenido.

Comunicación: Relativo a los parámetros de comunicación a más bajo nivel: identidad del emisor y receptor, y un identificador único asociado con la comunicación.

La siguiente figura muestra los niveles de comunicación en un mensaje ACL:

Estructura de un mensaje ACL

Un mensaje ACL esta formado por:

Identificador del tipo de comunicación: Define el significado principal del mensaje. Es decir, lo que el agente origen pretende con dicho mensaje. Por ejemplo: ”inform”(un agente transmite información a otro), ”request”(un agente solicita a otro que realice una accion), ”agree”(un agente acepta la petición realizada), ”query”(un agente solicita información a otro).

Secuencia de parámetros del mensaje: Es un conjunto de parejas clave-valor que permiten asociar a cada acto de comunicación concreto toda la información necesaria.

Ejemplo de mensaje ACL:

(inform
:sender agente1
:receiver: agente2
:content
(velocidad agenteA 40)
:in-reply-to round-4
:reply-with bid04
:language sl
:ontology ontologia-agente
)

Este mensaje enviado del agente1 al agente2 informa que la velocidad del agente A es de 40, utiliza el lenguaje SL y la ontología ontologia-agente para describir esta información.

La siguiente figura muestra la estructura de los mensajes que se intercambian entre agentes:

Parámetros del mensaje

Los parámetros básicos del lenguaje ACL definidos por la especificación FIPA, son los siguientes:

Manejo de comportamientos en JADE

noreply@blogger.com (José Luis Coronel Cortés) — Sat, 29 Mar 2008 18:31:00 +0000

Las tareas o servicios que un agente hace se especifican a través de comportamientos. Un comportamiento (behaviour) hace referencia a una funcionalidad que incorpora el agente. Para que un agente pueda crear uno o más comportamientos debe heredar la clase jade.core.behaviours.Behaviour. Una vez que se ha implementado, el agente puede ejecutar ese comportamiento cada vez que sea invocado dentro del método setup del agente, el cual los anexa al agente a través del metodo addBehaviour perteneciente a la clase Agent.

Se puede pensar que los comportamientos son como los hilos de ejecución en Java (threads), ya que al igual que estos, en un agente pueden ejecutarse a la vez tantos comportamientos como sea necesario. Sin embargo, a diferencia de los hilos, el decidir que comportamiento se ejecuta en cada momento es tarea del desarrollador del agente. Esto es así para que cada agente sea equivalente únicamente a un único hilo, con el consiguiente ahorro de ciclos de CPU y memoria que esto implica.

La creación de los comportamientos se realiza extendiendo la clase jade.core. Behaviours, para lo cual la clase Agent tiene dos métodos para poder agregar o eliminar comportamientos:

addBehaviour
removeBehaviour

Estos comportamientos pueden ser anexados dentro del método setup (lo habitual), desde cualquier comportamiento, o desde otros agentes. Algunos métodos con los que cuentan los comportamientos son:

action: Método que implementa la tarea a realizar.
done: Método booleano que comprueba si la tarea ha acabado, eliminándola si retorna true.
block: Método que bloquea la ejecución del comportamiento. El bloqueo se hace efectivo cuando el método action retorna, el cual puede ser configurado con un determinado tiempo.
restar: Se reinicia explícitamente un comportamiento bloqueado.
reset: Retorna el comportamiento a su estado inicial.
onStart: Acciones antes de iniciar el comportamiento.
onEnd: Acciones antes de finalizar el comportamiento.

JADE no guarda el estado de los comportamientos, razón por la cual es responsabilidad del desarrollador guardar el último estado de este.

Los comportamientos pueden ser agrupados en tres grandes grupos:

Comportamientos one-shot: Son aquellos que se ejecutan de manera casi instantánea, y solamente una vez.
Comportamientos cíclicos: Son aquellos que nunca son sacados del conjunto de comportamientos del agente y cuyo método action siempre ejecuta el mismo código. Por lo tanto, nunca finalizan.
Comportamientos genéricos: Un poco más complejos ya que el código que se ejecuta en ellos depende del estatus del agente, y eventualmente analizan su ejecución.

Otro tipo de comportamientos en JADE son los compuestos, que permiten combinar comportamientos previamente definidos de manera conveniente para aplicarles un orden de ejecución determinado; estos son:

Secuenciales a través de SequentialBehaviour.
En paralelo a través de ParallelBehaviour.
Guiados mediante un autómata finito deterministico a través de FSMBehaviour.

Existen comportamientos a los cuales se les puede definir su ejecución a través de un tiempo de espera; estos son WakerBehaviour y TickerBehaviour, los cuales tienen en común que su ejecución es diferida. Se invocan y aguardan hasta que se ha cumplido un determinado tiempo. El primero de estos solamente se ejecuta una vez y el segundo es un comportamiento cíclico.

Los objetos behaviour describen pequeñas tareas que debe realizar el agente ejecutándose según un planificador que se encuentra implementado en la clase Agent. El planificador va ejecutando según una política round-robin (o por turnos rotatorios) de los objetos behaviour que se encuentran en una cola FIFO.

Los objetos behaviour tienen dos métodos que se deben reescribir, action() y done(). El método action() es en donde se deben desarrollar las tareas que debe realizar el agente, mientras que el método done() es llamado cuando el action() finaliza. El planificador va ejecutando uno a uno los métodos action() de la cola y cuando el método action() de un objeto finaliza se llama al método done(), el cual debe retornar un valor booleano. Si retorna true, el objeto es sacado fuera del planificador ya que se da por concluida su tarea, mientras que si retorna false se vuelve a planificar.

Si en algún momento de la ejecución del método action() se requiere esperar por la llegada de un mensaje, existe el método block() para mandar a una cola de bloqueados cuando el método action() finaliza (no cuando se llama a block()). Cuando se produce la llegada de un mensaje, todos los objetos en la cola de bloqueados se planifican y deben comprobar si el mensaje llegado es para ellos o no. En caso de que un objeto no sea el destinatario del mensaje este debe volver a bloquearse.

Es importante que los métodos action() sean cortos, de esta forma se permite un cierto grado de paralelismo. Si se necesita realizar una tarea que va a requerir un largo periodo de tiempo, entonces el desarrollador deberá dividir la tarea en subtareas y cada una de ellas implementarla mediante un objeto behaviour. Con el fin de ayudar en esta labor, JADE proporciona una jerarquía de clases behaviour, que permite incluso simular maquinas de estados finitos.

SimpleBehaviour: Representa un comportamiento atómico.
OneShotBehaviour: Representa un comportamiento que se debe ejecutar solo una vez, por eso su método done() retorna true, si no es redefinido.
CyclicBehaviour: Representa un comportamiento que debe ejecutarse una serie de veces. El método done, si no es redefinido, devuelve false.
SenderBehaviour: Encapsula la acción de envió de un mensaje ACL. Este mensaje debe ser especificado en el constructor.
ReceiverBehaviour: Encapsula la acción de recepción de un mensaje ACL. Termina cuando se recibe el mensaje o cuando pasa una cierta cantidad de tiempo especificada en el constructor.
WakerBehaviour: Implementa un comportamiento OneShot que se ejecuta justo después de que haya pasado un tiempo especificado.
CompositeBehaviour: Esta clase se compone de diferentes sub-behaviours que se pueden ejecutar siguiendo diferentes políticas de planificación, las cuales vienen determinadas por la subclase elegida, las que pueden ser: SequentialBehaviour, ParallelBehaviour y FSMBehavior.
SequentialBehaviour: Esta clase deriva de CompositeBehaviour y ejecuta sub-behaviours de forma secuencial, y termina cuando todos los métodos action() han terminado.

ParallelBehaviour: Esta clase deriva de CompositeBehaviour y ejecuta los sub-behaviours de manera concurrente. En el constructor de la clase se puede especificar cuando se desea que acabe la ejecución: cuando todos los sub-behaviours lo han hecho, cuando uno termine, o cuando un numero especificado lo logre.

FSMBehaviour: Esta clase permite definir una maquina de estados finita mediante sub-behaviours. Cada sub- comportamiento representa un estado de la maquina, y las transiciones se van produciendo según la salida de dichos estados. La finalización se alcanza cuando se termine de ejecutar algún sub-behaviour que se haya registrado como estado final.

Adjunto dos codigos de ejemplo para que vean lo facil que es agregar comportamientos a un agente.

En el proximo post veremos mensajeria y ACL.

Conceptos básicos de programación de un agente en JADE

noreply@blogger.com (José Luis Coronel Cortés) — Fri, 14 Mar 2008 17:40:00 +0000

Hasta el momento hemos visto parte de la especificación FIPA y algunas de las funcionalidades básicas de JADE….pero falta lo mas importante, la programación de un agente, para luego continuar con un SMA!!!

Para crear un agente en JADE se debe extender la clase jade.core.Agent. Esta contiene dos métodos muy importantes que tienen que ser implementados necesariamente. Estos son setup() y takedown(), los cuales permiten inicializar y finalizar el agente respectivamente.

La siguiente figura muestra la estructura de un agente:

Cada agente del sistema multiagente será una instancia de una clase java que sea subclase de la clase Agent. Esta clase se compondrá básicamente de un método setup, que se ejecutara al iniciarse el agente y que contendrá código de inicialización, incluyendo instrucciones que especificaran la ontología a utilizar y los comportamientos asociados al agente. Además del método setup, se dispondrá de una clase interna a la clase del agente por cada uno de los comportamientos asociados al agente.

Estos comportamientos básicamente se utilizan para el envió y recepción de mensajes, aunque también se podrían realizar otras tareas

A continuación se muestra el código del agente EstructuraBasica, correspondiente a un agente simple al que no se ha asociado ningún comportamiento ni ninguna ontología, y que se tomara como base para implementar los futuros ejemplos de agentes:

package ejemplo1;

import jade.core.Agent;
import jade.domain.FIPAAgentManagement.ServiceDescription;
import jade.domain.FIPAAgentManagement.DFAgentDescription;
import jade.domain.DFService;
import jade.domain.FIPAException;

public class EstructuraBasica extends Agent {

protected void setup() {
/* Registrarse con el agente DF */
DFAgentDescription dfd = new DFAgentDescription();
ServiceDescription sd = new ServiceDescription();
sd.setType("EstructuraBasica");
sd.setName(getName());
dfd.setName(getAID());
dfd.addServices(sd);
try {
DFService.register(this,dfd);
}
catch (FIPAException e) {
System.err.println("Problemas : " +e.getMessage());
doDelete();
}
}

}

En este ejemplo se observa como el agente EstructuraBasica es una subclase de Agent y por lo tanto se pueden crear agentes de la clase EstructuraBasica utilizando "java jade.Boot". Todos los agentes heredan la clase jade.core.Agent, para lo cual cada uno de estos al momento de ser creado tiene un identificador único el cual es un objeto de la clase jade.core.AID. El AID que se genera es del tipo:

nombre_agente@host:puerto/JADE

Al momento de crearse el agente se realizan varias tareas automáticamente; algunas de estas son:

Se llama al constructor del agente
Se crea un identificador del agente (AID)
Se registra el agente en el AMS
Se ejecuta el método setup

En el método setup se pueden realizar las siguientes operaciones:

Modificar el registro del AMS
Registra el agente en el DF
Agregar los comportamientos (Behaviours) que ejecutara el agente

Otros métodos con los que cuenta la clase Agent son:

doDelete: Finaliza la ejecución del agente.
TakeDown: Se ejecuta antes de que el agente finalice. Un uso común es el de desregistrar al agente del DF.

La siguiente figura muestra el ciclo de ejecución de un agente:

El acceso a los métodos del DF se realiza importando la clase jade.domain.DFService con la cual se construyen dos tipos de objetos:

DFAgentDescription: Permite guardar el nombre del agente y el o los tipos de servicios que este desea registrar.
ServiceDescription: Permite guardar el nombre y tipo de servicio que el agente desea registrar.

Hay que recordar que el AMS es un agente de gestión que controla el estado y el acceso a la plataforma. También proporciona un servicio de ”páginas blancas” que permite la localización de agentes a partir de sus nombres, y que el DF proporciona un servicio de “páginas amarillas” al resto de los agentes. Los agentes usan el DF para registrar sus servicios o para obtener los servicios de los demás agentes.

Estos serán unos puntos muy importantes al momento de desarrollar un SMA.

Con esto hasta el momento hemos visto la estructura básica de un agente, los métodos mas importantes que componen las estructura de un agente y una pequeña descripción de estos.

Para que sea mas claro les adjunto un video en el cual se detalla la ejecución de cuatro agentes básicos de ejemplo, estos son:

BuscarAMS: Permite obtener una lista de todos los agentes que se encuentren registrados en el AMS.
RegistrarDF: Permite registrar un servicio en el directorio facilitador.
BuscarDF: Permite obtener un listado de todos los servicios registrados en el directorio facilitador.
EjemploCompletoDF: Permite registrar un servicio en el directorio facilitador y obtener un listado de los agentes registrados en el DF que presten un servicio determinado.

En el próximo post veremos los distintos tipos de comportamientos (Behaviours) y comenzaremos a programar nuestros primeros SMA.

Herramientas de JADE

noreply@blogger.com (José Luis Coronel Cortés) — Sat, 08 Mar 2008 02:32:00 +0000

Hasta el momento hemos visto parte del estándar FIPA, ahora veremos como este se encuentra implementado en JADE.

JADE dispone de un conjunto de herramientas para ayudar en la administración y monitorización de los procesos de depuración del sistema.

Para poder iniciar una sesión y crear los agentes, se debe escribir el siguiente comando en alguna consola de sistema:

java jade.Boot -platform [opciones] [lista de agentes]

En el campo de opciones se puede especificar por ejemplo si se quiere ejecutar el entorno grafico, para lo cual se debe escribir el parámetro “-gui”. Respecto a la lista de agentes, esta debe ser una cadena de texto, donde cada uno de ellos se debe encontrar separado por un espacio en blanco y seguir el siguiente formato:

[Nombre_Agente]:ClasseJava

La siguiente figura muestra la ejecución de la pantalla principal de JADE:

Cuando se ejecuta el entorno grafico, aunque no se inicie ningún agente propio, se crearan tres agentes automaticamente:

El agente RMA: El cual se encuentra encargado de controlar la interfaz.
El agente DF: En donde se suscribirán los servicios de los agentes.
El agente AMS: En donde se guardaran las direcciones de los agentes.

En la parte superior de la interfaz se encuentra la barra de menu, la cual contiene las siguientes opciones:

File:

Close RMA Agent: Cierra la interfaz anteriormente mostrada, aunque la plataforma de agentes continuara funcionando, así como todos aquellos agentes que estuvieran activos.
Exit this container: Destruye el container donde el agente RMA se aloja, matando a este agente y todos aquellos que le acompañaran dentro del container. Si dicho container es el MainContainer será toda la plataforma la que se desactivara.
Shutdown Agent Platform: Cierra totalmente la plataforma, eliminando todos los agentes y containers.

Actions:

Start New Agent: Esta acción crea un agente. Al usuario se le preguntara por el nombre del agente y la clase a la cual se instanciara (los agentes son instancias de alguna clase). Si hubiera algún container seleccionado, este será en el que dicho agente se alojara. También se puede indicar el nombre del container en el que se desea ejecutar el agente.
Kill: Mata a todos los agentes y elimina todos los containers seleccionados. Si el MainContainer estuviera seleccionado, la plataforma entera seria cerrada.
Suspend: Suspende los agentes seleccionados.
Resume: Este comando vuelve a poner en estado de activo los agentes seleccionados que estuvieran suspendidos.
Send Message: Este comando permite enviar un mensaje ACL a un agente.
Migrate Agent: Esta acción permite migrar un agente. Cuando se selecciona, un dialogo es mostrado en donde el usuario debe especificar el container de la plataforma donde el agente seleccionado debe migrar. No todos los agentes pueden ser migrados debido a una falta de serializacion en su implementación.
Clone Agent: Esta opción permite clonar un agente. Cuando es seleccionado, un cuadro de dialogo es mostrado donde el usuario debe introducir el nombre del nuevo agente y el container donde será alojado.

Tools:

Start Sniffer: Crea un agente de tipo Sniffer. El agente Sniffer es una de las herramientas que proporciona la JADE para la depuración durante el proceso de desarrollo del sistema multiagente. Básicamente permite comprobar como se produce la interacción e intercambio de mensajes entre los agentes que se seleccionen.

Para iniciar el agente Sniffer primero se debe seleccionar el contenedor donde se alojara, y tras ello seleccionar dentro del menú Tools la opción Start Sniffer o pulsar el botón correcto de la barra de botones.

Tras hacer esto se creara un nuevo agente en el contenedor seleccionado. Se le asignara automaticamente un nombre sniffer0 como se muestra en la siguiente imagen de ejemplo:

Asociado al agente Sniffer se dispone de una interfaz grafica en la que se irán viendo los mensajes enviados y recibidos por los distintos agentes que se hayan decidido inspeccionar.

La siguiente figura muestra la interfaz del agente Sniffer:

En la parte superior se dispone de una barra de menús, con una barra de botones debajo correspondiendo cada uno de estos botones con las distintas opciones del primero de los menús. En la parte inferior se dispone de dos paneles. En el de la izquierda se muestra el árbol de plataformas, contenedores y agentes. En la parte derecha se puede ver el intercambio de mensajes entre los agentes seleccionados. Las opciones del menú Actions más importantes, que van a permitir realizar la depuración de la plataforma multiagente que se este desarrollando, son las siguientes:

Do sniff this agent(s): Añade el o los agentes seleccionados al panel de la derecha donde se visualiza el intercambio de mensajes.
Do not sniff this agent(s): Elimina el agente o los agentes seleccionados del panel de la derecha donde se visualiza el intercambio de mensajes.
Show only agent(s): Añade el agente o agentes seleccionados al panel donde se visualiza el intercambio de mensajes, pero solo mostrara el agente, no los mensajes que lleguen hasta el o provengan de el.
Clear Canvas: Borra todos los mensajes que estuvieran dibujados hasta el momento en el panel. Se continúa con el proceso de depuración.

Una vez elegidos los agentes para los que se desea observar su intercambio de mensajes, la ventana tendrá un aspecto similar al siguiente:

Los mensajes enviados y recibidos aparecen en orden cronológico comenzando desde la parte superior. Si queremos analizar los distintos campos de un mensaje no tenemos mas que hacer dobleclick sobre el mensaje que deseemos.

Otra opcion es el DummyAgent:

Start DummyAgent: Crea un agente de tipo DummyAgent. El agente DummyAgent es otra de las herramientas proporcionadas por JADE para la depuración del sistema multiagente. Se trata de un agente enviador de mensajes que tiene asociado una interfaz grafica que permite indicar los distintos campos del mensaje a enviar, así como visualizar los mensajes enviados y recibidos. Lo primero que se debe hacer para crear un agente de este tipo es seleccionar el contenedor donde se alojara. Después seleccionar la opción Start DummyAgent del menú Tools, o el botón correspondiente de la barra de botones.

Al nuevo DummyAgent se le asignara automaticamente un nombre y se desplegara un cuadro de dialogo con el que se puede acceder a todas las funcionalidades de este, como se muestra en la siguiente figura:

Básicamente se trata de un agente que permite enviar mensajes y visualizar la cola de mensajes enviados y recibidos, ası como los detalles de cada uno de estos mensajes. En la parte superior se dispone de la barra de menús, con una barra de iconos que representan las distintas acciones disponibles. Bajo esta se encuentra una serie de botones cuya funcionalidad coincide con la de las distintas opciones de los menús superiores. La parte principal de la ventana esta dividida en dos. En la izquierda se dispone de una serie de campos donde se puede introducir el valor de los campos del mensaje a enviar. En la parte derecha se muestra la cola de mensajes enviados y recibidos. Haciendo doble-click sobre alguno de estos mensajes se puede ver el valor de cada uno de sus campos. Con respecto a los menús, a continuación se muestra la función de cada una de sus opciones:

Menu General:

Exit: Cierra el dialogo del agente DummyAgent, eliminándolo de la plataforma.

Menu Current message:

Reset: Vacía todos los campos del mensaje a enviar.
Send: Envia el mensaje con los valores de los campos especificados en la parte izquierda del dialogo. Al hacerlo, se mostrara el mensaje, enviado en la cola de mensajes, en la parte derecha de la ventana, así como las contestaciones, en el caso de que las hubiera.
Open: Abre un mensaje almacenado en disco.
Save: Guarda el mensaje en disco.

Menu Queued message:

Open queue: Abre una cola de mensajes almacenados en el disco.
Save queue: Guarda la cola de mensajes en disco.
Set as current: Toma los valores de los campos del mensaje seleccionado en la cola de mensajes y rellena los campos de la parte izquierda de la ventana correspondientes al mensaje a enviar con dichos valores.
Reply: Permite crear un mensaje de respuesta.
View: Muestra un cuadro de dialogo donde se puede examinar los valores de los campos del mensaje seleccionado de la cola de mensajes.
Delete: Elimina el mensaje seleccionado de la cola de mensajes.
Show the DF GUI: Activa la interfaz del agente DF, desde la cual se puede observar los agentes que se han registrado y que servicios ofrecen.

La siguiente figura muestra la interfaz del DF:

Otra opicion es el InstrospectorAgent:

Start IntrospectorAgent: Inicia un agente de tipo IntrospectorAgent, mostrando su interfaz asociada. Este agente permite monitorizar y controlar el ciclo de vida de un agente y muestra las colas de entrada y salida de mensaje.

La siguiente figura muestra la interfaz del IntrospectorAgent:

Tambien se encuntr la opcion para ver las peltaformas remotas:

Remote Platforms: Este menú permite controlar plataformas remotas que cumplan con las especificaciones FIPA. Estas plataformas no tienen por que ser JADE.

Hasta ahora ya hemos visto de manera rápida parte de la especificación FIPA y como JADE implementa esta y las opciones de las que dispone el framework para administrar los agentes.

En el próximo post comenzaremos con la programación en JADE, veremos la estructura de un agente, como registrarse en el DF, la comunicación con ACL…...y muchas cosas mas que se encuentran en el desarrollo de agentes inteligentes y SMA.

Ya se encuentra disponible la version 1.0 de JADE-ANDROID

noreply@blogger.com (José Luis Coronel Cortés) — Mon, 03 Mar 2008 22:46:00 +0000

Android es una plataforma para desarrollar aplicaciones para dispositivos móviles que incluyan el sistema operativo realizado por el Open Handset Alliance en Noviembre del 2007(mas información en http://code.google.com/android/ y http://www.openhandsetalliance.com/ ).

El lenguaje de programación en Android es Java, el cual incluye la nueva maquina virtual Dalvik, la cual permite acceder a todas las funcionalidades propias del dispositivo móvil.

La posibilidad de combinar la expresividad de FIPA soportada por los agentes en JADE junto con el poder de la plataforma Android, permitirá el desarrollo de innovadoras aplicaciones basadas en modelos sociales y peer-to-peer.

JADE-Android es distribuido como un add-on de JADE y se encuentra disponible para descarga bajo licencia LGPL en la sitio web de JADE. Este add-on también incluye una aplicación de ejemplo llamada Dummy Agent la cual corre sobre Android SDK m5-rc14

Información mas detallada acerca de como usar JADE-Android puede ser encontrada en la guía del usuario incluida en el archivo de distribución del add-on.

Este será un gran año para la comunidad Jade, ya que junto con este add-on, también tenemos la nueva versión del add-on WSIG (Web Service Integration Getawey) pronto tendremos la nueva versión de JADE y WADE.

FIPA parte 2

noreply@blogger.com (José Luis Coronel Cortés) — Sun, 24 Feb 2008 22:32:00 +0000

Continuando con la especificación FIPA, terminare de detallar alguno de los puntos mas importantes para luego ver como esta se encuentra implementada en JADE.

El Directorio Facilitador (DF) proporciona un servicio de paginas amarillas al resto de los agentes. Cualquier plataforma de agentes FIPA tiene que tener al menos un DF. Los agentes usan el DF para registrar sus servicios o para obtener los servicios de los demás agentes.

Los DF’s pueden registrarse entre ellos. De la misma forma, los componentes AMS y ACC también pueden registrarse con un DF. Todos los DF’s tienen un nombre por defecto que empieza por ”df ”.

Las acciones de gestión que soporta son:

register: Petición de registro de los servicios de un agente.
search: Petición de búsqueda de agentes que proporcionen determinados servicios.
deregister: Petición de borrado de los servicios registrados de un agente.
modify: Petición de modificación de los servicios registrados de un agente

Solo un Agent Management System (AMS) puede existir en una plataforma de agentes FIPA. Este es responsable de gestionar las operaciones de su plataforma tales como la creación de agentes, borrado de agentes, decidir si un agente puede registrarse en la plataforma y supervisar la migración de los agentes a/desde la plataforma.

El AMS es la autoridad en toda la plataforma. Puede solicitar a un agente que finalice su ejecución (quit) e incluso obligarle a finalizar.

El AMS gestiona una lista con todos los agentes que se encuentran en la plataforma. En la lista se encuentran las identificaciones GUID de los agentes asociadas a sus direcciones en la plataforma. Para que un agente resida en la plataforma tiene que registrarse con el AMS.

Todos los AMS tienen un nombre por defecto que empieza con “ams”. Las acciones de gestión que tiene que soportar cualquier AMS son:

register-agent: Petición de registro de un agente.
deregister-agent: Petición de borrar del registro a un agente.
modify-agent: Petición de modificación del registro de un agente.
query-platform-profile: Petición del perfil de la plataforma.
authenticate: Petición de autentificar la identidad de un agente creado en la plataforma.
search-agent: Petición de búsqueda de la dirección de un agente.

Existe una acción de gestión para movilidad que también tiene que soportar cualquier AMS:

move: Petición de transferencia/migración de un agente.

Además de las acciones de gestión intercambiadas entre el AMS y los agentes en la plataforma, el AMS puede proporcionar a la plataforma la realización de las siguientes operaciones:

suspend agent: Suspender o parar la ejecución de una agente.
terminate agent: Finalizar la ejecución de un agente.
create agent: Crear un agente.
resume agent execution: Continuar con la ejecución de un agente suspendido.
invoke agent: Empezar la ejecución de un agente recién creado.
execute agent: Ejecutar un agente después de moverse.
resource management: Gestionar los recursos.

Existe una acción de gestión que tienen que soportar los agentes utilizados por el AMS:

quit: Petición de terminación de un agente, la cual finaliza la ejecución del agente que recibe la solicitud.

El ACC proporciona el encaminamiento de mensajes entre agentes de diferentes plataformas FIPA. Todos los agentes FIPA tienen acceso al menos a un ACC. Únicamente mensajes dirigidos a agentes pueden ser enviados a un ACC.

El encaminamiento de mensajes entre diferentes plataformas requiere un protocolo de interoperabilidad por defecto (especificándose el protocolo de transporte, codificación y direccionamiento). Este protocolo es IIOP.

La acción de gestión que soporta es:

forward: Petición de envió de un mensaje desde un agente a otro.

Esta acción no debe de interpretarse como el mecanismo por defecto para enviar mensajes entre los agentes de la misma plataforma. Estos podrán comunicarse empleando el método interno (IPMT) que se haya implementado en la plataforma.

Dentro del Agent Plataform (AP) el ciclo de vida de los agentes FIPA esta caracterizado por:

Definir los posibles estados y transiciones de un agente independientemente del tipo de implementación de la plataforma.
Cada agente es físicamente gestionado en una plataforma. Si el agente es estacionario, su ciclo de vida siempre será en la misma plataforma.
Cada agente descrito con el modelo de ciclo de vida es asumido como una instancia con nombre propio y único que se ejecuta de forma independientemente.
Cada agente solo puede encontrase en un estado en una única plataforma al mismo tiempo.

El ciclo de vida de los agentes se representa mediante estados y transiciones, los cuales se muestran en la siguiente figura:

Únicamente los agentes móviles pueden entrar en el estado “transit”. Esto asegura que los agentes estacionarios ejecuten todas sus instrucciones en el nodo donde fueron invocados.

Las acciones para pasar los agentes de un estado a otro son:

Create: Creación de un nuevo agente.
Invoke: Invocación o activación de un nuevo agente una vez inicializado.
Destroy: Se fuerza la terminación de un agente. Esta acción solo puede ser iniciada por el AMS y no puede ser ignorada.
Quit: Se solicita la terminación de un agente. El agente puede ignorar la acción.
Suspend: Pone a un agente en el estado de suspendido. Esta acción puede ser iniciada por el propio agente o por el AMS.
Resume: Saca a un agente del estado suspendido. Esta acción solo puede ser iniciada por el AMS.
Wait: Pone a un agente en el estado de espera. Esta acción solo puede ser iniciada por el propio agente.
Wake up: Saca a un agente del estado de espera. Esta acción solo puede ser iniciada por el AMS.

Las siguientes acciones solo son usadas por los agentes móviles:

Move: Pone a un agente en el estado de transición. Esta acción solo puede ser iniciada por el propio agente.
Execute: Saca al agente del estado

La plataforma en la cual se creo un agente se denomina la Home Agent Platform (HAP) de dicho agente. La responsabilidad del HAP es garantizar la identidad del agente en sus relaciones con otros agentes y plataformas. El estándar FIPA requiere que cada agente tenga un HAP que responda por el ante el resto de la comunidad de agentes. Por tal motivo:

Es necesario que a partir del análisis del GUID de un agente pueda obtenerse la dirección IIOP-URL del HAP.

Es necesario que el HAP pueda autentificar la identidad del agente en la plataforma. Para ello, el AMS del HAP soporta la acción “authenticate”.

El AMS del HAP de un agente es responsable de guardar la dirección de dicho agente. Por otro lado, el agente tiene la responsabilidad de asegurar que la dirección guardada por el AMS sea valida. Un agente siempre debe registrarse en su HAP. El nombre de un agente (GUID) es el mismo durante toda su existencia.

Un agente puede registrarse en una plataforma si se cumple alguna de las siguientes condiciones:

El agente se creo en la plataforma.
El agente migro a la plataforma. Ambas plataformas, HAP y destino, tienen que soportar movilidad de agentes.
El agente se registra dinámicamente en una plataforma diferente a su HAP como agente local. Ambas plataformas tienen que soportar registro dinámico.

Al registrarse un agente se facilita al AMS la siguiente información:

El identificador global y único del agente (GUID).
La dirección local del agente.

El agente se registra en el AMS mediante la acción “register-agent”.

Un agente tiene dos opciones cuando desea contactarse (enviar un mensaje) con otro agente de una plataforma diferente:

Puede solicitar que el ACC de su plataforma envié el mensaje al ACC y agente de la otra plataforma.
Puede contactarse directamente con el ACC de la otra plataforma y enviarle el mensaje.

Es necesario el GUID del agente destino para poder contactar con el. El mensaje se enviara al HAP del agente destino y a partir de aquí se hará llegar a dicho agente. Alternativamente, si se desea enviar el mensaje directamente al agente o a una plataforma (distinta del HAP) donde el agente se registro dinámicamente, entonces se deberá indicar además del GUID la dirección destino.

Aun quedan puntos pendientes por ver de la especificación, pero ya que con lo visto hasta ahora podemos comenzar a ver los primeros códigos de ejemplo en JADE….pero eso será para el próximo post.

Introduccion a FIPA - parte 1

noreply@blogger.com (José Luis Coronel Cortés) — Sun, 24 Feb 2008 00:00:00 +0000

El creciente desarrollo de grupos de investigación en torno a los sistemas multiagente fomento la aparición de nuevas formas para el desarrollo de esta tecnología, lo cual conllevo a que cada uno de estos grupos presentara soluciones diferentes e independientes.

Algunos problemas que se presentaron fue la carencia de una definición estándar de sistema multiagente e incompatibilidad, lo que conllevo a una incapacidad para satisfacer los fuertes requisitos de las empresas e industrias actuales.

Esto promovió la creación de diversos organismos, los cuales se preocuparıan de desarrollar una definición estándar para la construcción de sistemas multiagente. Algunos de estos organismos son:

OMG (Object Management Group) quienes desarrollaron MASIF (Mobile Agent System Interoperability Facilities).

KSE (Knowledge Sharing Effort) quienes desarrollaron KQML (Knowledge Querying and Manipulation Language) y KIF (Knowledge Interchange Format).

Agent Society, cuya labor principal es el intercambio y recopilación de información sobre agentes.

FIPA (Foundation for Intelligent Physical Agents) cuya labor principal es el desarrollo de especificaciones de una arquitectura para sistemas multiagente, infraestructura y aplicaciones.

De estos, FIPA es el que más relevancia a tomado fuerza estos últimos años.

En su versión inicial (FIPA 97) tres documentos integraban esta parte del estándar:

Agent Management
Agent Communication Language

Agent/Software Integration

Posteriormente se han ido actualizando e incluyendo nuevos documentos hasta alcanzar la versión de FIPA-2000 con la que actualmente se trabaja.

El “Agent Management” proporciona la normativa del entorno donde los agentes FIPA se crean y operan. Establece el modelo lógico de referencia para la gestión de agentes (creación, registro, localización, comunicación, migración y terminación de los agentes). El modelo presenta un conjunto de capacidades lógicas y no implica ninguna configuración física, sino que deja los detalles de implementación a elección del equipo de desarrollo.

Agente: Es el componente básico y principal del modelo. Combina una o más capacidades de servicio dentro de un entorno de ejecución integrado y unificado que proporciona servicios de comunicación, acceso a software externo y acceso a los usuarios.

Un agente tiene que tener uno o más dueños. Además debe disponer de una identidad propia proporcionada por un identificador global y único GUID (Globally Unique Identifier) denominado nombre del agente. Una gente puede registrarse con un número de direcciones en las cuales puede ser contactado.

Agent Platform (AP): Proporciona la infraestructura fısica y lógica necesaria en la cual los agentes pueden ejecutarse. Una plataforma de agentes esta constituida por el hardware (puede haber varios computadores), el sistema operativo, software de comunicaciones y software de agentes.

Directory Facilitator (DF): Componente que siempre tiene que aparecer en cualquier plataforma de agentes FIPA. Es un agente que proporciona un servicio de ”paginas amarillas” a los demás agentes. Un agente puede utilizar el DF para registrar sus servicios o para encontrar los servicios ofrecidos por otros agentes.

Agent Management System (AMS): Componente que siempre tiene que aparecer en cualquier plataforma de agentes FIPA, uno por plataforma. Es un agente de gestión que controla el estado y el acceso a la plataforma. También proporciona un servicio de ”paginas blancas” que permite la localización de agentes a partir de sus nombres.

Agent Communication Channel (ACC): Todos los agentes tienen acceso al menos a un ACC. El ACC es el canal de comunicación por defecto entre agentes de diferentes plataformas. Tiene que soportar el protocolo de comunicación para interoperabilidad IIOP (Internet Inter-ORB Protocol ).

Internal Platform Message Transport (IPMT): Método de intercambio de mensajes dentro de la misma plataforma el cual depende de la implementación.

El modelo de referencia para la gestión de agentes esta formado por los siguientes componentes lógicos, los cuales se muestran en la siguiente figura:

En el próximo post continuare detallando el estándar FIPA, pera luego comenzar con la parte entretenida..….la programación de agentes y sistemas multiagentes!!!!

JADE WADE (Workflow and Agent Development Environment)

noreply@blogger.com (José Luis Coronel Cortés) — Fri, 22 Feb 2008 00:37:00 +0000

En el AAMAS 2008 (Autonomous Agents and Multuagent Systems) se presentara un tutorial de WADE, el cual es la principal evolución de JADE y añade a este la habilidad de definir sistemas lógicos dentro de un workflow. WADE no es precisamente un add-on, pero si es un complemento para la plataforma (esta construido sobre JADE) proveyendo administración avanzada, mecanismos de tolerancia a fallos y habilitando a un grupo de agentes, ejecutar cooperativamente complejas tareas definidas en el workflow. WADE será liberado como Open Source en Abril de este año junto con la versión 3.6 de JADE.

Más información en http://gaips.inesc-id.pt/aamas2008/tutorials.html