Modulo 1 java ee platform

2015 ByWind Software – Lic. Roberto Marchena
Java EE Platform
Basado en el curso “Developing Applications for the Java EE 6
Platform (FJ-310-EE6)” del Oracle Java and Middleware Training

Java EE Platform
Temario
 01.- Introducción
 02.- Java EE Component Model
 03.- Web Component Model
 04.- Servlets
 05.- JavaServer Pages (JSP)
 06.- EJB Component Model
 07.- EJB 3 Session Beans
 08.- Java Persistence API (JPA)
 09.- Java Transaction API (JTA)
 10.- Message-Driven Beans
 11 .-Web Services Model
 12.- Security Policies

01.Introducción
Java Language roadmap
 1995 - JDK Alpha and Beta - Sun Microsystems
 Enero 1996 – JDK 1.0
 Febrero 1997 - Microsoft Visual J++ (MSJVM)
 Febrero 1997 - JDK 1.1 - JavaBeans | JDBC | RMI | reflection | JIT compiler
 Marzo 1998 - EJB 1.0 – Especificación para construir Enterprise Applications
 Diciembre 1998 - J2SE 1.2 - Java 2 Platform (J2SE, J2EE, J2ME) | Swing | Java IDL | Collections
 Diciembre 1999 – EJB 1.1 - XML deployment descriptors | RMI over IIOP | Entity Bean support
 Mayo 2000 - J2SE 1.3 - Compatibilidad RMI con CORBA | JNDI
 Agosto 2001 – EJB 2.0 - Standard component architecture | components from different vendors (Write Once, Run Anywhere)
 Febrero 2002 - J2SE 1.4 - Primera edición desarrollada bajo el JCP | logging API | integrated XML parser | integrated security and
cryptography extensions | Java Web Start included
 Febrero 2002 – Microsoft Visual J# (última release .NET. Visual Studio 2005)
 Noviembre 2003 – EJB 2.1 - Web service support | EJB timer service
 Septiembre 2004 - J2SE 5.0 - Metadata | Enumerations | Varargs | Enhanced For Each
 Mayo 2006 – EJB 3.0 – Facilidad escribir EJBs usando 'annotations' en lugar de complejos 'deployment descriptors'
 Diciembre 2006 - Java SE 6 Java Platform (Java SE, Java EE, Java ME) | Scripting Language Support | Improved Web Service
support through JAX-WS | JDBC 4.0 support | Java FX | Security fixes
 Abril 2009 - Oracle compra a Sun Microsystems
 Diciembre 2009 – EJB 3.1 - Local view without interface | .war packaging of EJB components | Singletons (Singleton Session Beans)
 Julio 2011 - Java SE 7 - JVM support for dynamic languages | Security fixes
 Mayo 2013 . EJB 3.2 – Minor release
 Marzo 2014 - Java SE 8 - Lambda Expressions | Improve the Java security model | Date and Time API
 2015 - Java 9 - Big data | multi-language interoperability | cloud | mobile
 2017 - Java 10 – Aun se encuentra en disusión | unified type system turns everything into objects (no more primitives)

01.Introducción
Java EE
•Java EE applications
• large-scale
• multi-tiered
• scalable
• reliable
• secure network
•Distributed components
Java EE Infraestructure Technologies
Java EE Technology Suite
Java Technology Platforms

01.Introducción
Java EE layers
•Bussines Logic components
•Container services
• Deployment-based services
• Persistence
• Transaction
• Security
• API-based services
• Naming
• Messaging
• Connector
• Inherent services
• Life-Cycle
• Threading
• Remote object communication
• Vendor-specific
• Scalability
• Failover
• Load balancing
•Platform services
•Java DataBase Connectivity (JDBC)
•Java Naming and Directory Interface (JNDI) API
•RMI over Internet Inter-Object Broker (ORB) Protocol
(IIOP)
•JavaMail API
•Java EE Connector Architecture (JCA)
•Java Message Service (JMS) API
•Java Transaction API (JTA)
•Java Authentication and Authorization Service (JAAS)
•Java API for XML Processing (JAXP)
•Web services integration (XML-based RPC and
messagning operations)
•Simple Object Access Protocol (SOAP)
•Attachment API for Java (SAAJ)
•Java API for XML Registries (JAXR)
•Java API for XML Web Services (JAX-WS)
•Java Management Extensions (JMX)
•Timer services
•Java Persistence API (JPA)

