FW2-ArqWebApps

FW2 - Arquitectura Aplicaciones Web
FRAMEWORK 2
-
ARQUITECTURA
APLICACIONES WEB
Versión 1.1
Septiembre 2008
Subdirección General de Desarrollo, Tecnología e Infraestructuras. Página: 1

Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales
Área de Integración y Arquitectura de Aplicaciones.
CONTROL DE CAMBIOS
Fecha Versión Cambios

21/05/2008 1.0 Primera versión
11/09/2008 1.1 Se eliminan las referencias a Remote Scripting y se
sustituye por la librería DWR

INDICE
1 INTRODUCCION.................................................................................................... 4
2 GESTION DE USUARIOS...................................................................................... 5
3 CARACTERISTICAS DE LAS APLICACIONES ................................................. 5
3.1 CONFIGURACION ......................................................................................... 5
3.2 ARQUITECTURA DE LAS APLICACIONES .............................................. 6
3.2.1 Controlador............................................................................................... 8
3.2.2 Modelo.................................................................................................... 11
3.2.3 Acciones ................................................................................................. 14
3.2.4 Vista........................................................................................................ 16
3.3 ESTRUCTURA DE DIRECTORIOS ............................................................ 17
3.4 PAQUETES JAVA ........................................................................................ 17
3.5 GESTION DE EXCEPCIONES..................................................................... 19
4 PORTAL DE LA APLICACION........................................................................... 20
4.1 Hojas de estilo ................................................................................................ 22
4.2 Librerías de etiquetas del portal: regiones...................................................... 22
4.3 Menú de aplicación......................................................................................... 23
5 ANEXO 1: Variables del fichero de configuración................................................ 26

1 INTRODUCCION
La presente guía presenta el framework para el desarrollo de las aplicaciones de entorno

web que se desarrollen para la Comunidad de Madrid con el framework 2. Por tanto, estos
desarrollos deberán seguir además la normativa general para el Desarrollo de las
aplicaciones con el framework 2.
Este framework es propietario de ICM y se encuentra implementado en la librería

Sistemas2.x.
REQUISITOS
Para facilitar el desarrollo de aplicaciones web ICM proporciona una serie de plantillas.
Estas plantillas son distintas dependiendo del tipo de acceso a la aplicación.
Podemos tener varios tipos de aplicaciones dependiendo del tipo de acceso:
- Públicas: Todo el mundo tiene acceso a la aplicación.

- Privadas: Para acceder a la aplicación es necesario disponer de un usuario
autorizado. Dentro de estas aplicaciones diferenciamos:
o Aplicaciones para intranet: El usuario es de la Comunidad de Madrid.
o Aplicaciones para internet: El usuario no es de la Comunidad de
Madrid pero es un usuario controlado y gestionado por la Comunidad
de Madrid.

2 GESTION DE USUARIOS
En ICM existe una gestión centralizada de los usuarios. Las aplicaciones no podrán
implementar su propia gestión de usuarios, tendrán que utilizar la de ICM.
Para la gestión de usuarios se dispone de dos modelos de datos:
• USU: Para aplicaciones de Intranet.

• USUI: Para aplicaciones de Internet.
Dentro de estos modelos de datos se encuentran las aplicaciones, los usuarios, los grupos
(perfiles) y las acciones.
Para generar este modelo de datos en las instalaciones de los proveedores es necesario
abrir el modelo Erwin correspondiente y hacer Forward Engineer/Schema generation.
Los modelos de datos se encuentran en la web de soja.
3 CARACTERISTICAS DE LAS APLICACIONES
3.1 CONFIGURACION
REQUISITOS
• El fichero de configuración deberá estar en el directorio WEB-INF/conf.

3.2 ARQUITECTURA DE LAS APLICACIONES
Las aplicaciones deberán desarrollarse basando su capa de presentación en el

Framework propietario de ICM. Este framework esta basado en el MVC Modelo 2.
• Model-View-Controller: El modelo vista controlador (MVC) permite independizar la

REQUISITOS
presentación, de la lógica de navegación y de los datos de la aplicaciones.
• Front-Controller: El procesamiento de la peticiones es gestionado de manera

centralizada, unificando y facilitando el desarrollo de políticas de seguridad,
trazabilidad entre otras.
• Composite View: Permite gestionar la capa de presentación como la composición

