Servidor de aplicaciones

Tipo de servidor que permite el procesamiento de datos de una aplicación de cliente. Las principales ventajas de la tecnología de los servidores de aplicación es la centralización y la disminución de la complejidad del desarrollo de aplicaciones, dado que las aplicaciones no necesitan ser programadas; en su lugar, estas son ensambladas desde bloques provistos por el servidor de aplicación.

Interceptores

Los interceptores son eventos lanzados y escuchados mediante anotaciones que permite a los métpdps centrarse en una sola funcionalidad, es decir, permiteque el método se haga solo una cosa.

POO

La Programación Orientada a Objetos (POO u OOP según sus siglas en inglés) es un paradigma de programación que usa objetos y sus interacciones para diseñar aplicaciones y programas de ordenador.

Este tipo de programación, como su propio nombre indica, se basa en objetos que son entidades "independientes" con vida propia.

Conceptos fundamentales

Objeto: entidad que tiene atributos (variables) y métodos (funciones), se corresponden con los objetos reales.
Clase: definición de atributos y métodos de un objeto.
Método: son las funciones usadas en programación estructurada. También se puede definir como el "comportamiento" de un objeto.
Evento: suceso provocado en la aplicación ya sea por parte del usuario o por parte de un método.
Mensaje: comunicación entre objetos.

Características de la POO

Encapsulación: consiste en la ocultación de datos entre los objetos de una aplicación.
Polimorfismo: es la posibilidad de poder llamar a dos métodos con el mismo nombre recibiendo distintos parámetros devuelven el mismo tipo de dato. Esto se le conoce como sobrecarga de funciones.
Herencia: consiste en que unas clases llamadas "hijas" pueden tomar característicass de otras llamadas "padres". También la herencia se aplica a las interfaces.


Ejemplos:
Polimorfismo:
double velocidad();
double velocidad(double);
El primer método devuelve la velocidad actual y el segundo la devuelve la velocidad en m/s tras recibirla en k/h.
Herencia:
Public Class Vehiculo ------>clase padre
Public Class Coche extends Vehiculo ----> clase hija la herencia en java se indica con extends

AOP

AOP es la programación orientada a aspectos, esto hace que la aplicación se separe en aspectos, las pruebas y las codificaciones ya no son por objetos sino que varias clases que se crean con un fin determinado seguridad, envío de información, historial de sucesos conforman lo que se llama un Aspecto. Un aspecto no es más un pequeño sistema que se alimenta de cierta información y es capaz de generar ciertas acciones sin requerir de nadie más.
Así las pruebas que se realizan aquí van dirigidas al aspecto en sí, creándose todo el software a partir de las pruebas, es decir, se prepara la prueba y a posteriori se genera el código que debe superar las diferentes pruebas a las que es sometido.

EJB3

Los EJBs proporcionan un modelo de componentes distribuido estándar del lado del servidor. El objetivo de los EJBs es dotar al programador de un modelo que le permita abstraerse de los problemas generales de una aplicación empresarial (concurrencia, transacciones, persistencia, seguridad, ...) para centrarse en el desarrollo de la lógica de negocio en sí. El hecho de estar basado en componentes permite que éstos sean flexibles y sobre todo reutilizables.

No hay que confundir los Enterprise JavaBeans con los JavaBeans. Los JavaBeans también son un modelo de componentes creado por Sun Microsystems para la construcción de aplicaciones, pero no pueden utilizarse en entornos de objetos distribuidos al no soportar nativamente la invocación remota (RMI).

TIPOS:

Existen tres tipos de EJBs:

• EJBs de Entidad (Entity EJBs): su objetivo es encapsular los objetos del lado del servidor que almacena los datos. Los EJBs de entidad presentan la característica fundamental de la persistencia:
  • Persistencia gestionada por el contenedor (CMP): el contenedor se encarga de almacenar y recuperar los datos del objeto de entidad mediante el mapeo de una tabla de la base de datos.
  • Persistencia gestionada por el bean (BMP): el propio objeto entidad se encarga, mediante una base de datos u otro mecanismo, de almacenar y recuperar los datos a los que se refiere, por lo cual, la responsabilidad de implementar los mecanismos de persistencia es del programador.
  
  