01.Introducción
n-Tier Model (1)
Java EE EJB Component-Centric Architecture
Java EE Web-Centric Architecture
Java EE Application Mapped to the n-Tier model

01.Introducción
n-Tier Model (2)
B2B Application Architecture
Java EE Web Service Architecture

01.Introducción
Java Patterns
•Java EE Patterns (principios arquitectura)
• Presentation Tier
• View Helper
• Front Controller
• Business Tier
• Service Locator
• Session Facade
• Transfer Object
• Integration Tier
• Data Access Objects (DAO)
• Domain Store
•Java EE BluePrints
• Java Pet Store application
• AJAX
• Web Services
• Naming and Project conventions
• etc.
•GoF Patterns (principios diseño)
• Creational
• Factory Method
• Abstract Factory
• Singleton
• Structural
• Facade
• Proxy
• Adapter
• Bridge
• Composite
• Decorator
• Behavioral
• Strategy
• Command
• Iterator
• Observer
• Mediator
Using Java EE Patterns

02.Java EE Component Model
Java EE Components
Java EE Components
•Principios
• La especificación EJB se diseñó
para soportar componentes de
diferentes vendedores
• Los componentes EJB se pueden
crear sin conocer el ambiente en el
que se ejecutarán
• Los componentes EJB son “Loosely
coupled”
• Fácil de testear
• Fácil de reusar
•Características
• Los componentes pueden tener un
estado
• Tienen propiedades (métodos
accessor / mutator)
• Encapsulación por el contenedor
• Una estricta separación entre las
intefaces y su implementación
• Soportan interacción local y remota
con otros componentes
• Location transparency

Encapsulated Components
Encapsulated Components
•El container
• Encapsula los componentes
• Controla su ciclo de vida
• Aisla los componentes de otros
componentes y del entorno
•Interfaces como contratos
• Un componente puede interactuar
con otro únicamente a través de su
interface
• Incluso los componente que se
ejecutan en una misma JVM
•Interacciones locales y
remotas
• Permite especificar cuales
componentes pueden accederse en
forma local, remota o ambas
• Interacción local ambos
componentes usan la misma JVM
• Para una interacción remota se
utiliza RMI

Local vs. Remote invocations
Distributed Components and RMI
•El protocolo IIOP
• El protocolo RMI se ejecuta sobre
IIOP que es parte de la
especificación CORBA
•En interacciones locales
• Los argumentos que se pasan entre
componentes comparten el mismo
espacio de memoria
• Los argumentos pueden ser
modificados por el componente
destino
• Tanto el origen como el destino ven
la misma instancia del argumento
•En interacciones remotas
• Los argumentos se pasan copiando
su estado
• Los argumentos se serializan para
transferirlos a través de la red
• Excepción cuando los argumentos
son en si mismo componentes
distribuibles porque pasan su stub

Location Transparency
•Es uno de los objetivo en el diseño de la plataforma Java EE
•Se puede hacer el deploy de un componente en más de un servidor con
los siguientes beneficios:
• Load balancing: Las llamadas pueden hacerse en forma circular entre ditintos servers para distribuir la
carga
• Faut tolerance: En caso de falla de un servidor se puede redireccionar a otro servidor

Naming Services
Locations transparency / Naming Service Java
Naming and Directory Interface(JNDI)
•Permite a un componente
obtener una referencia a otro
componente
•El contenedor provee sus
componentes a través de un
repositorio central donde los
componentes son accesibles por
su nombre
•Java EE usa la JNDI API como
servicio de búsqueda
• Conexiones con bases de datos
relacionales
• Conexiones con servicio de mensajes
• Destino de mensajes
• Conexiones con legacy systems que usan
adapters
•Se puede utilizar Dependency
Injection para localizar
componentes que maneja el
servidor como EJBs, Servlets y
JSPs
Performing a Lookup Operation
Dependency Injection as an alternative to
Lookups

Asynchronous Communication
Asynchronous Component-to-Component
Asynchronous Messaging with JMS
•Synchronous vs. Asynchronous
• Operaciones sincrónicas Request-Response
se caracterizan porque el cliente se bloquea
hasta tanto recibe la respuesta
• En operaciones asincrónicas Request-
Notification el cliente hace una solicitud y
continúa procesando y luego recibe una
notificación más tarde
• Las operaciones asincrónicas reducen el
acoplamiento entre componentes
• Para operaciones asincrónicas los
componentes usan la JMS API para enviar
mensajes y los Message-driven beans actuan
como consumidores de mensajes
•Ventajas operaciones asincrónicas:
• Reducen el acoplamiento entre componentes
• Permiten realizar operaciones que toman
tiempo en completarse
•Desventajas operaciones
asincrónicas:
• Requieren una infraestructura más compleja
• Uso menos eficiente de los recursos de red

