PDF M10 Java PDF

Módulo 10
Desarrollando
Arquitecturas para
Aplicaciones
Empresariales Java
Profesional en
Plataforma
JAVA
Contenido
Introducción y Objetivos ........................................................................................................ 5
Unidad 1. Introducción a los Conceptos Fundamentales de Arquitectura ...................................... 6
Introducción: ¿Que es una arquitectura? ............................................................................................................... 6
Evolución de histórica de las arquitecturas de software ........................................................................................ 7
3
La función del Arquitecto de Software ................................................................................................................. 11
¿Qué relación hay entre Arquitectura y Diseño de aplicaciones? ........................................................................ 12
Recursos de arquitectura y diseño de aplicaciones: ............................................................................................. 13
Métodos de desarrollo ......................................................................................................................................... 14
Definición de Arquitectura en RUP ....................................................................................................................... 16
Unidad 2. Conociendo las Cualidades Sistemáticas................................................................... 20
Cualidades Sistémicas........................................................................................................................................... 21
Restricciones y suposiciones ................................................................................................................................ 24
Desarrollo guiado por las Cualidades Sistémicas .................................................................................................. 24
Unidad 3. Heurística de Desarrollo Arquitectónico y Directrices .................................................. 26
Análisis de la heurística de desarrollo de la arquitectura: .................................................................................... 27
Redes de comunicaciones .................................................................................................................................... 28
Uso de transacciones............................................................................................................................................ 30
Revisión de arquitectura basada en servicios ....................................................................................................... 30
Riesgos ................................................................................................................................................................. 32
Planificando la Capacidad del sistema .................................................................................................................. 34
Unidad 4. Arquitectura de la capa de cliente ........................................................................... 39
Clientes Web ........................................................................................................................................................ 39
Applets ................................................................................................................................................................. 39
Aplicaciones cliente .............................................................................................................................................. 40
Clientes Web ........................................................................................................................................................ 40
Applet ................................................................................................................................................................... 42
Aplicaciones cliente .............................................................................................................................................. 44
Laboratorio: Ejemplo página JSP como capa cliente ............................................................................................ 47
Unidad 5. Arquitectura de la capa web ................................................................................... 49
Arquitectura web de 3 capas ................................................................................................................................ 49
Arquitectura web de 4 capas ................................................................................................................................ 49
Tecnologías web ................................................................................................................................................... 50
MVC ...................................................................................................................................................................... 51
Tipos de beans ...................................................................................................................................................... 55
www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Laboratorio: Arquitectura Capa Web con MVC .................................................................................................... 57
Unidad 6. Arquitectura de la Capa de Negocio ......................................................................... 60
Diseño Procedimental .......................................................................................................................................... 60
Ciclo de Vida de los Beans de Session .................................................................................................................. 61
Diseño Orientado a Objetos ................................................................................................................................. 62
4
Laboratorio: POJO con Hibernate ......................................................................................................................... 70
Unidad 7. Arquitectura de Integración de Capas ...................................................................... 77
Modelo Vista Controlador .................................................................................................................................... 78
Struts con Java ...................................................................................................................................................... 81
Capas de arquitectura JEE .................................................................................................................................... 82
Componentes EJB ................................................................................................................................................. 82
Tipos de beans ...................................................................................................................................................... 84
Anotaciones de un bean ....................................................................................................................................... 85
Role de EJB dentro de las aplicaciones JEE ........................................................................................................... 87
Estructura de EJB .................................................................................................................................................. 88
Custom Tags ......................................................................................................................................................... 92
Laboratorio: Custom Tags Departamentos ........................................................................................................... 98
Unidad 8. Arquitectura de seguridad ..................................................................................... 105
Seguridad criptográfica ...................................................................................................................................... 105
Algoritmo criptográfico ...................................................................................................................................... 106
Algoritmos de cifrado simétrico ......................................................................................................................... 106
Algoritmos de clave pública o asimétricos ......................................................................................................... 107
Tipos de algoritmos de cifrado simétrico ........................................................................................................... 112
Tipos de algoritmos de cifrado asimétrico.......................................................................................................... 114
Certificados digitales .......................................................................................................................................... 115
Arquitectura de seguridad por componentes .................................................................................................... 117
Implementación de la seguridad servidor y EJB ................................................................................................. 118
Seguridad de aplicaciones web en servlets y jsp ................................................................................................ 121
Laboratorio: Uso de Criptografía ........................................................................................................................ 124
Unidad 9. Arquitectura de software ....................................................................................... 131
Modelos de arquitectura .................................................................................................................................... 131
Lenguajes de descripción arquitectónica ........................................................................................................... 134
Frameworks y Vistas ........................................................................................................................................... 134
Lenguajes de patrones ....................................................................................................................................... 137
www.learning.es
Introducción y Objetivos
Introducción y Objetivos
Este módulo proporcionará los conocimientos suficientes al estudiante, los cuales permitirán que
pueda utilizar la plataforma Java EE(TM) en la creación de aplicaciones corporativas adaptables a
cambios y con posibilidades de crecimiento.
www.learning.es
Unidad 1. Introducción a los Conceptos
Fundamentales de Arquitectura
Objetivo
6
Conocer los conceptos más básicos involucrados en el diseño y desarrollo de arquitecturas para
software así como su evolución y aplicación en el lenguaje Java.
Introducción: ¿Que es una arquitectura?

Con la arquitectura del software ocurre a menudo que no estamos seguros de lo que es, pero la
reconocemos cuando vemos una. En el nivel conceptual más alto de un sistema lo que encontramos
es su ambiente y en este sentido la arquitectura se refiere a la representación abstracta de los
componentes de un sistema y su comportamiento. Así, constituiría una organización fundamental de
un sistema descrita a través de:
– Sus componentes.
– Relación entre ellos y con el ambiente.
– Principios que guían su diseño y evolución”.
Otra manera de definir la arquitectura del software podría ser aquella estructura de estructuras de
un sistema, la cual abarca componentes de software, propiedades externas visibles de estos
componentes y sus relaciones.
El objetivo de esta definición es que la arquitectura de software debe abstraer alguna información
del sistema y aún proveer suficiente información para ser la base del análisis, toma de decisiones y
lograr la reducción de riesgos. Ahora bien, una arquitectura no contiene detalles de implementación.
Se corresponde con la estructura de los componentes más significativos de un sistema interactuando
a través de interfaces con otros componentes conformados por componentes sucesivamente
pequeños e interfaces.
A la hora de plasmar en la práctica una arquitectura, debemos poner en marcha una secuencia de
actividades que conllevan la producción de diferentes artefactos arquitectónicos. En concreto dos
fundamentales:
 Descripción de arquitectura
 Prototipo arquitectónico
¿Por qué es importante definir una arquitectura? Básicamente, porque las arquitecturas de los
sistemas, existen con independencia de que hayan sido definidas formalmente o no. Es decir, que
aunque los profesionales que hayan llevado a cabo un desarrollo de software no hayan dedicado
ningún segundo de su tiempo a reflexionar sobre la arquitectura de su proyecto, dicha arquitectura
estará allí.
Por otro lado, otra razón que justifica la necesidad de definir una arquitectura es que los dos
factores primarios en la ingeniería de software que han incrementado la importancia de la
arquitectura son la escala de nuestros programas y su distribución final. Ambos factores van ligados
www.learning.es
a la complejidad del proyecto y a los riesgos del mismo. Por consiguiente, al aumentar la
escalabilidad y la distribución de nuestros productos, automáticamente estamos incrementando su
complejidad y los riesgos que debe afrontar.
Evolución de histórica de las arquitecturas de

software
Para comprender bien el concepto de arquitectura lo mejor es repasar su evolución histórica. De
este modo, podemos distinguir diferentes manera de realizar aplicaciones informáticas desde los
primeros diseños arquitectónicos hasta nuestros días.
a) Aplicaciones Monolíticas:
Este tipo de aplicaciones corresponderían a los desarrollos más primitivos y estarían caracterizadas
por:
 Interfaces gráficas de usuario (GUI).
 Servicios de presentación, negocios y persistencia en la misma máquina.
 No hay concurrencia de usuarios.
 Alto acoplamiento entre tiers o capas.
b) Arquitectura Cliente-Servidor:
Este tipo de arquitecturas supone un paso notable en el desarrollo de aplicaciones. Así, las características
más importantes ligadas a este modelo serían las siguientes:
 Clientes pesados, no estándar
 Conexiones dedicadas a BD
 Protocolos pesados
 Ejecución remota de SQLs
 Alta administración
 Bajo rendimiento
 Alto tráfico de red
 Baja accesibilidad
www.learning.es
8
c) Arquitectura Cliente-Servidor Mejorada:
Supone, como el propio nombre indica, una evolución mejorada de la arquitectura anterior. Los
rasgos fundamentales que la definen son:
 Clientes pesados, no estándar

 Conexiones dedicadas a la BD
 Lógica de negocios en BD
 Mejora en rendimiento
 Alta administración
 Baja escalabilidad
 Baja flexibilidad
 Baja portabilidad
d) Aplicaciones 3 niveles:
Las aplicaciones en tres niveles supusieron uno de los avances con más éxito dentro del desarrollo
de software, en gran medida ligado al mayor empleo de los lenguajes orientados a objetos. Las
características de esta arquitectura serían:
 Reutilización de lógica de negocio para diferentes clientes o sistemas.
 Mejora la escalabilidad.
 Mejora la flexibilidad.
 Independencia de la base de datos.
www.learning.es
9
e) Aplicaciones N-niveles (clientes livianos):
Al ampliar la escalabilidad y complejidad de los proyectos de software, se hizo necesaria una

arquitectura más modular que permitiera acoplar y desacoplar con relativa facilidad los diferentes
componentes de un proyecto, así como adaptar el mismo a las nuevas necesidades que fueran
surgiendo sobre la marcha. Surge así el modelo de N-niveles cuyos rasgos más concretos son:
 Bajo costo de administración de clientes.
 Alta accesibilidad.
 Alta flexibilidad.
 Alta disponibilidad y tolerancia a fallos.
 Alta escalabilidad.
 Independencia de DB
Arquitectura de software en la actualidad

En la actualidad las empresas necesitan agilidad en su negocio debido a que:
– Los requerimientos cambian continuamente.
– Es necesaria una implementación de nuevos programas o servicios para atraer o retener
clientes.
– A menudo se requiere unificar, refinar y medir sus procesos de negocio
De este modo, las empresas terminan demandando que su infraestructura de Tecnología de la

Información (IT) se pueda adaptar al cambio, sea flexible y tenga libertad de escoger nuevas
tecnologías o productos en una relación costo/beneficio absolutamente optima.
www.learning.es
10
Un aspecto muy extendido de esta situación son los denominados procesos fragmentatos. Es decir,
aplicaciones publicadas en diferentes departamentos y unidades de negocios.
Entonces surge el problema. ¿Cómo podemos integrar dichos procesos y datos de una empresa con
una relación costo/beneficio adecuada? Y lo que es más importante ¿Cómo puede ayudar la
arquitectura de software a cumplir con dicho cometido? La respuesta la encontramos en la
denominada Arquitectura Orientada a Servicios (SOA) que es la manera actual más extendida e
implantada de diseñar aplicaciones empresariales.
Una visión idealizada de esta Arquitectura Orientada a Servicios (SOA) englobaría los siguientes
requisitos arquitectónicos a afrontar e integrar:
 Heterogeneidad
 Escalabilidad
 Disponibilidad
 Distribución
 Manejabilidad de Procesos
 Administración y monitoreo de procesos, servicios e infraestructura
Un ejemplo esquemátizado de esta arquitetura de aplicaciones empresariales y de sus componentes

habituales lo podemos ver en la siguiente ilustración. Así vamos precibiendo la realidad informática
compleja y sofisticada a la que debe dar respuesta la arquitectura.
www.learning.es
11
La función del Arquitecto de Software

Además de las nociones teóricas en sí que permiten definir una arquitectura determinada, también
están las personas que ayudan a llevarla a cabo. Dentro de estas personas el papel o rol
fundamental lo ocupa el denominado arquitecto de desarrollo.
El arquitecto es un rol en un proyecto de desarrollo de software, el cual ha de asumir las siguientes

responsabilidades:
– Liderar el proceso de arquitectura.
– Producir los artefactos necesarios: Documento de descripción de arquitectura
– Modelos y prototipos de arquitectura.
Más concretamente, el arquitecto debe

– Visualizar el comportamiento del sistema.
– Crear los planos del sistema.
– Definir la forma en la cual los elementos del sistema trabajan en conjunto.
– Responsabilizarse de integrar los requerimientos no-funcionales (NRFs) en el sistema.
A la hora de cumplir con su papel, el arquitecto debe estar al tanto de las diferentes tecnologías
disponibles en el Mercado y proceder a su evaluación. Con tal experiencia, el arquitecto obtendrá
una serie de beneficios a la hora de aplicarla a sus proyectos:
 Aceptación. Conseguir la aceptación de los participantes del proyecto sustentando sus

recomendaciones y decisiones con un buen nivel de fundamentación.
 Uso adecuado. Asegurar el uso apropiado de las tecnologías por los miembros del equipo.
A la hora de manejar el grupo de trabajo, conviene recordar que:

 Un Arquitecto es un facilitador y líder.
 No toma decisiones unilaterales ni irracionales.
 Evita riesgos en los proyectos y agrega valor al mismo.
www.learning.es
¿Qué relación hay entre Arquitectura y Diseño de
aplicaciones?
¿Existe alguna diferencia entre arquitectura y diseño de software? En principio dentro del lenguaje
profesial parece ambos, dos conceptos muy semejantes e incluso intercambiables dentro del
lenguaje común y corriente de un equipo de trabajo. Sin embargo, la arquitectura y el diseño 12
difieren en tres áreas:
Arquitectura Diseño
Nivel de Abstracción Alto nivel Bajo nivel. Enfoque específico en
detalles
Entregables Planear subsistemas, interfaces con Diseño detallado componentes,
sistemas externos, servicios horizontales, Especificaciones de codificación
frameworks, componentes reutilizables,
prototipo arquitectónico
Áreas de Enfoque Selección de tecnologías, Requerimientos funcionales

Requerimientos no funcionales (QoS),
Manejo de riesgos
La arquitectura envuelve un conjunto de decisiones estratégicas de diseño, lineamientos, reglas y

patrones que restringen el diseño y la implementación de un software.
Las decisiones de arquitectura son las decisiones más fundamentales, por lo tanto, cambiarlas
ocasiona efectos significativos.
www.learning.es
Recursos de arquitectura y diseño de aplicaciones:
En la puesta en marcha de una arquitectura y diseño de aplicaciones debemos tener presente al
menos tres recursos útiles:
– La generación de unos artefactos vinculados a la arquitectura
– El empleo de Patrones
– El empleo de un Framework
13
a) Artefactos de Arquitectura:
En el proceso de definición de arquitectura se produce:

 Una arquitectura Inicial.
 Una arquitectura de Referencia.
Un Documento de Descripción de arquitectura (SAD):
 Subsistemas
 Componentes
 Arquitectura Runtime.
 Guías para el proyecto y estándares de Diseño.
Adicionalmente se producen:
 Matriz Tecnológica de Layers y Tiers
 Plantilla de Arquitectura
b) Patrones de patrones de diseño
Los patrones de diseño son una herramienta muy relevante para un arquitecto de software. Un
Patrón describe una solución probada a un problema recurrente de diseño, el cual ocurre en un
contexto determinado. Existen patrones de arquitectura, de análisis y de diseño.
De hecho, la definición de una arquitectura requiere de un proceso basado en el raciocinio sobre
patrones. Un arquitecto reutiliza patrones para definir la estructura y el comportamiento interno y
externo de un sistema. Ahora bien, utilizar patrones de diseño es diferente a diseñar patrones. El
arquitecto se debe familiarizar con la mayor cantidad de patrones posibles:
 Dedicar tiempo a los catálogos de patrones.
 Conocer los patrones que están disponibles.
 Adquirir experiencia en el uso de los patrones.
 Conocer como tipificar los problemas que resuelven los patrones.
Un arquitecto experimentado reutiliza:
Arquitecturas de sistemas exitosos.
Diseños que han funcionado correctamente en el pasado.
Frameworks conceptuales y tecnológicos.
Componentes y librerías.
c) Framework
El framework es un subsistema de software parcialmente construido, de propósito general para un

tipo específico de problema, el cual debe ser instanciado para resolver una necesidad particular. A
su vez, define la arquitectura para una familia de subsistemas y provee bloques básicos de
construcción y adaptadores.
Conviene subrayar que un framework, habitualmente, se construye a partir de patrones de diseño.
Así, el framework impone patrones de diseño para su uso.
Ejemplos típicos de Frameworks serían:
www.learning.es
1. Tecnológicos:
a. Struts y Java Server Faces (JSF) para Interfaces Web.
b. Log4J para auditoría técnica o negocios en app.
c. Toplink, Hybernate, ROME para mapeos objeto-relacionales.
d. Enterprise Java Beans para construcción de servicios de negocios.
e. Framework de patrones de diseño para J2EE de Sun Microsystems.
f. Grinder como framework para testing de performance. 14
2. Conceptuales:
a. El Cubo para definición de arquitecturas.
b. eTom para empresas de telecomunicaciones.
c. RUP como metodología para definición de procesos de desarrollo.
Métodos de desarrollo
¿Cuáles son los principios fundamentales en los métodos de desarrollo de software modernos?
Podemos enumerarlos rápidamente del siguiente modo:
 Desarrollo iterativo e incremental.
 Conducido por las calidades sistémicas.
 Centrado en la arquitectura.
 Dirigido por los casos de uso.
 Basada en Modelos.
 Mejores prácticas de diseño.
Los modelos son mecanismos primarios de comunicación entre todos los participantes de un
proyecto de software. Reflejan un aspecto particular de un sistema y abstraen detalles no
relevantes.
Tipos:
 Documentos de texto
 Diagramas UML
 Prototipos
Objetivos:
 Comunicación
 Resolver Problemas
 Pruebas de Concepto
www.learning.es
15
Uno de los aspectos más llamativos entre estos modelos, son las diferencias producidas entre el
modelo de desarrollo tradicional y el denominado iterativo. Mientras que en el primero a medida que
pasa el tiempo, los costes de producción se incrementan indefinidamente. En el modelo interactivo
los costes son más fáciles de preveer porque finalizan con el lanzamiento de cada nueva versión del
producto.
Podemos comparar el costo de hacer correcciones en un desarrollo tradicional, con el costo de hacer
correcciones en un desarrollo iterativo en las siguientes gráficas:
Como vemos, está muy bien justificado el optar por un desarrollo iterativo frente al tradicional. Pues
bien, a la hora de poner en marcha dicho desarrollo, el arquitecto de software actual tiene en su
mano dos modelos:
 Desarrollo Centrado en la Arquitectura 4 + 1 View Model Framework de definición de
arquitectura del RUP
www.learning.es
 Desarrollo mediante SunTones AM, el cual agrega dos características importantes a RUP:
o Un enfoque en las calidades sistémicas
o El uso de patrones basados en el razonamiento
La combinación de ambos modelos configura un Framework con forma de Cubo que tiene los
siguientes elementos:
16
Definición de Arquitectura en RUP

El Proceso Racional Unificado o Rational Unified Process (RUP) es un proceso de desarrollo de
software que junto con el Lenguaje Unificado de Modelado UML, constituyen las metodologías
estándar más utilizadas para el análisis, implementación y documentación de sistemas orientados a
objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologías adaptables al contexto y necesidades de cada organización.
El RUP está basado en seis principios:
Adaptar el proceso: El proceso deberá adaptarse a las necesidades del cliente ya que es muy
importante interactuar con él. Las características propias del proyecto u organización. El tamaño del
mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico.
También se deberá tener en cuenta el alcance del proyecto en un área subformal.
Equilibrar prioridades: Los requisitos de los diversos participantes pueden ser diferentes,
contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los
deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.
Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de un modo interno, en
etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del
producto, y se refina la dirección del proyecto así como también los riesgos involucrados
Colaboración entre equipos: El desarrollo de software no lo hace una única persona sino múltiples
equipos. Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones,
planes, resultados, etc.
Elevar el nivel de abstracción: Este principio dominante motiva el uso de conceptos reutilizables
tales como patrón del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar
algunos. Esto evita que los arquitectos de software vayan directamente de los requisitos a la
codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer
de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilización del
código. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones
arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de la arquitectura,
por ejemplo con el lenguaje UML.
Centrarse en la calidad: El control de calidad no debe realizarse al final de cada iteración, sino en
todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de
desarrollo y no de un grupo independiente.
www.learning.es
17
Fase de Inicio
Durante la fase de inicio se establecen:
– Requerimientos no-funcionales.
– Arquitectura inicial, la cual se considera viable para el proyecto.
– Lista de Riesgos y Restricciones.
– Entregables:
– Documento de Visión
– Arquitectura Inicial
– Plan de la siguiente fase
Fase de Elaboración
Durante esta fase se crean:
www.learning.es
– Arquitectura línea base.
– 80% de los requerimientos del sistema.
– Plan de iteraciones para la fase de construcción.
Los entregables correspondientes a esta fase serían:

– Requerimientos del Sistema.
– Documento de Definición de Arquitectura.
18
– Prototipo evolutivo de arquitectura.
– Guías y Estándares.
– Plan de Iteraciones.
La metodología RUP es más apropiada para proyectos grandes, dado que requiere un equipo de
trabajo capaz de administrar un proceso complejo en varias etapas. En proyectos pequeños, es
posible que no se puedan cubrir los costos de dedicación del equipo de profesionales necesarios.
Modelo de Vista 4+1

El Framework para Descripción de Arquitecturas del Rational Unified Process (RUP), basado en vistas
lógicas y físicas UML y una vista funcional de casos de uso.
SunTone AM
SunTone AM es una metodología de desarrollo de software análoga al Unified Process (UP), con un
fuerte énfasis en las calidades sistémicas y patrones de diseño.
Tiene un framework conceptual, el cubo, el cual provee una vista tridimensional de:
– Capas lógicos
– Layers o niveles tecnológicos
– Calidades sistémicas
Con el cubo se puede definir la matriz tecnológica de Layers y Tiers, la cual documenta las
decisiones tecnológicas para soportar la arquitectura de un sistema.
www.learning.es
Profundizaresmo en algunos elementos de este cubo en las unidades siguientes.
19
Ver Video: Introducción de Conceptos Fundamentales de

arquitectura , en la Unidad 1, en el Módulo 10,
en la plataforma elearning
Actividades
“Recuerde que para un seguimiento óptimo de la unidad es imprescindible realizar las
actividades que encontrará en la unidad correspondiente de la plataforma eLearning”.
www.learning.es
Unidad 2. Conociendo las Cualidades
Sistemáticas
Objetivo
20
Profundizar en los conceptos más básicos involucrados en el diseño y desarrollo de arquitecturas
para software bajo el lenguaje Java.
Introducción
Conviene profundizar ahora en algunos contenidos sucintamente expuesto a en la unidad anterior. El

analista funcional de sistemas ha de preocuparse por identificar los requerimentos de Negocio y
Funcionales hasta determinar toda la funcionalidad que debe proporcionar un sistema.
Por su parte, el arquitecto ha de concentrarse en los requerimentos no funcionales y las

restricciones iniciales con la intención de indagar la manera en la cual debe de ser construido el
sistema para lograr dichas funcionalidades establecidas por el analista.
El Arquitecto al igual que el Analista de Sistemas debe realizar actividades de Análisis, Diseño y
Construcción con la diferencia que su objetivo son los Requerimientos No Funcionales del Sistema.
Es decir, todo aquello que determina como debe funcionar el sistema.
El Arquitecto obtiene los requerimientos iniciales, las restricciones, los supuestos, identifica riesgos,
analiza la información y formula una o varias propuestas de solución tomando en cuenta todo lo
anterior. Dentro de la solución no elige un framework porque es el favorito del Arquitecto, no elige el
lenguaje de desarrollo porque quiere aprenderlo o porque es el de moda, los elementos que
conforman la solución deben ser elegidos de forma adecuada para que, en conjunto, cumplan con
los requerimientos no funcionales y las restricciones de tiempo, costo y recursos.
El resultado de este proceso será obtener un entregable al que denominado Documento de

Arquitectura. Dicho documento puede tener diferentes nombres dependiendo de la metodología y de
www.learning.es
la empresa: Documento de Arquitectura (Vision Consulting), Service Level Agreement (SLA),
TCH100 (GNP) etc.
Para ello, las siguientes resultan ser algunas de las actividades que debe realizar el Arquitecto para
poder proponer una solución de Arquitectura.
a) Requerimientos de Negocio: Al igual que el Analista Funcional, el arquitecto debe identificar y

conocer cuáles son los objetivos de negocio que motivan el desarrollo del sistema. Esto permitirá
proponer la solución más adecuada en función de estos objetivos y evitar cualquier desviación. 21
b) Requerimientos No Funcionales: Los Requerimientos No Funcionales (NFRs) son los niveles de

servicio y restricciones que el sistema debe cumplir. Cuando un cliente es experimentado puede
definirlas por él mismo, en otras ocasiones es el arquitecto quien debe ayudar a identificarlas.
En el Documento de Arquitectura el listado de Requerimientos No funcionales puede ir en una tabla

como la siguiente escritas con palabras propias del cliente.
Clave / Descripción
NFR01
Descripción del Requerimiento No Funcional
NFR 02
Estas características están concebidas para especificar con detalle cómo realizar la funcionalidad del
sistema, con qué medios y en cuanto tiempo. Para ello, conviene ayudarse de los procedimientos
propuestos por Sun Microsystems en su Metodología de Arquitectura Sun Tone Methodology:
Cualidades Sistémicas o Quality of Service (QoS)
Cualidades Sistémicas
Las cualidades o calidades sistémicas están definidas por Sun Microsystems de la siguiente manera:
 Son propiedades que establecen la calidad de servicio (QoS) que un sistema expone.
 Son globales a toda la arquitectura e influencian el diseño.
 Son no-funcionales pero observables.
 No se pueden satisfacer completamente por un componente.
Las Calidades sistémicas se descomponen en las siguientes familias:

 Manifiestas (Manifiest).
 Operacionales (Operational).
 Desarrollo (Developmental).
 Evolutivas (Evolutionary).
a) Manifiestas u obvias para el usuario

Desempeño (Performance). La rapidez y eficacia con la cual el sistema cumple la petición. Es decir,
determina el tiempo de respuesta desde el punto de vista del usuario.
Confiabilidad (Reliability). El sistema debe ser exacto y fiable. Esta calidad se preocupa por el grado
de probabilidad de que las operaciones se realicen correctamente.
www.learning.es
Disponibilidad (Availability). Cantidad de tiempo en línea en el que el sistema puede procesar
solicitudes. Este es asunto más complejo puesto que determina el porcentaje de tiempo que un
sistema puede usar para procesar dichas solicitudes.
Usabilidad (Usability). El grado de facilidad o dificultad en el manejo del sistema.
22
b) Cualidades operacionales que están ligadas al sistema en ejecución

Rendimiento de trabajo (Throughput). Cantidad de trabajo hecho por el sistema medido en
operaciones por unidad de tiempo.
Posibilidad de ser Administrado (Manageability).
Seguridad (Security). Prevención de uso no autorizado del sistema y su información.
Serviceabilidad (Serviceability). Esfuerzo necesario para actualizar o reparar el sistema.
Facilidad de hacer pruebas (Testeability). Esfuerzo requerido para identificar y aislar una falla en el
sistema.
c) Cualidades Evolucionarias vinculadas a cómo se comporta el sistema cuando es

modificado o actualizado.
Escalabilidad (Scalability). La habilidad para mantener la calidad de servicio requerida conforme la
carga aumenta. Es decir, implica conocer la capacidad de crecer y mantener buenos niveles de
operación ante un incremento en el número de usuarios o peticiones.
Mantenibilidad (Maintainability). La facilidad con la que la aplicación será susceptible de ser
corregida o reparada. Así, como determinar el esfuerzo ahorrado cuando se hacen dichos cambios
de configuración.
Extensibilidad (Extensibility). Posibilidad de agregar funcionalidad nueva. Supone, por tanto,

determinar el esfuerzo ahorrado para añadir nuevas funcionalidades.
Flexibilidad (Flexibility). Costo de implementar una corrección o una funcionalidad nueva.
Reusabilidad (Reusability). Esfuerzo ahorrado cuando empleamos o apoyamos en nuestro
proyecto componentes preexistentes
Portabilidad (Portability). Esfuerzo ahorrado cuando se migra a una infraestructura diferente.
d) Cualidades de Desarrollo que afectan a la manera en la cual se está construyendo el

