Tutorial de Tomcat en Cluster

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

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

Agregamos el “jvmRoute” para cada caso.

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

Descomentamos el tag “cluster”

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

Nodo1

<br /><!-- Note: A "Server" is not itself a "Container", so you may not define subcomponents such as "Valves" at this level. Documentation at /docs/config/server.html --><br /><br /><server port="8015" shutdown="SHUTDOWN"><br /><br /><br /><br /> <!--APR library loader. Documentation at /docs/apr.html --><br /><br /> <listener classname="org.apache.catalina.core.AprLifecycleListener" sslengine="on"><br /><br /> <!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html --><br /><br /> <listener classname="org.apache.catalina.core.JasperListener"><br /><br /> <!-- JMX Support for the Tomcat server. Documentation at /docs/non-existent.html --><br /><br /> <listener classname="org.apache.catalina.mbeans.ServerLifecycleListener"><br /><br /> <listener classname="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"><br /><br /><br /><br /> <!-- Global JNDI resources Documentation at /docs/jndi-resources-howto.html --><br /><br /> <globalnamingresources><br /><br /> <!-- Editable user database that can also be used by UserDatabaseRealm to authenticate users --><br /><br /> <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"><br /><br /> </globalnamingresources><br /><br /><br /><br /> <!-- A "Service" is a collection of one or more "Connectors" that share a single "Container" Note: A "Service" is not itself a "Container", so you may not define subcomponents such as "Valves" at this level. Documentation at /docs/config/service.html --><br /><br /> <service name="Catalina"><br /><br /><br /><br /> <!-- A "Connector" represents an endpoint by which requests are received and responses are returned. Documentation at : Java HTTP Connector: /docs/config/http.html (blocking & non-blocking) Java AJP Connector: /docs/config/ajp.html APR (HTTP/AJP) Connector: /docs/apr.html Define a non-SSL HTTP/1.1 Connector on port 8080 --><br /><br /> <connector port="8081" protocol="HTTP/1.1" maxthreads="150" connectiontimeout="20000" redirectport="8443"><br /><br /><br /><br /> <!-- Define a SSL HTTP/1.1 Connector on port 8443 This connector uses the JSSE configuration, when using APR, the connector should be using the OpenSSL style configuration described in the APR documentation --><br /><br /> <!-- <connector port="8443" protocol="HTTP/1.1" sslenabled="true" maxthreads="150" scheme="https" secure="true" clientauth="false" sslprotocol="TLS"><br /><br /> --><br /><br /><br /><br /> <!-- Define an AJP 1.3 Connector on port 8009 --><br /><br /> <connector port="8109" protocol="AJP/1.3" redirectport="8443"><br /><br /><br /><br /><br /><br /> <!-- An Engine represents the entry point (within Catalina) that processes every request. The Engine implementation for Tomcat stand alone analyzes the HTTP headers included with the request, and passes them on to the appropriate Host (virtual host). Documentation at /docs/config/engine.html --><br /><br /><br /><br /> <!-- You should set jvmRoute to support load-balancing via AJP ie : --><br /><br /> <engine name="Standalone" defaulthost="localhost" jvmroute="tomcatNodo1"> <br /><br /> <br /><br /> <engine name="Catalina" defaulthost="localhost"><br /><br /><br /><br /> <!--For clustering, please take a look at documentation at: /docs/cluster-howto.html (simple how to) /docs/config/cluster.html (reference documentation) --><br /><br /> <br /><br /> <cluster classname="org.apache.catalina.ha.tcp.SimpleTcpCluster"><br /><br /> <br /><br /><br /><br /> <!-- The request dumper valve dumps useful debugging information about the request and response data received and sent by Tomcat. Documentation at: /docs/config/valve.html --><br /><br /> <!-- <valve classname="org.apache.catalina.valves.RequestDumperValve"><br /><br /> --><br /><br /><br /><br /> <!-- This Realm uses the UserDatabase configured in the global JNDI resources under the key "UserDatabase". Any edits that are performed against this UserDatabase are immediately available for use by the Realm. --><br /><br /> <realm classname="org.apache.catalina.realm.UserDatabaseRealm" resourcename="UserDatabase"><br /><br /><br /><br /> <!-- Define the default virtual host Note: XML Schema validation will not work with Xerces 2.2. --><br /><br /> <host name="localhost" appbase="webapps" unpackwars="true" autodeploy="true" xmlvalidation="false" xmlnamespaceaware="false"><br /><br /><br /><br /> <!-- SingleSignOn valve, share authentication between web applications Documentation at: /docs/config/valve.html --><br /><br /> <!-- <valve classname="org.apache.catalina.authenticator.SingleSignOn"><br /><br /> --><br /><br /><br /><br /> <!-- Access log processes all example. Documentation at: /docs/config/valve.html --><br /><br /> <!-- <valve classname="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="common" resolvehosts="false"><br /><br /> --><br /><br /><br /><br /> </host><br /><br /> </engine><br /><br /> </service><br /><br /></server><br /><br />