Desarrollo aplicaciones Java EE
•Java EE Roles
• Application component provider
• Application assembler
• Developer
• System administrator
• Tool provider
• Product provider
•Steps for deploying a Java
EE Application
• Designing
• Coding
• Creating deployment descriptors
• Packing
• Assembling
• Deployment
Java EE Application Development Process

Packing Java EE Applications
•Tipos de archivos utilizados para
distribuir aplicaciones Java EE
• Web archive (WAR) files
• Java Archive (JAR) files
• Resource archive (RAR) files
• Enterprise archive (EAR) files
Web Archive File (.war)
EJB JAR file contents
EAR file contents

03.Web Component Model
Introducción
•Objetivos del Web-tier
• Generar contenido dinámico en diferentes formatos
content-type
• HTML page – text/html
• XML document – text/xml
• Image in JPEG format – image/jpeg
• Obtener y validar información de la interfaz del usuario y
retornar una respuesta adecuada del business-tier
• Controlar el flujo de pantallas o páginas en el cliente
• Mantener el estado de los datos de la sesión del usuario
• Resolver lógica básica y mantener algunos datos en
forma temporal
•Web-Tier Java EE Technologies
• Servlets
• JavaServer Pages (JSP)
• Web-Tier frameworks: JavaServer Faces (JSF), Struts,
etc.
HTTP protocol Request-Response Model
Life Cycle of a Web Component

Hello World Servlet

Hello World JSP

Servlets and JSP Components
•Servlets JSP collaboration
• Servlets para manejar request
processing
• Servlets intecatúan con la lógica del
negocio recopila datos amostrar
• JSP components para visualizar los
datos al cliente
Model View Controller (MVC) architecture
Web-Tier Decoupled from Business Logic

Hello World JSF

04.Servlets
Introducción
Servlet API
Request Handling Methods
A basic web.xml Deployment Descriptor
Servlet Live Cycle Methods

04.Servlets
Request and Response APIs
•Request y Response APIs
• Obtener datos
• Pasar datos de un componente a otro
• Obtener información de seguridad
• Generar una salida o respuesta
•Métodos objeto Request
• getParameter
• setAttribute / getAttribute
• getRequestDispatcher
•Métodos objeto HttpServletRequest
• getUserPrincipal
• getCookies
• getSession
•Métodos objeto Response
• getOutputStream
• getWriter
• setContentType
•Métodos objeto HttpServletResponse
• encodeURL
• addCookie
• sendError
•RequestDispatcher Interface
•Métodos RequestDispatcher
•forward (típico para controllers)
•include (típio para views)
•Transferir datos en el objeto Request

04.Servlets
Session Management API
•Session management API
• Determina cuando una sesión ha sido creada
• Hace posible al server identificar el cliente
• Agrega un named item a una sesión
• Obtiene un named item de una sesión
• Despues de autenticarse el Id y estado del usuario
son parte de la sesión
• Manejo de Session Timeout
• Cierra una sesión
Java EE Platform Web-Tier Session Management
Retrieving a Session Object
Invalidating a Session

05.JavaServer Pages (JSP)
Introducción
•Características
• Extensión .jsp
• La tecnología JSP está basada en “Write Once,
Run Anywhere” y puede correr en cualquier
navegador web
• Describen como procesar un Request y crear
un Response (front-end access)
• Además de elementos estáticos (HTML o XML)
contienen elementos JSP
• Los componentes que usa o accede se basa
en la arquitectura JavaBeans
• Usa beans para interactuar con los servidores
del lado del servidor
• Proveen acceso al conjunto completo de Java
APIs
• Son componentes basados en el modelo
Servlet y tienen el mismo comportamiento
• Al compilarse y ejecutarse como Servlets
tienen beneficios similares a los CGIs
•Worker Beans, JSTL y Custom Tags
• Incoporan clases y el JavaServer Pages
Standard Tag Library (JSTL) usando el tag
<jsp:useBean>
• El uso de Custom Tag Libearies permite la
reutilización de código
JSP Page Translation Procedure

Componentes
•Directive Types:
• page
• include
• taglib
JSP Page Components
JSP 2.1 soporta XML tags

page include Directives
JSP page Directives
JSP include Directive

