Posts Tagged ‘framework’

h1

Una adopción ágil: retos y soluciones

02/14/2014

Wizdoc [Icon By Buuf]  Tips & Tricks.

Primero, tienes que aprender las reglas del juego. Luego, tienes que jugar mejor que nadie.

Albert Einstein (1879 – 1955). Físico judeo-alemán, nacionalizado suizo y posteriormente, estadounidense.

Desde hace poco menos de un año hemos venido trabajando con varias células de desarrollo ágil para un cliente que en aquél entonces era relativamente inexperto en esta metodología. Algunas de estas células han sido todo un éxito, compuestas por gente altamente calificada que trabaja como uña y mugre con el Product Owner (PO) perteneciente al cliente, mientras lanzan funcionalidad a producción como si fueran una fábrica de juguetes china. Otras células menos afortunadas han tenido que afrontar duros retos, incluyendo gente sin la suficiente experiencia para implementar el stack tecnológico y grado de colaboración necesarios para lidiar con proyectos y clientes complicados.

Pues bien, a partir de enero de este año, el cliente nos solicitó integrar Extreme Programming (XP) como parte de la implementación ágil, sin dejar de lado Scrum como framework de gestión de proyectos. Esto requirió un poco de flexibilidad entre ambas partes para incluir una serie de nuevos controles, tales como:

• Programación por pares, donde el trabajo es desempeñado por dos desarrolladores en vez de hacerlo de forma individual.

• El refactoring y la integración continua han tomado un rol mucho más importante durante el ciclo de desarrollo.

• Ahora existe una “propiedad colectiva del código”, en la que cualquiera puede modificar el código de otro, siempre que éste cambio sea respaldado por las mandatorias pruebas unitarias así como una correcta integración continua, evitando los así denominados cowboy coders: programadores muy buenos, pero que siempre dejan detrás de ellos un revoltijo inmantenible de código.

• La planeación ahora debe tomar en cuenta spikes de XP, los que en realidad son experimentos, análisis técnicos o pruebas de concepto que incluyen una revisión formal por parte del cliente.

• Anteriormente, la definición de “terminado” significaba tener algo listo para la demo. Ahora, ésta ha cambiado a “cuando el cliente lo haya probado satisfactoriamente”. Esto significa que durante el Sprint, el cliente realiza pruebas sobre los entregables, previo a la sesión de demostración.

• El análisis y diseño arquitectónico deben hacer uso de “metáforas”, o historias muy sencillas que explican cómo funciona el sistema. Esto se debe a que para el análisis, debemos interactuar con “embajadores” que oficialmente fungen como enlace entre las áreas de negocio y TI. Por ello la necesidad de explicarles cómo funcionan las cosas en términos “que hasta un niño pueda entender”.

Estos puntos han derivado en que el equipo tenga que reforzar la disciplina, pues si no tenemos cuidado, podemos terminar con una dinámica de grupo totalmente anárquica, en la que cada quien hace lo que quiere. Esto es más aparente si tomamos en cuenta que ahora todos trabajan en pares y pueden “tocar” cualquier parte del código. Por otro lado, el beneficio principal y la razón por la que el cliente ha considerado hacer este cambio, es que ya somos lo suficientemente maduros como para evolucionar el proceso hasta la fase de innovación:

pic: Enterprise agility adoption roadmap

Roadmap de adopción ágil. Generalmente, todo inicia con una fase de experimentación a través de un proyecto piloto con sólo un equipo de trabajo (Pasos 1 y 2). Posteriormente, corremos una fase de lanzamiento, donde varios equipos ágiles trabajan en paralelo sobre un mismo programa (Pasos 3 y 4). Después, ejecutamos un rollout general, donde establecemos ágil a nivel portafolio (Paso 4). Finalmente, viene la fase de innovación (Paso 5), en la que se implementan prácticas como colaboración remota y configuración de un ALM comercial. (Fuente de la imagen: appslog.com)

Lo que debe quedar muy claro, es que antes de llegar a esta fase, debimos haber alcanzado el punto en el que el cliente confía en nosotros lo suficiente como para sólo indicarnos cuál es el valor de negocio de la funcionalidad a entregar, dejando a nuestro criterio todo lo demás. Es decir, el momento en el que se le ha cedido el control y mando al equipo.

Los principales retos durante la adopción

Tanto la adopción ágil en general, como la implementación de XP en particular, han implicado muchísimos retos que sobre todo, tienen que ver con el lado humano. Ciertamente, desde hacía tiempo ya habíamos cubierto el tema del ciclo de desarrollo o SDLC y la calidad de los entregables; por lo que ahora debíamos lidiar con temas como “… ¿por qué debo sentarme con este tío a programar?” El cambio de algunos paradigmas, incluso entre gente “ágil”, no es cosa sencilla. A continuación, enumero los mayores retos que llegamos a enfrentar y cómo los hemos mitigado:

• El primero, y más importante de todos: ágil no significa que terminaremos un proyecto en menos tiempo. Este es un concepto erróneo que muchos usan como argumento de venta. La realidad es que el mayor beneficio de ágil, desde el punto de vista de negocio, son las liberaciones tempranas: ¿Para qué esperar seis meses a tener todo terminado, si desde el primer mes ya existe un entregable “listo para liberar a producción” que puede indicarnos si el proyecto está destinado al éxito o al fracaso? Obviamente, tendremos que esperar otros cinco meses para tener todo al 100%, pero desde el primer mes tendremos algo tangible y generando un ingreso, o podemos darnos cuenta que el caso de negocio era erróneo, teniendo la posibilidad de “tirar del enchufe” cuando apenas se ha gastado una pequeña fracción del presupuesto.

