Aplicaciones Web con Cocoon y PL/SQL

Centro de Tecnologas de la Informacin Universidad de las Islas Baleares Josep A. Frau Domingo Sebastin

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 evolucin histrica de las aplicaciones desarrolladas en el CTI. Tradicionalmente, todos los aplicativos de gestin 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 travs de la Web. Las nuevas aplicaciones compartan parte del cdigo base con las ya existentes y adems, la mayor parte del personal del CTI acumulaba un conocimiento y experiencia en el desarrollo con herramientas de Oracle del que no se quera prescindir. Durante los aos anteriores el CTI haba desarrollado una metodologa propia que permita el desarrollo directo con la herramienta de anlisis de Oracle (Oracle Designer). El trabajo previo de adaptacin de las preferencias para la generacin a partir del anlisis 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 anlisis y diseo 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 impona ms bien una adaptacin a un entorno bien establecido que permitiese continuar con la solucin 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 consideracin la situacin actual, sin dejarse llevar por modas que, an siendo validas para otras organizaciones, no eran justificadas para el caso actual. El resultado final del estudio de requerimientos poda resumirse en la siguiente lista. La nueva plataforma de desarrollo deba: Reutilizar al mximo el cdigo disponible en PL/SQL. Aprovechar al mximo los conocimientos en el entorno de desarrollo Oracle. Usar tecnologas abiertas, basadas en estndares. Usar tecnologas de fcil aprendizaje y productivas.

Con ello se pretenda una ampliacin al mundo Web de los desarrollos internos sin un cambio traumtico que llevase a perder el modelo actual de trabajo. La estrategia seguida para cumplir los requerimientos fue, en lnea con la teora bien establecida, separar claramente los aspectos relacionados con la presentacin (donde aplicaciones en Oracle Forms y aplicaciones Web diferiran notablemente) de los Cuore 2005 Josep A. Frau Domingo Sebastin

Aplicaciones Web con Cocoon y PL/SQL

CTI@UIB

aspectos relacionados con la lgica (donde habra muchas posibilidades de reutilizacin). A partir de este momento el trabajo fue analizar las distintas estrategias para la separacin entre presentacin y lgica.

XML/XSLT
Entre las distintas opciones existentes se opt por usar la tecnologa XSLT (Extensible Stylesheet Language Transformations) ya que cumpla con los requerimientos establecidos y, adems, se mostraba slida 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 transformacin XSL XML

PL/SQL

Base de datos

Aplicaciones Oracle Forms

Con XSLT, los datos pueden representarse en XML, sin informacin de presentacin ni ninguna dependencia a la tecnologa utilizada por el cliente. Con ello, se facilita la reutilizacin de los datos y lgica de negocio y se aslan los aspectos de presentacin en las plantillas de transformacin.

Cocoon
Cocoon es un framework para el desarrollo de aplicaciones Web modulares que asla los distintos aspectos involucrados en la construccin y presentacin de las vistas. Para ello, hace un intenso uso de las tecnologas 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 tecnologas alternativas sino que se complementan para implementar las distintas posibilidades de interaccin entre el usuario y el sistema. Durante la ejecucin de los pipelines o flowscript, pueden realizarse tareas de validacin de datos, gestin de la sesin o muchas otras tareas tpicas, aunque la ms habitual es la Cuore 2005 Josep A. Frau Domingo Sebastin

Aplicaciones Web con Cocoon y PL/SQL

CTI@UIB

de convertir documentos nicamente con datos (XML) en vistas con la presentacin deseada (HTML, PDF ) mediante hojas de estilo (XSL). Modelo Vista Controlador Veamos en ms detalle el esquema de funcionamiento del Cocoon. El diseo de Cocoon response al patrn de diseo Modelo Vista Controlador (MVC). El MVC distingue tres roles diferentes en los sistemas que interaccionan con un usuario. El modelo representa la lgica de negocio del sistema, independiente de la forma de interaccin que tenga. La vista la componen todos los elementos que son presentados al usuario: pantallas, formularios, mensajes, etctera. El controlador contiene la lgica que coordina el resto de componentes. Indica como responder a cada accin del usuario, como utilizar el modelo, etctera. En el caso de Cocoon, las vistas son generalmente las pginas HTML presentadas al usuario, aunque pueden ser otros formatos como PDF o SVG. El modelo son documentos XML, con datos sin informacin de presentacin. Para el rol de controlador Cocoon proporciona dos tecnologas diferentes. El sitemap.xmap, es una forma declarativa de indicar como responder a cada peticin recibida. A continuacin 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=filesrc=menor.xml/> <map:transform type=xslt src=html.xslt/> <map:serialize type=html/> </map:match> </map:pipeline> </map:pipelines> </map:sitemap> Cocoon compara la peticin 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 peticin http://localhost/menor.html, el resultado devuelto ser la transformacin mediante html.xslt del fichero menor.xml. Con el sitemap disponemos de una forma limpia y escalable de describir el comportamiento de la aplicacin, aunque a veces no es suficiente.