Declarations and Expressions
•Declarations
• Se usa para declarar variables y métodos que se
pueden usar dentro de la página
•Expressions
• El contenedor JSP evalúa la expresión en runtime
• El contenedor JSP automáticamente convierte la
expresión a String

Scriptlets
•Scriptlets
• Bloques de código que tiene acceso full a Java API
• El contenedor JSP inserta los scriptlets sin
modificación
JSP to Servlet translation

jsp:useBean Action
jsp:useBean Scopes
•jsp:useBean action
• Se usa por lo general para compatir
información entre Servlets y páginas JSP
usando un scope request
• Los Servlets en general atienden las solicitudes
del front-end y redireccionan el resultado
usando páginas JSP
• En general se establecen los atributos en los
Servlets y jsp:useBean se usa para obtener los
datos

jsp:getProperty Action
jsp:getProperty Action
•El estilo XML para usar,
modificar, o crear objetos

JavaServer Pages Standard Tag Library (JSTL)
URI Prefijo Descripción
http://java.sun.com/jsp/jstl/core c core library
http://java.sun.com/jsp/jstl/xml x XML processing library
http://java.sun.com/jsp/jstl/fmt fmt I18n formatting library
http://java.sun.com/jsp/jstl/sql sql SQL library
http://java.sun.com/jsp/jstl/functions fn EL functions
•Java EE provee varios tags.
•Estas librerías se agrupan por funcionalidades
•Ejemplo

Expression Language (EL)
•Pueden combinarse con JSP libraries para evitar tener que usar scriptlets.
•Ejemplos:

Custom Tag Libraries
/WEB-INF/tags/message.tag
•Los Custom Tags permiten extender el set de tags que el contenedor JSP
puede interpretar
•Ejemplo:

06.EJB Component Model
Introducción
•EJB Components
• Distributed
• Scalable
• Transactional
• multi-user
• secure
•Tipos de EJB
• Session EJB components
• Stateless
• Stateful
• Message-Driven Beans
• Entity EJB components (*)
•Un container puede también contener
• Java Persistence API (JPA) entity classes
• Object Relational Mapping (ORM)
• Otras helper o utility classes
•EJB Timer Service
• At a specific time
• After a specific elapsed duration
• At specific reucrring intervals
EJB Application Tiers

06.EJB Component Model
EJB Container
•El modelo usa contenedores para
encapsular componentes usando intefaces
base:
• EJBContext
• SessionContext
• MessageDrivenContext
•Funciones de un EJB Container:
• Provee proxies que limitan y controlan el acceso
• Encapsula el acceso a recursos externos y provee
servicios de connection pooling
• Maneja el ciclo de vida de las intancias de los
componentes EJB
• Aisla las clases que proveen la implementación del cliente
• Provee timer services
• Para message-driven beans el container monitorea la cola
de mensajes
EJB Container

07.EJB 3 Session Beans
Tipos de session beans
•Stateless Session Beans
• No retiene información específica del cliente
• El cliente podría no obtener la misma
instancia del session bean
• Una instancia de session bean puede
responder a varios clientes
•Stateful Session Bean
• El bean pertenece a un cliente en particular
• La conexión del cliente existe hasta que el
cliente remueve la instancia o finaliza por
timeout
• El container mantiene objetos EJBs e
instancias EJB separados para cada cliente
• Requieren más memoria por cliente que un
stateless session bean
Stateless Session Beans
Stateful Session Beans

Crear un Session Bean
•Declarar las Business Interfaces para
el session bean
• Local interface (default)
• Remote interface
•Crear la clase para el session bean
que implementa la/s interface/s
•Configurar el session bean
• Anotations
• Deployment descriptor (ejb-jar.xml)
•Packaging and Deploy
Session Beans Local interface
Session Beans class

Crear un cliente local
•El cliente se ejecuta en
la misma JVM
•Usa injetion services del
container
•@EJB trabaja con:
• Otros EJBs manejados por el
mismo container
• JSF Managed Beans
• Servlets
• Enterprise Application Client
alojada en el mismo
container

Crear un cliente remoto
•El cliente se ejecuta en
otra JVM
•Usa JNDI naming
services para obtener
una referencia al bean

Life-Cycle Event Handlers
•Callback methods:
• PostConstruct
• PreDestroy
• PostActivate
• PreActivate
•Un mismo método puede
manejar varios callbacks
•Un callback puede tener
asignado un único método
•Una excepción en un
callback method causa un
Rollback
Lyfe Cycle of a Session Beans
Callback Method in Bean Class