• Interdependencias entre equipos y proyectos. Aunque Scrum hace énfasis en que no existan interdependencias entre equipos, la realidad es que esto es el pan nuestro de cada día. Por ejemplo, un equipo en Java desarrolla web services que serán consumidos por una aplicación en .net desarrollada por otro equipo. En este caso, podemos echar mano de un perfil que no viene descrito en el framework original, conocido como Technical Owner (TO), que está al mismo nivel del Scrum of Scrum Masters. El TO es el responsable de la arquitectura de un programa o portafolio, definiendo interfaces y dependencias. Así mismo, debe apoyar en la definición del plan de liberación o release plan, evitando al máximo que nos pisemos los callos unos con otros, trazando una ruta crítica que tomará precedencia sobre cualquier otro ítem de los product backlogs para cada equipo involucrado:

pic: Scrum in an interdependent environment

El equipo 1 (rojo) hace Sprints de dos semanas y liberaciones cada mes; el equipo 2 (azul) ejecuta Sprints de cuatro semanas y libera cada dos meses. Sabiendo que el equipo 2 debe implementar ciertos componentes para que el equipo 1 pueda integrarlos, el Technical Owner debe apoyar a los Product Owners de ambos equipos para definir la ruta crítica y acordar quién hará qué y cuándo debe tenerlo listo. (Fuente de la imagen: cardinalsolutions.com)

Así, el TO apoyará en la generación de las especificaciones necesarias para que los equipos utilicen “mock ups” mientras tienen lista su parte. Finalmente, los POs deben considerar un Sprint o parte de éste dedicado a la integración, pruebas y refactoring entre ambos equipos.

• Dificultades para asegurar la calidad y generar los entregables de acuerdo a CMMi-L3. Desde un principio contamos con un miembro del equipo que podía fungir como “especialista técnico” (su puesto oficial es Tech Lead o TL, pero NO es el líder del equipo; tampoco tiene el rol de Scrum Master). Dicha persona colabora de forma muy estrecha con el TO para implementar adecuadamente la arquitectura definida por aquél, así como reforzar una correcta ejecución de desarrollo guiado por pruebas (TDD) e integración continua. En resumen: un TL no puede confiar en un software que no tenga un set de pruebas cuantificables que puedan ejecutarse con sólo pulsar un botón. Por otro lado, contamos con un par de Business Analysts (BA) encargados de verificar una correcta transferencia de conocimiento entre el cliente y el resto del equipo. Ya que esta transferencia está muy relacionada a la documentación requerida por CMMi, ellos son también los encargados de apoyar en esta tarea, liberando a los desarrolladores de cargas innecesarias.

• Scrum distribuido. Esta modalidad del proceso es una historia aparte, pero baste decir que en un par de células, algunos miembros del equipo pertenecen a offshore. Es decir, por un lado tenemos al Scrum Master, el tech lead, un desarrollador y un analista de negocio trabajando hombro con hombro con el cliente, mientras el resto del equipo – el tester, tres desarrolladores y otro business analyst – colabora desde literalmente, el otro lado del mundo. Desde un punto de vista táctico, el principal reto es la comunicación, confianza y respeto mutuo, así como diferencias culturales. En cuanto a estrategia de negocios, este modelo rebaja muchísimo los costos, pero también refleja una pequeña pero perceptible disminución en la productividad – en nuestra experiencia, a menos que todo el equipo este co-locado o ya se hayan resuelto diferencias culturales, los tiempos de ejecución se incrementarán hasta en un 25% debido precisamente, al overhead de comunicación.

Conclusiones

Cualquier adopción ágil y su correspondiente implementación tendrán retos a enfrentar, principalmente en las áreas de interdependencia entre equipos, manejo de recursos remotos y alineación del cliente. Sin embargo, si obtenemos el patrocinio sincero de high management – o como en nuestro caso, es una directiva que viene del cuartel general y debe adoptarse por todas sus subsidiarias alrededor del mundo – nuestros problemas serán mucho menores, limitándose a temas de madurez y alineación de procesos.

¿Dónde nos encontramos parados después de todo este ejercicio? Bastante bien, ya que después de diez meses, hemos trabajado de forma casi ininterrumpida, e incluso tenemos la oportunidad de expandir nuestras operaciones a otras unidades de negocio. Si todo sale bien, en un par de meses estaremos haciendo un copy + paste del proceso de adopción e implementación, aunque en esta ocasión, tendremos que enfrentar un área en la que personalmente no me siento tan fuerte: e-commerce.

h1

Las herramientas y tecnologías más usadas en Java

11/29/2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

El aprendiz evita todo uso de clases en Java. El profesional, acepta las clases de Java. El maestro sabe qué clases aprovechar y cuáles evitar.

— Michael Fogus, programador y escritor Estadounidense. Autor del libro The Joy of Clojure.

Regularmente, un proyecto desarrollado en el lenguaje de programación Java incluye librerías de terceros. Esto ocurre porque en estricta teoría, los APIs del core del lenguaje poseen toda la funcionalidad que necesitamos, mientras que en realidad, generar este middleware por nuestra cuenta requiere demasiado esfuerzo, por lo que podemos minimizar esta tarea con la ayuda de librerías que nos permiten enfocarnos en lo que realmente importa: la lógica de negocio. Así, desde las tareas tan pedestres como los logs, hasta las más esotéricas como el procesamiento de lenguaje natural, tenemos a nuestra disposición un sinfín de herramientas y frameworks generados por otros desarrolladores que nos permitirán resolver el problema en cuestión sin necesidad de reinventar la rueda. Por otro lado, con el explosivo crecimiento de Java y las plataformas que la componen, incluyendo desktop, web y móvil, existen literalmente cientos de librerías para una misma función que pueden generarnos ansiedad por indecisión, porque debemos elegir entre frameworks “de moda” – los que pueden impresionar a los clientes, cerrando un trato – y aquellas herramientas que ya son consideradas maduras y por lo tanto, “aburridas”. Esto es razonable, ya que el éxito o fracaso de un proyecto desde el punto de vista técnico se debe en gran medida al uso de tecnologías inmaduras o aquellas que tienen una pronunciada curva de aprendizaje.