Cuore 2005

Josep A. Frau Domingo Sebastin

Aplicaciones Web con Cocoon y PL/SQL

CTI@UIB

En las aplicaciones Web es frecuente que el flujo de navegacin no sea fcilmente describible mediante una correspondencia peticin accin. Si la navegacin depende del estado, es posible especificar la tarea del controlador de forma programtica. El lenguaje utilizado para esta tarea, el flowscript, permite resolver de forma elegante complejos esquemas de navegacin. El ejemplo que sigue captura dos entradas y muestra una tercera pantalla en funcin 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 navegacin del cliente. Por ejemplo, gestionar correctamente la informacin introducida por el cliente cuando este retrocede algunos pasos durante un proceso complejo (el clsico problema del botn back), se soluciona de forma natural sin apenas intervencin alguna del programador. Cocoon Forms Cocoon Forms o CForms es la tecnologa 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 declaracin de los campos (Definition) En enlace de los datos con los campos (Binding) La plantilla de presentacin (Template) Los aspectos dinmicos de la aplicacin (Flowscript)

El form definition proporciona una definicin del formulario independiente de los datos y de la presentacin: <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 Sebastin

Aplicaciones Web con Cocoon y PL/SQL <fd:datatype base=integer"/> <fd:validation> <fd:range min=1 max=50"/> </fd:validation> </fd:field> </fd:widgets> </fd:form>

CTI@UIB

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 lnea general indica para cada elemento del formulario, que elemento del documento XML proporciona sus datos. Finalmente, se controla su presentacin mediante el fichero de Template. <html> <body> <h1>Escoja dos nmeros</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 documentacin. El framework no dispone de un manual de referencia, ni una documentacin completa. La mayora de funcionalidades deben extraerse del anlisis de los ejemplos proporcionados con el framework y en demasiados casos consultando el cdigo directamente. Irnicamente Cocoon naci como una herramienta para mejorar la Web y la documentacin de los proyectos de la fundacin Apache, pero la documentacin de usuario o desarrollador de Cocoon es muy mala, incompleta y muchas veces anticuada.

Cuore 2005

Josep A. Frau Domingo Sebastin

Aplicaciones Web con Cocoon y PL/SQL

CTI@UIB

Esta debilidad es reconocida por la comunidad de desarrolladores de Cocoon y peridicamente se proponen cambios en la infraestructura para generar la documentacin. 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 continuacin se explica como la base anterior ha sido extendida para hacer frente a los requerimientos expuestos.

Mecanismos de extensin del Cocoon

Cocoon es un producto construido con la intencin de ser fcilmente extensible. Cocoon se forma a partir de un conjunto de elementos cuya integracin se especifica en un fichero de configuracin llamado cocoon.xconf. Adems, 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 despus, mediante la modificacin del fichero cocoon.xconf, integrarlos en nuestra distribucin 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 bsicos de Cocoon realizan transformaciones sobre contenido XML guardado en ficheros pero, con otros source factories, podemos utilizar informacin leda de bases de datos, de una URL, etc. Cuore 2005 Josep A. Frau Domingo Sebastin

Aplicaciones Web con Cocoon y PL/SQL Generadores

CTI@UIB

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 presentacin final. Input-modules Los input-modules permiten el acceso a los atributos de la peticin.

Funcionalidades del Pseudoprotocolo

CTI@UIB ha extendido ste framework bsico en distintas lneas buscando una mayor productividad cuando la plataforma de desarrollo elegida es Oracle. 1. Desarrollar un protocolo procedimientos PL/SQL. de comunicacin directa entre Cocoon y