SessionContext Object
•Uso del objeto
SessionContext para:
• Acceder objetos EJB
• Obtener el estado de la
transacción
• Obtener security
information
•SessionContext
extiende EJBContext

08.Java Persistence API (JPA)
Introducción
•Concepto de persistencia
•La Java Persistence API
(object / relational mapping)
•Tipo persistencia de un
contenedor EJB
• Container-Managed Persistence
(EJB 2.1 CMP)
• Application-Managed Persistence
(EJB 2.1 BMP)
•JPA no requiere un
contenedor EJB
•Object Relational Mapping
(ORM) software
• Anotations
• xml configuration files
•Java Data Objects (JDO)
1-N Mapping of a Java Object to
Relational Tables
Entity Beans

Entity Class Requirements
•Declarar las Entity Classes
•Verificar y sobreescribir el mapeo
predeterminado
•Persistent Fields
• No pueden ser públicos
• No los puede acceder el cliente
• Tienen el keyword @Column
•Persistent Data Types
• Java primitives types
• Java wrappers
• java.lang.String
• byte[] / Byte[]
• char[] / Character[]
• Serializable Types
• java.util.Date
• java.util.TimeStamp
Object Tier to Database Tier elements

Components
•Persistence Unit
• Especifica las características del DataSource utilizado
• Define las clases que forman parte de la unidad de persistencia
• Es un agrupamiento lógico de todos los elementos que requiere el contenedor y es necesario para hacer el
deploy de Entity Classes
•Entity Manager
• Provee métodos para controlar un Persistence context
• Administra el ciclo de vida de las Entity instances
• Reemplaza gran parte de la funcionalidad de los Entity Beans de EJB 2.1
•Persistence context
• Todo Entity Manager se asocia a un Persistence context
• Es un conjunto de instancias de entidades
• Tipicamente tiene la duración de una transacción
• Pueden existir varios Persistence context usando la misma Persistence entity al mismo tiempo
•Persistence identity
• Es el valor unico que usa el contenedor para mapear una instancia de una entidad

Persistence Unit
Example of Persistence Unit Components
within an EJB-JAR
•Donde poner los elementos de un
Pesistence unit
• En un archivo EAR
• En un archivo EJB-JAR
• En un archivo WAR
• En un archivo JAR de una aplicación

transaction-type
JTA RESOURCE_LOCAL
El contenedor crea y administra el
EntityManager
El desarrollador es responsable de crear
y administrar el EntityManager
Se obtiene un EntityManager usando la
@PersistenceContext annotation
Usa el EntityManagerFactory para obtener un
EntityManager
No puede utiliar la @PersistenceUnit
annotation para hacer referencia a la unidad JTA
El EntityManagerFactory puede ser inyectado
usando la @PersistenceUnit annotation
Solamente se puede obtener un EntityManager
suministrado por el contenedor
No puede utilizar la @PersistenceContext
annotation y llamar al método
entityManagerFactory.createEntityManager
devuelve dos instancias de EntityManager y en
concecuencia a dos PersistenceContexts/Caches
Puede usar Declarative JTA Transactions Se debe usar los métodos begin/commit para
demarcar transacciones para usar el EntityTransaction
API
El PersistenceContext/Cache es flushed
y liberado con un JTA commit
El desarrollador es responsable de liberar los recursos
utilizados

transaction-type=JTA
persistence.xml
sun-resources.xml

transaction-type=RESOURCE_LOCAL

Entity Manager – Life-Cycle States
Entity Instance States and Entity Manager
Methods
•Callback anotations
• @PrePersist
• @PostPersist
• @PreRemove
• @PostRemove
• @PreUpdate
• @PostUpdate
• @PostLoad

Data Transfer Objects (DTOs)
•Ventajas
• Desacopla la lógica del negocio del cliente y la mantiene en la capa
del negocio, esta separación es un concepto clave en un buen
diseño.
• Reduce el tráfico de red en sistemas distribuidos, los objetos se
pasan al ciente en una única llamada remota
• Soluciona posibles problemas de tráficos con objetos que tengan
más datos que los requeridos (columnas que almacenan varios
bytes y relaciones eager).
• Mejora el rendimiento del cliente al eliminar cualquier necesidad de
montar el modelo de datos.
• El desarrollador del front-end del cliente no necesita conocer el
modelo de datos.
• Oculta el mapeo de la base de datos al cliente (data access tier) y
evita posibles problemas de seguridad.
• Evita la manipulación directa de los objetos que residen en la base
de datos desde la capa de presentación
•Contras
• La necesidad de crear las clases DTO además de las clases JPA, lo
que resulta en varios casos en duplicación de código o simplemente
escribir código extra.
• Al modificar la estructura de datos de la base de datos puede
requerir que además de modificar las clases JPA se tenga que
modificar las clases DTO y el código que copia los atributos del
objeto DTO al JPA y viseversa
Data Transfer Objects
Data Access Object (DAO) Pattern