• EJBs de Sesión (Session EJBs): gestionan el flujo de la información en el servidor. Generalmente sirven a los clientes como una fachada de los servicios proporcionados por otros componentes disponibles en el servidor. Puede haber dos tipos:
  
  • con estado (stateful). Los beans de sesión con estado son objetos distribuidos que poseen un estado. El estado no es persistente, pero el acceso al bean se limita a un solo cliente.
  • sin estado (stateless). Los beans de sesión sin estado son objetos distribuidos que carecen de estado asociado permitiendo por tanto que se los acceda concurrentemente. No se garantiza que los contenidos de las variables de instancia se conserven entre llamadas al método.
  
  
• EJBs dirigidos por mensajes (Message-driven EJBs): son los únicos beans con funcionamiento asíncrono. Usando el Java Messaging System (JMS), se suscriben a un tema (topic) o a una cola (queue) y se activan al recibir un mensaje dirigido a dicho tema o cola. No requieren de su instanciación por parte del cliente.

J2EE

Java Platform, Enterprise Edition o Java EE (anteriormente conocido como Java 2 Platform, Enterprise Edition o J2EE hasta la versión 1.4), es una plataforma de programación—parte de la plataforma Java—para desarrollar y ejecutar software de aplicaciones en Lenguaje de programación Java con arquitectura de niveles distribuida, basándose ampliamente en componentes de software modulares ejecutándose sobre un servidor de aplicaciones. La plataforma Java EE está definida por una especificación. Similar a otras especificaciones del Java Community Process, Java EE es también considerada informalmente como un estándar debido a que los suministradores deben cumplir ciertos requisitos de conformidad para declarar que sus productos son conformes a Java EE; no obstante sin un estándar de ISO o ECMA.

Una de las caracteristicas del desarrollo de aplicacione con J2EE es que gracias a una serie de librerias como son EasyMock, JUnit, TestNG, etc..., los programadores crean las aplicaciones a partir de pruebas, es decir, se va construyendo un entorno que obliga al programador a implementar las entidades necesarias para que estas pruebas cumplan su cometido.

TestNG

TestNG es una librería para pruebas (tests) que trabaja con Java y está basado en JUnit (para Java) y NUnit (para .NET), pero introduciendo nuevas funcionalidades que los hacen más poderosos y fáciles de usar, tales como:

• Anotaciones JDK 5 (Annotations) (JDK 1.4 también es soportado con JavaDoc annotations).
• Configuración flexible de pruebas.
• Soporte para pruebas para data-driven testing (con @DataProvider).
• Soporta el paso de parámetros.
• Permite distribución de las pruebas en maquinas esclavas.
• Modelo de ejecución poderoso (TestSuite nunca más).
• Soportado por herramientas y plugins importantes y variados como: (Eclipse, IDEA, Maven, etc...).
• Permite embeber BeanShell para una flexibilidad más amplia.
• Funciones JDK por defecto de runtime y logging. (sin dependencias)
• Métodos dependientes para pruebas sobre servidores de aplicación.

TestNG está diseñado para cubrir todas las categorías de las pruebas: unitarias, funcionales, end-to-end, integración, etc.

EasyMock

EasyMock es una librería muy útil para hacer pruebas unitarias con JUnit. Nos sirve para crear cualquier objeto fantasma (mock) y hacer que devuelva un resultado concreto para una entrada concreta.

Por ejemplo, si queremos probar un servicio que necesita un DAO para obtener un dato, podemos crear un DAO fantasma (mock) que realice esa función y así librarnos de dependencias y probar el servicio unitariamente.

Para usar EasyMock tan solo hay que hacer 3 cosas:

1. Crear el objeto fantasma (mock) con createMock

   IMyDAO mockDAO = EasyMock.createMock(IMyDAO.class); 

2. Proporcionar los parámetros de entrada concretos y los objetos de salida concretos (si es necesario) con expect:

   DAOPK pk = new DAOPK("111"); // clave de lo que se busca
   DAOReturn return = new DAOReturn("Alex");
   EasyMock.expect(mockDAO.find(pk)).andReturn(return); 

3. Generar la implementación del mock con replay:

   EasyMock.replay(mockDAO);

Así ya tendríamos un mock para el DAO y podríamos probar el servicio pasándole este mock:

MyService service = new MyService();
service.setDao(mockDAO);
Customer customer = new Customer("111");
service.findCustumer(customer);