Nodo2

<br /><!-- Note: A "Server" is not itself a "Container", so you may not define subcomponents such as "Valves" at this level. Documentation at /docs/config/server.html --><br /><br /><server port="8205" shutdown="SHUTDOWN"><br /><br /><br /><br /> <!--APR library loader. Documentation at /docs/apr.html --><br /><br /> <listener classname="org.apache.catalina.core.AprLifecycleListener" sslengine="on"><br /><br /> <!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html --><br /><br /> <listener classname="org.apache.catalina.core.JasperListener"><br /><br /> <!-- JMX Support for the Tomcat server. Documentation at /docs/non-existent.html --><br /><br /> <listener classname="org.apache.catalina.mbeans.ServerLifecycleListener"><br /><br /> <listener classname="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"><br /><br /><br /><br /> <!-- Global JNDI resources Documentation at /docs/jndi-resources-howto.html --><br /><br /> <globalnamingresources><br /><br /> <!-- Editable user database that can also be used by UserDatabaseRealm to authenticate users --><br /><br /> <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"><br /><br /> </globalnamingresources><br /><br /><br /><br /> <!-- A "Service" is a collection of one or more "Connectors" that share a single "Container" Note: A "Service" is not itself a "Container", so you may not define subcomponents such as "Valves" at this level. Documentation at /docs/config/service.html --><br /><br /> <service name="Catalina"><br /><br /><br /><br /> <!-- A "Connector" represents an endpoint by which requests are received and responses are returned. Documentation at : Java HTTP Connector: /docs/config/http.html (blocking & non-blocking) Java AJP Connector: /docs/config/ajp.html APR (HTTP/AJP) Connector: /docs/apr.html Define a non-SSL HTTP/1.1 Connector on port 8080 --><br /><br /> <connector port="8082" protocol="HTTP/1.1" maxthreads="150" connectiontimeout="20000" redirectport="8443"><br /><br /><br /><br /> <!-- Define a SSL HTTP/1.1 Connector on port 8443 This connector uses the JSSE configuration, when using APR, the connector should be using the OpenSSL style configuration described in the APR documentation --><br /><br /> <!-- <connector port="8443" protocol="HTTP/1.1" sslenabled="true" maxthreads="150" scheme="https" secure="true" clientauth="false" sslprotocol="TLS"><br /><br /> --><br /><br /><br /><br /> <!-- Define an AJP 1.3 Connector on port 8009 --><br /><br /> <connector port="8209" protocol="AJP/1.3" redirectport="8443"><br /><br /><br /><br /><br /><br /> <!-- An Engine represents the entry point (within Catalina) that processes every request. The Engine implementation for Tomcat stand alone analyzes the HTTP headers included with the request, and passes them on to the appropriate Host (virtual host). Documentation at /docs/config/engine.html --><br /><br /><br /><br /> <!-- You should set jvmRoute to support load-balancing via AJP ie : --> <br /><br /> <engine name="Standalone" defaulthost="localhost" jvmroute="tomcatNodo2"> <br /><br /> <br /><br /> <engine name="Catalina" defaulthost="localhost"><br /><br /><br /><br /> <!--For clustering, please take a look at documentation at: /docs/cluster-howto.html (simple how to) /docs/config/cluster.html (reference documentation) --><br /><br /> <br /><br /> <cluster classname="org.apache.catalina.ha.tcp.SimpleTcpCluster"><br /><br /> <br /><br /><br /><br /> <!-- The request dumper valve dumps useful debugging information about the request and response data received and sent by Tomcat. Documentation at: /docs/config/valve.html --><br /><br /> <!-- <valve classname="org.apache.catalina.valves.RequestDumperValve"><br /><br /> --><br /><br /><br /><br /> <!-- This Realm uses the UserDatabase configured in the global JNDI resources under the key "UserDatabase". Any edits that are performed against this UserDatabase are immediately available for use by the Realm. --><br /><br /> <realm classname="org.apache.catalina.realm.UserDatabaseRealm" resourcename="UserDatabase"><br /><br /><br /><br /> <!-- Define the default virtual host Note: XML Schema validation will not work with Xerces 2.2. --><br /><br /> <host name="localhost" appbase="webapps" unpackwars="true" autodeploy="true" xmlvalidation="false" xmlnamespaceaware="false"><br /><br /><br /><br /> <!-- SingleSignOn valve, share authentication between web applications Documentation at: /docs/config/valve.html --><br /><br /> <!-- <valve classname="org.apache.catalina.authenticator.SingleSignOn"><br /><br /> --><br /><br /><br /><br /> <!-- Access log processes all example. Documentation at: /docs/config/valve.html --><br /><br /> <!-- <valve classname="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="common" resolvehosts="false"><br /><br /> --><br /><br /><br /><br /> </host><br /><br /> </engine><br /><br /> </service><br /><br /></server><br /><br />