sistema.
Realizabilidad (Realizabilidad). Probabilidad o confianza en que el sistema puede desarrollarse, se ve
reflejado en la facilidad de estimación, planeación y construcción.
Planeabilidad (Serviceability). Confianza en que el sistema puede ser planeado en costo y esfuerzo.
Algunas cualidades sistémicas son excluyentes entre sí, por ejemplo Desempeño frente a Seguridad:
el cumplimiento de una minimiza a otra por lo que resulta necesaria una priorización en las
www.learning.es
cualidades sistémicas para poder decidir de entre varias opciones de solución más adecuada y que
no comprometa el cumplimiento de una o varias cualidades.
Las cualidades sistémicas deben quedar identificadas y listarse en nuestro proyecto como el
siguiente:
23
Calidad del Prioridad Descripción del Propuesta para cubrir el
servicio (QoS) Requerimiento requerimiento
Disponibilidad Alta El sistema no debe quedar Opción 1: Se propone escalar el
fuera de línea en las horas sistema con XX Memoria RAM y
pico o dentro de la ventana mover las aplicaciones existentes a
de servicio. otro servidor con menos recursos
Opción 2: Se propone el uso de 2

servidores YYY y 1 balanceador de
carga.
Seguridad Alta
Tiempos de Alto Ver tabla anexa
Respuesta
El ejemplo anterior que simula una situación de desarrollo de una aplicación fictícea se
complementaría con tablas de pruebas similares a la que vemos a continuación y cuyo vínculo a la
tabla anterior debe quedar registrado también a modo de llamada entre tablas. En nuestro caso se
emplea la expresión “Ver tabla anexa”.
Tiempos de respuesta esperados (Ejemplo)
Tipo Respu Respues Volume Accesos Latencia Latencia

operación esta en ta en n concurrent detecta detecta
Hora Hora promed es, (prom. da hacia da hacia
Prome Pico io de futuro.) Server BD
dio datos
Escritura ¿? ¿? 50k 825 Por Por

probar probar
Lectura ¿? ¿? 50k 300 Por Por
probar probar
Reportes ¿? ¿? 50k 300 Por Por
probar probar
General 1seg 5seg 50k 300 Por Por
probar probar
Otras facetas funcionales del desarrollo también deberán contemplarse y documentarse mediante la
enumeración y resolución de diferentes características operacionales. Veamos otra tabla de registro
que expresa esta labor:
www.learning.es
Características operacionales
Característica Operaciones del Descripción
Sistema Detectadas
Transaccional *Asignación del folio Se desarrollarán los componentes de negocio con EJBs
*Calculo de número de Los demás componentes de negocio se desarrollarán

referencia con POJOs para poder llegar a los tiempos de respuesta
24
solicitados.
Concurrencia * Registro de un
solicitante
* Consulta de reportes
* Configuración de
procesos de registro
Restricciones y suposiciones
Todo proyecto tiene restricciones, las más comunes son tiempo, recursos, presupuesto y tecnología
a utilizar. El arquitecto debe proponer alternativas de solución que se muevan dentro de estas
restricciones. En algunos casos será necesario sacrificar una buena opción porque no cumple alguna
de estas.
Es muy importante documentar las restricciones iniciales del proyecto y a lo largo del desarrollo
documentar los cambios sobre estas restricciones. Al final del proyecto es común que alguien, sin el
debido conocimiento de cómo han trascurrido los hechos, pueda preguntarse por qué se hicieron las
cosas de esta manera. La respuesta la encontrará tanto en las restricciones iniciales como en los
cambios surgidos, justificados y documentados a lo largo del proyecto.
Al inicio del proyecto no siempre tenemos toda la información necesaria para poder plantar una
propuesta, incluso el cliente puede no tenerla. Esta incertidumbre hará que dudemos en proponer
una solución porque no sabemos qué implicaciones puede tener esa ausencia de información. Pero,
por otro lado, no podemos quedarnos impasibles. Ante estos casos se deben hacer supuestos y
actuar en base a éstos. Cuando, por ejemplo, se hace una propuesta dichos supuestos se deben
notificar a todos los involucrados y subrayar que cierta solución será válida sólo bajo ciertas
consideraciones.
Ejemplo. El cliente no tiene idea de cuantos informes o reportes se tienen que generar en el
sistema.
Supuesto: Se realiza una propuesta suponiendo que solamente se requerirán 100 horas de
construcción de reportes.
Desarrollo guiado por las Cualidades Sistémicas

Hemos visto que las calidades sistémicas son requerimientos no funcionales, los cuales definen la
calidad de servicio que un sistema expone. Dichos requerimentos no funcionales serían, por
ejemplo:
– Rendimiento
– Confiabilidad
– Escalabilidad
– Seguridad
Pues bien, esas calidades sistémicas impactan directamente en la arquitectura de un sistema. Aquí
es donde se engarzan las diferentes piezas que venimos exponiendo en la unidad anterior y la
presente porque la arquitectura del software es primariamente necesaria para crear un framework
www.learning.es
orientado al desarrollo basado en patrones y para la entrega de calidades sistémicas predecibles.
Todo ello distribuido en capas. En la ilustración siguiente podemos ver un ejemplo abstracto de
arquitectura que tiene en cuenta los patrones y las calidades sistémicas distribuidas en diferentes
capas: presentación, negocio y base de datos.
25
Si entramos más concretamente en la aplicación de dichos conceptos abstractos sobre los elementos
o productos tecnológicos que nos ofrece Java, veremos que éstos se pueden aplicar sobre una
arquitectura de software típica del modo que ilustra la siguiente tabla:
Cada elemento de Java o auxiliar opera o funciona en un determinado nivel y capa dentro de la
arquitectura de software concebida para el desarrollo con dicha tecnología y lenguaje. Es en ese
empleo concreto donde, de manera inherente, se solventan y se consiguen un mayor grado de
optimización buena parte de las calidades sistémicas del modelo de desarrollo que venimos
repasando en estas páginas.
Ver Video: Las Cualidades Sistémicas , en la Unidad 2,

en el Módulo 10, en la plataforma elearning
Actividades
www.learning.es
Unidad 3. Heurística de Desarrollo
Arquitectónico y Directrices
Objetivo
26
 Conocer los factores y elementos que permiten introducir innovaciones de manera rápida en
el diseño y desarrollo de arquitecturas para software realizado bajo lenguaje Java.
Introducción
En sistemas altamente distribuidos, la capacidad de tomar las decisiones correctas acerca de dónde
los componentes están localizados y como ellos se comunican resulta mucho más crítico y dificultoso
que en los sistemas de pequeño tamaño y prestaciones limitadas.
La importancia de esta clase de decisiones crea la necesidad de la arquitectura. Entonces, la función
crítica de la arquitectura es llevar a cabo una planificación de alto nivel, de localización y de
comunicación entre los diferentes componentes del software que se esté desarrollando.
Esta función distingue a la arquitectura del diseño, de la programación y de la integración de las

otras áreas del desarrollo del software.
La planificiación de alto nivel nunca debe perder de vista las siguientes metas:
– El sistema resultará robusto si ocurren sólo fallos parciales
– El sistema manejará y soportará la carga de trabajo requerida
– El sistema será escalable cuando la demanda por uso concurrente excede de los parámetros
de diseño original
Conviene insister entonces en las diferencias entre la arquitectura y el diseño del software:
Arquitectura Diseño
Nivel de Abstracción Enfoque alto y extenso en Enfoque bajo y específico

algunos detalles en muchos detalles
Resultados Planes de sistemas y Diseño de componentes,
subsistemas, prototipos especificaciones del código
arquitectónicos
Área de enfoque Requerimientos no funcionales, Requerimientos
manejo de riesgo funcionales
¿Cuáles serían las principales preocupaciones de la arquitectura? Podríamos desglosarlas en cinco

puntos fundamentales:
www.learning.es
Usar documentos arquitectónicos para crear el modelo del sistema que se ocupe de la calidad del
servicio.
 Documento de Visión: oportunidades de negocio.
 Especificación de requerimientos: funcionales y no funcionales.
Identificación de riesgos y plan de mitigación
27
 Modelo de dominio para la aplicación: estructura y relaciones.
 Descripción del contexto: cómo y dónde el software y el servicio deben estar localizado.
 Plan del proyecto: Definir los hitos que caracterizarán cada una de las fases de desarrollo del
proyecto.
 Lista de supuestos: crecimiento de usuarios y transacciones a implementar.
 Evaluar apropiadamente el uso de tecnología J2EE y asegurarse de la aprobación por parte
de los gestores del proyecto:
Los gestores del proyecto pueden tener ideas preconcebidas sobre qué tecnología debe ser
usada en el proyecto. Por ello, hay que justificar adecuadamente la decisión tecnológica
adoptada o elegida y no dejarse llevar por tendencias o gustos particulares.
 Identificar y controlar los riesgos:
La primera meta de la arquitectura es asegurar la calidad del servicio, su desempeño y
fiabilidad.
Análizar los costos
 Usar patrones adecuados:
Revisar catálogos de patrones
 Desarrollar prototipos:
Un prototipo arquitectónico describe el sistema y permite experimentaciones mentales para
determinar si el plan está resultando satisfactorio o no.
Análisis de la heurística de desarrollo de la

arquitectura:
Se denomina heurística a la capacidad de un sistema para realizar de forma inmediata
innovaciones.
Un servicio permite a muchos usuarios concurrentes acceder a un recurso que este maneja,
mientras que simultáneamente opera con la integridad de los datos.
Los servicios se mapean a los temas duraderos del negocio, o sea partes del negocio que no
cambian. Por ejemplo, el manejo de las cuentas de acceso a un sistema.
Si nuestro modelo de negocios es un conjunto de servicios duraderos, el modelo habrá de responder
fácilmente y a bajo costo a los diferentes cambios venideros del negocio.
Ahora bien, aunque todo lo anterior es lo deseable ¿Qué problemas se deben eliminar para que una
arquitectura resulte óptima?:
 Flexibilidad del sistema: Es inevitable que el sistema requiera cambios en el tiempo. Si el
sistema no es flexible hacer cambios será muy costoso
www.learning.es
 Red de comunicaciones y diseño: La red es la parte más lenta de un sistema de computación
distribuido. Por lo tanto, se ha de tener muy en cuenta cómo los elementos se comunican
unos con otros.
 Modelo transaccional: Las transacciones son importantes para mantener la integridad de los
datos, pero limitan la concurrencia.
 En algunos casos es conveniente eliminar el uso de transacciones o reducir el ámbito de la
aplicación, para que no se proteja completamente los datos. Pero se incluye código que 28
repare el daño en caso de producirse
 Manejo de costos: Si un proyecto excede su presupuesto, difícilmente podrá continuar. Una
técnica común para reducir gastos es usar patrones y heurística. El trasfondo de esta forma
de operar es razonar pensando en que la última vez que un problema se presentó, la solución
aplicada funcionó bien, así que se repetirá el mismo procedimiento de la otra ocasión.
La arquitectura también, como se ha señalado en otras unidades, se refiere a una representación

abstracta de los componentes y el ambiente del sistema. Esto significa que la representación del
sistema no debe contener detalles de la implementación porque impide la flexibilidad. No obstante,
los elementos que conforman la arquitectura son componentes y sistemas. Y dichos componentes
son elementos de software comparables a los objetos de alto nivel. Es aquí donde ponemos en
contacto la arquitectura con el diseño de los componentes orientados a objetos. Así que debemos
aplicar los principios usuales de la orientación a objetos sobre dichos componentes. Así, lo que
deberemos hacer sera:
– Separar los elementos no relacionados
– Separar las partes que tiendan a cambiar con el tiempo
– Mantener las interfaces de componentes simples y claras.
Estos principios ayudan a maximizar la flexibilidad del sistema y reducen el riesgo de que un
requerimiento de cambio haga inútil todo el sistema.
También usaremos la abstracción arquitectónica para definir límites:

 La abstracción permite centrarnos en los componentes grandes antes que discutir los detalles
más minúsculos.
 La idea es tener una abstracción que tenga interfaces pequeñas, simples y claras y sus
respectivas dependencias
 Los cuadros y esquemas deberán mostrar los elementos claves de todo el escenario.
Dentro de dicho ámbito de abstracción se procederá también a establecer dichos límites, pero, sobre
todo, subrayando cuál será el área de superficie, sus fricciones internas y puntos de fragilidad. El
área de superficie es cada atributo de las interfaces donde los módulos se comunican entre sí. Los
cambios a los componentes de áreas de superficie grande, crea fricciones y en los sistemas más
frágiles, la fricción puede propagarse de componente a componente a través de todo el sistema.
Todas estas circunstancias deben ser contempladas durante la abstracción arquitectónica del
proyecto.
Redes de comunicaciones
El desempeño o papel de la red de comunicaciones del sistema es una de las preocupaciones
principal en la arquitectura y diseño de aplicaciones informáticas. Tres factores que determinan el
desempeño de la red son:
 Ancho de banda: regula la capacidad de datos en una red de comunicaciones.
 Requerimiento de latencia: el tiempo transcurrido hasta completarse la comunicación en la
red.
 Frecuencia de solicitud: Uso de la capacidad del canal.
www.learning.es
29
www.learning.es
Surgen entonces dudas que hay que afrontar durante la definición arquitectónica del proyecto. Por
ejemplo, ¿qué es mejor para el sistema enviar muchas solicitudes de datos pequeñas o una solicitud
más grande? Para guiarnos en el rendimiento de la red podemos tener en cuenta algunas
consideraciones. Así, puede resultar que no sea necesario tener todos los datos de una vez.
Conviene entonces calcular todos los datos tomando su envío durante un tiempo significativo. El
proceso puede empezar solo con una parte de los datos. Luego, minimizar la frecuencia de
solicitudes, realizar un cuidadoso diseño de interfaz de Usuario que mejore la progresiva captación
de los datos para no saturar el sistema con una sola llamada y, finalmente, hacer un diseño también 30
cuidadoso de la API remota para no hacer todo en una sola llamada.
Uso de transacciones
Una transacción es una simple unidad de trabajo que está compuesta por una serie de operaciones
individuales, donde toda la serie debe suceder con éxito o fallar completamente a pesar de que
parte de los procesos secuenciados puedan realizarse efectivamente. Es decir, se trata de un
procedimiento que tiene que producirse en su totalidad o no producirse.
¿Cuándo debemos usar transaciones? Debemos distinguir dos situaciones diferenciadas:

Transacciones Necesarias: Hay operaciones que tienen que ejecutarse en un grupo indivisible.
Ej. Comprar con tarjeta de crédito: comprobar el stock de productos y actualizarlo, chequear que
haya crédito, hacer el débito del pago y cambiar el estado del elemento adquirido.
Cuando no son Necesarias: Hay que evitar las transacciones siempre que sea posible, porque estas
tienen un impacto negativo en el desempeño y el rendimiento de nuestras aplicaciones. Por ejemplo,
ya vimos que:
 Los beans de entidad representan un objeto concreto que tiene existencia en alguna base de
datos de la empresa
 Por último, un bean de sesión representa un proceso o una acción de negocio.
Finalmente, el diseño de transacciones en la programación multi-hilo, es no-determinística, por

tanto, se pueden presentar problemas muy difíciles de resolver como son los bloqueos deadlock.
Revisión de arquitectura basada en servicios

La Arquitectura Orientada a Servicio (SOA) no es una forma nueva de crear soluciones a problemas
del dominio, sino más bien un paradigma de organización que permite obtener mayor valor de las
capacidades, tanto poseídas como controladas por otros. SOA no provee elementos del dominio de
una solución que no exista sin SOA. El objetivo en SOA es hacer que cada subsistema de una
empresa presente sus capacidades a través de servicios adecuados que permitan usar las
capacidades de una manera homogénea. Esto evita crear interfaces para cada par de sistemas que
requieran comunicación. La filosofía detrás del concepto es que cada sistema brinda servicios a
clientes desconocidos, por lo que se debe hacer hincapié en las capacidades que se ofrecen y no en
quién las va a usar. Este modelo de servicio permite crear funciones que sean utilizables por
distintos clientes, los cuales simplemente deben conocer la descripción del servicio para poder
utilizarlo.
www.learning.es
31
En el ambiente heterogéneo de los sistemas de información de una empresa, cada sector de la

misma resuelve sus problemas mediante sistemas adecuados. Puede haber sistemas para gestión
contable, ERP, CRM, información interna (intranet), transacciones, bases de datos, etc. Cada uno es
pensado como una identidad independiente, con su propio entorno (hardware, sistema operativo,
lenguaje de programación, entorno de ejecución); muchas veces existe una funcionalidad
redundante entre los distintos sistemas. En muchos casos, se tienen sistemas antiguos o heredados
con décadas de desarrollo acumuladas, de los cuales se depende y no son factibles de reemplazar,
ya sea por dependencia del negocio o riesgos de implementación. Para permitir la interacción entre
todos los sistemas, se suele contar con interfaces entre cada par de subsistemas que requieren
comunicarse, lo cual complica entender el funcionamiento global del negocio y agrega redundancia a
nivel interacción (se implementan las mismas funcionalidades para muchos sistemas clientes). Las
interacciones entre sistemas van evolucionando a medida que cambia el negocio, lo cual crea la
necesidad de desarrollar nuevas formas de integración. Es justamente en la integración de distintos
sistemas donde SOA entra en juego.
La implementación de servicios es la clave para producir arquitecturas con buena seguridad,

disponibilidad, y escalabilidad.
Las características básicas de SOA son:
– La arquitectura basada en servicios esta compuesta de un número alto de servicios.
– Cada servicio provee acceso a los componentes de la aplicación.
– Los servicios actúan como puntos de venta en el sentido que ellos proveen la conexión con el
resto de la aplicación, lo cual mejora la extensibilidad del sistema.
Existen un buen número de razones para usar Arquitecturas Basadas en Servicios:

 Los servicios encapsulan el dominio del negocio.
 Los clientes puede solicitar servicios en lugar de interactuar directamente con ellos.
 Este acoplamiento flexible hace que sean menos frágiles.
 Responden fácil a los cambios del negocio.
 Se puede dividir el sistema por capas o por funciones especiales.
En cuanto a los tipos de servicios que están involucrados en SOA podemos hablar de:
• Servicios Verticales:
Basados en el contenido del sistema
www.learning.es
Estos servicios reflejan el modelo del negocio y son específicos para un dominio en particular
Ej. El servicio de inventario
• Servicios Horizontales:
Basados en la infraestructura del sistema
Son accedidos desde muchas capas y sobre diferentes dominios.
32
Ej. El servicio de seguridad de autenticación
Riesgos
El manejo de riesgos es un tema importante en la administración de proyectos y de igual forma para
la Actividad de Arquitectura. Uno de los objetivos de la arquitectura es precisamente disminuir los
riesgos tecnológicos. La idea es identificar todas aquellas situaciones que puedan poner en riesgo el
éxito del proyecto dentro de las restricciones de tiempo y presupuesto, crear un plan de mitigación y
de contingencia en caso de que se dé el problema.
Uno de los objetivos de RUP es asegurar que las expectativas de todas las partes estén
sincronizadas y sean consistentes. Esto es asegurado a través de evaluaciones periódicas durante el
ciclo de vida del proyecto, y es documentado en el Reporte o Informe de Evaluación de Status. Este
reporte es utilizado para hacer un seguimiento de la información acerca de los recursos disponibles
(humano y financiero), de los mayores riesgos, del progreso técnico medido a través de métricas y
de los resultados de hitos principales.
Con RUP hacemos uso de las siguientes clases de métricas:

– Progreso: líneas de código, número de clases, puntos de función por iteración, rehacer.
– Estabilidad: tipo de rehacer, volatilidad de requerimientos o implementación.
– Adaptabilidad: costo de rehacer.
– Modularidad: extensión del impacto de rehacer.
– Calidad: velocidad de descubrimiento de defectos, densidad, profundidad e inheritancia,
indicador de rehacer.
– Madurez: horas de prueba por falla.
– Perfil de desembolso de recursos: planeados versus actuales.
Los documentos RUP que contienen los planes y compromisos son:

– Casos de Negocio
– Plan de Desarrollo de Software
– Plan de Medición
– Lista de Riesgos
– Plan del Proyecto
– Plan(es) de Iteración
– Evaluación(es) de Iteración, y
– Evaluación(es) de Status
La Lista de Riesgos es un artefacto de RUP que nos provee una visión de todos los riesgos conocidos
en el proyecto, y sirve como entrada para la planificación y evaluación del proyecto. Cada riesgo es
descrito en función de su impacto, y un plan de contingencia será desarrollado para mitigar el riesgo
en cuestión.
Dependiendo del sistema o modelo de desarrollo empleado, el índice de riesgos al que sometemos a
nuestro proyecto varía significativamente. Por ejemplo, hay gran diferencia entre optar por un
desarrollo en cascada que por uno iterativo como ilustra la siguiente gráfica:
www.learning.es
33
A la hora de controlar los riesgos, lo primero que debemos conocer es identificar las razones o
motivos por los cuales fallan usualmente los proyectos. En ese sentido cabe decir que:
La calidad de servicio (QoS = Quality Of Service) es un riesgo primario relacionado con la
arquitectura.
El manejo inadecuado de los requerimientos no funcionales, es una de las fuentes más importante
de riesgo en los proyectos:
 Reglas de negocio de alta complejidad.
 Calidades sistémicas
 Seguridad
 Rendimiento
 Escalabilidad
 Disponibilidad
 Extensibilidad
La Lista de Riesgos será desarrollada junto con los Casos de Negocio, los cuales formarán la base
para la decisión de continuar o no con el proyecto. La Lista de Riesgos es mantenida a través de
todo el ciclo de vida del proyecto. Veamos un ejemplo fictíceo de este tipo de Lista de Riesgos,
contemplando en cada uno de dichos riesgos su descripción, probabilidad de que se produzca el
fallo, su impacto cuando ocurra y la respuesta prevista para mitigar su presencia:
Riesgo Descripción Probabilidad Impacto Plan de

mitigación
Ejemplo: El ambiente de desarrollo es ALTA / MEDIA ALTO / * Desarrollar
Windows y el de Producción es / BAJA MEDIO / en maquinas
Diferente UNIX puede haber problemas BAJO virtuales
comportamiento de ambientación * Realizar
entre el deploys y
ambiente de revisiones
desarrollo y de periódicas del
producción sistema en el
ambiente AIX
www.learning.es
Ejemplo: La especificación dice que el BAJA ALTO RESUELTO
servidor de aplicaciones que
El cliente adquirirá el cliente cumple con Se realizaron
propone el uso le especificación XXX y el pruebas de
de un framework necesita de esa operaciones
framework web especificación para poder complejas
open source funcionar. Hay una probabilidad con el
que no ha sido de que el framework no framework 34
probado en el funcione correctamente usando la
servidor final misma
versión y
sistema
operativo del
servidor de
aplicaciones.
Ejemplo: Se está solicitando el tener MEDIO ALTO Se deben
tiempos de respuesta de hacer
Tiempos de máximo 5 segundos para pruebas de
respuesta arriba operaciones de consulta en desempeño
del valor horario pico Es un criterio en el servidor
requerido de de pruebas
Dada la configuración de aceptación usando los
topología red donde se tiene … para la mismos
… liberación elementos de
hardware e
identificar
posibles
cuellos de
botella fuera
de la
aplicación
Esta tabla es un ejemplo y nos ayuda a identificar y prepararnos para saber qué debe hacerse en
caso de que se presente un problema previamente identificado.
Dicha lista de riesgos debe actualizarse y mantenerse durante todo el desarrollo del proyecto.
Planificando la Capacidad del sistema

Uno de los aspect a evaluar dentro de nuestra definición arquitectónica del proyecto es la medición
del crecimiento de espacio en disco por causa de los elementos propios de la aplicación, por la
información empleada o generada, tales como archivos o datos de la base de datos o por el número
de peticiones de clientes considerando las cifras iniciales y las venideras.
Esta recolección de cifras ayudará a determinar qué tipo y cantidad de hardware es necesaria para
soportar las operaciones del sistema en un horizonte de tiempo dado. Para documentar dichas cifras
podemos realizar diferentes pruebas de esfuerzo y registrarlas en tablas similares a las que vemos a
continuación:
Numero de Accesos
www.learning.es
Operaciones Accesos Accesos Accesos Accesos
más concurrentes concurrentes concurrentes concurrentes
demandantes Iníciales, Horario Futuros, Horario
Pico Iníciales, Pico Futuros,
Horario No Horario No
(Operaciones / Pico (Operaciones / Pico
min) min)
(Operaciones / (Operaciones 35
min) / min)
Registro de X 750 200 825 220
Consulta de 300 50 330 55
reportes
Configuración - - 330 55
de catalogos
A 1 año A 1 año
Crecimiento de espacio en Disco Duro

Descripción del Tipo de Cantidad Tamaño al Porcentaje Periodicidad
archivo Archivo inicial (6 final del año semestral
meses) MB (MB)
EARs, Wars de Aplicación
la aplicación
Archivos Archivos
Base de datos Base de
Datos
Log Archivo de
texto
Esquema de Esquema
Base de Datos
Total
Crecimiento de la base de datos
Sobre toda la base de información anterior se realizará una propuesta de solución, indicando el tipo
de sistema a desarrollar:
 Cliente / Servidor
 Multicapa
 Multicapa web
www.learning.es
36
Diagrama de Capas y Filas

Este diagrama es un artefacto de la metodología Sun Tone Methodology que muestra la tecnología a
utilizar en cada una de las capas del sistema y por cada capa define niveles de productos que
participan en la solución. Cada una de las tecnologías elegidas da solución a los requerimientos
detectados durante la fase de Análisis. Podemos ver a continuación un diagrama de ejemplo.
Algunas de las celdas pueden haber sido dadas de inicio por las restricciones tecnológicas del cliente
y las otras se llenan con la propuesta tecnológica del Arquitecto:
www.learning.es
37
Capa de Cliente: Es la capa donde se ejecuta una aplicación de consola, dispositivo móvil, pc
desktop o con navegador web.
Capa de Presentación: Aquí residen los componentes dinámicos de vista y control que generan
una salida HTML, XML y los Reportes que se envían al cliente, por ejemplo JSP, Servlets.
Capa de Negocio: Aquí residen los procesos de negocio, workflow, timers.
Capa de Integración: Aquí residen los componentes que permiten la comunicación al exterior tal
como componentes de acceso a base de datos, web services, correo, colas de mensajes, clientes de
web service, conectores.
Capa de Recursos: Aquí se encuentran todas las fuentes de información externas, tales como
Bases de Datos, sistemas de Archivos, Content Managers, Mainframes.
Diagrama de Componentes
El diagrama de componentes inicial es una propuesta de qué componentes de software intervendrán
en la solución.
Diagrama de Despliegue
El Diagrama de Despliegue inicial nos ayuda a saber con qué otros sistemas interactuarán y
convivirá el nuestro dentro.
Prototipo
Provee una demostración o implementación de principio a fin de los componentes tecnológicos
primarios, demuestra la viabilidad de la solución y sirve como guía para el desarrollo del sistema.
Estos prototipos pueden ser implementaciones base o presentaciones en PowerPoint dependiendo
del nivel de cliente para el cual se desea hacer una prueba.
www.learning.es
Usabilidad
La usabilidad toma en cuenta el tipo de personas que serán usuarios del sistema para
proporcionarles una interfaz de usuario que permita hacer productivo su trabajo y por ninguna
circunstancia dañe su información. En este sentido es necesario al inicio del proyecto hacer pruebas
de usabilidad ya sea con un demo o una presentación que muestre la forma en la que se
interactuará con el sistema.
Principios de Diseño a seguir:
 Visibilidad: Claridad en la información a presentar. 38
 Retroalimentación: Enviar información en respuesta a una acción del usuario.

 Facilidad: Uso de elementos obvios y sencillos para el usuario.
 Simplicidad: Mantener una interfaz simple.
 Estructura: La interfaz de usuario está dispuesta en una forma lógica y con sentido.
 Consistencia: Uniformidad y la navegación hacen fácil el uso
 Tolerancia: La aplicación debe tolerar los errores de usuario, uso de confirmaciones y
mensajes de error.
El realizar esta exploración de los elementos de interfaz de usuario requeridos ayudará a elegir la
tecnología de la capa de presentación que debe usarse desde el inicio del proyecto. No es lo mismo
utilizar simples JSPs que utilizar AJAX, esta diferencia implica requerimientos del servidor de
aplicaciones, de recursos humanos y de costos.
Conclusión
Si bien el Arquitecto de Sistemas es una persona experimentada, su responsabilidad no jugar el rol

de Analista, Diseñador, Líder de Proyecto y Tester al mismo tiempo, más bien tiene como
responsabilidad el asegurar que el sistema sea desarrollado minimizando riesgos tecnológicos y que
el sistema una vez liberado opere sin poner en riesgo los objetivos de negocio para los cuales fue
creado. Para esto es necesario que aplique su experiencia y buenas prácticas de diseño de sistemas.
Así mismo el entregable del Arquitecto no es un "Si" o un "No" a capricho en la elección de la

tecnología a usar. Todo el proceso de análisis, las alternativas de solución y la decisión final deben
estar sustentados y plasmados en un Documento de Arquitectura que documente las decisiones de
diseño y guie el desarrollo.
Ver Video: Riesgo y Diseño de Aplicaciones, en la Unidad 3, en

