B3-T6_JEE Flashcards
¿Para qué se usa la clase “InitialContext” en una aplicación JEE?
Para poder recuperar del servicio de directorio (JNDI) distintos objetos/recursos.
¿Qué es JNDI?
La API JNDI (Java Naming and Directory Interface) es una interfaz de programación de aplicaciones que permite a las aplicaciones Java acceder y manipular objetos almacenados en sistemas de nombres y directorios o ÁRBOL de directorios.
La API JNDI se utiliza comúnmente para acceder a recursos como bases de datos, servicios de correo electrónico, servicios de directorio y otros recursos que se registran en un sistema de nombres y directorios. Permite a las aplicaciones Java buscar y utilizar estos recursos de manera dinámica, sin tener que conocer los detalles de su implementación o ubicación física.
En resumen, la API JNDI es una herramienta importante para desarrolladores de aplicaciones Java que necesitan acceder a servicios de nombres y directorios de manera flexible y portátil.
Sabemos que JEE (Java Enterprise Edition), JAKARTA EE y J2EE son lo mismo y NO son lenguajes de programación, sino plataformas.
Pero ¿qué son?
Son lo mismo y funcionan sobre la JRE de Java, pues usan código Java => AUNQUE LO LLEVAN AL DESARROLLO WEB.
Esta plataforma que acoge 2 conjuntos de tecnologías (APIs) para facilitar el desarrollo de aplicaciones empresariales escalables en Java (con un grupo haces tu aplicaciones y con las otras la hacemos multiplataformas para poderla usar en cualquier Servidor De Aplicaciones dotándola de capacidad web).
Es decir, JEE es una plataforma para desarrollar aplicaciones de servidor, como aplicaciones web, aplicaciones de comercio electrónico y sistemas de gestión de contenido.
En resumen, estandarizan el desarrollo web con Java y así no dependen de un producto único => puedes usar diversos servidores de aplicaciones como WebLogic, JBoss, …
*JBoss: es un servidor de aplicaciones Java EE de código abierto (puede ser usado por cualquier plataforma) implementado en Java puro.
*WebLogic: plataforma unificada y extensible para desarrollar, implementar y ejecutar aplicaciones empresariales (como aplicaciones Java) y en la nube.
¿En qué 2 grupos se dividen las APIs que forman la plataforma Java EE?
- Unas definen los componentes de tu aplicación, es decir, son con las que hacemos nuestra aplicación y se dividen en 2 capas:
1.1.Capa PRESENTACIÓN:
*Servlets 3.1 (javax.servelt y javax.servlet.http) => recogen todas las peticiones HTTP para adaptarlas a la “lógica de negocio” y a la Capa PRESENTACIÓN, es decir el paso de la Capa PRESENTACIÓN a la Capa de NEGOCIO.
*JSP (JavaServer Pages): para hacer páginas JSP.
*JSF (JavaServer Faces) => para crear interfaces de usuario.
*JSTL (JavaServer Pages Standard Tag Library) => librería de etiquetas para JSP.
1.2.Capa NEGOCIO:
*EJB (Enterprise JavaBeans) => para aplicaciones empresariales Java en un entorno distribuido.
*EJB MDB (Lógica de negocio asíncrono) => consumo de mensajes.
*Para hacer Web Services:
a)SOAP (XML) => javax.jws
b)REST (HTTP) => javax.ws.rs
- Otras definen o dan forma a los servicios que ofrece el “Servidor de Aplicaciones” (JBoss, WEbLogic, Jetty, JRun, Tomcat, …), es decir, da forma a los servicios que voy a usar en mis componentes con el fin de hacerlas multiplataformas y poderla usar en cualquier Servidor Aplicaciones dotándola de capacidad web:
*Directorio de objetos (ÁRBOL) => JNDI API: con este API vamos a poder acceder al árbol de objetos (DataSource).
Ej: obejto DataSource
*Transacciones distribuidas => JTA API: para realizar transacciones distribuidas, es decir, transacciones entre 2 gestores (SGBD) de BBDD diferentes
*Servicios de persistencias => JPA: conjunto de interfaces y clases para la gestión de la persistencia de los objetos Java en una base de datos relacional.
*Servicios de colas de mensajes =>JMS: para enviar mensajes, porque para recibirlos se usa MDB.
*Servicios para documentos JSON => JSON-P
*Servicios de Inyección de Dependencias => CDI: (copia del FrameWork: Spring) te proporciona el objeto que necesitas sin todas sus complejidades para simplificar, es decir, te da el objeto sin sus clases y dependencias (el objeto directamente).
*Patrón para crear aplicaciones web => Jacarta MVC
Jacarta NoSQL : herramientas que permiten el acceso a diferentes bases de datos NoSQL, basada en JPA.
En resumen, JEE se compone de 2 grupos de APIs: Con las que definimos los componentes de nuestra aplicación, es decir, con las que hacemos nuestra aplicación. Y las APis con las que definimos los servicios de Servidor de Aplicaciones para hacer nuestra API multiplataforma y usable en cualquier SERVIDOR DE APLICACIONES, el cual le daría el alcance web
IMPORTANTE: el Servidor de Aplicaciones es la pieza situada encima de la JRE (en el servidor) para dar capacidad web a este.
Java Servlet API, es el API que proporciona una interfaz para definir y usar servlets, pero ¿qué es un servlet?
Un servlet de Java EE es una clase de Java que se utiliza para procesar las solicitudes del cliente y generar respuestas en un servidor web, es decir, son como pequeños programas que se ejecutan en el servidor web para proporcionar contenido dinámico a través de internet
Esta clase de Java o servlet sirve para ampliar las capacidades de un servidor.
La palabra “SERVLET” viene de APPLET, que se refiere a pequeños programas que se ejecutan en el NAVEGADOR.
El uso más común de los servlet es generar páginas web de forma dinámica a partir de peticiones que envía el navegador web.
Sabemos que el uso más común de los servlet es generar páginas web de forma dinámica a partir de peticiones que envía el navegador web.
Pero ¿cuál es el ciclo de vida del SERVLET?
CICLO DE VIDA DEL SERVLET
1.Inicializar el SERVLET: cuando un servidor ejecuta un SERVLET ejecuta el método init del SERVLET.
2.Interactuar con los CLIENTES: con el método service, después de la iniciación, el SERVLET puede dar servicio a las peticiones de los clientes.
3.Destruir el SERVLET: los SERVLETs se ejecutan hasta que el servidor los destruye, con el método destruya, por cierre del servidor o a petición del administrador del sistema.
En la arquitectura Java EE los Motores de Ejecución se conocen como Servidores de Aplicaciones, ¿conoces algunos?
Apache Tomcat: contenedor de SERVLET para compilar y ejecutar aplicaciones web creadas en Java, tanto JSP como Java SOCKETS.
JRun: servidor de aplicaciones de MACROMEDIA basado en la plataforma JAva 2 Enterprise Edition (J2EE). Tiene 4 ediciones:
*DEVELOPER (desarrollador)
*PROFESSIONAL
*ADVANCED
*ENTERPRISE
Jetty: servidor HTTP de código abierto con un contender de SERVLET para proporcionar contenido estático o dinámico.
Otros: JBoss, WEbLogic, WildFly (Red Hat), …
IMPORTANTE: el Servidor de Aplicaciones es la pieza situada encima de la JRE (en el servidor) para dar capacidad web a la aplicación que hayamos creado en la plataforma JEE y estandarizado (definiendo sus servicios) para poderla usar en cualquier SERVIDOR DE APLICACIONES.
Los servlets son modulos java que nos sirven para extender las capacidades de los servidores web, pero ¿en qué se diferencian de los APPLETs?
Los SERVLETs son programas para los servidores, mientras que los APPLETs son programas para los clientes.
El desarrollo de JEE era controlado por Oracle y realizado según los procedimientos establecidos por Java Community Process (JSP) a partir de Java Specification Request (JRS), que es una solicitud para una especificación nueva o modificación de Java.
¿Cuándo dejó de formar parte de Oracle para pasar a llamarse Jacarta EE?
A finales de 2017, Oracle, con la idea de liberar Java, cedió Java EE a la Fundation ECLIPSE, pasando a formar parte de la iniciativa EE4J (ECLIPSE Enterprise for Java) y renombrándose como Jacarta EE Specification Process (JESP).
NOTA: a partir de Jacarta EE 9.0 los paquetes pasaron de javax._ a _Jacarta..
Las arquitecturas J2EE, JEE y Jacarta EE son lo mismo y funcionan sobre la JRE de Java, porque son código Java.
Definelos:
Jakarta EE, que es una plataforma de software empresarial de código abierto, anteriormente conocida como Java EE (Java Enterprise Edition).
Proporciona un conjunto de especificaciones y APIs para desarrollar y desplegar aplicaciones empresariales en Java (para trabajar con bases de datos, servicios web, mensajería, seguridad, entre otras).
a)Unas APIs sirven para generar nuestros propios COMPONENTES que funcionan en cualquier producto que cumpla con dichos estándares => es la parte que afecta a nuestro código. Es decir, son las APIs con las que creamos
Servlets, JSP, JSF, JSTL, EJB, SOAP o REST
b)Otras APIs sirven para consumir unos SERVICIOS estándares dentro de ese nuevo “RunTime” (JRE) o Servidor de Aplicaciones, es decir, estas APIs estandarizan nuestra aplicación para poderla usar en cualquier Servidor de Aplicaciones (son los que proporcionan el alcance web):
JNDI (Para acceder al Directorio de objetos => ÁRBOL) o JTA (TRANSACCIONES DISTRIBUIDAS, es decir, entre 2 SGBD diferentes)*
Es decir, JEE estandariza el desarrollo web con Java y así no dependes de un producto o servidor de aplicaciones único, porque todos cumplen con dichos estándares => JBOSS, WebLogic, Jetty, JRun, Apache Tomcat, …
En JEE los “Motores de Ejecución” se llaman Servidores de Aplicaciones (JBOSS, WebLogic, Jetty, JRun, Apache Tomcat, …) y son los encargados de dar alcance web a nuestras aplicaciones creadas en la plataforma JEE.
¿Cuál es su estructura?
De ABAJO a ARRIBA:
1.JRE: al estar estos Servidores de Aplicaciones construidos en Java, necesitan de JRE para ejecutarse.
2.Servidores J2EE:
JNDI: para acceder al árbol de directorios.
JTA: para realizar transacciones distribuidas (entre 2 SGBD diferentes).
3.Motor de servicios Web: motor para realizar las llamadas a los distintos servicios web.
REST: HTTP
SOAP: XML + HTTP
4.CONTENEDORES: módulos o contenedores de componentes fundamentales en J2EE:
Web Container: SERVLET y páginas JSP (Java Server Pages, es similar a PHP, pero en Java).
EJB Container: como su propio nombre indica, contienen componetes EJB (Java Beans Enterprise) de varios tipos:
*Sesion
*Entidad
*MDB (Message Driven Beans): EJB dirigidos a mensajes.
Cuando navegamos también enviamos información al Servidor (texto que escribimos en las búsquedas, el orden de una lista, el filtro que usemos en tiendas,…).
¿Qué métodos de peticiones provee el Servidor HTTP para enviar dicha información?
GET: los datos que se envian al servidor se escriben en la misma dirección URL.
Sirve para configuración de páginas Web (filtros, búsquedas, ordenación, …)
GET /url + request
POST: introduce los parámetros en la solicitud HTTP.
Por ello, no quedan visibles para el usuario.
Además, la capacidad del método POST es ilimitada.
Sirve para la transferencia de información y datos.
POST /url + request
Sabemos que con Java básico (Java SE) no se pueden hacer aplicaciones web, para ello esta la plataforma JEE, pero ¿cómo lo hace?
PASO1: definimos los componentes de la app (son una variantes de las clases, pero mas versátiles), es decir, creamos nuestra aplicación con un conjunto de tecnologías particulares (JSP, JSTL, JSF, Servlets, EJB, MDB, SOAP y REST).
PASO2: definimos o damos forma a los servicios que ofrecen los Servidores de Aplicaciones, es decir, estandarizamos nuestra app para que sea multiplataformas, así poderla usar en cualquier Servidor de Aplicaciones y lo hacemos con otros tipos de tecnologías diferente al de definición de componentes (JTA, JNDI, JPA, JMS, JSON-P, CDI, Jacarta MVC y Jacarta NoSQL).
PASO3: una vez creado y estandarizado nuestra app, LE DAMOS ALCANCE WEB con el uso de un Servidor de Aplicaciones, que funcionan sobre la JRE de Java (JBoss, WildFly, WebLogic, Apache Tomcat o TomEE, …).
En cuanto a los servicios principales de Java EE, ahora Jacarta EE, expón algunas APIs con sus métodos u objetos:
JTA (Servicios de Transacciones Distribuidas) => commit, rollback,…
JNDI (Servicios del árbol de directorios) => lookup (objeto a buscar) -> con este método buscas un objeto en el árbol JNDI (BD).
JDBC (Servicio de persistencia de bajo nivel= cuando quieres guardar un objeto con en esta aPI de Java tú tienes que construirte el SQL, es decir, no usa ORM) => Driver, DataSource, Connection, PrepareStatement o ResultSet.
JPA (API de persistencias de más alto nivel que JDBC para guardar objetos en BBDD=> NO tienes que construir el SQL, el ORM lo hace por tí) => EntityManager
NOTA: JPA es el API e Hibernate (ORM) es una implementación de un fabricante.
Otros ORMs: TopLink (EclipseLink), Apache OpenJPA o DataNucleus (admite JDO o Java Data Objects).
Un Container web es un servidor que proporciona un ambiente en tiempo de ejecución para aplicaciones web basadas en Java EE.
Pero ¿qué hay dentro de dicho container?
*Dentro del CONTAINER se gestionan componentes.
El API de componentes se llama Servlet.
*Dentro del CONTAINER pueden ejecutarse muchas aplicaciones web independientemente.
*Dentro del CONTAINER tenemos una serie de servicios (piezas) que ofrecen una funcionalidad determinada al Servlet.
El API de servicios se llama J2EE.
En cuanto a los servicios principales de Java EE, ahora Jacarta EE, expón algunas APIs con sus métodos, objetos o @anotaciones:
JMS [Servicios asíncronos de colas de mensajes => para enviar mensajes. En cambio, para recibir o consumir mensajes esta MDB] => onMessage (encolar): método para poner un mensaje en cola, queue (cola) o topic ( para crear o acceder a un objeto Topic en el servidor JMS. El objeto Topic se utiliza luego para enviar o recibir mensajes desde un publicador a uno o más suscriptores.).
CDI [(Contexts and Dependency Injection) es una API de Java que proporciona un conjunto de anotaciones y clases que permiten la inyección de dependencias y la gestión de contextos en aplicaciones Java EE y Java SE] => @Inject, @RequestScoped o @Named.
JAX-WS [Para desarrollar Servicios Web SOAP (XML)] => @WebService, @WebMethod o @WebParam.
JAX-RS [Para desarrollar Servicios Web REST (HTTP)] => @Path, @Get o @Post.
NOTA: SOAP (Simple Object Access Protocol) y REST (Representational State Transfer) son dos protocolos diferentes para la comunicación entre sistemas distribuidos, uno usa formato XML y otro HTTP.
Al igual que las Páginas JSP (Java Server Pages), un Servlet de Java EE es un componente de programación de servidor que se utiliza para procesar solicitudes y respuestas HTTP en una aplicación web basada en Java EE.
Se hacen con el API de los Servlet, que, además de sus 2 objetos principales (HttpServletRequest y HttpServletResponse), usa varios objetos más (HttpServlet, ServletContext o HttpSession), define algunos con sus métodos:
HttpServletRequest (para las peticiones):
getCookies ( ) => para conseguir las cookies.
NOTA: con HttpServletResponse seria:
addCookie ( ) => añade cookies al navegador
getHeader (name) => obtener las cabeceras HTTP.
getQueryString ( ) => para obtener la parte de la derecha de la “?” en la URL.
*getParameter (name) => obtiene los parámetros de la URL
getSession ( ) => nos da acceso al objeto que esta asociado al cliente -> Httpsession (objeto del cliente): en este objeto vamos a poder meter información que tendrá sentido cuando se vuelva a conectar el mismo cliente, es decir, este objeto tiene el estado de navegación de cada cliente / usuario que se haya conectado.
Hay 4 componentes muy importantes dentro del “Api de los Servlet” (Core) para implementar el patrón CHAIN of RESPONSABILITY, ¿cuáles son?
HTTP Session
Filter
Listener (escuchar sesiones)
Contexto: concepto global o único de toda la aplicación web.
CHAIN of RESPONSABILITY (cadena de responsabilidades):
es un patrón de diseño de software que se utiliza para crear una cadena de objetos que pueden procesar una solicitud y no tener que codificarlo todo en el servlet.
Al igual que las Páginas JSP (Java Server Pages), un Servlet de Java EE es un componente de programación de servidor que se utiliza para procesar solicitudes y respuestas HTTP en una aplicación web basada en Java EE.
Se hacen con el API de los Servlet, que, además de sus 2 objetos principales (HttpServetRequest y HttpServletResponse), usa varios objetos más (HttpServlet, ServletContext o HttmSession), define algunos con sus métodos:
HttpServletResponse (para las respuestas).
addCookie ( ) => añade cookies al navegador.
NOTA: con HttpServletRequest sería:
getCookies ( ) => para conseguir las cookies.
addHeader ( ) => añadirle alguna cabecera.
sendRedirect ( ) => redirección de cliente, con un código http le dice al navegador que vaya a otra URL.
Ej: HTTP 300 al navegador: significa que el servidor ha recibido una solicitud del cliente, pero la respuesta requerida no se encuentra en la ubicación solicitada. En lugar de devolver un error 404, el servidor envía una respuesta 300 para indicar que la respuesta se puede encontrar en otra ubicación.
getWriter ( ) => canal de entrada/salida (I/O) para mandar información por red.
1º Hay que indicar el tipo de información (página html, un pdf, una imagen,…) con:
setContentType (tipoMIME)
y luego se envía con getWriter.
Al igual que las Páginas JSP (Java Server Pages), un Servlet de Java EE es un componente de programación de servidor que se utiliza para procesar solicitudes y respuestas HTTP en una aplicación web basada en Java EE.
Se hacen con el API de los Servlet, que, además de sus 2 objetos principales (HttpServetRequest y HttpServletResponse), usa varios objetos más (HttpServlet, ServletContext o HttmSession), define algunos con sus métodos:
ServletContext: objeto global.
getAttribute (name) (para ofrecer un valor) + setAttribute (name,value) (para dar un valor) => con estos métodos podemos pasar información a nivel interno y se puede usar con 3 objetos:
1.Si lo pasas x el contexto (ServletContext), estaríamos hablando de un saco de información global.
2.Si lo haces sobre la sesión (HttpSession), esta información sólo la verían los componentes asociados a la sesión de navegación de un determinado usuario.
3.Cuando se le hace a un request (HttpServletRequest), sólo tiene sentido cuando se lo pasamos a otro componente web y se eliminan en cada petición o respuesta.
getRequestDispatcher (path) + forward (req,resp) => cuando quieres desde un componente web (servlet o página JSP) llamar a otro componente de tú aplicación: le pasas el path de uno de tus componentes (página JSP u otro servlet) al método:
getRequestDispatcher (path) y con el método:
fordward (Req, Res)
lo ejecutas, es decir, estos métodos sirven para hacer llamadas entre componentes web.
Además de los SERVLET, existen componentes en JEE “para hacer Páginas (Vistas)”, “para servicios web” o “para hacer apps empresariales con EJB”.
¿Cuáles son las que podemos usar para hacer páginas (vistas)?
1.JSP: (JavaServer Pages o Páginas de servidor Java) => página HTML con trozos de código Java (scriptlet).
Permite crear páginas web empresariales dinámicas HTML (gran interacción entre el usuario y la aplicación) utilizando el lenguaje de programación Java. Las páginas JSP son similares a las páginas HTML tradicionales, pero incluyen elementos de código Java que se ejecutan en el servidor antes de que se envíe la página al navegador web del usuario.
NOTA: en el código de Java que incluyen hay una serie de objetos predefinidos:
*Session
*Request
*Page
2.JSF: (JavaServer Faces o Caras de servidor Java) => HTML + Tags UI.
Documentos que tiene mezcladas etiquetas HTML con etiquetas UI (User Interfaz), con las que se dota a JSF de componentes gráficos (TABLE, Tree,…).
*JSF es un framework de componentes de interfaz de usuario (UI) para aplicaciones web empresariales escritas en Java.
3.JSTL : (JavaServer Pages Standard Tag Library) => HTML + Tags Library.
JSTL es una librería de etiquetas, es decir, proporciona etiquetas que permiten a los desarrolladores de aplicaciones web de Java evitar escribir código Java complejo en sus páginas JSP.
Además de los SERVLET, existen componentes en JEE “para hacer Páginas (Vistas)”, “para servicios web” o “para hacer apps empresariales con EJB”.
¿Cuáles son las que podemos usar para hacer apps empresariales con EJB?
Se ubican en el CONTAINER EJB Container y hay de 3 tipos:
1.Sesion:
a)StatLess: (sin estado) orientados a la lógica de negocio (Ej: cálculos).
b)StateFul: (con estado) para lógica de negocio con estado.
2.Entity: desaparecieron en favor de JPA y servían para BBDD, pero tenían problemas de diseño y rendimiento.
3.MDB: (dirigidos por mensajes: Message Driven Beans) se invocan cuando llega un mensaje ala cola (queue) de la que escucha.
Este EJB es muy importante para hacer programación asíncrona.
Explica el flujo de aplicación web, es decir, lo que ocurre dentro del Web CONTAINER (Servidor):
req, res => se crean continuamente por cada petición de usuario.
HttpSesion => se crea por cada usuario conectado.
Servlet => se crea un objeto de cada clase al inicio de la app.
Filter => la petición pasa por los filtros.
ServletContext => se crea un objeto global compartido por todos los servlets.
En resumen:
1º se hacen peticiones (req, res), que son como URLs, continuamente al servidor.
2º se crean HttpSesion con cada petición y la información del susodicho usuario.
3º pasan por los filtros => CHAIN of RESPONSABILITY o CoR (patrón de diseño de software que se utiliza para manejar solicitudes de manera jerárquica y puede implementarse a través de los filtros utilizando filtros de Servlets)
4º según la petición, se ejecuta un servlet u otro (cada servlet tiene su cometido).
5º se crea el objeto ´global ServletContext compartido por todos los servlets.
Sabemos que las “Aplicaciones Web” se crean con las APIS JEE programadas en Java y que una vez creada la aplicación se empaqueta en un fichero.ear.
¿De qué se compone este fichero empaquetador?
.ear (Enterprise ARchive) esta compuesto de (EJ. nominas.ear):
application.xml, fichero en cuyo interior pueden haber 1 o varios .war (Web ARchive) y .jar (Java Archive) para dar de alta lo módulos web y módulos EJB (es un archivo comprimido dentro de un archivo comprimido).
admin.war empleados.war
calculos.jar informes.jar
…
1.Módulos Web (.war): cada .war tiene toda la parte web, es decir, todo el contenido de la Web CONTAINER.
1.1.html/css/jsp => las páginas web
1.2.WEB-INF => carpeta que contiene:
a)Las clases Java compiladas (.class)
b)Librerías de terceros (.jar):
logback.jar
iText.jar (generar PDF)
Log4J
SLF4J-api.jar
c)web.xml => fichero que usa etiquetas y lee/analiza el Web Container.
NOTA: habría un módulo con la misma estructura por cada “fichero.war” (admin.war, empleados.war, …)
2.Módulos EJB (.jar): cada fichero.jar contendría:
2.1.META-INF: carpeta con:
a)ejb-jar.xml => es un fichero con la definición de la configuración EJB:
b)Las clases ya compiladas (.class) para implementar la lógica de negocio.
NOTA: habría un módulo EJB con la misma estructura por cada “fichero.war” (calculos.jar, informes.jar, …)
El fichero.ear empaqueta la aplicación que hayamos creado con JEE, incluye el fichero application.xml donde damos de alta los módulos web (.war) y los módulos EJB (.jar).
Define los módulos.war:
.war (Web ARchive) => contenido del “módulo Web CONTAINER”.
1.Módulos Web (.war): cada .war tiene toda la parte web, es decir, todo el contenido de la Web CONTAINER.
1.1.html/css/jsp => las páginas web (recursos estáticos)
1.2.WEB-INF => esta carpeta contiene:
a)Las clases (.class) Java usadas para implementar la lógica de este módulo web.
b)Un directorio estándar para las librerías de terceros (*.jar):
logback.jar
iText.jar (generar PDF)
Log4J
SLF4J-api.jar
c)Y el fichero web.xml => es un fichero que usa etiquetas y lee/analiza el Web Container.
NOTA: habría un módulo con la misma estructura por cada “fichero.war” (admin.war, empleados.war, …)
El fichero.ear empaqueta la aplicación que hayamos creado con JEE, incluye el fichero application.xml donde damos de alta los módulos web (.war) y los módulos EJB (.jar).
Define los módulos.jar:
.jar (Java ARchive) => archivo con herramientas Java y contiene los “módulos EJB”.
2.Módulos EJB (.jar): cada fichero.jar contendría:
2.1.META-INF: carpeta con el fichero de configuración ejb-jar.xml y las clases (.class) para implementar la lógica de negocio.
a)ejb-jar.xml => es un fichero con la definición de la configuración EJB:
<business-local>INTERFACE </business-local> => invocaríamos en la misma máquina (local).
<business-remote>INTERFACE </business-remote> => si quisieramos tener arquitectura distribuida y poder invocar por la red.
b)Las clases ya compiladas (.class) para implementar la lógica de negocio.
NOTA: habría un módulo EJB con la misma estructura por cada “fichero.war” (calculos.jar, informes.jar, …)
¿Qué quiere decir que la seguridad en J2EE esta basada en roles?
Se indica que rol puede ejecutar que componente web en el Web CONTAINER.
Funcionamiento:
1º El método de autenticación, ya sea el básico (usuario/password) o certificados x509, comprobarán en la base de datos y fichero user.xml donde esta el rol del usuario en cuestión.
2º Una vez localizado dicho rol, en el CONTAINER web se chequea con el fichero de configuración web.xml para comprobar si ese rol tiene “autenticación” y si no => ACCESO NO AUTORIZADO.
NOTA: en la Capa o CONTENEDOR EJB se hace lo mismo: se busca el rol que tiene el usuario en el CONTAINER Web, tanto en la BD como en el fichero user.xml y se propaga al CONTAINER Web si se ha llamado a alguna funcionalidad EJB o lógica de negocio de EJB Container.
¿Por qué motivo mejora JPA (Java Persistence API) la API JDBC (Api de persistencia de bajo nivel) u el lenguaje de consulta de EJB llamado JPQL (Java Persitence Query Languaje)?
Porque JPA usa los Motores de Persistencia u ORMs que, por medio del Entity Manager (clase principal de JPA), construyen solos el SQL, agilizándonos el trabajo en gran medida.
NOTA: con la clase o interfaz principal de JPA **EntityManager* lo que se hace es crear unas @anotaciones con las que el ORM genera automáticamente el SQL.
Creas un objeto o entidad por medio de @anotaciones de la clase “ENTITY MANAGER”. Entonces los ORMs automáticamente averiguan la clase y atributos de nuestro objeto (@anotación) y genera automáticamente el SQL. Para recuperar datos es igual
ORMS: Hibernate (Java), Nhibernate (.NET), EklipseLink (antes TopLink) u OpenJPA.
Sabemos que el API de Persistencia JPA es el de Alto Nivel, porque gracias a los ORM (motores de persistencia), genera automáticamente el SQL que necesitamos, pero ¿Por qué JDBC es el de Bajo Nivel?
Porque tiene un sistema IMPERATIVO cuando JPA es DECLARATIVO. Es decir, con JPA sólo das unas instrucciones y el ORM hace el resto. Pero, con JDBC al ser imperativo, tienes que hacerlo todo manualmente:
1ºLe decimos al DataSource:
get connection
y nos conecta al servidor de la BD.
2ºA esa conexión le decimos que vamos a preparar una sentencia SQL:
PreparedStatement
Así la prepara y luego la ejecuta contra la BD.
3ºEjecuta la sentencia contra la BD a través de Driver y este nos devuelve un cursor.
4ºEl Driver de la BD nos devuelve un cursor ResultSet, con el que procesamos o recorremos el resultado obtenido de nuestra consulta.
En resumen, este JDBC:
CREA CONEXIONES (DataSource) -> EJECUTA SENTENCIAS (PreparedStatement + Driver) -> PROCESA RESULTADOS (ResultSet)
