Persistence en Java

Un POJO (Plain Old Java Object) lleva como definición una forma de enfatizar el uso de clases simples que no dependen de ningún framework en especial.
Se conoce como Persistencia a la acción de guardar en un archivo la información de un objeto para luego volver a recuperarla, sin hacer uso de la Ram.
Existen Frameworks que permiten utilizar de forma mas fácil la Persistencia como por ejemplo pueden ser Hibernate, Toplink, etc.
Para poder llevar a cabo la acción de Persistencia podemos utilizar la interfaz Serializable, que serializará un objeto para luego reconstruirlo de nuevo. 
Los campos del objeto marcados con transient no serán serializados.

Ejemplo:

public class serialization {
    public static void main(String args[]){
        try {//serializacion
            //crea el objecto e imprime sus valores por consola
            //clase pojo abajo
            MyPojo object1 = new MyPojo("Hello Persisted Object!", -33, 2.72);
            System.out.println("object1: " + object1);
            //crea un fichero para persistir el objeto
            FileOutputStream fos = new FileOutputStream("persisted-object.file");
            ObjectOutputStream oos = new ObjectOutputStream(fos);
            //escribe el objeto serializado a un archivo
            oos.writeObject(object1);
            oos.flush();
            oos.close();
        }catch (Exception e) {
            System.out.println("Exception during serialization: " + e);
            System.exit(0);
        }
        // Deserialización de objeto
        try {
            MyPojo object2;
            //abre el archivo
            FileInputStream fis = new FileInputStream("persisted-object.file");
            ObjectInputStream ois = new ObjectInputStream(fis);
            //lee el objeto del archivo
            object2 = (MyPojo) ois.readObject();
            ois.close();
            //imprime los valores del objeto persistido
            System.out.println("object2: " + object2);
            System.out.println("object2 mystring: " +object2.getMyString());
            //saca por pantalla null porque myTransString está marcado como transient
            System.out.println("object2 mystring2: " +object2.getMyTransString());           
        } catch (Exception e) {
            System.out.println("Exception during deserialization: " + e);
            System.exit(0);
        }
    }   
}
//Pojo serializado
class MyPojo implements Serializable {   
    public MyPojo(String mystring, int intVal1, double doubleVal) {
        this.myString = mystring;
        this.intVal1 = intVal1;
        this.doubleVal = doubleVal;
        this.myTransString = "Este valor no se persistirá.";
    }
    //safety ID
    private static final long serialVersionUID = 1234233342333L;
    //campos para persistir
    private String myString;
    private int intVal1;
    private double doubleVal;   
    //campos que no serán persistidos
    private transient String myTransString;
    //getters y setters
    public String getMyString() {
        return myString;
    }
    public void setMyString(String myString) {
        this.myString = myString;
    }
    public String getMyTransString() {
        return myTransString;
    }
    public void setMyTransString(String myTransString) {
        this.myTransString = myTransString;
    }
    public int getIntVal1() {
        return intVal1;
    }
    public void setIntVal1(int intVal1) {
        this.intVal1 = intVal1;
    }
    public double getDoubleVal() {
        return doubleVal;
    }
    public void setDoubleVal(double doubleVal) {
        this.doubleVal = doubleVal;
    }
    //para sacar todos los valores persistibles por pantalla
    @Override
    public String toString() {
        return "mystring=" + myString + "; intVal1=" + intVal1 + "; doubleVal=" + doubleVal;
    }
}


Persistencia API de Java


Beans de Entidad

Los EJB de entidad están directamente relacionados con los datos de la aplicación, son objetos que mantienen en memoria los datos que maneja la aplicación, las entidades que disponen de persistencia, Noticias, Usuarios, Clientes, etc...

Anotaciones de entidades POJO's:

Anotación @Entity Indica que el objeto es una entidad.
Anotación Table indica la tabla de base de datos que contiene objetos de este tipo. 
Toda entidad debe tener una clave primaria que se debe identificar con la anotación @Id. Además, todas las entidades deben contener un constructor vacío.