Nodo3

<br /><!-- Note: A "Server" is not itself a "Container", so you may not define subcomponents such as "Valves" at this level. Documentation at /docs/config/server.html --><br /><br /><server port="8305" shutdown="SHUTDOWN"><br /><br /><br /><br /> <!--APR library loader. Documentation at /docs/apr.html --><br /><br /> <listener classname="org.apache.catalina.core.AprLifecycleListener" sslengine="on"><br /><br /> <!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html --><br /><br /> <listener classname="org.apache.catalina.core.JasperListener"><br /><br /> <!-- JMX Support for the Tomcat server. Documentation at /docs/non-existent.html --><br /><br /> <listener classname="org.apache.catalina.mbeans.ServerLifecycleListener"><br /><br /> <listener classname="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"><br /><br /><br /><br /> <!-- Global JNDI resources Documentation at /docs/jndi-resources-howto.html --><br /><br /> <globalnamingresources><br /><br /> <!-- Editable user database that can also be used by UserDatabaseRealm to authenticate users --><br /><br /> <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"><br /><br /> </globalnamingresources><br /><br /><br /><br /> <!-- A "Service" is a collection of one or more "Connectors" that share a single "Container" Note: A "Service" is not itself a "Container", so you may not define subcomponents such as "Valves" at this level. Documentation at /docs/config/service.html --><br /><br /> <service name="Catalina"><br /><br /><br /><br /> <!-- A "Connector" represents an endpoint by which requests are received and responses are returned. Documentation at : Java HTTP Connector: /docs/config/http.html (blocking & non-blocking) Java AJP Connector: /docs/config/ajp.html APR (HTTP/AJP) Connector: /docs/apr.html Define a non-SSL HTTP/1.1 Connector on port 8080 --><br /><br /> <connector port="8083" protocol="HTTP/1.1" maxthreads="150" connectiontimeout="20000" redirectport="8443"><br /><br /><br /><br /> <!-- Define a SSL HTTP/1.1 Connector on port 8443 This connector uses the JSSE configuration, when using APR, the connector should be using the OpenSSL style configuration described in the APR documentation --><br /><br /> <!-- <connector port="8443" protocol="HTTP/1.1" sslenabled="true" maxthreads="150" scheme="https" secure="true" clientauth="false" sslprotocol="TLS"><br /><br /> --><br /><br /><br /><br /> <!-- Define an AJP 1.3 Connector on port 8009 --><br /><br /> <connector port="8309" protocol="AJP/1.3" redirectport="8443"><br /><br /><br /><br /><br /><br /> <!-- An Engine represents the entry point (within Catalina) that processes every request. The Engine implementation for Tomcat stand alone analyzes the HTTP headers included with the request, and passes them on to the appropriate Host (virtual host). Documentation at /docs/config/engine.html --><br /><br /><br /><br /> <!-- You should set jvmRoute to support load-balancing via AJP ie : --> <br /><br /> <engine name="Standalone" defaulthost="localhost" jvmroute="tomcatNodo3"> <br /><br /> <br /><br /> <engine name="Catalina" defaulthost="localhost"><br /><br /><br /><br /> <!--For clustering, please take a look at documentation at: /docs/cluster-howto.html (simple how to) /docs/config/cluster.html (reference documentation) --><br /><br /> <br /><br /> <cluster classname="org.apache.catalina.ha.tcp.SimpleTcpCluster"><br /><br /> <br /><br /><br /><br /> <!-- The request dumper valve dumps useful debugging information about the request and response data received and sent by Tomcat. Documentation at: /docs/config/valve.html --><br /><br /> <!-- <valve classname="org.apache.catalina.valves.RequestDumperValve"><br /><br /> --><br /><br /><br /><br /> <!-- This Realm uses the UserDatabase configured in the global JNDI resources under the key "UserDatabase". Any edits that are performed against this UserDatabase are immediately available for use by the Realm. --><br /><br /> <realm classname="org.apache.catalina.realm.UserDatabaseRealm" resourcename="UserDatabase"><br /><br /><br /><br /> <!-- Define the default virtual host Note: XML Schema validation will not work with Xerces 2.2. --><br /><br /> <host name="localhost" appbase="webapps" unpackwars="true" autodeploy="true" xmlvalidation="false" xmlnamespaceaware="false"><br /><br /><br /><br /> <!-- SingleSignOn valve, share authentication between web applications Documentation at: /docs/config/valve.html --><br /><br /> <!-- <valve classname="org.apache.catalina.authenticator.SingleSignOn"><br /><br /> --><br /><br /><br /><br /> <!-- Access log processes all example. Documentation at: /docs/config/valve.html --><br /><br /> <!-- <valve classname="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="common" resolvehosts="false"><br /><br /> --><br /><br /><br /><br /> </host><br /><br /> </engine><br /><br /> </service><br /><br /></server><br /><br />


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)

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

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

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


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.

