Mdulo 10

Desarrollando
Arquitecturas para
Aplicaciones
Empresariales Java

Profesional en
Plataforma

JAVA
Contenido
Introduccin y Objetivos ........................................................................................................ 5
Unidad 1. Introduccin a los Conceptos Fundamentales de Arquitectura ...................................... 6
Introduccin: Que es una arquitectura? ............................................................................................................... 6
Evolucin de histrica de las arquitecturas de software ........................................................................................ 7
3
La funcin del Arquitecto de Software ................................................................................................................. 11
Qu relacin hay entre Arquitectura y Diseo de aplicaciones? ........................................................................ 12
Recursos de arquitectura y diseo de aplicaciones: ............................................................................................. 13
Mtodos de desarrollo ......................................................................................................................................... 14
Definicin de Arquitectura en RUP ....................................................................................................................... 16
Unidad 2. Conociendo las Cualidades Sistemticas................................................................... 20
Cualidades Sistmicas........................................................................................................................................... 21
Restricciones y suposiciones ................................................................................................................................ 24
Desarrollo guiado por las Cualidades Sistmicas .................................................................................................. 24
Unidad 3. Heurstica de Desarrollo Arquitectnico y Directrices .................................................. 26
Anlisis de la heurstica de desarrollo de la arquitectura: .................................................................................... 27
Redes de comunicaciones .................................................................................................................................... 28
Uso de transacciones............................................................................................................................................ 30
Revisin 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 pgina 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
Tecnologas 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
Diseo Procedimental .......................................................................................................................................... 60
Ciclo de Vida de los Beans de Session .................................................................................................................. 61
Diseo Orientado a Objetos ................................................................................................................................. 62
4
Laboratorio: POJO con Hibernate ......................................................................................................................... 70
Unidad 7. Arquitectura de Integracin 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 criptogrfica ...................................................................................................................................... 105
Algoritmo criptogrfico ...................................................................................................................................... 106
Algoritmos de cifrado simtrico ......................................................................................................................... 106
Algoritmos de clave pblica o asimtricos ......................................................................................................... 107
Tipos de algoritmos de cifrado simtrico ........................................................................................................... 112
Tipos de algoritmos de cifrado asimtrico.......................................................................................................... 114
Certificados digitales .......................................................................................................................................... 115
Arquitectura de seguridad por componentes .................................................................................................... 117
Implementacin de la seguridad servidor y EJB ................................................................................................. 118
Seguridad de aplicaciones web en servlets y jsp ................................................................................................ 121
Laboratorio: Uso de Criptografa ........................................................................................................................ 124
Unidad 9. Arquitectura de software ....................................................................................... 131
Modelos de arquitectura .................................................................................................................................... 131
Lenguajes de descripcin arquitectnica ........................................................................................................... 134
Frameworks y Vistas ........................................................................................................................................... 134
Lenguajes de patrones ....................................................................................................................................... 137

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Introduccin y Objetivos

Introduccin y Objetivos
Este mdulo proporcionar los conocimientos suficientes al estudiante, los cuales permitirn que
pueda utilizar la plataforma Java EE(TM) en la creacin de aplicaciones corporativas adaptables a
cambios y con posibilidades de crecimiento.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Unidad 1. Introduccin a los Conceptos
Fundamentales de Arquitectura

Objetivo
6
Conocer los conceptos ms bsicos involucrados en el diseo y desarrollo de arquitecturas para
software as como su evolucin y aplicacin en el lenguaje Java.

Introduccin: 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 ms alto de un sistema lo que encontramos
es su ambiente y en este sentido la arquitectura se refiere a la representacin abstracta de los
componentes de un sistema y su comportamiento. As, constituira una organizacin fundamental de
un sistema descrita a travs de:
Sus componentes.
Relacin entre ellos y con el ambiente.
Principios que guan su diseo y evolucin.

Otra manera de definir la arquitectura del software podra 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 definicin es que la arquitectura de software debe abstraer alguna informacin
del sistema y an proveer suficiente informacin para ser la base del anlisis, toma de decisiones y
lograr la reduccin de riesgos. Ahora bien, una arquitectura no contiene detalles de implementacin.
Se corresponde con la estructura de los componentes ms significativos de un sistema interactuando
a travs de interfaces con otros componentes conformados por componentes sucesivamente
pequeos e interfaces.
A la hora de plasmar en la prctica una arquitectura, debemos poner en marcha una secuencia de
actividades que conllevan la produccin de diferentes artefactos arquitectnicos. En concreto dos
fundamentales:
Descripcin de arquitectura
Prototipo arquitectnico

Por qu es importante definir una arquitectura? Bsicamente, 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
ningn segundo de su tiempo a reflexionar sobre la arquitectura de su proyecto, dicha arquitectura
estar all.

Por otro lado, otra razn que justifica la necesidad de definir una arquitectura es que los dos
factores primarios en la ingeniera de software que han incrementado la importancia de la
arquitectura son la escala de nuestros programas y su distribucin final. Ambos factores van ligados

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
a la complejidad del proyecto y a los riesgos del mismo. Por consiguiente, al aumentar la
escalabilidad y la distribucin de nuestros productos, automticamente estamos incrementando su
complejidad y los riesgos que debe afrontar.

Evolucin de histrica de las arquitecturas de

software
Para comprender bien el concepto de arquitectura lo mejor es repasar su evolucin histrica. De
este modo, podemos distinguir diferentes manera de realizar aplicaciones informticas desde los
primeros diseos arquitectnicos hasta nuestros das.
a) Aplicaciones Monolticas:

Este tipo de aplicaciones corresponderan a los desarrollos ms primitivos y estaran caracterizadas

por:
Interfaces grficas de usuario (GUI).
Servicios de presentacin, negocios y persistencia en la misma mquina.
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 caractersticas
ms importantes ligadas a este modelo seran las siguientes:
Clientes pesados, no estndar
Conexiones dedicadas a BD
Protocolos pesados
Ejecucin remota de SQLs
Alta administracin
Bajo rendimiento
Alto trfico de red
Baja accesibilidad

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 8

c) Arquitectura Cliente-Servidor Mejorada:

Supone, como el propio nombre indica, una evolucin mejorada de la arquitectura anterior. Los
rasgos fundamentales que la definen son:

Clientes pesados, no estndar

Conexiones dedicadas a la BD
Lgica de negocios en BD
Mejora en rendimiento
Alta administracin
Baja escalabilidad
Baja flexibilidad
Baja portabilidad

d) Aplicaciones 3 niveles:

Las aplicaciones en tres niveles supusieron uno de los avances con ms xito dentro del desarrollo
de software, en gran medida ligado al mayor empleo de los lenguajes orientados a objetos. Las
caractersticas de esta arquitectura seran:
Reutilizacin de lgica de negocio para diferentes clientes o sistemas.
Mejora la escalabilidad.
Mejora la flexibilidad.
Independencia de la base de datos.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 9

e) Aplicaciones N-niveles (clientes livianos):

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

arquitectura ms 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 ms concretos son:
Bajo costo de administracin 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 implementacin 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 Tecnologa de la

Informacin (IT) se pueda adaptar al cambio, sea flexible y tenga libertad de escoger nuevas
tecnologas o productos en una relacin costo/beneficio absolutamente optima.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 10

Un aspecto muy extendido de esta situacin son los denominados procesos fragmentatos. Es decir,
aplicaciones publicadas en diferentes departamentos y unidades de negocios.

Entonces surge el problema. Cmo podemos integrar dichos procesos y datos de una empresa con
una relacin costo/beneficio adecuada? Y lo que es ms importante Cmo 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 ms extendida e
implantada de disear aplicaciones empresariales.

Una visin idealizada de esta Arquitectura Orientada a Servicios (SOA) englobara los siguientes
requisitos arquitectnicos a afrontar e integrar:
Heterogeneidad
Escalabilidad
Disponibilidad
Distribucin
Manejabilidad de Procesos
Administracin y monitoreo de procesos, servicios e infraestructura

Un ejemplo esquemtizado de esta arquitetura de aplicaciones empresariales y de sus componentes

habituales lo podemos ver en la siguiente ilustracin. As vamos precibiendo la realidad informtica
compleja y sofisticada a la que debe dar respuesta la arquitectura.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 11

La funcin del Arquitecto de Software

Adems de las nociones tericas en s que permiten definir una arquitectura determinada, tambin
estn 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 descripcin de arquitectura
Modelos y prototipos de arquitectura.

Ms 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 tecnologas
disponibles en el Mercado y proceder a su evaluacin. Con tal experiencia, el arquitecto obtendr
una serie de beneficios a la hora de aplicarla a sus proyectos:

Aceptacin. Conseguir la aceptacin de los participantes del proyecto sustentando sus

recomendaciones y decisiones con un buen nivel de fundamentacin.
Uso adecuado. Asegurar el uso apropiado de las tecnologas por los miembros del equipo.

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

Un Arquitecto es un facilitador y lder.
No toma decisiones unilaterales ni irracionales.
Evita riesgos en los proyectos y agrega valor al mismo.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Qu relacin hay entre Arquitectura y Diseo de
aplicaciones?
Existe alguna diferencia entre arquitectura y diseo de software? En principio dentro del lenguaje
profesial parece ambos, dos conceptos muy semejantes e incluso intercambiables dentro del
lenguaje comn y corriente de un equipo de trabajo. Sin embargo, la arquitectura y el diseo 12
difieren en tres reas:

Arquitectura Diseo
Nivel de Abstraccin Alto nivel Bajo nivel. Enfoque especfico en
detalles
Entregables Planear subsistemas, interfaces con Diseo detallado componentes,
sistemas externos, servicios horizontales, Especificaciones de codificacin
frameworks, componentes reutilizables,
prototipo arquitectnico

reas de Enfoque Seleccin de tecnologas, Requerimientos funcionales

Requerimientos no funcionales (QoS),
Manejo de riesgos

La arquitectura envuelve un conjunto de decisiones estratgicas de diseo, lineamientos, reglas y

patrones que restringen el diseo y la implementacin de un software.

Las decisiones de arquitectura son las decisiones ms fundamentales, por lo tanto, cambiarlas
ocasiona efectos significativos.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Recursos de arquitectura y diseo de aplicaciones:
En la puesta en marcha de una arquitectura y diseo de aplicaciones debemos tener presente al
menos tres recursos tiles:
La generacin 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 definicin de arquitectura se produce:

Una arquitectura Inicial.
Una arquitectura de Referencia.
Un Documento de Descripcin de arquitectura (SAD):
Subsistemas
Componentes
Arquitectura Runtime.
Guas para el proyecto y estndares de Diseo.

Adicionalmente se producen:
Matriz Tecnolgica de Layers y Tiers
Plantilla de Arquitectura

b) Patrones de patrones de diseo

Los patrones de diseo son una herramienta muy relevante para un arquitecto de software. Un
Patrn describe una solucin probada a un problema recurrente de diseo, el cual ocurre en un
contexto determinado. Existen patrones de arquitectura, de anlisis y de diseo.
De hecho, la definicin 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 diseo es diferente a disear patrones. El
arquitecto se debe familiarizar con la mayor cantidad de patrones posibles:
Dedicar tiempo a los catlogos de patrones.
Conocer los patrones que estn 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.
Diseos que han funcionado correctamente en el pasado.
Frameworks conceptuales y tecnolgicos.
Componentes y libreras.

c) Framework

El framework es un subsistema de software parcialmente construido, de propsito general para un

tipo especfico 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 bsicos de
construccin y adaptadores.
Conviene subrayar que un framework, habitualmente, se construye a partir de patrones de diseo.
As, el framework impone patrones de diseo para su uso.
Ejemplos tpicos de Frameworks seran:

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
1. Tecnolgicos:
a. Struts y Java Server Faces (JSF) para Interfaces Web.
b. Log4J para auditora tcnica o negocios en app.
c. Toplink, Hybernate, ROME para mapeos objeto-relacionales.
d. Enterprise Java Beans para construccin de servicios de negocios.
e. Framework de patrones de diseo para J2EE de Sun Microsystems.
f. Grinder como framework para testing de performance. 14
2. Conceptuales:
a. El Cubo para definicin de arquitecturas.
b. eTom para empresas de telecomunicaciones.
c. RUP como metodologa para definicin de procesos de desarrollo.

Mtodos de desarrollo
Cules son los principios fundamentales en los mtodos de desarrollo de software modernos?
Podemos enumerarlos rpidamente del siguiente modo:
Desarrollo iterativo e incremental.
Conducido por las calidades sistmicas.
Centrado en la arquitectura.
Dirigido por los casos de uso.
Basada en Modelos.
Mejores prcticas de diseo.

Los modelos son mecanismos primarios de comunicacin 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:
Comunicacin
Resolver Problemas
Pruebas de Concepto

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 15

Uno de los aspectos ms 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 produccin se incrementan indefinidamente. En el modelo interactivo
los costes son ms fciles de preveer porque finalizan con el lanzamiento de cada nueva versin 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 grficas:

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 definicin de
arquitectura del RUP

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Desarrollo mediante SunTones AM, el cual agrega dos caractersticas importantes a RUP:
o Un enfoque en las calidades sistmicas
o El uso de patrones basados en el razonamiento

La combinacin de ambos modelos configura un Framework con forma de Cubo que tiene los
siguientes elementos:
16

Definicin 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 metodologas
estndar ms utilizadas para el anlisis, implementacin y documentacin de sistemas orientados a
objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologas adaptables al contexto y necesidades de cada organizacin.

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 caractersticas propias del proyecto u organizacin. El tamao del
mismo, as como su tipo o las regulaciones que lo condicionen, influirn en su diseo especfico.
Tambin 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 podrn 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 iteracin se analiza la opinin de los inversores, la estabilidad y calidad del
producto, y se refina la direccin del proyecto as como tambin los riesgos involucrados

Colaboracin entre equipos: El desarrollo de software no lo hace una nica persona sino mltiples
equipos. Debe haber una comunicacin fluida para coordinar requisitos, desarrollo, evaluaciones,
planes, resultados, etc.

Elevar el nivel de abstraccin: Este principio dominante motiva el uso de conceptos reutilizables
tales como patrn 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
codificacin 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 reutilizacin del
cdigo. Un alto nivel de abstraccin tambin permite discusiones sobre diversos niveles y soluciones
arquitectnicas. stas se pueden acompaar 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 iteracin, sino en
todos los aspectos de la produccin. El aseguramiento de la calidad forma parte del proceso de
desarrollo y no de un grupo independiente.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 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 Visin
Arquitectura Inicial
Plan de la siguiente fase

Fase de Elaboracin
Durante esta fase se crean:

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Arquitectura lnea base.
80% de los requerimientos del sistema.
Plan de iteraciones para la fase de construccin.

Los entregables correspondientes a esta fase seran:

Requerimientos del Sistema.
Documento de Definicin de Arquitectura.
18
Prototipo evolutivo de arquitectura.
Guas y Estndares.
Plan de Iteraciones.

La metodologa RUP es ms apropiada para proyectos grandes, dado que requiere un equipo de
trabajo capaz de administrar un proceso complejo en varias etapas. En proyectos pequeos, es
posible que no se puedan cubrir los costos de dedicacin del equipo de profesionales necesarios.

Modelo de Vista 4+1

El Framework para Descripcin de Arquitecturas del Rational Unified Process (RUP), basado en vistas
lgicas y fsicas UML y una vista funcional de casos de uso.

SunTone AM
SunTone AM es una metodologa de desarrollo de software anloga al Unified Process (UP), con un
fuerte nfasis en las calidades sistmicas y patrones de diseo.
Tiene un framework conceptual, el cubo, el cual provee una vista tridimensional de:
Capas lgicos
Layers o niveles tecnolgicos
Calidades sistmicas

Con el cubo se puede definir la matriz tecnolgica de Layers y Tiers, la cual documenta las
decisiones tecnolgicas para soportar la arquitectura de un sistema.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Profundizaresmo en algunos elementos de este cubo en las unidades siguientes.

19

Ver Video: Introduccin de Conceptos Fundamentales de

arquitectura , en la Unidad 1, en el Mdulo 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Unidad 2. Conociendo las Cualidades
Sistemticas
Objetivo
20
Profundizar en los conceptos ms bsicos involucrados en el diseo y desarrollo de arquitecturas
para software bajo el lenguaje Java.

Introduccin

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 intencin 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 Anlisis, Diseo y
Construccin 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 informacin y formula una o varias propuestas de solucin tomando en cuenta todo lo
anterior. Dentro de la solucin 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 solucin 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 metodologa y de

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
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 solucin de Arquitectura.

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

conocer cules son los objetivos de negocio que motivan el desarrollo del sistema. Esto permitir
proponer la solucin ms adecuada en funcin de estos objetivos y evitar cualquier desviacin. 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 / Descripcin
NFR01
Descripcin del Requerimiento No Funcional
NFR 02
Estas caractersticas estn concebidas para especificar con detalle cmo 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 Metodologa de Arquitectura Sun Tone Methodology:
Cualidades Sistmicas o Quality of Service (QoS)

Cualidades Sistmicas
Las cualidades o calidades sistmicas estn 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 diseo.
Son no-funcionales pero observables.
No se pueden satisfacer completamente por un componente.

Las Calidades sistmicas se descomponen en las siguientes familias:

Manifiestas (Manifiest).
Operacionales (Operational).
Desarrollo (Developmental).
Evolutivas (Evolutionary).

a) Manifiestas u obvias para el usuario

Desempeo (Performance). La rapidez y eficacia con la cual el sistema cumple la peticin. 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Disponibilidad (Availability). Cantidad de tiempo en lnea en el que el sistema puede procesar
solicitudes. Este es asunto ms 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 estn ligadas al sistema en ejecucin

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). Prevencin de uso no autorizado del sistema y su informacin.
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 cmo 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
operacin ante un incremento en el nmero de usuarios o peticiones.
Mantenibilidad (Maintainability). La facilidad con la que la aplicacin ser susceptible de ser
corregida o reparada. As, como determinar el esfuerzo ahorrado cuando se hacen dichos cambios
de configuracin.

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

determinar el esfuerzo ahorrado para aadir nuevas funcionalidades.
Flexibilidad (Flexibility). Costo de implementar una correccin 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 estimacin, planeacin y construccin.
Planeabilidad (Serviceability). Confianza en que el sistema puede ser planeado en costo y esfuerzo.
Algunas cualidades sistmicas son excluyentes entre s, por ejemplo Desempeo frente a Seguridad:
el cumplimiento de una minimiza a otra por lo que resulta necesaria una priorizacin en las

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
cualidades sistmicas para poder decidir de entre varias opciones de solucin ms adecuada y que
no comprometa el cumplimiento de una o varias cualidades.
Las cualidades sistmicas deben quedar identificadas y listarse en nuestro proyecto como el
siguiente:

23
Calidad del Prioridad Descripcin del Propuesta para cubrir el
servicio (QoS) Requerimiento requerimiento
Disponibilidad Alta El sistema no debe quedar Opcin 1: Se propone escalar el
fuera de lnea 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

Opcin 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 situacin de desarrollo de una aplicacin fictcea se
complementara con tablas de pruebas similares a la que vemos a continuacin y cuyo vnculo a la
tabla anterior debe quedar registrado tambin a modo de llamada entre tablas. En nuestro caso se
emplea la expresin Ver tabla anexa.