Así entonces, hace algún tiempo se publicaron dos análisis que describen las herramientas y frameworks más utilizados por la comunidad Java. El primero fue generado por el staff de Takipi, un startup que ha basado su estudio en las estadísticas que arrojaron más de 10,000 proyectos de Java hosteados en GitHub. El segundo fue desarrollado por ZeroTurnaround, otra compañía que realizó su análisis a través de encuestas publicadas en el reconocido sitio The Server Side. Los resultados se muestran a continuación:

Pic: Tools & Tech - 1 of 2
Pic: Tools & Tech - 2 of 2

Herramientas y tecnologías más comunes en la comunidad Java. En la gráfica se muestra el porcentaje de proyectos en los que los desarrolladores han utilizado una tecnología específica, de acuerdo a su categoría.

A partir de estos números, obtenemos algunos hallazgos interesantes:

• En este momento, la versión de Java más usada es la 6, publicada en Diciembre de 2006. Puesto que la versión 5 tiene poco más de 9 años de existencia (Septiembre 2004) y la versión 7 apenas tiene un par de años de haber sido liberada (Julio 2011), estos porcentajes proporcionan el tiempo aproximado para que una versión de Java se generalice: 3 años y 4 meses.

• Debido a su tremenda potencia, relativa facilidad de aprendizaje y extensa documentación, Eclipse, Maven, Ant, Jenkins/Hudson, Subversion, SLF4J, Spring, Hibernate y JUnit se han vuelto los estándares de facto en la industria, al grado en que no existen implementaciones de Java que no usen alguno de estos frameworks y herramientas.

• Adicionalmente, Spring MVC y Java Server Faces se han convertido en los frameworks de mayor uso para cualquier implementación web. Apache Struts sigue apareciendo entre los primeros lugares, aunque no está claro cuál de las dos versiones es la más popular. Lamentablemente, otros frameworks como Wicket o Tapestry – que personalmente me parecen mucho más accesibles que JSF o Struts – se han quedado rezagados.

• En cuanto a los servidores de aplicaciones, vale la pena mencionar cómo Tomcat está presente en casi cualquier despliegue web, mientras JBoss es el “servidor empresarial” con mayor uso por la comunidad. Por otro lado, vemos cómo los millones de dólares que respaldan a los servidores de aplicaciones comerciales no han servido de mucho para incrementar su participación. Sin embargo, esto es sólo relativo, ya que con frecuencia, Tomcat y Jetty son utilizados para ambientes de desarrollo, mientras el servidor en el que se deja la producción termina siendo un Websphere o un Weblogic.

• Finalmente, de acuerdo a las estadísticas, el desarrollo orientado a pruebas está cambiando la manera de hacer los proyectos, con casi uno de cada tres utilizando JUnit: Ahora, las pruebas unitarias ya son prácticamente un requerimiento que nosotros como desarrolladores debemos conocer y saber cómo llevar a cabo.

Conclusiones

Los resultados pueden no ser sorprendentes, pero son un buen punto de referencia para saber hacia dónde se está dirigiendo Java, mientras que para los desarrolladores novatos éstos pueden servir como guía para conocer qué frameworks y herramientas deben dominar si quieren ser competitivos en el ambiente laboral presente. Adicionalmente, podemos darnos cuenta que con muy marcadas excepciones, el desarrollo en Java depende casi exclusivamente de iniciativas open source, lo que ciertamente democratiza esta disciplina, evitando que un sólo jugador sea el que defina el futuro de la especialidad, tal como aquella otra tecnología que opera bajo el (poco ético) lema de “adoptar, extender y extinguir“.

h1

Wicket vs. Tapestry.

07/21/2008

Wizdoc [Icon By Buuf]  Tips & Tricks.
Hace algún tiempo encontré este post, donde a través del Google Trends han estado midiendo la "popularidad" de varios frameworks de desarrollo web – entre ellos Java Server Faces, Struts 2 y Adobe Flex – llegando a la conclusión de que ASP.NET y Flex son la solución más socorrida mientras que frameworks tan buenos como Tapestry o Stripes son relegados a la nada.

Pero no nos engañemos, eso sólo son chaquetas mentales: como bien aciertan en este otro blog, las estadísticas proporcionadas por Google Trends pueden ser muy engañosas: cuando se comparan dos términos de búsqueda no obtenemos la verdadera razón tras éstas, y lo mismo muchos de los hits pueden deberse a su popularidad que a múltiples búsquedas porque los desarrolladores no encuentran cómo resolver un problema en el framework.

De hecho, le creería un poco más a una estadística parecida al TIOBE Programming Community Index. Aunque en dicho índice se calcula la popularidad de los lenguajes de programación de manera más general, sirve como referencia para ver el verdadero porcentaje de uso de los frameworks de presentación (dar click en imagen para ver la gráfica actualizada en tamaño original).

Por otro lado, y a sabiendas que le tengo aversión a Struts y por el momento no he revisado la funcionalidad de Struts 2, busqué comparativos y he estado realizando algunas pruebillas de concepto entre Apache Tapestry y Apache Wicket. Las diferencias – y sobre todo, las similitudes – son sorprendentes:

• En cuanto a la administración de requerimientos, Tapestry es prácticamente el trabajo de Howard Lewis Ship y a final de cuentas, es quien decide qué incluir y qué no dentro del core del framework. Por otro lado, Wicket es producto de una comunidad de desarrolladores, quienes debaten y acuerdan este tipo de funcionalidad en foros de discusión.

• Tapestry ha sido optimizado para tener un buen desempeño a costa de la curva de aprendizaje; Wicket es la otra cara de la moneda y ha sido pensado con la facilidad de implementación en mente.

• Tapestry es equivalente a un Ferrari: siempre con la última tecnología, se busca que el framework atraiga usuarios por la calidad y potencia de desempeño; Wicket es más bien un utilitario: con sólo lo suficiente de acuerdo a la retroalimentación del usuario para que haga la chamba.

Habiendo estudiado la teoría y ejecutado los ejercicios descritos en los libros Enjoying Web Development with Tapestry, Enjoying Web Development with Wicket y el excelente artículo de IBM titulado Tapestry and Wicket compared, resulta que Wicket es un mini-me con esteroides de Tapestry; de hecho, podríamos switchear entre estos dos frameworks de acuerdo a nuestras propias necesidades o idiosincrasia de desarrollo:

• Ambos frameworks son basados en componentes, utilizando etiquetas especiales embebidas en el HTML que parsea el core engine para ligar HTML con Java (por ejemplo, usando <span wicket:id="receivedItemsPages"> en Wicket o <span jwcid="table"> para Tapestry).

• La mayor diferencia existente entre Tapestry y Wicket es el uso de páginas escritas en XML para definir los componentes: en Tapestry siempre se requieren 3 archivos para definir una página web: los html, los java y los .page que ligan aquellos dos. Con Wicket prácticamente sólo usamos un java y un html. Sin embargo, cabe mencionar que si se conocen bien los inner workings de Tapestry, el XML contenido en los archivos page es básicamente de copy + paste:

Login.html


<form jwcid="@Form" listener="ognl: listeners.formSubmit" method="POST" onSubmit="javascript:return checkForm();">
 …
 Usuario: <input type="text" style="loginfield" jwcid="usrLog@TextField" value="ognl: usrLog"/>
 …
 Password: <input type="password" style="loginfield" jwcid="usrPwd@TextField" hidden="ognl: true" value="ognl: usrPwd"/>
 …
</form>

Login.page

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE page-specification PUBLIC "-//Howard Lewis Ship//Tapestry Specification 1.3//EN" "http://tapestry.sf.net/dtd/Tapestry_1_3.dtd"&gt;

<page-specification class="my.java.package.Login">
 <context-asset name="stylesheet" path="/css/login.css"/>
</page-specification>

Login.java

package my.java.package;

public class Login extends BasePage {
  …
  /** El username introducido en la forma (usa getters y setters)*/
  private String usrLog;

  /** El password introducido en la forma (usa getters y setters)*/
  private String usrPwd;
  …
  public void formSubmit(IRequestCycle cycle) {
    try {
      SecurityDAOJDBC dao = new SecurityDAOJDBC();
      …
      UserVO user = dao.getUser(getUsrLog(), EncryptionHelper.md5(getUsrPwd()));
      …
    } catch (MyException e) { … }
    …
  }
  …
}

Los tres componentes básicos de una página web en Tapestry (versión 1.3)

En conclusión, si ya estamos hasta el queque de depurar Struts y su programación basada en eventos, podemos tratar con alguno de estos frameworks: en caso de requerir un "deportivo" de alto desempeño y por la misma razón tenemos acceso a un buen "mecánico" que le sepa meter mano al motor, Tapestry es nuestro gallo; si queremos "sacar a pasear a la familia" sin meternos en problemas podemos lanzarnos al ruedo con Wicket.

Finalmente, retomando el tema de las estadísticas "hechizas" que muestra Google Trends, ya que Tapestry tiene en general más tiempo en el mercado y posee muchas características semejantes a Wicket, me extraña que de acuerdo a esas estadísticas Tapestry ni siquiera aparece en la gráfica y Wicket sea de los frameworks más populares… ¿no habrá aquí algo de mano negra?

h1

Permisos y Politicas de Seguridad con Java Frameworks: el caso de Glassfish

06/25/2008

Wizdoc [Icon By Buuf]

 Tips & Tricks

Como parte de las mejores prácticas del deployment de aplicaciones JEE, siempre es recomendable incluir en los WARs o EARs de nuestra distribución sólo el código que nosotros estamos implementando. Es decir, los frameworks y librerías de terceros que utiliza la aplicación deben estar fuera del directorio WEB-INF/lib, dejando en éste sólo los JARs que contengan nuestros componentes. Se ofrece un ejemplo utilizando esta distribución:

${j2ee-modules}
+—(Otras instalaciones)
.
.
+—MiAplicacion (directorio explotado / .WAR)
    |  web.xml
    |  struts-config.xml
    |
    +—web
    |      index.jsp
    |      error.jsp
    |
    —WEB-INF
        +—lib
        |      miscomponentes1.jar
        |      miscomponentes2.jar
        |
        —classes
               servlet1.class

En este post veremos cómo podemos extraer esos JARs de nuestras distribuciones para realizar un despliegue más limpio de la aplicación mientras al mismo tiempo mejoramos la seguridad sobre el código que estamos ejecutando; como ejemplo de configuración del servidor de aplicaciones utilizaremos el Sun Glassfish Enterprise Server (antes llamado Sun Java System Application Server), aunque este tipo de solución no se limita a éste.

Glassfish: aspectos de seguridad

Por defecto, la seguridad del Glassfish se encuentra activa. Es decir, a diferencia de otros servidores de aplicaciones como Weblogic, la creación y configuración de un dominio out-of-the-box contiene habilitadas todas las restricciones de seguridad, permitiendo sólo tareas como manipulación de sockets y archivos y generando errores de seguridad del género XPermissionException durante el despliegue o ejecución de "código no permitido". Aqui se muestran los permisos manejados por Java y aqui cómo deben manejarse estos privilegios en el código aplicativo.

Por otro lado, la mayoría de los frameworks actualmente disponibles – ya sea de web services como Axis2, persistencia como Hibernate o web como Java Server Faces – requieren ciertos permisos, de los cuales probablemente los más requeridos sean la creación y recuperación del Java ClassLoader y generar instancias de objetos a través de Reflexión.

Existen dos maneras de facilitar la ejecución de código que requiera permisos especiales de seguridad. La primera es fácil de implementar, aunque no es segura pues implica deshabilitar la seguridad de ejecución de código y la otra es un poco más complicada pero acota los permisos sólo al código o librerías que los requieren.

Deshabilitando la seguridad: la manera fácil

Para deshabilitar la seguridad durante la ejecución de código basta con ingresar a la consola de administración del Glassfish y editar las opciones de tiempo de ejecución de la Máquina Virtual de Java [Arbol de tareas >> Configuraciones >> <server-config> >> Configuración JVM >> Pestaña Opciones JVM]. En la pantalla mostrada eliminamos la opción -Djava.security.policy que indica la localización del archivo donde se encuentran configuradas las políticas de seguridad, como se muestra a continuación:


Eliminación de la variable -Djava.security.policy en la consola de administración del Glassfish. Nota: la pantalla muestra la solución para la Glassfish 8.2, pero también aplica para las siguientes, incluyendo la 9.1 U2.

La alternativa no gráfica a la solución consiste en eliminar o comentar la línea correspondiente en el archivo de configuración del dominio, encontrado en el archivo domain.xml y localizado en el directorio ${dir_install}/domains/<domain>/config/

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE domain … >

<domain … >
 <applications>…</applications>
 <resources>…</resources>
 <configs>
  <config dynamic-reconfiguration-enabled="true" name="server-config">
   <http-service>…</http-service>
   <java-config classpath-suffix="…">
    <!– various required jvm-options –>
    <jvm-options>…</jvm-options>
    <jvm-options>
     -Djava.security.policy=
${com.sun.aas.instanceRoot}/config/server.policy

    </jvm-options>
   </java-config>
    …
  </config>
 </configs>
</domain>

Sin embargo es conveniente observar que esta solución sólo es recomendable para ambientes de desarrollo, pues efectivamente estamos deshabilitando la seguridad de la JVM sobre la carga y ejecución de nuestras clases. Si en la aplicación existe código malicioso, podemos encontrarnos con una falla de seguridad potencialmente peligrosa.

Deshabilitando la seguridad: la forma talachuda pero correcta

Con esta opción, podremos designar en el archivo de políticas de seguridad sólo los permisos que nuestro código requiere. Dichas políticas se encuentran en el bloque grant del archivo server.policy localizado en el directorio de configuración del dominio ${dir_install} /domains/<domain>/config/

// Basic set of required permissions granted to all remaining code
grant {
  permission java.net.SocketPermission  "*", "connect";
  permission java.io.FilePermission   "<<ALL FILES>>", "read,write";
  permission java.util.PropertyPermission "*", "read";
};

Por otro lado, debemos depositar los JARs correspondientes a los frameworks y librerías externas en un directorio por separado. Por ejemplo, el directorio lib del dominio (${dir_install}/domains/domain1/lib/) es una buena opción si estamos compartiendo frameworks entre varios contextos aplicativos del dominio. Más tarde deberemos configurar el archivo de políticas de seguridad, agregando un bloque de permisos como se muestra a continuación:

grant codeBase "file:/opt/glass91/domains/domain1/lib/-" {
  permission java.lang.RuntimePermission "createClassLoader";
  permission java.lang.RuntimePermission "getClassLoader";
};

Nótese que estamos permitiendo la carga o creación de un ClassLoader a todas las librerías y código encontrados en /opt/glass91/domains/domain1/lib/. La asignación de permisos puede ser tan general o tan puntual como sea requerido, dependiendo de la criticidad del permiso (aqui se describe en detalle el formato de los bloques grant en un archivo de políticas de seguridad).

Finalmente, puede presentarse un problema de errores ClassNotFoundException lanzados durante la carga o ejecución de la aplicación. Esto se debe a que Glassfish no carga las librerías o código de ningún otro lugar que no sea el WEB-INF/lib de la aplicación o el directorio de librerías del servidor (${dir_install}/lib). Como solución a este detalle debemos incluir en el classpath del servidor las librerías correspondientes. Esto se logra en la consola de administración mediante la ruta [Arbol de tareas >> Configuraciones >> <server-config> >> Configuración JVM >> Pestaña "configuración de ruta" o classpath]. Alternativamente podemos editar el archivo domain.xml e incluir las librerías de forma manual en la propiedad classpath-suffix de la etiqueta java-config.

Conclusión

La reusabilidad no se limita sólo a nuestros componentes sino también a las librerías y frameworks que usamos entre diferentes aplicaciones y contextos. Por ello, con esta sencilla solución tendremos WARs y EARs con mayor limpieza y consistencia de código, aplicando security checks sólo a los componentes que lo necesitan y obteniendo deployments más ligeros que se desplegarán con mayor velocidad.

h1

JSF with JSP 2.1 on Sun App Server 9.1

06/24/2008

Wizdoc [Icon By Buuf]

 Tips & Tricks

SP

Versión en Español

Otra vez la burra al trigo[1]. Now, a user needs to publish a web service implemented in XFire and two Web applications that include Java Server Faces, Spring and Hibernate on an application server; As we were originally asked for Weblogic licenses, we said to ourselves "ummm… we should include a Sun Application Server quotation instead, to see if they like it". Of course, considering they needed 10 licenses, the amount saved by our customers is pretty step (more than US$100,000 in savings) and we were asked for a small proof of concept (POC) that included load testing to see if the App Server was well suited to their needs.

As I had to do some juggling bringing together people from development, application support and infrastructure, I could not perform the tests as I wanted and I opted instead for the installation of two working instances of the last versions of the Application Server (8.2 and 9.1), in such way that they will eventually perform their own tests. I hope that by speaking with the department manager it is easier to close the deal, and I no longer have to be dealing with these boys. This is because every minute they keep annoying me with comments like "hey, I can do this with Weblogic, you can’t do it with your application server, do you?" and obviously I have to show them you can – as a reference, the Sun Application Server 9.1 is the equivalent in almost all functionality aspects to the Weblogic 9 – but the explanations consume a lot of my time and we can’t move forward with the installation and testing.

The technicalities

When deploying the web application on the Sun Application Server 9.1 it throws the following error:

[#| 2008-03-11T19:11:19.343+0000 | SEVERE | sun-appserver9.1 | javax.enterprise.system.container.web | _ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-0;_RequestID=5b0615d8-92de-49d1-b74a-c07777fc1175; | StandardWrapperValve[jsp]: PWC1406: Servlet.service() para el servlet jsp desencadenó una excepción

org.apache.jasper.JasperException: /WEB-INF/tags/ext/body.tag(104,4) PWC6038: "${empty(extLocation)?"js/ext-2.0":extLocation}" contiene expresiones no válidas: javax.el.ELException: Error Parsing: ${empty(extLocation)?"js/ext-2.0":extLocation}

at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:62)
at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:357)
at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:169)