el Módulo 10, en la plataforma elearning
Actividades
“Recuerde que para un seguimiento óptimo de la unidad es imprescindible realizar las actividades
que encontrará en la unidad correspondiente de la plataforma eLearning”.
www.learning.es
Unidad 4. Arquitectura de la capa de cliente
Introducción
Un cliente Java EE puede ser un cliente Web o una aplicación cliente.
39
Objetivos
 Describir la arquitectura de la capa cliente.
 Entender los distintos tipos de clientes que existen en Java EE.
Clientes Web
Un cliente web consiste en dos partes:
 Una página web dinámica que contiene varios tipos de lenguajes de marcas (HTML, XML y
demás), que son generados por componentes web ejecutándose en la capa web
 Un navegador web que despliega las páginas recibidas del servidor.
Un cliente web, llamado a veces terminal (thin client, cliente ligero, NetPC). Los terminales
usualmente no consultan bases de datos, ejecutan reglas de negocio complejas o conectan a
aplicaciones legadas. Cuando se utiliza un terminal, estas operaciones pesadas son delegadas a los
beans empresariales que se ejecutan en el servidor Java EE que pueden soportar la seguridad,
velocidad, servicios y ofrecer el nivel de confianza de la tecnología Java EE del lado del servidor.
Applets
Una página web recibida de una capa web puede incluir un Applet incrustado. Un Applet es una
pequeña aplicación cliente escrita en el lenguaje de programación Java que se ejecuta en la máquina
virtual de Java en el navegador web. Sin embargo, los sistemas clientes pueden necesitar la
necesidad de un plug-in y posiblemente un fichero con políticas de seguridad para que el Applet se
ejecute con éxito en el navegador web.
Los componentes son la API preferida para crear un programa para cliente web ya que no se
necesitan plug-ins o políticas de seguridad en los sistemas clientes. Los componentes web además
tienen un diseño más limpio y más modular porque estos proporcionan una forma de separa la
programación de la aplicación del diseño de la página web. El personal involucrado en el diseño de la
página no necesita entender la sintaxis del lenguaje de programación Java para hacer su trabajo.
www.learning.es
Aplicaciones cliente
Una aplicación cliente se ejecuta en una máquina cliente y proporciona a los usuarios una forma de
manejar las tareas que requieren una interfase de usuario rica que puede ser proporcionada por un
lenguaje de formato. Normalmente este tiene una interfase gráfica de usuario (GUI) creada con la
API de Swing o AWT, aunque una interfase de línea de comandos ciertamente es posible.
Las aplicaciones cliente acceden directamente a beans empresariales que se ejecutan en la capa de
40
negocio. Sin embargo, si los requerimientos de una aplicación lo exigen, un cliente de aplicación
puede abrir una conexión HTTP para establecer una comunicación con un Servlet que se ejecuta en
la capa web. Los clientes de aplicación escritos en lenguajes diferentes a Java pueden interactuar
con servidores Java EE 5, habilitando la plataforma Java EE 5 a interactuar con sistemas legados,
clientes y lenguajes que no son Java.
Clientes Web
Servlets
Un servlet es una clase java usada para extender las capacidades de los servidores que albergan
aplicaciones accedidas mediante un modelo de programación cliente-servidor.
Los servlets (al igual que los applet) se ejecutan en una caja restringida (sandbox) lo que protege al
servidor de cualquier mal funcionamiento del servlet. Esto permite a los proveedores de Internet
que sus clientes depositen servlets sin temor de que sean maliciosos. Se incrementa la seguridad
respecto a cualquier otra tecnología notablemente.
Al estar escritos en Java, tienen todas las ventajas de este lenguaje (pueden hacer uso de cualquier
paquete de Java). Como es un lenguaje altamente escalable surgirán paquetes de una forma muy
rápida.
Los servlets son portables entre plataformas ("escribir una vez, ejecutar en cualquier lugar"). Los
servidores Web más populares, dicen soportar los servlets.
Los servlets son componentes de la parte del servidor de Java EE, encargados de generar
respuestas a las peticiones recibidas de los clientes.
En la mayoría de las páginas Web se van a introducir los llamados formularios, los cuales sirven para
recoger datos aportados por los clientes. Estos formularios van a ser una mezcla de código HTML y
de Scripts  Son programas que se ejecutan en el servidor y su función fundamental es la de
recoger los datos que el cliente ha introducido a través de un formulario y, en base a ellos,
construir una página dinámicamente para responder a la petición.
Estas páginas se llaman dinámicas porque no van a existir en el disco duro del servidor sino que se
van a generar como respuesta a una petición hecha desde el cliente a través de un formulario.
Estos Scripts aún se usan mucho por varios motivos:

 Se van a encontrar en el servidor por lo que son totalmente independientes del navegador
que use el cliente.
 La respuesta que generar va a ser mucho más rápida debido a su ubicación en el servidor.
www.learning.es
 La seguridad aumenta mucho debido a que los programas van a correr bajo el control directo
del administrador del servidor.
Los Scripts más extendidos son los denominados CGI (Common Gateway Interface). Estos CGI
tienen una gran desventaja: son poco eficientes debido a que el servidor ejecuta una copia de los
mismos por cada petición que le llega.
Así, si el sitio Web es bastante popular, supone una pérdida considerable de rendimiento. Para 41
solventar este problema, los fabricantes han desarrollado alternativas: Microsoft  ISAPI; NetScape
 NSAPI; JavaSoft  Servlets.
Las ventajas de los Servlets en comparación con las CGI son:

 Los Servlets no se van a ejecutar en un proceso separado, por lo que no necesita ejecutarse
cada vez que recibe una petición.
 Una vez que se ha invocado, quedan almacenados en memoria por lo que consumen menos
recursos, aunque se le esté invocando constantemente. Esto significa que una sola instancia
de un Servlet responde a todas las peticiones con lo que, además del ahorro de recursos, se
pueden gestionar, de modo más adecuado, los datos que le llegan.
 Los Servlets van a ser aplicaciones que van a ser ejecutados, al igual que los Applets de