Tiempos de respuesta esperados (Ejemplo)

Tipo Respu Respues Volume Accesos Latencia Latencia

operacin 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 tambin debern contemplarse y documentarse mediante la
enumeracin y resolucin de diferentes caractersticas operacionales. Veamos otra tabla de registro
que expresa esta labor:

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Caractersticas operacionales
Caracterstica Operaciones del Descripcin
Sistema Detectadas
Transaccional *Asignacin del folio Se desarrollarn los componentes de negocio con EJBs

*Calculo de nmero de Los dems componentes de negocio se desarrollarn

referencia con POJOs para poder llegar a los tiempos de respuesta
24
solicitados.
Concurrencia * Registro de un
solicitante

* Consulta de reportes

* Configuracin de
procesos de registro

Restricciones y suposiciones
Todo proyecto tiene restricciones, las ms comunes son tiempo, recursos, presupuesto y tecnologa
a utilizar. El arquitecto debe proponer alternativas de solucin que se muevan dentro de estas
restricciones. En algunos casos ser necesario sacrificar una buena opcin 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 comn que alguien, sin el
debido conocimiento de cmo 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 informacin necesaria para poder plantar una
propuesta, incluso el cliente puede no tenerla. Esta incertidumbre har que dudemos en proponer
una solucin porque no sabemos qu implicaciones puede tener esa ausencia de informacin. 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 solucin ser vlida slo 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 requerirn 100 horas de
construccin de reportes.

Desarrollo guiado por las Cualidades Sistmicas

Hemos visto que las calidades sistmicas son requerimientos no funcionales, los cuales definen la
calidad de servicio que un sistema expone. Dichos requerimentos no funcionales seran, por
ejemplo:
Rendimiento
Confiabilidad
Escalabilidad
Seguridad
Pues bien, esas calidades sistmicas 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
orientado al desarrollo basado en patrones y para la entrega de calidades sistmicas predecibles.
Todo ello distribuido en capas. En la ilustracin siguiente podemos ver un ejemplo abstracto de
arquitectura que tiene en cuenta los patrones y las calidades sistmicas distribuidas en diferentes
capas: presentacin, negocio y base de datos.

25

Si entramos ms concretamente en la aplicacin de dichos conceptos abstractos sobre los elementos

o productos tecnolgicos que nos ofrece Java, veremos que stos se pueden aplicar sobre una
arquitectura de software tpica 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 tecnologa y lenguaje. Es en ese
empleo concreto donde, de manera inherente, se solventan y se consiguen un mayor grado de
optimizacin buena parte de las calidades sistmicas del modelo de desarrollo que venimos
repasando en estas pginas.

Ver Video: Las Cualidades Sistmicas , en la Unidad 2,

en el Mdulo 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Unidad 3. Heurstica de Desarrollo
Arquitectnico y Directrices
Objetivo
26
Conocer los factores y elementos que permiten introducir innovaciones de manera rpida en
el diseo y desarrollo de arquitecturas para software realizado bajo lenguaje Java.

Introduccin
En sistemas altamente distribuidos, la capacidad de tomar las decisiones correctas acerca de dnde
los componentes estn localizados y como ellos se comunican resulta mucho ms crtico y dificultoso
que en los sistemas de pequeo tamao y prestaciones limitadas.
La importancia de esta clase de decisiones crea la necesidad de la arquitectura. Entonces, la funcin
crtica de la arquitectura es llevar a cabo una planificacin de alto nivel, de localizacin y de
comunicacin entre los diferentes componentes del software que se est desarrollando.

Esta funcin distingue a la arquitectura del diseo, de la programacin y de la integracin de las

otras reas del desarrollo del software.
La planificiacin de alto nivel nunca debe perder de vista las siguientes metas:
El sistema resultar robusto si ocurren slo 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 parmetros
de diseo original

Conviene insister entonces en las diferencias entre la arquitectura y el diseo del software:
Arquitectura Diseo

Nivel de Abstraccin Enfoque alto y extenso en Enfoque bajo y especfico

algunos detalles en muchos detalles
Resultados Planes de sistemas y Diseo de componentes,
subsistemas, prototipos especificaciones del cdigo
arquitectnicos
rea de enfoque Requerimientos no funcionales, Requerimientos
manejo de riesgo funcionales

Cules seran las principales preocupaciones de la arquitectura? Podramos desglosarlas en cinco

puntos fundamentales:

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Usar documentos arquitectnicos para crear el modelo del sistema que se ocupe de la calidad del
servicio.
Documento de Visin: oportunidades de negocio.
Especificacin de requerimientos: funcionales y no funcionales.
Identificacin de riesgos y plan de mitigacin
27
Modelo de dominio para la aplicacin: estructura y relaciones.
Descripcin del contexto: cmo y dnde el software y el servicio deben estar localizado.
Plan del proyecto: Definir los hitos que caracterizarn cada una de las fases de desarrollo del
proyecto.
Lista de supuestos: crecimiento de usuarios y transacciones a implementar.
Evaluar apropiadamente el uso de tecnologa J2EE y asegurarse de la aprobacin por parte
de los gestores del proyecto:
Los gestores del proyecto pueden tener ideas preconcebidas sobre qu tecnologa debe ser
usada en el proyecto. Por ello, hay que justificar adecuadamente la decisin tecnolgica
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 desempeo y
fiabilidad.
Anlizar los costos
Usar patrones adecuados:
Revisar catlogos de patrones
Desarrollar prototipos:
Un prototipo arquitectnico describe el sistema y permite experimentaciones mentales para
determinar si el plan est resultando satisfactorio o no.

Anlisis de la heurstica de desarrollo de la

arquitectura:
Se denomina heurstica 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 simultneamente 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
fcilmente 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Red de comunicaciones y diseo: La red es la parte ms lenta de un sistema de computacin
distribuido. Por lo tanto, se ha de tener muy en cuenta cmo 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
aplicacin, para que no se proteja completamente los datos. Pero se incluye cdigo que 28
repare el dao en caso de producirse
Manejo de costos: Si un proyecto excede su presupuesto, difcilmente podr continuar. Una
tcnica comn para reducir gastos es usar patrones y heurstica. El trasfondo de esta forma
de operar es razonar pensando en que la ltima vez que un problema se present, la solucin
aplicada funcion bien, as que se repetir el mismo procedimiento de la otra ocasin.

La arquitectura tambin, como se ha sealado en otras unidades, se refiere a una representacin

abstracta de los componentes y el ambiente del sistema. Esto significa que la representacin del
sistema no debe contener detalles de la implementacin 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 diseo de los componentes orientados a objetos. As que debemos
aplicar los principios usuales de la orientacin 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 intil todo el sistema.

Tambin usaremos la abstraccin arquitectnica para definir lmites:

La abstraccin permite centrarnos en los componentes grandes antes que discutir los detalles
ms minsculos.
La idea es tener una abstraccin que tenga interfaces pequeas, simples y claras y sus
respectivas dependencias
Los cuadros y esquemas debern mostrar los elementos claves de todo el escenario.

Dentro de dicho mbito de abstraccin se proceder tambin a establecer dichos lmites, pero, sobre
todo, subrayando cul ser el rea de superficie, sus fricciones internas y puntos de fragilidad. El
rea de superficie es cada atributo de las interfaces donde los mdulos se comunican entre s. Los
cambios a los componentes de reas de superficie grande, crea fricciones y en los sistemas ms
frgiles, la friccin puede propagarse de componente a componente a travs de todo el sistema.
Todas estas circunstancias deben ser contempladas durante la abstraccin arquitectnica del
proyecto.

Redes de comunicaciones
El desempeo o papel de la red de comunicaciones del sistema es una de las preocupaciones
principal en la arquitectura y diseo de aplicaciones informticas. Tres factores que determinan el
desempeo 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 comunicacin en la
red.
Frecuencia de solicitud: Uso de la capacidad del canal.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 29

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Surgen entonces dudas que hay que afrontar durante la definicin arquitectnica del proyecto. Por
ejemplo, qu es mejor para el sistema enviar muchas solicitudes de datos pequeas o una solicitud
ms 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 envo durante un tiempo significativo. El
proceso puede empezar solo con una parte de los datos. Luego, minimizar la frecuencia de
solicitudes, realizar un cuidadoso diseo de interfaz de Usuario que mejore la progresiva captacin
de los datos para no saturar el sistema con una sola llamada y, finalmente, hacer un diseo tambin 30
cuidadoso de la API remota para no hacer todo en una sola llamada.

Uso de transacciones
Una transaccin 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.

Cundo 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 crdito: comprobar el stock de productos y actualizarlo, chequear que
haya crdito, hacer el dbito 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 desempeo 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 sesin representa un proceso o una accin de negocio.

Finalmente, el diseo de transacciones en la programacin multi-hilo, es no-determinstica, por

tanto, se pueden presentar problemas muy difciles de resolver como son los bloqueos deadlock.

Revisin de arquitectura basada en servicios

La Arquitectura Orientada a Servicio (SOA) no es una forma nueva de crear soluciones a problemas
del dominio, sino ms bien un paradigma de organizacin que permite obtener mayor valor de las
capacidades, tanto posedas como controladas por otros. SOA no provee elementos del dominio de
una solucin que no exista sin SOA. El objetivo en SOA es hacer que cada subsistema de una
empresa presente sus capacidades a travs de servicios adecuados que permitan usar las
capacidades de una manera homognea. Esto evita crear interfaces para cada par de sistemas que
requieran comunicacin. La filosofa detrs 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
quin las va a usar. Este modelo de servicio permite crear funciones que sean utilizables por
distintos clientes, los cuales simplemente deben conocer la descripcin del servicio para poder
utilizarlo.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 31

En el ambiente heterogneo de los sistemas de informacin de una empresa, cada sector de la

misma resuelve sus problemas mediante sistemas adecuados. Puede haber sistemas para gestin
contable, ERP, CRM, informacin interna (intranet), transacciones, bases de datos, etc. Cada uno es
pensado como una identidad independiente, con su propio entorno (hardware, sistema operativo,
lenguaje de programacin, entorno de ejecucin); muchas veces existe una funcionalidad
redundante entre los distintos sistemas. En muchos casos, se tienen sistemas antiguos o heredados
con dcadas de desarrollo acumuladas, de los cuales se depende y no son factibles de reemplazar,
ya sea por dependencia del negocio o riesgos de implementacin. Para permitir la interaccin 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 interaccin (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 integracin. Es justamente en la integracin de distintos
sistemas donde SOA entra en juego.

La implementacin de servicios es la clave para producir arquitecturas con buena seguridad,

disponibilidad, y escalabilidad.
Las caractersticas bsicas de SOA son:
La arquitectura basada en servicios esta compuesta de un nmero alto de servicios.
Cada servicio provee acceso a los componentes de la aplicacin.
Los servicios actan como puntos de venta en el sentido que ellos proveen la conexin con el
resto de la aplicacin, lo cual mejora la extensibilidad del sistema.

Existen un buen nmero 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 frgiles.
Responden fcil a los cambios del negocio.
Se puede dividir el sistema por capas o por funciones especiales.

En cuanto a los tipos de servicios que estn involucrados en SOA podemos hablar de:
Servicios Verticales:
Basados en el contenido del sistema

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Estos servicios reflejan el modelo del negocio y son especficos 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 autenticacin

Riesgos
El manejo de riesgos es un tema importante en la administracin de proyectos y de igual forma para
la Actividad de Arquitectura. Uno de los objetivos de la arquitectura es precisamente disminuir los
riesgos tecnolgicos. 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 mitigacin 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 estn
sincronizadas y sean consistentes. Esto es asegurado a travs de evaluaciones peridicas durante el
ciclo de vida del proyecto, y es documentado en el Reporte o Informe de Evaluacin de Status. Este
reporte es utilizado para hacer un seguimiento de la informacin acerca de los recursos disponibles
(humano y financiero), de los mayores riesgos, del progreso tcnico medido a travs de mtricas y
de los resultados de hitos principales.

Con RUP hacemos uso de las siguientes clases de mtricas:

Progreso: lneas de cdigo, nmero de clases, puntos de funcin por iteracin, rehacer.
Estabilidad: tipo de rehacer, volatilidad de requerimientos o implementacin.
Adaptabilidad: costo de rehacer.
Modularidad: extensin 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 Medicin
Lista de Riesgos
Plan del Proyecto
Plan(es) de Iteracin
Evaluacin(es) de Iteracin, y
Evaluacin(es) de Status

La Lista de Riesgos es un artefacto de RUP que nos provee una visin de todos los riesgos conocidos
en el proyecto, y sirve como entrada para la planificacin y evaluacin del proyecto. Cada riesgo es
descrito en funcin de su impacto, y un plan de contingencia ser desarrollado para mitigar el riesgo
en cuestin.
Dependiendo del sistema o modelo de desarrollo empleado, el ndice de riesgos al que sometemos a
nuestro proyecto vara significativamente. Por ejemplo, hay gran diferencia entre optar por un
desarrollo en cascada que por uno iterativo como ilustra la siguiente grfica:

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 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 ms importante
de riesgo en los proyectos:
Reglas de negocio de alta complejidad.
Calidades sistmicas
Seguridad
Rendimiento
Escalabilidad
Disponibilidad
Extensibilidad
La Lista de Riesgos ser desarrollada junto con los Casos de Negocio, los cuales formarn la base
para la decisin de continuar o no con el proyecto. La Lista de Riesgos es mantenida a travs de
todo el ciclo de vida del proyecto. Veamos un ejemplo fictceo de este tipo de Lista de Riesgos,
contemplando en cada uno de dichos riesgos su descripcin, probabilidad de que se produzca el
fallo, su impacto cuando ocurra y la respuesta prevista para mitigar su presencia:

Riesgo Descripcin Probabilidad Impacto Plan de

mitigacin
Ejemplo: El ambiente de desarrollo es ALTA / MEDIA ALTO / * Desarrollar
Windows y el de Produccin es / BAJA MEDIO / en maquinas
Diferente UNIX puede haber problemas BAJO virtuales
comportamiento de ambientacin * Realizar
entre el deploys y
ambiente de revisiones
desarrollo y de peridicas del
produccin sistema en el
ambiente AIX

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Ejemplo: La especificacin dice que el BAJA ALTO RESUELTO
servidor de aplicaciones que
El cliente adquirir el cliente cumple con Se realizaron
propone el uso le especificacin XXX y el pruebas de
de un framework necesita de esa operaciones
framework web especificacin 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
versin y
sistema
operativo del
servidor de
aplicaciones.
Ejemplo: Se est solicitando el tener MEDIO ALTO Se deben
tiempos de respuesta de hacer
Tiempos de mximo 5 segundos para pruebas de
respuesta arriba operaciones de consulta en desempeo
del valor horario pico Es un criterio en el servidor
requerido de de pruebas
Dada la configuracin de aceptacin usando los
topologa red donde se tiene para la mismos
liberacin elementos de
hardware e
identificar
posibles
cuellos de
botella fuera
de la
aplicacin

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 definicin arquitectnica del proyecto es la medicin
del crecimiento de espacio en disco por causa de los elementos propios de la aplicacin, por la
informacin empleada o generada, tales como archivos o datos de la base de datos o por el nmero
de peticiones de clientes considerando las cifras iniciales y las venideras.

Esta recoleccin 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
continuacin:

Numero de Accesos

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Operaciones Accesos Accesos Accesos Accesos
ms concurrentes concurrentes concurrentes concurrentes
demandantes Inciales, Horario Futuros, Horario
Pico Inciales, 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
Configuracin - - 330 55
de catalogos
A 1 ao A 1 ao

Crecimiento de espacio en Disco Duro

Descripcin del Tipo de Cantidad Tamao al Porcentaje Periodicidad
archivo Archivo inicial (6 final del ao semestral
meses) MB (MB)
EARs, Wars de Aplicacin
la aplicacin
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 informacin anterior se realizar una propuesta de solucin, indicando el tipo
de sistema a desarrollar:
Cliente / Servidor
Multicapa
Multicapa web

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 36

Diagrama de Capas y Filas

Este diagrama es un artefacto de la metodologa Sun Tone Methodology que muestra la tecnologa a
utilizar en cada una de las capas del sistema y por cada capa define niveles de productos que
participan en la solucin. Cada una de las tecnologas elegidas da solucin a los requerimientos
detectados durante la fase de Anlisis. Podemos ver a continuacin un diagrama de ejemplo.
Algunas de las celdas pueden haber sido dadas de inicio por las restricciones tecnolgicas del cliente
y las otras se llenan con la propuesta tecnolgica del Arquitecto:

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 37

Capa de Cliente: Es la capa donde se ejecuta una aplicacin de consola, dispositivo mvil, pc
desktop o con navegador web.
Capa de Presentacin: Aqu residen los componentes dinmicos de vista y control que generan
una salida HTML, XML y los Reportes que se envan al cliente, por ejemplo JSP, Servlets.
Capa de Negocio: Aqu residen los procesos de negocio, workflow, timers.
Capa de Integracin: Aqu residen los componentes que permiten la comunicacin 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 informacin 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 intervendrn
en la solucin.

Diagrama de Despliegue

El Diagrama de Despliegue inicial nos ayuda a saber con qu otros sistemas interactuarn y
convivir el nuestro dentro.

Prototipo
Provee una demostracin o implementacin de principio a fin de los componentes tecnolgicos
primarios, demuestra la viabilidad de la solucin y sirve como gua 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Usabilidad
La usabilidad toma en cuenta el tipo de personas que sern usuarios del sistema para
proporcionarles una interfaz de usuario que permita hacer productivo su trabajo y por ninguna
circunstancia dae su informacin. En este sentido es necesario al inicio del proyecto hacer pruebas
de usabilidad ya sea con un demo o una presentacin que muestre la forma en la que se
interactuar con el sistema.
Principios de Diseo a seguir:
Visibilidad: Claridad en la informacin a presentar. 38

Retroalimentacin: Enviar informacin en respuesta a una accin 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 lgica y con sentido.
Consistencia: Uniformidad y la navegacin hacen fcil el uso
Tolerancia: La aplicacin debe tolerar los errores de usuario, uso de confirmaciones y
mensajes de error.

El realizar esta exploracin de los elementos de interfaz de usuario requeridos ayudar a elegir la
tecnologa de la capa de presentacin 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.

Conclusin

Si bien el Arquitecto de Sistemas es una persona experimentada, su responsabilidad no jugar el rol

de Analista, Diseador, Lder de Proyecto y Tester al mismo tiempo, ms bien tiene como
responsabilidad el asegurar que el sistema sea desarrollado minimizando riesgos tecnolgicos 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 prcticas de diseo de sistemas.

As mismo el entregable del Arquitecto no es un "Si" o un "No" a capricho en la eleccin de la

tecnologa a usar. Todo el proceso de anlisis, las alternativas de solucin y la decisin final deben
estar sustentados y plasmados en un Documento de Arquitectura que documente las decisiones de
diseo y guie el desarrollo.

Ver Video: Riesgo y Diseo de Aplicaciones, en la Unidad 3, en

el Mdulo 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Unidad 4. Arquitectura de la capa de cliente

Introduccin
Un cliente Java EE puede ser un cliente Web o una aplicacin 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 pgina web dinmica que contiene varios tipos de lenguajes de marcas (HTML, XML y
dems), que son generados por componentes web ejecutndose en la capa web
Un navegador web que despliega las pginas 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 tecnologa Java EE del lado del servidor.

Applets
Una pgina web recibida de una capa web puede incluir un Applet incrustado. Un Applet es una
pequea aplicacin cliente escrita en el lenguaje de programacin Java que se ejecuta en la mquina
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 polticas 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 polticas de seguridad en los sistemas clientes. Los componentes web adems
tienen un diseo ms limpio y ms modular porque estos proporcionan una forma de separa la
programacin de la aplicacin del diseo de la pgina web. El personal involucrado en el diseo de la
pgina no necesita entender la sintaxis del lenguaje de programacin Java para hacer su trabajo.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Aplicaciones cliente
Una aplicacin cliente se ejecuta en una mquina 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 grfica de usuario (GUI) creada con la
API de Swing o AWT, aunque una interfase de lnea 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 aplicacin lo exigen, un cliente de aplicacin
puede abrir una conexin HTTP para establecer una comunicacin con un Servlet que se ejecuta en
la capa web. Los clientes de aplicacin 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 programacin 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 tecnologa 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 surgirn paquetes de una forma muy
rpida.

Los servlets son portables entre plataformas ("escribir una vez, ejecutar en cualquier lugar"). Los
servidores Web ms 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 mayora de las pginas 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 cdigo HTML y
de Scripts Son programas que se ejecutan en el servidor y su funcin fundamental es la de
recoger los datos que el cliente ha introducido a travs de un formulario y, en base a ellos,
construir una pgina dinmicamente para responder a la peticin.
Estas pginas se llaman dinmicas porque no van a existir en el disco duro del servidor sino que se
van a generar como respuesta a una peticin hecha desde el cliente a travs de un formulario.

Estos Scripts an 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 ms rpida debido a su ubicacin en el servidor.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 La seguridad aumenta mucho debido a que los programas van a correr bajo el control directo
del administrador del servidor.

Los Scripts ms 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 peticin que le llega.

As, si el sitio Web es bastante popular, supone una prdida 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 comparacin 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 peticin.
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, adems del ahorro de recursos, se
pueden gestionar, de modo ms 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 ningn temor a que los usuarios puedan introducir
Servlet en el servidor, ya que se encuentran protegidos frente a cdigo 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 surgirn paquetes de
una forma muy rpida (por ejemplo, ya existen paquetes para la gestin 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 ms
populares, soportan los Servlets.

Java Server Pages (JSPs)

Los servlets generan siempre toda la pgina, en muchos casos casi toda la pgina es esttica. La
solucin Java Server Pages (JSPs):
Permite mezclar tanto de HTML esttico
Contenido dinmico generado por servlets
Ampliamente soportado por plataformas y servidores Web
Acceso completo a servlets y tecnologas Java (JavaBeans, etc.) en la parte dinmica
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 dinmica de tus pginas de la parte HTML
esttica. Para ello, basta con:
Escribir la parte esttica HTML de la manera habitual.
Encerrar el cdigo Java que genera la parte dinmica de la pgina entre unos delimitadores
especiales, la mayora de los cuales empiezan por y terminan con .
Si quieres tener en la salida esttica 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 42

Una pgina 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 pginas JSP est basado en los servlets de Java -programas en Java destinados a ejecutarse en
el servidor-, aunque el nmero de desarrolladores que pueden afrontar la programacin de JSP es mucho mayor,
dado que resulta mucho ms sencillo aprender que los servlets.

En JSP creamos pginas de manera parecida a como se crean en ASP o PHP -otras dos tecnologas de servidor-.
Generamos archivos con extensin .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
traduccin de esa pgina en un servlet, implementado en un archivo class (Byte codes de Java). Esta fase de
traduccin se lleva a cabo habitualmente cuando se recibe la primera solicitud de la pgina .jsp, aunque existe la
opcin de precompilar en cdigo para evitar ese tiempo de espera la primera vez que un cliente solicita la pgina.

Applet
La definicin ms extendida de applet es "una pequea aplicacin accesible en un servidor de
Internet, que se transporta por la red, se instala automticamente y se ejecuta in situ como parte
de un documento web".
Un Applet es un pequeo programa que no puede correr por s mismo, sino que tiene que estar
incluido en alguna aplicacin 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
mtodos de dicha clase y de sus superclases (Container, Component, Object).

Cualquier Applet que diseemos debe heredar de la clase Applet. Su cdigo bsico asociado es el
siguiente:

import java.awt.*;
import java.applet.*;
public class MyApp extends Applet
{

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
public void init(){
// Este mtodo se llama automticamente cuando se carga el Applet en el sistema.
// Lo llama el navegador o el visor de applets.
// Slo se llama una vez con lo cual se usar para inicializar al Applet.
//Cundo se inicia un applet? Cuando se carga la pgina desde la cual se le
//hace referencia.
// En este mtodo se suele:
Fijar el tamao del applet. 43
Cargar imgenes 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 ejecucin 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 ejecucin.
//Cundo el applet para su ejecucin? Normalmente cuando desaparece del
//campo de visin.
}

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 mtodo es llamado por el sistema de forma automtica cuando considera que el applet
necesita ser repintado.
//En dicho mtodo debemos colocar todo el contenido grfico del Applet.
g.drawString("Hello World", 20, 20);
}
}

No es obligatorio escribir los mtodos init(), start(), stop() y destroy() porque la clase Applet realiza
una implementacin por defecto para todos ellos. La implementacin por defecto no hace nada, por
tanto, los deberemos sobreescribir cuando lo necesitemos.

Invocando a un applet desde pginas HTML

Para invocar a un applet desde una pgina HTML se recurre al siguiente tag.
<APPLET codebase=.. code="Graficos/Miapplet.class" width=350 height=200 name=...>
<!-- codebase es el camino hasta el paquete donde se encuentra la clase que implementa el applet.
Este camino es relativo respecto a la situacin de la pgina -->
<!--code es el nombre de la clase que implementa el applet con el nombre del paquete en caso de
pertenecer a alguno-->
<!--width y height son las dimensiones del rectngulo en el que se va a representar en applet-->
<PARAM name=... value=....>
<!-- Parmetros que deseamos pasarle al applet, conjunto de valores (name,value)-->
<PARAM name=... value=... >
</APPLET>

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Mtodos de la clase Applet.

AppletContext getAppletContext()
Obtiene el contexto del Applet. Ver la clase AppletContext para saber los
mtodos que podemos usar sobre un objeto de este tipo.
String getAppletInfo()
Devuelve informacin acerca del applet.
44
AudioClip getAudioClip(URL url) Devuelve el objeto de tipo AudioClip especificado en la URL.
Posteriormente se puede reproducir con los mtodos play() o loop().
AudioClip getAudioClip(URL url, String name) Devuelve el objeto AudioClip que resulta de la
composicin 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 pgina 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 parmetro especificado. Estos parmetros se le pasan al
applet desde la pgina HTML mediante el tag
String[][] getParameterInfo()
Devuelve informacin sobre los parmetros 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)
Peticin 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 grfica de usuario (GUI) creada con la API de Swing
o AWT, y pudiera ser una aplicacin que se ejecute desde la lnea de comandos.