Where the code snippet that is the root of the problem is as follows:


 98 <%@ include file="inc/taglibs.jsp" %>
 99 <%@ tag import="org.apache.commons.beanutils.BeanUtils, java.util.Scanner"
100   dynamic-attributes="dynamicAttributes"
101   description="" %>
102
103 <c:set var="extLocation">
104   ${empty(extLocation)?"js/ext-2.0":extLocation}
105 </c:set>
106
107 <link rel="stylesheet" type="text/css" href="${extLocation} /resources/css/ext-all.css" />

And although at first glance there is nothing wrong with it and in some forums it is recommended to configure the web.xml to prevent expression parsing among the jsp tags, the real source of the problem has to do with the JSP specification, which is the version 2.1 for the Sun Application Server 9.1; the libraries that throw this kind of errors are written with the JSP 2.0 Specification.

The solution

The amazing news is, the new JSP Specification for JEE 5 requires spaces for the ternary operator (<expression> ? <if true> : <if false>). Therefore, if we change the previous code snippet with the following:


 98 <%@ include file="inc/taglibs.jsp" %>
 99 <%@ tag import="org.apache.commons.beanutils.BeanUtils, java.util.Scanner"
100   dynamic-attributes="dynamicAttributes"
101   description="" %>
102
103 <c:set var="extLocation">
104   ${empty(extLocation) ? "js/ext-2.0" : extLocation}
105 </c:set>
106
107 <link rel="stylesheet" type="text/css" href="${extLocation} /resources/css/ext-all.css" />

The application should work correctly. Note: You may need to do the same "space adding" scheme in more than one configuration file in order to prevent any error of this kind from happening again.

Conclusions

Although I do not know the JEE 5 Specification cin all its extent, it is unusual that it has problems with the OGNL libraries such as this, which are practically the base of any web framework like Struts or Tapestry. In the meantime, I am waiting for these "kids" to end up their load tests successfully so I can go with the Head Honcho to tell him "Did you see? Everything works just as fine; please sign this cheque here."

h1

Frameworks de desarrollo de web services: ¿Cuál es el mejor?

01/08/2008

Wizdoc [Icon By Buuf]  Tips & Tricks.
Con cierta regularidad, ya sea para la integración de plataformas mediante web services o para los pininos de una arquitectura orientada a servicios, es necesario seleccionar puntualmente una tecnología mediante la cual implementaremos la publicación o consumo de dichos servicios que componen nuestra solución.

En la actualidad existen cuatro excelentes frameworks – tres de los cuales son opensource – mediante los cuales pueden generarse los servicios y clientes correspondientes de la solución; sin embargo todos tienen sus ventajas y desventajas dependiendo del contexto bajo el que realizaremos nuestros web services. A continuación, una descripción breve de dichos frameworks con sus pros y contras:

Framework Descripción
BEA Workshop Más IDE que framework debido a su capacidad de generar desarrollos completos que incluyen EJBs o páginas web, el Workshop permite la implementación de web services de forma más o menos sencilla, utilizando una interfaz gráfica en conjunto con tablas de propiedades.


Vista típica en el Workshop al generar un web service.

Como es costumbre con el software de BEA, aunque el producto en sí es excelente y cuenta con mucha flexibilidad, el precio es estratosférico al grado que muchas empresas medianas no tienen los recursos para utilizarlo. Peor aún si se considera que los servicios que genera están casados con el Weblogic y no es posible migrarlos a otro servidor más que a pata.

Apache Axis Siendo un framework maduro patrocinado por Apache, Axis permite implementar de forma bastante sencilla los web services. Dicho framework tiene una gran ventaja sobre los demás: para los web services RPC-Style[1] no hay ninguno que se le compare: es la mejor implementación en existencia. Por otro lado, su mayor defecto es la limitada capacidad de soporte para web services DOC-style[1]; los plugins de Axis para Eclipse son chafitas y de acuerdo al tipo de codificación del mensaje[2] la integración entre estos servicios y plataformas como Weblogic pueden generar dolores de cabeza.
Apache Axis 2 Esta es la otra cara de la moneda: Axis 2 es la mejor implementación de servicios DOC-style, al grado que por sus características técnicas es el único framework comparable a la implementación de referencia de Sun (Glassfish Metro). El principal detalle con el que me he encontrado en este framewrok es la parte del databinding[3], que puede convertirse en un desmother de administración de la configuración:


99 clases (paquete org.xmlsoap.schemas.soap.encoding) para sólo un web service
[Click aquí para ver tamaño original]
Glassfish Metro Siendo no oficialmente la implementación de referencia – pues existe mucha retroalimentación con equipos de desarrollo de Sun – Metro podría ser el mejor framework opensource de web services existente salvo por un pequeño detalle: sólo opera bajo el JEE 5, lo que nos limita a unos cuantos contenedores[4] y es algo que muchos clientes no pueden o no están dispuestos a adquirir; Máxime que aquí en México la mayoría tiene Weblogic 8.x o JBoss (certificados para JEE 4).

Como hemos visto – a grandes rasgos – dependiendo de que tipo de web services vamos a implementar y cómo se da el contexto de nuestro proyecto, podremos decidir qué framework se adapta mejor a nuestras necesidades:

  • Cuando no hay limitaciones en cuanto al costo de las licencias (sobre todo para SOAs de gran envergadura o empresas que tienen la capacidad económica), Workshop nos puede dar todo lo que necesitamos.
  • Cuando requerimos web services síncronos, estemos integrando plataformas homogéneas (es decir, JEE con JEE) o que por razones de desempeño requieran de estilo RPC, Axis es nuestro gallo.
  • Si es necesario generar web services con entrega garantizada de mensajes – o en pocas palabras, con un modelo asíncrono -, estemos integrando plataformas heterogéneas (por ejemplo JEE con .NET) o de plano nuestro usuario requiere una implementación de estilo documental, podemos ofrecer las bondades de Axis 2.
  • Finalmente, si nuestro cliente requiere una combinación de las anteriores y está dispuesto a lanzarse a adquirir lo último en tecnología, podremos proponerle Metro como una solución a sus problemas de integración.