Java Persistence Query Language (JPQL)
•Basado en SQL, permite escribir querys portables
•Diferencia con Native Query
•Diferencia con EJBQL
•Usa un esquema abstracto de entidades, incluyendo relaciones con otras
entidades de la misma Persitence Unit

JPQL Querys
createQuery example
Join example
Aggregate Functions example
Delete example
Update example

Native Querys
createNativeQuery example
Result in Object[]

Named Querys
createNamedQuery example
@NamedQuery example

09.- Java Transaction API (JTA)
Introducción
•Conceptos básicos
• Atomicity: Operaciones que se
ejecutan o fallan en conjunto
• Locking and isolation: Una sola
transacción puede actualizar una
dato al mismo tiempo
• Flat transaction model: Solo una
transacción tiene efecto en un
mismo thread en un momento
dado
•Transaction scope
• Begin point
• Commit / Rollback point
•Flat Transaction model
• El modelo que soporta Java EE
• No soporta subtransacciones
• Lo soportan todos los vendedores
de bases de datos
Example of Atomic Unit of Work
Effect of Locking on Multiple
Accesses to the Same Data

Local vs Distributed Transactions
Local = 1 DataSource Distributed = n DataSources

Programmatic vs Declarative Transactions (1)

Programmatic vs Declarative Transactions (2)
•Notas:
• De no especificar el tipo de
transaction-type se asume
Declarative
• Programmatic Transactions no
se pueden cambiar en
assembly time
• El contenedor no puede
manejar una combinación de
programmatic y declarative
transactions
Programatic – Bean-managed transactions (BMT)
Declarative – Container-managed transactions
(CMT)

Declarative Transactions Attributes
•@TransactionAttribute
define como el
contenedor administra la
transacción:
El método NO está en
una transacción
El método SI está en
una transacción
Container Interactions with the Transaction Manager

Locking and Versioning
•Tipos de bloqueos
• Pessimistic locking
• Bloqueos de filas o tablas por largos períodos de tiempo para
actualización
• Bloquea los datos cuando se leen y los desbloquea cuando todas las
actualizaciones se efectuaron
• Cuando más usuarios concurrentes mayor la posibilidad de bloqueos
• Optimistic locking
• Trata de evitar bloqueos por largos períodos de tiempo
• Los datos se pueden bloquear en la lectura o en la escritura, pero no se
mantienen bloqueados entre la lectura y la escritura
• Puede ocurrir que un usuario sobre-escriba los cambios de otro usuario
•Versionamiento
• La especificación JPA adiciona números de versiones para evitar
la sobre-escritura de datos cuando el desarrollador lo habilita
• Puede usar una columna integer para implementar
versionamiento
A Versioning Field in an
Entity Class

10.- Message-Driven Beans
Messaging systems
•Messaging systems
• Permite la comunicación
asincrónica
• Promueve las relaciones pear-
to-pear entre los componentes
de la aplicación
• Mantiene un alto grado de
anonimidad entre los
productores y consumidores de
mensajes
• Son escalables, confiables y
permiten una fácil integración en
redes heterogéneas
• Java EE incluye la JMS API
para implementar mensajería
•Java Message Service
(JMS) API
• Estandariza la forma de enviar
mensajes en Java
Enterprise Messaging System
JMS API

Messaging Models
•Point-to-Point
• Se basan en el concepto de una cola de mensajes
(Queue)
• Una Queue retiene los mensajes hasta que son
consumidos
• En general existe un único consumidor para cada
mensaje
• El cliente recibe todos los mensajes de la Queue, aun
los creados previos a la creación del consumidor
• La Queue elimina los mensajes que han sido leidos
exitosamente
• Si hay multiples consumidores solo un consumidor
puede leer cada mensaje
•Publish-Subscribe
• Se basa en el concepto de Message Topics
• El productor de mensajes publica los mensajes en un
tópico específico
• Los consumidores de mensajes se subscriben a
tópicos
• Un message-router redirecciona los mensajes a los
subscriptores de un topic
• El Topic retiene los mensajes hasta que ha sido
consumidos por todos sus subscriptores activos
• El consumidor solo recibe los mensajes que fueron
enviados después de su subscripción o mientras esté
activo
Publish/Subscribe Architecture
Point-to-Point Architecture

