Aplicaciones Web con Cocoon y PL/SQL Centro de Tecnologías de la Información Universidad de las Islas Baleares Josep A. Frau Domingo Sebastián Resumen En esta ponencia se describen los elementos fundamentales de Cocoon, así como las extensiones realizadas en el CTI@UIB para convertirlo en la base de un entorno productivo e integrado con los recursos ofrecidos por Oracle. Aplicaciones Web con Cocoon y PL/SQL CTI@UIB Aplicaciones Web con Cocoon y PL/SQL Parte I – Cocoon La primera parte del documento muestra qué es Cocoon y porque fue la herramienta elegida para construir las aplicaciones Web sobre Oracle. Origen Las necesidades que llevaron a escoger la arquitectura presentada se derivan de la evolución histórica de las aplicaciones desarrolladas en el CTI. Tradicionalmente, todos los aplicativos de gestión interna se desarrollaban utilizando Forms Server de Oracle. Con la llegada de Internet, nuevos requerimientos exigieron hacer accesibles aplicaciones existentes a usuarios que llegaban a través de la Web. Las nuevas aplicaciones compartían parte del código base con las ya existentes y además, la mayor parte del personal del CTI acumulaba un conocimiento y experiencia en el desarrollo con herramientas de Oracle del que no se quería prescindir. Durante los años anteriores el CTI había desarrollado una metodología propia que permitía el desarrollo directo con la herramienta de análisis de Oracle (Oracle Designer). El trabajo previo de adaptación de las preferencias para la generación a partir del análisis fue un éxito. El tiempo invertido fue sobradamente recuperado cuando, posteriormente, se dispuso de la posibilidad de construir las aplicaciones directamente desde las herramientas de análisis y diseño con una productividad muy elevada. En este contexto, no resultaba atractiva la idea de saltar a un entorno Web con herramientas y lenguajes completamente nuevos. Se imponía más bien una adaptación a un entorno bien establecido que permitiese continuar con la solución que tan buenos resultados estaba dando. Requerimientos Por ello, el CTI elaboro una lista de requerimientos que reflejasen correctamente sus necesidades. Se tomo muy en consideración la situación actual, sin dejarse llevar por modas que, aún siendo validas para otras organizaciones, no eran justificadas para el caso actual. El resultado final del estudio de requerimientos podía resumirse en la siguiente lista. La nueva plataforma de desarrollo debía: Reutilizar al máximo el código disponible en PL/SQL. Aprovechar al máximo los conocimientos en el entorno de desarrollo Oracle. Usar tecnologías abiertas, basadas en estándares. Usar tecnologías de fácil aprendizaje y productivas. Con ello se pretendía una ampliación al mundo Web de los desarrollos internos sin un cambio traumático que llevase a perder el modelo actual de trabajo. La estrategia seguida para cumplir los requerimientos fue, en línea con la teoría bien establecida, separar claramente los aspectos relacionados con la presentación (donde aplicaciones en Oracle Forms y aplicaciones Web diferirían notablemente) de los Cuore 2005 Josep A. Frau Domingo Sebastián Aplicaciones Web con Cocoon y PL/SQL CTI@UIB aspectos relacionados con la lógica (donde habría muchas posibilidades de reutilización). A partir de este momento el trabajo fue analizar las distintas estrategias para la separación entre presentación y lógica. XML/XSLT Entre las distintas opciones existentes se optó por usar la tecnología XSLT (Extensible Stylesheet Language Transformations) ya que cumplía con los requerimientos establecidos y, además, se mostraba sólida y con una buena base de usuarios. Con XSLT, el funcionamiento del sistema quedaba tal como se representa en la siguiente figura: Web HTML Plantillas de transformación XSL XML PL/SQL Base de datos Aplicaciones Oracle Forms Con XSLT, los datos pueden representarse en XML, sin información de presentación ni ninguna dependencia a la tecnología utilizada por el cliente. Con ello, se facilita la reutilización de los datos y lógica de negocio y se aíslan los aspectos de presentación en las plantillas de transformación. Cocoon Cocoon es un framework para el desarrollo de aplicaciones Web modulares que aísla los distintos aspectos involucrados en la construcción y presentación de las vistas. Para ello, hace un intenso uso de las tecnologías basadas en XML. La idea central de Cocoon es el proceso de las peticiones mediante un encadenamiento de acciones independientes (pipelines) dirigidas de forma declarativa mediante un fichero XML (sitemap) o de forma procedimental utilizando un lenguaje de script (flowscript). Pipelines y flowscript no son tecnologías alternativas sino que se complementan para implementar las distintas posibilidades de interacción entre el usuario y el sistema. Durante la ejecución de los pipelines o flowscript, pueden realizarse tareas de validación de datos, gestión de la sesión o muchas otras tareas típicas, aunque la más habitual es la Cuore 2005 Josep A. Frau Domingo Sebastián Aplicaciones Web con Cocoon y PL/SQL CTI@UIB de convertir documentos únicamente con datos (XML) en vistas con la presentación deseada (HTML, PDF … ) mediante hojas de estilo (XSL). Modelo – Vista – Controlador Veamos en más detalle el esquema de funcionamiento del Cocoon. El diseño de Cocoon response al patrón de diseño Modelo – Vista – Controlador (MVC). El MVC distingue tres roles diferentes en los sistemas que interaccionan con un usuario. El modelo representa la lógica de negocio del sistema, independiente de la forma de interacción que tenga. La vista la componen todos los elementos que son presentados al usuario: pantallas, formularios, mensajes, etcétera. El controlador contiene la lógica que coordina el resto de componentes. Indica como responder a cada acción del usuario, como utilizar el modelo, etcétera. En el caso de Cocoon, las vistas son generalmente las páginas HTML presentadas al usuario, aunque pueden ser otros formatos como PDF o SVG. El modelo son documentos XML, con datos sin información de presentación. Para el rol de controlador Cocoon proporciona dos tecnologías diferentes. El sitemap.xmap, es una forma declarativa de indicar como responder a cada petición recibida. A continuación se presenta un ejemplo sencillo de sitemap: <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0" > <map:pipelines> <map:pipeline> <map:match pattern=“menor.html”> <map:generate type=“file”src=“menor.xml”/> <map:transform type=“xslt” src=“html.xslt”/> <map:serialize type=“html”/> </map:match> </map:pipeline> </map:pipelines> </map:sitemap> Cocoon compara la petición recibida (la URL) con los distintos patrones especificados en los map:match. Una vez encontrado el “match” correspondiente, ejecuta la secuencia de acciones (pipeline) declarada. En el ejemplo anterior, para una petición http://localhost/menor.html, el resultado devuelto será la transformación mediante html.xslt del fichero menor.xml. Con el sitemap disponemos de una forma limpia y escalable de describir el comportamiento de la aplicación, aunque a veces no es suficiente. Cuore 2005 Josep A. Frau Domingo Sebastián Aplicaciones Web con Cocoon y PL/SQL CTI@UIB En las aplicaciones Web es frecuente que el flujo de navegación no sea fácilmente describible mediante una correspondencia petición – acción. Si la navegación depende del estado, es posible especificar la tarea del controlador de forma programática. El lenguaje utilizado para esta tarea, el flowscript, permite resolver de forma elegante complejos esquemas de navegación. El ejemplo que sigue captura dos entradas y muestra una tercera pantalla en función de los valores entrados: function comparacion () { cocoon.sendPageAndWait (“operador.html”); var op1 = cocoon.request.get(“valor”); cocoon.sendPageAndWait (“operador.html”); var op2 = cocoon.request.get(“valor”); if (op1>op2) cocoon.sendPage (“mayor.html”); else cocoon.sendPage (“menor.html”); } A pesar de su sencillez conceptual, el flowscript es una potente herramienta a la hora de resolver problemas asociados al mantenimiento del estado durante la navegación del cliente. Por ejemplo, gestionar correctamente la información introducida por el cliente cuando este retrocede algunos pasos durante un proceso complejo (el clásico problema del botón back), se soluciona de forma natural sin apenas intervención alguna del programador. Cocoon Forms Cocoon Forms o CForms es la tecnología de Cocoon para gestionar los formularios de las aplicaciones Web. Cocoon presenta un modelo de formulario compuesto por cuatro aspectos diferentes, descritos en ficheros independientes: - La declaración de los campos (Definition) - En enlace de los datos con los campos (Binding) - La plantilla de presentación (Template) - Los aspectos dinámicos de la aplicación (Flowscript) El form definition proporciona una definición del formulario independiente de los datos y de la presentación: <fd:form xmlns:fd="http://apache.org/cocoon/forms/1.0#definition"> <fd:widgets> <fd:field id=“op1" required="true“> <fd:label>Primer operador:</fd:label> Cuore 2005 Josep A. Frau Domingo Sebastián Aplicaciones Web con Cocoon y PL/SQL CTI@UIB <fd:datatype base=“integer"/> <fd:validation> <fd:range min=“1” max=“50"/> </fd:validation> </fd:field> </fd:widgets> </fd:form> Cuando el formulario necesita recoger datos existentes se hace uso del Binding: <fb:context xmlns:fb=“http://apache.org/coco...” path="/" > <fb:value id=“op1" path=“VALOR1"/> </fb:context> Sin entrar en detalles de su funcionamiento, en línea general indica para cada elemento del formulario, que elemento del documento XML proporciona sus datos. Finalmente, se controla su presentación mediante el fichero de Template. <html> <body> <h1>Escoja dos números</h1> <ft:form-template action=“{$continuation/id}.cont” method=“post” xmlns:ft=“http://apache.org/cocoon/forms/1.0#template”> <ft:widget id=“op1”/> <ft:action id=“submit”/> </ft:form-template> </body> </html> Problemas de Cocoon. El principal problema de Cocoon es la documentación. El framework no dispone de un manual de referencia, ni una documentación completa. La mayoría de funcionalidades deben extraerse del análisis de los ejemplos proporcionados con el framework y en demasiados casos consultando el código directamente. Irónicamente Cocoon nació como una herramienta para mejorar la Web y la documentación de los proyectos de la fundación Apache, pero la documentación de usuario o desarrollador de Cocoon es muy mala, incompleta y muchas veces anticuada. Cuore 2005 Josep A. Frau Domingo Sebastián Aplicaciones Web con Cocoon y PL/SQL CTI@UIB Esta debilidad es reconocida por la comunidad de desarrolladores de Cocoon y periódicamente se proponen cambios en la infraestructura para generar la documentación. Pero faltan desarrolladores con conocimientos profundos de la herramienta que la documenten de un modo completo, coherente y la mantengan actualizada. Parte II – Pseudoprotocolo PL/SQL En la parte anterior se han introducido las tecnologias escogidas como base de trabajo para el desarrollo en el CTI. A continuación se explica como la base anterior ha sido extendida para hacer frente a los requerimientos expuestos. Mecanismos de extensión del Cocoon Cocoon es un producto construido con la intención de ser fácilmente extensible. Cocoon se forma a partir de un conjunto de elementos cuya integración se especifica en un fichero de configuración llamado cocoon.xconf. Además, las funcionalidades que componen el Cocoon son descritas mediante interfaces. Esto propicia que, en lugar de utilizar únicamente los elementos proporcionados por Cocoon, podamos desarrollar nuestros propios componentes para después, mediante la modificación del fichero cocoon.xconf, integrarlos en nuestra distribución de Cocoon personalizada. Interfaz 1 Componente_1 Cocoon cocoon.xconf Interfaz n Componente_n Son varios los aspectos que Cocoon permite personalizar y han servido para obtener la funcionalidad requerida: Source factories Los Source Factories son componentes que permiten acceder a distintos tipos de recursos. Los ejemplos básicos de Cocoon realizan transformaciones sobre contenido XML guardado en ficheros pero, con otros source factories, podemos utilizar información leída de bases de datos, de una URL, etc. Cuore 2005 Josep A. Frau Domingo Sebastián Aplicaciones Web con Cocoon y PL/SQL CTI@UIB Generadores Los generadores son los componentes que suministran el contenido original (una serie de eventos SAX), a partir del cual se sucede la cadena de transformaciones hasta llegar a la presentación final. Input-modules Los input-modules permiten el acceso a los atributos de la petición. Funcionalidades del Pseudoprotocolo CTI@UIB ha extendido éste framework básico en distintas líneas buscando una mayor productividad cuando la plataforma de desarrollo elegida es Oracle. 1. Desarrollar un protocolo procedimientos PL/SQL. de comunicación directa entre Cocoon y 2. Implementación de un pool de conexiones integrado en Cocoon que permita, de forma eficiente, cambiar el usuario de la conexión de un usuario genérico asociado al pool, al cliente de la petición. Se explicará como ésta solución mejora la seguridad global del sistema y la reutilización del código, sin renunciar a los beneficios de escalabilidad y rendimiento ofrecidos por los pools de conexiones. 3. Se proporciona una implementación para validar los valores de los campos de un formulario (CForms) contra procedimientos PL/SQL de la base de datos. 4. Se ha creado un sistema para guardar los valores de documentos XML, especialmente construidos (típicamente como resultado de un formulario CForms) para ser tratados por procedimientos PL/SQL Ejemplo de uso del Pseudoprotocolo Antes de entrar en los detalles del funcionamiento del pseudoprotocolo, presentaremos un simple ejemplo para facilitar posteriormente la comprensión de los detalles. Desde el sitemap de Cocoon se configura una respuesta para la petición saluda.html con la siguiente entrada: <map:match pattern="saluda.html"> <map:generate src="ora:plsql://POOL/ejemplo.proc?p1=COURE"/> <map:transform src="xslt/plantilla.xsl" type="xslt"/> <map:serialize type="html"/> </map:match> El sitemap indica que la respuesta se construirá a partir del contenido (documento XML) de la URL: ora:plsql://POOL/ejemplo.proc?p1=COURE procesado por la hoja de estilo xslt/plantilla.xsl Cuore 2005 Josep A. Frau Domingo Sebastián Aplicaciones Web con Cocoon y PL/SQL CTI@UIB Veamos brevemente que sucede cuando Cocoon accede a la URL para obtener el documento inicial. En primer lugar analiza el nombre de protocolo para determinar que forma de acceso utilizar. En el ejemplo, se trata del protocolo “ora:plsql” que previamente ha sido registrado para usar las classes del pseudoprotocolo PL/SQL. De este modo, la URL se pasa al pseudoprocolo para accedera a la fuente de XML. El procesado de la URL extrae sus distintos componentes: POOL es el nombre del pool de conexiones a utilizar ejemplo es el nombre del package PL/SQL proc es el nombre del procedimiento p1 es un parámetro con valor CUORE Por tanto, el resultado es la invocación al procedimiento ejemplo.proc con parámetro p1. La implementación de este procedimiento podría ser la que sigue: PACKAGE BODY ejemplo IS PROCEDURE proc (p1 IN VARCHAR2) IS BEGIN xmp.p( ‘<SALIDA>’ ); xmp.p( LOWER (p1) ); xmp.p( ‘</SALIDA>’ ); END proc; END ejemplo; El documento XML resultado del procedimiento es el acumulado en las sucesivas invocaciones al procedimiento xmp.p. En nuestro caso seria: <?xml version="1.0" encoding="iso-8859-1"?> <SALIDA> cuore </SALIDA> Este documento sería posteriormente procesado siguiendo los mecanismos estándares de Cocoon. Configuración del pool de conexiones Para acceder a la base de datos es necesario definir previamente uno o varios pools de conexiones, a partir de los cuales se obtendrán las conexiones. La configuración se lleva a cabo en el fichero cocoon.xconf, y es procesada por una clase del pseudoprocolo que es la que crea el pool de conexiones. <component-instance class="es.uib.pseudoprotocol.excalibur.OracleSourceFactory" Cuore 2005 Josep A. Frau Domingo Sebastián Aplicaciones Web con Cocoon y PL/SQL CTI@UIB logger="core.sources.ora" name="ora"> <driver ConnectionString="jdbc:oracle:thin:@172.1.1.2:1539:SID" PoolName="poolname" User="usuario" Password="password" PoolType="CACHE_POOL" > <configuration MaxConn = "7" MinConn = "3" Wait = "FALSE" TimeoutConn = "2" IncrementConn = "1" /> </driver> </component-instance> En la configuración se especifican: - la cadena de conexión utilizada por el JDBC - el nombre dado al pool - el usuario y password para la conexión - el tipo de pool - el número máximo y mínimo de conexiones - si esperar o no una para una conexión una vez sobrepasado el máximo - tiempo máximo de inactividad antes de cerrar una conexión - número de conexiones a crear simultáneamente Los tipos de pool existentes son: - JDBC_POOL utiliza la API estándar de JDBC - OCI_POOL utiliza la API específica de los driver OCI. Permite, entre otras funcionalidades, cambiar el usuario de las conexiones una vez obtenidas del pool - CACHE_POOL utiliza una implementación de Oracle de pool de conexiones. Usuarios y conexiones A la hora de afrontar la implementación del pseudoprotocolo PLSQL se tuvo que afrontar otro problema relacionado con las distintas “culturas” o formar de entender la aplicación por parte del desarrollo tradicional de aplicaciones sobre bases de datos y las aplicaciones Web. Las aplicaciones Web, generalmente hacen uso de un único usuario para el acceso a base de datos. La existencia de un único usuario, compartido por todos los clientes permite disponer de las ventajas de un pool único de conexiones y facilita la gestión del servidor de aplicaciones. El CTI@UIB, para sus aplicaciones basadas en Oracle Forms, había desarrollado un sistema de seguridad basado en los mecanismos de gestión y agrupación de permisos Cuore 2005 Josep A. Frau Domingo Sebastián Aplicaciones Web con Cocoon y PL/SQL CTI@UIB del gestor de base de datos Oracle. Esencialmente, el sistema asocia los usuarios y perfiles a los objetos de la base de datos basándose en una definición de las unidades funcionalidades del sistema (módulos de aplicaciones Web, Forms o Reports) y de los permisos que éstas requieren. Por ese motivo, era necesario que los accesos a la base de datos desde la aplicación Web se realizasen con usuarios asociados al cliente y no con una conexión común. La solución al problema vino de mano de la implementación OCI de los drivers de Oracle. Esta implementación permitía la re-autenticación sobre una conexión creada con un coste sustancialmente inferior al de crear una conexión nueva. La arquitectura resultante, por tanto, consistía en mantener un pool de conexiones con un usuario genérico y, al obtener una conexión del pool, realizar una re-autenticación con el usuario asociado a la petición. El resultado final fue el acceso a los beneficios en términos de seguridad proporcionados por la infraestructura elaborada para las aplicaciones Forms, conservando el rendimiento y facilidad de gestión típico de los pools de conexiones de las aplicaciones Web. Tipos de URLs y funcionalidad Forma básica La forma más básica de URL es la que invoca a un procedimiento sin parámetros ni atenticación: ora:plsql://pool/paquete.procedimento ora:plsql es el nombre dado al protocolo creado pool es el nombre con el que se ha declarado el pool en el fichero cocoon.xconf paquete es el nombre del package PLSQL procedimiento es el nombre del procedure Autenticación En el caso, más habitual, de necesitar acceder a conexiones con usuario y password se utiliza: ora:plsql://usuari:password@pool/paquete.procedimento Parámetros de entrada ora:plsql://usuari:password@pool/paquete.procedimento?IN:arg1=val1&INarg2=val2 Opcionalmente, puede simplificarse la URL anterior eliminando “IN:”, ya que por defecto, los parámetros son de entrada. ora:plsql://pool/paquete.procedimento?arg1=val1&arg2=val2 Parametros de entrada y salida Si un parámetro es de entrada/salida o salida, sustituimos IN por INOUT o OUT: ora:plsql://pool/paquete.procedimento?IN:arg1=val1&INOUT:arg2=val Cuore 2005 Josep A. Frau Domingo Sebastián Aplicaciones Web con Cocoon y PL/SQL CTI@UIB Parámetros múltiples Hay dos maneras de pasar parámetros múltiples. Podemos pasar el parámetro repetido: ora:plsql://pool/paquete.procedimento?arg1=val1&arg1=val2 O podemos utilizar otra notación más compacta: ora:plsql://pool/paquete.procedimento?arg1=val1~val2 Variables de entorno La notación con URL también permite definir variables de entorno activas durante la ejecución del procedimiento: ora:plsql://pool/paquete.procedimento?arg1=val1&#en1=val1&#en2=val2 Transacciones Para trabajar con transacciones, debe utilizarse el flowscript, ya que la interacción necesaria con los pools no puede realizarse desde el sitemap. Si necesitamos que distintas invocaciones formen parte de una misma transacción, entonces el procedimiento es el siguiente: En primer lugar iniciamos y obtenemos la transacción. String transid = PoolContainer.beginTransaction ( pool, user, password); Posteriormente la usamos en distintas invocaciones: ora:plsql://pool-transid/paquete.procedimento Podemos finalizar la transacción con PoolContainer.commit( transid, user, password ); o PoolContainer.rollback( transid, user, password ); Extensiones al CForms El mecanismo básico de validaciones en formularios ha sido extendido con nueva funcionalidad que permite acceder a lógica de negocio en PL/SQL. Algunas aplicaciones existentes, realizaban complejos procesos de validación de los datos de usuario utilizando información de la base de datos. Estos procesos estaban implementados en PL/SQL y estaban integrados en un mecanismo de elaboración propia para el tratamiento de errores. Con la intención de evitar la duplicación de código, se analizaron distintas estrategias para usar este código directamente en las aplicaciones Web. Finalmente, la opción que se considero más adecuada, fue la de extender el CForms de Cocoon para poder delegar la validación de uno o varios campos a un procedimiento PL/SQL. Cuore 2005 Josep A. Frau Domingo Sebastián Aplicaciones Web con Cocoon y PL/SQL CTI@UIB Se valoró el hecho que los procedimientos existentes podían reutilizarse sin modificación y que la gestión del error quedaba en manos de CForms, con lo que se garantizaba una presentación consistente con el resto de la capa Web. <fd:plsql Procedure="ora:plsql://POOL/Paquete.Procedimiento" WidgetError="path al widget que representará el error"> <fd:parametre Nom="parametro1" WidgetPath="path a un widget con el valor"/> <fd:parametre Nom="parametro2" Valor="Valor constante"/> </fd:plsql> El código anterior instruye al gestor de formularios de Cocoon para que invoque a un determinado procedimiento para realizar la validación, con los dos parámetros especificados: uno con el valor recogido en uno de los campos y el segundo con un valor constante. En caso de que la validación produzca un error el formulario es advertido de la situación y se le proporciona el mensaje descriptivo devuelto por el procedimiento PL/SQL Aplicaciones implementadas con el Pseudoprotocolo PL/SQL El CTI@UIB ha experimentado con Cocoon desde la versión 1.x. Cuando básicamente era un servlet para transformar documentos XML utilizando XSLT. Aunque las aplicaciones Web en producción se desarrollaban usando un framework propio (WebLeaf). El primer proyecto en usar Cocoon fue el Web del CTI@UIB. Este proyecto de publicación Web, usaba las características de framework de publicación que proporciona el Cocoon. Se desarrolló en el 2003 sobre la versión 2.1.3 de Cocoon. Como parte del proyecto de publicación del Web del SCI se creó una macro de Word para permitir la confección de contenidos de un modo fácil para los usuarios. Estos escribían documentos de Word que eran transformados en XML por la macro para ser publicado en el Web. <http://cti.uib.es> Todos los contenidos del servidor se generan dinámicamente en cada petición al Web. El primer proyecto en usar las características de framework de aplicaciones Web fue el Herbario Virtual de las Islas Baleares <http://herbarivirtual.uib.es>. Para esta aplicación se desarrolló el pseudoprotocolo PLSQL para interaccionar con la base de datos. Esta aplicación sirve para introducir la información de las especies vegetales de las islas Baleares y con ella generar el Web que es accesible a los usuarios. Está desarrollado sobre Cocoon 2.1.5. Las peticiones del usuario son generadas sobre un servidor Web para reducir la carga sobre el servidor dinámico. Se desarrollo la primera versión de la aplicación durante el año 2004. El desarrollo del pseudoprotocolo PLSQL sirvió para actualizar el Web del CTI para recoger dinámicamente información de noticias des de la base de datos y publicarlo en el Web. El proyecto actual es una aplicación para la automatización de la Fundació Universitat Empresa de les Illes Balears. El primer módulo Web que se ha desarrollado es el mantenimiento del currículo por parte de los candidatos de la bolsa de trabajo de la fundación. Cuore 2005 Josep A. Frau Domingo Sebastián Aplicaciones Web con Cocoon y PL/SQL CTI@UIB En este proyecto se ha utilizado Flowscript y CForms. Para este proyecto se han desarrollado extensiones para CForms y funciones para acceder a procedimientos PLSQ desde flowscript sobre el pseudoprotocolo PLSQL. Actualmente se está desarrollando una nueva versión del Web del CTI sobre Lenya (un proyecto de CMS sobre Cocoon). Posibles evoluciones Aprovechando la funcionalidad que aporta CForms en la gestión de formularios Web se han previsto algunas mejoras en la metodología. Oracle Designer permite almacenar información de los campos de las tablas como longitud máxima, longitud de presentación, label, hint, listas de valores, etc. esta información podría utilizarse para definir el documento de definición de los formularios. De la información de los módulos almacenada en Designer se podría generar un prototipo de los formularios Web creando los documentos de binding. Para los mantenimientos sencillos se podría utilizar una herramienta de mapeo como Hibernate y utilizar como fuente del proceso de binding Java Beans generados por la herramienta de mapeo. Conclusiones El sistema construido se ha mostrado productivo, simple y de aprendizaje fácil. La separación conseguida entre la capa de presentación y la de negocio permite aprovechar código y conocimientos en Oracle ya existentes. El acceso a los procedimientos almacenados mediante simples URLs y el tratamiento posterior del resultado mediante plantillas de transformación XSL es suficientemente sencillo para construir aplicaciones Web con una productividad comparable a las aplicaciones Form Server. Cuore 2005 Josep A. Frau Domingo Sebastián