Java, por un motor Servlet en una caja restringida (lo que se conoce con el nombre de
Sandbox) por lo que se aumenta la seguridad enormemente. Los proveedores de Internet,
debido a este motivo, no van a tener ningún temor a que los usuarios puedan introducir
Servlet en el servidor, ya que se encuentran protegidos frente a código malicioso.
 Al estar escritos en Java, tienen todas las ventajas de este lenguaje (pueden hacer uso de
cualquier paquete de Java). Como es un lenguaje altamente escalable surgirán paquetes de
una forma muy rápida (por ejemplo, ya existen paquetes para la gestión de documentos
XML).
 Los Servlets son portables entre plataformas (siguen la premisa de Java "escribir una vez,
ejecutar en cualquier lugar"). Netscape, Apache e IIS, los tres servidores Web más
populares, soportan los Servlets.
Java Server Pages (JSPs)

Los servlets generan siempre toda la página, en muchos casos casi toda la página es estática. La
solución Java Server Pages (JSPs):
 Permite mezclar tanto de HTML estático
 Contenido dinámico generado por servlets
 Ampliamente soportado por plataformas y servidores Web
 Acceso completo a servlets y tecnologías Java (JavaBeans, etc.) en la parte dinámica
 Las JSP son convertidas por el servidor en servlets la primera vez que se usan o se
despliegan.
Las JavaServer Pages (JSP) permiten separar la parte dinámica de tus páginas de la parte HTML
estática. Para ello, basta con:
 Escribir la parte estática HTML de la manera habitual.
 Encerrar el código Java que genera la parte dinámica de la página entre unos delimitadores
especiales, la mayoría de los cuales empiezan por y terminan con .
 Si quieres tener en la salida estática HTML el conjunto de caracteres debes poner o
bien usar <%.
En esta imagen podemos apreciar las directivas que utilizaremos en aplicaciones JSP:
www.learning.es
42
Una página JSP cuando se ejecuta el servidor de base de datos genera un servlet. El ejemplo anterior generará
un servlet como el de la imagen siguiente:
El motor de las páginas JSP está basado en los servlets de Java -programas en Java destinados a ejecutarse en
el servidor-, aunque el número de desarrolladores que pueden afrontar la programación de JSP es mucho mayor,
dado que resulta mucho más sencillo aprender que los servlets.
En JSP creamos páginas de manera parecida a como se crean en ASP o PHP -otras dos tecnologías de servidor-.
Generamos archivos con extensión .jsp que incluyen, dentro de la estructura de etiquetas HTML, las sentencias
Java a ejecutar en el servidor. Antes de que sean funcionales los archivos, el motor JSP lleva a cabo una fase de
traducción de esa página en un servlet, implementado en un archivo class (Byte codes de Java). Esta fase de
traducción se lleva a cabo habitualmente cuando se recibe la primera solicitud de la página .jsp, aunque existe la
opción de precompilar en código para evitar ese tiempo de espera la primera vez que un cliente solicita la página.
Applet
La definición más extendida de applet es "una pequeña aplicación accesible en un servidor de
Internet, que se transporta por la red, se instala automáticamente y se ejecuta in situ como parte
de un documento web".
Un Applet es un pequeño programa que no puede correr por sí mismo, sino que tiene que estar
incluido en alguna aplicación que le dé soporte. Por ejemplo, un navegador o un visualizador de
applets.
La clase Applet (aquella es la que podemos encontrar las funcionalidades de los applet) hereda
directamente de Panel. Por tanto, su contenedor por defecto es un Panel y podemos usar todos los
métodos de dicha clase y de sus superclases (Container, Component, Object).
Cualquier Applet que diseñemos debe heredar de la clase Applet. Su código básico asociado es el
siguiente:
import java.awt.*;
import java.applet.*;
public class MyApp extends Applet
{
www.learning.es
public void init(){
// Este método se llama automáticamente cuando se carga el Applet en el sistema.
// Lo llama el navegador o el visor de applets.
// Sólo se llama una vez con lo cual se usará para inicializar al Applet.
//¿Cuándo se inicia un applet? Cuando se carga la página desde la cual se le
//hace referencia.
// En este método se suele:
Fijar el tamaño del applet. 43
Cargar imágenes y sonidos.
Asignar valores a las variables globales que se usen.
}
public void start(){
//Llamado por el navegador o visor de applets cuando se desea comenzar la ejecución del mismo.
//Se llama la primera vez que se carga, tras el init y posteriormente cuando
//el applet necesita ser arrancado de nuevo. Normalmente se arranca el
//applet cada vez que se expone a la vista.
}
public void stop(){
// Lo llama el visor del applet o el navegador cuando el applet para su ejecución.
//¿Cuándo el applet para su ejecución? Normalmente cuando desaparece del
//campo de visión.
}
public void destroy(){

//Llamado por el navegador o visor de applets cuando el applet debe ser eliminado y todos
//los recursos que ocupa liberados.
}
public void paint(Graphics g)
{
//Este método es llamado por el sistema de forma automática cuando considera que el applet
necesita ser repintado.
//En dicho método debemos colocar todo el contenido gráfico del Applet.
g.drawString("Hello World", 20, 20);
}
}
No es obligatorio escribir los métodos init(), start(), stop() y destroy() porque la clase Applet realiza
una implementación por defecto para todos ellos. La implementación por defecto no hace nada, por
tanto, los deberemos sobreescribir cuando lo necesitemos.
Invocando a un applet desde páginas HTML

Para invocar a un applet desde una página HTML se recurre al siguiente tag.
<APPLET codebase=.. code="Graficos/Miapplet.class" width=350 height=200 name=...>



<PARAM name=... value=....>

<PARAM name=... value=... >
</APPLET>
www.learning.es
Métodos de la clase Applet.
AppletContext getAppletContext()
Obtiene el contexto del Applet. Ver la clase AppletContext para saber los
métodos que podemos usar sobre un objeto de este tipo.
String getAppletInfo()
Devuelve información acerca del applet.
44
AudioClip getAudioClip(URL url) Devuelve el objeto de tipo AudioClip especificado en la URL.
Posteriormente se puede reproducir con los métodos play() o loop().
AudioClip getAudioClip(URL url, String name) Devuelve el objeto AudioClip que resulta de la
composición de la URL y del string especificados.
URL getCodeBase() Obtiene el campo codebase del applet. Este campo es uno de los
atributos que se usan en la llamada a un applet desde una página HTML. El
codebase lo obtiene en forma de objeto URL.
URL getDocumentBase() Obtiene la base del documento desde el que se llama al
applet, en formato URL.
Image getImage(URL url)
Devuelve un objeto imagen que puede ser pintado sobre la pantalla.
Image getImage(URL url, String name)
Otra forma de obtener una imagen.
String getParameter(String name)
Obtiene el valor del parámetro especificado. Estos parámetros se le pasan al
applet desde la página HTML mediante el tag
String[][] getParameterInfo()
Devuelve información sobre los parámetros que se le han pasado al applet.
boolean isActive()
Determina si el applet está activo.
static newAudioClip(URL url)
AudioClip Devuelve un nuevo audioclip desde la URL especificada.
void play(URL url)
Reproduce el audioclip especificado en la URL.
void play(URL url, String name)
Otra forma de reproducir un audioclip.
void print (Graphics g)
Imprime en impresora el contenido del applet.
void resize(Dimension d)
Petición de que el applet sea redimensionado. Ver la clase Dimension.
void resize(int width, int height)
Otra forma de pedir que el applet sea redimensionado.
void showStatus(String msg)
Muestra el string en la ventana de estado del navegador.
Aplicaciones cliente
Las aplicaciones cliente suele ser una interfase gráfica de usuario (GUI) creada con la API de Swing
o AWT, y pudiera ser una aplicación que se ejecute desde la línea de comandos.
La base de la programación gráfica se encuentra en estos dos elementos físicos del ordenador, los
cuales se diseñaron de forma conjunta con el propósito de presentar información al usuario. El
comprender su funcionamiento ayuda a conocer lo que estamos haciendo cuando diseñamos un
entorno gráfico.
En una estructura AWT hay que destacar varios elementos dentro del sistema gráfico de Java.
www.learning.es
Elemento Descripción
Gestores de trazado Modos predefinidos de colocación de los componentes y/o contenedores.
(Layout) El AWT dispone de los siguientes modos:
- FlowLayout, BorderLayout, GridLayout, GridBagLayout, CardLayout,
AbsoluteLayout.
Contenedores Objetos capaces de contener componentes básicos. El AWT dispone de los
siguientes contenedores:
- Window, Frame, Panel, Dialog. 45
Componentes Controles básicos que dan funcionalidad al interfaz gráfico. El AWT
dispone de:
- Label, Button, TextField, TextArea, Checkbox, Choice, List, Scrollbar,
Panel, Canvas, MenuBar y PopupMenu.
Eventos Acciones que se pueden realizar sobre los componentes o los
contenedores y que pueden ser recogidos por las aplicaciones.
Swing hay que verlo como una extensión de AWT, por tanto, no hay que olvidar lo aprendido en
AWT. Es más, en la mayoría de los casos es suficiente con añadir una "J" al componente AWT para
que se convierta en un componente Swing.
En Swing, los componentes de la interfaz gráfica son Beans. Todos los componentes son "ligeros"
(lightweight), es decir, ya no se usan componentes dependientes del sistema operativo.
Se utiliza sólo el nuevo modelo de Delegación de eventos.
Son muchas las ventajas que ofrece el uso de Swing:

 La navegación con el teclado es automática, es decir, cualquier aplicación Swing se puede
usar sin el ratón sin tener que añadir líneas de código adicionales.
 Las etiquetas de información ("tool tips") se pueden crear con una sola línea de código. Estas
etiquetas de información son las que aparecen cuando nos situamos con el ratón sobre un
componente del interfaz gráfico.
Con respecto al AWT, Swing incorpora muchos aspectos que permiten mejorar el entorno gráfico.
Paquete javax.swing
Las clases principales de Swing se encuentran en este paquete.
Tenemos que seguir distinguiendo entre Gestores de trazado, Contenedores y Componentes.
A continuación pasamos a describir las nuevas clases agrupadas según lo que sean:
Sumario de clases del paquete javax.swing
BoxLayout Un gestor de trazado nuevo que permite a múltiples
componentes ser colocados según un eje horizontal o vertical.
JRootPane El componente fundamental en la jerarquía de contenedores.
JWindow Una representación de una ventana.
JApplet Una versión extendida de java.applet.Applet que añade nuevas
funcionalidades, por ejemplo, pueden añadirse barras de menú de
Swing.
JDialog La clase principal para crear una ventana de diálogo.
JFrame Una versión extendida de java.awt.Frame que añade funcionalidades
extras.
JPanel JPanel es un contenedor ligero genérico.
JInternalFrame Un objeto ligero que proporciona muchas de las características de
una ventana nativa, incluyendo "pinchar y arrastrar", cerrado,
iconizado, redimensionado, título y barra de menú.
JComponent La clase base para los componentes Swing.
www.learning.es
AbstractButton Define el comportamiento común de las clases JButton,
JToggleButton, JCheckbox y JRadioButton. Es una clase abstracta y,
por tanto, no pueden crearse objetos.
AbstractListModel La definición abstracta para el modelo de datos que proporciona una
lista con sus contenidos.
JButton Un botón Swing.
JCheckBox Un CheckBox Swing.
JRadioButton Una implementación de un botón tipo radio 46
JToggleButton Una implementación de un botón de dos estados.

ButtonGroup Esta clase permite crear un grupo de botones con exclusión múltiple.
JLabel Un área para visualizar un texto corto, una imagen o ambos.
JComboBox Implementación de Swing de un ComboBox -- Un ComboBox es una
combinación de una caja de tecto y una lista desplegable que permite
a un usuario o introducir un valor mediante teclado o seleccionar de
la lista.
JList Un componente que permite al usuario seleccionar uno o más objetos
de una lista.
ImageIcon Una implementación del interface Icon que permite pintar iconos a
partir de imágenes.
JTextField Una implementación de una caja de texto..
JPasswordField JPasswordField es un campo de texto tipo password.
JTextArea Una implementación de un textarea.
JScrollPane Un contenedor que permite añadir barras de desplazamiento a otros
componentes.
JProgressBar Un componente que representa un valor entero dentro de un
intervalo limitado.
JSlider Un componente que permite al usuario seleccionar gráficamente un
valor desplazando una barra dentro de un intervalo.
JMenuBar Una implementación de una barra de menú.
JMenu Una implementación de un menú.
JMenuItem Una implementación de un MenuItem.
JPopupMenu Una implementación de un menú emergente
JRadioButtonMenuItem Una implementación de un item de menú tipo radio.
JCheckBoxMenuItem Un item de un menú Swing que puede ser seleccionado o no.
JSeparator Una implementación de un separador de opciones de menú.
JToolBar Una implementación de una barra de herramientas.
JColorChooser Esta clase proporciona un panel de controles diseñado para permitir
al usuario manipular y seleccionar un color.
JFileChooser JFileChooser proporciona un mecanismo simple para seleccionar un
fichero.
JOptionPane JOptionPane facilita el despliegue de una caja de diálogo estándar
que pregunta al usuario acerca de un valor o le informa de algo.
JEditorPane Un componente de texto para editar diversas clases de contenidos.

JTextPane Un componente de texto con capacidad de representación gráfica.
JScrollBar Una implementación de una barra de desplazamiento.
JTabbedPane Un componente que permite al usuario desplazarse entre un grupo
de componentes pulsando el tabulador con un título y/o icono dado.
JSplitPane JSplitPane se usa para dividir dos (y sólo dos) componentes.
JTable JTable es un componente que permite presentar datos en formato de
tabla de dos dimensiones.
JTree Un control que visualiza un conjunto de datos organizados
jerarquicamente en forma de árbol.
www.learning.es
Ver Video: Arquitectura de la capa cliente, en la Unidad 4, en
el Módulo 10, en la plataforma elearning
Laboratorio: Ejemplo página JSP como capa cliente 47
Objetivo
Crear una página JSP como ejemplo de capa cliente.
Enunciado
- Realizar una página JSP que envíe información sobre si misma al pulsar sobre un botón.
- Cuando enviemos información, mostraremos en una etiqueta DIV los elementos seleccionados.
- Para completar la práctica, debemos dejar marcados los elementos que el usuario haya
seleccionado en nuestra página.
<%@page contentType="text/html" pageEncoding="UTF-8"%>

<%@page import="java.util.*"%>
<html>
<head>
<title>JSP Page</title>
</head>
<body>
<%String[] datos=request.getParameterValues("chkfruta");%>
<%Vector<String> vfrutas = new Vector<String>();%>
<%String[] frutas = new String[] {"Coco","Mandarina","Papaya","Platano"};%>
<table border="1">
<form name="form1" action="index.jsp" method="post">
<%
if (datos==null)
{
for (int i=0;i<frutas.length;i++)
{%>
<tr><td><input type="checkbox" name="chkfruta"
value="<%=frutas[i]%>"><%=frutas[i]%></td></tr>
<%}
}else{
for (int i=0;i<datos.length;i++)
{
vfrutas.add(datos[i]);
}
for (int i=0;i<frutas.length;i++)
{
www.learning.es
if (vfrutas.indexOf(frutas[i])==-1)
{%>
<tr><td><input type="checkbox" name="chkfruta"
<%}else{%>
<tr><td><input type="checkbox" name="chkfruta" checked
<%}%> 48
<%}
}%>
<tr><td><input type="submit" name="btnenviar" value="Enviar Datos"></td></tr>
</form>
</table>
<%
if (datos!=null)
{
for (int i=0;i<datos.length;i++)
{%>
<div style="background-color:fuchsia">
Elementos seleccionados:<%=datos[i]%>
</div>
<%}
}
%>
</body>
</html>
Actividades
www.learning.es
Unidad 5. Arquitectura de la capa web
Introducción
La estrategia tradicional de utilizar aplicaciones compactas causa gran cantidad de problemas de 49
integración en sistemas software complejos como pueden ser los sistemas de gestión de una
empresa o los sistemas de información integrados consistentes en más de una aplicación. Estas
aplicaciones suelen encontrarse con importantes problemas de escalabilidad, disponibilidad,
seguridad, integración...
Para solventar estos problemas se ha generalizado la división de las aplicaciones en capas que
normalmente serán tres: una capa que servirá para guardar los datos (base de datos), una capa
para centralizar la lógica de negocio (modelo) y por último una interfaz gráfica que facilite al usuario
el uso del sistema.
Objetivos
 Describir la arquitectura de la capa web.
 Entender los componentes que intervienen en una arquitectura web.
Arquitectura web de 3 capas

Mantener el número de capas en 3, como se ve en la figura, integrando interfaz web y modelo en
un mismo servidor aunque conservando su independencia funcional. Ésta es la distribución en capas
más común en las aplicaciones web.
Arquitectura web de 4 capas

Crear un modelo de 4 capas, tal y como puede verse en la figura, separando cliente, servidor web,
modelo y almacén de datos. Esto nos permite una mayor extensibilidad en caso de que existan
también clientes no web en el sistema, que trabajarían directamente contra el servidor del modelo.
www.learning.es
Tecnologías web
En la tabla siguiente se muestran los diferentes servicios J2EE estándar y los aspectos de aplicación
correspondiente los que resuelven.
50
J2EE estándar de los servicios
J2EE services J2EE Application aspect Aplicación

servicios
EJB EJB Distribuido modelo de programación de componentes
Soporte para la persistencia, transacciones, y la seguridad
JSP JSP Manejo y procesamiento de las solicitudes y respuestas HTTP
Para generar contenido dinámico en lenguajes de marcado basados en
texto, tales como HTML, XML, WML, y SVG
Servlets Servlets Manejo y procesamiento de las solicitudes y respuestas HTTP
Para el manejo de datos textuales y envío de solicitudes
JMS JMS Para comunicarse con el middleware orientado a mensajes (MOM) los
productos de una manera genérica
Para la comunicación de acoplamiento flexible
Para la comunicación asíncrona y fiable entre los componentes de la
empresa y los sistemas heredados
JDBC JDBC Para acceder a los almacenes de datos de una manera genérica
JNDI JNDI Para acceder a nombres de directorios y servicios de una manera genérica
JAXP JAXP Para analizar y transformar documentos XML en forma genérica
RMI-IIOP RMI- La sencillez del lenguaje Java y la interoperabilidad con CORBA es
IIOP necesario
Java IDL Java IDL Para invocar objetos externos utilizando CORBA IIOP
JTA/JTS JTA / JTS Delimitar las transacciones de una manera genérica independiente de la
aplicación gestor de transacciones
JavaMail JavaMail marco independiente de la plataforma e independiente del protocolo para
construir aplicaciones de correo y de mensajería
JCA JCA Para el desarrollo de adaptadores de acoplamiento activo de recursos que
apoyen el acceso a EIS
www.learning.es
MVC
MVC es un modelo de diseño estándar con el que están familiarizados muchos desarrolladores.
El marco de MVC incluye los componentes siguientes:

 Modelos. Los objetos de modelo son las partes de la aplicación que implementan la lógica del
dominio de datos de la aplicación. A menudo, los objetos de modelo recuperan y almacenan
51
el estado del modelo en una base de datos. Por ejemplo, un objeto Product podría recuperar
información de una base de datos, trabajar con ella y, a continuación, escribir la información
actualizada en una tabla Productos de una base de datos de SQL Server. En las aplicaciones
pequeñas, el modelo es a menudo una separación conceptual en lugar de física. Por ejemplo,
si la aplicación solo lee un conjunto de datos y lo envía a la vista, la aplicación no tiene un
nivel de modelo físico y las clases asociadas. En ese caso, el conjunto de datos asume el rol
de un objeto de modelo.
 Vistas. Las vistas son los componentes que muestra la interfaz de usuario de la aplicación.
Normalmente, esta interfaz de usuario se crea a partir de los datos de modelo. Un ejemplo
sería una vista de edición de una tabla Productos que muestra cuadros de texto, listas
desplegables y casillas basándose en el estado actual de un objeto Product.
 Controladores. Los controladores son los componentes que controlan la interacción del
usuario, trabajan con el modelo y por último seleccionan una vista para representar la
interfaz de usuario. En una aplicación MVC, la vista solo muestra información; el controlador
administra y responde a los datos proporcionados por el usuario y su interacción. Por
ejemplo, el controlador administra los valores de la cadena de consulta y pasa estos valores
al modelo, que a su vez podría utilizarlos para consultar la base de datos.
El modelo de MVC ayuda a crear aplicaciones que separan los aspectos diferentes de la aplicación
(lógica de entrada, lógica comercial y lógica de la interfaz de usuario), proporcionando un
acoplamiento entre estos elementos.
El modelo especifica dónde se debería encontrar cada tipo de lógica en la aplicación. La lógica de la
interfaz de usuario pertenece a la vista. La lógica de entrada pertenece al controlador. La lógica
comercial pertenece al modelo.
Esta separación ayuda a administrar la complejidad al compilar una aplicación, ya que permite
centrarse en cada momento en un único aspecto de la implementación.
Componentes del modelo

Corresponden a la lógica del negocio con el cual se comunica la aplicación web. Usualmente el
modelo comprende accesos a Bases de Datos o sistemas que funcionan independientemente de la
aplicación web.
Componentes del control

Los componentes de control son los encargados de coordinar las actividades de la aplicación, que
van desde la recepción de datos del usuario, las verificaciones de forma y la selección de un
componente del modelo a ser llamado. Por su parte los componentes del modelo envían al control
sus eventuales resultados y/o errores de manera de poder continuar con otros pasos de la
aplicación.
Esta separación simplifica enormemente la escritura tanto de vistas como de componentes del
modelo: Las páginas JSP no tienen que incluir manejo de errores, mientras que los elementos del
control simplemente deciden sobre el paso siguiente a seguir.
www.learning.es
Entre las características de Struts se pueden mencionar:
 Configuración del control centralizada.
 Interrelaciones entre Acciones y página u otras acciones se especifican por tablas XML en
lugar de codificarlas en los programas o páginas.
 Componentes de aplicación, que son el mecanismo para compartir información
bidireccionalmente entre el usuario de la aplicación y las acciones del modelo.
52
 Librerías de entidades para facilitar la mayoría de las operaciones que generalmente realizan
las páginas JSP.
 Struts contiene herramientas para validación de campos de plantillas. bajo varios esquemas
que van desde validaciones locales en la página (en javaScript) hasta las validaciones de
fondo hechas a nivel de las acciones.
 Struts permite que el desarrollador se concentre en el diseño de aplicaciones complejas como
una serie simple de componentes del Modelo y de la vista intercomunicados por un control
centralizado. Diseñando de esta manera se debe obtener una aplicación más consistente y
más fácil de mantener.
Componentes de la vista
La parte de la Vista de una aplicación basada en Struts generalmente está construida usando
tecnología JavaServer Pages (JSP). Las págnas JSP pueden contener texto HTML estático (o XML)
llamado "plantilla de texto", además de la habilidad de insertar contenido dinámico basado en la
interpretación (en el momento de solicitud de la página) de etiquetas de acción especiales. El
entorno JSP incluye un conjunto de etiquetas estándard, como Además, hay una
facilidad estándard para definir nuestras propias etiquetas, que están organizadas en "librerías de
etiquetas personalizadas".
Struts incluye una extensa librería de etiquetas personalizadas que facilitan la creación de interfaces
de usuario que están completamente internacionalizados, y que interactúan amigablemente con
beans ActionForm que son parte del Modelo del sistema. El uso de estas etiquetas se explica más
adelante en detalle.
Además de las páginas JSP y la acción y las etiquetas personalizadas que contienen, normalmente
los objetos de negocio necesitan poder dibujarse a sí mismos en HTML (o XML), basándose en su
estado actual en el momento de la solicitud. La salida renderizada desde dichos objetos puede
incluirse fácilmente en una página JSP resultante usando la etiqueta de acción estándar
Enterprise Java Beans (EJB) es una plataforma para construir aplicaciones de negocio portables,
reutilizables y escalables usando el lenguaje de programación Java.
Desde el punto de vista del desarrollador, un EJB es una porción de código que se ejecuta en un
contenedor EJB, que no es más que un ambiente especializado (runtime) que provee determinados
componentes de servicio.
Los EJBs pueden ser vistos como componentes, desde el punto de vista que encapsulan
comportamiento y permite reutilizar porciones de código, pero también pueden ser vistos como un
framework, ya que, desplegados en un contenedor, proveen servicios para el desarrollo de
aplicaciones empresariales, servicios que son invisibles para el programador y no ensucian la lógica
de negocio con funcionalidades trasversales al modelo de dominio.
En la especificación 3.0, los EJB no son más que POJOs (clases planas comunes y corrientes de
Java) con algunos poderes especiales implícitos, que se activan en tiempo de ejecución (runtime)
cuando son ejecutados en un contenedor de EJBs.
www.learning.es
Componentes EJB
Con la tecnología Enterprise JavaBeans es posible desarrollar componentes (enterprise beans) que
luego podemos reutilizar y ensamblar en distintas aplicaciones que implementemos en la empresa.
Por ejemplo, podriamos desarrollar un bean Cliente que represente un cliente en una base de datos.
Dicho vean Cliente podríamos usarlo, posteriormente, en un programa de agenda o en una
aplicación de comercio electrónico o virtualmente en cualquier programa en el que se necesite
representar un cliente. 53
Con esta tecnología, podemos separar las capas, llegando incluso a ser posible que el desarrollador
del bean y el ensamblador de la aplicación no fueran la misma persona, o ni siquiera trabajaran en
la misma empresa.
El desarrollo basado en componentes promete un paso más en el camino de la programación

orientada a objetos.
Con la programación orientada a objetos podemos reutilizar clases, pero con componentes es
posible reutilizar un mayor nivel de funcionalidades e incluso es posible modificar estas
funcionalidades y adaptarlas a cada entorno de trabajo particular sin tocar el código del componente
desarrollado.
El contenedor de componentes se denomina contenedor EJB y es algo así como el sistema operativo
en el que éstos residen.
Cuando se utilizan componentes en un marco de trabajo, debemos prestar atención tanto al

desarrollo de los beans como a los descriptores de despliegue que comunican nuestro trabajo con el
contenedor.
Debemos recordar que un descriptor de despliegue ofrece la información del componente a nuestro
contenedor EJB y a nuestro entorno de trabajo (bases de datos, arquitectura de la aplicación, etc.).
El despliegue se define de forma declarativa, mediante un fichero XML (descriptor del despliegue,
deployment descriptor) en el que se definen todas las características del bean o con anotaciones.
El funcionamiento de los componentes EJB se basa fundamentalmente en el trabajo del contenedor

EJB.
El contenedor EJB es un programa Java que trabaja en el servidor y que contiene todas las clases y
objetos necesarios para el correcto funcionamiento de los EJBs.
Los servicios que ofrece un contenedor de EJBs son los siguientes:
 Integración: Proveen una forma de acoplar en tiempo de ejecución diferentes componentes,

mediante la simple configuración de anotaciones xml. La integración es un servicio que
proveen los beans de sesión y los MDBs.
 Pooling: El contenedor de EJBs crea para componentes EJB un pool de instancias que es
compartido por los diferentes clientes. Aunque cada cliente visualiza el entorno como si
recibiera siempre instancias diferentes de los EJB, el contenedor está constantemente
reutilizando objetos para optimizar memoria. El pooling es un servicio que se aplica a los
Stateless Session Beans y a los MDBs.
 Thread-safely: El programador puede escribir componentes del lado del servidor como si
estuviera trabajando en una aplicación sencilla con un solo thread (hilo). El contenedor se
encarga de que los EJBs tengan el soporte adecuado para una aplicación multi-usuario (como
www.learning.es
son en general las aplicaciones empresariales) de forma transparente, asegurando el acceso
seguro, consistente y alto rendimiento. Se aplican a los beans de sesión y a los MDBs.
 Administración de Estados: El contenedor de EJBs almacena y maneja el estado de un

Stateful Session Bean de forma transparente, lo que significa que el programador puede
mantener el estado de los miembros de una clase como si estuviera desarrollando una
aplicación de escritorio ordinaria. El contenedor manipula los detalles de las sesiones. 54
 Mensajería: Mediante los MDBs es posible desacoplar por completo dos componentes para
que se comuniquen de forma asincrónica, sin reparar demasiado en los mecanismos de la
JMS API que los MDBs encapsulan.
 Transacciones: EJB soporta el manejo de transacciones declarativas que permiten agregar

comportamiento transaccional a un componente simplemente usando anotaciones xml de
configuración. Esto significa que cuando un método de un EJB (Session Bean o MDB) se
completa normalmente, el contenedor se encargará de finalizar la transacción y validar los
cambios que se realizaron en los datos de forma permanente. Si algo fallara durante la
ejecución del método (una excepción o cualquier otro problema), la transacción haría un
rollback y es como si el método jamás se hubiera invocado.
 Seguridad: EJB soporta integración con la Java Authentication and Authorization Service
(JAAS) API, haciendo casi transparente el manejo transversal de la seguridad. Se aplica a
todos los Session Beans.
 Interceptors: EJB introduce un framework liviano y simple para AOP (programación

orientada a aspectos). No es tan robusto y completo como otros, pero es lo suficientemente
útil para que sea utilizado por los demás servicios del contenedor para brindarnos de forma
invisible los crosscutting concerns de seguridad, transacciones, thread-safely.
 Acceso Remoto: Es posible acceder de forma remota a distintos EJBs de forma sencilla,
simplemente mediante la Inyección de Dependencia. El procedimiento para inyectar un
componente local o uno remoto es exactamente el mismo, abstrayéndonos de las
complicaciones específicas de RMI o similares. Este servicio aplica únicamente a los Session
Beans.
 Web Services: Un Stateless Session Bean puede publicar sus métodos como servicios web
mediante una sencilla anotación.
 Persistencia: EJB 3 provee la especificación JPA para el mapeo de objetos llamados

Entidades a tablas o POJOs.
Aquí tenemos un gráfico que mostraría la representación de EJB dentro de un módulo web.
www.learning.es
55
Tipos de beans
Existen tres tipos de beans definidos, cada uno implementa unas características diferentes y
permiten ser combinados entre si.
Beans de Sesión (Session Beans)

En una aplicación típica, dividida en grandes capas (presentación, lógica de negocio, persistencia y
base de datos), los Beans de Sesión viven en la lógica de negocio.
Hay dos grandes tipos de Beans de Sesión:

Stateless (sin estado)
Stateful (con estado)
Stateless no conserva el estado de ninguno de sus atributos de la invocación de un método a otro.

Stateful conserva el estado a lo largo de toda una sesión. Los Beans de Sesión Stateless son los
únicos que pueden exponerse como servicios web.
Los beans de sesión son invocados por el cliente con el propósito de ejecutar operaciones de negocio
específicas, como por ejemplo podría ser mostrar todos los datos de una determinada tabla.
El nombre sesión implica que la instancia del bean estará disponible durante una unidad de trabajo
(unit of work) y no sobrevivirá a una caída del servidor.
Un bean de sesión sirve para modelar cualquier funcionalidad lógica de una aplicación y se utilizan
para realizar acciones y representar propiedades de objetos.
Message-Driven Beans (MDBs)

Viven en la lógica de negocio y los servicios que proveen son parecidos a los Beans de Sesión, con la
diferencia de que los MDBs son usados para invocar métodos de forma asincrónica.
Cuando se produce la invocación de un método de un MDB desde un cliente, la llamada no bloquea

el código del cliente y el mismo puede seguir con su ejecución, sin tener que esperar
indefinidamente por la respuesta del servidor.
Los MDBs encapsulan el popular servicio de mensajería de Java, Java Message Service (JMS).
Los MDBs también procesan lógica de negocio, pero un cliente nunca invoca a un método de un MDB
directamente.
El sistema de mensajería asincrónica propone la utilización de una capa intermedia en la

comunicación entre el creador y el consumidor del mensaje.
En EJB 3, esta capa se llama MOM (Message-oriented Middleware).
www.learning.es
Básicamente, MOM es un software que permite funcionar como servidor de mensajería, reteniendo
los mensajes del productor y enviándolos posteriormente al consumidor en el momento en que esté
disponible para recibirlo.
Beans de Entidad (Entities)

Las entidades viven en la capa de persistencia y son los EJBs que manejan Java Persistence API
(JPA), también parte de la especificación de EJB 3.0.
56
Las entidades son POJOs con cierta información metadata que permite a la capa de persistencia
mapear los atributos de la clase a las tablas de la base de datos y sus relaciones.
Existen dos tipos BMP y CMP según se gestione la persistencia por parte del bean o del contenedor.
Los EJB de entidad están directamente relacionados con los datos de la aplicación, son objetos que
mantienen en memoria los datos que maneja la aplicación, las entidades que disponen de
persistencia.
Los Beans de Entidad normalmente mapean (mantienen una relación en memoria) las tablas de
una base de datos relacional, aunque también es posible que mantengan la persistencia de los datos
en ficheros, como por ejemplo un xml.
En cualquiera de los casos el objetivo de un Bean de Entidad es almacenar los datos en memoria
desde una fuente persistente y mantener una sincronización total entre el estado de los datos entre
la memoria y la fuente de datos.
Por esta razón se dice que los Beans de Entidad son los EJB que sobreviven a caídas del sistema, ya
que en caso de un fallo del sistema, los datos que hay en memoria estarían guardados en el
dispositivo persistente, como por ejemplo la base de datos, con lo cual, cuando se reinicie el
servidor se recuperarán sin ningún problema.
La especificación Enterprise JavaBeans está escrita para diferentes públicos, pero podría resumirse
en dos niveles diferentes:
El desarrollador del cliente

Un cliente es cualquier usuario de un Enterprise JavaBean y podria ser cualquier aplicación Java del
lado del cliente, un servlet o incluso otro EJB.
Un programador del lado del cliente que diseña una aplicación Web o utilice un servlet para
establecer la comunicación con un EJB, necesita comprender como se accede a los EJB y como se
utilizan.
En proyectos de grandes dimensiones, es bastante probable que el programador Web y el

programador EJB sean personas distintas.
El programador cliente tiene menos preocupaciones que un desarrollador bean en cuanto al uso de
EJB.
Necesitan saber como encontrar o crear un bean, como utilizar sus métodos y cómo liberar sus
recursos.
Un cliente siempre utiliza el mismo procedimiento para la creación de objetos, búsquedas e

invocación de métodos, independientemente de como se implemente un EJB determinado.
El cliente no necesita preocuparse sobre la implementación del EJB, solamente debe tener en cuenta
las acciones o propiedades del bean para representar los elementos en las páginas.
www.learning.es
El desarrollador EJB
La principal responsabilidad del programador de un bean será escribir la lógica de empresa y
acciones o propiedades.
Siempre que sea posible, la especificación Enterprise JavaBeans intenta abstraer a los
programadores de un bean de cualquier tarea de nivel de sistema.
El programador de un bean debe estructurar su código de una forma determinada. 57

No importa el tipo de EJB que se esté desarrollando, normalmente deben crearse archivos de clase
primarios y un descriptor xml o bien, incluir anotaciones en las clases del bean.
También podríamos tener clases Java adicionales que apoyen la operación del bean, clases de ayuda
que implementen la lógica de negocio.
Todos estos archivos estarían empaquetados en un JAR, ya hemos visto que es la unidad estándar
de empaquetado de clases de Java.
Podriamos tener muchos beans dentro de un único archivo JAR, pero cada archivo JAR contendría
únicamente descriptor del bean xml.
El descriptor de implementación debe situarse en un directorio especifico, de forma que el

contenedor EJB sabría donde buscarlo.
Este directorio se llama META- INF y no podemos cambiarle el nombre, sigue una especificación
estándar.
Aquí podemos visualizar la implementación del uso de un EJB dentro de un entorno de desarrollo,
independientemente que sea realizada la llamada desde un navegador o desde una aplicación Java.
Ver Video: Arquitectura de la Capa Web, en la Unidad 5,

Laboratorio: Arquitectura Capa Web con MVC

Objetivo
Realizar el esqueleto de una aplicación MVC con Struts.
Enunciado
- Abrir un proyecto Struts y añadir dos ficheros de tipo Struts Action y Struts ActionForm
Beans.
- En la página jsp insertaremos etiquetas de la librería de Struts html para enlazar la página al
modelo y al controlador.
Clase Action
Las subclases de la Clase Action se ejecutan en respuesta a una petición de un usuario.
Las subclases de Action desempeñan el siguiente papel:

 Interactuar con el modelo
 Controlar el flujo de navegación a la vista (en este caso página JSP) que corresponda
www.learning.es
Class Name: TiendaAction
Package: paqActions
Action Path: /Tienda
58
Como podemos observar, en el fichero struts-config.xml, el asistente de NetBeans ha añadido el

elemento
<action-mappings>
<action input="/TiendaForm.jsp" name="TiendaActionForm" path="/Tienda" scope="session"
type="pqActions.TiendaAction"/>
<action path="/Welcome" forward="/welcomeStruts.jsp"/>
</action-mappings>
Nos crea el esqueleto de la Clase TiendaAction:
package pqActions;
import javax.servlet.http.HttpServletRequest;
www.learning.es
import javax.servlet.http.HttpServletResponse;
import org.apache.struts.action.Action;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionMapping;
import org.apache.struts.action.ActionForward;
public class TiendaAction extends org.apache.struts.action.Action {

59
private final static String SUCCESS = "success";
public ActionForward execute(ActionMapping mapping, ActionForm form,

HttpServletRequest request, HttpServletResponse response)
throws Exception {
return mapping.findForward(SUCCESS);
}
}
Actividades
www.learning.es
Unidad 6. Arquitectura de la Capa de Negocio
Introducción
En aplicaciones Java los desarrolladores web siempre han organizado la lógica de negocios a través 60
de un diseño procedimental u orientado a objetos.
Objetivos
 Describir la arquitectura de la capa de negocio.
 Entender la organización que se realiza en aplicaciones java haciendo uso de la capa de
negocio.
Diseño procedimental
Organiza el código en funciones y estructuras de datos simples. Las estructuras de datos,
generalmente se crean, se inicializan y se pasan como parámetros a las funciones. La relación entre
estas funciones y los datos que utilizan suelen asociarse en librerías según el criterio del
programador.
Orientado a objetos
Organiza el código en objetos que contienen ambos aspectos, datos y comportamiento. Dichos
objetos colaboran, generalmente mediante herencia o composición para resolver la lógica de la
aplicación. La relación entre los datos y las funciones que los usan está mantenida en su mayor
parte por el propio lenguaje. Generalmente el diseño orientado a objetos es más fácil de entender,
mantener, extender y probar.
A pesar de los beneficios del diseño OO, muchas aplicaciones J2EE modernas se han escrito
utilizando el estilo procedimental. Uno de los precursores principales de dicho estilo fue la
especificación EJB (anterior a 3.0).
Diseño Procedimental
Las características más importantes del diseño procedimental son las siguientes:
 Implementar nuevas funcionalidades es fácil. Basta añadir código a un script transaccional
(Transaction Script, Fowler, P_EAA) o añadir un script transaccional nuevo.
 No hace falta diseñar la aplicación. No se necesita determinar las clases ni sus
responsabilidades. La lógica de negocio se distribuye en los spcripts transaccionales (Session
Beans en EJB 2.0) y los datos persistentes en simples estructuras de datos (Entity Beans en
EJB 2.0).
www.learning.es
61
Es más asequible para programadores con poca experiencia. Este es el principal motivo por el que
las Factorías de Software suelen decantarse principalmente por el estilo procedimental frente al OO.
El sistema funciona bien con lógicas de negocio simples pero a medida que esta se complica, los
scripts transaccionales suelen contener miles de líneas de código. Se promueve la duplicación de
código, los programadores tenderán a programar para si mismos debido a la dificultad de encontrar
los métodos disponibles para cada modelo de datos. Se pierde el principal atractivo de la omisión del
diseño. El sistema se hace demasiado difícil de entender, probar y mantener.
Ciclo de Vida de los Beans de Session

El ciclo de vida de los beans de sesión depende del tipo de anotación en la que se ha delimitado
dicho Bean.
Ciclo de vida Bean @StateFul:

 Creación: Cuando el cliente ejecuta el método create().
 Uso: Cuando el cliente llama un método de negocio.
 Desactivación: El bean se manda a memoria secundaria.
 Activación: El bean es despertado para servir algún método al cliente.
 Destrucción: Cuando el cliente termina su sesión con el bean.
www.learning.es
62
Diseño Orientado a Objetos

En la actualidad podemos decir que en muchos desarrollos Java muchos programadores han optado
por utilizar orientación a objetos en sus desarrollos, esto es debido a que muchos autores no optado
por el desarrollo de EJB. Los EJB son mucho más complejos que el diseño OO con los framework
actuales.
Existen algunos frameworks que recuperaban el diseño OO mediante objetos que no implementaban
ninguna de las interfaces específicas de EJB.
www.learning.es
Actualmente se conocen con el nombre de POJO (Plain Old Java Object) para dar un nombre
atractivo al desarrollo de aplicaciones basados en objetos java regulares no vinculados a un
contenedor EJB.
Un POJO (acrónimo de Plain Old Java Object) es una sigla creada por Martin Fowler, Rebecca
Parsons y Josh MacKenzie en septiembre de 2000 y utilizada por programadores Java para enfatizar
el uso de clases simples y que no dependen de un framework en especial. Este acrónimo surge como
una reacción en el mundo Java a los frameworks cada vez más complejos, y que requieren un 63
complicado andamiaje que esconde el problema que realmente se está modelando. En particular
surge en oposición al modelo planteado por los estándares EJB anteriores al 3.0, en los que los
"Enterprise JavaBeans" debían implementar interfaces especiales.
POJO es una nueva palabra para designar algo viejo. No existe en Java una nueva tecnología con
ese nombre, sino que el nombre existe en el marco de una revalorización de la programación
"simplemente orientada a objetos". Esta revalorización tiene que ver también con el éxito de
lenguajes orientados a objetos más puros y sencillos, que empezaron a tomar parte del mercado al
que Java apunta, como Ruby y Python.
En modelos medianamente complejos, el estado de los modelos del dominio se hace persistente
mediante un framework ORM (Object/Relational Mapping) de persistencia, como JDO, Hibernate o
TopLink. La configuración de los modelos del dominio se realiza forma declarativa mediante un
contenedor IoC como Spring o PicoContainer. Por último, los servicios basados en POJOs proveen
capacidades similares a un contenedor EJB, como sguridad y transacciones declarativas, mediante el
uso de AOP.
Esta arquitectura, conocida como arquitectura de contenedor ligero (Lightweight Container

Architecture)
Ventajas principales de la arquitectura de Framework ligero.

Es simple y versátil
Escalable horizontalmente mediante el uso de clusters en los contenedores web aunque limitada por
las sesiones y el servidor de base de datos.
Reutilización de código: Los contenedores ligeros manejan POJOs que son independientes del
contenedor. Es posible reutilizar los modelos del dominio en cualquier otro entorno.
Servicios declarativos mediante contenedores ligeros con soporte de AOP. Por ejemplo, la
configuración de transacciones mediante Spring es más configurable que la proporcionada por EJB
CMT.
Orientación a Objetos: Puesto que no hay limitaciones (o muy pocas, como podría ser la
especificación java beans) impuestas en los POJOs, la lógica de negocio de la aplicación puede
resolverse utilizando técnicas de diseño OO.
Esta ventaja se hace más importante según la lógica de negocio se hace más compleja.
www.learning.es
Es posible escribir test Unitarios de forma independiente para cada modelo del dominio ya que no es
necesario desplegarlos en el contenedor. El desarrollo dirigido por test (Test Driven Development)
resulta natural en este entorno. El respaldo de los test unitarios permite que el código pueda
refactorizarse con seguridad según evoluciona la aplicación.
Ejemplo de POJO con el Framework Hibernate

1. Crear un proyecto con el Framework de Hibernate con NetBeans. 64
2. Agregamos el jar de classes12.jar y en el archivo hibernate.cfg.xml agregamos las siguientes

propiedades:
a. Agregar la contraseña
b. Añadir la propiedad hibernate.show_sql el valor true en configuration properties.
c. Añadir la propiedad hibernate.current_session_context_class el valor true en

miscellaneous properties.
3. Agreguemos un nuevo archivo, y seleccionemos Hibernate > Asistente de ingeniería inversa de

Hibernate.
www.learning.es
65
www.learning.es
66
En el siguiente paso dejamos los valores por defecto. Siguiente.

Se cargarán automáticamente los nombres de las tablas de la base de datos de hospital (elegida
cuando creamos el proyecto), y seleccionaremos las tablas con las que nos interese trabajar.
Si marcamos la casilla Incluir tablas relacionadas algunas otras tablas se incluirán automáticamente.
Nos generará el siguiente archivo:
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE hibernate-reverse-engineering PUBLIC "-//Hibernate/Hibernate Reverse Engineering
DTD 3.0//EN" "_
http://hibernate.sourceforge.net/hibernate-reverse-engineering-3.0.dtd">
<hibernate-reverse-engineering>
<schema-selection match-schema="SYSTEM"/>
<table-filter match-name="HOSPITAL"/>
<table-filter match-name="ENFERMO"/>
<table-filter match-name="EMP"/>
<table-filter match-name="DOCTOR"/>
<table-filter match-name="DEPT"/>
</hibernate-reverse-engineering>
4. Crea un Archivo nuevo.... Categoría Hibernate, tipo Archivos de mapas de Hibernate y POJOs de
la base de datos.
www.learning.es
67
Le decimos que genere las clases en el paquete ClasesHospital:
Al darle finalizar se generarán los siguientes archivos:
5. Lo último sería crear un Archivo Nuevo..., Categoría Hibernate, Tipo HibernateUtil.java.
www.learning.es
Lo guardamos en el mismo paquete:
68
6. Después de configurarlo todo comenzamos con el desarrollo de nuestra aplicación.
Crea una nueva Clase Java (Archivo Nuevo..., Categoría Java, tipo Clase Java) y llámale
EmpleadosHelper y lo ponemos dentro del paquete ClasesHospital.
Incluimos el siguiente código:

package ClasesHospital;
import java.util.List;
import org.hibernate.Query;
import org.hibernate.Session;
public class EmpleadosHelper {

Session session = null;
public EmpleadosHelper() {
this.session = HibernateUtil.getSessionFactory().getCurrentSession();
}
Después incluimos un método para realizar búsquedas:
public List getFilmTitles(int startID, int endID) {

List<Emp> filmList = null;
try {
org.hibernate.Transaction tx = session.beginTransaction();
Query q = session.createQuery("from Emp as emp");// where film.filmId between '" + startID + "'
and '" + endID + "'");
filmList = (List<Emp>) q.list();
} catch (Exception e) {
e.printStackTrace();
}
return filmList;
}
Creamos página jsp.
<%@page import="ClasesHospital.*"%>
<%@page import="java.util.List"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
www.learning.es
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<%
EmpleadosHelper helper = new EmpleadosHelper();
List filmTitles = helper.getFilmTitles(1, 10); 69
int filmTitlesSize = filmTitles.size();
out.print("<table>");
out.print("<tr><th>Title</th><th>Description</th><th> </th><th> </th></tr>");
for (int i = 0; i < filmTitlesSize; i++) {
Emp film = (Emp) filmTitles.get(i);
String filmID = film.getApellido();
out.print("<tr>");
out.print("<td class='COL1'>" + filmID +"</td>");
out.print("</tr>");
}
out.print("</table>");
%>
</body>
</html>
PROBAR CONSULTAS HQL:
www.learning.es
70
Ver Video: Arquitectura de la capa de negocio, en la Unidad 6,

Laboratorio: POJO con Hibernate

Objetivo
Crear un proyecto Hibernate con POJO como ejemplo de arquitectura de la capa de negocio.
Enunciado:
- Realizar un ejemplo de consultas de acción con Hibernate
- Crear métodos para el alta, baja y modificación.
1. Crear un proyecto con el Framework de Hibernate con NetBeans.
2. Agregamos el jar de classes12.jar y en el archivo hibernate.cfg.xml agregamos las siguientes

propiedades:
- Agregar la contraseña
www.learning.es
- Añadir la propiedad hibernate.show_sql el valor true en configuration properties.
71
- Añadir la propiedad hibernate.current_session_context_class el valor true en miscellaneous

properties.
3. Agreguemos un nuevo archivo, y seleccionemos Hibernate > Asistente de ingeniería inversa de

Hibernate.
En el siguiente paso dejamos los valores por defecto. Siguiente.

Se cargarán automáticamente los nombres de las tablas de la base de datos de hospital (elegida cuando creamos
el proyecto), y seleccionaremos las tablas con las que nos interese trabajar.
Si marcamos la casilla Incluir tablas relacionadas algunas otras tablas se incluirán automáticamente.
Nos generará el siguiente archivo:
www.learning.es
72
www.learning.es
<!DOCTYPE hibernate-reverse-engineering PUBLIC "-//Hibernate/Hibernate Reverse Engineering
DTD 3.0//EN_
" "http://hibernate.sourceforge.net/hibernate-reverse-engineering-3.0.dtd">
<hibernate-reverse-engineering>
<schema-selection match-schema="SYSTEM"/>
<table-filter match-name="HOSPITAL"/> 73
<table-filter match-name="ENFERMO"/>
<table-filter match-name="EMP"/>
<table-filter match-name="DOCTOR"/>
<table-filter match-name="DEPT"/>
</hibernate-reverse-engineering>
4. Crea un Archivo nuevo.... Categoría Hibernate, tipo Archivos de mapas de Hibernate y POJOs de
la base de datos.
Le decimos que genere las clases en el paquete ClasesHospital:
Al darle finalizar se generarán los siguientes archivos:
www.learning.es
5. Lo último sería crear un Archivo Nuevo..., Categoría Hibernate, Tipo HibernateUtil.java.
74
Lo guardamos en el mismo paquete:
6. Después de configurarlo todo comenzamos con el desarrollo de nuestra aplicación.
Crea una nueva Clase Java (Archivo Nuevo..., Categoría Java, tipo Clase Java) y llámale
EmpleadosHelper y lo pnemos dentro del paquete ClasesHospital.
Incluimos el siguiente código:
package ClasesHospital;
import java.util.List;
import org.hibernate.Query;
import org.hibernate.Session;
public class EmpleadosHelper {

Session session = null;
public EmpleadosHelper() {
this.session = HibernateUtil.getSessionFactory().getCurrentSession();
}
Después incluimos un método para realizar las acciones:
www.learning.es
public void borrar() {
Emp ee = new Emp();
short ii=7698;
ee.setEmpNo(ii);
session.delete(ee);
tx.commit(); 75
}
public void anadir() {
Emp ee = new Emp();

short categ=111;
ee.setEmpNo(categ);
ee.setApellido("SÁNCHEZ ORO");
org.hibernate.Transaction tx = null;
try {
tx = session.beginTransaction();
session.save(ee);
tx.commit();
session.close();} catch (Exception e) {

}
}
public void Modificas() {

short num=111;
Emp ee = (Emp)session.load(Emp.class,num);
ee.setApellido("ddd");
session.update(ee);
tx.commit();
Actividades
www.learning.es
76
www.learning.es
Unidad 7. Arquitectura de Integración de
Capas
77
Objetivos
 Entender la arquitectura de capas en Java.
 Conocer las diferentes estructuras y ventajas de los patrones de diseño y arquitectura en n capas.
Introducción
Un patrón de diseño es una abstracción de una solución en un nivel alto. Los patrones solucionan
problemas que existen en muchos niveles de abstracción. Hay patrones que abarcan las distintas
etapas del desarrollo, desde el análisis hasta el diseño y desde la arquitectura hasta la
implementación.
Algunas personas definen un patrón como una solución recurrente para un problema en un contexto.
Los patrones de diseño no están enfocados a ningún lenguaje, son arquitecturas que definen las
estructuras de soluciones.
Un contexto es el entorno, situación, o condiciones relacionadas dentro de las cuales existe algo.
Un problema es una cuestión inacabada, algo que se necesita investigar y resolver. Un problema se
puede especificar mediante un conjunto de causas y efectos. Usualmente un problema está
restringido al contexto en el que ocurre.
La solución se refiere a la respuesta al problema dentro de un contexto que ayuda a resolver las
dificultades.
Entonces, si tenemos una solución a un problema en un contexto, ¿es un patrón?. No
necesariamente. También necesitamos asociar la característica de recurrencia con la definición de un
patrón.
Los patrones deberían comunicar soluciones de diseño a los desarrolladores y arquitectos que los
leen y los utilizan. Aunque el concepto de patrón es bastante simple, definir realmente el término es
muy complejo.
Hemos señalado sólo las referencias para que puedas indagar en más profundidad en la historia de
los patrones y aprender sobre ellos en otras áreas. Sin embargo, deberías tener en mente que la
definición de patrón que hemos adoptado funciona. En nuestro catálogo, se describe un patrón de
acuerdo a sus principales características: contexto, problema y solucion, junto con otros aspectos
importantes, como causas y consecuencias. La página que describe la plantilla de patrones explica
estas características en más detalle.
A cada diseño de proyecto le sigue el problema que trata de resolver, la solución que aporta y las
posibles desventajas asociadas.
Un desarrollador debe buscar un equilibrio entre las ventajas y las desventajas a la hora de decidir
que patrón utilizar. Lo normal es, como observará a menudo en la tecnología de programación y
otros campos, es buscar la media entre flexibilidad y rendimiento.
La mayoría de las personas utiliza patrones de diseño cuando perciben un problema en su proyecto,
como por ejemplo, el rendimiento.
Un patrón de diseño es el trabajo de una persona que ya se encontró con el problema
anteriormente, intentó muchas soluciones posibles, y escogió y describió una de las mejores.
Todos los proyectos grandes utilizan los patrones de diseño para solucionar los problemas e
implementar el rendimiento de la aplicación.
Los patrones de diseño se pueden dividir en tres grandes categorías basadas en su propósito:
creacionales, estructurales y de comportamiento.
Creacionales: Los patrones creacionales tratan con las formas de crear instancias de objetos. El objetivo de
estos patrones es abstraer el proceso de instanciación y ocultar los detalles de cómo los objetos son creados o
inicializados.
www.learning.es
Estructurales: Los patrones estructurales describen como las clases y objetos pueden ser combinados para
formar grandes estructuras y proporcionar nuevas funcionalidades. Estos objetos insertados pueden ser incluso
objetos simples u objetos compuestos.
Comportamiento: Los patrones de comportamiento ayudan a definir la comunicación y relación entre los objetos
de un sistema. El propósito de este patrón es reducir el acoplamiento entre los objetos.
Podemos subdividir a su vez los patrones en Clases y Objetos:

78
Creacionales
 Creacional de la Clase: Los patrones creacionales de Clases usan la herencia como un
mecanismo para lograr la instanciación de la Clase.
 Creacional del objeto: Los patrones creacionales de objetos son más escalables y dinámicos
comparados de los patrones creacionales de Clases.
Estructurales
 Estructural de la Clase: Los patrones estructurales de Clases usan la herencia para
proporcionar interfaces más útiles combinando la funcionalidad de múltiples Clases.
 Estructural de Objetos: Los patrones estructurales de objetos crean objetos complejos
agregando objetos individuales para construir grandes estructuras. La composición del
patrón estructural del objeto puede ser cambiado en tiempo de ejecución, el cual nos da
flexibilidad adicional sobre los patrones estructurales de Clases
Comportamiento
 Comportamiento de Clase: Los patrones de comportamiento de Clases usan la herencia para
distribuir el comportamiento entre Clases.
 Comportamiento de Objeto: Los patrones de comportamiento de objetos nos permiten
analizar los patrones de comunicación entre objetos relacionales, como objetos incluidos en
un objeto complejo.
Con la aparición del entorno J2EE, aparecieron nuevos catálogos de patrones de diseño. J2EE es
una arquitectura por si misma que integra otras arquitecturas, incluyendo servlets, JavaServer
Pages, Enterprise JavaBeans, y más. Existen 5 capas en la arquitectura J2EE:
Cliente
Presentación
Negocios
Integración
Recurso
Los patrones J2EE se pueden dividir en tres categorías:

 Capa de presentación
 Capa de Negocios
 Capa de Integración
Modelo Vista Controlador

El modelo actual de páginas web, define que las peticiones de los clientes son solicitudes a páginas
de servidor (jsp, servlets…) que contienen la lógica de negocio y el diseño html en un mismo ligar.
Las páginas ejecutan acciones del usuario que ha realizado sobre esa página. Dichas acciones son
capturadas por clases o pueden estar escritas en una clase Servlet.
www.learning.es
En este tipo de arquitectura conocida, el cliente hace Request a objetos de la capa de presentación
(Pagina del servidor), que luego llama a su código controlador para pedirle funcionalidad.
En el caso de un diseño de datos MVC, el Request se realiza a un objeto de tipo Controlador que
crea una presentación como Response a esa solicitud.
En los frameworks MVC, las URLs se mapean directamente a clases, estas son denominadas
"Controladoras" y son las que procesan los Request entrantes, manejando las entradas del usuario,
sus interacciones y ejecutando la lógica apropiada para el proceso.
Una clase controladora llama a una vista, la cual genera la salida HTML que se enviará como 79
Response.
Dicho modelo MVC permite diseñar en tres capas de negocio y no poner todo el código en las
interfaces de usuario de tu sistema (IU).
La idea consiste en tener 3 niveles de funcionalidad bien definidos:

Capa de presentación: Con nuestras Interfaces (páginas HTML..) y sus controles visuales
(controles de formulario) junto con sus eventos.
Capa de negocio: Lógica del dominio. Aquí irá todo el código que define las reglas de negocio
(cálculos, validaciones). Surge de los procesos que hemos encontrado en el análisis.
Capa de acceso a datos: El código que permite acceder a las fuentes de datos. Esencialmente
trata sobre 4 operaciones básicas, llamadas CRUD (por Create-Retrieve-Update y Delete), que se
realizan sobre cualquier fuente de datos (normalmente alguna base de datos relacional).
El modelo de arquitectura Model-View-Controller (MVC) separa una aplicación en tres componentes
principales: el modelo, la vista y el controlador.
El marco de J2EE proporciona una alternativa al modelo de páginas de servidor para crear
aplicaciones web.
El marco de J2EE es un marco de presentación de poca complejidad y fácil de comprobar que se
integra con las características de Java existentes, como el acceso a datos o la representación de
datos en las páginas.
MVC es un modelo de diseño estándar con el que están familiarizados muchos desarrolladores.
Algunos tipos de aplicaciones web salen beneficiadas con el marco de MVC.
Otras seguirán utilizando el modelo de la aplicación J2EE tradicional que está basado en formularios
html, código del servidor y postbacks. Otros tipos de aplicaciones web combinarán las dos
estrategias; una no excluye a la otra.
El marco de MVC incluye los componentes siguientes:

Modelos. Los objetos de modelo son las partes de la aplicación que implementan la lógica del
dominio de datos de la aplicación.
A menudo, los objetos de modelo recuperan y almacenan el estado del modelo en una base de
datos. Por ejemplo, un objeto Product podría recuperar información de una base de datos, trabajar
con ella y, a continuación, escribir la información actualizada en una tabla Productos de una base de
datos.
En las aplicaciones pequeñas, el modelo es a menudo una separación conceptual en lugar de física.
Por ejemplo, si la aplicación solo lee un conjunto de datos y lo envía a la vista, la aplicación no tiene
un nivel de modelo físico y las clases asociadas. En ese caso, el conjunto de datos asume el rol de
un objeto de modelo.
Vistas. Las vistas son los componentes que muestra la interfaz de usuario de la aplicación.
Normalmente, esta interfaz de usuario se crea a partir de los datos de modelo. Un ejemplo sería
una vista de edición de una tabla Productos que muestra cuadros de texto, listas desplegables y
casillas basándose en el estado actual de un objeto Product.
Controladores. Los controladores son los componentes que controlan la interacción del usuario,
trabajan con el modelo y por último seleccionan una vista para representar la interfaz de usuario.
En una aplicación MVC, la vista solo muestra información; el controlador administra y responde a los
datos proporcionados por el usuario y su interacción. Por ejemplo, el controlador administra los
valores de la cadena de consulta y pasa estos valores al modelo, que a su vez podría utilizarlos para
consultar la base de datos.
El modelo de MVC ayuda a crear aplicaciones que separan los aspectos diferentes de la aplicación
(lógica de entrada, lógica comercial y lógica de la interfaz de usuario), proporcionando un
acoplamiento entre estos elementos.
www.learning.es
El modelo especifica dónde se debería encontrar cada tipo de lógica en la aplicación. La lógica de la
interfaz de usuario pertenece a la vista. La lógica de entrada pertenece al controlador. La lógica
comercial pertenece al modelo.
Esta separación ayuda a administrar la complejidad al compilar una aplicación, ya que permite
centrarse en cada momento en un único aspecto de la implementación. Por ejemplo, podemos
centrarnos en la vista sin estar condicionado por la lógica comercial.
El acoplamiento entre los tres componentes principales de una aplicación MVC favorece el desarrollo
paralelo. Por ejemplo, un desarrollador de software puede trabajar en la vista, un segundo 80
desarrollador puede ocuparse de la lógica del controlador y un tercero se puede centrar en la lógica
comercial del modelo.
En este gráfico podemos visualizar cómo son las características de envió de una página web con la
lógica tradicional de J2EE utilizando páginas de servidor.
El ciclo de vida de una aplicación MVC es simple. Lo primero de todo es que no realizamos en
ningún momento un postback. No existen métodos de acción para el envío de la página tal y como
los conocemos, sino que cada acción está delimitada por un controlador, que devolverá la Vista final
al usuario.
El usuario realizará una acción en la Vista, que llamará al controlador con una acción delimitada, y el
modelo se encargará de la lógica para poder realizar la acción final.
Si nos fijamos en la lógica MVC, solamente tenemos un manejador, que será el encargado de llamar
a su controlador correspondiente, según la acción del usuario.
Cada página que visualiza el usuario es independiente a la lógica de negocio, y cada una es
representada individualmente al realizar acciones sobre ella.
www.learning.es
Con la lógica MVC, lo que hacemos es representar al usuario acciones para realizar las llamadas.
Vamos a ver un ejemplo, tenemos acciones para Details y Orders.
Cuando el usuario hace una petición sobre una de esas acciones, el manejador se encarga de enviar
dicha información al servidor, y dependiendo de la acción que envía el usuario, se llama a un
controlador que representará la vista correspondiente en Html.
En cambio, si lo hacemos con las páginas JSP, cada página es independiente entre sí y si
quisiéramos cambiar o añadir algo, habría que hacerlo página a página, mientras que con MVC,
habría que hacerlo independiente a cada controlador y vista. 81
Struts con Java

Struts es un framework basado en tecnología Java para el desarrollo Web basado en el patrón de
diseño MVC (modelo, vista, controlador).
Un framework es una herramienta que se basa en soluciones reutilizables para el desarrollo y/o
implementación de una aplicación que permite acotar tiempos, reducir código y optimizar tareas.
Gracias a Struts podemos construir aplicaciones Web sin introducir código java en nuestras páginas
jsp, en su lugar struts contiene unos tags o etiquetas que realizan acciones y que permiten reducir
el tiempo de desarrollo.
El patrón de diseño MVC consiste en separar una aplicación en tres componentes:
Modelo: Reglas de Negocio, acceso a los datos y Persistencia.( Beans, EJB, ORM)
Vista: Gestión de la Interfaz de los datos a los usuarios. (html, jsp, javaScript, flex, ajax etc.)
Controlador: Gestiona eventos entre el Modelo y la vista. (struts Form,strutsAction, struts-conf).
Una regla principal de Struts sería que la Vista no podrá acceder al modelo directamente, sino que
debe pasar por el controlador para acceder al modelo.
La Vista consiste en un conjunto de páginas jsp y tags personalizados que aporta struts.
Estas etiquetas permiten separar la vista del controlador debido a que estas etiquetas acceden al
modelo.
El controlador Struts se encarga de tres tareas:
 Validaciones simples:
Consiste en validaciones simples sin acceder al modelo, se utiliza para comprobar que se
hayan ingresado todos los datos necesarios, para comprobar la longitud de las contraseñas o
de las direcciones de correo.
Esto se logra extendiendo la clase ActionForm
 Validaciones Complejas:
Se realiza extendiendo la clase base de struts llamada Action. A este nivel se comprueba
contra las reglas de negocio (modelo).
Por ejemplo: Se instancian objetos del modelo,se realizan consultas contra la base de datos y
se obtienen los errores, etc.
 Control de flujo o de Navegación:
www.learning.es
A través de un archivo de configuración (struts-conf) se gestiona el flujo de navegación entre
páginas, que también se logra extendiendo la clase ActionForm y Action.
Capas de arquitectura JEE

En la arquitectura JEE se contemplan cuatro capas, en función del tipo de servicio y contenedores:
 Capa de cliente: También conocida como capa de presentación o de aplicación. Nos
82
encontramos con componentes Java (applets o aplicaciones) y componentes que son parte
del diseño web y su lógica en el cliente (HTML, JavaScript, css, etc.).
 Capa Web. Intermediario entre el cliente y otras capas. Sus componentes principales son los
servlets y las páginas JSP. Aunque componentes de capa cliente (applets o aplicaciones)
pueden acceder directamente a la capa EJB, lo normal es que Los servlets/JSPs pueden
llamar a los EJB.
 Capa Enterprise JavaBeans: Permite a múltiples aplicaciones tener acceso de forma
concurrente a datos y lógica de negocio. Los EJB se encuentran en un servidor EJB, que no
es más que un servidor de objetos distribuidos. Un EJB puede conectarse a cualquier capa,
aunque su misión esencial es conectarse con los sistemas de información empresarial (un
gestor de base de datos, ERP, etc.)
 Capa de sistemas de información empresarial.
La visión de la arquitectura es un esquema lógico, no físico. Cuando hablamos de capas nos

referimos sobre todo a servicios diferentes que pueden estar físicamente dentro de la misma
máquina e incluso compartir servidor de aplicaciones y JVM.
Componentes EJB
Con la tecnología Enterprise JavaBeans es posible desarrollar componentes (enterprise beans) que
luego podemos reutilizar y ensamblar en distintas aplicaciones que implementemos en la empresa.
Por ejemplo, podriamos desarrollar un bean Cliente que represente un cliente en una base de datos.
Dicho vean Cliente podríamos usarlo, posteriormente, en un programa de agenda o en una
aplicación de comercio electrónico o virtualmente en cualquier programa en el que se necesite
representar un cliente.
Con esta tecnología, podemos separar las capas, llegando incluso a ser posible que el desarrollador
del bean y el ensamblador de la aplicación no fueran la misma persona, o ni siquiera trabajaran en
la misma empresa.
El desarrollo basado en componentes promete un paso más en el camino de la programación
orientada a objetos.
Con la programación orientada a objetos podemos reutilizar clases, pero con componentes es
posible reutilizar un mayor nivel de funcionalidades e incluso es posible modificar estas
funcionalidades y adaptarlas a cada entorno de trabajo particular sin tocar el código del componente
desarrollado.
El contenedor de componentes se denomina contenedor EJB y es algo así como el sistema operativo
en el que éstos residen.
Cuando se utilizan componentes en un marco de trabajo, debemos prestar atención tanto al
desarrollo de los beans como a los descriptores de despliegue que comunican nuestro trabajo con el
contenedor.
Debemos recordar que un descriptor de despliegue ofrece la información del componente a nuestro
contenedor EJB y a nuestro entorno de trabajo (bases de datos, arquitectura de la aplicación, etc.).
El despliegue se define de forma declarativa, mediante un fichero XML (descriptor del despliegue,
deployment descriptor) en el que se definen todas las características del bean o con anotaciones.
El funcionamiento de los componentes EJB se basa fundamentalmente en el trabajo del contenedor
EJB.
El contenedor EJB es un programa Java que trabaja en el servidor y que contiene todas las clases y
objetos necesarios para el correcto funcionamiento de los EJBs.
www.learning.es
Los servicios que ofrece un contenedor de EJBs son los siguientes:
Integración: Proveen una forma de acoplar en tiempo de ejecución diferentes componentes, mediante la simple
configuración de anotaciones xml. La integración es un servicio que proveen los beans de sesión y los MDBs.
Pooling: El contenedor de EJBs crea para componentes EJB un pool de instancias que es compartido por los
diferentes clientes. Aunque cada cliente visualiza el entorno como si recibiera siempre instancias diferentes de
los EJB, el contenedor está constantemente reutilizando objetos para optimizar memoria. El pooling es un servicio
que se aplica a los Stateless Session Beans y a los MDBs. 83
Thread-safely: El programador puede escribir componentes del lado del servidor como si estuviera trabajando en
una aplicación sencilla con un solo thread (hilo). El contenedor se encarga de que los EJBs tengan el soporte
adecuado para una aplicación multi-usuario (como son en general las aplicaciones empresariales) de forma
transparente, asegurando el acceso seguro, consistente y alto rendimiento. Se aplican a los beans de sesión y a
los MDBs.
Administración de Estados: El contenedor de EJBs almacena y maneja el estado de un Stateful Session Bean de
forma transparente, lo que significa que el programador puede mantener el estado de los miembros de una clase
como si estuviera desarrollando una aplicación de escritorio ordinaria. El contenedor manipula los detalles de las
sesiones.
Mensajería: Mediante los MDBs es posible desacoplar por completo dos componentes para que se comuniquen
de forma asincrónica, sin reparar demasiado en los mecanismos de la JMS API que los MDBs encapsulan.
Transacciones: EJB soporta el manejo de transacciones declarativas que permiten agregar comportamiento
transaccional a un componente simplemente usando anotaciones xml de configuración. Esto significa que cuando
un método de un EJB (Session Bean o MDB) se completa normalmente, el contenedor se encargará de finalizar la
transacción y validar los cambios que se realizaron en los datos de forma permanente. Si algo fallara durante la
ejecución del método (una excepción o cualquier otro problema), la transacción haría un rollback y es como si el
método jamás se hubiera invocado.
Seguridad: EJB soporta integración con la Java Authentication and Authorization Service (JAAS) API, haciendo
casi transparente el manejo transversal de la seguridad. Se aplica a todos los Session Beans.
Interceptors: EJB introduce un framework liviano y simple para AOP (programación orientada a aspectos). No es
tan robusto y completo como otros, pero es lo suficientemente útil para que sea utilizado por los demás servicios
del contenedor para brindarnos de forma invisible los crosscutting concerns de seguridad, transacciones, thread-
safely.
Acceso Remoto: Es posible acceder de forma remota a distintos EJBs de forma sencilla, simplemente mediante la
Inyección de Dependencia. El procedimiento para inyectar un componente local o uno remoto es exactamente el
mismo, abstrayéndonos de las complicaciones específicas de RMI o similares. Este servicio aplica únicamente a
los Session Beans.
Web Services: Un Stateless Session Bean puede publicar sus métodos como servicios web mediante una sencilla
anotación.
Persistencia: EJB 3 provee la especificación JPA para el mapeo de objetos llamados Entidades a tablas o POJOs.
Aquí tenemos un gráfico que mostraría la representación de EJB dentro de un módulo web.
www.learning.es
84
Tipos de beans
Existen tres tipos de beans definidos, cada uno implementa unas características diferentes y
permiten ser combinados entre si.
Beans de Sesión (Session Beans)

En una aplicación típica, dividida en grandes capas (presentación, lógica de negocio, persistencia y
base de datos), los Beans de Sesión viven en la lógica de negocio.
Hay dos grandes tipos de Beans de Sesión:
Stateless (sin estado)
Stateful (con estado)
Stateless no conserva el estado de ninguno de sus atributos de la invocación de un método a otro.

Stateful conserva el estado a lo largo de toda una sesión. Los Beans de Sesión Stateless son los
únicos que pueden exponerse como servicios web.
Los beans de sesión son invocados por el cliente con el propósito de ejecutar operaciones de negocio
específicas, como por ejemplo podría ser mostrar todos los datos de una determinada tabla.
El nombre sesión implica que la instancia del bean estará disponible durante una unidad de trabajo
(unit of work) y no sobrevivirá a una caída del servidor.
Un bean de sesión sirve para modelar cualquier funcionalidad lógica de una aplicación y se utilizan
para realizar acciones y representar propiedades de objetos.
Message-Driven Beans (MDBs)

Viven en la lógica de negocio y los servicios que proveen son parecidos a los Beans de Sesión, con la
diferencia de que los MDBs son usados para invocar métodos de forma asincrónica.
Cuando se produce la invocación de un método de un MDB desde un cliente, la llamada no bloquea
el código del cliente y el mismo puede seguir con su ejecución, sin tener que esperar
indefinidamente por la respuesta del servidor.
Los MDBs encapsulan el popular servicio de mensajería de Java, Java Message Service (JMS).
Los MDBs también procesan lógica de negocio, pero un cliente nunca invoca a un método de un MDB
directamente.
El sistema de mensajería asincrónica propone la utilización de una capa intermedia en la
comunicación entre el creador y el consumidor del mensaje.
En EJB 3, esta capa se llama MOM (Message-oriented Middleware). Básicamente, MOM es un
software que permite funcionar como servidor de mensajería, reteniendo los mensajes del
productor y enviándolos posteriormente al consumidor en el momento en que esté disponible para
recibirlo.
Beans de Entidad (Entities)

Las entidades viven en la capa de persistencia y son los EJBs que manejan Java Persistence API
(JPA), también parte de la especificación de EJB 3.0.
www.learning.es
Las entidades son POJOs con cierta información metadata que permite a la capa de persistencia
mapear los atributos de la clase a las tablas de la base de datos y sus relaciones.
Existen dos tipos BMP y CMP según se gestione la persistencia por parte del bean o del contenedor.
Los EJB de entidad están directamente relacionados con los datos de la aplicación, son objetos que
mantienen en memoria los datos que maneja la aplicación, las entidades que disponen de
persistencia.
Los Beans de Entidad normalmente mapean (mantienen una relación en memoria) las tablas de
una base de datos relacional, aunque también es posible que mantengan la persistencia de los datos 85
en ficheros, como por ejemplo un xml.
En cualquiera de los casos el objetivo de un Bean de Entidad es almacenar los datos en memoria
desde una fuente persistente y mantener una sincronización total entre el estado de los datos entre
la memoria y la fuente de datos.
Por esta razón se dice que los Beans de Entidad son los EJB que sobreviven a caídas del sistema, ya
que en caso de un fallo del sistema, los datos que hay en memoria estarían guardados en el
dispositivo persistente, como por ejemplo la base de datos, con lo cual, cuando se reinicie el
servidor se recuperarán sin ningún problema.
Anotaciones de un bean
Para poder configurar correctamente un vean, debemos indicar al contenedor de EJB qué servicios
debe proveer a nuestro Bean, y para ello disponemos de los descriptores de despliegue o de las
anotaciones en las clases bean.
Vamos a visualizar las anotaciones básicas para los Session Beans.
@Stateful
Indica que el Bean de Sesión es con estado. Sus atributos son:
 name: por defecto es el nombre de la clase pero se puede especificar otro nombre diferente.
 mappedName: Indica si deseamos que el contenedor maneje el objeto de forma específica.
Si incluimos esta opción nuestra aplicación podría no ser portable y no funcione en otro
servidor de aplicaciones.
 description: Indica la descripción de la anotación.
@Stateless
Indica que el Bean de Sesión es sin estado. Sus atributos son:
 name: Por defecto el nombre de la clase pero se puede especificar otra diferente.
 mappedName: Si deseamos que el contenedor maneje el objeto de manera específica. Al
igual que @StateFul esta opción podría hacer que nuestra aplicación no sea portable y no
funcione en otro servidor de aplicaciones.
 Description: descripción de la anotación.
@Init
Especifica que el método se corresponde con un método create de un EJBHome o EJBLocalHome de
EJB 2.1.
Sólo se podrá llamar una única vez a este método. Sus atributos son:
 Value: indica el nombre del correspondiente método create de la interfaz home adaptada.
Sólo se debe utilizar cuando se utiliza el bean anotado con un bean con estado de la
especificación 2.1 o anterior y que disponga de más de un método create.
@Remove
Indica que el contenedor debe llamar al método cuando quiera destruir la instancia del Bean. Sus
atributos son:
 retainIfException: indica si el Bean debe mantenerse activo si se produce una excepción. Por
defecto su valor es false.
www.learning.es
86
www.learning.es
@Local
Indica que la interfaz es local.
@Remote
Indica que la interfaz es remota.
@PostActivate
Invocado después de que el Bean sea activado por el contenedor. 87
@PrePassivate
Invocado antes de que el Bean esté en estado passivate.
Normalmente las anotaciones más empleadas en las aplicaciones serán @Stateless y @Stateful,
para indicar el tipo de EJB que estemos utilizando. El resto de anotaciones se utilizarán en casos
más particulares.
Role de EJB dentro de las aplicaciones JEE

La especificación Enterprise JavaBeans está escrita para diferentes públicos, pero podría resumirse
en dos niveles diferentes:
El desarrollador del cliente

Un cliente es cualquier usuario de un Enterprise JavaBean y podria ser cualquier aplicación Java del
lado del cliente, un servlet o incluso otro EJB.
Un programador del lado del cliente que diseña una aplicación Web o utilice un servlet para
establecer la comunicación con un EJB, necesita comprender como se accede a los EJB y como se
utilizan.
En proyectos de grandes dimensiones, es bastante probable que el programador Web y el
programador EJB sean personas distintas.
El programador cliente tiene menos preocupaciones que un desarrollador bean en cuanto al uso de
EJB.
Necesitan saber como encontrar o crear un bean, como utilizar sus métodos y cómo liberar sus
recursos.
Un cliente siempre utiliza el mismo procedimiento para la creación de objetos, búsquedas e
invocación de métodos, independientemente de como se implemente un EJB determinado.
El cliente no necesita preocuparse sobre la implementación del EJB, solamente debe tener en cuenta
las acciones o propiedades del bean para representar los elementos en las páginas.
El desarrollador EJB
La principal responsabilidad del programador de un bean será escribir la lógica de empresa y
acciones o propiedades.
Siempre que sea posible, la especificación Enterprise JavaBeans intenta abstraer a los
programadores de un bean de cualquier tarea de nivel de sistema.
El programador de un bean debe estructurar su código de una forma determinada.
No importa el tipo de EJB que se esté desarrollando, normalmente deben crearse archivos de clase
primarios y un descriptor xml o bien, incluir anotaciones en las clases del bean.
También podríamos tener clases Java adicionales que apoyen la operación del bean, clases de ayuda
que implementen la lógica de negocio.
Todos estos archivos estarían empaquetados en un JAR, ya hemos visto que es la unidad estándar
de empaquetado de clases de Java.
Podriamos tener muchos beans dentro de un único archivo JAR, pero cada archivo JAR contendría
únicamente descriptor del bean xml.
El descriptor de implementación debe situarse en un directorio especifico, de forma que el
contenedor EJB sabría donde buscarlo.
Este directorio se llama META- INF y no podemos cambiarle el nombre, sigue una especificación
estándar.
www.learning.es
Aquí podemos visualizar la implementación del uso de un EJB dentro de un entorno de desarrollo,
independientemente que sea realizada la llamada desde un navegador o desde una aplicación Java.
88
Estructura de EJB
Todo EJB está compuesto por dos capas.
 Capa Interfaz
La capa Interfaz es un contrato que indica a las clases que consuman el EJB los métodos y
características de dicho EJB.
Para poder trabajar con EJB, necesitamos tener una Interfaz que contenga los métodos que vamos a
exponer a un cliente final.
 Capa Implementación
La capa de implementación es una clase que implementa la capa de Interfaz.

Una clase que hereda directamente de la interfaz del EJB e implementa los métodos que se hayan
incluido en el contrato.
Por último, el cliente que consuma nuestro EJB, sabrá los métodos que contiene debido al contrato
de nuestra interfaz. Nuestro código estará fuertemente tipado debido a que la clase EJB debe
implementar todos los métodos de la interfaz y el cliente tendrá la seguridad que esos métodos no
van a variar el “contrato”.
Vamos a visualizar una creación y una llamada a un EJB:
Lo vamos a hacer creándonos un nuevo proyecto de Java  Aplicación Java.
Sobre nuestro nuevo proyecto y sobre el paquete creado, vamos a agregar una Interfaz que será el
contrato.
www.learning.es
89
Llamaremos a nuestra Interfaz: InterfazEJB
Simplemente vamos a escribir un código con un método que recibirá un tipo de dato String.
Escribimos el siguiente código en la Interfaz.
package javaapplication1;
public interface InterfazEJB {
public void GetMensaje(String nombre);
}
A continuación, nos crearemos una clase sobre el mismo paquete que llamaremos ClaseEJB.
Dicha clase se encargará de implementar la Interfaz de contrato EJB. Para poder trabajar con ello,
debemos utilizar el espacio de nombres siguiente:
import javax.ejb.Stateless
Como podemos comprobar en la imagen, no reconoce la librería de los EJB, por lo que tendremos
que incluirla manualmente para poder trabajar con dichas clases.
www.learning.es
90
En la carpeta Biblioteca de NetBeans, irán todas las librerías relacionadas con nuestro proyecto.
Lo que vamos a realizar es agregar la librería que permite trabajar con EJB. Para ello,
seleccionamos en el menú contextual: “Agregar archivo JAR/carpeta”.
Buscamos la librería de ejb en la carpeta dónde la hayamos situado. Dicha librería es proporcionada
en la documentación del módulo.
Una vez que ya tenemos la librería añadida, ahora es el momento de implementar la Interfaz sobre
la ClaseEJB. Para ello escribimos el siguiente código:
public class ClaseEJB implements InterfazEJB {
Como vemos en la imagen, nos dará un fallo debido a que tenemos que implementar todos los
métodos que contega la Interfaz de la que estamos heredando.
Para implementar los métodos, NetBeans ofrece una herramienta muy útil que “lee” todos los
métodos de la Interfaz y los implementa dentro de nuestra clase.
Si pulsamos sobre el símbolo de la bombilla de la izquierda del código, nos aparecerá una opción
para Implementar los métodos. Seleccionamos dicha opción.
www.learning.es
Una vez que tenemos todos los métodos implementados, escribimos el siguiente código dentro de la 91
clase llamada ClaseEJB.
import javax.ejb.Stateless;
public class ClaseEJB implements InterfazEJB
{
public void GetMensaje(String nombre) {
System.out.println("Primer EJB, Bienvenido a la tecnología " + nombre);
}
}
Ahora nos quedará crearnos un cliente que consuma nuestro bean.
Para ello, debemos agregar una nueva clase sobre el paquete creado y la llamaremos ClienteEJB.
Sobre dicho cliente escribiremos la implementación del consumo del Bean. Para indicar que estamos
utilizando un contrato, utilizaremos la anotación @EJB para que el contenedor reconozca nuestra
lógica de negocio.
Escribimos el siguiente código dentro de la clase ClienteEJB:
import javax.ejb.EJB;
public class ClienteEJB {
@EJB
private ClaseEJB BeanEJB;
www.learning.es
void MetodoCliente()
{
BeanEJB = new ClaseEJB();
BeanEJB.GetMensaje("Usuario de EJB");
}
}
Por último, nos quedará mostrar el resultado de la aplicación. Para ello, iremos a la clase inicial de 92
los proyectos de J2SE llamada Main.java.
En el código de arranque de la clase, crearemos el objeto cliente, que a su vez, llamará al método
del Bean que seguirá el contrato de la Interfaz.
Implementamos el siguiente código en Main.java:
public class Main {
public static void main(String[] args) {
ClienteEJB cliente = new ClienteEJB();
cliente.MetodoCliente();
}
}
Como podemos comprobar cuando ejecutemos la aplicación (tecla F6), veremos el resultado de la
llamada al Bean en la consola de NetBeans.
Custom Tags
Son etiquetas personalizadas que no tiene por qué realizarlas el programador, sino el analista
programador.
Uno de los grandes objetivos, es que el programador que lo vaya a utilizar, bastaría con que supiese
HTML para poder implementar la funcionalidad.
Un Custom Tag es una etiqueta propia, personalizada, es una ampliación de las Acciones JavaBeans.
Uno de los objetivos, será no utilizar en las páginas JSP código java, sino que los Custom Tags se
encargan de realizar todos los posibles tipos de acciones.
Se necesitan múltiples ficheros para trabajar: XML y JSP
Definición de etiquetas:
 Archivo tld  Es el archivo de definición de las etiquetas Custom Tags
 Debemos indicar las características de etiquetas que habrá en todo mi proyecto.
 El fichero Xml es la descripción de nuestro sitio web
www.learning.es
 El fichero class  es la clase con la lógica java
 El fichero JSP  La página para mostrar las etiquetas Custom tags.
Necesitamos un fichero descriptor de la estructura de etiquetas que contenga una serie de

argumentos obligatorios para trabajar:
 Tlibversion  Versión de la librería
 Jspversion  Versión del jsp
 Shortname  El nombre del programador 93
 Tagclass  Nombre del paquete, nombre de la clase

 Bodycontent  Contenido del cuerpo, si no existe contenido, se pondrá Empty
Ejemplo de un archivo tld válido:

<taglib>
<tlibversion>1.0</tlibversion>
<jspversion>2.0<jspversion>
<shortname>Programeitor<shortname>
<tag>
<name>nombreetiqueta</name>
<tagclass>nombre del paquete y de la clase</tagclass>
<bodycontent>Es el contenido del cuerpo</bodycontent>
</tag>
</taglib>
Vamos a visualizar un ejemplo en el que crearemos una etiqueta personalizada que mostrará un
saludo.
Nos creamos un nuevo proyecto Java Web:
Lo llamaremos ProyectoCustomTags:
www.learning.es
Utilizaremos el servidor Apache Tomcat que trae el IDE Netbeans.
94
Sobre la carpeta WEB-INF, nos crearemos una nueva carpeta que llamaremos FolderTLD. Para
ello, seleccionamos la opción Folder dentro de la categoría Other.
Sobre la carpeta FolderTLD ya creada en nuestro proyecto, vamos a agregar un objeto Tag Library
Descriptor de la carpeta Web:
www.learning.es
Lo llamaremos mensaje.
95
Escribiremos el siguiente código dentro del fichero mensaje.tld:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE taglib PUBLIC
"-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN"
"http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd">
<taglib>
<jspversion>2.0</jspversion>
<shortname>mensaje</shortname>
<tag>
<name>primera</name>
<tagclass>paquetecustomtags.PrimeraEtiqueta</tagclass>
<bodycontent>empty</bodycontent>
</tag>
</taglib>
A continuación nos crearemos un nuevo paquete que contendrá la clase que dibujará nuestra
etiqueta, en nuestro ejemplo, hemos puesto lo siguiente:
<tagclass>paquetecustomtags.PrimeraEtiqueta</tagclass>
Por lo que debemos crearnos una clase llamada PrimeraEtiqueta dentro de un paquete que se
llamará paquetecustomtags.
www.learning.es
96
Implementamos el siguiente código dentro de la clase para, posteriormente, representarlo en una

página JSP:
package paquetecustomtags;
import java.io.IOException;
import javax.servlet.jsp.*;
import javax.servlet.jsp.tagext.TagSupport;
import java.util.*;
import java.text.*;
public class PrimeraEtiqueta extends TagSupport {
@Override
public int doStartTag() throws JspTagException
{
return SKIP_BODY;
}
@Override
public int doEndTag() throws JspTagException
{
String horaactual = this.GetHora();
try
{
JspWriter out = pageContext.getOut();
out.write("<h1>Bienvenido a mi pagina Custom Tags</h1>");
out.write("El nombre de mi clase es: ");
out.write(getClass().getName());
out.write("<br> y la hora es " + horaactual + "<p/>");
}catch (IOException ex)
{
throw new JspTagException("Excepcion al cargar el fichero TLD " +ex.toString());
}
return EVAL_PAGE;
}
private String GetHora()

{
Date horaactual;
DateFormat formato;
String cadhora;
horaactual= Calendar.getInstance().getTime();
www.learning.es
formato= DateFormat.getTimeInstance();
cadhora=formato.format(horaactual);
return cadhora;
}
}
Ahora debemos irnos al descriptor de la aplicación web. Seleccionamos el fichero web.xml dentro de
la carpeta WEB-INF:
<?xml version="1.0" encoding="UTF-8"?> 97
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web
Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
<taglib>
<taglib-uri>mietiquetacustomtag</taglib-uri>
<taglib-location>/WEB-INF/FolderTLD/mensaje.tld</taglib-location>
</taglib>
</web-app>
La estructura de nuestra aplicación web quedaría de la siguiente forma:
Por último, escribiremos el siguiente código en la página index.jsp para realizar la llamada a la
librería Custom Tags que hemos creado:
<%@taglib uri="mietiquetacustomtag" prefix="MiEtiqueta" %>
<html>
<head>
</head>
<body>
<h1>Pagina realizada con Custom Tags</h1>
<MiEtiqueta:primera/>
</body>
</html>
www.learning.es
Como podremos comprobar al ejecutar la aplicación, la llamada a nuestro Custom tag se realiza
correctamente siempre y cuando hayamos configurado correctamente todo.
98
Ver Video: Arquitectura Struts, en la Unidad 7,

Laboratorio: Custom Tags Departamentos

Objetivos
 Conocer el funcionamiento de la tecnología Custom Tags.
 Representar datos en páginas JSP a partir de etiquetas Custom Tags.
Enunciado
Vamos a realizar una página JSP que mostrará una tabla con los datos de los departamentos.
Para ello, utilizaremos la tecnología Custom Tags.
La página JSP solamente contendrá una etiqueta Custom Tag que será la encargada de dibujar la
tabla.
Lo primero que vamos a realizar será crearnos un nuevo proyecto Web Application.
Nos creamos un nuevo proyecto Java Web:
www.learning.es
Lo llamaremos AplicacionCustomTags
99
Utilizaremos el servidor Apache Tomcat que trae el IDE Netbeans.
No implementaremos ningún Framework.

Sobre la carpeta WEB-INF, nos crearemos una nueva carpeta que llamaremos EtiquetasDEPT.
Para ello, seleccionamos la opción Folder dentro de la categoría Other.
Sobre la carpeta EtiquetasDEPT ya creada en nuestro proyecto, vamos a agregar un objeto Tag Library
Descriptor de la carpeta Web:
www.learning.es
100
Lo llamaremos etiquetadepartamentos
Escribiremos el siguiente código dentro del fichero etiquetadepartamentos.tld:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE taglib PUBLIC
"-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN"
"http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd">
<taglib>
<jspversion>2.0</jspversion>
<shortname>etiquetadepartamentos</shortname>
<tag>
<name>tabladepartamentos</name>
<tagclass>paquetecustomtags.EtiquetaTablaDept</tagclass>
<bodycontent>empty</bodycontent>
</tag>
</taglib>
A continuación nos crearemos una clase para poder implementar el código de la etiqueta que
acabamos de realizar.
www.learning.es
101
Crearemos la clase en un paquete llamado paquetecustomtags y le pondremos de nombre

EtiquetaTablaDept.
Lo que debemos realizar ahora es el acceso mediante JDBC a la tabla EMP de Oracle. Para ello,
debemos agregar dentro de la carpeta Libraries el conector JDBC para Oracle.
www.learning.es
102
A continuación, implementaremos el código de la clase EtiquetaTablaDept

package paquetecustomtags;
import java.io.IOException;
import javax.servlet.jsp.*;
import javax.servlet.jsp.tagext.TagSupport;
import java.util.*;
import java.text.*;
import java.sql.*;
public class EtiquetaTablaDept extends TagSupport {

@Override
public int doStartTag() throws JspTagException
{
return SKIP_BODY;
}
@Override
public int doEndTag() throws JspTagException
{
try
{
JspWriter out = pageContext.getOut();
DriverManager.registerDriver(new oracle.jdbc.OracleDriver());
Connection cn = DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE",
"SYSTEM", "12345");
Statement sentencia = cn.createStatement();
//(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY);
ResultSet rs = sentencia.executeQuery("SELECT * FROM DEPT");
out.write("<h1>Datos de los departamentos</h1>");
String tabla = "<table border='1'>";
tabla += "<tr><th>Numero</th><th>Nombre</th><th>Localidad</th></tr>";
while (rs.next())
{
tabla += "<tr>";
tabla += "<td>"+rs.getString(1)+"</td>";
tabla += "</tr>";
}
tabla += "</table>";
out.write(tabla);
}catch (Exception ex)
www.learning.es
{
throw new JspTagException("Excepcion al cargar el fichero TLD " +ex.toString());
}
return EVAL_PAGE;
}
}
Ahora debemos irnos al descriptor de la aplicación web.
Seleccionamos el fichero web.xml dentro de la carpeta WEB-INF y escribimos lo siguiente: 103
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web
Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
<taglib>
<taglib-uri>mietiquetacustomtag</taglib-uri>
<taglib-location>/WEB-INF/EtiquetasDEPT/etiquetadepartamentos.tld</taglib-location>
</taglib>
</web-app>
Ahora vamos a agregar una pagina JSP que dibujará los empleados que tenemos en la etiqueta
Custom Tag.
Le daremos el nombre tabladepartamentos
Implementamos el código para dibujar los departamentos.

<%@taglib uri="mietiquetacustomtag" prefix="tagdept" %>
<html>
<head>
www.learning.es
</head>
<body>
<tagdept:tabladepartamentos/>
</body>
</html> 104
Ya podremos ejecutar nuestro proyecto y comprobar el funcionamiento correcto de la aplicación:
Actividades
www.learning.es
Unidad 8. Arquitectura de seguridad
Introducción
Java contiene dos definiciones importantes:
 Es un lenguaje de programación orientado a objetos 105
 Es una plataforma software en la que se ejecutan programas.
La arquitectura de seguridad de cualquier lenguaje puede exponerse a través de su programación o

a través de sus entornos o componentes.
Los componentes principales de la plataforma Java son:
Un entorno de ejecución proporcionado por la Máquina Virtual Java (Java VM o JVM).
Este entorno de ejecución no es ni interpretado ni compilado, es un sistema híbrido.
Los programas se compilan en un formato independiente de la máquina denominado bytecode y son
interpretados por la Máquina Virtual, que es el único componente de Java que depende de la
plataforma en la que trabajamos (y, por lo tanto, debe ser portada a cada arquitectura).
La implementación de la JVM es la responsable de la seguridad incorporada en Java, por lo que es
importante que su implementación sea adecuada.
Un conjunto de interfaces y arquitecturas proporcionadas por la Interfaz con el programador de
aplicaciones Java (API de Java).
El API de Java es una colección de componentes software, agrupados en bibliotecas o paquetes de
componentes relacionados, que proporcionan multitud de capacidades útiles para el diseño de
interfaces gráficos, acceso a redes, gestión de E/S, etc.
En lo que respecta a la seguridad, el API de Java nos proporciona paquetes que implementan o dan
acceso a herramientas de seguridad de alto y bajo nivel como algoritmos de encriptación, firmas
electrónicas, gestión de certificados, etc.
La arquitectura de seguridad se puede exponer desde varios puntos de vista:
 Entorno de ejecución.
La seguridad de un sistema Java para los usuarios, está en la máquina virtual, ya que ésta es
la encargada de controlar las acciones que se pueden ejecutar y de que modo,
permitiéndonos de esta forma, controlar qué pueden hacer los programas al ejecutarse en
nuestro sistema.
 Interfaces y arquitecturas de seguridad.

Para que las aplicaciones cliente/servidor sean seguras, es necesario emplear técnicas
criptográficas.
Java proporciona una arquitectura en la que integrar estas técnicas y un conjunto de
interfaces para simplificar su uso en el desarrollo de aplicaciones.
Objetivos
 Comprender las diferentes alternativas que existen para crear una arquitectura de seguridad en un entorno
de desarrollo.
 Conocer el modelo de arquitectura de lenguaje y el modelo de arquitectura de componentes seguros.
Seguridad criptográfica
La criptología es el estudio de la criptografía y el criptoanálisis.
Viendo sus características en términos sociales, es la ciencia que permite que el coste de adquirir o
alterar información de modo impropio sea mayor que el posible valor obtenido al hacerlo.
Vista en términos más formales, es la práctica y el estudio de técnicas de encriptación y

desencriptación de información, es decir, de técnicas para codificar un mensaje haciéndolo
www.learning.es
ininteligible (encriptación) y recuperar el mensaje original a partir de esa versión ininteligible
(desencriptación).
Algoritmo criptográfico
Es un método matemático que se emplea para encriptar y desencriptar un mensaje.
Generalmente funciona empleando una o más claves (números o cadenas de caracteres) como 106
parámetros del algoritmo, de modo que sean necesarias para recuperar el mensaje a partir de la
versión cifrada.
El mensaje antes de encriptar se denomina texto en claro y una vez encriptado se denomina texto
cifrado.
Sistema criptográfico
Es un sistema para encriptar y desencriptar información compuesto por un conjunto de algoritmos
criptográficos, claves y, posiblemente, varios textos en claro con sus correspondientes versiones en
texto cifrado.
Criptoanálisis
Es el conjunto de procedimientos, procesos y métodos empleados para romper un algoritmo
criptográfico, desencriptar un texto cifrado o descubrir las claves empleadas para generarlo.
Los sistemas criptográficos actuales se basan, principalmente, en dos tipos de algoritmos

criptográficos:
 Algoritmos de clave privada o simétricos
Convierten un mensaje en un texto cifrado del mismo tamaño que el original.
Emplean una sola clave para encriptar y desencriptar.
Son los algoritmos empleados para transferir grandes cantidades de información de modo
seguro.
 Clave pública o asimétricos
Encriptan un mensaje generando un texto cifrado del mismo tamaño que el original.
Usan una clave para encriptar el mensaje (clave privada) y otra para desencriptar (clave
pública).
Tienen un coste computacional alto y se suelen emplear para distribuir las claves de los
algoritmos simétricos.
Algoritmos de cifrado simétrico

Dentro de estos algoritmos distinguimos dos tipos de algoritmos en función de la cantidad de datos
de entrada que manejan a la vez: algoritmos de cifrado por bloques y algoritmos de cifrado de flujo.
Cifrado por bloques
Los algoritmos de cifrado por bloques toman bloques de tamaño fijo del texto en claro y producen
un bloque de tamaño fijo de texto cifrado, generalmente del mismo tamaño que la entrada.
El tamaño del bloque debe ser lo suficientemente grande como para evitar ataques de texto cifrado.
La asignación de bloques de entrada a bloques de salida debe ser uno a uno para hacer el proceso
reversible y que su formación parezca aleatoria.
Para la asignación de bloques los algoritmos de cifrado simétrico realizan sustituciones y
permutaciones en el texto en claro hasta obtener el texto cifrado.
La sustitución es el reemplazo de un valor de entrada por otro de los posibles valores de salida, en
general, si usamos un tamaño de bloque n, el bloque de entrada puede ser sustituido por cualquiera
de los 2n bloques posibles.
La permutación es un tipo especial de sustitución en el que los bits de un bloque de entrada son
reordenados para producir el bloque cifrado, de este modo se preservan las estadísticas del bloque
de entrada.
www.learning.es
Los algoritmos de cifrado por bloques iterativos funcionan aplicando en sucesivas rotaciones una
transformación a un bloque de texto en claro.
La misma función es aplicada a los datos usando una subclave obtenida de la clave secreta
proporcionada por el usuario.
El número de rotaciones en un algoritmo de cifrado por bloques iterativo depende del nivel de
seguridad deseado.
Un tipo especial de algoritmos de cifrado por bloques iterativos son los denominados algoritmos de
cifrado de Feistel. 107
En estos algoritmos el texto cifrado se obtiene del texto en claro aplicando repetidamente la misma
transformación o función de rotación.
Una característica interesante de estos algoritmos es que la encriptación y desencriptación son
idénticas estructuralmente, aunque las subclaves empleadas en la encriptación se toman en orden
inverso en la desencriptación.
Para aplicar un algoritmo por bloques es necesario descomponer el texto de entrada en bloques de
tamaño fijo.
Algoritmos de clave pública o asimétricos

La criptografía de clave pública fue inventada en 1975 por Whitfield Diffie y Matin Hellman.
Se basa en emplear un par de claves distintas, una pública y otra privada.

La idea fundamental es que las claves están ligadas matemáticamente, pero es computacionalmente
imposible obtener una a partir de la otra.
Fundamentos matemáticos
Las funciones de una sola dirección son aquellas en las que obtener el resultado en una dirección es
fácil, pero en la otra es casi imposible.
Los algoritmos criptográficos de clave pública se basan en funciones de una sola dirección con
puerta trasera, que son aquellos en los que el problema es resoluble en la dirección opuesta (la que
antes era muy difícil) empleando una ayuda (la puerta trasera).
Los siguientes problemas matemáticos son considerados como funciones de una sola dirección con
puerta trasera y son la base de la mayoría de algoritmos de clave pública actuales:
 Factorización de enteros. Un número entero siempre se puede representar como un producto
de números primos denominados factores primos.
La factorización de enteros consiste en encontrar los factores primos de un número.
Los algoritmos criptográficos basados en este problema aprovechan el hecho de que la
multiplicación de números primos grandes es computacionalmente sencilla pero la
factorización un número grande en sus factores primos es muy cara computacionalmente.
 Logaritmos discretos. En aritmética módulo n dos enteros son equivalentes si tienen el
mismo resto cuando son divididos por n.
El resto de la división m / n es el menor entero no negativo que difiere de m por un múltiplo
de n.
La exponenciación discreta (ax mod n), es la exponenciación en aritmética módulo n.
Por ejemplo, 34 mod 10 es 81 mod 10, que es equivalente a 1 mod 10.
El logaritmo discreto es la operación inversa a la exponenciación discreta.
Los algoritmos que emplean este tipo de problema se basan en que la exponenciación
módulo n es un problema fácil y hallar el logaritmo discreto es un problema difícil.
 Logaritmos discretos de curva elíptica. Es una variación del problema anterior más cara
computacionalmente, lo que permite usar claves más pequeñas que mejoran las prestaciones
de los algoritmos y reducen el tamaño de los textos cifrados.
Tipos de algoritmo
En función de su relación matemática distinguimos varios tipos de algoritmo:
www.learning.es
 Reversible.
o Es aquel en el que un mensaje encriptado con la clave privada puede ser
desencriptado usando la clave pública y viceversa, es decir, uno encriptado usando la
clave pública puede ser desencriptado usando la privada.
 Irreversible.
o Es aquel en el que un mensaje encriptado usando la clave privada, puede ser
desencriptado con la clave pública, pero la clave privada no desencripta los mensajes 108
cifrados usando la clave pública.
 De intercambio de claves.
o Sólo permiten negociar de forma segura una clave secreta entre dos partes.
Hay que indicar que los algoritmos reversibles también se pueden emplear para esta función,
pero los irreversibles no.
Aplicaciones de los algoritmos
Este tipo de algoritmos tienen dos aplicaciones fundamentales:
 Encriptación:
Si un usuario A quiere mandar un mensaje a otro usuario B, lo encripta usando la clave
pública de B.
Cuando B lo recibe lo desencripta usando su clave privada. Si alguien intercepta el mensaje
no puede descifrarlo, ya que no conoce la clave privada de B, de hecho, ni siquiera A es
capaz de desencriptar el mensaje.
 Firmas digitales:
Si B encripta un mensaje usando su clave privada cualquiera que tenga su clave pública
podrá obtener el texto en claro correspondiente.
Si alguien quiere hacerse pasar por B tendrá que cifrar el mensaje usando la misma clave
privada o no se descifrará correctamente con la clave pública de B.
Lo que B ha hecho es firmar digitalmente el mensaje.
El proceso de desencriptar con una clave pública un mensaje firmado se denomina
verificación de firma.
Estos algoritmos son mucho más caros que los de clave secreta, por lo que no se usan para
encriptar mucha información.
Su principal aplicación está en la fase inicial de una comunicación, ya que permiten que los dos
extremos se autentifiquen e intercambien claves secretas para encriptar con un algoritmo simétrico.
El problema fundamental de este tipo de algoritmos es la distribución de las claves, aunque la clave
pública se puede distribuir libremente quedaría el problema de la suplantación.
Para solventar estos problemas se emplean autoridades certificadoras y certificados digitales.
Códigos de autentificación de mensajes y firmas digitales

Un código de autentificación de mensaje (message authentication code o MAC) es un bloque de
datos de tamaño fijo que se envía con un mensaje para averiguar su origen e integridad.
Son muy útiles para proporcionar autentificación e integridad sin confidencialidad.
Para generar MACs se pueden usar algoritmos de clave secreta, de clave pública y algoritmos de
resumen de mensajes.
Un tipo de MAC muy empleado en la actualidad es el código de autentificación de mensaje resumido

(hashed message authentication code o HMAC).
Lo que realiza es generar el MAC aplicando una función de dispersión criptográfica a un conjunto
formado por un mensaje y un código secreto.
www.learning.es
De esta forma, quien recibe el mensaje puede calcular su propio MAC con el mensaje y el código
secreto, que comparte con el que ha generado el MAC.
Si no coinciden, sabemos que el mensaje ha sido manipulado.
Este tipo de técnicas se emplean para proteger comunicaciones a nivel de la capa de red.
La firma digital es un elemento que responde del origen e integridad de un mensaje.

109
Quien escribe un mensaje lo firma usando una clave de firmado, y manda el mensaje y la firma
digital.
El destinatario usa una clave de verificación para comprobar el origen del mensaje y que no ha sido
modificado durante el tránsito.
Para firmar los mensajes se emplean algoritmos de clave pública y funciones de dispersión.
El proceso es el siguiente:
1. El emisor genera un resumen del mensaje, lo encripta con su clave privada (clave de
firmado) y envía el mensaje y el texto cifrado que corresponde al resumen del mensaje.
2. El destinatario genera un resumen del mensaje que recibe y desencripta el resumen cifrado
que lo acompañaba usando la clave pública del emisor (clave de verificación).
Si al comparar los resúmenes, ambos son iguales, el mensaje es válido y ha sido firmado por el
emisor real, ya que de otro modo no se hubiera podido desencriptar correctamente con su clave
pública.
Hay que indicar que los MAC y las firmas digitales se diferencian en un punto importante, aunque los
MAC se pueden usar para verificar la autenticidad de los mensajes, no se pueden usar para firmar
los mensajes, ya que sólo se usa una clave secreta que comparten el emisor y el receptor, lo que
hace que ambos puedan generar la misma firma.
Seguridad de los sistemas criptográficos

La seguridad de un sistema criptográfico depende generalmente de que al menos una de las claves
empleadas sea secreta, más que de que el algoritmo de encriptación sea secreto.
El publicar los algoritmos empleados por un sistema criptográfico para que sean revisados
públicamente es una buena práctica que permite que se mejoren algoritmos no totalmente seguros
o se considere que un algoritmo no tiene debilidades.
Los algoritmos criptográficos tienen distintos grados de seguridad

 Seguro computacionalmente.
Con suficiente poder de cálculo y almacenamiento, el sistema puede ser vulnerable, pero a
un coste tan elevado que no es práctico.
De cualquier forma, el coste computacional para considerar que un algoritmo es seguro ha
ido cambiando con el paso del tiempo.
Algoritmos antes considerados seguros, como el DES, han sido rotos en meses con sistemas
distribuidos, y en días, con sistemas diseñados específicamente para la tarea.
 Seguro incondicionalmente.
Son aquellos en los que aun disponiendo de recursos y gran cantidad de texto cifrado no es
posible romper el algoritmo.
Los únicos sistemas incondicionalmente seguros son los One Time Pads.
Un sistema criptográfico puede ser roto en varios niveles:
 Deducción de información. Se obtiene parte de información de la clave o del texto en claro.
 Deducción de una instancia. Se obtiene el texto en claro a partir de un texto cifrado.
 Deducción global. A partir de la deducción de una instancia, se obtiene un algoritmo que
obtiene los mismos resultados que el algoritmo original.
www.learning.es
 Rotura total. Se recupera la clave y se puede descifrar cualquier mensaje encriptado con la
misma clave.
Para romper un algoritmo se pueden emplear distintos tipos de ataque criptoanalítico:

 Ataque de sólo texto cifrado.
El analista dispone de un texto cifrado y quiere obtener el texto en claro o la clave.
Se pueden usar métodos de fuerza bruta (probando todas las claves posibles hasta que
obtenemos un mensaje con sentido) o basados en diccionario (probando únicamente con un 110
subconjunto de las claves posibles, por ejemplo si las claves son palabras).
Es importante disponer de suficiente texto en clave para que sea fácil identificar cual es el
texto en claro correcto.
 Ataque de texto en claro conocido.
El analista dispone de un texto en claro y su correspondiente texto cifrado, lo que permite
reducir el espacio de búsqueda de claves u obtener estadísticas que pueden usarse para
hacer deducciones en otros textos cifrados.
 Ataque de texto en claro conocido adaptativo.
Es igual que el anterior, pero el analista puede elegir nuevos textos dinámicamente y alterar
sus elecciones en función de los resultados que va obteniendo.
 Ataque de texto en claro elegido.
El analista puede elegir el texto en claro y obtener el texto cifrado correspondiente.
Este tipo de ataque puede evitar duplicados y centrarse más en las debilidades del algoritmo.
 Ataque de texto en claro elegido adaptativo. Es la versión adaptativa del ataque anterior.
Para que un sistema criptográfico sea considerado como seguro, debe contener las siguientes
características:
 Debe disponer de un número muy elevado de claves posibles, de modo que sea poco
razonable intentar descifrar un mensaje por el método de la fuerza bruta (probando todas las
claves).
 Debe producir texto cifrado que parezca aleatorio a un test estadístico estándar.
 Debe resistir todos los métodos conocidos de romper los códigos, es decir, debe ser
resistente al criptoanálisis.
Aplicaciones de la criptografía
La criptografía es una disciplina con multitud de aplicaciones, muchas de las cuales están en uso hoy
en día.
Entre las más importantes destacamos las siguientes:

 Seguridad de las comunicaciones.
Es la principal aplicación de la criptografía a las redes de ordenadores, ya que permiten
establecer canales seguros sobre redes que no lo son.
Además, con la potencia de cálculo actual y empleando algoritmos de cifrado simétrico (que
se intercambian usando algoritmos de clave pública) se consigue la privacidad sin perder
velocidad en la transferencia.
 Identificación y autentificación.
Gracias al uso de firmas digitales y otras técnicas criptográficas, es posible identificar a un
individuo o validar el acceso a un recurso en un entorno de red con más garantías que con
los sistemas de usuario y clave tradicionales.
 Certificación.
La certificación es un esquema mediante el cual, agentes fiables (como una entidad
certificadora) validan la identidad de agentes desconocidos (como usuarios reales).
El sistema de certificación es la extensión lógica del uso de la criptografía para identificar y
autentificar cuando se emplea a gran escala.
 Comercio electrónico.
www.learning.es
111
www.learning.es
Gracias al empleo de canales seguros y a los mecanismos de identificación se posibilita el
comercio electrónico, ya que tanto las empresas como los usuarios tienen garantías de que
las operaciones no pueden ser espiadas, reduciéndose el riesgo de fraudes y robos.
Tipos de algoritmos de cifrado simétrico

DES
112
El DES (Data Encription Standard o Estándar de Encriptación de Datos) es el nombre del documento
FIPS (Federal Information Processing Standard) 46-1 del Instituto Nacional de Estándares y
Tecnología (NIST) del Departamento de Comercio de Estados Unidos.
Fue publicado en 1977. En este documento se describe el DEA (Data Encription Algorithm o
Algoritmo de Encriptación de Datos.
Es el algoritmo de cifrado simétrico más estudiado, mejor conocido y más empleado del mundo.
El DEA (llamado con frecuencia DES) es un algoritmo de cifrado por bloques de 64 bits de tamaño.
Emplea una clave de 56 bits durante la ejecución (se eliminan 8 bits de paridad del bloque de 64).
El algoritmo fue diseñado para ser implementado en hardware.

Cuando se utiliza en comunicaciones, ambos participantes deben conocer la clave secreta.
El algoritmo se puede usar para encriptar y desencriptar mensajes, generar y verificar códigos de
autentificación de mensajes (MAC) y para encriptación de un sólo usuario.
Triple-DES
Consiste en encriptar tres veces una clave DES.
Esto se puede hacer de varias formas:

 DES-EEE3: Tres encriptaciones DES con tres claves distintas.
 DES-EDE3: Tres operaciones DES con la secuencia encriptar-desencriptar-encriptar con tres
claves diferentes.
 DES-EEE2 y DES-EDE2: Igual que los anteriores pero la primera y tercera operación emplean
la misma clave.
 Dependiendo del método elegido, el grado de seguridad varía; el método más seguro es el
DES-EEE3.
AES
El AES (Advanced Encription Standard o Estándar Criptográfico Avanzado) es un algoritmo de cifrado
por bloques destinado a reemplazar al DES como estándar.
RC2
El RC2 es un algoritmo de cifrado por bloques de clave de tamaño variable.
El algoritmo trabaja con bloques de 64 bits y entre dos y tres veces más rápido que el DES en
software.
Se puede hacer más o menos seguro que el DES contra algoritmos de fuerza bruta eligiendo el
tamaño de clave apropiadamente.
RC4
El RC4 es un algoritmo de cifrado de flujo.
Es un algoritmo de tamaño de clave variable con operaciones a nivel de byte. Se basa en el uso de
una permutación aleatoria y tiene un periodo estimado de más de 10100. Además, es un algoritmo
de ejecución rápida en software.
El algoritmo se emplea para encriptación de ficheros y para encriptar la comunicación en protocolos
como el SSL (TLS).
www.learning.es
RC5
El RC5 es un algoritmo parametrizable con tamaño de bloque variable, tamaño de clave variable y
número de rotaciones variable.
Los valores más comunes de los parámetros son 64 o 128 bits para el tamaño de bloque, de 0 a 255
rotaciones y claves de 0 a 2048 bits.
113
El RC5 tiene 3 rutinas: expansión de la clave, encriptación y desencriptación.
En la primera rutina la clave proporcionada por el usuario se expande para llenar una tabla de claves
cuyo tamaño depende del número de rotaciones.
La tabla se emplea en la encriptación y desencriptación. Para la encriptación sólo se emplean tres

operaciones: suma de enteros, o-exclusiva de bits y rotación de variables.
La mezcla de rotaciones dependientes de los datos y de distintas operaciones lo hace resistente al

criptoanálisis lineal y diferencial.
IDEA
El IDEA (International Data Encription Algorithm) es un algoritmo de cifrado por bloques de 64 bits
iterativo.
La clave es de 128 bits.
La encriptación precisa 8 rotaciones complejas.
El algoritmo funciona de la misma forma para encriptar que para desencriptar.

El algoritmo es fácilmente implementable en hardware y software, aunque algunas de las
operaciones que realiza no son eficientes en software, por lo que su eficiencia es similar a la del
DES.
SAFER
El SAFER (Secure And Fast Encription Routine) es un algoritmo de cifrado por bloques no
propietario.
Está orientado a bytes y emplea un tamaño de bloque de 64 bits y claves de 64 (SAFER K-64) o 128
bits (SAFER K-128).
Tiene un número variable de rotaciones, pero es recomendable emplear como mínimo 6.
Blowfish
Es un algoritmo de cifrado por bloques de 64 bits.
Es un algoritmo de tipo Feistel y cada rotación consiste en una permutación que depende de la clave
y una sustitución que depende de la clave y los datos.
Todas las operaciones se basan en o-exclusivas sobre palabras de 32 bits.
La clave tiene tamaño variable (con un máximo de 448 bits) y se emplea para generar varios
vectores de subclaves.
www.learning.es
Tipos de algoritmos de cifrado asimétrico
RSA
El RSA, llamado así por las siglas de sus creadores (Rivest, Shamir y Adelman), es el algoritmo de
clave pública más popular.
El algoritmo se puede usar para encriptar comunicaciones, firmas digitales e intercambio de claves. 114
La clave es de tamaño variable, generalmente se usan claves entre 512 y 2048 bits.
Las claves más grandes aumentan la seguridad del algoritmo pero disminuyen su eficiencia y
generan más texto cifrado.
Los bloques de texto en claro pueden ser de cualquier tamaño, siempre que sea menor que la
longitud de la clave.
Los bloques de texto cifrado generados son del tamaño de la clave.

La clave pública del algoritmo tiene la forma (e, n), donde e es el exponente y n el módulo.
La longitud de la clave es igual al número de bits de n.
El módulo se obtiene multiplicando dos números primos grandes, p y q.
Los números se seleccionan aleatoriamente y se guardan en secreto.
La clave privada tiene la forma (d, n), donde d es el producto inverso de e modulo (p-1)(q-1) (es
decir, (ed - 1) es divisible por (p-1)(q-1)).
El cálculo de d a partir de p y q es sencillo, pero es computacionalmente imposible calcular d sin

conocer p y q para valores grandes de n, ya que obtener sus valores es equivalente a factorizar n,
que es un problema intratable computacionalmente.
El funcionamiento del algoritmo es el siguiente:

Diffie-Hellman
El algoritmo de Diffie Hellman es un algoritmo de clave pública que permite el intercambio seguro de
un secreto compartido.
Generalmente se emplea junto con algoritmos de cifrado simétrico, como método para acordar una
clave secreta.
El algoritmo no se puede usar para encriptar conversaciones o firmas digitales.
SHA y SHA-1
El SHA (Secure Hash Algorithm) es un algoritmo de resumen seguro desarrollado por el NIST.
El SHA-1 es una versión corregida del algoritmo publicada en 1994.
El algoritmo es un estándar ANSI.
El algoritmo toma un mensaje de menos de 264 bits y genera un resumen de 160 bits.
Es más lento que el MD5, pero la mayor longitud de clave lo hace más resistente a ataques de
colisión por fuerza bruta y de inversión.
MD2, MD4 y MD5

Los tres son algoritmos de resumen de mensajes (el MD viene de Message Digest) desarrollados por
Rivest.
Los tres toman un mensaje de longitud arbitraria y generan un resumen de 128 bits.
El MD2 está optimizado para máquinas de 8 bits, mientras que el MD4 y MD5 son para arquitecturas
de 32 bits.
El MD2 funciona rellenando el mensaje para que tenga una longitud en bytes múltiplo de 16.
www.learning.es
Sobre ese mensaje se calcula un checksum de 16 bytes que se añade al mensaje y la función de
dispersión se aplica al mensaje resultante.
Con el MD4, el mensaje se rellena para que su longitud en bits más 448 sea divisible por 512.
Una representación de la longitud del mensaje de 64 bits se concatena entonces con el mensaje.
El mensaje se procesa iterativamente en bloques de 512 bits y cada bloque es procesado en tres
rotaciones distintas.
El algoritmo ha sido criptoanalizado y se han encontrado debilidades, de hecho es posible encontrar
colisiones en menos de un minuto en máquinas modernas, por lo que el algoritmo se considera a 115
todos los efectos roto.
El MD5 es, básicamente, el MD4 con mejoras en la seguridad, aunque es más lento que este.
El tamaño del resumen y la necesidad del relleno son iguales que en el MD4.
Consta de cuatro rotaciones que tienen un diseño ligeramente diferente a las del MD4.
El algoritmo ha sido criptoanalizado con técnicas similares a las del MD4 y se han encontrado
pseudo-colisiones en la función de compresión, pero no en el algoritmo completo.
Certificados digitales
Los certificados digitales son el equivalente digital del DNI, en lo que a la autentificación de
individuos se refiere, ya que permiten que un individuo demuestre que es quien dice ser, es decir,
que está en posesión de la clave secreta asociada a su certificado.
Para los usuarios, proporcionan un mecanismo para verificar la autenticidad de programas y

documentos obtenidos a través de la red, el envío de correo encriptado y/o firmado digitalmente, el
control de acceso a recursos, etc.
Un certificado de clave pública es un punto de unión entre la clave pública de una entidad y uno o
más atributos referidos a su identidad.
El certificado garantiza que la clave pública pertenece a la entidad identificada y que la entidad
posee la correspondiente clave privada.
Los certificados de clave pública se denominan comúnmente Certificado Digital, ID Digital o

simplemente certificado.
La entidad identificada se denomina sujeto del certificado o subscriptor (si es una entidad legal
como, por ejemplo, una persona).
Los certificados digitales sólo son útiles si existe alguna Autoridad Certificadora (Certification
Authority o CA) que los valide, ya que si uno se certifica a sí mismo no hay ninguna garantía de que
su identidad sea la que anuncia, y por lo tanto, no debe ser aceptada por un tercero que no lo
conozca.
Es importante ser capaz de verificar que una autoridad certificadora ha emitido un certificado y
detectar si un certificado no es válido.
Para evitar la falsificación de certificados, la entidad certificadora después de autentificar la
identidad de un sujeto, firma el certificado digitalmente.
Los certificados digitales proporcionan un mecanismo criptográfico para implementar la
autentificación, también proporcionan un mecanismo seguro y escalable para distribuir claves
públicas en comunidades grandes.
Certificados X.509
El formato de certificados X.509 es un estándar del ITU-T (International Telecommunication Union-
Telecommunication Standarization Sector) y el ISO/IEC (International Standards Organization /
International Electrotechnical Commission) que se publicó por primera vez en 1988.
El formato de la versión 1 fue extendido en 1993 para incluir dos nuevos campos que permiten
soportar el control de acceso a directorios.
www.learning.es
Después de emplear el X.509 v2 para intentar desarrollar un estándar de correo electrónico seguro,
el formato fue revisado para permitir la extensión con campos adicionales, dando lugar al X.509 v3,
publicado en 1996.
Los elementos del formato de un certificado X.509 v3 son:
 Versión. El campo de versión contiene el número de versión del certificado codificado.
 Número de serie del certificado. Este campo es un entero asignado por la autoridad
certificadora.
116
Cada certificado emitido por una CA debe tener un número de serie único.
 Identificador del algoritmo de firmado. Este campo identifica el algoritmo empleado para
firmar el certificado (como por ejemplo el RSA o el DSA).
 Nombre del emisor. Este campo identifica la CA que ha firmado y emitido el certificado.
 Periodo de validez. Este campo indica el periodo de tiempo durante el cual el certificado es
válido y la CA está obligada a mantener información sobre el estado del mismo.
El campo consiste en una fecha inicial, la fecha en la que el certificado comienza a ser válido
y la fecha después de la cual, el certificado deja de serlo.
 Nombre del sujeto. Este campo identifica la identidad cuya clave pública está certificada en
el campo siguiente.
El nombre debe ser único para cada entidad certificada por una CA dada, aunque puede
emitir más de un certificado con el mismo nombre si es para la misma entidad.
 Información de clave pública del sujeto. Este campo contiene la clave pública, sus
parámetros y el identificador del algoritmo con el que se emplea la clave.
 Identificador único del emisor. Este es un campo opcional que permite reutilizar nombres de
emisor.
 Identificador único del sujeto. Este es un campo opcional que permite reutilizar nombres de
sujeto.
Extensiones de certificado
Las extensiones del X.509 proporcionan una manera de asociar información adicional a sujetos,
claves públicas, etc.
Un campo de extensión contiene tres partes:
 Tipo de extensión. Es un identificador de objeto que proporciona la semántica y el tipo de
información (cadena de texto, fecha u otra estructura de datos) para un valor de extensión.
 Valor de la extensión. Este subcampo contiene el valor actual del campo.
 Indicador de importancia. Es una etiqueta que indica a una aplicación si es seguro ignorar el
campo de extensión si no reconoce el tipo.
El indicador proporciona una manera de implementar aplicaciones que trabajan de modo
seguro con certificados y evolucionan conforme se van añadiendo nuevas extensiones.
El formato de certificados X.509 se especifica en un sistema de notación denominado sintaxis
abstracta uno (Abstract Sintax One o ASN-1).
Para la transmisión de los datos se aplica el DER (Distinguished Encoding Rules o reglas de
codificación distinguible), que transforma el certificado en formato ASN-1 en una secuencia de
octetos apropiada para la transmisión en redes reales.
Autoridades Certificadoras
Una autoridad certificadora es una organización fiable que acepta solicitudes de certificados de
entidades, las valida, genera certificados y mantiene la información de su estado.
Una CA debe proporcionar una Declaración de Prácticas de Certificación (Certification Practice
Statement o CPS) que indique claramente sus políticas y prácticas relativas a la seguridad y
mantenimiento de los certificados, las responsabilidades de la CA respecto a los sistemas que
emplean sus certificados y las obligaciones de los subscriptores respecto de la misma.
Las labores de un CA son:
 Admisión de solicitudes. Un usuario rellena un formulario y lo envía a la CA solicitando un
certificado.
www.learning.es
La generación de las claves pública y privada son responsabilidad del usuario o de un sistema
asociado a la CA.
 Autentificación del sujeto. Antes de firmar la información proporcionada por el sujeto, la CA
debe verificar su identidad.
Dependiendo del nivel de seguridad deseado y el tipo de certificado se deberán tomar las
medidas oportunas para la validación.
 Generación de certificados. Después de recibir una solicitud y validar los datos, la CA genera
117
el certificado correspondiente y lo firma con su clave privada.
Posteriormente lo manda al subscriptor y, opcionalmente, lo envía a un almacén de
certificados para su distribución.
 Distribución de certificados. La entidad certificadora puede proporcionar un servicio de
distribución de certificados para que las aplicaciones tengan acceso y puedan obtener los
certificados de sus subscriptores.
Los métodos de distribución pueden ser: correo electrónico, servicios de directorio como el
X.500 o el LDAP, etc.
 Anulación de certificados. Al igual que sucede con las solicitudes de certificados, la CA debe
validar el origen y autenticidad de una solicitud de anulación.
La CA debe mantener información sobre una anulación durante todo el tiempo de validez del
certificado original.
 Almacenes de datos. Hoy en día existe una noción formal de almacén donde se guardan los
certificados y la información de las anulaciones. La designación oficial de una base de datos
como almacén tiene por objeto señalar que el trabajo con los certificados es fiable y de
confianza.
Los mensajes de datos de la aplicación son transportados por la capa de registro y son
fragmentados, comprimidos y encriptados basándose en el estado actual de la conexión. Los
mensajes se tratan como datos transparentes para la capa de registro.
Arquitectura de seguridad por componentes

La seguridad por componentes se limita al ámbito del desarrollo en cuestión y al entorno sobre el
que se establecerá el tipo de desarrollo.
Los servicios de seguridad de Java EE proporcionan un mecanismo robusto y fácilmente configurable

para autenticación y autorización de acceso en diferentes niveles:
 Aplicación.
 Transporte.
 Contenido de Mensajes.
Un mecanismo de seguridad implementado correctamente debe proporcionar la siguiente

funcionalidad:
 Prevenir accesos no autorizados a componentes y datos de la aplicación.
 Responsabilizar a los usuarios por las operaciones que realicen (non-repudiation).
 Facilitar su administración.
 Proporcionar mecanismos transparentes para los usuarios.
 Ser homogéneo a través de aplicaciones.
Existen varios mecanismos de seguridad que permiten realizar estas acciones:

 Identificación (identification): Mecanismo que permite el reconocimiento de una entidad
(usuario) por un sistema.
 Autenticación (authentication): Mecanismo por el cual los usuarios se validan y se comprueba
que existen en nuestro ámbito de seguridad.
www.learning.es
 Autorización (authorization o access control): Mecanismo para asegurar que los usuarios
tienen permiso para realizar operaciones o para obtener acceso a la información.
 Integridad de datos (data integrity): Mecanismo usado para probar que la información no ha
sido modificada por usuarios no autorizados.
 Confidencialidad (confidentiality o data privacy): Mecanismo usado para asegurar que sólo
usuarios autorizados puedan ver cierta información.
 No-rechazo (non-repudiation): Mecanismo para impedir que un usuario niegue haber 118
realizado alguna operación.
 Auditoría (auditing): Mecanismo para capturar registros de operaciones, a prueba de
falsificaciones.
Implementación de la seguridad servidor y EJB

Existen diversas formas de configurar la seguridad dentro de las aplicaciones Java EE.
Seguridad a nivel de servidor

Una de las formas que podemos utilizar es mediante el servidor de aplicaciones. Dentro del
servidor, podemos utilizar diversos mecanismos de seguridad configurables:
 Creación y mantenimiento de políticas de seguridad.
 Administración de ámbitos “realms”.
 Altas, bajas y cambios de usuarios autorizados.
 HTTP e IIOP Listeners.
 Conectores.
 Inserción (plug-in) de otros programas de seguridad.
 Inserción (plug-in) de módulos de auditoría.
Seguridad a nivel declarativo (EJB)

La seguridad a nivel declarativo, implica que la seguridad se monta dentro de la propia aplicación
empresarial, utilizando anotaciones o archivos descriptores.
Para utilizar la seguridad a nivel declarativo se utilizan una serie de elementos que pueden formar
grupos o usuarios individuales, dependiendo del tipo de validación que deseamos utilizar.
 Realms: Colección de usuarios (que pueden o no pertenecer a un grupo) y grupos de
usuarios controlados por la misma política de seguridad.
Existen 3 tipos: file, admin y certificate realms.

 Users: Individuos (o programas de aplicación) definidos en el Servidor de aplicaciones.
 Groups: Conjuntos de usuarios clasificados normalmente por características comunes.
 Roles: Nombres abstractos que identifican los permisos para acceder a un conjunto de
recursos. Se mapean a grupos o roles.
 Principal: Una entidad (usuario o aplicación) que puede ser autenticado.
 Security policy: Es el alcance de una política de seguridad domain implementada por un
servicio de seguridad.
 Security attributes: Características de seguridad asociadas a un usuario.
 Credentials: Conjunto de security attributes usados para autenticar un principal.
Los servicios de seguridad de Java EE se implementan mediante una o algunas de las siguientes
formas:
 Anotaciones: La información de seguridad se especifica dentro de las mismas clases.
 Declarativa: La información de seguridad se especifica en el deployment descriptor. (Los
valores especificados en el descriptor sustituyen a los de las anotaciones.)
 Programática: Postulados embebidos en las clases.
www.learning.es
Los Enterprise Java Beans (Session y Message Driven) pueden implementar la seguridad declarativa
y hace uso de la seguridad mediante las siguientes formas:
 Declarando nombres de roles referenciados desde el código del bean.
 Utilizando anotaciones.
 Utilizando elementos en un deployment descriptor.
Para poder utilizar dichas características, será necesario tener acceso al “contexto de seguridad”,
que es un objeto creado por el contenedor de EJB. 119
Para tener acceso a dicho contexto de seguridad se utiliza la siguiente nomenclatura de código:
@Resource SessionContext contextoseguro
contextoseguro.getCallerPrincipal( )
contextoseguro.isCallerInRole(String roleName)
Un ejemplo de seguridad utilizando el método getCallerPrincipal().
Dicho método valida los usuarios dentro del propio código y se validaría el nombre del usuario.
package newpackage;
import java.security.Principal;
import javax.annotation.Resource;
import javax.ejb.SessionContext;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
@Stateless
public class NewSessionBean {
@Resource SessionContext contextoseguridad;
@PersistenceContext EntityManager em;
public void CambiarNombre() {
//obtenemos el usuario Principal de la aplicación.
Principal usuarioPrincipal;
String nombreusuario;
usuarioPrincipal = contextoseguridad.getCallerPrincipal();
//Obtenemos el nombre del usuario.
nombreusuario = usuarioPrincipal.getName();
//Para buscar usuarios, enviamos la entidad
//y el nombre del usuario, que estaría validado en
//el método findByPrimaryKey
Emp empleado =
em.findByPrimaryKey(Emp.class, nombreusuario);
//Si llegamos a este punto, podriamos modificar los datos
//del usuario mediante métodos implementados...
empleado.setEName("oldname","newname");
}
}
Como podemos comprobar, los usuarios se validarían antes de la acción del método, y una vez
validados, el propio método comprobaría su nombre de usuario para poder realizar las acciones.
Otro tipo de validación se puede realizar con el método isCallerInRole(role), que permite validar
usuarios mediante grupos o roles a los que perteneces, no validaría un usuario Principal, sino que
utiliza anotaciones en el propio bean para definir los grupos de usuarios a los que se les permite
acceso:
package newpackage;
import javax.annotation.Resource;
import javax.annotation.security.DeclareRoles;
import javax.ejb.SessionContext;
www.learning.es
@DeclareRoles("EJECUTIVOS")
@Stateless
public class NewSessionBean {
@Resource SessionContext contextoseguridad;
public void ModificarSalarioEmpleado(int nuevosalario, int idempleado) {

// El campo salario solamente puede ser 120
//modificado por usuarios que se encuentren
//dentro del rol EJECUTIVOS.
if (contextoseguridad.isCallerInRole("EJECUTIVOS")==false)
{
throw new SecurityException("No tiene permisos para modificar el salario");
}else{
//Acciones en la base de datos para modificar
//el salario de los empleados...
}
}
}
Los nombres de los roles usados en el código de los beans se pueden declarar de dos formas
diferentes:
 Utilizando la anotación @DeclareRoles (preferida)
 Usando la etiqueta en el fichero deployment descriptor.
Este role de seguridad permite poder modificar los datos de los empleados. Solamente están
admitidos los roles de EJECUTIVOS
<enterprise-beans>
<session>
<ejb-name> NewSessionBean</ejb-name>
<ejb-class> NewSessionBean</ejb-class>
<security-role-ref>
<description>
</description>
<role-name> EJECUTIVOS </role-name>
</security-role-ref>
</session>
...
</Enterprise-beans>
También podemos definir los permisos que necesitamos administrar a nivel de método de la clase.
Los permisos de métodos se pueden especificar a nivel de clase o a nivel de método (o ambos).
Para ello, debemos emplear las siguientes anotaciones:

 @RolesAllowed("lista de roles")
 @PermitAll
 @DenyAll
Un ejemplo para ofrecer permisos en los métodos sería el siguiente:

Código de la clase que permite acceso a los administradores
import javax.annotation.security.RolesAllowed;
@RolesAllowed("administrador")
public class MiClase
{
public void PrimerMetodo () {...}
public void SegundoMetodo () {...}
}
Código de la clase del Bean
www.learning.es
@Stateless
public class NewSessionBean implements MiBean extends MiClase
{
@RolesAllowed("usuarios")
public void PrimerMetodo () {...}
public void SegundoMetodo () {...}
public void OtroMetodo () {...}
} 121
Si analizamos el código anterior, los administradores podrán obtener acceso a los dos método del objeto
“MiClase”, pero en el método PrimerMetodo(), también tendrán acceso los usuarios, mientras que en el método
SegundoMetodo() solamente podrán acceder los administradores como roles.
Seguridad de aplicaciones web en servlets y jsp

Se utilizan las mismas técnicas de seguridad que para el caso de los Enterprise Beans:
 Declaración de roles de seguridad.
 Declaración de requerimientos de seguridad
También se utilizan otras técnicas específicas para el contenedor Web:

 Restricciones de seguridad.
 Conexiones seguras.
 Mecanismos de autenticación específicos.
Para poder crearnos Roles de seguridad tenemos dos formas de realizar la acción:
Mediante anotaciones en un servlet (por ejemplo)
@DeclareRoles("administrador")
public class MiServlet {
//CODIGO DEL SERVLET
}
Mediante el fichero web.xml:
<security-role>
<role-name> administrador</role-name>
</security-role>
También podemos especificar la seguridad propia de cada uno de los servlets en el fichero web.xml:
<servlet>
<security-role-ref>
<rol-name>admin</rol-name>
<rol-link>administrador</rol-link> Este sera el nombre del ROLE utilizando en el código del
servlet para la validación
</security-role-ref>
</servlet>
Al igual que con los EJB, podemos realizar mapeos de nombres a grupos, pero se escribirían en el
descriptor de la aplicación, no el fichero web.xml.
<sun-web-app>
<security-role-mapping>
<role-name>administradores</role-name>
<principal-name>admin1</principal-name>
<principal-name>admin2</principal-name>
</security-role-mapping>
<security-role-mapping>
<role-name>Becarios</role-name>
<group-name>beca</group-name>
</security-role-mapping>
..</sun-web-app>
Dentro de los servlets, tenemos tres métodos para implementar sobre la interfaz HttpServletRequest
que nos permiten el acceso a la información de seguridad:
www.learning.es
 String getRemoteUser( )
 Principal getUserPrincipal()
 boolean isUserInRole(String roleName)
Por ejemplo, vamos a visualizar un servlet que valida los usuarios que se han conectado en nuestra
aplicación:
package newpackage;
import java.io.IOException; 122
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.annotation.security.DeclareRoles;
@DeclareRoles({"admin", "user"})
public class ServletSeguridad extends HttpServlet {
protected void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
try {
out.println("<html>");
out.println("<head>");
out.println("<title>Servlet ServletSeguridad</title>");
out.println("</head>");
out.println("<body>");
out.println("<h1>Servlet con Seguridad</h1>");
if (request.isUserInRole("admin"))
{
out.println("Bienvenido administrador");
out.println("TIENE TODOS LOS PERMISOS");
}
if (request.isUserInRole("user"))
{
out.println("Bienvenido USUARIO");
out.println("SUS PERMISOS SON LIMITADOS...");
}
out.println("</body>");
out.println("</html>");
} finally {
out.close();
}
}
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
processRequest(request, response);
}
@Override
protected void doPost(HttpServletRequest request, HttpServletResponse response)
processRequest(request, response);
}
}
www.learning.es
123
www.learning.es
Ver Video: Implementando Seguridad, en la Unidad 8,
Laboratorio: Uso de Criptografía 124
Objetivos
 Comprobar el funcionamiento de la criptografía dentro del entorno de Java.
 Aprender a cifrar y descifrar mensajes mediante la criptografía simétrica en aplicaciones
Java.
Enunciado
En este laboratorio realizaremos una aplicación gráfica de swing en la que cifraremos el contenido de
un texto mediante un password y lo descifraremos posteriormente.
El método de encriptación se realizará mediante base 64, por lo que escribiremos los bytes de la
encriptación dentro de un fichero para, posteriormente, leerlos y desencriptarlos.
Dicha encriptación nos permitiría guardar los datos en cualquier tipo de soporte para bytes[], por lo
que sería muy útil también para encriptar datos en Bases de datos.
Comenzaremos creándonos un nuevo proyecto Java  Java Application en NetBeans.
Llamaremos al proyecto ProyectoEncriptacion
www.learning.es
Sobre el proyecto seleccionaremos un nuevo elemento:
125
Y sobre la carpeta Formularios de Interfaz gráfica Swing, seleccionamos un Formulario JFrame:
Le pondremos el nombre FormularioSeguridad y lo incluimos en un paquete llamado pk_seguridad.
Este es el diseño de nuestro proyecto:
A continuación, realizaremos el siguiente diseño en la ventana del JFrame:

Controles del formulario (sin las etiquetas descriptivas):
www.learning.es
126
www.learning.es
JTextField  txttexto
JTextField  txtpass
JButton  btncifrar
JButton  btndescifrar
JTextArea  txtresultado
127
A continuación, debemos implementar nuestro código por pasos.

Lo primero será importar el espacio de nombres:
import javax.crypto.*;
Nuestra aplicación utilizará un password para poder encriptar y desencriptar los datos, por lo que
debemos crearnos un método que nos devolverá un objeto SecretKey a partir de la palabra que
escribamos en la caja de texto:
private SecretKey generarClave()
{
try
{
String password = this.txtpass.getText();
DESKeySpec desKeySpec = new DESKeySpec(password.getBytes());
SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("DES");
SecretKey clave = keyFactory.generateSecret(desKeySpec);
return clave;
{
JOptionPane.showMessageDialog(this, ex.toString());
return null;
}
}
Ahora nos crearemos un método que se encargará de cifrar un texto que enviaremos a partir de una
clave generada y que nos devolverá un array de byte[] de salida con el resultado de la encriptación.
private byte[] encriptarTexto(String texto, SecretKey clave)
{
try
{
//Creamos el objeto que se encargara de cifrar el mensaje
Cipher encriptar = Cipher.getInstance("DES/ECB/PKCS5Padding");
//Iniciamos el objeto en modo Encriptar
encriptar.init(Cipher.ENCRYPT_MODE, clave);
//Obtenemos la salida del mensaje encriptado
byte[] mensajeencriptado = encriptar.doFinal(texto.getBytes(), 0, texto.getBytes().length);
return mensajeencriptado;
www.learning.es
{
return null;
}
}
A continuación, debemos crearnos un método que se encargará de escribir los datos binarios del
array byte[] dentro de un fichero. 128
Dicho método nos permitiría, posteriormente si lo desearamos, escribir sobre una base de datos o
sobre un documento xml.
private void escribirDatosFichero(byte[] entrada)
{
try
{
FileOutputStream fileOutput = new FileOutputStream("C:\\textocifrado.bin");
BufferedOutputStream bufferedOutput = new BufferedOutputStream(fileOutput);
bufferedOutput.write(entrada,0,entrada.length);
bufferedOutput.close();
{
}
}
Ahora ya podemos implementar el código del ActionPerformed del botón de Cifrar.
Para ello, en el diseñador del JFrame, pulsamos dos veces sobre el botón de Cifrar y nos mostrará el
siguiente código:
private void btncifrarActionPerformed(java.awt.event.ActionEvent evt) {
}
Ahí implementaremos el código que nos permitirá cifrar el texto mediante un password y poder
escribir el resultado en un fichero.
El código que escribiremos será el siguiente:
private void btncifrarActionPerformed(java.awt.event.ActionEvent evt) {
try
{
//Generamos nuestra clave secreta para utilizada para cifrar nuestro mensaje
SecretKey clave = this.generarClave();
String mensaje = this.txttexto.getText();
byte[] resultadocifrado = this.encriptarTexto(mensaje, clave);
String textocifrado = new String(resultadocifrado);
this.txtresultado.setText(textocifrado);
this.escribirDatosFichero(resultadocifrado);
JOptionPane.showMessageDialog(this,"El mensaje encriptado es: " + new String(resultadocifrado));
{
}
}
A continuación, debemos implementar los elementos para desencriptar el mensaje que hemos
almacenado en un fichero.
Nos crearemos un método que nos permite leer del fichero binario y devolver un array de bytes[]
con el resultado:
private byte[] leerDatosFichero()
{
try
{
FileInputStream ficherooriginal = new FileInputStream("C:\\textocifrado.bin");
BufferedInputStream lector = new BufferedInputStream(ficherooriginal);
www.learning.es
ByteArrayOutputStream salida = new ByteArrayOutputStream();
byte [] array = new byte[1000];
int leidos = lector.read(array);
while (leidos > 0)
{
salida.write(array,0,leidos);
leidos=lector.read(array);
} 129
// Cierre de los ficheros
lector.close();
return salida.toByteArray();
{
return null;
}
}
Ahora que ya tenemos todo el código para leer los bytes[] que deseamos desencriptar, pulsaremos
dos veces sobre el botón Descifrar y escribiremos el siguiente código:
private void btndescifrarActionPerformed(java.awt.event.ActionEvent evt) {
try
{
//Iniciamos ahora un objeto que se encargara de desencriptar el mensaje
Cipher desencriptar = Cipher.getInstance("DES/ECB/PKCS5Padding");
SecretKey clave = this.generarClave();
//Inicializamos el objeto en modo Desencriptar
desencriptar.init(Cipher.DECRYPT_MODE, clave);
byte[] datosentrada = leerDatosFichero();
byte[] msjDesencriptado = desencriptar.doFinal(datosentrada, 0, datosentrada.length);
JOptionPane.showMessageDialog(this,"\nEl mensaje desencriptado es: " + new
String(msjDesencriptado));
{
}
}
Ya podremos probar nuestra aplicación y comprobar su funcionamiento:
Cuando pulsemos sobre Cifrar:
Y si utilizamos la misma clave, podremos comprobar que descifrará el texto correctamente:
www.learning.es
130
Actividades
www.learning.es
Unidad 9. Arquitectura de software
Introducción
La arquitectura de software es, independientemente del lenguaje con el que se implemente:
 Un diseño de alto nivel. 131
 La estructura del sistema.
 Los componentes de un programa o sistema, sus relaciones, los principios que gobiernan su
diseño y su evolución en el tiempo.
 Componentes y conectores.
 Componentes, conectores, configuración y restricciones.
 Estructura del sistema
La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus

componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y
evolución.
La primera actividad del diseño de la arquitectura de un sistema de software es definir un conjunto
de sub-sistemas que componen el sistema completo.
Una primera aproximación es un diagrama de cajas y flechas donde las cajas corresponden a sub-
sistemas y las flechas son flujos de datos o de control.
Se tiene una visión general del sistema usando pocos componentes.
Las características de utilizar la arquitectura de software pueden definir los siguientes elementos
para el entorno de desarrollo:
 Portabilidad: permite ver si el sistema va a ser portable.
 Permite estar preparado para el cambio (identificar elementos críticos al comienzo de
cualquier desarrollo).
La arquitectura tiene un impacto relevante ya que se detectan las partes más críticas de forma
temprana.
Los problemas se detectan antes y se solucionan mejor, debido a que toda la base ya está
estructurada
El coste del mantenimiento se reduce.
Permite identificar decisiones de diseño tempranamente.
Permite tener una idea general del sistema para aminorar riesgos.
Un intento de formalizar la forma en que se comunica y reusa la experiencia de diseño.
Captura la experiencia probada de diseño de software.
Describen problemas recurrentes que surgen en determinados contextos.
Describen esquemas de soluciones probados. Herramientas para los no expertos.
Un patrón de arquitectura de software es un esquema genérico probado para solucionar un
problema particular recurrente que surge en un cierto contexto.
Este esquema se especifica describiendo las componentes, con sus responsabilidades, relaciones y
las formas en que colaboran.
Existen multitud de definiciones para la arquitectura de software, todas ellas dependen del modelo
dónde se vayan a aplicar.
Objetivos
 Comprender el análisis y la estructura de la arquitectura de software.
 Su uso y desarrollo en los proyectos y su unión o diferenciación con UML.
Modelos de arquitectura
 Modelos estructurales
Sostienen que la arquitectura de software está compuesta por componentes, conexiones
entre ellos y, en algunas ocasiones, otros aspectos tales como configuración, estilo,
www.learning.es
restricciones, semántica, análisis, propiedades, racionalizaciones, requerimientos,
necesidades de los participantes.
El trabajo en esta área, está caracterizado por el desarrollo de lenguajes de descripción
arquitectónica (ADLs).
 Modelos de framework
Son similares a la vista estructural, pero su característica principal radica en la estructura
coherente del sistema completo, en lugar de concentrarse en su composición.
Los modelos de framework a menudo se refieren a dominios o clases de problemas 132
específicos.
El trabajo que ejemplifica esta variante incluye arquitecturas de software específicas de
dominios, como CORBA, o modelos basados en CORBA, o repositorios de componentes
específicos.
 Modelos dinámicos: Enfatizan la cualidad conductual de los sistemas.
La palabra “dinámico” puede referirse a los cambios en la configuración del sistema, o a la
dinámica involucrada en el progreso de la computación, tales como valores cambiantes de
datos.
 Modelos de proceso
Se concentran en la construcción de la arquitectura, y en los pasos o procesos involucrados
en esa construcción.
En esta perspectiva, la arquitectura es el resultado de seguir un argumento (script) de
proceso.
Esta vista se ejemplifica con el actual trabajo sobre programación de procesos para derivar
arquitecturas.
 Modelos funcionales
Una minoría considera la arquitectura como un conjunto de componentes funcionales,
organizados en capas que proporcionan servicios hacia arriba.
Podríamos pensar en esta visión como un framework particular.
Ninguna de estas vistas excluye a las otras, ni representa un conflicto fundamental sobre lo que es o
debe ser la arquitectura de software.
Por el contrario, representan un espectro en la comunidad de investigación sobre distintos puntos de
vista que pueden aplicarse a la arquitectura, involucrando sus partes constituyentes, su totalidad y
la forma en que se comporta una vez construida, o el proceso de su construcción.
Tomadas en su conjunto, destacan como una especie de elementos conjuntos que se separan en
capas.
Más allá de que existen numerosos conceptos en el plano detallado de las técnicas y metodologías,
la arquitectura de software se desarrolla alrededor de unos pocos conceptos y principios esenciales y
unas pocas herramientas características.
La arquitectura de software es el primer paso en la producción de un diseño de software, en una
secuencia que distingue tres pasos:
1) Arquitectura.
Asocia las capacidades del sistema especificadas en el requerimiento con los componentes
del sistema que habrán de implementarla.
La descripción arquitectónica incluye componentes y conectores (en términos de estilos) y la
definición de operadores que crean sistemas a partir de subsistemas o, en otros términos,
componen estilos complejos a partir de estilos simples.
2) Diseño del código.

Comprende algoritmos y estructuras de datos.
Los componentes son elementos primitivos del lenguaje de programación, tales como
números, caracteres, punteros e hilos de control.
También existen operadores primitivos.
3) Diseño ejecutable.
Remite al diseño de código a un nivel de detalle todavía más bajo y trata cuestiones tales
como la asignación de memoria, los formatos de datos, etc.
www.learning.es
133
www.learning.es
Estilos Un estilo es un concepto descriptivo que define una forma de articulación u organización
arquitectónica.
El conjunto de los estilos cataloga las formas básicas posibles de estructuras de software, mientras
que las formas complejas se articulan mediante composición de los estilos fundamentales.
Los estilos conjugan elementos o componentes, conectores, configuraciones y restricciones.
Al utilizar los conectores como componentes de primera clase, el concepto de estilo se sitúa en un
orden de discurso y de método que el modelado orientado a objetos en general, y UML en particular,
no cubren satisfactoriamente. 134
La descripción de un estilo se puede formular en lenguaje natural o en diagramas, pero lo mejor es
hacerlo en un lenguaje de descripción arquitectónica o en lenguajes formales de especificación.
A diferencia de los patrones de diseño, los estilos se ordenan en seis o siete clases fundamentales y
unos veinte ejemplares, como máximo.
Las arquitecturas complejas o compuestas resultan de la composición de estilos más básicos.
Algunos estilos típicos son las arquitecturas basadas en flujo de datos, las peer-to-peer, las de
invocación implícita, las jerárquicas, las centradas en datos o las de intérprete-máquina virtual.
Lenguajes de descripción arquitectónica

Los lenguajes de descripción de arquitecturas, o ADLs, ocupan una parte importante del trabajo
arquitectónico desde la fundación de la disciplina.
Se trata de un conjunto de propuestas de variado nivel de rigurosidad, casi todas ellas de extracción
académica, que fueron surgiendo desde comienzos de la década de 1990 hasta la actualidad, más o
menos en contemporaneidad con el proyecto de unificación de los lenguajes de modelado bajo la
forma de UML.
Los ADLs permiten modelar una arquitectura mucho antes que se lleve a cabo la programación de
las aplicaciones que la componen, analizar su adecuación, determinar sus puntos críticos y,
ocasionalmente, simular su comportamiento.
Los ADLs son bien conocidos en los estudios universitarios de arquitectura de software, pero muy
pocos arquitectos de industria parecen conocerlos y son menos aún quienes los utilizan como
instrumento en el diseño arquitectónico de sus proyectos.
Frameworks y Vistas
Existen unos organismos de estándares (ISO, CEN, IEEE, OMG) que han codificado diferentes
aspectos de la arquitectura de sofware, con el objetivo de homogeneizar la terminología, los
modelos y los procedimientos.
Los elementos que forman estos estándares son una serie de especificaciones y recomendaciones.,
Los marcos arquitectónicos, como las metodologías de modelado de los organismos, acostumbran
ordenar las diferentes perspectivas de una arquitectura en términos de vistas (views).
Una vista es un subconjunto resultante de practicar una selección o abstracción sobre una realidad,
desde un punto de vista determinado.
La estrategia de arquitectura de software utilizando vistas define, cuatro vistas principales,
ocasionalmente llamadas también arquitecturas: Negocios, Aplicación, Información y Tecnología.
La vista de aplicación es la que utiliza la arquitectura de software y está compuesta por los
siguientes elementos:
 Descripciones de servicios automatizados: dan soporte a los procesos de negocios.
 Descripciones de las interacciones e interdependencias (interfaces) de los sistemas
aplicativos de la organización.
 Planes para el desarrollo de nuevas aplicaciones y la revisión de las antiguas, basados en los
objetivos de la empresa y la evolución de las plataformas tecnológicas.
La división de los diferentes escenarios que supeditan toda la arquitectura de software es la siguiente:
 Arquitectura como etapa de ingeniería y diseño orientado a objetos.
Es un modelo estrechamente asociado al entorno de UML y Rational.
www.learning.es
La arquitectura se restringe a las fases iniciales y preliminares del proceso y concierne a los
niveles más elevados de abstracción, pero no está sistemáticamente ligada al requerimiento
que viene antes o a la composición del diseño que viene después.
Lo que sigue al momento arquitectónico es business as usual, y a cualquier configuración,
topología o morfología de las piezas del sistema se la llama arquitectura.
En este tipo, se reconoce el valor primordial de la abstracción y del ocultamiento de
información como concepto de encapsulación en clases y objetos.
Importa más la abundancia y el detalle de diagramas y técnicas disponibles que la 135
simplicidad de la visión de conjunto.
Cuando aquí se habla de estilos, se los confunde con patrones arquitectónicos o de diseño.
La definición de arquitectura que se promueve en esta corriente tiene que ver con aspectos
formales a la hora del desarrollo.
Esta arquitectura es isomorfa a la estructura de las piezas de código.
 Arquitectura estructural, basada en un modelo estático de estilos, ADLs y vistas.
Utiliza el más alto nivel de abstracción, y además no tiene por qué coincidir con la
configuración explícita de las aplicaciones.
No se suelen encontrar referencias a los lenguajes de programación o piezas de código, y en
general, nadie habla de clases o de objetos.
 Estructuralismo arquitectónico radical.
Utilizados dos tendencias, una que excluye la relevancia del modelado orientado a objetos
para la arquitectura de software y otra que procura definir nuevos metamodelos y
estereotipos de UML como correctivos de la situación.
 Arquitectura basada en patrones.
Este tipo de arquitectura está claramente diferenciada de la tendencia a diagramas de UML.
Utiliza modelos de proceso tácticos.
El diseño consiste en identificar y articular patrones preexistentes, que se definen en forma
parecida a los estilos de arquitectura.
 Arquitectura procesual.
Su función principal es establecer modelos de ciclo de vida y técnicas de requerimientos,
diseño, análisis, selección de alternativas, validación, comparación, estimación de calidad y
justificación económica específicas para la arquitectura de software.
 Arquitectura basada en escenarios.

Es modelo más novedoso.
Utiliza la unión de la arquitectura de software con los requerimientos y la funcionalidad del
sistema, ocasionalmente borroso en la arquitectura estructural clásica.
En este modelo suelen utilizarse diagramas de casos de uso UML como herramienta informal
u ocasional, dado que los casos de uso son uno de los escenarios posibles.
Los casos de uso no están orientados a objetos.
Para que una arquitectura tenga unos atributos de calidad debe tener las siguientes características:
La arquitectura de software debe cubrir una serie de requisitos mínimos para poder involucrar todo
un desarrollo de análisis:
 Los individuos y las interacciones por encima de los procesos y las herramientas
 El software que funciona por encima de la documentación exhaustiva
 La colaboración con el cliente por encima de la negociación contractual
www.learning.es
 La respuesta al cambio por encima del seguimiento de un plan
Una de las herramientas más importantes y utilizadas para los desarrollos es el propio UML, que
permite crear diagramas de objetos y su interacción entre ellos.
En el campo del software, la arquitectura nos identifica los elementos más importantes de un
sistema así como sus relaciones, es decir, nos da una visión global del sistema.
Generalmente, las metodologías de desarrollo indican principios para identificar y diseñar una
arquitectura, aunque por ahora la ayuda real que ofrecen es muy limitada al basarse en principios 136
muy genéricos.
Las arquitecturas software no responden únicamente a requisitos estructurales, sino que están
relacionadas con aspectos de rendimiento, usabilidad, reutilización, restricciones económicas y
tecnológicas, e incluso cuestiones estéticas.
Actualmente existen muchas metodologías de desarrollo de software, desde métodos muy “pesados”
y burocráticos, métodos ajustables al proyecto y a las condiciones de desarrollo, hasta métodos
“ligeros” que surgen como respuesta a los excesos formales de otros métodos.
Evidentemente, partiendo de los principios de tantas y diversas metodologías es muy difícil sacar
una visión unificada sobre el diseño arquitectónico.
Es difícil encontrar elementos comunes entre tantos modelos de arquitectura, aunque existen una
serie de elementos o patrones que definen todas las estructuras.
El primero es la existencia de una fase en la que se establece o diseña una arquitectura base y el
segundo la altísima dependencia que definen entre los casos de uso y la arquitectura, definiendo un
caso de uso como una interacción (secuencia de acciones) típica entre el usuario y el sistema.
Desde un punto de vista arquitectónico, no todos los casos de uso tienen la misma importancia,
destacando aquellos que nos ayudan a mitigar los riesgos más importantes y sobre todo aquellos
que representan la funcionalidad básica del sistema a construir.
Esta arquitectura base estará especificada por diagramas que muestren subsistemas, interfaces
entre los mismos, diagramas de componentes, clases, descripciones diversas, y por el conjunto de
casos de uso básicos.
Este conjunto de especificaciones nos permiten validar la arquitectura con los clientes y los
desarrolladores, y asegurarnos que es adecuada para implementar la funcionalidad básica deseada.
A partir de aquí, lo normal sería desarrollar de forma iterativa el sistema hasta tenerlo
funcionalmente completo.
Una visión alternativa sería identificar el tipo de sistema que queremos construir.
Todos sabemos que no hay dos aplicaciones iguales, pero que existen claros paralelismos entre las
aplicaciones construidas para resolver problemas similares.
El fijarnos en aplicaciones del mismo tipo tiene muchas ventajas ya que nos ayuda a entender las
necesidades del cliente y las soluciones ya encontradas por otros.
Utilizar una metodología tradicional de desarrollo y arquitectura de software permite una serie de
características:
 Centralizar los aspectos en parte del problema (el dominio del problema, sus requisitos y su
microestructura), obviando cuestiones como rendimiento, seguridad, protocolos de
comunicación, restricciones de hardware, software, y económicas, etc.
 Proporciona una visión estrecha, ya que frecuentemente el cliente no expone adecuadamente
todos sus requisitos porque no los conoce.
Imaginemos que estamos desarrollando un portal web.

La experiencia en dicho desarrollo dice que a partir de cierto número de páginas, es útil desarrollar
un sistema basado en plantillas Xslt (por ejemplo), por la disminución de costes de mantenimiento
que ello implica.
Esto es algo que ningún requisito funcional nos daría, y que probablemente tampoco surgiría de
forma natura' en los modelos de diseño.
A este tipo de soluciones (patrones de diseño) se llega por la experiencia en el desarrollo de
sistemas web y por el conocimiento de las tecnologías existentes en el mercado.
Gracias a esta experiencia, desde el inicio del desarrollo de una aplicación, podemos buscar
componentes que implementen estas tecnologías o ciertas funcionalidades, y por lo tanto integrar la
búsqueda de componentes y su uso dentro del proceso de desarrollo de software.
www.learning.es
Identificar el tipo de sistema a construir nos permite examinar la arquitectura de sistemas ya
construidos, comprender los requisitos a los que se enfrentan, y contrastarlos con nuestros clientes.
Si tenemos en cuenta que en cualquier tipo de sistema, existen necesidades similares, muchos de
los componentes que se usan en su desarrollo suelen ser los mismos (por ejemplo: Modelo Vista
Controlador, Bases de datos, , buscadores, carritos de la compra, gestores de contenidos, etc).
Las metodologías que gestionen de forma directa las cuestiones arquitectónicas y estructurales,
podrán producir no solo productos de mayor calidad, sino a un menor coste y en menos tiempo. 137
Esto se debe a que los riesgos arquitectónicos del proyecto son menores y están mucho mas
controlados, y que al poder integrar una visión orientada a componentes, las posibilidades de
reutilizar software ya desarrollado son mucho mayores, con las ventajas que ello implica.
Construir una arquitectura es una actividad donde desarrollar ideas nuevas basándose en la
experiencia acumulada en otros desarrollos estructurados, siendo casi siempre responsabilidad del
desarrollador crear un producto de calidad y, por tanto, conocer el tipo de sistema a construir.
Afortunadamente para esto último, los lenguajes de patrones nos pueden proporcionar una
inestimable ayuda.
Lenguajes de patrones
Los lenguajes de patrones se pueden definir de la siguiente forma: "La especificación de una serie
de elementos (patrones) y sus relaciones (patrones) de modo que nos permiten describir buenas
soluciones a los diferentes problemas que aparecen en un contexto específico".
El objetivo de los patrones de diseño es el de capturar buenas prácticas que nos permitan mejorar la
calidad del diseño de un sistema, determinando elementos que soporten roles útiles en dicho
contexto, encapsulando complejidad, y haciéndolo más flexible.
Por otro lado, con frecuencia se dice que la función define a la forma, es decir, que la estructura o la
arquitectura de cualquier sistema está muy relacionada con lo que dicho sistema tiene que hacer.
Esta es la razón por la que los sistemas con objetivos similares comparten también, una arquitectura
común, unos procesos bien definidos, y un conjunto de elementos similares (patrones de diseño).
Similar funcionalidad y servicio, similar estructura.
Cuando desarrollamos un sistema que se encuadra dentro de cierto tipo, es muy útil consultar
lenguajes de patrones que traten el dominio en el que estamos.
Un lenguaje de patrones nos sirve como referencia conceptual del dominio del problema, ya que
éstos parten como solución a un conjunto de casos de uso, e interacciones con actores específicos.
Además constituyen también un marco conceptual en el diseño de la arquitectura de nuestros
sistemas, ya que como la función define a la forma, sintetizan por lo general soluciones
arquitectónicas y estructurales bien probadas y muy útiles dentro del tipo de problemas que
modelan.
De alguna forma, los patrones nos permiten identificar y completar los casos de uso básicos
expuestos por el cliente, comprender la arquitectura del sistema a construir así como su
problemática, y buscar componentes ya desarrollados que cumplan con los requisitos del tipo de
sistema a construir, es decir nos permiten obtener, de una forma sencilla, la arquitectura base que
buscamos duran la fase de diseño arquitectónico.
Un lenguaje de patrones que modele un tipo de sistema debe de ser descrito incluyendo la siguiente
información:
 Características básicas que lo definen y diferencian. Por ejemplo, un sistema web se
caracteriza por clientes ultra ligeros, o uso de protocolos sin estado, o centralización del
software de ejecución en servidores de tal forma que la aplicación es compartida por todos
los usuarios.
 Definición de los actores principales que participan en dicho sistema así como sus casos de
uso básicos, descritos evidentemente de forma genérica.
 Especificación de los principales componentes funcionales del sistema así como las relaciones
entre ellos.
www.learning.es
 Arquitectura lógica y flujos de información, que estructuran los diferentes subsistemas, el
intercambio de información de los mismos, etc. Por ejemplo, arquitecturas reflexivas,
modelo-vista-controlador, etc.
 Arquitectura de componentes. Consiste en mapear los componentes funcionales en la
arquitectura lógica de la aplicación.
 Arquitectura física. Especificación del despliegue de los componentes.
138
Estos lenguajes deberían, además, tener una visión orientada a la construcción de software y a
constituirse como elementos integrables en el proceso de desarrollo de las aplicaciones.
Ver Video: Arquitectura de sofware, en la Unidad 9,

Actividades
www.learning.es

PDF M10 Java PDF

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

PDF M10 Java PDF

Cargado por

Copyright:

Formatos disponibles

Módulo 10

Introducción: ¿Que es una arquitectura?

Evolución de histórica de las arquitecturas de

c) Arquitectura Cliente-Servidor Mejorada:

 Clientes pesados, no estándar

e) Aplicaciones N-niveles (clientes livianos):

Al ampliar la escalabilidad y complejidad de los proyectos de software, se hizo necesaria una

Arquitectura de software en la actualidad

De este modo, las empresas terminan demandando que su infraestructura de Tecnología de la

Un ejemplo esquemátizado de esta arquitetura de aplicaciones empresariales y de sus componentes

La función del Arquitecto de Software

El arquitecto es un rol en un proyecto de desarrollo de software, el cual ha de asumir las siguientes

Más concretamente, el arquitecto debe

 Aceptación. Conseguir la aceptación de los participantes del proyecto sustentando sus

A la hora de manejar el grupo de trabajo, conviene recordar que:

Áreas de Enfoque Selección de tecnologías, Requerimientos funcionales

La arquitectura envuelve un conjunto de decisiones estratégicas de diseño, lineamientos, reglas y

En el proceso de definición de arquitectura se produce:

b) Patrones de patrones de diseño

El framework es un subsistema de software parcialmente construido, de propósito general para un

Definición de Arquitectura en RUP

El RUP está basado en seis principios:

Los entregables correspondientes a esta fase serían:

Modelo de Vista 4+1

Ver Video: Introducción de Conceptos Fundamentales de

Conviene profundizar ahora en algunos contenidos sucintamente expuesto a en la unidad anterior. El

Por su parte, el arquitecto ha de concentrarse en los requerimentos no funcionales y las

El resultado de este proceso será obtener un entregable al que denominado Documento de

a) Requerimientos de Negocio: Al igual que el Analista Funcional, el arquitecto debe identificar y

b) Requerimientos No Funcionales: Los Requerimientos No Funcionales (NFRs) son los niveles de