Synchronous and Asynchronous Messaging
Synchronous and Asynchronous comparison

Java Message Service (JMS) API
•Características:
• La JMS API estandariza la forma de enviar
mensajes en Java
• EL JMS API es un conjunto de interfaces
que el programador puede asumir que han
sido implementadas por un vendedor (JMS
provider)
• Un cliente JMS produce o consume
mensajes
• Los clientes JMS usan Connection
Factories para conectarse a un destino
JMS
Messaging System Participants

Messages
•Estructura de un mensaje:
• Header: Información estándar para
identificación y routeo del mensaje
• Properties: Pares de nombre/valor que
permiten filtrar los mensajes y
permiten la ineroperatividad con otros
sistemas de mensajes
• Body:Contiene el mensaje en uno de
los formatos estándar Message structure

Message-Driven Beans
•Características
• Los Message-Driven Beans fueron diseñados para
trabajar como consumidores asincrónicos de
mensajes
• El Bean implementa la interface MessageListener
• El desarrollador del bean es responsable de escribir
el método onMessage
• Los Message-Driven Beans no tienen interfaces local
ni remota
• Los clientes se comunican con el Message-Driven
bean enviando mensajes (queue o topic)
• Queue javax.jms.QueueConnectionFactory
• Topic javax.jms.TopicConnectionFactory
• Los Message-Driven bean son anónimos para los
clientes y no tienen un estado asociado a los clientes
• El contenedor puede crear un pool de múltiples
instancias de Message-Driven beans, y cuando un
mensaje arriba el contenedor elije la instancia
Client View of a Message-Driven Bean
Example of messaging

Message-Driven Beans Life Cicle
Message-Driven Bean Life Cycle
•Callback anotations
• @PostConstruct
• @PreDestroy

Send a message to a Queue
Send a message to a Queue example

onMessage example
Message-Driven Bean example

GlassFish JSM Connection Factory
JSM Connection Factory example

GlassFish JSM Destination Resourse
JSM Destination Resourse example

Additional message information
•JMS Message Selectors
• Permite identificar que tipo de
mensajes le interesan al
consumidor
• Basado en expresiones
condicionales de SQL92
• El filtro lo realiza el JMS
provider
•Acknowledge Mode
• Auto-acknowledge (default)
• Automáticamente realiza el
acuse de recibo si el cliente
retorna exitosamente por cada
mensaje
• Dups-ok-acknowledge
• Acuse de recibo en modo tardía
(cada n mensajes o n segundos)
• Posibilidad de duplicación del
mensaje en caso de pérdida de
comunicación
• Puede reducir la sobrecarga
minimizando la cantidad de
trabajo para prevenir mensajes
duplicados
Using message header message selectors
Setting message properties
Specifying message acknowledgement

11 .-Web Services Model
Introducción
•Definición
• Es un sistema de software diseñado para soportar el intercambio de datos entre aplicaciones sobre una
red basado en un conjunto de protocolos y estándares.
• Un Web Service expone servicios remotos a aplicaciones clientes.
•Características
• Plataforma independiente: No se requiere ningún tipo particular de CPU, sistema operativo, o tipos de
datos para intercambio.
• Diseñado para trabajar con diferentes tecnologías: Hace uso de XML y HTTP
• Interoperable con diferentes lenguajes de programación: Es posible que el server y el cliente estén
escritos en diferentes lenguajes de programación
•Comparación Web Services vs. EJBs remotos
• Utiliza UDDI (Universal Description, Discovery and Integration) para publicar y buscar servicios en lugar
de JNDI
• Utiliza un archivo WSDL (Web Service Description Language) para exponer la API del Web Service
• Utiliza SOAP (Simple Object Access Protocol) sobre HTTP como protocolo de transporte para invocar
operaciones y obtener resultados en lugar de IIOP
• Usa XML para serializar los objetos