Notas y pies de página

  1. Los web services de tipo RPC (también conocidos como JAX-RPC) indican que el framework convierte los mensajes SOAP a objetos de Java – es decir, del lado del servicio nunca vemos un XML de por medio. Para los web services de tipo documental (o que implementan JAXM), el mensaje llega directo a la aplicación como un XML, siendo deber de ésta manipular el mensaje de acuerdo a las necesidades de la lógica de negocio.
  2. Los mensajes SOAP enviados por un web service tienen dos tipos de estructura: codificados y literales. Los codificados están construidos de acuerdo a un modelo de datos definido por SOAP; los literales se construyen de acuerdo a un schema (el famoso archivito con terminación .xsd). El problema con ambas estructuras es que en el caso de los mensajes codificados, no existe una definición final de dicha codificación, por lo que puede haber diferencias de implementación – de hecho .NET o Axis 2 no los soportan – y en el caso de los mensajes literales se incrementa la complejidad de las aplicaciones que conforman el web service debido a la manipulación de los XMLs o la integración de frameworks de terceros para poder utilizar la información contenida en éstos.
  3. Por experiencia, el databinding es en realidad una conversión Java-Documento XML que realizamos en las implementaciones de web services. Un ejemplo es el framework XMLBeans, implementado por Apache.
  4. Hasta este momento (08/01/2007) sólo existen 6 servidores certificados con JEE5:
    • Sun Java System Application Server 9.x (también conocido como Glassfish)
    • BEA Weblogic 10.x
    • SAP NetWeaver Application Server, Java EE 5 Edition
    • TmaxSoft JEUS 6
    • Apache Geronimo 2.0
    • IBM WebSphere Application Server Community Edition 2.0

h1

5 Herramientas Opensource y 10 Frameworks de desarrollo que todo delivery engineer debería conocer (Parte II)

08/02/2007

Wizdoc [Icon By Buuf]  Tips & Tricks.
Continuando con el tema iniciado la semana pasada, donde describí 5 herramientas opensource indispensables para cualquier developer, hoy concluyo con los 10 frameworks que, aventurándose a un proyecto sin ellos, tenemos la mejor receta para el desastre: recuerdo un proyecto en una anterior vida donde se requería la generación y/o parseo de archivos XML de varios Megabytes de longitud. El arquitecto decidió que …los frameworks no tienen utilidad y es mejor hacerlo a mano… y así fue, hasta que todo reventó espectacularmente.

Dejando los rodeos, éstos son los frameworks que no sólo pueden salvar un proyecto, sino también un trabajo (o dos o más, si el equipo esta muy comprometido con el proyecto):

Framework: Echo2
Tipo: AJAX (Asynchronous JavaScript and XML)
Desarrollado originalmente por NextApp y liberado posteriormente como opensource bajo las licencias Mozilla Public License o GNU LGPL, es EL framework por excelencia en cuanto a AJAX se refiere: cuando se necesite una aplicación web con cliente rico (parecido al meebo), este framework es como implementar una aplicación AWT/Swing pero sin la necesidad de conocer HTML o Javascript.


Demo de Echo2

Ya en una ocasión anterior resumí una comparación originalmente realizada en The Server Side entre este framework y el Google Web Toolkit proporcionando los pros y contras de ambas tecnologías; por supuesto ambos destronan al infame JackBe.

Framework: Hibernate
Tipo: ORM (Object Relational Mapping)
Desde el principio: ORM se refiere a aquellas tecnologías dedicadas a la integración y comunicación de sistemas de datos relacionales (es decir, cualquier base de datos existente como Oracle) con lenguajes orientados a objetos (por ejemplo, Java).

La principal característica de Hibernate es que permite realizar el mapeo casi transparente entre clases de Java y tablas en la base de datos; los queries son generados por el framework liberando al programador de las tareas de generación de conexión, conversiones a partir del ResultSet y demás labor de bajo nivel. Por esta simple funcionalidad, Hibernate en conjunto con Spring, provocará la desaparición de los EJBs – especialmente los Entity Beans. Al grado que prácticamente la especificación EJB 3.0 fue diseñada tomando a Hibernate y Spring como modelos a seguir por Sun para evitar la desaparición de su propia tecnología.

Framework: Jasper Reports (+ Herramienta iReport)
Tipo: Reporteo
Concebido desde el principio como un proyecto opensource, Jasper Reports es el framework de su tipo más utilizado en la industria, permitiendo la generación de reportes con los formatos "más buscados" (desde PDF o HTML hasta XML). Adicionalmente tiene algunos "extras" que facilitan la labor del programador o mejoran los resultados del producto terminado: añadir gráficas (en conjunto con el framework JFreeChart, descrito más abajo), funciones tales como cálculo de consolidados, números de página, promedios, mínimo, máximo, etcétera.


El "primer reporte" en Jasper

Por otro lado, la herramienta de diseño iReport tiene una curva de aprendizaje muy baja, y en conjunto estas dos tecnologías ayudan a generar reportes en un dos por tres.

Framework: JCSP (Java Communicating Sequential Processes)
Tipo: Multithreading
Desarrollado inicialmente como un proyecto académico por parte de Peter Welch, de la Universidad de Kent (Canterbury, Reino Unido), este framework está basado en la investigación relacionada a los Procesos de Comunicación Secuencial, que básicamente son una rama de la teoría de la computación relacionada a la descripción de patrones de interacción en sistemas concurrentes. En pocas palabras, tanto la teoría como la implementación realizada por el framework abstraen la capa de multithreading (Threads/Runnable) y evitan que el programador "meta las cuatro" al construir un sistema con este tipo de requerimientos.
Framework: JFreeChart
Tipo: Graficación (Histogramas, gráficas de pie, líneas, dispersión)
De acuerdo a la información desplegada en el home del proyecto:

El proyecto JFreeChart fue fundado hace siete años, en febrero del 2000, por David Gilbert. En la actualidad, JFreeChart es usado por aproximadamente 40-50 mil desarrolladores (ver aquí una lista de los proyectos que utilizan JFreeChart). El proyecto continúa siendo administrado por Gilbert, con las contribuciones de una diversa comunidad de desarrolladores.

El financiamiento del proyecto es proporcionado por Object Refinery Limited, la compañía de David Gilbert basada en el Reino Unido. Object Refinery vende la documentación y servicios de consultoría relacionados a JFreeChart.


Uno de los muchos tipos de gráficas obtenidos mediante JFreeChart

Así entonces, JFreeChart utiliza el mismo modelo comercial de JBoss o Sun Microsystems: como desarrollador puedes descargar el software y utilizarlo de forma libre, pero si requieres documentación o soporte, ahí te la dejamos ir.

Framework: Log4J
Tipo: Bitácoras/depuración
Parece difícil que a estas alturas todavía existan proyectos donde se siga utilizando System.out.println() para depurar programas; especialmente aquellos donde el desempeño de la aplicación está en juego. Sin embargo, he visto aplicaciones donde el nivel de transaccionalidad es altísimo (300 o más transacciones compuestas por segundo) y aún así para cada paso de la transacción lo utilizan. La respuesta es Log4J, que adicionalmente a ser un proceso ligero (es decir, el memory footprint y el overhead resultantes de integrarlo a nuestra aplicación son muy bajos), permite varios niveles de depuración (o lo que es lo mismo: sólo "imprime" los mensajes del tipo asignado, desde el aburrido DEBUG hasta el temido FATAL) es muy sencillo de instalar e integrar a cualquier componente, desde stand-alones hasta JSPs, servlets o EJBs. De hecho, cualquier framework que se respete contiene por ahí su archivo de configuración del log4j para que podamos depurarlo.
Framework: OSCache
Tipo: Sistema de Cacheo (Caching System)
Cuando se requiere algo más que sólo un Hashtable para implementar nuestro cache (por ejemplo, caches que automáticamente se actualicen cada cierto tiempo, o que requieran ser persistidos en disco) podemos utilizar la implementación ofrecida por OpenSymphony: adicionalmente a las características antes mencionadas, incluye otros features que agregan robustez y escalabilidad al framework, como tags de JSP para el manejo dinámico del cache o plugins de persistencia con JDBC y OLAP. Finalmente, lo que me pareció realmente interesante del proyecto es que puede integrarse a Hibernate, proporcionando funcionalidad de cache sobre la base de datos (de primera instancia, cargar en el cache los catálogos de la aplicación me parece un buen inicio).
Framework: Quartz
Tipo: Calendarización de eventos
Implementado también por OpenSymphony, Quartz es un framework que nos permite calendarizar eventos, extendiendo la funcionalidad básica de las clases de Java java.util.Timer y java.util.TimerTask para incluir novedades tales como manejo del estado resultante del evento (éxito/fracaso), JobListeners y TriggerListeners que escuchan cuándo sucede la ejecución de un evento, implementación de transaccionalidad (JTA), entre otras. Adicionalmente, al igual que OSCache, este framework ha sido diseñado tomando en cuenta su integración a Hibernate y Spring.

Nota: El único detalle que le he encontrado es que para ciertos servidores de aplicaciones (específicamente el Sybase EAServer) puede generar errores fatales que tiran el servidor debido a la manera en que maneja los hilos de ejecución.

Framework: Spring
Tipo: Middleware / Reemplazo de la especificación EJB
Altamente basado en las técnicas de Inversión de Control (Inversion of Control – IoC) y Programación Orientada a Aspectos (Aspect-Oriented Programming – AOP), Spring es un framework que ha revolucionado la manera en que se desarrollan sistemas de alta escalabilidad y robustez. Genuinamente llevando a cabo las promesas incumplidas por los EJBs, Spring permite desarrollos más orientados al negocio (en vez de ser orientados a la tecnología implementada). Adicionalmente, es un framework muy completo que puede funcionar como middleware por las siguientes características y/o módulos que lo componen:

  • Es un lightweight container (En términos simples, mantiene y gestiona pools de Java Beans).
  • Mediante la AOP que lo integra, logra implementar una capa de abstracción para la gestión de la transaccionalidad.
  • También posee una capa de abstracción para las implementaciones de JDBC.
  • Es integrable con un sinnúmero de frameworks (Quartz, Hibernate, Tapestry, entre otros).
  • Posee su propio submódulo MVC que opera bastante bien al integrarlo con web frameworks como Struts o Tapestry.

Aunque la curva de aprendizaje de Spring es algo elevada, es bastante menor que la de los EJBs y como mencioné anteriormente, ha incluso afectado el cómo se definió la propia especificación EJB 3.0 y probablemente, tarde o temprano la reemplace o elimine por completo.

Framework: Tapestry
Tipo: Presentación (Web)
Mi favorito en cuanto a MVCs, aunque poco utilizado en la industria (espero que con la llegada de los JSF esto cambie), Tapestry es un framework que por su excelente documentación, facilidad de aprendizaje, mantenibilidad y relativa escalabilidad, cada que implemento un proyecto web y puedo seleccionar las tecnologías de implementación, me voy por éste.


El Tapestry Component Workbench

Nota: Por ahí llegué a escuchar que no funciona del todo montado sobre el Websphere, pero ya lo he visto correr sin problemas sobre Sun Application Server, Weblogic y hasta Sybase EAServer.

Conclusiones

Ahhh listo; por supuesto que hay muchos otros frameworks que son igualmente útiles para nuestros proyectos de JEE delivery (como Apache Axis), pero estos son los más significativos en cuanto a capacidad y uso. Tomando prestada la leyenda en la entrada del Infierno de La Divina Comedia (con un poco de mi cosecha, claro está): "¡Oh vosotros los que entráis a este proyecto sin sus frameworks al hombro abandonad toda esperanza!"