<br /><?xml version="1.0" encoding="ISO-8859-1"?><br /><br /><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"><br /><br /> <distributable> <br /><br /></web-app><br /><br />

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:

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

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:

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

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

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

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

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

TomcatNodo2

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

TomcatNodo3

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


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

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.

public interface Sujeto{<br /><br /> public Rol getExtension( String nombreExt );<br /><br />}

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;<br /><br />public interface Sujeto {<br /><br /> public Rol getExtension( String nombreExt );<br /><br />}

package extensionobject.paso1;<br /><br />public interface AccionesBasicas {<br /><br /> void moverBrazos( );<br /> void moverPiernas( );<br /> void moverCabeza( );<br /><br />}

package extensionobject.paso1;<br /><br />public interface AccionFabricante {<br /><br /> void construir();<br /> void disenar();<br /><br />}

package extensionobject.paso1;<br /><br />public interface AccionSoldado {<br /><br /> void atacar();<br /> void defender();<br /><br />}

package extensionobject.paso1;<br /><br />public abstract class Rol {<br /><br />}

package extensionobject.paso1;<br /><br />public class RolFabricante extends Rol implements AccionFabricante{<br /><br /> private AccionesBasicas sujeto;<br /> <br /> public RolFabricante(AccionesBasicas sujeto){<br /> this.sujeto = sujeto;<br /> System.out.println("RolFabricante creado");<br /> }<br /><br /> public void construir(){<br /> System.out.println("Interfaz construir ejecutada");<br /> sujeto.moverBrazos();<br /> sujeto.moverPiernas();<br /> }<br /><br /> public void disenar(){<br /> System.out.println("Interfaz disenar ejecutada");<br /> sujeto.moverCabeza();<br /> sujeto.moverBrazos();<br /> }<br /><br />}