En el Documento de Arquitectura el listado de Requerimientos No funcionales puede ir en una tabla

Las Calidades sistémicas se descomponen en las siguientes familias:

a) Manifiestas u obvias para el usuario

b) Cualidades operacionales que están ligadas al sistema en ejecución

c) Cualidades Evolucionarias vinculadas a cómo se comporta el sistema cuando es

Extensibilidad (Extensibility). Posibilidad de agregar funcionalidad nueva. Supone, por tanto,

d) Cualidades de Desarrollo que afectan a la manera en la cual se está construyendo el

Opción 2: Se propone el uso de 2

Tiempos de respuesta esperados (Ejemplo)

Tipo Respu Respues Volume Accesos Latencia Latencia

Escritura ¿? ¿? 50k 825 Por Por

*Calculo de número de Los demás componentes de negocio se desarrollarán

Desarrollo guiado por las Cualidades Sistémicas

Ver Video: Las Cualidades Sistémicas , en la Unidad 2,

Esta función distingue a la arquitectura del diseño, de la programación y de la integración de las

Nivel de Abstracción Enfoque alto y extenso en Enfoque bajo y específico

¿Cuáles serían las principales preocupaciones de la arquitectura? Podríamos desglosarlas en cinco

Análisis de la heurística de desarrollo de la

La arquitectura también, como se ha señalado en otras unidades, se refiere a una representación

También usaremos la abstracción arquitectónica para definir límites:

¿Cuándo debemos usar transaciones? Debemos distinguir dos situaciones diferenciadas:

Finalmente, el diseño de transacciones en la programación multi-hilo, es no-determinística, por

Revisión de arquitectura basada en servicios

En el ambiente heterogéneo de los sistemas de información de una empresa, cada sector de la

La implementación de servicios es la clave para producir arquitecturas con buena seguridad,

Existen un buen número de razones para usar Arquitecturas Basadas en Servicios:

Con RUP hacemos uso de las siguientes clases de métricas:

Los documentos RUP que contienen los planes y compromisos son:

Riesgo Descripción Probabilidad Impacto Plan de

Planificando la Capacidad del sistema

Crecimiento de espacio en Disco Duro

Crecimiento de la base de datos

Diagrama de Capas y Filas