i
Indice general
4. Apache Lenya 1.4: Arquitectura 1 4.1. Introduccion ...... 1 4.1.1. Arquitectura del sistema ...... 1 4.1.2. Arquitectura del gestor de contenidos ...... 2 4.2. Conceptos basicos ...... 4 4.2.1. Modulos ...... 4 4.2.2. Polimor smo de las publicaciones ...... 4 4.2.2.1. El protocolo fallback:// ...... 6 4.3. La capa de presentacion ...... 6 4.3.1. Los sitemaps de Lenya ...... 6 4.3.1.1. El espacio de URIs ...... 6 4.3.1.2. Proceso de una peticion ...... 8 4.4. La capa de gestion ...... 11 4.4.1. Marco de casos de uso ...... 11 4.4.1.1. Introduccion ...... 11 4.4.1.2. Descripciondel funcionamiento ...... 13 4.4.1.3. Implementacionde un caso de uso ...... 13 4.4.2. Control de acceso ...... 16 4.4.2.1. De niciones basicas ...... 17 4.4.2.2. Componentes ...... 18 4.4.2.3. Los mecanismos de autorizaciony autenticacion ...... 19 4.4.3. Flujo de trabajo ...... 19 4.4.3.1. La de niciondel ujo de trabajo ...... 21 4.4.3.2. Personalizaciondel ujo de trabajo ...... 23 4.4.4. Noti caciones ...... 23 4.5. La capa de repositorio ...... 24 4.5.1. Acceso al repositorio ...... 24 4.5.1.1. Control optimista de concurrencia ...... 24 4.5.1.2. Check-In y Check-Out ...... 25 4.5.2. Control de versiones ...... 25 4.6. Arquitectura fsica ...... 25 4.6.1. Estructura de directorios de una publicacion ...... 25 4.6.2. Estructura de directorios de un modulo ...... 27 ii
4.6.2.1. Adicionde un nuevo modulo ...... 28 4.6.2.2. El chero module.xml ...... 29 4.6.3. Estructura de directorios de la aplicacion ...... 29
1
Captulo4
Apache Lenya 1.4: Arquitectura
4.1. Introduccion
Apache Lenya estaconstruido sobre la arquitectura de publicacionde Apache Cocoon a la que se le han a~nadidocomponentes propios para aportar funcionalidades de gestionde contenidos, como, por ejemplo:
Edicionde contenidos: Para ello se han integrado varios editores WYSIWYG, y se han creado modulospara soportar los protocolos WebDAV y Neutron (OSR-101).
Gestiondel sitio: Funcionalidades para crear documentos, moverlos, eliminarlos, etc.
Mecanismos de plani caciony noti cacion
Control de acceso
Gestionde ujo de trabajo
Motor de busquedas: Proporciona busquedasen los campos de contenido de cheros XML basadas en Apache Lucene.
En los proximos apartados de este captulode niremos algunos conceptos basicos y analizaremos algunos de los aspectos masimportantes de cada una de las capas que constituyen la arquitectura funcional de Lenya. Para nalizar, describiremos brevemente la arquitectura fsicadel mismo.
4.1.1. Arquitectura del sistema La arquitectura de un sistema basado en Lenya serapor tanto la que se muestra en la gura 4.1. Como podemos ver, se trata de un sistema tremendamente exible tanto en los formatos de publicacion,los medios de ediciony repositorios de contenidos a elegir. Apache Lenya soporta publicacionmulticanal y permite disponer de una amplia variedad de clientes 2 CAPITULO 4. APACHE LENYA 1.4: ARQUITECTURA
Figura 4.1: Arquitectura de un sistema basado en Apache Lenya 1.4 de CMS, desde navegadores web hasta programas de dise~noavanzados como Dreamweaver. Tambienexiste una gran exibilidad en cuanto al repositorio de contenidos, pudiendose elegir entre el sistema de archivos, bases de datos con conector JDBC, bases de datos XML, etc. Tambiense proporciona integracioncon repositorios JCR, aunque estaes aunlimitada y previsiblemente la integraciontotal se lleve a cabo en la version1.6. Esta gura nos permite observar ademaslas futuras lneasde dise~node Lenya. Se han dado ya los primeros pasos para soportar el protocolo Neutron (OSR-101) y para la integracioncon repositorios que sigan la especi cacionJSR-170. Con esto se persigue conseguir un sistema como el de la gura 4.2. Sin embargo, como ya hemos comentado, esto constituye una lneade futuro y aun estasujeta a discusiondentro de la comunidad de desarrolladores de Lenya. Por ejemplo, la limitaciondel repositorio a repositorios JSR-170 es un tema muy debatido.
4.1.2. Arquitectura del gestor de contenidos La losofadetrasdel dise~node la arquitectura de Lenya podraresumirse en los siguientes puntos:
Facilidad de migracionde portales basados en Cocoon.
Reutilizacionde componentes de codigoabierto de probada e ciencia: Ant, Quartz Scheduler, Log4j... 4.1. INTRODUCCION 3
Figura 4.2: Futura arquitectura de un sistema basado en Apache Lenya
Descentralizacion:Sistema de bloqueo de cheros mientras estansiendo modi cados.
Respeto a los patrones de dise~node Avalon y Cocoon.
Modularizacion:Las distintas funcionalidades de Lenya se implementan mediante modulos.
Polimor smo de las publicaciones: Las publicaciones pueden sobreescribir funcionali- dades implementadas por el nucleocon compatibilidad con futuras versiones garanti- zada.
La arquitectura funcional de Lenya permite una divisionen tres capas, segunvemos en la gura 4.3. La capa de presentaciones la encargada de generar la interfaz CMS, interactuar con los programas de ediciony mostrar la publicacion. La capa de gestionse encarga del control de acceso, del ujo de trabajo, la gestion de la plani caciony las transacciones de la logica de negocio. La capa de repositorio actuacomo interfaz con los repositorios de contenidos. Su funciones engloban la generacionde metadatos, el control de versiones y las transacciones de sistema. 4 CAPITULO 4. APACHE LENYA 1.4: ARQUITECTURA
Figura 4.3: Arquitectura de capas de Lenya
4.2. Conceptos basicos
4.2.1. Modulos Un modulo es un paquete que que proporciona un conjunto de recursos o una funcionalidad. Por ejemplo, un modulopuede utilizarse para proporcionar un nuevo tipo de recurso, una implementacionde repositorio o un conjunto de hojas de estilo XSLT. Algunos de los modulosincluidos en la distribucionde Lenya son:
lucene: Proporciona funcionalidades de busqueda.
lenyadoc: A~nadeel protocolo lenyadoc://.
administration: Proporciona la funcionalidad de gestionde usuarios.
links: Tipo de recurso para gestionar listas de vnculos.
4.2.2. Polimor smo de las publicaciones Apache Lenya delega la personalizaciondel nucleodel gestor a las publicaciones. Esto signi ca que desde las publicaciones se pueden sobreescribir o extender las funciona- lidades que ofrece el nucleo.Gracias a esta caracterstica, las modi caciones de aspectos del nucleorequeridas por algunas publicaciones podranser realizadas sin afectar al resto. Ademas,se tendrala garantade que dichos cambios serancompatibles con futuras versiones de Lenya. Veamos comoes posible esto. La API de Lenya se divide en nucleoe implementacion.El nucleo comprende aque- llas interfaces y algunas clases muy concretas que de nen el comportamiento de Lenya como gestor de contenidos y que puede garantizarse que serancompatibles con futuras versiones. La implementaciondel nucleo,por su parte, estaformada por modulosque implementan 4.2. CONCEPTOS BASICOS 5
Figura 4.4: Plantillas de publicacion funcionalidades de nidas por dichas interfaces. Para proporcionar una funcionalidad con- creta, ademasde las clases de Java que implementan las interfaces correspondientes, los modulostambienpueden contener un sitemap, hojas de estilo XSLT, JXTemplates, etc. Las publicaciones pueden sobreescribir cualquiera de los cheros que forman par- te de los modulos,incluidas las clases de Java. Si dentro de alguna publicacionse desea modi car algun chero de un moduloen particular, habraque ubicarlo en
PUB HOME/lenya/modules/
Gracias a este mecanismo, las publicaciones podranreemplazar las implementa- ciones del nucleopor otras personalizadas, con la garantade que se mantendrala com- patibilidad con futuras versiones. Esto ultimoseracierto siempre y cuando se respeten las interfaces de nidas en el nucleode la API. As,podramodi carse la forma en que se al- macenan los datos de los usuarios para que en lugar de guardarse en el sistema de cheros se guardasen en una base de datos. Ademasde la posibilidad de sobreescribir o extender el nucleoque ya existaen la version1.2, la version1.4 extiende estos mecanismos a las propias publicaciones. En la nueva version,las publicaciones pueden compartir propiedades arbitrarias ( cheros XSLT, cheros de con guracion, cheros de cuentas de usuarios, tipos de recursos, etc.). En efecto, toda publicacionpuede ser empleada como plantilla para una nueva publicacion,creandosede este modo publicaciones derivadas de estaque se denominan "instancias". No existe limitacionen cuanto al nivel de anidacion.De esta forma, se posibilita la creacionde portales corporativos con una apariencia consistente de forma sencilla y evitando redundancias. Las publicaciones derivadas pueden sobreescribir los cheros heredados de la publi- cacionplantilla simplemente replicando la estructura de directorios y el nombre del chero 6 CAPITULO 4. APACHE LENYA 1.4: ARQUITECTURA en cuestion.Si un chero es sobreescrito, los cambios en el chero original almacenado en la publicacionplantilla no tendranningunefecto sobre el chero sobreescrito de la publicacion derivada.
4.2.2.1. El protocolo fallback:// Estos mecanismos de herencia se implementan mediante un protocolo espec co de Lenya denominado fallback:// que se utiliza para la resolucionde URIs. Es importante destacar que este protocolo actuaa nivel de cheros y por tanto soloes aplicable a cheros completos que sean referenciados mediante URIs en cheros de con guracion. Si una URI comienza con el identi cador de protocolo fallback://, el chero sera buscado de forma recursiva del siguiente modo:
context://lenya/pubs/mi-pub/ruta-relativa-hacia- chero
context://lenya/pubs/plantilla(mi-pub)/ruta-relativa-hacia- chero
context://lenya/pubs/plantilla(plantilla(mi-pub))/ruta-relativa-hacia- chero
...
context://ruta-relativa-hacia- chero
4.3. La capa de presentacion
La capa de presentacionse encarga de mostrar la publicacionen el modo de fun- cionamiento de producciony de mostrar la interfaz CMS en el modo de funcionamiento de edicion.Asmismo,tambiense encarga de realizar la integracionde las distintas posibilida- des de edicioncomentadas en ?? con el gestor. En este apartado estudiaremos comolos sitemaps de Lenya llevan a cabo el proceso de mostrar la publicaciony la interfaz CMS.
4.3.1. Los sitemaps de Lenya 4.3.1.1. El espacio de URIs El espacio de URIs se utiliza para organizar y controlar el acceso a los modos de funcionamiento de producciony edicion.Dentro del modo de edicion,tambiense utili- zarapara generar la interfaz CMS. El espacio de URIs en Lenya responde al siguiente esquema:
context-pre x/pub-id/mode/document-id?optional-parameters
Estudiemos a continuacioncomolas distintas partes de la URI determinan el procesado a realizar. 4.3. LA CAPA DE PRESENTACION 7
El contexto El contexto determina el acceso al sitemap razde Lenya. En el caso de desplegar Lenya dentro del contexto razde un contenedor de servlets, se puede acceder al sitemap razde Lenya a travesde http://localhost:8080/. Si no se ha desplegado en el contexto razdel contenedor, la primera parte de la URI serautilizada por estepara decidir queservlet es el responsable de gestionar la peticion. En tal caso, el sitemap razse accederadesde http://localhost:8080/lenya. En lo que sigue consideraremos que Lenya ha sido desplegado en el contexto raz del contenedor.
El identi cador de la publicacion La primera parte de la URL solicitada es el identi cador de la publicacion.Es importante se~nalarque el nombre de la publicaciony su identi cador no tienen por queser iguales, ya que el identi cador tiene que ser compatible con con el esquema de codi cacion de la URI y con el sistema de archivos en el que estase almacena. El motivo es que coincide con nombre del directorio donde se guarda la publicaciony ha de formar parte de la URL.
El modo de funcionamiento Hemos reiterado en varias ocasiones que Lenya presenta dos modos de funciona- miento: ediciony produccion.Desde el punto de vista del usuario, la mayor diferencia entre ambos modos es que en el de edicionlos menusdel CMS no se muestran. Sin embargo, internamente el repositorio almacena copias distintas de los documentos para cada una de las areas.Esto permite a los editores la modi cacionde una copia de trabajo sin que esto afecte al sitio en produccion. El modo de funcionamiento determinarael repositorio al que hay que acceder y si es necesario mostrar o no la interfaz CMS.
La URL del documento El sitemap de la publicacionse encarga de tomar la URL del documento de la porcionde la URL original y de generar y renderizar el contenido de la pagina.Esta tarea aparentemente simple es la que marca las diferencias masgrandes entre los distintos CMS en cuestion de caractersticas y con gurabilidad. La forma massimple de tratarlo sera:
Elegir el repositorio de contenido apropiado (producciono edicion).
Usar la URL del documento para encontrar un archivo por su nombre.
Si es necesario, aplicar una hoja XSLT y serializar el resultado.
Ademasde esto, tambiense puede ocurrir que: 8 CAPITULO 4. APACHE LENYA 1.4: ARQUITECTURA
Se utilice una clase espec cade la publicacionpara mapear la URL del documento a un repositorio interno. Esto permitiraocultar la estructura real del repositorio a un visitante de la web.
Se decida queversionde idioma usar para servir el documento. Por ejemplo, si no se especi ca un idioma, Lenya podradecidir usar el idioma de nido por defecto. Si se solicita un idioma espec co, Lenya lo buscara en el repositorio y lo generara si estuviera disponible. Si no existiera una versionpara el idioma solicitado, Lenya volveraa optar por mostrar la versionen el idioma por defecto.
Invocar al sitemap del modulodel tipo de recurso asociado para que renderice el documento.
Parametrosde la URL Estos parametrosson opcionales y entre ellos podemos encontrar los parametros espec cosde Lenya, como pueden ser los referidos a los casos de uso y los espec cosde la publicacion,introducidos por el desarrollador. El parametroutilizado para invocar los casos de uso es lenya.usecase.
4.3.1.2. Proceso de una peticion Lenya estaformado por un conjunto de sitemaps que se utilizan para procesar la peticiony devolver la respuesta. Pareceramas facilconcentrarlo todo en un solositemap, pero hay varias razones para tener varios sitemaps aun a riesgo de ganar complejidad:
Separaciondel contenido de la publicaciony de la interfaz del CMS.
Separaciondel nucleode Lenya y las partes espec cas de la publicacion.
Implementacionde los mecanismos de fallback.
Montaje automaticode los subsitemaps dependiendo de los valores de las variables del sitemap padre.
Esta abundancia de sitemaps provoca que el analisisdel proceso de una peticion sea bastante complejo. Veamos a grandes rasgos comose lleva esto a cabo. Todas las peticiones que un cliente realiza a Lenya se procesan de forma similar, distinguiendoselos siguientes pasos:
El sistema operativo recibe la peticiony la pasa al contenedor de servlets.
El contenedor decide queservlet es el encargado de procesarla (Lenya).
El sitemap razde Lenya recibe la peticion.
Por regla general, este sitemap trans ere la peticiona global-sitemap.xmap. 4.3. LA CAPA DE PRESENTACION 9
Este ultimodecidirasi hay que montar el sitemap usecase.xmap, porque la peticion solicite la ejecucionde un caso de uso o si hay que montar el sitemap de la publicacion el que se encargue del procesamiento.
La peticionse procesa y se devuelve el resultado al cliente.
Como podemos comprobar, el lugar donde acabe de procesarse dependeraexclu- sivamente de los valores de los parametrosde la URL. Si la peticionllega a la publicacion, se continuaranmontando sitemaps para formatear la informacionque se devolveracomo resultado de la peticion.El numerode subsitemaps que se montan puede ser muy variable, dependiendo de si, por ejemplo, lanzamos una peticion de edicionde la paginaque estamos visitando.
Jerarquade sitemaps
Como acabamos de ver, los sitemaps de Lenya se seleccionan en tiempo de ejecu- cion,dirigiendo el ujo de la misma hacia un sitemap de nivel inferior si fuera necesario. En la gura 4.5 podemos ver un esquema simpli cado de este proceso. En esta gura podemos observar un ujo normal de procesamiento de una peticion de una URL. La peticionentra en el Sitemap1 y tras ser procesada dentro de el se decide que es necesario proceder al montado del Sitemap2 para continuar atendiendola.Dentro de este,se observa que para seguir resolviendolaes necesario montar el Sitemap3, por lo que se procede al montaje del mismo y se le pasa el control. Una vez en este sitemap hemos distinguido tres casos:
Caso 1: Se decide que para seguir resolviendo la peticiones necesario ejecutar un conducto (pipeline) del Sitemap1, por lo que a travesdel protocolo cocoon:// se re- dirige la peticionhacia la URI cocoon://prueba que seracapturada y procesada en el Sitemap1.
Caso 2: Se decide que para seguir resolviendo la peticiones necesario ejecutar un conducto distinto del mismo sitemap en el que se encuentra, por lo que mediante el protocolo cocoon:/ se pasa el control otra vez al inicio del Sitemap3 para que se capture la URI cocoon:/prueba2.
Caso 3: Se decide que la peticionha sido completamente resuelta y se serializa el resultado, devolviendo la respuesta al cliente.
Como podemos comprobar, la casusticade un ejemplo tan simple es muy grande. En Lenya hay muchos mas sitemaps que en este peque~noejemplo: hay algunos que se montan para los servicios de edicion,otros que se montan para la gestionde los casos de uso, otros que se montan para tareas de internacionalizacion,etc. Esto di culta la comprensiondel procesado de peticiones en un primer momento. En el apendicepodemos encontrar una descripcionde los sitemaps masimportantes de Lenya. 10 CAPITULO 4. APACHE LENYA 1.4: ARQUITECTURA
Figura 4.5: Ejemplo de sitemaps 4.4. LA CAPA DE GESTION 11
4.4. La capa de gestion
La capa de gestionse encarga de las siguientes tareas:
Creaciony gestionde usuarios, grupos y roles.
Control de acceso a la publicaciony dentro de la misma control de las acciones que pueden llevar a cabo los usuarios en funcionde los roles que tenga asignados.
Gestionar la estructura de la publicacion:crear, copiar, mover, eliminar documentos.
Gestionar las operaciones de aprobacionde documentos: enviar para su revision,acep- tar, publicar, desactivar...
Todas estas tareas se llevan a cabo mediante la interaccionde los siguientes com- ponentes:
Control de acceso: Este componente se encarga de la autenticacionde usuarios y de controlar que los usuarios sololleven a cabo las operaciones que les estanpermitidas en funciondel rol que desempe~nan.
Marco de casos de uso: Se encarga de ejecutar las acciones de los menusde la interfaz CMS cuando un usuario las selecciona.
Plani cador: Se encarga de controlar que acciones como la publicacionde un docu- mento o su retirada del portal en produccionse lleven a cabo en el momento indicado por el usuario.
Flujo de trabajo: Se encarga de controlar que las distintas acciones que pueden realizarse dentro del gestor sean ejecutadas solamente por los usuarios autorizados a ello.
Noti cacion: Se encarga de gestionar las noti caciones a los usuarios. Por ejemplo, si un revisor decide rechazar un documento, es componente se encargarade enviar un correo electronicoal editor que creodicho documento, con los contenidos que especi que el revisor que lo rechaza (normalmente, el motivo del rechazo).
La gura 4.6 nos muestra la interaccionentre estos componentes.
4.4.1. Marco de casos de uso 4.4.1.1. Introduccion Un caso de uso en Lenya es una acciondesencadenada por el usuario. En la mayora de las ocasiones, los casos de uso se desencadenan al seleccionar una opcionen uno de los menusde la interfaz CMS para un documento dentro de una publicacionespec ca.El caso de uso llevaraa cabo su accionsobre dicho documento. Sin embargo, esto no siempre es as.Tambienhay casos de uso que no operan sobre ningundocumento, como por ejemplo el caso de uso ac.logout, que controla el proceso de 12 CAPITULO 4. APACHE LENYA 1.4: ARQUITECTURA
Figura 4.6: Interaccionde componentes de la capa de gestion cierre de sesionde los usuarios. En este ejemplo, el caso de uso se ejecuta con independencia del documento que se estaba visualizando cuando se seleccionola opciondel menu. Los menusde la interfaz CMS disparan los casos de uso a~nadiendoel parametro lenya.usecase a la peticiondel documento actual. Si por ejemplo el usuario elige la opcion Publicar del menu Flujo de Trabajo, se lanzarauna peticioncomo esta:
GET http://www.server.com/lenya/default/authoring/tutorial.html?&lenya.usecase=publish
El sitemap global-sitemap.xmap redirigiratodas las peticiones que contengan el parametro lenya.usecase al sitemap LENYA WEBAPP/lenya/usecase.xmap. Desde la version1.4 en adelante, el conducto del listado 4.1 se encarga de detectar si el caso de uso ha sido implementado en Java utilizando el nuevo marco de casos de uso de Lenya 1.4. listado 4.1 usecase.xmap: Resoluciondel manejador del caso de uso
La implementacionpor defecto del matcher registered-usecase comprobarasi el caso de uso estaregistrado dentro del marco de casos de uso, en cuyo caso el procesado el procesado continuaraen sitemap LENYA WEBAPP/lenya/usecases/usecase.xmap Si por el contrario, el caso de uso no estaregistrado, seraejecutado segunlos mecanismos de la version1.2. Este paso es necesario puesto que Lenya 1.4 mantiene la compatibilidad con el marco de casos de uso de la versionanterior. 4.4. LA CAPA DE GESTION 13
Figura 4.7: Marco de casos de uso
El marco de casos de uso de Lenya 1.4 es un marco sencillo para la implementacion de casos de uso mediante JXTemplates y Java. Este marco permite a los usuarios imple- mentar una amplia variedad de casos de uso comunes. Sin embargo, algunos casos de uso particularmente complejos pueden tener que ser implementados mediante los mecanismos de la version1.2.
4.4.1.2. Descripciondel funcionamiento Las peticiones de casos de uso, identi cadas por el parametro lenya.usecase de la peticionHTTP, son despachadas por el sitemap LENYA WEBAPP/lenya/usecases/usecase.xmap Este sitemap trans ere el control al ujo de Cocoon LENYA WEBAPP/lenya/usecases/usecases.js El ujo usecases.js instancia el manejador del caso de uso a partir de su nombre y le trans ere el control para que lleve a cabo las operaciones necesarias. Cuando sea necesario, el caso de uso devolverael control al ujo, que a su vez invocaraal sitemap para mostrar al usuario las pantallas (vistas) apropiadas. La gura 4.7 ilustra este proceso.
4.4.1.3. Implementacionde un caso de uso La implementacionde un caso de uso consta de unos pasos bien de nidos. 14 CAPITULO 4. APACHE LENYA 1.4: ARQUITECTURA
Elecciondel nombre El primer caso es elegir un nombre para identi car el caso de uso, por ejem- plo: editHeadline. Los casos de uso pueden agruparse utilizando '.' como delimitador (Ej: edit.Headline).
A~nadirla entrada en el menuCMS Este paso soloes necesario si se desea poder invocar el caso de uso desde la ba- rra de menusde Lenya. Lo que ha que hacer es a~nadirla siguiente entrada al chero PUB HOME/con g/menus/generic.xsp:
Implementar la vista La vista de un caso de uso es opcional. Si este paso se omite, no se presentaranin- guna pantalla al usuario. Los casos de uso pueden implementar tres tipos de vista: JXTemplate: Este tipo de vista muestra una unicapantalla al usuario y permite interaccion con este. CForms: Este tipo de vista permite presentar al usuario un formulario o una sucesion de los mismos, en funcion de las reacciones del usuario. Otras: Tambiense puede mostrar una pantalla estaticacon la que el usuario no puede interaccionar. Por ejemplo podramostrarse el contenido de un chero pdf o una imagen. La vista tiene que ser declarada en el chero de con guraciondel caso de uso. El listado 4.2 es un ejemplo de este tipo de cheros. listado 4.2 Declaraciondel manejador del caso de uso y su vista asociada (opcional).
El elemento
Implementar el manejador del caso de uso 1. Elegir un nombre para la clase de Java, por ejemplo:
org.myproject.lenya.usecases.EditHeadline
2. La clase de Java debe implementar la interfaz org.apache.lenya.cms.usecase.Usecase. Para simpli car el desarrollo, se pueden extender las siguientes clases:
org.apache.lenya.cms.usecase.AbstractUsecase org.apache.lenya.cms.usecase.DocumentUsecase (Solopara casos de uso invocados sobre documentos). org.apache.lenya.cms.usecase.SiteUsecase
Estas clases implementan funcionalidades espec casdel areaen la que van a utilizarse (Ej: Area site).
3. A~nadirla declaraciondel manejador del caso de uso a un chero XPatch. Por ejemplo:
PUB HOME/con g/cocoon-xconf/usecase-editHeadline.xconf
El contrato entre el ujo y el manejador del caso de uso Como ya hemos comentado, el manejador del caso de uso debe implementar la interfaz org.apache.lenya.cms.usecase.Usecase. Los metodos de nidos en esta interfaz son invocados desde el ujo para llevar a cabo las operaciones del caso de uso. Estudiemos brevemente algunos de los metodos mas importantes.
setSourceURL(String sourceUrl), setName(String): Inicializar el manejador.
getParameterAsString(name): Permite al manejador recuperar los parametrosde la peticionHTTP.
checkPreconditions(): Este metodo se ejecuta antes de que el caso de uso comience (antes de que se muestre la primera pantalla al usuario). Permite comprobar si se cumplen condiciones previas necesarias para la ejecuciondel caso de uso. 16 CAPITULO 4. APACHE LENYA 1.4: ARQUITECTURA
lockInvolvedObjects(): Bloquea todos los objetos que podrancambiar durante la eje- cuciondel caso de uso.
Los metodos siguientes se invocan en un bucle para lograr la interaccioncon el usuario. El bucle naliza cuando se envael parametro submit.
getView(): Solicita la siguiente vista a mostrar. La vista puede ser nula si no hay que presentar pantalla al usuario.
advance(): Este metodo se invoca para avanzar en el caso de uso despuesde la inte- raccioncon el usuario. A diferencia de execute(), este metodo no se invoca cuando se presiona el boton submit, sino al pulsar cualquier otro botondel formulario.
Cuando el formulario es enviado pulsando submit, se invocan los siguientes meto- dos:
checkExecutionConditions(): Este metodo es llamado antes de que el caso de uso ejecute la accionpara la que ha sido dise~nado.Un ejemplo de uso de este metodo serala validacionde los datos introducidos en el formulario.
execute(): Este metodo ejecuta el ultimo paso del caso de uso. Por ejemplo, almacenar los datos introducidos en el formulario en alguntipo de chero.
cancel(): Este metodo se invoca cuando no se cumplen las condiciones necesarias para continuar con la ejecuciondel caso de uso. La transaccionque estaba teniendo lugar se anula.
Es importante se~nalar que en los casos de uso que no presentan pantalla al usua- rio el metodo checkExecutionConditions() no es invocado ya que seraredundante invocar checkPreconditions() y a continuacion checkExecutionConditions().
4.4.2. Control de acceso El control de acceso debe ocuparse de las tareas de autenticaciony autorizacion. Veamos la diferencia entre cada una de ellas:
Autenticacion: Es el acto de con rmacionde la identidad de un usuario (el usuario es quien dice ser).
Autorizacion: Es el acto de comprobacionde que un usuario tiene los permisos apropiados para acceder a un recurso o llevar a cabo una determinada opcion.
La implementacionde los mecanismos de control de acceso en Lenya es bastante compleja, por lo que su descripcionexhaustiva escapa a los objetivos de este proyecto. Nos conformaremos con una descripcionque cubra los aspectos fundamentales de la misma. 4.4. LA CAPA DE GESTION 17
4.4.2.1. De niciones basicas Para comprender el funcionamiento del control de acceso, es preciso familiarizarse primero con la terminologaempleada.
Rol: Los roles son la conexionentre el control de acceso y las funcionalidades CMS. En el lado de control de acceso, se asignan Roles a Usuarios y Rangos de IP y Grupos a ciertos espacios de URLS. En el lado CMS, se de nen queRoles son necesarios para la ejecucionde ciertos casos de uso y transiciones del ujo de trabajo. Si el cliente tiene cierto Rol, signi ca que tiene permiso para realizar ciertas cosas.
Identi cable: Un Identi cable es una caracterstica del cliente que puede ser iden- ti cada. Todos los Identi cables son Acreditables. En la actualidad, Lenya de ne los Identi cables Usuario, Maquinay World. Este ultimose le asigna a todos los clientes que intentan acceder al sistema.
Identidad: La Identidad de un cliente es el conjunto de todos los Identi cables que tienen acceso al sistema en la sesionactual. La Identidad siempre contiene los Identi- cables Maquinay World. Si el cliente ha ingresado en el sistema, el Usuario tambien formaraparte de la Identidad.
Acreditable: Un Acreditable puede ser acreditado mediante su Rol por una Poltica. Los acreditables de nidos en Lenya son: Usuario, Rango de IPs, Grupos, World.
Credencial: Un Credencial asigna un conjunto de Roles a un Acreditable.
Poltica: Una Polticaasocia un conjunto de Credenciales con una cierta URL. Tiene la responsabilidad de devolver todos los Roles de un Acreditable para una URL. Por ejemplo, si la Polticapara la URL /tv/noticias contiene los Credenciales:
editores noticias: editor, revisor Juan: admin 192.168.0.72: visitante
y el usuario Juan pertenece al grupo editores noticias y ha ingresado en el sistema desde la maquina192.168.0.72, la Poltica devolveralos Roles editor, revisor y visitante para el Acreditable Juan.
Las polticasde acceso se de nen en cheros XML con extensionacml. Para una publicacionestos cheros se ubican en PUB HOME/con g. Habra cheros de polticas de acceso para el ujo de trabajo, para los casos de uso de nidos por la publicaciony para cada una de las areasde trabajo. La de nicion de una polticade acceso tiene el siguiente aspecto: En este ejemplo vemos la asignacion de Roles a los Acreditables Usuario, Grupo, Rango de IPs y World. 18 CAPITULO 4. APACHE LENYA 1.4: ARQUITECTURA listado 4.3 Ejemplo de de nicionde polticas de acceso
4.4.2.2. Componentes
Los mecanismos de control de acceso son implementados por una serie de compo- nentes que interactuanentre si para determinar si el cliente puede ingresar en el sistema o estaautorizado para invocar cierta operacion.A continuaciondescribiremos los componen- tes mas importantes de la capa de control de acceso.
Controladores de Acceso
El Controlador de Acceso (AccessController) tiene la responsabilidad de autenticar clientes y autorizar peticiones. El Controlador de Acceso masimportante es el DefaultAc- cessController, que combina un Autenticador, un conjunto de Autorizadores y un Gestor de Polticas para llevar a cabo estas tareas.
Autenticadores
Los Autenticadores se utilizan para identi car a los clientes. Son los encargados de inicializar la Identidad del cliente si la autenticaciontiene exito.La Identidad se a~nade a la sesion.El Autenticador masimportante es el UserAuthenticator, que autentica usuarios a partir del nombre de usuario y contrase~nasuministrados en la peticion. 4.4. LA CAPA DE GESTION 19
Autorizadores Los Autorizadores comprueban si una Identidad estaautorizada para invocar cierta peticion.Hay varios tipos de Autorizadores. PolicyAuthorizer: Autoriza la operacionsi la Identidad posee al menos uno de los Roles asociados a la URL de la peticionen la Polticacorrespondiente. UsecaseAuthorizer: Utilizando el nombre del caso de uso (contenido en el parametro lenya.usecase de la peticion)comprueba si la Identidad tiene los Roles de nidos para ese caso de uso en el chero de polticasde casos de uso ubicado en PUB HOME/con g/ac/usecase-policies.xml. Work owAuthorizer: Este autorizador es el responsable de proteger las transiciones del ujo de trabajo. Para ello determina el estado actual de la instancia de ujo de trabajo y comprueba si el evento puede ser invocado por algunos de los Roles de la Identidad.
4.4.2.3. Los mecanismos de autorizaciony autenticacion Cuando un usuario intenta acceder a Lenya en el modo de edicion,su peticiones procesada por el fragmento del sitemap razrecogido en el listado 4.4. Todas las peticiones realizadas al sistema pasan por este conducto antes de ser procesadas. Por lo tanto, es en este punto donde se comprueba si un usuario estaautorizado para invocar un caso de uso o un evento del ujo de trabajo. Veamos comose lleva a cabo este proceso. En primer lugar, se comprueba si el usuario estaautorizado para realizar esa peti- cion.Esta comprobaciones desencadenada por la accion DelegatingAuthorizerAction (recor- demos que las acciones eran uno de los componentes de los sitemaps). Esta accioninstancia al Controlador de Acceso DefaultAccessController, que delegarael proceso de autorizacion a sus Autorizadores. Solocuando todos los Autorizadores devuelven true se permitirala ejecucionde la peticion.Si no se autoriza la peticion,se mostrarauna pantalla indicando el motivo del rechazo. Si el usuario no ha ingresado en el sistema, el proceso de autorizaciondetermi- naraque el cliente no estaautorizado para acceder a ninguna URL dentro del mismo. En ese caso, en lugar de mostrar una pantalla de error, se ejecutarala redireccionque vemos en el extracto del sitemap. Esta redireccionprovoca que se ejecute el caso de uso ac.login. Este caso de uso se limita a instanciar el Controlador de Acceso apropiado y devolver el resultado que estele proporcione (admision/rechazo). El Controlador de Acceso se encargaraa su vez de instanciar el autenticador UserAuthenticator, que comprobarasi existe un usuario para el nombre de usuario y la contrase~nasuministrados en la peticion.Si es as,se a~nadirael Acreditable Usuario con el nombre del usuario a la Identidad del cliente y se permitirael acceso.
4.4.3. Flujo de trabajo El esquema de ujo de trabajo que trae la publicacionpor defecto de Lenya se puede ver en la gura 4.8 20 CAPITULO 4. APACHE LENYA 1.4: ARQUITECTURA
listado 4.4 Comienzo del proceso de autenticacion
[...]
[...]
[...]
4.4. LA CAPA DE GESTION 21
Figura 4.8: Esquema de ujo de trabajo
4.4.3.1. La de niciondel ujo de trabajo
Un chero de de nicionde ujo de trabajo en Lenya tiene el siguiente aspecto: La URI correspondiente al espacio de nombres del esquema de ujo de trabajo es
http://apache.org/cocoon/lenya/work ow/1.0
Estados
Todos los estados que se usen en el esquema de ujo de trabajo tienen que ser declarados mediante los elementos
Variables
Todas las variables usadas son declaradas mediante los elementos
Transiciones
Una transicionse declara mediante el uso de los elementos
listado 4.5 De niciondel esquema de ujo de trabajo
[...] 4.4. LA CAPA DE GESTION 23
Asignaciones de variables Una asignacionde un valor a una variable vendradada por una sentencia de la forma
BooleanVariableCondition La clase BooleanVariableCondition del paquete org.apache.lenya.work ow.impl re- quiere una expresionde la forma fvariablenameg= fvalueg, donde fvariablenameg es el nom- bre de la variable que se declaroen el esquema de ujo de trabajo y fvalueg tiene el valor true o false.
RoleCondition La clase org.apache.lenya.cms.work ow.RoleCondition requiere una lista de identi - cadores de roles separada por comas: froleid1g,froleid2g,... La condicionse completa cuando la identidad actual tiene alguno de esos roles para la URL solicitada.
4.4.3.2. Personalizaciondel ujo de trabajo Si se desea crear un esquema de ujo de trabajo personalizado, habraque crear un chero denominado work ow.xml que contenga la de niciondel esquema deseado y ubicarlo en el directorio LENYA PUB/con g/work ow/.
4.4.4. Noti caciones Para habilitar las noti caciones por correo electronico,hay que descargarse las bibliotecas JavaMail y JavaBeans Activation Framework desde el portal de JavaMail y ubicarlas en LENYA WEBAPP/WEB-INF/lib. 24 CAPITULO 4. APACHE LENYA 1.4: ARQUITECTURA
La implementacionactual, DefaultNoti er, enva un correo electronicoa cada re- ceptor traducido segunsu atributo locale. Futuras implementaciones incluiranuna lista de mensajes que seragestionada por el nucleode Lenya y se presentaraal usuario despuesdel ingreso en el sistema.
4.5. La capa de repositorio
La version1.4 de Lenya proporciona la implementacionde un repositorio basico, que probablemente serareemplazada por un repositorio JCR en futuras versiones. Esta capa es la responsable de gestionar el acceso al repositorio y llevar a cabo el control de versiones.
4.5.1. Acceso al repositorio El repositorio es accedido por medio de URLs utilizando el protocolo lenya://. Este protocolo es un protocolo de Cocoon creado espec camente para Lenya. La razdel espacio de URLs es el directorio de contexto del servlet, lo que signi ca que la URL len- ya://lenya/pubs/mypub/content/authoring/index.xml accede a recursos de contenido dentro de una publicacion. Cuando se resuelve una URL de la forma lenya://, se accede al repositorio emplean- do el protocolo context:// del nucleode Cocoon. La implementaciondel acceso al repositorio obliga a que los nodos del repositorio tengan que ser accedidos mediante transacciones. En Lenya 1.4 se utilizan dos mecanismos para la implementacionde las transacciones. Vamos a estudiarlos.
4.5.1.1. Control optimista de concurrencia Imaginemos el siguiente escenario: 1. Bego~naabre el documento A y realiza algunos cambios. 2. Alvaro decide hacer algunos cambios tambieny los guarda inmediatamente. 3. A continuacion,Bego~napulsa el boton Guardar. Si no se toman precauciones especiales, los cambios realizados por Alvaro se per- deran.Los mecanismos de bloqueo se utilizan para determinar si un elemento persistente (en este caso, un documento) ha sido modi cado desde que fue accedido por primera vez durante la transaccion. Para utilizar el elemento, esteha tenido que ser cargado como un objeto. Antes del primer acceso en lectura, se coloca un cerrojo sobre el mismo. Este cerrojo almacena el numerode versionactual. Cuando Alvaro guarde los cambios realizados en el documento A, la transaccionde Bego~napodracomparar el numerode versiondel documento A con el numerode version que guarda el cerrojo mediante el metodo Transactionable.hasChanged(). De esta forma, podradeterminarse si A fue modi cado durante la transacciony mostrar un mensaje de advertencia. Esta polticase conoce como control optimista de concurrencia, por que las transacciones se basan en la esperanza de que no ocurran con ictos de acceso. 4.6. ARQUITECTURA FISICA 25
4.5.1.2. Check-In y Check-Out Para algunas transacciones complejas el control optimista de concurrencia puede no ser un mecanismo valido,ya que sera demasiado costoso perder todos los cambios realizados si el nodo involucrado fuese modi cado por otro usuario. Para estos casos se emplean los mecanismos de Check-In y Check-Out, que no permiten que un nodo del repositorio se modi cado por masde un usuario de forma con- currente. Con este mecanismo, el nodo se marca como checked out y no se admitiraque se coloquen cerrojos sobre el mismo. Esto signi ca que no podracomenzar ninguna otra transaccionque involucre a este nodo, ya que esteestaprotegido.
4.5.2. Control de versiones El Controlador de versiones (Revision Controller) se encarga de gestionar los pro- cesos de Check-In y Check-Out, las copias de seguridad de versiones y el mecanismo de Rollback para anular las transacciones. Cada vez que se realiza un Check-In sobre un elemento del repositorio, se crea una nueva versiondel mismo y se guarda una copia de la versionanterior. El estado de un documento en cuanto a los procesos de Check-In y Check-Out (hora, identidad del usuario, estado del documento(checked-in/checked-out)) se guardan en un archivo XML con su propio espacio de nombres: el chero RCML.
4.6. Arquitectura fsica
4.6.1. Estructura de directorios de una publicacion Para detallar la estructura de directorios de una publicacionnos basaremos en la publicacionpor defecto, que incluye todas las posibilidades existentes. Suponiendo que Lenya se ha desplegado dentro del contexto de Tomcat como una aplicacionnormal, la publicacionpor defecto se encuentra en
TOMCAT HOME/webapps/lenya/lenya/pubs/default
Si por el contrario se ha desplegado dentro del contexto razde Tomcat, se en- cuentra en
TOMCAT HOME/webapps/ROOT/lenya/pubs/default
La estructura de archivos de Lenya para una publicacionse muestra en 4.9. De esta estructura se desprende que los mecanismos utilizados en el dise~no para conseguir la separacionentre presentacion,contenido y logicano soloafectan al funciona- miento del gestor, sino tambienal modo en que estese estructura. Expliquemos el propositode cada uno de los directorios y cheros que conforman la estructura de una publicacionen Lenya.
con g: Archivos de con guracion. 26 CAPITULO 4. APACHE LENYA 1.4: ARQUITECTURA
Figura 4.9: Estructura de directorios de una publicacion
content: Contenidos de la publicacion,almacenados en cheros XML.
java: Clases de Java espec casde la publicacion.
lenya: Archivos que sobreecriben el nucleo.
modules: Modulosespec cosde la publicacion.
resources: Recursos estaticos(imagenes,css, etc).
test: Tests web.
xslt: Hojas de estilo XSLT
menus.xmap: Sitemap para la generacionde menusen el modo Edicion.
publication-tests.xml: De nicionde tests web.
publication.xml: Datos de la publicacionque se muestran en la paginade ingreso.
sitemap.xmap: Sitemap de la publicacion.
Detallemos un poco el contenido de los directorios content y con g. content Apache Lenya utiliza como repositorio en las versiones 1.2.x el propio sistema de archivos, por lo que en este directorio es donde se encontraraalmacenada toda la informacion 4.6. ARQUITECTURA FISICA 27 correspondiente a la ediciony publicacionde contenidos a~nadidapor editores. En la version 1.4.x aunse mantiene este sistema, aunque se ha comenzado la integracionde JCR para tener un mecanismo de control de versiones masavanzado. Examinemos cada una de las subcarpetas: archive: Almacena todos los documentos que los editores han decidido almacenar para su posterior uso. authoring: Almacena todos los archivos que se encuentran en el estado de ediciono de revision. live: Almacena todos los archivos que se encuentran publicados y disponibles para ser visitados vaweb. trash: Almacena todos los archivos que han sido eliminados de la web. Permite la restauracionde un archivo eliminado work ow: Guarda la historia del ujo de trabajo de todos los documentos que se han modi cado tanto en el areade edicioncomo en el archivo como en la papelera. rcml y rcbak: Directorios para el almacenamiento del historicode control de revisiones y de las copias del control. Aques donde se guardan los documentos que han sido sustituidos por versiones masnuevas. Hay que se~nalartambienque las carpetas archive, authoring, live y trash contienen un archivo llamado sitetree.xml. Este archivo es meramente descriptivo. Se limita a esque- matizar la distribucionde los archivos dentro de esa carpeta, re ejando de forma el la estructura de la misma en forma de arbol, de ahsu nombre. Por otra parte, cada uno de los archivos
4.6.2. Estructura de directorios de un modulo La estructura de directorios del moduloxhtml se muestra en la gura 4.10. Esta estructura se corresponde con la de un modulogenericodespuesde haberse desplegado en Lenya. Todas las carpetas y cheros mostrados a excepcionde module.xml son opcionales y dependen de la naturaleza del modulo.Estudiemos brevemente la funcionde cada una de ellas. 28 CAPITULO 4. APACHE LENYA 1.4: ARQUITECTURA
Figura 4.10: Estructura de directorios de un modulo
con g: Ficheros de con guracion.Se pueden con gurar las entradas en los menus a~nadidaspor el modulo,el ujo de trabajo asociado a la funcionalidad implementada por este,etc.
resources: Recursos estaticos(imagenes,css, etc).
samples: Si el moduloimplementa un tipo de recurso, esta carpeta contendradocu- mentos de ejemplo de dicho tipo de recurso.
xslt: Hojas de estilo XSLT
menus.xmap: Sitemap para la generacionde menus.
sitemap.xmap: Sitemap del modulo.Controla la respuesta que ha de dar el modulo a la peticion.En el caso de la implementacionde un tipo de recurso, controlarala renderizacionde los documentos que pertenezcan a dicho tipo de recurso.
module.xml: Descriptor del modulo.Se explica en 4.6.2.2.
4.6.2.1. Adicionde un nuevo modulo Para a~nadirun nuevo moduloa la instalacionde Lenya hay que declararlo en el chero LENYA HOME/local.build.properties del siguiente modo:
modules.root.dirs=/home/user/modules/mymodule
Cuando el moduloes desplegado, se llevan a cabo los siguientes pasos:
Se valida el descriptor del modulo, module.xml.
Los cheros del modulose copian en context://lenya/modules. 4.6. ARQUITECTURA FISICA 29
Los cheros fuente de Java son compilados y las bibliotecas son instaladas.
Se a~nadenlas entradas especi cadas a cocoon.xconf.
4.6.2.2. El chero module.xml Cada modulodebe ser descrito en un chero denominado module.xml, que ha de ubicarse en el directorio razdel modulo. Un descriptor de modulotiene esta aspecto: listado 4.6 Ejemplo de descriptor de modulos
Si el moduloutiliza codigode otros modulos,hay que a~nadiruna entrada
4.6.3. Estructura de directorios de la aplicacion En este apartado mostraremos la estructura de directorios de Lenya una vez des- plegado en el contexto del contenedor de servlets, especi cando la funcionde cada uno de los directorios que la componen. En la gura 4.11, observamos el esquema de la aplicacion una vez desplegado en el contexto razde Tomcat. En los nodos identi cados del (1) al (3) tenemos la estructura basicade los directo- rios de la aplicacion.El nodo (1) sirve para albergar los contenidos de las publicaciones tras la migracional repositorio JCR. El nodo (2) identi ca la carpeta que almacena todas las funcionalidades espec casde Lenya, la con guracionde sus publicaciones y el contenido de las mismas. El sitemap razde la aplicacionmonta los que se encuentran en este directorio para realizar el procesamiento de la URL. El nodo etiquetado como (3), WEB-INF, contiene todos los elementos necesarios para la con guraciony el funcionamiento de la aplicacionweb. En else encuentra el archivo web.xml en el que se de nen los valores necesarios para que funcione el servlet de Cocoon y los archivos xconf necesarios para la con guraciondel sistema de logging (log4j.xconf) y de la aplicacion(cocoon.xconf). Dentro de este nodo tendremos las clases compiladas y las bibliotecas necesarias para el funcionamiento de Lenya bajo los directorios classes y lib respectivamente. En la carpeta logs se almacenaranlos resultados de los loggers de nidos para la aplicacion. La carpeta en la que realmente se hallan los archivos de con guraciony los recursos del gestor de contenidos estaetiquetada con el numero(1) como ya hemos comentado. En 30 CAPITULO 4. APACHE LENYA 1.4: ARQUITECTURA
Figura 4.11: Estructura de directorios de la aplicacion 4.6. ARQUITECTURA FISICA 31 la razde la misma se hallan todos los sitemaps necesarios para el funcionamiento de la aplicacion.Sobre estospodemos ver una explicacionmasdetallada en el apendice En la carpeta bin identi cada con la etiqueta (4), encontramos utilidades para la replicadel portal en un servidor remoto y los scripts necesarios para el indexado de la publicacionnecesario para el funcionamiento del motor de busqueda. En la carpeta con g, identi cada con la etiqueta (5), podemos encontrar los archi- vos xconf de con guracion de los servicios de control de revisiony plani cacion. En la carpeta content, identi cada con la etiqueta (6), podemos encontrar los archivos de contenido de las paginasde inicio y bienvenida de Lenya, en la que se nos muestran una lista de las publicaciones que se hallan en esta instancia de Lenya. Ademas, contiene los generadores xsp necesarios para la creacionde las paginasde administracion, edicion,los menus,etc. Estos generadores son los tomados por defecto cuando no se han de nido componentes espec cospara la publicacion. La carpeta modules, identi cada con la etiqueta (7), contiene los distintos modulos que conforman la aplicacion.Podemos agruparlos por funcionalidades:
Control de acceso y administracionde usuarios: ac-impl,administration, ldap.
Edicion: kupu, fckeditor, bxe, xopus, editors, neutron, webdav.
Repositorio: jackrabbit, jcr, repository, sourcerepository, migration.
Documentos y gestionde activos: usecasedocument, resource.
Tipos de recurso: xhtml, cforms, opendocument, svg, links, contactform.
Motor de busquedas: lucene.
Noti caciones: noti cation.
Plantillas de publicacion: templating-impl.
Marco de casos de uso: usecase, usecase-impl.
Control de ujo de trabajo: work ow-impl.
Cache y uso de memoria: cache, janitor
Gestionde la estructura del portal: sitemanagement.
En la carpeta pubs, identi cada con la etiqueta (8), podemos encontrar todas las publicaciones que se hallan dentro de la instancia de Lenya. En esta carpeta se almacena el contenido de las publicaciones y se pueden encontrar tambientodos los componentes espec cosde la publicacion,que se utilizaran en lugar de los del nucleo. En la carpeta resources, identi cada con la etiqueta (9), podemos encontrar todos los recursos comunes a Lenya: las hojas de estilo para la interfaz CMS, las imagenese iconos de la misma, los archivos de JavaScript necesarios, etc. Tambiense pueden encontrar en esta carpeta los catalogos necesarios para la internacionalizacion,almacenados en el 32 CAPITULO 4. APACHE LENYA 1.4: ARQUITECTURA directorio i18n. En la carpeta usecases, identi cada con la etiqueta (10), podemos encontrar el sitemap y el ujo que se encargan del nuevo marco de casos de uso, usecase.xmap y usecases.js, respectivamente. En la carpeta xslt, identi cada con la etiqueta (11), podemos encontrar todas las hojas de estilo XSLT que se aplicaranpara la generaciondel contenido, de los menusy de la estructura de la aplicacionen el caso de que no se hayan de nido hojas personalizadas en la publicacion.