Java API for XML Web Services (JAX-WS)
•La JAX-WS API es una especificación que permite la ejecución de
métodos remotos usando un esquema de mensajes basados en XML
•Características
• Reemplaza JAX-RPC (Java API for XML-based Remote Process Communications), que es la
especificación original para implementar Web Services en Java.
• Requiere un conocimiento mínimo o nulo de XML y WSDL
• Utiliza JAXB (Java Architecture for XML binding) para especificar como mapear tipos de datos usando
XML.
• Utiliza SAAJ (SOAP With Attachments API for Java) para enviar, recibir, y parsear mensajes SOAP
• Usar JAX-WS en el cliente o en el servidor no requiere que también se utilice del otro lado de la
conexión
•Web Service Endpoints
• Es un componente que se ejecuta en forma remota como resultado de recibir un mensaje SOAP de un
cliente y existen dos tipos:
• Componentes JAX-WS servlet
• Componentes stateless session beans

JAX-WS Servlet Endpoints
•Características
• Son multi-threaded
• No requieren un contenedor EJB
Servlet Endpoint example

JAX-WS EJB Endpoints
•Características
• En general es un session bean que también
se utiliza dentro de la aplicación
• Es una forma sencilla de dar acceso a otras
plataformas para invocar componentes EJB
• Requiere un contenedor EJB
EJB Endpoint example

Data Types
•Características
• Soporta los tipos de datos básicos de Java
• Para para pasar o retornar instancias de
objetos complejos se requiere cierta
programación usando JAXB
Using JAXB to convert Java object to / from XML
@XmlType annotation

Web Service Clients
•Para acceder a un web service el cliente JAX-WS necesita:
• Tener una copia del archivo WSDL que describe operaciones, argumentos y valores de retorno del Web
Service.
• Este archivo permite crear las interfaces del lado del cliente.
• Se puede generar y obtener el archivo WSDL utilizando las herramientas wsgen y wsimport del Java SDK.
• Para obtener el archivo WSDL desde GlassFish se puede usar el navegador Web usando un URL similar al siguiente
http://localhost:8086/CursoWebApp1/ServletWebService?WSDL
• La llamada al Web Service se hace a través de un port y un objeto local que actua como proxy para el
servicio remoto.
• El objeto proxy maneja la creación de mensajes SOAP y la comunicación HTTP
• En JAX-WS el objeto proxy es conocido como Port
Web Service Client example

12.- Security Policies
Introducción
•Java EE Security Model
• La principal tarea es definir roles y crear declarative security policy.
• Una policy que operaciones están permitidas para determinados grupos y usuarios.
• La security API se basa en un modelo de seguridad gestionado por el contenedor.
•Conceptos
• Authentication: El proceso de identificar el usuario.
• Authorization: Determinar si un usuario tiene permitido realizar una determinada operación.
• Confidentiality: Protección de los datos durante las transacciones. Técnica de public-key.
• Integrity: El proceso de asegurar que el dato recibido es el mismo dato que fue enviado.

End-to-End Security Model
•Características
• Una vez que se establece la
identificación del usuario para
un componente esa identidad
se propaga a otros
componentes
• Si un componente decide si el
usuario tiene permisos basado
en un security role, otros
componentes utilizan los
mismos security roles, dado
que los roles se propagan
entre contenedores
End-to-End Security Model

Container-Managed Security Model
•Características
• Si es necesario el contenedor
autentifica el usuario
• El contenedor verifica los permisos
del ciente para realizar la acción
solicitada
• Si la autorización es correcta el
contenedor invoca el código de la
aplicación.
Security Policy Enforced by Web Containers and EJB
Containters

Authentication
•Web Clients authentication
• HTTP basic: El browser un usuario y clave y le envía
esta información al servidor.
• Client certificate: El cliente envía un certificado
digital en respuesta a una solicitud por parte del
servidor.
• Form-based: El desarrollador controla el look and
feel del proceso de autenticación enviando forms
HTML.
•Web tier to EJB tier authentication
• El contenedor Web es responsable de pasar las
credenciales al cliente EJB.
•Non-Web Clients authentication
• Usar un contenedor para la aplicación cliente
Authentication in the Web Tier

Role-Based Security Model
•User roles y
responsabilidades
• La estructura de roles el plana (no
es jerárquica).
• Un usuario puede tener mas de un
role asociado.
• La forma de mapear los usuarios o
grupos a roles depende de la
plataforma específicica.
Role-Based Java EE Security Model

Role-Based Authorization
Role-Based Authorization in the Web Tier
Role-Based Authorization in the EJB Tier

Usar la Security API
Web-Tier Security API
EJB-Tier Security API

Security API Clients
HTML Login Page for Form-Based Authentication
HTTP Security and JAX-WS Clients

Modulo 1 java ee platform

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Modulo 1 java ee platform

Ähnlich wie Modulo 1 java ee platform (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (6)

Modulo 1 java ee platform

Hinweis der Redaktion