package extensionobject.paso1;<br /><br />public class RolSoldado extends Rol implements AccionSoldado{<br /><br /> private AccionesBasicas sujeto;<br /> <br /> public RolSoldado(AccionesBasicas sujeto){<br /> this.sujeto = sujeto;<br /> System.out.println("RolSoldado creado");<br /> }<br /><br /> public void atacar() {<br /> System.out.println("Interfaz atacar ejecutada");<br /> sujeto.moverBrazos();<br /> sujeto.moverPiernas();<br /> }<br /><br /> public void defender() {<br /> System.out.println("Interfaz defender ejecutada");<br /> sujeto.moverBrazos();<br /> }<br /><br />}

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

package extensionobject.paso1;<br /><br />public class ManejarRobots {<br /><br /> public static void main(String args[]){<br /> MazingerZ robot = new MazingerZ();<br /> AccionSoldado robotSoldado = (AccionSoldado) <br /> robot.getExtension("RolSoldado");<br /> robotSoldado.atacar();<br /> AccionFabricante robotFabricante = <br /> (AccionFabricante) robot.getExtension("RolFabricante");<br /> robotFabricante.disenar();<br /> }<br /><br />}

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í).

public abstract class Rol {<br /><br />}

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;<br /><br />import extensionobject.paso1.Rol;<br /><br />public interface Sujeto {<br /><br /> Rol getExtension(String nombreExt);<br /> void addExtension(String nombreExt, Rol extension);<br /> void removerExtension(String nombreExt);<br /><br />}

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

package extensionobject.paso2;<br /><br />import extensionobject.paso1.AccionSoldado;<br />import extensionobject.paso1.RolSoldado;<br />import extensionobject.paso1.RolFabricante;<br />import extensionobject.paso1.AccionFabricante;<br /><br />public class ManejarRobots {<br /><br /> public static void main(String args[]){<br /> MazingerZ robot = new MazingerZ();<br /> robot.addExtension("RolSoldado", <br /> new RolSoldado(robot));<br /> AccionSoldado robotSoldado = (AccionSoldado)<br /> robot.getExtension("RolSoldado");<br /> robotSoldado.atacar();<br /> robot.removerExtension("RolSoldado");<br /> robot.addExtension("RolFabricante", <br /> new RolFabricante(robot) );<br /> AccionFabricante robotFabricante = <br /> ( AccionFabricante ) robot.getExtension<br /> ("RolFabricante");<br /> robotFabricante.construir();<br /> }<br /><br />}

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

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;<br /><br />public class MazingerZ {<br /><br /> public MazingerZ(){<br /> System.out.println("Construyendo robot Mazinger Z");<br /> }<br /><br />}

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

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

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;<br /><br />public class ElVengador {<br /><br /> public ElVengador(){<br /> System.out.println("Construyendo robot El Vengador");<br /> }<br /><br />}

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

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

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

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 {<br /><br /> public ClonarRobot duplicar( );<br /><br />}


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;<br /><br />public interface ClonarRobot extends Cloneable {<br /><br /> ClonarRobot duplicar( );<br /><br />}

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

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

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

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

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)

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 :

package dukechile.jug.ioc.paso1;<br /><br />public class Servicio {<br /><br /> public String ejecutarServicio(){<br /> return "Simulacion de llamada a un servicio";<br /> }<br /><br />}