Anotaciones @Id, @IdClass, @EmbeddedId
Se emplean para declarar claves primarias de clases, bien de forma simple @Id o compuesta @IdClass y @EmbeddedId.
 
Veamos un código utilizando @IdClass:
 
@Entity 
@IdClass(PersonaId.class) 
public class Persona { 
    @Id 
    private int id; 
    @Id 
    private String nombre;  
    ... 
    public Persona() { } 
    //METODOS Getters y Setters  
} 
 
public class PersonaId { 
     int id; 
    String nombre; 
     public boolean equals(Object o) { 
        // Codigo que comprueba si las dos entidades son iguales 
    } 
}
Y ahora un código utilizando @EmbeddedId
 
@Entity 
public class Persona { 
  @EmbeddedId 
  @AttributeOverrides({ 
     @AttributeOverride(name = "id", column = @Column(name = "ID",  
                              nullable = false, precision = 5, scale = 0)), 
    @AttributeOverride(name = "nombre", column = @Column(name = "NOMBRE"
                       nullable = false, length = 50)), 
 }) 
    private PersonaId id; 
    public Persona() { } 
    //Métodos Getters y Setters  
} 

@Embedded 
public class PersonaId { 
     int id; 
    String nombre; 
     public PersonaId() { } 
     public boolean equals(Object o) { 
        // Codigo que comprueba si las dos entidades son iguales 
    } 
}
@Entity 
@Table(name="PERSONAS") 
public class Persona { 
    @Id 
    private String nombre;  
    @Embedded 
    @AttributeOverrides({@AttributeOverride(name="codigoPostal",  
                                            column=@Column(name="CODIGOPOSTAL")), 
                         @AttributeOverride(name="direccionPostal",  
                                            column=@Column(name="DIRECCIONPOSTAL")) 
    }) 
    private Direccion direccion; 
    public Persona() { } 
    //Métodos Getters y Setters  
} 

@Embeddable  
public class Direccion implements Serializable {  
    private String direccionPostal; 
    private String ciudad; 
    private int codigoPostal; 
    private String pais; 
    public Direccion() { } 
    public boolean equals(Object o) { 
        // Codigo que comprueba si las dos entidades son iguales 
    }   
}

Bean de Sesion

Un bean de sesión representa a un cliente dentro de un servidor J2EE. Para acceder a una aplicación desplegada en el servidor, el cliente invoca métodos del bean de sesión.
Existen dos tipos de Bean de Session:
Stateful (con sesión)
El estado de un objeto consiste en el valor de sus variables de instancia:
  • Mantienen estado de sesión.
  • Cada cliente usa una instancia del bean.
  • Se especifican mediante la anotación @Stateful.
Stateless (sin sesión)
Una sesión stateless no mantiene un estado conversacional para un cliente en particular. Puede servir a muchos clientes.
  • No mantienen el estado del cliente.
  • El contenedor crea pools de Session bean stateless usados por n clientes.
  • Se especifican mediante la anotación @Stateless
Ciclo de vida Bean @StateFul:
  • Creación: Cuando el cliente ejecuta el método create().
  • Uso: Cuando el cliente llama un método de negocio.
  • Desactivación: El bean se manda a memoria secundaria.
  • Activación: El bean es despertado para servir algún método al cliente.
  • Destrucción: Cuando el cliente termina su sesión con el bean.
Ciclo de vida Bean @Stateless:
  • Creación: Cuando el contenedor quiere un bean.
  • Uso: Cuando el cliente llama un método de negocio.
  • Destrucción: Cuando el contenedor decide que hay muchos beans en el pool.
Métodos invocados automáticamente por el EJB container:
No tienen parámetros y son tipos de métodos void.