de múltiples vistas (encabezado, pie de página, menús, contenido, etc).
El siguiente gráfico muestra las distintas capas a implementar en las aplicaciones:

Modelo contiene toda la lógica de la aplicación y accede a la base de datos. Debe ser
independiente de la vista y del controlador.
Vista proporciona la presentación del Modelo. La vista puede acceder a los métodos get
de los JavaBean para obtener información pero no puede acceder a los métodos set para
actualizar el Modelo sino que las actualizaciones se harán a través del controlador.
Controlador es quien reacciona frente a las peticiones de los usuarios y es el encargado

de crear las distintas Acciones para ejecutar la petición correspondiente.
Acciones es el conjunto de clases que actúan como intermediarias entre el Controlador y

el Modelo. Reciben información de la Base de Datos a través del Modelo y la
proporcionan a la vista a través de Java Beans.
Las peticiones al Controlador van a ser de la forma Opcion.icm.

Ejemplo: http://icmweb01.icm.es/empleados/AltaEmpleado.icm
El siguiente diagrama muestra los distintos elementos que son invocados en cuanto llega
una petición al Controlador.
• Opcion.icm: Nombre de la opción. Ejemplo:AltaEmpleado.icm

• OpcionA.java: Clase de Acción correspondiente. Ejemplo: AltaEmpleado.java
• TablaDAO.java: Clase del Modelo que accede a la Base de Datos y rellena objetos de
clases JavaBean. Ejemplo: EmpleadosDAO.java
• opcionA.jsp: Página resultado de la opción. Ejemplo: confirmacion_alta.jsp
• Bean1 y Bean2: Objetos con información para ser visualizada por las páginas JSP.
Ejemplo: EmpleadoBean.java

3.2.1 Controlador
El Controlador es un Servlet, único por aplicación que recibe todas las peticiones de
los clientes de la aplicación y actúa como un dispatcher enviando la petición a la clase
correspondiente.
Tipos de controladores según el tipo de acceso a la aplicación (todos estos

controladores se encuentran en sistemas.framework.controlador):
• ControladorPublico: Cualquiera tiene acceso a la aplicación.
• ControladorPublico + Certificado digital (SSL): Para acceder a la aplicación es

necesario disponer de un certificado digital, aunque cualquiera que lo tenga
puede acceder.
• ControladorPrivadoIntranet: Este tipo de controlador se usa en aplicaciones

para Intranet donde el usuario es de la Comunidad de Madrid y se identifica
mediante login/password. La información de los usuarios que tienen acceso a la
aplicación se encuentra dentro de un directorio LDAP y en la base de datos de
usuarios USUG.
• ControladorPrivadoInternet: Este tipo de controlador se usa en aplicaciones

para Internet donde el usuario es externo a la Comunidad de Madrid pero no es
un ciudadano. En principio se accede solicitando un certificado digital y en caso
de que no disponga de él nos mostrará una pantalla de login/password. La
información de los usuarios que tienen acceso a la aplicación se encuentra dentro
de la base de datos de usuarios USUI.

Por cada petición al Controlador desde el navegador se van a realizar las siguientes
operaciones.
• Obtener información del usuario

• Comprobar el acceso del usuario a la aplicación
• Obtener una conexión para el acceso a la Base de Datos
• Indicar que las operaciones de BD son en una transacción (autocommit a false)
• Cargar y crear una instancia de la clase suministrada en el parámetro opcion
• Procesar dicha clase
• Realizar un commit o un rollback de la transacción dependiendo de si el proceso
anterior ha ido bien o no.
• Capturar los posibles errores del proceso y mostrarlos en el fichero de trazas y en
el navegador.
• Liberar la conexión con la Base de Datos
La clase Controlador es la única que debe realizar el commit o el rollback.
El hacer commit o rollback está prohibido en cualquier otra parte del código. Tampoco se
puede hacer commit o rollback en los procedimientos almacenados que son invocados
desde java.
La clase Controlador de la aplicación se incluirá en el paquete aplicacion.controlador.
No se pueden crear nuevas clases Controlador.

Ejemplo de un controlador:
package empleados.controlador; Controlador
import empleados.*;
public class ControladorEmpleados