La base de la programacin grfica se encuentra en estos dos elementos fsicos del ordenador, los
cuales se disearon de forma conjunta con el propsito de presentar informacin al usuario. El
comprender su funcionamiento ayuda a conocer lo que estamos haciendo cuando diseamos un
entorno grfico.
En una estructura AWT hay que destacar varios elementos dentro del sistema grfico de Java.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Elemento Descripcin
Gestores de trazado Modos predefinidos de colocacin 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 bsicos. El AWT dispone de los
siguientes contenedores:
- Window, Frame, Panel, Dialog. 45
Componentes Controles bsicos que dan funcionalidad al interfaz grfico. 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 extensin de AWT, por tanto, no hay que olvidar lo aprendido en
AWT. Es ms, en la mayora de los casos es suficiente con aadir una "J" al componente AWT para
que se convierta en un componente Swing.

En Swing, los componentes de la interfaz grfica son Beans. Todos los componentes son "ligeros"
(lightweight), es decir, ya no se usan componentes dependientes del sistema operativo.

Se utiliza slo el nuevo modelo de Delegacin de eventos.

Son muchas las ventajas que ofrece el uso de Swing:

La navegacin con el teclado es automtica, es decir, cualquier aplicacin Swing se puede
usar sin el ratn sin tener que aadir lneas de cdigo adicionales.
Las etiquetas de informacin ("tool tips") se pueden crear con una sola lnea de cdigo. Estas
etiquetas de informacin son las que aparecen cuando nos situamos con el ratn sobre un
componente del interfaz grfico.
Con respecto al AWT, Swing incorpora muchos aspectos que permiten mejorar el entorno grfico.

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 continuacin pasamos a describir las nuevas clases agrupadas segn lo que sean:
Sumario de clases del paquete javax.swing
BoxLayout Un gestor de trazado nuevo que permite a mltiples
componentes ser colocados segn un eje horizontal o vertical.
JRootPane El componente fundamental en la jerarqua de contenedores.
JWindow Una representacin de una ventana.
JApplet Una versin extendida de java.applet.Applet que aade nuevas
funcionalidades, por ejemplo, pueden aadirse barras de men de
Swing.
JDialog La clase principal para crear una ventana de dilogo.
JFrame Una versin extendida de java.awt.Frame que aade funcionalidades
extras.
JPanel JPanel es un contenedor ligero genrico.
JInternalFrame Un objeto ligero que proporciona muchas de las caractersticas de
una ventana nativa, incluyendo "pinchar y arrastrar", cerrado,
iconizado, redimensionado, ttulo y barra de men.
JComponent La clase base para los componentes Swing.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
AbstractButton Define el comportamiento comn de las clases JButton,
JToggleButton, JCheckbox y JRadioButton. Es una clase abstracta y,
por tanto, no pueden crearse objetos.
AbstractListModel La definicin abstracta para el modelo de datos que proporciona una
lista con sus contenidos.
JButton Un botn Swing.
JCheckBox Un CheckBox Swing.
JRadioButton Una implementacin de un botn tipo radio 46

JToggleButton Una implementacin de un botn de dos estados.

ButtonGroup Esta clase permite crear un grupo de botones con exclusin mltiple.
JLabel Un rea para visualizar un texto corto, una imagen o ambos.
JComboBox Implementacin de Swing de un ComboBox -- Un ComboBox es una
combinacin 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 ms objetos
de una lista.
ImageIcon Una implementacin del interface Icon que permite pintar iconos a
partir de imgenes.
JTextField Una implementacin de una caja de texto..
JPasswordField JPasswordField es un campo de texto tipo password.
JTextArea Una implementacin de un textarea.
JScrollPane Un contenedor que permite aadir 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 grficamente un
valor desplazando una barra dentro de un intervalo.
JMenuBar Una implementacin de una barra de men.
JMenu Una implementacin de un men.
JMenuItem Una implementacin de un MenuItem.
JPopupMenu Una implementacin de un men emergente
JRadioButtonMenuItem Una implementacin de un item de men tipo radio.
JCheckBoxMenuItem Un item de un men Swing que puede ser seleccionado o no.
JSeparator Una implementacin de un separador de opciones de men.
JToolBar Una implementacin de una barra de herramientas.
JColorChooser Esta clase proporciona un panel de controles diseado 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 dilogo estndar
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 representacin grfica.
JScrollBar Una implementacin de una barra de desplazamiento.
JTabbedPane Un componente que permite al usuario desplazarse entre un grupo
de componentes pulsando el tabulador con un ttulo y/o icono dado.
JSplitPane JSplitPane se usa para dividir dos (y slo 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Ver Video: Arquitectura de la capa cliente, en la Unidad 4, en
el Mdulo 10, en la plataforma elearning

Laboratorio: Ejemplo pgina JSP como capa cliente 47

Objetivo
Crear una pgina JSP como ejemplo de capa cliente.
Enunciado
- Realizar una pgina JSP que enve informacin sobre si misma al pulsar sobre un botn.
- Cuando enviemos informacin, mostraremos en una etiqueta DIV los elementos seleccionados.
- Para completar la prctica, debemos dejar marcados los elementos que el usuario haya
seleccionado en nuestra pgina.

<%@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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 if (vfrutas.indexOf(frutas[i])==-1)
{%>
<tr><td><input type="checkbox" name="chkfruta"
value="<%=frutas[i]%>"><%=frutas[i]%></td></tr>
<%}else{%>
<tr><td><input type="checkbox" name="chkfruta" checked
value="<%=frutas[i]%>"><%=frutas[i]%></td></tr>
<%}%> 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
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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Unidad 5. Arquitectura de la capa web

Introduccin
La estrategia tradicional de utilizar aplicaciones compactas causa gran cantidad de problemas de 49
integracin en sistemas software complejos como pueden ser los sistemas de gestin de una
empresa o los sistemas de informacin integrados consistentes en ms de una aplicacin. Estas
aplicaciones suelen encontrarse con importantes problemas de escalabilidad, disponibilidad,
seguridad, integracin...

Para solventar estos problemas se ha generalizado la divisin de las aplicaciones en capas que
normalmente sern tres: una capa que servir para guardar los datos (base de datos), una capa
para centralizar la lgica de negocio (modelo) y por ltimo una interfaz grfica 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 nmero 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 distribucin en capas
ms comn 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 almacn de datos. Esto nos permite una mayor extensibilidad en caso de que existan
tambin clientes no web en el sistema, que trabajaran directamente contra el servidor del modelo.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Tecnologas web
En la tabla siguiente se muestran los diferentes servicios J2EE estndar y los aspectos de aplicacin
correspondiente los que resuelven.
50
J2EE estndar de los servicios

J2EE services J2EE Application aspect Aplicacin

servicios
EJB EJB Distribuido modelo de programacin de componentes
Soporte para la persistencia, transacciones, y la seguridad
JSP JSP Manejo y procesamiento de las solicitudes y respuestas HTTP
Para generar contenido dinmico 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 envo de solicitudes
JMS JMS Para comunicarse con el middleware orientado a mensajes (MOM) los
productos de una manera genrica
Para la comunicacin de acoplamiento flexible
Para la comunicacin asncrona y fiable entre los componentes de la
empresa y los sistemas heredados
JDBC JDBC Para acceder a los almacenes de datos de una manera genrica
JNDI JNDI Para acceder a nombres de directorios y servicios de una manera genrica
JAXP JAXP Para analizar y transformar documentos XML en forma genrica
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 genrica independiente de la
aplicacin gestor de transacciones
JavaMail JavaMail marco independiente de la plataforma e independiente del protocolo para
construir aplicaciones de correo y de mensajera
JCA JCA Para el desarrollo de adaptadores de acoplamiento activo de recursos que
apoyen el acceso a EIS

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 MVC
MVC es un modelo de diseo estndar con el que estn familiarizados muchos desarrolladores.

El marco de MVC incluye los componentes siguientes:

Modelos. Los objetos de modelo son las partes de la aplicacin que implementan la lgica del
dominio de datos de la aplicacin. A menudo, los objetos de modelo recuperan y almacenan
51
el estado del modelo en una base de datos. Por ejemplo, un objeto Product podra recuperar
informacin de una base de datos, trabajar con ella y, a continuacin, escribir la informacin
actualizada en una tabla Productos de una base de datos de SQL Server. En las aplicaciones
pequeas, el modelo es a menudo una separacin conceptual en lugar de fsica. Por ejemplo,
si la aplicacin solo lee un conjunto de datos y lo enva a la vista, la aplicacin no tiene un
nivel de modelo fsico 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 aplicacin.
Normalmente, esta interfaz de usuario se crea a partir de los datos de modelo. Un ejemplo
sera una vista de edicin de una tabla Productos que muestra cuadros de texto, listas
desplegables y casillas basndose en el estado actual de un objeto Product.
Controladores. Los controladores son los componentes que controlan la interaccin del
usuario, trabajan con el modelo y por ltimo seleccionan una vista para representar la
interfaz de usuario. En una aplicacin MVC, la vista solo muestra informacin; el controlador
administra y responde a los datos proporcionados por el usuario y su interaccin. Por
ejemplo, el controlador administra los valores de la cadena de consulta y pasa estos valores
al modelo, que a su vez podra utilizarlos para consultar la base de datos.

El modelo de MVC ayuda a crear aplicaciones que separan los aspectos diferentes de la aplicacin
(lgica de entrada, lgica comercial y lgica de la interfaz de usuario), proporcionando un
acoplamiento entre estos elementos.

El modelo especifica dnde se debera encontrar cada tipo de lgica en la aplicacin. La lgica de la
interfaz de usuario pertenece a la vista. La lgica de entrada pertenece al controlador. La lgica
comercial pertenece al modelo.

Esta separacin ayuda a administrar la complejidad al compilar una aplicacin, ya que permite
centrarse en cada momento en un nico aspecto de la implementacin.

Componentes del modelo

Corresponden a la lgica del negocio con el cual se comunica la aplicacin web. Usualmente el
modelo comprende accesos a Bases de Datos o sistemas que funcionan independientemente de la
aplicacin web.

Componentes del control

Los componentes de control son los encargados de coordinar las actividades de la aplicacin, que
van desde la recepcin de datos del usuario, las verificaciones de forma y la seleccin de un
componente del modelo a ser llamado. Por su parte los componentes del modelo envan al control
sus eventuales resultados y/o errores de manera de poder continuar con otros pasos de la
aplicacin.

Esta separacin simplifica enormemente la escritura tanto de vistas como de componentes del
modelo: Las pginas 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Entre las caractersticas de Struts se pueden mencionar:
Configuracin del control centralizada.
Interrelaciones entre Acciones y pgina u otras acciones se especifican por tablas XML en
lugar de codificarlas en los programas o pginas.
Componentes de aplicacin, que son el mecanismo para compartir informacin
bidireccionalmente entre el usuario de la aplicacin y las acciones del modelo.
52
Libreras de entidades para facilitar la mayora de las operaciones que generalmente realizan
las pginas JSP.
Struts contiene herramientas para validacin de campos de plantillas. bajo varios esquemas
que van desde validaciones locales en la pgina (en javaScript) hasta las validaciones de
fondo hechas a nivel de las acciones.
Struts permite que el desarrollador se concentre en el diseo de aplicaciones complejas como
una serie simple de componentes del Modelo y de la vista intercomunicados por un control
centralizado. Diseando de esta manera se debe obtener una aplicacin ms consistente y
ms fcil de mantener.

Componentes de la vista
La parte de la Vista de una aplicacin basada en Struts generalmente est construida usando
tecnologa JavaServer Pages (JSP). Las pgnas JSP pueden contener texto HTML esttico (o XML)
llamado "plantilla de texto", adems de la habilidad de insertar contenido dinmico basado en la
interpretacin (en el momento de solicitud de la pgina) de etiquetas de accin especiales. El
entorno JSP incluye un conjunto de etiquetas estndard, como Adems, hay una
facilidad estndard para definir nuestras propias etiquetas, que estn organizadas en "libreras de
etiquetas personalizadas".

Struts incluye una extensa librera de etiquetas personalizadas que facilitan la creacin de interfaces
de usuario que estn completamente internacionalizados, y que interactan amigablemente con
beans ActionForm que son parte del Modelo del sistema. El uso de estas etiquetas se explica ms
adelante en detalle.

Adems de las pginas JSP y la accin y las etiquetas personalizadas que contienen, normalmente
los objetos de negocio necesitan poder dibujarse a s mismos en HTML (o XML), basndose en su
estado actual en el momento de la solicitud. La salida renderizada desde dichos objetos puede
incluirse fcilmente en una pgina JSP resultante usando la etiqueta de accin estndar

Enterprise Java Beans (EJB) es una plataforma para construir aplicaciones de negocio portables,
reutilizables y escalables usando el lenguaje de programacin Java.

Desde el punto de vista del desarrollador, un EJB es una porcin de cdigo que se ejecuta en un
contenedor EJB, que no es ms 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 cdigo, pero tambin 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 lgica
de negocio con funcionalidades trasversales al modelo de dominio.

En la especificacin 3.0, los EJB no son ms que POJOs (clases planas comunes y corrientes de
Java) con algunos poderes especiales implcitos, que se activan en tiempo de ejecucin (runtime)
cuando son ejecutados en un contenedor de EJBs.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Componentes EJB
Con la tecnologa 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 podramos usarlo, posteriormente, en un programa de agenda o en una
aplicacin de comercio electrnico o virtualmente en cualquier programa en el que se necesite
representar un cliente. 53

Con esta tecnologa, podemos separar las capas, llegando incluso a ser posible que el desarrollador
del bean y el ensamblador de la aplicacin no fueran la misma persona, o ni siquiera trabajaran en
la misma empresa.

El desarrollo basado en componentes promete un paso ms en el camino de la programacin

orientada a objetos.

Con la programacin 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 cdigo 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 atencin 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 informacin del componente a nuestro
contenedor EJB y a nuestro entorno de trabajo (bases de datos, arquitectura de la aplicacin, etc.).

El despliegue se define de forma declarativa, mediante un fichero XML (descriptor del despliegue,
deployment descriptor) en el que se definen todas las caractersticas 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:

Integracin: Proveen una forma de acoplar en tiempo de ejecucin diferentes componentes,

mediante la simple configuracin de anotaciones xml. La integracin es un servicio que
proveen los beans de sesin 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 aplicacin sencilla con un solo thread (hilo). El contenedor se
encarga de que los EJBs tengan el soporte adecuado para una aplicacin multi-usuario (como

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 son en general las aplicaciones empresariales) de forma transparente, asegurando el acceso
seguro, consistente y alto rendimiento. Se aplican a los beans de sesin y a los MDBs.

Administracin 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
aplicacin de escritorio ordinaria. El contenedor manipula los detalles de las sesiones. 54

Mensajera: Mediante los MDBs es posible desacoplar por completo dos componentes para
que se comuniquen de forma asincrnica, 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
configuracin. Esto significa que cuando un mtodo de un EJB (Session Bean o MDB) se
completa normalmente, el contenedor se encargar de finalizar la transaccin y validar los
cambios que se realizaron en los datos de forma permanente. Si algo fallara durante la
ejecucin del mtodo (una excepcin o cualquier otro problema), la transaccin hara un
rollback y es como si el mtodo jams se hubiera invocado.

Seguridad: EJB soporta integracin 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 (programacin

orientada a aspectos). No es tan robusto y completo como otros, pero es lo suficientemente
til para que sea utilizado por los dems 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 Inyeccin de Dependencia. El procedimiento para inyectar un
componente local o uno remoto es exactamente el mismo, abstrayndonos de las
complicaciones especficas de RMI o similares. Este servicio aplica nicamente a los Session
Beans.

Web Services: Un Stateless Session Bean puede publicar sus mtodos como servicios web
mediante una sencilla anotacin.

Persistencia: EJB 3 provee la especificacin JPA para el mapeo de objetos llamados

Entidades a tablas o POJOs.

Aqu tenemos un grfico que mostrara la representacin de EJB dentro de un mdulo web.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 55

Tipos de beans
Existen tres tipos de beans definidos, cada uno implementa unas caractersticas diferentes y
permiten ser combinados entre si.

Beans de Sesin (Session Beans)

En una aplicacin tpica, dividida en grandes capas (presentacin, lgica de negocio, persistencia y
base de datos), los Beans de Sesin viven en la lgica de negocio.

Hay dos grandes tipos de Beans de Sesin:

Stateless (sin estado)
Stateful (con estado)

Stateless no conserva el estado de ninguno de sus atributos de la invocacin de un mtodo a otro.

Stateful conserva el estado a lo largo de toda una sesin. Los Beans de Sesin Stateless son los
nicos que pueden exponerse como servicios web.
Los beans de sesin son invocados por el cliente con el propsito de ejecutar operaciones de negocio
especficas, como por ejemplo podra ser mostrar todos los datos de una determinada tabla.
El nombre sesin implica que la instancia del bean estar disponible durante una unidad de trabajo
(unit of work) y no sobrevivir a una cada del servidor.
Un bean de sesin sirve para modelar cualquier funcionalidad lgica de una aplicacin y se utilizan
para realizar acciones y representar propiedades de objetos.

Message-Driven Beans (MDBs)

Viven en la lgica de negocio y los servicios que proveen son parecidos a los Beans de Sesin, con la
diferencia de que los MDBs son usados para invocar mtodos de forma asincrnica.

Cuando se produce la invocacin de un mtodo de un MDB desde un cliente, la llamada no bloquea

el cdigo del cliente y el mismo puede seguir con su ejecucin, sin tener que esperar
indefinidamente por la respuesta del servidor.
Los MDBs encapsulan el popular servicio de mensajera de Java, Java Message Service (JMS).

Los MDBs tambin procesan lgica de negocio, pero un cliente nunca invoca a un mtodo de un MDB
directamente.

El sistema de mensajera asincrnica propone la utilizacin de una capa intermedia en la

comunicacin entre el creador y el consumidor del mensaje.
En EJB 3, esta capa se llama MOM (Message-oriented Middleware).

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Bsicamente, MOM es un software que permite funcionar como servidor de mensajera, reteniendo
los mensajes del productor y envindolos 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), tambin parte de la especificacin de EJB 3.0.
56
Las entidades son POJOs con cierta informacin 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 segn se gestione la persistencia por parte del bean o del contenedor.