Los métodos anotados con @PostConstruct son invocados cuando se instancia un bean, después de la inyección de las anotaciones y antes de que se invoque el primer método de negocio.
Los métodos anotados con @PreDestroy son invocados después de la ejecución de métodos anotados con @Remove y antes de que el contenedor elimine la instancia del bean.
Los métodos anotados con @PostActivate son invocados después de que el contenedor mueva el bean de memoria secundaria a estado activo.
Los métodos anotados con @PrePassivate son invocados antes de que el contenedor elimine el bean del ambiente activo y lo salve en la memoria secundaria.
Un método anotado con @Remove es un método de ciclo de vida especial, que puede ser invocado por el cliente del bean.
Después de su ejecución el contenedor llama al método anotado con @PreDestroy, si existe.
A continuación la instancia queda sin referencia y lista para ser procesada con el Garbage Collector (recolector de basura).

Acceso de Clientes Bean a una Sesión:
Un cliente sólo puede acceder un Session Bean a través de los métodos definidos en la Interfaz. Es el tipo de cliente quién determina que interfaces se usan. Pueden haber dos tipos de interfaces:
  • Remotas.
  • Locales.
Un cliente remoto de un session bean:
  • Corre en una máquina virtual de Java diferente a la del bean.
  • Puede ser un programa standalone, un componente web (servlet o JSP) u otro EJB.
  • La localización del bean es transparente para el cliente.
  • Para definirlo debe usarse la anotación @Remote y puede hacerse de dos formas diferentes.
Un cliente local de un session bean:
  • Debe correr en la misma máquina virtual de Java que el bean.
  • Normalmente es otro EJB.
  • La localización del bean NO es transparente para el cliente.
  • Para definirlo debe usarse la anotación @Local en la declaración de la interfaz o nada, que es por defecto.
@Local
public interface MiBeanLocal 
{
//CODIGO DEL BEAN
}
  • Debemos especificar la clase principal con la anotación @Local con la interfaz como parámetro:
 
@Local(MiBeanLocal.class)
public class MiBean implements MiBeanLocal 
{
//CODIGO DE LA CLASE
}
 

Factores a considerar para utilizar acceso local o acceso remoto:

  • Beans relacionados entre sí deben usar interfaces locales para comunicarse entre ellos.
  • Clientes en otras máquinas virtuales o reales diferentes deben usar interfaces remotas.

Introducción a los Servlets

Los Servlets son clases de Java que implementan la clase HttpServlet de Java. Dichos servlets no contienen parte gráfica, por lo que su funcionamiento en el momento de recibir una petición no tiene por qué ser dar salida a código HTML en el cliente.
Un servlet se puede definir como un conjunto de acciones capturadas desde un cliente y que pueden derivar en una respuesta http o pueden realizar un flujo de trabajo.
El cliente, mediante el navegador, hace una solicitud al contenedor web, que captura dicha solicitud en un servlet mediante un request.
El servlet puede enviar una respuesta mediante un objeto response, y dicha respuesta puede ser implementada mediante un objeto PrintWriter para devolver código HTML que se generará de nuevo en el cliente.
La llamada a un servlet se debe realizar a través de contenidos estáticos HTML, tales como páginas HTML o jsp.
Las páginas JSP contienen lógica de servidor y lenguaje HTML en un mismo conjunto. Teniendo en cuenta esto, las páginas jsp contienen parte gráfica y lógica de servidor. En realidad, las páginas JSP utilizan un servlet interno al que se accede mediante etiquetas de servidor y que también implementan el diseño HTML. Las páginas JSP son la evolución de los servlets y permiten realizar acciones más dinámicas que un servlet, ya que podemos utilizar la lógica del servidor separada del diseño, pero en un mismo conjunto.

Estructura de un servlet