extends sistemas.framework.controlador.ControladorPrivadoIntranet
{
public ControladorEmpleados() {
ControladorPrivadoIntranet
}
public String getPaquete() {

return "empleados.acciones";
}
public String getFicheroConfiguracion() {

return "empleados.conf";
} ControladorEmpleados
public String getDirectorioPlantillas(String userAgent){

return "/WEB-INF/jsp/";
}
}

3.2.2 Modelo
El Modelo comprende el conjunto de clases Java que implementan la lógica de negocio

de la aplicación.
Las aplicaciones deberán implementar la lógica de negocio atendiendo a los siguientes
requisitos:
• La lógica se implementará en clases Java normales, comúnmente conocidas

como POJOs (Plain Old Java Object), de lo cual se deduce las siguientes normas:
o Se prohíbe el uso de EJBs (Enterprise Java Beans).
o Las clases serán independientes de cualquier framework usado en la

capa de presentación, es decir, deben ser clases independientes de las
acciones de nuestro framework. De forma que si se sustituyera el
framework de presentación no se viera afectada la parte de lógica de
REQUISITOS
negocio.
• La persistencia de los datos almacenados en la base de datos se realizará

siguiendo el patrón DAO (Data Access Object). El patrón DAO permite encapsular
y ocultar el acceso a base de datos a la capa de lógica, consiguiéndose
independizar al máximo el desarrollo de las aplicaciones de la implementación
concreta de la persistencia.
• Todos los accesos a base de datos realizados por las aplicaciones se deberán
encapsular en clases DAO.
• Las clases DAO implementarán el acceso a base de datos mediante sentencias

SQL directamente en el código Java. No se utilizará ningún motor de persistencia
ni ORM. Estas sentencias SQL se ejecutarán mediante PreparedStatement.
• El código de acceso a Base de datos solo puede estar localizado en las clases
DAO.
• Todas las clases del modelo estarán bajo el paquete aplicación.modelo y dentro
de este paquete se podrá disponer de una estructura de paquetes.

El acceso a Base de Datos se va a realizar a través de JDBC. Esto implica que

necesitamos tener los drivers de JDBC de la Base de Datos que estemos utilizando. Los
drivers en realidad son una librería de clases que en el caso de ORACLE es ojdbc14.jar.
Esta librería sólo se debe utilizar desde JBuilder o Eclipse, en el directorio lib de la
aplicación a la hora de compilar las clases java. A la hora de desplegar la aplicación la
librería de oracle no debe aparecer en el directorio WEB-INF/lib ya que el propio servidor
de aplicaciones ya la incorpora.
La conexión con la base de datos le llegará al modelo desde la capa de las acciones y el
modelo se la pasará a las clases DAO para que la utilicen.
Desde el Modelo nunca se van a crear conexiones ni se va a hacer commit ni
rollback.
El Modelo tiene que ser independiente de la forma en la que se van a presentar los
datos esto quiere decir que nunca va a acceder al request ni al response.
Para recibir o pasar información de esta capa a otras lo va a hacer mediante clases
JavaBean. Estos JavaBean no van a procesar información simplemente van a contener
propiedades y métodos para acceder a esas propiedades. Todos los JavaBean deben
heredar de ModeloBean.
A continuación se muestra un ejemplo de una clase JavaBean:
package empleadosmvc.bean;
import empleadosmvc.*;
public class EmpleadosBean extends sistemas.framework.beans.ModeloBean