2. Implementacin de un pool de conexiones integrado en Cocoon que permita, de forma eficiente, cambiar el usuario de la conexin de un usuario genrico asociado al pool, al cliente de la peticin. Se explicar como sta solucin mejora la seguridad global del sistema y la reutilizacin del cdigo, sin renunciar a los beneficios de escalabilidad y rendimiento ofrecidos por los pools de conexiones. 3. Se proporciona una implementacin 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 (tpicamente 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 comprensin de los detalles. Desde el sitemap de Cocoon se configura una respuesta para la peticin 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 Sebastin

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 parmetro con valor CUORE

Por tanto, el resultado es la invocacin al procedimiento ejemplo.proc con parmetro p1. La implementacin de este procedimiento podra 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 sera posteriormente procesado siguiendo los mecanismos estndares de Cocoon.

Configuracin 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 obtendrn las conexiones. La configuracin 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 Sebastin

Aplicaciones Web con Cocoon y PL/SQL

logger="core.sources.ora" name="ora">

CTI@UIB

<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 configuracin se especifican: la cadena de conexin utilizada por el JDBC el nombre dado al pool el usuario y password para la conexin el tipo de pool el nmero mximo y mnimo de conexiones si esperar o no una para una conexin una vez sobrepasado el mximo tiempo mximo de inactividad antes de cerrar una conexin nmero de conexiones a crear simultneamente JDBC_POOL utiliza la API estndar de JDBC OCI_POOL utiliza la API especfica de los driver OCI. Permite, entre otras funcionalidades, cambiar el usuario de las conexiones una vez obtenidas del pool CACHE_POOL utiliza una implementacin de Oracle de pool de conexiones.

Los tipos de pool existentes son:

Usuarios y conexiones
A la hora de afrontar la implementacin del pseudoprotocolo PLSQL se tuvo que afrontar otro problema relacionado con las distintas culturas o formar de entender la aplicacin 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 gestin del servidor de aplicaciones. El CTI@UIB, para sus aplicaciones basadas en Oracle Forms, haba desarrollado un sistema de seguridad basado en los mecanismos de gestin y agrupacin de permisos Cuore 2005 Josep A. Frau Domingo Sebastin

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 basndose en una definicin de las unidades funcionalidades del sistema (mdulos 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 aplicacin Web se realizasen con usuarios asociados al cliente y no con una conexin comn. La solucin al problema vino de mano de la implementacin OCI de los drivers de Oracle. Esta implementacin permita la re-autenticacin sobre una conexin creada con un coste sustancialmente inferior al de crear una conexin nueva. La arquitectura resultante, por tanto, consista en mantener un pool de conexiones con un usuario genrico y, al obtener una conexin del pool, realizar una re-autenticacin con el usuario asociado a la peticin. El resultado final fue el acceso a los beneficios en trminos de seguridad proporcionados por la infraestructura elaborada para las aplicaciones Forms, conservando el rendimiento y facilidad de gestin tpico de los pools de conexiones de las aplicaciones Web.

Tipos de URLs y funcionalidad

Forma bsica La forma ms bsica de URL es la que invoca a un procedimiento sin parmetros ni atenticacin: 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 Autenticacin En el caso, ms habitual, de necesitar acceder a conexiones con usuario y password se utiliza: ora:plsql://usuari:password@pool/paquete.procedimento Parmetros 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 parmetros son de entrada. ora:plsql://pool/paquete.procedimento?arg1=val1&arg2=val2 Parametros de entrada y salida Si un parmetro 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 Sebastin

Aplicaciones Web con Cocoon y PL/SQL Parmetros mltiples

CTI@UIB

Hay dos maneras de pasar parmetros mltiples. Podemos pasar el parmetro repetido: ora:plsql://pool/paquete.procedimento?arg1=val1&arg1=val2 O podemos utilizar otra notacin ms compacta: ora:plsql://pool/paquete.procedimento?arg1=val1~val2 Variables de entorno La notacin con URL tambin permite definir variables de entorno activas durante la ejecucin 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 interaccin necesaria con los pools no puede realizarse desde el sitemap. Si necesitamos que distintas invocaciones formen parte de una misma transaccin, entonces el procedimiento es el siguiente: En primer lugar iniciamos y obtenemos la transaccin. String transid = PoolContainer.beginTransaction ( pool, user, password); Posteriormente la usamos en distintas invocaciones: ora:plsql://pool-transid/paquete.procedimento Podemos finalizar la transaccin con PoolContainer.commit( transid, user, password ); o PoolContainer.rollback( transid, user, password );

Extensiones al CForms
El mecanismo bsico de validaciones en formularios ha sido extendido con nueva funcionalidad que permite acceder a lgica de negocio en PL/SQL. Algunas aplicaciones existentes, realizaban complejos procesos de validacin de los datos de usuario utilizando informacin de la base de datos. Estos procesos estaban implementados en PL/SQL y estaban integrados en un mecanismo de elaboracin propia para el tratamiento de errores. Con la intencin de evitar la duplicacin de cdigo, se analizaron distintas estrategias para usar este cdigo directamente en las aplicaciones Web. Finalmente, la opcin que se considero ms adecuada, fue la de extender el CForms de Cocoon para poder delegar la validacin de uno o varios campos a un procedimiento PL/SQL.

Cuore 2005

Josep A. Frau Domingo Sebastin

Aplicaciones Web con Cocoon y PL/SQL

CTI@UIB

Se valor el hecho que los procedimientos existentes podan reutilizarse sin modificacin y que la gestin del error quedaba en manos de CForms, con lo que se garantizaba una presentacin 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 cdigo anterior instruye al gestor de formularios de Cocoon para que invoque a un determinado procedimiento para realizar la validacin, con los dos parmetros especificados: uno con el valor recogido en uno de los campos y el segundo con un valor constante. En caso de que la validacin produzca un error el formulario es advertido de la situacin 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 versin 1.x. Cuando bsicamente era un servlet para transformar documentos XML utilizando XSLT. Aunque las aplicaciones Web en produccin se desarrollaban usando un framework propio (WebLeaf). El primer proyecto en usar Cocoon fue el Web del CTI@UIB. Este proyecto de publicacin Web, usaba las caractersticas de framework de publicacin que proporciona el Cocoon. Se desarroll en el 2003 sobre la versin 2.1.3 de Cocoon. Como parte del proyecto de publicacin del Web del SCI se cre una macro de Word para permitir la confeccin de contenidos de un modo fcil para los usuarios. Estos escriban 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 dinmicamente en cada peticin al Web. El primer proyecto en usar las caractersticas de framework de aplicaciones Web fue el Herbario Virtual de las Islas Baleares <http://herbarivirtual.uib.es>. Para esta aplicacin se desarroll el pseudoprotocolo PLSQL para interaccionar con la base de datos. Esta aplicacin sirve para introducir la informacin 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 dinmico. Se desarrollo la primera versin de la aplicacin durante el ao 2004. El desarrollo del pseudoprotocolo PLSQL sirvi para actualizar el Web del CTI para recoger dinmicamente informacin de noticias des de la base de datos y publicarlo en el Web. El proyecto actual es una aplicacin para la automatizacin de la Fundaci Universitat Empresa de les Illes Balears. El primer mdulo Web que se ha desarrollado es el mantenimiento del currculo por parte de los candidatos de la bolsa de trabajo de la fundacin. Cuore 2005 Josep A. Frau Domingo Sebastin

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 versin del Web del CTI sobre Lenya (un proyecto de CMS sobre Cocoon).

Posibles evoluciones
Aprovechando la funcionalidad que aporta CForms en la gestin de formularios Web se han previsto algunas mejoras en la metodologa. Oracle Designer permite almacenar informacin de los campos de las tablas como longitud mxima, longitud de presentacin, label, hint, listas de valores, etc. esta informacin podra utilizarse para definir el documento de definicin de los formularios. De la informacin de los mdulos almacenada en Designer se podra generar un prototipo de los formularios Web creando los documentos de binding. Para los mantenimientos sencillos se podra 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 fcil. La separacin conseguida entre la capa de presentacin y la de negocio permite aprovechar cdigo y conocimientos en Oracle ya existentes. El acceso a los procedimientos almacenados mediante simples URLs y el tratamiento posterior del resultado mediante plantillas de transformacin XSL es suficientemente sencillo para construir aplicaciones Web con una productividad comparable a las aplicaciones Form Server.

Cuore 2005

Josep A. Frau Domingo Sebastin