Los servlets heredan de la clase HttpServlet y sobreescriben el método doPost o doGet, dependiendo de si los datos han sido enviados por el método POST o GET.
Podemos realizar la misma acción tanto para peticiones GET y POST simplemente llamando a doGet desde doPost o viceversa.
Ambos métodos, doPost y doGet, ofrecen dos argumentos:
  • Un objeto HttpServletRequest: Encapsula la petición http
  • Un objeto HttpServletResponse: Encapsula la respuesta HTTP.
El objeto HttpServletRequest nos permite acceder tanto a los datos como a las cabeceras de la petición HTTP.
El objeto HttpServletResponse nos permite modificar la información de salida, como los códigos de estado HTTP o las cabeceras de respuesta.
Además podemos obtener un objeto PrintWriter sobre el que generar el contenido dinámico del documento al cliente.
Los métodos doGet y doPost pueden lanzar las excepciones ServletException e IOexception por lo que deben controlar dichas excepciones, ya sea mediante throws o mediante try-catch.

Clases principales de servlets

Para poder trabajar con servlets, debemos importar los paquetes java.io (para el PrintWriter), javax.servlet (para el HttpServlet) y javax.servlet.http (para el HttpServletRequest y HttpServletResponse).
Los objetos para la definición de servlets se encuentran divididos en dos paquetes: javax.servlet.*, que proporciona clases necesarias para crear servlets genéricos, independientes del protocolo utilizado, y javax.servlet.http.*, que proporciona las clases que definen un servlet específico para el protocolo HTTP.
Servlet define la funcionalidad básica que tiene un servlet como es su ciclo de vida (métodos init, destroy) y procesar requests (método service).
Es implementado por la clase GenericServlet.
SingleThreadModel es una interfaz utilizada para marcar los servlets que se desea que se ejecuten en forma secuencial por requests simultáneos, evitando posibles problemas de procesamiento paralelo.
HttpServlet agrega la funcionalidad para procesar los variados tipos de request HTTP (principalmente los métodos doGet, doPost para procesar formularios GET y POST, respectivamente).
HttpServletRequest proporciona información del request del cliente al servlet a través del protocolo HTTP. Se pueden obtener datos como encabezados, cookies y características genéricas como dirección del cliente y parámetros recibidos desde él (getParameter). Permite también asociar objetos (setAttribute) y acceder al objeto HttpSession.
HttpServletResponse asiste a un servlet para enviar una respuesta al cliente a través de un canal de comunicación binario o de texto (getWriter). Provee también funcionalidad específica para respuestas HTTP como enviar encabezados, cookies (addCookie) y errores con códigos numéricos como 403 (sendError).
HttpSession permite identificar un usuario a través de más de una página, para esto se le asigna un identificador único que se mantiene mientras el usuario navega en el sitio (getId). Permite asignar un tiempo máximo de inactividad y se le pueden asociar objetos para compartir entre servlets (setAttribute y getAttribute).
El código completo de cualquier servlet sería el siguiente:
 
package NOMBREPAQUETE;
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class NewServlet extends HttpServlet {
    @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);
    }
}
 

Métodos de información del servidor con servlets

Los servlets pueden obtener información del servidor, ya sean datos propios del servidor o mediante el envío de información desde un formulario HTML. Tenemos los siguientes métodos:
  • Nombre del servidor: request.getServerName()
  • Número de puerto: request.getServerPort()
  • Software del servidor: getServletContext().getServerInfo()
  • Obtener la dirección IP del cliente: request.getRemoteAddr()
  • Obtener el nombre del cliente Host: request.getRemoteHost()
O mediante formularios HTML por medio de GET como una cadena añadida a la URL o POST:
El método String getParameter("nombreParámetro") devuelve el valor asociado al objeto que se ha denominado como nombreParámetro en la petición. Tenemos que tener en cuenta que se diferencia entre mayúsculas y minúsculas. Devuelve null si no aparece dicho parámetro en la petición.
  • Método getParameterValues("NombreParametros"): devuelve un array de valores. Se utiliza para capturar objetos que forman conjuntos en un formulario, como puede ser un grupo de radiobutton HTML.
  • GetParameterNames( ): devuelve una enumeración de los parámetros de petición sin ningún orden.