Los EJB de entidad estn directamente relacionados con los datos de la aplicacin, son objetos que
mantienen en memoria los datos que maneja la aplicacin, las entidades que disponen de
persistencia.

Los Beans de Entidad normalmente mapean (mantienen una relacin en memoria) las tablas de
una base de datos relacional, aunque tambin 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 sincronizacin total entre el estado de los datos entre
la memoria y la fuente de datos.
Por esta razn se dice que los Beans de Entidad son los EJB que sobreviven a cadas del sistema, ya
que en caso de un fallo del sistema, los datos que hay en memoria estaran guardados en el
dispositivo persistente, como por ejemplo la base de datos, con lo cual, cuando se reinicie el
servidor se recuperarn sin ningn problema.

La especificacin Enterprise JavaBeans est escrita para diferentes pblicos, pero podra resumirse
en dos niveles diferentes:

El desarrollador del cliente

Un cliente es cualquier usuario de un Enterprise JavaBean y podria ser cualquier aplicacin Java del
lado del cliente, un servlet o incluso otro EJB.

Un programador del lado del cliente que disea una aplicacin Web o utilice un servlet para
establecer la comunicacin 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 mtodos y cmo liberar sus
recursos.

Un cliente siempre utiliza el mismo procedimiento para la creacin de objetos, bsquedas e

invocacin de mtodos, independientemente de como se implemente un EJB determinado.

El cliente no necesita preocuparse sobre la implementacin del EJB, solamente debe tener en cuenta
las acciones o propiedades del bean para representar los elementos en las pginas.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
El desarrollador EJB
La principal responsabilidad del programador de un bean ser escribir la lgica de empresa y
acciones o propiedades.

Siempre que sea posible, la especificacin 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 cdigo 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.

Tambin podramos tener clases Java adicionales que apoyen la operacin del bean, clases de ayuda
que implementen la lgica de negocio.

Todos estos archivos estaran empaquetados en un JAR, ya hemos visto que es la unidad estndar
de empaquetado de clases de Java.

Podriamos tener muchos beans dentro de un nico archivo JAR, pero cada archivo JAR contendra
nicamente descriptor del bean xml.

El descriptor de implementacin debe situarse en un directorio especifico, de forma que el

contenedor EJB sabra donde buscarlo.

Este directorio se llama META- INF y no podemos cambiarle el nombre, sigue una especificacin
estndar.

Aqu podemos visualizar la implementacin del uso de un EJB dentro de un entorno de desarrollo,
independientemente que sea realizada la llamada desde un navegador o desde una aplicacin Java.

Ver Video: Arquitectura de la Capa Web, en la Unidad 5,

en el Mdulo 10, en la plataforma elearning

Laboratorio: Arquitectura Capa Web con MVC

Objetivo
Realizar el esqueleto de una aplicacin MVC con Struts.

Enunciado
- Abrir un proyecto Struts y aadir dos ficheros de tipo Struts Action y Struts ActionForm
Beans.
- En la pgina jsp insertaremos etiquetas de la librera de Struts html para enlazar la pgina al
modelo y al controlador.

Clase Action
Las subclases de la Clase Action se ejecutan en respuesta a una peticin de un usuario.

Las subclases de Action desempean el siguiente papel:

Interactuar con el modelo
Controlar el flujo de navegacin a la vista (en este caso pgina JSP) que corresponda

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Class Name: TiendaAction
Package: paqActions
Action Path: /Tienda

58

Como podemos observar, en el fichero struts-config.xml, el asistente de NetBeans ha aadido 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
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
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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Unidad 6. Arquitectura de la Capa de Negocio

Introduccin
En aplicaciones Java los desarrolladores web siempre han organizado la lgica de negocios a travs 60
de un diseo procedimental u orientado a objetos.

Objetivos
Describir la arquitectura de la capa de negocio.
Entender la organizacin que se realiza en aplicaciones java haciendo uso de la capa de
negocio.

Diseo procedimental
Organiza el cdigo en funciones y estructuras de datos simples. Las estructuras de datos,
generalmente se crean, se inicializan y se pasan como parmetros a las funciones. La relacin entre
estas funciones y los datos que utilizan suelen asociarse en libreras segn el criterio del
programador.

Orientado a objetos
Organiza el cdigo en objetos que contienen ambos aspectos, datos y comportamiento. Dichos
objetos colaboran, generalmente mediante herencia o composicin para resolver la lgica de la
aplicacin. La relacin entre los datos y las funciones que los usan est mantenida en su mayor
parte por el propio lenguaje. Generalmente el diseo orientado a objetos es ms fcil de entender,
mantener, extender y probar.

A pesar de los beneficios del diseo OO, muchas aplicaciones J2EE modernas se han escrito
utilizando el estilo procedimental. Uno de los precursores principales de dicho estilo fue la
especificacin EJB (anterior a 3.0).

Diseo Procedimental
Las caractersticas ms importantes del diseo procedimental son las siguientes:
Implementar nuevas funcionalidades es fcil. Basta aadir cdigo a un script transaccional
(Transaction Script, Fowler, P_EAA) o aadir un script transaccional nuevo.
No hace falta disear la aplicacin. No se necesita determinar las clases ni sus
responsabilidades. La lgica 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 61

Es ms asequible para programadores con poca experiencia. Este es el principal motivo por el que
las Factoras de Software suelen decantarse principalmente por el estilo procedimental frente al OO.

El sistema funciona bien con lgicas de negocio simples pero a medida que esta se complica, los
scripts transaccionales suelen contener miles de lneas de cdigo. Se promueve la duplicacin de
cdigo, los programadores tendern a programar para si mismos debido a la dificultad de encontrar
los mtodos disponibles para cada modelo de datos. Se pierde el principal atractivo de la omisin del
diseo. El sistema se hace demasiado difcil de entender, probar y mantener.

Ciclo de Vida de los Beans de Session

El ciclo de vida de los beans de sesin depende del tipo de anotacin en la que se ha delimitado
dicho Bean.

Ciclo de vida Bean @StateFul:

Creacin: Cuando el cliente ejecuta el mtodo create().
Uso: Cuando el cliente llama un mtodo de negocio.
Desactivacin: El bean se manda a memoria secundaria.
Activacin: El bean es despertado para servir algn mtodo al cliente.
Destruccin: Cuando el cliente termina su sesin con el bean.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 62

Diseo Orientado a Objetos

En la actualidad podemos decir que en muchos desarrollos Java muchos programadores han optado
por utilizar orientacin a objetos en sus desarrollos, esto es debido a que muchos autores no optado
por el desarrollo de EJB. Los EJB son mucho ms complejos que el diseo OO con los framework
actuales.
Existen algunos frameworks que recuperaban el diseo OO mediante objetos que no implementaban
ninguna de las interfaces especficas de EJB.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
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 (acrnimo 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 acrnimo surge como
una reaccin en el mundo Java a los frameworks cada vez ms complejos, y que requieren un 63
complicado andamiaje que esconde el problema que realmente se est modelando. En particular
surge en oposicin al modelo planteado por los estndares EJB anteriores al 3.0, en los que los
"Enterprise JavaBeans" deban implementar interfaces especiales.

POJO es una nueva palabra para designar algo viejo. No existe en Java una nueva tecnologa con
ese nombre, sino que el nombre existe en el marco de una revalorizacin de la programacin
"simplemente orientada a objetos". Esta revalorizacin tiene que ver tambin con el xito de
lenguajes orientados a objetos ms 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 configuracin 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 verstil
Escalable horizontalmente mediante el uso de clusters en los contenedores web aunque limitada por
las sesiones y el servidor de base de datos.
Reutilizacin de cdigo: 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
configuracin de transacciones mediante Spring es ms configurable que la proporcionada por EJB
CMT.

Orientacin a Objetos: Puesto que no hay limitaciones (o muy pocas, como podra ser la
especificacin java beans) impuestas en los POJOs, la lgica de negocio de la aplicacin puede
resolverse utilizando tcnicas de diseo OO.

Esta ventaja se hace ms importante segn la lgica de negocio se hace ms compleja.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
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 cdigo pueda
refactorizarse con seguridad segn evoluciona la aplicacin.

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 contrasea

b. Aadir la propiedad hibernate.show_sql el valor true en configuration properties.

c. Aadir la propiedad hibernate.current_session_context_class el valor true en

miscellaneous properties.

3. Agreguemos un nuevo archivo, y seleccionemos Hibernate > Asistente de ingeniera inversa de

Hibernate.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 65

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 66

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

Se cargarn automticamente 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 incluirn automticamente.

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.... Categora Hibernate, tipo Archivos de mapas de Hibernate y POJOs de
la base de datos.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 67

Le decimos que genere las clases en el paquete ClasesHospital:

Al darle finalizar se generarn los siguientes archivos:

5. Lo ltimo sera crear un Archivo Nuevo..., Categora Hibernate, Tipo HibernateUtil.java.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Lo guardamos en el mismo paquete:

68

6. Despus de configurarlo todo comenzamos con el desarrollo de nuestra aplicacin.

Crea una nueva Clase Java (Archivo Nuevo..., Categora Java, tipo Clase Java) y llmale
EmpleadosHelper y lo ponemos dentro del paquete ClasesHospital.

Incluimos el siguiente cdigo:

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();
}

Despus incluimos un mtodo para realizar bsquedas:

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 pgina jsp.
<%@page import="ClasesHospital.*"%>
<%@page import="java.util.List"%>
<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

<html>

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 <head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>JSP Page</title>
</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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 70

Ver Video: Arquitectura de la capa de negocio, en la Unidad 6,

en el Mdulo 10, en la plataforma elearning

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 accin con Hibernate
- Crear mtodos para el alta, baja y modificacin.

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 contrasea

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 - Aadir la propiedad hibernate.show_sql el valor true en configuration properties.

71

- Aadir la propiedad hibernate.current_session_context_class el valor true en miscellaneous

properties.

3. Agreguemos un nuevo archivo, y seleccionemos Hibernate > Asistente de ingeniera inversa de

Hibernate.

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

Se cargarn automticamente 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 incluirn automticamente.
Nos generar el siguiente archivo:

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 72

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
<?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"/> 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.... Categora 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 generarn los siguientes archivos:

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
5. Lo ltimo sera crear un Archivo Nuevo..., Categora Hibernate, Tipo HibernateUtil.java.

74

Lo guardamos en el mismo paquete:

6. Despus de configurarlo todo comenzamos con el desarrollo de nuestra aplicacin.

Crea una nueva Clase Java (Archivo Nuevo..., Categora Java, tipo Clase Java) y llmale
EmpleadosHelper y lo pnemos dentro del paquete ClasesHospital.

Incluimos el siguiente cdigo:

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();
}

