Download anexo iv - Consell de Mallorca

ANEXO IV
GUÍA DE DESARROLLO DE PROYECTOS J2EE
Consell de Mallorca
Servei d'Informàtica y Telecomunicacions
Versión 3.0
Junio 09
Índice
!
"
#
$
!
Guía de desarrollo proyectos J2EE - Consejo de Mallorca
2
1. Glosario
A continuación tenemos un glosario de términos utilizados en este documento:
•
Portlets: Micro aplicaciones autocontenidas compatibles con la especificación JSR-168 y
desplegables en un servidor compatible.
•
JSR: Java Specification Requests. Especificaciones y estándares para la tecnología JAVA.
o
JSR-168 y JSR-170: Estándares para la construcción de portlets. Ésta "Java
Specification Request" se compone de las interfaces y métodos para poder desplegar
un portlet en cualquier sistema de portales compatible con esta especificación.
o
JSR-127 y JSR-252: Estándares para la creación y mantenimiento de interfaces de
usuario
en
aplicaciones
de
servidor
en
Java
(http://www.jcp.org/en/JSR/detail?id=127). Es una implementación seguida por
diferentes fabricantes mayoritarios y bajo el marco de las "Java Specification
Request". Su implementación legacy es la Java Server Faces de Sun. No obstante,
diferentes fabricantes (Oracle, Apache) han desarrollado sus implementaciones
compatibles.
•
XML (eXtensible Markup Language o lenguaje de marcado extensible): Lenguaje basado
en documentos de texto plano con etiquetas que delimitan los elementos. Fue desarrollado
originalmente por W3C para separar en una plana web el contenido de la estructura, y con la
finalidad de acabar sustituyendo el HTML (http://www.w3.org/XML/). En la actualidad se ha
convertido en el formato estándar para intercambiar información entre aplicaciones.
•
JAAS (Java Authentication and Authorization Service): Interfaz Java para acceder a
servicios de autenticación y autorización de forma desvinculada al propio servicio
(http://java.sun.com/products/jaas/). Existen módulos de autenticación por Windows,
Kerberos, JNDI, etc. Para la autorización, JAAS extiende la arquitectura de seguridad de Java
y proporciona una política de control de acceso por usuario, grupos o roles.
•
Webservices: Aplicación de Software diseñada para soportar la interacción entre máquinas a
través de una red. Se rigen por una serie de estándares abiertos como XML, WSDL, UDI y
WSS (Oasis) que los hace independientes de la plataforma y del lenguaje de programación.
Se utiliza SOAP como protocolo de transporte.
•
POJO (Plain Old Java Object): término utilizado para enfatizar que un objeto Java no es
mes que un objeto bean de utilidad básica. A la practica son un conjunto de APIS hechas por
diferentes fabricantes que dan una alternativa a la implementación J2EE para EJB.
•
CASO (Central Authentication Service): Servicio de autenticación central para permitir la
integración a nivel de autenticación de diferentes sistemas.
•
Hibernate: Framework para implementar la capa de persistencia en Java. Es un proyecto de
código abierto que permite el mapeo de objetos a una base de datos relacional con su propio
lenguaje de acceso a los datos HQL y con SQL.
•
JPA (Java Persistence APIO): Framework para implementar la capa de persistencia en
Java. Es un proyecto de código abierto que permite el mapeo de objetos a una base de datos
relacional.
•
ICEFaces: Framework de componentes ajax java para el desarrollo de aplicaciones basadas
en el framework de desarrollo JSF(java server faces)
•
ZK: Framework java para el desarrollo de aplicaciones basadas en ajax
Guía de desarrollo proyectos J2EE - Consejo de Mallorca
3
2. Objetivo
Este documento contiene la descripción del entorno tecnológico y las bases para seguir un estándar
en el desarrollo de las aplicaciones J2EE. Las especificaciones descritas para el desarrollo de las
aplicaciones, está orientado a que puedan ser desplegadas y ejecutadas dentro de la intranet basada
en un portal de sexta generación.
Este documento se focaliza sobre el entorno tecnológico, guía de desarrollo e implantación,
nomenclatura y otras convenciones del entorno a producción
3. Entorno tecnológico
El sistema implantado sobre el que se desarrollará el proyecto dispone de:
LIFERAY: Portal "agregador de servicios web". Instalado sobre el servidor de aplicaciones
Apache Tomcat v.6
ALFRESCO: Gestor documental, que incorpora un sistema de gestión de Workflow.
Oracle Database 10 gr Real Application Cluster: para la base de datos relacional.
Capa lógica: J2EE1.5 (o superior), Portlets (JSR-168 y JSP-170).
Capa presentación: utilización de AJAX (frameworks: ICEFaces o ZK) para el desarrollo de
herramientas de backoffice, HTML, JSP, Java Server Faces (JSR-127 y JSR-252) o superior
por contenidos o herramientas de frontoffice.
Los mecanismos de autenticación y control de acceso se basan en los proporcionados por CAS
(Central Authentication Service) a nivel de servidor de aplicaciones.
El mecanismo de autenticación es único (Single-Sign-On):
Se permite el acceso a los usuarios de ALFRESCO a través del portal LifeRay.
Los usuarios que sean trabajadores del Consell de Mallorca, ya están dados de alta en un
Active Directory.
Los usuarios externos (ciudadanos, empresas, ayuntamientos u otras entidades) están
almacenados en un repositorio diferente.
La visión de las diferentes fuentes de usuarios es única mediante el uso de PenRose
Guía de desarrollo proyectos J2EE - Consejo de Mallorca
4
4. Estándar de aplicaciones J2EE
4.1.
Arquitectura general del sistema
El global de las nuevas aplicaciones y servicios seguirán la siguiente arquitectura:
Imagen 1: Arquitectura general
Consiste en una plataforma tecnológica horizontal que soporta servicios de portal, publicación, de
transacción que estarán agrupados en aplicaciones y servicios:
•
•
Aplicaciones (herramientas de backoffice): Entendidas como un conjunto estructurado de
páginas y formularios web para resolver una problemática, y una lógica de nivel alto o medio.
Podemos distinguir segun el alcance de la aplicación.
o
Aplicaciones corporativas todas aquellas aplicaciones de alcance general, y que su
funcionalidad hace que sea utilizada por usuarios de diferentes departamentos del
Consell de Mallorca.
o
Aplicaciones departamentales las aplicaciones de gestión de cada departamento
del Consell de Mallorca.
Servicios (herramientas de frontoffice): Formulario de consulta o un conjunto de páginas
con una lógica de aplicación muy baja. Orientados a la interacción con el usuario. De la
misma manera se pueden distinguir según el alcance del servicio:
o
Servicios corporativos todos aquellos servicios de alcance general destinados a
usuarios de diferentes departamentos del Consell de Mallorca.
o
Servicios departamentales los servicios destinados a departamentos o grupos de
trabajo concretos del Consell de Mallorca.
Guía de desarrollo proyectos J2EE - Consejo de Mallorca
5
o
Servicios para el ciudadano servicios de alcance global, destinados a todos los
ciudadanos que acceden al Consell de Mallorca telemáticamente
o
Servicios para otras entidades los servicios destinados a la interacción con otras
entidades como pueden ser ayuntamientos, universidades, empresas, etc.
También soporta servicios de comunicación e integración con otras administraciones, entidades y
empresas y tendrá que tener un sistema de BackOffice de administración y gestión tanto de los
contenidos como de la seguridad y la gestión de la plataforma.
Todos estos servicios se encuentran integrados por esta plataforma o portal sobre un servidor de
aplicaciones J2EE y permitirá ampliar con nuevas aplicaciones y/o servicios desarrollados a medida
siguiendo estándares java (JSR-168, JSR-170, JSR-127, JSR-252) y utilizando frameworks para el
desarrollo de aplicaciones web como JSF o persistencia de datos como Hibernate o JPA.
Todo este módulo de servidor de aplicaciones y servicios está integrado en lo que llamaremos portal.
Este portal es una aplicación web, que viene dada en un archivo con la extensión WAR, que será
desplegado en el servidor de aplicaciones. Todo el conjunto de aplicaciones y servicios de nueva
creación, serán Portlets siguiendo el estándar JSR-168 y JSR-252 que desplegarán desde dentro del
mismo portal.
Importante: Los usuarios de todas las aplicaciones no tienen que ser propios de cada aplicación sino
que tienen que utilizar la fuente de usuarios proporcionada para el sistema.
Características técnicas
•
Utilizando la especificación JSR-168 y JSR-252
•
Se utilizará la tecnología Java Server Faces como tecnología para desarrollar el patrón MVC
•
Se utilizará AJAX siempre que sea posible (ICEFaces o ZK)
•
A nivel de componentes, siempre que se puedan funcionalmente y no tengan ninguna
equivalencia con componentes AJAX se utilizarán los de la implementación de referencia
para asegurar la portabilidad entre librerías.
•
Se realizarán componentes JSF
•
El acceso a la base de datos de Oracle del propio desarrollo, se hará mediante capas de
persistencia (Hibernate o JPA).
•
El acceso a datos de otras aplicaciones o a la base de datos con información corporativa se
hará mediante el uso de WebServices publicados a WSAS(Web Service Application Server).
Arquitectura para las aplicaciones en ICEfaces:
Guía de desarrollo proyectos J2EE - Consejo de Mallorca
6
Imagen 2: Aplicación ICEfaces/JSF
Como se puede ver en la imagen, encontramos aplicaciones hechas siguiendo únicamente el patrón
MVC bajo la tecnología Java Server Faces (estándar JSR-127 y JSR-252) del proveedor Sun y los
componentes de ICEfaces. A continuación se presenta la arquitectura para aplicaciones con ZK:
Guía de desarrollo proyectos J2EE - Consejo de Mallorca
7
Imagen 3: Aplicación ZK
Presentación. La capa de presentación se basa en Java Server Faces. Para realizar toda la lógica
Ajax se utilizarán los componentes encapsulados ya hechos en JSF o ZK y componentes nuevos
hechos mediante la composición de otros ya hechos.
Interpretación. Beans contenidos en el propio container de la aplicación y que accederán a los
servicios.
4.2.
Seguridad y permisos
Los permisos se basan en la filosofía del portal (LIFERAY). Se pueden dar acceso a los portlets para
usuario y grupos de usuarios. Por lo tanto, en base a los roles identificados en la fase de análisis del
proyecto se diseñarán los portlets.
5. Nomenclatura
5.1.
J2EE
Se aplicarán las convenciones de nomenclatura de estándares de java.
Aplicaciones
Las aplicaciones J2EE se identificarán por un nombre que constará de una sola cadena de
caracteres identificativa toda ella en minúsculas. El nombre de esta cadena identificará la
aplicación al sistema, dará lugar a una nueva aplicación dentro del portal.
Los nombres de las aplicaciones tendrán relación con el nombre del esquema principal de base de
datos (Oracle) relacionado.
Guía de desarrollo proyectos J2EE - Consejo de Mallorca
8
Ejemplo:
solicitudes
nombre para la aplicación de las solicitudes informáticas
Portlets
Las aplicaciones tendrán agrupación lógica y funcional en portlets. Los nombres, igual que con las
aplicaciones, se trata de una sola cadena de caracteres identificativa, toda ella en minúsculas.
La agrupación en portlets se hace en función de las funcionalidades de la aplicación. Los criterios
para esta agrupación son flexibles, y es muy importante tener definidos los roles a la hora de
crearlos.
Ejemplo: Si en la aplicación "restaurante" controlamos el almacén del restaurante, la reserva de
mesas y los menús podríamos tener 3 portlets:
almacén
reservas
menú
Clases
Los nombres de las clases serán una cadena de caracteres con la primera letra en mayúsculas,
así como también será mayúscula la primera letra de cada palabra, el resto en minúsculas y sólo
puede estar formada por letras y números.
Ejemplos:
HolaMon
Multiplicar
ClasseExemple
Métodos y atributos
Los nombres de los métodos y atributos serán siempre en minúsculas, excepto cuándo son
agrupaciones de diversas palabras, en este caso la primera letra de las palabras 2º, 3º... será
mayúscula.
Ejemplos:
int longitudArray;
String nombre;
public boolean provocaOverflow (int numRegistres)
5.2.
Base de datos
Todo lo referente a la base de datos, se entregará con los scripts necesarios para la creación de
la base de datos así como toda la documentación asociada.
NO ESTÁN PERMITIDOS LOS DBLINKS para las integraciones con otras aplicaciones
existentes, ya que se harán mediante servicios web.
En el caso de nuevos desarrollos, los nombres de los esquemas así como sus contraseñas, las
fijará el Consell de Mallorca.
Los criterios con respecto a los nombres de las tablas, campos, secuencias y restricciones se
dejan a criterio de la parte desarrolladora de la aplicación. En cuanto a los usuarios (esquemas de
Oracle), tablespaces y datafiles seguirán la expuesta a continuación, aunque siempre, antes de
hacer cualquier implementación, se tendrá que consensuar con los responsables del proyecto del
Consell de Mallorca
Guía de desarrollo proyectos J2EE - Consejo de Mallorca
9
Usuarios, tablespaces y datafiles
Para cada aplicación se generarán tantos usuarios (esquemas) como haga falta.
Para cada esquema se crearán: un tablespace y tantos datafiles como se considere para datos,
un tablespace y un datafile temporales y un tablespace y tantos datafiles como se considere
para los índices. Se seguirá la siguiente nomenclatura:
•
Tablespace:
TS_AAA(_XXX) donde:
TS_
AAA
_XXX
prefijo de tablespace
prefijo del esquema
sólo se aplicará por los casos de tablespaces para índices (_IDX) y temporales
(_TMP)
Ejemplos:
TS_AVA
Tablespace de datos de la aplicación de averías
TS_AVA_IDX
Tablespace de índices de la aplicación de averías
TS_AVA_TMP
Tablespace temporal de la aplicación de averías
•
Datafile:
AAA(_XXX)(NN).dbf donde:
AAA
_XXX
NN
prefijo del esquema
sólo se aplicará por los casos de tablespaces para índices (_IDX) y temporales
(_TMP)
número de datafile (caso de datos y de índices)
Ejemplos:
AVA02.dbf
Segundo datafile de datos de la aplicación de averías
AVA_TMP.dbf
Datafile temporal de la aplicación de averías
AVA_IDX01.dbf
Primer datafile de índices de la aplicación de averías
6. Integración, pruebas y puesta en producción
Todo desarrollo pasará por las siguientes grandes etapas: Desarrollo, Integración, validación y
producción.
•
Desarrollo etapa de codificación del proyecto y se realizará en un entorno particular (para el
desarrollador, tanto interno como externo)
•
Integración todos los desarrollos requieren de una parte de integración, para este objetivo, el
Consell de Mallorca dispone de un entorno propio para los desarrollos internos y de los externos
que quieran utilizarlo antes de pasar a validación. Permite hacer pruebas funcionales internas y
de código (para la detección de errores de codificación relacionados con la integración con otros
módulos).
•
Validación Es la etapa que requiere de la validación funcional. El Consell dispone de un entorno
para este propósito y todo desarrollo habrá de ser testeado en este entorno y validado antes de la
puesta en producción.
Guía de desarrollo proyectos J2EE - Consejo de Mallorca
10
•
Producción, etapa en la cual se pasa el proyecto a real. El procedimiento para aplicaciones
J2EE se detalla a continuación:
Base de Datos: Documentación detallada en la que se indique:
•
Modelo de datos
•
Nombres de los esquemas necesarios
•
Scripts de creación de objetos de la base de datos indicando con qué usuario de BD se
tienen que ejecutar, el orden de ejecución y una pequeña descripción de lo que hacen.
•
Scripts de inserciones de registros indicando con qué usuario se tienen que ejecutar, por
que es necesaria esta información inicial y la orden de ejecución
•
Indicar de forma resaltada la interactuación con tablas de otras aplicaciones ya existentes
en caso de claves extranjeras.
•
Indicar de forma resaltada la utilización de información almacenada en tablas de otras
aplicaciones.
•
Otras informaciones que el equipo de desarrollo o empresa desarrolladora considere
relevantes a la hora de poner en producción la aplicación o de su mantenimiento y/o
explotación.
Archivos adjuntos (situados en la carpeta de base de datos) a la documentación:
•
Scripts de creación de objetos de la base de datos. No se entregarán archivos con
creación de objetos diferentes en el mismo archivo, sino que se entregarán diferentes
archivos para la creación de cada uno de los tipos de objeto que se tengan que crear, así
por ejemplo, habrá un archivo para la creación de las tablas, otro para la creación de las
vistas, de los disparadores, etc.
•
Scripts de inserción de registros con la información que forma parte de la carga inicial
necesaria para la puesta en marcha. Los inserts de las diferentes tablas se podrán
entregar dentro del mismo archivo indicando cada conjunto de inserts en qué tabla se
hace o bien separarlos en diferentes archivos de inserción de registros según las tablas
en las cuales se inserten.
Servidor de Aplicaciones: Documentación detallada (situado en la carpeta de documentación)
en la que se indique:
•
Nombre del archivo a desplegar con una pequeña descripción de sus funcionalidades
•
Listado de archivos a copiar en el servidor (librerías javascript, imágenes, librerías java
...) indicando la carpeta destino y sus funcionalidades.
•
Otras informaciones que el equipo de desarrollo o empresa desarrolladora considere
relevantes a la hora de poner en producción la aplicación o de su mantenimiento y/o
explotación.
Archivos adjuntos a la documentación:
•
Se entregará la aplicación empaquetada siguiendo el estándar J2EE en un archivo .war o
en caso necesario, un .ear. Este archivo se encontrará en la raíz de la carpeta Aplicación.
•
Todos los archivos que contengan exclusivamente código javascript con un nombre
orientativo de su finalidad. Los archivos tendrán la extensión .js. Estos archivos se
encontrarán en una carpeta con el nombre /javascript que estará dentro de la carpeta
Aplicación (. /Aplicacio/javascript).
Guía de desarrollo proyectos J2EE - Consejo de Mallorca
11
•
Todas las imágenes propias de la aplicación que no sean corporativas (estandarizadas al
diseño de la I2) con un nombre orientativo de su finalidad. Los formatos de las imágenes
sólo podrán ser .gif o .jpg, no se aceptarán imágenes en otros formatos. Todas dentro de
una carpeta llamada imatges (. /Aplicacio/imatges). La medida no excederá de 50KB para
los logos del departamento y/o aplicación y se encontrarán en una carpeta con el nombre
logos (./Aplicacio/imatges/logos). La medida de los iconos de aplicación que no sean
corporativos no excederán de 2KB y se encontrarán en una carpeta con el nombre icones
(./Aplicacio/imatges/icones). En caso de que haya imágenes o fotografías, éstas no
podrán exceder de 1 MB y se encontrarán en una carpeta con el nombre fotos
(./Aplicacio/imatges/fotos).
•
Las librerías java que sean de utilidad para otras aplicaciones se entregarán
empaquetadas en un archivo con extensión .jar con la documentación necesaria para
poderlas utilitzar (API). Las librerías se entregarán dentro de una carpeta nombrada lib
(./Aplicacio/lib). En caso de librerías de uso exclusivo por la aplicación instalada, nunca
tendrán que entregarse como librerías aparte y por lo tanto estarán incluidas dentro del
archivo de despliegue.
En caso de que las aplicaciones necesiten un archivo de configuración, éste siempre tendrá que
estar en formato XML, no se aceptarán archivos de configuración en otros formatos. También se
entregará un archivo DTD o ESCHEMA de definición de los tags empleados. Los dos archivos se
encontrarán dentro de una carpeta nombrada conf (. /Aplicacio/conf). Estos archivos se tienen
que entregar en esta carpeta por conocimiento del equipo de sistemas aunque se tienen que
incluir dentro del archivo de despliegue.
7. Control de versiones
Dependiendo del tamaño del proyecto desarrollado, se fijarán entregas (en el documento de
planificación, apartado 9 de este documento) con fases determinadas (versiones). Éstas se definirán
en función de las funcionalidades. Cada uno de estas fases del proyecto requerirá de una validación
por parte del Consell de Mallorca, y el mantenimiento correctivo realizado recibirá el nombre de
release.
Ejemplo:
Fase 1
projecteF1
Fase1 y revisión 1
projecteF1.1
8. Documentación
Junto con todo proyecto se tendrá que entregar una documentación. La documentación estará
elaborada íntegramente en catalán. El formato en que se tendrá que entregar será:
Documentos ofimáticos en formato abierto para la documentación textual (RTF).
Documentos para los diagramas UML.
Una versión en PDF.
Esta documentación tendrá que tener la aprobación por parte del responsable del proyecto del
Consell de Mallorca, en el momento de la entrega definitiva se presentará en forma de CD donde en
la portada figurarán los datos siguientes:
Fecha de entrega
Guía de desarrollo proyectos J2EE - Consejo de Mallorca
12
Nombre del proyecto
Nombre de la empresa contratista
Área del Consell a quien va dirigido (si es necesario)
La documentación técnica a entregar será la siguiente:
Planificación del proyecto (con fechas, hitos y tareas).
Documento de contexto. Incluye la información siguiente: Personas participantes en el
proyecto y su rol, descripción de la tecnología utilizada, descripción de los objetivos del
proyecto, diagrama de contexto del sistema.
Documento de análisis de requerimientos. Incluye: Casos de uso, diagramas de clases,
diagramas de actividades y otras informaciones o diagramas que se consideren
adecuados para realizar la descripción del comportamiento estático y dinámico de la
aplicación, flujo de acontecimientos principales y alternativos para cada caso de uso.
Documento de arquitectura del sistema. Incluye diagramas, aclaraciones y descripciones
de la arquitectura general del sistema.
Documento de diseño de la capa de dominio. Incluye diseño de las clases del modelo
conceptual, diagramas de colaboración, modelo estático y modelo conceptual definitivo.
Documento de la capa de servicios técnicos. Incluye diseño del modelo lógico de la base
de datos, diseño del subsistema de persistencia (en caso de ser necesario).
Documento de diseño de la capa de presentación y navegabilidad. Incluirá el diseño
gráfico de las pantallas, su aspecto gráfico así como los controles de interfaz gráfica de
usuario (desplegables, botones, etc.). También incluirá diagramas con el flujo de
navegación. Especificación de los componentes o clases que se utilizarán para
implementar estas pantallas y las interacciones con las clases de la parte lógica como el
documento de diseño.
Documento de implementación. Incluye: Diagrama de componentes y descripción de cada
uno de ellos y, si la aplicación se tiene que instalar en diversos servidores o ámbitos web,
diagrama de despliegue.
Documento de pruebas funcionales. Incluye un plan de pruebas funcionales y los
resultados de su realización para las funcionalidades incluidas en el documento de
análisis de requerimientos. Se detallarán datos como requerimiento certificado, fecha,
resultado, etc.:
o
Test básico funcional: Cumplido de los requisitos establecidos
o
Test de calificación funcional general
o
Test de compatibilidad entre navegadores (Firefox, IExplorer, Safari, Opera)
o
Test de navegación
o
Test de carga y rendimiento
o
Test de seguridad de acceso a datos
o
Test de instalación
Documento de pruebas en la construcción. Incluye un plan de pruebas y el resultado de la
realización de estas pruebas de funcionamiento en implementación e integración de
componentes.
o
Revisión de la documentación técnica asociada
o
Definición de un proceso de implementación y construcción
o
Estándares de codificación
o
Planificación de los tests de integración
Documento del cuaderno de carga llenado (plantilla que facilitará el Consell de Mallorca,
por la puesta en preproducción y producción de cada uno de las releases o versiones).
Guía de desarrollo proyectos J2EE - Consejo de Mallorca
13
9. Control y Seguimiento
9.1.
Reuniones de seguimiento
En caso de desarrollos internos o mixtos (con personal interno y externo) se harán reuniones
semanalmente con todos los miembros involucrados en las tareas de desarrollo y puesta en
producción con el fin de mantener en todo el equipo informado de la evolución del proyecto, hacer
un seguimiento de las tareas asignadas y establecimiento de nuevos hitos y asignación de
nuevas tareas.
9.2.
Comités de dirección
El Consell de Mallorca creará un comité de seguimiento formado por personas expertas en los
aspectos técnicos y funcionales del proyecto y serán trabajadores o asesores del Servicio de
Informática.
El objetivo de este comité será el de revisar periódicamente el desarrollo del proyecto. A tal efecto
se llevarán a cabo las tareas de revisión que el comité estime adecuados, especialmente para
comprobar si el adjudicatario está cumpliendo con los requerimientos y con los plazos del
proyecto. El comité podrá reunirse siempre que lo considere adecuado, pero como mínimo lo hará
para revisar los hitos determinados en la planificación.
Guía de desarrollo proyectos J2EE - Consejo de Mallorca
14