Conceptos Básicos en Java

Las ediciones de Java más importantes son:
* Java Standard Edition (Java SE) → Para PC
* Java Micro Edition (Java ME) → Para moviles
* Java Entreprise Edition (Java EE) → Version mas completa
* Java Card → Para tarjetas de credito con chip

Los módulos que forman una aplicación empresarial en Java pueden ser de tres tipos:
  • Archivos JAR (Java Archive): Los archivos JAR permiten agrupar distintos archivos .java en uno solo. Es el empleado para empaquetar componentes EJBs.
  • Archivos WAR (Web Application Archive): Los archivos WAR permiten empaquetar en una sola unidad aplicaciones web completas (servlets, páginas JSPs, contenido estático como imágenes y otros recursos Web).
  • Archivos EAR (Enterprise Application Archive): Los archivos EAR son archivos desplegables en servidores de aplicaciones JEE. Contienen archivos WAR y EJBs empaquetados en ficheros JAR.
Por lo que podemos decir que existen tres tipos de aplicaciones Java EE:
  • Aplicaciones Web JAVA.
  • Objetos distribuidos EJBs.
  • Aplicaciones empresariales que engloban a las dos anteriores, aplicaciones web JAVA y objetos distribuidos EJBs
La interfaz de programación de aplicaciones, abreviada como API (del inglés: Application Programming Interface), es el conjunto de subrutinas, funciones y procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción.
Las clases en las APIs de Java se organizan en grupos distintos llamados paquetes.
Cada paquete contiene un conjunto de interfaces, clases y excepciones relacionadas con el entorno de trabajo.
 
Vamos a visualizar algunos de los servicios que provee Java EE(Enterprise Edition) y que podemos emplear en cualquier servidor de aplicaciones que siga este estándar.
  • Java Transaction API (JTA): Consta de dos partes y define las interfaces entre el manejador de transacciones y las partes involucradas en un sistema de transacciones distribuido, el manejador de recursos, el servidor de aplicaciones y las aplicaciones transaccionales.
  • Java Persistente API (JPA): Para dotar de persistencia a objetos del lenguaje.
  • Java Message Service (JMS): Sistema de mensajería, permite mensajes punto a punto y sistemas publicado suscrito.
  • Java Naming Direct Interface (JNDI): Sistema de nombrado para localizar recursos o componentes de proveedores.
  • JavaMail: Para manejo de correo electrónico.
  • Java Beans Active Framework (JAF): Manejo de datos en diferentes tipos mime, ligado al uso del correo.
  • Java API for XML Processing (JAXP): Soporte para el manejo de XML.
  • Java EE Connector Arquitectura: Permite el acceso a otro tipo de sistemas de información empresarial por medio del desarrollo de un pluggin, similar a los conectores JDBC.
  • Java Autentícation and Authorization Service (JAAS): Provee servicios de seguridad de autenticación y autorización.
  • Servicios Web (JAX-WS): Para manejo de servicios web.

Introducción a los Servidores de Aplicaciones