Despus incluimos un mtodo para realizar las acciones:

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
public void borrar() {
Emp ee = new Emp();
short ii=7698;
ee.setEmpNo(ii);
org.hibernate.Transaction tx = session.beginTransaction();
session.delete(ee);
tx.commit(); 75
}
public void anadir() {

Emp ee = new Emp();

short categ=111;
ee.setEmpNo(categ);
ee.setApellido("SNCHEZ 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;
org.hibernate.Transaction tx = session.beginTransaction();
Emp ee = (Emp)session.load(Emp.class,num);

ee.setApellido("ddd");

session.update(ee);
tx.commit();

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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 76

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Unidad 7. Arquitectura de Integracin de
Capas

77
Objetivos
Entender la arquitectura de capas en Java.

Conocer las diferentes estructuras y ventajas de los patrones de diseo y arquitectura en n capas.

Introduccin
Un patrn de diseo es una abstraccin de una solucin en un nivel alto. Los patrones solucionan
problemas que existen en muchos niveles de abstraccin. Hay patrones que abarcan las distintas
etapas del desarrollo, desde el anlisis hasta el diseo y desde la arquitectura hasta la
implementacin.
Algunas personas definen un patrn como una solucin recurrente para un problema en un contexto.
Los patrones de diseo no estn enfocados a ningn lenguaje, son arquitecturas que definen las
estructuras de soluciones.
Un contexto es el entorno, situacin, o condiciones relacionadas dentro de las cuales existe algo.
Un problema es una cuestin 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 solucin se refiere a la respuesta al problema dentro de un contexto que ayuda a resolver las
dificultades.
Entonces, si tenemos una solucin a un problema en un contexto, es un patrn?. No
necesariamente. Tambin necesitamos asociar la caracterstica de recurrencia con la definicin de un
patrn.
Los patrones deberan comunicar soluciones de diseo a los desarrolladores y arquitectos que los
leen y los utilizan. Aunque el concepto de patrn es bastante simple, definir realmente el trmino es
muy complejo.
Hemos sealado slo las referencias para que puedas indagar en ms profundidad en la historia de
los patrones y aprender sobre ellos en otras reas. Sin embargo, deberas tener en mente que la
definicin de patrn que hemos adoptado funciona. En nuestro catlogo, se describe un patrn de
acuerdo a sus principales caractersticas: contexto, problema y solucion, junto con otros aspectos
importantes, como causas y consecuencias. La pgina que describe la plantilla de patrones explica
estas caractersticas en ms detalle.
A cada diseo de proyecto le sigue el problema que trata de resolver, la solucin 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 patrn utilizar. Lo normal es, como observar a menudo en la tecnologa de programacin y
otros campos, es buscar la media entre flexibilidad y rendimiento.
La mayora de las personas utiliza patrones de diseo cuando perciben un problema en su proyecto,
como por ejemplo, el rendimiento.
Un patrn de diseo 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 diseo para solucionar los problemas e
implementar el rendimiento de la aplicacin.
Los patrones de diseo se pueden dividir en tres grandes categoras basadas en su propsito:
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 instanciacin y ocultar los detalles de cmo los objetos son creados o
inicializados.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
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 comunicacin y relacin entre los objetos
de un sistema. El propsito de este patrn 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 instanciacin de la Clase.
Creacional del objeto: Los patrones creacionales de objetos son ms escalables y dinmicos
comparados de los patrones creacionales de Clases.

Estructurales
Estructural de la Clase: Los patrones estructurales de Clases usan la herencia para
proporcionar interfaces ms tiles combinando la funcionalidad de mltiples Clases.
Estructural de Objetos: Los patrones estructurales de objetos crean objetos complejos
agregando objetos individuales para construir grandes estructuras. La composicin del
patrn estructural del objeto puede ser cambiado en tiempo de ejecucin, 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 comunicacin entre objetos relacionales, como objetos incluidos en
un objeto complejo.

Con la aparicin del entorno J2EE, aparecieron nuevos catlogos de patrones de diseo. J2EE es
una arquitectura por si misma que integra otras arquitecturas, incluyendo servlets, JavaServer
Pages, Enterprise JavaBeans, y ms. Existen 5 capas en la arquitectura J2EE:
Cliente

Presentacin

Negocios

Integracin

Recurso

Los patrones J2EE se pueden dividir en tres categoras:

Capa de presentacin
Capa de Negocios
Capa de Integracin

Modelo Vista Controlador

El modelo actual de pginas web, define que las peticiones de los clientes son solicitudes a pginas
de servidor (jsp, servlets) que contienen la lgica de negocio y el diseo html en un mismo ligar.
Las pginas ejecutan acciones del usuario que ha realizado sobre esa pgina. Dichas acciones son
capturadas por clases o pueden estar escritas en una clase Servlet.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
En este tipo de arquitectura conocida, el cliente hace Request a objetos de la capa de presentacin
(Pagina del servidor), que luego llama a su cdigo controlador para pedirle funcionalidad.
En el caso de un diseo de datos MVC, el Request se realiza a un objeto de tipo Controlador que
crea una presentacin 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 lgica 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 disear en tres capas de negocio y no poner todo el cdigo en las
interfaces de usuario de tu sistema (IU).

La idea consiste en tener 3 niveles de funcionalidad bien definidos:

Capa de presentacin: Con nuestras Interfaces (pginas HTML..) y sus controles visuales
(controles de formulario) junto con sus eventos.
Capa de negocio: Lgica del dominio. Aqu ir todo el cdigo que define las reglas de negocio
(clculos, validaciones). Surge de los procesos que hemos encontrado en el anlisis.
Capa de acceso a datos: El cdigo que permite acceder a las fuentes de datos. Esencialmente
trata sobre 4 operaciones bsicas, 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 aplicacin en tres componentes
principales: el modelo, la vista y el controlador.
El marco de J2EE proporciona una alternativa al modelo de pginas de servidor para crear
aplicaciones web.
El marco de J2EE es un marco de presentacin de poca complejidad y fcil de comprobar que se
integra con las caractersticas de Java existentes, como el acceso a datos o la representacin de
datos en las pginas.
MVC es un modelo de diseo estndar con el que estn familiarizados muchos desarrolladores.
Algunos tipos de aplicaciones web salen beneficiadas con el marco de MVC.
Otras seguirn utilizando el modelo de la aplicacin J2EE tradicional que est basado en formularios
html, cdigo del servidor y postbacks. Otros tipos de aplicaciones web combinarn 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 aplicacin que implementan la lgica del
dominio de datos de la aplicacin.
A menudo, los objetos de modelo recuperan y almacenan el estado del modelo en una base de
datos. Por ejemplo, un objeto Product podra recuperar informacin de una base de datos, trabajar
con ella y, a continuacin, escribir la informacin actualizada en una tabla Productos de una base de
datos.
En las aplicaciones pequeas, el modelo es a menudo una separacin conceptual en lugar de fsica.
Por ejemplo, si la aplicacin solo lee un conjunto de datos y lo enva a la vista, la aplicacin no tiene
un nivel de modelo fsico 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 aplicacin.
Normalmente, esta interfaz de usuario se crea a partir de los datos de modelo. Un ejemplo sera
una vista de edicin de una tabla Productos que muestra cuadros de texto, listas desplegables y
casillas basndose en el estado actual de un objeto Product.
Controladores. Los controladores son los componentes que controlan la interaccin del usuario,
trabajan con el modelo y por ltimo seleccionan una vista para representar la interfaz de usuario.
En una aplicacin MVC, la vista solo muestra informacin; el controlador administra y responde a los
datos proporcionados por el usuario y su interaccin. Por ejemplo, el controlador administra los
valores de la cadena de consulta y pasa estos valores al modelo, que a su vez podra utilizarlos para
consultar la base de datos.
El modelo de MVC ayuda a crear aplicaciones que separan los aspectos diferentes de la aplicacin
(lgica de entrada, lgica comercial y lgica de la interfaz de usuario), proporcionando un
acoplamiento entre estos elementos.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
El modelo especifica dnde se debera encontrar cada tipo de lgica en la aplicacin. La lgica de la
interfaz de usuario pertenece a la vista. La lgica de entrada pertenece al controlador. La lgica
comercial pertenece al modelo.
Esta separacin ayuda a administrar la complejidad al compilar una aplicacin, ya que permite
centrarse en cada momento en un nico aspecto de la implementacin. Por ejemplo, podemos
centrarnos en la vista sin estar condicionado por la lgica comercial.
El acoplamiento entre los tres componentes principales de una aplicacin MVC favorece el desarrollo
paralelo. Por ejemplo, un desarrollador de software puede trabajar en la vista, un segundo 80
desarrollador puede ocuparse de la lgica del controlador y un tercero se puede centrar en la lgica
comercial del modelo.
En este grfico podemos visualizar cmo son las caractersticas de envi de una pgina web con la
lgica tradicional de J2EE utilizando pginas de servidor.

El ciclo de vida de una aplicacin MVC es simple. Lo primero de todo es que no realizamos en
ningn momento un postback. No existen mtodos de accin para el envo de la pgina tal y como
los conocemos, sino que cada accin est delimitada por un controlador, que devolver la Vista final
al usuario.
El usuario realizar una accin en la Vista, que llamar al controlador con una accin delimitada, y el
modelo se encargar de la lgica para poder realizar la accin final.

Si nos fijamos en la lgica MVC, solamente tenemos un manejador, que ser el encargado de llamar
a su controlador correspondiente, segn la accin del usuario.

Cada pgina que visualiza el usuario es independiente a la lgica de negocio, y cada una es
representada individualmente al realizar acciones sobre ella.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Con la lgica 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 peticin sobre una de esas acciones, el manejador se encarga de enviar
dicha informacin al servidor, y dependiendo de la accin que enva el usuario, se llama a un
controlador que representar la vista correspondiente en Html.
En cambio, si lo hacemos con las pginas JSP, cada pgina es independiente entre s y si
quisiramos cambiar o aadir algo, habra que hacerlo pgina a pgina, mientras que con MVC,
habra que hacerlo independiente a cada controlador y vista. 81

Struts con Java

Struts es un framework basado en tecnologa Java para el desarrollo Web basado en el patrn de
diseo MVC (modelo, vista, controlador).
Un framework es una herramienta que se basa en soluciones reutilizables para el desarrollo y/o
implementacin de una aplicacin que permite acotar tiempos, reducir cdigo y optimizar tareas.
Gracias a Struts podemos construir aplicaciones Web sin introducir cdigo java en nuestras pginas
jsp, en su lugar struts contiene unos tags o etiquetas que realizan acciones y que permiten reducir
el tiempo de desarrollo.
El patrn de diseo MVC consiste en separar una aplicacin en tres componentes:
Modelo: Reglas de Negocio, acceso a los datos y Persistencia.( Beans, EJB, ORM)
Vista: Gestin 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 sera 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 pginas 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 contraseas 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 Navegacin:

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 A travs de un archivo de configuracin (struts-conf) se gestiona el flujo de navegacin entre
pginas, que tambin se logra extendiendo la clase ActionForm y Action.

Capas de arquitectura JEE

En la arquitectura JEE se contemplan cuatro capas, en funcin del tipo de servicio y contenedores:
Capa de cliente: Tambin conocida como capa de presentacin o de aplicacin. Nos
82
encontramos con componentes Java (applets o aplicaciones) y componentes que son parte
del diseo web y su lgica en el cliente (HTML, JavaScript, css, etc.).
Capa Web. Intermediario entre el cliente y otras capas. Sus componentes principales son los
servlets y las pginas 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 mltiples aplicaciones tener acceso de forma
concurrente a datos y lgica de negocio. Los EJB se encuentran en un servidor EJB, que no
es ms que un servidor de objetos distribuidos. Un EJB puede conectarse a cualquier capa,
aunque su misin esencial es conectarse con los sistemas de informacin empresarial (un
gestor de base de datos, ERP, etc.)
Capa de sistemas de informacin empresarial.

La visin de la arquitectura es un esquema lgico, no fsico. Cuando hablamos de capas nos

referimos sobre todo a servicios diferentes que pueden estar fsicamente dentro de la misma
mquina e incluso compartir servidor de aplicaciones y JVM.

Componentes EJB
Con la tecnologa 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 podramos usarlo, posteriormente, en un programa de agenda o en una
aplicacin de comercio electrnico o virtualmente en cualquier programa en el que se necesite
representar un cliente.
Con esta tecnologa, podemos separar las capas, llegando incluso a ser posible que el desarrollador
del bean y el ensamblador de la aplicacin no fueran la misma persona, o ni siquiera trabajaran en
la misma empresa.
El desarrollo basado en componentes promete un paso ms en el camino de la programacin
orientada a objetos.
Con la programacin 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 cdigo 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 atencin 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 informacin del componente a nuestro
contenedor EJB y a nuestro entorno de trabajo (bases de datos, arquitectura de la aplicacin, etc.).
El despliegue se define de forma declarativa, mediante un fichero XML (descriptor del despliegue,
deployment descriptor) en el que se definen todas las caractersticas 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Los servicios que ofrece un contenedor de EJBs son los siguientes:
Integracin: Proveen una forma de acoplar en tiempo de ejecucin diferentes componentes, mediante la simple
configuracin de anotaciones xml. La integracin es un servicio que proveen los beans de sesin 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 aplicacin sencilla con un solo thread (hilo). El contenedor se encarga de que los EJBs tengan el soporte
adecuado para una aplicacin 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 sesin y a
los MDBs.

Administracin 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 aplicacin de escritorio ordinaria. El contenedor manipula los detalles de las
sesiones.

Mensajera: Mediante los MDBs es posible desacoplar por completo dos componentes para que se comuniquen
de forma asincrnica, 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 configuracin. Esto significa que cuando
un mtodo de un EJB (Session Bean o MDB) se completa normalmente, el contenedor se encargar de finalizar la
transaccin y validar los cambios que se realizaron en los datos de forma permanente. Si algo fallara durante la
ejecucin del mtodo (una excepcin o cualquier otro problema), la transaccin hara un rollback y es como si el
mtodo jams se hubiera invocado.

Seguridad: EJB soporta integracin 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 (programacin orientada a aspectos). No es
tan robusto y completo como otros, pero es lo suficientemente til para que sea utilizado por los dems 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
Inyeccin de Dependencia. El procedimiento para inyectar un componente local o uno remoto es exactamente el
mismo, abstrayndonos de las complicaciones especficas de RMI o similares. Este servicio aplica nicamente a
los Session Beans.

Web Services: Un Stateless Session Bean puede publicar sus mtodos como servicios web mediante una sencilla
anotacin.

Persistencia: EJB 3 provee la especificacin JPA para el mapeo de objetos llamados Entidades a tablas o POJOs.

Aqu tenemos un grfico que mostrara la representacin de EJB dentro de un mdulo web.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 84

Tipos de beans
Existen tres tipos de beans definidos, cada uno implementa unas caractersticas diferentes y
permiten ser combinados entre si.

Beans de Sesin (Session Beans)

En una aplicacin tpica, dividida en grandes capas (presentacin, lgica de negocio, persistencia y
base de datos), los Beans de Sesin viven en la lgica de negocio.
Hay dos grandes tipos de Beans de Sesin:
Stateless (sin estado)

Stateful (con estado)

Stateless no conserva el estado de ninguno de sus atributos de la invocacin de un mtodo a otro.

Stateful conserva el estado a lo largo de toda una sesin. Los Beans de Sesin Stateless son los
nicos que pueden exponerse como servicios web.
Los beans de sesin son invocados por el cliente con el propsito de ejecutar operaciones de negocio
especficas, como por ejemplo podra ser mostrar todos los datos de una determinada tabla.
El nombre sesin implica que la instancia del bean estar disponible durante una unidad de trabajo
(unit of work) y no sobrevivir a una cada del servidor.
Un bean de sesin sirve para modelar cualquier funcionalidad lgica de una aplicacin y se utilizan
para realizar acciones y representar propiedades de objetos.

Message-Driven Beans (MDBs)

Viven en la lgica de negocio y los servicios que proveen son parecidos a los Beans de Sesin, con la
diferencia de que los MDBs son usados para invocar mtodos de forma asincrnica.
Cuando se produce la invocacin de un mtodo de un MDB desde un cliente, la llamada no bloquea
el cdigo del cliente y el mismo puede seguir con su ejecucin, sin tener que esperar
indefinidamente por la respuesta del servidor.
Los MDBs encapsulan el popular servicio de mensajera de Java, Java Message Service (JMS).
Los MDBs tambin procesan lgica de negocio, pero un cliente nunca invoca a un mtodo de un MDB
directamente.
El sistema de mensajera asincrnica propone la utilizacin de una capa intermedia en la
comunicacin entre el creador y el consumidor del mensaje.
En EJB 3, esta capa se llama MOM (Message-oriented Middleware). Bsicamente, MOM es un
software que permite funcionar como servidor de mensajera, reteniendo los mensajes del
productor y envindolos 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), tambin parte de la especificacin de EJB 3.0.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Las entidades son POJOs con cierta informacin 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 segn se gestione la persistencia por parte del bean o del contenedor.
Los EJB de entidad estn directamente relacionados con los datos de la aplicacin, son objetos que
mantienen en memoria los datos que maneja la aplicacin, las entidades que disponen de
persistencia.
Los Beans de Entidad normalmente mapean (mantienen una relacin en memoria) las tablas de
una base de datos relacional, aunque tambin 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 sincronizacin total entre el estado de los datos entre
la memoria y la fuente de datos.
Por esta razn se dice que los Beans de Entidad son los EJB que sobreviven a cadas del sistema, ya
que en caso de un fallo del sistema, los datos que hay en memoria estaran guardados en el
dispositivo persistente, como por ejemplo la base de datos, con lo cual, cuando se reinicie el
servidor se recuperarn sin ningn 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 bsicas para los Session Beans.
@Stateful
Indica que el Bean de Sesin 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 especfica.
Si incluimos esta opcin nuestra aplicacin podra no ser portable y no funcione en otro
servidor de aplicaciones.
description: Indica la descripcin de la anotacin.

@Stateless
Indica que el Bean de Sesin 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 especfica. Al
igual que @StateFul esta opcin podra hacer que nuestra aplicacin no sea portable y no
funcione en otro servidor de aplicaciones.
Description: descripcin de la anotacin.

@Init
Especifica que el mtodo se corresponde con un mtodo create de un EJBHome o EJBLocalHome de
EJB 2.1.
Slo se podr llamar una nica vez a este mtodo. Sus atributos son:
Value: indica el nombre del correspondiente mtodo create de la interfaz home adaptada.
Slo se debe utilizar cuando se utiliza el bean anotado con un bean con estado de la
especificacin 2.1 o anterior y que disponga de ms de un mtodo create.

@Remove
Indica que el contenedor debe llamar al mtodo cuando quiera destruir la instancia del Bean. Sus
atributos son:
retainIfException: indica si el Bean debe mantenerse activo si se produce una excepcin. Por
defecto su valor es false.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 86

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
@Local
Indica que la interfaz es local.

@Remote
Indica que la interfaz es remota.
@PostActivate
Invocado despus de que el Bean sea activado por el contenedor. 87

@PrePassivate
Invocado antes de que el Bean est en estado passivate.
Normalmente las anotaciones ms empleadas en las aplicaciones sern @Stateless y @Stateful,
para indicar el tipo de EJB que estemos utilizando. El resto de anotaciones se utilizarn en casos
ms particulares.

Role de EJB dentro de las aplicaciones JEE

La especificacin Enterprise JavaBeans est escrita para diferentes pblicos, pero podra resumirse
en dos niveles diferentes:

El desarrollador del cliente

Un cliente es cualquier usuario de un Enterprise JavaBean y podria ser cualquier aplicacin Java del
lado del cliente, un servlet o incluso otro EJB.
Un programador del lado del cliente que disea una aplicacin Web o utilice un servlet para
establecer la comunicacin 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 mtodos y cmo liberar sus
recursos.
Un cliente siempre utiliza el mismo procedimiento para la creacin de objetos, bsquedas e
invocacin de mtodos, independientemente de como se implemente un EJB determinado.
El cliente no necesita preocuparse sobre la implementacin del EJB, solamente debe tener en cuenta
las acciones o propiedades del bean para representar los elementos en las pginas.

El desarrollador EJB
La principal responsabilidad del programador de un bean ser escribir la lgica de empresa y
acciones o propiedades.
Siempre que sea posible, la especificacin 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 cdigo 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.
Tambin podramos tener clases Java adicionales que apoyen la operacin del bean, clases de ayuda
que implementen la lgica de negocio.
Todos estos archivos estaran empaquetados en un JAR, ya hemos visto que es la unidad estndar
de empaquetado de clases de Java.
Podriamos tener muchos beans dentro de un nico archivo JAR, pero cada archivo JAR contendra
nicamente descriptor del bean xml.
El descriptor de implementacin debe situarse en un directorio especifico, de forma que el
contenedor EJB sabra donde buscarlo.
Este directorio se llama META- INF y no podemos cambiarle el nombre, sigue una especificacin
estndar.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Aqu podemos visualizar la implementacin del uso de un EJB dentro de un entorno de desarrollo,
independientemente que sea realizada la llamada desde un navegador o desde una aplicacin 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 mtodos y
caractersticas de dicho EJB.
Para poder trabajar con EJB, necesitamos tener una Interfaz que contenga los mtodos que vamos a
exponer a un cliente final.
Capa Implementacin

La capa de implementacin es una clase que implementa la capa de Interfaz.

Una clase que hereda directamente de la interfaz del EJB e implementa los mtodos que se hayan
incluido en el contrato.
Por ltimo, el cliente que consuma nuestro EJB, sabr los mtodos que contiene debido al contrato
de nuestra interfaz. Nuestro cdigo estar fuertemente tipado debido a que la clase EJB debe
implementar todos los mtodos de la interfaz y el cliente tendr la seguridad que esos mtodos no
van a variar el contrato.
Vamos a visualizar una creacin y una llamada a un EJB:
Lo vamos a hacer crendonos un nuevo proyecto de Java Aplicacin Java.

Sobre nuestro nuevo proyecto y sobre el paquete creado, vamos a agregar una Interfaz que ser el
contrato.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 89

Llamaremos a nuestra Interfaz: InterfazEJB

Simplemente vamos a escribir un cdigo con un mtodo que recibir un tipo de dato String.
Escribimos el siguiente cdigo en la Interfaz.
package javaapplication1;
public interface InterfazEJB {
public void GetMensaje(String nombre);
}
A continuacin, 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 librera de los EJB, por lo que tendremos
que incluirla manualmente para poder trabajar con dichas clases.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 90

En la carpeta Biblioteca de NetBeans, irn todas las libreras relacionadas con nuestro proyecto.
Lo que vamos a realizar es agregar la librera que permite trabajar con EJB. Para ello,
seleccionamos en el men contextual: Agregar archivo JAR/carpeta.

Buscamos la librera de ejb en la carpeta dnde la hayamos situado. Dicha librera es proporcionada
en la documentacin del mdulo.

Una vez que ya tenemos la librera aadida, ahora es el momento de implementar la Interfaz sobre
la ClaseEJB. Para ello escribimos el siguiente cdigo:
public class ClaseEJB implements InterfazEJB {
Como vemos en la imagen, nos dar un fallo debido a que tenemos que implementar todos los
mtodos que contega la Interfaz de la que estamos heredando.

Para implementar los mtodos, NetBeans ofrece una herramienta muy til que lee todos los
mtodos de la Interfaz y los implementa dentro de nuestra clase.
Si pulsamos sobre el smbolo de la bombilla de la izquierda del cdigo, nos aparecer una opcin
para Implementar los mtodos. Seleccionamos dicha opcin.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Una vez que tenemos todos los mtodos implementados, escribimos el siguiente cdigo dentro de la 91
clase llamada ClaseEJB.
package javaapplication1;
import javax.ejb.Stateless;
public class ClaseEJB implements InterfazEJB
{
public void GetMensaje(String nombre) {
System.out.println("Primer EJB, Bienvenido a la tecnologa " + 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 implementacin del consumo del Bean. Para indicar que estamos
utilizando un contrato, utilizaremos la anotacin @EJB para que el contenedor reconozca nuestra
lgica de negocio.
Escribimos el siguiente cdigo dentro de la clase ClienteEJB:
package javaapplication1;
import javax.ejb.EJB;
public class ClienteEJB {
@EJB
private ClaseEJB BeanEJB;

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 void MetodoCliente()
{
BeanEJB = new ClaseEJB();
BeanEJB.GetMensaje("Usuario de EJB");
}
}
Por ltimo, nos quedar mostrar el resultado de la aplicacin. Para ello, iremos a la clase inicial de 92
los proyectos de J2SE llamada Main.java.
En el cdigo de arranque de la clase, crearemos el objeto cliente, que a su vez, llamar al mtodo
del Bean que seguir el contrato de la Interfaz.
Implementamos el siguiente cdigo en Main.java:
package javaapplication1;
public class Main {
public static void main(String[] args) {
ClienteEJB cliente = new ClienteEJB();
cliente.MetodoCliente();
}
}
Como podemos comprobar cuando ejecutemos la aplicacin (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, bastara con que supiese
HTML para poder implementar la funcionalidad.
Un Custom Tag es una etiqueta propia, personalizada, es una ampliacin de las Acciones JavaBeans.
Uno de los objetivos, ser no utilizar en las pginas JSP cdigo java, sino que los Custom Tags se
encargan de realizar todos los posibles tipos de acciones.
Se necesitan mltiples ficheros para trabajar: XML y JSP
Definicin de etiquetas:
Archivo tld Es el archivo de definicin de las etiquetas Custom Tags
Debemos indicar las caractersticas de etiquetas que habr en todo mi proyecto.
El fichero Xml es la descripcin de nuestro sitio web

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 El fichero class es la clase con la lgica java
El fichero JSP La pgina 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 Versin de la librera
Jspversion Versin 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 vlido:

<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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
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 opcin Folder dentro de la categora 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Lo llamaremos mensaje.

95

Escribiremos el siguiente cdigo 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>
<tlibversion>1.0</tlibversion>
<jspversion>2.0</jspversion>
<shortname>mensaje</shortname>
<tag>
<name>primera</name>
<tagclass>paquetecustomtags.PrimeraEtiqueta</tagclass>
<bodycontent>empty</bodycontent>
</tag>
</taglib>
A continuacin 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 96

Implementamos el siguiente cdigo dentro de la clase para, posteriormente, representarlo en una

pgina 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 formato= DateFormat.getTimeInstance();
cadhora=formato.format(horaactual);
return cadhora;
}
}
Ahora debemos irnos al descriptor de la aplicacin 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 aplicacin web quedara de la siguiente forma:

Por ltimo, escribiremos el siguiente cdigo en la pgina index.jsp para realizar la llamada a la
librera Custom Tags que hemos creado:
<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<%@taglib uri="mietiquetacustomtag" prefix="MiEtiqueta" %>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>JSP Page</title>
</head>
<body>
<h1>Pagina realizada con Custom Tags</h1>
<MiEtiqueta:primera/>
</body>
</html>

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Como podremos comprobar al ejecutar la aplicacin, 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,

en el Mdulo 10, en la plataforma elearning

Laboratorio: Custom Tags Departamentos

Objetivos
Conocer el funcionamiento de la tecnologa Custom Tags.
Representar datos en pginas JSP a partir de etiquetas Custom Tags.

Enunciado
Vamos a realizar una pgina JSP que mostrar una tabla con los datos de los departamentos.
Para ello, utilizaremos la tecnologa Custom Tags.
La pgina 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Lo llamaremos AplicacionCustomTags

99

Utilizaremos el servidor Apache Tomcat que trae el IDE Netbeans.

No implementaremos ningn Framework.

Sobre la carpeta WEB-INF, nos crearemos una nueva carpeta que llamaremos EtiquetasDEPT.
Para ello, seleccionamos la opcin Folder dentro de la categora 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 100

Lo llamaremos etiquetadepartamentos

Escribiremos el siguiente cdigo 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>
<tlibversion>1.0</tlibversion>
<jspversion>2.0</jspversion>
<shortname>etiquetadepartamentos</shortname>
<tag>
<name>tabladepartamentos</name>
<tagclass>paquetecustomtags.EtiquetaTablaDept</tagclass>
<bodycontent>empty</bodycontent>
</tag>
</taglib>
A continuacin nos crearemos una clase para poder implementar el cdigo de la etiqueta que
acabamos de realizar.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 102

A continuacin, implementaremos el cdigo 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 += "<td>"+rs.getString(2)+"</td>";
tabla += "<td>"+rs.getString(3)+"</td>";
tabla += "</tr>";
}
tabla += "</table>";
out.write(tabla);
}catch (Exception ex)

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 {
throw new JspTagException("Excepcion al cargar el fichero TLD " +ex.toString());
}
return EVAL_PAGE;
}
}
Ahora debemos irnos al descriptor de la aplicacin web.
Seleccionamos el fichero web.xml dentro de la carpeta WEB-INF y escribimos lo siguiente: 103
<?xml version="1.0" encoding="UTF-8"?>
<!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 cdigo para dibujar los departamentos.