package dukechile.jug.ioc.paso1;<br /><br />public class Componente {<br /><br /> private Servicio servicio;<br /><br /> public Componente(){<br /> servicio = new Servicio();<br /> }<br /><br /> public void ejecutarServicio(){<br /> String mensaje = servicio.ejecutarServicio();<br /> System.out.println(mensaje);<br /> }<br /><br />}

package dukechile.jug.ioc.paso1;<br /><br />public class ClaseTest {<br /><br /> public static void main(String[] args) {<br /> Componente componente = new Componente();<br /> componente.ejecutarServicio();<br /> }<br /><br />}

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”:

package dukechile.jug.ioc.paso2;<br /><br />public class Servicio2 {<br /><br /> public String ejecutarServicio(){<br /> return "Simulacion de llamada a un servicio optimizada";<br /> }<br /><br />}

package dukechile.jug.ioc.paso2;<br /><br />public class Componente {<br /><br /> //private Servicio servicio;<br /> private Servicio2 servicio2;<br /><br /> public Componente(){<br /> //servicio = new Servicio();<br /> servicio2 = new Servicio2();<br /> }<br /><br /> public void ejecutarServicio(){<br /> //String mensaje = servicio.ejecutarServicio();<br /> String mensaje = servicio2.ejecutarServicio();<br /> System.out.println(mensaje);<br /> }<br /><br />}

package dukechile.jug.ioc.paso2;<br /><br />public class ClaseTest {<br /><br /> public static void main(String[] args) {<br /> Componente componente = new Componente();<br /> componente.ejecutarServicio();<br /> }<br /><br />}

…..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” :

package dukechile.jug.ioc.paso3;<br /><br />public class Componente {<br /><br /> private Servicio2 servicio2;<br /><br /> public Componente(){<br /> }<br /><br /> public void setServicio2(Servicio2 servicio2){<br /> this.servicio2 = servicio2;<br /> }<br /><br /> public void ejecutarServicio(){<br /> String mensaje = servicio2.ejecutarServicio();<br /> System.out.println(mensaje);<br /> }<br /><br />}

package dukechile.jug.ioc.paso3;<br /><br />public class Servicio2 {<br /><br /> public String ejecutarServicio(){<br /> return "Simulacion de llamada a un servicio optimizada";<br /> }<br /><br />}

package dukechile.jug.ioc.paso3;<br /><br />public class ClaseTest {<br /><br /> public static void main(String[] args) {<br /> Componente componente = new Componente();<br /> componente.setServicio2(new Servicio2());<br /> }<br /><br />}

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”).

package dukechile.jug.ioc.paso4;<br /><br />public class Componente {<br /><br /> private ServicioI servicio;<br /><br /> public Componente(){<br /> }<br /><br /> public void setServicio(ServicioI servicio){<br /> this.servicio = servicio;<br /> }<br /><br /> public void ejecutarServicio(){<br /> String mensaje = servicio.ejecutarServicio();<br /> System.out.println(mensaje);<br /> }<br /><br />}

package dukechile.jug.ioc.paso4;<br /><br />public interface ServicioI {<br /><br /> String ejecutarServicio();<br /><br />}

package dukechile.jug.ioc.paso4;<br /><br />public class Servicio implements ServicioI{<br /><br /> public String ejecutarServicio(){<br /> return "Simulacion de llamada a un servicio";<br /> }<br /><br />}

package dukechile.jug.ioc.paso4;<br /><br />public class Servicio2 implements ServicioI{<br /><br /> public String ejecutarServicio(){<br /> return "Simulacion de llamada a un servicio optimizada";<br /> }<br /><br />}

package dukechile.jug.ioc.paso4;<br /><br />public class ClaseTest {<br /><br /> public static void main(String[] args) {<br /> Componente componente = new Componente();<br /> componente.setServicio(new Servicio());<br /> componente.ejecutarServicio();<br /> componente.setServicio(new Servicio2());<br /> componente.ejecutarServicio();<br /> }<br /><br />}

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

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.