Como consecuencia del éxito del lenguaje de programación Java, el término servidor de aplicaciones hace referencia a un servidor de aplicaciones Java EE.
Algunos servidores certificados de JEE son los siguientes:
  • JOnAS: servidor de aplicaciones de código abierto de ObjectWeb
  • JBoss: desarrollado inicialmente por JBoss Inc y adquirido posteriormente por Red Hat. Existe una versión de código abierto soportada por la comunidad y otra empresarial.
  • Sun Java System Application Server Platform Edition 9.0: Es un servidor basado en GlassFish.
  • Oracle WebLogic Application Server 10.0: antes conocido como BEA Systems.
  • Servidor de Aplicaciones SAP NetWeaver, Java EE 5 Edition de SAP
  • JEUS 6, un Servidor de aplicaciones específico de Linux de TmaxSoft
  • Apache Gerónimo 2.0
  • IBM WebSphere Application Server Community Edition 2.0: basado en el servidor Apache Gerónimo
  • Oracle Containers for Java EE 11
  • GlassFish: un servidor de aplicaciones de código abierto de Sun
  • Apache OpenEJB vía Apache Gerónimo


Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces. Un patrón de diseño resulta ser una solución a un problema de diseño.
Los patrones de diseño se pueden dividir en tres grandes categorías basadas en su propósito, que a su vez cada una se divide en patrones de Clases y Objetos:
  • Creacionales: Los patrones creacionales tratan con las formas de crear instancias de objetos. Usan la herencia (extends).
  • Estructurales: Los patrones estructurales describen como las clases y objetos pueden ser combinados para formar grandes estructuras y proporcionar nuevas funcionalidades. Estos objetos insertados pueden ser incluso objetos simples u objetos compuestos.
  • Comportamiento: Los patrones de comportamiento ayudan a definir la comunicación y relación entre los objetos de un sistema. El propósito de este patrón es reducir el acoplamiento entre los objetos.


Modelo Vista Controlador (MVC)

En este tipo de arquitectura conocida, el cliente hace Request(solicita) a objetos de la capa de presentación (Pagina del servidor), que luego llama a su código controlador para pedirle funcionalidad, que crea una presentación como Response(respuesta) a esa solicitud.
En los frameworks MVC, las URLs se mapean directamente a clases, estas son denominadas "Controladoras" y son las que procesan los Request entrantes, manejando las entradas del usuario, sus interacciones y ejecutando la lógica apropiada para el proceso. Una clase controladora llama a una vista, la cual genera la salida HTML que se enviará como Response.
El modelo MVC permite diseñar en tres capas de negocio y no poner todo el código en las interfaces de usuario de tu sistema (IU):
Capa de presentación: Con nuestras Interfaces (páginas HTML.) y sus controles visuales (controles de formulario) junto con sus eventos.
Capa de negocio: Lógica del dominio. Aquí irá todo el código que define las reglas de negocio (cálculos, validaciones). Surge de los procesos que hemos encontrado en el análisis.
Capa de acceso a datos: El código que permite acceder a las fuentes de datos. Esencialmente trata sobre 4 operaciones básicas, llamadas CRUD (por Create-Retrieve-Update y Delete), que se realizan sobre cualquier fuente de datos.
El modelo de arquitectura Model-View-Controller (MVC) separa una aplicación en tres componentes principales: el modelo, la vista y el controlador:
Modelos. Los objetos de modelo recuperan y almacenan el estado del modelo en una base de datos. Por ejemplo, un objeto Product podría recuperar información de una base de datos, trabajar con ella y, a continuación, escribir la información actualizada en una tabla Productos de una base de datos.
Vistas. Las vistas son los componentes que muestra la interfaz de usuario de la aplicación. Normalmente, esta interfaz de usuario se crea a partir de los datos de modelo.
Controladores. Los controladores son los componentes que controlan la interacción del usuario, trabajan con el modelo y por último seleccionan una vista para representar la interfaz de usuario.

Comunicación Síncrona y Asíncrona

Síncrona. Quien envía permanece bloqueado esperando a que llegue una respuesta del receptor antes de realizar cualquier otra tarea.

Asíncrona. Quien envía continúa con su ejecución inmediatamente después de enviar el mensaje al receptor.

La mayoría de las aplicaciones Web existentes realizan la comunicación de datos con el servidor de manera síncrona. En una comunicación síncrona, se ejecutan los procesos en el siguiente orden:
  1. El cliente realiza una petición al servidor.
  2. El servidor envía los datos solicitados y el cliente comienza a recibir los datos.
  3. Una vez finalizada la recepción de los datos en la página, el usuario vuelve a tener el control.