<%@page contentType="text/html" pageEncoding="UTF-8"%>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<%@taglib uri="mietiquetacustomtag" prefix="tagdept" %>
<html>
<head>

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>JSP Page</title>
</head>
<body>
<tagdept:tabladepartamentos/>
</body>
</html> 104
Ya podremos ejecutar nuestro proyecto y comprobar el funcionamiento correcto de la aplicacin:

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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Unidad 8. Arquitectura de seguridad

Introduccin
Java contiene dos definiciones importantes:
Es un lenguaje de programacin orientado a objetos 105
Es una plataforma software en la que se ejecutan programas.

La arquitectura de seguridad de cualquier lenguaje puede exponerse a travs de su programacin o

a travs de sus entornos o componentes.
Los componentes principales de la plataforma Java son:
Un entorno de ejecucin proporcionado por la Mquina Virtual Java (Java VM o JVM).
Este entorno de ejecucin no es ni interpretado ni compilado, es un sistema hbrido.
Los programas se compilan en un formato independiente de la mquina denominado bytecode y son
interpretados por la Mquina 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 implementacin de la JVM es la responsable de la seguridad incorporada en Java, por lo que es
importante que su implementacin 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 coleccin de componentes software, agrupados en bibliotecas o paquetes de
componentes relacionados, que proporcionan multitud de capacidades tiles para el diseo de
interfaces grficos, acceso a redes, gestin 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 encriptacin, firmas
electrnicas, gestin de certificados, etc.
La arquitectura de seguridad se puede exponer desde varios puntos de vista:
Entorno de ejecucin.
La seguridad de un sistema Java para los usuarios, est en la mquina virtual, ya que sta es
la encargada de controlar las acciones que se pueden ejecutar y de que modo,
permitindonos 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 tcnicas
criptogrficas.
Java proporciona una arquitectura en la que integrar estas tcnicas 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 criptogrfica
La criptologa es el estudio de la criptografa y el criptoanlisis.

Viendo sus caractersticas en trminos sociales, es la ciencia que permite que el coste de adquirir o
alterar informacin de modo impropio sea mayor que el posible valor obtenido al hacerlo.

Vista en trminos ms formales, es la prctica y el estudio de tcnicas de encriptacin y

desencriptacin de informacin, es decir, de tcnicas para codificar un mensaje hacindolo

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
ininteligible (encriptacin) y recuperar el mensaje original a partir de esa versin ininteligible
(desencriptacin).

Algoritmo criptogrfico
Es un mtodo matemtico que se emplea para encriptar y desencriptar un mensaje.
Generalmente funciona empleando una o ms claves (nmeros o cadenas de caracteres) como 106
parmetros del algoritmo, de modo que sean necesarias para recuperar el mensaje a partir de la
versin cifrada.
El mensaje antes de encriptar se denomina texto en claro y una vez encriptado se denomina texto
cifrado.

Sistema criptogrfico
Es un sistema para encriptar y desencriptar informacin compuesto por un conjunto de algoritmos
criptogrficos, claves y, posiblemente, varios textos en claro con sus correspondientes versiones en
texto cifrado.

Criptoanlisis
Es el conjunto de procedimientos, procesos y mtodos empleados para romper un algoritmo
criptogrfico, desencriptar un texto cifrado o descubrir las claves empleadas para generarlo.

Los sistemas criptogrficos actuales se basan, principalmente, en dos tipos de algoritmos

criptogrficos:
Algoritmos de clave privada o simtricos
Convierten un mensaje en un texto cifrado del mismo tamao que el original.
Emplean una sola clave para encriptar y desencriptar.
Son los algoritmos empleados para transferir grandes cantidades de informacin de modo
seguro.
Clave pblica o asimtricos
Encriptan un mensaje generando un texto cifrado del mismo tamao que el original.
Usan una clave para encriptar el mensaje (clave privada) y otra para desencriptar (clave
pblica).
Tienen un coste computacional alto y se suelen emplear para distribuir las claves de los
algoritmos simtricos.

Algoritmos de cifrado simtrico

Dentro de estos algoritmos distinguimos dos tipos de algoritmos en funcin 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 tamao fijo del texto en claro y producen
un bloque de tamao fijo de texto cifrado, generalmente del mismo tamao que la entrada.
El tamao del bloque debe ser lo suficientemente grande como para evitar ataques de texto cifrado.
La asignacin de bloques de entrada a bloques de salida debe ser uno a uno para hacer el proceso
reversible y que su formacin parezca aleatoria.
Para la asignacin de bloques los algoritmos de cifrado simtrico realizan sustituciones y
permutaciones en el texto en claro hasta obtener el texto cifrado.
La sustitucin es el reemplazo de un valor de entrada por otro de los posibles valores de salida, en
general, si usamos un tamao de bloque n, el bloque de entrada puede ser sustituido por cualquiera
de los 2n bloques posibles.
La permutacin es un tipo especial de sustitucin en el que los bits de un bloque de entrada son
reordenados para producir el bloque cifrado, de este modo se preservan las estadsticas del bloque
de entrada.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Los algoritmos de cifrado por bloques iterativos funcionan aplicando en sucesivas rotaciones una
transformacin a un bloque de texto en claro.
La misma funcin es aplicada a los datos usando una subclave obtenida de la clave secreta
proporcionada por el usuario.
El nmero 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
transformacin o funcin de rotacin.
Una caracterstica interesante de estos algoritmos es que la encriptacin y desencriptacin son
idnticas estructuralmente, aunque las subclaves empleadas en la encriptacin se toman en orden
inverso en la desencriptacin.
Para aplicar un algoritmo por bloques es necesario descomponer el texto de entrada en bloques de
tamao fijo.

Algoritmos de clave pblica o asimtricos

La criptografa de clave pblica fue inventada en 1975 por Whitfield Diffie y Matin Hellman.

Se basa en emplear un par de claves distintas, una pblica y otra privada.

La idea fundamental es que las claves estn ligadas matemticamente, pero es computacionalmente
imposible obtener una a partir de la otra.

Fundamentos matemticos
Las funciones de una sola direccin son aquellas en las que obtener el resultado en una direccin es
fcil, pero en la otra es casi imposible.

Los algoritmos criptogrficos de clave pblica se basan en funciones de una sola direccin con
puerta trasera, que son aquellos en los que el problema es resoluble en la direccin opuesta (la que
antes era muy difcil) empleando una ayuda (la puerta trasera).

Los siguientes problemas matemticos son considerados como funciones de una sola direccin con
puerta trasera y son la base de la mayora de algoritmos de clave pblica actuales:
Factorizacin de enteros. Un nmero entero siempre se puede representar como un producto
de nmeros primos denominados factores primos.
La factorizacin de enteros consiste en encontrar los factores primos de un nmero.
Los algoritmos criptogrficos basados en este problema aprovechan el hecho de que la
multiplicacin de nmeros primos grandes es computacionalmente sencilla pero la
factorizacin un nmero grande en sus factores primos es muy cara computacionalmente.
Logaritmos discretos. En aritmtica mdulo n dos enteros son equivalentes si tienen el
mismo resto cuando son divididos por n.
El resto de la divisin m / n es el menor entero no negativo que difiere de m por un mltiplo
de n.
La exponenciacin discreta (ax mod n), es la exponenciacin en aritmtica mdulo n.
Por ejemplo, 34 mod 10 es 81 mod 10, que es equivalente a 1 mod 10.
El logaritmo discreto es la operacin inversa a la exponenciacin discreta.
Los algoritmos que emplean este tipo de problema se basan en que la exponenciacin
mdulo n es un problema fcil y hallar el logaritmo discreto es un problema difcil.
Logaritmos discretos de curva elptica. Es una variacin del problema anterior ms cara
computacionalmente, lo que permite usar claves ms pequeas que mejoran las prestaciones
de los algoritmos y reducen el tamao de los textos cifrados.

Tipos de algoritmo
En funcin de su relacin matemtica distinguimos varios tipos de algoritmo:

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Reversible.
o Es aquel en el que un mensaje encriptado con la clave privada puede ser
desencriptado usando la clave pblica y viceversa, es decir, uno encriptado usando la
clave pblica 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 pblica, pero la clave privada no desencripta los mensajes 108
cifrados usando la clave pblica.
De intercambio de claves.
o Slo permiten negociar de forma segura una clave secreta entre dos partes.
Hay que indicar que los algoritmos reversibles tambin se pueden emplear para esta funcin,
pero los irreversibles no.
Aplicaciones de los algoritmos
Este tipo de algoritmos tienen dos aplicaciones fundamentales:
Encriptacin:
Si un usuario A quiere mandar un mensaje a otro usuario B, lo encripta usando la clave
pblica 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 pblica
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 pblica de B.
Lo que B ha hecho es firmar digitalmente el mensaje.
El proceso de desencriptar con una clave pblica un mensaje firmado se denomina
verificacin de firma.
Estos algoritmos son mucho ms caros que los de clave secreta, por lo que no se usan para
encriptar mucha informacin.

Su principal aplicacin est en la fase inicial de una comunicacin, ya que permiten que los dos
extremos se autentifiquen e intercambien claves secretas para encriptar con un algoritmo simtrico.

El problema fundamental de este tipo de algoritmos es la distribucin de las claves, aunque la clave
pblica se puede distribuir libremente quedara el problema de la suplantacin.

Para solventar estos problemas se emplean autoridades certificadoras y certificados digitales.

Cdigos de autentificacin de mensajes y firmas digitales

Un cdigo de autentificacin de mensaje (message authentication code o MAC) es un bloque de
datos de tamao fijo que se enva con un mensaje para averiguar su origen e integridad.

Son muy tiles para proporcionar autentificacin e integridad sin confidencialidad.

Para generar MACs se pueden usar algoritmos de clave secreta, de clave pblica y algoritmos de
resumen de mensajes.

Un tipo de MAC muy empleado en la actualidad es el cdigo de autentificacin de mensaje resumido

(hashed message authentication code o HMAC).

Lo que realiza es generar el MAC aplicando una funcin de dispersin criptogrfica a un conjunto
formado por un mensaje y un cdigo secreto.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
De esta forma, quien recibe el mensaje puede calcular su propio MAC con el mensaje y el cdigo
secreto, que comparte con el que ha generado el MAC.
Si no coinciden, sabemos que el mensaje ha sido manipulado.

Este tipo de tcnicas 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 verificacin para comprobar el origen del mensaje y que no ha sido
modificado durante el trnsito.

Para firmar los mensajes se emplean algoritmos de clave pblica y funciones de dispersin.

El proceso es el siguiente:
1. El emisor genera un resumen del mensaje, lo encripta con su clave privada (clave de
firmado) y enva 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 acompaaba usando la clave pblica del emisor (clave de verificacin).

Si al comparar los resmenes, ambos son iguales, el mensaje es vlido y ha sido firmado por el
emisor real, ya que de otro modo no se hubiera podido desencriptar correctamente con su clave
pblica.

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 slo 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 criptogrficos

La seguridad de un sistema criptogrfico depende generalmente de que al menos una de las claves
empleadas sea secreta, ms que de que el algoritmo de encriptacin sea secreto.

El publicar los algoritmos empleados por un sistema criptogrfico para que sean revisados
pblicamente es una buena prctica que permite que se mejoren algoritmos no totalmente seguros
o se considere que un algoritmo no tiene debilidades.

Los algoritmos criptogrficos tienen distintos grados de seguridad