{
private String codigo;

private String nombre; ModeloBean
....
public EmpleadosBean() {
}
public String getCodigo() {

return codigo;
EmpleadoBean
}
-codigo
public void setCodigo(String codigo) { -nombre
-apellido1
this.codigo = codigo;
-apellido2
}
+getCodigo()
+getNombre()
public String getNombre() { +getApellidos()
return nombre; +getEdad()
}
public void setNombre(String nombre) {

this.nombre = nombre;
}

Para el desarrollo de las clases DAO se ha creado dentro de la librería Sistemas una
clase llamada ClaseDAO que obliga a implementar los métodos de alta, baja, consulta y
modificación con un sintaxis común a todas las clases DAO. Para desarrollar las clases
DAO de la aplicación hay que heredar de esta clase e implementar los métodos
necesarios.
Los métodos que no se necesite implementar devolverán una excepción de que el método
no está implementado.
Esta excepción deberá ser “UnsupportedOperationException”, y dicha excepción deberá
tener el parámetro “Operación no disponible”. Es decir, deberá ser
UnsupportedOperationException(“Operación no disponible”).
Se recuerda que el código de acceso a base de datos deberá incluirse dentro de un
bloque try-catch.
Los cursores deberán cerrarse en la parte del finally.

3.2.3 Acciones
Para cada opción de la aplicación vamos a tener lo que vamos a llamar Acciones.
Se trata de una clase Java que se corresponde con el nombre de la opción y que
implementa el interfaz Accion. Estas acciones van a ser invocadas por el Controlador.
Para facilitar la creación de Acciones se ha creado la clase ClaseAccion. Por lo tanto

todas las clases que implementen una Accion tienen que heredar de ClaseAccion.
En la implementación tienen que sobreescribir el método procesar.
Estas acciones van a ser invocadas por el Controlador.
Cada acción realiza las siguientes operaciones:
• Accede al Modelo para obtener o almacenar información
• Prepara el JavaBean y lo almacena en el ámbito adecuado para que la

correspondiente página JSP de la Vista lo lea. (En el caso de que tenga que
hacerlo)
Los posibles ámbitos son:
• Aplicación
• Sesión
• Request
• Page
• Indica al Controlador cual es el destino del resultado de la opción. Existe un

fichero que mapea los destinos de cada opción con la correspondiente página
JSP.
Ejemplo de clase de Accion:
package empleadosmvc.acciones;
import empleadosmvc.modelo.EmpleadosDAO;
import empleadosmvc.bean.EmpleadosBean;
public class FormBajaEmpleado extends

sistemas.framework.acciones.ClaseAccion {
public static String NOMBRE_VISTA = "formulario-baja-empleado";
public FormBajaEmpleado() {
super.tieneFormulariosSensibles = true;
}

public String procesar() throws

sistemas.framework.excepciones.AccionException {
EmpleadosBean empleadosBean = new EmpleadosBean();
empleadosBean.setCodigo(request.getParameter("CODIGO"));
try {
empleadosBean =(EmpleadosBean) new
EmpleadosDAO().consulta(con, empleadosBean);
} catch (sistemas.framework.excepciones.DAOException ex) {
throw new
sistemas.framework.excepciones.AccionException(ex.getMessage());
}
request.getSession(true).setAttribute("empleadosBeanId",
empleadosBean);
return NOMBRE_VISTA;
}
}
A continuación se muestra un ejemplo de fichero vistas.conf:
formulario-modificacion-empleado = formModEmpleado.jsp
baja-empleado = confirmacionBorrado.jsp
formulario-accion-catalogo = formAccionCatalogo.jsp
formulario-alta-empleado = formAltaEmpleado.jsp
formulario-baja-empleado = formBajaEmpleado.jsp
formulario-busqueda-empleado = formBuscarEmpleado.jsp
pagina-inicio = index.jsp
listado-catalogos = listadoCatalogos.jsp
listado-empleados = listadoEmpleados.jsp
modificacion-empleado = confirmacionModificacion.jsp
menu-xml = menu_xml.jsp
calendario = calendar.jsp

3.2.4 Vista
La vista es la que se encarga de la capa de presentación de la aplicación.
La vista va a estar representada por páginas JSP que acceden a JavaBean previamente
generados en el Modelo.
• Las aplicaciones utilizarán una librería propia de ICM llamada regiones para
definir las estructura principal de las aplicaciones (encabezado, menú, pie de
página, etc) así como cualquier otra estructura que sea reutilizada en diferentes
páginas.
• Cualquier validación que realice la aplicación en el navegador (cliente) deberá

replicarse de lado servidor para garantizar la robustez de la misma.
REQUISITOS
• Las funciones Javascript que sean propias de la aplicación y comunes a varias

páginas deberán ser extraídas a un único fichero Javascript (fichero con extensión
.js) que se deberá incluir en el directorio js de la web.
• El código JSP sólo se podrá utilizar para aspectos relacionados con la

presentación de los datos.
• Básicamente se van a usar JavaBeans y librerías de tags.
• Los JavaBean van a contener la información a visualizar en la página o van a

recibir información de la página.
• La librería de estandar de tags a utilizar es la JSTL (Java Standard Tag Library).

Esta librería se utilizará para minimizar el uso de código Java en la página JSP.

A fin de proporcionar un interfaz rico y evitar refrescos de página innecesarios, se

proporciona la librería DWR que desde código javascript en el navegador permite
interactuar con código java en el servidor.
Por tanto, esta librería se utilizará como mecanismo de refresco de componentes de una
página. Hay que tener en cuenta que el uso de esta librería Javascript implica que la
aplicación no va a cumplir los requisitos de accesibilidad de W3C.
• El uso de la librería debe estar orientado a una interacción del usuario sobre un
componente de la página JSP.
• Evitar el uso excesivo de este tipo de componentes.
• ICM proporciona una aplicación de ejemplo de uso de esta librería.
• Cualquier otro componente o especialización de los ejemplos deberá ser

programado por el proveedor de la aplicación.
• No se puede utilizar la librería para actualización o borrado en Base de Datos.
3.3 ESTRUCTURA DE DIRECTORIOS

REQUISITOS
La estructura de directorios es la definida en la plantillas.
3.4 PAQUETES JAVA
Todas las clases de la aplicación van a estar en un paquete llamado igual que el nombre del
módulo de la aplicación.
Estructura de paquetes java de la aplicación:

aplicacion.controlador: En este paquete se incorpora la clase del controlador. Dentro de

este paquete no se puede incluir subpaquetes.
aplicacion.modelo: En este paquete se incorporan todas las clases de la lógica de

negocio de la aplicación. Dentro de este paquete se pueden incluir subpaquetes.
REQUISITOS
aplicacion.acciones: En este paquete se incorporan todas las clases de acciones.

Dentro de este paquete no se puede incluir subpaquetes.
Una excepción a esta regla son las clases que se utilicen para DWR. Estas clases
deberán incluirse en el paquete aplicación.acciones.ajax, tal y como se indica en el
manual “Librería DWR-Manual de uso”.
aplicacion.beans: En este paquete se incorporan todas las clases JavaBeans. Dentro de

este paquete no se puede incluir subpaquetes.

3.5 GESTION DE EXCEPCIONES
Cada vez que se produzca una excepción en las clases que son cargadas por el
Controlador, esta excepción va a ser capturada por la clase Controlador y va a mostrar una
página jsp con el mensaje del error.
La clase MostrarErrorGeneral es la que muestra la página de error y usa la pagina

error.jsp que debe existir en el directorio de las jsp.
También es posible personalizar la clase que va a mostrar el error dependiendo del error
producido.
Para poder controlar que página se va a mostrar se debe conocer primero el código del
error a controlar Por ejemplo, ListaValores lanza el error de que no ha encontrado registros
con el código 1001.
Si lo que se quiere es que un error (de la aplicación) sea controlado por una clase propia o
mostrado en una pagina personalizada lo que hay que hacer es lanzar este error usando el
constructor de CargableException
Este constructor acepta como parámetros una cadena y un número. El número será el
código de error que también deberá ser incluido en el fichero de configuración.
Ejemplo:
try{
…
}catch(SQLException sqle){
throw new CargableException(“Mi error personalizado:
“+sqle.getMessage(), 501);
}

Las modificaciones en el fichero de configuración serán las siguientes:
1. Añadir una línea con la página que queremos que muestre el controlador cuando
se lance este error:
aplicacion.codError[codigo_error].paginaError = [nuestra_pagina_de_error]
2. Añadir una linea con la clase que queremos que gestione este error:
aplicacion.codError[codigo_error].claseError = [nuestra_clase_de_error].
Esta clase debe implementar el interface

‘sistemas.framework.acciones.comunes.ErrorPersonalizado’
Si se añaden ambas líneas se harán las dos cosas, es decir, el error será gestionado por
una clase propia de la aplicación y será mostrado por una página jsp también propia de la
aplicación.
4 PORTAL DE LA APLICACION
Todas las aplicaciones web deben de tener un aspecto homogéneo y de acuerdo al portal
REQUISITOS
de madrid.org. Para conseguir este aspecto se han predefinido una cabecera y un pie que
son comunes a todas las aplicaciones web.
La cabecera y el pie se deben mantener tal cual, simplemente en la cabecera deberemos

modificar el texto del Nombre del Centro, Nombre de la Consejería y Nombre de la
aplicación.
A continuación se muestra un ejemplo del aspecto de una aplicación:

Para conseguir este aspecto visual tenemos que utilizar los siguientes elementos:
• Hojas de estilo de madrid.org

• Librería de etiquetas para la definición del portal: regiones
• Menú de la aplicación
Partiendo de las plantillas que ICM proporciona ya tenemos definido todo lo anterior.

4.1 Hojas de estilo
Dentro del directorio estilos de la web tenemos que tener las siguientes hojas de estilo:
• Hoja de estilos de madrid.org: estilos.css

• Hoja de estilos del portal: sistemas.css
REQUISITOS
La primera hoja contiene los estilos propios del portal de madrid.org y que debemos
utilizar en nuestras páginas jsp.
En la hoja sistemas.css se encuentran los estilos que se utilizan para colocar los distintos
elementos del portal.
Ninguna de estas dos hojas se puede modificar.
En el caso de que se usen estilos propios estos se incluirán en una hoja de estilos cuyo
nombre va a ser <nombre_aplicacion>.css.
4.2 Librerías de etiquetas del portal: regiones
Se ha creado un librería de etiquetas para la creación de un portal para una

aplicación. Esta librería permite dividir la página en regiones y a cada region darle un
contenido que puede ser :
• fijo : una url de una página html o jsp

• ejecución directa de una acción: Llamada directa a una accion
• contenido variable: La ejecución de varias acciones va a ir a dicha region.
El conjunto de regiones es lo que denominamos rejilla.

Un portal se compone por tanto de las distintas rejillas que contiene la aplicación.
Esta librería se llama regiones.

Una vez definidas las distintas regiones debemos asociar las distintas acciones de la
aplicación Java con la correspondiente región donde se deben pintar. Esto lo haremos en
el fichero de configuración portal.xml.
Para más información sobre la definición del portal consultar el manual especializado.
4.3 Menú de aplicación
En algunas aplicaciones nos interesa incorporar un menú de aplicación que normalmente

a la izquierda de la aplicación nos ofrece en forma de árbol desplegable las distintas
opciones de la aplicación. Para realizar estos menús sin incorporar código Javascript en la
página se ha preparado una solución que mediante el uso de un fichero xml en el que se
definen los distintos elementos del menú y a través de la ejecución de una acción se
genera el menú correspondiente.
REQUISITOS
Entre las características de este menú están:
• Definición del menú independiente de la forma de presentarlo.

• Sin uso de javascript.
• Menú personalizado al perfil de la aplicación para el usuario.
• Posibilidad de invocar directamente a un elemento del menú.
Un menú de ejemplo ya se encuentra incluido en las plantillas.

Para definir los elementos del menú utilizamos un fichero xml.

REQUISITOS
El nombre del fichero debe ser menu_aplicacion.xml.
No es necesario llamar al Menú es el propio Controlador el que se va a encargar de

llamarlo.
A continuación se muestra un ejemplo de fichero menu_aplicacion.xml:
<?xml version="1.0" encoding="ISO-8859-1"?>

<menu-principal desplegar-todos="false">
<elemento id="1" nombre="Inicio"
nombre-navegacion="Home"
url="../../html/web/index.htm" >
<elemento id="1_1" nombre="Elemento 1_1"
nombre-navegacion="Elemento 1_1"
url="../../html/web/elemento1_1.htm"/>
<elemento id="1_2" nombre="Elemento 1_2"
url="../../html/web/elemento1_2.htm">
<elemento id="1_2_1" nombre="Accion1"
nombre-navegacion="Accion 1"
url="Accion1.icm"/>
<elemento id="1_2_2" nombre="Ejemplo de aplicación"
nombre-navegacion="Ejemplo"
url="../../html/web/ejemplo.htm"/>
<elemento id="1_2_3" nombre="Ejemplo de paginacion"
nombre-navegacion="Ejemplo de paginacion"
url="IniciaListado.icm"/>
<elemento id="1_2_4" nombre="Ejemplo de solapas"
nombre-navegacion="Ejemplo de solapas"
url="EjemploSolapas.icm"/>
</elemento>
<elemento id="1_3" nombre="Otro Elemento"
url="../../html/web/elemento1_3.htm"/>
</elemento>

<elemento id="2" nombre="Novedades"

nombre-navegacion="Novedades"
url="../../html/web/novedades.htm"
target="Nueva ventana"/>
<elemento id="3" nombre="(c) ICM-2003" no-url="true"/>
</menu-principal>
En la definición del menu podemos especificar los elementos que queremos que le
aparezcan a los distintos perfiles.
Esto se hace mediante el tag perfil asignando a este tag el valor del código del grupo o
grupos que tienen autorización para acceder a este elemento del menú. Si el tag perfil no
aparece entonces el elemento del menú estará disponible para todos los usuarios.
El Controlador será el encargado de visualizar el menú dependiendo del perfil o grupo al

que pertenezca el usuario conectado.
A continuación se muestra un ejemplo de menu_aplicacion.xml con definición de perfiles.
<?xml version="1.0" encoding="ISO-8859-1"?>

<menu-principal desplegar-todos="false" imagen-
menu="%IMG_ROOT%/samp2_downarrow.gif" imagen-
opcion="%IMG_ROOT%/samp2_bullet_hl.gif" cellpadding="0" cellspacing="0"
width="158">
<elemento id="1" nombre="Empleados" url="Inicio.icm" perfil="2;1">
<elemento id="1_1" nombre="Información" url="Inicio.icm" perfil="2;1"/>
<elemento id="1_2" nombre="Registro" url="FormAltaEmpleado.icm" perfil="1"/>
</elemento>
<elemento id="2" nombre="Busqueda avanzada" url="Menu.icm?numero=1" perfil="2;1"/>
<elemento id="3" nombre="Administracion" url="Inicio.icm" perfil="1">
<elemento id="3_1" nombre="Dirección" url="ListadoCatalogos.icm?CATALOGO=DIRECCION"
perfil="1"/>
<elemento id="3_2" nombre="Sexo" url="ListadoCatalogos.icm?CATALOGO=SEXO"
perfil="1"/>
<elemento id="3_3" nombre="Area" url="ListadoCatalogos.icm?CATALOGO=AREA"
perfil="1"/>
<elemento id="3_4" nombre="Nivel" url="ListadoCatalogos.icm?CATALOGO=NIVEL"
perfil="1"/>
</elemento>
<elemento id="4" nombre="(c) ICM-2003" no-url="true" perfil="2;1"/>
</menu-principal>

5 ANEXO 1: Variables del fichero de configuración
Variables para la definición del portal
Variables Descripción Valores que toma

Variable que indica que si se integrará el portal
portal.integrar true/false
en la aplicación.
Fichero xml donde se define el portal de la
portal.definicion portal.xml
aplicación.
portal.clase Clase que integra el portal. sistemas.portal.generico.PortalGenerico
portal.clasesNoIntegrables Clases que no se integran en el portal. ListaValores;Calendario
Variables del ControladorPrivadoInternet
Página web en la que se solicitan los datos para

aplicacion.paginaAutentificacion /WEB-INF/jsp/login.jsp
la autentificación.
Clase para determinar el perfil del usuario de la

aplicacion.claseControlAcceso sistemas.acceso.impl.GestionUsuariosInternet
aplicación.
Servidor que permite acceder a los datos de

aplicacion.servidorAplicaciones sistemas.servidores.impl.USUIImpl
usuario.
aplicacion.limiteIntentos Número de intentos para validarse. Ejemplo: 5
Local:J2EE
aplicacion.certificados.exportacion Localización de certificado dentro del request.
Desarrollo y producción: PERL
Variable que indica si hay que comprobar o no

certificados.comprobar false/true
la existencia del certificado
Página de error que se mostrará en el caso de

certificados.paginaError /WEB-INF/conf/error_certificado.xml
que no exista certificado.
Nombre de la cookie donde se guardan los

aplicacion.cookieUsuario cookie_usuario
datos del usuario en esa sesión.
CambiarClave Clase que redirige a renuevaClave.jsp. sistemas.framework.acciones.comunes.usui
Si el usuario ha sido bloqueado redirige a

Desbloqueo sistemas.framework.acciones.comunes.usui
desbloqueaUsuario.jsp.
Variables del ControladorPrivadoIntranetSSL
Las variables para el controladorPrivadoIntranetSSL son las mismas que para el

controladorIntranet excepto las siguientes que cambian su valor:

aplicacion.claseControlAcceso Servidor que permite acceder a los datos de usuario. sistemas.acceso.impl.GestionUsuariosIntranetSSL

aplicacion.servidorAplicaciones Servidor que permite acceder a los datos de usuario. sistemas.servidores.impl.LDAPImpl


FW2-ArqWebApps

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

FW2-ArqWebApps

Cargado por

Copyright:

Formatos disponibles

FW2 - Arquitectura Aplicaciones Web

Subdirección General de Desarrollo, Tecnología e Infraestructuras. Página: 1

Fecha Versión Cambios

Subdirección General de Desarrollo, Tecnología e Infraestructuras. Página: 2

Subdirección General de Desarrollo, Tecnología e Infraestructuras. Página: 3

La presente guía presenta el framework para el desarrollo de las aplicaciones de entorno

Este framework es propietario de ICM y se encuentra implementado en la librería

Podemos tener varios tipos de aplicaciones dependiendo del tipo de acceso:

- Públicas: Todo el mundo tiene acceso a la aplicación.

Subdirección General de Desarrollo, Tecnología e Infraestructuras. Página: 4

Para la gestión de usuarios se dispone de dos modelos de datos:

• USU: Para aplicaciones de Intranet.

3 CARACTERISTICAS DE LAS APLICACIONES

• El fichero de configuración deberá estar en el directorio WEB-INF/conf.

Subdirección General de Desarrollo, Tecnología e Infraestructuras. Página: 5

3.2 ARQUITECTURA DE LAS APLICACIONES

Las aplicaciones deberán desarrollarse basando su capa de presentación en el

• Model-View-Controller: El modelo vista controlador (MVC) permite independizar la

presentación, de la lógica de navegación y de los datos de la aplicaciones.

• Front-Controller: El procesamiento de la peticiones es gestionado de manera

• Composite View: Permite gestionar la capa de presentación como la composición

El siguiente gráfico muestra las distintas capas a implementar en las aplicaciones:

Subdirección General de Desarrollo, Tecnología e Infraestructuras. Página: 6

Controlador es quien reacciona frente a las peticiones de los usuarios y es el encargado

Acciones es el conjunto de clases que actúan como intermediarias entre el Controlador y

Las peticiones al Controlador van a ser de la forma Opcion.icm.

• Opcion.icm: Nombre de la opción. Ejemplo:AltaEmpleado.icm

Subdirección General de Desarrollo, Tecnología e Infraestructuras. Página: 7

Tipos de controladores según el tipo de acceso a la aplicación (todos estos

• ControladorPublico: Cualquiera tiene acceso a la aplicación.

• ControladorPublico + Certificado digital (SSL): Para acceder a la aplicación es

• ControladorPrivadoIntranet: Este tipo de controlador se usa en aplicaciones

• ControladorPrivadoInternet: Este tipo de controlador se usa en aplicaciones

Subdirección General de Desarrollo, Tecnología e Infraestructuras. Página: 8

• Obtener información del usuario

La clase Controlador es la única que debe realizar el commit o el rollback.

La clase Controlador de la aplicación se incluirá en el paquete aplicacion.controlador.

No se pueden crear nuevas clases Controlador.

Subdirección General de Desarrollo, Tecnología e Infraestructuras. Página: 9

package empleados.controlador; Controlador

public class ControladorEmpleados

public String getPaquete() {

public String getFicheroConfiguracion() {

public String getDirectorioPlantillas(String userAgent){

Subdirección General de Desarrollo, Tecnología e Infraestructuras. Página: 10

El Modelo comprende el conjunto de clases Java que implementan la lógica de negocio

• La lógica se implementará en clases Java normales, comúnmente conocidas

o Se prohíbe el uso de EJBs (Enterprise Java Beans).

o Las clases serán independientes de cualquier framework usado en la

• La persistencia de los datos almacenados en la base de datos se realizará

• Las clases DAO implementarán el acceso a base de datos mediante sentencias

Subdirección General de Desarrollo, Tecnología e Infraestructuras. Página: 11

El acceso a Base de Datos se va a realizar a través de JDBC. Esto implica que

A continuación se muestra un ejemplo de una clase JavaBean:

public class EmpleadosBean extends sistemas.framework.beans.ModeloBean

private String codigo;

public String getCodigo() {

public void setNombre(String nombre) {

Subdirección General de Desarrollo, Tecnología e Infraestructuras. Página: 12

Subdirección General de Desarrollo, Tecnología e Infraestructuras. Página: 13

Para facilitar la creación de Acciones se ha creado la clase ClaseAccion. Por lo tanto

En la implementación tienen que sobreescribir el método procesar.

Estas acciones van a ser invocadas por el Controlador.