Este proceso conduce a que cada vez que se está enviando más información al servidor, el usuario pierde el control sobre la página Web que está visitando, limitándose de esta manera a esperar que la aplicación le devuelva el control.
En una aplicación Web que se comunica asíncronamente con el servidor, los procesos son los siguientes:
  1. El cliente realiza una solicitud al servidor.
  2. El servidor envía los datos solicitados
  3. El cliente comienza a recibir los datos.
El cliente en ningún momento pierde el control de las acciones sobre la página que está visualizando y permite acciones con el usuario durante la devolución de los datos.

La tecnología más importante dentro de las llamadas asíncronas es AJAX.

AJAX. Acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML). Ajax no es una tecnología, es el conjunto de muchas tecnologías (XHTML, CSS, DOM, XML, XSLT, XMLHttpRequest, JavaScript, Jquery). Dichas tecnologías se ejecutan en el navegador de los usuarios y mantiene comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre la misma página sin necesidad de recargarla. En aplicaciones AJAX se pueden enviar peticiones al servidor web para obtener solamente la información necesaria y así ahorrar ancho de banda. Su desventaja sería que el cargar la página inicial, el proceso es más lento, debido a que primero tiene que cargar todo el código JavaScript y XML que hará la implementación. Las acciones de la tecnología Ajax se ejecutan en el cliente, es decir, en el navegador del usuario, y mantiene comunicación asíncrona con el servidor en segundo plano. Las tecnologías que forman AJAX son:
  • XHTML y CSS, para crear una presentación basada en estándares.
  • DOM, para la interacción y manipulación dinámica de la presentación.
  • XML, XSLT y JSON, para el intercambio y la manipulación de información.
  • XMLHttpRequest, para el intercambio asíncrono de información.
  • JavaScript, para unir todas las demás tecnologías.

Capas de arquitectura JEE

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

Empaquetado de aplicaciones JEE

Existen tres tipos de empaquetados dentro de las aplicaciones JEE:

*Archivos JAR (Java Archive)

Características:
  • Permiten empaquetar diferentes archivos de java en uno solo.
  • Siguen el formato ZIP
  • Fueron incorporados en la versión 1.1 del JDK
  • Contienen clases Java y recursos que utilizan dichas clases
  • Es el empleado para empaquetar componentes EJBs respetando su estructura de directorios.

*Archivos WAR (Web Application Archive)

Características:
  • Permiten empaquetar en una sola unidad aplicaciones web java completas
  • Pueden empaquetar los siguientes elementos:
    • Java Server Pages (JSP)
    • Servlets
    • Contenido estático como css, HTML o imágenes
    • Otros recursos web

*Archivos EAR (Enterprise Application Archive)

Características:
  • Archivos desplegables en servidores de aplicaciones J2EE.
  • Contienen los siguientes elementos:
    • Archivos War
    • EJBs empaquetados dentro de ficheros jar
Una aplicación JEE se empaqueta en un archivo .ear que no es nada mas que un jar normal y corriente.
Debe contener obligatoriamente una carpeta META-INF y un fichero application.xml donde estará toda la meta-información, como su propio nombre indica.
Módulos web: ficheros .war que contienen la capa web
Módulos EJB: que contiene ficheros .jar.
Módulos de adaptadores de recursos
En la práctica, casi todo se reduce a un módulo war y pocos elementos más.
La estructura de un módulo web (empaquetado .war) es la siguiente:
/Raiz
/Raiz/WEB-INF
/Raiz/WEB-INF
/Raiz/WEB-INF/lib
/Raiz/WEB-INF/classes
/Raiz/WEB-INF/tags
El directorio Raíz contiene todos los archivos estáticos (HTML, gráficos, jsp, y los recursos estáticos de cualquier web)
El directorio WEB-INF debe contener un archivo web.xml que es la información que contendrá la meta-información de el archivo war.
El directorio WEB-INF/lib contiene las librerías de código .jar
El directorio WEB-INF/classes contendrá las clases compiladas
El directorio WEB-INF/lib contendrá las etiquetas personalizadas