Seguro computacionalmente.
Con suficiente poder de clculo y almacenamiento, el sistema puede ser vulnerable, pero a
un coste tan elevado que no es prctico.
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 das, con sistemas diseados especficamente 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 criptogrfico puede ser roto en varios niveles:
Deduccin de informacin. Se obtiene parte de informacin de la clave o del texto en claro.
Deduccin de una instancia. Se obtiene el texto en claro a partir de un texto cifrado.
Deduccin global. A partir de la deduccin de una instancia, se obtiene un algoritmo que
obtiene los mismos resultados que el algoritmo original.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 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 criptoanaltico:

Ataque de slo texto cifrado.
El analista dispone de un texto cifrado y quiere obtener el texto en claro o la clave.
Se pueden usar mtodos 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 fcil 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 bsqueda de claves u obtener estadsticas 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 dinmicamente y alterar
sus elecciones en funcin 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 ms en las debilidades del algoritmo.
Ataque de texto en claro elegido adaptativo. Es la versin adaptativa del ataque anterior.

Para que un sistema criptogrfico sea considerado como seguro, debe contener las siguientes
caractersticas:
Debe disponer de un nmero muy elevado de claves posibles, de modo que sea poco
razonable intentar descifrar un mensaje por el mtodo de la fuerza bruta (probando todas las
claves).
Debe producir texto cifrado que parezca aleatorio a un test estadstico estndar.
Debe resistir todos los mtodos conocidos de romper los cdigos, es decir, debe ser
resistente al criptoanlisis.

Aplicaciones de la criptografa
La criptografa es una disciplina con multitud de aplicaciones, muchas de las cuales estn en uso hoy
en da.

Entre las ms importantes destacamos las siguientes:

Seguridad de las comunicaciones.
Es la principal aplicacin de la criptografa a las redes de ordenadores, ya que permiten
establecer canales seguros sobre redes que no lo son.
Adems, con la potencia de clculo actual y empleando algoritmos de cifrado simtrico (que
se intercambian usando algoritmos de clave pblica) se consigue la privacidad sin perder
velocidad en la transferencia.
Identificacin y autentificacin.
Gracias al uso de firmas digitales y otras tcnicas criptogrficas, es posible identificar a un
individuo o validar el acceso a un recurso en un entorno de red con ms garantas que con
los sistemas de usuario y clave tradicionales.
Certificacin.
La certificacin es un esquema mediante el cual, agentes fiables (como una entidad
certificadora) validan la identidad de agentes desconocidos (como usuarios reales).
El sistema de certificacin es la extensin lgica del uso de la criptografa para identificar y
autentificar cuando se emplea a gran escala.
Comercio electrnico.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 111

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Gracias al empleo de canales seguros y a los mecanismos de identificacin se posibilita el
comercio electrnico, ya que tanto las empresas como los usuarios tienen garantas de que
las operaciones no pueden ser espiadas, reducindose el riesgo de fraudes y robos.

Tipos de algoritmos de cifrado simtrico

DES
112
El DES (Data Encription Standard o Estndar de Encriptacin de Datos) es el nombre del documento
FIPS (Federal Information Processing Standard) 46-1 del Instituto Nacional de Estndares y
Tecnologa (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 Encriptacin de Datos.
Es el algoritmo de cifrado simtrico ms estudiado, mejor conocido y ms empleado del mundo.

El DEA (llamado con frecuencia DES) es un algoritmo de cifrado por bloques de 64 bits de tamao.

Emplea una clave de 56 bits durante la ejecucin (se eliminan 8 bits de paridad del bloque de 64).

El algoritmo fue diseado 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 cdigos de
autentificacin de mensajes (MAC) y para encriptacin de un slo 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 operacin emplean
la misma clave.
Dependiendo del mtodo elegido, el grado de seguridad vara; el mtodo ms seguro es el
DES-EEE3.

AES
El AES (Advanced Encription Standard o Estndar Criptogrfico Avanzado) es un algoritmo de cifrado
por bloques destinado a reemplazar al DES como estndar.

RC2
El RC2 es un algoritmo de cifrado por bloques de clave de tamao variable.
El algoritmo trabaja con bloques de 64 bits y entre dos y tres veces ms rpido que el DES en
software.
Se puede hacer ms o menos seguro que el DES contra algoritmos de fuerza bruta eligiendo el
tamao de clave apropiadamente.

RC4
El RC4 es un algoritmo de cifrado de flujo.
Es un algoritmo de tamao de clave variable con operaciones a nivel de byte. Se basa en el uso de
una permutacin aleatoria y tiene un periodo estimado de ms de 10100. Adems, es un algoritmo
de ejecucin rpida en software.
El algoritmo se emplea para encriptacin de ficheros y para encriptar la comunicacin en protocolos
como el SSL (TLS).

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
RC5
El RC5 es un algoritmo parametrizable con tamao de bloque variable, tamao de clave variable y
nmero de rotaciones variable.

Los valores ms comunes de los parmetros son 64 o 128 bits para el tamao de bloque, de 0 a 255
rotaciones y claves de 0 a 2048 bits.
113
El RC5 tiene 3 rutinas: expansin de la clave, encriptacin y desencriptacin.

En la primera rutina la clave proporcionada por el usuario se expande para llenar una tabla de claves
cuyo tamao depende del nmero de rotaciones.

La tabla se emplea en la encriptacin y desencriptacin. Para la encriptacin slo se emplean tres

operaciones: suma de enteros, o-exclusiva de bits y rotacin de variables.

La mezcla de rotaciones dependientes de los datos y de distintas operaciones lo hace resistente al

criptoanlisis 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 encriptacin precisa 8 rotaciones complejas.

El algoritmo funciona de la misma forma para encriptar que para desencriptar.

El algoritmo es fcilmente 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 tamao de bloque de 64 bits y claves de 64 (SAFER K-64) o 128
bits (SAFER K-128).

Tiene un nmero variable de rotaciones, pero es recomendable emplear como mnimo 6.

Blowfish
Es un algoritmo de cifrado por bloques de 64 bits.

Es un algoritmo de tipo Feistel y cada rotacin consiste en una permutacin que depende de la clave
y una sustitucin que depende de la clave y los datos.
Todas las operaciones se basan en o-exclusivas sobre palabras de 32 bits.

La clave tiene tamao variable (con un mximo de 448 bits) y se emplea para generar varios
vectores de subclaves.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Tipos de algoritmos de cifrado asimtrico
RSA
El RSA, llamado as por las siglas de sus creadores (Rivest, Shamir y Adelman), es el algoritmo de
clave pblica ms popular.

El algoritmo se puede usar para encriptar comunicaciones, firmas digitales e intercambio de claves. 114

La clave es de tamao variable, generalmente se usan claves entre 512 y 2048 bits.

Las claves ms grandes aumentan la seguridad del algoritmo pero disminuyen su eficiencia y
generan ms texto cifrado.

Los bloques de texto en claro pueden ser de cualquier tamao, siempre que sea menor que la
longitud de la clave.

Los bloques de texto cifrado generados son del tamao de la clave.

La clave pblica del algoritmo tiene la forma (e, n), donde e es el exponente y n el mdulo.

La longitud de la clave es igual al nmero de bits de n.

El mdulo se obtiene multiplicando dos nmeros primos grandes, p y q.

Los nmeros se seleccionan aleatoriamente y se guardan en secreto.

La clave privada tiene la forma (d, n), donde d es el producto inverso de emodulo(p-1)(q-1) (es
decir, (ed - 1) es divisible por (p-1)(q-1)).

El clculo 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 pblica que permite el intercambio seguro de
un secreto compartido.
Generalmente se emplea junto con algoritmos de cifrado simtrico, como mtodo 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 versin corregida del algoritmo publicada en 1994.
El algoritmo es un estndar ANSI.
El algoritmo toma un mensaje de menos de 264 bits y genera un resumen de 160 bits.
Es ms lento que el MD5, pero la mayor longitud de clave lo hace ms resistente a ataques de
colisin por fuerza bruta y de inversin.

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 mquinas 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 mltiplo de 16.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Sobre ese mensaje se calcula un checksum de 16 bytes que se aade al mensaje y la funcin de
dispersin se aplica al mensaje resultante.
Con el MD4, el mensaje se rellena para que su longitud en bits ms 448 sea divisible por 512.
Una representacin 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 mquinas modernas, por lo que el algoritmo se considera a 115
todos los efectos roto.
El MD5 es, bsicamente, el MD4 con mejoras en la seguridad, aunque es ms lento que este.
El tamao del resumen y la necesidad del relleno son iguales que en el MD4.
Consta de cuatro rotaciones que tienen un diseo ligeramente diferente a las del MD4.
El algoritmo ha sido criptoanalizado con tcnicas similares a las del MD4 y se han encontrado
pseudo-colisiones en la funcin de compresin, pero no en el algoritmo completo.

Certificados digitales
Los certificados digitales son el equivalente digital del DNI, en lo que a la autentificacin de
individuos se refiere, ya que permiten que un individuo demuestre que es quien dice ser, es decir,
que est en posesin de la clave secreta asociada a su certificado.

Para los usuarios, proporcionan un mecanismo para verificar la autenticidad de programas y

documentos obtenidos a travs de la red, el envo de correo encriptado y/o firmado digitalmente, el
control de acceso a recursos, etc.
Un certificado de clave pblica es un punto de unin entre la clave pblica de una entidad y uno o
ms atributos referidos a su identidad.
El certificado garantiza que la clave pblica pertenece a la entidad identificada y que la entidad
posee la correspondiente clave privada.

Los certificados de clave pblica se denominan comnmente 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 slo 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 garanta 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 vlido.
Para evitar la falsificacin de certificados, la entidad certificadora despus de autentificar la
identidad de un sujeto, firma el certificado digitalmente.
Los certificados digitales proporcionan un mecanismo criptogrfico para implementar la
autentificacin, tambin proporcionan un mecanismo seguro y escalable para distribuir claves
pblicas en comunidades grandes.

Certificados X.509
El formato de certificados X.509 es un estndar 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 versin 1 fue extendido en 1993 para incluir dos nuevos campos que permiten
soportar el control de acceso a directorios.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Despus de emplear el X.509 v2 para intentar desarrollar un estndar de correo electrnico seguro,
el formato fue revisado para permitir la extensin con campos adicionales, dando lugar al X.509 v3,
publicado en 1996.
Los elementos del formato de un certificado X.509 v3 son:
Versin. El campo de versin contiene el nmero de versin del certificado codificado.
Nmero de serie del certificado. Este campo es un entero asignado por la autoridad
certificadora.
116
Cada certificado emitido por una CA debe tener un nmero 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
vlido y la CA est obligada a mantener informacin sobre el estado del mismo.
El campo consiste en una fecha inicial, la fecha en la que el certificado comienza a ser vlido
y la fecha despus de la cual, el certificado deja de serlo.
Nombre del sujeto. Este campo identifica la identidad cuya clave pblica est certificada en
el campo siguiente.
El nombre debe ser nico para cada entidad certificada por una CA dada, aunque puede
emitir ms de un certificado con el mismo nombre si es para la misma entidad.
Informacin de clave pblica del sujeto. Este campo contiene la clave pblica, sus
parmetros 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 informacin adicional a sujetos,
claves pblicas, etc.
Un campo de extensin contiene tres partes:
Tipo de extensin. Es un identificador de objeto que proporciona la semntica y el tipo de
informacin (cadena de texto, fecha u otra estructura de datos) para un valor de extensin.
Valor de la extensin. Este subcampo contiene el valor actual del campo.
Indicador de importancia. Es una etiqueta que indica a una aplicacin si es seguro ignorar el
campo de extensin 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 aadiendo nuevas extensiones.
El formato de certificados X.509 se especifica en un sistema de notacin denominado sintaxis
abstracta uno (Abstract Sintax One o ASN-1).
Para la transmisin de los datos se aplica el DER (Distinguished Encoding Rules o reglas de
codificacin distinguible), que transforma el certificado en formato ASN-1 en una secuencia de
octetos apropiada para la transmisin en redes reales.

Autoridades Certificadoras
Una autoridad certificadora es una organizacin fiable que acepta solicitudes de certificados de
entidades, las valida, genera certificados y mantiene la informacin de su estado.
Una CA debe proporcionar una Declaracin de Prcticas de Certificacin (Certification Practice
Statement o CPS) que indique claramente sus polticas y prcticas 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:
Admisin de solicitudes. Un usuario rellena un formulario y lo enva a la CA solicitando un
certificado.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 La generacin de las claves pblica y privada son responsabilidad del usuario o de un sistema
asociado a la CA.
Autentificacin del sujeto. Antes de firmar la informacin proporcionada por el sujeto, la CA
debe verificar su identidad.
Dependiendo del nivel de seguridad deseado y el tipo de certificado se debern tomar las
medidas oportunas para la validacin.
Generacin de certificados. Despus 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 enva a un almacn de
certificados para su distribucin.
Distribucin de certificados. La entidad certificadora puede proporcionar un servicio de
distribucin de certificados para que las aplicaciones tengan acceso y puedan obtener los
certificados de sus subscriptores.
Los mtodos de distribucin pueden ser: correo electrnico, servicios de directorio como el
X.500 o el LDAP, etc.
Anulacin de certificados. Al igual que sucede con las solicitudes de certificados, la CA debe
validar el origen y autenticidad de una solicitud de anulacin.
La CA debe mantener informacin sobre una anulacin durante todo el tiempo de validez del
certificado original.
Almacenes de datos. Hoy en da existe una nocin formal de almacn donde se guardan los
certificados y la informacin de las anulaciones. La designacin oficial de una base de datos
como almacn tiene por objeto sealar que el trabajo con los certificados es fiable y de
confianza.

Los mensajes de datos de la aplicacin son transportados por la capa de registro y son
fragmentados, comprimidos y encriptados basndose en el estado actual de la conexin. 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 cuestin y al entorno sobre el
que se establecer el tipo de desarrollo.

Los servicios de seguridad de Java EE proporcionan un mecanismo robusto y fcilmente configurable

para autenticacin y autorizacin de acceso en diferentes niveles:
Aplicacin.
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 aplicacin.
Responsabilizar a los usuarios por las operaciones que realicen (non-repudiation).
Facilitar su administracin.
Proporcionar mecanismos transparentes para los usuarios.
Ser homogneo a travs de aplicaciones.

Existen varios mecanismos de seguridad que permiten realizar estas acciones:

Identificacin (identification): Mecanismo que permite el reconocimiento de una entidad
(usuario) por un sistema.
Autenticacin (authentication): Mecanismo por el cual los usuarios se validan y se comprueba
que existen en nuestro mbito de seguridad.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Autorizacin (authorization o access control): Mecanismo para asegurar que los usuarios
tienen permiso para realizar operaciones o para obtener acceso a la informacin.
Integridad de datos (data integrity): Mecanismo usado para probar que la informacin no ha
sido modificada por usuarios no autorizados.
Confidencialidad (confidentiality o data privacy): Mecanismo usado para asegurar que slo
usuarios autorizados puedan ver cierta informacin.
No-rechazo (non-repudiation): Mecanismo para impedir que un usuario niegue haber 118
realizado alguna operacin.
Auditora (auditing): Mecanismo para capturar registros de operaciones, a prueba de
falsificaciones.

Implementacin 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:
Creacin y mantenimiento de polticas de seguridad.
Administracin de mbitos realms.
Altas, bajas y cambios de usuarios autorizados.
HTTP e IIOP Listeners.
Conectores.
Insercin (plug-in) de otros programas de seguridad.
Insercin (plug-in) de mdulos de auditora.

Seguridad a nivel declarativo (EJB)

La seguridad a nivel declarativo, implica que la seguridad se monta dentro de la propia aplicacin
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 validacin que deseamos utilizar.
Realms: Coleccin de usuarios (que pueden o no pertenecer a un grupo) y grupos de
usuarios controlados por la misma poltica de seguridad.

Existen 3 tipos: file, admin y certificate realms.

Users: Individuos (o programas de aplicacin) definidos en el Servidor de aplicaciones.
Groups: Conjuntos de usuarios clasificados normalmente por caractersticas 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 aplicacin) que puede ser autenticado.
Security policy: Es el alcance de una poltica de seguridad domain implementada por un
servicio de seguridad.
Security attributes: Caractersticas 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 informacin de seguridad se especifica dentro de las mismas clases.
Declarativa: La informacin de seguridad se especifica en el deployment descriptor. (Los
valores especificados en el descriptor sustituyen a los de las anotaciones.)
Programtica: Postulados embebidos en las clases.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
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 cdigo del bean.
Utilizando anotaciones.
Utilizando elementos en un deployment descriptor.

Para poder utilizar dichas caractersticas, 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 cdigo:
@Resource SessionContext contextoseguro
contextoseguro.getCallerPrincipal( )
contextoseguro.isCallerInRole(String roleName)
Un ejemplo de seguridad utilizando el mtodo getCallerPrincipal().
Dicho mtodo valida los usuarios dentro del propio cdigo y se validara el nombre del usuario.
package newpackage;
import java.security.Principal;
import javax.annotation.Resource;
import javax.ejb.SessionContext;
import javax.ejb.Stateless;
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 aplicacin.
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 estara validado en
//el mtodo findByPrimaryKey
Emp empleado =
em.findByPrimaryKey(Emp.class, nombreusuario);
//Si llegamos a este punto, podriamos modificar los datos
//del usuario mediante mtodos implementados...
empleado.setEName("oldname","newname");
}
}
Como podemos comprobar, los usuarios se validaran antes de la accin del mtodo, y una vez
validados, el propio mtodo comprobara su nombre de usuario para poder realizar las acciones.

Otro tipo de validacin se puede realizar con el mtodo isCallerInRole(role), que permite validar
usuarios mediante grupos o roles a los que perteneces, no validara 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
import javax.ejb.Stateless;
@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 cdigo de los beans se pueden declarar de dos formas
diferentes:
Utilizando la anotacin @DeclareRoles (preferida)
Usando la etiqueta en el fichero deployment descriptor.

Este role de seguridad permite poder modificar los datos de los empleados. Solamente estn
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>
Tambin podemos definir los permisos que necesitamos administrar a nivel de mtodo de la clase.
Los permisos de mtodos se pueden especificar a nivel de clase o a nivel de mtodo (o ambos).

Para ello, debemos emplear las siguientes anotaciones:

@RolesAllowed("lista de roles")
@PermitAll
@DenyAll

Un ejemplo para ofrecer permisos en los mtodos sera el siguiente:

Cdigo 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 () {...}
}
Cdigo de la clase del Bean
import javax.ejb.Stateless;

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
@Stateless
public class NewSessionBean implements MiBean extends MiClase
{
@RolesAllowed("usuarios")
public void PrimerMetodo () {...}
public void SegundoMetodo () {...}
public void OtroMetodo () {...}
} 121
Si analizamos el cdigo anterior, los administradores podrn obtener acceso a los dos mtodo del objeto
MiClase, pero en el mtodo PrimerMetodo(), tambin tendrn acceso los usuarios, mientras que en el mtodo
SegundoMetodo() solamente podrn acceder los administradores como roles.

Seguridad de aplicaciones web en servlets y jsp

