Aplicaciones Web con Cocoon y PL/SQL

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