Tecnologías en J2EE
La tecnología Enterprise JavaBeans (EJB) usa un modelo de componente para simplificar el desarrollo de aplicaciones de middleware (capas) con soporte automático de servicios como transacciones, seguridad y conectividad de base de datos.
*JavaMail es una API que proporciona una serie de clases abstractas que modelan un sistema de correo.
*Java Message Service (JMS) es una API que permite el desarrollo de aplicaciones portables y basadas en mensajes para la plataforma Java.
*JavaServer Faces (JSF) proporciona un modelo de programación que ayuda a crear aplicaciones Web.
*JavaServer Pages (JSP) permite que desarrolladores Web desarrollen rápidamente y mantengan fácilmente páginas Web dinámicas.
*Standard Tag Library for JavaServer Pages (JSTL) es un conjunto de etiquetas personalizadas que habilitan varias funciones comunes de Web sites en un formato estandarizado.
*Los Java Servlets amplían y mejoran el alcance de los servidores Web al proporcionar un método basado en componentes e independiente de plataforma para crear aplicaciones basadas en la Web sin las limitaciones de rendimiento de los programas CGI.
*La API Java Transaction (JTA) es una API de alto nivel, independiente de implementación y de protocolo que permite que aplicaciones y servidores de aplicaciones accedan a transacciones Java Transaction Service(JTS) especifica la implementación de un gestor de transacciones que soporta JTA e implementa la correlación entre Java y la especificación OMG.
Los componentes de software son unidades binarias de producción, adquisición y despliegue independientes, que al interactuar, forman un sistema en funcionamiento.
Un componente puede tener varias interfaces, una por cada punto de acceso: uso, administración y configuración.
Los componentes más utilizados podemos diferenciarlos entre los siguientes
  • Enterprise JavaBeans y el modelo de componentes de Java EE
  • La estructura de componentes de .NET
Un contenedor es un proceso donde se ejecutan los componentes.
Cuando un desarrollador crea un modelo de arquitectura basado en la plataforma JEE, debe especificar los siguientes elementos en el contenedor:
  • Los componentes de la aplicación
    • Servlets
    • JSPs (Java Server Pages)
    • EJBs (Enterprise Java Beans)
  • Los descriptores de despliegue
    • Ficheros XML que describen los componentes de la aplicación

Envío de información request y response HTTP

Una aplicación web es una aplicación que trabaja en un servidor y sobre la que un usuario accede desde un cliente general, como por ejemplo un navegador en un PC, un teléfono móvil o una PDA.
La comunicación en la Web gira en torno al protocolo http y sus características son las siguientes:
  • Protocolo de nivel de aplicación
  • Funciona sobre TCP
  • Usa el puerto 80 por defecto
  • Modelo petición/respuesta (request/response)
  • No tiene estado
  • Al igual que SMTP, es un protocolo ASCII, que usa MIME para transferir información no ASCII.
  • Tipos de peticiones: GET, POST, PUT, DELETE, TRACE, OPTIONS, HEAD

El formato estándar para peticiones http con el método get es la siguiente:

URL?dato1=valor1&dato2=valor2 ... &datoN=valorN
Debemos tener en cuenta los siguientes parámetros al enviar caracteres en el valor de un parámetro:
  • Caracteres ASCII alfanuméricos y signos. (punto), - (guión), * (asterisco) y _ (subrayado) son literales.
  • Debemos sustituir los espacios en blanco por el símbolo +.
  • Resto de caracteres son admitidos
Si un valor aparece repetido más de una vez en la cadena del envío, el parámetro correspondiente es recibido como un vector de valores. dato[0], dato[1], dato[2]