Se utilizan las mismas tcnicas de seguridad que para el caso de los Enterprise Beans:
Declaracin de roles de seguridad.
Declaracin de requerimientos de seguridad

Tambin se utilizan otras tcnicas especficas para el contenedor Web:

Restricciones de seguridad.
Conexiones seguras.
Mecanismos de autenticacin especficos.

Para poder crearnos Roles de seguridad tenemos dos formas de realizar la accin:
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>
Tambin 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 cdigo del
servlet para la validacin
</security-role-ref>
</servlet>
Al igual que con los EJB, podemos realizar mapeos de nombres a grupos, pero se escribiran en el
descriptor de la aplicacin, 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 mtodos para implementar sobre la interfaz HttpServletRequest
que nos permiten el acceso a la informacin de seguridad:

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 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
aplicacin:
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)
throws ServletException, IOException {
processRequest(request, response);
}

@Override
protected void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
processRequest(request, response);
}
}

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 123

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Ver Video: Implementando Seguridad, en la Unidad 8,
en el Mdulo 10, en la plataforma elearning

Laboratorio: Uso de Criptografa 124

Objetivos
Comprobar el funcionamiento de la criptografa dentro del entorno de Java.
Aprender a cifrar y descifrar mensajes mediante la criptografa simtrica en aplicaciones
Java.

Enunciado
En este laboratorio realizaremos una aplicacin grfica de swing en la que cifraremos el contenido de
un texto mediante un password y lo descifraremos posteriormente.
El mtodo de encriptacin se realizar mediante base 64, por lo que escribiremos los bytes de la
encriptacin dentro de un fichero para, posteriormente, leerlos y desencriptarlos.
Dicha encriptacin nos permitira guardar los datos en cualquier tipo de soporte para bytes[], por lo
que sera muy til tambin para encriptar datos en Bases de datos.
Comenzaremos crendonos un nuevo proyecto Java Java Application en NetBeans.

Llamaremos al proyecto ProyectoEncriptacion

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Sobre el proyecto seleccionaremos un nuevo elemento:

125

Y sobre la carpeta Formularios de Interfaz grfica Swing, seleccionamos un Formulario JFrame:

Le pondremos el nombre FormularioSeguridad y lo incluimos en un paquete llamado pk_seguridad.

Este es el diseo de nuestro proyecto:

A continuacin, realizaremos el siguiente diseo en la ventana del JFrame:

Controles del formulario (sin las etiquetas descriptivas):

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 126

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
JTextField txttexto
JTextField txtpass
JButton btncifrar
JButton btndescifrar
JTextArea txtresultado

127

A continuacin, debemos implementar nuestro cdigo por pasos.

Lo primero ser importar el espacio de nombres:
import javax.crypto.*;
Nuestra aplicacin utilizar un password para poder encriptar y desencriptar los datos, por lo que
debemos crearnos un mtodo 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;
}catch (Exception ex)
{
JOptionPane.showMessageDialog(this, ex.toString());
return null;
}
}
Ahora nos crearemos un mtodo 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 encriptacin.
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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 }catch (Exception ex)
{
JOptionPane.showMessageDialog(this, ex.toString());
return null;
}
}
A continuacin, debemos crearnos un mtodo que se encargar de escribir los datos binarios del
array byte[] dentro de un fichero. 128
Dicho mtodo nos permitira, 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();
}catch (Exception ex)
{
JOptionPane.showMessageDialog(this, ex.toString());
}
}
Ahora ya podemos implementar el cdigo del ActionPerformed del botn de Cifrar.
Para ello, en el diseador del JFrame, pulsamos dos veces sobre el botn de Cifrar y nos mostrar el
siguiente cdigo:
private void btncifrarActionPerformed(java.awt.event.ActionEvent evt) {
}
Ah implementaremos el cdigo que nos permitir cifrar el texto mediante un password y poder
escribir el resultado en un fichero.
El cdigo 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));
}catch (Exception ex)
{
JOptionPane.showMessageDialog(this, ex.toString());
}
}
A continuacin, debemos implementar los elementos para desencriptar el mensaje que hemos
almacenado en un fichero.
Nos crearemos un mtodo 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 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();
}catch (Exception ex)
{
JOptionPane.showMessageDialog(this, ex.toString());
return null;
}
}
Ahora que ya tenemos todo el cdigo para leer los bytes[] que deseamos desencriptar, pulsaremos
dos veces sobre el botn Descifrar y escribiremos el siguiente cdigo:
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));
}catch (Exception ex)
{
JOptionPane.showMessageDialog(this, ex.toString());
}
}
Ya podremos probar nuestra aplicacin y comprobar su funcionamiento:
Cuando pulsemos sobre Cifrar:

Y si utilizamos la misma clave, podremos comprobar que descifrar el texto correctamente:

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 130

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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Unidad 9. Arquitectura de software

Introduccin
La arquitectura de software es, independientemente del lenguaje con el que se implemente:
Un diseo de alto nivel. 131
La estructura del sistema.
Los componentes de un programa o sistema, sus relaciones, los principios que gobiernan su
diseo y su evolucin en el tiempo.
Componentes y conectores.
Componentes, conectores, configuracin y restricciones.
Estructura del sistema

La Arquitectura de Software es la organizacin fundamental de un sistema encarnada en sus

componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseo y
evolucin.
La primera actividad del diseo de la arquitectura de un sistema de software es definir un conjunto
de sub-sistemas que componen el sistema completo.
Una primera aproximacin 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 visin general del sistema usando pocos componentes.
Las caractersticas 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 crticos al comienzo de
cualquier desarrollo).

La arquitectura tiene un impacto relevante ya que se detectan las partes ms crticas 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 diseo 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 diseo.
Captura la experiencia probada de diseo de software.
Describen problemas recurrentes que surgen en determinados contextos.
Describen esquemas de soluciones probados. Herramientas para los no expertos.
Un patrn de arquitectura de software es un esquema genrico 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
dnde se vayan a aplicar.
Objetivos
Comprender el anlisis y la estructura de la arquitectura de software.
Su uso y desarrollo en los proyectos y su unin o diferenciacin 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 configuracin, estilo,

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 restricciones, semntica, anlisis, propiedades, racionalizaciones, requerimientos,
necesidades de los participantes.
El trabajo en esta rea, est caracterizado por el desarrollo de lenguajes de descripcin
arquitectnica (ADLs).
Modelos de framework
Son similares a la vista estructural, pero su caracterstica principal radica en la estructura
coherente del sistema completo, en lugar de concentrarse en su composicin.
Los modelos de framework a menudo se refieren a dominios o clases de problemas 132
especficos.
El trabajo que ejemplifica esta variante incluye arquitecturas de software especficas de
dominios, como CORBA, o modelos basados en CORBA, o repositorios de componentes
especficos.
Modelos dinmicos: Enfatizan la cualidad conductual de los sistemas.
La palabra dinmico puede referirse a los cambios en la configuracin del sistema, o a la
dinmica involucrada en el progreso de la computacin, tales como valores cambiantes de
datos.
Modelos de proceso
Se concentran en la construccin de la arquitectura, y en los pasos o procesos involucrados
en esa construccin.
En esta perspectiva, la arquitectura es el resultado de seguir un argumento (script) de
proceso.
Esta vista se ejemplifica con el actual trabajo sobre programacin de procesos para derivar
arquitecturas.
Modelos funcionales
Una minora considera la arquitectura como un conjunto de componentes funcionales,
organizados en capas que proporcionan servicios hacia arriba.
Podramos pensar en esta visin 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 investigacin 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 construccin.
Tomadas en su conjunto, destacan como una especie de elementos conjuntos que se separan en
capas.
Ms all de que existen numerosos conceptos en el plano detallado de las tcnicas y metodologas,
la arquitectura de software se desarrolla alrededor de unos pocos conceptos y principios esenciales y
unas pocas herramientas caractersticas.
La arquitectura de software es el primer paso en la produccin de un diseo 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 habrn de implementarla.
La descripcin arquitectnica incluye componentes y conectores (en trminos de estilos) y la
definicin de operadores que crean sistemas a partir de subsistemas o, en otros trminos,
componen estilos complejos a partir de estilos simples.

2) Diseo del cdigo.

Comprende algoritmos y estructuras de datos.
Los componentes son elementos primitivos del lenguaje de programacin, tales como
nmeros, caracteres, punteros e hilos de control.
Tambin existen operadores primitivos.

3) Diseo ejecutable.
Remite al diseo de cdigo a un nivel de detalle todava ms bajo y trata cuestiones tales
como la asignacin de memoria, los formatos de datos, etc.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 133

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Estilos Un estilo es un concepto descriptivo que define una forma de articulacin u organizacin
arquitectnica.
El conjunto de los estilos cataloga las formas bsicas posibles de estructuras de software, mientras
que las formas complejas se articulan mediante composicin 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 sita en un
orden de discurso y de mtodo que el modelado orientado a objetos en general, y UML en particular,
no cubren satisfactoriamente. 134
La descripcin de un estilo se puede formular en lenguaje natural o en diagramas, pero lo mejor es
hacerlo en un lenguaje de descripcin arquitectnica o en lenguajes formales de especificacin.
A diferencia de los patrones de diseo, los estilos se ordenan en seis o siete clases fundamentales y
unos veinte ejemplares, como mximo.
Las arquitecturas complejas o compuestas resultan de la composicin de estilos ms bsicos.
Algunos estilos tpicos son las arquitecturas basadas en flujo de datos, las peer-to-peer, las de
invocacin implcita, las jerrquicas, las centradas en datos o las de intrprete-mquina virtual.

Lenguajes de descripcin arquitectnica

Los lenguajes de descripcin de arquitecturas, o ADLs, ocupan una parte importante del trabajo
arquitectnico desde la fundacin de la disciplina.
Se trata de un conjunto de propuestas de variado nivel de rigurosidad, casi todas ellas de extraccin
acadmica, que fueron surgiendo desde comienzos de la dcada de 1990 hasta la actualidad, ms o
menos en contemporaneidad con el proyecto de unificacin de los lenguajes de modelado bajo la
forma de UML.
Los ADLs permiten modelar una arquitectura mucho antes que se lleve a cabo la programacin de
las aplicaciones que la componen, analizar su adecuacin, determinar sus puntos crticos 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 an quienes los utilizan como
instrumento en el diseo arquitectnico de sus proyectos.

Frameworks y Vistas
Existen unos organismos de estndares (ISO, CEN, IEEE, OMG) que han codificado diferentes
aspectos de la arquitectura de sofware, con el objetivo de homogeneizar la terminologa, los
modelos y los procedimientos.
Los elementos que forman estos estndares son una serie de especificaciones y recomendaciones.,
Los marcos arquitectnicos, como las metodologas de modelado de los organismos, acostumbran
ordenar las diferentes perspectivas de una arquitectura en trminos de vistas (views).
Una vista es un subconjunto resultante de practicar una seleccin o abstraccin sobre una realidad,
desde un punto de vista determinado.
La estrategia de arquitectura de software utilizando vistas define, cuatro vistas principales,
ocasionalmente llamadas tambin arquitecturas: Negocios, Aplicacin, Informacin y Tecnologa.
La vista de aplicacin 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 organizacin.
Planes para el desarrollo de nuevas aplicaciones y la revisin de las antiguas, basados en los
objetivos de la empresa y la evolucin de las plataformas tecnolgicas.

La divisin de los diferentes escenarios que supeditan toda la arquitectura de software es la siguiente:
Arquitectura como etapa de ingeniera y diseo orientado a objetos.
Es un modelo estrechamente asociado al entorno de UML y Rational.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 La arquitectura se restringe a las fases iniciales y preliminares del proceso y concierne a los
niveles ms elevados de abstraccin, pero no est sistemticamente ligada al requerimiento
que viene antes o a la composicin del diseo que viene despus.
Lo que sigue al momento arquitectnico es business as usual, y a cualquier configuracin,
topologa o morfologa de las piezas del sistema se la llama arquitectura.
En este tipo, se reconoce el valor primordial de la abstraccin y del ocultamiento de
informacin como concepto de encapsulacin en clases y objetos.
Importa ms la abundancia y el detalle de diagramas y tcnicas disponibles que la 135
simplicidad de la visin de conjunto.
Cuando aqu se habla de estilos, se los confunde con patrones arquitectnicos o de diseo.
La definicin 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 cdigo.
Arquitectura estructural, basada en un modelo esttico de estilos, ADLs y vistas.
Utiliza el ms alto nivel de abstraccin, y adems no tiene por qu coincidir con la
configuracin explcita de las aplicaciones.
No se suelen encontrar referencias a los lenguajes de programacin o piezas de cdigo, y en
general, nadie habla de clases o de objetos.
Estructuralismo arquitectnico 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 situacin.
Arquitectura basada en patrones.
Este tipo de arquitectura est claramente diferenciada de la tendencia a diagramas de UML.
Utiliza modelos de proceso tcticos.
El diseo consiste en identificar y articular patrones preexistentes, que se definen en forma
parecida a los estilos de arquitectura.
Arquitectura procesual.
Su funcin principal es establecer modelos de ciclo de vida y tcnicas de requerimientos,
diseo, anlisis, seleccin de alternativas, validacin, comparacin, estimacin de calidad y
justificacin econmica especficas para la arquitectura de software.

Arquitectura basada en escenarios.

Es modelo ms novedoso.
Utiliza la unin de la arquitectura de software con los requerimientos y la funcionalidad del
sistema, ocasionalmente borroso en la arquitectura estructural clsica.
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 estn orientados a objetos.
Para que una arquitectura tenga unos atributos de calidad debe tener las siguientes caractersticas:

La arquitectura de software debe cubrir una serie de requisitos mnimos para poder involucrar todo
un desarrollo de anlisis:
Los individuos y las interacciones por encima de los procesos y las herramientas
El software que funciona por encima de la documentacin exhaustiva
La colaboracin con el cliente por encima de la negociacin contractual

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 La respuesta al cambio por encima del seguimiento de un plan

Una de las herramientas ms importantes y utilizadas para los desarrollos es el propio UML, que
permite crear diagramas de objetos y su interaccin entre ellos.
En el campo del software, la arquitectura nos identifica los elementos ms importantes de un
sistema as como sus relaciones, es decir, nos da una visin global del sistema.
Generalmente, las metodologas de desarrollo indican principios para identificar y disear una
arquitectura, aunque por ahora la ayuda real que ofrecen es muy limitada al basarse en principios 136
muy genricos.
Las arquitecturas software no responden nicamente a requisitos estructurales, sino que estn
relacionadas con aspectos de rendimiento, usabilidad, reutilizacin, restricciones econmicas y
tecnolgicas, e incluso cuestiones estticas.
Actualmente existen muchas metodologas de desarrollo de software, desde mtodos muy pesados
y burocrticos, mtodos ajustables al proyecto y a las condiciones de desarrollo, hasta mtodos
ligeros que surgen como respuesta a los excesos formales de otros mtodos.
Evidentemente, partiendo de los principios de tantas y diversas metodologas es muy difcil sacar
una visin unificada sobre el diseo arquitectnico.
Es difcil 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 disea una arquitectura base y el
segundo la altsima dependencia que definen entre los casos de uso y la arquitectura, definiendo un
caso de uso como una interaccin (secuencia de acciones) tpica entre el usuario y el sistema.

Desde un punto de vista arquitectnico, no todos los casos de uso tienen la misma importancia,
destacando aquellos que nos ayudan a mitigar los riesgos ms importantes y sobre todo aquellos
que representan la funcionalidad bsica 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 bsicos.
Este conjunto de especificaciones nos permiten validar la arquitectura con los clientes y los
desarrolladores, y asegurarnos que es adecuada para implementar la funcionalidad bsica deseada.
A partir de aqu, lo normal sera desarrollar de forma iterativa el sistema hasta tenerlo
funcionalmente completo.
Una visin alternativa sera 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 metodologa tradicional de desarrollo y arquitectura de software permite una serie de
caractersticas:
Centralizar los aspectos en parte del problema (el dominio del problema, sus requisitos y su
microestructura), obviando cuestiones como rendimiento, seguridad, protocolos de
comunicacin, restricciones de hardware, software, y econmicas, etc.
Proporciona una visin 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 nmero de pginas, es til desarrollar
un sistema basado en plantillas Xslt (por ejemplo), por la disminucin de costes de mantenimiento
que ello implica.
Esto es algo que ningn requisito funcional nos dara, y que probablemente tampoco surgira de
forma natura' en los modelos de diseo.
A este tipo de soluciones (patrones de diseo) se llega por la experiencia en el desarrollo de
sistemas web y por el conocimiento de las tecnologas existentes en el mercado.
Gracias a esta experiencia, desde el inicio del desarrollo de una aplicacin, podemos buscar
componentes que implementen estas tecnologas o ciertas funcionalidades, y por lo tanto integrar la
bsqueda de componentes y su uso dentro del proceso de desarrollo de software.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
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 metodologas que gestionen de forma directa las cuestiones arquitectnicas y estructurales,
podrn producir no solo productos de mayor calidad, sino a un menor coste y en menos tiempo. 137
Esto se debe a que los riesgos arquitectnicos del proyecto son menores y estn mucho mas
controlados, y que al poder integrar una visin 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 basndose 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 especificacin 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 especfico".
El objetivo de los patrones de diseo es el de capturar buenas prcticas que nos permitan mejorar la
calidad del diseo de un sistema, determinando elementos que soporten roles tiles en dicho
contexto, encapsulando complejidad, y hacindolo ms flexible.

Por otro lado, con frecuencia se dice que la funcin 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 razn por la que los sistemas con objetivos similares comparten tambin, una arquitectura
comn, unos procesos bien definidos, y un conjunto de elementos similares (patrones de diseo).
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 solucin a un conjunto de casos de uso, e interacciones con actores especficos.
Adems constituyen tambin un marco conceptual en el diseo de la arquitectura de nuestros
sistemas, ya que como la funcin define a la forma, sintetizan por lo general soluciones
arquitectnicas 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 bsicos
expuestos por el cliente, comprender la arquitectura del sistema a construir as como su
problemtica, 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 diseo arquitectnico.
Un lenguaje de patrones que modele un tipo de sistema debe de ser descrito incluyendo la siguiente
informacin:
Caractersticas bsicas que lo definen y diferencian. Por ejemplo, un sistema web se
caracteriza por clientes ultra ligeros, o uso de protocolos sin estado, o centralizacin del
software de ejecucin en servidores de tal forma que la aplicacin es compartida por todos
los usuarios.
Definicin de los actores principales que participan en dicho sistema as como sus casos de
uso bsicos, descritos evidentemente de forma genrica.
Especificacin de los principales componentes funcionales del sistema as como las relaciones
entre ellos.

www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
 Arquitectura lgica y flujos de informacin, que estructuran los diferentes subsistemas, el
intercambio de informacin de los mismos, etc. Por ejemplo, arquitecturas reflexivas,
modelo-vista-controlador, etc.
Arquitectura de componentes. Consiste en mapear los componentes funcionales en la
arquitectura lgica de la aplicacin.
Arquitectura fsica. Especificacin del despliegue de los componentes.
138
Estos lenguajes deberan, adems, tener una visin orientada a la construccin 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,

en el Mdulo 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
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.